5.1 运输层概述

核心任务：为相互通信的应用进程提供端到端的逻辑通信服务，实现进程到进程的通信（网络层仅提供主机到主机通信）。

5.1.1 进程间基于网络的通信

关键概念：

  • 端到端协议：运输层也称端到端协议，作用范围是应用进程到应用进程
  • 逻辑通信：运输层之间看似水平传输，实际数据沿垂直方向经多层封装/解封装
  • 屏蔽细节：运输层向应用层屏蔽网络核心细节（拓扑、路由协议等），提供透明传输信道
  • 客户/服务器模式：主动发起通信的进程是客户，被动接收请求的是服务器

体系结构视角：

  • 发送方运输层通过不同端口区分应用进程，封装应用层报文后向下交付
  • 接收方运输层通过端口号将报文分发给对应应用进程
  • 端口：逻辑标识符，非物理端口，用于区分本机应用进程

5.1.2 TCP/IP运输层两个重要协议

TCP/IP体系结构为应用层提供两种服务：

协议 服务类型 特点 适用场景
UDP 无连接、不可靠 - 传输前不建立连接- 不保证可靠交付- 首部简单（8字节）- 低开销、高效率 实时应用（IP电话、视频会议、流媒体、DNS）
TCP 面向连接、可靠 - "三报文握手"建立连接- 确认、重传、流量/拥塞控制>- 首部复杂（20-60字节）- 开销大、资源消耗多 可靠性要求高的应用（HTTP、FTP、SMTP、Telnet）

术语规范：

  • TCP/IP体系：TCP报文段、UDP用户数据报
  • OSI体系：运输协议数据单元(TPDU)

5.1.3 运输层端口号、复用与分用

1. 端口号机制

必要性：统一标识不同操作系统（Windows/Linux/macOS）中的应用进程，解决PID格式不统一问题。

端口号规则：

  • 长度：16比特，范围0-65535
  • 分类：
    • 熟知端口号（0-1023）：IANA分配，全球通用（如HTTP:80，FTP:21/20，DNS:53，SMTP:25）
    • 登记端口号（1024-49151）：需向IANA登记（如RDP:3389）
    • 短暂端口号（49152-65535）：客户端动态选择，通信结束后回收

重要特性：端口号仅具本地意义，不同计算机的相同端口号相互独立，TCP与UDP端口号也相互独立。

2. 发送方复用与接收方分用

复用(Multiplexing)：发送方多个应用进程通过不同端口共享同一网络连接
分用(Demultiplexing)：接收方根据端口号将数据交付给对应应用进程

分层处理流程：

  1. 应用层：应用报文→运输层
  2. 运输层复用：UDP复用/TCP复用→添加端口号→UDP用户数据报/TCP报文段
  3. IP复用：IP协议封装→IP数据报（协议字段：6=TCP，17=UDP）
  4. 接收方IP分用：根据协议字段值向上交付TCP或UDP
  5. 运输层分用：根据目的端口号交付应用进程

3. 应用实例：DNS查询+HTTP访问

场景：用户PC访问www.porttest.net

DNS查询阶段（UDP）：

  1. PC浏览器输入域名→DNS客户进程准备查询
  2. UDP封装：源端口=49152（短暂），目的端口=53（DNS熟知端口）
  3. IP封装后发送给DNS服务器
  4. DNS服务器解封，根据目的端口53交付给DNS服务进程
  5. DNS服务进程查询后，UDP响应：源端口=53，目的端口=49152
  6. PC收到响应，获得IP地址192.168.0.3，归还端口号49152

HTTP访问阶段（TCP）：

  1. TCP三次握手建立连接（详见5.3.2）
  2. HTTP请求：源端口=49152，目的端口=80（HTTP熟知端口）
  3. Web服务器根据目的端口80交付给HTTP服务进程
  4. HTTP服务进程响应后，TCP响应：源端口=80，目的端口=49152
  5. PC浏览器渲染显示，通信结束后四次挥手释放连接

5.2 UDP和TCP的对比

5.2.1 无连接的UDP vs 面向连接的TCP

  • UDP：无需建立连接，随时发送数据（无"握手"过程）
  • TCP：必须通过**“三报文握手"建立连接，数据传输后通过"四报文挥手”**释放连接

5.2.2 对单播、多播、广播的支持

  • UDP：支持单播、多播、广播（“一对一”、“一对多”、“一对全”）
  • TCP：仅支持单播（“一对一”），因连接机制限制无法多播/广播

