大厂男孩的粉丝先说我为什么想写这篇。前两天线上有个服务跨地域传输大文件，吞吐率一直上不去，RTT明明只有几十毫秒，带宽也买了 100M，可实际速率就是卡在 2MB/s 左右。抓包一看，重传满天飞，每秒几十个 DUP ACK，于是把问题定位到 TCP 重传和拥塞窗口上。说来惭愧，干了这么多年 Linux 后端，真正把 TCP 可靠传输整条链路吃透，还是靠那次"被线上教做人"的经历。
这篇文章我打算彻底讲透 Linux 下的 TCP 可靠传输机制。不讲那种"三次握手四次挥手"的浅层八股，而是从协议设计动机出发，一路拆到 Linux 内核的实现路径，再到实际排查中用得到的命令、参数和案例。全程配合生动例子和文字图解，把每一个"为什么这么做"都说清楚。无论是准备面试的后端研发、搞网络排查的运维、还是刚接触嵌入式网络编程的同学，这篇文章都值得存下来反复看。
1. 可靠传输这个需求，到底是被什么逼出来的
1.1 网络从诞生那天起，就没承诺过"不丢"
以太网、IP 网络从设计之初走的就是"尽力而为"路线。什么叫尽力而为？就是说每个网络节点都会尽可能帮你把数据转发到目的地，但如果出现链路拥塞、缓冲区溢出、信号干扰、路由环路，它可以选择直接丢弃数据包，而且不通知任何人。这事听起来很反直觉，因为在我们的日常认知里，网络就像一根水管，水倒进去就应该从另一头流出来，但物理世界从来没这么美好。
打个比方。把 IP 网络想象成一个快递系统，但是没有电话回执、没有签收确认、没有物流跟踪。你把包裹交给快递员，快递员会尽量帮你送，但路上可能遇到暴雨把包裹淋湿了，可能分拣中心爆仓把你的包裹搁置了，甚至可能快递员自己也迷路了。你作为发件人，完全不知道包裹到底送到了没有。这就是无连接、不可靠的 IP 服务模型。
那应用层能不能忍？能忍才有鬼了。我们传输文件、发消息、看网页、调接口，任何一条数据丢失都可能导致文件损坏、消息缺失、页面打不开、接口报错。所以必须在 IP 之上加一层协议，专门解决"怎么知道对方收到了""没收到怎么办""重复收到了怎么处理""收到的顺序乱了怎么恢复"这四个问题。TCP 就是干这个的。
1.2 不可靠的三个"罪魁祸首"，对应 TCP 的三套对策
实际网络中，数据出问题无非以下三种情况，每一种都对应 TCP 一套精密的机制。
第一是丢包。路由器、交换机、服务器的网卡队列都有容量上限，流量一超过上限，新来的包就只能丢掉。TCP 的对策是确认与重传：每收到一个数据段都要回一个 ACK，发送方如果发现超时没收到 ACK，就认为丢了，重新发送。
第二是乱序。路径上的多个路由器可能选择了不同的转发路径，先发的包反而后到。TCP 的对策是序列号排序：每个字节都有一个唯一的序列号，接收方按序列号把数据重新排好再交给上层。
第三是重复。超时重传可能导致同一个数据段被发送两次，接收方可能重复收到。TCP 的对策还是序列号：接收方用序列号去重，序列号已经收过的数据直接丢弃。
这三种情况加在一起，构成了 TCP 可靠传输的全部核心问题域。内核里那一堆让人头大的状态机、定时器、缓冲区管理，本质上都是在围绕这三个问题做文章。
1.3 我们常说的"TCP 连接"，内核视角到底是什么
面试和实战中经常被问到：TCP 连接到底是什么？应用层看到的是一个 socket 文件描述符，但内核视角下，一条 TCP 连接是一对四元组 (src_ip, src_port, dst_ip, dst_port)，以及挂在这对四元组上的一堆数据结构：发送缓冲区、接收缓冲区、拥塞控制状态机、重传定时器、保活定时器、序列号空间等。
你可以把 TCP 连接理解为两个主机之间的一组"契约状态"。这些状态分散在两台主机的内核里，不占物理线路，不占中间设备资源，纯粹靠协议行为维持。一旦中间链路断开、双方主机重启，这组状态就失效了，对端可能永远不知道你已经"消失"，直到某个超时机制发现了它。这也是后面要讲 TIME_WAIT、保活机制的根本原因。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 三次握手和四次挥手：TCP 的建立与拆除机制，远不止背状态码那么简单
2.1 起始序列号（ISN）为什么不能固定
TCP 建立连接的第一步，是交换初始序列号。如果所有连接的初始序列号都从一个固定值开始，很容易被两种攻击利用：一是攻击者可以猜测序列号，发送伪造的 RST 包切断连接；二是历史连接中的残留数据段可能恰好落在新连接的序列号空间内，造成数据污染。
Linux 内核的做法是初始化序列号随时间变化，具体实现是 secure_tcp_seq() 函数，它基于一个全局的随机数种子和当前时间抖动生成。也就是说，即使同一台服务器上短时间内反复建立同样的四元组连接，每一次的 ISN 都不同。这一点在设计 NAT、防火墙规则时尤其重要，很多只认四元组的中间设备在实现上如果偷懒，可能忽略序列号校验，导致连接被 RST。
2.2 三次握手的状态迁移，以及 SYN 洪泛攻击的应对
三次握手的完整过程，用文字图表示如下：
code复制客户端 服务端
|----------- SYN, seq=x --------------->| 进入 SYN_RECV
|<------- SYN+ACK, seq=y, ack=x+1 ------| 内核分配连接控制块
|----------- ACK, seq=x+1, ack=y+1 ---->| 进入 ESTABLISHED
每次握手都带两个关键字段：seq 是自己的序列号起始点，ack 是对接收到的数据的确认号。注意 ACK 号表示"我期望收到的下一个字节的序列号"，也就是说 ack=x+1 表示"你发来的 seq=x 我收到了，下一个请从 x+1 开始发"。
关于握手，绝大多数人只知道状态迁移，但不知道内核在握手期间做了大量资源分配和队列管理。服务端收到 SYN 后，内核并不是直接把连接放到全连接队列，而是先放入半连接队列（SYN Queue），然后回复 SYN+ACK。只有收到客户端的最终 ACK，连接才会从半连接队列移动到全连接队列（Accept Queue），等待应用调用 accept() 把它取走。
这就引出一个经典问题：如果客户端故意不回最终的 ACK，服务端就一直在半连接队列里躺着无效连接，队列一满，正常的新连接就进不来了。这就是 SYN 洪泛攻击的基本原理。Linux 的应对之策是 SYN Cookie：不分配任何资源，把连接的必要信息通过精心构造的序号计算出来，放到 SYN+ACK 的序号里返回。客户端回 ACK 时带上这个序号，服务端从 ACK 中提取并进行校验，校验通过再分配资源建立连接。内核参数 net.ipv4.tcp_syncookies=1 就是干这个的，一般建议保持默认开启。
2.3 全连接队列溢出，实际业务中比 SYN 洪泛更常见
很多老运维都遇到过这样的情况：服务端应用处理慢，连接堆积在队列里，客户端那边表现就是连接卡在握手阶段迟迟无法完成，或者握手完成后发数据失败。这通常不是网络问题，而是全连接队列（Accept Queue）满了。
Linux 下可以通过 ss -lnt 查看全连接队列的状态：
bash复制ss -lnt
State Recv-Q Send-Q Local Address:Port
LISTEN 0 128 0.0.0.0:8080
这里的 Send-Q 是监听 socket 的全连接队列最大长度，由应用 listen(fd, backlog) 传入。Recv-Q 表示当前已建立等待 accept() 的连接数量。如果 Recv-Q 长期接近 Send-Q，说明应用 accept 速度跟不上连接建立速度。
这里有个关键的细节：backlog 的值不是直接等于队列长度，内核会做一次上限裁剪。listen() 传入的 backlog 会被 net.core.somaxconn 参数限制，net.ipv4.tcp_max_syn_backlog 则限制半连接队列大小。修改这些参数后，还需要应用重新 listen() 才能生效。Nginx 默认的 backlog 是 511，但很多系统 somaxconn 默认 128，如果你没显式调整，Nginx 实际用的就是 128，高并发下很容易丢连接。
2.4 四次挥手，服务端大量 TIME_WAIT 怎么解
连接关闭时，主动关闭方要经过 TIME_WAIT 状态，等待 2MSL（Maximum Segment Lifetime，最长报文段寿命）才彻底释放资源。MSL 在 Linux 内被硬编码为 30 秒左右（TCP_TIMEWAIT_LEN = 60 秒的 2 倍我看过不同版本，实际上 4.15+ 内核定义是 60 秒，但 TIME_WAIT 等待期间实际定时器是 60s），也就是主动关闭的 socket 要等约 60 秒才真正消亡。
为什么要有 TIME_WAIT？两个原因：
第一，保证最后一个 ACK 能让对方收到。如果这个 ACK 丢了，对方会重发 FIN，如果连接已经释放，重发的 FIN 会被当作错误连接处理，造成各种诡异问题。TIME_WAIT 给这个 ACK 留了重传窗口。
第二，让旧连接上的残留数据包在网络中彻底消失。如果之前这条连接上有数据段在网络中"游荡"，而马上用同样的四元组建立新连接，新连接就可能收到旧数据段，造成数据错乱。2MSL 时间足够一个数据包在网络中往返两次，从而保证过期数据全部消亡。
高并发的短连接场景下，服务端作为主动关闭方时会产生大量 TIME_WAIT 连接。很多调优文章会建议你把 net.ipv4.tcp_tw_reuse=1 打开，让内核复用 TIME_WAIT 状态的连接。但这里要特别注意：tcp_tw_reuse 只对主动连接方有效，而且它是在建立新连接时通过时间戳校验判断是否可以复用 TIME_WAIT 连接，没有办法让服务端大量 TIME_WAIT 消失。真正合理的做法是调整应用层，尽量让客户端主动断开；或者评估是否真的需要建立大量短连接，考虑连接池复用。
3. 滑动窗口、缓冲区与流量控制：可靠传输的"内存账本"
3.1 窗口机制解决的核心矛盾：生产者与消费者的速率不匹配
发送方只想尽可能快地发数据，接收方却可能来不及处理。没有流控的话，接收方的缓冲区很快被塞满，之后任何到达的数据只能丢弃。这就像下水道入口是一个水桶，上游拿消防水管往里灌水，桶满了水就溢出来浪费掉了。
TCP 用滑动窗口解决这个问题。每个 ACK 包中携带一个 window 字段，表示"从确认号开始，我还有多少空闲缓冲区可以接收数据"。发送方看到这个值，就知道当前可以发送的未确认数据总量不能超过这个窗口大小。
窗口相关的两个维度要分清：一个是接收窗口（rwnd），由接收方通告，目的是避免接收方缓冲区溢出；一个是拥塞窗口（cwnd），由发送方自行维护，目的是避免网络链路拥塞。实际可发送的未确认数据量是 min(rwnd, cwnd)。滑窗这个设计本质上是把"限制发送量"这件事做成双向协商：发送方有一个滑窗，接收方也有一个滑窗，两个窗口通过 ACK 报文互相传递信息。
3.2 16 位窗口字段与窗口缩放因子
TCP 报文头里，窗口大小字段只有 16 位，最大只能表示 65535 字节。按现在的带宽水平，这个数字小得可怜。设想一下 10Gbps 的链路上，20ms RTT 的带宽延迟积（BDP）是多少：10Gbps * 0.02s = 200Mbit = 25MB。而 TCP 窗口最多 64KB，显然没用。
解决办法是 RFC 1323 定义的窗口缩放（Window Scale）选项。在三次握手时，双方通过 WSOPT 选项告知对方自己的缩放因子。这个因子是一个 0 到 14 的整数，含义是实际的窗口大小 = 报文字段的 window 值左移因子位（即乘以 2 的因子次方）。
Linux 下很多同学抓包时看到窗口是 65535，以为是对方缓冲区配小了，其实只是没开缩放。默认情况下，net.ipv4.tcp_window_scaling=1 是开启的，但如果中间网络设备（防火墙、负载均衡）不支持这个选项，可能出现连接建立后吞吐率只有几 MB/s 的诡异现象。遇到这种问题优先检查链路设备的 TCP 选项兼容性。
3.3 Linux 内核缓冲区的动态调优：tcp_rmem 与 tcp_wmem
接收窗口只是"通知"层面的限制，真正限制窗口大小的背后是内核为每个 socket 分配的内存缓冲区。如果接收缓冲区只有 64KB，那接收窗口就不可能通告到几 MB。
Linux 内核对 socket 的读缓冲区和写缓冲区都提供了一组动态范围参数，分别叫 net.ipv4.tcp_rmem 和 net.ipv4.tcp_wmem。每个都是三个值：最小值、默认值、最大值。
bash复制sysctl net.ipv4.tcp_rmem
# net.ipv4.tcp_rmem = 4096 131072 6291456
第一个 4096 是最小值，表示 socket 在内存压力下至少保证的最小缓冲大小。第二个 131072 是默认值，新建 socket 的初始缓冲区大小。第三个 6291456 是最大值，受 net.ipv4.tcp_rmem 最大值的限制。
内核会动态调整缓冲区：当接收方处理慢、接收队列累积时，如果还有内存富余，内核会自动调大缓冲区到 6MB 甚至更高；当内存紧张时又往下收缩。所以不要试图把 tcp_rmem 的默认值手动调成一个很大的数字，动态机制比静态配置更高效。真正需要手工调整的是最大值，比如你要跑大流量传输任务，可以把最大值提高到 16MB 或 32MB。
发送端同样有一套动态机制。另外还有一个全局上限参数 net.core.wmem_max 和 net.core.rmem_max，socket 通过 setsockopt(SO_SNDBUF/SO_RCVBUF) 能设置的上限就是这两个值。很多应用层框架号称"把 Socket 缓冲区调到 8MB"，如果内核 max 还是默认的 212992，实际根本不会成功，用 ss -m 才能看到真实生效值。
3.4 零窗口与糊涂窗口综合征：两个"发送方想发发不动"的极端场景
当接收方的缓冲区被填满，它会通告窗口为 0，这时发送方必须停止发送，进入**持续探测（Persist Timer）**状态：定时发送一个字节的窗口探测包，询问接收方"窗口开了没有"。这是避免死锁的经典机制，因为如果接收方恢复接收能力后发送的 ACK 包丢了，发送方永远不知道可以继续发了，必须靠主动探测打破僵局。
糊涂窗口综合征（Silly Window Syndrome）则是另一个合理但有害的现象：当接收方每次只能腾出几字节空间，它就通告一个小窗口，发送方也立刻发送几字节的数据，双方每来一个 ACK 就发送一个只有几个字节的包，造成极大浪费。就好比快递公司每次只派一辆装满一个盒子的卡车送一件商品。
TCP 的两个解决方案：接收方通告窗口时，如果新增可用空间小于 min(MSS, 窗口的一半)，就保持不变，这就是 David Clark 算法；发送方在窗口特别小时，如果可发送数据不足一个 MSS，就延迟发送或者等待更高层调用 push，这跟 Nagle 算法有些类似。Linux 内核对这两个行为都有内置实现，一般不需要应用层介入处理。
4. 确认与重传：TCP 可靠性的发动机
4.1 序列号是可靠传输的"记账本"
每个 TCP 数据段中，seq 字段表示本段数据的第一个字节在整个字节流中的位置。比如第一次发送 1000 字节，序列号是 1000，那么这 1000 字节就是 1000~1999，下一个数据段从 2000 开始。接收方校验收到的数据段是否连续，用 ACK 号告诉发送方"1~1999 都收到了，请从 2000 继续发"。
这种累计确认机制带来一个特性：ACK 号代表的是"按序收到的最大字节 + 1"，但并不保证前面的全部字节都收到了，中间可能有空洞。比如发了 seq=1000、2000、3000 三段，接收方收到 1000 和 3000，没收到 2000，那 ACK 号依然是 2000，表示"我最想要的是 2000 这一段"。
4.2 RTT 测量与 RTO 计算：重传等待时间怎么来
TCP 的重传不能盲目立即进行，也不能等太久。等太久的话吞吐率急剧下降，一旦丢一个包，整个管道空转一个 RTT；立即重传则会造成大量重复包，进一步加剧拥塞。
所以 TCP 核心是测量往返时间 RTT，然后基于 RTT 的均值和平滑波动计算出重传超时时间 RTO。经典算法是 Jacobson/Karels 算法，维护两个变量：平滑 RTT（SRTT）和 RTT 方差（RTTVAR）。公式是：
- SRTT = (1 - α) * SRTT + α * RTT，α 典型值是 1/8
- RTTVAR = (1 - β) * RTTVAR + β * |RTT - SRTT|，β 典型值是 1/4
- RTO = SRTT + max(G, 4 * RTTVAR)，G 是时钟粒度
这个设计的高明之处在于把"方差"也纳入了考虑。如果网络抖动大，RTO 会相应变大，避免频繁超时误判丢包；如果网络很稳定，RTO 就紧贴 RTT，保证丢包后能迅速重传。
Linux 内核有个参数 net.ipv4.tcp_rto_min，默认值是 200ms（或按系统 HZ 调整）。不管实测 RTT 多小，RTO 都不会低于这个下限，这样避免极端情况下重传定时器过紧导致无意义重传。在高精度低延迟的网络环境（如数据中心内部），可以考虑调低这个值。
重传还有个重要特性叫指数退避：第一次超时重传后，如果还没收到 ACK，下一次超时时间翻倍。这是为了避免网络已经拥塞了，重传还在拼命增加压力。
4.3 快速重传与重复 ACK：没必要等超时的重传机制
如果发送方发出多个包，其中一个丢了，接收方收到后续乱序包时，会立即重复返回"我期望的那个序列号"的 ACK。发送方连续收到 3 个重复 ACK，就知道那个包大概率丢了，不用等超时，立刻重传。这就是快速重传。
比如发送了 7 个包：1,2,3,4,5,6,7，其中 2 丢了。接收方收到 1 返回 ACK=2；收到 3 发现不连续，返回 ACK=2；收到 4 依然返回 ACK=2；收到 5、6、7 也依然返回 ACK=2。发送方看到连续 3 个 ACK=2，马上重传 seq=2 的数据。快速重传比超时重传效率高太多了，因为它不需要等待一个 RTO。
这里提一个常见的坑：如果接收方启用了 GRO/GSO（后面会详细讲），大量小包被打包成一个大包，乱序可能导致原始 ACK 顺序被打乱。不过 Linux 内核的 ACK 验证逻辑对这些场景做了兼容处理，一般不会误触发快速重传。
4.4 SACK 与 DSACK：处理多个包同时丢失的问题
快速重传一次只能处理一个丢包。如果网络抖动导致 3、4、5 三个包都丢了，发送方重传完 3 之后，后续收到的 ACK 还是会提示"丢 4 丢 5"，需要一步一步重传，效率非常低。
SACK（Selective Acknowledgment，选择性确认）选项允许接收方在 ACK 中携带"我已经收到了哪些不连续的块"，发送方一次就能知道哪几个包丢了，可以一起重传。Linux 内核参数 net.ipv4.tcp_sack=1 默认开启。抓包时看到的 SACK 块形如：SACK range: 1000-2000, 3000-4000，意思是这些区间的数据已收到，但中间有空洞。
DSACK（Duplicate SACK）更进一步，可以告知发送方"你重传的数据段我重复收到了"，发送方据此可以调低重传阈值，避免不必要的重传。这在拥塞控制里很有价值，因为不必要的重传会白白加剧网络负载。
4.5 真实场景：丢包率 1% 时吞吐量掉多少
很多同学不理解"1% 丢包率对性能影响有多大"，做个简单的数学推演就很震撼。假设链路带宽 100Mbps，RTT 100ms，每包大小 1500 字节，MSS 1460 字节。
理论上，无丢包时单连接吞吐受窗口限制，假设窗口足够大，就是带宽上限。如果有 1% 丢包，TCP 每次丢包后进入快速重传，拥塞窗口减半，然后进入拥塞避免阶段，每次 RTT 只增加 1 个 MSS。丢包对吞吐的惩罚是：(丢包率) 与窗口恢复时间的乘积关系。粗略估算，窗口从 W 减到 W/2，要恢复到 W 需要 W/2 个 RTT。这段时间内吞吐率只有峰值的一半多。按经典公式 吞吐 <= MSS / (RTT * sqrt(丢包率)) 计算：1460 * 8 / (0.1 * sqrt(0.01)) = 11680 / 0.1 = 116800 bps = 1.1Mbps。
1% 丢包率，直接吃掉 98.9% 的吞吐。 这就是为什么 TCP 可靠性机制在网络不稳定时表现出的"断崖式"下跌。也解释了为什么很多长肥管道的调优，不是调窗口，而是在降低丢包率和优化拥塞控制算法上做文章。
5. 拥塞控制在可靠传输里的角色：不但要可靠，还要"不添乱"
5.1 可靠传输的一个悖论：重传会加剧拥塞
如果网络丢了包，发送方重传是必要的，但问题在于：丢包往往不是偶然，而是某个路由器缓冲区满溢了，说明链路已经拥塞。 如果发送方还在重传、还在满速发送，就会让拥塞进一步恶化，形成雪崩。所以 TCP 必须有一个机制来"探知"网络负载程度，动态调整发送速率，这就是拥塞控制。
拥塞控制的基本哲学非常朴素：把丢包当作拥塞信号，发现丢包就降速，没丢就试着加速。 所有算法本质上都是怎么加速、怎么降速的策略差异。
5.2 慢启动、拥塞避免、快恢复与快重传的组合拳
经典的 Tahoe/Reno/NewReno 拥塞控制有这么几个状态：
慢启动（Slow Start）。连接刚建立时，发送方不知道网络状况，从很小的拥塞窗口开始（Linux 初始 cwnd 默认 10 个 MSS，可以调 net.ipv4.tcp_init_cwnd 修改）。每收到一个 ACK，cwnd 加 1 个 MSS，相当于每过一个 RTT，发送量翻倍。这是指数增长，非常激进，但目的就是快速探测网络容量边界。
拥塞避免（Congestion Avoidance）。当 cwnd 超过慢启动阈值 ssthresh 后，指数增长变成线性增长，每个 RTT 只增加 1 个 MSS。慢速逼近链路实际容量，避免指数增长直接打爆网络。
快速重传 + 快速恢复（Fast Retransmit / Fast Recovery）。收到 3 个重复 ACK 时，判定丢包，但比超时重传温和。此时阈值减半，cwnd 减半，然后进入线性恢复阶段，不回到慢启动。这种设计是基于"快速重传往往意味着链路只是轻微拥塞，而不是彻底瘫痪"的观察。改成超时重传的话，说明链路真的不行了，必须重走慢启动。
5.3 Linux 默认的 Cubic 和新贵 BBR，怎么选
老牌 Reno 的问题在于窗口增长是线性的，在带宽大、RTT 大的所谓"长肥管道"里，要花很多个 RTT 才能把窗口恢复到丢包前的水平。Cubic 把窗口增长函数改成三次函数：丢包后窗口快速回升到丢包前的水平，然后放慢速度试探，这样在高 BDP 网络里恢复速度远快于 Reno。这也是 Linux 多年来的默认算法。
BBR（Bottleneck Bandwidth and Round-trip propagation time）是 Google 提出来的一套完全不同思路的算法：它不再把丢包当作唯一的拥塞信号，而是直接测量瓶颈带宽和最小 RTT，用这两个参数计算出最优发送速率。BBR 在丢包环境下表现优异：即便在 5% 丢包率下也能维持较高吞吐，而 Cubic 早就趴窝了。
在 Linux 上切换拥塞控制算法很简单：
bash复制sysctl net.ipv4.tcp_congestion_control
# 查看当前算法，通常输出 cubic
# 加载 BBR 模块
modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
BBR 适合长距离高带宽链路（跨境、跨地域数据中心同步）、弱网环境（移动网络）、以及丢包率较高的链路。但它也有弱点：对深队列网络的公平性不如 Cubic，而且最初版本与某些防火墙的兼容性有些问题。新的 BBR 版本（v2/v3）改进了很多。
5.4 内核里那些截图常见的"缓冲区自动调优"
当接收方缓冲太小或太大时，性能都会打折扣。太小窗口受限，太大则接收方内存占用高，还可能导致接收窗口通告太大，发送方一股脑灌入大量数据，中间路由器缓冲区轻易被打爆。
Linux 的 tcp_moderate_rcvbuf 参数控制"接收缓冲区自动调节"。默认开启时，内核会根据接收速率、丢包统计动态调整 rcvbuf。发送端同样有 tcp_wmem 动态调整机制。调优时建议先看系统的丢包率和 BDP 需求，别一上来就盲目把缓冲区调到几十 MB。
6. Linux 内核里 TCP 包从入口到出口的全链路地图
6.1 接收路径：网卡中断、NAPI、GRO 与协议栈
一个 TCP 数据包到达网卡后，内核的处理流程大体如下：
- 网卡 DMA 把包写入内存环形缓冲区，然后触发硬中断。
- 中断处理程序快速禁用该网卡中断，把它挂到软中断的 poll 队列，唤醒
ksoftirqd处理。 - 软中断处理中，调用网卡驱动注册的 NAPI poll 方法，把 skb（socket buffer）从队列里取出。
- 如果开启 GRO（Generic Receive Offload），驱动会把多个连续的小包合并成一个大 skb，减少上层处理次数。
- 随后 skb 进入 IP 层
ip_rcv，经过路由查找、分片重组，进入 TCP 层tcp_v4_rcv。 tcp_v4_rcv根据四元组找到对应的 sock 结构，把数据放入接收队列，然后唤醒等待在recvfrom上的进程。
这个链路里，最容易成为瓶颈的是第 4 步前后的队列长度，以及 listen 全连接队列的容量。线上看网卡有没有丢包，用 ethtool -S eth0 | grep drop 能看到收包丢包计数。如果是软中断处理不及时导致的，看 /proc/net/softnet_stat 的第三列，不为 0 说明有 softnet backlog 丢弃。
6.2 发送路径：写缓冲区、Nagle 算法与 GSO
发送路径相对简洁。应用调用 send() 后，数据被拷贝到内核 socket 发送缓冲区。只要发送缓冲区有空间，send() 通常立即返回，真正的数据传输由 TCP 发送内核线程或调用路径驱动。
发送前，内核会做一系列决策：是否允许发送（窗口是否够）、是否合并小包（Nagle 算法）、是否走 GSO 硬件分片。
Nagle 算法是 TCP 里争议最大的特性之一。它的规则是：当发送缓冲区里有未确认的数据时，新到达的小段数据不立即发送，而是等之前的段被确认后一起发，或者积累到接近一个 MSS 再发。这能减少大量小包造成网络浪费，但应用实时性要求高时就成了灾难——比如一个指令请求 + 小响应，被 Nagle 算法卡住 40ms，表现就是"接口偶尔慢 40ms"。
解决方式两种：一是 setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &one, sizeof(one)) 关闭 Nagle；二是使用 TCP_CORK，攒够一整个 MSS 再一次性发送。实际开发中，绝大多数请求响应型的服务都应该开 TCP_NODELAY。
6.3 socket 阻塞与非阻塞语义，底层是怎么实现的
对 send() 来说，阻塞模式下，如果发送缓冲区剩余空间不够，进程会挂到 sock 的等待队列上，直到内核缓冲区腾出空间（收到 ACK 释放窗口）才被唤醒继续拷贝。非阻塞模式下，缓冲区不够就直接返回 EAGAIN 或 EWOULDBLOCK。
对 recv() 阻塞模式，如果接收队列为空，进程挂起到等待队列，直到数据到达或超时。非阻塞模式则直接返回 EAGAIN。理解了这一点，很多网上讨论的 socket 性能问题就有了判断依据。比如"发送缓冲区满导致 CPU 100%"——如果大量 non-blocking send 返回 EAGAIN，业务层频繁重试，CPU 就涨上去了。正确做法是用 epoll 的 EPOLLOUT 事件等待可写。
6.4 tcpdump、ss、netstat 和 Wireshark 组合排查的基本功
线上排查 TCP 问题，工具链是必备的。我常用的组合如下：
抓包用 tcpdump，抓握手包、重传包、乱序：
bash复制# 抓取 80 端口，保存到文件，每个包最大抓 128 字节
tcpdump -i eth0 -nn -s 128 port 80 -w /tmp/http.pcap
# 实时看 TCP 重传
tcpdump -i eth0 -nn tcp[tcpflags] & (tcp-syn|tcp-ack) == 0 and (tcp[tcpflags] & tcp-ack) != 0 and (tcp[((tcp[12] & 0xf0) >> 2)] & 0x01) != 0
用 Wireshark 分析 pcap 时，直接选中任意 TCP 包，右键"Follow TCP Stream"，看整条连接的 seq/ack 和重传标记。Wireshark 会标红重传包、标紫乱序包、标黑 RST，一眼定位问题。
实时连接状态用 ss 比 netstat 快，尤其在大量连接场景：
bash复制# 查看当前所有 TCP 连接状态统计
ss -s
# 查看 TIME_WAIT 数量
ss -tan state time-wait
# 查看某个端口有没有 accept 队列溢出
ss -lnt
如果 Recv-Q 积压而 Send-Q 为满，说明对端接收能力不足或应用没及时 read；如果 Send-Q 一直有数据，可能是对端窗口为 0 或网络拥塞。
7. 那些"看似正常但就是慢"的 TCP 坑，逐个拆给你看
7.1 网卡 GSO/TSO 参数导致的"小包聚合"假象
开启 TSO（TCP Segmentation Offload）和 GSO 后，TCP 发给网卡的是一个很大的数据包，由网卡硬件负责按 MSS 分片。这能大幅降低 CPU 开销，但也带来一个现象：抓包时 tcpdump 看到的是分片后的小包，而不是内核视角的大包。有时候 TCP 重传判断异常，需要先确认抓包位置是否在 TSO 之前。
排查方法：ethtool -k eth0 查看 TSO 状态，ethtool -K eth0 tso off 可以临时关闭。如果关闭后问题消失，基本可以确定与硬件分片相关。
7.2 局域网内 RTT 低但吞吐低，可能是初始窗口太小
有些场景内网 RTT 只有 0.2ms，但如果连接只传几 MB 的小对象，还没等窗口涨起来就发完了。此时如果初始窗口太小，吞吐必然受限。Linux 默认初始拥塞窗口是 10 个 MSS，也就是 14600 字节。按 0.2ms RTT 算，一个 RTT 内最多发 14600 字节，10 个 RTT 才 146KB，很多小请求只有几 KB 到几十 KB，根本没机会涨窗口。
调大初始窗口参数 net.ipv4.tcp_init_cwnd 到 20 甚至 30，对短连接收发小对象场景提升明显。需要注意这是主机全局配置，最好确认所有正常应用都能接受更激进的初始行为。
7.3 四次挥手里的 FIN_WAIT_2 和 RST 攻击
收到 FIN 后进入 CLOSE_WAIT 的应用迟迟不 close，服务端会一直处于 FIN_WAIT_2。虽然 Linux 有 net.ipv4.tcp_fin_timeout（默认 60 秒）兜底，但大量 FIN_WAIT_2 往往意味着应用没有正确关闭连接，需要先从代码角度排查。
RST 则更粗暴。任何一台主机都可以向连接发送伪造的 RST 包，如果序列号恰好落在接收窗口内，连接立刻被断开。这种攻击在公网环境尤其常见。应对方案是启用 MD5 签名选项（TCP_MD5SIG），或者把服务放在受信任内网中。这个在很多生产事故里都被怀疑过——抓包发现大量 RST，其实只是中间设备或对端主动发送的。
7.4 模拟丢包实验：亲手让 TCP 现原形
纸上谈兵永远不够，我建议你在本地搭一个实验环境，用 tc netem 模拟丢包，观察 TCP 行为。系统是 Linux，有 root 权限即可。
- 先建立两个网络命名空间或用两台虚拟机，配置好 IP。
- 在其中一端添加丢包规则：
bash复制tc qdisc add dev eth0 root netem loss 10%
- 跑 iperf3 测吞吐：
bash复制iperf3 -c 192.168.1.2 -t 30
- 在另一端同时抓包，观察重传和 DUP ACK：
bash复制tcpdump -i eth0 -nn tcp port 5201 -w /tmp/loss_test.pcap
你可以直观看到：无丢包时 iperf 吞吐接近带宽；加了 10% 丢包后，吞吐大幅下滑，抓包里出现大量重传、DUP ACK。接下来试试切换 BBR：
bash复制sysctl -w net.ipv4.tcp_congestion_control=bbr
再进行同样的传输，对比吞吐。通常在 10% 丢包下，BBR 比 Cubic 维持的速率高得多。这个实验做完，你对 TCP 拥塞控制和可靠传输对性能的影响，绝对比看十篇文章都深刻。
8. 为什么说"可靠传输"不是免费的：代价与边界
8.1 队头阻塞：TCP 可靠性的"阿喀琉斯之踵"
TCP 要求字节流严格按序交付，一个包的丢失会阻塞它之后所有已到达数据的交付，因为接收方缓冲区里即使有后续数据，应用层也读不到。这就是队头阻塞（Head-of-Line Blocking）。HTTP/2 在一条 TCP 连接上多路复用多个请求流，如果其中一个流的包丢了，同一条连接上的其他流也会被拖累。
这种设计在"单文件传输"场景下没毛病，但在"多请求复用同一链路"场景下就不划算。这也是 QUIC 协议选择基于 UDP 自研可靠传输、为每个流独立做可靠性和拥塞控制的原因。QUIC 的 Stream 之间互不阻塞，彻底解决了队头阻塞问题。如今 HTTP/3 就是跑在 QUIC 上的。
8.2 三次握手的开销不能忍，于是有了 Fast Open
短连接场景下，三次握手至少要消耗一个 RTT 才能开始传数据。对很多几百字节的小请求，这一个 RTT 的开销占了大头。TCP Fast Open（TFO）允许客户端在 SYN 包中就携带应用数据，服务端验证 TFO cookie 后直接处理数据，省掉一个 RTT。Linux 支持 TFO：sysctl net.ipv4.tcp_fastopen，取值 3 表示客户端和服务端都开启。不过需要应用显式使用对应的 socket 操作接口，实际部署并不算广泛。
8.3 可靠传输的未来：从内核到用户态
如今已经有很多高性能场景把 TCP 栈从内核搬到了用户态，比如 Intel DPDK、Solarflare Onload、DPDK 生态的 FStack。用户态 TCP 栈可以利用大页内存、无锁队列、轮询模式接收，规避内核协议栈的锁竞争和中断开销，实现数百万级并发连接。但这套东西复杂度极高，通用性也不如内核 TCP。
对绝大多数应用来说，理解并调优内核 TCP 已经足够。真正需要用户态协议栈的，往往是网关、负载均衡、高性能中间件这类专用系统。
9. 两个极其有用的内核参数清单，直接抄作业
最后整理一份我实际项目中经常用的参数清单，按场景分类，方便你直接做实验：
9.1 高并发短连接场景
bash复制# backlog 上限，建议调大
sysctl -w net.core.somaxconn=4096
sysctl -w net.ipv4.tcp_max_syn_backlog=8192
# 开启 TIME_WAIT 复用（只作用于主动连接发起方）
sysctl -w net.ipv4.tcp_tw_reuse=1
# 减少 FIN 超时时间，加速释放 FIN_WAIT_2
sysctl -w net.ipv4.tcp_fin_timeout=15
9.2 高带宽大 RTT 传输场景
bash复制# 加大 socket 读缓冲上限
sysctl -w net.core.rmem_max=16777216
sysctl -w net.core.wmem_max=16777216
# 加大 TCP 缓冲区动态范围
sysctl -w net.ipv4.tcp_rmem='4096 87380 16777216'
sysctl -w net.ipv4.tcp_wmem='4096 65536 16777216'
# 启用 BBR 拥塞控制
modprobe tcp_bbr
sysctl -w net.ipv4.tcp_congestion_control=bbr
# 关闭小包延迟（取决于应用）
# 应用层设置，不使用 Nagle
9.3 网络抖动较大、需要快速恢复链路
bash复制# 允许 SACK，提高多丢包场景的重传效率
sysctl -w net.ipv4.tcp_sack=1
# 开启时间戳选项，辅助 RTT 计算和 PAWS
sysctl -w net.ipv4.tcp_timestamps=1
# 降低 RTO 下限（数据中心场景谨慎）
sysctl -w net.ipv4.tcp_rto_min=50
要注意，tcp_rto_min 的单位是毫秒，但内核实际实现是 HZ/10 * 2 的倍数，并不完全按你写的最小值运作。对绝大多数人，我建议先理解参数含义再动手，别把网上抄来的一堆"优化脚本"直接丢到生产环境。内核参数的调整往往是一套组合拳，需要结合硬件能力、网络拓扑、应用模型综合评估。
个人经验是：不先明确问题，绝不动内核参数。改之前拍下 sysctl -a 相关项的基线值，改完观察一个业务周期，再决定回滚与否。TCP 调优是门"慢功夫"，但对服务稳定性和吞吐的回报非常直接。趁周末在自己测试环境把上面这些实验做一遍，你会对可靠传输这件事产生完全不同的敬畏感。