TCP/IP，服务端开发每天都要打交道的东西。但说实话，我这些年做技术面试，发现很多写了好几年业务的开发者，对TCP/IP的理解还停留在"三次握手四次挥手"这个层面。你让他说说SYN队列和accept队列的区别，说说TIME_WAIT为什么要等2MSL，说说Nagle算法和延迟ACK为什么会打架，基本就卡住了。
高性能服务器开发和普通业务开发有一个本质区别：普通业务开发把TCP当作一条"可靠的数据管道"来用，出了问题大不了重连重试；高性能服务器不行，你追求的高并发、低延迟、高吞吐，每一项都直接受TCP/IP协议机制约束。连接怎么建立、怎么维护、怎么关闭，数据怎么确认、怎么重传、怎么控制流量和拥塞，这些细节直接决定了你的服务器能不能撑住每秒几万甚至几十万的连接和请求。
这篇博文，我打算从协议原理和工程落地两个层面，把TCP/IP里那些和高性能服务器开发强相关的机制讲透，再结合我在实际项目里踩过的坑和调优经验，给出一份可以直接拿去用的排查和配置参考。适合正在做网络服务、中间件、网关、游戏服务器、消息推送系统，或者想往底层深入的开发者阅读。下文开始。
1. 先把TCP/IP这栋楼看清楚：分层模型与开发者的对应关系
1.1 四层模型不是理论，它决定你的代码写在哪一层
看懂协议栈之前，先理解一个核心问题：这栋协议楼为什么要分层？答案是，每一层都在解决一个特定的传输问题，层与层之间职责分离，上层不用关心下层的实现细节。OSI七层模型和TCP/IP四层模型都讲分层，但对开发来说，记住四层就够用了：链路层、网络层、传输层、应用层。
链路层解决的是"同一物理网络内怎么把帧从一台机器送到另一台机器"，网络层（IP协议）解决的是"数据怎么从源主机跨网络路由到目的主机"，传输层（TCP/UDP）解决的是"数据怎么从源进程可靠地送到目的进程"，应用层就是我们写的HTTP、自定义RPC协议等等。这个分层顺序不是随便排的，每一层都在上一层的基础上增加能力，同时屏蔽下层细节。
这个分层对高性能服务器开发有什么实际意义？举个例子：你遇到一个性能问题，首先得判断它发生在哪一层。客户端连不上服务端，可能是应用层代码的问题，也可能是传输层握手失败，还可能是网络层路由不通，排查手段完全不一样。再比如，你要调MTU（最大传输单元），这其实是链路层和网络层交界处的概念，MTU设置不合理会导致IP分片，分片后在传输层会表现为包丢失或重组开销大增，TCP性能直线下降。不懂分层，你就无法准确定位问题边界。
还有一个非常实用的理解：每一层头和尾的封装叠加过程。数据从应用层往下，每经过一层就加上该层的头部（某些层还有尾部校验），到了对端再逐层剥离。这个"逐层封装、逐层解析"的机制，直接解释了为什么抓包工具里你会看到以太网帧头、IP头、TCP头的完整叠加结构。写网络协议解析代码的时候，你就是在精确地处理这一层层头的偏移和字段。
1.2 面向连接与无连接：TCP和UDP的本质区别
TCP是面向连接的，UDP是无连接的。这句话被说烂了，但背后的工程含义值得展开。面向连接意味着什么？意味着在通信正式开始之前，两端要先建立一套"会话状态"。这套状态包括：各自的初始序列号、接收窗口大小、拥塞控制参数、发送和接收缓冲区指针等等。也就是说，有一个连接就有一份状态要维护，连接数量越大，内存和CPU开销越高。
UDP没有这套状态，它就是"发出去就不管了"，所以UDP能轻松做到比TCP高得多的吞吐量，但也因此丢包、乱序、重复都不管。对高性能服务器开发来说，这个区别影响深远。你选择TCP，就是选择用一部分资源去换可靠性；你选择UDP或基于UDP的QUIC类协议，就是把可靠性逻辑拿到应用层自己实现，以此换取更低延迟和更高灵活性。
我见过不少做游戏同步或者实时音视频的团队，最终放弃TCP改用UDP自己做可靠传输，核心原因是TCP的拥塞控制在某些低延迟场景下"太保守"，延迟抖动的表现不能满足业务要求。不过，绝大多数业务系统仍然以TCP为主，原因很朴素：TCP把可靠性、顺序性、流量控制、拥塞控制这些复杂问题都给你处理好了，应用层不需要重复造轮子。你要做的，是理解它的机制，知道在什么情况下它"不干活"或者"帮倒忙"，然后通过参数和代码去纠正。后文所有内容，都将围绕TCP展开。
2. 三次握手与四次挥手：连接生命周期里的资源账本
2.1 三次握手：连接建立的成本比你想象的高
TCP建立连接的三次握手，基本流程大家都清楚：客户端发SYN，服务端回SYN+ACK，客户端再发ACK。但高性能服务器开发者必须看清这背后隐藏的两个队列和几个必须调优的参数。服务端在收到第一个SYN后，并不是直接建立一个完整连接，而是先往半连接队列（SYN队列）里放一个条目，等到三次握手完成，再把连接转移到全连接队列（accept队列），等待应用层调用accept取走。
这两个队列都有长度限制，分别由系统参数和socket参数控制。SYN队列长度主要由net.ipv4.tcp_max_syn_backlog控制，accept队列长度由listen的backlog参数和net.core.somaxconn共同决定，实际生效取两者较小值。为什么要区分两个队列？因为半连接状态下，服务端还没有和客户端交换完建立连接所需的信息，链路尚不可信，不能直接交付给应用。这种"区分中间态和完成态"的设计，保证了应用层拿到的连接都是已经通过握手校验的。
问题来了：高并发场景下，如果连接请求速率超过内核处理能力，或者应用层accept不及时，队列就会溢出。SYN队列溢出时，内核会直接丢弃SYN包（开启SYN Cookie时可以部分缓解）；accept队列溢出时，表现为客户端连接成功但服务端长时间accept不到新连接。很多线上"连接闪断""连接卡住"的故障，根源都在这里。
实操建议：排查队列溢出，可以用netstat -s观察SYN overflow相关的统计计数，再用ss -lnt查看当前套接字的排队状态。调优时，somaxconn和backlog建议在实际负载压测下逐步加大，不要盲目调到天文数字，因为队列越大，握手完成但未处理状态下连接占用的内存就越多，极端情况下会把内存吃光。
2.2 四次挥手与TIME_WAIT：线上故障的高发现场
断开连接的四次挥手，流程上比三次握手复杂，因为TCP支持半关闭，任何一端都可以主动发起关闭。主动关闭方在发出最后一个ACK之后，会进入TIME_WAIT状态，持续2MSL（MSL是报文最大生存时间，典型值30秒到2分钟不等，Linux常见的是60秒左右）。TIME_WAIT存在的意义有两个。
第一，保证最后一次ACK能到达对端。如果这个ACK丢了，对端会重发FIN，而主动方还处在TIME_WAIT状态，可以重新响应；如果不等2MSL就直接关闭，对端重发的FIN会因为找不到对应连接而被RST，导致对端无法正常关闭。第二，让本次连接中残留在网络中的所有旧报文自然消亡，防止相同四元组的新连接接收到旧数据。这两个意义都是协议正确性的保障，不是多余的。
问题在于，2MSL等待期内，连接的四元组（源IP、源端口、目的IP、目的端口）是被占用的。高并发短连接场景下，比如网关、代理服务，每秒有大量连接被快速建立又快速关闭，TIME_WAIT连接会大量堆积，最终把文件描述符和内存耗尽，或者导致新连接无法复用端口而失败。这就是线上最常见的TIME_WAIT故障。应对层面，第五节我会给出具体排查和调优方案，这里先记住一个原则：TIME_WAIT是协议正确性的代价，不能为了消灭它而盲目关掉，那是拿可靠性换指标。
3. 可靠传输的三大支柱：确认、重传与窗口控制
3.1 序列号与累积确认：TCP怎么知道丢了和错了
TCP的可靠传输，第一块基石是序列号。每个字节流上的字节都有自己的序号，发送方发数据时会带上起始字节的序号，接收方收到后按序号重组，乱序也能纠正。初始序列号ISN不是从0开始的，而是通过时间戳等算法生成，目的就是防止旧连接延迟到达的报文被误认为是新连接的数据。
确认机制是累积的：接收方回复ACK时，携带的确认号表示"这个序号之前的所有字节都已收到"。比如发送方发了序号1到1000的数据，接收方收到后回ACK=1001，表示1000字节全部收到。这种累积确认实现简单，但缺点也明显：它不精确。如果中间丢了序号500到600的包，接收方只能对1到499的数据做累积确认，后续即使收到了1000之后的新数据，ACK号也不会前移，发送方需要靠重传机制来补救。
理解了累积确认，你就能明白为什么三个重复ACK会触发快重传：接收方收到乱序数据后，每收到一个超过当前累积号的数据包，就会立即回复当前累积确认号去提醒发送方"我这里缺了一块"。连续三个重复的ACK，意味着不是单纯的乱序抖动，而是这段数据很可能真的丢了。发送方这时候不等超时定时器，立刻重传缺失段，能显著降低丢包时的恢复延迟。
3.2 RTO超时重传：等待时间是怎么算出来的
如果数据包丢了，而接收方又没有足够的新数据触发重复ACK，TCP只能依靠超时定时器来兜底。这个定时器的值RTO（Retransmission Timeout）不是拍脑袋设的，而是基于RTT（往返时延）采样，用加权平均和平均偏差计算出来的。粗略地说，RTO会跟着网络延迟动态调整：网络慢，RTO变长；网络抖动大，RTO也会放大，目的是减少不必要的重传。
这里有个对性能影响极大的现象：在高延迟链路（比如跨地域专线）上，如果RTT是100毫秒，RTO通常会被计算到200毫秒以上。当发生一次真正的丢包且需要超时重传时，这个代价就是200毫秒的延迟空窗期。所以高性能系统的第一原则是：尽量避免走到超时重传这一步。能靠快重传解决的，说明网络还没有彻底堵死；快重传解决不了，那就是链路质量问题了。
3.3 滑动窗口：吞吐量的节流阀
有了序号和确认，TCP理论上就可以发了，但如果发一个等一个确认，网络利用率会低得可怕，尤其是在高带宽高延迟链路上，这种"停等"模式会把吞吐量压到极低。滑动窗口就是解决这个问题的：发送方允许在未收到ACK的情况下，最多发送窗口大小的数据。窗口越大，同一时刻在途的数据就越多，管道利用率就越高。
窗口大小并不是固定不变的。接收方会在每个ACK里带上自己的接收窗口（rwnd），告诉发送方"我的缓冲区还能收这么多"。如果应用层读数据慢，缓冲区快满了，接收方就会缩小通告窗口，甚至通告零窗口。发送方收到零窗口通告后必须停止发送，并定期发送窗口探测包。这个机制直接决定了"消费者速度"会反向压制"生产者速度"。
对高性能服务器开发来说，接收窗口这个参数非常实际：服务端socket的接收缓冲区大小（SO_RCVBUF）设得太小，会导致窗口频繁收紧，客户端发送速率被压制，整体吞吐上不去；设得太大，又可能造成内存浪费。现代内核大多支持接收窗口自动调节，但自动调节依赖一个良好的运行环境预设，在容器化、虚拟化环境下，内核参数经常被裁剪或覆盖，很多情况下需要手动明确设置。
3.4 拥塞控制：网络不好时TCP会自动踩刹车
滑动窗口解决的是接收方能力的问题，但发送方在网络中能塞多少数据，还取决于网络的承受能力。拥塞控制就是TCP用来探知网络承受能力的机制，核心算法从最早的Tahoe、Reno，到如今内核默认的CUBIC，以及高延迟长距离链路上很火的BBR，已经演进几十年。
经典流程是：连接刚建立时，拥塞窗口从很小的初始值开始，每收到一个ACK就翻倍增长，这叫慢启动，直到达到慢启动阈值ssthresh，之后转入线性增长，这叫拥塞避免。遇到丢包，如果是超时重传，拥塞窗口直接降到初始值，重新慢启动；如果是快重传恢复，窗口减半，进入快恢复。这套机制保证了TCP在网络拥堵时会主动降速，避免把大家都挤爆。
知道这个背景后，很多性能现象就讲通了。比如，一个长连接闲置很久后突然发大流量，它其实又回到了慢启动状态，吞吐量需要一段时间才能爬升。在高性能架构里，连接池的预热、TCP连接的复用策略、甚至部署BBR这类新拥塞算法，本质上都是在和慢启动机制做博弈。你不需要实现算法，但你必须理解它何时限制你的吞吐，才能在设计上规避。
4. 高性能服务器开发落地：从socket选项到内核参数
4.1 四个必须掌握的socket选项
理论讲完，进入实践环节。高性能服务器的代码层面，有几个socket选项几乎每个项目都会碰到，用错一个就掉一个坑。
第一个是TCP_NODELAY，开启后禁用Nagle算法。Nagle算法的初衷是减少小包数量：发送方在没收到前一个包的ACK之前，不发送新数据的小包，先把数据攒着合并。听起来很合理，但它和TCP延迟ACK（接收方延迟200毫秒左右再回复ACK，以便合并多个确认）一组合，就成了经典的"互相等待"死锁：发送方等ACK，接收方等更多数据才回ACK。交互类应用一旦遇到这个组合，延迟能飙到几百毫秒。所以对延迟敏感的服务器，几乎一律开启TCP_NODELAY。这是我踩过的最早也最痛的一个坑。
第二个是SO_KEEPALIVE。TCP本身没有严格心跳机制，保活探测默认两小时一次，太疏了，很多应用层会自己设计心跳。如果要依赖内核保活，必须同时设置TCP_KEEPIDLE、TCP_KEEPINTVL、TCP_KEEPCNT三个参数，让保活探测变得频繁且可控。注意，保活探活只能发现"对端完全不可达"，不能发现"对端进程卡死"。很多线上"连接假死"问题，就是因为只依赖了默认保活参数。
第三个是SO_REUSEADDR。服务端在监听socket上设置它，允许重启时绑定端口，即使有TIME_WAIT状态的连接存在。没有它，服务器重启后立刻bind端口会失败，这是开发调试期最常见的报错。值得注意，很多人为了处理大量TIME_WAIT，会给客户端socket也加SO_REUSEADDR，这在多数场景下是无效的，客户端主动关闭产生的TIME_WAIT需要其他机制配合，后文会讲。
第四个是SO_RCVBUF和SO_SNDBUF，它们直接决定socket收发缓冲区大小，进而影响TCP通告窗口和吞吐能力。手动设置时注意，内核实际值会翻倍（因为要预留一部分给内核头部开销），而且设置后要和系统自动调节参数协调，否则会被自动调整逻辑覆盖。建议先在测试环境实测吞吐量，再根据瓶颈确定buffer大小。
4.2 IO模型与多路复用：高并发的真正秘密
协议机制之外，服务器的IO模型决定你能不能撑住那么多连接。在高性能服务器领域，经典的演进路线是：阻塞IO加多线程，到非阻塞IO加多路复用，再到异步IO。对Linux来说，实际主流方案就是epoll。
epoll解决的核心问题有两个。第一，不需要每次轮询所有连接来判断哪个有事件，内核直接通知你哪些文件描述符就绪了，复杂度从O(N)降到O(就绪连接数)。第二，水平触发（LT）和边沿触发（ET）两种模式给了开发者精细控制权。LT模式下，只要缓冲区还有数据，每次epoll_wait都会通知你，代码简单，但可能重复通知；ET模式下，只有状态变化才通知一次，你需要一次性把数据读完，否则可能漏数据。
我个人的经验是，新手做项目优先用LT，逻辑简单不容易出错；对性能有极致要求、对协议理解已经很深的老手再上ET。ET省掉了一些系统调用，但代价是代码复杂度陡增，数据没读完就漏事件的坑，真的是踩一次记一辈子。另外，不要在新代码里再用select和poll，连接数一上千，它们的性能劣化非常明显。如果真有跨平台需求，也优先考虑封装好的事件库，而不是自己裸写。
4.3 内核参数调优清单：一份需要压测验证的配置参考
代码层搞定后，操作系统层还有几个关键参数直接影响TCP性能。下面是我在多个项目里验证过、相对稳妥的一组配置思路，具体数值要根据机器内存、业务特点去压测调整，不要直接照抄。
关于net.core.somaxconn，它是全连接队列的上限，建议大于128，并且要配合应用层listen的backlog一起调。很多框架默认backlog是128，但如果你把somaxconn调大了，而listen的backlog没跟着改，最终生效的还是那个较小的值。实际项目中我习惯把两者都设为1024以上，然后观察accept队列水位再微调。
关于net.ipv4.tcp_max_syn_backlog，它是半连接队列上限。高新建连接速率（CPS）的业务建议调大，同时确保内核开启了SYN Cookie机制，这样即使SYN队列满，服务端也能通过Cookie完成握手验证，而不是简单丢包。这个参数在遭遇突发流量时，往往是第一道防线。
关于net.ipv4.ip_local_port_range，它限制客户端可用端口范围。做大量出站短连接时，这个范围直接决定理论并发上限。默认32768到60999，可用端口数约两万多个，如果瞬时出站连接数接近这个量级，端口就不够用了，表现就是connect失败频繁。可以适当扩大范围，但要注意端口号区间过大，TIME_WAIT管理成本也会上升。
关于net.ipv4.tcp_fin_timeout，它是FIN_WAIT_2状态的超时时间。调小可以更快回收异常半关闭连接，但这个参数不建议设得太激进，否则正常的长连接半关闭流程也会受影响，我一般设置30秒到60秒之间。
关于net.ipv4.tcp_max_tw_buckets，它是系统TIME_WAIT总量上限，超出后新TIME_WAIT会被立即清除并打印告警。这个参数不要盲目调大，应该在确认"真的是TIME_WAIT堆积导致资源耗尽"之后，再结合业务调整。很多时候，调大了只是把症状往后推。
关于net.ipv4.tcp_tw_reuse，它允许在相同四元组前提下，将处于TIME_WAIT的连接用于新的出站连接。对客户端场景有效，服务端场景无效，安全坑较少，可以开启。而net.ipv4.tcp_tw_recycle这个参数，新版本内核基本已经废弃了，但在老内核上仍然存在，开启后会因为NAT场景下的时间戳问题，导致大量合法连接被RST。这是真实踩过的坑，建议一律不要开，哪怕网上教程写它"性能提升明显"。
调这些参数前，先用sysctl -a查看当前值，改完用sysctl -p生效，并且一定要在测试环境压测验证。生产环境改动内核参数，务必走变更评审流程，准备回退方案。TCP参数之间存在耦合，一个参数的调整可能放大另一个参数的问题，所以一次只改一个参数，做好记录，是我一直坚持的习惯。
5. 线上问题排查实录：从现象到原因的完整链条
5.1 连接建立慢且经常失败：先看握手队列是不是满了
某次协助一个做消息推送的团队排查问题，现象是客户端连服务端经常超时，但偶尔又能成功，成功时延迟忽高忽低。很多人第一反应是去查应用代码，但我们先看了netstat -s的输出，SYN重传计数异常地高，配合ss -lnt看到accept队列的使用率长期接近上限，问题很快就锁定了：accept队列溢出。
定位路径是：先确认服务端进程的accept是不是卡住了，用strace看系统调用；再确认listen的backlog和somaxconn的配置是否匹配；最后看压测下的队列占用。最后发现是该团队在某次版本升级后，把listen的backlog从1024改成了512，却没有同步检查somaxconn，导致最终生效值变小。改回去并重启服务后，连接成功率恢复。
这类问题的核心排查思路是：不要猜，直接看内核的统计计数。netstat -s里的listen queue overflow、SYN dropped、times SYN retransmitted都是重要线索。配套工具是ss -lnt，可以显示当前已建立连接数和排队等待accept的连接数，能直观量化队列水位。监控系统里最好长期采集这些指标，队列溢出往往是一个渐进过程，提前告警比事后排查有价值得多。
5.2 TIME_WAIT堆积：处理方案分场景
短连接密集型的服务，TIME_WAIT几乎是绕不开的。碰到的典型场景是某内部网关，需要大量转发RPC请求，运行一段时间后进程句柄数告警，ss -s显示TIME_WAIT数量接近五位数。排查后确认，这些TIME_WAIT主要来自网关主动关闭出站连接：它每转发一个请求就新建一次到下游的连接，请求完毕立即close。
这个架构设计本身就有问题，短连接在转发场景里放大了TIME_WAIT成本。最终的修复组合分三层。第一层，把转发连接改成长连接复用，用连接池管理到下游的连接，从源头上减少连接建立和关闭的频率，这是最关键的一层。第二层，配置net.ipv4.tcp_tw_reuse，让出站连接可以适当复用TIME_WAIT的四元组。第三层，对确无复用价值的空闲连接，调低tcp_fin_timeout，加速FIN_WAIT_2回收。
这套组合处理下来，TIME_WAIT数量降了一个量级。但我要强调，三层里真正起决定性作用的是第一层的架构调整，后面的内核参数只是锦上添花。遇到TIME_WAIT堆积，先想业务层能不能减少连接创建频率，再动内核，这个顺序不能反。如果架构短期改不动，又需要顶住压力，tcp_max_tw_buckets和端口范围调整可以作为临时止血手段。
5.3 小包延迟高得离谱：Nagle与延迟ACK的经典冲突
另一个高频问题：服务端返回一个很小的响应，客户端却要等很久才收到。抓包一看，服务端发出的数据包数量非常少，都攒在缓冲区里不发，明显是Nagle算法在起作用。而客户端那边因为交互模式的关系，又因为延迟ACK的存在，迟迟不确认之前的包。两边都在等，延迟就越拖越大。
解决方法就是前文提到的TCP_NODELAY，在服务端socket上加这个选项，问题当场消失。这里多说一句：很多现代网络库、框架已经把TCP_NODELAY默认加上了，但如果你在做自定义协议、裸socket编程，一定要记得自己处理。另外，如果协议本身要求高吞吐、不要求低延迟，保留Nagle算法反而能减少小包数量、提升带宽利用率，所以不要无脑"能开就开"，要看业务场景。
延迟ACK也不是一无是处，它通过合并多个确认来减少网络中ACK包的数量，在纯下载、大块数据传输场景下能提升效率。冲突只在"交互式小包请求"这个场景最明显。判断标准很简单：抓包看两端是否形成"一方攒包不发送、一方攒确认不回复"的循环，如果有，TCP_NODELAY就是标准解药。
5.4 长连接莫名其妙被断开：看看是谁把连接杀掉的
长连接服务还会遇到一类问题：连接保持十几个小时后突然被对端关闭，或者长时间空闲后一发数据就报错。常见元凶有几个。第一，中间网络设备（比如负载均衡、防火墙）对空闲连接设置了超时回收策略，TCP对端感知不到空闲连接被清理，等到数据发送时才发现连接已死。应对方法是在应用层设计心跳，或者开启并调短TCP保活参数，让空闲连接有持续的探测流量。
第二，进程侧用了SO_KEEPALIVE但参数是默认值，两小时才开始探测，这在很多业务里远远不够。真实案例是某团队做了个长连接推送服务，运维层面LB的超时设置是5分钟，而客户端心跳周期设置成了10分钟，结果每15分钟左右就会出现大范围的连接假死。最后把心跳周期调到小于LB超时的一半，并且服务端、客户端两层的保活超时都对齐，问题才根治。
这类问题的排查思路是：分别在两端抓包，确认断开方是谁、断开时是什么样的TCP报文，就能快速锁定是被中间设备RST还是对端主动关闭。如果是中间设备的RST，特征是对端没有发过FIN，抓包里直接出现RST；如果是对端主动关闭，会有完整的FIN交换流程。定位到元凶后，再针对性地调整心跳周期或中间设备超时，问题通常能一次性解决。
6. 一些值得记住的经验
写到这里，核心内容已经差不多完整了。最后分享几个我在长期做服务器开发过程中沉淀下来的习惯。
第一，任何TCP性能问题，先抓包看真相，不要凭感觉调参数。tcpdump加Wireshark的组合，能把三次握手耗时、重传频率、窗口变化、零窗口通告这些底层信号全部可视化。很多时候调了半天应用代码，最后发现是网络丢包率本身就不合格，这个顺序不能搞反。
第二，线上变更内核参数，一定要有回退预案。TCP参数之间有耦合，比如tcp_tw_reuse和某些时间戳机制的搭配，在一些老的虚拟化网络环境下会踩坑。我的习惯是：每次只改一个参数，独立压测，留好记录，确认有效再固化到配置管理里。不要一次性堆一堆参数上去，出了问题根本分不清是哪一项导致的。
第三，架构设计阶段就要考虑连接生命周期。不要在系统成型后再头疼TIME_WAIT和句柄泄漏，提前规划好连接池、心跳策略、优雅关闭流程，能省掉后面大量的夜间值班时间。连接是有成本的，确认、重传、窗口、拥塞，每一个机制都在替你操心数据的路怎么走。你要做的不是绕过它们，而是理解它们、配合它们，让协议栈在你的设计下发挥出应有的性能。