5.2.3 对应用层报文的处理

  • UDP面向报文：对应用层报文不合并、不拆分，保留报文边界，直接添加首部
  • TCP面向字节流：将应用报文视为无结构字节流，编号后存入发送缓存，根据策略提取字节构建报文段。不保证数据块边界对应，但保证字节流完全一致

5.2.4 数据传输可靠性支持

  • UDP：无连接不可靠服务
    • 检测到误码仅丢弃，不纠错
    • 数据丢失不做处理
    • 适用场景：实时性要求>可靠性要求
  • TCP：面向连接的可靠服务
    • 基于TCP连接提供无差错、不丢失、不重复、按序到达的可靠信道
    • 适用场景：可靠性要求高的应用（文件传输、电子邮件）

5.2.5 首部格式对比

UDP首部（8字节）：

  • 源端口、目的端口、长度、检验和（各2字节）
  • 伪首部：计算检验和时添加12字节伪首部（含源/目的IP、协议、长度），用于验证IP地址和端口号

TCP首部（20-60字节）：

  • 固定部分20字节，选项最多40字节
  • 包含：**序号、确认号、数据偏移、窗口、检验和、6个标志位（SYN/FIN/ACK/RST/PSH/URG）**等复杂字段

5.3 传输控制协议(TCP)

5.3.1 TCP报文段首部格式

关键字段解析：

  1. 源端口/目的端口（各16比特）：标识发送/接收应用进程

  2. 序号字段seq（32比特）：指出本报文段数据载荷第一个字节的序号

  3. 确认号字段ack（32比特）：期望收到对方下一个报文段数据载荷第一个字节的序号（对之前所有数据的累积确认）

    • ACK标志位必须为1，确认号才有效
    • 规定：TCP连接建立后所有报文段必须将ACK置1

  4. 数据偏移字段（4比特）：以4字节为单位，指出首部长度（20-60字节）

    • 最小值0101→20字节
    • 最大值1111→60字节

  5. 窗口字段rwnd（16比特）：以字节为单位，指出接收窗口大小，用于流量控制

  6. 检验和字段：检查报文段是否误码，计算时同样需添加12字节伪首部（协议字段值=6）

  7. 6个标志位：

    • SYN：同步标志位
      • SYN=1,ACK=0 → 连接请求报文段
      • SYN=1,ACK=1 → 连接响应报文段
    • FIN：终止标志位，FIN=1表示发送方数据发送完毕，要求释放连接
    • RST：复位标志位，RST=1表示严重差错，必须释放重连或拒绝非法报文段/连接
    • PSH：推送标志位，PSH=1要求立即发送/交付，不等待缓存填满
    • URG：紧急标志位，URG=1时紧急指针有效，指明紧急数据长度（可插队）
    • ACK：确认标志位

  8. 选项字段（最多40字节）：

    • MSS：最大报文段长度（数据载荷部分最大长度，非整个报文段）
    • 窗口扩大选项：扩大窗口提高吞吐率
    • 时间戳选项：计算RTT、防止序号绕回(PAWS)
    • 选择确认选项：实现SACK功能

5.3.2 TCP运输连接管理

TCP连接三个阶段：建立连接→数据传送→释放连接

1. "三报文握手"建立TCP连接

解决的问题：

  • 确认双方存在
  • 协商参数（MSS、窗口大小、时间戳等）
  • 分配初始化资源（缓存、状态变量等）

连接建立过程：

1
2
3
4
TCP客户(CLOSED) → 主动打开 → 发送SYN=1,seq=x → SYN-SENT
TCP服务器(CLOSED) → 被动打开 → LISTEN → 收到请求 → 发送SYN=1,ACK=1,seq=y,ack=x+1 → SYN-RCVD
TCP客户 → 收到确认 → 发送ACK=1,seq=x+1,ack=y+1 → ESTABLISHED
TCP服务器 → 收到确认 → ESTABLISHED

关键细节：

  • SYN=1的报文段不能携带数据，但要消耗一个序号
  • 普通确认报文段(ACK=1)若不携带数据，不消耗序号

为何必须"三报文握手"？
防止已失效的连接请求报文段突然到达导致错误。若仅用"两报文握手"，当失效的请求到达服务器，服务器会建立连接并等待数据，造成资源浪费。

2. "四报文挥手"释放TCP连接

释放过程：

