SRE面试必问：TCP网络问题深度解析与实战应对

1. TCP三次握手：为什么不是两次或四次？

最近在帮团队面试SRE候选人时，发现80%的候选人对TCP三次握手的理解都停留在表面。实际上，大厂面试官最想考察的是你对网络底层原理的掌握程度。让我用一个真实案例来说明：去年我们线上服务突然出现大量连接失败，最终定位到就是因为对三次握手的理解不够深入。

TCP连接建立需要三次握手，本质上是为了解决历史连接和资源浪费两个核心问题。想象这样一个场景：客户端第一次发送的SYN包因为网络延迟，在连接关闭后才到达服务端。如果是两次握手，服务端会直接建立连接，导致资源被无效占用。

具体到Linux内核实现，当服务端收到SYN包时，会创建request_sock结构体存入半连接队列。这个队列的大小由tcp_max_syn_backlog参数控制，如果队列满了就会出现我们常说的SYN Flood攻击。可以通过以下命令查看当前系统的半连接队列状态：

netstat -s | grep -i "SYNs to LISTEN"

2. TCP状态转换中的魔鬼细节

2.1 TIME_WAIT：最容易被误解的状态

在一次故障复盘会上，我们发现某台服务器存在8万个TIME_WAIT连接。很多工程师第一反应是"这肯定有问题"，但其实TIME_WAIT是TCP协议设计的自我保护机制。它的两个核心作用：

1. 确保最后一个ACK能到达对端
2. 让网络中残留的旧报文自然消亡

真正需要警惕的是TIME_WAIT过多导致端口耗尽的情况。这时可以通过调整内核参数来缓解：

# 启用TIME_WAIT快速回收 echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle # 允许TIME_WAIT套接字被重用 echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

不过要注意，在NAT环境下启用tcp_tw_recycle可能导致连接失败，这是很多面试者容易忽略的细节。

2.2 CLOSE_WAIT：排查线上问题的关键指标

CLOSE_WAIT状态过多通常意味着应用层没有正确关闭连接。去年我们遇到一个典型案例：某Java应用CLOSE_WAIT连接持续增长，最终发现是因为没有正确关闭数据库连接。可以通过以下命令快速定位问题：

netstat -antp | grep CLOSE_WAIT | awk '{print $7}' | sort | uniq -c

3. 面试高频问题实战解析

3.1 字节跳动真题：网页访问慢的排查思路

这类问题考察的是系统性思维。我的排查框架通常分为四个层次：

1. 客户端：浏览器缓存、DNS解析
2. 网络层：TCP连接建立时间、丢包率
3. 服务端：请求队列、线程池状态
4. 数据库/缓存：慢查询、连接池

具体到TCP层面，可以用tcpdump抓包分析：

tcpdump -i eth0 -w slow.pcap port 80

然后结合Wireshark分析握手阶段的RTT时间、是否有重传等细节。

3.2 腾讯真题：SYN Flood攻击防御

当半连接队列被塞满时，正常用户就无法建立连接。防御措施包括：

• 启用SYN Cookie：echo 1 > /proc/sys/net/ipv4/tcp_syncookies
• 调整半连接队列大小：sysctl -w net.ipv4.tcp_max_syn_backlog=2048
• 缩短SYN超时时间：sysctl -w net.ipv4.tcp_synack_retries=2

4. 内核参数调优实战

4.1 Keepalive机制配置

TCP Keepalive可以检测死连接，避免占用资源。推荐配置：

# 7200秒（2小时）后开始探测 echo 7200 > /proc/sys/net/ipv4/tcp_keepalive_time # 每隔75秒探测一次 echo 75 > /proc/sys/net/ipv4/tcp_keepalive_intvl # 探测失败重试次数 echo 9 > /proc/sys/net/ipv4/tcp_keepalive_probes

4.2 缓冲区大小调整

根据业务特点调整读写缓冲区：

# 最大读写缓冲区大小 echo "4096 87380 6291456" > /proc/sys/net/ipv4/tcp_rmem echo "4096 16384 4194304" > /proc/sys/net/ipv4/tcp_wmem

在实际项目中，我们发现将初始窗口从10调整为30可以显著提升小文件传输性能，这在CDN场景下特别有效。