【计算机网络】传输层 | Forrest’s 博客

type

status

date

slug

summary

TCP & UDP区别

连接

服务对象

可靠性：TCP能保证不乱、不丢、不错、按序到达。UDP是尽力而为服务，不保证服务的可靠交付

拥塞控制、流量控制

首部开销（报文格式）：TCP的首部较长最小为20字节，如果由【选项】字段会变长。UDP首部为8字节，且为定长，开销小

传输方式：TCP是流式传输，没有边界，但保证顺序和可靠；UDP是一个包一个包的传输，是有边界的，但可能出现丢包和乱序

使用场景

tcp适合可靠性传输要求强的场景

数据库连接
文件传输
web浏览

udp适合实时性要求强的场景

在线游戏
音视频传输
DNS查询
DHCP服务

UDP数据格式

UDP是一种无连接的、尽力而为的传输层协议

报文可能出现重复、失序、丢失

支持一对一、一对多、多对一、多对多的交互通信

UDP首部只有8字节（源端口、目的端口、UDP总长度、校验和各16位）

DNS、DHCP、TFTP使用的是UDP

TCP数据格式

面向连接、可靠的、基于字节流的传输层协议；保证数据的不丢、不乱、有序

拥塞控制、流量控制、有序传输

序列号：连接建立时由计算机生成的随机数，通过sync报文传给接收端主机，每发送一次数据，就【累加】一次该数据字节数的大小。用来解决网络包乱序的问题

确认应答号：指下一次【期望】收到的数据的序列号。发送端收到这个确认应答后，可以确认这个序列以前的数据都已经被正确接受。用来解决丢包的问题

控制位

ACK：确认应答
RST：TCP连接出现异常，需要强制断开连接
SYN：希望建立连接
FIN：表示连接断开

TCP三次握手

一开始，客户端和服务端都处于close状态，先是服务端处于某个端口监听，处于listen状态

客户端随机初始化client_isn ，将此序列号设置与 TCP首部的【序列号】字段中，将syn设置为1，发送syn报文给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于syn-sent状态

服务端收到客户端的SYN报文后，首先服务器也随机初始化主机的server_isn，将序号填入TCP首部【序号】；将确认应答号设置为client_isn+1；把syn+ack设置为1；服务端处于sync-recveid

客户端收到服务端报文后，还要向服务端发送一个应答报文；将TCP首部的ACK设置为1，【确认应答号】设置为server_isn+1；客户端处于established状态

服务端收到客户端的应答报文后，进入established状态

为什么需要三次握手来建立连接

三次握手可以阻止重复的历史连接的初始化，避免资源浪费

三次握手可以同步双方的初始化序列号

TCP四次挥手

客户端主动调用关闭连接的函数，于是会发送FIN报文，代表客户端不会再发送数据了，进入FIN_Wait_1 状态

服务端收到FIN报文，马上回复ACK确认报文，此时服务端进入close_wait状态

服务端确认数据发送结束后，客户端发送FIN报文，进入last_ack状态

客户端收到服务端的FIN报文后，发送ACK报文给服务端，客户端进入Time_wait 状态

服务端收到后，进入close状态

客户端经过2MSL之后，进入close状态

为什么四次挥手后需要等待2MSL

MSL(max segment lifeTime)报文最大生存时间，这是任何报文在网络上存活最长时间，超过这个时间的报文会被丢失。TCP报文基于IP协议，IP头中有一个TTL字段，是IP数据包可以经过的最长路由数

确保所有报文段都已经从网络中消失，防止旧的报文段干扰新的连接

确保对方成功接受到客户端发的ACK；如果服务器没有收到这个ACK报文，它会重新发送FIN报文。客户端在TIME_WAIT期间可以再次发送ACK报文，以确保服务器能够正常关闭连接。

如何保证可靠传输

连接管理：三次握手和四次挥手，来保证可靠的连接以及数据的完整传输

序列号：使用序列号来保证数据的顺序，用来解决网络包乱序的问题

确认应答：接收方节后到数据之后，会回传ACK报文，保卫呢中带有此次确认的序列号，用于发送方此次接收的情况。在指定时间内未收到ACK，就会启动超时重传

超时重传：发送方设置定时器，如果超过定时器时间，发送方会重新发送

流量控制：通过滑动窗口来进行流量控制

拥塞控制：通过算法如慢启动、拥塞避免、快重传、快恢复等，来感知网络阻塞情况，控制发送速率，防止网络阻塞

TCP流量控制

流量控制是用来解决「接收端处理不过来」问题，防止“接收端”被压垮

TCP 使用 接收窗口（rwnd, receiver window） 来限制发送方的速度：

接收端根据自己内核缓冲区剩余空间动态调整 rwnd

发送方必须按 rwnd 限速

当缓冲区满 → rwnd = 0 → 发送方暂停发送

本质：接收端告诉发送端“我吃不下了，停一停”

TCP拥塞控制

拥塞控制是用来解决网络整体拥挤的问题；网络过载（丢包、延迟变大）怎么办？

TCP利用拥塞控制来动态调整发送速率，以适应当前网络阻塞情况，从而减少丢包和延迟，提高数据传输效率

慢启动：cwnd从1开始逐步增长，直到达到ssthresh。

拥塞避免：cwnd达到ssthresh后，进入线性增长。

快速重传：通过重复ACK来触发丢包的重传。

快速恢复不同算法逻辑不通

项目	Reno	CUBIC（Linux 默认）	BBR（Google）
拥塞判断依据	丢包	丢包	带宽 + RTT（不依赖丢包）
增长方式	加性增大（线性）	三次函数增长（更快）	主动探测最佳发送速率
恢复方式	丢包后 cwnd 减半	丢包后下降较少，快速恢复	基于带宽估计调整，不做剧烈下降
适应网络类型	低带宽、低延迟网络	高带宽、高延迟网络（现代互联网）	各类网络均适合，尤其是高带宽
吞吐量表现	一般	较高	极高
延迟表现	中等	中等偏高	很低（不会因积压导致缓冲膨胀）
优点	简单、经典、兼容性好	现代互联网主流，恢复快	高吞吐、低延迟，不依赖丢包
缺点	高带宽场景下利用不充分	仍依赖丢包，会造成不必要降速	RTT 会波动，对路由器 buffer 敏感
是否利用全部可用带宽	否	相对好	最好（主动追踪瓶颈带宽）

真正发送量 = min(rwnd, cwnd)

TCP 粘包

TCP 粘包是因为 TCP 是流式协议，没有消息边界，导致多个消息在接收端被合并读到。解决方式通常是固定长度、分隔符，或最常见的消息头+消息体方案。

📌【计算机网络】传输层