握手协议教学工作区 · 课程 0001 · 约 25 分钟 · 前置:无 · 2026-09-24

TCP 三次握手:把一次请求拆成四段

为什么是这一步

使命说这条线是"边缘函数工程师知识树的第一支柱:连接层原理"。 而连接层的第一个动作就是建立连接。大多数人能背出"三次握手",但说不出 "多出来的那一次到底防了什么" —— 这一节用你机器上的真实计时把这件事钉住。

最小知识:三条

1. 三次握手 = SYN → SYN+ACK → ACK。它的目的不是"打招呼",而是双方各自确认两件事: 我能发、你能收;同时交换初始序列号(后面每个字节都要按序号确认,不交换就没法保证顺序与重传)。
2. 为什么不能是两次?如果只发两次,服务端无法确认"客户端收到了我的 SYN+ACK"。 更关键的是:网络上可能有延迟很久的旧连接请求突然到达,服务端会为它建立一条客户端早已忘记的连接(半开)。 第三次 ACK 让服务端只在"客户端确实还在"时才认账。
3. 四段计时的含义(curl 的 -w 变量): time_namelookup DNS 解析 → time_connect TCP 握手完成 → time_appconnect TLS 握手完成 → time_starttransfer 收到第一个字节。 每两段之间的差,就是那一层花的钱。

动手:量一次真实请求

在 Git Bash 里(输出是实测值,来自你这台机器 2026-09-24):

curl -s -o /dev/null -w "dns=%{time_namelookup}s tcp=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s\n" https://example.com
# dns=0.005605s tcp=0.020753s tls=6.684226s ttfb=7.125429s

先读你自己的数字:

• DNS 5.6 ms、TCP 20.8 ms —— 都很快,说明网络到目标站点的往返延迟正常。
• TLS 6.68 秒 —— 这一段明显异常。TCP 已经握手完成(TCP 段才 20ms),说明瓶颈不在网络往返,而在 TLS 协商: 常见原因是流量走了代理、证书链校验慢、或链路在 TLS 阶段被额外转发。这正是这条线要能解释的现象。
• 首字节 7.13 秒 = TLS 完成 + 服务端处理 + 回包。和 TLS 的差只有 0.44 秒 —— 服务端其实很快,钱都花在握手上了。

再看一眼"四次挥手"(顺带):连接关闭时为什么是四次?因为 TCP 是全双工 —— 一方的"我发完了"(FIN)与另一方的"我也发完了"(FIN)是两件独立的事,各自需要一次确认。 而握手可以合并(SYN+ACK 一次搞定),挥手不能。

加一道对比实验:把目标换成你本机的一个服务(比如 curl -w … http://127.0.0.1:8000,若没服务可用 python -m http.server 8000 起一个), 观察四段各自变成多少 —— 你会看到 DNS 与 TCP 都接近 0,这就是"局域网/本机"与"公网 + TLS"的差别。

自测(选项一样长,别从长度上猜)