2021 February 19 计算机网络

网络协议五：传输层

传输层（Transport）

  1. 传输层有2个协议
    1. TCP（Transmission Control Protocol），传输控制协议
    2. UDP（User Datagram Protocol），用户数据报协议

图1

UDP

数据格式

  1. UDP是无连接的，减少了建立和释放连接的开销
  2. UDP尽最大能力交付，不保证可靠交付
    1. 因此不需要维护一些复杂的参数，首部只有8个字节（TCP的首部至少20个字节）
  3. UDP长度（Length）
    1. 占16位，首部的长度 + 数据的长度 图1

检验和(Checksum)

  1. 检验和的计算内容：伪首部 + 首部 + 数据
  2. 伪首部：仅在计算检验和时起作用，并不会传递给网络层

图1

端口（Port）

  1. UDP首部中端口是占用2字节
    1. 可以推测出端口号的取值范围是：0~65535
  2. 客户端的源端口是临时开启的随机端口
  3. 防火墙可以设置开启\关闭某些端口来提高安全性
  4. 常用命令行
    1. netstat –an：查看本机已经被占用的端口
    2. netstat –anb：查看本机已经被占用的端口、占用端口的应用程序
    3. telnet 主机 端口：查看是否可以访问主机的某个端口
      1. 安装telnet：控制面板 – 程序 – 启用或关闭Windows功能 – 勾选“Telnet Client” – 确定

图1

TCP

数据格式

图1

  1. 数据偏移
    1. 占4位，取值范围是0x0101~0x1111
    2. 乘以4：首部长度（Header Length）
    3. 首部长度是20~60字节
  2. 保留
    1. 占6位，目前全为0
  3. 细节问题
    1. UDP的首部中有个16位的字段记录了整个UDP报文段的长度（首部+数据）
    2. 但是，TCP的首部中仅仅有个4位的字段记录了TCP报文段的首部长度，并没有字段记录TCP报文段的数据长度
    3. 分析
      1. UDP首部中占16位的长度字段是冗余的，纯粹是为了保证首部是32bit对齐
      2. TCP\UDP的数据长度，完全可以由IP数据包的首部推测出来
        1. 传输层的数据长度 = 网络层的总长度 – 网络层的首部长度 – 传输层的首部长度

检验和（Checksum）、标志位（Flags）

  1. 检验和
    1. 跟UDP一样，TCP检验和的计算内容：伪首部 + 首部 + 数据
    2. 伪首部：占用12字节，仅在计算检验和时起作用，并不会传递给网络层
  2. 标志位：
    1. URG（Urgent）
      1. 当URG=1时，紧急指针字段才有效。表明当前报文段中有紧急数据，应优先尽快传送
    2. ACK（Acknowledgment）
      1. 当ACK=1时，确认号字段才有效
    3. PSH（Push）
    4. RST（Reset）
      1. 当RST=1时，表明连接中出现严重差错，必须释放连接，然后再重新建立连接
    5. SYN（Synchronization）:建立连接时使用
      1. 当SYN=1、ACK=0时，表明这是一个建立连接的请求
      2. 若对方同意建立连接，则回复SYN=1、ACK=1
    6. FIN（Finish）:释放连接时使用
      1. 当FIN=1时，表明数据已经发送完毕，要求释放连接

序号、确认号、窗口

  1. 序号（Sequence Number）
    1. 占4字节
    2. 首先，在传输过程的每一个字节都会有一个编号
    3. 在建立连接后，序号代表：这一次传给对方的TCP数据部分的第一个字节的编号
  2. 确认号（Acknowledgment Number）
    1. 占4字节
    2. 在建立连接后，确认号代表：期望对方下一次传过来的TCP数据部分的第一个字节的编号
  3. 窗口（Window）
    1. 占2字节
    2. 这个字段有流量控制功能，用以告知对方下一次允许发送的数据大小（字节为单位）

TC的几个要点

  1. 可靠传输
  2. 流量控制
  3. 拥塞控制
  4. 连接管理
    1. 建立连接
    2. 释放连接

可靠传输

  1. TCP协议是如何保证传输的数据是可靠的呢？

