【学习笔记】计算机网络（五）

第5章 运输层

5.1 运输层协议概述

5.1.1 进程之间的通信

通信： 两台主机之间的通信 —— 真正进行通信的实体是主机中的应用进程，是一台主机中的应用进程和另一台主机中的应用进程在交换数据(即通信)。【端到端的通信是应用进程之间的通信】

• 网络层为主机之间的通信提供服务
• 运输层则在网络层的基础上，为应用进程之间的通信提供服务。

复用(multiplexing)： 在发送方不同的应用进程都可以使用同一个运输层协议传送数据(当然需要加上适当的首部)

分用(demultiplexing)： 接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程

5.1.2 运输层的两个主要协议

• 用户数据报协议 UDP(User Datagram Protocol)
  • 不可靠交付【不可靠的:接收方无论收没收到数据、数据是否正确，者都不给发送方反馈】
  • 无连接的
• 传输控制协议 TCP(Transmission Control Protocol)
  • 面向连接：在传送数据之前必须先建立连接，数据传送结束后要释放连接。
  • TCP不提供广播或多播服务。
  • 可靠交付【可靠的:接收方使用“确认机制让发送方知道哪些数据已被正确接收】

OSI：运输协议数据单元TPDU(Transport Protocol Data Unit)——两个对等运输实体在通信时传送的数据单位。

TCP/IP：根据所使用的协议是 TCP 或UDP，分别称之为 TCP报文段(segment)或 UDP用户数据报。

5.1.3 运输层的端口

IP地址 + 端口号 -> 指向网络中一台主机上的一个特定的进程

协议端口(protocol port) - 简称为端口(port)：

• 每一个端口用一个称为端口号(port number)的正整数来标志。
• 软件端口：是应用层的各种协议进程与运输实体进行层间交互的地点
• 不同主机的端口号是相互独立的
• TCP、UDP的端口号也是相互独立的
• 端口具有缓存功能：必须有一定容量的缓存来暂时存放数据。

当两个进程之间想要通信时，需要指明: ①使用哪种传输层协议; ②本进程绑定的端口号; ③对方的IP地址和端口号;

• 当应用层要发送数据时，应用进程就把数据发送到适当的端口，然后运输层从该端口读取数据，进行后续的处理(把数据发送到目的主机)。

• 当运输层收到对方主机发来的数据时，就把数据发送到适当的端口，然后应用进程就从该端口读取这些数据。

端口号：

• 16位，可允许有65535个不同的端口

• 只具有本地意义 —— 在互联网不同计算机中，相同的端口号是没有关联的。

• 分类：

  • 服务器端使用的端口号

    • 熟知端口号(well-known port number)或全球通用端口号：数值为 0~1023
      指派给了 TCP/IP最重要的一些应用程序

      应用程序	FTP	TELNET	SMTP	DNS	TFTP	HTTP	SNMP	SNMP(trap)	HTTPS
      熟知端口号	21	23	25	53	69	80	161	162	443

    • 登记端口号: 数值为 1024~49151

  • 客户端使用的端口号: 数值为 49152~65535 【又叫作短暂端口号】，临时使用。

5.2 用户数据报协议 UDP

5.2.1 UDP 概述

UDP 只在IP 的数据报服务之上增加了很少一点的功能：

• 复用和分用的功能;
• 差错检测的功能：检测出错误后直接丢弃数据且不通知发送方

UDP特点：简单方便，但不可靠

• UDP是无连接的。即发送数据之前不需要建立连接，发送数据结束时也没有连接可释放，因此减少了开销和发送数据之前的时延。
• UDP使用尽最大努力交付，即不保证可靠交付。所发送的报文在传输过程中有可能丢失，同时也不保证报文都能按照发送的先后顺序到达终点。
• UDP是面向报文的。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界，即一次发送一个报文。 在接收方的UDP，对I层交上来的UDP用户数据报，在去除首部后就原封不动地交付上层的应用进程。【UDP一次交付一个完整的报文】
• UDP没有拥塞控制。网络出现的拥塞不会使源主机的发送速率降低。很多的实时应用(如IP电话、实时视频会议等)要求源主机以恒定的速率发送数据，并且允许在网络发生拥塞时丢失一些数据，但却不允许数据有太大的时延，UDP正好适合这种要求。
• UDP 支持一对一、一对多、多对一和多对多的交互通信。
• UDP的首部开销小，只有8个字节。TCP 的首部 20 个字节。

UDP使用场景：

• 可以重复请求信息的情况下:
  • 例如:RIP, DNS，DHCP等。
• 一次性传小量数据的应用(面向报文的)
• 实时应用:
  • IP电话、视频会议、多媒体、直播等。

