计算机网络

计算机网络

• OSI模型
  • 物理层
    • 电流信号的传输
    • 为在物理介质上建立、维持和终止传输数据比特流的物理连接提供机械、电气、功能和过程的手段。
  • 数据链路层
    • 将比特组合成数据链路协议数据单元DL-PDU,特有单位帧(Frame)
  • 网络层
    • 关心通信子网的运行控制
    • 对通信子网进行路有选择
  • 传输层
    • 运输层为上层用户提供端对端的透明优化的数据传输服务。
    • 主机到主机的层次
  • 会话层
    • 进程到进程之间的层次。
  • 表示层
    • 数据压缩和加密
    • 提供共同需要的数据或信息语法表示变换
  • 应用层
    • 文件传送、访问和管理
    • 网络环境下传送标准电子邮件的文电处理系统
    • 方便不同类型终端和不同类型主机间通过网络交互访问的虚拟终端
• TCP/IP模型
  • 应用层
    • 对应应用层,表示层,会话层
  • 传输层
    • 对应传输层
  • 网际层
    • 对应网络层
  • 网络接口层
    • 对应数据链路层和物理层

---

数据链路层

帧:

封装成帧

• 一个控制字符SOH (Start Of Header)放在一帧的最前面，表示帧的首部开始。另一个控制字符EOT (End Of Transmission)表示帧的结束。请注意，SOH和EOT都是控制字符的名称。它们的十六进制编码分别是01（二进制是00000001）和04（二进制是00000100）。SOH（或EOT）并不是S，O，H（或E，O，T）三个字符。

透明传输

• 转义字符“ESC”(其十六进制编码是1B，二进制是00011011)。 转义SOH(EOF)
• 如果转义字符也出现在数据当中，那么解决方法仍然是在转义字符的前面插入一个转义字符。因此，当接收端收到连续的两个转义字符时，就删除其中前面的一个。

差错检测

• 比特差错: 1可能会变成0，而0也可能变成1。这就叫做比特差错。比特差错是传输差错中的一种。本小节所说的“差错”，如无特殊说明，就是指“比特差错
• 误码率:传输错误的比特占所传输比特总数的比率称为误码率BER (Bit Error Rate)。

