一文讲透TCP协议：从三次握手到TIME_WAIT与工程排障

1. 从一次"地址已在使用"报错说起：TCP在协议栈里的真实位置

前阵子组里一位做Java后端的同事半夜发消息：客户端一重连就报"Address already in use"，代码里明明调用了close，到底哪来的鬼。我隔着屏幕都能感觉到那股焦灼。这类问题根子不在业务代码，而在TCP协议本身。做了十几年网络相关开发，我越来越觉得TCP这东西，学校里人人背过三次握手，可真到线上故障、性能调优、嵌入式联网的时候，能把它讲透的人不多。这篇我打算换种讲法，把TCP协议从协议栈定位开始，一路串到三次握手四次挥手、端口号与连接五元组、重传与DUP ACK，再到ESP01S联网、Modbus TCP、Nginx四层代理和C语言socket编程这些真实场景。适合刚接触网络编程的初学者，也适合被线上TCP问题反复折腾的后端、嵌入式、上位机工程师。读完之后，至少遇到上面那个报错，你知道该去查连接状态、查端口复用，而不是怀疑人生。

1.1 一次让我印象深刻的"网络问题"排查

先说那次排查的完整链条。同事的客户端程序是个定时任务，每次跑完主动断开连接，下次跑之前重新connect。他在本机测试一切正常，一上测试环境就偶发"Address already in use"。我用netstat看了一眼，发现测试环境的客户端本地端口固定绑在一个范围内，关闭后一堆TIME_WAIT状态还没清掉，重连时又想复用同一个端口，于是直接被内核拒绝。这个例子特别典型：协议状态和业务代码扯在一起，但真正的根因是TCP连接状态机里TIME_WAIT的行为，而不是代码逻辑。理解TCP，本质上就是理解它维护的那张连接状态表、那套序号与窗口机制，以及它们在不同工程场景下的具体表现。

1.2 一份数据从网卡到应用的旅程

TCP/IP协议栈一般讲四层：应用层、传输层、网络层、链路层。TCP位于传输层，夹在IP网络层和应用之间。一次最简单的数据发送，应用把字符串交给操作系统，TCP把这串字节切成大小合适的段，给每段编上序号、贴上TCP头，再交给IP层封装成IP包、选择路由，最后网卡把比特流发出去。接收端完全反过来，网卡收包、IP层去掉IP头、TCP层负责校验、排序、去重、按序号重组，最后才把完整字节流交给应用。

很多人分不清TCP和IP的分工，我习惯用一个快递类比：IP是快递公司，只承诺"尽力把包裹从A送到B"，它不管包裹是不是丢了、顺序是不是乱了；TCP则是寄件人和收件人之间的电话确认，每个包裹到了都要回执，少了就补发，乱了就重排。所以TCP/IP合在一起，才能让应用层拿到一份完整、有序、不丢的字节流。没有TCP只有IP，数据可能发出去了但永远到不了，这在丢包严重的无线链路上体现得淋漓尽致。

1.3 TCP与UDP的分水岭：什么场景必须用TCP

TCP和UDP都工作在传输层，但设计哲学完全相反。TCP面向连接，先握手再传输，之后还有确认、重传、排序、流量控制，保证"一个字节都不能错"；UDP无连接，发出去就不管了，头部只有8字节，延迟极低。拿实时音视频举例，语音通话偶尔丢一帧，人耳几乎感知不到，但如果是TCP，丢包触发重传，那一帧数据晚到了几百毫秒，整个通话延迟越堆越高，体验反而更差。所以视频通话、直播、游戏位置同步这类"新数据比旧数据重要"的场景，普遍用UDP；而网页、文件传输、数据库事务、邮件这些"少一个字节都不行"的场景，必须TCP。

顺带说一句，现在很火的HTTP/3基于QUIC协议，QUIC本质上是在UDP之上实现了类似TCP的可靠传输与拥塞控制。这说明TCP的设计不是唯一答案，但围绕"可靠传输要解决什么问题"的思考方式，至今仍然成立。选型的时候先问一句"能不能容忍丢包"，答案基本就出来了。

2. 连接的状态机：三次握手、四次挥手和TIME_WAIT

2.1 三次握手为什么必须是三次