5.2.2 UDP的首部格式

• 数据字段
• 首部字段：8个字节，4个字段，每个字段2个字节
  • 源端口：源端口号。在需要对方回信时选用。不需要时可用全0。
  • 目的端口：目的端口号。这在终点交付报文时必须使用。
    如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用进程)，就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。
  • 长度：UDP用户数据报的长度，其最小值是8(仅有首部)。
  • 检验和：检测UDP用户数据报在传输中是否有错。有错就丢弃。

​

5.3 传输控制协议 TCP 概述

5.3.1 TCP 最主要的特点

• TCP 是面向连接的: 在使用TCP协议之前，必须先建立 TCP连接。在传送数据完毕后，必须释放已经建立的TCP连接。

• TCP 连接只能有两个端点，TCP 连接是点对点的(一对一);

• TCP 提供可靠交付的服务：通过 TCP连接传送的数据，无差错、不丢失、不重复并且按序到达。

• TCP 有拥塞控制。

• TCP 提供全双工通信：TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。

• 面向字节流:

  • TCP 中的"流”(stream)指的是流入或流出进程的字节序列;

  • 面向字节流：虽应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅是一连串无结构的字节流。

    • 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系。

    • 接收方应用程序收到的字节流 必须和发送方应用程序发出的字节流 完全一样。

    • 接收方的应用程序必须有能力识别收到的字节流，把它还原成有意义的应用层数据。

  

面向连接：

• 面向连接的电路交换（物理层保证可靠）：

  通信双方之间必须有一条物理连接的通路(直接相连)，且被通信双方独享，数据按序发送并按序接收。

• 面向连接TCP（运输层协议保证可靠）：

  采用协议的方法(确认、序号、重传)，确保通信双方有一条全双工的、可靠的逻辑信道(事实上，提供服务的IP数据报是不可靠的)，字节按序发送并按序接收(但网络层IP数据报并不一定按序到达)

5.3.2 TCP 的连接

每一条 TCP 连接有两个端点，TCP 连接的端点叫做 套接字(socket)或插口 。

套接字格式：

• 套接字 socket=(IP地址:端口号)
• TCP 连接::={socket1,socket2}={(IP1: port1),(IP2: port2)}

• 同一个 IP 地址可以有多个不同的TCP 连接;
• 同一个端口号也可以出现在多个不同的 TCP 连接中。

5.4 可靠传输的工作原理

流量控制： 控制发送方发送帧的速率别太快让接收方"来得及"接受

可靠传输： 解决帧错

滑动窗口机制：

流量控制、可靠传输 两种功能都可以基于滑动窗口机制来实现

发送窗口W_T： 发送方当前允许发送的帧

接收窗口W_R： 接收方当前允许接收的帧

5.4.1 停止等待协议

停止-等待协议（S-W） - 发送窗口 = 1；接收窗口 = 1

滑动窗口机制：W_T=1，W_R=1

确认机制：确认帧ACK_i —— 若接收方收到i号帧，且没有检测出“差错”，需要给发送方返回确认帧 ACK_i

重传机制：超时重传 —— 若发送方超时未收到ACK_i，则重传i号帧

帧编号：1 bit 编号 且 W_T + W_R ≤ 2ⁿ

停止-等待协议（S-W）的信道利用率：

5.4.2 连续 ARQ 协议

• 滑动窗口协议： 停止-等待协议不属于“滑动窗口协议”范畴，GBN 和 SR【发送窗口大于1】属于“滑动窗口协议”范畴

• ARQ协议: 即Automatic repeat request，通常译为“自动重传清求”协议，包含 S-W、GBN、SR三种协议

• 连续ARQ协议： GBN 和 SR【发送窗口大于1】属于“连续ARQ协议”范畴

后退N帧协议（GO-BACK-N，GBN） - 发送窗口 ＞ 1；接收窗口 = 1

滑动窗口机制：W_T＞1，W_R=1

确认机制：确认帧ACK_i —— 若接收方收到i号帧，且没有检测出“差错”，需要给发送方返回确认帧 ACK_i

重传机制：超时重传 —— 若发送方超时未收到ACK_i，则重传i号帧

帧编号：至少 n bit 编号 且 W_T + W_R ≤ 2ⁿ

特殊规则：

• 关于 确认帧: 接收方可以“累积确认"。即连续收到多个数据帧时，可以仅返回最后一个帧的ACK
  【ACK_i表示接收方已收到i号帧及其之前的所有帧】
• 关于 超时重传: 若发送方超时未收到ACK_i，则重传i号帧，及其之后的所有帧

