深入 TCP 核心：握手、挥手、滑动窗口与并发服务器实战
一、 连接的诞生与消亡
1. 三次握手 (The 3-Way Handshake)
发生时机：connect()调用时。
本质：双方确认对方的发送和接收能力正常，并同步初始序列号 (ISN)。
- 第一次：客户端发送
SYN=1, seq=J。（我想连你） - 第二次：服务器回复
SYN=1, ACK=1, ack=J+1, seq=K。（收到，我也想连你） - 第三次：客户端回复
ACK=1, ack=K+1。（收到，连接建立！）
程序表现：当三次握手在内核层面全部完成后，客户端的
connect函数才会返回 0 (成功)。此时双方状态变为ESTABLISHED。
2. 四次挥手 (The 4-Way Wave)
发生时机：close()调用时。
本质：TCP 是全双工的，断开需要双向分别关闭。
- 第一次：主动方发
FIN。（我没数据发了，申请关闭发送通道） - 第二次：被动方回
ACK。（知道了，但我可能还有数据没发完，你先等着）- 此时处于半关闭状态 (Half-Close)。
- 第三次：被动方发
FIN。（我的数据也发完了，申请关闭） - 第四次：主动方回
ACK。（好的，再见）。
为什么是四次？
握手时，服务器的 SYN 和 ACK 可以合并在一个包里发。但在挥手时，服务器收到 FIN 后，可能还需要发送未处理完的数据，所以先回 ACK，等数据发完了再发自己的 FIN。
二、 流量控制的秘密：滑动窗口
在 TCP 头部中有一个字段叫Window。
- 误区：它不是屏幕上的窗口，而是一个数值。
- 本质：告诉我你还能吃多少（接收缓冲区的剩余容量）。
工作机制：
- 接收方在回复 ACK 时，会带上自己的
Win大小。 - 发送方根据这个数值调整发送速度。
- 如果
Win=0，发送方就会停止发送（阻塞），直到窗口变大。
这实现了流量控制，防止发送方把接收方“撑死”。
三、 突破瓶颈：多进程并发服务器
1. 问题背景
我们之前写的服务器是迭代服务器（Iterative Server）：
while(1){accept();// 接一个process();// 处理完}// 才能接下一个如果有客户端连上后一直不说话（挂机），process()就会一直阻塞，导致后续的客户端无法连接。
2. 解决方案：多进程模型
利用fork()创建子进程。
- 父进程：只负责
accept（即“迎宾小姐”），一有客人来就 fork 一个子进程。 - 子进程：负责具体的通信（即“服务员”），服务完一个客人就退出。
3. 代码实战 (tcp_mp_server.c)
为了避免僵尸进程（Zombie Process），我们需要通过信号机制回收子进程。
#include<stdio.h>#include<stdlib.h>#include<unistd.h>#include<string.h>#include<arpa/inet.h>#include<sys/socket.h>#include<signal.h>#include<sys/wa