一次完整的TCP连接建立，是三次交互。客户端发SYN段，带上自己的初始序号x；服务端回SYN+ACK，带上自己的初始序号y，同时确认客户端x；客户端再回ACK确认y。三次交互完成，双方都确认了"我发的东西你能收到，你发的东西我也能收到"。

为什么不能是两次？因为两次握手只能让服务端确认"客户端能发、我能收"，但客户端无法确认"服务端能否正确接收自己发的东西"。更关键的是，两次握手没法处理历史重复SYN。设想一个很老的SYN包在网络里绕了很久才到达服务端，如果是两次握手，服务端立刻分配资源并建立连接，但客户端根本不知道这回事，也不会发上层数据，这个"幽灵连接"会一直挂在那里消耗资源。三次握手让服务端在收到客户端ACK之前不把连接交给应用，从根上避免误建连接。

这里牵扯出两个队列：半连接队列（SYN队列）和全连接队列（accept队列）。握手完成前，连接待在SYN队列；握手完成后，连接进入accept队列等待应用调用accept()。如果accept队列满了，内核会丢弃新连接或直接发RST，表现就是客户端connect超时，服务端用ss -lnt看Send-Q列会显示队列积压。这也是为什么高并发服务器要合理设置listen的backlog参数，并尽快从队列里取走连接，否则队列一满，再多的worker也白搭。

2.2 四次挥手与TIME_WAIT的纠缠

TCP连接是全双工的，两条方向的数据流可以独立关闭，所以断开要四次交互。A发FIN表示"我没数据要发了"，B回ACK表示"知道了，但我可能还有数据要发"；B发完数据后再发FIN，A回ACK确认。每一半的关闭都是独立的请求与确认，这就是为什么挥手比握手多一次。

四次挥手之后，主动关闭的一方要进入TIME_WAIT状态，等2MSL（最大报文段生存时间，通常30秒到1分钟）才彻底释放连接。等这么久有两个原因：一是最后一次ACK可能丢失，如果丢了，对端会重发FIN，主动方需要留着这个状态重发ACK；二是要让旧连接在网络里遗留的迟到报文彻底消失，避免它们混进一个用相同五元组的新连接，造成数据串包。

TIME_WAIT是协议的正确行为，但它确实会带来工程麻烦。高并发短连接场景下，主动关闭方会产生大量TIME_WAIT连接，占住本地端口。比如Java客户端用固定本地端口连接服务端，关闭后立刻重连，本地端口还卡在TIME_WAIT里，就会撞出"Address already in use"。常规解法是给socket设置SO_REUSEADDR，让TIME_WAIT状态的端口可以立即被复用；Linux下还有tcp_tw_reuse，但这只对主动发起连接的一方生效，且要配合时间戳使用，别不分青红皂白就打开，否则可能出现连接复用后的语义混乱。

2.3 端口号与连接五元组：单连接实验的底气

端口范围0到65535，0到1023是知名端口，HTTP对应80、HTTPS对应443、Modbus TCP对应502；1024到49151是注册端口，49152到65535是临时端口，客户端发起连接时由操作系统自动分配。端口号解决的是"数据包到了机器之后，交给哪个进程"的问题，IP地址加端口，才算把"哪台机器上的哪个程序"定位清楚。

再看那个容易让人困惑的问题：同一个客户端、同一个服务端端口，能不能建立多条连接？答案是能。原因在于五元组。客户端的IP和目标端口都一样，但每次发起连接时操作系统会给客户端分配不同的临时源端口，五元组变了，就是一条全新的连接。Nginx能同时扛住几十万甚至上百万连接，靠的就是这个机制——所有连接共享同一个监听端口，但每条连接的源地址和源端口各不相同。我带新人时喜欢让他们做"单连接实验"：在本机起一个服务端，用同一个客户端程序反复连接、收发、断开，同时抓包。跑完你就会直观看到，每一次连接都是完整的三次握手加四次挥手，端口号像公交站牌，五元组一变，就完全是另一条线路。

3. 可靠传输的引擎：序号、窗口、重传与DUP ACK

3.1 序号与确认号：可靠性的地基

TCP把应用层传来的字节流看作一个无限长的字节序列，每一个字节都有编号。发送时，TCP头里的序号（seq）表示这一段数据的第一个字节编号；确认号（ack）表示"我已经正确收到ack之前的所有字节，请从ack开始发下一个"。这种机制叫累计确认，它不需要对每个包单独回执，回一个ack=100，就代表1到99都收到了，效率很高，也让重传变得好办：收据丢了，补发从断点开始的那一段即可。

