尧图网站建设 
搞网络编程绕不开 Socket这词儿听起来挺唬人其实它是操作系统给应用层提供的一套“通信接口”。爬虫抓数据、聊天室发消息、设备上报状态、远程连交换机查配置底层基本都有 Socket 在干活。我这些年因为工作原因前后在 Python、Java、VBA 里都写过 Socket 相关的东西算是把这套东西从原理到坑都趟了一遍。这篇就把我自己的实操经验整理出来。不管你是刚接触网络编程的学生还是做后端、搞自动化、写办公插件的开发只要需要让程序“跨进程、跨机器说话”这篇文章都能给你一套直接能用的方案。我会按“原理认知 → Python 实战 → Spring Boot WebSocket 实战 → VBA 跨语言调用 → 问题排查”的顺序来写代码都是能复制的过程中哪些地方最容易踩坑我也会强调。1. 先理解 Socket 本身比写代码更重要1.1 Socket 到底是什么一个电话类比就够了很多人一上来就查 API、抄代码结果遇到问题一头雾水。我建议先花 10 分钟把模型搞明白。Socket 直译是“插槽”你可以把它理解成两栋楼之间拉了一根电话线每栋楼门口装了一个电话机。你要跟对面的人通话得先在自家装好电话机、分配一个分机号然后拨号建立连接之后双方随时可以说话。这个“电话机”在操作系统里就是 Socket电话号码就是端口号楼房的地址就是 IP。所谓“Socket 网络编程”本质就是拿操作系统提供的这套接口自己实现一次“拨号、通话、挂断”。它不关心你家电话里说的语言是中文还是英文只保证“声音”能传过去。对应到技术层面就是不关心你传输的数据是 HTTP、FTP 还是自定义协议它只管字节流的可靠传输。1.2 TCP、UDP 与端口三个绕不开的核心概念Socket 编程里最常见的两个模式是 TCP 和 UDP很多人把它们当成二选一的零件其实它们是两种完全不同的通信策略。TCP 是面向连接的、可靠的字节流传输。连接前要“三次握手”就像两个人先互相确认“你听得见吗”“听得见你呢”“我也听见了”然后才开始正式说话。传输过程中如果数据丢了、错了协议栈会负责重传和纠正。它适合对完整性要求极高的场景比如文件传输、数据库同步、网页访问。代价是延迟稍高、连接开销大。UDP 则简单粗暴发完就算不确认对方收没收到也不保证顺序。就像往楼下扔纸条纸可能被风吹跑也可能后写的先到。但它快、开销小适合实时性优先的场景比如视频通话、游戏位置同步、DNS 查询。还要理解端口。一台服务器只有一个 IP但可以同时跑很多服务浏览器访问网页走 80/443SSH 走 22聊天软件可能走自定义端口。端口号就是操作系统区分“这个数据应该交给哪个应用处理”的标签。Socket 绑定的核心组合就是协议 本地 IP 本地端口 远端 IP 远端端口。在看连接状态时这五个维度可以帮助你快速定位问题。1.3 什么时候该用 Socket什么时候不该用有些场景并不需要你自己写原生 Socket用了反而给自己找麻烦前后端网页通信用 HTTP 或 WebSocket浏览器原生支持没必要用原生 Socket。微服务之间调用用成熟的 RPC 框架gRPC、Dubbo或消息队列。需要低延迟但又不愁网络环境可以考虑 UDP但要做好可靠性设计。真正需要 Socket 的场景通常是自定义二进制协议、内网设备通信交换机、打印机、传感器、没有现成封装库的编程环境、需要精准控制连接生命周期的底层工具。我自己的判断标准很简单如果技术栈里已经有封装好的协议库就千万别从 Socket 开始造轮子如果现有库满足不了或者你想搞明白底层原理那 Socket 就是绕不开的那一层。2. Python Socket 实战从零写一个 TCP 回显服务器2.1 Python 的 socket 模块核心 APIPython 的好处是标准库里直接带了 socket 模块不需要安装任何第三方包就能跑通整个流程。服务端和客户端的标准套路如下服务端核心流程是创建 socket → bind 绑定地址 → listen 开始监听 → accept 接受连接 → recv/send 收发数据 → close 关闭。客户端核心流程是创建 socket → connect 连接 → send/recv 收发 → close。对应到代码每个函数都有几个关键参数先看一段最简单的服务端import socket # 1. AF_INET 表示用 IPv4SOCK_STREAM 表示用 TCP server socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 2. 允许端口重用否则服务重启时经常报 Address already in use server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 3. 绑定到本机 9000 端口0.0.0.0 表示接受所有网卡的连接 server.bind((0.0.0.0, 9000)) # 4. 开始监听backlog 表示等待队列长度 server.listen(5) print(等待客户端连接...) # 5. 接受一个客户端连接返回新 socket 和客户端地址 conn, addr server.accept() print(f客户端地址: {addr}) data conn.recv(1024) print(f收到: {data.decode()}) conn.sendall(data) # 原样返回实现回显 conn.close() server.close()这段代码里有两个细节值得注意第一是SO_REUSEADDR。调试阶段程序经常崩溃重启如果 socket 没有设置这个选项你会发现重启时报“Address already in use”原因就是端口还在 TIME_WAIT 状态没过完 2MSL 周期。加上这个设置可以快速恢复服务生产环境下要评估安全影响但开发环境几乎必加。第二是accept()之后返回的是一个新的 socket 对象。原来的 server socket 只管监听真正收发数据的是 accept 返回的新连接这是新手最容易迷糊的地方。2.2 可复现的完整版多客户端并发回显服务器上面的例子只能处理一个连接实际场景里客户端肯定不止一个。真正的服务端需要在一个死循环里反复 accept而且每个连接都要能独立收发数据不然一个客户端卡住整个服务就瘫痪了。我用最基础的 threading 方案来处理并发没有引入复杂框架方便理解背后思路import socket import threading def handle_client(conn, addr): print(f客户端 {addr} 已连接) try: while True: data conn.recv(1024) if not data: print(f客户端 {addr} 断开) break print(f{addr} 发送: {data.decode(errorsignore)}) conn.sendall(data) # 回显 except ConnectionResetError: print(f客户端 {addr} 异常断开) finally: conn.close() server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(5) print(服务端已启动端口 9000) while True: conn, addr server.accept() t threading.Thread(targethandle_client, args(conn, addr)) t.start()这种方案在并发量不大的内部工具场景非常好用。但注意 Python 的 GIL 决定了 threading 不适合做 CPU 密集任务而且每个连接一个线程一两百个连接后线程开销就很明显。真要支撑大规模长连接需要换 asyncio、selectors 或者用第三方库但原理还是这个模型。客户端的代码就简单多了import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.settimeout(3) # 连接和接收数据的超时时间避免永久卡死 client.connect((127.0.0.1, 9000)) client.sendall(bhello server) resp client.recv(1024) print(resp.decode()) client.close()2.3 收到“半个包”怎么办粘包与拆包等你能跑通回显服务下一步一定会遇到经典问题粘包和拆包。TCP 是字节流协议没有消息边界。你调用 send 发送一条消息对端 recv 的时候拿到的可能只是这条消息的前半截也可能两条消息粘在一起一次性收到。很多新手在调试时发现数据是对的但数据一多就开始错乱多半就是这个原因。解决思路不外乎三种固定长度包每一条消息都按固定的字节数发送不够就补空。适合字段定长、协议固定的场景。分隔符协议每条消息末尾加一个特殊标记比如\r\n接收端按分隔符切分。适合文本协议实现最简单。长度前缀发送前先发 4 个字节表示后续消息长度接收端先读长度再读完整消息体。最通用适合混合二进制数据的业务协议。我自己写内部工具时最爱用长度前缀因为它的逻辑最好统一发送端import struct msg 你好服务端.encode(utf-8) prefix struct.pack(I, len(msg)) client.sendall(prefix msg)接收端import struct def recv_exact(conn, n): 严格读取 n 个字节确保不因为网络缓冲而少收 buf b while len(buf) n: chunk conn.recv(n - len(buf)) if not chunk: break buf chunk return buf length_data recv_exact(conn, 4) msg_len struct.unpack(I, length_data)[0] msg recv_exact(conn, msg_len)recv_exact这个函数太重要了。因为recv(1024)并不保证一次拿到 1024 字节它只是“最多拿 1024 字节”实际拿多少取决于内核缓冲区和网络状况。所以任何严谨的协议接收都必须手动“等够字节”这是我在接手别人代码时最先检查的点。2.4 Python 网络编程里的超时、阻塞与异常处理Python socket 默认是阻塞模式recv会一直卡住直到有数据。这在客户端偶尔等一会儿没问题但服务端某个连接不发送数据时对应线程就一直挂着浪费资源。解决办法是给 socket 设置超时client.settimeout(5) # 超过 5 秒没数据就抛 socket.timeout生产级的服务端一般用 select / epoll 做事件驱动不过这超出了入门范围。普通工具场景我建议至少做到三点设置超时、捕获socket.timeout、捕获ConnectionResetError和BrokenPipeError这两兄弟在连接被对端关闭时经常不约而同地出现。3. Spring Boot 集成 WebSocketYML 配置与真实生产坑3.1 WebSocket 和原生 Socket 不是一回事很多人刚接触 WebSocket 时会疑惑这是不是 Java 版的 Socket其实差别很大。原生 Socket 工作在传输层只要端口通就能连适合任意语言和任意客户端但浏览器里跑不了 JS 原生 TCP。WebSocket 是工作在应用层的协议它会先通过 HTTP 协议完成一次握手再把协议升级为 WebSocket之后双方维持一条长连接可以双向推送数据。所以 Spring Boot 里集成 WebSocket更多是为了解决“网页聊天”“实时通知”“在线协作”这类需求不需要你手动维护 TCP 连接。它和我们在第 2 章讲的 Python 原生 Socket是两个不同层级的东西但底层依然离不开 TCP。3.2 Spring Boot 集成 WebSocket 的标准姿势先添加依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency然后是application.yml这里必须注意一个关键点WebSocket 的端点路径和项目 context-path 是两个概念。很多人配置 WebSocket 的时候把“端点路径”混淆成“端口”其实端口还是用server.portWebSocket 路径是在代码的注册方法里定义的。一个典型的配置server: port: 8080 servlet: context-path: /myapp spring: application: name: socket-demo这里 context-path 是/myapp那后续 WebSocket 连接地址就应该是ws://localhost:8080/myapp/ws路径写错是浏览器一直连不上的常见原因。接着写配置类注册 WebSocket 处理器import org.springframework.context.annotation.Configuration; import org.springframework.web.socket.config.annotation.EnableWebSocket; import org.springframework.web.socket.config.annotation.WebSocketConfigurer; import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry; Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { private final ChatWebSocketHandler chatHandler; public WebSocketConfig(ChatWebSocketHandler chatHandler) { this.chatHandler chatHandler; } Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(chatHandler, /ws) .setAllowedOrigins(*); } }再写处理器核心业务都在这个类里import org.springframework.web.socket.*; import org.springframework.web.socket.handler.TextWebSocketHandler; import java.util.concurrent.ConcurrentHashMap; public class ChatWebSocketHandler extends TextWebSocketHandler { // 用 Map 保存会话方便向所有在线用户广播 private static final ConcurrentHashMapString, WebSocketSession SESSIONS new ConcurrentHashMap(); Override public void afterConnectionEstablished(WebSocketSession session) { SESSIONS.put(session.getId(), session); System.out.println(连接建立: session.getId()); } Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { // 收到客户端消息广播给所有人 for (WebSocketSession s : SESSIONS.values()) { if (s.isOpen()) { s.sendMessage(new TextMessage(收到消息: message.getPayload())); } } } Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) { SESSIONS.remove(session.getId()); System.out.println(连接关闭: session.getId()); } }前端 JS 也很固定const ws new WebSocket(ws://localhost:8080/myapp/ws); ws.onopen function() { console.log(连接成功); ws.send(hello); }; ws.onmessage function(event) { console.log(收到:, event.data); };3.3 经典报错failed to create server shutdown socket on address [localhost] and port [802]这条报错在遇到过的朋友里属于高频噩梦级别。它在服务启动阶段就蹦出来特别容易让人误以为是 WebSocket 配置出了问题实际上它跟你业务端的连接端口是两码事。这个报错背后通常是 Java 生态某个框架在准备“服务关闭监听”时往localhost:802上创建了一个 socket 失败。构成失败的原因主要有三种第一种是端口 802 被占用。可能是之前跑的服务进程没退干净也可能是别的软件占用了 802。排查命令在 Windows 上是netstat -ano | findstr 802在 Linux 上是netstat -anp | grep 802。如果发现 PID 还在直接taskkill或kill掉如果 PID 反复变化就要检查是否有工具自动拉起服务。第二种是localhost 解析异常。有些机器 hosts 文件里把 localhost 指向了 IPv6 的::1而 Java 默认可能先去解析 IPv6一旦本机 IPv6 被禁用或中间有干扰创建 socket 就会失败。此时把配置里的localhost显式改成127.0.0.1或者启动参数加上-Djava.net.preferIPv4Stacktrue一般立即解决。第三种是框架配置了其他 shutdown 端口。很多框架的关闭监听端口是可以自定义的如果你在 yml 里看到类似server.shutdown、management.server.port、shutdownPort这类配置检查它们的端口值是否和 802 冲突。报错自带的[localhost]和port [802]是两个关键线索顺着配置找一定能定位。我遇到过最隐蔽的场景是同一个服务器里部署了多个 Java 应用其中一个曾把 shutdown 端口配置成 802后来另一个应用也被配成了 802两个进程同时抢后启动的那个必然报这个错。建议多实例部署时给每个实例分配独立且显式声明的 shutdown 端口避免用随机值。3.4 WebSocket 生产配置的四个细节心跳保活WebSocket 本身没有超时踢人的机制但运营商和 Nginx 会清理空闲连接。建议前端自动发心跳每 30 到 50 秒发送一个 JSON 字符串比如{type:ping}服务端收到后回个{type:pong}。跨域限制前端页面和后端服务不在同一个域名就容易碰上跨域拒绝。setAllowedOrigins不要随便用*生产环境请写明确域名。Session 管理客户端断网时服务端不会立刻感知要结合心跳 WebSocketSession.isOpen()做兜底。长期不清理死连接会导致内存泄漏。线程安全ConcurrentHashMap是必须的因为 WebSocket 回调可能来自不同线程hashMap 在多线程条件下会因为扩容丢数据。4. 跨界需求VBA 调用 Window Socket 实现 Telnet4.1 为什么要在 Excel 里写网络编程很多老牌的运维体系里Excel 依然是业务人员最常用的数据处理工具。我遇到过一个需求每天要登录几十台交换机执行命令、把状态汇总成表格。手工 telnet 太慢于是就用 VBA 写一个小工具在 Excel 里直接调用 Socket自动连接设备、发命令、取返回、填单元格。这套玩法用熟了以后你会发现VBA 能做的远不止操作单元格它完全可以成为一个“接口汇聚层”从 Excel 里直接调 Windows 的 Socket 能力连接内网设备干一些原本需要专业工具才能干的活。4.2 方案 A用 MSWinsock 控件适合窗体场景如果你在 Excel 里用 UserForm 做界面最直接的方式是拖一个控件。在 VBA 编辑器里先点击“工具 → 引用”勾选Microsoft Winsock Control 6.0或者直接在工具箱里添加这个控件。使用起来非常简洁 假设窗体上放了一个名为 Winsock1 的 Winsock 控件 Winsock1.RemoteHost 10.0.0.1 Winsock1.RemotePort 23 Winsock1.Connect 非阻塞连接接收数据要写在控件的 DataArrival 事件里注意这属于异步事件不能直接在事件里做大量 UI 操作否则 Excel 会感觉卡顿Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long) Dim data As String Winsock1.GetData data, vbString 把收到的文本追加到文本框 TextBox1.Text TextBox1.Text data End Sub发送命令Winsock1.SendData show version vbCrLf这种方案下手最快但有个致命坑MSWinsock 控件在 64 位 Office 环境下的兼容性很差很多机器上根本引用不到。如果你公司 Office 是 64 位建议直接走方案 B。4.3 方案 B直接用 Winsock API不依赖控件API 方式不需要任何控件在标准模块里声明函数就能用。需要注意 64 位 Office 下Declare语句必须加PtrSafe关键字。核心代码如下Private Declare PtrSafe Function socket Lib ws2_32.dll (ByVal af As Long, ByVal sock_type As Long, ByVal protocol As Long) As Long Private Declare PtrSafe Function connect Lib ws2_32.dll (ByVal s As Long, ByRef name As sockaddr_in, ByVal namelen As Long) As Long Private Declare PtrSafe Function send Lib ws2_32.dll (ByVal s As Long, ByRef buf As Any, ByVal buflen As Long, ByVal flags As Long) As Long Private Declare PtrSafe Function recv Lib ws2_32.dll (ByVal s As Long, ByRef buf As Any, ByVal buflen As Long, ByVal flags As Long) As Long Private Declare PtrSafe Function closesocket Lib ws2_32.dll (ByVal s As Long) As Long Private Type sockaddr_in sin_family As Integer sin_port As Integer sin_addr As Long sin_zero(0 To 7) As Byte End Type这里要做一个字节序转换。网络字节序是大端模式而 Windows 端口号通常是小端模式所以端口 23 要经过htons转换。VBA 里没有内置 htens 函数需要自己写Private Function Htons(ByVal port As Long) As Integer Htons (port Mod 256) * 256 (port \ 256) End Function连接和发送的封装Dim sock As Long Dim saddr As sockaddr_in 创建 socketAF_INET2SOCK_STREAM1 sock socket(2, 1, 0) saddr.sin_family 2 saddr.sin_port Htons(23) saddr.sin_addr H0100A80A 这里实际是 10.0.0.1 的十六进制小端表示也可以封装 inet_addr 这里简化处理真正写代码时需要用 lstrcpyA 把 IP 转换成地址值 ret connect(sock, saddr, LenB(saddr))这段代码只是展示骨架最麻烦的是 IP 字符串转换需要用inet_addr或者Winsock 的 GetAddrByName处理。如果嫌 API 麻烦也可以先用方案 A 写原型再在部署时评估是否值得换 API。4.4 Telnet 客户端的协议要点与调试技巧Telnet 协议本身是 NVT网络虚拟终端文本协议绝大多数设备只需要发送纯文本命令末尾加\r\n即可。但要注意设备返回的数据里可能包含控制字符比如光标移动、颜色控制码。在 Excel 单元格里展示时最好按行切分只保留可打印字符 用 Split 按 vbCrLf 和 vbLf 切分行 Dim lines() As String lines Split(data, vbCrLf) For i 0 To UBound(lines) 去掉不可见控制字符 CleanLine Replace(lines(i), Chr(27), ) Next调试时可以先用 Windows 自带的 telnet 命令测一下设备是否支持明文登录再用 VBA 模仿同样的输入输出。注意 VBA 的 send 和 recv 都是阻塞的连接前一定要设置好超时否则设备不响应时 Excel 会直接假死。用 API 时可以把 socket 设成非阻塞模式但代码复杂度会上升内部工具场景我个人建议保持简单、加超时提示。5. 高频问题排查速查表与经验总结5.1 网络编程高频报错与解决方向这些年我在不同语言里遇到过的坑汇总成一张速查表报错或现象出现场景核心解决思路Connection refused客户端连接目标端口失败目标服务是否监听该端口防火墙是否拦截目标 IP 是否正确Address already in use服务端重启时端口被占用检查残留进程启用SO_REUSEADDR等待 TIME_WAIT 超时TimeoutError: timed out连接或接收数据长时间无响应检查网络连通性确认目标 IP/端口路由可达确认防火墙没有静默丢弃BrokenPipeError向已关闭的连接写数据对端主动关闭写数据前先判断连接状态捕获异常并清理数据收到一半或粘在一起TCP 字节流环境设计长度前缀或分隔符协议使用 recv 循环读取完整字节failed to create server shutdown socketJava 服务启动失败排查端口 802 被占、localhost 解析异常、shutdown 端口冲突WebSocket 握手 404前端连不上后端检查 context-path 和端点路径拼接是否正确检查 Nginx 代理是否配置升级头recv 阻塞导致 UI 卡死客户端同步等待设置 socket 超时或改用异步/非阻塞模式5.2 排查网络问题必备三板斧连接不上时不要瞎改代码先按顺序检查三层状态。第一层是验证端口是否通。Windows 和 Linux 都能用telnet 目标IP 目标端口做快速验证能连上说明网络通、端口在监听连不上就要继续排查。有些现代系统 telnet 默认没装也可以改用 PowerShell 的Test-NetConnection -Port 80 目标IP。第二层是看连接状态。netstat -ano可以列出所有 TCP 连接本地端口、远端地址、状态LISTENING / ESTABLISHED / TIME_WAIT都能看到。如果你发现服务端该监听的端口没有 LISTENING说明程序压根没起来如果 LISTENING 但客户端连不上问题基本在防火墙或路由。第三层是抓包确认。Wireshark 是排查网络问题的终极手段过滤条件写tcp.port 9000就能看到三次握手是否完成、数据包有没有重传。SYN 发出去没回应大概率被防火墙丢了三次握手成功但应用层没数据那就是代码逻辑问题。抓包能帮你把“网络问题”和“代码问题”彻底切开。我有一次排查客户端连接服务端偶发超时代码层面怎么都找不到原因最后抓包发现是服务端网卡的 TCP 分段卸载导致延迟换个网卡驱动后问题消失。这种经历只有抓包才能给你答案。5.3 我个人的三个固定习惯最后分享几个我自己写网络程序时雷打不动的习惯。第一个是连接用完必须关闭。网络连接是稀缺资源忘关连接导致连接数耗尽是我见过最多的生产事故源头。写 Python 用try/finally写 Java 用try-with-resources写 VBA 也要在Exit Sub前把所有 socket 关掉。第二个是所有网络操作必须显式设置超时。默认阻塞模式下一旦对端死掉你的代码可能永远卡住。无论客户端还是服务端连接和接收都要有超时阈值即使只是给一个合理的报错也比无限期挂死好。第三个是协议先行代码后写。两个人一起做联调各写各的最怕的就是消息格式不统一。我会在写第一行代码前先把协议文档固定下来字段顺序、长度、编码、结束标记。哪怕只是自己写给自己用也照样写因为三天后你看着代码根本回忆不起当初定义的“类型 1 表示心跳”是什么意思。这行当没有什么高深莫测的东西无非是把原理理解透把每一步控制好失败了就按层排查。希望这篇文章能帮你少走我当年走过的弯路。 Socket网络编程实战：从原理到Python、WebSocket与VBA应用
搞网络编程绕不开 Socket这词儿听起来挺唬人其实它是操作系统给应用层提供的一套“通信接口”。爬虫抓数据、聊天室发消息、设备上报状态、远程连交换机查配置底层基本都有 Socket 在干活。我这些年因为工作原因前后在 Python、Java、VBA 里都写过 Socket 相关的东西算是把这套东西从原理到坑都趟了一遍。这篇就把我自己的实操经验整理出来。不管你是刚接触网络编程的学生还是做后端、搞自动化、写办公插件的开发只要需要让程序“跨进程、跨机器说话”这篇文章都能给你一套直接能用的方案。我会按“原理认知 → Python 实战 → Spring Boot WebSocket 实战 → VBA 跨语言调用 → 问题排查”的顺序来写代码都是能复制的过程中哪些地方最容易踩坑我也会强调。1. 先理解 Socket 本身比写代码更重要1.1 Socket 到底是什么一个电话类比就够了很多人一上来就查 API、抄代码结果遇到问题一头雾水。我建议先花 10 分钟把模型搞明白。Socket 直译是“插槽”你可以把它理解成两栋楼之间拉了一根电话线每栋楼门口装了一个电话机。你要跟对面的人通话得先在自家装好电话机、分配一个分机号然后拨号建立连接之后双方随时可以说话。这个“电话机”在操作系统里就是 Socket电话号码就是端口号楼房的地址就是 IP。所谓“Socket 网络编程”本质就是拿操作系统提供的这套接口自己实现一次“拨号、通话、挂断”。它不关心你家电话里说的语言是中文还是英文只保证“声音”能传过去。对应到技术层面就是不关心你传输的数据是 HTTP、FTP 还是自定义协议它只管字节流的可靠传输。1.2 TCP、UDP 与端口三个绕不开的核心概念Socket 编程里最常见的两个模式是 TCP 和 UDP很多人把它们当成二选一的零件其实它们是两种完全不同的通信策略。TCP 是面向连接的、可靠的字节流传输。连接前要“三次握手”就像两个人先互相确认“你听得见吗”“听得见你呢”“我也听见了”然后才开始正式说话。传输过程中如果数据丢了、错了协议栈会负责重传和纠正。它适合对完整性要求极高的场景比如文件传输、数据库同步、网页访问。代价是延迟稍高、连接开销大。UDP 则简单粗暴发完就算不确认对方收没收到也不保证顺序。就像往楼下扔纸条纸可能被风吹跑也可能后写的先到。但它快、开销小适合实时性优先的场景比如视频通话、游戏位置同步、DNS 查询。还要理解端口。一台服务器只有一个 IP但可以同时跑很多服务浏览器访问网页走 80/443SSH 走 22聊天软件可能走自定义端口。端口号就是操作系统区分“这个数据应该交给哪个应用处理”的标签。Socket 绑定的核心组合就是协议 本地 IP 本地端口 远端 IP 远端端口。在看连接状态时这五个维度可以帮助你快速定位问题。1.3 什么时候该用 Socket什么时候不该用有些场景并不需要你自己写原生 Socket用了反而给自己找麻烦前后端网页通信用 HTTP 或 WebSocket浏览器原生支持没必要用原生 Socket。微服务之间调用用成熟的 RPC 框架gRPC、Dubbo或消息队列。需要低延迟但又不愁网络环境可以考虑 UDP但要做好可靠性设计。真正需要 Socket 的场景通常是自定义二进制协议、内网设备通信交换机、打印机、传感器、没有现成封装库的编程环境、需要精准控制连接生命周期的底层工具。我自己的判断标准很简单如果技术栈里已经有封装好的协议库就千万别从 Socket 开始造轮子如果现有库满足不了或者你想搞明白底层原理那 Socket 就是绕不开的那一层。2. Python Socket 实战从零写一个 TCP 回显服务器2.1 Python 的 socket 模块核心 APIPython 的好处是标准库里直接带了 socket 模块不需要安装任何第三方包就能跑通整个流程。服务端和客户端的标准套路如下服务端核心流程是创建 socket → bind 绑定地址 → listen 开始监听 → accept 接受连接 → recv/send 收发数据 → close 关闭。客户端核心流程是创建 socket → connect 连接 → send/recv 收发 → close。对应到代码每个函数都有几个关键参数先看一段最简单的服务端import socket # 1. AF_INET 表示用 IPv4SOCK_STREAM 表示用 TCP server socket.socket(socket.AF_INET, socket.SOCK_STREAM) # 2. 允许端口重用否则服务重启时经常报 Address already in use server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) # 3. 绑定到本机 9000 端口0.0.0.0 表示接受所有网卡的连接 server.bind((0.0.0.0, 9000)) # 4. 开始监听backlog 表示等待队列长度 server.listen(5) print(等待客户端连接...) # 5. 接受一个客户端连接返回新 socket 和客户端地址 conn, addr server.accept() print(f客户端地址: {addr}) data conn.recv(1024) print(f收到: {data.decode()}) conn.sendall(data) # 原样返回实现回显 conn.close() server.close()这段代码里有两个细节值得注意第一是SO_REUSEADDR。调试阶段程序经常崩溃重启如果 socket 没有设置这个选项你会发现重启时报“Address already in use”原因就是端口还在 TIME_WAIT 状态没过完 2MSL 周期。加上这个设置可以快速恢复服务生产环境下要评估安全影响但开发环境几乎必加。第二是accept()之后返回的是一个新的 socket 对象。原来的 server socket 只管监听真正收发数据的是 accept 返回的新连接这是新手最容易迷糊的地方。2.2 可复现的完整版多客户端并发回显服务器上面的例子只能处理一个连接实际场景里客户端肯定不止一个。真正的服务端需要在一个死循环里反复 accept而且每个连接都要能独立收发数据不然一个客户端卡住整个服务就瘫痪了。我用最基础的 threading 方案来处理并发没有引入复杂框架方便理解背后思路import socket import threading def handle_client(conn, addr): print(f客户端 {addr} 已连接) try: while True: data conn.recv(1024) if not data: print(f客户端 {addr} 断开) break print(f{addr} 发送: {data.decode(errorsignore)}) conn.sendall(data) # 回显 except ConnectionResetError: print(f客户端 {addr} 异常断开) finally: conn.close() server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((0.0.0.0, 9000)) server.listen(5) print(服务端已启动端口 9000) while True: conn, addr server.accept() t threading.Thread(targethandle_client, args(conn, addr)) t.start()这种方案在并发量不大的内部工具场景非常好用。但注意 Python 的 GIL 决定了 threading 不适合做 CPU 密集任务而且每个连接一个线程一两百个连接后线程开销就很明显。真要支撑大规模长连接需要换 asyncio、selectors 或者用第三方库但原理还是这个模型。客户端的代码就简单多了import socket client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.settimeout(3) # 连接和接收数据的超时时间避免永久卡死 client.connect((127.0.0.1, 9000)) client.sendall(bhello server) resp client.recv(1024) print(resp.decode()) client.close()2.3 收到“半个包”怎么办粘包与拆包等你能跑通回显服务下一步一定会遇到经典问题粘包和拆包。TCP 是字节流协议没有消息边界。你调用 send 发送一条消息对端 recv 的时候拿到的可能只是这条消息的前半截也可能两条消息粘在一起一次性收到。很多新手在调试时发现数据是对的但数据一多就开始错乱多半就是这个原因。解决思路不外乎三种固定长度包每一条消息都按固定的字节数发送不够就补空。适合字段定长、协议固定的场景。分隔符协议每条消息末尾加一个特殊标记比如\r\n接收端按分隔符切分。适合文本协议实现最简单。长度前缀发送前先发 4 个字节表示后续消息长度接收端先读长度再读完整消息体。最通用适合混合二进制数据的业务协议。我自己写内部工具时最爱用长度前缀因为它的逻辑最好统一发送端import struct msg 你好服务端.encode(utf-8) prefix struct.pack(I, len(msg)) client.sendall(prefix msg)接收端import struct def recv_exact(conn, n): 严格读取 n 个字节确保不因为网络缓冲而少收 buf b while len(buf) n: chunk conn.recv(n - len(buf)) if not chunk: break buf chunk return buf length_data recv_exact(conn, 4) msg_len struct.unpack(I, length_data)[0] msg recv_exact(conn, msg_len)recv_exact这个函数太重要了。因为recv(1024)并不保证一次拿到 1024 字节它只是“最多拿 1024 字节”实际拿多少取决于内核缓冲区和网络状况。所以任何严谨的协议接收都必须手动“等够字节”这是我在接手别人代码时最先检查的点。2.4 Python 网络编程里的超时、阻塞与异常处理Python socket 默认是阻塞模式recv会一直卡住直到有数据。这在客户端偶尔等一会儿没问题但服务端某个连接不发送数据时对应线程就一直挂着浪费资源。解决办法是给 socket 设置超时client.settimeout(5) # 超过 5 秒没数据就抛 socket.timeout生产级的服务端一般用 select / epoll 做事件驱动不过这超出了入门范围。普通工具场景我建议至少做到三点设置超时、捕获socket.timeout、捕获ConnectionResetError和BrokenPipeError这两兄弟在连接被对端关闭时经常不约而同地出现。3. Spring Boot 集成 WebSocketYML 配置与真实生产坑3.1 WebSocket 和原生 Socket 不是一回事很多人刚接触 WebSocket 时会疑惑这是不是 Java 版的 Socket其实差别很大。原生 Socket 工作在传输层只要端口通就能连适合任意语言和任意客户端但浏览器里跑不了 JS 原生 TCP。WebSocket 是工作在应用层的协议它会先通过 HTTP 协议完成一次握手再把协议升级为 WebSocket之后双方维持一条长连接可以双向推送数据。所以 Spring Boot 里集成 WebSocket更多是为了解决“网页聊天”“实时通知”“在线协作”这类需求不需要你手动维护 TCP 连接。它和我们在第 2 章讲的 Python 原生 Socket是两个不同层级的东西但底层依然离不开 TCP。3.2 Spring Boot 集成 WebSocket 的标准姿势先添加依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-websocket/artifactId /dependency然后是application.yml这里必须注意一个关键点WebSocket 的端点路径和项目 context-path 是两个概念。很多人配置 WebSocket 的时候把“端点路径”混淆成“端口”其实端口还是用server.portWebSocket 路径是在代码的注册方法里定义的。一个典型的配置server: port: 8080 servlet: context-path: /myapp spring: application: name: socket-demo这里 context-path 是/myapp那后续 WebSocket 连接地址就应该是ws://localhost:8080/myapp/ws路径写错是浏览器一直连不上的常见原因。接着写配置类注册 WebSocket 处理器import org.springframework.context.annotation.Configuration; import org.springframework.web.socket.config.annotation.EnableWebSocket; import org.springframework.web.socket.config.annotation.WebSocketConfigurer; import org.springframework.web.socket.config.annotation.WebSocketHandlerRegistry; Configuration EnableWebSocket public class WebSocketConfig implements WebSocketConfigurer { private final ChatWebSocketHandler chatHandler; public WebSocketConfig(ChatWebSocketHandler chatHandler) { this.chatHandler chatHandler; } Override public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) { registry.addHandler(chatHandler, /ws) .setAllowedOrigins(*); } }再写处理器核心业务都在这个类里import org.springframework.web.socket.*; import org.springframework.web.socket.handler.TextWebSocketHandler; import java.util.concurrent.ConcurrentHashMap; public class ChatWebSocketHandler extends TextWebSocketHandler { // 用 Map 保存会话方便向所有在线用户广播 private static final ConcurrentHashMapString, WebSocketSession SESSIONS new ConcurrentHashMap(); Override public void afterConnectionEstablished(WebSocketSession session) { SESSIONS.put(session.getId(), session); System.out.println(连接建立: session.getId()); } Override protected void handleTextMessage(WebSocketSession session, TextMessage message) throws Exception { // 收到客户端消息广播给所有人 for (WebSocketSession s : SESSIONS.values()) { if (s.isOpen()) { s.sendMessage(new TextMessage(收到消息: message.getPayload())); } } } Override public void afterConnectionClosed(WebSocketSession session, CloseStatus status) { SESSIONS.remove(session.getId()); System.out.println(连接关闭: session.getId()); } }前端 JS 也很固定const ws new WebSocket(ws://localhost:8080/myapp/ws); ws.onopen function() { console.log(连接成功); ws.send(hello); }; ws.onmessage function(event) { console.log(收到:, event.data); };3.3 经典报错failed to create server shutdown socket on address [localhost] and port [802]这条报错在遇到过的朋友里属于高频噩梦级别。它在服务启动阶段就蹦出来特别容易让人误以为是 WebSocket 配置出了问题实际上它跟你业务端的连接端口是两码事。这个报错背后通常是 Java 生态某个框架在准备“服务关闭监听”时往localhost:802上创建了一个 socket 失败。构成失败的原因主要有三种第一种是端口 802 被占用。可能是之前跑的服务进程没退干净也可能是别的软件占用了 802。排查命令在 Windows 上是netstat -ano | findstr 802在 Linux 上是netstat -anp | grep 802。如果发现 PID 还在直接taskkill或kill掉如果 PID 反复变化就要检查是否有工具自动拉起服务。第二种是localhost 解析异常。有些机器 hosts 文件里把 localhost 指向了 IPv6 的::1而 Java 默认可能先去解析 IPv6一旦本机 IPv6 被禁用或中间有干扰创建 socket 就会失败。此时把配置里的localhost显式改成127.0.0.1或者启动参数加上-Djava.net.preferIPv4Stacktrue一般立即解决。第三种是框架配置了其他 shutdown 端口。很多框架的关闭监听端口是可以自定义的如果你在 yml 里看到类似server.shutdown、management.server.port、shutdownPort这类配置检查它们的端口值是否和 802 冲突。报错自带的[localhost]和port [802]是两个关键线索顺着配置找一定能定位。我遇到过最隐蔽的场景是同一个服务器里部署了多个 Java 应用其中一个曾把 shutdown 端口配置成 802后来另一个应用也被配成了 802两个进程同时抢后启动的那个必然报这个错。建议多实例部署时给每个实例分配独立且显式声明的 shutdown 端口避免用随机值。3.4 WebSocket 生产配置的四个细节心跳保活WebSocket 本身没有超时踢人的机制但运营商和 Nginx 会清理空闲连接。建议前端自动发心跳每 30 到 50 秒发送一个 JSON 字符串比如{type:ping}服务端收到后回个{type:pong}。跨域限制前端页面和后端服务不在同一个域名就容易碰上跨域拒绝。setAllowedOrigins不要随便用*生产环境请写明确域名。Session 管理客户端断网时服务端不会立刻感知要结合心跳 WebSocketSession.isOpen()做兜底。长期不清理死连接会导致内存泄漏。线程安全ConcurrentHashMap是必须的因为 WebSocket 回调可能来自不同线程hashMap 在多线程条件下会因为扩容丢数据。4. 跨界需求VBA 调用 Window Socket 实现 Telnet4.1 为什么要在 Excel 里写网络编程很多老牌的运维体系里Excel 依然是业务人员最常用的数据处理工具。我遇到过一个需求每天要登录几十台交换机执行命令、把状态汇总成表格。手工 telnet 太慢于是就用 VBA 写一个小工具在 Excel 里直接调用 Socket自动连接设备、发命令、取返回、填单元格。这套玩法用熟了以后你会发现VBA 能做的远不止操作单元格它完全可以成为一个“接口汇聚层”从 Excel 里直接调 Windows 的 Socket 能力连接内网设备干一些原本需要专业工具才能干的活。4.2 方案 A用 MSWinsock 控件适合窗体场景如果你在 Excel 里用 UserForm 做界面最直接的方式是拖一个控件。在 VBA 编辑器里先点击“工具 → 引用”勾选Microsoft Winsock Control 6.0或者直接在工具箱里添加这个控件。使用起来非常简洁 假设窗体上放了一个名为 Winsock1 的 Winsock 控件 Winsock1.RemoteHost 10.0.0.1 Winsock1.RemotePort 23 Winsock1.Connect 非阻塞连接接收数据要写在控件的 DataArrival 事件里注意这属于异步事件不能直接在事件里做大量 UI 操作否则 Excel 会感觉卡顿Private Sub Winsock1_DataArrival(ByVal bytesTotal As Long) Dim data As String Winsock1.GetData data, vbString 把收到的文本追加到文本框 TextBox1.Text TextBox1.Text data End Sub发送命令Winsock1.SendData show version vbCrLf这种方案下手最快但有个致命坑MSWinsock 控件在 64 位 Office 环境下的兼容性很差很多机器上根本引用不到。如果你公司 Office 是 64 位建议直接走方案 B。4.3 方案 B直接用 Winsock API不依赖控件API 方式不需要任何控件在标准模块里声明函数就能用。需要注意 64 位 Office 下Declare语句必须加PtrSafe关键字。核心代码如下Private Declare PtrSafe Function socket Lib ws2_32.dll (ByVal af As Long, ByVal sock_type As Long, ByVal protocol As Long) As Long Private Declare PtrSafe Function connect Lib ws2_32.dll (ByVal s As Long, ByRef name As sockaddr_in, ByVal namelen As Long) As Long Private Declare PtrSafe Function send Lib ws2_32.dll (ByVal s As Long, ByRef buf As Any, ByVal buflen As Long, ByVal flags As Long) As Long Private Declare PtrSafe Function recv Lib ws2_32.dll (ByVal s As Long, ByRef buf As Any, ByVal buflen As Long, ByVal flags As Long) As Long Private Declare PtrSafe Function closesocket Lib ws2_32.dll (ByVal s As Long) As Long Private Type sockaddr_in sin_family As Integer sin_port As Integer sin_addr As Long sin_zero(0 To 7) As Byte End Type这里要做一个字节序转换。网络字节序是大端模式而 Windows 端口号通常是小端模式所以端口 23 要经过htons转换。VBA 里没有内置 htens 函数需要自己写Private Function Htons(ByVal port As Long) As Integer Htons (port Mod 256) * 256 (port \ 256) End Function连接和发送的封装Dim sock As Long Dim saddr As sockaddr_in 创建 socketAF_INET2SOCK_STREAM1 sock socket(2, 1, 0) saddr.sin_family 2 saddr.sin_port Htons(23) saddr.sin_addr H0100A80A 这里实际是 10.0.0.1 的十六进制小端表示也可以封装 inet_addr 这里简化处理真正写代码时需要用 lstrcpyA 把 IP 转换成地址值 ret connect(sock, saddr, LenB(saddr))这段代码只是展示骨架最麻烦的是 IP 字符串转换需要用inet_addr或者Winsock 的 GetAddrByName处理。如果嫌 API 麻烦也可以先用方案 A 写原型再在部署时评估是否值得换 API。4.4 Telnet 客户端的协议要点与调试技巧Telnet 协议本身是 NVT网络虚拟终端文本协议绝大多数设备只需要发送纯文本命令末尾加\r\n即可。但要注意设备返回的数据里可能包含控制字符比如光标移动、颜色控制码。在 Excel 单元格里展示时最好按行切分只保留可打印字符 用 Split 按 vbCrLf 和 vbLf 切分行 Dim lines() As String lines Split(data, vbCrLf) For i 0 To UBound(lines) 去掉不可见控制字符 CleanLine Replace(lines(i), Chr(27), ) Next调试时可以先用 Windows 自带的 telnet 命令测一下设备是否支持明文登录再用 VBA 模仿同样的输入输出。注意 VBA 的 send 和 recv 都是阻塞的连接前一定要设置好超时否则设备不响应时 Excel 会直接假死。用 API 时可以把 socket 设成非阻塞模式但代码复杂度会上升内部工具场景我个人建议保持简单、加超时提示。5. 高频问题排查速查表与经验总结5.1 网络编程高频报错与解决方向这些年我在不同语言里遇到过的坑汇总成一张速查表报错或现象出现场景核心解决思路Connection refused客户端连接目标端口失败目标服务是否监听该端口防火墙是否拦截目标 IP 是否正确Address already in use服务端重启时端口被占用检查残留进程启用SO_REUSEADDR等待 TIME_WAIT 超时TimeoutError: timed out连接或接收数据长时间无响应检查网络连通性确认目标 IP/端口路由可达确认防火墙没有静默丢弃BrokenPipeError向已关闭的连接写数据对端主动关闭写数据前先判断连接状态捕获异常并清理数据收到一半或粘在一起TCP 字节流环境设计长度前缀或分隔符协议使用 recv 循环读取完整字节failed to create server shutdown socketJava 服务启动失败排查端口 802 被占、localhost 解析异常、shutdown 端口冲突WebSocket 握手 404前端连不上后端检查 context-path 和端点路径拼接是否正确检查 Nginx 代理是否配置升级头recv 阻塞导致 UI 卡死客户端同步等待设置 socket 超时或改用异步/非阻塞模式5.2 排查网络问题必备三板斧连接不上时不要瞎改代码先按顺序检查三层状态。第一层是验证端口是否通。Windows 和 Linux 都能用telnet 目标IP 目标端口做快速验证能连上说明网络通、端口在监听连不上就要继续排查。有些现代系统 telnet 默认没装也可以改用 PowerShell 的Test-NetConnection -Port 80 目标IP。第二层是看连接状态。netstat -ano可以列出所有 TCP 连接本地端口、远端地址、状态LISTENING / ESTABLISHED / TIME_WAIT都能看到。如果你发现服务端该监听的端口没有 LISTENING说明程序压根没起来如果 LISTENING 但客户端连不上问题基本在防火墙或路由。第三层是抓包确认。Wireshark 是排查网络问题的终极手段过滤条件写tcp.port 9000就能看到三次握手是否完成、数据包有没有重传。SYN 发出去没回应大概率被防火墙丢了三次握手成功但应用层没数据那就是代码逻辑问题。抓包能帮你把“网络问题”和“代码问题”彻底切开。我有一次排查客户端连接服务端偶发超时代码层面怎么都找不到原因最后抓包发现是服务端网卡的 TCP 分段卸载导致延迟换个网卡驱动后问题消失。这种经历只有抓包才能给你答案。5.3 我个人的三个固定习惯最后分享几个我自己写网络程序时雷打不动的习惯。第一个是连接用完必须关闭。网络连接是稀缺资源忘关连接导致连接数耗尽是我见过最多的生产事故源头。写 Python 用try/finally写 Java 用try-with-resources写 VBA 也要在Exit Sub前把所有 socket 关掉。第二个是所有网络操作必须显式设置超时。默认阻塞模式下一旦对端死掉你的代码可能永远卡住。无论客户端还是服务端连接和接收都要有超时阈值即使只是给一个合理的报错也比无限期挂死好。第三个是协议先行代码后写。两个人一起做联调各写各的最怕的就是消息格式不统一。我会在写第一行代码前先把协议文档固定下来字段顺序、长度、编码、结束标记。哪怕只是自己写给自己用也照样写因为三天后你看着代码根本回忆不起当初定义的“类型 1 表示心跳”是什么意思。这行当没有什么高深莫测的东西无非是把原理理解透把每一步控制好失败了就按层排查。希望这篇文章能帮你少走我当年走过的弯路。