先说个我对TCP/IP协议的真实感受不管你是做Java后端、Android还是嵌入式只要写网络相关的代码TCP/IP就是绕不过去的一道坎。很多初学者会把HTTP、HTTPS、TCP、UDP这些概念混在一起背真正出了问题又从哪一层查起都搞不清楚。这篇是TCP/IP协议的第二部分重点放在传输层的核心机制上三次握手为什么是三次而不是两次、四次挥手为什么是四次不是三次、重传和滑动窗口到底怎么配合、拥塞控制又是怎么避免网络被“堵死”的以及不同连接状态在线上系统里意味着什么。更直白一点说这篇内容适合两类人来读。一类是刚学完Java基础、开始接触网络编程的初学者需要把TCP的可靠性机制真正理解透而不是死记面试题答案另一类是已经写过一些网络代码、但遇到线上问题总是靠重启解决的开发者想补上“连接状态分析”“超时与重传排查”这些实战底子。看完这篇你至少能看懂抓包结果里的SYN、ACK、FIN分别代表什么能判断一条连接卡住是卡在哪一步也清楚为什么TCP连接池里的连接会有TIME_WAIT状态。1. 先理清TCP/IP分层里传输层到底在解决什么1.1 从“能连通”到“连通且可靠”TCP补上了什么TCP/IP协议族是一个分层模型每一层解决不同的问题。网络层负责把数据包从一台机器送到另一台机器它关心的是寻址和路由。但网络层不保证数据包一定能到达也不保证到达顺序、不保证不丢包。而传输层的TCP就是在网络层这个“尽力而为”的通道之上建立一套可靠性机制。怎么理解这件事想象你通过普通快递寄一箱瓷器快递公司网络层负责把箱子从一个城市运到另一个城市但路上可能磕碰、可能丢件、可能两箱货顺序颠倒。TCP要做的事情就是发货前和收货人约定好一套确认手续每发出一箱都要求对方签收没签收就重新发签收后发现顺序乱了就重新排序甚至还能根据双方的处理速度协调发货节奏。这套机制是TCP用几个核心手段实现的连接管理、序列号与确认应答、超时重传、滑动窗口、流量控制、拥塞控制。这些话看起来像背定义但它们每一个都对应着抓包里那些字段、代码里那些异常现象。把这几个机制串起来理解TCP就没什么神秘的了。1.2 端口、IP与套接字一条连接的唯一标识TCP建立连接之前首先要回答一个问题数据要发给哪台机器上的哪个程序IP地址负责“哪台机器”端口号负责“哪个程序”。IP加端口组合成一个套接字Socket地址比如192.168.1.10:8080和192.168.1.11:52340这一对套接字就唯一定义了一条TCP连接。这里有个容易忽略的点一条TCP连接是由四元组决定的也就是源IP、源端口、目的IP、目的端口。很多人写代码时只关心目的地址但排查连接数量时会发现一台服务端机器上同一个端口可以对应成千上万个连接原因就是每个客户端的源IP和源端口不同四元组也不同。对应到Java开发里ServerSocket监听某个端口时操作系统会维护一个监听队列Socket发起连接时内核会临时分配一个源端口。这些底层逻辑虽然不是Java语法层面的东西但理解了它你就能明白为什么连接数一多会报Too many open files为什么服务端主动断开连接后端口会处于TIME_WAIT。2. 三次握手的时序拆解为什么必须是三回2.1 一个完整的SYN、SYNACK、ACK过程TCP在传输数据之前先要建立一个连接。这个建立过程就是经典的三次握手。我见过很多初学者背“客户端发SYN、服务端回SYNACK、客户端再回ACK”但还是不理解中间状态的含义。这里用一个真实抓包时序来看会更清楚。假设客户端是10.0.0.2服务端是10.0.0.3服务端监听8080端口。三次握手对应的包长这样1. 10.0.0.2:52340 - 10.0.0.3:8080 [SYN] Seq1000, Win64240, MSS1460 2. 10.0.0.3:8080 - 10.0.0.2:52340 [SYNACK] Seq2000, Ack1001, Win65535, MSS1460 3. 10.0.0.2:52340 - 10.0.0.3:8080 [ACK] Seq1001, Ack2001, Win65535第一步客户端把标志位SYN置为1随机生成一个初始序列号Seq1000发送给服务端。这个序列号不是从0开始而是内核随机生成的主要目的是防止旧连接的数据包被误认为是新连接的数据。第二步服务端收到SYN后如果资源允许会同时回复SYN和ACK两个标志位其中Ack1001表示“我收到了你1000号报文下一个期待1001号”Seq2000是服务端自己的初始序列号。第三步客户端回一个纯ACKAck2001表示收到服务端的序列号。这三次交互之后双方都确认了“我能发数据给你你也能发数据给我”连接才算建立。2.2 为什么不能是两次也不能是四次这个问题是网络面试里最高频的问题之一。原因一句话就能说清两次握手无法让发送方确认自己的发送能力正常也无法防止历史重复连接初始化请求突然到达服务端。详细展开一下。如果只有两次握手也就是客户端发SYN、服务端回SYNACK就认为连接建立那么客户端不会对服务端的序列号做确认。一但客户端发出的SYN因为网络阻塞延迟到达服务端服务端收到后建立连接、等待数据但客户端那边可能已经超时放弃、重新发起了连接旧的那个SYN包才慢吞吞地到达服务端服务端就会建立一条客户端根本不知道的“幽灵连接”白白占用资源。三次握手里客户端最后一回ACK可以看作对前两次信息的再确认更关键的是它可以携带客户端已经知道的信息来“兜底”。如果客户端发现对方ACK的序列号不是自己期望的就知道这是历史连接直接发RST终止它。这就是三次握手比两次握手多出来的一回的最核心价值。至于为什么不是四次就简单了因为三次已经能达到各自确认收发能力、同步初始序列号的目的再多一次只是信息冗余没有实质意义。TCP设计追求的是够用和有效而不是绝对完美。2.3 Java Socket中握手失败的常见表现用Java写一个最简单的TCP连接代码可能就几行Socket socket new Socket(10.0.0.3, 8080);这一行代码背后JDK和操作系统会完成三次握手。如果握手失败最常见的异常就是ConnectException: Connection refused或者SocketTimeoutException: connect timed out。这两类异常对应的原因完全不同Connection refused意味着服务端收到了SYN但目标端口没有进程监听或者监听队列已满内核直接回了RST包如果是半连接队列满则可能直接丢弃SYN。connect timed out意味着客户端发出SYN后一直没有收到服务端的SYNACK客户端设置的连接超时时间到了。我给初学者的建议是遇到连接异常时先判断是“没到服务端”还是“到了但被拒了”。前者多半是网络不通、防火墙拦截后者多半是服务没起来、端口没监听、队列满。判断方法很简单在服务端机器上执行ss -lntp看端口监听状态或者在客户端机器上执行telnet 10.0.0.3 8080试探看是超时还是拒绝。3. 可靠传输的秘密序列号、确认应答与超时重传3.1 序列号的职责不止排序TCP把应用层的数据当成一个无结构的字节流每一个字节都会有一个序列号。发送方在发送一段数据时报文的序列号是这段数据第一个字节的编号接收方收到后确认号则是它期望收到的下一个字节的编号。举个例子。假如客户端要发送1000个字节给服务端第一个字节的序列号是1001那么这批数据的TCP头里Seq1001。服务端收齐后回一个Ack2001意思是“你从1001开始发到2000一共1000个字节我都收到了接下来请从2001继续”。这个机制的好处是TCP不用管应用层怎么分割消息只看字节流本身。对应到Java开发里就是OutputStream.write()发送的数据底层可能被TCP拆成多个段发送也可能多个write()合并成一个段发送。所以写网络编程时网络层根本没有“消息边界”的概念你需要自己设计协议来划分消息长度比如自定义一个数据长度 数据体的结构。很多人第一次写Socket通信时发现收到的数据和发送时对不上就是这个原因。3.2 超时重传的时间怎么定数据包发出去后如果迟迟等不到ACK发送方就要重传。但“等多久”是个很有讲究的问题。时间定得太短ACK还在路上就重传会白白造成网络冗余定得太长一旦丢包应用层的感知延迟就会很大。TCP实际采用的是自适应算法会根据网络的实时往返时间动态调整。计算方式叫加权移动平均每次测量到一个RTT样本就用一个系数加权更新SRTT (1 - alpha) * SRTT alpha * RTT // 平滑往返时间 RTO beta * SRTT // 超时重传时间传统实现中alpha取1/8、beta取2也就是说超时时间大概是平滑往返时间的两倍。现代的Linux内核实现还会引入Karn算法和抖动因子这里不多展开。理解核心思想就够超时时间不是写死的而是跟随网络状况动态变化的网络越差RTO越大重传越谨慎。实操中你会更容易感受到另一个现象如果TCP触发超时重传随着重传次数增加RTO会进一步放大一般会加倍。比如第一次超时1秒第二次可能变2秒第三次4秒直到超过上限。这就是为什么网络很差时应用层会感觉连接“卡死”很久才报错。3.3 快速重传与重复ACK如果发送方只靠超时重传效率会很差。好在TCP还有快速重传机制。它的原理是接收方如果收到乱序的数据段会立即重复发送它期望的那个序列号的ACK而不是等数据齐了再统一确认。发送方如果连续收到3次同样的重复ACK就认为中间那个包丢了不等RTO超时立刻重传。这个机制对应到一个经典排查场景你看到一个慢查询或者接口偶发延迟抓包一看没有超时重传但有一大片重复ACK。这通常意味着网络里发生了乱序或者有轻微丢包快速重传机制正在忙着补救。这种情况光看应用层日志可能完全看不出来因为TCP把包给兜住了但延迟已经上去了。4. 滑动窗口与流量控制让收发双方不拖后腿4.1 窗口大小决定一次能发多少数据如果不加任何限制TCP每发一个段就等一个ACK那效率会非常低尤其在高延迟链路上。滑动窗口就是为了解决“等待确认”带来的空窗问题允许发送方在收到ACK之前连续发送多个段只要总量不超过窗口大小。窗口大小由接收方的接收能力决定。接收方的内核缓冲区剩余空间越大通告给发送方的窗口就越大反之缓冲区快满了窗口就会缩小到0通知发送方“先停下来我处理不过来”。这就是流量控制。这个字段就是TCP头里的Window。抓包的时候要注意这个值是接收方通告给发送方的决定的是发送方能发多少数据。有些网络优化工具或者配置里会把双方的Socket缓冲区调大本质就是让通告窗口变大允许更多数据在途。4.2 窗口为零时发生的窗口探测窗口变成0之后发送方就不能再发数据了只能等接收方重新通告一个更大的窗口。问题来了如果接收方后来处理完了数据发送了一个窗口更新包但更新包又丢了怎么办双方不就会死等吗TCP的解决办法是坚持定时器。发送方在窗口为0时会定时发出一个1字节的窗口探测包接收方必须回复当前的窗口值。如果窗口还没恢复就回复窗口仍为0如果恢复了多少就回复新值。这个机制的细节不用深啃但线上遇到问题要能认出来抓包时看到大量1字节的包同时窗口字段为0说明接收方处理不过来连接处于停滞状态。对应到Java服务里一个很典型的现象是如果你往Socket的输出流里写入数据阻塞在write()方法上了很可能就是因为对端的接收窗口为0TCP不让你继续发了。很多人以为是Java方法本身的问题实际上是传输层的流控在起作用。4.3 零窗口、糊涂窗口与Nagle算法的关系接收方回复窗口更新时有时会出现只腾出一点空间的情况比如1字节。如果发送方真的只发1字节那网络利用率就很差因为TCP头就有几十字节加上IP头传输一字节的代价太高。TCP专门有一个算法叫Nagle算法规定连接上最多只能有一个未被确认的小报文段后续的小数据先合并等ACK来了或者数据攒够一个MSS再发送。这个算法对Java网络编程有一个直接影响如果用Socket.getOutputStream().write()一个字节一个字节地写数据尤其写完后不立即flush会发现数据迟迟发不出去必须在积累到一定程度或者收到ACK后才发送。如果业务场景需要低延迟通常会调用setTcpNoDelay(true)关闭Nagle算法代价是可能增加一些小包在局域网内基本无感在移动网络下会损伤带宽效率。我处理过一个实时消息推送业务延迟总是抖动排查后发现服务端开启了Nagle、客户端开启了延迟ACK两种机制叠加导致小数据包被搁置等待关闭Nagle后延迟立刻好转。5. 拥塞控制替整个网络踩刹车的机制5.1 慢启动与拥塞避免的配合流量控制关注的是收发双方的缓冲能力拥塞控制关注的却是整条链路上所有设备的承载能力。如果发送方不考虑中间路由器的转发能力一股脑把大量数据灌进去路由器缓冲区溢出就会丢包大量重传进一步加剧拥塞网络雪崩。TCP的拥塞控制机制基本就是一套“先试探、再加速、超限就减速”的策略。发送方维护一个拥塞窗口流量控制里还有一个接收窗口实际发送量取这两个窗口的较小值。拥塞窗口刚建立连接时只有几十个字节之后的增长速度遵循两个阶段慢启动阶段窗口指数增长。每收到一个ACK窗口增加一个MSS1变2、2变4、4变8看起来叫“慢”实际增长非常快。当窗口达到一个门限值ssthresh转入拥塞避免阶段改成线性增长每一轮往返时间窗口只增加1个MSS。这里我补充一个直观理解指数增长是为了快速占满链路线性增长是为了靠近瓶颈时不要冲过头一旦发生丢包或确认异常门限值会减半、窗口回落然后重新走慢启动。这套机制保证TCP永远不会一次把网络打垮。5.2 从超时重传到快速恢复Linux下TCP拥塞控制有多个实现版本比如Reno、Cubic、BBR。Reno里有一个经典过程如果发生超时重传说明网络可能严重拥塞发送方把ssthresh设为当前窗口的一半窗口直接降到1个MSS重新开始慢启动。如果只是收到3个重复ACK触发快速重传说明网络还有响应能力窗口先降一半再进入快速恢复阶段收到新的ACK后可以快速恢复到门限值附近。实际部署的系统里现代服务器普遍使用Cubic它是Linux默认的拥塞控制算法适合高带宽长距离网络。但容器或云平台有时会启用BBR这类基于瓶颈带宽反馈的算法。做Java后端时一般不需要修改内核拥塞控制算法但了解它的存在是必要的因为在跨机房或者专线场景里如果你看到带宽利用率上不去、实际速率远低于链路容量排查方向可能就要从应用代码转向TCP参数本身。5.3 线上慢接口排查时怎么隔离拥塞因素遇到过一种很典型的情况某个服务的接口在晚高峰延迟明显飙升应用日志显示数据库查询很快CPU和内存都正常全链路监控也看不出哪个节点慢。后来抓包才发现机房到另一个机房的骨干链路在高峰时出现丢包TCP频繁触发拥塞控制发送窗口被压缩到很低吞吐量瞬间下降。排查这类问题时一个非常好用的方法是看统计信息。在服务端执行ss -s可以看到当前的TCP重传情况或者用nstat -z TcpExtTCPRetrans查看重传计数。如果重传率持续高于一定水平就要开始怀疑链路质量。另一个技巧是用ping加大包和mtr看中间跳的丢包率能快速定位是哪一跳在丢包。我自己总结的排查顺序是先看应用日志有没有超时异常再看TCP连接状态有没有大量非ESTABLISHED然后抓包看有没有TCP重传或者重复ACK最后用链路层工具确认物理链路。按照这个顺序大部分网络问题都能在十分钟内定位到具体层面。6. 四次挥手与连接状态连接的半关闭与资源释放6.1 FIN和ACK的你来我往TCP连接是全双工的数据可以双向流动。所以要关闭一条连接时理论上每一方都需要单独确认“我不再发数据了”。这就是为什么挥手需要四次而不是三次。一个完整过程如下1. 主动关闭方 - 被动关闭方 FINSeqM 2. 被动关闭方 - 主动关闭方 ACKAckM1 3. 被动关闭方 - 主动关闭方 FINSeqN加上它想发送的剩余数据 4. 主动关闭方 - 被动关闭方 ACKAckN1中间之所以分开是因为步骤2的ACK只是告诉主动方“我收到了你的FIN”但被动方可能还有数据没发完。它需要先把手头数据发完再发自己的FIN。如果恰好被动方数据也发完了从抓包角度看第2和第3步可能合并成一步看起来像三次挥手。很多文章默认四次实际上抓包时常见的是三次因为合并ACK很常见。6.2 TIME_WAIT、CLOSE_WAIT与线上故障四次挥手两个状态值得重点关注。先看TIME_WAIT主动关闭方发出最后的ACK之后不会立即关闭连接而是进入一段时间的等待状态Linux下默认是60秒。等待的目的是防止最后一个ACK丢失后被动方重发FIN所以主动方要留下来再处理一次。这个状态下连接的四元组还占着资源大量TIME_WAIT会让端口被占满服务器处理新连接的能力下降。再来看CLOSE_WAIT被动关闭方收到对方的FIN并回复ACK后就进入这个状态此时被动方要调用close方法释放连接。如果程序里忘记关闭Socket或者IO流没释放句柄就长期处于CLOSE_WAIT数量会一直累积。这是Java服务里最常见的连接泄漏问题。我在排查过分享一个小案例。某应用运行几天后开始拒绝新连接ss -lntp一看服务端有几千个CLOSE_WAIT。顺着代码找发现某个分支异常后没有在finally块里关闭Socket和输入输出流。修正为try-with-resources写法后CLOSE_WAIT数量立刻归零。所以线上排查时看到CLOSE_WAIT上涨第一反应应该是检查代码里的关闭逻辑而不是怀疑网络配置。6.3 Java编程中对连接关闭的常见误解初学者最容易犯的一个错误是在关闭Socket前只调用outputStream.close()以为数据发出去了。实际上close()会关闭整个Socket操作系统发送FIN此时你再查Socket状态会发现整个连接都断了。如果只是想告诉对端“我这个方向的写结束”应该调用socket.shutdownOutput()这样只发送FIN但还能继续读。另一个误区是误用setSoLinger。默认关闭Socket时send缓冲区里如果还有数据操作系统会尝试发送完后才返回或者直接返回丢弃。有些开发者调这个参数想加快关闭速度结果反而导致数据丢失。一般情况下不要动这个设置默认行为足够安全。7. TCP与UDP怎么选Java开发中的典型场景对比先给一个结论TCP适合要求可靠、有序、数据完整性的场景UDP适合实时性要求高、能容忍少量丢失的场景。做Java后端时不要用“感觉”来选而是根据业务可容忍的故障模式来定。应用层自己封装可靠传输的代价很高所以轻易不要用UDP来替代TCP。只有在明确需要UDP特性的场景才值得视频会议丢几帧无所谓但不能卡、语音通话延迟敏感、实时游戏位置同步数据高频更新重传旧状态没有意义、日志上报丢了就丢了不能用重传阻塞主流程。用一张表总结两者的关键差异特性TCPUDP连接状态面向连接需要三次握手无连接直接发数据报可靠性确认应答、重传、排序不保证送达、不保证顺序传输方式字节流数据报流量控制/拥塞控制有没有传输效率相对低有额外开销相对高几乎无开销粘包半包问题需要自己解析边界系统保留消息边界拿Java举例Netty框架既支持TCPNioSocketChannel也支持UDPNioDatagramChannel。写TCP时需要定义编解码器解决粘包和半包写UDP时不需要每个DatagramPacket就是一条独立消息。这就是“数据报”和“字节流”的实际差异带来的编码差别。8. 抓包实操用一次真实的HTTP请求看懂TCP细节8.1 抓包工具与基本过滤这一节讲实操。抓包工具我用得最多的是tcpdump和Wireshark的组合。tcpdump适合在服务器上轻量抓取输出文本格式适合快速过滤Wireshark适合深度分析图形化界面看时序图非常直观。抓包的核心思路是在客户端和服务端的网络路径上随便挑一个点捕获经过的TCP报文。对于本机调试最简单的用法是tcpdump -i lo port 8080 -w tcp.cap这个命令监听回环接口的8080端口写入tcp.cap文件。抓完用Wireshark打开能看到完整的握手、数据交互和挥手过程。注意过滤条件里写tcp port 8080而不是只写port 8080这样可以过滤掉同端口上的UDP报文。如果想实时看握手报文可以配合-nn参数关闭域名解析让输出更干净tcpdump -nn -i eth0 tcp port 80808.2 从抓包结果里看真实参数抓出来后你会看到类似下面的输出IP和端口做了脱敏23:57:30.111111 IP 10.0.0.2.52340 10.0.0.3.8080: Flags [S], seq 4010582127 23:57:30.111256 IP 10.0.0.3.8080 10.0.0.2.52340: Flags [S.], seq 2790581231, ack 4010582128 23:57:30.111312 IP 10.0.0.2.52340 10.0.0.3.8080: Flags [.], ack 2790581232这里Flags字段的字母分别代表S是SYN点是ACKF是FINR是RST。seq和ack两个字段反映了序列号的增长方向。如果看到某个seq被反复发送说明发生了重传如果看到大量[P.]标志的包说明数据载荷正在传输P表示PSH意思是“数据已经准备好请立即交付给应用层”。我建议初学者至少亲手抓一次本机HTTP请求的包然后逐一确认三次握手、请求数据、确认包、四次挥手这一整条链路。看完一次之后TCP对你来说就不再是抽象概念了你能够直接说出“哦这个包是TCP层的确认不是HTTP层的响应”。9. TCP参数调优与常见问题的速查表9.1 几个高频出现的Linux内核参数线上干活的时候官方文档和教程不会告诉你的一个点是Linux内核里有一些TCP参数直接决定了连接能否建立、能建多少、能活多久。Java应用层代码写得再好下面的参数不对也白搭。我把最常见的几个列出来方便大家排查时查阅参数作用建议net.ipv4.tcp_syncookies半连接队列满时是否开启SYN Cookie通常1开启net.ipv4.ip_local_port_range本地自动分配端口范围适当扩大比如1024-65000net.ipv4.tcp_fin_timeoutFIN_WAIT_2状态超时默认2分钟必要时调整net.ipv4.tcp_tw_reuse是否允许TIME_WAIT连接重新使用开启有争议谨慎用net.ipv4.tcp_max_syn_backlogSYN半连接队列长度高并发按内存适当调大net.core.somaxconn全连接队列长度和Java中backlog参数配合尤其在用Java写高并发服务时ServerSocket的backlog参数和系统的somaxconn参数是叠加生效的。Java里传100但系统只有128实际能用的就是两者较小值。线上如果出现连接拒绝并不一定是服务崩了先看全连接队列是否被打满。9.2 常见故障现象与排查方向我在日常开发中把TCP相关故障归成几类遇到问题直接对照着查连接超时连不上先看服务进程是否存活、端口是否监听、防火墙是否放行再看目标网段是否可达最后抓包看SYN有没有回应。大量TIME_WAIT客户端主动频繁关闭连接时容易出现。如果TIME_WAIT占用导致端口耗尽优先检查代码里连接是否复用再考虑调整tw_reuse参数。大量CLOSE_WAIT服务端代码没有正确关闭连接优先排查IO流和Socket的生命周期管理。传输速度上不去优先看TCP重传率、带宽利用率、拥塞控制算法和Socket缓冲区大小。偶发请求延迟抓包看是否有重传、重复ACK、Nagle与延迟ACK叠加。这一套对照表是我实际工作中每次复盘都会用到的框架。它能让你在遇到故障时不是靠猜而是按层定位。9.3 避免乱调参数的一个原则最后提一个最重要的原则TCP参数不要看到别人的“优化配置”就盲目照搬。很多参数的修改会影响整个内核的网络路径对局部的“优化”很可能在另一种网络环境下变成灾难。比如把所有内核缓冲改大在局域网高压测试下吞吐提升明显但放到移动网络高丢包环境下大缓冲区反而让重传变得更加缓慢。我处理过一次事故某个团队为了让内网传输更快把所有socket的读写缓冲区调到了几百兆结果一个内存告警直接拖垮了应用进程。原因是内核缓冲区分配是在发送和接收路径上逐渐膨胀的连接一多内存占用远超预期。调参之前先确认你的网络瓶颈到底在哪一层是针对性地改而不是把所有参数都调成网上说的“最佳值”。10. TCP协议学习中的几个高阶建议很多初学者问我TCP协议学的时候有没有什么捷径。我的建议一直很朴素不要只看书要把抓包工具当成显微镜把网上那些半懂的面试题亲手验证一遍。比如你可以在本机起一个Java Socket服务端和客户端分别用tcpdump抓包然后观察三次握手的具体过程和连接关闭的状态变化。代码不用复杂十几行就够// 服务端 ServerSocket serverSocket new ServerSocket(8080); Socket socket serverSocket.accept(); byte[] buffer new byte[1024]; socket.getInputStream().read(buffer); socket.getOutputStream().write(pong.getBytes()); socket.close(); serverSocket.close();// 客户端 Socket socket new Socket(127.0.0.1, 8080); socket.getOutputStream().write(ping.getBytes()); byte[] buffer new byte[1024]; socket.getInputStream().read(buffer); socket.close();跑起来以后你会发现很多书上没有写清楚的细节比如ACK包往往不会单独出现而是“顺带”被捎带在下一个数据包里这就是TCP的延迟确认机制。这些真实体验比单纯背面试题有用太多。关于TCP/IP协议的网络层之上的这部分最后再给一个我自己的体会传输层的所有机制归根到底都是在“效率”和“可靠性”之间找平衡。三次握手、滑动窗口、拥塞控制、重传策略没有一个机制是孤立存在的。一旦把这些机制放进一条真实的物理链路里去理解你会发现TCP设计的每个细节都恰到好处这一步迈过去之后再回来看HTTP、Netty、数据库连接池这些上层技术理解速度会有明显的提升。之后如果你们有兴趣我可以继续写一篇TCP异常案例分析的文章把我们平时排查线上问题的那套方法完整拆出来。
先说个我对TCP/IP协议的真实感受不管你是做Java后端、Android还是嵌入式只要写网络相关的代码TCP/IP就是绕不过去的一道坎。很多初学者会把HTTP、HTTPS、TCP、UDP这些概念混在一起背真正出了问题又从哪一层查起都搞不清楚。这篇是TCP/IP协议的第二部分重点放在传输层的核心机制上三次握手为什么是三次而不是两次、四次挥手为什么是四次不是三次、重传和滑动窗口到底怎么配合、拥塞控制又是怎么避免网络被“堵死”的以及不同连接状态在线上系统里意味着什么。更直白一点说这篇内容适合两类人来读。一类是刚学完Java基础、开始接触网络编程的初学者需要把TCP的可靠性机制真正理解透而不是死记面试题答案另一类是已经写过一些网络代码、但遇到线上问题总是靠重启解决的开发者想补上“连接状态分析”“超时与重传排查”这些实战底子。看完这篇你至少能看懂抓包结果里的SYN、ACK、FIN分别代表什么能判断一条连接卡住是卡在哪一步也清楚为什么TCP连接池里的连接会有TIME_WAIT状态。1. 先理清TCP/IP分层里传输层到底在解决什么1.1 从“能连通”到“连通且可靠”TCP补上了什么TCP/IP协议族是一个分层模型每一层解决不同的问题。网络层负责把数据包从一台机器送到另一台机器它关心的是寻址和路由。但网络层不保证数据包一定能到达也不保证到达顺序、不保证不丢包。而传输层的TCP就是在网络层这个“尽力而为”的通道之上建立一套可靠性机制。怎么理解这件事想象你通过普通快递寄一箱瓷器快递公司网络层负责把箱子从一个城市运到另一个城市但路上可能磕碰、可能丢件、可能两箱货顺序颠倒。TCP要做的事情就是发货前和收货人约定好一套确认手续每发出一箱都要求对方签收没签收就重新发签收后发现顺序乱了就重新排序甚至还能根据双方的处理速度协调发货节奏。这套机制是TCP用几个核心手段实现的连接管理、序列号与确认应答、超时重传、滑动窗口、流量控制、拥塞控制。这些话看起来像背定义但它们每一个都对应着抓包里那些字段、代码里那些异常现象。把这几个机制串起来理解TCP就没什么神秘的了。1.2 端口、IP与套接字一条连接的唯一标识TCP建立连接之前首先要回答一个问题数据要发给哪台机器上的哪个程序IP地址负责“哪台机器”端口号负责“哪个程序”。IP加端口组合成一个套接字Socket地址比如192.168.1.10:8080和192.168.1.11:52340这一对套接字就唯一定义了一条TCP连接。这里有个容易忽略的点一条TCP连接是由四元组决定的也就是源IP、源端口、目的IP、目的端口。很多人写代码时只关心目的地址但排查连接数量时会发现一台服务端机器上同一个端口可以对应成千上万个连接原因就是每个客户端的源IP和源端口不同四元组也不同。对应到Java开发里ServerSocket监听某个端口时操作系统会维护一个监听队列Socket发起连接时内核会临时分配一个源端口。这些底层逻辑虽然不是Java语法层面的东西但理解了它你就能明白为什么连接数一多会报Too many open files为什么服务端主动断开连接后端口会处于TIME_WAIT。2. 三次握手的时序拆解为什么必须是三回2.1 一个完整的SYN、SYNACK、ACK过程TCP在传输数据之前先要建立一个连接。这个建立过程就是经典的三次握手。我见过很多初学者背“客户端发SYN、服务端回SYNACK、客户端再回ACK”但还是不理解中间状态的含义。这里用一个真实抓包时序来看会更清楚。假设客户端是10.0.0.2服务端是10.0.0.3服务端监听8080端口。三次握手对应的包长这样1. 10.0.0.2:52340 - 10.0.0.3:8080 [SYN] Seq1000, Win64240, MSS1460 2. 10.0.0.3:8080 - 10.0.0.2:52340 [SYNACK] Seq2000, Ack1001, Win65535, MSS1460 3. 10.0.0.2:52340 - 10.0.0.3:8080 [ACK] Seq1001, Ack2001, Win65535第一步客户端把标志位SYN置为1随机生成一个初始序列号Seq1000发送给服务端。这个序列号不是从0开始而是内核随机生成的主要目的是防止旧连接的数据包被误认为是新连接的数据。第二步服务端收到SYN后如果资源允许会同时回复SYN和ACK两个标志位其中Ack1001表示“我收到了你1000号报文下一个期待1001号”Seq2000是服务端自己的初始序列号。第三步客户端回一个纯ACKAck2001表示收到服务端的序列号。这三次交互之后双方都确认了“我能发数据给你你也能发数据给我”连接才算建立。2.2 为什么不能是两次也不能是四次这个问题是网络面试里最高频的问题之一。原因一句话就能说清两次握手无法让发送方确认自己的发送能力正常也无法防止历史重复连接初始化请求突然到达服务端。详细展开一下。如果只有两次握手也就是客户端发SYN、服务端回SYNACK就认为连接建立那么客户端不会对服务端的序列号做确认。一但客户端发出的SYN因为网络阻塞延迟到达服务端服务端收到后建立连接、等待数据但客户端那边可能已经超时放弃、重新发起了连接旧的那个SYN包才慢吞吞地到达服务端服务端就会建立一条客户端根本不知道的“幽灵连接”白白占用资源。三次握手里客户端最后一回ACK可以看作对前两次信息的再确认更关键的是它可以携带客户端已经知道的信息来“兜底”。如果客户端发现对方ACK的序列号不是自己期望的就知道这是历史连接直接发RST终止它。这就是三次握手比两次握手多出来的一回的最核心价值。至于为什么不是四次就简单了因为三次已经能达到各自确认收发能力、同步初始序列号的目的再多一次只是信息冗余没有实质意义。TCP设计追求的是够用和有效而不是绝对完美。2.3 Java Socket中握手失败的常见表现用Java写一个最简单的TCP连接代码可能就几行Socket socket new Socket(10.0.0.3, 8080);这一行代码背后JDK和操作系统会完成三次握手。如果握手失败最常见的异常就是ConnectException: Connection refused或者SocketTimeoutException: connect timed out。这两类异常对应的原因完全不同Connection refused意味着服务端收到了SYN但目标端口没有进程监听或者监听队列已满内核直接回了RST包如果是半连接队列满则可能直接丢弃SYN。connect timed out意味着客户端发出SYN后一直没有收到服务端的SYNACK客户端设置的连接超时时间到了。我给初学者的建议是遇到连接异常时先判断是“没到服务端”还是“到了但被拒了”。前者多半是网络不通、防火墙拦截后者多半是服务没起来、端口没监听、队列满。判断方法很简单在服务端机器上执行ss -lntp看端口监听状态或者在客户端机器上执行telnet 10.0.0.3 8080试探看是超时还是拒绝。3. 可靠传输的秘密序列号、确认应答与超时重传3.1 序列号的职责不止排序TCP把应用层的数据当成一个无结构的字节流每一个字节都会有一个序列号。发送方在发送一段数据时报文的序列号是这段数据第一个字节的编号接收方收到后确认号则是它期望收到的下一个字节的编号。举个例子。假如客户端要发送1000个字节给服务端第一个字节的序列号是1001那么这批数据的TCP头里Seq1001。服务端收齐后回一个Ack2001意思是“你从1001开始发到2000一共1000个字节我都收到了接下来请从2001继续”。这个机制的好处是TCP不用管应用层怎么分割消息只看字节流本身。对应到Java开发里就是OutputStream.write()发送的数据底层可能被TCP拆成多个段发送也可能多个write()合并成一个段发送。所以写网络编程时网络层根本没有“消息边界”的概念你需要自己设计协议来划分消息长度比如自定义一个数据长度 数据体的结构。很多人第一次写Socket通信时发现收到的数据和发送时对不上就是这个原因。3.2 超时重传的时间怎么定数据包发出去后如果迟迟等不到ACK发送方就要重传。但“等多久”是个很有讲究的问题。时间定得太短ACK还在路上就重传会白白造成网络冗余定得太长一旦丢包应用层的感知延迟就会很大。TCP实际采用的是自适应算法会根据网络的实时往返时间动态调整。计算方式叫加权移动平均每次测量到一个RTT样本就用一个系数加权更新SRTT (1 - alpha) * SRTT alpha * RTT // 平滑往返时间 RTO beta * SRTT // 超时重传时间传统实现中alpha取1/8、beta取2也就是说超时时间大概是平滑往返时间的两倍。现代的Linux内核实现还会引入Karn算法和抖动因子这里不多展开。理解核心思想就够超时时间不是写死的而是跟随网络状况动态变化的网络越差RTO越大重传越谨慎。实操中你会更容易感受到另一个现象如果TCP触发超时重传随着重传次数增加RTO会进一步放大一般会加倍。比如第一次超时1秒第二次可能变2秒第三次4秒直到超过上限。这就是为什么网络很差时应用层会感觉连接“卡死”很久才报错。3.3 快速重传与重复ACK如果发送方只靠超时重传效率会很差。好在TCP还有快速重传机制。它的原理是接收方如果收到乱序的数据段会立即重复发送它期望的那个序列号的ACK而不是等数据齐了再统一确认。发送方如果连续收到3次同样的重复ACK就认为中间那个包丢了不等RTO超时立刻重传。这个机制对应到一个经典排查场景你看到一个慢查询或者接口偶发延迟抓包一看没有超时重传但有一大片重复ACK。这通常意味着网络里发生了乱序或者有轻微丢包快速重传机制正在忙着补救。这种情况光看应用层日志可能完全看不出来因为TCP把包给兜住了但延迟已经上去了。4. 滑动窗口与流量控制让收发双方不拖后腿4.1 窗口大小决定一次能发多少数据如果不加任何限制TCP每发一个段就等一个ACK那效率会非常低尤其在高延迟链路上。滑动窗口就是为了解决“等待确认”带来的空窗问题允许发送方在收到ACK之前连续发送多个段只要总量不超过窗口大小。窗口大小由接收方的接收能力决定。接收方的内核缓冲区剩余空间越大通告给发送方的窗口就越大反之缓冲区快满了窗口就会缩小到0通知发送方“先停下来我处理不过来”。这就是流量控制。这个字段就是TCP头里的Window。抓包的时候要注意这个值是接收方通告给发送方的决定的是发送方能发多少数据。有些网络优化工具或者配置里会把双方的Socket缓冲区调大本质就是让通告窗口变大允许更多数据在途。4.2 窗口为零时发生的窗口探测窗口变成0之后发送方就不能再发数据了只能等接收方重新通告一个更大的窗口。问题来了如果接收方后来处理完了数据发送了一个窗口更新包但更新包又丢了怎么办双方不就会死等吗TCP的解决办法是坚持定时器。发送方在窗口为0时会定时发出一个1字节的窗口探测包接收方必须回复当前的窗口值。如果窗口还没恢复就回复窗口仍为0如果恢复了多少就回复新值。这个机制的细节不用深啃但线上遇到问题要能认出来抓包时看到大量1字节的包同时窗口字段为0说明接收方处理不过来连接处于停滞状态。对应到Java服务里一个很典型的现象是如果你往Socket的输出流里写入数据阻塞在write()方法上了很可能就是因为对端的接收窗口为0TCP不让你继续发了。很多人以为是Java方法本身的问题实际上是传输层的流控在起作用。4.3 零窗口、糊涂窗口与Nagle算法的关系接收方回复窗口更新时有时会出现只腾出一点空间的情况比如1字节。如果发送方真的只发1字节那网络利用率就很差因为TCP头就有几十字节加上IP头传输一字节的代价太高。TCP专门有一个算法叫Nagle算法规定连接上最多只能有一个未被确认的小报文段后续的小数据先合并等ACK来了或者数据攒够一个MSS再发送。这个算法对Java网络编程有一个直接影响如果用Socket.getOutputStream().write()一个字节一个字节地写数据尤其写完后不立即flush会发现数据迟迟发不出去必须在积累到一定程度或者收到ACK后才发送。如果业务场景需要低延迟通常会调用setTcpNoDelay(true)关闭Nagle算法代价是可能增加一些小包在局域网内基本无感在移动网络下会损伤带宽效率。我处理过一个实时消息推送业务延迟总是抖动排查后发现服务端开启了Nagle、客户端开启了延迟ACK两种机制叠加导致小数据包被搁置等待关闭Nagle后延迟立刻好转。5. 拥塞控制替整个网络踩刹车的机制5.1 慢启动与拥塞避免的配合流量控制关注的是收发双方的缓冲能力拥塞控制关注的却是整条链路上所有设备的承载能力。如果发送方不考虑中间路由器的转发能力一股脑把大量数据灌进去路由器缓冲区溢出就会丢包大量重传进一步加剧拥塞网络雪崩。TCP的拥塞控制机制基本就是一套“先试探、再加速、超限就减速”的策略。发送方维护一个拥塞窗口流量控制里还有一个接收窗口实际发送量取这两个窗口的较小值。拥塞窗口刚建立连接时只有几十个字节之后的增长速度遵循两个阶段慢启动阶段窗口指数增长。每收到一个ACK窗口增加一个MSS1变2、2变4、4变8看起来叫“慢”实际增长非常快。当窗口达到一个门限值ssthresh转入拥塞避免阶段改成线性增长每一轮往返时间窗口只增加1个MSS。这里我补充一个直观理解指数增长是为了快速占满链路线性增长是为了靠近瓶颈时不要冲过头一旦发生丢包或确认异常门限值会减半、窗口回落然后重新走慢启动。这套机制保证TCP永远不会一次把网络打垮。5.2 从超时重传到快速恢复Linux下TCP拥塞控制有多个实现版本比如Reno、Cubic、BBR。Reno里有一个经典过程如果发生超时重传说明网络可能严重拥塞发送方把ssthresh设为当前窗口的一半窗口直接降到1个MSS重新开始慢启动。如果只是收到3个重复ACK触发快速重传说明网络还有响应能力窗口先降一半再进入快速恢复阶段收到新的ACK后可以快速恢复到门限值附近。实际部署的系统里现代服务器普遍使用Cubic它是Linux默认的拥塞控制算法适合高带宽长距离网络。但容器或云平台有时会启用BBR这类基于瓶颈带宽反馈的算法。做Java后端时一般不需要修改内核拥塞控制算法但了解它的存在是必要的因为在跨机房或者专线场景里如果你看到带宽利用率上不去、实际速率远低于链路容量排查方向可能就要从应用代码转向TCP参数本身。5.3 线上慢接口排查时怎么隔离拥塞因素遇到过一种很典型的情况某个服务的接口在晚高峰延迟明显飙升应用日志显示数据库查询很快CPU和内存都正常全链路监控也看不出哪个节点慢。后来抓包才发现机房到另一个机房的骨干链路在高峰时出现丢包TCP频繁触发拥塞控制发送窗口被压缩到很低吞吐量瞬间下降。排查这类问题时一个非常好用的方法是看统计信息。在服务端执行ss -s可以看到当前的TCP重传情况或者用nstat -z TcpExtTCPRetrans查看重传计数。如果重传率持续高于一定水平就要开始怀疑链路质量。另一个技巧是用ping加大包和mtr看中间跳的丢包率能快速定位是哪一跳在丢包。我自己总结的排查顺序是先看应用日志有没有超时异常再看TCP连接状态有没有大量非ESTABLISHED然后抓包看有没有TCP重传或者重复ACK最后用链路层工具确认物理链路。按照这个顺序大部分网络问题都能在十分钟内定位到具体层面。6. 四次挥手与连接状态连接的半关闭与资源释放6.1 FIN和ACK的你来我往TCP连接是全双工的数据可以双向流动。所以要关闭一条连接时理论上每一方都需要单独确认“我不再发数据了”。这就是为什么挥手需要四次而不是三次。一个完整过程如下1. 主动关闭方 - 被动关闭方 FINSeqM 2. 被动关闭方 - 主动关闭方 ACKAckM1 3. 被动关闭方 - 主动关闭方 FINSeqN加上它想发送的剩余数据 4. 主动关闭方 - 被动关闭方 ACKAckN1中间之所以分开是因为步骤2的ACK只是告诉主动方“我收到了你的FIN”但被动方可能还有数据没发完。它需要先把手头数据发完再发自己的FIN。如果恰好被动方数据也发完了从抓包角度看第2和第3步可能合并成一步看起来像三次挥手。很多文章默认四次实际上抓包时常见的是三次因为合并ACK很常见。6.2 TIME_WAIT、CLOSE_WAIT与线上故障四次挥手两个状态值得重点关注。先看TIME_WAIT主动关闭方发出最后的ACK之后不会立即关闭连接而是进入一段时间的等待状态Linux下默认是60秒。等待的目的是防止最后一个ACK丢失后被动方重发FIN所以主动方要留下来再处理一次。这个状态下连接的四元组还占着资源大量TIME_WAIT会让端口被占满服务器处理新连接的能力下降。再来看CLOSE_WAIT被动关闭方收到对方的FIN并回复ACK后就进入这个状态此时被动方要调用close方法释放连接。如果程序里忘记关闭Socket或者IO流没释放句柄就长期处于CLOSE_WAIT数量会一直累积。这是Java服务里最常见的连接泄漏问题。我在排查过分享一个小案例。某应用运行几天后开始拒绝新连接ss -lntp一看服务端有几千个CLOSE_WAIT。顺着代码找发现某个分支异常后没有在finally块里关闭Socket和输入输出流。修正为try-with-resources写法后CLOSE_WAIT数量立刻归零。所以线上排查时看到CLOSE_WAIT上涨第一反应应该是检查代码里的关闭逻辑而不是怀疑网络配置。6.3 Java编程中对连接关闭的常见误解初学者最容易犯的一个错误是在关闭Socket前只调用outputStream.close()以为数据发出去了。实际上close()会关闭整个Socket操作系统发送FIN此时你再查Socket状态会发现整个连接都断了。如果只是想告诉对端“我这个方向的写结束”应该调用socket.shutdownOutput()这样只发送FIN但还能继续读。另一个误区是误用setSoLinger。默认关闭Socket时send缓冲区里如果还有数据操作系统会尝试发送完后才返回或者直接返回丢弃。有些开发者调这个参数想加快关闭速度结果反而导致数据丢失。一般情况下不要动这个设置默认行为足够安全。7. TCP与UDP怎么选Java开发中的典型场景对比先给一个结论TCP适合要求可靠、有序、数据完整性的场景UDP适合实时性要求高、能容忍少量丢失的场景。做Java后端时不要用“感觉”来选而是根据业务可容忍的故障模式来定。应用层自己封装可靠传输的代价很高所以轻易不要用UDP来替代TCP。只有在明确需要UDP特性的场景才值得视频会议丢几帧无所谓但不能卡、语音通话延迟敏感、实时游戏位置同步数据高频更新重传旧状态没有意义、日志上报丢了就丢了不能用重传阻塞主流程。用一张表总结两者的关键差异特性TCPUDP连接状态面向连接需要三次握手无连接直接发数据报可靠性确认应答、重传、排序不保证送达、不保证顺序传输方式字节流数据报流量控制/拥塞控制有没有传输效率相对低有额外开销相对高几乎无开销粘包半包问题需要自己解析边界系统保留消息边界拿Java举例Netty框架既支持TCPNioSocketChannel也支持UDPNioDatagramChannel。写TCP时需要定义编解码器解决粘包和半包写UDP时不需要每个DatagramPacket就是一条独立消息。这就是“数据报”和“字节流”的实际差异带来的编码差别。8. 抓包实操用一次真实的HTTP请求看懂TCP细节8.1 抓包工具与基本过滤这一节讲实操。抓包工具我用得最多的是tcpdump和Wireshark的组合。tcpdump适合在服务器上轻量抓取输出文本格式适合快速过滤Wireshark适合深度分析图形化界面看时序图非常直观。抓包的核心思路是在客户端和服务端的网络路径上随便挑一个点捕获经过的TCP报文。对于本机调试最简单的用法是tcpdump -i lo port 8080 -w tcp.cap这个命令监听回环接口的8080端口写入tcp.cap文件。抓完用Wireshark打开能看到完整的握手、数据交互和挥手过程。注意过滤条件里写tcp port 8080而不是只写port 8080这样可以过滤掉同端口上的UDP报文。如果想实时看握手报文可以配合-nn参数关闭域名解析让输出更干净tcpdump -nn -i eth0 tcp port 80808.2 从抓包结果里看真实参数抓出来后你会看到类似下面的输出IP和端口做了脱敏23:57:30.111111 IP 10.0.0.2.52340 10.0.0.3.8080: Flags [S], seq 4010582127 23:57:30.111256 IP 10.0.0.3.8080 10.0.0.2.52340: Flags [S.], seq 2790581231, ack 4010582128 23:57:30.111312 IP 10.0.0.2.52340 10.0.0.3.8080: Flags [.], ack 2790581232这里Flags字段的字母分别代表S是SYN点是ACKF是FINR是RST。seq和ack两个字段反映了序列号的增长方向。如果看到某个seq被反复发送说明发生了重传如果看到大量[P.]标志的包说明数据载荷正在传输P表示PSH意思是“数据已经准备好请立即交付给应用层”。我建议初学者至少亲手抓一次本机HTTP请求的包然后逐一确认三次握手、请求数据、确认包、四次挥手这一整条链路。看完一次之后TCP对你来说就不再是抽象概念了你能够直接说出“哦这个包是TCP层的确认不是HTTP层的响应”。9. TCP参数调优与常见问题的速查表9.1 几个高频出现的Linux内核参数线上干活的时候官方文档和教程不会告诉你的一个点是Linux内核里有一些TCP参数直接决定了连接能否建立、能建多少、能活多久。Java应用层代码写得再好下面的参数不对也白搭。我把最常见的几个列出来方便大家排查时查阅参数作用建议net.ipv4.tcp_syncookies半连接队列满时是否开启SYN Cookie通常1开启net.ipv4.ip_local_port_range本地自动分配端口范围适当扩大比如1024-65000net.ipv4.tcp_fin_timeoutFIN_WAIT_2状态超时默认2分钟必要时调整net.ipv4.tcp_tw_reuse是否允许TIME_WAIT连接重新使用开启有争议谨慎用net.ipv4.tcp_max_syn_backlogSYN半连接队列长度高并发按内存适当调大net.core.somaxconn全连接队列长度和Java中backlog参数配合尤其在用Java写高并发服务时ServerSocket的backlog参数和系统的somaxconn参数是叠加生效的。Java里传100但系统只有128实际能用的就是两者较小值。线上如果出现连接拒绝并不一定是服务崩了先看全连接队列是否被打满。9.2 常见故障现象与排查方向我在日常开发中把TCP相关故障归成几类遇到问题直接对照着查连接超时连不上先看服务进程是否存活、端口是否监听、防火墙是否放行再看目标网段是否可达最后抓包看SYN有没有回应。大量TIME_WAIT客户端主动频繁关闭连接时容易出现。如果TIME_WAIT占用导致端口耗尽优先检查代码里连接是否复用再考虑调整tw_reuse参数。大量CLOSE_WAIT服务端代码没有正确关闭连接优先排查IO流和Socket的生命周期管理。传输速度上不去优先看TCP重传率、带宽利用率、拥塞控制算法和Socket缓冲区大小。偶发请求延迟抓包看是否有重传、重复ACK、Nagle与延迟ACK叠加。这一套对照表是我实际工作中每次复盘都会用到的框架。它能让你在遇到故障时不是靠猜而是按层定位。9.3 避免乱调参数的一个原则最后提一个最重要的原则TCP参数不要看到别人的“优化配置”就盲目照搬。很多参数的修改会影响整个内核的网络路径对局部的“优化”很可能在另一种网络环境下变成灾难。比如把所有内核缓冲改大在局域网高压测试下吞吐提升明显但放到移动网络高丢包环境下大缓冲区反而让重传变得更加缓慢。我处理过一次事故某个团队为了让内网传输更快把所有socket的读写缓冲区调到了几百兆结果一个内存告警直接拖垮了应用进程。原因是内核缓冲区分配是在发送和接收路径上逐渐膨胀的连接一多内存占用远超预期。调参之前先确认你的网络瓶颈到底在哪一层是针对性地改而不是把所有参数都调成网上说的“最佳值”。10. TCP协议学习中的几个高阶建议很多初学者问我TCP协议学的时候有没有什么捷径。我的建议一直很朴素不要只看书要把抓包工具当成显微镜把网上那些半懂的面试题亲手验证一遍。比如你可以在本机起一个Java Socket服务端和客户端分别用tcpdump抓包然后观察三次握手的具体过程和连接关闭的状态变化。代码不用复杂十几行就够// 服务端 ServerSocket serverSocket new ServerSocket(8080); Socket socket serverSocket.accept(); byte[] buffer new byte[1024]; socket.getInputStream().read(buffer); socket.getOutputStream().write(pong.getBytes()); socket.close(); serverSocket.close();// 客户端 Socket socket new Socket(127.0.0.1, 8080); socket.getOutputStream().write(ping.getBytes()); byte[] buffer new byte[1024]; socket.getInputStream().read(buffer); socket.close();跑起来以后你会发现很多书上没有写清楚的细节比如ACK包往往不会单独出现而是“顺带”被捎带在下一个数据包里这就是TCP的延迟确认机制。这些真实体验比单纯背面试题有用太多。关于TCP/IP协议的网络层之上的这部分最后再给一个我自己的体会传输层的所有机制归根到底都是在“效率”和“可靠性”之间找平衡。三次握手、滑动窗口、拥塞控制、重传策略没有一个机制是孤立存在的。一旦把这些机制放进一条真实的物理链路里去理解你会发现TCP设计的每个细节都恰到好处这一步迈过去之后再回来看HTTP、Netty、数据库连接池这些上层技术理解速度会有明显的提升。之后如果你们有兴趣我可以继续写一篇TCP异常案例分析的文章把我们平时排查线上问题的那套方法完整拆出来。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