停止等待ARQ协议

  1. ARQ（Automatic Repeat–reQuest），自动重传请求
    1. 超时重传：A发给B，如果一定时间B没有相应（没有接收到，或者接受到是错误直接丢弃），则为超时，重新发送M1
    2. 确认丢失：B接收到之后，返回给A确认消息，但是发送失败，或者中间发送错误，没有到达A，导致A重新发送M1，但此时B会得到2分相同的M1，B会丢弃掉重复的

    3. 确认迟到：B接收到之后，返回给A确认消息比较晚了，因此A也会重新发送M1，但此时B会得到2分相同的M1，B会丢弃掉重复的

      图1

  2. 疑问
    1. 若有个包重传了N次还是失败，会一直持续重传到成功为止么？
      1. 这个取决于系统的设置，比如有些系统，重传5次还未成功就会发送reset报文（RST）断开TCP连接
    2. 如果一个数据包非常大，分成n个传输，每个都这么传输、而且串行传输的话非常浪费时间？—连续ARQ协议+滑动窗口协议

连续ARQ协议+滑动窗口协议

图1

  1. 原理：发送方一次发送4个（根据接收方窗口的大小来确定）包，然后接收方只需要确认最后一个包即可
  2. 窗口大小在TCP协议的首部设置的有
  3. 疑问：
    1. 如果接收窗口最多能接收4个包，但发送方只发了2个包，接收方如何确定后面还有没有2个包？
      1. 等待一定时间后没有第3个包，就会返回确认收到2个包给发送方

SACK(选择性确认)

  1. 在TCP通信过程中，如果发送序列中间某个数据包丢失（比如1、2、3、4、5中的3丢失了）
  2. TCP会通过重传最后确认的分组后续的分组（最后确认的是2，会重传3、4、5）
  3. 这样原先已经正确传输的分组也可能重复发送（比如4、5），降低了TCP性能
  4. 为改善上述情况，发展出了SACK（Selective acknowledgment，选择性确认）技术
    1. 告诉发送方哪些数据丢失，哪些数据已经提前收到
    2. 使TCP只重新发送丢失的包（比如3），不用发送后续所有的分组（比如4、5）
  5. SACK信息会放在TCP首部的选项部分，具体设置的值如下：
    1. Kind：占1字节。值为5代表这是SACK选项
    2. Length：占1字节。表明SACK选项一共占用多少字节
    3. Left Edge：占4字节，左边界
    4. Right Edge：占4字节，右边界
  6. 一对边界信息需要占用8字节，由于TCP首部的选项部分最多40字节，所以
    1. SACK选项最多携带4组边界信息
    2. SACK选项的最大占用字节数 = 4 * 8 + 2 = 34
  7. 疑问：
    1. 为什么选择在传输层就将数据“大卸八块”分成多个段，而不是等到网络层再分片传递给数据链路层？
      1. 因为可以提高重传的性能
      2. 需要明确的是：可靠传输是在传输层进行控制的
        1. 如果在传输层不分段，一旦出现数据丢失，整个传输层的数据都得重传
        2. 如果在传输层分了段，一旦出现数据丢失，只需要重传丢失的那些段即可

流量控制

  1. 如果接收方的缓存区满了，发送方还在疯狂着发送数据
    1. 接收方只能把收到的数据包丢掉，大量的丢包会极大着浪费网络资源
    2. 所以要进行流量控制
  2. 什么是流量控制？
    1. 让发送方的发送速率不要太快，让接收方来得及接收处理
  3. 原理
    1. 通过确认报文中窗口字段来控制发送方的发送速率
    2. 发送方的发送窗口大小不能超过接收方给出窗口大小
    3. 当发送方收到接收窗口的大小为0时，发送方就会停止发送数据

图1

  1. 图中的rwnd：接收方窗口大小

特殊情况

  1. 有一种特殊情况
    1. 一开始，接收方给发送方发送了0窗口的报文段
    2. 后面，接收方又有了一些存储空间，给发送方发送的非0窗口的报文段丢失了
    3. 发送方的发送窗口一直为零，双方陷入僵局
  2. 解决方案
    1. 当发送方收到0窗口通知时，这时发送方停止发送报文
    2. 并且同时开启一个定时器，隔一段时间就发个测试报文去询问接收方最新的窗口大小
    3. 如果接收的窗口大小还是为0，则发送方再次刷新启动定时器

拥塞控制

