TCP 连接建立只要三次握手，断开却要四次挥手，比建立还多一步。第一次听说的人都会纳闷：告别怎么比相识还麻烦，代理IP链路里两段连接各自告别岂不是更麻烦？
答案是连接是双向的：建立时一次确认能覆盖两个方向，断开时两个方向却要分别告别。这篇把四次的来龙去脉讲清楚。
连接是双向的，断开也要两边各自来
一条 TCP 连接上，数据可以同时往两个方向流动，这叫全双工。建立连接时，一次确认就能让双方都知道「两个方向都通了」；断开时情况不同——两边不一定同时想结束。
设想你在下载大文件：下载方向数据不断，但你随时可能想关掉上传方向。两个方向的需求不同步，断开就必须拆成两个独立动作，各自完成各自的告别。
四次挥手各是哪四次
第一次：主动方发出结束请求，表示「我不再发数据了」。第二次：被动方确认收到，表示「知道了，你那边可以停了」，但被动方自己的数据可能还没发完。
第三次：被动方把自己要发的数据发完后，也发出结束请求，表示「我这边也发完了」。第四次：主动方确认收到，双方正式断开。
中间隔开的第二次和第三次，就是两个方向各自告别造成的：被动方要先确认、再等自己的数据发完、然后才轮到它告别。这多出来的一步，正是挥手比握手多一次的原因。
挥手在代理IP链路里会发生两次
走代理IP时连接分两段，断开也分两段：本机与转发层之间挥一次手，转发层与目标站之间再挥一次手。某一段先断，另一段会跟着被动关闭，先后顺序取决于谁先发结束请求。
这也是代理IP链路偶尔出现「一边断了另一边还挂着」的原因——两段挥手不一定是同时进行的，中间有时间差。
这种时间差在频繁切换代理IP出口时尤其常见：本机侧挥手先完成，转发层那侧还挂着旧连接等超时。所以切换出口后偶尔看到旧连接残留，不一定是没关干净，可能是另一段挥手还在路上。
挥手状态去哪儿看
挥手过程中的连接状态会经历几个专有名字：主动方进入等待确认、等待对方结束等阶段，被动方也会停在某个状态等最后确认。这些状态名在系统连接列表里能看到，读到它们就知道挥手走到了第几步。
把挥手理解成「两个方向各自的道别」，四次的数字就不难记了：你先说再见、我确认、我说再见、你确认——每一次道别都要被对方确认一次。
理解四次的顺序，再看连接断开时的提示就有帮助：如果程序提示对端主动关闭，说明对方先说了再见；如果程序自己迟迟关不掉连接，多半是卡在等对方确认的那一步，顺着状态名去查最直接。
挥手比握手多一次，是因为断开要照顾两个方向各自的节奏——代理IP链路的两段连接，也各自按这个节奏完成自己的道别。
挥手过程如果被强制打断——比如设备突然断电、链路瞬间中断——双方来不及道别，连接会以异常状态残留，直到系统超时清理。这也是异常退出后立刻重连有时会失败的原因：旧连接的清理还没走完。