第五章：运输层

1.运输层概述

之前课程所介绍的计算机网络体系结构中的物理层、数据链路层以及网络层它们共同解决了将主机通过异构网络互联起来所面临的问题，实现了主机到主机的通信。但实际上在计算机网络中进行通信的真正实体是位于通信两端主机中的进程。如何为运行在不同主机上的应用进程提供直接的通信服务是运输层的任务，运输层协议又称为端到端协议。

2.运输层端口号、复用与分用的概念

端口号：

端口号是运输层协议（TCP/UDP） 给应用程序分配的一个16 位整数标识符 ，取值范围是 0~65535，核心作用是区分同一台主机上的不同应用进程。

可以把主机比作一栋大楼，IP 地址是大楼的地址，而端口号就是大楼里各个房间的门牌号，运输层通过端口号把数据精准送到对应的应用程序。

端口号分类

• 熟知端口号（0~1023）：也叫系统端口号，由 IANA 统一分配，绑定常用的网络应用。例：HTTP 用 80、HTTPS 用 443、FTP 用 21、SSH 用 22。
• 登记端口号（1024~49151）：供用户或应用程序登记使用，避免和熟知端口号冲突。
• 临时端口号（49152~65535）：客户端发起连接时，系统临时分配的端口号，连接断开后释放。

复用（Multiplexing）

复用 指的是：发送方的多个应用进程，共用同一个运输层协议（TCP 或 UDP），通过不同的端口号，将数据封装成运输层报文，然后交给网络层发送。

简单理解：多个应用的 "数据流"，通过端口号这个 "标记"，在运输层合并成一股数据流，共用一条网络层通道传输。例：你电脑上同时开着浏览器（用 80 端口）、QQ（用特定登记端口）、网易云音乐（用另一端口），这些应用的数据都会通过 TCP/UDP 协议，带着各自的端口号，交给 IP 层发送，这就是复用。

分用（Demultiplexing）

分用 是复用的逆过程：接收方 的运输层收到网络层传来的报文后，根据报文中的目的端口号，把数据分发给对应的应用进程。

简单理解：运输层收到一股包含多个应用数据的数据流后，根据端口号这个 "标记"，拆分成多股数据流，分别送到对应的应用程序。例：服务器收到一个 TCP 报文，目的端口号是 80，就把数据交给 HTTP 服务；目的端口号是 21，就交给 FTP 服务，这就是分用。

核心关系总结

• 复用 ：发送方 多应用进程 → 一个运输层 → 一个网络层

• 分用 ：接收方 一个网络层 → 一个运输层 → 多应用进程

• 关键 ：端口号是实现复用和分用的唯一依据。

3. UDP和TCP的对比

核心特性对比表

对比维度	TCP（传输控制协议）	UDP（用户数据报协议）
连接方式	面向连接，三次握手建立连接，四次挥手断开连接	无连接，直接发送数据，无需建立和释放连接
可靠性	可靠，通过确认应答、序列号、超时重传等机制保证数据不丢失、不重复、按序到达	不可靠，不确认、不重传、不排序，数据可能丢失、乱序或重复
数据处理	面向字节流，无数据边界，需应用层处理数据拆分与拼接	面向数据报，每个数据报独立，有明确边界，接收方完整接收每个数据报
流量控制	支持，滑动窗口机制防止接收方缓冲区溢出	不支持，发送方持续发送，可能导致接收方缓冲区溢出
拥塞控制	支持，通过慢启动、拥塞避免等算法动态调整发送速率	不支持，发送速率固定，可能引发网络拥塞
头部开销	至少 20 字节，包含序列号、确认号等众多控制字段	固定 8 字节，仅含源端口、目的端口、长度、校验和
传输速度	较慢，连接管理、确认应答等机制增加延迟	较快，无额外控制机制，传输延迟低
适用场景	文件传输、网页浏览、邮件收发、数据库同步等	实时视频、语音通话、在线游戏、DNS 查询等

核心差异详解

1. 连接与可靠性机制
   • TCP：通过三次握手建立连接，四次挥手释放连接，确保通信双方状态同步。传输中使用序列号标识数据包，接收方通过确认号反馈接收状态，发送方超时未收到确认则重传。同时，滑动窗口实现流量控制，拥塞控制算法避免网络拥塞，保障数据可靠传输。
   • UDP：无连接建立与释放过程，发送方直接封装数据发送，接收方收到后不确认。数据传输的可靠性、顺序性等需由应用层自行处理，如实时视频应用可通过丢帧保证流畅性。
2. 性能与开销
   • TCP：由于连接管理、可靠性保障等机制，头部开销大，传输延迟较高，效率相对较低，但能保证数据传输的准确性和完整性。
   • UDP：头部开销小，无复杂控制机制，数据传输延迟低，效率高，适合对实时性要求高、允许少量数据丢失的场景。
3. 应用场景选择
   • TCP：适用于对数据可靠性要求严格的场景，如文件传输（FTP）、超文本传输（HTTP/HTTPS）、邮件传输（SMTP）等，这些场景中数据的完整性和顺序性至关重要。
   • UDP：适用于实时性优先的场景，如视频会议、在线直播、VoIP、在线游戏等，这些场景中少量数据丢失不会对整体体验造成太大影响，而低延迟更为关键。