1
2
3
4
5
6
TCP客户(ESTABLISHED) → 主动关闭 → 发送FIN=1,ACK=1,seq=u,ack=v → FIN-WAIT-1
TCP服务器 → 收到 → 发送ACK=1,seq=v,ack=u+1 → CLOSE-WAIT
TCP客户 → 收到确认 → FIN-WAIT-2（半关闭状态）
TCP服务器 → 数据发送完 → 发送FIN=1,ACK=1,seq=w,ack=u+1 → LAST-ACK
TCP客户 → 收到 → 发送ACK=1,seq=u+1,ack=w+1 → TIME-WAIT(2MSL) → CLOSED
TCP服务器 → 收到确认 → CLOSED

关键机制：

  • 半关闭状态：客户到服务器的连接已释放，但服务器到客户的连接可能仍未关闭
  • TIME-WAIT状态必须等待2MSL（最长报文段寿命，建议2分钟）：
    1. 确保服务器收到最后的确认，能正常关闭
    2. 使本连接持续时间内产生的所有报文段从网络消失，避免影响新连接
  • 保活计时器：服务器每收到客户数据重置为2小时，超时后每隔75秒发探测报文，连续10次无响应则断开连接

5.3.3 TCP的流量控制

核心概念：根据接收方接收能力（接收缓存可用空间）控制发送方速率，防止接收缓存溢出

实现方法：基于滑动窗口机制

流量控制示例分析：

  1. B初始接收窗口=400 → A发送窗口=400
  2. A发送序号1-100,101-200,201-300（丢失）,301-400
  3. B收到1-200，确认号=201，窗口=300（第一次流量控制）
  4. A调整发送窗口=300，发送401-500,501-600
  5. 201-300超时重传 → B确认到501，窗口=100（第二次流量控制）
  6. A发送窗口=100，发送501-600 → B确认到601，窗口=0（第三次流量控制）
  7. 死锁局面：A等待非零窗口通知，B等待A发送数据

破解死锁：持续计时器

  • 收到零窗口通知时启动
  • 超时后发送仅携带1字节的零窗口探测报文段
  • 对方必须接受并返回当前窗口值（即使窗口为0）
  • 若窗口仍为0，重启计时器；若非零，打破死锁

5.3.4 TCP的拥塞控制

拥塞定义：对网络资源需求 > 可用部分，导致网络性能恶化

拥塞控制 vs 流量控制：

  • 流量控制：点对点，接收方控制发送方，防止接收方缓存溢出
  • 拥塞控制：全局性，防止过多数据注入网络，涉及所有主机、路由器

控制方法：

  • 开环控制：设计时预防，运行中不调整
  • 闭环控制：基于反馈（监测→传送→调整），因特网主要采用

TCP四种拥塞控制算法（Reno版本）：

1. 慢开始(Slow-Start) + 拥塞避免(Congestion Avoidance)

状态变量：

  • cwnd（拥塞窗口）：动态变化，网络拥塞时减小，无拥塞时增大
  • swnd（发送窗口）：swnd = min(cwnd, rwnd)（本例忽略流量控制，swnd=cwnd）
  • ssthresh（慢开始门限）：
    • cwnd < ssthresh：慢开始（指数增长）
    • cwnd > ssthresh：拥塞避免（线性增长）
    • cwnd = ssthresh：两者皆可

执行过程示例：

  1. 慢开始：cwnd=1，每收到1个确认cwnd+1 → 指数增长（1→2→4→8→16）
  2. 拥塞避免：cwnd=16=ssthresh，每轮次cwnd+1 → 线性增长（16→17→18…→24）
  3. 超时重传：cwnd=24时丢失，判断网络拥塞
    • 调整：ssthresh = cwnd/2 = 12；cwnd = 1
    • 重启慢开始→增长到ssthresh→拥塞避免

关键理解：

  • “慢开始”：初始注入报文少，但增长速度指数级，不慢
  • “拥塞避免”：并非避免拥塞，而是让窗口线性增长，不易拥塞

2. 快重传(Fast Retransmit) + 快恢复(Fast Recovery)

触发条件：收到3个连续重复确认（个别报文段丢失，非网络拥塞）

快重传：立即重传丢失报文段，不等待超时

快恢复：收到3个重复确认后

  • 标准做法：ssthresh = cwnd/2，cwnd = ssthresh，执行拥塞避免
  • 改进做法：cwnd = ssthresh + 3（因为3个报文段已离开网络）

优势：避免个别丢包导致cwnd骤降为1，提高吞吐量约20%

5.3.5 TCP拥塞控制与网际层拥塞控制的关系

核心关联：IP路由器丢包策略直接影响TCP拥塞控制

