刚结束一个本地产物部署任务又碰上熟悉的端口被占错误“error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address”。这个报错在网上搜一下能找到一大堆但很多新手压根没弄明白背后的TCP通信原理只能瞎重启硬碰运气。今天借“网络编程基础之TCP基本通信”这个话题把TCP里最核心的socket通信流程、三次握手四次挥手、以及那些高频出现的连接异常完整捋一遍。这篇东西不堆概念直接对照实操讲适合刚入门的开发者也适合那些写了好几年业务代码但没系统整理过TCP细节的朋友。1. TCP通信的核心知识点1.1 为什么大多数通信场景都选TCPTCP全称是Transmission Control Protocol传输控制协议它是TCP/IP四层模型中传输层的核心协议。和UDP那种“发出去就不管”的传输方式相比TCP最核心的卖点就是可靠传输数据没到、到了但损坏、或者重复到达TCP都能通过序号、确认应答、重传、校验和这些机制把问题兜住。打个生活化比方UDP像你往宿舍楼下喊一句话喊完就完了至于对方听没听清、听没听到你根本不关心。TCP则像寄一封挂号信每一层中转都要签字确认最后收件人还得签收中间任何一环出问题都会重新投递保证对方拿到的内容和你寄出时一模一样。正因为TCP有这种可靠性HTTP、HTTPS、SSH、FTP、数据库连接以及大量物联网协议底层清一色都是TCP。甚至在工控领域常见的Modbus TCP本质也就是把传统的Modbus RTU报文封装在TCP报文里传输。理解了基础TCP通信再去看这些上层协议会顺畅很多。1.2 TCP三次握手与四次挥手三次握手是TCP建立连接的过程。客户端先发送一个SYN报文服务端收到后回复SYNACK客户端再回一个ACK至此连接建立双方进入数据传输阶段。为什么非要三次而不是两次核心原因是要确认双方的收发能力都正常。第一次握手服务端确认了客户端的发送能力第二次握手客户端确认了服务端的接收和发送能力第三次握手服务端确认了客户端的接收能力。只有三次握手双方才能确认“你能收我能发我能收你能发”这四个维度都成立。如果只握手两次服务端无法确认客户端是否具备接收能力万一客户端接收有问题服务端发了数据也没人完整接收。四次挥手则是断开连接的过程。主动关闭方发送FIN对端回复ACK然后对端再发送FIN主动关闭方再回ACK。这里比握手多一次是因为TCP支持半关闭状态。实际数据传输中一方发送完数据后它的发送通道可以关闭但接收通道还能继续收数据所以需要两端各自独立地关闭自己的发送方向。1.3 TCP报文结构速览TCP报文头部结构是理解各种抓包结果的基础。一个标准的TCP报文头有20字节固定部分主要字段包括源端口和目的端口各占2字节用来标识通信的应用进程序号和确认号各占4字节这是可靠传输和流量控制的基础标志位包含URG、ACK、PSH、RST、SYN、FIN其中SYN用于建立连接FIN用于断开连接RST用于异常重置连接ACK用于确认窗口大小占2字节用于流量控制告知对方自己还能接收多少数据用Wireshark抓包时你看到的SYN、ACK、FIN这些标识就是报文头里这些标志位的直观呈现。很多TCP异常场景比如连接被重置、超时重传都能通过抓包后观察这些标志位的配合情况来定位。1.4 TCP和UDP到底怎么选每次讲TCP几乎都会有人问TCP和UDP的区别。整理成表格最直观对比维度TCPUDP连接状态面向连接必须先建立连接无连接直接发数据可靠性可靠有确认、重传机制不可靠丢了不管传输效率较慢有握手和确认开销快无额外开销数据边界字节流无消息边界数据报有消息边界典型场景HTTP、FTP、数据库、文件传输音视频直播、DNS查询、游戏数据上报实际项目中如果对数据完整性要求很高比如文件上传、接口调用、设备控制指令果断选TCP。如果是音视频这种丢几帧也无所谓的场景或者要求极低延迟的实时通信UDP更合适。有些实际场景是TCP和UDP配合使用比如RTSP流媒体协议就用TCP传控制指令、UDP传音视频数据。2. Socket基本通信实操指南2.1 服务端的固定开发流程不管是C、C、Java、Go还是PythonTCP服务端的socket编程套路高度一致核心就六个步骤创建socket指定地址族、套接字类型和协议绑定IP和端口调用bind开启监听调用listen等待客户端接入调用accept此时程序会阻塞在这里收发数据调用read/write或recv/send关闭连接调用close这里有个关键点很多人会搞混listen和accept的区别。listen只是把socket变成被动监听状态告诉内核“我可以接受连接了”accept才是真正从已完成握手的连接队列里取一个连接出来交给应用程序处理。我在讲解的时候喜欢用饭馆的类比socket是饭馆大门bind是确定饭馆开在哪条街多少号listen是挂上“营业中”的牌子accept是服务员接待进店的客人。每次accept返回一个新的socket fd专门负责和这个客户端通信原先的监听socket fd继续等新客人。2.2 客户端的固定开发流程客户端比服务端简单得多核心三步创建socket调用connect发起连接这个动作会触发三次握手收发数据后关闭连接客户端不需要bind和listen因为客户端用的是临时端口内核会自动分配一个可用的源端口。如果connect失败客户端进程通过返回错误就知道网络不可达、服务端没监听或者连接被拒。而在网络上我们经常会看到“tcp connect超时”的报错这通常意味着服务端存在但不可达比如防火墙丢包、路由不通。connect超时问题到第4章再详细展开。2.3 最小可用的TCP通信代码示例用Go写一个最简TCP回显服务代码量很少但完整覆盖了服务端和客户端两端。Go标准库的net包把socket操作封装得很清晰适合观察通信流程。package main import ( fmt net io ) func main() { // 1. 监听本地8888端口 listener, err : net.Listen(tcp, 127.0.0.1:8888) if err ! nil { fmt.Println(listen failed:, err) return } defer listener.Close() fmt.Println(server listening on 127.0.0.1:8888) // 2. 循环接受客户端连接 for { conn, err : listener.Accept() if err ! nil { fmt.Println(accept failed:, err) continue } // 3. 每个连接单独开一个goroutine处理 go handleConn(conn) } } func handleConn(conn net.Conn) { defer conn.Close() buf : make([]byte, 4096) for { n, err : conn.Read(buf) if err io.EOF { fmt.Println(client closed connection) return } if err ! nil { fmt.Println(read failed:, err) return } fmt.Printf(received %d bytes: %s\n, n, string(buf[:n])) // 回显数据给客户端 conn.Write(buf[:n]) } }package main import ( fmt net ) func main() { // 1. 连接服务端 conn, err : net.Dial(tcp, 127.0.0.1:8888) if err ! nil { fmt.Println(dial failed:, err) return } defer conn.Close() // 2. 发送数据 message : hello, tcp server conn.Write([]byte(message)) fmt.Println(sent:, message) // 3. 读取服务端回复 buf : make([]byte, 4096) n, err : conn.Read(buf) if err ! nil { fmt.Println(read failed:, err) return } fmt.Printf(received: %s\n, string(buf[:n])) }先把服务端程序跑起来再运行客户端就能看到完整的TCP通信过程。如果服务端没启动直接跑客户端通常会得到connection refused的错误对应Wireshark里能看到客户端发SYN后收到RST。2.4 端口绑定失败和地址占用问题排查回到开头的报错error: listen tcp 127.0.0.1:11434: bind: only one usage of each socket address。这个错误在Windows和Linux上都很常见含义很直接你尝试监听的IP和端口组合已经被其他进程占用了。这种问题在开发环境中高发尤其是像Ollama这类本地服务。我那次遇到的就是本地服务上一次异常退出监听的端口没有被释放或者有另一个进程占着11434。排查步骤很简单# Linux查看端口占用 netstat -tlnp | grep 11434 # 或 lsof -i :11434 # Windows查看端口占用 netstat -ano | findstr 11434拿到占用端口的进程PID后确认这个进程没用了再kill掉然后重新启动服务就好了。这里补充一个容易忽略的点bind时指定的IP地址和端口走的是本地回环地址127.0.0.1那服务就只能从本机访问。如果想从局域网其他机器访问需要监听0.0.0.0或者具体的网卡IP。很多新手第一次做TCP通信服务端监听127.0.0.1然后在另一台机器上连不上卡了半天才发现是绑定地址的问题。文章开头那个报错信息里其实还藏着这个问题的一半监听127.0.0.1意味着只能本机访问。另外还有一类占用情况是TIME_WAIT状态导致的端口暂不可用。比如服务端进程端口刚释放但是连接处于TIME_WAIT状态此时立即重启绑定同一个端口个别系统会报地址占用。实际开发中可以设置SO_REUSEADDR选项让端口复用。Go语言里可以通过net.ListenConfig设置Java里ServerSocket有个setReuseAddress方法C语言用setsockopt设置。2.5 给connect设置超时默认情况下TCP的connect可能会因为网络问题长时间阻塞比如对端IP不可达且防火墙丢弃了SYN包系统默认的超时时间可能长达两分钟。生产环境不可能让一个连接请求卡这么久所以必须给connect设置超时。Go语言里用net.DialTimeoutconn, err : net.DialTimeout(tcp, 192.168.1.100:8080, 3*time.Second) if err ! nil { fmt.Println(connect timeout:, err) return }Python里用socket的settimeoutimport socket s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.settimeout(3) try: s.connect((192.168.1.100, 8080)) except socket.timeout: print(connect timeout)超时时间的设置要结合业务场景。本地局域网设备通信3秒足够了跨公网的业务可以放宽到5秒到10秒。设置太短容易误判设置太长又影响用户体验。合理的做法是连接受超时设一个硬上限连接建立后的读写也单独设置超时这是很多线上故障的真凶。3. 高频异常与排查技巧3.1 TCP connection reset by peer“curl: (35) tcp connection reset by peer”这类报错在网络请求中很常见。这个错误的意思是一端正在通信时对端直接发送了RST报文重置了连接没有走正常的四次挥手流程。触发场景大致有以下几类服务端进程崩溃退出内核会发送RST给已连接的客户端服务端accept之后应用层还没来得及处理就把连接关闭了客户端发送数据时服务端已经关闭了连接防火墙或中间设备主动发送了RST包连接被对端应用主动踢掉比如某些服务端有连接空闲超时策略排查这类问题第一件事就是抓包。用wireshark或者tcpdump查看连接断开前的报文如果看到RST标志位再结合RST包出现的位置判断是谁发的。如果RST由服务端发出重点检查服务端程序逻辑是否主动关闭连接或异常退出。如果RST由中间设备发出要检查是否有防火墙策略误伤。一个我在实际项目中踩过的坑服务端每处理完一次请求就close连接但客户端认为连接还活着会重复使用这个连接发下一条数据结果就时不时报connection reset。解决方法是客户端每次请求前严格判断连接状态或者服务端响应里明确告诉客户端连接即将关闭让客户端主动重连。3.2 TCP粘包问题与拆包方案TCP是字节流协议它不像UDP那样一个数据报对应一条消息应用层写入的数据到了TCP层被当作连续的字节流接收方读到的数据边界和发送方写入的边界完全可能不一致。这就产生了经典的粘包问题。比如客户端连续发送了“hello”和“world”服务端可能一次就读到“helloworld”也可能读到“hel”和“loworld”这取决于底层缓冲和调度时机。需要明确一点这不是TCP协议的错误而是TCP流式传输的特性。解决粘包问题的核心手段是应用层自己定义消息边界。业界常用的方案有四种固定长度每个消息定长不够补零特殊分隔符比如用\n、\r\n作为消息边界长度前缀每个消息前面加一个4字节的字段声明消息长度自定义协议头类似HTTP那样头部包含body长度实际项目中最推荐第三个方案长度前缀加二进制协议。比如定义消息格式为“4字节长度 业务数据”服务端先读4字节得到长度再读对应长度的数据完整还原一条消息。Go语言里可以用io.ReadFull来精确读取指定字节数// 读取4字节长度字段 lenBuf : make([]byte, 4) if _, err : io.ReadFull(conn, lenBuf); err ! nil { return err } length : binary.BigEndian.Uint32(lenBuf) // 按长度读取消息体 bodyBuf : make([]byte, length) if _, err : io.ReadFull(conn, bodyBuf); err ! nil { return err }3.3 端口数量与连接数量限制有人问“C# tcp连接数量多少”这类问题其实需要拆成两个维度看单机最大端口数和单进程最大文件描述符数。从客户端角度看一个TCP连接的标识是四元组源IP、源端口、目标IP、目标端口。客户端每次发起到同一个服务端的连接都会占用一个本地端口而端口数量只有65536个减去保留端口理论上客户端到同一个服务端的连接数上限大概在6万左右。如果需要更大的连接数需要增加客户端IP或用多网卡。从服务端角度看接受的连接数不受端口数量限制因为服务端所有连接共用一个监听端口但受进程能打开的文件描述符数量限制。在Linux上可以用ulimit -n查看默认值通常是1024对于高并发服务显然是远远不够的。很多线上服务连接数上不去先查这个。还有一个隐藏限制是内核参数net.ipv4.ip_local_port_range它决定了本地自动分配的端口范围默认通常是32768到60999这也解释了为什么客户端到同一个服务端的并发连接数会被限制在约3万个。想提高这个限制可以修改系统内核参数。3.4 Wireshark抓包与分析TCP的三次握手和四次挥手排查TCP交互问题抓包是最直接的手段。如果你第一次抓包打开wireshark选择对应的网卡设置过滤条件tcp.port 8888然后执行一次客户端连接就能抓到完整的握手挥手报文。抓包后怎么快速看建连是否正常找到第一个SYN报文观察它是否正常发出再看服务端是否回了SYNACK最后看客户端是否回了ACK。三步齐全代表三次握手成功。如果只有SYN没有SYNACK大概率是防火墙拦截如果客户端收到RST大概率是服务端端口没监听。分析数据交互阶段的抓包时还有一个非常实用的技巧观察TCP报文头的Seq和ACK号的变化同步判断对端是否收到了数据。如果客户端一直重传同一个Seq号的数据说明对端没有返回ACK此时大概率是网络链路有问题或对端处理卡死。4. 进阶方向与实际应用扩展4.1 长连接的心跳探测与KeepAliveTCP长连接在空闲时可能出现中间链路静默断开的情况。比如客户端连着服务器超过一段时间没发数据中间路由器或NAT设备可能悄悄把这条连接丢弃了此时双方都不知道连接已经失效直到下次发送数据才发现。解决方案有两层TCP协议层面的keepalive和应用层应用层的自定义心跳。TCP自带的keepalive默认是关闭的开启后系统会周期性发送探测包默认探测周期通常是2小时这个时间对大多数场景来说太长了。所以更靠谱的是应用层自己做心跳客户端每隔一段时间发送一个心跳包服务端超过阈值没收到心跳就判定连接失效并清理。设计心跳机制时要考虑两个参数的配合心跳发送间隔要小于服务端判定失效的超时时间。比如服务端判定60秒没收到数据就断开客户端就每20秒发一个心跳包留足网络抖动的冗余。心跳消息不要传业务数据单独定义一种轻量级的消息类型避免影响正常业务消息的处理逻辑。4.2 IO模型与高并发连接处理如果只是写一个简单的TCP回显服务单线程或者每连接一个线程就够用了。但要处理高并发连接就必须考虑IO模型的选择。常见的方案有阻塞IO加多线程每连接一个线程、IO多路复用select、poll、epoll、事件驱动模型。Go语言通过goroutine天然支持高并发每个连接分配一个goroutine成本极低。C/C等语言高性能服务器一般用epollJava用NIO的Selector本质上都是IO多路复用机制。在Linux下epoll是目前最高效的IO多路复用方案它能同时监听大量socket只在有事件发生时唤醒应用去处理避免了阻塞和频繁轮询的开销。理解了这个机制再去看Tomcat这类容器的连接线程模型就会清晰很多容器里有专门的acceptor线程负责accept新连接然后把连接分配给工作线程去处理还有一堆后台线程做超时管理、连接检测。4.3 TCP与WebSocket的关系与区别很多人在做前端开发时接触WebSocket然后对“TCP和ws区别”感到困惑。简单理解TCP是传输层协议WebSocket是应用层协议。WebSocket依赖TCP提供可靠的传输能力HTTP也是同样的道理。和传统HTTP短连接相比WebSocket复用同一个TCP连接通过帧机制在应用层支持双向实时通信特别适合聊天、行情推送、协同编辑这类场景。从协议演进看WebSocket的握手建立在HTTP Upgrade机制上连接建立后升级为WebSocket数据帧格式底层仍然是TCP的可靠传输。在做协议选型时如果只是短连接请求响应场景用HTTP就好如果是长连接双向通信或服务端主动推送给客户端的场景WebSocket更合适如果是嵌入式设备与服务器通信直接基于TCP自定义协议往往更灵活轻量。4.4 工业物联网中的TCP应用TCP的应用远不止互联网领域。在工业控制中Modbus TCP是非常典型的例子。传统Modbus RTU基于串口通信工业以太网普及后Modbus TCP把相同的寄存器读写指令封装进TCP协议带来两个明显优势传输距离更远、支持更多节点同时通信。Modbus TCP的报文结构也很有代表性。它继承了Modbus协议的应用层格式额外增加了MBAP报文头其中包含事务处理标识符、协议标识符、长度和单元标识符。实际排查Modbus TCP通信问题时除了通用的TCP排查手段还要关注MBAP头的完整性、功能码是否正确、寄存器地址是否在设备支持范围内。嵌入式领域也大量使用TCP。ESP8266这类物联网模块通过AT命令或者SDK直接发起TCP连接可以连接手机上的上位机或云平台。在做这类设备通信时因为嵌入式设备的缓冲区普遍较小特别要做好TCP粘包拆包处理通常使用简单固定的帧格式。比如帧头长度数据CRC校验接收端通过状态机解析。这套思路和PC端网络编程没有本质区别只是多了对内存和计算资源的约束意识。5. 我的实操体会做了这么久的网络编程个人最大的体会是TCP面试背得再熟都不如自己亲手服务端连一次、抓一次包、排一次错来得深刻。写TCP通信代码最容易犯的错不是语法不会而是没把连接的生命周期想清楚。谁创建、谁关闭、什么时候FIN、什么时候RST、连接空闲了怎么办、超时了怎么办这些问题在动手前就应当有清晰的方案。遇到网络类报错别瞎猜先看报错类型再配合抓包确认最后结合应用逻辑定位。整个排查链路听起来简单但真的能帮你少走不少弯路。TCP通信是网络编程的基石把这层打扎实了HTTP、WebSocket、gRPC这些上层协议学起来都会轻松很多。