从端口到拥塞控制：传输层TCP/UDP核心机制与抓包排障-北京尧图网络

传输层这块内容我前前后后翻过不下五遍每次的感觉都不一样。第一次学的时候满脑子都是“背下来就行”三次握手四次挥手、十一种状态、几个定时器考试能画出来就算过关。等到真正开始写服务端代码、半夜被叫起来看线上连接堆积的时候才发现当年背的那些东西只有落回到端口、序列号、窗口、拥塞控制这几个具体机制上才算是真懂了。这篇就按我自己重新梳理的顺序来讲传输层从端口怎么寻址到 UDP 和 TCP 的取舍再到握手挥手、重传与滑窗、拥塞控制最后落到抓包排障的实操。不管你是刚学完网络分层、还在纠结“为什么握手是三次”的学生还是已经在写后端、被 TIME_WAIT 和粘包折腾过的开发者这篇都能对上号。1. 传输层到底在解决什么问题网络层把包从一台主机送到另一台主机这件事它做得挺好但它交付的是“尽力而为”的报文丢了不赔、乱序不管、重复了也不去重。传输层要做的就是在这条不太靠谱的通道上把“主机到主机”的通信变成“进程到进程”的通信并且按需补上可靠性、有序性、流量控制这些能力。想清楚这一层到底在补什么后面所有机制的存在理由就都顺了。1.1 为什么寻址靠端口而不是进程 ID网络层的 IP 地址只能定位到一台主机可一台机器上同时跑着 Web 服务、数据库、缓存客户端、日志上报包到了网卡之后该交给谁最直觉的想法是用进程 ID反正它唯一标识了一个进程。但 PID 这个方案在实际系统里根本走不通进程重启一次 PID 就变了对端根本没法预先知道同一个服务起多个实例PID 各不相同客户端也没法统一地连更麻烦的是 PID 属于操作系统内部概念把它暴露到网络协议里等于让协议依赖具体操作系统的实现细节。端口本质上是给“服务”而不是给“进程”编的号。一个端口可以被一个进程监听也可以被多个进程共享比如多进程模型里子进程继承监听套接字进程死掉了端口还能被新进程重新绑定。这套间接层让通信双方只需要约定一个稳定的数字剩下的映射交给操作系统维护。真正唯一标识一条连接的不是端口而是五元组源 IP、源端口、目的 IP、目的端口、传输层协议号。这也是为什么同一台机器上两个浏览器标签页去访问同一个站点目的端口都是 443却不会串数据——它们的源端口不同。服务端同理一个监听 8080 的进程能同时处理上万条连接靠的就是用五元组把每条连接区分开。端口号是 16 位范围 0 到 65535按惯例分成三段范围名称说明典型例子0 - 1023知名端口需要特权才能绑定通常由系统服务占用22、80、4431024 - 49151注册端口普通应用使用建议按规范登记避免撞车3306、6379、808049152 - 65535动态端口内核分配给客户端连接的临时源端口连接外网时的本地端口这里有个很多人踩过的坑客户端发起大量短连接时如果目标地址和端口固定可用源端口只有约 2.8 万个Linux 默认 ip_local_port_range 通常是 32768-60999约 2.8 万TIME_WAIT 状态下端口不能被立即复用高并发短连接场景下很容易把端口耗光报出 “Cannot assign requested address”。这个报错的根因不在服务端而在本机端口资源排查方向要搞对。1.2 端口复用与套接字选项的真实作用写服务端代码的人基本都见过SO_REUSEADDR很多人是照着示例抄上去的从来没想过它到底解决什么问题。它的核心作用是允许绑定一个处于 TIME_WAIT 状态的地址端口组合以及在同一端口上绑定不同 IP或使用通配地址与非通配地址混绑。没有它服务重启时会因为旧连接还停留在 TIME_WAIT 而绑定失败报 “Address already in use”。import socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind((0.0.0.0, 8080)) s.listen(128)另一个常被混淆的是SO_REUSEPORT它允许多个进程各自 bind 同一个端口由内核做负载均衡。这跟SO_REUSEADDR不是一回事前者是“多个套接字共享同一端口并行收包”后者是“允许绑定一个还没完全释放的地址”。两者混用时要清楚语义别以为设了 REUSEADDR 就能让多个进程同时监听同一端口。注意SO_REUSEADDR不会让两个处于 ESTABLISHED 状态的监听套接字共存它处理的是 TIME_WAIT 和地址重叠绑定的问题。想多进程共享端口看清楚文档再选SO_REUSEPORT并且注意它带来的连接分布不均问题。还有一点值得说绑定0.0.0.0和绑定具体 IP在连接匹配上的优先级不同。内核选监听套接字时会优先匹配更具体的地址。所以同一端口上绑定0.0.0.0:8080和127.0.0.1:8080是可行的从本机回环进来的连接会走后者。理解这个匹配顺序在排查“为什么我的连接走到了另一个监听器”时非常关键。2. UDP 与 TCP 的取舍分界线是责任由谁承担教科书里常用“可靠 vs 不可靠”“面向连接 vs 无连接”来描述这两者这个说法没错但不够用。我更喜欢换一个角度看传输层提供的能力越少应用层要补的就越多。选 UDP 不是图快而是你愿意自己接手一部分责任选 TCP 不是图稳而是你愿意接受它替你做了很多决定包括一些你不喜欢的决定比如队头阻塞。2.1 UDP 到底薄在哪里UDP 头部只有 8 个字节源端口、目的端口、长度、校验和。没有序列号、没有确认号、没有窗口字段、没有连接状态。发出去就完事内核不保存任何关于“这条连接”的信息。这带来的直接后果是它天然支持一对多、多对多天然适合广播和多播它没有握手延迟DNS 查询一个来回就能拿到结果不用先花一个 RTT 建连它不会因为某个包丢了就把后续已经到达的包压在缓冲区里等着重传实时音视频场景里一个迟到的包补回来也没意义丢掉反而更好。但“薄”也意味着应用层得自己处理很多事。丢包检测、乱序重排、重复去重、分片重组应用层消息边界、拥塞控制——这些 TCP 帮你做了的事情用 UDP 就得自己做或者引入现成方案。曾经有个内部服务图省事用 UDP 传日志结果在网络抖动时丢了将近三成数据而且因为没有序号压根不知道丢了哪些。后来老老实实改成“UDP 应用层序号定期补拉”才把完整性补上。这个故事说明一件事用 UDP 之前先明确你能接受丢什么。2.2 TCP 的“厚”和它带来的代价TCP 头部固定 20 字节带选项可以更长。它维护连接状态、维护发送和接收缓冲区、维护多个定时器、维护拥塞窗口和接收窗口。这套机制的收益是字节流语义你往里写什么对端按顺序读出来就是什么中间丢了、乱了、重了都由它兜住。代价也很明确。最典型的是队头阻塞一条连接上前面某个字节没到后面所有已到达的字节都得在接收缓冲区里等着不能先交给应用。在 HTTP/1.1 时代这会导致一个慢请求卡住同连接上的其他请求所以才有了多连接并发、域名分片这些补丁。另一个常被忽略的代价是握手和慢启动的固定开销。新建一条连接至少一个 RTT 建连然后从较小的拥塞窗口开始往上探Linux 默认初始窗口 10 个 MSS 左右短连接根本跑不满带宽。这也是长连接、连接池存在的现实理由不是什么架构洁癖。选择上的判断标准我给一个自己的经验口径场景特征倾向 UDP倾向 TCP数据可容忍丢失时效性优先是否需要有序完整交付否是一对多 / 广播 / 组播是否交互频繁、单次数据量小视情况省握手视情况省重连需要穿透复杂中间设备的“类流”语义否是顺便说一句现在很常见的做法在 UDP 之上自己实现可靠有序传输兼顾低握手延迟和可控的拥塞策略。这条路不是银弹实现成本相当高没有明确的场景收益之前别轻易自己造。2.3 一个容易忽视的细节UDP 也有“连接”很多人以为 UDP 完全无状态其实调用connect()之后内核也会记录对端地址之后可以用send()而不用每次写地址并且只接收来自该对端的包。这个“连接”没有握手只是一个本地缓存但它能让内核提前做路由查找并且让recv的错误码更准确比如收到 ICMP 端口不可达时能报出来。写 UDP 客户端时用一用connect()能省掉不少麻烦。3. TCP 连接的生命周期握手、挥手与状态机这部分被讲得最多也最容易被背成口诀。但如果只记住“三次握手四次挥手”遇到真实问题还是不会分析。我建议抓住两条主线握手是为了双方确认彼此的收发能力和初始序列号挥手是为了双方各自独立地关闭自己的发送方向。3.1 三次握手少一次不行多一次浪费握手过程客户端发 SYN携带初始序列号 seqx服务端回 SYNACKseqyackx1客户端再回 ACKseqx1acky1。为什么是三次而不是两次核心有两点。第一双方都要确认“我的发送能力对端能收到对端的发送能力我能收到”这需要各自发出一次、收到一次确认四次动作压缩成三次是因为服务端把 SYN 和 ACK 合并在一个包里发了。第二双方要同步各自的初始序列号。序列号不是从 0 开始的随机取值是为了避免历史连接的残留报文被误认为新连接的数据。如果只握手两次服务端发完 SYNACK 就认为连接建立但此时它并不知道客户端是否收到了这个包。假如这个包在网络里丢了客户端会重发 SYN服务端却已经在为一个不存在的连接分配资源——这就是 SYN Flood 攻击的基本原理。三次握手的最后一次 ACK正是让服务端确认“客户端确实收到了我的序列号”。这里还牵扯到一个常被问的问题初始序列号为什么随机。假设固定从 0 开始上一轮连接里有一个延迟了很久的报文恰好在新连接建立后到达序列号对得上就会被当成有效数据注入造成数据错乱。随机化让这种巧合概率降到可以忽略。3.2 四次挥手和 TIME_WAIT 的真实意义关闭时主动关闭方发 FIN表示“我没有数据要发了”对端回 ACK等对端也把数据发完了再发自己的 FIN主动方回最后一个 ACK。之所以是四次是因为 TCP 是全双工的两个方向要各自独立关闭。收到 FIN 只代表对端不再发送本端仍然可以继续发送数据这就是半关闭状态代码上对应shutdown(sock, SHUT_WR)。最后那个 ACK 发完之后主动关闭方进入 TIME_WAIT等待 2MSLLinux 上通常约 60 秒才真正释放。为什么必须等两个理由。第一保证最后那个 ACK 能到达对端。如果 ACK 丢了对端会重发 FIN处于 TIME_WAIT 的一方还能再回一个 ACK如果直接关掉对端会收到 RST关闭过程就不干净了。第二让这条连接上的残留报文在网络中自然消亡避免它们干扰立刻复用的同五元组新连接。TIME_WAIT 只出现在主动关闭方。这就解释了一个常见现象服务端如果主动关连接比如设置了较短的 keepalive 或者业务主动断开大量 TIME_WAIT 会堆在服务端如果是客户端先关那就堆在客户端。谁先关谁承担。# 统计各状态的连接数量 ss -tan | awk NR1 {print $1} | sort | uniq -c | sort -rn # 只看 TIME_WAIT并统计对端分布 ss -tan state time-wait | awk NR1 {print $5} | cut -d: -f1 | sort | uniq -c | sort -rn | head3.3 状态机速查抓包时对着看实际排障时看状态比背状态有用。下面这张表是我自己常用的对照版只保留最常遇到的几个状态出现在哪一方含义常见异常SYN_SENT客户端已发 SYN等 SYNACK大量堆积说明对端不响应或网络不通SYN_RECV服务端收到 SYN 并回了 SYNACK等最后 ACK大量堆积可能是 SYN Flood 或半开连接泄漏ESTABLISHED双方连接可用数量持续上涨要查是否泄漏未关闭FIN_WAIT_1主动关闭方已发 FIN等 ACK卡住说明对端没回 ACKFIN_WAIT_2主动关闭方收到 ACK等对端 FIN大量堆积通常是对端没正确关闭CLOSE_WAIT被动关闭方收到对端 FIN本端还没关大量堆积几乎一定是代码没 closeLAST_ACK被动关闭方已发 FIN等最后 ACK少见TIME_WAIT主动关闭方等 2MSL数量大是现象不是病要看根因CLOSE_WAIT 堆积是我见过最典型的线上事故形态。它意味着对端已经把连接关了本端代码却没调用 close句柄一直挂着。根因几乎都在业务代码异常分支里 return 之前没释放连接、用了连接池但借出后没归还、或者读循环里没处理对端返回 0 的情况。看到 CLOSE_WAIT 上千别去调内核参数去看代码。4. 可靠性怎么落地确认、重传与窗口TCP 保证可靠靠的不是某一个机制而是几个机制配合序列号解决乱序和重复确认号告诉对端我收到了哪定时器兜住丢包窗口控制发送节奏。拆开看都不复杂难的是它们之间的相互影响。4.1 序列号和确认号按字节编号不是按包这是初学者最容易搞错的一点。TCP 的序列号是对字节编号的不是对报文段编号。假设初始序列号是 1000发送一个 500 字节的段那么这段覆盖的序列号范围是 1000 到 1499下一个段的序列号是 1500对端的确认号会是 1500意思是“1499 及之前的字节我都收到了下一个我要 1500”。这个视角非常重要。它解释了几件事为什么重传时可以只重传一部分因为按字节定位为什么窗口大小以字节为单位而不是以包为单位为什么 MSS 协商的是每个段能带多少数据而不是总共能发多少。客户端 - 服务端 seq1000, len500 覆盖 1000-1499 服务端 - 客户端 ack1500 1000-1499 已收到客户端 - 服务端 seq1500, len300 覆盖 1500-1799如果中间那个 1500 开始的段丢了客户端后续又发了 1800 开始的段服务端收到后仍然回 ack1500这就是重复 ACK是快速重传的触发信号。4.2 滑动窗口与流量控制别把接收方压垮接收方在自己的接收缓冲区里维护一个窗口告诉发送方“我现在还能接多少字节”。这个值放在 TCP 头的窗口字段里16 位最大 65535 字节。发送方在途未确认的数据不能超过这个量。问题来了65535 字节在早期网络够用放到现在就是瓶颈。一个千兆链路、往返 10 毫秒的场景管道容量是 1Gbps × 0.01s 10Mbit ≈ 1.25MB窗口只有 64KB 的话吞吐上限被卡在 64KB / 0.01s 6.4MB/s 左右连千兆的一半都跑不到。解决办法是窗口缩放选项在握手时协商一个移位因子最大 14把窗口字段左移理论上限能到 1GB 量级。带宽时延积这个概念值得记住它就是“管道里能装多少数据”BDP 带宽 × RTT 例100 Mbps 链路RTT 40 ms BDP 100e6 bit/s × 0.04 s 4e6 bit 500,000 字节 ≈ 488 KB也就是说这条链路上窗口至少要接近 488KB 才能跑满。低于这个值限制吞吐的就是窗口而不是带宽。排查“带宽明明够但速度上不去”时先算一遍 BDP再去抓包看窗口字段方向就清楚了。零窗口是另一个需要留意的状态。接收方缓冲区满了通告窗口为 0发送方停止发送并启动零窗口探测定时器定期发一个字节的探测包询问窗口是否恢复。如果探测机制失效连接就会僵死——两边都以为在等对方。我遇到过一次线上连接“假死”抓包发现是零窗口后探测包被中间设备丢了最后靠应用层心跳超时兜底才没一直挂住。4.3 超时重传与快速重传两条路径丢包恢复有两条路。第一条是超时重传发送方为一个段启动定时器超时还没收到确认就重发。第二条是快速重传收到三个重复 ACK 就立刻重发不用等定时器。超时时间 RTO 不能写死得根据实测 RTT 动态算。RFC 6298 给的算法是平滑 RTT 加四倍偏差SRTT (1 - 1/8) × SRTT (1/8) × RTT_sample RTTVAR (1 - 1/4) × RTTVAR (1/4) × |SRTT - RTT_sample| RTO SRTT 4 × RTTVAR用四倍偏差是为了覆盖 RTT 的波动宁可等久一点也不要误重传。误重传的代价不只是浪费带宽还会让拥塞控制误以为网络拥塞把窗口砍半形成恶性循环。举个手算的例子。假设初始 SRTT 100msRTTVAR 20ms新采样 RTT 140msSRTT 0.875 × 100 0.125 × 140 87.5 17.5 105 ms RTTVAR 0.75 × 20 0.25 × |100 - 140| 15 10 25 ms RTO 105 4 × 25 205 ms可以看到 RTT 涨了 40msRTO 涨了约 100ms偏差项对波动的惩罚是放大的。这就是为什么网络抖一下之后重传会变得保守。快速重传这边三个重复 ACK 的门槛是个折中。太少容易误判正常的乱序也会产生重复 ACK太多则恢复慢。三个是经验值。现代内核还实现了 SACK选择性确认让接收方告诉发送方“我收到了哪些不连续区间”重传时就能精准补洞而不是把丢包之后的所有数据全重发一遍。注意SACK 需要在握手时协商如果中间有设备剥离了 TCP 选项SACK 就失效了性能会明显下降。抓包看握手包里的 SACK permitted 选项是排查“为什么重传效率低”的一个入口。5. 拥塞控制从慢启动到 BBR 的取舍流量控制是怕把接收方压垮拥塞控制是怕把网络压垮。这两个窗口取小值生效实际能发多少 min(拥塞窗口 cwnd, 接收窗口 rwnd)。拥塞控制这块很多人只记住“慢启动、拥塞避免、快重传、快恢复”四个词但不知道每个阶段窗口怎么变遇到性能问题就没法分析。5.1 四个阶段的窗口变化慢启动阶段cwnd 从初始值开始每收到一个 ACK 就加一个 MSS效果是每个 RTT 翻倍指数增长。名字叫“慢”是相对早期的做法而言实际上增长很猛。Linux 默认初始窗口是 10 个 MSS约 14.6KB这是经过大量实测后定的值太小则短连接吃亏太大则容易在起步阶段就把网络打爆。当 cwnd 涨到慢启动阈值 ssthresh 时进入拥塞避免改为每个 RTT 加一个 MSS线性增长。这个切换点就是“指数”到“线性”的拐点。丢包发生时经典算法Reno的做法是ssthresh 设为当前 cwnd 的一半cwnd 也降到一半然后进入快速恢复每收到一个重复 ACK 就把 cwnd 加一个 MSS补偿已经离开网络的数据直到收到新的 ACK 再回到拥塞避免。我把窗口变化整理成一张对照表方便算阶段触发条件cwnd 变化增长曲线慢启动连接建立 / 超时后每个 ACK 1 MSS每 RTT 翻倍拥塞避免cwnd ≥ ssthresh每 RTT 1 MSS线性快速重传3 个重复 ACK立即重传丢失段-快速恢复快速重传后ssthresh cwnd/2cwnd ssthresh 3 MSS逐步恢复超时重传RTO 到期ssthresh cwnd/2cwnd 回初始值重新慢启动手算一个例子。假设 cwnd 从 10 MSS 开始ssthresh 初始极大RTT 1: cwnd 10 - 20 RTT 2: cwnd 20 - 40 RTT 3: cwnd 40 - 80 ...如果第 4 个 RTT 时发生了三个重复 ACK假设当时 cwnd 80ssthresh 80 / 2 40 cwnd 40 3 43 后续每个重复 ACK 1直到收到新 ACKcwnd 回到 40 左右进入拥塞避免如果发生的是超时重传更严重说明连 ACK 都回不来了cwnd 直接掉回初始值 10重新慢启动ssthresh 同样是 40。这就是超时比快速重传“更伤”的原因。5.2 丢包就一定要降速吗经典算法把“丢包”等同于“拥塞”这个假设在早期网络成立因为那时候链路质量差丢包基本都是缓冲区溢出。但现在的网络不一样了无线链路、长肥管道、中间设备的浅缓冲都会造成非拥塞性丢包。一旦误判窗口砍半吞吐掉一半恢复又要好几个 RTT。基于这个反思出现了不以丢包为唯一信号的算法。BBR 的思路是主动测量瓶颈带宽和最小 RTT按“带宽 × RTT”来定发送速率尽量把数据填满管道但不排队。它在高丢包、长 RTT 链路上表现通常比 Reno/CUBIC 好但在浅缓冲共享链路上可能过于激进挤占其他流的空间。所以没有“哪个算法更好”只有“哪个更适合你的链路特征”。内核里一般会提供多个可选算法# 查看可用算法 sysctl net.ipv4.tcp_available_congestion_control # 查看当前默认算法 sysctl net.ipv4.tcp_congestion_control # 临时切换需要 root sysctl -w net.ipv4.tcp_congestion_controlbbr注意切换拥塞控制算法是全局行为会影响这台机器上所有新建连接。在共享链路上贸然切到激进算法可能把别人的流量挤掉。动之前先明确链路特征最好在测试环境压一遍再上线。5.3 实操验证窗口和拥塞控制的真实表现光看理论不够得抓一次包看数字。我常用的做法是在两端之间抓握手包和一段数据传输对着看窗口字段和窗口缩放因子# 抓 8080 端口的前 200 个包带时间戳和绝对序列号 tcpdump -i eth0 -nn -tttt -S tcp port 8080 -c 200 -w /tmp/tcp.pcap # 用文本方式粗略看握手三包 tcpdump -i eth0 -nn -S tcp port 8080 and tcp[tcpflags] (tcp-syn|tcp-ack) ! 0 -c 10抓到之后重点看三处握手包里的 window scale 选项值是多少数据传输阶段通告窗口是否长期贴着小值以及有没有大量重复 ACK。这三个信息基本能定位是接收端处理慢、窗口太小还是链路真的在丢包。# 看内核层面的重传和拥塞统计 netstat -s | grep -i -E retrans|timeout|reordering ss -tinss -tin的输出里有 cwnd、rtt、retrans 等字段压测时一边打流量一边看这些数字怎么变比看任何文档都直观。我一般会先在本地用两个终端跑个简单的收发程序人为在中间加延迟和丢包观察 cwnd 的爬升和被砍几次之后就形成肌肉记忆了。6. 抓包与排障实录从连不上到慢得离谱传输层的问题症状无非三类连不上、连上但很慢、连上但数据不对。这三类的排查路径差别很大混在一起查只会浪费时间。我的习惯是先分类再动手。6.1 建一个可复现的最小抓包环境排障最怕两件事一是问题复现不了二是抓了一堆包不知道看哪。我的做法是先搭一个最小环境把变量控制住。本机起一个服务用tc人为注入延迟和丢包然后用客户端去连这样每次现象都可控。# 给回环网卡加 50ms 延迟和 1% 丢包 sudo tc qdisc add dev lo root netem delay 50ms loss 1% # 查看当前规则 tc qdisc show dev lo # 用完记得删掉否则会影响本机其他测试 sudo tc qdisc del dev lo root加完之后跑一个简单的请求观察耗时变化再抓包对照。这个方法的价值在于你可以精确知道“应该”发生什么然后去验证实际发生了什么。比起在线上盲抓效率高一个量级。import socket, time start time.time() s socket.create_connection((127.0.0.1, 8080), timeout5) s.sendall(bhello) data s.recv(1024) elapsed (time.time() - start) * 1000 print(f耗时 {elapsed:.1f} ms, 收到 {len(data)} 字节) s.close()上面这段代码跑出来的耗时会明显受到注入延迟的影响握手一个 RTT、请求一个 RTT加上处理时间跟理论值能对上就说明链路行为符合预期对不上就得看抓包了。6.2 常见症状速查表下面这张表是我这些年遇到的高频问题按症状归的类实际排查时可以直接照着走症状优先看什么常见根因处理方向连接超时卡在 SYN_SENT抓包有无 SYNACK目标未监听、安全策略拦截、路由不通先确认端口监听再确认中间链路连接被立即拒绝是否收到 RST端口无监听、监听队列满查 backlog 和 listen 配置连接建立但一读就断读完是否返回 0对端 close 了写方向检查对端关闭逻辑CLOSE_WAIT 大量堆积本端代码是否 close异常分支未释放连接查资源释放路径TIME_WAIT 数量巨大谁在主动关闭短连接频繁、服务端主动关改长连接或调关闭策略吞吐上不去窗口字段和 BDP窗口太小、窗口缩放未协商算 BDP检查窗口缩放周期性卡顿重传和 RTO链路丢包、RTO 过于保守看重传率评估算法数据错乱 / 粘包应用层分帧方式把字节流当消息流处理加长度前缀或分隔符关于 backlog 有个细节值得展开。很多框架的listen(backlog)参数只是建议值内核还会受somaxconn限制。当并发建连速度超过 accept 速度半连接队列或全连接队列满了新连接就会被丢弃或拒绝客户端看到的是超时或 reset。这类问题在建连高峰期特别明显抓包会看到 SYN 重传但没有 SYNACK。# 查看全连接队列溢出统计 netstat -s | grep -i listen # 查看当前 somaxconn sysctl net.core.somaxconn6.3 粘包、半关闭与 RST三个经典坑粘包这个词其实不太准确TCP 是字节流它根本没有“包”的概念所谓粘包是应用层把字节流当成了消息流。两次send的数据可能被合并成一次recv读到一次send的数据也可能被拆成多次读到。解决办法只有一条应用层自己定边界。定长、分隔符、长度前缀三种做法里长度前缀最通用也最好实现。import struct def send_msg(sock, payload: bytes): # 4 字节大端长度内容 sock.sendall(struct.pack(I, len(payload)) payload) def recv_msg(sock): header recv_exact(sock, 4) if not header: return None (length,) struct.unpack(I, header) return recv_exact(sock, length) def recv_exact(sock, n): buf b while len(buf) n: chunk sock.recv(n - len(buf)) if not chunk: return None buf chunk return buf这里recv_exact的循环是必须的单次recv不保证读满。我见过不少代码直接sock.recv(4)解长度在本地测试永远正常一上真实网络就偶发解析错位根因就是没处理短读。半关闭的坑在于很多人以为close()就是“我说完了”实际上close()会同时关闭读写两个方向如果对端还有数据在发就会收到 RST之前发出去但还没被读走的数据也可能丢失。正确的做法是先shutdown(SHUT_WR)只关写方向把剩余数据读完再close()。RST是最容易被误判的信号。常见的产生场景有连接到不存在的端口、向已经关闭的连接写数据、设置了SO_LINGER为 0 后 close、接收缓冲区里还有未读数据时 close。看到 RST 不要急着怪网络先看是本端发的还是对端发的再对着上面这几种场景逐一排除。6.4 几个我踩过的坑和对应经验第一条经验不要一看到 TIME_WAIT 就去调tcp_tw_reuse。TIME_WAIT 是协议正常工作的表现数量大只是症状。真正的解法通常是改用长连接、连接池或者让客户端主动关闭。另外注意某些“加速回收”的历史参数在新内核上已经被移除照抄老文章里的配置可能直接报错甚至引发更诡异的连接问题。第二条经验先看应用层日志再看抓包。抓包成本高、信息密度低很多时候应用日志里已经写了“连接超时”或者“对端关闭”直接定位到具体环节再用抓包验证假设效率高得多。我早期喜欢一上来就tcpdump经常抓了几百兆还没找到问题点。第三条经验用ss代替netstat。ss直接从内核取数据连接数上万时速度差异非常明显而且支持按状态过滤写脚本很方便。# 按状态统计排除监听态 ss -tan state established | wc -l ss -tan state close-wait | wc -l ss -tan state time-wait | wc -l # 看某进程的套接字 ss -tanp | grep 8080第四条经验压测时同时盯三样东西连接数、重传率、RTT。只盯 QPS 容易误判QPS 上不去可能是客户端并发不够也可能是服务端窗口太小还可能是链路在丢包三样一起看才能区分。我一般会开三个终端一个打流量一个ss -s循环看汇总一个ss -tin看单连接的 cwnd 和 rtt。最后分享一个排查顺序上的小习惯遇到传输层问题我固定按“端口是否监听 → 三次握手是否完成 → 数据是否双向流动 → 关闭是否干净”这四步走。这四步对应了连接生命周期的四个阶段任何一步卡住问题范围立刻缩小到几个可能原因比漫无目的地翻日志快得多。这套顺序用了几年几乎没失手过唯一需要额外注意的是长连接场景下要加上“空闲期是否被中间设备悄悄断开”这一条检查因为很多中间设备有静默超时连接看着是 ESTABLISHED实际早就发不出去了只能靠应用层心跳来发现。

从端口到拥塞控制：传输层TCP/UDP核心机制与抓包排障

相关推荐

动态规划解决棋盘路径乘积末尾零问题

从端口到拥塞控制：传输层TCP/UDP原理与抓包排障实战

智能数据分析平台的核心技术与应用实践

更多资讯

扩散模型局部风格控制：实现内容保真与风格注入的精准解耦

STM32综合测评B类题固件：ADC/DMA采样、校准与PID闭环

分布式计算核心技术解析与大数据实践

全双工语音模型的话轮控制：解决AI抢话与冷场问题

多模型共识机制提升教育AI诊断准确率

Diagram设计不是画图，而是结构化建模思维

今日更新

基于YOLOv11的石油泄漏智能检测系统开发实践

AI行业变局：合规、Mod化与上下文管理的实战启示

计算机视觉与AI原生应用融合的技术实践

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？