CH5-运输层计算机网络

CH5运输层计算机网络·端到端通信服务的核心机制Contents目录计算机网络运输层核心协议与机制解析01运输层概述与核心功能02UDP与TCP协议对比03TCP流量控制机制04TCP拥塞控制机制05TCP可靠传输与连接管理Chapter01运输层概述与核心功能理解运输层在网络体系结构中的定位、职责与核心服务TransportLayer运输层的定位与作用运输层位于网络层与应用层之间，是实现"主机到主机"通信向"进程到进程"通信跃升的关键层。承上启下—向上为应用层提供通信服务，向下利用网络层的主机间交付能力，是体系结构中的关键枢纽端到端通信—网络层实现主机到主机的逻辑通信，运输层在此基础上扩展为应用进程间的通信端到端协议—通信双方运输层之间并无物理连接，数据实际沿协议栈上下多次传送屏蔽底层—应用开发者无需关心网络细节，只需调用运输层接口即可实现可靠的进程间通信TCP/IP五层体系结构·运输层位置示意TransportLayer复用与分用：运输层的核心功能复用与分用是运输层实现多进程并发通信的基础机制。复用允许多个应用进程共享运输层服务发送数据，分用则根据端口号将接收到的数据精准交付给目标进程。复用多个应用层进程可同时使用运输层服务，运输层为每份数据附加端口号等控制信息后统一封装并向下层交付Multiplexing分用运输层接收报文段后，根据目的端口号将数据准确交付给对应的应用进程，实现数据的精准路由Demultiplexing熟知端口号0–1023分配给常用服务如HTTP(80)、FTP(21)，登记端口号1024–49151用于需注册的应用0–1023客户端口号49152–65535由客户端程序随机选择，用于临时与服务器的通信会话，通信结束后即可释放49152–65535TransportLayer端口号：进程标识与分类体系端口号是运输层用于标识应用进程的核心机制，16位长度提供0-65535共65536个可用端口。IANA将端口号划分为熟知端口、登记端口和客户端口三大类，通过分层管理确保全球网络服务的端口分配标准化，避免冲突，使客户端能够准确寻址到目标服务。端口号基础端口号为16位整数(0-65535)，与IP地址共同构成套接字(Socket)，唯一标识网络中的一个通信端点0–65535熟知端口由IANA统一分配(0-1023)，如HTTP=80、HTTPS=443、FTP=21、SSH=22、DNS=53等标准服务0–1023登记端口供用户注册使用(1024-49151)，如MySQL=3306、Redis=6379、Tomcat=8080等非核心但广泛使用的服务1024–49151客户端口由操作系统动态分配(49152-65535)给发起连接的客户端进程，会话结束后回收，支撑高并发通信49152–65535TRANSPORTLAYER运输层四大核心功能运输层承担分段重组、流量控制、差错控制和连接管理四大核心功能，共同保障应用进程间的可靠高效通信。这些功能使运输层不仅是数据的"搬运工"，更是通信质量的"管理者"。数据处理分段与重组将应用层大数据块分割为适合网络传输的报文段，接收端按序重组还原，解决应用数据单元与网络MTU不匹配的问题。MTU适配数据处理多路复用与分用通过端口号机制实现一台主机上多个应用程序并发通信，每个进程独享一条逻辑通信信道。端口号传输保障流量控制基于滑动窗口机制调节发送速率，防止接收方缓存溢出导致数据丢失，保障收发双方速率匹配。滑动窗口传输保障差错控制通过校验和检测、序列号排序、确认重传等机制确保数据完整、有序、无差错地交付给应用层。确认重传TransportLayer端到端通信vs点对点通信网络层实现主机间的点对点通信，而运输层实现进程间的端到端通信。真正进行通信的实体不是主机本身，而是主机中的应用进程。01NetworkLayer主机到主机的逻辑通信—以IP地址标识主机，数据包经多跳路由实现物理层面的交付02TransportLayer进程到进程的逻辑通信—以IP地址+端口号标识进程，在两端主机上实现精准收发03ProcessEntity通信的真正实体是应用进程—同一主机上多个进程可同时与远端不同进程独立通信04ProtocolScope运输层协议只在两端主机起作用—中间路由器仅处理网络层及以下协议，不感知运输层信息CHAPTER02UDP与TCP协议对比深入理解两种运输层协议的设计理念、服务特征与适用场景TransportLayerUDP：用户数据报协议UDP以极简设计实现低延迟、低开销的数据传输，核心特征是"无连接+尽最大努力交付"。无连接通信发送数据前无需建立连接，应用层报文直接封装UDP首部后即可发送，通信延迟极低，无需握手过程零握手尽最大努力交付不保证数据可靠到达，不实现确认、重传、排序机制，丢失或损坏的数据不会自动恢复，依赖应用层处理无确认面向报文传输对应用层交付的报文原样封装，不拆分不合并，保持应用层消息边界的完整性，首部仅8字节开销极小8字节支持多对多通信除一对一外还支持一对多、多对一广播和多播，适用于群组通信和内容分发场景，灵活高效多播TRANSPORTLAYERTCP：传输控制协议TCP以'面向连接+可靠传输'为核心设计理念，通过三次握手建立连接、序列号与确认机制保障数据可靠交付、滑动窗口实现流量控制、拥塞控制算法保护网络资源。面向连接通信每次通信前通过三次握手建立连接，通信结束后通过四次挥手释放，保障通信过程的有序性。三次握手可靠字节流传输数据被视为连续字节序列，通过序号、确认、重传机制确保无差错、不丢失、不重复、按序交付。序号+确认内置流量控制利用滑动窗口机制根据接收方处理能力动态调节发送速率，防止接收缓存溢出导致数据丢失。滑动窗口内置拥塞控制通过慢开始、拥塞避免、快重传、快恢复等算法感知网络状态，避免发送过快导致网络过载崩溃。四大算法TRANSPORTLAYERUDP与TCP全面对比UDP与TCP代表运输层两种截然不同的服务策略：UDP以最小协议开销实现快速传输，TCP以完善控制机制实现可靠传输，选择本质是速度与可靠性的权衡。UDP与TCP核心特性对比对比维度UDPTCP连接方式无连接，直接发送面向连接，需三次握手建立可靠性尽最大努力交付，不可靠可靠传输，确认+重传机制通信模式支持一对一、一对多、多对多仅支持一对一（点对点）传输单位面向报文，保持消息边界面向字节流，无消息边界首部开销固定8字节，开销小最小20字节，最大60字节流量控制无滑动窗口机制拥塞控制无慢开始、拥塞避免、快重传、快恢复UDP以速度和简洁取胜，TCP以可靠和控制取胜，两者互补覆盖不同应用需求TRANSPORTLAYER·PROTOCOLHEADERUDP报文段首部结构UDP首部仅8字节，由源端口号、目的端口号、长度和校验和四个2字节字段组成，极简设计降低开销与延迟，但也意味着无法提供可靠性保障。UDPHEADER·8BYTES源端口号2BYTES目的端口号2BYTES长度2BYTES校验和2BYTESTOTAL:8BYTES源端口号标识发送方应用进程，在不需要回信时可置为0。该字段配合IP地址共同构成发送端套接字，使接收方能够识别数据来源。目的端口号标识接收方应用进程，是运输层分用机制的核心依据。端口号决定数据最终交付给哪个上层应用，实现多路复用与分解。长度字段记录UDP数据报总长度，包含首部与数据两部分。最小值为8字节即仅有首部，理论最大长度为65535字节，受限于16位字段宽度。校验和检测传输过程中数据是否发生损坏，覆盖首部、数据和伪首部三部分。若校验失败则直接丢弃报文不做任何重传处理，可靠性由应用层保障。TransportLayer·TCPTCP报文段首部结构TCP首部固定部分20字节，可选部分最大40字节，总计最大60字节。丰富的字段设计支撑了TCP的全部控制功能。01序号标识本报文段数据第一个字节的序号，TCP面向字节流编号，支撑数据排序、去重和丢失检测。4字节02确认号期望收到对方下一个报文段的第一个字节序号，采用累计确认机制，确认号N表示N之前的数据均已收到。4字节03数据偏移指示TCP首部长度，以4字节为单位，最小值5即固定20字节，最大值15即含选项共60字节。4位04窗口通告接收方当前可用缓存大小，发送方据此调整发送窗口，是TCP流量控制的直接实现手段。2字节TransportLayerTCP首部六大控制标志位TCP通过6个1比特的标志位精确控制报文段的功能语义与连接状态转换。SYN和FIN管理连接的建立与释放，ACK使确认机制生效，RST处理异常连接重置，URG和PSH控制数据的优先级与交付时机。ConnectionControl连接管理标志位SYN同步位三次握手时置1，SYN=1+ACK=0为连接请求报文，SYN=1+ACK=1为连接同意报文FIN终止位置1表示发送方数据传输完毕请求释放连接，四次挥手中双方各发一个FIN报文RST复位位置1表示连接出现严重差错需立即中断，也可用于拒绝无效的连接请求DataTransfer数据传输标志位ACK确认位置1时确认号字段才有效，TCP规定连接建立后传送的所有报文段ACK都必须置1PSH推送位置1时要求接收方立即将数据交付应用层而非在缓存中等待，适用于交互式通信URG紧急位置1时表示报文段含紧急数据需优先处理，配合紧急指针字段标识紧急数据的末尾位置CHAPTER03TCP流量控制机制通过滑动窗口与接收方通告实现收发速率的动态匹配TCP·传输层机制流量控制：为什么需要调节发送速率流量控制解决的核心矛盾是发送方发送速率与接收方处理速率的不匹配。当发送方持续以超出接收方处理能力的速率发送数据时，接收缓存将溢出导致数据丢失，破坏TCP的可靠传输承诺。流量控制通过接收方主动通告自身可用缓存空间，使发送方动态调整发送窗口，实现收发速率的自适应匹配。端到端机制由接收方根据自身缓存余量限制发送方的发送窗口大小，防止接收缓存溢出造成数据丢失，确保可靠传输。核心要素接收缓存余量·窗口通告·速率匹配区别于拥塞控制流量控制关注接收方处理能力，拥塞控制关注网络承载能力，两者独立运作又相互制约，共同约束实际发送窗口。双重约束接收窗口(rwnd)·拥塞窗口(cwnd)·取最小值动态自适应接收方每处理一批数据就更新窗口通告，发送方据此实时调整可发送数据量，形成闭环反馈机制。反馈机制ACK确认·窗口更新·实时调节必要性场景高性能服务器向低性能终端传输、突发数据流超出接收方处理速度等速率不匹配场景均需流量控制。典型场景异构设备互联·突发流量·移动网络TCPFlowControl滑动窗口机制：流量控制的核心实现滑动窗口是TCP流量控制的实现载体，发送窗口大小受接收方通告窗口约束。窗口随确认号推进向右滑动，形成连续的数据流控制闭环。发送窗口结构由"已发送未确认"和"可发送未发送"两部分组成，窗口大小等于接收方通告的接收窗口值。接收窗口值窗口滑动过程接收方确认数据后，确认号推进带动窗口右移，已确认数据移出窗口，新数据获得发送许可。确认号推进接收窗口通告接收方在每个ACK报文段的窗口字段中携带当前可用缓存大小，发送方据此调整发送窗口。ACK窗口字段动态调节效果接收方处理速度快时窗口大、传输效率高；处理速度慢时窗口小、发送速率自动降低。自适应速率TCPFLOWCONTROL零窗口与持续计时器：防止流量控制死锁当接收方通告零窗口时，发送方必须停止发送，但后续的窗口更新报文可能丢失导致发送方永久等待。TCP通过持续计时器机制解决这一死锁风险。STEP01零窗口通告接收方缓存满时发送窗口=0的确认报文，发送方收到后必须停止发送新数据，仅允许发送探测报文。窗口=0STEP02死锁风险接收方缓存释放后发出的窗口更新报文若丢失，发送方将永久认为窗口为0而无法恢复传输。报文丢失STEP03持续计时器发送方收到零窗口通知后启动，超时触发零窗口探测报文发送，接收方据此回复当前可用窗口大小。周期探测STEP04探测与恢复探测报文携带当前确认号，接收方回复包含最新窗口值的ACK，若窗口>0则传输立即恢复正常。ACK恢复CHAPTER04TCP拥塞控制机制通过慢开始、拥塞避免、快重传、快恢复四阶段算法保护网络稳定性TCPCongestionControl拥塞控制：保护网络免受过载崩溃网络拥塞发生时，路由器缓存溢出导致大量丢包和延迟激增，而丢包引发的重传又会进一步加重拥塞形成恶性循环。拥塞成因网络需求超过链路带宽和路由器缓存容量，导致数据包排队延迟增大、被迫丢弃，有效吞吐量反而下降。当多个流量汇聚到同一链路时，竞争加剧使问题恶化。核心矛盾：需求>容量恶性循环效应丢包触发重传增加网络负载，进一步加剧拥塞，若无控制机制将导致网络全面瘫痪。这种正反馈循环被称为拥塞崩溃，是早期互联网多次中断的主因。严重后果：拥塞崩溃拥塞窗口cwnd发送方维护的拥塞控制变量，与接收窗口共同决定实际发送窗口大小。TCP发送端通过动态调整cwnd来探测和适应网络可用带宽。发送窗口：min(cwnd,rwnd)拥塞信号判断主要依据超时重传和三个重复ACK两种信号触发不同控制策略。前者表示严重拥塞需激进降级，后者表示轻度拥塞可快速恢复。检测机制：Timeout+3-ACKTCPCongestionControl慢开始与拥塞避免：渐进式带宽探测慢开始从极小窗口出发以指数增长快速探测可用带宽，到达门限后切换为拥塞避免的线性增长，在逼近网络容量时更加谨慎。两个阶段共同遵循'AIMD'原则（加法增大、乘法减小），在追求高吞吐量的同时避免触发网络拥塞，实现网络资源的高效利用。慢开始阶段初始cwnd=1MSS，每收到一个新确认cwnd加1，每个RTT后cwnd翻倍（指数增长），快速探测可用带宽。2×指数慢开始门限拥塞窗口达到此阈值时从慢开始切换到拥塞避免，初始值通常设为较大值。ssthresh拥塞避免阶段每经过一个RTT（往返时间）cwnd增加1个MSS（加法增大），线性增长避免过快逼近网络容量上限。+1线性拥塞检测响应一旦检测到拥塞（超时或重复ACK），将ssthresh设为当前cwnd的一半（乘法减小），cwnd重置或缩减。½乘法TCPCONGESTIONCONTROL快重传与快恢复：优化轻度拥塞响应快重传在收到3个重复ACK后立即重传丢失报文段，避免等待超时带来的延迟浪费。快恢复认识到3个重复ACK意味着轻度拥塞而非严重拥塞（仍有报文能到达对端），因此不将cwnd重置为1重新慢开始，而是从减半的ssthresh直接进入拥塞避免，保持较高的传输效率。快重传机制接收方对乱序报文发送重复ACK，发送方收到3个重复ACK后立即重传缺失报文段，无需等待超时计时器触发。这一机制显著降低了丢包后的恢复延迟，避免了因等待超时导致的吞吐量下降。3DUPLICATEACKS延迟ACK策略接收方每收到2个报文段才发一次确认，乱序时仍立即发送重复ACK，为快重传提供及时信号。延迟ACK减少了确认包数量，但在检测到乱序时保持响应敏捷。每2段确认一次快恢复算法收到3个重复ACK时，ssthresh降为cwnd/2，cwnd设为ssthresh而非1，直接进入拥塞避免的线性增长阶段。这种处理方式避免了慢开始阶段的低效率，使连接能快速恢复到较高传输速率。cwnd=ssthresh设计考量3个重复ACK说明部分报文仍能到达对端，网络拥塞程度较轻，不必像超时那样激进地降低发送速率。快恢复体现了TCP对网络状态的精细判断，在保障稳定性的同时最大化带宽利用率。轻度拥塞CongestionControl拥塞控制全流程：四阶段状态转换TCP拥塞控制形成完整的状态机闭环：从慢开始的指数探测到拥塞避免的线性增长，根据拥塞信号类型选择激进回退（超时→慢开始）或温和回退（重复ACK→快恢复）。超时触发的严重拥塞响应01ssthresh减半—更新为当前cwnd的一半（乘法减小），记录上次拥塞时的带宽水位线，作为后续增长的阈值上限02cwnd重置为1MSS—重新进入慢开始阶段从头指数增长，保守重建传输速率，避免再次冲击网络cwnd=1SLOWSTART重复ACK触发的轻度拥塞响应01快重传—不等待超时直接重传丢失报文段，减少不必要的传输延迟，快速修复数据缺口02快恢复—ssthresh减半，cwnd设为新的ssthresh值，直接进入拥塞避免线性增长阶段cwnd=ssthreshFASTRECOVERYCHAPTER05TCP可靠传输与连接管理从序列号确认到三次握手四次挥手，完整理解TCP可靠性的实现基础ReliableTransportTCP可靠传输：序列号、确认与重传TCP可靠传输建立在序列号编号、确认应答和超时重传三大机制之上。每个字节被赋予唯一序列号，接收方通过确认号告知已接收进度，发送方对超时未确认的数据执行重传。三者协同工作，确保数据在网络丢包、乱序、重复等异常情况下仍能完整、有序地交付给应用层。字节流编号TCP将应用数据视为连续字节序列，每个字节分配唯一序号，报文段序号字段记录数据首字节编号。该机制为可靠传输奠定基础，确保接收方能按序重组数据。SequenceNo.确认应答接收方通过确认号告知发送方已成功接收的数据范围，确认号N表示序号N之前的所有字节均已收到。累积确认机制减少控制报文开销。ACK超时重传发送方为每个已发送未确认的报文段维护重传计时器，超时未收到确认则重新发送该报文段。这是TCP应对网络丢包的核心恢复机制。RetransmitRTO动态计算超时重传时间(RTO)基于加权平均往返时间(RTT)动态调整，超时后RTO加倍以应对网络恶化。自适应算法平衡传输效率与网络负载。RTO=2×RTTTCPACKNOWLEDGMENT累计确认与捎带确认：高效确认策略TCP采用累计确认减少确认报文数量——只确认连续已接收数据的最大序号，无需逐个确认每个报文段。同时利用捎带确认将确认信息搭载在反向数据报文中发送，避免单独确认报文造成的带宽浪费。累计确认接收方发送确认号N表示序号N之前的所有字节均已收到，无需逐个确认，大幅减少ACK报文数量，提升信道利用率。ACK优化批量确认累计确认的局限发送方无法获知N之后哪些报文段已成功到达，重传时可能包含已到达数据，造成带宽冗余，需配合SACK选项优化。信息盲区冗余重传捎带确认双向通信时将确认信息搭载在反向数据报文中发送，利用TCP头部的ACK标志位和确认号字段，减少独立ACK报文开销。双向复用带宽节省延迟确认策略每收到2个完整报文段或等待200ms才发送一次确认，平衡确认及时性与协议开销，配合快重传机制高效处理丢包。定时触发批量ACKTCPRTO超时重传时间RTO的动态计算TCP通过动态测量往返时间RTT并计算平滑值SRTT与偏差RTTVAR，自适应地确定超时重传时间RTO=SRTT+4×RTTVAR。01RTT采样测量每个报文段从发送到收到确认的实际往返时间，作为计算基础数据，仅对未被重传的报文段采样，确保数据准确性RTTsample02SRTT平滑SRTT=(1−0.125)×SRTT+0.125×RTT_sample，用加权平均消除单次采样的偶然波动，使估计值更加稳定可靠α=0.12503RTTVAR偏差RTTVAR=(1−0.25)×RTTVAR+0.25×|SRTT−RTT_sample|，反映网络延迟的波动程度，用于动态调整超时容限β=0.2504RTO确定与退避RTO=SRTT+4×RTTVAR，超时重传后RTO翻倍(2倍、4倍...)，遵循Karn算法避免重传干扰RTT测量，实现自适应退避×2BackoffTCP·ConnectionEstablishment三次握手：TCP连接建立过程三次握手确保双方收发能力正常并同步初始序列号，三次而非两次可防止历史连接导致资源浪费01第一次·SYN客户端发送SYN=1、seq=x的报文段，进入SYN-SENT状态等待服务器响应。SYN-SENT01防止历史连接两次握手无法区分当前请求与已失效的历史请求，第三次握手让服务器确认客户端仍在主动建立连接。安全防护02第二次·SYN+ACK服务器回复SYN=1、ACK=1、seq=y、ack=x+1的报文段，进入SYN-RCVD状态。SYN-RCVD02双向能力确认三次交互确保双方都能正常发送和接收，任何一方收发能力异常都无法完成握手。能力验证03第三次·ACK客户端发送ACK=1、seq=x+1、ack=y+1的报文段，双方进入ESTABLISHED状态。ESTABLISHED03初始序号同步双方交换各自的初始序列号（ISN），为后续数据传输的编号和确认奠定基础。ISNConnectionRelease四次挥手：TCP连接释放过程TCP全双工通信要求两个方向的数据流分别关闭，因此连接释放需要四次交互而非三次。主动关闭方先发送FIN表明本方数据发送完毕，被动方确认后仍可继续发送剩余数据（半关闭状态），待发完后被动方也发送FIN，最终双方各自确认对方的关闭请求完成连接释放。Step01第一次挥手—FIN主动关闭方发送FIN=1报文段（seq=u），进入FIN-WAIT-1状态，通知对方本方数据传输完毕。FIN-WAIT-1Step02第二次挥手—ACK被动方回复ACK（ack=u+1），进入CLOSE-WAIT状态。连接半关闭——被动方仍可发送剩余数据。CLOSE-WAITStep03第三次挥手—FIN被动方剩余数据发送完毕后发送FIN=1报文段（seq=w），进入LAST-ACK状态等待最后确认。LAST-ACKStep04第四次挥手—ACK主动方回复ACK（ack=w+1），进入TIME-WAIT状态，等待2MSL后彻底关闭；被动方收到ACK后立即关闭。TIME-WAITTCPConnectionLifecycleTIME-WAIT状态：为何等待2MSL主动关闭方在发送最后一个ACK后进入TIME-WAIT状态，需等待2MSL（最大报文段生存时间，通常共4分钟）才能彻底释放连接。可靠终止保障最后一个ACK可能丢失导致被动方重传FIN，TIME-WAIT期间主动方可重新确认，确保双方都能正常关闭。ACK残留报文消亡等待2M