尾部丢弃策略：队列满后丢弃所有后续IP数据报 → 导致全局同步（多TCP连接同时超时重传）

主动队列管理(AQM)：队列长度达阈值但未满时主动丢弃分组

  • 随机早期检测(RED)：根据平均队列长度概率性丢弃
    • 小于<最小门限：入队
    • 大于>最大门限：丢弃
    • 之间：概率p丢弃
  • 现状：RED效果不理想（RFC7567列为陈旧），新算法仍在实验阶段

5.3.6 TCP可靠传输的实现

基于字节滑动窗口机制

发送方：

  • 发送窗口swnd = min(cwnd, rwnd)
  • 三个指针：P1（已发送未确认首字节）、P2（允许发送首字节）、P3（窗口外首字节）
  • 已发送未确认数据需保留用于超时重传

接收方：

  • 接收窗口rwnd：缓存可用空间
  • 仅对按序到达数据的最高序号给出累积确认
  • 不按序数据暂存接收缓存，待缺序数据到达后一并交付

重要特性：

  1. 发送窗口 ≠ 接收窗口（网络延迟、拥塞控制导致）
  2. 不按序数据处理方式：TCP通常暂存，不丢弃（与GBN/SR有区别）
  3. 必须有累积确认和捎带确认
  4. 全双工通信：双方各有发送/接收窗口

image-20251118095339698

5.3.7 TCP超时重传时间(RTO)的选择

核心挑战：RTO应略大于RTT，但RTT动态变化且难以准确测量

RTT测量问题：

  • 现象：收到确认时无法判断是对原报文段还是重传报文段的确认
  • 后果：
    • 误判为重传确认 → RTT偏大 → RTO偏大 → 延迟重传
    • 误判为原确认 → RTT偏小 → RTO偏小 → 不必要重传

Karn算法：报文段重传时，不采用其RTT样本

加权平均RTT计算：

1
2
3
4
5
6
7
8
初始：RTTs = RTT样本
后续：新RTTs = (1-α)×旧RTTs + α×新RTT样本 （α推荐0.125）

RTO = RTTs + 4×RTTd

RTTd计算：
初始：RTTd = RTT样本/2
后续：新RTTd = (1-β)×旧RTTd + β×|RTTs - 新RTT样本| （β推荐0.25）

Karn算法修正：每重传一次，RTO = 2×RTO（防止持续超时）

5.3.8 TCP的选择确认(SACK)

问题：累积确认导致已接收的不按序数据被重复传输

解决方案：SACK选项（需双方协商启用）

  • 功能：报告收到的不连续字节块边界
  • 限制：最多报告4个字节块（8个边界，需32字节）
  • 实现：大多数TCP重传所有未确认数据块（而非仅缺序部分）

5.3.9 TCP窗口与缓存的关系

发送方：

  • 发送缓存：存放①应用进程交付的数据 ②已发送未确认的数据
  • 发送窗口：发送缓存的子集，后沿与已确认数据重合

接收方：

  • 接收缓存：存放①按序到达未读取的数据 ②不按序到达的数据
  • 接收窗口：接收缓存可用空间，大小动态变化（应用读取速率影响）

关键关系：

  • 发送窗口 ≤ 发送缓存
  • 接收窗口 ≤ 接收缓存
  • 应用进程读取速率决定接收窗口大小，进而影响发送方发送速率

本章核心要点总结

  1. 端口机制：运输层通过端口号实现多路复用与分用，端口号仅本地有效
  2. UDP vs TCP：无连接/面向连接、不可靠/可靠、简单/复杂、高效/稳健
  3. TCP连接管理：三次握手建立、四次挥手释放，解决失效请求问题和资源浪费
  4. 流量控制：接收方通过窗口字段控制发送方速率，持续计时器破解零窗口死锁
  5. 拥塞控制：慢开始（指数增长）→拥塞避免（线性增长）→快重传/快恢复（个别丢包优化）
  6. 可靠传输：基于字节滑动窗口，累积确认，不按序数据暂存，全双工通信
  7. RTO选择：加权平均RTT计算+Karn算法，动态自适应网络变化
  8. SACK机制：可选功能，报告不连续接收块，避免不必要重传

题

5.1.3 运输层端口号、复用与分用

【例题1：端口范围与分类】
某Web服务器同时提供HTTP(80)、HTTPS(443)和自定义数据库服务(端口50000)。下列说法正确的是：
A. 端口号50000属于登记端口号，需向IANA登记
B. 客户端访问HTTP服务时，目标端口可能是49152
C. 服务器重启后，HTTP服务端口可能动态变为1024
D. 同一主机上TCP的80端口和UDP的80端口可共存