假如没有序号，接收方无法判断先到的包到底是新的还是乱序的旧包；没有确认号，发送方永远不知道数据有没有到达。TCP的可靠性就是从这两个32位数字长出来的。很多协议栈性能问题，本质上是序号空间、确认频率和窗口大小的匹配问题。举个例子，假设RTT是50毫秒，窗口只有16KB，那无论链路带宽多大，实际吞吐都被压在16KB除以0.05秒等于320KB/s左右，这在国内服务器之间还算正常，但跨洋链路就很要命了。

3.2 滑动窗口、流量控制与拥塞控制

有了确认机制还不够，发送方不能无脑灌数据。TCP为此维护了两个窗口。接收窗口（rwnd）由接收方在TCP头里通告，告诉发送方"我的接收缓冲区还能装多少字节"，作用是防止发太快把对方缓冲区撑爆；拥塞窗口（cwnd）由发送方根据网络状态维护，作用是探测链路能承受多大速率。实际能发送的数据量是这两个窗口的较小值。

拥塞控制经历了慢启动、拥塞避免、快速重传和快速恢复几个阶段。慢启动阶段，cwnd从1个MSS开始，每个RTT翻倍；达到慢启动阈值后进入拥塞避免，每个RTT只线性增长；一旦发生丢包或收到重复确认，cwnd立刻收敛。这里面有个关键概念叫带宽时延积（BDP），等于链路带宽乘往返时延。如果接收窗口小于BDP，链路利用率就上不去，就像一根很粗的水管配了个很小的储水池，水龙头开到最大也是白搭。

排障时经常需要做"TCP参数标定"：先测出链路的真实带宽与RTT，算出BDP，再据此把socket的收发缓冲区、TCP窗口缩放因子、初始拥塞窗口配置到合理范围。我在压测环境里习惯先用网络损伤仪或Linux的tc命令把丢包率、时延、带宽限定到目标档位，把标定基线固定住，再跑应用测试，否则测出来的数据根本没有参考意义。尤其是做端到端性能验收时，不标定链路参数的测试结果，换个网络环境就完全不能复现。

3.3 DUP ACK机制与快速重传：一次真实排障

当接收方收到乱序段——比如期望序号5，却先来了序号7——它不会确认7，而是立刻重复返回"我还在等5"的ACK。发送方如果连续收到3个相同的重复ACK（DUP ACK），就认定5丢了，不等超时立刻重传5，这叫快速重传。相比超时重传要等一个RTO（通常几百毫秒到数秒），快速重传显然快得多。

我碰到过一起文件传输变慢的故障，高峰期TCP重传率飙升。抓包看到典型的"三段式"画面：一个乱序包之后跟着一串DUP ACK，接着就是TCP Retransmission，循环往复。顺着重传包一路查，最后定位到中间交换机的一个光模块，CRC错误计数暴涨，端口在持续丢包。换掉光模块后，重传率立刻恢复正常。这里有个经验：少量DUP ACK是网络设备乱序的正常现象，但如果DUP ACK和Retransmission高频率成对出现，基本可以判定链路丢包，去查物理层，别在应用层浪费太多时间。

3.4 TCP协议包如果想改，得先看清报文结构

有朋友问"TCP协议包如何修改"，这个问题的答案取决于你想在哪一层动手。TCP头长这样：源端口和目的端口各16位，序号32位，确认号32位，然后是数据偏移、保留位、9个标志位、16位窗口大小、16位校验和、16位紧急指针，后面跟着可选区域，MSS、窗口缩放、时间戳都在这里。

如果你想改自己socket发出的TCP行为，正确姿势是用setsockopt，比如TCP_MAXSEG改MSS，SO_SNDBUF/SO_RCVBUF改收发缓冲区，TCP_NODELAY关掉Nagle算法，TCP_QUICKACK改确认策略。如果你想改经过网关的流量，可以在转发路径上用iptables的TCP选项匹配与修改，或者用eBPF钩子处理。如果你要完全自己捏一个TCP头，那就只能走raw socket自己构造报文。但请记住：普通应用层代码改不了TCP头，你只能改payload，所谓"协议包修改"绝大部分场景其实是socket选项调优，把需求说清楚，方案自然就出来了。