选择重传协议（SR） - 发送窗口 ＞ 1；接收窗口 > 1

滑动窗口机制：W_T＞1，W_R＞1

确认机制：确认帧ACK_i —— 若接收方收到i号帧，且没有检测出“差错”，需要给发送方返回确认帧 ACK_i【不支持“累计确认”，必须一帧一确认】

重传机制：超时重传 —— 若发送方超时未收到ACK_i，则重传i号帧

帧编号：至少 n bit 编号 且 W_T + W_R ≤ 2ⁿ

特殊规则：

• 否认帧 NAK_i：若接收方收到 i 号帧，但检测出i号帧有“差错”，需要丢弃该帧，并给发送方返回否认帧 NAK_i
• 请求重传 : 若发送方收到NAK_i，则重传i号帧
• 要求 : 接收窗口不能大于发送窗口 W_R ≤ W_T 实际应用通常 W_R = W_T

GBN 和 SR的信道利用率：

真题：

5.5 TCP报文段的首部格式

• TCP 是面向字节流的，但TCP 的数据单元是报文段；
• TCP 报文段分为首部和数据两部分，TCP的全部功能体现在首部中各字段的作用；
• TCP 报文段首部的前20个字节是固定的;后面有 4n 字节是根据需要可增加的选项；
• TCP 首部的最小长度是 20 字节，最大长度是60字节。

源端口和目的端口：各占2个字节，分别写入源端口号和目的端口号。

序号 - seq：占4字节。

• 指是本报文段所携带数据的第一个字节的序号,也称为报文段序号。【例如，一报文段的序号字段值是301，而携带的数据共有100字节。这就表明:本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400。显然，下一个报文段(如果还有的话)的数据序号应当从401开始，即下一个报文段的序号字段值应为401。】

• 序号范围是 [0,2³²-1] ，共2³²(即4294967296)个序号。使用 mod 2³²运算【序号增加到2³²-1后，下一个序号就又回到0】

确认号 - ack / ack_seq：占4字节。

• 是期望收到对方的下一个报文段中数据的第一个字节的序号。【例如，一报文段的序号字段值是301，而携带的数据共有100字节。这就表明:本报文段的数据的第一个字节的序号是301，最后一个字节的序号是400。期望收到的下一个报文段(如果还有的话)的序号 - 确认号是401】
• 若确认号=N，则表明:到序号N-1为止的所有数据都已正确收到。

数据偏移：占4位。

• 指出TCP报文段的首部长度。

• 单位是32位字(即以4字节长的字为计算单位)。

  由于4位二进制数能够表示的最大十进制数字是15，因此数据偏移的最大值是60字节，即是TCP首部的最大长度(选项长度不能超过40字节)。

保留：占6位，保留为今后使用，但目前应置为0。

6个控制位：

• 紧急 URG：当 URG=1时，紧急指针字段有效，此报文段中有紧急数据，应尽快传送。【高优先级的数据，不按原来的排队顺序传送；把紧急数据插入到本报文段数据的最前面，而在紧急数据后面的数据仍是普通数据。】

• 确认 ACK：只有当 ACK=1时确认号字段才有效。当ACK=0时，确认号无效。【在连接建立后所有传送的报文段都必须把ACK置为1。】【只有握手①的ACK=0，其他所有TCP报文段都是ACK=1】

• 推送 PSH：收到 PSH=1的报文段，发送方立即发送，接收方尽快上交接收应用进程。而不再等到整个缓存都填满了后再向上交付。很少使用。

• 复位 RST：当 RST=1时，表明TCP 连接中出现严重差错，必须释放连接，然后再重新建立运输连接。还可以用来拒绝一个非法的报文段或拒绝打开一个连接。

• 同步 SYN：同步SYN=1表示这是一个连接请求或连接接受报文。【只有握手①、握手②的SYN=1，其他所有TCP报文段都是SYN=0】

  • SYN=1而ACK=0时，表明这是一个连接请求报文段。
  • 对方若同意建立连接，则应在响应的报文段中使SYN=1和ACK=1。

• 终止 FIN：用来释放一个连接。FIN=1表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。【只有挥手①、挥手③的FIN=1，其他所有TCP报文段都是FIN=0】

  考题常见术语补充: 若SYN=1，可称为SYN段；若FIN=1，可称为FIN段；若ACK=1，可称为ACK段

窗口：占2字节。- 实现流量控制

• 窗口值是[0,2¹⁶-1]之间的整数。
• 窗口指的是发送本报文段的一方的接收窗口(而不是自己的发送窗口)。
• 因为接收方的数据缓存空间是有限的，窗口值告诉对方: 从本报文段首部中的确认号算起，接收方目前允许对方发送的数据量(以字节为单位)。

