1. 传输层到底在解决什么问题很多人学计算机网络学到传输层就开始犯迷糊。前面物理层、数据链路层、网络层还能靠“网线”“交换机”“IP地址”这些看得见摸得着的东西撑着一到传输层全是端口、序列号、窗口、标志位抽象得让人头皮发麻。我当初也是这样背了半天TCP三次握手过两周就忘得一干二净。后来做后端开发天天跟Socket打交道被线上问题反复教育之后才真正把这一层的东西嚼碎了咽下去。传输层这个知识点说白了就干一件事让两台主机上的两个具体进程能够可靠或者高效地对话。网络层负责把数据包从一台机器送到另一台机器但它不关心这台机器上跑的是浏览器、微信还是数据库。传输层就是在这条“主机到主机”的通道上再切出一条条“进程到进程”的管道。你打开十个网页标签每个标签背后都是一个独立的连接它们互不干扰靠的就是传输层用端口号做的多路复用和解复用。这篇文章适合谁看如果你是计算机专业的学生正在准备考试或者面试这里有你需要的核心概念和记忆框架如果你是刚入行的开发者写代码时调用过connect()、send()、recv()但说不清楚底层发生了什么这篇文章会帮你把API和协议对应起来如果你已经工作几年想重新梳理一遍传输层的知识体系我也会分享一些实际排查问题的思路。整篇内容我会尽量用大白话加实际场景来讲不堆砌公式但关键的计算过程和参数含义一个都不会少。传输层最核心的两个协议就是TCP和UDP。TCP追求的是可靠UDP追求的是快。这个“可靠”和“快”不是随便说说的背后是一整套机制在支撑。TCP为了保证数据不丢、不重、不乱序设计了序列号、确认应答、超时重传、滑动窗口、拥塞控制这一大套东西。UDP则几乎什么都不管把数据打包扔出去就完事丢了就丢了应用层自己看着办。理解这两个协议的设计哲学比死记硬背报文格式重要得多。2. 端口与多路复用传输层的地址体系2.1 端口号到底怎么分配的网络层用IP地址标识一台主机传输层用端口号标识主机上的一个进程。端口号是一个16位的数字范围从0到65535。这个数字看起来简单但分配规则是有讲究的。0到1023是知名端口分配给那些最核心的服务比如HTTP的80、HTTPS的443、DNS的53、SSH的22。1024到49151是注册端口给一些应用软件注册使用比如MySQL的3306、Redis的6379。49152到65535是动态端口客户端发起连接时操作系统会从这个范围里临时分配一个端口给应用程序用。这里有个实际开发中容易踩的坑如果你自己写服务端程序监听端口尽量选1024以上的因为1024以下的端口在Linux上需要root权限才能绑定。我见过有同学在本地用80端口起服务结果一直报权限错误折腾半天才发现是这个问题。另外动态端口的范围在不同操作系统上可能略有差异Linux的默认范围可以通过/proc/sys/net/ipv4/ip_local_port_range查看和调整。如果你的服务需要处理海量并发连接客户端端口不够用是个真实存在的问题后面讲TIME_WAIT的时候会再提到。2.2 套接字IP加端口才是完整地址单独一个IP地址或者单独一个端口号都没法唯一标识一个通信端点。传输层用的是套接字这个概念一个套接字由IP地址和端口号共同组成。更准确地说一条TCP连接由四元组唯一标识源IP、源端口、目的IP、目的端口。只要这四元组里任何一个元素不同就是不同的连接。这个四元组的概念在实际排查问题时特别有用。比如你用netstat -an或者ss -an看连接状态输出的每一行就是一条连接的四元组信息。当服务器出现大量连接堆积时你需要判断是哪个客户端IP、哪个端口在疯狂建连这时候四元组就是你的线索。再比如同一台服务器上可以同时监听80端口和443端口因为目的端口不同四元组不同内核能正确地把数据包分发给对应的进程。注意一个端口可以被多个连接复用但前提是四元组不同。服务端监听端口只有一个但可以接受成千上万条连接每条连接的四元组都不一样。这就是传输层多路复用的核心含义。2.3 多路复用与解复用的实际意义多路复用是指发送方多个应用进程的数据通过同一个传输层协议封装后交给网络层发送出去。解复用是指接收方传输层根据端口号把数据正确交付给对应的应用进程。这两个过程是传输层最基础的功能没有它们一台机器上就没法同时跑多个网络应用。举个生活中的例子。一栋写字楼有一个总收发室网络层相当于把信件从城市A的邮局送到城市B的邮局传输层相当于收发室根据房间号把信件分发给各个公司。房间号就是端口号公司就是进程。没有房间号收发室就不知道该把信给谁。这个类比虽然简化了很多细节但能帮你快速理解端口号存在的意义。3. TCP协议深度拆解可靠传输是怎么做到的3.1 三次握手不只是背状态码TCP建立连接需要三次握手这个过程几乎每本教材都会讲但很多人只记住了“SYN、SYN-ACK、ACK”这三个词不知道为什么要三次。核心原因在于TCP是全双工的双方都需要确认对方的发送能力和接收能力都正常。第一次握手客户端发送SYN报文携带一个初始序列号seqx。这告诉服务端“我想跟你建立连接我的初始序列号是x。”服务端收到后知道客户端的发送能力正常。第二次握手服务端回复SYN-ACK携带自己的初始序列号seqy同时确认号ackx1。这告诉客户端“我收到你的SYN了我也准备好连接了我的初始序列号是y。”客户端收到后知道服务端的发送和接收能力都正常。第三次握手客户端发送ACK确认号acky1。服务端收到后知道客户端的接收能力正常。为什么不是两次因为如果只有两次服务端无法确认客户端能收到自己的SYN-ACK。如果客户端没收到服务端却认为连接已建立就会白白维护一个连接状态浪费资源。三次握手是确保双方都确认对方收发能力正常的最小次数。初始序列号不是随便选的也不是从0开始。RFC规范建议初始序列号基于时钟生成每4微秒加1这样做的目的是防止旧连接的数据包干扰新连接。如果初始序列号固定一个延迟了很久的旧报文可能被新连接误认为是有效数据。实际实现中操作系统会用更复杂的算法生成初始序列号增加随机性。3.2 四次挥手与TIME_WAIT的真相TCP断开连接需要四次挥手因为TCP是全双工的每个方向都需要单独关闭。主动关闭方发送FIN进入FIN_WAIT_1状态被动关闭方回复ACK进入CLOSE_WAIT状态被动关闭方处理完数据后发送FIN进入LAST_ACK状态主动关闭方回复ACK进入TIME_WAIT状态等待2MSL后进入CLOSED状态。TIME_WAIT状态是面试和实际工作中被问得最多的点之一。为什么需要等待2MSLMSL是报文最大生存时间2MSL就是一来一回的最大时间。等待2MSL有两个目的第一确保最后一个ACK能到达被动关闭方。如果这个ACK丢了被动关闭方会重传FIN主动关闭方在TIME_WAIT状态下还能响应。第二让本次连接产生的所有报文都从网络中消失防止它们干扰后续使用相同四元组的新连接。实际工作中TIME_WAIT过多是一个常见问题。在高并发短连接场景下服务器主动关闭连接后会产生大量TIME_WAIT占用端口资源。如果客户端端口耗尽就无法发起新连接。解决办法有几个一是让客户端主动关闭连接把TIME_WAIT分散到客户端二是调整内核参数开启tcp_tw_reuse允许将TIME_WAIT状态的端口用于新的 outgoing 连接三是使用长连接减少连接建立和关闭的频率。提示tcp_tw_recycle这个参数在较新的Linux内核中已经被移除因为它会导致NAT环境下的连接问题。不要在生产环境使用它。3.3 滑动窗口流量控制的核心机制TCP的滑动窗口机制解决的是流量控制问题。接收方根据自己的缓冲区大小告诉发送方自己还能接收多少字节这个值就是接收窗口。发送方根据接收窗口和网络拥塞情况决定自己能发送多少数据这个值就是发送窗口。发送窗口取接收窗口和拥塞窗口的较小值。滑动窗口的“滑动”体现在当发送方收到接收方的确认应答后窗口向右滑动可以发送新的数据。窗口内的数据分为四部分已发送已确认、已发送未确认、未发送但可发送、未发送但不可发送。这个机制让TCP能够连续发送多个报文段而不是发一个等一个确认大大提高了传输效率。窗口大小是16位字段最大65535字节。但在高带宽高延迟的网络中这个值太小了。比如带宽100Mbps、往返时间100ms的链路带宽时延积是1.25MB远大于65535字节。所以TCP引入了窗口缩放选项在三次握手时协商一个缩放因子把窗口大小左移最多14位最大可以达到1GB左右。这个细节在实际调优长距离传输时很重要。3.4 拥塞控制从慢开始到快速恢复流量控制是端到端的问题拥塞控制是全局的问题。TCP的拥塞控制有四个核心算法慢开始、拥塞避免、快重传、快恢复。慢开始是指连接刚建立时拥塞窗口从一个较小的值开始每收到一个确认就翻倍指数增长。这样做的原因是不知道网络当前状况先小步试探。当拥塞窗口达到慢开始门限后进入拥塞避免阶段每个往返时间只增加一个报文段线性增长。如果发生超时重传说明网络严重拥塞拥塞窗口直接降到1重新慢开始。如果收到三个重复确认说明只是个别报文丢失网络还没完全拥塞执行快重传和快恢复拥塞窗口减半后线性增长。实际开发中拥塞控制算法对性能影响很大。Linux默认使用CUBIC算法适合高带宽网络。Google提出的BBR算法则通过测量带宽和往返时间来调整发送速率在有一定丢包率的链路上表现更好。如果你在做视频传输或者大文件分发了解这些算法的差异能帮你做出更好的技术选型。4. UDP协议简单但不简陋4.1 UDP的报文格式与适用场景UDP的报文格式简单到令人发指源端口、目的端口、长度、校验和各占2字节一共8字节头部后面直接跟数据。没有序列号没有确认号没有窗口没有标志位。UDP不保证可靠交付不保证顺序不保证不重复甚至不保证能到达。那为什么还要用UDP因为简单意味着快。UDP没有连接建立和关闭的开销没有确认和重传的延迟没有拥塞控制的限速。对于实时性要求高、能容忍少量丢包的应用UDP是更好的选择。比如直播、视频会议、在线游戏、DNS查询这些场景下丢一帧画面比延迟几百毫秒要可接受得多。DNS查询用UDP是因为查询本身很小一次往返就能搞定用TCP三次握手反而慢。UDP的校验和是可选的IPv4中如果不计算校验和该字段填0。IPv6中校验和是强制计算的。校验和的计算需要用到伪首部包括源IP、目的IP、协议号、UDP长度。伪首部只是为了计算校验和不会实际传输。这个设计让UDP能检测出IP层的一些错误比如数据包被错误路由。4.2 UDP的缓冲区与丢包问题UDP没有流量控制发送方按自己的节奏发接收方按自己的节奏收。如果发送方发得太快接收方的缓冲区满了后续的数据包就会被内核直接丢弃。应用程序调用recvfrom()时如果缓冲区里有多个数据报它一次只能读一个剩下的还在缓冲区里。如果应用程序读取速度跟不上缓冲区迟早会满。这个问题在实际开发中很常见。我做过一个日志收集系统用UDP接收日志高峰期丢包严重。排查后发现是接收缓冲区太小默认只有几十KB。调整SO_RCVBUF参数后丢包率大幅下降。但调大缓冲区只是缓解根本解决办法还是要在应用层做限速或者改用TCP。UDP的丢包是静默的发送方完全不知道所以如果你用UDP传重要数据必须在应用层自己做确认和重传机制。注意UDP数据报的大小受MTU限制。以太网MTU通常是1500字节减去IP头和UDP头数据部分最多1472字节。超过这个大小IP层会分片任何一片丢失都会导致整个数据报丢弃。所以UDP应用通常会把数据控制在1200字节以内避免分片。4.3 TCP和UDP的选择框架到底选TCP还是UDP不能拍脑袋决定。我一般用下面这个框架来判断判断维度选TCP选UDP数据可靠性不能丢丢了要重传能容忍少量丢包实时性要求可以接受一定延迟延迟敏感宁可丢包连接开销可以接受三次握手需要快速开始传输数据量大量数据需要流控小数据包请求响应模式网络环境网络质量较好网络质量差或不确定实现复杂度希望内核处理可靠性愿意在应用层自己控制HTTP/1.1和HTTP/2用TCP因为网页内容不能丢。HTTP/3改用QUIC底层是UDP因为QUIC在应用层实现了可靠传输和拥塞控制同时避免了TCP的队头阻塞问题。这个演进过程说明TCP和UDP不是对立的而是可以组合的。QUIC就是把TCP的可靠性机制搬到UDP之上同时保留了UDP的灵活性。5. 传输层核心机制对比与实操排查5.1 TCP与UDP关键特性对照表特性TCPUDP连接方式面向连接无连接可靠性可靠有确认重传不可靠尽力交付顺序性保证顺序不保证顺序流量控制滑动窗口无拥塞控制有无头部大小20-60字节8字节传输效率较低较高适用场景文件传输、网页、邮件直播、游戏、DNS多播支持不支持支持状态维护有连接状态无状态这张表建议每个学网络的人都背下来面试时能脱口而出。但背下来只是第一步理解每一项背后的原因才是关键。比如为什么TCP头部是20到60字节因为固定部分20字节选项部分最多40字节。为什么UDP支持多播而TCP不支持因为TCP需要维护连接状态多播是一对多状态维护不现实。5.2 用命令行工具观察传输层状态理论学再多不如动手看一次。Linux上最常用的传输层排查工具是ss和netstat。ss是新一代工具性能更好推荐优先使用。查看所有TCP连接ss -tan查看监听端口ss -tlnp查看UDP连接ss -uan查看连接状态统计ss -s这些命令输出的State列就是TCP状态机的当前状态。ESTAB表示连接已建立TIME_WAIT表示等待关闭CLOSE_WAIT表示被动关闭方还没发FIN。如果你看到大量CLOSE_WAIT说明应用程序没有正确关闭连接可能是代码里忘了调用close()。如果看到大量TIME_WAIT说明主动关闭方太多可以考虑调整内核参数或者改用长连接。抓包工具tcpdump能让你看到传输层的报文细节tcpdump -i eth0 -nn tcp port 80这个命令会抓取80端口的TCP报文-nn表示不解析IP和端口为名称。你可以看到三次握手的SYN、SYN-ACK、ACK也能看到数据传输时的序列号和确认号。刚开始看可能觉得乱但抓几次就能看懂了。5.3 常见传输层问题排查速查表问题现象可能原因排查方法解决思路连接建立失败端口未监听、防火墙拦截ss -tlnp检查监听telnet测试连通启动服务、开放端口连接超时网络不通、SYN被丢弃tcpdump抓包看SYN是否有响应检查路由、防火墙规则大量TIME_WAIT短连接过多、主动关闭方集中ss -tan state time-wait统计改长连接、调整内核参数大量CLOSE_WAIT应用未关闭连接ss -tan state close-wait统计检查代码、修复资源泄漏传输速度慢窗口太小、拥塞控制限速ss -ti查看窗口和RTT调整窗口、换拥塞算法UDP丢包缓冲区满、MTU分片netstat -su看丢包统计调大缓冲区、减小包大小连接被重置RST报文、对端异常关闭tcpdump抓RST包检查对端服务状态这张表是我在实际工作中慢慢积累的每一条都对应着真实踩过的坑。比如“连接被重置”这个问题有一次线上服务频繁出现RST抓包发现是负载均衡器健康检查超时后主动发RST。后来调整了健康检查的超时时间就解决了。传输层的问题十有八九都能通过抓包找到线索。6. 从理论到代码传输层的实际应用6.1 Socket编程中的传输层参数写Socket代码时有几个参数直接对应传输层的机制。SO_RCVBUF和SO_SNDBUF控制接收和发送缓冲区大小影响滑动窗口的实际上限。TCP_NODELAY控制是否开启Nagle算法Nagle算法会把小包合并成大包发送减少网络开销但会增加延迟。对于交互式应用比如SSH、游戏通常要设置TCP_NODELAY来降低延迟。SO_REUSEADDR允许绑定处于TIME_WAIT状态的端口服务器重启时特别有用。没有这个选项服务器重启后要等2MSL才能重新绑定同一端口。SO_BACKLOG控制已完成三次握手但还没被应用accept()的连接队列长度。如果这个队列满了新的SYN会被丢弃或拒绝客户端会感受到连接超时。import socket sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) sock.bind((0.0.0.0, 8080)) sock.listen(128)这段代码里SO_REUSEADDR和TCP_NODELAY是服务端最常用的两个选项。listen(128)的参数就是backlog表示等待accept的连接队列长度。在高并发场景下这个值要适当调大否则会出现连接被拒绝的情况。6.2 一个简单的TCP客户端服务端示例下面是一个最小的TCP回声服务端能帮你直观理解传输层的数据流import socket def start_server(): server socket.socket(socket.AF_INET, socket.SOCK_STREAM) server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) server.bind((127.0.0.1, 9999)) server.listen(5) print(Server listening on port 9999) while True: conn, addr server.accept() print(fConnection from {addr}) while True: data conn.recv(1024) if not data: break conn.sendall(data) conn.close() if __name__ __main__: start_server()对应的客户端import socket def start_client(): client socket.socket(socket.AF_INET, socket.SOCK_STREAM) client.connect((127.0.0.1, 9999)) client.sendall(bHello, Transport Layer) response client.recv(1024) print(fReceived: {response.decode()}) client.close() if __name__ __main__: start_client()运行这个例子时你可以同时用tcpdump抓包观察三次握手、数据传输、四次挥手的完整过程。connect()调用触发三次握手sendall()发送数据recv()接收数据close()触发四次挥手。代码里的每一个调用在传输层都有对应的报文交互。把代码和抓包对照着看比看十遍书都管用。6.3 UDP编程的注意事项UDP的Socket编程比TCP简单但有几个坑要注意。sendto()发送的数据报如果超过MTUIP层会分片接收方需要重组。如果任何一片丢失整个数据报就废了。所以UDP应用要控制单包大小。recvfrom()每次只读一个数据报如果缓冲区太小多余的部分会被截断丢弃。所以缓冲区要足够大至少能容纳一个完整的数据报。import socket sock socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 1024 * 1024) sock.bind((0.0.0.0, 9999)) while True: data, addr sock.recvfrom(65535) print(fReceived {len(data)} bytes from {addr})这里把接收缓冲区调到了1MBrecvfrom的参数设为65535确保能接收最大的UDP数据报。实际应用中还要考虑丢包处理、乱序处理、重复包处理这些都需要在应用层自己实现。7. 传输层知识体系的构建建议学传输层最容易陷入的误区是死记硬背。三次握手四次挥手背得滚瓜烂熟但一问你为什么需要TIME_WAIT就卡壳。我的建议是先抓住“可靠传输”这个核心目标然后看TCP用了哪些机制来实现它序列号解决乱序和重复确认应答解决丢包超时重传解决确认丢失滑动窗口解决流量控制拥塞控制解决网络过载。每一个机制都是为了解决一个具体问题理解了问题机制就自然记住了。另一个建议是动手实践。装个Wireshark或者用tcpdump抓一次完整的HTTP请求看三次握手怎么建立连接看数据怎么传输看四次挥手怎么关闭。抓一次大文件传输看滑动窗口怎么变化看拥塞窗口怎么增长。抓一次UDP的DNS查询看请求和响应有多简单。这些直观的体验比任何文字描述都深刻。最后传输层的知识不是孤立的。它上承应用层下接网络层。理解传输层能帮你更好地理解HTTP、HTTPS、WebSocket这些应用层协议的设计。比如HTTP/2的多路复用本质上是在一条TCP连接上虚拟出多条流解决了HTTP/1.1的队头阻塞问题。HTTP/3干脆抛弃TCP改用QUIC在UDP上重新实现了可靠传输。这些演进都建立在传输层的基础知识之上。我在实际工作中最大的体会是传输层的知识不是用来考试的是用来解决问题的。当你遇到连接超时、传输慢、丢包这些问题时脑子里能浮现出TCP状态机、滑动窗口、拥塞控制这些概念知道从哪里下手排查这才是真正学会了。