4. 工程场景拆解：ESP01S联网、Modbus TCP与Nginx四层代理

4.1 ESP01S发送TCP消息到手机：最小物联网链路

ESP-01S是很多入门玩家手里的第一块Wi-Fi模块，成本低，但坑也不少。想让它发TCP消息到手机，最简单的路径是：手机装一个"网络调试助手"App，开TCP Server监听一个端口，比如8080；模块和手机连同一个路由器，注意别开AP隔离；模块通过串口发AT指令。

AT指令流程大致是这样：

text复制AT+CWMODE=1
AT+CWJAP="你的Wi-Fi名","你的Wi-Fi密码"
AT+CIPSTART="TCP","手机IP",8080
AT+CIPSEND=5
> hello

CIPSEND后面跟的是要发送的字节数，进入大于号提示后输入内容，模块返回SEND OK说明发送成功。整个过程里最有意思的是，你可以在手机App端清楚看到连接状态的变化：从LISTEN到收到SYN，再到ESTABLISHED，最后断开时状态翻转。这一步跑通，TCP三次握手在你眼里就不再是PPT上的三条箭头了。

实际工程里要注意三点：一是ESP-01S峰值电流能到300毫安以上，很多USB转TTL的3.3V根本带不动，必须外接稳压模块，否则模块反复重启，排查半天还以为是程序问题；二是AT指令返回要及时读，串口缓冲区一满，指令就丢了；三是裸TCP长连接对IoT设备不友好，要长期运营的设备建议走MQTT over TCP，保留TCP可靠性的同时，又多了心跳、主题和QoS，设备端也不用时刻保持长连接。

4.2 Modbus TCP：工业协议为什么能安稳跑在TCP上

Modbus TCP是工业现场最常见的"TCP+应用协议"组合之一，端口502。它在TCP之上又定义了一套自己的报文规则：MBAP头加PDU。MBAP头7字节，事务ID占2字节、协议ID占2字节、长度字段2字节、单元ID 1字节；PDU则是功能码加数据。常用的功能码就那几个：0x03读保持寄存器，0x06写单个寄存器，0x10写多个寄存器。

以读保持寄存器为例，请求帧是：00 01 00 00 00 06 01 03 00 00 00 02。拆开看，00 01是事务ID，00 00是协议ID，00 06表示后面还有6个字节，01是单元ID，03是功能码，00 00是起始寄存器地址，00 02是寄存器数量。响应帧会在这后面带上一段字节数和寄存器值。三菱FX5U要配Modbus TCP主站功能时，在GX Works3里配置连接，把目标寄存器映射到内部软元件；而C#侧做客户端，可以直接引用NModbus4这类库，也可以自己拼报文。

我自己干这行久了反而更喜欢手拼报文——库虽然方便，但遇到怪问题时你根本不知道它给你埋了什么字节序陷阱。Modbus TCP最容易踩的坑有三个：字节序是大端还是小端、协议地址和PLC地址之间常常差个1的偏移、事务ID必须原样回显。任何一次抓包比对，都能帮你快速定位是哪个环节错了。比如C#客户端连不上FX5U，先抓包确认请求帧到了没有、响应帧回没回，事务ID对不对，比反复改代码高效得多。

4.3 Nginx做TCP反向代理：连接数与性能边界

Nginx的HTTP模块处理的是七层转发，想转发裸TCP流量，要用stream模块。一段最简配置像这样：

nginx复制stream {
    upstream backend {
        server 192.168.1.10:3306;
    }
    server {
        listen 3000;
        proxy_pass backend;
    }
}

这样Nginx就把本机3000端口的TCP流量原样转发到了内网数据库的3306端口。做MySQL、Redis、自研协议的负载均衡时，这种四层代理非常常见。很多人关心它能扛多少连接，这里有个粗糙的估算公式：max_clients约等于worker_processes乘以worker_connections。如果worker_processes设4，worker_connections设10240，理论上限是40960，但还要受系统文件描述符上限（ulimit -n）约束，因为每个连接至少消耗一个fd，监听fd、日志fd、事件通知fd都要占。

