2. TCP 通信核心流程与接口使用写这篇东西的起因是我最近在排查一个 Java 服务端程序的问题客户端连上之后隔一段时间就自动断开服务端日志里全是 Connection reset抓包一看是服务端主动发了 RST。排查到最后是 Nginx 作为反向代理时的空闲超时配置太短导致代理把空闲连接给断了那个 Java 服务根本没有机会说再见。这种问题在 TCP 通信里太常见了。你写了几年代码可能天天跟connect()、accept()、send()、recv()打交道也知道 TCP 有三次握手、四次挥手但真到出问题的时候——连不上、掉线、超时、端口被占用、数据粘包——就发现脑子里对 TCP 其实是半懂不懂的状态只能在网上东搜一下西查一下。这个文章我想把 TCP 这条线从头到尾捋一遍重点放在两件事上一是 TCP 协议的核心流程三次握手、四次挥手、可靠传输、滑动窗口这些到底是怎么回事二是接口使用socket API 层面的调法和那些让你头疼的报错到底在说什么。你可以当它是一个 TCP 通信的排查手册和入门复习手册的结合体适合正在写网络程序的后端开发、嵌入式里做 TCP 通信的工程师以及被网络问题折磨得想转行的运维。先说清楚这不是协议规范解读是我把这些年实际用 TCP 通信时踩过的坑、看过的代码、抓过的包按一套能解决问题的逻辑重新组织的经验总结。我尽量少讲教科书理论多讲这个机制为什么会这样设计以及出问题的时候怎么定位。1. 先把 TCP 的核心概念摆正连接、端口与字节流1.1 TCP 在网络里到底处于哪一层只需要记住两句话TCP 是传输层协议它管的是怎么把数据从一端可靠地送到另一端IP 是网络层协议它管的是数据包怎么从一台主机路由到另一台主机。两者配合才构成了你天天挂在嘴边的 TCP/IP。换句话说IP 解决的是路的问题TCP 解决的是信的问题。路通了不代表信能送到因为路上会丢包、会乱序、会堵塞TCP 就是那个负责丢了重发、乱了排序、堵了限速的快递公司客服。这也是为什么 TCP 被设计得这么复杂——它的复杂是有道理的。你要在不可靠的信道上做出可靠的传输就得靠确认、重传、序号、校验这些超额开销去换。与其抱怨 TCP 握手慢、头部大不如想想如果什么都不做数据传输会是什么修罗场。1.2 TCP 里的连接到底是什么很多新手对TCP 连接有个误解以为它是像电话线一样的一条实体线路。实际上TCP 连接是两端各维护的一个状态机的共识。经典类比TCP 连接不是一条线而是两端共同维护的一张状态表。每一端都记录了对方的 IP、端口、自己的 IP、端口、当前所处的状态、发送/接收的序号、窗口大小等一大堆信息。只要这两张表还在连接就还在任何一端主动把表删了或者中间设备把这条通路弄断了连接就结束了。这就是为什么 TCP 没有物理通道——中间路由器和交换机并不维护你的 TCP 状态它们只看 IP 包往哪发。这也是为什么 TCP 连接经常遇到死连接问题一端断电了另一端不知道还傻傻地等着对方的数据直到超时或者发送失败才发现连不上了。1.3 TCP 与 UDP 的选型对比每次写通信程序都要面对这个选择题。我直接给你一个速查表特性TCPUDP连接状态有连接需要建立/断开无连接直接发可靠性可靠确认重传不可靠丢了就丢了有序性有序乱序会重组无序可能乱序到达传输效率相对低头部大握手/确认开销相对高头部小无握手流量控制有滑动窗口拥塞控制无应用场景Web、数据库、文件传输、远程登录视频直播、语音通话、DNS、游戏同步实际工作中我的建议是能选 TCP 就别乱选 UDP除非你真的知道自己在干什么。视频通话、语音这种对延迟敏感、能容忍少量丢包的场景UDP 是合理的但你要是传输业务数据、控制指令、日志上报用 UDP 就要自己做可靠性设计——重传、排序、去重、拥塞控制每一项都是脏活累活99% 的情况下你没这个必要。2. 连接的建立与关闭三次握手和四次挥手的本质2.1 三次握手为什么不多不少正好三次三次握手的流程你肯定背得出来客户端发 SYN服务端回 SYNACK客户端再回 ACK。但为什么是三次这个问题教科书上写得比较绕我用一句人话解释双方需要确认自己发的数据对方能收到对方发的数据自己能收到——这需要双方各发一次、各确认一次最少三次。具体走一遍你就明白了客户端发 SYN客户端状态变成 SYN_SENT。这一刻客户端确认了我的发送能力 OK对方的接收能力 OK因为 SYN 能发出去而且理论上对方能收到。服务端收到 SYN回 SYNACK服务端状态变成 SYN_RCVD。服务端此刻确认了对方的发送 OK我的接收 OK但还不知道我的发送 OK对方的接收 OK。客户端收到 SYNACK回 ACK两边都变成 ESTABLISHED。A 端确认了我的接收 OK对方的发送 OKB 端收到 ACK 后也确认了我的发送 OK对方的接收 OK。到这一步两端才共同确认了全双工链路的两向能力。如果是两次握手B 端拿不到我发的东西你能收到这个确认建立连接就是盲人摸象。从拔高一点的角度看三次握手还解决了历史重复 SYN 的干扰问题。因为你永远不知道网络上是不是有一个多年前的迟到 SYN 包在游荡只有通过三次握手带上新的序号才能让服务端通过序号判断这个 SYN 是不是过期货从而避免建立错误的连接。这个点很有用后面排查莫名连上就断开之类的问题时你会回忆起这段。2.2 握手建立阶段在代码上对应什么从 socket API 的角度看三次握手其实非常直观服务端socket()→bind()→listen()→accept()。listen()之后内核就开始监听连接请求了accept()是从已完成握手队列里取出一个已经握完手的连接。客户端socket()→connect()。connect()是一个阻塞调用它内部就完成了三次握手的过程握手成功才返回成功。但这里有个极其关键的细节大量生产事故出在这里listen()之后内核维护了两个队列半连接队列SYN Queue存放收到了 SYN 但还没完成握手的连接。全连接队列Accept Queue存放完成了三次握手但还没被accept()取走的连接。如果 Accept Queue 满了内核会根据tcp_abort_on_overflow的设置决定直接丢新连接还是往客户端回一个 RST。这就是你经常遇到的连接突然连不上的最常见原因之一——不是网络不通不是端口没监听而是 accept 消费速度跟不上握手的完成速度把队列挤爆了。后文我专门写这个的排查方法。2.3 四次挥手为什么是四次为什么有 TIME_WAIT挥手过程主动关闭方比如客户端发 FIN 进入 FIN_WAIT_1 → 对端回 ACK → 对端也发 FIN → 主动方回 ACK然后主动方进入 TIME_WAIT等 2MSL 后才真正关闭。四次的原因很简单TCP 是全双工的两个方向的关闭是独立的。A 说我发完了FINB 收到后可能还有数据没发完呢所以 B 先回 ACK 告诉 A 你的 FIN 我收到了等 B 把数据全发完再发自己的 FIN。一来一回至少四次。TIME_WAIT 是很多人恨之入骨的状态。主动关闭方在回完最后一个 ACK 之后要在这个状态里等 2MSL最大报文段生存时间通常 2 分钟才能彻底关闭。原因有两个确保最后一个 ACK 能到达对端。如果这个 ACK 丢了对端会重发 FIN而你在 TIME_WAIT 里还能回应。让网络上残留的旧数据包都过期消失避免它们干扰新的连接相同四元组的新连接收到旧连接的脏数据包。TIME_WAIT 多了会占着端口不释放这就是你 Java 服务高并发短连接场景下遇到 Address already in use 的根源。应对思路不是绕开 TIME_WAIT而是要理解它如果你有大量短连接TIME_WAIT 是正常的、合理的真正该改的是你的应用设计用连接池或者协议设计让服务端先断把 TIME_WAIT 留在服务端而不是客户端。2.4 端口与四元组为什么端口被占用不代表只能有一个连接再聊一个日常被误解的点。很多人以为一个端口只能被一个进程监听一个连接只能占一个端口实际上监听端口一个端口确实只能被一个 socket 监听可以用 SO_REUSEPORT 多进程负载均衡这是后话。已建立的连接一个连接由四元组唯一确定(源 IP, 源端口, 目的 IP, 目的端口)。所以你的服务端 80 端口可以同时挂几十万个并发连接因为每个连接的对端源 IP: 源端口不同。客户端连出的时候每个 TCP 连接会临时占用本地的一个端口。如果本地端口范围太小或者大量连接处于 TIME_WAIT 占着端口你 connect 就会报 Cannot assign requested address。这个问题在 Linux 上可以用sysctl net.ipv4.ip_local_port_range扩大范围解决。3. 可靠传输的幕后机制确认、重传与流量控制3.1 ACK、超时重传与快速重传TCP 是可靠的靠的就是确认号ACK。每一端发送数据时包里都会带上一个序号Seq对端收到后回一个 ACK 告诉它你发的到这个序号为止的数据我全收到了。如果发送方很久没收到 ACK会超时重传。但这个很久是动态计算的基于采样往返时间RTT估算太小会频繁重传浪费带宽太大则影响效率。Linux 下可以通过/proc/sys/net/ipv4/tcp_rto_min等参数窥见一隅但正常情况下你不需要动它——内核的算法比你调的靠谱。还有一种优化叫快速重传发送方连续收到三个相同的 ACK说明对端在反复告诉你我缺的就是那段数据这比傻等超时效率高得多。这就是你搜索到的 tcp dup ack 机制的核心。产生大量 dup ACK 并不一定代表网络故障——只要有一个包乱序到达就会触发一两个 dup ACK这是正常的。但如果持续出现大量相同 ACK基本可以断定有丢包或乱序。3.2 滑动窗口流量控制的大门滑动窗口是 TCP 流量控制的核心机制也是最常被忽略、却最直接影响传输性能的部分。窗口大小是接收方通告给发送方的我还剩多少缓冲区能收数据。发送方只能发窗口范围内的数据窗口左边是已确认右边是可发送。收到 ACK 后窗口右移新的数据才能发出去。这个机制解决了两个问题防止接收方被数据淹没。接收方缓冲区满了窗口就变小变成零了发送方就得停着等窗口更新。实现批量发送。如果没有滑动窗口发送方发一个等一个 ACK 再发下一个停止等待协议效率极低一个 RTT 只能发一个包。有了窗口一个 RTT 能把整个窗口的数据全发出去。我看过不少自我吹嘘高性能网络框架的代码实际上在大量小数据块的同步send()里把 TCP 的窗口利用得七零八碎。很多情况下一顿操作猛如虎抓包一看吞吐量就是上不去。3.3 拥塞控制别把网络挤爆了滑动窗口管的是接收方能收多少拥塞控制管的是网络能承受多少。两者叠加发送方的实际发送速率由min(接收窗口, 拥塞窗口)决定。拥塞控制有四个经典阶段慢启动、拥塞避免、快速重传、快速恢复。慢启动是指一个连接刚建立的时候拥塞窗口从 1 个报文段开始每收到一个 ACK 就翻倍指数增长直到出现丢包或达到慢启动阈值才转为线性增长。这个机制的直觉是我不知道网络的承载能力先用小窗口试探逐渐加大撞了墙丢包就退回来。有一件事必须提醒TCP 拥塞控制遇到高带宽高延迟链路时特别吃亏。比如你要通过跨地域专线传输大文件窗口增长太慢RTT 又大吞吐量可能只到链路的 10%。这时候你可能需要调大初始窗口、启用 BBR或者干脆在应用层用并行的多个连接打满链路。我的经验是这种场景直接无脑换 BBR 调大 socket 缓冲区往往比你优化什么应用层代码都管用。3.4 沾包和拆包应用层必须处理的问题最后是应用层开发中永远躲不开的经典问题TCP 是字节流没有消息边界。你以为send(hello)和send(world)是两次独立发送接收方recv()两次分别拿到 hello 和 world不对。接收方可能一次拿到 helloworld也可能一次拿到 hell下一次才拿到 oworld。TCP 不保证消息边界。解决办法绕不开三条路定长消息每个消息固定 N 字节不够补零。简单但浪费带宽。分隔符消息末尾加\n或自定义分隔符像 HTTP 的换行分隔头部。要注意的是一个消息可能被拆成多个包分隔符可能在包中间。长度前缀每个消息前面加 4 字节长度。最通用所有 RPC 框架基本都用这种。这三个方案里 90% 的业务场景推荐第三种。你去看看 Netty、gRPC核心都是读长度 读消息体。自己设计协议时从第一天就把长度字段加上。4. Socket 接口使用从代码视角理解 TCP4.1 服务端和客户端的基础调法Linux 下 C/C 的 socket API 是理解 TCP 接口的最佳入口其他语言Java、Python、Go的内核都是这些调用的封装。我贴一段最小可运行的框架服务端int listen_fd socket(AF_INET, SOCK_STREAM, 0); // 创建 TCP socket struct sockaddr_in addr; addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); // 监听所有网卡 addr.sin_port htons(8080); bind(listen_fd, (struct sockaddr*)addr, sizeof(addr)); // 绑定端口 listen(listen_fd, 1024); // 开始监听backlog1024 while (1) { int conn_fd accept(listen_fd, NULL, NULL); // 取出已完成握手的连接 // 处理 conn_fd ... }客户端int sockfd socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in server_addr; server_addr.sin_family AF_INET; server_addr.sin_port htons(8080); inet_pton(AF_INET, 192.168.1.10, server_addr.sin_addr); connect(sockfd, (struct sockaddr*)server_addr, sizeof(server_addr)); // 发起三次握手这几个函数看起来平平无奇但每个都有一堆隐藏细节socket()的第三个参数 0 代表默认协议SOCK_STREAM 下就是 TCP。bind()不是必须的客户端可以不 bind内核会自动分配临时端口。listen()的 backlog 参数直接关系全连接队列大小后文详述。accept()返回的是新的已连接 socket监听 socket 继续管新连接。connect()会阻塞直到握手完成可以设置超时。4.2 核心参数和选项别忽视这些要命的细节SO_REUSEADDR这个选项排障时经常看到它能让端口在 TIME_WAIT 状态下允许重新绑定也是解决 Address already in use 报错的常规手段之一。但注意它并不能跳过 TIME_WAIT 本身只是允许监听端口复用。真正避免 TIME_WAIT 的方法是长连接或者让连接关闭时由对端先发 FIN。TCP_NODELAY用来关闭 Nagle 算法。Nagle 算法会把小数据攒起来合并发送这对减少小包有好处但对交互式应用是灾难——你会觉得延迟贼高。做游戏、即时通信、交互式请求时一定要setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, on, sizeof(on))。SO_KEEPALIVE默认每 2 小时发一个探测包这个频率对绝大多数业务来说太慢了。实际应用中更推荐在应用层做心跳比如每 30 秒一个 ping 消息而不是依赖内核 keepalive。当然你可以调/proc/sys/net/ipv4/tcp_keepalive_time等参数但全局调影响所有连接不如应用层心跳可控。4.3 send()、recv() 的行为逻辑与返回值很多人把send()和recv()当成发了 N 字节和收了 N 字节的简单函数其实远不止send(fd, buf, len, flags)返回的是实际写入内核发送缓冲区的字节数。缓冲区不够时阻塞模式下会等非阻塞模式下返回部分字节或返回 -1 并置 errno 为 EAGAIN/EWOULDBLOCK。recv()返回 0 意味着对端已经优雅关闭收到 FIN这是判断连接关闭的最可靠标志。recv()返回 -1 且 errno 为 EINTR代表被信号中断不是错误重试即可返回 -1 且 errno 为 ECONNRESET代表对端发了 RST连接已被强制重置。这里最大的坑在于send()返回成功只代表数据进了本地内核缓冲区不代表对端收到了更不代表对端应用层处理了。所以应用层往往还需要自己的 ACK 机制来确认业务数据被对端处理。TCP 能保证的可靠是内核收到不是业务处理完成。4.4 close() vs shutdown()关连接的讲究close(fd)会立即尝试发送缓冲区里的剩余数据然后发 FIN但如果这个 fd 被多个进程/线程共享引用计数大于 1close()只是减引用计数连接并不关闭。shutdown(fd, SHUT_WR)则明确表示我不再发送数据了会立刻发 FIN但还可以继续接收数据。这两个的区别在实践中非常有用。比如你要实现半关闭我发完了但还可以收你的数据用 shutdown 就能做到你用 close 想立刻断开但如果共享了 fd可能会发现连接纹丝不动。服务端处理完请求后安全关闭的姿势是先shutdown(SHUT_WR)发 FIN再循环recv()直到返回 0等对端也关闭最后close()。这样能尽量避免 RST 造成的数据丢失。5. 高频故障排查实录从连不上到连上了又断5.1 端口被占用和 Address already in useJava 服务端报BindException: Address already in use或者你写 C 程序 bind 失败基本只有两种可能端口已经被别的进程占用了。用netstat -tlnp或ss -tlnp查一下到底是谁。上一个服务实例还处于 TIME_WAIT而你没设置 SO_REUSEADDR。排查时用lsof -i:8080看到底是哪个进程占的端口必要时直接杀进程。但如果是 TIME_WAIT 导致的重启失败光杀了也没用关键是代码层把 SO_REUSEADDR 加上或者等 2MSL大约 2 分钟。5.2 客户端连不上SYN 发出去没人理客户端connect()阻塞半天然后超时这种问题最让人抓狂因为看起来哪都没坏。按这个顺序排查先在本机 ping 对端 IP不通就是网络层问题。用telnet 对端IP 端口单独测端口连不上说明端口服务有问题或防火墙拦截。在服务端ss -tlnp | grep 端口看服务是否真的在监听。抓包看 SYN 有没有到有到没回包 - 半连接队列满了或防火墙丢包没到 - 中间路由丢包或对端防火墙拦截 SYN。检查服务端 accept 队列溢出netstat -s | grep overflowed如果一直在涨就是应用 accept 太慢。注意很多新手一上来就怀疑是防火墙但现实里最常见的其实是服务崩了、backlog 满了、或者内核参数限制了本地端口范围。先看基本情况再开防火墙排查。5.3 半连接队列满导致的部分客户端连不上这是典型的隐蔽故障。连接建立流程里SYN 到内核先进半连接队列完成握手进全连接队列。如果半连接队列满了内核直接丢 SYN 包客户端表现为 connect 超时。半连接队列的大小受listen()的 backlog 和内核参数net.ipv4.tcp_max_syn_backlog共同影响。经典错误是listen(fd, SOMAXCONN)但系统默认的tcp_max_syn_backlog太小高并发时一压就满。遇到这种问题除了调大 backlog更根本的是看应用能不能更快地 accept。我遇到过一次很难查的案例客户端大量重试连接服务端ss -lnt显示 Listen 队列 Send-Q 一直满但应用层 CPU 使用率并不高。最后发现是应用里accept()出来后处理业务逻辑太慢属于经典的全连接队列堆积。解决方法是把 accept 之后的业务处理丢到线程池保证 accept 循环永不阻塞。5.4 连接无故断开和 RST 问题连接用着用着就断了是另一种高频困扰。常见原因整理成一张表现象可能原因解决方向连接空闲一段时间后断中间设备NAT、防火墙空闲超时回收连接应用层心跳30~60秒一次保证空闲时也有流量报 Connection reset by peer对端进程崩溃或主动 RST检查对端日志看是否抛异常、OOM、主动关闭报 Broken pipe对端已经关闭自己还在 write写数据前判断连接状态或用信号处理 SIGPIPE数据发送到一半断了发送缓冲区溢出的 WINDOW 死锁检查对端是否停止 recv应用层是否有读取瓶颈大量 TIME_WAIT高并发短连接主动关闭方积压调整为长连接池或让被动方先关我最想强调的一条经验不要指望 TCP 自动发现对端不见了。一台机器断电、拔网线另一端可能根本不知道。TCP 虽然有两小时超时探测的 keepalive但那个周期在生产环境的业务里几乎等于没有。所以凡是需要长期保持的 TCP 连接一定要设计应用层心跳。心跳不光能保活还能让双方在 N 个周期没收到心跳时主动判定连接死亡快速释放资源。5.5 高并发下连接数上不去文件描述符和端口范围高并发 TCP 服务排查到最后几乎都会碰到这两个 Linux 内核限制文件描述符限制每个 TCP 连接都是一个文件描述符进程默认 ulimit -n 经常只有 1024。改/etc/security/limits.conf里的 nofile 到 100000或者直接在 systemd service 里配 LimitNOFILE。本地端口范围作为客户端大量发起连接时源端口范围net.ipv4.ip_local_port_range默认 32768~61000总共大约 28000 个端口如果 TIME_WAIT 又占着端口就会 Cannot assign requested address。可以调大范围也可以开net.ipv4.tcp_tw_reuse注意这要求对端开启时间戳。backlog 参数不仅是 listen 队列Nginx 反向代理的proxy_backlog、Java 的acceptCount都对应这个值。压测时连接不上先看这几个地方。我自己的经验是不要一上来就调内核参数先把应用层问题排干净连接池、关闭逻辑、accept 循环内核参数是加分项不是救命稻草。6. 接口设计层面的几条附加心得6.1 协议设计版本号、长度、校验一个都不能少自己定义 TCP 应用协议时除了长度前缀我强烈建议加上协议版本号和校验字段。版本号用于将来升级不完全破坏兼容性校验可以做 CRC32 或者最少一个长度校验防止错位帧把后面所有数据全搞乱。一个最简可靠的二进制协议头字段长度说明Magic2 字节固定魔数 0xABCD用于快速识别帧头Version1 字节协议版本Type1 字节消息类型Length4 字节消息体长度不包括头Payload变长消息体解析流程不复杂先读固定长度头校验 Magic 和 Length 合法性再读 Length 字节的 body。这样粘包拆包问题、错位问题基本都防住了。6.2 抓包基本功Wireshark 只看这几点排查 TCP 问题最高效的手段永远是抓包。Wireshark 里你不需要看每一条细节重点看这么几个东西过滤tcp.flags.syn1看握手包是否往返。过滤tcp.analysis.retransmission看有没有重传重传比例高就说明有丢包。看tcp.analysis.duplicate_ack如果 dup ack 大量出现说明包乱序或丢失。过滤tcp.flags.rst1看是谁发的 RST谁发谁就有问题。看时间列connect()超时的典型特征是 SYN 重传了好几次间隔从 1 秒、2 秒、4 秒呈指数增长。抓包工具不会骗你配合netstat -s的内核统计大多数 TCP 疑难杂症都能在十分钟内定位到方向。6.3 常见面试点和知识自测如果你是想通过这篇文章顺便巩固一些面试知识我留几个自查题为什么第三次握手可以携带数据前两次不行TIME_WAIT 是主动关闭方还是被动关闭方的状态为什么主动方要等 2MSL什么是 SYN Flood 攻击它针对的是哪个队列Nagle 算法和延迟 ACK 同时启用会带来什么问题服务端 accept 返回的连接和 listen 的 fd 是什么关系如果客户端连着网线看视频UDP路由器突然重启一下TCP 连接会断吗UDP 会受影响吗这几个题想明白TCP 通信的核心流程和接口使用这块就算真正吃透了。在这个领域里真正的成长往往来自排查实战。我强烈建议你在一个可控的测试环境里自己故意制造几次连接故障故意把 backlog 调小压并发故意关掉 SO_REUSEADDR 然后快速重启故意在中间交换机上丢包然后用抓包工具去观察现象。看一遍现象胜过读十遍理论——等你把 TCP 的状态流、队列、重传机制真正看见了以后不管做嵌入式、后端还是网络设备遇到通信问题就不会两眼一抹黑了。