解析：D正确。

  • A错误：50000 > 49151，属于短暂端口号，无需登记
  • B错误：服务端熟知端口固定为80，客户端短暂端口才可能是49152
  • C错误：熟知端口号固定不变，重启后HTTP服务端口仍为80
  • D正确：TCP与UDP端口号空间独立，可共存

5.2 UDP和TCP的对比

【例题2：协议选型决策】
某应用需求：①传输延迟<50ms ②允许5%数据丢失 ③支持一对多传输 ④首部开销最小。应选用：
A. TCP B. UDP C. 两者皆可 D. 需改进TCP

解析：B正确。分析需求：①实时性高 ②容忍丢失 ③一对多（广播/多播）④开销小，完全符合UDP特性。TCP会因重传机制、连接管理导致延迟不可控，且仅支持单播，首部长度≥20字节。

5.3.1 TCP报文段首部格式

【例题3：序号与确认号机制】
主机A向主机B发送TCP报文段，数据载荷共1000字节，首个字节序号是2001。则：

  • 该报文段首部"序号字段"值为____
  • 主机B正确接收后，应答报文的"确认号字段"值为____

解析：

  • 序号字段 = 数据载荷第一个字节序号 = 2001
  • 确认号 = 期望接收的下一字节序号 = 2001 + 1000 = 3001

【例题4：标志位组合分析】
以下哪个标志位组合代表连接建立阶段的第二次握手？
A. SYN=1, ACK=0
B. SYN=1, ACK=1
C. FIN=1, ACK=1
D. RST=1, ACK=1

解析：B正确。第二次握手是服务器对客户端SYN的确认，同时为建立反向连接发送自己的SYN，故SYN和ACK均为1。

5.3.2 TCP运输连接管理

【例题5：三次握手序号变化】
TCP连接建立过程中，客户端初始序号seq=1000，服务器初始序号seq=3000。则第三次握手报文段的正确序号与确认号是：
A. seq=1001, ack=3001
B. seq=1000, ack=3000
C. seq=1001, ack=3000
D. seq=1000, ack=3001

解析：A正确。

  • 第一次握手：SYN=1, seq=1000（消耗序号）
  • 第二次握手：SYN=1, ACK=1, seq=3000, ack=1001（期望接收客户端的1001）
  • 第三次握手：ACK=1, seq=1001（消耗了1000），ack=3001（期望接收服务器的3001）

5.3.3 TCP的流量控制

【例题6：零窗口死锁破解】
主机A发送窗口=1000字节，已发送未确认700字节。收到主机B的确认报文，ack=801, rwnd=0。随后B进程读取200字节数据，此时B应立即：
A. 发送rwnd=200的报文
B. 等待A的探测报文
C. 发送ack=801, rwnd=200
D. 无需响应

解析：C正确。B读取数据后接收缓存腾出空间，必须立即通告新窗口值。TCP规定接收方有义务在窗口变化时主动通知，避免死锁。

【例题7：发送窗口计算（真题改编）】
主机甲和主机乙之间建立了一个TCP连接，TCP最大段长度为1000字节。若主机甲的当前拥塞窗口为4000字节，在主机甲向主机乙连续发送两个最大段后，成功收到主机乙发送的第一个确认段，确认段中通告的接收窗口大小为2000字节，则此时主机甲还可以向主机乙发送的最大字节数是（ ）。

解析：答案A. 1000字节。

计算过程：

  1. 确定发送窗口：swnd = min(cwnd, rwnd) = min(4000, 2000) = 2000字节
  2. 分析已发送数据：连续发送2个MSS = 2×1000 = 2000字节
  3. 确认情况：收到第一个MSS的确认 ⇒ 第一个MSS（1000字节）已确认
  4. 计算未确认数据：已发送未确认 = 第二个MSS = 1000字节
  5. 可发送空间：还可发送 = swnd - 已发送未确认 = 2000 - 1000 = 1000字节

关键点：发送窗口是"飞行中"数据的限制，已确认的数据不再占用窗口。

5.3.4 TCP的拥塞控制

【例题8：cwnd变化全过程】
某TCP连接ssthresh=32KB，MSS=2KB。第1轮次传输后cwnd=2KB，第5轮次发生超时。请填写第1-10轮次的cwnd值（KB）。

解析：