真实压测时你会发现，默认配置往往先撞上文件描述符或者本地端口范围，而不是Nginx自身瓶颈。所以调优顺序是：先加ulimit，再看worker数量，最后看内核参数如tcp_max_tw_buckets、somaxconn。还要提醒一句，Nginx只负责搬运字节，连接能不能长寿取决于后端协议本身。代理MySQL这种长连接协议时，后端连接池会放大Nginx的连接数，别只盯着Nginx调参，数据库连接池上限和空闲超时同样要关注。

4.4 Java/C#客户端重连"地址已在使用"的根因

回到开头那个问题。Java客户端调用close之后立刻重连，抛BindException: Address already in use，为什么？因为主动关闭的客户端socket进入TIME_WAIT，本地端口在2MSL内不能复用。如果这个客户端恰好bind了固定本地端口，重连时还想用同一个端口，就直接撞上了。就算没有bind，如果系统临时端口分配策略导致新的临时端口和旧端口重复，也可能撞上，但概率低得多。

解法分几步看。第一，客户端尽量不要bind固定端口，让操作系统从临时端口范围随机分配，TIME_WAIT占住的端口和下一次分配到的端口冲突概率极低；第二，非要固定端口，就设置SO_REUSEADDR，Java里是Socket.setReuseAddress(true)，C#里对应SocketOptionName.ReuseAddress，它允许TIME_WAIT状态的端口被立即复用；第三，如果服务端这边出现一堆CLOSE_WAIT，那就是另外一种病——应用拿到了对端FIN却不调用close，一般是代码没释放连接，netstat一眼就能看出来，这种只能去改代码，调任何参数都救不了。搞懂这个根因，比记住那一行报错要值钱得多。

5. 排障工具箱：本机命令、抓包思维与常见问题速查

5.1 一条命令一张表：看懂TCP状态

排查TCP问题，第一步永远是看状态。Windows上最常用netstat -ano，配合findstr过滤端口；想看得更细，用Get-NetTCPConnection可以拿到连接状态、本地端口、对端端口和所属进程。Linux上的对应物是ss，ss -taneip一条就能把所有TCP状态、收发队列、重传信息列全，ss -s还能看系统级的TCP汇总。

netsh interface tcp show global这条命令被问得不少，它在Windows上打印全局TCP参数，关键几行要知道：接收窗口自动调谐级别，如果显示disabled，高带宽长链路吞吐会差一大截；初始RTO显示初始重传超时，默认是1秒；时间戳显示是否启用RFC1323时间戳，它关系到tcp_tw_reuse类功能能不能正确工作。

状态字段是排障的罗盘。LISTEN表示在监听，SYN_SENT表示connect发出但握手没完成，ESTABLISHED是正常连接，TIME_WAIT是主动关闭方等待，CLOSE_WAIT是被动关闭方等应用close。Recv-Q和Send-Q也有讲究：established状态下Recv-Q长期不为0，说明应用读得太慢；Send-Q长期不为0，说明对端窗口为0或链路堵了。listen状态下的Send-Q表示accept队列深度，如果它长期等于backlog上限，你的应用accept得太慢，已经在丢新连接了。

5.2 上位机与NI实时机TCP交互的信息量怎么查

有人在问"LabVIEW上位机与NI实时机TCP交互的信息量怎么查询"，我理解这里的"信息量"通常指吞吐量，单位是字节每秒或者报文数每秒。最直接的办法是在LabVIEW里用Tick Count(ms)包住TCP Read和TCP Write节点，统计一段时间内的累计字节数除以时间，就是吞吐。要更精确，在实时机上可以用硬件时戳，或者用带FPGA的板卡计时。

如果想从网络侧看，Wireshark是更客观的第三方视角。抓包之后，Statistics菜单下的IO Graph能把时间轴上的吞吐画出来，Y轴选Bytes就是字节速率；Conversations对话框可以看到每条TCP连接累计发了多少字节、多少报文，一目了然。这与查"TCP连接数"是两回事，前者看流量大小，后者用netstat或ss数ESTABLISHED状态的数量。上位机交互变慢时，先看这两组数据，确认是流量本身大，还是握手延迟高，方向完全不同。

5.3 高频问题速查表

这张表能解决百分之八十的日常疑问。剩下那部分疑难杂症，就该走到抓包那一步了。抓包不是最后手段，而应该是第一反应——很多问题看一眼包就知道答案，比翻代码快得多。

