做网络编程这些年我一直有个感受很多人一上来就撸代码结果卡在连接超时、数据粘包、服务端莫名挂掉这些问题上搞半天也不知道根因在哪。问题往往不在代码本身而是对网络编程的底层理解还差一块拼图。这篇总结不打算面面俱到我挑了自己在实际项目里反复用到、也最容易被忽略的几个基础知识模块——从分层模型到socket本质从TCP/UDP选型到粘包处理再到排障工具——尽量用这个知识点到底在解决什么问题的角度讲而不是罗列术语定义。熟悉这块的可以直接跳到第4、5节看踩坑经验刚入门的建议从头顺序读。1. 网络编程的起点先理解数据是怎么出网的很多教程把TCP/IP四层模型讲得像考试提纲一层层背下来还是不知道为什么自己的代码连不上服务器。我自己的体会是这个模型与其说是知识点不如说是一张排障地图。当程序表现异常时你得知道问题可能出在哪个层再去对应那一层找证据。1.1 四层模型不是背的是定位用的TCP/IP四层模型从上到下是应用层、传输层、网络层、网络接口层。每一层在程序员视角里留下的痕迹都不一样应用层你写的HTTP、WebSocket、自定义协议代码直接操作的就是这一层的报文格式。传输层TCP/UDP决定了数据可靠还是不可靠、要不要维持连接由系统内核帮你实现大部分逻辑。网络层IP地址、路由负责把数据从一台机器送到另一台机器基本不用你处理出问题时表现为ping不通。网络接口层MAC地址、网卡驱动对应用开发者几乎是透明的顶多在排查丢包时看一眼。我习惯把四层对应成一道流水线你家的快递应用层数据要出门先得装进运输箱TCP/UDP段箱子要写上门牌号IP头最后把箱子放上快递车帧才能上路。路上换成哪辆车、走哪条路应用层根本不用管。排查问题时我最先做的一步就是自下而上问一遍网线/网卡通不通IP能不能路由到对方端口有没有在监听TCP握手有没有建立起来最后才怀疑应用层协议解析。顺序反了容易在一个不存在的应用层bug里浪费半天。1.2 每一层都给你留了接口去观测基础知识里最容易忽略的一点是每一层都有对应的系统工具供你观测而不是靠猜。网络接口层看网卡统计用ethtool或ifconfig网络层用ping、traceroute判断路由和连通性传输层用ss/netstat看端口和连接状态应用层直接看服务日志和抓包内容。我见过不少同事遇到连不上就反复改代码最后发现是防火墙把端口都挡了。防火墙过滤的位置恰好横跨了网络层和传输层之间如果一开始就用ping测一下IP通不通、再用ss -lnt看端口有没有监听一分钟就能缩小范围根本不用动代码。2. Socket到底是什么一个被你反复读写的神秘文件很多新手最初接触socket都很懵socket()返回一个整数然后bind、listen、accept、read、write……感觉跟文件操作差不多但又不太一样。事实上这个像文件的直觉是对的。2.1 从文件描述符到socketUnix哲学里有一句话叫一切皆文件。socket在Linux里的确是一个文件描述符fd你可以像操作文件一样read、write它。但它的特殊之处在于文件对应的是磁盘上的真实数据而socket对应的是内核缓冲区——连接两端的内核缓冲区互相接在一起形成一条虚拟管道。理解这点很多行为就顺了为什么三路握手要send、recv两端参与因为缓冲区要建立双向的同步关系。为什么调用close()后连接不会立刻消失因为内核缓冲区里可能还有残留的数据没处理完或者对端还没收到FIN。为什么socket能以open()的方式被继承、被重定向因为它本质上就是fd能被dup、被select/poll/epoll监控。我在实际写业务代码时不太care fd底层怎么管理但排查句柄泄漏时会特别在意每一次socket()都必须对应一次close()尤其在高并发服务里fd不够用最常见的两个原因不是系统限制而是代码里open了socket没关或者TIME_WAIT状态的fd还没来得及释放。判断fd泄漏只需要在服务端执行ls /proc/pid/fd | wc -l看数量涨不涨涨得离谱基本就是泄漏。2.2 三次握手与四次挥手系统调用背后的真实时序三次握手很多人能背SYN、SYNACK、ACK。但我更建议和系统调用对应着看因为面试题之外这才是天天打交道的时序客户端connect()主动发SYN然后阻塞等待ACK此时服务端的监听socket在accept()里等待。服务端内核算半连接队列和全连接队列。收到SYN把连接放到半连接队列SYN队列回复SYNACK收到客户端的ACK连接进入全连接队列accept队列accept()从队列里取出连接返回。客户端收到SYNACK后内核自动回复ACKconnect()返回成功。也就是说你以为accept()是创建连接其实它只是从已完成握手的队列里取货。如果队列满了——例如半连接队列溢出、全连接队列溢出——客户端那边表现为连接超时或直接被reset服务端日志却不一定有明显报错。排查时执行ss -lnt看Send-Q和Recv-Q是否持续非零往往就能发现问题严重性。四次挥手更不复杂主动关的一方发FIN对端回ACK对端再发FIN主动方回ACK。但有一个陷阱点——很多文章强调主动关闭方进入TIME_WAIT结果新手默认谁调用close谁进TIME_WAIT。实际上TIME_WAIT只出现在最后一个回ACK的那一方。而如果两端都调用close通常是谁先发FIN谁就是主动关闭方它最后回ACK进TIME_WAIT。2.3 TIME_WAIT为什么必须存在以及它带来的问题TIME_WAIT默认时长是2个MSL通常约60秒。它存在的第一个原因是让最后一个ACK能可靠到达对端——如果ACK丢了对端会重发FINTIME_WAIT状态还能再回一个ACK第二个原因是防止上一个连接里的迷路数据包污染到新建立的同名连接同样的四元组。但代价就是大量连接快速建立/关闭后fd被TIME_WAIT占用如果端口不够用就可能出现Cannot assign requested address。我碰到的场景是压测工具频繁新建TCP连接短时间创建几十万连接客户端端口被占光。当时临时用sysctl net.ipv4.tcp_tw_reuse1给客户端开了端口复用有效缓解。但我必须提醒不要图省事在服务端也开tcp_tw_recycle这个参数在NAT环境下会引发严重的连接故障内核新版本基本已经把它移除了。正经的服务端设计思路是让连接尽量长生命周期避免频繁建立/关闭。3. TCP和UDP的选择先搞清楚你的业务能容忍丢失还是能容忍延迟选TCP还是UDP不是看哪一个更高级而是看你愿意付出什么代价。这里面关键变量就两个能不能容忍数据丢失、能不能容忍连接状态的开销。3.1 TCP的可靠性与代价TCP的可靠不是魔法靠的是三个东西序列号让接收方知道顺序确认机制告诉发送方这段数据我收好了超时重传自动补发。所以TCP天然要付出至少一个RTT的等待重传时还要加大延迟。对应用开发者而言TCP的可靠还有一个隐藏的坑可靠不是消息可达而是字节流有序交付。你send了三次数据对端read可能收到它们拼在一起的结果也可能收到其中某次send的一半。因为TCP只保证字节流的有序不丢不重不保证消息边界。这就是第4节粘包问题的根源。3.2 UDP的轻量与边界UDP不建立连接每个数据报都是独立的自带边界——你一个sendto发100字节对端recvfrom通常也收到100字节不碎片的情况下。代价是可能丢、可能乱序、可能重复到达应用程序要自己处理。所以UDP非常适合三类场景实时性要求高于可靠性的音视频直播、游戏帧同步、多点通信广播/组播在这个层天然支持、以及应用层已经自带可靠协议的场景比如QUIC底层就是UDP。我接手过一个内部日志上报服务用的UDP因为丢了几个包不影响整体数据统计完全能接受而且实现简单、吞吐高。3.3 一个选型决策示例拿聊天系统来说文本消息用TCP更稳因为无法容忍消息悄悄消失但语音通话用UDP因为等待重传造成的卡顿比偶尔丢几个包更让用户痛苦。真正的语音应用往往在这个基础上叠加FEC前向纠错和音量插值把少量丢包的影响降到感知不到的程度。另一个容易选错的例子是文件传输。有人觉得文件必须完整那必然TCP这没错但对于超大文件的多人分发场景TCP的队头阻塞会影响整体吞吐所以现代方案如QUIC用UDP承载可靠传输逻辑既保留了UDP的灵活性又在应用层实现了可靠和有序。这也是协议设计里应用层补可靠思路的现实产物。4. 新手最常踩的坑粘包、半包、缓冲区与阻塞这是网络编程里基础知识含量最高的部分也是我每次带新人必讲的内容。很多bug不是逻辑错而是对数据边界和阻塞的理解错。4.1 粘包半包问题的根源与三种应对思路根源前面提了TCP是字节流没有消息边界。你连续send两次对端一次read可能拿到两次send的全部数据这叫粘包也可能只拿到第一次send的一半这叫半包。解决方式不外乎三种各有适用场景定长消息每个消息固定N字节服务端按N切割。实现简单但浪费带宽适合消息种类少、长度固定的内部协议。分隔符方式比如以\r\n、\0作为消息结尾。灵活但正文里可能出现与分隔符冲突的内容需要转义或保证分隔符不出现。长度前缀最推荐也称为TLV/长度域每个消息前加若干字节表示当前包长度收端先读长度头再按长度读完整包。绝大多数现代协议HTTP/2、HTTP/3包括很多RPC框架都这么做因为它干净且可靠。我实际用的框架比如Netty、gRPC底层都封装了这些机制。但自己写协议的时候必须亲自实现粘包拆包逻辑没法偷懒 —— 我在一个老系统里见过有人每一条消息放在独立连接里为的就是避免粘包性能自然堪忧。正确做法是在同一个TCP连接上做好拆包而不是通过多连接规避。4.2 阻塞与非阻塞你调read时到底在等什么新手写客户端的时候最容易遇到这种现象调了read()明明服务端没有发数据程序却卡死在那里。这是正常的默认socket是阻塞模式read()在没有读到数据时不会返回线程会挂起等待。这里要区分阻塞、非阻塞和异步的区别很多人混为一谈。阻塞模式下read()会等到有数据才回来非阻塞模式下read()立刻返回没数据就返回一个EAGAIN/EWOULDBLOCK而异步I/O如io_uring则根本不用你主动调用read内核把数据准备好的时候直接通知你。三者各有适用场景没有绝对优劣。如果说要记住一条经验那就是别用阻塞读的心智去写高并发服务。当一个线程只能服务一个连接时1000个连接就需要1000个线程线程一多上下文切换开销就上去了。常见的方案是I/O多路复用select/poll/epoll 非阻塞socket 事件循环这也是Netty、Redis、Nginx这类高性能组件的核心打法。入门的话先把非阻塞读写和epoll的LT/ET模式弄明白就足以应付绝大多数业务。4.3 缓冲区与背压高并发下缓冲区配置的实战考量TCP收发都有缓冲区你用SO_RCVBUF、SO_SNDBUF可以调整大小。很多人以为缓冲区开越大越好其实不完全是。接收缓冲区太小数据到达后内核没地方放就会丢弃或触发对端重传造成吞吐下降接收缓冲区太大又会占内存尤其是在几千上万个并发连接的情况下。发送缓冲区同理如果你服务端write()返回的字节数比传入的少说明内核发送缓冲区已经满了不能再往里面塞数据否则要么丢数据要么被阻塞。这个时候正确的做法不是你继续死循环write而是把数据放到业务层的队列里等socket可写事件EPOLLOUT再继续发送。我在做推送网关时就在这里栽过业务层速度快socket写不进去我循环重发结果CPU飙升连接被对端反复reset。后来改成按EPOLLOUT事件驱动发送问题立刻消失。这算是背压设计最基础的一环也是面试里常说的压垮服务的往往不是读太慢而是写不动。5. 出门必备的排查基本功这些工具和数据你真的看懂了吗最后一节讲几个日常最该会的排查命令和观测点。网络编程基础不只是写代码还包括能快速定位谁出了问题。5.1 本机视角netstat/ss 看连接状态ss是netstat的现代替代品输出更丰富。我建议养成用ss -lnt看监听端口的习惯-l只显示监听socket-t只看TCP-n数字显示端口和IP。Recv-Q、Send-Q分别表示接收队列和发送队列的字节数长期非零说明数据没被及时处理。状态列里的ESTAB、TIME_WAIT、CLOSE_WAIT也是重点。大量CLOSE_WAIT一般说明服务端调了读但没调close连接被对端关闭后自己没关大量TIME_WAIT通常是主动关闭方太多。5.2 包级视角tcpdump 与 Wireshark 的配合本地状态看不出问题的时候就该抓包了。tcpdump基础用法很简单tcpdump -i eth0 tcp port 8080 -nn -w /tmp/capture.pcap把抓到的pcap用Wireshark打开重点看三件事有没有SYN包发出但没收到SYNACK网络层或防火墙拦截握手完成之后有没有大量重传网络质量差或对端处理不过来按下Analyze看TCP分析的提示比如Duplicate ACKOut-of-order这些关键字。我遇到过一例非常典型的服务端报连接不断被重置本地看代码毫无问题抓包后才发现对端是Windows机器它主动发送了RST包而不是FIN原因是Windows的TCP实现有KeepAlive默认超时重置空闲连接的行为。这是抓包前完全靠猜很难定位的。5.3 日志与监控失败连接、重传率、RTT波动的信号意义线上环境的排障不能等到出问题再临时抓包最好提前有监控。我一般会盯几个指标重传率TCP重传率异常升高说明链路有拥塞或丢包几乎必然导致请求延迟增大。RTT往返时延波动RTT突然大幅上升可能不只是网络问题也可能是服务端负载高、qdisc排队增加。SYN重传次数和listen队列溢出次数说明连接进来的速率已经超过accept()拉取的速度需要加服务端实例数或优化处理逻辑。这个角度很多教程不会讲但我觉得这才是网络编程基础里的核心——不要等报错才想起协议平时带着状态跑起来才可靠。6. 一个小结之外的现场心得上面几个模块基本覆盖了我在日常开发里最常用的网络编程知识。如果让我给初学者划重点就三条第一分层模型是排障地图别只背定义第二socket的本质是文件描述符加内核缓冲区理解它你就能理解一半的连接行为第三TCP可靠不等于有消息边界所有自定义协议都要自己解决拆包问题。另外再分享一个很朴素的检查习惯每次写完网络相关代码我会用系统自带工具看一遍连接状态和句柄数别等到线上报警。用ss、lsof、ls /proc/pid/fd这些命令观察自己服务的连接状态比任何纸上分析都直观。基础知识最大的价值不是你一下能写出多复杂的网络应用而是当服务在线上表现出诡异行为时你心里有知识、手里有工具能快速把问题从玄学拉回工程。
网络编程底层原理：从TCP/IP分层到Socket与粘包实战
做网络编程这些年我一直有个感受很多人一上来就撸代码结果卡在连接超时、数据粘包、服务端莫名挂掉这些问题上搞半天也不知道根因在哪。问题往往不在代码本身而是对网络编程的底层理解还差一块拼图。这篇总结不打算面面俱到我挑了自己在实际项目里反复用到、也最容易被忽略的几个基础知识模块——从分层模型到socket本质从TCP/UDP选型到粘包处理再到排障工具——尽量用这个知识点到底在解决什么问题的角度讲而不是罗列术语定义。熟悉这块的可以直接跳到第4、5节看踩坑经验刚入门的建议从头顺序读。1. 网络编程的起点先理解数据是怎么出网的很多教程把TCP/IP四层模型讲得像考试提纲一层层背下来还是不知道为什么自己的代码连不上服务器。我自己的体会是这个模型与其说是知识点不如说是一张排障地图。当程序表现异常时你得知道问题可能出在哪个层再去对应那一层找证据。1.1 四层模型不是背的是定位用的TCP/IP四层模型从上到下是应用层、传输层、网络层、网络接口层。每一层在程序员视角里留下的痕迹都不一样应用层你写的HTTP、WebSocket、自定义协议代码直接操作的就是这一层的报文格式。传输层TCP/UDP决定了数据可靠还是不可靠、要不要维持连接由系统内核帮你实现大部分逻辑。网络层IP地址、路由负责把数据从一台机器送到另一台机器基本不用你处理出问题时表现为ping不通。网络接口层MAC地址、网卡驱动对应用开发者几乎是透明的顶多在排查丢包时看一眼。我习惯把四层对应成一道流水线你家的快递应用层数据要出门先得装进运输箱TCP/UDP段箱子要写上门牌号IP头最后把箱子放上快递车帧才能上路。路上换成哪辆车、走哪条路应用层根本不用管。排查问题时我最先做的一步就是自下而上问一遍网线/网卡通不通IP能不能路由到对方端口有没有在监听TCP握手有没有建立起来最后才怀疑应用层协议解析。顺序反了容易在一个不存在的应用层bug里浪费半天。1.2 每一层都给你留了接口去观测基础知识里最容易忽略的一点是每一层都有对应的系统工具供你观测而不是靠猜。网络接口层看网卡统计用ethtool或ifconfig网络层用ping、traceroute判断路由和连通性传输层用ss/netstat看端口和连接状态应用层直接看服务日志和抓包内容。我见过不少同事遇到连不上就反复改代码最后发现是防火墙把端口都挡了。防火墙过滤的位置恰好横跨了网络层和传输层之间如果一开始就用ping测一下IP通不通、再用ss -lnt看端口有没有监听一分钟就能缩小范围根本不用动代码。2. Socket到底是什么一个被你反复读写的神秘文件很多新手最初接触socket都很懵socket()返回一个整数然后bind、listen、accept、read、write……感觉跟文件操作差不多但又不太一样。事实上这个像文件的直觉是对的。2.1 从文件描述符到socketUnix哲学里有一句话叫一切皆文件。socket在Linux里的确是一个文件描述符fd你可以像操作文件一样read、write它。但它的特殊之处在于文件对应的是磁盘上的真实数据而socket对应的是内核缓冲区——连接两端的内核缓冲区互相接在一起形成一条虚拟管道。理解这点很多行为就顺了为什么三路握手要send、recv两端参与因为缓冲区要建立双向的同步关系。为什么调用close()后连接不会立刻消失因为内核缓冲区里可能还有残留的数据没处理完或者对端还没收到FIN。为什么socket能以open()的方式被继承、被重定向因为它本质上就是fd能被dup、被select/poll/epoll监控。我在实际写业务代码时不太care fd底层怎么管理但排查句柄泄漏时会特别在意每一次socket()都必须对应一次close()尤其在高并发服务里fd不够用最常见的两个原因不是系统限制而是代码里open了socket没关或者TIME_WAIT状态的fd还没来得及释放。判断fd泄漏只需要在服务端执行ls /proc/pid/fd | wc -l看数量涨不涨涨得离谱基本就是泄漏。2.2 三次握手与四次挥手系统调用背后的真实时序三次握手很多人能背SYN、SYNACK、ACK。但我更建议和系统调用对应着看因为面试题之外这才是天天打交道的时序客户端connect()主动发SYN然后阻塞等待ACK此时服务端的监听socket在accept()里等待。服务端内核算半连接队列和全连接队列。收到SYN把连接放到半连接队列SYN队列回复SYNACK收到客户端的ACK连接进入全连接队列accept队列accept()从队列里取出连接返回。客户端收到SYNACK后内核自动回复ACKconnect()返回成功。也就是说你以为accept()是创建连接其实它只是从已完成握手的队列里取货。如果队列满了——例如半连接队列溢出、全连接队列溢出——客户端那边表现为连接超时或直接被reset服务端日志却不一定有明显报错。排查时执行ss -lnt看Send-Q和Recv-Q是否持续非零往往就能发现问题严重性。四次挥手更不复杂主动关的一方发FIN对端回ACK对端再发FIN主动方回ACK。但有一个陷阱点——很多文章强调主动关闭方进入TIME_WAIT结果新手默认谁调用close谁进TIME_WAIT。实际上TIME_WAIT只出现在最后一个回ACK的那一方。而如果两端都调用close通常是谁先发FIN谁就是主动关闭方它最后回ACK进TIME_WAIT。2.3 TIME_WAIT为什么必须存在以及它带来的问题TIME_WAIT默认时长是2个MSL通常约60秒。它存在的第一个原因是让最后一个ACK能可靠到达对端——如果ACK丢了对端会重发FINTIME_WAIT状态还能再回一个ACK第二个原因是防止上一个连接里的迷路数据包污染到新建立的同名连接同样的四元组。但代价就是大量连接快速建立/关闭后fd被TIME_WAIT占用如果端口不够用就可能出现Cannot assign requested address。我碰到的场景是压测工具频繁新建TCP连接短时间创建几十万连接客户端端口被占光。当时临时用sysctl net.ipv4.tcp_tw_reuse1给客户端开了端口复用有效缓解。但我必须提醒不要图省事在服务端也开tcp_tw_recycle这个参数在NAT环境下会引发严重的连接故障内核新版本基本已经把它移除了。正经的服务端设计思路是让连接尽量长生命周期避免频繁建立/关闭。3. TCP和UDP的选择先搞清楚你的业务能容忍丢失还是能容忍延迟选TCP还是UDP不是看哪一个更高级而是看你愿意付出什么代价。这里面关键变量就两个能不能容忍数据丢失、能不能容忍连接状态的开销。3.1 TCP的可靠性与代价TCP的可靠不是魔法靠的是三个东西序列号让接收方知道顺序确认机制告诉发送方这段数据我收好了超时重传自动补发。所以TCP天然要付出至少一个RTT的等待重传时还要加大延迟。对应用开发者而言TCP的可靠还有一个隐藏的坑可靠不是消息可达而是字节流有序交付。你send了三次数据对端read可能收到它们拼在一起的结果也可能收到其中某次send的一半。因为TCP只保证字节流的有序不丢不重不保证消息边界。这就是第4节粘包问题的根源。3.2 UDP的轻量与边界UDP不建立连接每个数据报都是独立的自带边界——你一个sendto发100字节对端recvfrom通常也收到100字节不碎片的情况下。代价是可能丢、可能乱序、可能重复到达应用程序要自己处理。所以UDP非常适合三类场景实时性要求高于可靠性的音视频直播、游戏帧同步、多点通信广播/组播在这个层天然支持、以及应用层已经自带可靠协议的场景比如QUIC底层就是UDP。我接手过一个内部日志上报服务用的UDP因为丢了几个包不影响整体数据统计完全能接受而且实现简单、吞吐高。3.3 一个选型决策示例拿聊天系统来说文本消息用TCP更稳因为无法容忍消息悄悄消失但语音通话用UDP因为等待重传造成的卡顿比偶尔丢几个包更让用户痛苦。真正的语音应用往往在这个基础上叠加FEC前向纠错和音量插值把少量丢包的影响降到感知不到的程度。另一个容易选错的例子是文件传输。有人觉得文件必须完整那必然TCP这没错但对于超大文件的多人分发场景TCP的队头阻塞会影响整体吞吐所以现代方案如QUIC用UDP承载可靠传输逻辑既保留了UDP的灵活性又在应用层实现了可靠和有序。这也是协议设计里应用层补可靠思路的现实产物。4. 新手最常踩的坑粘包、半包、缓冲区与阻塞这是网络编程里基础知识含量最高的部分也是我每次带新人必讲的内容。很多bug不是逻辑错而是对数据边界和阻塞的理解错。4.1 粘包半包问题的根源与三种应对思路根源前面提了TCP是字节流没有消息边界。你连续send两次对端一次read可能拿到两次send的全部数据这叫粘包也可能只拿到第一次send的一半这叫半包。解决方式不外乎三种各有适用场景定长消息每个消息固定N字节服务端按N切割。实现简单但浪费带宽适合消息种类少、长度固定的内部协议。分隔符方式比如以\r\n、\0作为消息结尾。灵活但正文里可能出现与分隔符冲突的内容需要转义或保证分隔符不出现。长度前缀最推荐也称为TLV/长度域每个消息前加若干字节表示当前包长度收端先读长度头再按长度读完整包。绝大多数现代协议HTTP/2、HTTP/3包括很多RPC框架都这么做因为它干净且可靠。我实际用的框架比如Netty、gRPC底层都封装了这些机制。但自己写协议的时候必须亲自实现粘包拆包逻辑没法偷懒 —— 我在一个老系统里见过有人每一条消息放在独立连接里为的就是避免粘包性能自然堪忧。正确做法是在同一个TCP连接上做好拆包而不是通过多连接规避。4.2 阻塞与非阻塞你调read时到底在等什么新手写客户端的时候最容易遇到这种现象调了read()明明服务端没有发数据程序却卡死在那里。这是正常的默认socket是阻塞模式read()在没有读到数据时不会返回线程会挂起等待。这里要区分阻塞、非阻塞和异步的区别很多人混为一谈。阻塞模式下read()会等到有数据才回来非阻塞模式下read()立刻返回没数据就返回一个EAGAIN/EWOULDBLOCK而异步I/O如io_uring则根本不用你主动调用read内核把数据准备好的时候直接通知你。三者各有适用场景没有绝对优劣。如果说要记住一条经验那就是别用阻塞读的心智去写高并发服务。当一个线程只能服务一个连接时1000个连接就需要1000个线程线程一多上下文切换开销就上去了。常见的方案是I/O多路复用select/poll/epoll 非阻塞socket 事件循环这也是Netty、Redis、Nginx这类高性能组件的核心打法。入门的话先把非阻塞读写和epoll的LT/ET模式弄明白就足以应付绝大多数业务。4.3 缓冲区与背压高并发下缓冲区配置的实战考量TCP收发都有缓冲区你用SO_RCVBUF、SO_SNDBUF可以调整大小。很多人以为缓冲区开越大越好其实不完全是。接收缓冲区太小数据到达后内核没地方放就会丢弃或触发对端重传造成吞吐下降接收缓冲区太大又会占内存尤其是在几千上万个并发连接的情况下。发送缓冲区同理如果你服务端write()返回的字节数比传入的少说明内核发送缓冲区已经满了不能再往里面塞数据否则要么丢数据要么被阻塞。这个时候正确的做法不是你继续死循环write而是把数据放到业务层的队列里等socket可写事件EPOLLOUT再继续发送。我在做推送网关时就在这里栽过业务层速度快socket写不进去我循环重发结果CPU飙升连接被对端反复reset。后来改成按EPOLLOUT事件驱动发送问题立刻消失。这算是背压设计最基础的一环也是面试里常说的压垮服务的往往不是读太慢而是写不动。5. 出门必备的排查基本功这些工具和数据你真的看懂了吗最后一节讲几个日常最该会的排查命令和观测点。网络编程基础不只是写代码还包括能快速定位谁出了问题。5.1 本机视角netstat/ss 看连接状态ss是netstat的现代替代品输出更丰富。我建议养成用ss -lnt看监听端口的习惯-l只显示监听socket-t只看TCP-n数字显示端口和IP。Recv-Q、Send-Q分别表示接收队列和发送队列的字节数长期非零说明数据没被及时处理。状态列里的ESTAB、TIME_WAIT、CLOSE_WAIT也是重点。大量CLOSE_WAIT一般说明服务端调了读但没调close连接被对端关闭后自己没关大量TIME_WAIT通常是主动关闭方太多。5.2 包级视角tcpdump 与 Wireshark 的配合本地状态看不出问题的时候就该抓包了。tcpdump基础用法很简单tcpdump -i eth0 tcp port 8080 -nn -w /tmp/capture.pcap把抓到的pcap用Wireshark打开重点看三件事有没有SYN包发出但没收到SYNACK网络层或防火墙拦截握手完成之后有没有大量重传网络质量差或对端处理不过来按下Analyze看TCP分析的提示比如Duplicate ACKOut-of-order这些关键字。我遇到过一例非常典型的服务端报连接不断被重置本地看代码毫无问题抓包后才发现对端是Windows机器它主动发送了RST包而不是FIN原因是Windows的TCP实现有KeepAlive默认超时重置空闲连接的行为。这是抓包前完全靠猜很难定位的。5.3 日志与监控失败连接、重传率、RTT波动的信号意义线上环境的排障不能等到出问题再临时抓包最好提前有监控。我一般会盯几个指标重传率TCP重传率异常升高说明链路有拥塞或丢包几乎必然导致请求延迟增大。RTT往返时延波动RTT突然大幅上升可能不只是网络问题也可能是服务端负载高、qdisc排队增加。SYN重传次数和listen队列溢出次数说明连接进来的速率已经超过accept()拉取的速度需要加服务端实例数或优化处理逻辑。这个角度很多教程不会讲但我觉得这才是网络编程基础里的核心——不要等报错才想起协议平时带着状态跑起来才可靠。6. 一个小结之外的现场心得上面几个模块基本覆盖了我在日常开发里最常用的网络编程知识。如果让我给初学者划重点就三条第一分层模型是排障地图别只背定义第二socket的本质是文件描述符加内核缓冲区理解它你就能理解一半的连接行为第三TCP可靠不等于有消息边界所有自定义协议都要自己解决拆包问题。另外再分享一个很朴素的检查习惯每次写完网络相关代码我会用系统自带工具看一遍连接状态和句柄数别等到线上报警。用ss、lsof、ls /proc/pid/fd这些命令观察自己服务的连接状态比任何纸上分析都直观。基础知识最大的价值不是你一下能写出多复杂的网络应用而是当服务在线上表现出诡异行为时你心里有知识、手里有工具能快速把问题从玄学拉回工程。
