附录3:本章的无背景乐的视频

官方信息技术老师·11 页·深入(追求细节与边界)·0 次浏览·3 天前
传输层TCP/UDP状态机时序图

附录3:本章的无背景乐的

看清 TCP 与 UDP 的状态机、握手挥手时序与每一个设计取舍

按 空格/→ 演示下一步

1 / 11 页

全部页面点击任意一页,跳回舞台从这页播放

传输层TCP/UDP状态机时序图

附录3:本章的无背景乐的

看清 TCP 与 UDP 的状态机、握手挥手时序与每一个设计取舍

1第 1 页 · 附录3:本章的无背景乐的

传输层概念

你电脑上同时开着浏览器、微信、游戏——它们共用一个网卡,却互不串扰。是谁把每个数据包准确地交给了正确的程序?

端到端进程通信
在主机内部的进程之间建立数据通道,是传输层的根本使命
端口与套接字
端口号标识进程,IP+端口(套接字)唯一定位一次通信的两端
复用与分用
多个进程共享同一网络连接,发送合路、到达按端口分发给对应进程
可靠传输机制
面向连接时提供确认、重传、排序、流量与拥塞控制;无连接时只管发
两大代表协议
TCP 可靠面向连接,UDP 不可靠无连接,二者各擅胜场而非优劣
快递公司把包裹送到大楼对应 →IP送到主机,传输层送到进程

IP 层只认大楼地址,传输层才把包裹放到具体工位

2第 2 页 · 传输层概念

通信模型

你点「发送」把微信发给朋友,从手指离开屏幕到对方手机弹出消息,中间走过了一整套「编码—搬运—解码」的流水线。这条流水线就是通信模型。

五个功能部件
信源、发送器、信道、接收器、信宿——信息从产生到抵达要走的五个角色
噪声源
传输过程可能引入的干扰或差错,理论上可作用于任一部件
三种通信方向
单工:单向;半双工:双向但不可同时;全双工:双向同时进行
与网络的映射
信源/信宿=两端进程;发送/接收器=协议栈+网卡;信道=物理链路
寄一封信对应 →通信模型五部件

写信=信源;信封+邮戳=发送器;邮路=信道;拆信封=接收器;收信人=信宿

3第 3 页 · 通信模型

数据段

上一节我们聊过传输层的位置和通信模型,但「它实际搬运什么」还没拆开。这页就来拆:传输层搬运数据的最小单位——段。

段的定义
传输层协议数据单元(PDU),由头部和数据载荷组成
端口号
标识源/目的应用进程,实现多路复用与分解
TCP vs UDP
TCP 段含序列号/确认号等控制字段,UDP 段仅 8 字节头部
MSS 边界
最大段长度约 1460 字节,受网络层 MTU 1500 限制
封装位置
段被作为载荷装入 IP 数据报,由网络层继续转发
快递包裹对应 →传输层数据段

快递单=头部(含端口号),包裹=数据载荷,快递车=IP 数据报

4第 4 页 · 数据段

TCP三次握手建立连接

TCP三次握手建立连接:定义、要点与典型应用

TCP三次握手建立连接
TCP三次握手建立连接:定义、要点与典型应用
5第 5 页 · TCP三次握手建立连接

TCP连接释放

三次握手让两端都准备好收发数据。现在要把通话结束掉——双方都要独立告别,因为TCP支持半关闭,没法像建立时那样把SYN和ACK合并。

四次挥手
FIN→ACK→FIN→ACK,主动方先发起关闭,被动方再关闭
FIN 标志
表示「我这方向的数据发完了」,与建立时的SYN相对应
半关闭
一方发FIN后仍能接收,另一方向关闭即可
TIME_WAIT
主动方等 2MSL(约2-4分钟),保证最后ACK到达
为何不能合并
释放两端独立,各端FIN到ACK不能像建立那样合并
电话两端说再见对应 →TCP 四次挥手

A说「我挂了」B答「好」;B说「我也挂了」A答「好」。两边独立告别,不能并成一句

6第 6 页 · TCP连接释放

