同样是发数据，为什么要分 TCP 和 UDP

上一课说传输层负责「进程到进程」的通信。这一层有两个主角：TCP（传输控制协议）和 UDP（用户数据报协议）。你每天用的网页、HTTPS 接口、文件下载几乎都走 TCP；而域名解析、视频通话、直播、在线游戏大量用 UDP。它们的差别不是「谁更先进」，而是在「可靠」和「快、简单」之间做了不同取舍。理解这个取舍，你才看得懂连接为什么慢、弱网为什么转圈、流式输出为什么那样设计。

TCP：用一套复杂机制，换「可靠且有序」

IP 层只负责把数据包尽力发出去，不保证不丢、不保证顺序、不保证不重复。TCP 在其上建立了一套承诺：数据无差错、不丢失、不重复、按发送顺序到达，这叫面向连接的、可靠的字节流。它靠几块基石实现：

TCP 可靠性的四块基石序列号 ：给每个字节编号，接收方据此排序、发现丢包确认ACK ：接收方告诉发送方「我连续收到哪了」超时重传：发出去一段时间没收到 ACK，就认为丢了、重发一遍流量/拥塞控制：根据接收方能力和网络拥堵程度动态调整发送速度，避免把网络压垮

代价是额外开销：建立连接要握手、每个包带序号和确认、丢包要等待重传。所以 TCP 适合「一个字节都不能错」的场景——网页、API、文件、数据库连接；不适合「宁可丢一两帧也不能卡」的实时语音。

三次握手：为什么偏偏是三次，两次不行吗

TCP 是面向连接的，传数据前要先在双方之间建立连接，这个建立过程固定是三次报文，俗称三次握手：

关键问题：为什么不能两次？因为建立连接要确认两件事——双方各自的「发送能力」和「接收能力」都正常，并且要让双方都同步好彼此的初始序列号。第 1 次客户端证明自己能发；第 2 次服务器证明自己能收也能发；第 3 次客户端再确认自己能收到服务器的回应。少了第三次，服务器无法确认客户端是否真的收到了自己的同步信号；更重要的是，网络中可能滞留一个早已过期的连接请求，两次握手会让服务器仅凭这个旧请求就白白建立连接，三次握手则让客户端在第三次有机会否决它。三次，是确认双向通道全通所需的最少次数。

四次挥手与 TIME_WAIT：断开为什么反而更麻烦

TCP 是全双工的——两个方向可以独立收发数据，所以关闭时两个方向要分别关闭，通常需要四次报文：

第 2 次的 ACK 和第 3 次的 FIN 之所以分开，是因为收到对方「我发完了」时，自己这边可能还有没发完的数据，要先发 ACK 应付着、等数据发完再发 FIN。主动关闭的一方发完最后一个 ACK 后会进入 TIME_WAIT，停留约 2MSL（最长报文寿命的两倍）才彻底释放，目的有二：确保最后的 ACK 万一丢失还能重发、让本次连接在网络中残留的旧报文自然消亡，避免它们污染下一条复用同一端口的新连接。部署启示：频繁重启的服务可能因 TIME_WAIT 占用而一时无法重新绑定端口，服务器程序通常会开启 SO_REUSEADDR（地址复用）来缓解。

UDP：为了快和简单，主动放弃可靠

UDP 走另一个极端：无连接（不握手、挥挥手就发）、不保证到达、不保证顺序、没有拥塞控制，每个数据报独立、头部极小（只有 8 字节）。它把「要不要重传、要不要排序」的自由交还给应用自己。正因为省去了握手和重传等待，UDP 延迟极低，适合「实时性比完整性更重要」的场景：

这些原理如何影响 App 的真实网络体验

传输层不是面试题，它直接决定你接口该怎么设计。第一，握手有成本，所以不要每个请求都新建连接：HTTP 的 keep-alive 让一条 TCP 连接承载多个请求，后端到后端、后端到数据库则用连接池复用。第二，弱网下 TCP 的超时重传会表现为「转圈很久」，因此客户端要设合理的超时与可重试机制，且重试接口必须幂等（同一请求重复执行结果不变）。第三，像大模型逐字输出、TTS 流式播放这种「边生成边返回」的场景，朋友好学用的是 SSE（Server-Sent Events）：它建立一条长连接（跑在 TCP 上），服务器生成一点推一点，而不是让用户干等整段生成完——这正是利用了 TCP 有序字节流的特性。

本节小结

传输层在 IP 之上做进程到进程通信。TCP 面向连接、可靠有序，靠序列号、ACK、超时重传、流量与拥塞控制实现，适合网页/API/文件，代价是握手与重传开销；三次握手同步双方序号、确认双向能力并防旧连接，是最少次数；四次挥手因全双工需双向分别关闭，主动方 TIME_WAIT 停留 2MSL 以保证可靠关闭、消散旧报文，频繁重启的服务需 SO_REUSEADDR。UDP 无连接、不保证可靠有序、头部极小、延迟低，适合 DNS、音视频、游戏，HTTP/3 的 QUIC 基于 UDP 自建可靠与加密。工程上映射为：keep-alive/连接池减少握手、接口幂等以容忍重传、SSE 长连接实现大模型与 TTS 的流式返回。