图1

  1. 什么是拥塞：
    1. 链路的吞吐量是1000M
    2. 理想情况下：只要输入的负载和小于1000都不会拥堵，当超过1000时才拥堵、丢包
    3. 实际情况下：输入的负载和小于1000时就可能拥堵，继续增加还会造成死锁
    4. 拥塞：输入的负载和大于实际的吞吐量，造成包丢失
  2. 拥塞控制
    1. 防止过多的数据注入到网络中
    2. 避免网络中的路由器或链路过载
  3. 拥塞控制是一个全局性的过程
    1. 涉及到所有的主机、路由器
    2. 以及与降低网络传输性能有关的所有因素
    3. 是大家共同努力的结果
  4. 相比而言，流量控制是点对点通信的控制
  5. 拥塞控制常用的方法：
    1. 慢开始（slow start，慢启动）
    2. 拥塞避免（congestion avoidance）
    3. 快速重传（fast retransmit）
    4. 快速恢复（fast recovery）
  6. 常见的几个缩写
    1. MSS（Maximum Segment Size）：每个段最大的数据部分大小
      1. 在建立连接时确定
    2. cwnd（congestion window）：拥塞窗口
    3. rwnd（receive window）：接收窗口
    4. swnd（send window）：发送窗口
      1. swnd = min(cwnd, rwnd)

慢开始、拥塞避免、重传、恢复（略）

  1. 具体比较复杂略

建立连接

  1. 发送一个HTTP请求之前，要发送3次TCP请求，即三次握手建立连接

    图1

3次握手

  1. 数据的传输过程举例：
    1. 假设服务器要发送一个数据100字节给客户端，每个字节都有一个编号，比如每个字节的编号为1~100，每次能发送10个包，用10次发送。每次发送包的时候要告诉对方当前发送的包是从第几个字节开始的，比如第一次发送是从编号1(seq=1)开始的，第二次发送是从编号11(seq=11)开始的。。。
    2. 以上是理想情况，实际情况是编号不是从1开始，为了安全起见，每次发送数据都要在编号的基础上加上一个很大的初始值用于混淆作用，初始值是在建立连接的时候确定的。比如初始值为x，那么每次的序号就要加上x，比如：第一次1+x(seq=1+x)，第二次11+x(seq=11+x)。。。
    3. 以上说的是服务器一方。客户端一方也是同样的，每次发送给服务器的数据也是包含客户端的编号信息，编号信息用seq表示
    4. 发送方发送时总有seq、ack这两个参数值：seq值表示当前发送的数据字节开始编号，ack的值表示需要接收方给我发送从第几个字节开始的数据

  2. 三次握手过程如下

    图1

    1. 客户端、服务器分别有三种状态
      1. CLOSED：client处于关闭状态
      2. LISTEN：server处于监听状态，等待client连接
      3. SYN-RCVD：表示server接受到了SYN报文，当收到client的ACK报文后，它会进入到ESTABLISHED状态
      4. SYN-SENT：表示client已发送SYN报文，等待server的第2次握手
      5. ESTABLISHED：表示连接已经建立
    2. 客户端发送连接请求SYN=0,ACK=1,seq=x,此时客户端进入 SYN-SENT状态
      1. x是一个初始序号，就是每次发送的字节编号要加上这个相对初始序号才是最终的字节编号，避免外部破解，安全作用；
    3. 服务端接收到客户端发送过来的简历连接的请求，给客户端进行响应，SYN=1,ACK=1,seq=y，ack=x+1;服务器进入SYN-RCVD状态
      1. ACK=1表示同意接收连接，y值为服务端的字节编号初始序号，与x同理，只是是服务端每次发送字节编号的相对值。x+1表示确认号，表示要求客户端发送第1个字节的数据过来
    4. 客户端发送确认信息，ACK=1,seq=x+1，ack=y+1;客户端、服务端进入ESTABLISHED状态
      1. ACK=1表示确认号有效，x+1表示当前发送给服务端的数据是数据的第1个字节开始的数据；y+1表示要求服务端发送字节编号为1的数据过来
  3. 前2次握手的特点
    1. SYN都设置为1
    2. 数据部分的长度都为0
    3. TCP头部的长度一般是32字节
      1. 固定头部：20字节
      2. 选项部分：12字节
    4. 双方会交换确认一些信息
      1. 比如MSS、是否支持SACK、Window scale（窗口缩放系数）等
      2. 这些数据都放在了TCP头部的选项部分中（12字节）
  4. 疑问
    1. 为什么建立连接的时候，要进行3次握手？2次不行么？
      1. 主要目的：防止server端一直等待，浪费资源
    2. 如果建立连接只需要2次握手，可能会出现的情况
      1. 假设client发出的第一个连接请求报文段，因为网络延迟，在连接释放以后的某个时间才到达server
      2. 本来这是一个早已失效的连接请求，但server收到此失效的请求后，误认为是client再次发出的一个新的连接请求
      3. 于是server就向client发出确认报文段，同意建立连接
      4. 如果不采用“3次握手”，那么只要server发出确认，新的连接就建立了
      5. 由于现在client并没有真正想连接服务器的意愿，因此不会理睬server的确认，也不会向server发送数据
      6. 但server却以为新的连接已经建立，并一直等待client发来数据，这样，server的很多资源就白白浪费掉了
    3. 采用“三次握手”的办法可以防止上述现象发生
      1. 例如上述情况，client没有向server的确认发出确认，server由于收不到确认，就知道client并没有要求建立连接
    4. 第3次握手失败了，会怎么处理？
      1. 此时server的状态为SYN-RCVD，若等不到client的ACK，server会重新发送SYN+ACK包
      2. 如果server多次重发SYN+ACK都等不到client的ACK，就会发送RST包，强制关闭连接

