我做了好几年服务端性能排查频繁遇到过一类场景高峰期接口突然变慢、连接建立失败、客户端报超时可CPU、内存、带宽看着都挺正常。查到最后问题往往不在业务代码而是卡在TCP握手这个最基础的环节上。说白了三次握手太常被当成“理所当然的规矩”很少有人真的去看内核为这次握手干了什么活、排了哪些队、丢了多少包。这篇东西我想把TCP握手的底层路径拆开讲一遍并顺手带出Linux上完整的观测方法和调优参数让你下次再遇到类似问题能从“猜”变成“查”。内容虽然偏底层但不需要你有多深的网络背景只要会点Linux命令、看得懂基本的socket概念就够了。搞服务端开发、运维、SRE或者研究高性能网关的人都应该花时间把这块补上。1. 握手到底在握什么从三次消息说起1.1 三次握手不只是“确认双方在线”很多人对TCP握手的第一印象就是“三次握手建立连接”。这没问题但我们要往前再走一步三次握手本质上是一次能力协商和状态同步的过程而不只是一次“你好在吗”的确认。第一次握手客户端发出SYN服务端如果愿意建立连接就回一个SYNACK。这里服务端干了两件事一是告诉客户端“你的SYN我收到了”二是同时把自己的初始序列号一起发给对方。第三方收到SYNACK之后再回一个ACK给服务端双方连接进入ESTABLISHED状态。关键点在于每台机器发出的TCP段都带一个32位序列号。握手阶段交换的信息之一就是让对方知道自己的序列号起点是多少。因为后续每个字节的数据都要用序列号来编号、确认、排序、去重如果双方对起点没有共同认知后续的数据传输根本没办法进行。握手还顺带协商了双方窗口大小、是否启用SACK等选项也是在这个阶段完成的。我经常用生活化的例子来帮助理解类似两个人初次见面互相握手的同时把自己手里各自拿着的那本空白笔记本给对方看一眼约定“我这边从第1页开始记你那边也从第1页开始记后面我们往本子上写的东西会对得上号”。三次握手保证的是双方不仅知道“对面有个人”而且知道“我们的记录规则是一致的”。1.2 序列号、时间戳和其他容易忽略的细节握手报文里带的东西远比想象多。只看包的时候你会发现每个TCP头部除了SYN、ACK标志位之外还有一大串选项字段。这些字段在握手阶段就决定了连接后续的行为模式。序列号Sequence Number初始序列号不是从0开始的。现代Linux内核采用随机化初始序列号这是为了避免序列号预测攻击、防止同一连接的旧包串扰。时间戳TCP Timestamp很多内核参数依赖它比如tcp_timestamps开启后可以用来计算RTT也可以配合PAWS防止超老包带来数据污染。窗口缩放因子Window Scale)如果不协商这个选项TCP最大窗口只能到64KB。高带宽长链路下如果不开启吞吐量会被死死压住。选择性确认SACK允许接收方告知发送方“我丢了哪些不连续的段”避免只依赖累计ACK导致重传过多数据。所以我建议你在看握手问题时不要只盯三个包的来回还要看握手时双方交换了什么选项。很多时候“连接很慢”的谜底其实藏在选项组合不匹配里。比如客户端开启了窗口缩放但对端不响应这时候有效窗口就受限了。你可以在抓包里看到这些选项字段确认双方到底协商出了什么结果。与其说这是“三次握手”不如说它是一次完整的参数握手会议——所有连接级的能力都在这个阶段敲定。提示在实际项目中判断“握手是否有问题”技巧之一是看握手阶段包之间的时间间隔。如果SYN发出后几百毫秒甚至上秒才收到SYNACK基本可以确定中间某处发生了重传或丢包光看状态机是发现不了这种延迟的。2. 走进内核握手在内核协议栈中的真实路径2.1 socket从listen开始就不一样了应用层用socket、bind、listen、accept这一套标准接口启动服务但在内核里listen操作远不是把端口打开那么简单。当进程调用listen(fd, backlog)时内核会针对这个监听socket建立两个独立的连接队列一个用来放还没完成握手的“半连接”一个用来放握手完成、等待应用accept的“全连接”。这两个队列非常关键。很多线上问题本质就是其中一个队列满了导致新连接被直接丢弃或表现异常。我见过不少团队在排查连接失败时盯着iptables、安全组查了半天最后拿ss一看才发现是Accept队列溢出丢包。在Linux内核源码4.x及之后版本中实际情况是收到SYN后如果当前半连接队列没满就创建一个inet_request_sock对象放入半连接队列回复SYNACK。收到对方最后一个ACK后握手完成内核把这个连接从半连接队列摘出来移入全连接队列。应用调用accept()时从全连接队列取一个已完成握手的连接出来分配一个真正的socket fd交给进程。2.2 backlog、somaxconn与队列大小的真实关系历史包袱在这里体现得非常明显。listen的backlog参数初衷是限制全连接队列的大小但不同内核版本、不同操作系统对它的解释不一样。Linux上的实际规则是全连接队列的长度约等于min(backlog, net.core.somaxconn)默认somaxconn是4096低版本是128。很多应用没设backlog或者框架里沿用了一个很老的默认值结果全连接队列被默默限制在128。一旦并发连接稍微上来一点全连接队列溢出内核开始丢弃握手的最后那个ACK客户端看着“连接超时”而服务端日志里什么都没有。这种情况非常隐蔽。半连接队列的最大长度由net.ipv4.tcp_max_syn_backlog控制但它最终能有多大还和tcp_syncookies是否开启、内存等有关系。一个比较容易理解的近似公式是如果启用了syncookies半连接队列可以动态变化如果没启用它的上限受tcp_max_syn_backlog与内核内部hash表大小共同影响。2.3 SYN Cookie队列满时的救命机制半连接队列满时内核不会坐以待毙。只要开启了net.ipv4.tcp_syncookies默认就是1内核就会进入一种“无状态”的握手模式它不在半连接队列里为这个SYN保存任何记录而是把该连接的关键信息加密编码成一个cookie塞进SYNACK的序列号里回给客户端。当收到最后的ACK时再把这个cookie解码验证如果合法就直接建立连接。用这个机制能把半连接队列满导致的SYN丢弃问题大大缓解。但要注意syncookies是解决“SYN洪水”的手段不是性能优化的万能药。因为握手完成后如果全连接队列也满了连接还是会失败另外启用syncookies时有些TCP选项可能无法完整协商比如窗口缩放部分场景下会受限。所以它看起来是“救命机制”实际代价也在暗处。注意如果服务端启用了syncookies在netstat或某些工具里处于SYN_RECV状态的连接可能会极少甚至没有因为真正的排队根本没发生。千万不要因为看到SYN_RECV为0就判断“没有握手问题”。3. 观测TCP握手从命令行到抓包全景3.1 ss先看队列溢出再看连接状态系统里最常用的Socket观测命令是ss它通过读取内核的socket诊断信息比netstat更直接而且能看到netstat给不出的统计项。我排查握手问题时第一步永远是先看监听socket的Send-Q和Recv-Q。在ss -lnt输出中对于LISTEN状态的socketRecv-Q表示当前全连接队列里已经存在但还没被accept的已建立连接数量Send-Q表示全连接队列的最大容量。这两个数字一旦变得相等说明队列已经满了后续握手完成的连接会被内核丢弃。有一个专门计数器可以佐证这个行为/proc/net/netstat中ListenOverflows字段每次全连接队列溢出都会加一。想看它就用cat /proc/net/netstat | awk /TcpExt:/ {print $21}这个ListenOverflows是排查“客户端超时但服务端进程日志一切正常”的第一手证据。我建议监控系统里一定要把这条指标加上它比什么应用层错误率都更早反映问题。再来ss -s可以查看全系统TCP连接的总量统计ss -s侧面观察TIME_WAIT数量也有助于判断短连接场景是否过于严重。虽然这不算握手但大量TIME_WAIT累积会占用内存和端口资源间接拖慢新连接的建立。3.2 tcpdump把握手全过程在报文级别摊开要真正看懂握手抓包是绕不过去的一步。tcpdump命令本身不复杂复杂的是怎么读包。以80端口为例tcpdump -i any tcp port 80 -nn -S -tttt-nn代表不做域名和端口反解-S显示绝对序列号-tttt让时间戳精确到微秒级别。重点看三个包第一包 Client → ServerSYN标志位置位Seq是客户端初始序列号。第二包 Server → ClientSYNACK同时置位Ack回应第一包的Seq1同时给出服务端自己的初始序列号。第三包 Client → ServerACK标志位置位Ack回应第二包的Seq1。如果只抓到第一包和第三包没有第二包大概率是服务端在收到SYN后没能及时回复这时要去查半连接队列、SYN cookie配置和内核是否丢弃了SYN。如果只抓到第一包那可能是中间网络问题也可能是服务端根本没收到。关于序列号在抓包里看初始序列号要注意别被tcpdump“相对序列号”显示误导。默认tcpdump为了可读性显示相对值计算相对值时会拿当前包序列号减握手的初始序列号。加-S显示绝对序列号之后你能直接看到客户端的ISN是随机变化的大整数这正是Linux随机化初始序列号的体现。3.3 nstat与计数器从内核统计里找答案除了ss和tcpdump系统自带一个很有用的命令叫nstat它把内核网络统计输出成类似SNMP的键值对非常适合脚本采集。直接运行nstat -az | grep -E Tcp|Listen|Sync其中值得关注的有TcpPassiveOpens服务端收到SYN并进入SYN_RCVD的次数。TcpAttemptFails连接建立失败的次数。TcpExtListenOverflows全连接队列溢出的次数。TcpExtListenDrops处于监听状态时因各种原因丢弃的SYN或ACK包数量。TcpExtSyncookiesSent开启了syncookies后发出的SYNACK cookie数量。这套计数器就是Linux关于TCP连接的内核体检表。通过对比它们的增量可以判断出SYN到底有没有进来、有没有排队、有没有溢出、有没有被丢弃。比如听任Overflows持续增长说明全连接队列长期饱和需要加accept的消费速度或扩大somaxconn如果SyncookiesSent疯狂增长说明半连接队列都在吃紧可能是SYN洪峰或半连接长期滞留。3.4 进阶用BPF工具观察握手内部耗时常规命令能看到宏观状态但看不到“时间花在哪”。如果某个环节特别慢想搞清楚是内核排队慢还是应用accept慢可以尝试BPF类的火焰图分析工具。以BCC工具包为例其中的tcpaccept工具可以追踪到accept发生时内核栈的执行时间。用bpftrace自己挂一个kprobe也能查看listen socket接收SYN时的日志处理时间。我实际会先看/proc/net/stat或跑一个简单的ss -lnt看队列是否积压再决定要不要上BPF。如果队列没积压但握手还是慢那么应该在网络路径上追。很多时候最费时间的并不是内核处理而是从服务器网卡到应用进程之间的流控、软中断以及锁竞争。BPF工具能帮助把这段盲区补上。实操心得软中断分发不均也会导致握手性能下降。当你的服务用多队列网卡时可以在网卡上启用Receive Packet SteeringRPS让各CPU分摊收包软中断。我遇到过单核软中断打满、其余核心空闲的案例开启RPS后握手能力翻了一倍不止。观测时可以用top看si列哪一列的si常年高企哪个CPU就成了瓶颈。4. 调优实战从参数到方案的组合拳4.1 核心内核参数逐个说清下面这些参数是我在调优Linux TCP握手时的常用集合。注意不同内核版本默认值会有变化修改前先对着自己系统的文档核一遍。net.core.somaxconn全局全连接队列上限。很多框架自己会设置listen backlog但超过这个值会被截断。建议明确调大比如设为65535。同时应用侧listen的backlog参数也要同步调大两边取最小值才生效。net.ipv4.tcp_max_syn_backlog半连接队列上限。在syncookies开启时它仍会影响行为。一般高并发服务建议从默认的1024或2048调整到16384以上。net.ipv4.tcp_syncookies默认1建议保持开启。它在半连接队列满时启用无状态握手但也别把它当作“防洪水”的唯一方案更要在应用层、防火墙层协同处理。net.ipv4.tcp_syn_retriesSYN重传次数。默认通常为6意味着对端不回应时客户端会重试多次整个过程可能持续一分钟以上。内部服务之间可以下调到3或甚至2让失败快速暴露避免业务线程长时间卡在connect上。net.ipv4.tcp_synack_retries服务端对SYNACK的重传次数。同样可以适当下调尤其是快速失败场景。net.ipv4.tcp_tw_reuse旧代码中经常推荐开启这个来复用TIME_WAIT连接但现代内核里对它的行为有严格限制。结论是在客户端做连接时开它有用服务端开它意义不大Newer kernnelle还可能有安全隐患。建议不要无脑开。net.ipv4.tcp_fastopenTCP Fast Open可以让客户端在SYN时直接携带数据省掉一次RTT。需要客户端和服务端同时支持且业务形态适合比如反复建连的短请求。默认通常是3enable on listener and client测试后可以按需调整。修改参数通常用sysctl完成sysctl -w net.core.somaxconn65535 sysctl -w net.ipv4.tcp_max_syn_backlog16384为了让重启后也保持生效写入/etc/sysctl.conf然后sysctl -p加载。4.2 高并发短连接场景的调优顺序短连接高并发是最典型的握手压力场景比如网关、鉴权服务、消息推送等。这类服务的特点是每秒新建立连接量极大握手消耗成了核心矛盾。我建议的调优顺序是先观测用ss看当前队列大小和积压用nstat看Overflows和Drops增长。调应用层backlog应用代码里listen()的backlog写大方常见框架比如Nginx有backlog配置项Java的ServerSocket要显式传参别用默认值。调内核层somaxconn把net.core.somaxconn设成和应用层同步例如65535。检查半连接队列tcp_max_syn_backlog适当放大但这部分内存消耗不大不用太担心。开启/确认syncookies默认1确认自己没有把它设成0。评估是否需要TCP Fast Open如果只是普通HTTP短连接Fast Open未必有明显收益但某些内部长RT服务会很受用。如果单核软中断高启用RPS等中断均衡手段让收包负载分散。最后再反向检查一遍全链接队列是否还在溢出。如果仍然溢出要看应用accept是不是阻塞了。进程里某个线程卡在慢查询导致不调用accept连接就会堆在队列里。这是应用层问题调内核参数字符串没用。4.3 该不该开syncookies什么时候关我见过一些“调优文档”建议把syncookies设为0理由是可以开启更大的半连接队列、避免某些TCP选项丢失。这个说法有一定道理但对于大多数互联网服务我不建议关。原因是一旦流量突然冲高、受到SYN风暴影响syncookies是最后的兜底它的成本远比整个服务拒绝新连接小。如果做的是受控内网服务且流量特征稳定、端口不对外暴露可以考虑关闭syncookies换取完整特性协商。但是要用监控先保证半连接队列永远不会满否则一个突发就能让你全线崩溃。注意tcp_syncookies设为2时表示仅在SYN队列满了才启用设为1时表示一直可用但不强制设为0表示禁止。Linux默认通常是1。在没有充分监控和压测依据的情况下不要轻易改成0。5. 常见问题与排查技巧实录5.1 客户端connect超时服务端进程毫无压力这是最让人头大的“幽灵问题”之一。排查路径一般按照这四步走在服务端执行ss -lnt看Recv-Q是否已经等于Send-Q。查/proc/net/netstat中的ListenOverflows看是否存在持续增长。用抓包看是否能抓到客户端的SYN和服务端的SYNACK。如果能抓到SYNACK说明只是最后的ACK没被处理全连接队列问题连SYNACK都没有多半是半连接队列或防火墙问题。看服务端进程是否还活着监听。可以用ss -lntp确认进程绑定状态。我踩过的一个典型坑是服务端程序内部用了一个连接池但因为某个线程池满了accept后建立的连接没人处理应用表现为“假死”内核 echter全连接队列溢出。优化方向是解决应用内部线程模型而不是加内核参数。5.2 握手完成但HTTP请求迟迟开始如果三次握手都完成了但客户端发出第一个HTTP请求后服务端迟迟没响应那问题往往不在握手而在全连接队列之后的应用调度。比如请求了太多线程竞争锁、连接没有及时分发到工作线程。这种情况在观测时你需要区分从tcpdump看SYN、SYNACK、ACK三个包是连续的、时差很小但从ACK之后到四个数据包出现之间有很长时间的空白。这段空白就是“内核握手之后、进程开始处理之前”的等待属于应用瓶颈。5.3 握手非常快但数据传输很慢另外一个容易被误判为“握手问题”的场景握手包都挺正常但后续数据包RTO重传频繁。此时要做的是检查丢包率、窗口大小以及拥塞控制算法。TCP握手表现好只说明连接建立路径没毛病数据传输慢可能是MTU问题、路径拥塞或小包合并策略Nagle导致。调优方向完全不一样。5.4 观察不到的坑防火墙状态表溢出很多线上服务会在云环境里同时配安全组、装iptables。即使内核本身工作正常netfilter的conntrack表满了以后新连接也会被静默丢弃。因为conntrack表的默认上限往往不小但面对极高的短连接速率时容易被耗尽。此时内核日志或dmesg里会出现nf_conntrack: table full的提示ss -s里也能看到连接数并不多。解决方法是调大nf_conntrack_max或者缩减防火墙规则必要时按业务只放行必要端口。5.5 排查工具速查表现象优先命令关注点连接超时ss -lntRecv-Q是否等于Send-Q队列溢出/proc/net/netstat、nstatListenOverflows、ListenDrops握手内部耗时tcpdump BPF工具包间隔时间、内核调用栈全系统连接统计ss -s各状态总量、TIME_WAIT量防火墙丢弃dmesg、conntrack -Sconntrack table full、计数器增长5.6 最后再分享一个小技巧调优TCP握手我建议大家养成“先量化、再调整、再量化”的习惯。不要一上来就堆参数。每次改之前记录ss的队列状态和nstat的计数器改完之后再采集一次对比增量。因为很多参数之间存在制约关系比如你把somaxconn调大到65535但是应用的accept线程不够队列只会积压得更深看起来“调好了”实际更糟。另外内核文档和各发行版默认值有差异我在某个版本上验证过的值换到另一个版本后会重新确认避免被旧经验带偏。这部分的排查经验我在好几个线上项目里反复验证过。说到底TCP握手的性能问题没有那么多玄学把队列、计数器、抓包这三样工具用好大多数问题都能有清晰答案。剩下的就是用你的业务特征去匹配参数组合。 
长河君 · 2026/10/19 4:17:51 · 阅读 1.2k TCP三次握手内核路径解读：队列观测与调优实战
我做了好几年服务端性能排查频繁遇到过一类场景高峰期接口突然变慢、连接建立失败、客户端报超时可CPU、内存、带宽看着都挺正常。查到最后问题往往不在业务代码而是卡在TCP握手这个最基础的环节上。说白了三次握手太常被当成“理所当然的规矩”很少有人真的去看内核为这次握手干了什么活、排了哪些队、丢了多少包。这篇东西我想把TCP握手的底层路径拆开讲一遍并顺手带出Linux上完整的观测方法和调优参数让你下次再遇到类似问题能从“猜”变成“查”。内容虽然偏底层但不需要你有多深的网络背景只要会点Linux命令、看得懂基本的socket概念就够了。搞服务端开发、运维、SRE或者研究高性能网关的人都应该花时间把这块补上。1. 握手到底在握什么从三次消息说起1.1 三次握手不只是“确认双方在线”很多人对TCP握手的第一印象就是“三次握手建立连接”。这没问题但我们要往前再走一步三次握手本质上是一次能力协商和状态同步的过程而不只是一次“你好在吗”的确认。第一次握手客户端发出SYN服务端如果愿意建立连接就回一个SYNACK。这里服务端干了两件事一是告诉客户端“你的SYN我收到了”二是同时把自己的初始序列号一起发给对方。第三方收到SYNACK之后再回一个ACK给服务端双方连接进入ESTABLISHED状态。关键点在于每台机器发出的TCP段都带一个32位序列号。握手阶段交换的信息之一就是让对方知道自己的序列号起点是多少。因为后续每个字节的数据都要用序列号来编号、确认、排序、去重如果双方对起点没有共同认知后续的数据传输根本没办法进行。握手还顺带协商了双方窗口大小、是否启用SACK等选项也是在这个阶段完成的。我经常用生活化的例子来帮助理解类似两个人初次见面互相握手的同时把自己手里各自拿着的那本空白笔记本给对方看一眼约定“我这边从第1页开始记你那边也从第1页开始记后面我们往本子上写的东西会对得上号”。三次握手保证的是双方不仅知道“对面有个人”而且知道“我们的记录规则是一致的”。1.2 序列号、时间戳和其他容易忽略的细节握手报文里带的东西远比想象多。只看包的时候你会发现每个TCP头部除了SYN、ACK标志位之外还有一大串选项字段。这些字段在握手阶段就决定了连接后续的行为模式。序列号Sequence Number初始序列号不是从0开始的。现代Linux内核采用随机化初始序列号这是为了避免序列号预测攻击、防止同一连接的旧包串扰。时间戳TCP Timestamp很多内核参数依赖它比如tcp_timestamps开启后可以用来计算RTT也可以配合PAWS防止超老包带来数据污染。窗口缩放因子Window Scale)如果不协商这个选项TCP最大窗口只能到64KB。高带宽长链路下如果不开启吞吐量会被死死压住。选择性确认SACK允许接收方告知发送方“我丢了哪些不连续的段”避免只依赖累计ACK导致重传过多数据。所以我建议你在看握手问题时不要只盯三个包的来回还要看握手时双方交换了什么选项。很多时候“连接很慢”的谜底其实藏在选项组合不匹配里。比如客户端开启了窗口缩放但对端不响应这时候有效窗口就受限了。你可以在抓包里看到这些选项字段确认双方到底协商出了什么结果。与其说这是“三次握手”不如说它是一次完整的参数握手会议——所有连接级的能力都在这个阶段敲定。提示在实际项目中判断“握手是否有问题”技巧之一是看握手阶段包之间的时间间隔。如果SYN发出后几百毫秒甚至上秒才收到SYNACK基本可以确定中间某处发生了重传或丢包光看状态机是发现不了这种延迟的。2. 走进内核握手在内核协议栈中的真实路径2.1 socket从listen开始就不一样了应用层用socket、bind、listen、accept这一套标准接口启动服务但在内核里listen操作远不是把端口打开那么简单。当进程调用listen(fd, backlog)时内核会针对这个监听socket建立两个独立的连接队列一个用来放还没完成握手的“半连接”一个用来放握手完成、等待应用accept的“全连接”。这两个队列非常关键。很多线上问题本质就是其中一个队列满了导致新连接被直接丢弃或表现异常。我见过不少团队在排查连接失败时盯着iptables、安全组查了半天最后拿ss一看才发现是Accept队列溢出丢包。在Linux内核源码4.x及之后版本中实际情况是收到SYN后如果当前半连接队列没满就创建一个inet_request_sock对象放入半连接队列回复SYNACK。收到对方最后一个ACK后握手完成内核把这个连接从半连接队列摘出来移入全连接队列。应用调用accept()时从全连接队列取一个已完成握手的连接出来分配一个真正的socket fd交给进程。2.2 backlog、somaxconn与队列大小的真实关系历史包袱在这里体现得非常明显。listen的backlog参数初衷是限制全连接队列的大小但不同内核版本、不同操作系统对它的解释不一样。Linux上的实际规则是全连接队列的长度约等于min(backlog, net.core.somaxconn)默认somaxconn是4096低版本是128。很多应用没设backlog或者框架里沿用了一个很老的默认值结果全连接队列被默默限制在128。一旦并发连接稍微上来一点全连接队列溢出内核开始丢弃握手的最后那个ACK客户端看着“连接超时”而服务端日志里什么都没有。这种情况非常隐蔽。半连接队列的最大长度由net.ipv4.tcp_max_syn_backlog控制但它最终能有多大还和tcp_syncookies是否开启、内存等有关系。一个比较容易理解的近似公式是如果启用了syncookies半连接队列可以动态变化如果没启用它的上限受tcp_max_syn_backlog与内核内部hash表大小共同影响。2.3 SYN Cookie队列满时的救命机制半连接队列满时内核不会坐以待毙。只要开启了net.ipv4.tcp_syncookies默认就是1内核就会进入一种“无状态”的握手模式它不在半连接队列里为这个SYN保存任何记录而是把该连接的关键信息加密编码成一个cookie塞进SYNACK的序列号里回给客户端。当收到最后的ACK时再把这个cookie解码验证如果合法就直接建立连接。用这个机制能把半连接队列满导致的SYN丢弃问题大大缓解。但要注意syncookies是解决“SYN洪水”的手段不是性能优化的万能药。因为握手完成后如果全连接队列也满了连接还是会失败另外启用syncookies时有些TCP选项可能无法完整协商比如窗口缩放部分场景下会受限。所以它看起来是“救命机制”实际代价也在暗处。注意如果服务端启用了syncookies在netstat或某些工具里处于SYN_RECV状态的连接可能会极少甚至没有因为真正的排队根本没发生。千万不要因为看到SYN_RECV为0就判断“没有握手问题”。3. 观测TCP握手从命令行到抓包全景3.1 ss先看队列溢出再看连接状态系统里最常用的Socket观测命令是ss它通过读取内核的socket诊断信息比netstat更直接而且能看到netstat给不出的统计项。我排查握手问题时第一步永远是先看监听socket的Send-Q和Recv-Q。在ss -lnt输出中对于LISTEN状态的socketRecv-Q表示当前全连接队列里已经存在但还没被accept的已建立连接数量Send-Q表示全连接队列的最大容量。这两个数字一旦变得相等说明队列已经满了后续握手完成的连接会被内核丢弃。有一个专门计数器可以佐证这个行为/proc/net/netstat中ListenOverflows字段每次全连接队列溢出都会加一。想看它就用cat /proc/net/netstat | awk /TcpExt:/ {print $21}这个ListenOverflows是排查“客户端超时但服务端进程日志一切正常”的第一手证据。我建议监控系统里一定要把这条指标加上它比什么应用层错误率都更早反映问题。再来ss -s可以查看全系统TCP连接的总量统计ss -s侧面观察TIME_WAIT数量也有助于判断短连接场景是否过于严重。虽然这不算握手但大量TIME_WAIT累积会占用内存和端口资源间接拖慢新连接的建立。3.2 tcpdump把握手全过程在报文级别摊开要真正看懂握手抓包是绕不过去的一步。tcpdump命令本身不复杂复杂的是怎么读包。以80端口为例tcpdump -i any tcp port 80 -nn -S -tttt-nn代表不做域名和端口反解-S显示绝对序列号-tttt让时间戳精确到微秒级别。重点看三个包第一包 Client → ServerSYN标志位置位Seq是客户端初始序列号。第二包 Server → ClientSYNACK同时置位Ack回应第一包的Seq1同时给出服务端自己的初始序列号。第三包 Client → ServerACK标志位置位Ack回应第二包的Seq1。如果只抓到第一包和第三包没有第二包大概率是服务端在收到SYN后没能及时回复这时要去查半连接队列、SYN cookie配置和内核是否丢弃了SYN。如果只抓到第一包那可能是中间网络问题也可能是服务端根本没收到。关于序列号在抓包里看初始序列号要注意别被tcpdump“相对序列号”显示误导。默认tcpdump为了可读性显示相对值计算相对值时会拿当前包序列号减握手的初始序列号。加-S显示绝对序列号之后你能直接看到客户端的ISN是随机变化的大整数这正是Linux随机化初始序列号的体现。3.3 nstat与计数器从内核统计里找答案除了ss和tcpdump系统自带一个很有用的命令叫nstat它把内核网络统计输出成类似SNMP的键值对非常适合脚本采集。直接运行nstat -az | grep -E Tcp|Listen|Sync其中值得关注的有TcpPassiveOpens服务端收到SYN并进入SYN_RCVD的次数。TcpAttemptFails连接建立失败的次数。TcpExtListenOverflows全连接队列溢出的次数。TcpExtListenDrops处于监听状态时因各种原因丢弃的SYN或ACK包数量。TcpExtSyncookiesSent开启了syncookies后发出的SYNACK cookie数量。这套计数器就是Linux关于TCP连接的内核体检表。通过对比它们的增量可以判断出SYN到底有没有进来、有没有排队、有没有溢出、有没有被丢弃。比如听任Overflows持续增长说明全连接队列长期饱和需要加accept的消费速度或扩大somaxconn如果SyncookiesSent疯狂增长说明半连接队列都在吃紧可能是SYN洪峰或半连接长期滞留。3.4 进阶用BPF工具观察握手内部耗时常规命令能看到宏观状态但看不到“时间花在哪”。如果某个环节特别慢想搞清楚是内核排队慢还是应用accept慢可以尝试BPF类的火焰图分析工具。以BCC工具包为例其中的tcpaccept工具可以追踪到accept发生时内核栈的执行时间。用bpftrace自己挂一个kprobe也能查看listen socket接收SYN时的日志处理时间。我实际会先看/proc/net/stat或跑一个简单的ss -lnt看队列是否积压再决定要不要上BPF。如果队列没积压但握手还是慢那么应该在网络路径上追。很多时候最费时间的并不是内核处理而是从服务器网卡到应用进程之间的流控、软中断以及锁竞争。BPF工具能帮助把这段盲区补上。实操心得软中断分发不均也会导致握手性能下降。当你的服务用多队列网卡时可以在网卡上启用Receive Packet SteeringRPS让各CPU分摊收包软中断。我遇到过单核软中断打满、其余核心空闲的案例开启RPS后握手能力翻了一倍不止。观测时可以用top看si列哪一列的si常年高企哪个CPU就成了瓶颈。4. 调优实战从参数到方案的组合拳4.1 核心内核参数逐个说清下面这些参数是我在调优Linux TCP握手时的常用集合。注意不同内核版本默认值会有变化修改前先对着自己系统的文档核一遍。net.core.somaxconn全局全连接队列上限。很多框架自己会设置listen backlog但超过这个值会被截断。建议明确调大比如设为65535。同时应用侧listen的backlog参数也要同步调大两边取最小值才生效。net.ipv4.tcp_max_syn_backlog半连接队列上限。在syncookies开启时它仍会影响行为。一般高并发服务建议从默认的1024或2048调整到16384以上。net.ipv4.tcp_syncookies默认1建议保持开启。它在半连接队列满时启用无状态握手但也别把它当作“防洪水”的唯一方案更要在应用层、防火墙层协同处理。net.ipv4.tcp_syn_retriesSYN重传次数。默认通常为6意味着对端不回应时客户端会重试多次整个过程可能持续一分钟以上。内部服务之间可以下调到3或甚至2让失败快速暴露避免业务线程长时间卡在connect上。net.ipv4.tcp_synack_retries服务端对SYNACK的重传次数。同样可以适当下调尤其是快速失败场景。net.ipv4.tcp_tw_reuse旧代码中经常推荐开启这个来复用TIME_WAIT连接但现代内核里对它的行为有严格限制。结论是在客户端做连接时开它有用服务端开它意义不大Newer kernnelle还可能有安全隐患。建议不要无脑开。net.ipv4.tcp_fastopenTCP Fast Open可以让客户端在SYN时直接携带数据省掉一次RTT。需要客户端和服务端同时支持且业务形态适合比如反复建连的短请求。默认通常是3enable on listener and client测试后可以按需调整。修改参数通常用sysctl完成sysctl -w net.core.somaxconn65535 sysctl -w net.ipv4.tcp_max_syn_backlog16384为了让重启后也保持生效写入/etc/sysctl.conf然后sysctl -p加载。4.2 高并发短连接场景的调优顺序短连接高并发是最典型的握手压力场景比如网关、鉴权服务、消息推送等。这类服务的特点是每秒新建立连接量极大握手消耗成了核心矛盾。我建议的调优顺序是先观测用ss看当前队列大小和积压用nstat看Overflows和Drops增长。调应用层backlog应用代码里listen()的backlog写大方常见框架比如Nginx有backlog配置项Java的ServerSocket要显式传参别用默认值。调内核层somaxconn把net.core.somaxconn设成和应用层同步例如65535。检查半连接队列tcp_max_syn_backlog适当放大但这部分内存消耗不大不用太担心。开启/确认syncookies默认1确认自己没有把它设成0。评估是否需要TCP Fast Open如果只是普通HTTP短连接Fast Open未必有明显收益但某些内部长RT服务会很受用。如果单核软中断高启用RPS等中断均衡手段让收包负载分散。最后再反向检查一遍全链接队列是否还在溢出。如果仍然溢出要看应用accept是不是阻塞了。进程里某个线程卡在慢查询导致不调用accept连接就会堆在队列里。这是应用层问题调内核参数字符串没用。4.3 该不该开syncookies什么时候关我见过一些“调优文档”建议把syncookies设为0理由是可以开启更大的半连接队列、避免某些TCP选项丢失。这个说法有一定道理但对于大多数互联网服务我不建议关。原因是一旦流量突然冲高、受到SYN风暴影响syncookies是最后的兜底它的成本远比整个服务拒绝新连接小。如果做的是受控内网服务且流量特征稳定、端口不对外暴露可以考虑关闭syncookies换取完整特性协商。但是要用监控先保证半连接队列永远不会满否则一个突发就能让你全线崩溃。注意tcp_syncookies设为2时表示仅在SYN队列满了才启用设为1时表示一直可用但不强制设为0表示禁止。Linux默认通常是1。在没有充分监控和压测依据的情况下不要轻易改成0。5. 常见问题与排查技巧实录5.1 客户端connect超时服务端进程毫无压力这是最让人头大的“幽灵问题”之一。排查路径一般按照这四步走在服务端执行ss -lnt看Recv-Q是否已经等于Send-Q。查/proc/net/netstat中的ListenOverflows看是否存在持续增长。用抓包看是否能抓到客户端的SYN和服务端的SYNACK。如果能抓到SYNACK说明只是最后的ACK没被处理全连接队列问题连SYNACK都没有多半是半连接队列或防火墙问题。看服务端进程是否还活着监听。可以用ss -lntp确认进程绑定状态。我踩过的一个典型坑是服务端程序内部用了一个连接池但因为某个线程池满了accept后建立的连接没人处理应用表现为“假死”内核 echter全连接队列溢出。优化方向是解决应用内部线程模型而不是加内核参数。5.2 握手完成但HTTP请求迟迟开始如果三次握手都完成了但客户端发出第一个HTTP请求后服务端迟迟没响应那问题往往不在握手而在全连接队列之后的应用调度。比如请求了太多线程竞争锁、连接没有及时分发到工作线程。这种情况在观测时你需要区分从tcpdump看SYN、SYNACK、ACK三个包是连续的、时差很小但从ACK之后到四个数据包出现之间有很长时间的空白。这段空白就是“内核握手之后、进程开始处理之前”的等待属于应用瓶颈。5.3 握手非常快但数据传输很慢另外一个容易被误判为“握手问题”的场景握手包都挺正常但后续数据包RTO重传频繁。此时要做的是检查丢包率、窗口大小以及拥塞控制算法。TCP握手表现好只说明连接建立路径没毛病数据传输慢可能是MTU问题、路径拥塞或小包合并策略Nagle导致。调优方向完全不一样。5.4 观察不到的坑防火墙状态表溢出很多线上服务会在云环境里同时配安全组、装iptables。即使内核本身工作正常netfilter的conntrack表满了以后新连接也会被静默丢弃。因为conntrack表的默认上限往往不小但面对极高的短连接速率时容易被耗尽。此时内核日志或dmesg里会出现nf_conntrack: table full的提示ss -s里也能看到连接数并不多。解决方法是调大nf_conntrack_max或者缩减防火墙规则必要时按业务只放行必要端口。5.5 排查工具速查表现象优先命令关注点连接超时ss -lntRecv-Q是否等于Send-Q队列溢出/proc/net/netstat、nstatListenOverflows、ListenDrops握手内部耗时tcpdump BPF工具包间隔时间、内核调用栈全系统连接统计ss -s各状态总量、TIME_WAIT量防火墙丢弃dmesg、conntrack -Sconntrack table full、计数器增长5.6 最后再分享一个小技巧调优TCP握手我建议大家养成“先量化、再调整、再量化”的习惯。不要一上来就堆参数。每次改之前记录ss的队列状态和nstat的计数器改完之后再采集一次对比增量。因为很多参数之间存在制约关系比如你把somaxconn调大到65535但是应用的accept线程不够队列只会积压得更深看起来“调好了”实际更糟。另外内核文档和各发行版默认值有差异我在某个版本上验证过的值换到另一个版本后会重新确认避免被旧经验带偏。这部分的排查经验我在好几个线上项目里反复验证过。说到底TCP握手的性能问题没有那么多玄学把队列、计数器、抓包这三样工具用好大多数问题都能有清晰答案。剩下的就是用你的业务特征去匹配参数组合。