简介这份PPT课件面向计算机专业学生及网络初学者系统讲解计算机网络体系结构中的运输层核心知识帮助读者从自顶向下的视角理解端到端通信原理。内容围绕运输层服务展开涵盖多路复用与多路分解、UDP无连接传输、可靠数据传输原理、TCP连接管理与报文段结构、流量控制、拥塞控制原则及TCP拥塞控制机制等模块并借助家庭通信类比、rdt协议演进、回退N帧与选择重传等实例辅助理解。资源包共1个文件为ppt格式大小约1.82MB结构紧凑适合课堂讲授或自学复习使用。目前已有58人学习读者可借此梳理运输层知识脉络掌握TCP与UDP协议差异、套接字分解机制及拥塞控制策略为后续网络编程与协议分析打下基础。1. 运输层到底在解决什么问题从一份自顶向下 PPT 说起很多人复习计算机网络时卡在运输层这一章TCP 三次握手背得滚瓜烂熟一到“为什么需要多路复用”“rdt 为什么从 rdt1 一路演进到 rdt3”就说不清楚。这份《计算机网络自顶向下》运输层 PPT把 3.1 到 3.7 的骨架完整铺开——运输层服务、多路复用与多路分解、UDP、可靠数据传输原理、TCP、拥塞控制原则、TCP 拥塞控制一条线拉通。它适合两类人一是准备期末或考研 408 的需要把散落的知识点串成因果链二是做后端、DevOps 的工程师天天调 TCP 连接、UDP 端口、拥塞窗口却从没系统看过底层机制。这份 PPT 的价值不在“又一份课件”而在于它用自顶向下的视角把应用层需求如何倒逼运输层设计讲清楚了。2. 多路复用与多路分解端口号、套接字和两种分解方式2.1 为什么运输层必须做复用与分解一台主机上同时跑着浏览器、即时通讯、DNS 查询网络层只负责把 IP 数据报送到主机但主机怎么知道这个数据报该交给哪个进程这就是运输层复用与分解要解决的问题。发送方从多个套接字收集数据加上首部封装成段交给网络层——这是复用接收方根据首部信息把段交付给正确的套接字——这是分解。PPT 里用了一个很直观的类比网络层是邮政服务负责把信送到家庭主机运输层是家里的 Ann 和 Bill负责把信分给 12 个孩子进程。没有运输层网络层只能把数据丢到主机门口没人认领。2.2 UDP 分解二元组标识套接字UDP 套接字由二元组标识目的 IP 地址 目的端口号。这意味着只要目的 IP 和目的端口相同不管源 IP 和源端口是什么UDP 段都会被定向到同一个套接字。PPT 里给了一段 Java 代码示例// 服务器创建 UDP 套接字绑定端口 6428 DatagramSocket serverSocket new DatagramSocket(6428); // 接收数据报 byte[] receiveData new byte[1024]; DatagramPacket receivePacket new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); // 从数据报中提取客户端地址和端口用于回送响应 InetAddress clientIP receivePacket.getAddress(); int clientPort receivePacket.getPort();这段代码的逻辑是服务器在 6428 端口监听任何客户端发来的 UDP 段只要目的端口是 6428都会进入这个套接字。receive()方法阻塞等待数据报到达收到后通过getAddress()和getPort()拿到客户端的返回地址。参数上DatagramSocket(6428)中的 6428 是服务器绑定的本地端口客户端发送时目的端口必须填这个值。常见做法是服务器用固定端口客户端用系统自动分配的临时端口。2.3 TCP 分解四元组标识套接字TCP 套接字由四元组标识源 IP 地址 源端口号 目的 IP 地址 目的端口号。接收主机用这四个值把段定向到正确的套接字。PPT 里特别强调了一个场景Web 服务器对每个连接都有不同的套接字。非持久 HTTP 每个请求都新建连接所以每个请求对应不同的套接字持久 HTTP 则复用同一个连接。多线程 Web 服务器会为每个新连接创建新线程和新套接字这就是为什么四元组是必要的——如果只用目的 IP 和目的端口多个客户端同时访问同一个 80 端口服务器就分不清哪个段属于哪个连接了。提示UDP 的二元组分解意味着如果两个客户端用相同的源端口向同一个服务器端口发数据服务器回送时只能根据数据报里的源地址和源端口来区分。TCP 的四元组则天然支持多客户端并发连接同一服务端口。3. UDP 协议无连接传输的报文格式、校验和与适用场景3.1 UDP 为什么存在没有不必要的只有基本要素UDP 被 PPT 称为“没有不必要的只有基本要素”的互联网传输协议。它不做握手、不维护连接状态、不保证可靠交付、不做拥塞控制。这些“缺失”恰恰是它的优势DNS 查询只需要一个请求一个响应建立连接的开销比查询本身还大流式多媒体能容忍丢包但不能容忍时延UDP 的“尽力而为”反而更合适。PPT 里列了 UDP 的典型应用DNS、SNMP、流式多媒体、实时游戏。这些场景的共同点是要么请求-响应模式极简要么对时延敏感而对可靠性要求不高。3.2 UDP 报文段格式与校验和计算UDP 报文段格式很简单源端口号16 位、目的端口号16 位、长度16 位包括首部和数据、校验和16 位、应用数据。校验和的计算方法是把段内容按 16 位分组做反码求和最高位的进位回卷加到最低位。PPT 给了一个具体例子两个 16 位整数相加 1111 0011 0011 0011 1110 1010 1010 1010 1101 1101 1101 1101 (回卷进位) 和的反码 0010 0010 0010 0010 (校验和)接收方把收到的段重新做一次反码求和如果结果全是 1说明没有检测到差错。注意校验和只能检测比特翻转不能纠正也不能保证绝对可靠——如果两个比特同时翻转且恰好抵消校验和就查不出来。常见做法是对可靠性要求高的应用在应用层自己做重传和确认比如 QUIC 协议就是在 UDP 之上实现了可靠传输。3.3 UDP 端口测试与调试实际工作中排查 UDP 问题常用nc或iperf3做端口连通性测试。比如# 在服务器端监听 UDP 9999 端口 nc -u -l 9999 # 在客户端发送 UDP 数据包 echo hello | nc -u 服务器IP 9999 # 用 iperf3 做 UDP 打流测试带宽 10M持续 10 秒 iperf3 -c 服务器IP -u -b 10M -t 10nc -u -l中的-u指定 UDP 模式-l表示监听。iperf3的-u指定 UDP-b指定目标带宽-t指定持续时间。UDP 打流测试能直观看到丢包率和抖动这是 TCP 测试看不到的。如果发现 UDP 丢包严重先查网络中间设备是否限速再查接收端缓冲区是否太小。4. 可靠数据传输原理从 rdt1 到 rdt3 的演进与流水线协议4.1 rdt 协议为什么一步步变复杂PPT 把可靠数据传输原理放在运输层核心位置因为它是“网络主题中最重要的 10 个之一”。rdt 的演进逻辑是信道越来越不可靠协议越来越复杂。rdt1.0 假设信道完全可靠发送方直接发接收方直接收。rdt2.0 引入比特差错发送方需要等待确认ACK或否认NAK收到 NAK 就重传。rdt2.1 解决 ACK/NAK 本身出错的问题给数据包加序号发送方收到重复 ACK 时知道接收方没收到新包。rdt2.2 去掉 NAK只用 ACK 加序号。rdt3.0 引入超时重传因为数据包可能丢失不能无限等待。4.2 流水线协议回退 N 帧与选择重传rdt3.0 是停等协议发一个包等一个确认效率极低。PPT 引出流水线协议发送方可以连续发多个包不用等每个包的确认。回退 N 帧Go-Back-N和选择重传Selective Repeat是两种典型实现。回退 N 帧的接收方只按序接收如果收到乱序包就丢弃发送方超时后重传从丢失包开始的所有包。选择重传的接收方有缓冲区可以接收乱序包发送方只重传真正丢失的包。PPT 里用窗口大小来区分回退 N 帧的发送窗口大于 1接收窗口等于 1选择重传的发送窗口和接收窗口都大于 1。# 回退 N 帧发送方伪代码 base 1 # 窗口基序号 next_seq 1 # 下一个待发序号 N 4 # 窗口大小 while True: if next_seq base N: send_packet(next_seq) next_seq 1 if timeout(base): # 超时重传从 base 开始的所有已发未确认包 for seq in range(base, next_seq): send_packet(seq) if receive_ack(seq) and seq base: base seq 1这段伪代码的核心参数是N窗口大小和base窗口基序号。next_seq base N控制发送窗口不溢出超时后重传base到next_seq之间的所有包这就是“回退 N 帧”名字的由来。选择重传则只需要重传超时的那个包但接收方要维护缓冲区来暂存乱序到达的包。注意回退 N 帧在丢包率高时性能急剧下降因为一个包丢失会导致后续所有包重传。选择重传效率更高但实现复杂度也更高。TCP 实际使用的是选择确认SACK机制介于两者之间。5. TCP 连接管理与拥塞控制三次握手、流量控制和吞吐量模型5.1 TCP 三次握手与四次挥手PPT 里 TCP 部分从连接管理讲起。三次握手的本质是双方交换初始序号确认对方收发能力正常。第一次客户端发 SYN第二次服务器回 SYNACK第三次客户端回 ACK。为什么不是两次因为如果客户端第一个 SYN 在网络中滞留超时后重发服务器收到重发的 SYN 后建立连接但客户端可能已经放弃。两次握手会让服务器单方面认为连接已建立浪费资源。四次挥手是因为 TCP 是全双工的每个方向需要单独关闭。# 查看当前 TCP 连接状态 ss -tan # 查看 TCP 拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 查看 TCP 发送和接收缓冲区大小 sysctl net.ipv4.tcp_wmem net.ipv4.tcp_rmemss -tan列出所有 TCP 连接及其状态-t表示 TCP-a表示所有-n表示不解析服务名。sysctl net.ipv4.tcp_congestion_control查看当前拥塞控制算法常见值有 cubic、reno、bbr。tcp_wmem和tcp_rmem分别控制发送和接收缓冲区调大缓冲区能提升高带宽高时延场景的吞吐量。5.2 TCP 流量控制与拥塞控制流量控制是接收方通过接收窗口rwnd告诉发送方自己还能收多少数据防止接收方缓冲区溢出。拥塞控制是发送方根据网络状况调整发送速率防止网络过载。PPT 里讲了 TCP 拥塞控制的几个阶段慢启动、拥塞避免、快速重传、快速恢复。慢启动阶段拥塞窗口指数增长到达阈值后进入拥塞避免线性增长。收到三个重复 ACK 时快速重传不等待超时。超时则拥塞窗口降为 1重新慢启动。5.3 TCP 吞吐量与公平性PPT 给出了 TCP 吞吐量的时延模型吞吐量 ≈ 窗口大小 / 往返时间。这意味着在长肥管道高带宽高时延中要提升吞吐量必须增大窗口。TCP 公平性指的是多个 TCP 连接共享同一瓶颈链路时每个连接最终能获得大致相等的带宽。但 UDP 流不参与拥塞控制会挤占 TCP 的带宽这是流媒体和 TCP 流量共存时常见的问题。机制作用关键参数流量控制防止接收方缓冲区溢出rwnd接收窗口拥塞控制防止网络过载cwnd拥塞窗口、ssthresh慢启动快速探测可用带宽cwnd 指数增长拥塞避免稳定利用带宽cwnd 线性增长快速重传减少重传延迟三个重复 ACK6. 把 PPT 用出效果复习路径、实验对照和几个容易翻车的地方6.1 复习路径从应用层需求倒推运输层设计这份 PPT 的章节顺序本身就是一条复习路径先看 3.1 运输层服务理解运输层为应用层提供什么再看 3.2 复用与分解理解端到端通信怎么落到进程然后 3.3 UDP 和 3.5 TCP 对比两种协议的设计取舍3.4 可靠数据传输原理是理解 TCP 的基础3.6 和 3.7 拥塞控制是运输层最复杂的部分。我一般会建议按这个顺序过一遍每看完一节问自己一个问题如果去掉这个机制会发生什么比如去掉序号会怎样去掉超时重传会怎样。这种“反事实推演”比死记硬背有效得多。6.2 实验对照用 ss、iperf3 和 tcpdump 验证 PPT 里的机制PPT 讲的是原理实际验证要靠工具。用ss -tan看连接状态能直观看到三次握手后的 ESTABLISHED 状态和四次挥手后的 TIME_WAIT 状态。用iperf3做 TCP 和 UDP 打流对比能直观感受拥塞控制对吞吐量的影响。用tcpdump抓包能看到 SYN、SYNACK、ACK 的实际报文# 抓取 80 端口的 TCP 包只抓前 20 个 tcpdump -i eth0 -c 20 tcp port 80 # 抓取 UDP 9999 端口的包 tcpdump -i eth0 udp port 9999 # 用 iperf3 做 TCP 打流持续 30 秒 iperf3 -c 服务器IP -t 30tcpdump -i eth0指定网卡-c 20限制抓包数量tcp port 80是过滤表达式。抓包后能看到 TCP 首部里的序号、确认号、窗口大小对照 PPT 里的报文段结构图理解会深很多。6.3 几个容易翻车的地方第一个坑把 UDP 校验和当成可靠保证。校验和只能检测比特翻转不能检测丢包和乱序更不能保证交付。第二个坑认为 TCP 三次握手是为了“确认双方在线”。三次握手的核心是交换初始序号确认双方收发能力不是简单的“在线检测”。第三个坑混淆流量控制和拥塞控制。流量控制是接收方驱动的拥塞控制是发送方根据网络状况驱动的两者独立但协同。第四个坑以为回退 N 帧和选择重传只是窗口大小不同。两者的接收方行为完全不同回退 N 帧接收方丢弃乱序包选择重传接收方缓存乱序包。第五个坑忽略 TIME_WAIT 状态。主动关闭方进入 TIME_WAIT 等待 2MSL是为了确保最后一个 ACK 能到达对方如果不等旧连接的延迟包可能干扰新连接。6.4 一个具体技巧用 Wireshark 对照 PPT 看三次握手如果你想把 PPT 里的 TCP 报文段结构和实际抓包对应起来最直接的方法是用 Wireshark 抓一次本地回环的 HTTP 请求。启动 Wireshark选择回环接口过滤tcp.port 80然后在浏览器访问一个 HTTP 网站。你会看到 SYN、SYNACK、ACK 三个包展开 TCP 首部对照 PPT 里的字段源端口、目的端口、序号、确认号、窗口大小、校验和。重点看序号的变化SYN 包的序号是初始序号SYNACK 包的确认号是初始序号1ACK 包的序号是初始序号1确认号是服务器初始序号1。这个对照过程比看十遍 PPT 都管用。从那以后我每次复习运输层都会先抓一次包把 PPT 里的字段和实际报文对一遍再去看协议演进逻辑。希望帮到你。本文还有配套的精品资源点击获取 计算机网络运输层详解：多路复用、UDP、TCP与可靠传输原理
简介这份PPT课件面向计算机专业学生及网络初学者系统讲解计算机网络体系结构中的运输层核心知识帮助读者从自顶向下的视角理解端到端通信原理。内容围绕运输层服务展开涵盖多路复用与多路分解、UDP无连接传输、可靠数据传输原理、TCP连接管理与报文段结构、流量控制、拥塞控制原则及TCP拥塞控制机制等模块并借助家庭通信类比、rdt协议演进、回退N帧与选择重传等实例辅助理解。资源包共1个文件为ppt格式大小约1.82MB结构紧凑适合课堂讲授或自学复习使用。目前已有58人学习读者可借此梳理运输层知识脉络掌握TCP与UDP协议差异、套接字分解机制及拥塞控制策略为后续网络编程与协议分析打下基础。1. 运输层到底在解决什么问题从一份自顶向下 PPT 说起很多人复习计算机网络时卡在运输层这一章TCP 三次握手背得滚瓜烂熟一到“为什么需要多路复用”“rdt 为什么从 rdt1 一路演进到 rdt3”就说不清楚。这份《计算机网络自顶向下》运输层 PPT把 3.1 到 3.7 的骨架完整铺开——运输层服务、多路复用与多路分解、UDP、可靠数据传输原理、TCP、拥塞控制原则、TCP 拥塞控制一条线拉通。它适合两类人一是准备期末或考研 408 的需要把散落的知识点串成因果链二是做后端、DevOps 的工程师天天调 TCP 连接、UDP 端口、拥塞窗口却从没系统看过底层机制。这份 PPT 的价值不在“又一份课件”而在于它用自顶向下的视角把应用层需求如何倒逼运输层设计讲清楚了。2. 多路复用与多路分解端口号、套接字和两种分解方式2.1 为什么运输层必须做复用与分解一台主机上同时跑着浏览器、即时通讯、DNS 查询网络层只负责把 IP 数据报送到主机但主机怎么知道这个数据报该交给哪个进程这就是运输层复用与分解要解决的问题。发送方从多个套接字收集数据加上首部封装成段交给网络层——这是复用接收方根据首部信息把段交付给正确的套接字——这是分解。PPT 里用了一个很直观的类比网络层是邮政服务负责把信送到家庭主机运输层是家里的 Ann 和 Bill负责把信分给 12 个孩子进程。没有运输层网络层只能把数据丢到主机门口没人认领。2.2 UDP 分解二元组标识套接字UDP 套接字由二元组标识目的 IP 地址 目的端口号。这意味着只要目的 IP 和目的端口相同不管源 IP 和源端口是什么UDP 段都会被定向到同一个套接字。PPT 里给了一段 Java 代码示例// 服务器创建 UDP 套接字绑定端口 6428 DatagramSocket serverSocket new DatagramSocket(6428); // 接收数据报 byte[] receiveData new byte[1024]; DatagramPacket receivePacket new DatagramPacket(receiveData, receiveData.length); serverSocket.receive(receivePacket); // 从数据报中提取客户端地址和端口用于回送响应 InetAddress clientIP receivePacket.getAddress(); int clientPort receivePacket.getPort();这段代码的逻辑是服务器在 6428 端口监听任何客户端发来的 UDP 段只要目的端口是 6428都会进入这个套接字。receive()方法阻塞等待数据报到达收到后通过getAddress()和getPort()拿到客户端的返回地址。参数上DatagramSocket(6428)中的 6428 是服务器绑定的本地端口客户端发送时目的端口必须填这个值。常见做法是服务器用固定端口客户端用系统自动分配的临时端口。2.3 TCP 分解四元组标识套接字TCP 套接字由四元组标识源 IP 地址 源端口号 目的 IP 地址 目的端口号。接收主机用这四个值把段定向到正确的套接字。PPT 里特别强调了一个场景Web 服务器对每个连接都有不同的套接字。非持久 HTTP 每个请求都新建连接所以每个请求对应不同的套接字持久 HTTP 则复用同一个连接。多线程 Web 服务器会为每个新连接创建新线程和新套接字这就是为什么四元组是必要的——如果只用目的 IP 和目的端口多个客户端同时访问同一个 80 端口服务器就分不清哪个段属于哪个连接了。提示UDP 的二元组分解意味着如果两个客户端用相同的源端口向同一个服务器端口发数据服务器回送时只能根据数据报里的源地址和源端口来区分。TCP 的四元组则天然支持多客户端并发连接同一服务端口。3. UDP 协议无连接传输的报文格式、校验和与适用场景3.1 UDP 为什么存在没有不必要的只有基本要素UDP 被 PPT 称为“没有不必要的只有基本要素”的互联网传输协议。它不做握手、不维护连接状态、不保证可靠交付、不做拥塞控制。这些“缺失”恰恰是它的优势DNS 查询只需要一个请求一个响应建立连接的开销比查询本身还大流式多媒体能容忍丢包但不能容忍时延UDP 的“尽力而为”反而更合适。PPT 里列了 UDP 的典型应用DNS、SNMP、流式多媒体、实时游戏。这些场景的共同点是要么请求-响应模式极简要么对时延敏感而对可靠性要求不高。3.2 UDP 报文段格式与校验和计算UDP 报文段格式很简单源端口号16 位、目的端口号16 位、长度16 位包括首部和数据、校验和16 位、应用数据。校验和的计算方法是把段内容按 16 位分组做反码求和最高位的进位回卷加到最低位。PPT 给了一个具体例子两个 16 位整数相加 1111 0011 0011 0011 1110 1010 1010 1010 1101 1101 1101 1101 (回卷进位) 和的反码 0010 0010 0010 0010 (校验和)接收方把收到的段重新做一次反码求和如果结果全是 1说明没有检测到差错。注意校验和只能检测比特翻转不能纠正也不能保证绝对可靠——如果两个比特同时翻转且恰好抵消校验和就查不出来。常见做法是对可靠性要求高的应用在应用层自己做重传和确认比如 QUIC 协议就是在 UDP 之上实现了可靠传输。3.3 UDP 端口测试与调试实际工作中排查 UDP 问题常用nc或iperf3做端口连通性测试。比如# 在服务器端监听 UDP 9999 端口 nc -u -l 9999 # 在客户端发送 UDP 数据包 echo hello | nc -u 服务器IP 9999 # 用 iperf3 做 UDP 打流测试带宽 10M持续 10 秒 iperf3 -c 服务器IP -u -b 10M -t 10nc -u -l中的-u指定 UDP 模式-l表示监听。iperf3的-u指定 UDP-b指定目标带宽-t指定持续时间。UDP 打流测试能直观看到丢包率和抖动这是 TCP 测试看不到的。如果发现 UDP 丢包严重先查网络中间设备是否限速再查接收端缓冲区是否太小。4. 可靠数据传输原理从 rdt1 到 rdt3 的演进与流水线协议4.1 rdt 协议为什么一步步变复杂PPT 把可靠数据传输原理放在运输层核心位置因为它是“网络主题中最重要的 10 个之一”。rdt 的演进逻辑是信道越来越不可靠协议越来越复杂。rdt1.0 假设信道完全可靠发送方直接发接收方直接收。rdt2.0 引入比特差错发送方需要等待确认ACK或否认NAK收到 NAK 就重传。rdt2.1 解决 ACK/NAK 本身出错的问题给数据包加序号发送方收到重复 ACK 时知道接收方没收到新包。rdt2.2 去掉 NAK只用 ACK 加序号。rdt3.0 引入超时重传因为数据包可能丢失不能无限等待。4.2 流水线协议回退 N 帧与选择重传rdt3.0 是停等协议发一个包等一个确认效率极低。PPT 引出流水线协议发送方可以连续发多个包不用等每个包的确认。回退 N 帧Go-Back-N和选择重传Selective Repeat是两种典型实现。回退 N 帧的接收方只按序接收如果收到乱序包就丢弃发送方超时后重传从丢失包开始的所有包。选择重传的接收方有缓冲区可以接收乱序包发送方只重传真正丢失的包。PPT 里用窗口大小来区分回退 N 帧的发送窗口大于 1接收窗口等于 1选择重传的发送窗口和接收窗口都大于 1。# 回退 N 帧发送方伪代码 base 1 # 窗口基序号 next_seq 1 # 下一个待发序号 N 4 # 窗口大小 while True: if next_seq base N: send_packet(next_seq) next_seq 1 if timeout(base): # 超时重传从 base 开始的所有已发未确认包 for seq in range(base, next_seq): send_packet(seq) if receive_ack(seq) and seq base: base seq 1这段伪代码的核心参数是N窗口大小和base窗口基序号。next_seq base N控制发送窗口不溢出超时后重传base到next_seq之间的所有包这就是“回退 N 帧”名字的由来。选择重传则只需要重传超时的那个包但接收方要维护缓冲区来暂存乱序到达的包。注意回退 N 帧在丢包率高时性能急剧下降因为一个包丢失会导致后续所有包重传。选择重传效率更高但实现复杂度也更高。TCP 实际使用的是选择确认SACK机制介于两者之间。5. TCP 连接管理与拥塞控制三次握手、流量控制和吞吐量模型5.1 TCP 三次握手与四次挥手PPT 里 TCP 部分从连接管理讲起。三次握手的本质是双方交换初始序号确认对方收发能力正常。第一次客户端发 SYN第二次服务器回 SYNACK第三次客户端回 ACK。为什么不是两次因为如果客户端第一个 SYN 在网络中滞留超时后重发服务器收到重发的 SYN 后建立连接但客户端可能已经放弃。两次握手会让服务器单方面认为连接已建立浪费资源。四次挥手是因为 TCP 是全双工的每个方向需要单独关闭。# 查看当前 TCP 连接状态 ss -tan # 查看 TCP 拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 查看 TCP 发送和接收缓冲区大小 sysctl net.ipv4.tcp_wmem net.ipv4.tcp_rmemss -tan列出所有 TCP 连接及其状态-t表示 TCP-a表示所有-n表示不解析服务名。sysctl net.ipv4.tcp_congestion_control查看当前拥塞控制算法常见值有 cubic、reno、bbr。tcp_wmem和tcp_rmem分别控制发送和接收缓冲区调大缓冲区能提升高带宽高时延场景的吞吐量。5.2 TCP 流量控制与拥塞控制流量控制是接收方通过接收窗口rwnd告诉发送方自己还能收多少数据防止接收方缓冲区溢出。拥塞控制是发送方根据网络状况调整发送速率防止网络过载。PPT 里讲了 TCP 拥塞控制的几个阶段慢启动、拥塞避免、快速重传、快速恢复。慢启动阶段拥塞窗口指数增长到达阈值后进入拥塞避免线性增长。收到三个重复 ACK 时快速重传不等待超时。超时则拥塞窗口降为 1重新慢启动。5.3 TCP 吞吐量与公平性PPT 给出了 TCP 吞吐量的时延模型吞吐量 ≈ 窗口大小 / 往返时间。这意味着在长肥管道高带宽高时延中要提升吞吐量必须增大窗口。TCP 公平性指的是多个 TCP 连接共享同一瓶颈链路时每个连接最终能获得大致相等的带宽。但 UDP 流不参与拥塞控制会挤占 TCP 的带宽这是流媒体和 TCP 流量共存时常见的问题。机制作用关键参数流量控制防止接收方缓冲区溢出rwnd接收窗口拥塞控制防止网络过载cwnd拥塞窗口、ssthresh慢启动快速探测可用带宽cwnd 指数增长拥塞避免稳定利用带宽cwnd 线性增长快速重传减少重传延迟三个重复 ACK6. 把 PPT 用出效果复习路径、实验对照和几个容易翻车的地方6.1 复习路径从应用层需求倒推运输层设计这份 PPT 的章节顺序本身就是一条复习路径先看 3.1 运输层服务理解运输层为应用层提供什么再看 3.2 复用与分解理解端到端通信怎么落到进程然后 3.3 UDP 和 3.5 TCP 对比两种协议的设计取舍3.4 可靠数据传输原理是理解 TCP 的基础3.6 和 3.7 拥塞控制是运输层最复杂的部分。我一般会建议按这个顺序过一遍每看完一节问自己一个问题如果去掉这个机制会发生什么比如去掉序号会怎样去掉超时重传会怎样。这种“反事实推演”比死记硬背有效得多。6.2 实验对照用 ss、iperf3 和 tcpdump 验证 PPT 里的机制PPT 讲的是原理实际验证要靠工具。用ss -tan看连接状态能直观看到三次握手后的 ESTABLISHED 状态和四次挥手后的 TIME_WAIT 状态。用iperf3做 TCP 和 UDP 打流对比能直观感受拥塞控制对吞吐量的影响。用tcpdump抓包能看到 SYN、SYNACK、ACK 的实际报文# 抓取 80 端口的 TCP 包只抓前 20 个 tcpdump -i eth0 -c 20 tcp port 80 # 抓取 UDP 9999 端口的包 tcpdump -i eth0 udp port 9999 # 用 iperf3 做 TCP 打流持续 30 秒 iperf3 -c 服务器IP -t 30tcpdump -i eth0指定网卡-c 20限制抓包数量tcp port 80是过滤表达式。抓包后能看到 TCP 首部里的序号、确认号、窗口大小对照 PPT 里的报文段结构图理解会深很多。6.3 几个容易翻车的地方第一个坑把 UDP 校验和当成可靠保证。校验和只能检测比特翻转不能检测丢包和乱序更不能保证交付。第二个坑认为 TCP 三次握手是为了“确认双方在线”。三次握手的核心是交换初始序号确认双方收发能力不是简单的“在线检测”。第三个坑混淆流量控制和拥塞控制。流量控制是接收方驱动的拥塞控制是发送方根据网络状况驱动的两者独立但协同。第四个坑以为回退 N 帧和选择重传只是窗口大小不同。两者的接收方行为完全不同回退 N 帧接收方丢弃乱序包选择重传接收方缓存乱序包。第五个坑忽略 TIME_WAIT 状态。主动关闭方进入 TIME_WAIT 等待 2MSL是为了确保最后一个 ACK 能到达对方如果不等旧连接的延迟包可能干扰新连接。6.4 一个具体技巧用 Wireshark 对照 PPT 看三次握手如果你想把 PPT 里的 TCP 报文段结构和实际抓包对应起来最直接的方法是用 Wireshark 抓一次本地回环的 HTTP 请求。启动 Wireshark选择回环接口过滤tcp.port 80然后在浏览器访问一个 HTTP 网站。你会看到 SYN、SYNACK、ACK 三个包展开 TCP 首部对照 PPT 里的字段源端口、目的端口、序号、确认号、窗口大小、校验和。重点看序号的变化SYN 包的序号是初始序号SYNACK 包的确认号是初始序号1ACK 包的序号是初始序号1确认号是服务器初始序号1。这个对照过程比看十遍 PPT 都管用。从那以后我每次复习运输层都会先抓一次包把 PPT 里的字段和实际报文对一遍再去看协议演进逻辑。希望帮到你。本文还有配套的精品资源点击获取