4.TCP的流量控制

核心目的：让发送方的速率适配接收方的处理能力，防止接收方缓冲区溢出导致数据丢失。

• 实现手段 ：滑动窗口机制 （这里指的是接收窗口 rwnd）

  1. 接收方会在 TCP 报文首部的 窗口字段 中，告诉发送方自己当前的空闲缓冲区大小（即接收窗口 rwnd）。
  2. 发送方的发送窗口大小 不能超过 接收方给出的 rwnd，只能在窗口范围内发送数据。
  3. 接收方处理完数据、腾出缓冲区后，会更新 rwnd 并告知发送方，发送方的窗口随之 "滑动"，继续发送后续数据。

• 关键特点 ：流量控制是点对点的控制，只考虑发送方和接收方的状态，不关心网络中间链路的情况。

若接收方窗口调为0后，一段时间之后又调为200，此时向发送方传递确认报文，可此时报文丢失，则会造成发送方窗口始终为0，接收方以为发送方收到了确认报文而开始等待数据，造成死锁，如何解决？

当发送方窗口大小为0时，其隔一段时间就会发送一个1字节大小的零窗口探测报文，看看此时接收窗口大小是否进行调整

当发送的零窗口探测报文也丢失，不会造成死锁，零窗口探测报文也有超时重传机制。

5.TCP的拥塞控制

核心目的 ：让发送方的速率适配网络带宽，防止大量数据涌入网络导致链路拥塞、丢包。

• 实现手段 ：基于拥塞窗口 cwnd 的四种算法，四个阶段依次执行：

  1. 慢启动
     • 刚建立连接时，cwnd 初始值很小（比如 1 个 MSS，最大报文段长度）。
     • 每收到一个确认，cwnd 指数增长（1→2→4→8...）。
     • 当 cwnd 增长到 慢启动门限 ssthresh 时，进入拥塞避免阶段。
  2. 拥塞避免
     • 每经过一个往返时间 RTT，cwnd 线性增长（每次加 1），增速放缓。
     • 目的是试探网络的拥塞临界点，避免突然拥塞。
  3. 拥塞检测（快重传）
     • 触发条件：超时重传 或 收到 3 个重复确认。
     • 处理逻辑：
       • 超时重传：说明网络严重拥塞 → ssthresh 设为当前 cwnd 的一半，cwnd 重置为 1，重新慢启动。
       • 3 个重复确认：说明只是个别包丢失 → ssthresh 设为当前 cwnd 的一半，cwnd 设为 ssthresh，进入快速恢复。
  4. 快速恢复
     • 发送方快速重传丢失的报文段，同时 cwnd 线性增长，直到 cwnd 等于 ssthresh，回到拥塞避免阶段。

• 关键特点 ：拥塞控制是全局 的控制，考虑整个网络的链路状态；发送方的实际发送窗口 = min(rwnd, cwnd)，由流量控制和拥塞控制共同决定。

6.TCP超时重传时间的选择

核心目的：设置合理的超时重传时间 RTO（Retransmission TimeOut），既要避免过早重传导致网络冗余，又要避免过晚重传导致效率低下。

• 核心计算逻辑

  1. 先计算 加权平均往返时间 RTTs（平滑后的 RTT，避免单次波动影响）
  2. 再计算 往返时间偏差 RTTd（衡量 RTT 的波动程度）
  3. 最终超时重传时间 RTO)

• 关键原则 ：RTO 不是固定值，会随着网络状况动态调整；如果超时重传后仍未收到确认，会采用指数退避策略（比如 RTO 翻倍），避免频繁重传加剧拥塞。

针对出现超时重传时无法测准往返时间RTT的问题，有以下解决方法

在计算加权平均往返时间RTTS时，只要报文段重传了，就不采用其往返时间RTT样本。也就是出现重传时，不重新计算RTTS，进而超时重传时间RTO也不会重新计算。

此方法的漏洞如下：如果报文段时延突然增大很多，并且之后很长一段时间都会保持这种时延。因此在原来得出的重传时间内，不会收到确认报文段，于是重传，造成死锁修正方法：报文段每重传一次，就把超时重传时间RTO增大一些，典型的做法是将RTO的值取为旧RTO的2倍

7.TCP可靠传输的实现

TCP 可靠传输的核心是 "确认 + 重传"，配合一系列辅助机制，确保数据不丢失、不重复、按序到达，具体依赖 5 个关键机制：

1. 序列号
   • 每个字节的数据都有唯一的序列号，报文段首部的序列号字段标识本包第一个字节的编号。
   • 作用：解决乱序问题，接收方可以按序列号重组数据。
2. 确认应答（ACK）
   • 接收方收到数据后，会发送确认报文，首部的确认号字段表示 "期望收到的下一个字节的序列号"。
   • 作用：告诉发送方 "哪些数据已经成功接收"。