检验和：占2字节。

• 检验和字段检验的范围包括首部和数据这两部分。
• 和UDP用户数据报一样，在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。伪首部的格式与UDP用户数据报的伪首部一样。但应把伪首部第4个字段中的17改为6(TCP的协议号是6)，把第5字段中的UDP长度改为TCP长度。

紧急指针 ：占2字节。

• 紧急指针仅在URG=1时才有意义
• 指出本报文段中的紧急数据的字节数(紧急数据结束后就是普通数据)。【指出了紧急数据的末尾在报文段中的位置。】即使窗口为零时也可发送紧急数据。

选项字段：长度可变。

• 最大报文段长度MSS
  MSS 告诉对方 TCP:“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。”
  MSS(Maximum Segment Size):是 TCP 报文段中的数据字段的最大长度。数据字段加上 TCP 首部才等于整个的TCP 报文段。
  在连接建立的过程中，双方都把自己能够支持的MSS写入这一字段，以后就按照这个数值传送数据，两个传送方向可以有不同的MSS值。若主机未填写这一项，则 MSS的默认值是536字节(这个数值来自576字节的IP数据报总长度减去TCP和IP的固定首部 ：576-20-20=536字节)。

• 窗口扩大选项：占3字节，其中有一个字节表示移位值S。新的窗口值等于TCP首部中的窗口位数增大到(16+S)，相当于把窗口值向左移动S位后获得实际的窗口大小，S≤14。不再需要扩大其窗口时，可发送S=0的选项，使窗口大小回到16。

• 时间戳选项：占 10 字节，其中最主要的字段时间戳值字段(4字节)和时间戳回送回答字段(4 字节)。
  第一，用来计算往返时间RTT

  第二，用于处理TCP序号超过2³²的情况，这又称为防止序号绕回PAWS(Protect Against Wrapped Sequence numbers)。

• 选择确认(SACK)选项：告诉发送方收到的连续的字节块。

填充字段: 这是为了使整个首部长度是4字节的整数倍

5.6 TCP 可靠传输的实现

5.6.1 以字节为单位的滑动窗口

• TCP连接的两个端点都有两个窗口:

  • 发送窗口: 准备发送的数据和已发送但未收到确认的数据

  • 接收窗口: 按序到达但未被应用程序接收的数据、不按序到达的数据。

• TCP 两端的四个窗口经常处于动态变化之中。

• TCP 的可靠传输机制用字节的序号进行控制。TCP所有的确认都是基于序号而不是基于报文段的。

窗口和缓存的关系：

总结：

• 第一，虽然A的发送窗口是根据B的接收窗口设置的，但在同一时刻，A的发送窗口并不总是和B的接收窗口一样大。原因：
  • 通过网络传送窗口值需要经历一定的时间滞后(这个时间是不确定的)。
  • 发送方A还可能根据网络当时的拥塞情况适当减小自己的发送窗口数值。
• 第二，对于不按序到达的数据处理：
  • 把不按序到达的数据先临时存放在接收窗口中，等到字节流中所缺少的字节收到后，再按序交付上层的应用进程。
• 第三，TCP要求接收方必须有累积确认的功能
• 最后，TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。每一方都有自己的发送窗口和接收窗口。

5.6.2 超时重传时间的选择

报文段的往返时间 RTT ：记录一个报文段发出的时间，以及收到相应的确认的时间。

加权平均往返时间 RTT_S：又称为平滑的往返时间, RTT 的加权平均

• 当第一次测量到RTT样本时，RTTS值就取为所测量到的RTT样本值。
• 以后每测量到一个新的RTT样本，就按下式重新计算一次：
  新的RTT_S = (1-α) × (旧的RTT_S)+ α × (新的 RTT 样本) 【0 ≤ α < 1，推荐 α = 1/8 = 0.125】

RTT_D ：是 RTT 的偏差的加权平均值

• 当第一次测量时，RTT_D 值取为测量到的RTT样本值的一半。
• 以后的测量中，则使用下式计算：
  新的 RTTD = (1-β) × (旧的RTTD) + β × | RTT_S - 新的 RTT 样本 | 【0 ≤ α < 1，推荐 α = 1/4 = 0.25】

超时重传时间 RTO(Retransmission Time-Out) ：RTO = RTT_S + 4 x RTT_D

区分有效的和无效的往返时间样本: Karn 算法

报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时才根据上面的式子计算超时重传时间。

5.6.3 选择确认 SACK

解决问题：若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，如何设法只传送缺少的数据而不重传已经正确到达接收方的数据?

传统 TCP 确认机制：

