网络通信这件事说穿了就是两台机器之间怎么把一堆0和1准确、有序、不重不漏地送到对方手里。我干了十多年后端和网络相关的工作面试过不少人也带过不少新人发现一个特别普遍的现象很多人天天写socket、调HTTP接口、配Nginx但一旦线上出现连接超时、丢包、握手失败就完全抓瞎因为他们脑子里的网络是一团浆糊没有分层没有协议栈的概念。TCP/IP协议恰恰就是把这团浆糊理清楚的那套东西它是网络通信的基石也是每一个想真正搞懂网络的人绕不过去的一道坎。这篇文章我不打算照本宣科地念教科书而是从一个一线从业者的角度把TCP/IP这套协议族拆开揉碎讲清楚它为什么这么设计、每个环节的关键点在哪、实际排障时怎么用。不管你是刚入行的新手还是写了几年业务代码想补网络底子的老手都能从里面拿到能直接上手的东西。1. 整体设计思路为什么网络要分层1.1 分层不是学术洁癖是被逼出来的工程妥协很多人第一次接触OSI七层模型或者TCP/IP四层模型第一反应是记不住、太抽象。我当年也是这么想的直到自己动手写过一个简易的协议解析器才明白分层这件事根本不是学者们为了发论文硬凑出来的而是工程上被逼出来的必然选择。你想想网络通信要解决的问题有多杂网线里是电信号光纤里是光信号无线是电磁波这是物理层面的事两台直连的机器怎么知道对方在不在线这是链路层面的事数据要跨越几十个路由器从北京到广州中间还要选路这是网络层面的事到了目的地数据可能丢了、可能乱序了、可能重复了得有人负责兜底这是传输层面的事最后应用到底是要传文件还是看网页这是应用层面的事。这么多完全不同性质的问题如果全塞进一个模块里那这个模块会复杂到没人能维护。分层的本质就是关注点分离。每一层只解决自己那一摊事对上提供稳定的接口对下依赖固定的服务。物理层换了介质上面的协议一行都不用改传输层想换个拥塞算法应用层完全无感。这种解耦带来的好处在实际工程里价值巨大。我见过太多系统因为耦合太深改一个地方牵一发动全身网络协议栈能稳定运行几十年分层设计功不可没。TCP/IP模型把网络分成四层网络接口层、网络层、传输层、应用层。注意它和OSI七层不是一一对应的TCP/IP更务实把OSI的物理层和数据链路层合并成了网络接口层把会话层、表示层、应用层合并成了应用层。这个合并本身就体现了工程思维——那些被合并的层在实际实现里往往没有清晰的边界硬拆反而增加复杂度。1.2 每一层到底在干什么用寄快递打个比方抽象的概念用生活化的类比最容易讲明白。把网络通信想象成寄快递四层模型就很好理解了。应用层就是你写的那张快递单和包裹里的东西你要寄什么、寄给谁、有什么特殊要求都在这一层表达。HTTP、FTP、DNS、SMTP这些协议本质上就是不同场景下的快递单格式。传输层相当于快递公司的分拣中心它负责把一个大包裹拆成合适大小的箱子分段给每个箱子编号序列号确保收件方按顺序收到、不丢件可靠传输还要根据路况调整发货速度拥塞控制。TCP和UDP就是两种不同的分拣策略TCP是挂号信件件签收、丢了重发UDP是普通平信发出去就不管了快但可能丢。网络层是物流的干线运输和路由调度它要知道从发货城市到收货城市走哪条线路中间经过哪些中转站。IP协议干的就是这个活给每个包裹贴上源地址和目的地址然后由路由器一站一站转发。这一层不关心包裹里装的是什么只负责把包裹送到正确的城市。网络接口层就是最后一公里的配送和装卸负责把数据真正变成电信号、光信号在物理介质上传输以及相邻两个节点之间的帧同步、差错检测。以太网、Wi-Fi、PPP都属于这一层。这个类比能帮你建立直觉但要注意一个关键区别快递的每一层是不同的人在干活而网络协议栈的每一层是同一台机器上的不同软件模块在协作数据从上往下逐层封装到了对端再从下往上逐层解封装。这个封装-解封装的过程是理解整个协议栈的钥匙。1.3 封装与解封装数据在协议栈里的旅行数据从应用层产生往下走每经过一层就被加上一个头部有时还有尾部这个过程叫封装。到了对端每往上一层就剥掉一个头部叫解封装。我用一个具体的HTTP请求来走一遍。你在浏览器里访问一个网页应用层生成HTTP请求报文比如GET /index.html HTTP/1.1加上一堆请求头。这个报文交给传输层TCP给它加上TCP头部里面包含源端口、目的端口、序列号、确认号、窗口大小、各种标志位。加上TCP头之后这个整体叫报文段Segment。报文段交给网络层IP给它加上IP头部包含源IP、目的IP、TTL、协议号等。加上IP头之后叫数据包Packet。注意这里有个容易混淆的点很多人把任何情况下的数据都叫包严格来说不同层有不同的叫法虽然日常交流中混用也无伤大雅但排障时心里要清楚。数据包交给网络接口层以太网给它加上以太网头部源MAC、目的MAC、类型和尾部FCS校验这时候叫帧Frame。帧最终被网卡变成电信号发出去。对端收到后反向操作网卡收到帧检查FCS剥掉以太网头发现类型是IP交给网络层网络层检查目的IP是不是自己剥掉IP头发现协议号是TCP交给传输层传输层根据目的端口找到对应的应用进程剥掉TCP头把HTTP报文交给应用。整个过程一气呵成每一层只认自己关心的头部字段。提示理解封装解封装排障时就能定位问题出在哪一层。比如抓包看到有以太网帧但没有IP包说明问题在链路层或IP层看到IP包但TCP握手不成功问题在传输层或防火墙。2. 网络层核心IP协议与路由的那些事2.1 IP地址与子网划分别只会看不能算IP协议是网络层的核心它提供的是无连接、不可靠的分组传输服务。所谓无连接就是发数据之前不需要建立连接每个包独立选路所谓不可靠就是IP层不保证包一定送到、不保证按序到达、不保证不重复。可靠性的事全部甩给上层TCP去兜底。这个设计看似甩锅实则是极致的简化——网络层只管转发越简单越快越稳。IPv4地址是32位写成点分十进制比如192.168.1.10。但光有地址不够还得知道哪些地址在同一个网段这就引出子网掩码。子网掩码也是32位1的部分表示网络位0的部分表示主机位。255.255.255.0意味着前24位是网络号后8位是主机号这个网段最多254台主机去掉网络地址和广播地址。这里我必须强调一个实操中极其重要的技能子网划分的计算。面试和实际配网络都会用到。举个例子给你192.168.10.0/26问这个子网有多少可用主机、范围是多少。/26表示掩码有26个1主机位是32-266位可用主机数是2^6-262台。块大小是2^664所以子网范围是192.168.10.0到192.168.10.63可用地址是.1到.62广播地址是.63。下一个子网从.64开始。我把常用的CIDR对照整理成表配网络时直接查CIDR子网掩码可用主机数块大小/24255.255.255.0254256/25255.255.255.128126128/26255.255.255.1926264/27255.255.255.2243032/28255.255.255.2401416/30255.255.255.25224/30特别常用因为它正好提供2个可用地址专门用于点对点链路比如两个路由器直连。这个细节很多教材一笔带过但实际组网时天天用。2.2 路由决策一个包到底走哪条路IP包到了路由器路由器怎么决定往哪个口转发靠的是路由表。路由表里每条记录包含目的网络、掩码、下一跳、出接口、度量值。转发时遵循最长前缀匹配原则在所有匹配目的地址的路由条目中选掩码最长最精确的那条。举个例子路由表里有三条10.0.0.0/8下一跳A10.1.0.0/16下一跳B10.1.1.0/24下一跳C。现在有个包目的地址是10.1.1.5三条都匹配但/24最长所以走C。这个原则保证了路由的精确性也让默认路由0.0.0.0/0能作为最后的兜底——它掩码最短只有在没有更精确匹配时才会被选中。路由的来源有两种静态路由和动态路由。静态路由是管理员手工配的简单可控适合小型网络或固定拓扑动态路由靠协议自动学习常见的有RIP、OSPF、BGP。RIP基于跳数最大15跳简单但收敛慢只适合小网络OSPF基于链路状态用Dijkstra算法算最短路径收敛快适合企业网BGP是自治系统之间的路由协议互联网的骨干就靠它基于路径向量策略性极强。我在实际项目里踩过一个坑某次机房网络调整两台核心交换机之间配了静态路由结果一条链路断了之后路由没自动切换业务中断了十几分钟。后来改成OSPF链路故障能秒级收敛。这个教训告诉我静态路由适合末端和固定场景核心链路一定要用动态路由别为了省事埋雷。2.3 TTL与分片两个容易被忽视但很关键的机制TTLTime To Live是IP头部的一个8位字段每经过一个路由器减1减到0就丢弃并回一个ICMP超时报文。它的初衷是防止包在网络里无限循环比如路由环路但实际排障时它是神器。你用tracerouteWindows下是tracert探测路径原理就是发TTL递增的包每个路由器返回超时从而逐跳暴露路径。# Linux下探测到目标经过的路由 traceroute 8.8.8.8 # Windows下 tracert 8.8.8.8看到某一跳之后全是星号通常说明那一跳之后的路由器禁了ICMP或者链路有问题。这个技巧在判断是本地网络问题还是对方网络问题时特别有用。分片是另一个重点。链路层有MTU最大传输单元以太网默认1500字节。如果一个IP包超过MTU就得分成多个片。分片字段在IP头里有标识Identification、标志Flags含DF禁止分片和MF更多分片、片偏移Fragment Offset。接收端根据标识和偏移重组。分片的问题在于只要丢一个片整个包就废了得全部重传效率极低。所以现代网络尽量避免分片。TCP有MSS最大报文段长度协商就是为了让TCP段不超过MTU从源头避免IP分片。MSS通常等于MTU减去IP头和TCP头以太网下就是1500-20-201460字节。注意如果你发现应用层大包传输特别慢、小包正常八成是路径上某处MTU变小导致分片或丢包这就是所谓的MTU黑洞问题。排查时可以用ping -s指定包大小逐步试探找到不分片的最大值。3. 传输层核心TCP凭什么可靠3.1 三次握手与四次挥手每个状态都有讲究TCP的可靠性建立在连接之上而连接的建立就是三次握手。这个过程被讲烂了但很多人只记住了SYN、SYN-ACK、ACK却说不清为什么是三次而不是两次。核心原因在于三次握手才能让双方都确认对方的收发能力正常并且同步初始序列号。两次握手的话服务端无法确认客户端能收到自己的包而且历史遗留的重复SYN可能导致服务端建立无效连接。三次是理论上的最小值。握手过程客户端发SYN带自己的初始序列号seqx进入SYN_SENT服务端回SYN-ACKseqyackx1进入SYN_RCVD客户端回ACKacky1双方进入ESTABLISHED。注意序列号在握手阶段就消耗了一个SYN占一个序号这是很多人忽略的细节。挥手是四次因为TCP是全双工的两个方向要分别关闭。主动关闭方发FIN进入FIN_WAIT_1被动方回ACK进入CLOSE_WAIT主动方进入FIN_WAIT_2被动方处理完数据后发FIN进入LAST_ACK主动方回ACK进入TIME_WAIT等待2MSL后关闭。TIME_WAIT状态是面试高频考点也是实际运维的痛点。它存在的理由有两个一是保证最后一个ACK能到达对端如果ACK丢了对端会重发FIN此时还能响应二是让本连接在网络中的残留包消散避免干扰后续使用相同四元组的新连接。2MSL就是报文最大生存时间的两倍。实际中大量TIME_WAIT堆积会耗尽本地端口导致无法建立新连接。解决办法是开启tcp_tw_reuse允许重用TIME_WAIT连接用于新连接和调整tcp_max_tw_buckets但tcp_tw_recycle在现代内核里已经废弃别再用。更根本的办法是让服务端主动关闭连接或者用长连接减少连接数。3.2 滑动窗口与流量控制别让快的等慢的TCP的可靠不只是不丢还包括不撑死对方。如果发送方拼命发接收方处理不过来缓冲区溢出就会丢包。滑动窗口就是解决这个问题的机制。接收方在ACK里带一个窗口字段Window告诉发送方我还能接收多少字节。发送方根据这个窗口调整发送量这就是流量控制。窗口是动态的接收方缓冲区空出来就增大窗口快满了就减小甚至发零窗口通告。窗口的单位在TCP头部里是16位最大65535字节。但现代网络带宽延迟积很大65535远远不够所以有窗口缩放选项Window Scale在握手时协商一个移位因子把窗口最大扩展到约1GB。这个选项在抓包时能看到WS字段就是它。滑动窗口的滑动体现在发送方维护一个发送窗口窗口内的数据已发送未确认收到ACK后窗口向前滑动可以发新数据。这个机制配合累积确认ACK n表示n之前的所有字节都收到了效率很高。我实际调优时遇到过一个典型案例跨地域传输大文件速度上不去抓包发现窗口一直很小。查下来是接收端应用读取太慢缓冲区被占满窗口上不去。后来优化了应用层的读取逻辑速度立刻提升。这说明窗口大小不只是网络参数问题往往根子在应用层。3.3 拥塞控制从慢启动到BBR的演进流量控制是端到端的拥塞控制是面向整个网络的。网络中间的路由器缓冲区有限如果所有发送方都猛发就会拥塞崩溃。TCP的拥塞控制通过维护一个拥塞窗口cwnd来调节发送速率实际发送窗口取cwnd和接收窗口的较小值。经典算法分四个阶段慢启动、拥塞避免、快重传、快恢复。慢启动时cwnd从1个MSS开始每收到一个ACK翻倍指数增长到达慢启动阈值ssthresh后进入拥塞避免每个RTT加1个MSS线性增长。遇到超时重传ssthresh减半cwnd重置为1重新慢启动遇到三个重复ACK触发快重传立即重发丢失的段然后快恢复ssthresh和cwnd都减半直接进入拥塞避免。这套算法在早期网络很有效但在高带宽、高延迟的现代网络上表现不佳因为丢包就降速的逻辑把丢包等同于拥塞而实际上很多丢包是链路误码导致的。于是有了BBR。BBR不依赖丢包信号而是主动测量带宽和RTT建立网络模型来调节发送速率在高丢包链路上表现远好于传统算法。# 查看当前拥塞控制算法 sysctl net.ipv4.tcp_congestion_control # 临时切换为BBR需内核支持 sysctl -w net.ipv4.tcp_congestion_controlbbr我在跨洋传输场景实测过同样的链路CUBIC默认算法只能跑到带宽的30%换成BBR能到80%以上。这个差距在长肥管道高带宽高延迟上尤其明显。不过BBR也不是万能它在浅缓冲区、多流竞争的场景下可能不够公平选型时要结合具体场景。3.4 UDP被低估的不可靠很多人觉得UDP不可靠所以没用这是误解。UDP只做一件事把数据报从源端口送到目的端口不建立连接、不保证顺序、不做拥塞控制。正因为简单它开销极小、延迟极低适合实时性要求高的场景。DNS查询用UDP因为一次查询一个包就够建立连接反而慢视频直播、语音通话用UDP因为丢几帧无所谓但延迟不能忍游戏用UDP因为要的是实时同步。现代很多协议在UDP之上自己实现可靠性比如QUIC它在UDP上重建了可靠传输、拥塞控制、多路复用还内置了加密HTTP/3就是基于QUIC的。UDP的头部只有8字节源端口、目的端口、长度、校验和对比TCP的20字节起步开销小很多。但要注意UDP没有拥塞控制大量使用可能挤占网络所以应用层要自己控制发送速率。4. 实操排障把协议知识变成解决问题的能力4.1 抓包分析看懂一个TCP连接的完整生命周期理论讲再多不如抓一次包。tcpdump和Wireshark是网络排障的两把利器。tcpdump在服务器上抓Wireshark在本地分析配合使用效率最高。# 抓取指定主机和端口的包保存为pcap文件 tcpdump -i eth0 -nn host 192.168.1.100 and port 80 -w capture.pcap # 实时查看TCP握手和挥手只看标志位 tcpdump -i eth0 -nn tcp[tcpflags] (tcp-syn|tcp-fin|tcp-rst) ! 0抓下来用Wireshark打开重点看几个东西三次握手是否完成有没有SYN没回应、有没有RST连接被重置、有没有重传同一序列号出现多次、窗口大小变化、RTT趋势。我排障时的习惯是先看有没有RST有RST基本就是端口没开或被防火墙拒绝没有RST但握手慢看是不是SYN丢包重传连接建立了但传输慢看窗口和重传率。Wireshark的专家信息Expert Information功能特别好用它会把重传、乱序、零窗口等异常自动标出来新手也能快速定位。另外善用过滤表达式比如tcp.analysis.retransmission只看重传tcp.flags.reset1只看RST。4.2 常见问题速查表我把这些年遇到的高频问题整理成表方便对照排查现象可能原因排查手段解决方向连接超时SYN无响应防火墙拦截或服务未监听telnet/nc测端口抓包看SYN有无回应检查防火墙规则、服务监听状态连接被重置收到RST端口未开或中间设备重置抓包看RST来源IP确认服务端口、检查中间设备策略传输慢但小包正常MTU问题导致分片或黑洞ping -s逐步增大包测试调整MSS或MTU大量TIME_WAIT短连接过多主动关闭方端口耗尽ss -s统计连接状态改长连接、开tw_reuse偶发丢包重传链路质量差或拥塞抓包统计重传率换拥塞算法、排查链路握手成功但无数据应用层未处理或阻塞看应用日志、线程栈排查应用逻辑这张表不是万能的但覆盖了八成常见场景。实际排障时我的原则是先分层定位再逐层深入。先确认是物理链路、IP可达、端口可达还是应用问题一层层排除比盲目猜测高效得多。4.3 几个容易踩的坑和实操心得第一个坑是混淆了能ping通和服务可用。ping通只说明ICMP可达不代表TCP端口开着更不代表应用正常。我见过有人排查半天应用问题最后发现是安全组没放行端口ping一直是通的。所以测端口要用nc -zv host port或telnet。第二个坑是忽视DNS解析时间。很多网络慢其实是DNS慢。用dig或nslookup看解析耗时如果解析就花了几百毫秒那跟TCP没关系。可以在应用里做DNS缓存或者用IP直连测试对比。第三个心得是养成看ss命令的习惯。ss -antp能看到所有TCP连接的状态、队列、进程比netstat快得多。ss -s看统计汇总ss -ti看单个连接的详细TCP信息包括RTT、重传、拥塞窗口排障时信息量很大。# 查看所有TCP连接及进程 ss -antp # 查看连接统计 ss -s # 查看某连接的TCP内部细节 ss -ti dst 192.168.1.100第四个心得关于长连接保活。NAT设备和防火墙会清理长时间空闲的连接导致长连接假死。解决办法是开TCP Keepalive或者应用层定时发心跳。Keepalive的参数tcp_keepalive_time、tcp_keepalive_intvl、tcp_keepalive_probes要按场景调默认2小时才探测一次太久了内网可以调到几分钟。4.4 从协议视角看性能优化懂协议的人做性能优化方向感会强很多。比如提升吞吐核心是增大窗口、减少重传、选对拥塞算法降低延迟核心是减少握手次数连接复用、避免队头阻塞多路复用、缩短RTT就近部署。这些优化方向都是从协议特性推导出来的不是拍脑袋。举个具体例子HTTP/1.1的队头阻塞问题根源在TCP的字节流特性——一个连接上前面的大响应没传完后面的小请求就得等着。HTTP/2用多路复用在一个TCP连接上并发多个流缓解了应用层队头阻塞但TCP层的队头阻塞还在一个包丢了所有流都等。HTTP/3换到QUIC基于UDP每个流独立彻底解决了这个问题。你看协议演进背后都是对底层特性的深刻理解。再比如连接池的配置不是越大越好。连接数超过带宽延迟积能支撑的量多出来的连接只会增加上下文切换和内存开销。合理值大致是带宽(Mbps) × RTT(ms) / 8 / MSS再留点余量。这个公式背后的逻辑就是滑动窗口能填满管道所需的数据量。5. 协议栈之外那些影响通信的现实因素5.1 NAT与连接跟踪中间设备的隐形影响现实网络里很少有端到端直连中间隔着NAT、防火墙、负载均衡。NAT做地址转换把内网私有地址映射成公网地址这导致外部无法主动连接内部也影响了依赖端到端连接的协议。连接跟踪表conntrack记录每条连接的状态表满了新连接就建不起来这是高并发场景的常见瓶颈。排查conntrack问题看/proc/sys/net/netfilter/nf_conntrack_count和nf_conntrack_max接近上限就要调大或优化连接复用。NAT的超时时间也要注意TCP已建立连接默认超时很长几天但UDP的NAT超时往往只有几十秒所以UDP应用必须自己做保活。5.2 无线与移动网络的特殊性有线网络丢包率极低无线和移动网络就复杂多了。Wi-Fi有信号干扰、漫游切换移动网络有基站切换、信号强弱变化这些都会导致RTT抖动和偶发丢包。在这种环境下传统TCP把丢包当拥塞的算法会误判降速BBR这类基于带宽测量的算法优势明显。另外移动网络的MTU往往比以太网小分片问题更突出。做移动端应用时要控制单包大小避免依赖大包传输。5.3 安全设备对协议行为的影响防火墙、IPS、WAF这些设备会深度检查流量有时会干扰正常的TCP行为。比如某些设备会重置长时间空闲的连接或者对异常标志位组合的包直接丢弃。我遇到过应用跑在特定安全策略后面TCP的某些选项如时间戳被剥离导致RTT计算异常。这类问题只能靠抓包对比经过设备前和经过设备后的差异来定位。提示跨设备排障时在路径两端同时抓包对比能快速判断问题出在哪一跳。这是最笨但最有效的方法。6. 学习路径与工具清单6.1 从理论到实践的进阶路线我给新人的建议是分三步走。第一步打基础把《TCP/IP详解 卷1》啃一遍重点看IP、TCP、UDP三章理解头部字段和状态机。这本书经典但偏厚不用全看抓核心章节即可。第二步动手验证用Wireshark抓自己日常的流量对照理论看每个字段用tcpdump在服务器上抓用nc手工构造连接。第三步深入排障主动去解决真实的网络问题哪怕是自己搭环境模拟丢包、延迟、分片用tc命令就能造。# 模拟100ms延迟和1%丢包需root tc qdisc add dev eth0 root netem delay 100ms loss 1% # 查看规则 tc qdisc show dev eth0 # 清除规则 tc qdisc del dev eth0 root用tc造各种恶劣网络环境然后观察TCP的行为比看十遍书都管用。我当年就是这么把拥塞控制、重传、窗口这些机制彻底搞明白的。6.2 必备工具速查工具用途典型命令tcpdump命令行抓包tcpdump -i eth0 -nn port 80Wireshark图形化分析打开pcap用过滤器ss连接状态查看ss -antp、ss -tiping/traceroute连通性与路径ping -s 1472 hostnc端口测试与手工连接nc -zv host portdigDNS诊断dig example.com statstc网络环境模拟tc qdisc add ... netem ...iperf3带宽测试iperf3 -c server -t 30这些工具不需要全会但tcpdump、ss、ping、nc这四个是日常必备建议练到肌肉记忆。6.3 我个人的一点体会网络这东西看再多不如抓一次包。我见过太多人背得出三次握手的每个状态但真让他从抓包文件里找出为什么连接建立慢就无从下手。协议知识只有落到能定位问题、能解释现象、能指导优化上才算真正掌握。TCP/IP是基石但基石不是用来供着的是用来踩的。你踩得越多对上层应用、对系统性能、对故障本质的理解就越透。我到现在还保持着遇到网络问题先抓包的习惯这个习惯帮我省下的排查时间远比学任何框架都值。最后分享一个我常用的排查顺序遇到网络问题按这个走基本不会跑偏先ping确认IP可达再nc确认端口可达然后tcpdump看握手是否完成接着看有没有RST或重传最后才怀疑应用层。这个顺序从底层往上每步都能排除一大片可能性比一上来就翻应用日志高效得多。
