《计算机网络自顶向下》学习随记 第三章：运输层

2025/2/10
寒假玩累了，上学期也一直在玩，新学期想要踏踏实实学点东西，在这里边记录边督促自己！两个小flag：
①《计算机网络自顶向下》的书+lab
② cs144的lab
大佬的资源汇总：https://github.com/PKUFlyingPig/Computer-Network-A-Top-Down-Approach/tree/master
希望自己可以尽快上手，就省去了视频，ppt+wireshark，看书做补充
2025/2/24
“日出我从海面出发”
“看我从大风扬起船帆”

---

概述

1. 首先，复习一下，运输层是干嘛的嘞？
   不同主机上的应用进程之间的逻辑通信。
2. 运输层是在哪里实现的？
   在端系统，而非路由器上。
3. 多路复用、多路分解？
   一言以蔽之，多路复用在发端，多路分解在收端。收端的话需要根据字段的标识定位到特定进程的套接字，发端的话需要为每个套接字封装上相应的首部信息，从而生成报文段。

多路复用与多路分解之无连接vs有连接

1. 无连接的多路复用与多路分解（UDP）

• 多路复用：
  • UDP在发送数据之前不需要建立连接。它从应用程序接收数据，添加源端口号和目的端口号字段后，将数据封装成UDP报文段并传递给网络层。
  • UDP套接字通过二元组（目的IP地址、目的端口号）来标识。
• 多路分解：
  • 当UDP报文段到达接收主机时，运输层检查报文段中的目的端口号，将数据导向绑定到该端口号的套接字。
  • 不同源IP地址或源端口号的报文段，只要目的IP地址和目的端口号相同，就会被导向同一个套接字。【区别在这里】

2. 有连接的多路复用与多路分解（TCP）

• 多路复用：
  • TCP在发送数据之前需要建立连接，通过三次握手来确保双方准备好进行数据传输。
  • TCP套接字通过四元组（源IP地址、源端口号、目的IP地址、目的端口号）来标识。
• 多路分解：
  • 当TCP报文段到达接收主机时，运输层检查报文段中的所有四个字段（源IP地址、源端口号、目的IP地址、目的端口号），将数据导向对应的套接字。
  • 不同的TCP连接即使使用相同的源端口号和目的端口号，也可以通过源IP地址和目的IP地址来区分。

4. 本章思路：
   什么是可靠数据传输？–>TCP是怎样提供可靠数据传输的？
   什么是拥塞控制？–>TCP是怎样实现拥塞控制的？

1 UDP

1.1 UDP的基本特性

1. 无连接（Connectionless）
   通信前无需握手建立连接，直接发送数据（如直接调用sendto()函数）。
   示例场景：DNS查询（客户端直接向服务器发送请求，无需预先建立连接）。
2. 不可靠传输（Unreliable）

• 不保证交付：数据包可能丢失、乱序或重复。
• 无确认、重传、拥塞控制机制 → 适用于对实时性要求高但对可靠性要求低的场景（如视频通话）。

3. 头部开销小（8字节 vs TCP的20字节）
   仅有以下字段：

• 源端口（Source Port，2字节）
• 目的端口（Destination Port，2字节）
• 长度（Length，2字节：报头+数据的总长度）
• 校验和（Checksum，2字节，可选）

协议头格式图示：
0 7 8 15 16 23 24 31
±-------±-------±-------±-------+
| Source Port | Destination Port |
±-------±-------±-------±-------+
| Length | Checksum |
±-------±-------±-------±-------+
| Data …

4. 支持一对一、一对多（多播/广播）通信
   广播地址（IPv4为255.255.255.255）。
   多播地址（IPv4为224.0.0.0~239.255.255.255）。

1.2 UDP的核心应用场景

1. 实时性要求高的场景

• 实时音视频传输（如Zoom、腾讯会议）：可容忍少量丢包，但要求低延迟。
• 在线游戏：玩家位置同步需要快速响应，UDP的延迟比TCP更稳定（避免拥塞控制导致的波动）。

2. 简单请求-应答模型

• DNS查询：单次请求/响应的场景，无需维护长连接。
• SNMP网络管理：周期性状态监测，适合轻量级UDP传输。

3. 广播/多播通信

• 局域网设备发现（如打印机广播服务）。
• 实时数据分发（如股票行情推送）。

4. 定制协议的基础

• 可以在UDP上实现自定义的可靠性机制（如RTP/RTCP、QUIC）。
• HTTP/3（基于QUIC）：利用UDP解决TCP队头阻塞问题，实现更高效的传输。

2 TCP

2.1 TCP的报文结构

1. 首部字段
   长度为20字节

• 源端口号、目的端口号：为了多路复用、多路分解
• 序号、确认号
• • 序号 ：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
• • 确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
• 接收窗口：指示接收方愿意接受的字节数量
• 首部长度：就是TCP首部的长度
• 确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
• 同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
• 终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。

2. 数据字段
   MSS:限制了 TCP数据字段的最大长度

2.2 超时/重传机制

TCP采用超时/重传机制来处理报文段的丢失问题。

• 超时机制：发送方为每个未被确认的报文段设置一个计时器，如果在计时器到期时仍未收到确认，发送方会重传该报文段。【计算RTO】
• 重传机制：TCP使用选择性重传（Selective Repeat）或累计确认（Cumulative Acknowledgment）机制，确保只有丢失的报文段被重传，而不是整个窗口内的所有报文段。

2.3 流量控制

为了防止接收缓存溢出，使发送方的发送速率和接收方的读取速率相匹配。
流量控制（Flow Control）
目标：防止发送方发送数据的速率超过接收方的处理能力，避免接收方缓冲区溢出导致丢包。

核心机制：滑动窗口协议

1. 接收窗口（rwnd）：
   接收方通过TCP报文头中的Window Size字段告知发送方自己的剩余缓冲区大小（即rwnd）。
   示例：接收方发送ACK报文时携带rwnd=1000，表示当前还能接收1000字节的数据。
2. 发送窗口动态调整：
   发送方的实际发送窗口由rwnd（接收方允许的窗口）和cwnd（拥塞窗口）共同决定，取两者最小值：
   实际窗口 = min(rwnd, cwnd)
   滑动过程：
   每次收到ACK时，发送窗口向前滑动，释放已确认数据的空间。

2.4 拥塞控制

防止发送方速率过快导致网络链路拥堵（如路由器队列溢出引发的丢包）

2.5 关于三次握手

三次握手发生在啥时候？

客户端调用connect，操作系统启动三次握手，发送第一个SYN到服务器。
服务器调用listen监听客户端的连接请求，收到客户端的SYN报文段后，会执行SYN-ACK响应，完成三次握手的第二步。
客户端收到服务器的SYN-ACK报文段后，发送ACK报文段，完成三次握手的第三步。

TCPvsUDP

总结

比较草率地过了一遍
拥塞控制那块没好好看，没懂【慢启动、拥塞避免、快重传、快恢复】
以及一些高频的问题：
【为啥是三次握手，两次不行吗】