• 接收方只能发送累积确认（ACK），确认最后一个连续接收到的数据段。
• 例如：
  • 发送方发送数据段：1、2、3、4、5。
  • 接收方成功接收：1、2、4、5（3 丢失）。
  • 接收方发送的 ACK = 2（确认了1和2，未确认3、4、5）。
  • 发送方会重传3、4、5。

SACK 的优势：

• 接收方可以通过 SACK 明确告知发送方哪些数据段已经成功接收。
• 例如：
  • 接收方发送的 SACK 信息：确认1、2，额外确认4、5。
  • 发送方只需要重传丢失的3，避免了不必要的重传。

SACK格式：

• Kind：1字节。kind == 5 代表这是SACK选项。
• Length：1字节。代表SACK选项长度（字节）。
• Left Edge：4字节。左边界。
• Right Edge：4字节。右边界。
• 区间左闭右开[Left Edge, Right Edge)

注意：

• 一个边界就要用掉4字节（因为序号是4字节）
• 首部选项的长度最多只有40字节
• 一个选项中，最多只能指明4个字节块的边界信息 = 8个边界 = 32字节
• 还需其他两个字节
  • 用来指明是 SACK 选项
  • 指明这个选项要占用多少字节

5.7 TCP的流量控制

5.7.1 利用滑动窗口实现流量控制

流量控制做法： 接收方的接收能力来限制发送方的发送能力。

死锁问题及其解决办法：

死锁问题

发送方A，接收方B

• B 向A发送了零窗口的报文段后，B的接收缓存又有了一些存储空间
• B 向A发送 rwnd = 400 的报文段。这个报文段在传送过程中丢失了:
  • A一直等待收到 B发送的非零窗口的通知;
  • B 一直等待 A发送的数据;
• 如果没有其他措施，互相等待的死锁局面将一直延续下去。

解决办法

• TCP 为每一个连接设有一个持续计时器。只要收到对方的零窗口通知，就启动该持续计时器:
• 持续计时器到期，发送一个零窗口探测报文段，对方在确认这个探测报文段时给出现在的窗口值;
  • 若窗口仍然是零，接收确认报文方重新设置持续计时器;
  • 若窗口不是零，死锁的僵局便被打破了。

5.7.2 TCP的传输效率

控制 TCP 报文段的发送时机的不同机制：

• 第一种机制: TCP 维持一个变量，它等于最大报文段长度MSS。只要缓存中存放的数据达到 MSS 字节时，就组装成一个 TCP 报文段发送出去;
• 第二种机制: 由发送方的应用进程指明要求发送报文段，即TCP 支持的推送(push)操作、紧急数据 URG
• 第三种机制: 发送方的一个计时器期限到了，这时就把当前已有的缓存数据装入报文段(但长度不能超过 MSS)发送出去。

Neglect算法：

• 发送方先发送第一个数据字节，缓存后面到达的数据字节;
  发送方收到对第一个数据字符的确认后，把发送缓存中的所有数据【组装成一个报文段】发送出去，继续对随后到达的数据进行缓存;
• 只有在收到对前一个报文段的确认后继续发送下一个报文段
• 当到达的数据已达到发送窗口大小的一半或已达到报文段的最大长度时，就立即发送一个报文段。

糊涂窗口综合症及解决办法：

• 问题：
  • 接收方的 TCP缓冲区已满，接收方会向发送方发送窗口大小为0 的报文；
  • 接收方的应用进程以交互方式每次只读取一个字节，接收方发送窗口大小为一个字节的确认报文，发送方发送一个字节的数据，接收窗口又满了，如此循环往复;
• 办法：
  • 接收方等待一段时间，使得接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一半空闲的空间;
    只要出现这两种情况之一，接收方就发出确认报文，并向发送方通知当前的窗口大小。

5.8 TCP的拥塞控制

5.8.1 拥塞控制的一般原理

拥塞(congestion)： 在某段时间，若对网络中某资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏的现象

Σ 对资源的需求 > 可用资源

若网络中有许多资源同时产生拥塞，网络的性能就要明显变坏，整个网络的吞吐量将随输入负荷的增大而下降

拥塞原因：

1. 流量相关：流量超载、流量突增【流量分布不均】。
2. 设备相关：缓冲区溢出、性能不足、设备故障，处理机速度太慢。
3. 链路相关：链路容量不足。
4. 网络行为：广播风暴、路由环路、不合理的网络设计。
5. 管理相关：资源分配不均。

拥塞的影响：

