【网络基石】从三次握手到 HTTP/3：深度拆解 TCP/UDP 传输奥秘

摘要网络传输是所有互联网应用的根基。无论你是 Android 开发还是后端架构理解协议底层逻辑是排查网络超时、优化加载速度的必备技能。本文将带你从物理层比特流出发一路向上深度剖析 TCP 的可靠性机制、三握四挥的防御设计以及 HTTP/3 颠覆性转向 UDP 的底层逻辑。一、 网络分层数据的“套娃”艺术在网络世界中数据的传输并非瞬间移动而是一个层层包裹与拆解的“套娃”过程。1. 从 OSI 七层到 TCP/IP 五层虽然 OSI 七层模型是学术上的标准但工业界普遍采用的是TCP/IP 五层模型。这种分层设计的核心目的在于解耦底层不关心上层传的是网页还是视频上层不关心底层走的是光纤还是 WiFi。应用层HTTP/DNS/FTP这是数据的“出厂地”。它定义了数据的格式。传输层TCP/UDP进程间通信的守门人。它最重要的工作是给数据打上“端口号Port”确保数据能准确送达某个 App如 80 端口给浏览器8080 给后端服务。网络层IP地理寻址导航。它不负责传输只负责规划路径。它给数据包贴上源 IP 和目的 IP像快递单上的地址。数据链路层以太网/MAC跳板传输。它负责在相邻的两个网络节点如你的电脑和路由器之间搬运比特流识别的是物理地址MAC。物理层电信号、光信号的物理载体。2. 数据包的封装与解封装当你发送一个“Hello”请求时应用层加上 HTTP Header。传输层加上 TCP Header包含序列号、端口。网络层加上 IP Header。链路层加上帧头和帧尾。最终原本的“Hello”变成了一个复杂的比特序列在光缆中穿梭。二、 TCP如何保证“绝对可靠”的传输TCP传输控制协议被形象地称为“面向连接的、可靠的、基于字节流”的协议。它的可靠性并非天生而是靠一套极其复杂的确认机制“堆”出来的。1. 三次握手不仅仅是打招呼三次握手的核心意义在于同步序列号ISN并确认双方的收发能力。第一次握手SYN客户端发送SYN包并带上初始序列号 $x$。此时客户端处于SYN_SENT状态。证明客户端具有发送能力。第二次握手SYN ACK服务端返回ACKx1和自己的SYN序列号 $y$。此时服务端处于SYN_RCVD状态。证明服务端具有接收能力且发能力也正常。第三次握手ACK客户端发送ACKy1。证明客户端确认了服务端的发能力至此双方“达成共识”。面试必杀技为什么不是两次假设是两次。客户端发送第一个 SYN 因网络阻塞没到于是重发了第二个。任务结束后第一个 SYN 突然到了服务端服务端以为是新连接并返回 ACK。如果是两次握手连接此时已建立服务端会一直空等客户端发数据导致资源死锁与浪费。2. 四次挥手为什么不能“三步走”TCP 是全双工的这意味着 A 停止发数据时B 可能还在发。第一步FIN客户端说“我没数据发了。”进入FIN_WAIT_1。第二步ACK服务端回“收到但我可能还没发完你等会。”进入CLOSE_WAIT。此时客户端进入FIN_WAIT_2。第三步FIN服务端发完最后的数据“我也发完了关了吧。”进入LAST_ACK。第四步ACK客户端回“收到再见。”进入TIME_WAIT。为什么要有 TIME_WAIT2MSL防止最后一个 ACK 丢失如果服务端没收到 ACK会重发 FIN客户端得活着才能重回应答。化解“幽灵包”确保本次连接中所有在网络中游荡的数据包都过期失效防止它们干扰下一个相同端口的连接。3. 拥塞控制网络的“宏观调控”如果网络卡顿TCP 会通过算法自动减速防止网络彻底瘫痪。慢启动Slow Start新连接开始时拥塞窗口cwnd从 1 开始按 $2^n$ 指数增长。拥塞避免Congestion Avoidance到达阈值ssthresh后增长速度变为线性1小心翼翼地探测带宽上限。快重传Fast Retransmit当客户端连续收到 3 个相同的冗余 ACK 时不等超时立刻重传。这被视为网络轻微拥堵的信号。快恢复Fast Recovery丢包后不直接降回 1而是降到一半维持一定的吞吐量。三、 HTTP 演进性能与安全的权衡从 1991 年 HTTP/0.9 到如今的 HTTP/3这其实是一部与延迟Latency作斗争的历史。1. HTTP/1.0 与 1.1从短到长的跨越HTTP/1.0每请求一个资源图片、JS都要重新建立 TCP 连接。**“短连接”**严重浪费了握手时间。HTTP/1.1引入了Keep-Alive长连接。允许在同一个 TCP 连接上发送多个请求。管道化Pipelining问题虽然可以发多个但服务器必须按顺序回。如果第一个请求卡住了后面的全部阻塞这就是**“应用层队头阻塞”**。2. HTTP/2多路复用与二进制分帧HTTP/2 是一个重大的飞跃。它将数据拆分为更小的“帧Frame”并引入了**流Stream**的概念。多路复用在同一个连接里多个请求的帧可以穿插发送。首部压缩HPACK利用哈希表索引大幅减少重复 Header 的体积。Server Push服务器可以主动把 CSS/JS 推送给客户端。痛点未消TCP 队头阻塞HTTP/2 解决了应用层阻塞但底层依然是 TCP。如果一个 TCP 包在传输中丢了整个连接的滑动窗口都会停止等待这个包重传。对于网络环境差的移动端HTTP/2 甚至可能不如 HTTP/1.1 稳定。3. HTTP/3基于 UDP 的 QUIC 革命Google 意识到TCP 是网络性能进一步提升的枷锁。于是HTTP/3 彻底抛弃了 TCP。QUIC 协议在 UDP 之上重新实现了可靠性。0-RTT 建连将 TLS 握手与传输层握手合并首次连接 1-RTT重连 0-RTT。无队头阻塞由于 UDP 是无序的QUIC 在应用层维护流。流 A 丢包流 B 依然可以正常处理。连接迁移Connection MigrationTCP 靠“四元组源IP/端口、目的IP/端口”识别。如果你从 WiFi 切到 4GIP 变了TCP 必断。而 QUIC 使用Connection ID识别即使网络切换连接依然无感保持。四、 实战排查Keep-Alive 与 抓包原理1. 两种 Keep-Alive 的终极对决很多开发者会混淆这两个概念其实它们属于不同的生命周期。特性HTTP Keep-AliveTCP Keep-Alive层级应用层 (HTTP)传输层 (内核)核心目的提高吞吐量减少建连次数存活检测清理僵尸连接场景网页加载、API 请求数据库长连接、Socket 心跳配置Connection: keep-aliveSO_KEEPALIVE2. 抓包工具Charles/Wireshark是如何工作的Wireshark工作在链路层利用网卡驱动的“混杂模式”像个旁观者默默记录所有路过的流量。Charles/Fiddler工作在应用层本质是HTTP 代理服务器。如果你抓的是 HTTPS你需要安装 Charles 的根证书。这其实是一次“合法的中间人攻击”Charles 截获你的请求用自己的证书骗过浏览器再用自己的身份去请求服务器。五、 总结从输入 URL 到页面显示的“全链路之旅”当你按下回车键这篇博客描述的所有知识点都在这一秒内爆发应用层浏览器解析 URL发起DNS 查询UDP 协议。传输层如果是 HTTP/1.1 或 2开始TCP 三次握手如果是 HTTP/3开始QUIC 建连。安全层进行TLS 握手协商加密方案。传输层数据被切割、编号、进入拥塞控制流程通过 IP 路由跨越千山万水。服务端责任链处理OkHttp/Nginx返回 HTML。渲染层浏览器解析 HTML渲染视觉效果。网络协议的进化本质上是人类对“极致速度”与“极致可靠”之间平衡点的不断重塑。作者Li Caijun专注 Android 与底层协议研究如果本文让你对网络有了新的认识欢迎在评论区交流点赞收藏不迷路