释放连接

图1

  1. 为什么释放连接的时候，要进行4次挥手？
    1. TCP是全双工模式：双方同时进行相互发送
    2. 第1次挥手：当主机1发出FIN报文段时
      1. 表示主机1告诉主机2，主机1已经没有数据要发送了，但是，此时主机1还是可以接受来自主机2的数据
    3. 第2次挥手：当主机2返回ACK报文段时
      1. 表示主机2已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的
    4. 第3次挥手：当主机2也发送了FIN报文段时
      1. 表示主机2告诉主机1，主机2已经没有数据要发送了
    5. 第4次挥手：当主机1返回ACK报文段时
      1. 表示主机1已经知道主机2没有数据发送了。随后正式断开整个TCP连接
  2. 状态解读
    1. FIN-WAIT-1：表示想主动关闭连接
      1. 向对方发送了FIN报文，此时进入到FIN-WAIT-1状态
    2. CLOSE-WAIT：表示在等待关闭
      1. 当对方发送FIN给自己，自己会回应一个ACK报文给对方，此时则进入到CLOSE-WAIT状态
      2. 在此状态下，需要考虑自己是否还有数据要发送给对方，如果没有，发送FIN报文给对方
    3. FIN-WAIT-2：只要对方发送ACK确认后，主动方就会处于FIN-WAIT-2状态，然后等待对方发送FIN报文
    4. CLOSING：一种比较罕见的例外状态
      1. 表示你发送FIN报文后，并没有收到对方的ACK报文，反而却也收到了对方的FIN报文
      2. 如果双方几乎在同时准备关闭连接的话，那么就出现了双方同时发送FIN报文的情况，也即会出现CLOSING状态
      3. 表示双方都正在关闭连接
    5. LAST-ACK：被动关闭一方在发送FIN报文后，最后等待对方的ACK报文
      1. 当收到ACK报文后，即可进入CLOSED状态了
    6. TIME-WAIT：表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可进入CLOSED状态了
      1. 如果FIN-WAIT-1状态下，收到了对方同时带FIN标志和ACK标志的报文时
        1. 可以直接进入到TIME-WAIT状态，而无须经过FIN-WAIT-2状态
    7. CLOSED：关闭状态
    8. 由于有些状态的时间比较短暂，所以很难用netstat命令看到，比如SYN-RCVD、FIN-WAIT-1等
  3. 细节
    1. TCP/IP协议栈在设计上，允许任何一方先发起断开请求。这里演示的是client主动要求断开
    2. client发送ACK后，需要有个TIME-WAIT阶段，等待一段时间后，再真正关闭连接
      1. 一般是等待2倍的MSL（Maximum Segment Lifetime，最大分段生存期）
        1. MSL是TCP报文在Internet上的最长生存时间
        2. 每个具体的TCP实现都必须选择一个确定的MSL值，RFC 1122建议是2分钟
        3. 可以防止本次连接中产生的数据包误传到下一次连接中（因为本次连接中的数据包都会在2MSL时间内消失了）
    3. 如果client发送ACK后马上释放了，然后又因为网络原因，server没有收到client的ACK，server就会重发FIN
      1. 这时可能出现的情况是
        1. client没有任何响应，服务器那边会干等，甚至多次重发FIN，浪费资源
        2. client有个新的应用程序刚好分配了同一个端口号，新的应用程序收到FIN后马上开始执行断开连接的操作，本来 它可能是想跟server建立连接的
  4. 抓包
    1. 有时候在使用抓包工具的时候，有可能只会看到“3次“挥手
      1. 这其实是将第2、3次挥手合并了
    2. 当server接收到client的FIN时，如果server后面也没有数据要发送给client了
      1. 这时，server就可以将第2、3次挥手合并，同时告诉client两件事
        1. 已经知道client没有数据要发
        2. server已经没有数据要发了

    图1

All content is licensed under CC BY-NC-SA

Buit with Jekyll and 3-Jekyll theme • Hosted on Github

Table of Contents