1. TCP三次握手与accept机制解析1.1 accept在三次握手后的触发时机在TCP连接建立过程中accept函数调用实际发生在三次握手完成之后。很多初学者容易误解为accept参与握手过程其实它只是从已完成连接的队列中取出连接。具体流程是这样的客户端发送SYN1, seqx服务端回复SYN1, ACK1, seqy, ackx1客户端发送ACK1, seqx1, acky1关键提示服务端内核在完成第三次握手后会将这个连接放入已连接队列(accept队列)此时accept调用才会从队列中取出这个连接。1.2 connect返回与连接确认当客户端调用connect返回成功时确实表示三次握手已经完成。但要注意几个细节服务端的accept队列有长度限制(somaxconn参数)如果队列已满服务端会忽略第三次握手的ACK客户端认为连接已建立但服务端实际未完成连接这种情况需要通过以下方式检测int ret connect(fd, ...); if (ret 0) { // TCP层连接成功 // 但应用层连接可能仍未就绪 }2. TCP握手过程中的数据传输机制2.1 三次握手携带数据规则握手阶段能否携带数据是个常考点握手阶段能否携带数据原因第一次不能防止SYN洪泛攻击第二次不能服务端资源未完全分配第三次能连接已确认安全实际开发中Linux内核通过以下代码控制// 内核源码 net/ipv4/tcp_input.c if (!th-syn) sk-sk_ack_backlog;2.2 安全考量与实现细节为什么前两次不能带数据这主要出于安全考虑内存分配服务端在SYN_RCVD状态需要分配资源攻击防护防止恶意客户端发送大量数据消耗资源状态验证只有完成三次握手才能确认连接可用性3. TIME_WAIT与2MSL机制深度解析3.1 MSL的计算与影响MSL(Maximum Segment Lifetime)默认值在Linux中是60秒$ cat /proc/sys/net/ipv4/tcp_fin_timeout 60等待2MSL(120秒)的原因确保最后一个ACK到达对端(1MSL)确保对端重传的FIN能够到达(1MSL)让网络中所有该连接的包都失效3.2 不等待2MSL的后果如果客户端直接关闭连接会怎样新应用可能收到旧连接的残留数据包服务端重传的FIN会导致RST响应端口快速重用可能导致数据混乱实际案例某电商平台曾因缩短TIME_WAIT导致0.1%的订单数据错乱。4. SYN Flood攻击与防御方案4.1 攻击原理详解SYN Flood利用TCP协议设计缺陷伪造大量源IP发送SYN服务端分配资源进入SYN_RECV状态半连接队列被占满拒绝服务攻击效果指标单个服务器可承受约20万SYN/s分布式攻击可达数百万SYN/s4.2 防御方案对比防御方式原理优缺点增大队列调大syn_backlog延迟问题治标不治本SYN Cookie无状态验证CPU计算开销略高首包丢弃随机丢弃SYN影响正常用户推荐配置# 启用SYN Cookie echo 1 /proc/sys/net/ipv4/tcp_syncookies # 减少SYNACK重试 echo 3 /proc/sys/net/ipv4/tcp_synack_retries5. TCP可靠传输机制实现5.1 序列号回绕问题当32位序列号用完时序列号从0重新开始旧连接的延迟包可能被误认时间戳选项可解决该问题Linux内核处理代码// 内核源码 include/net/tcp.h static inline bool tcp_retransmit_skb(struct sock *sk, struct sk_buff *skb) { if (tcp_skb_timestamp_us(skb) !between(tcp_skb_timestamp_us(skb), tp-retrans_stamp, tcp_time_stamp)) return false; }5.2 Nagle与延迟确认的交互Nagle算法规则立即发送小包(如SSH按键)后续包满足以下条件才发送达到MSS大小收到之前所有ACK延迟确认机制等待200ms合并ACK乱序包立即响应两者组合可能导致40ms延迟变成240ms6. TCP与HTTP的Keep-Alive对比6.1 TCP Keepalive机制检测死连接的三要素# 配置参数(单位秒) net.ipv4.tcp_keepalive_time 7200 net.ipv4.tcp_keepalive_intvl 75 net.ipv4.tcp_keepalive_probes 9工作流程7200秒无数据后发送探测包每隔75秒重试最多尝试9次6.2 HTTP Keep-Alive优化优势对比减少TCP握手开销(3RTT→1RTT)降低服务器SYN队列压力浏览器默认6-8个并发连接配置示例Connection: keep-alive Keep-Alive: timeout5, max10007. 队头阻塞问题与解决方案7.1 TCP层队头阻塞本质原因严格按序交付丢包重传阻塞后续数据Wireshark抓包可见[TCP Retransmission] Seq100 Len1460 [TCP Dup ACK 101#1] Ack1017.2 HTTP层解决方案HTTP/2的多路复用二进制分帧流优先级头部压缩但仍受限于TCP特性这是QUIC协议要解决的问题。8. UDP可靠传输实现方案8.1 类TCP实现方式基本要素class ReliableUDP: def __init__(self): self.send_buffer {} # {seq: (data, timestamp)} self.recv_buffer {} # {seq: data} self.ack_list [] # 待确认的ACK8.2 工程实践建议序列号用64位避免回绕动态RTO计算选择性重传前向纠错(FEC)实际案例某直播平台使用UDP重传机制将延迟从3秒降至800ms。