1. 延迟增加：数据包在网络中的传输时间增加，导致用户体验变差。
2. 丢包率上升：数据包被丢弃的概率增加，导致数据传输不完整。
3. 服务质量下降：语音、视频等实时应用的性能下降，可能导致卡顿、延迟或断线。
4. 网络资源浪费：网络设备和链路的资源被无效数据包占用，带宽利用率下降。
5. 网络瘫痪：严重拥塞可能导致网络完全不可用，部分服务中断。

拥塞控制：

• 拥塞控制定义: 防止过多的数据注入到网络中，使网络中的路由器或链路不致过载。
• 拥塞控制的前提: 网络能够承受现有的网络负荷
• 拥塞控制是一个全局性的过程: 涉及到所有的主机、所有的路由器，以及与降低网络传输性能有关的所有因素。

拥塞控制与流量控制的区别

• 流量控制: 是端到端的问题(接收端控制发送端)，点对点通信量的控制。抑制发送端发送速率，以便使接收端来得及接收。【网络不存在问题，畅通】
• 拥塞控制: 是一个全局性的过程，涉及到与降低网络传输性能有关的所有因素。防止过多数据注入到网络，使网络中的路由器或链路不致过载。【网络内部拥塞】
• 某些拥塞控制算法是向发送端发送控制报文，并告诉发送端，网络已出现麻烦，必须放慢发送速率，与流量控制是很相似。

拥塞控制作用

拥塞控制原理

• 拥塞控制是个动态问题

• TCP发现分组丢失了，会认为这时的网络可能产生了拥塞，然而分组的丢失是网络发生拥塞的征兆而不是原因, 拥塞控制本身也可能成为网络性能恶化甚至发生死锁的原因。

  • 分组丢失：
    • 数据链路层：帧出错被丢弃；
    • 网络层：出错IP分组被丢弃；

拥塞控制方法：

• 开环控制方法：在设计网络时考虑发生拥塞的因素，力求网络不产生拥塞。

• 闭环控制方法：基于反馈环路的概念：

  • 监测网络系统以便检测到拥塞在何时、何处发生;

    监测网络的拥塞的主要指标：

    • 由于缺少缓存空间而被丢弃的分组的百分数;

    • 平均队列长度;

    • 超时重传的分组数;

    • 平均分组时延;

    • 分组时延的标准差，等等。

      上述这些指标的上升都标志着拥塞的增长。

  • 传送拥塞发生的信息到可采取行动的地方;

    拥塞控制的时机选择:

    • 过乎频繁，会使系统产生不稳定的振荡;

    • 过于迟缓，头采取行动又不具有任何价值。

    采取的策略:

    • 将拥塞发生的信息传送到产生分组的源站【通知发送分组的源头设备】
    • 在路由器转发的分组中保留一个比特或字段，用该值表示网络没有拥塞或产生了拥塞。【拥塞状态字段】
    • 可以由一些主机或路由器周期性地发出探测分组，以询问拥塞是否发生。

  • 调整网络系统的运行以解决出现的问题。

拥塞通知的传递与时机：显示拥塞通告ECN

1. TOS（Type of Service）字段

TOS 是 IPv4 协议中用于指示数据包服务类型的一个字段，长度为 8 位（1 字节）。

TOS 字段的结构：

• 优先级（3 位）：定义数据包的优先级（0-7）。
• D（Delay，延迟）：请求低延迟服务。
• T（Throughput，吞吐量）：请求高吞吐量服务。
• R（Reliability，可靠性）：请求高可靠性服务。
• C（Cost，成本）：请求低成本服务。
• 位 0：保留位，通常为 0。

TOS 的作用：

• 服务质量（QoS）：为不同类型的应用（如实时应用、数据传输）提供不同的优化策略。
• 优先级调度：帮助路由器在网络拥塞时优先处理高优先级的数据包。

2. 显示拥塞通知（ECN, Explicit Congestion Notification）

ECN 是一种网络拥塞管理机制，允许网络设备在不丢弃 数据报的情况下，向发送方通知网络拥塞的情况。ECN 通过修改 IP 数据报头部的标志位来实现。

ECN 的工作原理：

ECN 位（TOS 字段的最后 2 位）：

• TOS 字段的最后 2 位（位 1 和位 0）可以用于 ECN。
• 在 IPv4 中，如果 TOS 字段中的 ECN 位被设置为 “ECT”/“CE”【 “ECN Capable Transport”（ECT）或 “Congestion Experienced”（CE）】（01 或 10），表示发送方支持 ECN。
• 具体位定义：
  • 00：不可用（非 ECN 数据包）。
  • 01：ECT(0)（ECN 能力）。
  • 10：ECT(1)（ECN 能力）。
  • 11：CE（拥塞发生，通知发送方降低发送速率）。