6. C语言Socket编程骨架：从代码看协议

6.1 最小TCP服务端

理解协议最好的方式是把代码跑起来。C语言的socket接口最贴近内核，没有框架包装，你能清清楚楚看到每一次系统调用对应协议的哪个动作。先看服务端：

c复制#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

int main() {
    int lfd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addr = {0};
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    addr.sin_port = htons(9000);

    int opt = 1;
    setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
    bind(lfd, (struct sockaddr *)&addr, sizeof(addr));
    listen(lfd, 128);

    struct sockaddr_in peer;
    socklen_t peerlen = sizeof(peer);
    int cfd = accept(lfd, (struct sockaddr *)&peer, &peerlen);

    char buf[128] = {0};
    int n = recv(cfd, buf, sizeof(buf), 0);
    send(cfd, buf, n, 0);

    close(cfd);
    close(lfd);
    return 0;
}

这段代码按顺序做了七件事：创建socket、允许端口复用、绑定地址、进入监听、接受连接、收数据、发数据。每一句背后都对应一个协议状态转变。bind把socket和本地IP端口绑定；listen让内核开始接受SYN，连接排队进入accept队列；accept从队列取走一个已完成握手的连接，返回一个全新的fd。注意我在bind前先设置了SO_REUSEADDR，这是服务端重启时的救命配置，否则上次程序留下的TIME_WAIT会让bind失败。

6.2 最小TCP客户端

再看看客户端：

c复制#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <arpa/inet.h>

int main() {
    int fd = socket(AF_INET, SOCK_STREAM, 0);

    struct sockaddr_in addr = {0};
    addr.sin_family = AF_INET;
    inet_pton(AF_INET, "127.0.0.1", &addr.sin_addr);
    addr.sin_port = htons(9000);

    if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) < 0) {
        perror("connect");
        return -1;
    }

    send(fd, "hello tcp", 9, 0);
    char buf[128] = {0};
    int n = recv(fd, buf, sizeof(buf), 0);
    printf("recv %d bytes: %s\n", n, buf);

    close(fd);
    return 0;
}

客户端比服务端少了好几部戏：不需要bind，内核在connect时自动从临时端口范围挑一个源端口；不需要listen和accept，connect本身就走完了三次握手，成功后直接返回。这也是为什么正常客户端很少遇到"端口被占用"——自动挑的临时端口千千万，除非你手贱去bind一个固定端口，或者撞上TIME_WAIT复用的特殊情形。

6.3 从代码反推协议行为

代码跑起来之后，有几件事值得亲手验证。第一，recv返回0表示对端关闭，此时必须close自己的fd，否则就是CLOSE_WAIT的温床；close调用只是把fd引用计数减一，真正发FIN是在最后一个持有该socket的引用释放时，多进程或多线程共享fd时尤其容易踩。第二，accept返回的是一个全新socket，监听fd继续接收新连接，这就是"单端口百万连接"的代码根据，一个进程配上epoll，就能吃下海量并发。第三，TCP是字节流，没有消息边界，你send两次"hello"和"world"，对端recv可能一次收到"helloworld"，也可能分两次，应用层必须自己约定消息边界，这是无数新手被坑的地方，也是和UDP最直观的行为差异。

如果机子上有tcpdump，建议再做一次实验：启动服务端后执行tcpdump -i lo port 9000，然后启动客户端，你会看到SYN、SYN-ACK、ACK三条记录，再等程序结束，又能看到FIN、ACK、FIN、ACK四条记录。把抓包结果和代码里的系统调用对上号，TCP协议在你脑子里就活了，以后再背状态转换图，也会觉得顺理成章。

最后说点个人体会。我带过的新人里，能把socket接口背得滚瓜烂熟的大有人在，但一遇到重传、TIME_WAIT、CLOSE_WAIT就懵。原因很简单，大家背的是接口，不是协议行为。我的建议很土但很管用：找一台本机，装个抓包工具，把三次握手、四次挥手、快速重传、窗口收缩这些现象一个个亲手抓出来看一遍。花一个下午，胜过刷一百个面试题。以后再遇到"地址已在使用""连接卡住""重传率高"，你至少知道去哪一层找证据，心里不慌，手上的操作也有方向。