3. 超时重传
   • 发送方发送数据后启动定时器，如果超时未收到确认，就重传该报文段。
   • 作用：解决丢包问题。
4. 快速重传
   • 接收方收到乱序报文段时，会立刻发送重复确认（比如期望收到 100 号字节，却收到 150 号，就反复发确认号 100）。
   • 发送方收到 3 个重复确认，不用等定时器超时，直接重传丢失的报文段。
   • 作用：比超时重传更快，提升传输效率。
5. 校验和
   • 发送方计算报文段的校验和，写入首部；接收方重新计算，对比校验和。
   • 作用：检测数据在传输过程中是否损坏，损坏则直接丢弃，不发送确认，触发重传

**8.**TCP 的运输连接管理

TCP 是面向连接 的协议，连接管理分为 连接建立 和 连接释放 两个阶段，核心是 "三次握手" 和 "四次挥手"。

8.1 连接建立：三次握手

核心目的：通信双方同步序列号和窗口信息，确认彼此的收发能力，建立可靠连接。

1. 第一次握手（客户端→服务器）
   • 客户端发送 SYN 报文 （同步报文段），首部 SYN=1，初始序列号 seq=x。
   • 含义："我想和你建立连接，我的初始序列号是 x"。
2. 第二次握手（服务器→客户端）
   • 服务器收到 SYN 报文后，回复 SYN+ACK 报文 ，首部 SYN=1，ACK=1，确认号 ack=x+1，自己的初始序列号 seq=y。
   • 含义："我收到你的连接请求了，确认号是 x+1（期望下一个字节是 x+1），我的初始序列号是 y"。
3. 第三次握手（客户端→服务器）
   • 客户端收到 SYN+ACK 报文后，发送 ACK 报文 ，首部 ACK=1，确认号 ack=y+1，序列号 seq=x+1。
   • 含义："我收到你的确认了，确认号是 y+1"。
   • 服务器收到 ACK 报文后，连接正式建立。

为什么需要三次握手？

• 防止失效的连接请求报文突然到达服务器，导致服务器建立无效连接。比如客户端发的 SYN 报文延迟很久才到，服务器回复后客户端已经不需要这个连接了，三次握手可以让客户端最后确认，避免资源浪费。

8.2 连接释放：四次挥手

核心目的：TCP 是全双工通信，双方需要分别关闭自己的发送通道，确保所有数据都传输完毕。

1. 第一次挥手（客户端→服务器）
   • 客户端发送 FIN 报文 （终止报文段），首部 FIN=1，序列号 seq=u。
   • 含义："我没有数据要发给你了，请求关闭我的发送通道"。
2. 第二次挥手（服务器→客户端）
   • 服务器收到 FIN 报文后，发送 ACK 报文 ，确认号 ack=u+1，序列号 seq=v。
   • 含义："我收到你的关闭请求了，我这边的接收通道可以关闭了"。
   • 此时客户端→服务器的通道关闭，但服务器→客户端的通道还能传数据。
3. 第三次挥手（服务器→客户端）
   • 服务器发完剩余数据后，发送 FIN+ACK 报文 ，首部 FIN=1，ACK=1，确认号 ack=u+1，序列号 seq=w。
   • 含义："我也没有数据要发给你了，请求关闭我的发送通道"。
4. 第四次挥手（客户端→服务器）
   • 客户端收到 FIN+ACK 报文后，发送 ACK 报文 ，确认号 ack=w+1，序列号 seq=u+1。
   • 客户端发送 ACK 后，会等待 2MSL（最长报文段寿命），确保服务器收到 ACK，然后彻底关闭连接；服务器收到 ACK 后，立即关闭连接。

为什么需要四次挥手？

• 因为 TCP 是全双工，关闭连接时，双方的发送通道需要独立关闭。服务器收到 FIN 后，可能还有数据要发，不能立刻关闭自己的发送通道，所以需要先回 ACK，等数据发完再发 FIN，因此比三次握手多一次。

9.TCP报文段的首部格式

字段（长度）	核心作用
源端口（2 字节）	标识发送方的应用程序端口
目的端口（2 字节）	标识接收方的应用程序端口
序列号 seq（4 字节）	本报文段第一个字节的编号
确认号 ack（4 字节）	期望收到的下一个字节的编号（仅 ACK=1 时有效）
数据偏移（4 位）	表示 TCP 首部的长度（单位：4 字节），最小值 5 → 20 字节
保留（6 位）	备用，暂时置 0
控制位（6 位）	关键标志位：1. URG：紧急指针有效2. ACK：确认号有效3. PSH：要求接收方立即交付应用层4. RST：重置连接（处理异常）5. SYN：同步序列号（建立连接）6. FIN：终止连接（关闭通道）
窗口（2 字节）	接收窗口大小 rwnd，用于流量控制
校验和（2 字节）	检测首部 + 数据的传输错误
紧急指针（2 字节）	仅 URG=1 时有效，标识紧急数据的末尾位置
选项（可变，0~40 字节）	可选字段，比如 MSS（最大报文段长度）、窗口扩大因子等