3. TCP报文首部中，除了6个常用的标志位，还有2个与拥塞有关的标志位

• E：ECE，显式拥塞提醒回应;
• W：CWR，拥塞窗口减少。【发送窗口是受到接收窗口影响，同时也会受到拥塞窗口限制的】

5.8.2 TCP的拥塞控制方法

• 慢开始(slow-start)
• 拥塞避免(congestion avoidance)
• 快重传(fast retransmit)
• 快恢复 (fast recovery)

拥塞控制算法：

• TCP 采用基于窗口的方法进行拥塞控制，该方法属于闭环控制方法。
• TCP发送方维持一个拥塞窗口 CWND(Congestion Window):
  • 拥塞窗口：发送方根据网络拥塞情况估算的窗口值，反映当前网络容量;
  • 拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化;
  • 发送端利用拥塞窗口根据网络的拥塞情况调整发送的数据量;
  • 网络没有出现拥塞，拥塞窗口增大一些，以便发送更多的分组，提高网络的利用率;
  • 网络出现拥塞或有可能出现拥塞，拥塞窗口减小一些，减少注入到网络中的分组数。
• 真正的发送窗口值 = Min(接收窗口值 rwnd，拥塞窗口值 cwnd)

TCP 拥塞判断依据：

超时重传计时器启动：现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率很小(远小于1%)。只要出现了超时，就可以猜想网络可能出现了拥塞

1. 慢开始：

• 算法思路: 由小到大逐渐增大拥塞窗口数值

  • 当主机在已建立的TCP连接上开始发送数据时，并不清楚网络当前的负荷情况。如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞;
  • 先探测一下，即由小到大逐渐增大注入到网络中的数据字节。

• 算法细节:

  • 发送方最大报文段SMSS (Sender Maximum Segment Size) = Min(MTU、MSS) ： 表示发送方在一次传输中可以发送的单个报文段的最大字节数。

  • 初始拥塞窗口 cwnd 设置(限制初始拥塞窗口的字节数)

    • 1至2个最大报文段(旧的规定);
    • 2至4个最大报文段(RFC5681规定)
      • SMSS > 2190字节，cwnd = 2 x SMSS字节，且不得超过2个报文段;
      • 1095字节 < SMSS ≤ 2190字节，cwnd = 3 x SMSS字节，且不得超过3个报文段;
      • SMSS ≤ 1095字节，cwnd = 4 x SMSS字节，且不得超过4个报文段;

  • 具体实现;

    • 收到一个对新的报文段的确认后 (不包括重传) , 就会增加拥塞窗口，每次增加量 = Min(N, SMSS)
      • N是原先未被确认的、但现在被刚收到的确认报文段所确认的字节数。【N 是发送方之前已经发送出去，但一直没有收到确认（ACK）的数据，现在终于收到确认报文了，这些确认报文确认了多少字节的数据，N 就等于多少字节。】
        • 当 N < SMSS，则拥塞窗口增加 N 字节。
        • 如果 N ≥ SMSS，则拥塞窗口增加 SMSS 字节。
    • 注意：窗口大小按指数增加

    

  • 慢开始门限 ssthresh (状态变量)：防止拥塞窗口cwnd增长过大引起网络拥塞。

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

    无论在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞(重传定时器超时)：

    • ssthresh = max(cwnd/2,2);
    • cwnd = 1;
    • 执行慢开始算法。

2. 拥塞避免：

算法思路: 让拥塞窗口 cwnd 缓慢地增大，避免出现拥塞;

• 每经过一个RTT，拥塞窗口 cwnd = cwnd+1;
• 使拥塞窗口 cwnd 按线性规律缓慢增长;
• 具有“加法增大”(Additive Increase)的特点。

3. 快重传：

算法思路: 可以让发送方尽早知道发生了个别报文段的丢失。

• 要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认
• 即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
• 发送方只要一连收到三个重复确认，应当立即进行重传(即“快重传”)，这样就不会出现超时，发送方不会误认为出现了网络拥塞。
• 使用快重传可以使整个网络的吞吐量提高约20%。

TCP 协议中：

1. 正常流程：—— 立即发送确认

• 接收方收到数据后，立刻发送一个 ACK 确认（没有数据要发回去）。

2. 捎带确认：

• 接收方收到数据后，如果自己也有数据要发回，那么可以等到自己发送数据时，把确认信息（ACK）一起发回去。
• 这样可以减少不必要的通信开销，因为确认信息和数据一起发回去了。

快重传例子：

1. 正常情况下：

   • 发送方发送一个报文段后，接收方会发送一个确认（ACK），确认号表示接收方期望接收的下一个字节。

