TCP/IP基础回顾：Socket通信原理、端口与连接、TCP三次握手与四次挥手、数据包结构

各位同学，咱们今天聊点“老本行”——TCP/IP。你可能会想：“这玩意儿我大学就学过，还用再讲？”

嗯，我在半导体设备现场摸爬滚打这么多年，发现一个规律：HSMS连不上的问题，十有八九是TCP/IP基础没吃透。不是协议本身多难，而是你排查时脑子里没有那张“数据包怎么走”的图。

所以这一章，咱们不背书，我带你从Socket通信原理开始，把三次握手、四次挥手、数据包结构这些硬骨头，用工程师的视角重新啃一遍。

2.1 Socket通信：说白了就是“两个程序打电话”

Socket是什么？我习惯把它理解成一个通信的“插座”。一端插在设备端（比如你的晶圆传输平台），另一端插在主机（比如MES系统），中间通过TCP/IP协议栈传数据。

在HSMS场景里，设备端通常作为客户端主动发起连接，主机作为服务器端监听端口。我见过不少新手把角色搞反，结果设备死活连不上主机——其实不是代码错了，是Socket角色没配对。

Socket通信的基本流程（以HSMS为例）

1. 服务器端（主机）：创建Socket → 绑定端口（比如5000） → 监听 → 接受连接
2. 客户端（设备）：创建Socket → 连接服务器IP+端口 → 发送数据
3. 数据传输：双方通过已建立的连接读写数据
4. 关闭连接：任意一方调用close()

2.2 端口与连接：别让端口号“打架”

端口号范围是0~65535。其中0~1023是知名端口，留给HTTP、FTP这些标准服务。HSMS通常用5000~9999之间的端口，具体看设备厂商定义。

端口范围	用途	HSMS相关说明
0~1023	知名端口（系统服务）	不要占用，否则可能冲突
1024~49151	注册端口（用户服务）	HSMS常用区间，如5000、6000
49152~65535	动态/私有端口	临时连接使用，设备端自动分配

你想想看，如果设备端和主机端都用了同一个端口号，会发生什么？端口冲突。我在调试某款刻蚀设备时，就遇到过主机端端口被其他进程占用，导致HSMS连接一直超时。排查了半天，最后用netstat -ano一看，才发现是另一个测试程序占着端口没释放。

2.3 TCP三次握手：为什么是三次？

TCP是面向连接的协议，通信前必须先建立连接。三次握手就是建立连接的过程。说白了，就是双方互相确认：“你准备好了吗？”“我准备好了！”“那咱们开始吧！”

我画了一张流程图，帮你把三次握手的过程刻在脑子里：

三次握手的核心目的：同步双方的序列号。第一次握手，客户端告诉服务器“我要连你，我的初始序列号是x”；第二次握手，服务器回应“收到，我的初始序列号是y”；第三次握手，客户端确认“好的，开始传数据吧”。

我在调试HSMS时，经常用Wireshark抓包看三次握手。如果只看到SYN没看到SYN+ACK，那基本是防火墙把包丢了，或者服务器端口没开。如果看到SYN+ACK但没看到最后的ACK，那可能是客户端网络有问题。

2.4 TCP四次挥手：好聚好散

通信结束后，需要断开连接。四次挥手就是“分手”的过程。为什么是四次？因为TCP是全双工的，双方都要独立关闭自己的通道。

四次挥手的关键点：

• 第一次挥手：主动关闭方发送FIN，表示“我这边没数据要发了”
• 第二次挥手：被动关闭方回复ACK，表示“收到，但我可能还有数据要发”
• 第三次挥手：被动关闭方发送FIN，表示“我这边也发完了”
• 第四次挥手：主动关闭方回复ACK，然后进入TIME_WAIT状态

2.5 TCP数据包结构：看懂报文才能定位问题

TCP数据包（报文段）的结构，说白了就是一堆控制字段 + 数据。你不需要背下所有字段，但以下几个必须记住，因为排查HSMS问题时经常用到：

字段	长度	作用	排查要点
源端口 / 目的端口	各16位	标识通信进程	检查端口号是否匹配配置
序列号（seq）	32位	数据字节流的编号	乱序或丢包时检查seq是否连续
确认号（ack）	32位	期望收到的下一个seq	确认对方是否收到数据
标志位	9位	控制连接状态（SYN、ACK、FIN等）	看标志位就知道当前处于握手还是挥手阶段
窗口大小	16位	流量控制，告诉对方自己能收多少	窗口为0表示接收方缓冲区满了
校验和	16位	检测数据是否损坏	校验和错误说明链路层有问题

2.6 本章小结：一张图记住TCP/IP核心

好了，咱们把TCP/IP的核心知识点串起来。下面这张图，我建议你保存下来，以后排查HSMS连接问题时，先对照这张图过一遍：

这一章的内容，说白了就是为后续的HSMS连接调试打地基。你想想看，如果连TCP三次握手都看不懂，那HSMS的Select.req、Linktest.req这些消息交互就更难理解了。