轮次 cwnd 算法阶段 说明
1 2 慢开始 初始=1MSS
2 4 慢开始 指数增长
3 8 慢开始 指数增长
4 16 慢开始 指数增长
5 24 拥塞避免 达ssthresh(32)，线性+2
5后 超时 - 网络拥塞
6 1 慢开始 超时后：cwnd=1, ssthresh=12
7 2 慢开始 指数增长
8 4 慢开始 指数增长
9 8 慢开始 指数增长
10 9 拥塞避免 cwnd=12时进入线性增长

【例题9：快重传触发】
cwnd=16KB时发送第1-16报文段，第3、5、7报文段丢失，其余正常到达。接收方会发送几个重复的ACK？发送方何时触发快重传？

解析：接收方会发送3个重复ACK（对第2报文段的重复确认）。当发送方连续收到3个相同的确认号时，立即重传第3报文段，不等待超时。此过程cwnd不降为1，而是减半后执行拥塞避免。

5.3.6 TCP可靠传输的实现

【例题10：发送窗口指针定位】
某TCP连接发送窗口swnd=3000字节，已发送未确认字节序号为2001-3500。此时指针P1、P2、P3分别指向何处？

解析：

  • P1指向已发送未确认首字节 = 2001
  • P2指向允许发送但尚未发送首字节 = 3501
  • P3指向发送窗外首字节 = 2001 + 3000 = 5001

验证：P3 - P1 = 5001 - 2001 = 3000 = swnd ✓

5.3.7 TCP超时重传时间(RTO)的选择

【例题11：RTO动态计算】
某TCP连接首次测得RTT样本=40ms，后续测得RTT样本=60ms。已知α=0.125，β=0.25，初始RTTd=20ms。求新的RTO。

解析：

1
2
3
RTTs = (1-0.125)×40 + 0.125×60 = 35 + 7.5 = 42.5ms
RTTd = (1-0.25)×20 + 0.25×|42.5-60| = 15 + 4.375 = 19.375ms
RTO = RTTs + 4×RTTd = 42.5 + 4×19.375 = 119.875ms ≈ 120ms

5.3.8 TCP的选择确认(SACK)

【例题12：SACK避免重传】
发送方发送序号1-1000,1001-2000,2001-3000,3001-4000，仅1001-2000丢失。启用SACK后，接收方应如何应答？

解析：ACK报文将包含：

  • 确认号=1001（累积确认，表明1001之前已收到）
  • SACK选项：报告已收到的块边界 (2001-4000)
  • 效果：发送方仅重传1001-2000，避免重传2001-4000

5.3.9 TCP窗口与缓存的关系

【例题13：接收窗口动态变化】
主机B接收缓存总大小=10KB，已接收未读取数据=3KB，不按序数据=2KB。此时B向A通告的rwnd是多少？若应用进程读取2KB后，rwnd变为多少？

解析：

  • 初始可用空间 = 10 - 3 - 2 = 5KB（rwnd）
  • 读取2KB后，已接收未读取减为1KB ⇒ 新rwnd = 10 - 1 - 2 = 7KB

综合应用题

【例题14：TCP全流程模拟】
主机A与B建立TCP连接，MSS=1KB，初始cwnd=1KB，ssthresh=8KB。传输过程中：

  1. 第1-3轮次无丢包，第4轮次第2个报文段丢失（引发3个重复ACK）
  2. 第5轮次开始直到cwnd=10KB时发生超时
  3. 后续传输顺利，窗口持续增大

要求：绘制cwnd变化曲线，标注各阶段名称、ssthresh变化点，并计算第1-8轮次的swnd值（假设rwnd始终充足）。

解析要点：

  • 第1-3轮次：慢开始 1→2→4→8（第3轮次达ssthresh）
  • 第4轮次：拥塞避免 8→9，丢包触发快重传→ssthresh=4.5, cwnd=4.5
  • 第5轮次起：拥塞避免 4.5→5.5→…→10（超时）
  • 超时后：ssthresh=5, cwnd=1，重启慢开始
  • 第8轮次：cwnd=4（1→2→4）

备考提示：TCP计算题核心公式

  1. 发送窗口 = min(cwnd, rwnd)
  2. 可发送量 = swnd - 已发送未确认量
  3. 慢开始：每RTT cwnd翻倍（指数）
  4. 拥塞避免：每RTT cwnd+1（线性）
  5. 超时：ssthresh=cwnd/2, cwnd=1
  6. 快重传：ssthresh=cwnd/2, cwnd=ssthresh（或+3）