2. 发生丢包时：

   • 假设发送方发送了报文段 1、2、3、4、5、6、7，但接收方只收到了报文段 1 、2、4、5、6，而报文段 3 丢失了。

3. 接收方的行为：

   • 接收方成功接收报文段 1，发送 ACK = 2（表示期望接收字节 2）
   • 接收方成功接收报文段 2，发送 ACK = 3（表示期望接收字节3）
   • 接收方没有收到报文段 3，即报文段 3 丢失了；
   • 接收方收到报文段 4，但因为报文段 3 丢失了，接收方无法继续处理报文段 4，因此仍然发送 ACK = 3【正常情况下是超时，重传】。
   • 这时，接收方发送了一个重复的 ACK，表示仍然期望接收报文段 3。

4. 快重传的触发：

   • 发送方连续收到 3 个重复的 ACK（表示接收方成功接收了了报文段 5、报文段 6，都返回发送 ACK = 3），说明报文段 2 可能丢失了。
   • 发送方立即重传报文段 2，而无需等待超时计时器（RTO）超时。

5. 重传后的处理：

   • 发送方重传报文段 3 后，接收方成功接收报文段 3，并继续处理报文段 4。

   

4. 快恢复：

算法思路:

​ 当发送端收到连续三个重复的确认时，发送方认为网络很可能没有发生拥塞，因此不执行慢开始算法，而是执行快恢复算法：

• 慢开始门限 ssthresh = 当前拥塞窗口cwnd/2;
• 新拥塞窗口 cwnd = 慢开始门限 ssthresh;
• 开始执行拥塞避免算法，使拥塞窗口缓慢地线性增大。

5.8.3 主动队列管理AQM - TCP 拥塞控制与网络层策略的关系

关系：

当网络层的路由器采取不当策略（如路由器的分组丢弃策略）时，可能导致 TCP 误判网络拥塞，进而引发不必要的拥塞控制行为。

路由器分组丢弃策略的影响：

• 尾部丢弃策略（Tail-Drop Policy）：
  • 路由器按照“先进先出”（FIFO）规则处理分组。
  • 当队列满时，新到达的分组会被丢弃（尾部丢弃）。
  • 这种策略可能导致：
    • 一连串分组丢失：路由器丢弃多个分组，导致发送方超时重传。
    • TCP 误判拥塞：发送方认为网络发生拥塞，进入慢开始状态。
    • 全局同步（Global Synchronization）：大量 TCP 连接同时进入慢开始状态，导致网络通信量骤降。
• 全局同步的问题：
  • 网络通信量波动剧烈。
  • 网络恢复后，通信量突然增加，可能再次引发拥塞。

主动队列管理（AQM, Active Queue Management）：

• 目标：避免全局同步，提前检测网络拥塞征兆，主动采取措施。
• 核心思想：
  • 不等队列满时才丢弃分组。
  • 在队列长度达到一定阈值时，主动丢弃部分分组，提醒发送方降低发送速率。

5.9 TCP 的运输连接管理

5.9.1 TCP的连接建立 - 三次握手

TCP 连接的作用：

TCP 连接（Transmission Control Protocol Connection）是为了在通信双方之间建立可靠的、全双工的数据传输通道。它的主要作用：

1. 确认对方的存在：
   • 确保通信双方都知道对方的存在，以便进行后续的数据传输。
2. 协商参数：
   • 允许双方协商一些传输参数，如：
     • 最大窗口值（Maximum Window Size）。
     • 是否使用窗口扩大选项（Window Scaling Option）。
     • 是否使用时间戳选项（Timestamp Option）。
     • 服务质量（Quality of Service, QoS）。
3. 分配资源：
   • 为通信双方分配运输实体资源，如：
     • 缓存大小（Buffer Size）：用于存储待发送或接收的数据。
     • 连接表中的项目（Connection Table Entry）：用于管理连接状态。

TCP 连接的建立方式：

TCP 连接的建立采用 客户-服务器模式（Client-Server Model）：

1. 主动发起方：
   • 客户（Client）：
     • 主动发起连接建立请求的应用进程。
     • 通常是请求服务的一方。
2. 被动等待方：
   • 服务器（Server）：
     • 被动等待连接请求的应用进程。
     • 通常是提供服务的一方。

三报文握手建立连接：

5.9.2 TCP的连接释放 - 四次挥手

四次报文挥手释放连接：

真题

5.9.3 TCP的有限状态机

参考：

教材：计算机网络（第8版） (谢希仁) (Z-Library).pdf

博客：

TCP选择重传和流量控制

视频：

王道计算机考研 计算机网络

计算机网络 第8版 谢希仁