TCP传输策略

连接握手成功,可以开始发数据了。发方和收方隔着一条看不见的网络——发太快收方被淹没,发太猛网络堵车。TCP传输策略解决的就是:在「不压垮对端」和「不压垮链路」之间动态拿捏发送节奏。

滑动窗口
接收方在ACK中通告剩余缓冲区,发送方据此约束未确认的飞行字节数
拥塞控制
发送方维护拥塞窗口cwnd,慢启动→拥塞避免→快重传→快恢复四阶段试探网络承载
取小窗口生效
两个机制独立运行,互不知情;实际发送上限 = min(接收窗口, 拥塞窗口)
Nagle算法
把多次小写入合并成一个数据段再发送,减少网络中大量小包和对应ACK
高速公路车流对应 →流量控制+拥塞控制

收费站放行速度对应接收窗口,道路承载对应拥塞窗口,实际车流由瓶颈段决定,与TCP完全同构

Snd.WND=min(Rcv.WND,Cng.WND)\text{Snd.WND} = \min(\text{Rcv.WND}, \text{Cng.WND})
7第 7 页 · TCP传输策略

TCP拥塞控制

前面讲了连接怎么建、数据怎么送。但路上车一多就堵——网络也一样,需要拥塞控制防止链路被压垮。

拥塞窗口 cwnd
发送方估计的网络可承载飞行中的数据量上限
慢启动
cwnd初始小,每RTT指数翻倍,直到达阈值ssthresh
拥塞避免
cwnd过阈值后每RTT只线性加1 MSS,谨慎试探
丢包响应
超时则cwnd重置为1;三重复ACK触发快重传与快恢复
高速公路车流调度对应 →TCP拥塞控制

慢启动≈匝道并入;拥塞避免≈限速匀速;丢包≈事故后快速疏导恢复

8第 8 页 · TCP拥塞控制

TCP定时器等

前面讲了三次握手、传输策略、拥塞控制——但TCP能稳定工作,背后还有一组"闹钟"在默默计时。这就是TCP的四大定时器。

重传定时器
未收到ACK则超时重传,是TCP可靠性的基石
坚持定时器
接收方窗口为0时,发送方周期性探测窗口是否恢复
保活定时器
连接长时间空闲时探测对端是否仍存活
2MSL定时器
主动关闭方等待2倍MSL,确保最后ACK能到达
手机的闹钟与待办对应 →TCP的多个定时器

不同闹钟管不同事——起床/吃药/回消息,对应TCP里重传/窗口/存活等场景

RTO=SRTT+max(G, 4×RTTVAR)RTO = SRTT + \max(G,\ 4 \times RTTVAR)
9第 9 页 · TCP定时器等

本节要点

  • 可靠五件套:连接、序号、重传、流/拥控、定时器
  • 三次握手防过期、四次挥手保残段——本质都在同步初始序号
  • 流控看接收方、拥控看网络,点对点 ≠ 全局
  • TCP 定时器 = 状态机兜底:超时/持续/保活/2MSL
  • TCP vs UDP 是可靠与时延的工程权衡,无绝对优劣
延伸主题:UDP 与 QUIC 的取舍现代拥塞控制 BBR 原理TCP 队头阻塞与 HTTP/3
10第 10 页 · 本节要点

课后思考

先独立想一会儿,再翻看参考答案;卡住了就回到对应章节复习。

1为什么TCP建立连接需要三次握手,两次行不行?

参考答案两次握手无法同时确认双方的收发能力。旧失效请求若到达服务器,还会建立错误连接并浪费资源。

2网络中段突然丢包率飙升,TCP的重传和拥塞控制会怎样相互影响?

参考答案重传增多加剧拥塞,拥塞窗口收缩又触发更多重传,形成恶性循环,可能演变为拥塞崩溃。

3既然TCP能保证可靠传输,为什么实时视频直播通常选择UDP?

参考答案实时场景更看重时效。TCP的重传与拥塞控制会引入延迟,宁可丢帧也不愿卡顿,UDP更契合。

11第 11 页 · 课后思考