• 帧丢失：收到[#1]-[#3]（丢失[#2]）。
• 帧重复：收到[#1]-[#2]-[#2]-[#3]（收到两个[#2]）。
• 失序：收到[#1]-[#3]-[#2]（后发送的帧反而先到达了接收端，这与一般数据链路层的传输概念不一样）。

---

ARP协议

ARP协议:地址解析协议(网络层)

• 在主机ARP高速缓存中应存放一个从IP地址到硬件地址的映射表，并且这个映射表还经常动态更新（新增或超时删除）。
• 查询步骤
  1. 先在其ARP高速缓存中查看有无主机B的IP地址。如有，就在ARP高速缓存中查出其对应的硬件地址，再把这个硬件地址写入MAC帧，然后通过局域网把该MAC帧发往此硬件地址。
  2. 无
     在本局域网上广播发送一个ARP请求分组。ARP请求分组的主要内容是：“我的IP地址是209.0.0.5，硬件地址是00-00-C0-15-AD-18。我想知道IP地址为209.0.0.6的主机的硬件地址。”
  3. 在本局域网上的所有主机上运行的ARP进程都收到此ARP请求分组。
  4. 主机B的IP地址与ARP请求分组中要查询的IP地址一致，就收下这个ARP请求分组，并向主机A发送ARP响应分组，并在这个ARP响应分组中写入自己的硬件地址。由于其余的所有主机的IP地址都与ARP请求分组中要查询的IP地址不一致，因此都不理睬这个ARP请求分组。ARP响应分组的主要内容是表明：“我的IP地址是209.0.0.6，我的硬件地址是08-00-2B-00-EE-0A。”请注意：虽然ARP请求分组是广播发送的，但ARP响应分组是普通的单播，即从一个源地址发送到一个目的地址。
  5. 主机A收到主机B的ARP响应分组后，就在其ARP高速缓存中写入主机B的IP地址到硬件地址的映射。

ARP是解决同一个局域网上的主机或路由器的IP地址和硬件地址的映射问题。

---

IP数据报的格式

32位（4字节）为单位来描述

• 首部 前一部分是固定长度，（20字节），后面是一部分可选字段，长度可变
  • 版本 4位
  • 首部长度 4位 最常用的首部长度是20字节，0101
  • 区分服务 8位 服务类型
  • 总长度 首部和数据之和的长度 单位为字节
  • 片偏移 13位，以八字节为偏移单位，因此片偏移一定是8的整数倍
• 数据

---

IP/ICMP协议

ICMP协议

ICMP允许主机或路由器报告差错情况和提供有关异常情况的报告。

ICMP报文的种类有两种，即ICMP差错报告报文和ICMP询问报文。

ICMP报文的前4个字节是统一的格式，共有三个字段：即类型、代码和检验和。接着的4个字节的内容与ICMP的类型有关。最后面是数据字段，其长度取决于ICMP的类型。

• (1) 终点不可达 当路由器或主机不能交付数据报时就向源点发送终点不可达报文。
• (2) 源点抑制 当路由器或主机由于拥塞而丢弃数据报时，就向源点发送源点抑制报文，使源点知道应当把数据报的发送速率放慢。
• (3) 时间超过 当路由器收到生存时间为零的数据报时，除丢弃该数据报外，还要向源点发送时间超过报文。当终点在预先规定的时间内不能收到一个数据报的全部数据报片时，就把已收到的数据报片都丢弃，并向源点发送时间超过报文。
• (4) 参数问题 当路由器或目的主机收到的数据报的首部中有的字段的值不正确时，就丢弃该数据报，并向源点发送参数问题报文。
• (5) 改变路由（重定向） 路由器把改变路由报文发送给主机，让主机知道下次应将数据报发送给另外的路由器（可通过更好的路由）。

---

下面是不应发送ICMP差错报告报文的几种情况。

• 对ICMP差错报告报文不再发送ICMP差错报告报文。
• 对第一个分片的数据报片的所有后续数据报片都不发送ICMP差错报告报文。
• 对具有多播地址的数据报都不发送ICMP差错报告报文。
• 对具有特殊地址（如127.0.0.0或0.0.0.0）的数据报不发送ICMP差错报告报文。

---

ICMP的一个重要应用就是分组网间探测PING (Packet InterNet Groper)，用来测试两个主机之间的连通性。

---

TCP/UDP协议

运输层需要有两种不同的运输协议，即面向连接的TCP 和无连接的UDP
TCP/IP运输层的两个主要协议都是因特网的正式标准，即 ：
(1) 用户数据报协议UDP (User Datagram Protocol) [RFC 768] TPC报文段
(2)传输控制协议TCP (Transmission Control Protocol) [RFC 793] UDP用户数据报

UDP协议

用户数据报协议UDP只在IP的数据报服务之上增加了很少一点的功能，这就是复用和分用的功能以及差错检测的功能。UDP的主要特点是：

• UDP是无连接的，因此减少了开销和发送数据之前的时延。
• UDP即不保证可靠交付，因此主机不需要维持复杂的连接状态表（这里面有许多参数）。
• UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP多长的报文，UDP就照样发送，即一次发送一个报文，也就是说，UDP一次交付一个完整的报文。因此，应用程序必须选择合适大小的报文。若报文太长，UDP把它交给IP层后，IP层在传送时可能要进行分片，这会降低IP层的效率。反之，若报文太短，UDP把它交给IP层后，会使IP数据报的首部的相对长度太大，这也降低了IP层的效率。
• UDP没有拥塞控制，这对某些实时应用是很重要的。很多的实时应用（如IP电话、实时视频会议等）要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延。UDP正好适合这种要求。
• UDP支持一对一、一对多、多对一和多对多的交互通信。
• UDP的首部开销小，只有8个字节，比TCP的20个字节的首部要短。
  UDP报文格式
  首部字段
• 源端口 源端口号 在需要对方回信时选用
• 目的端口
• 长度 最小值是8
• 检验和 检测UDP用户数据包在传输中是否有错，有错丢弃

TCP协议

• TCP是面向连接的运输层协议 需要先建立连接，在传输数据完毕后释放连接
• 每一条TCP连接都是点对点的
• 可靠交付 无差错，不丢失，不重复，按序抵达
• 全双工信道 在任何时候都能发送苏。设有发送缓存和接收缓存
• 面向字节流

每一条TCP连接唯一地被通信两端的两个端点（即两个套接字）所确定 192.3.4.5:80

---

可靠传输

停止等待协议
自动重传请求ARQ

• 每发送完一个分组就停止发送，等待对方应答。
• 当第一个数据报丢失或被丢弃时，A主机超时重传。
• A在发送完第一个分组后，暂时保留副本，在收到确认后清楚
• 分组和确认分组进行编号
• 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。
  确认收到丢失后重复传输
• 丢弃重复分组，不向上层交付
• 向A发送确认
• 确认迟到。收下后丢弃
  缺点：信道利用率太低。
  连续ARQ协议（滑动窗口）
• 在没收到B的确认时，A可以连续吧窗口内的数据都发送出去，但是发送出去的数据在没有收到确认之前都必须暂时保留，以便超时重传
• 窗口越大，传输效率越高
  发送缓存用来暂时存放
• 发送应用程序传送给发送方TCP准备发送的数据
• TCP已发送但尚未收到确认的数据
  接收缓存用来暂时存放
• 按序到达，但尚未被接收应用程序读取的数据
• 未按序到达的数据

对于不按序到达的数据应如何处理，TCP标准并无明确规定。如果接收方把不按序到达的数据一律丢弃，那么接收窗口的管理将会比较简单，但这样做对网络资源的利用不利（因为发送方会重复传送较多的数据）。因此TCP通常对不按序到达的数据是先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。

选择确认SACK

TCP的接收方在接收对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块。可以看出，序号1～1000收到了，但序号1001～1500没有收到。接下来的字节流又收到了，可是又缺少了3001～3500。再后面从序号4501起又没有收到。也就是说，接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。

• 在TCP首部的选项中加上“允许SACK”的选项
• SACK文档并没有指明发送方应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。

TCP的流量控制

流量控制(flow control)就是让发送方的发送速率不要太快，要让接收方来得及接收。

发送方的发送窗口不能超过接收方给出的接收窗口的数值。TCP的窗口单位是字节，不是报文段

打破死锁，持续计数器，当一方收到零窗口通知时，就启动持续计数器，时间到期后就发送一个零窗口探测报文段。

在TCP的实现中广泛使用Nagle算法。算法如下：若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把第一个数据字节先发送出去，把后面到达的数据字节都缓存起来。当发送方收到对第一个数据字符的确认后，再把发送缓存中的所有数据组装成一个报文段发送出去，同时继续对随后到达的数据进行缓存。只有在收到对前一个报文段的确认后才继续发送下一个报文段。当数据到达较快而网络速率较慢时，用这样的方法可明显地减少所用的网络带宽。Nagle算法还规定，当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。这样做，就可以有效地提高网络的吞吐量。

TCP的拥塞控制

若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞(congestion)。

拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。

拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程

流量控制往往指点对点通信量的控制，是个端到端的问题（接收端控制发送端）

开环控制方法就是在设计网络时事先将有关发生拥塞的因素考虑周到，力求网络在工作时不产生拥塞。但一旦整个系统运行起来，就不再中途进行改正了。

闭环控制

• 监测网络系统以便检测到拥塞在何时、何处发生。
• 把拥塞发生的信息传送到可采取行动的地方。
• 调整网络系统的运行以解决出现的问题。
  进行拥塞控制的四种算法
• 慢开始(slow-start)
  • 由小到大逐渐增大发送窗口，也就是说，由小到大逐渐增大拥塞窗口数值
  • 每经过一个传输轮次(transmission round)，拥塞窗口cwnd就加倍。
• 拥塞避免(congestion avoidance)
  • 拥塞避免算法的思路是让拥塞窗口cwnd缓慢地增大，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1[插图]，而不是加倍。这样，拥塞窗口cwnd 按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。

当cwnd < ssthresh时，使用上述的慢开始算法。当cwnd > ssthresh时，停止使用慢开始算法而改用拥塞避免算法。当cwnd = ssthresh时，既可使用慢开始算法，也可使用拥塞避免算法。

• 快重传(fast retransmit)
  • 快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认
  • 发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段M3，而不必继续等待为M3设置的重传计时器到期。
  • 由于发送方能尽早重传未被确认的报文段，因此采用快重传后可以使整个网络的吞吐量提高约20%。
• 快恢复(fast recovery)
  • 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半。这是为了预防网络发生拥塞。请注意，接下去不执行慢开始算法。
  • 由于发送方现在认为网络很可能没有发生拥塞（如果网络发生了严重的拥塞，就不会一连有好几个报文段连续到达接收方，也就不会导致接收方连续发送重复确认），因此与慢开始不同之处是现在不执行慢开始算法（即拥塞窗口cwnd现在不设置为1），而是把cwnd值设置为慢开始门限ssthresh减半后的数值，然后开始执行拥塞避免算法（“加法增大”），使拥塞窗口缓慢地线性增大。

TCP运输连接
连接建立---->数据传送---->连接释放。

• A主动打开连接，而B被动打开连接。
  三次握手
• A的TCP客户进程也是首先创建传输控制模块TCB，然后向B发出连接请求报文段，这时首部中的同步位SYN = 1，同时选择一个初始序号seq = x。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。
• B收到连接请求报文段后，如同意建立连接，则向A发送确认。在确认报文段中应把SYN位和ACK位都置1，确认号是ack = x + 1，同时也为自己选择一个初始序号seq = y。这时TCP服务器进程进入SYN-RCVD（同步收到）状态。
• TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号ack = y + 1，而自己的序号seq = x + 1。TCP连接已经建立，A进入ESTABLISHED（已建立连接）状态。

为什么A还要发送一次确认呢？这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。

连接释放

• A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。A进入FIN-WAIT-1（终止等待1）状态，等待B的确认。
• B收到连接释放报文段后即发出确认。TCP连接处于半关闭(half-close)状态，即A已经没有数据要发送了，但B若发送数据，A仍要接收。也就是说，从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。
• A收到来自B的确认后，就进入FIN-WAIT-2（终止等待2）状态，等待B发出的连接释放报文段。
• 若B已经没有要向A发送的数据，其应用进程就通知TCP释放连接。这时B就进入LAST-ACK（最后确认）状态，等待A的确认。
• A在收到B的连接释放报文段后，必须对此发出确认。然后进入到TIME-WAIT（时间等待）状态。必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后，A才进入到CLOSED状态。

MSL叫做最长报文段寿命(Maximum Segment Lifetime)，RFC 793建议设为2分钟。但这完全是从工程上来考虑，对于现在的网络，MSL = 2分钟可能太长了一些。因此TCP允许不同的实现可根据具体情况使用更小的MSL值。因此，从A进入到TIME-WAIT状态后，要经过4分钟才能进入到CLOSED状态，才能开始建立下一个新的连接。当A撤销相应的传输控制块TCB后，就结束了这次的TCP连接。
上述的TCP连接释放过程是四次握手。
为什么A在TIME-WAIT状态必须等待2MSL的时间呢？
这有两个理由。第一，为了保证A发送的最后一个ACK报文段能够到达B。这个ACK报文段有可能丢失，因而使处在LAST-ACK状态的B收不到对已发送的FIN + ACK报文段的确认。B会超时重传这个FIN +ACK报文段，而A就能在2MSL时间内收到这个重传的FIN + ACK报文段。接着A重传一次确认，重新启动2MSL计时器。最后，A和B都正常进入到CLOSED状态。如果A在TIME-WAIT状态不等待一段时间，而是在发送完ACK报文段后立即释放连接，那么就无法收到B重传的FIN + ACK报文段，因而也不会再发送一次确认报文段。这样，B就无法按照正常步骤进入CLOSED状态。
第二，防止上一节提到的“已失效的连接请求报文段”出现在本连接中。A在发送完最后一个ACK报文段后，再经过时间2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个新的连接中不会出现这种旧的连接请求报文段。

---

DNS/HTTP/HTTPS协议

DNS协议

假定域名为m.xyz.com的主机想知道另一个主机（域名为y.abc.com）的IP地址。例如，主机m.xyz.com打算发送邮件给主机y.abc.com。这时就必须知道主机y.abc.com的IP地址。下面是图6-5(a)的几个查询步骤：

• 主机m.xyz.com先向其本地域名服务器dns.xyz.com进行递归查询。
• 本地域名服务器采用迭代查询。它先向一个根域名服务器查询。
• 根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.com的IP地址。
• 本地域名服务器向顶级域名服务器dns.com进行查询。
• 顶级域名服务器dns.com告诉本地域名服务器，下一次应查询的权限域名服务器dns.abc.com的IP地址。
• 本地域名服务器向权限域名服务器dns.abc.com进行查询。
• 权限域名服务器dns.abc.com告诉本地域名服务器，所查询的主机的IP地址。
• 本地域名服务器最后把查询结果告诉主机m.xyz.com。

HTTP协议

HTTP是面向事务的(transaction-oriented)[插图]应用层协议，它是万维网上能够可靠地交换文件（包括文本、声音、图像等各种多媒体文件）的重要基础。
HTTP特点：

• 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作
• 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接。比如某个客户机在短时间多次请求同一个资源，服务器并不能区别是否已经响应过用户的请求，所以每次需要重新响应请求，需要耗费不必要的时间和流量。
• 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
• 简单快速、灵活
• 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

HTTPS协议

HTTPS特点：

• 基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护
• 内容加密：采用混合加密技术，中间者无法直接查看明文内容
• 验证身份：通过证书认证客户端访问的是自己的服务器
• 保护数据完整性：防止传输的内容被中间人冒充或者篡改
  二者相比较
• HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
• SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行

中间人攻击（MITM攻击）是指，黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM，被动MITM只窃取通信数据而不修改，而主动MITM不但能窃取数据，还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。
成本考虑：

• SSL证书需要购买申请，功能越强大的证书费用越高
• SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗（SSL有扩展可以部分解决这个问题，但是比较麻烦，而且要求浏览器、操作系统支持，
• Windows XP就不支持这个扩展，考虑到XP的装机量，这个特性几乎没用）。
• 根据ACM CoNEXT数据显示，使用HTTPS协议会使页面的加载时间延长近50%，增加10%到20%的耗电。
• HTTPS连接缓存不如HTTP高效，流量成本高。
• HTTPS连接服务器端资源占用高很多，支持访客多的网站需要投入更大的成本。
• HTTPS协议握手阶段比较费时，对网站的响应速度有影响，影响用户体验。比较好的方式是采用分而治之，类似12306网站的主页使用HTTP协议，有关于用户信息等方面使用HTTPS。

---

Session/Cookie

• cookie只是实现session的其中一种方案 虽然是最常用的,但并不是唯一的方法 禁用cookie后还有其他方法存储,比如放在url中
• 现在大多都是Session + Cookie,但是只用session不用cookie,或是只用cookie,不用session在理论上都可以保持会话状态 可是实际中因为多种原因,一般不会单独使用
• 用session只需要在客户端保存一个id,实际上大量数据都是保存在服务端 如果全部用cookie,数据量大的时候客户端是没有那么多空间的
• 如果只用cookie不用session,那么账户信息全部保存在客户端,一旦被劫持,全部信息都会泄露 并且客户端数据量变大,网络传输的数据量也会变大

TOKEN

token可以抵抗csrf攻击

受害者 Bob 在银行有一笔存款，通过对银行的网站发送请求 http://bank.example/withdraw?account=bob&amount=1000000&for=bob2 可以使 Bob 把 1000000 的存款转到 bob2 的账号下。通常情况下，该请求发送到网站后，服务器会先验证该请求是否来自一个合法的 session，并且该 session 的用户 Bob 已经成功登陆。
黑客 Mallory 自己在该银行也有账户，他知道上文中的 URL 可以把钱进行转帐操作。Mallory 可以自己发送一个请求给银行：http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory。但是这个请求来自 Mallory 而非 Bob，他不能通过安全认证，因此该请求不会起作用。
这时，Mallory 想到使用 CSRF 的攻击方式，他先自己做一个网站，在网站中放入如下代码： src=”http://bank.example/withdraw?account=bob&amount=1000000&for=Mallory ”，并且通过广告等诱使 Bob 来访问他的网站。当 Bob 访问该网站时，上述 url 就会从 Bob 的浏览器发向银行，而这个请求会附带 Bob 浏览器中的 cookie 一起发向银行服务器。大多数情况下，该请求会失败，因为他要求 Bob 的认证信息。但是，如果 Bob 当时恰巧刚访问他的银行后不久，他的浏览器与银行网站之间的 session 尚未过期，浏览器的 cookie 之中含有 Bob 的认证信息。这时，悲剧发生了，这个 url 请求就会得到响应，钱将从 Bob 的账号转移到 Mallory 的账号，而 Bob 当时毫不知情。等以后 Bob 发现账户钱少了，即使他去银行查询日志，他也只能发现确实有一个来自于他本人的合法请求转移了资金，没有任何被攻击的痕迹。而 Mallory 则可以拿到钱后逍遥法外。