1. 传输层到底在解决什么问题很多人学网络上来就背TCP三次握手、四次挥手背完就忘忘了再背最后只记得“SYN、ACK”几个字母真到抓包排障的时候还是一头雾水。我自己刚开始接触这块也是这样后来做了一段时间后端服务调优和线上问题排查才慢慢把传输层这套东西串起来。这篇就按我自己的理解路径把传输层从头到尾捋一遍尽量说人话把那些“为什么这么设计”讲清楚。传输层处在整个网络分层模型的中间偏上位置往下是网络层往上是应用层。网络层负责的是“把数据包从一台机器送到另一台机器”注意它只管送到主机不关心主机上哪个程序收。而一台机器上同时跑着浏览器、聊天软件、数据库连接、后台服务几十上百个进程都在收发数据网络层把包丢过来到底该给谁这就是传输层要解决的第一件事进程到进程的通信也就是常说的“端到端”。第二个要解决的问题是可靠性。底层链路和网络层本身是不可靠的包可能丢、可能乱序、可能重复。有些应用比如文件传输、网页加载要求数据一个字节都不能少、顺序不能乱而有些应用比如直播、语音通话宁可丢几帧也不能卡顿。传输层要能同时满足这两类截然不同的需求于是就有了TCP和UDP两条路线。第三个问题是流量控制和拥塞控制。发送方如果不管不顾地猛发接收方缓冲区会被撑爆中间网络也会被压垮。传输层需要一套机制让发送速度既能匹配接收方的处理能力又能适应整个网络的承载状况。这三件事——进程寻址、可靠传输、速率调节——基本构成了传输层的全部核心。适合谁来读这篇如果你是刚学计算机网络的学生或者准备面试的后端、运维、测试同学又或者是工作中经常要抓包、调优、排查连接问题的工程师这篇应该都能给你一些能直接上手的东西。我不打算只讲概念会把端口、报文结构、握手挥手、滑动窗口、拥塞控制这些拆开揉碎配上我实际踩过的坑和排查思路。2. 端口与复用分用传输层的“门牌号”体系2.1 端口号到底是怎么分配的网络层用IP地址定位主机传输层用端口号定位主机上的进程。IP加端口就构成了一个能唯一标识“某台机器上某个通信端点”的地址也就是常说的套接字Socket。你可以把IP理解成小区地址端口就是具体的门牌号快递数据包送到小区还不够得知道进哪一户。端口号是16位范围0到65535。这个范围不是随便用的被划分成了几段用途不一样端口范围名称用途说明0 - 1023熟知端口分配给系统级或广泛使用的服务如HTTP的80、HTTPS的443、DNS的531024 - 49151登记端口分配给用户注册的应用程序如MySQL的3306、Redis的637949152 - 65535动态端口客户端临时使用操作系统随机分配通信结束后释放这里有个很多人忽略的点服务端和客户端使用端口的方式完全不同。服务端是“固定端口监听”比如Web服务器一直守着80端口等连接客户端是“临时端口发起”每次连服务器时由操作系统随机挑一个空闲的高位端口。所以你抓包时会看到客户端端口每次都不一样而服务端端口始终是那个固定值。提示1024以下的端口在类Unix系统上通常需要管理员权限才能绑定这是历史遗留的安全设计防止普通用户冒充系统服务。2.2 复用与分用一台机器怎么同时聊几十个天“复用”和“分用”这两个词听着玄乎其实特别朴素。复用是发送方的事多个应用进程的数据都交给传输层传输层加上端口信息后统一交给网络层发出去。分用是接收方的事网络层把数据交上来传输层根据端口号判断该给哪个进程。分用还分两种模式。一种是无连接分用典型就是UDP收到包只看目的端口直接投递给对应进程简单粗暴。另一种是面向连接分用TCP不光看端口还要看四元组源IP、源端口、目的IP、目的端口因为同一个服务端端口上可能同时存在成千上万条连接必须靠四元组区分。我举个实际场景你就懂了。一台服务器开着80端口同时有一万个客户端连着它。如果只按目的端口分用这一万个连接的数据全混在一起根本没法区分。所以TCP必须用四元组来标识每一条独立的连接。这也是为什么服务端能用一个端口撑起海量并发连接的根本原因——连接的身份不是端口而是四元组。2.3 端口占用的那些坑实际工作中端口相关的报错特别常见我列几个最典型的Address already in use端口被占用。可能是上一个进程没退干净也可能是TIME_WAIT状态还没结束。用netstat -tunlp或ss -tunlp查一下谁占着。Cannot assign requested address客户端临时端口耗尽。高并发短连接场景下大量连接处于TIME_WAIT把本地端口池占满了。可以调大端口范围或开启端口复用。Permission denied想绑1024以下的端口但没权限。排查端口问题我习惯用这条命令先看全局ss -s它会汇总当前TCP、UDP连接数量和各状态分布一眼就能看出是不是连接数异常。然后再用ss -tn state time-wait专门看TIME_WAIT的数量。这些命令比netstat快得多连接数上万时差距非常明显。3. UDP简单到极致的设计哲学3.1 UDP报文结构为什么只有8字节UDP的报文头只有8个字节四个字段源端口、目的端口、长度、校验和。就这么简单没有序号、没有确认号、没有窗口、没有任何控制位。我第一次看到的时候还以为是简化版后来才明白这不是简化这是刻意为之的极简。0 7 8 15 16 23 24 31 -------------------------------- | 源端口 | 目的端口 | -------------------------------- | 长度 | 校验和 | -------------------------------- | 数据如果有 | -----------------------------------UDP的设计哲学是传输层只做最低限度的封装和分用其他一概不管。不保证送达、不保证顺序、不保证不重复、不做流量控制、不做拥塞控制。发出去就不管了收没收到是应用层自己的事。这种“甩手掌柜”式的设计恰恰是某些场景的最优解。因为那些保证机制都是有代价的——需要额外的字段、需要等待确认、需要维护状态、需要重传。对于实时性要求极高的应用这些代价换来的可靠性反而成了负担。3.2 哪些场景非UDP不可我总结下来UDP真正不可替代的场景有这么几类第一类是实时音视频。视频通话里一帧画面晚到200毫秒基本就没用了重传回来也是废数据还不如直接丢掉用后面的帧顶上。这时候TCP的重传机制纯属帮倒忙它会把后续数据全堵在缓冲区里等那个丢失的包造成更大的延迟这就是所谓的“队头阻塞”。第二类是DNS查询。DNS请求和响应都很小一问一答用UDP一次往返就搞定。如果走TCP光握手就要多花一个往返得不偿失。当然DNS在响应过大时也会切到TCP但绝大多数查询都是UDP。第三类是广播和多播。TCP是点对点的天生不支持一对多。UDP可以发给广播地址或多播组一次发送多个接收方都能收到这在服务发现、局域网通信里很常用。第四类是应用层自己实现了可靠性的场景。比如一些游戏协议、自定义的RPC框架它们在UDP之上自己做了序号、确认、重传因为通用TCP的拥塞控制策略不一定适合自己的业务特征自己定制反而更高效。3.3 UDP校验和与伪首部UDP的校验和有个细节值得说它计算时不仅包含UDP报文本身还要加上一个伪首部。伪首部包含源IP、目的IP、协议号、UDP长度这些信息但它并不实际传输只是参与校验和计算。为什么要这么设计因为UDP本身不记录IP地址如果校验和只算UDP部分那么一个包即使被错误地送到了别的主机只要UDP内容没坏校验也能通过。加上伪首部后IP地址参与了校验送错主机的包就会被检测出来。这是个很巧妙的设计用很小的代价增强了正确性。注意IPv4中UDP校验和是可选的填0表示不校验。但IPv6中强制要求校验因为IPv6去掉了网络层的校验和可靠性保障上移到了传输层。4. TCP可靠传输的完整实现4.1 TCP报文头逐字段拆解TCP报文头最少20字节比UDP复杂得多但每个字段都有明确用途没有一个是多余的。我按字段挨个说0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------------------------------------- | 源端口号 | 目的端口号 | -------------------------------------------------------------- | 序号Sequence Number | --------------------------------------------------------------- | 确认号Acknowledgment Number | ------------------------------------------------------- | 首部长度| 保留 |U|A|P|R|S|F| 窗口大小 | | | |R|C|S|S|Y|I| | | | |G|K|H|T|N|N| | ------------------------------------------------------- | 校验和 | 紧急指针 | -------------------------------------------------------------- | 选项可变长度 | --------------------------------------------------------------- | 数据 | ---------------------------------------------------------------序号是TCP可靠性的基石。它标识的是本报文段数据第一个字节在整个字节流中的位置。注意TCP是面向字节流的序号不是“第几个包”而是“第几个字节”。初始序号不是从0开始而是随机生成的这是为了防止旧连接的延迟包干扰新连接。确认号表示“我期望收到的下一个字节的序号”。比如确认号是1001说明1000及之前的字节都收到了。TCP采用累积确认一个确认号可以确认之前所有的数据不需要逐个确认。首部长度占4位单位是4字节所以TCP首部最长是15×460字节。减去固定的20字节选项字段最多40字节。六个标志位各有分工URG表示紧急指针有效ACK表示确认号有效连接建立后基本一直是1PSH提示接收方尽快交付应用层RST用于异常重置连接SYN用于建立连接FIN用于释放连接。窗口大小是接收方告诉发送方“我还能接收多少字节”这是流量控制的核心字段16位最大65535配合窗口缩放选项可以扩展到更大。4.2 三次握手为什么是三次而不是两次三次握手的流程大家都背过客户端发SYN服务端回SYNACK客户端再发ACK。但为什么必须是三次两次行不行核心原因在于TCP是全双工的双方都要确认自己和对方的收发能力都正常。第一次握手服务端确认“客户端发送能力正常我的接收能力正常”。第二次握手客户端确认“我的发送和接收都正常服务端的发送和接收都正常”。第三次握手服务端确认“客户端接收能力正常我的发送能力正常”。如果只有两次服务端发完SYNACK就认为连接建立了但此时它并不知道客户端有没有收到自己的SYN。万一客户端没收到服务端却已经开始发数据这些数据就全丢了。更严重的是网络中延迟的旧SYN包可能导致服务端建立一堆无效连接白白消耗资源。第三次握手让服务端最终确认客户端确实收到了自己的SYN连接才算真正建立。握手过程中还有个细节SYN会消耗一个序号。也就是说如果客户端初始序号是X那么它发完SYN后下一个数据字节的序号是X1。FIN同样消耗一个序号。这个设计是为了确保SYN和FIN这些控制报文也能被可靠确认。4.3 四次挥手与TIME_WAIT的深意挥手比握手多一次因为TCP连接是全双工的两个方向要分别关闭。主动关闭方发FIN对方回ACK此时一个方向关了对方数据发完后也发FIN主动方再回ACK另一个方向也关了。这里最让人困惑的就是TIME_WAIT状态。主动关闭方在发完最后一个ACK后不会立刻释放连接而是要等2MSL报文最大生存时间的两倍Linux上通常60秒才真正关闭。为什么要等第一个原因是确保最后的ACK能到达对方。如果这个ACK丢了对方会重传FIN此时主动方还在TIME_WAIT状态能重新发ACK。如果直接关了对方重传的FIN就没人理连接无法正常释放。第二个原因是让旧连接的延迟报文在网络中消散。如果不等待立刻用相同的四元组建立新连接旧连接残留在网络中的包可能被新连接误收造成数据错乱。等2MSL后旧包基本都过期了。TIME_WAIT本身不是问题但大量TIME_WAIT会占用端口资源。高并发短连接的服务端如果作为主动关闭方很容易堆积大量TIME_WAIT。解决办法通常是让客户端主动关闭或者调整内核参数缩短等待时间但缩短时间会削弱上面两个保障需要权衡。提示服务端如果频繁出现大量TIME_WAIT先别急着改内核参数先看看是不是业务逻辑上频繁短连接。改成连接池复用长连接往往比调参数更治本。4.4 超时重传与快速重传TCP保证可靠性的核心手段是确认加重传。发送方发出数据后启动定时器如果在超时时间内没收到确认就重传。但超时时间设多少很讲究设太短网络稍微抖动就重传浪费带宽设太长丢包后恢复慢影响体验。TCP的做法是动态估算RTT。它持续测量每个报文段的往返时间用加权平均算出平滑RTT再根据RTT的波动范围算出一个偏差值最终超时时间等于平滑RTT加上几倍偏差。这样超时时间能自适应网络状况网络稳定时短波动大时长。但光靠超时重传太慢因为要等定时器到期。于是有了快速重传如果发送方连续收到三个对同一数据的重复确认就认为后面的包丢了不等超时立刻重传。为什么是三个因为网络偶尔乱序会导致一两个重复确认三个以上基本可以确定是丢包了。这个机制大大加快了丢包恢复速度。4.5 滑动窗口流量控制的核心滑动窗口解决的是发送方别把接收方撑爆的问题。接收方在每个ACK里带上自己的接收窗口大小告诉发送方“我还能收这么多”。发送方根据这个值调整发送速率保证已发送但未确认的数据量不超过接收窗口。窗口在发送方这边可以理解成三个指针划分出的区间已发送已确认的、已发送未确认的、可以发送但还没发的、还不能发的。随着ACK到来窗口不断向右滑动所以叫滑动窗口。这里有个容易混淆的点接收窗口和拥塞窗口是两回事。接收窗口是接收方根据自己缓冲区剩余空间给出的反映的是接收方能力拥塞窗口是发送方根据网络拥塞状况自己维护的反映的是网络能力。实际发送窗口取两者的最小值。这个设计很关键后面讲拥塞控制时会展开。4.6 拥塞控制四大算法流量控制只管接收方但网络中间的路由器和链路也可能成为瓶颈。如果发送方只盯着接收方窗口猛发中间网络堵了照样丢包。拥塞控制就是让发送方感知网络状况动态调整发送速率。慢启动连接刚建立时拥塞窗口从一个很小的值开始通常几个MSS每收到一个ACK就翻倍增长呈指数上升。这样能快速探测网络容量但不会一上来就猛发。拥塞避免当拥塞窗口涨到慢启动阈值后改为每个RTT只加一个MSS变成线性增长。因为此时已经接近网络容量再指数增长容易撞墙。快重传前面说的连续三个重复ACK触发重传不用等超时。快恢复快重传后不回到慢启动的起点而是把拥塞窗口减半然后进入拥塞避免。因为收到重复ACK说明网络还在传数据只是个别包丢了情况没那么糟没必要从头再来。如果发生超时重传那说明网络可能严重拥塞这时会直接把拥塞窗口降到最小值重新慢启动。这套组合拳让TCP能在不知道网络全局状态的情况下靠ACK反馈自适应地找到合适的发送速率。5. 抓包实战把理论落到真实数据上5.1 抓包工具与环境准备光看理论容易飘抓一次真实流量就全明白了。我平时用tcpdump抓包、Wireshark分析这套组合免费且强大。抓包前先确认网卡名称ip addr show假设网卡是eth0抓一次访问某网站80端口的流量tcpdump -i eth0 -nn -s 0 port 80 -w capture.pcap参数说明-i指定网卡-nn不解析主机名和端口名保持数字避免DNS干扰-s 0抓完整包不截断-w写入文件供Wireshark分析。注意抓包会捕获经过网卡的所有流量涉及隐私和敏感信息务必只在授权环境下操作抓完及时删除文件。5.2 从抓包看三次握手用Wireshark打开抓到的文件过滤tcp.flags.syn1就能看到所有SYN包。一次完整的握手在Wireshark里是这样序号方向标志位序号确认号说明1客户端→服务端SYN0-请求建立连接2服务端→客户端SYN,ACK01同意并确认3客户端→服务端ACK11确认服务端SYN注意Wireshark显示的序号是相对序号它把初始序号显示为0方便阅读。点开报文详情能看到真实的绝对序号。观察确认号的变化就能理解“确认号是期望收到的下一个字节”这个定义。5.3 用抓包定位连接异常抓包最大的价值是排障。我遇到过几种典型情况连接被拒绝抓包看到客户端发SYN后服务端立刻回RST。这通常说明服务端端口没监听或者被防火墙拒绝了。RST是“我不认识你别连了”的意思。连接超时客户端发SYN后没有任何响应重传几次后放弃。这多半是网络不通、防火墙丢包或者服务端负载太高没来得及处理。握手成功但立刻断开三次握手正常但紧接着就收到FIN或RST。可能是服务端应用层逻辑主动拒绝比如鉴权失败、连接数超限。大量重传Wireshark里看到同一个序号反复出现标记为“TCP Retransmission”。这说明丢包严重要查是网络链路问题还是接收方处理不过来。排查时我习惯先看Statistics里的“Conversations”按流量排序找出异常的大流量或异常多的重传连接再逐个深入。这个思路比漫无目的地翻包高效得多。5.4 观察滑动窗口与拥塞控制在Wireshark里选中一个TCP包展开“Window Size”字段能看到接收方通告的窗口。连续观察几个ACK就能看到窗口的动态变化。如果窗口逐渐变小甚至变成0说明接收方处理不过来发送方应该暂停发送。拥塞窗口在抓包里看不到直接字段因为它只存在于发送方内核里。但可以通过观察发送速率间接推断慢启动阶段发送速率指数上升拥塞避免阶段线性上升发生重传后速率骤降。把“Sequence Number”和“Time”做图就能看到经典的锯齿状曲线这就是拥塞控制在起作用的直观体现。6. 常见问题与排查速查6.1 连接类问题速查表现象可能原因排查方向连接被拒绝RST端口未监听、防火墙拒绝检查服务是否启动、防火墙规则连接超时无响应网络不通、丢包、服务过载ping测试、traceroute、看服务端负载连接建立后立即断开应用层拒绝、鉴权失败查应用日志、看是否有连接数限制大量TIME_WAIT频繁短连接、主动关闭方改用连接池、调整内核参数大量CLOSE_WAIT应用没正确关闭连接查代码是否漏了close调用传输速度慢窗口太小、丢包重传、拥塞看窗口值、看重传率、看RTTCLOSE_WAIT这个状态特别值得说。它出现在被动关闭方收到FIN但还没发自己的FIN时。如果大量连接卡在CLOSE_WAIT几乎可以肯定是应用代码有问题——收到了对方的关闭请求但自己没调用关闭连接就一直挂着。这是代码bug调内核参数没用必须改代码。6.2 性能调优的几个关键参数Linux内核提供了一堆TCP相关参数我挑几个实际调优中最常动的说# 查看当前值 sysctl net.ipv4.tcp_max_syn_backlog sysctl net.core.somaxconn sysctl net.ipv4.tcp_tw_reusetcp_max_syn_backlog和somaxconn控制半连接队列和全连接队列的大小。高并发场景下如果队列太小新连接会被丢弃客户端表现为超时。适当调大能提升抗压能力。tcp_tw_reuse允许把TIME_WAIT状态的连接重新用于新的 outgoing 连接。注意它只对客户端主动发起的连接有效且需要时间戳选项支持。开启它能缓解客户端端口耗尽问题。tcp_rmem和tcp_wmem控制接收和发送缓冲区大小。缓冲区太小会限制吞吐量太大又浪费内存。现代内核支持自动调节一般不用手动改除非有明确的带宽延迟积需求。提示调内核参数前一定要先搞清楚瓶颈在哪。我见过有人一上来就改一堆参数结果问题没解决还引入了新问题。先用抓包和监控定位瓶颈再针对性调整。6.3 我踩过的几个坑坑一以为UDP一定比TCP快。其实在丢包率低的网络里TCP和UDP的吞吐量差距没那么大TCP的拥塞控制反而能更好地利用带宽。UDP的优势在于低延迟和可控性不是绝对的“快”。坑二忽略Nagle算法的影响。TCP默认开启Nagle算法会把小数据攒起来一起发减少小包数量。但对延迟敏感的应用这会导致额外延迟。可以设置TCP_NODELAY关闭它代价是小包变多。坑三把TIME_WAIT当成洪水猛兽。TIME_WAIT是正常且必要的状态少量存在完全没问题。真正要关注的是它是否占满了可用端口以及是否伴随其他异常。坑四抓包时忘了关DNS解析。tcpdump默认会尝试把IP解析成主机名在高流量下这个解析过程会拖慢抓包甚至丢包。加-nn参数关掉解析抓包会稳定很多。传输层这块内容理论看着枯燥但一旦和抓包、调优、排障结合起来就会发现每个字段、每个状态、每个算法都有它存在的理由。我自己是反复在“看理论—抓包验证—遇到问题—回头查理论”这个循环里滚了好几遍才慢慢建立起直觉的。建议你也找个测试环境自己抓几次握手挥手看看窗口怎么变、重传怎么发生比单纯背书强太多。