CPIP协议第八章传输控制协议_第1页
CPIP协议第八章传输控制协议_第2页
CPIP协议第八章传输控制协议_第3页
CPIP协议第八章传输控制协议_第4页
CPIP协议第八章传输控制协议_第5页
已阅读5页,还剩29页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

ComputerNetworks·Chapter08TCP/IP协议:传输控制协议《计算机网络》第八章·运输层核心协议深度解析Contents课程目录TCP/IP协议第八章:传输控制协议01TCP/IP协议族概述与运输层定位02TCP报文段格式与端口机制03TCP连接管理:建立与释放04可靠传输与流量控制机制05TCP协议的实际应用与对比CHAPTER01TCP/IP协议族概述与运输层定位从协议族全景到运输层核心职责的系统认知Chapter8·ProtocolSuiteTCP/IP协议族:互联网通信的基石TCP/IP(传输控制协议/互联网协议)并非单一协议,而是由IP、TCP、UDP、HTTP、FTP、SMTP等多个协议组成的协议族。它定义了电子设备连入互联网及数据传输的标准,是国际互联网的基础架构,其开放性和分层设计使其成为全球通用的网络通信标准。互联网数据中心—TCP/IP协议族支撑的全球网络物理基础设施01协议族构成TCP/IP全称TransmissionControlProtocol/InternetProtocol,涵盖网络层IP协议和传输层TCP协议两大核心,辅以UDP、ICMP等协议构成完整体系。02统一通信标准协议族定义了电子设备如何连入因特网、数据如何在设备间传输的统一标准,使不同操作系统和硬件平台的计算机能够相互通信与资源共享。03规模化验证TCP/IP的广泛采用极大推动了互联网普及,从早期ARPANET到今天的全球互联网,其四层架构设计经受住了数十年的规模化考验。TCP/IPArchitectureTCP/IP四层体系结构TCP/IP采用四层体系结构(应用层→传输层→网络层→网络接口层),每层向上一层提供服务并调用下一层能力。传输层处于承上启下的关键位置,向上为应用进程提供通信服务,向下依赖网络层的数据传输能力,是实现端到端可靠通信的核心环节。应用层包含HTTP、FTP、SMTP、DNS等高层协议,直接面向用户需求,处理具体的网络应用逻辑与数据格式HTTP·DNS传输层包含TCP和UDP两大协议,负责端到端的数据传输控制,为应用进程提供可靠或尽最大努力的通信服务TCP·UDP网络层以IP协议为核心,负责数据包的路由选择和转发,实现跨网络的寻址与数据投递IP协议网络接口层处理物理帧的接收与发送,将IP数据报封装为适合具体物理网络的帧格式进行传输EthernetTCP/IPProtocolStack数据封装与传输流程实例以浏览网页为例,数据从应用层到网络接口层经历四次封装:HTTP数据→TCP报文段→IP数据报→以太网帧。每一层添加自己的控制头部信息,逐层传递直至物理介质发送,接收端则反向逐层解封装,完整呈现了协议栈的协作机制。应用层浏览器将网址请求组成HTTP数据,包含请求方法、URL、头部字段等,将完整应用层消息传递给传输层HTTP传输层TCP在HTTP数据前添加报头(含源端口、目的端口80、序列号等),封装为报文段后交给网络层TCP网络层IP协议在报文段前添加IP头部(含源与目的IP地址),形成数据报,完成路由寻址信息附加IP网络接口层在数据报前添加MAC帧头与帧尾(含源与目的MAC地址),封装成帧后通过物理网卡以比特流发送MACTRANSPORTLAYER运输层的核心定位与双协议架构运输层承上启下,TCP与UDP互补覆盖从可靠性到实时性的全谱需求。运输层定位位于应用层与网络层之间,为不同主机上的应用进程提供逻辑通信服务,屏蔽底层网络复杂性逻辑通信TCP协议面向连接的可靠字节流传输,具备错误检测、重传机制与流量控制,适用于文件传输与网页浏览可靠传输UDP协议无连接的尽最大努力交付,开销小、延迟低,适用于音视频流与DNS查询等实时性敏感场景实时交付CHAPTER02TCP报文段格式与端口机制从报文结构到端口寻址的底层技术解析TCPSegmentStructureTCP报文段首部格式详解TCP报文段由20字节固定首部和可选字段及数据部分组成。首部包含源/目的端口、序号、确认号、控制标志位、窗口大小等关键信息,这些字段共同支撑了TCP的可靠传输、连接管理和流量控制三大核心功能。源端口与目的端口标识发送方和接收方的应用进程,结合IP地址构成完整的通信端点,确保数据准确交付给目标进程2×16位序号标记本报文段所发送数据的第一个字节编号,TCP通过字节流编号机制实现数据的有序重组和丢失检测32位确认号表示期望收到对方下一个报文段的第一个字节序号,与序号配合构成TCP的确认应答机制32位控制标志位URG紧急、ACK确认、PSH推送、RST重置、SYN同步、FIN结束,六个标志位组合控制连接的建立、维护和释放全过程URGACKPSHRSTSYNFIN窗口大小指示发送方还能接收的数据量,是TCP滑动窗口流量控制机制的核心参数,动态调节发送速率以避免接收方缓冲区溢出16位TCPSegmentStructureTCP报文段的辅助字段与选项机制TCP报文段首部的辅助字段和选项机制为协议提供了灵活扩展能力。校验和确保数据完整性,紧急指针支持优先级数据传输,选项字段可协商MSS、窗口缩放因子和时间戳等参数,使TCP能够适应不同网络环境和应用需求,兼顾了标准化与灵活性。校验和覆盖TCP首部和数据部分的完整性校验,接收方通过重新计算校验和检测传输过程中是否出现比特错误,出错则丢弃报文段。16bit紧急指针配合URG标志位标记紧急数据的末尾字节位置,允许接收方优先处理紧急数据而不必等待缓冲区中的普通数据。URG选项字段常用选项包括MSS(协商单次传输数据上限以避免IP分片)、窗口缩放因子(扩大窗口值上限以支持高带宽网络)、时间戳(精确RTT测量和防止序号回绕)。MSSTCP/IP·Chapter08·TransportLayer端口机制:进程间通信的寻址基础端口是运输层用于标识应用进程的逻辑地址,结合IP地址构成完整的通信端点(插口)。端口号分为熟知端口与临时端口,使多个应用进程能同时复用同一网络传输通道。熟知端口由ICANN统一分配给常用应用层程序固定使用,覆盖核心网络服务。这些端口在全球范围内保持唯一性和一致性,确保任何主机都能通过标准端口号访问对应服务。FTP21·TELNET23·SMTP25·DNS53·HTTP80·HTTPS4430~1023系统保留端口临时端口由客户端操作系统在发起通信时动态分配,通信结束后回收,确保多进程并发访问网络服务。临时端口机制支持单机同时建立数千条并发连接,是互联网高并发架构的基础支撑。1024~65535动态分配端口插口Socket由IP地址(32位)与端口号(16位)组合而成,是TCP连接的唯一标识,由通信双方的插口对确定。插口抽象屏蔽了底层网络差异,为应用程序提供统一的网络编程接口。48位完整通信端点TCP/IP·应用层协议常见网络协议的熟知端口对照互联网标准服务均使用ICANN分配的熟知端口号(0~1023),每个端口号与特定应用层协议一一对应。掌握常用协议的端口映射关系是网络编程、服务器配置和网络故障排查的基础技能,也是理解应用层与传输层交互机制的关键。常用网络协议与熟知端口号对照表应用层协议协议全称端口号传输层协议主要用途FTPFileTransferProtocol21TCP文件传输TELNETTelecommunicationNetwork23TCP远程登录SMTPSimpleMailTransferProtocol25TCP电子邮件发送DNSDomainNameSystem53UDP/TCP域名解析HTTPHypertextTransferProtocol80TCP万维网网页传输HTTPSHTTPSecure443TCP加密网页传输SNMPSimpleNetworkManagementProtocol161UDP网络设备管理互联网核心服务均绑定固定的熟知端口号,大部分基于TCP实现可靠传输,少数如DNS和SNMP使用UDP以提高效率。CHAPTER03TCP连接管理:建立与释放三次握手建立连接与四次挥手释放连接的完整过程TCP·ConnectionEstablishmentTCP三次握手:连接建立的完整过程TCP通过三次握手建立可靠的双向连接:客户端发SYN→服务器回SYN+ACK→客户端再发ACK。三次握手不仅同步了双方的初始序号,还确认了双方的收发能力均正常,同时防止已失效的历史连接请求造成资源浪费,是面向连接传输的基石。STEP1第一次握手:客户端发送SYN客户端发送SYN报文段(SYN=1,seq=x),告知服务器希望建立连接并携带自己的初始序号,客户端进入SYN-SENT状态。SYN=1seq=xSTEP2第二次握手:服务器回复SYN+ACK服务器收到SYN后回复SYN+ACK报文段(SYN=1,ACK=1,seq=y,ack=x+1),确认客户端请求并携带自己的初始序号,服务器进入SYN-RCVD状态。SYN+ACKseq=y·ack=x+1STEP3第三次握手:客户端发送ACK客户端收到确认后发送ACK报文段(ACK=1,seq=x+1,ack=y+1),服务器收到后双方连接建立完成,进入ESTABLISHED状态。ACK=1ESTABLISHEDTCPConnectionEstablishment三次握手的设计原理:为什么不能是两次三次握手的核心设计目标是确认双方的收发能力均正常,并防止历史失效的连接请求造成资源浪费。两次握手只能确认单向通信能力,无法让服务器确认客户端是否正确收到了自己的初始序号,且无法抵御过期SYN报文导致的"幽灵连接"问题,三次是保证连接可靠建立的最小次数。01两次握手无法防止"幽灵连接":若历史SYN因网络延迟重新到达服务器,服务器会错误建立连接并分配资源,而客户端不会响应,造成服务器资源浪费。02三次握手中客户端不发第三次ACK则连接不成立:服务器在SYN-RCVD状态收不到确认,超时后自动释放半连接资源,有效避免了失效请求的干扰。03三次握手确保双向确认:第一次确认客户端能发送,第二次确认服务器能收发,第三次确认客户端能接收,三步完成双方收发能力的完整验证。TCP·ConnectionReleaseTCP四次挥手:连接释放的完整过程TCP通过四次挥手释放连接,每次交互确保双向通道独立关闭;主动关闭方最终进入TIME-WAIT等待2MSL,让残留报文消散。01第一次挥手主动关闭方发送FIN报文段(FIN=1,seq=u),告知对方自己已无数据发送,进入FIN-WAIT-1状态。FIN-WAIT-102第二次挥手被动方收到FIN后回复ACK(ack=u+1),进入CLOSE-WAIT状态;主动方收到确认后进入FIN-WAIT-2,被动方可能还有数据要发送。CLOSE-WAIT03第三次挥手被动方数据发送完毕后发送FIN报文段(FIN=1,seq=w),表示自己也准备关闭连接,进入LAST-ACK状态。LAST-ACK04第四次挥手主动方收到FIN后回复ACK(ack=w+1),进入TIME-WAIT状态等待2MSL(最大报文段生存时间的两倍)后才彻底关闭连接。2MSLTCPConnectionLifecycleTIME-WAIT状态的设计意义与影响TIME-WAIT状态持续2MSL,确保最后ACK可靠送达并让残留报文消散,但高并发短连接场景下可能引发端口耗尽问题。确保ACK可靠送达若被动方未收到最终ACK会超时重发FIN,主动方在TIME-WAIT期间可捕获并重发ACK,保证对方正常关闭连接。这是TCP四次挥手机制的关键保障,防止连接异常终止导致的数据不一致问题。超时等待机制2MSL让残留报文消散2MSL时间足以覆盖报文段的最大往返周期,避免旧连接的迟到报文被复用相同端口号的新连接误收。这种设计有效防止了网络中滞留的历史数据包干扰后续通信的可靠性。网络隔离保护RTT×2高并发端口挑战大量TIME-WAIT连接占用端口资源,可通过tcp_tw_reuse或连接池、长连接等架构策略缓解端口耗尽风险。合理调优内核参数与优化应用架构是应对这一挑战的有效手段。内核参数调优tcp_tw_reuseTRANSMISSIONCONTROLPROTOCOLTCP连接状态机:11种状态的完整转换TCP连接生命周期涵盖11种状态,从CLOSED出发经三次握手到ESTABLISHED,再经四次挥手回到CLOSED。理解状态转换不仅有助于掌握协议原理,更是网络故障诊断的实用技能。PHASE1连接建立阶段01LISTEN:服务器调用bind和listen后进入监听状态,等待客户端SYN请求02SYN-SENT:客户端发送SYN后进入此状态,等待服务器确认03SYN-RCVD:服务器收到SYN并发送SYN+ACK后,等待客户端最终确认3-WAYHANDSHAKEPHASE2数据传输阶段ESTABLISHED连接建立完成,双方可正常传输数据,是TCP连接的核心工作状态。在此阶段,数据包通过序列号和确认号机制实现可靠传输,滑动窗口控制流量。DATATRANSFERFLOWCONTROLRELIABLEFULL-DUPLEXPHASE3连接释放阶段01FIN-WAIT-1/2:主动关闭方发送FIN后的等待阶段,等待对方确认及其FIN02CLOSE-WAIT:被动方收到FIN后,等待应用层处理完剩余数据并主动关闭03LAST-ACK:被动方发送FIN后等待最后一个ACK确认04TIME-WAIT:主动方发送最终ACK后的安全等待期,持续2MSL后彻底关闭4-WAYHANDSHAKEChapter04可靠传输与流量控制机制序号确认、滑动窗口与超时重传的核心原理TCP·TRANSMISSIONCONTROLPROTOCOL可靠传输基石:字节流编号与确认应答TCP将数据视为无结构的字节流,每个字节都有唯一编号。发送方通过序号标识报文段起始字节位置,接收方通过确认号反馈已成功接收的字节范围。这种"发送-确认-超时重传"的闭环机制,在不可靠的IP网络之上构建了可靠的数据传输保障。字节流编号机制TCP为应用层数据的每个字节分配递增序号,报文段的序号字段标识该段所携带数据的第一个字节编号,实现数据的精确定位。SEQ=N累积确认机制确认号表示接收方已成功收到该序号之前所有字节的确认,如ack=501表示序号0~500的字节均已正确接收。ACK=501超时重传触发发送方为每个已发送未确认的报文段启动定时器,若在超时时间内未收到确认则重新发送该报文段,确保数据不因丢包而丢失。RTO定时器TCPFlowControl滑动窗口:TCP流量控制的核心机制窗口大小由接收方动态通告,随确认到来向右滑动,既保证发送速率可控,又允许连续发送显著提升效率。01窗口结构划分—已发送已确认(窗口左侧)→已发送未确认(窗口内左半)→允许发送但尚未发送(窗口内右半)→不允许发送(窗口右侧),四区域随确认到来动态滑动。4Zones·DynamicSliding02接收方动态通告—接收方在每个ACK报文中通过窗口字段告知发送方当前缓冲区剩余容量,发送方据此调整发送窗口大小,防止接收方缓冲区溢出。ACKWindowField03连续发送提效—窗口内允许多个报文段同时处于"已发送未确认"状态,不必逐一等待确认,在带宽延迟积较大的网络中可显著提升吞吐量。Bandwidth×RTTTCPFlowControl滑动窗口工作过程示例窗口大小决定同时在途的未确认数据量,直接影响传输吞吐量——窗口越大并发度越高,但受限于接收方缓冲区与网络拥塞状况。初始状态0–499发送窗口覆盖序号0~499共5个报文段,发送方一次性发送全部5个报文段,无需等待逐一确认。第一次滑动100–599收到ack=100(确认0~99字节),窗口右移100字节,发送方立即发送序号500~599的新报文段。第二次滑动300–799收到ack=300(确认0~299字节),窗口右移200字节,发送方可继续发送序号600~799的两个新报文段。WindowSlidingProgression01003000–499ack100–599ack300–799发送窗口(500B)未来可发送区域RETRANSMISSION&RTT超时重传与RTT动态估算TCP通过超时重传机制应对数据包丢失,而超时时间RTO(重传超时时间)需要动态适应网络状况。TCP使用加权平均法持续估算RTT(往返时间),并基于RTT及其偏差计算RTO。这种自适应机制避免了固定超时时间在不同网络环境下的效率问题,是TCP在异构互联网中保持稳定性能的关键技术。RTT采样与加权平均发送方记录报文段发送时间,收到确认后计算实际RTT样本,使用指数加权移动平均法平滑RTT估算值。该方法有效过滤网络瞬时抖动,提供稳定的基准参考。新RTT=α×旧RTT+(1-α)×样本RTO动态计算RTO=RTT估算值+4×RTT偏差。偏差大时RTO增大以适应网络波动,偏差小时RTO趋近RTT以提高响应速度。这种动态调整平衡了可靠性与传输效率。RTO=SRTT+4×DevRTTKarn算法修正重传报文段的确认不用于更新RTT,因为无法区分是对原始报文还是重传报文的确认,避免估算被干扰。同时采用指数退避策略,防止网络拥塞时频繁重传。KARNALGORITHMTCPTRANSMISSIONCONTROL确认优化策略:延迟确认与快重传TCP通过延迟确认减少网络开销,通过快重传加速丢包恢复——两种策略体现了传输效率与可靠性之间的精细平衡。延迟确认与捎带技术接收方不立即发ACK而是短暂等待,若恰好有数据要发送则将确认号附加在数据包头部一起发送,减少独立的ACK报文数量ACK重复ACK检测接收方收到失序报文段时,立即重发对最近有序字节的确认,发送方据此感知到中间某个报文段可能已丢失DupACK快重传触发发送方连续收到3个相同确认号的重复ACK后,不等超时定时器到期就立即重传丢失的报文段,将丢包恢复延迟从RTO降低到约1个RTT1RTTTCPCongestionControl拥塞控制:全局性的网络保护机制拥塞控制是TCP在网络层面的保护机制,防止过多数据注入网络导致路由器缓冲区溢出和全局性能崩溃。实际发送窗口=min(cwnd,rwnd),核心思想是AIMD:加性增与乘性减。拥塞窗口cwnd发送方根据网络拥塞程度动态维护的窗口变量,网络畅通时增大、检测到拥塞时减小,直接控制发送速率。网络空闲时线性增长拥塞时快速降低cwnd双窗口约束实际发送窗口取拥塞窗口与接收窗口的最小值,同时满足网络承载能力和接收方处理能力的双重约束。cwnd:网络容量上限rwnd:接收方处理能力min(cwnd,rwnd)AIMD核心原则网络良好时每次RTT线性增加窗口(加性增),拥塞时窗口减半或重置(乘性减),在公平性与效率间平衡。加性增:缓慢探测带宽乘性减:快速缓解拥塞AIMDTCP拥塞控制慢开始与拥塞避免算法慢开始阶段拥塞窗口指数增长快速探测带宽,达门限后切换为线性增长谨慎逼近网络容量慢开始初始cwnd=1个MSS,每收到一个完整窗口的确认后窗口翻倍,以指数增长快速从低起点探测网络可用带宽。2×指数切换时机当cwnd达到慢开始门限ssthresh时切换到拥塞避免算法,ssthresh初始值通常为65535字节或上次拥塞窗口的一半。ssthresh拥塞避免每经过一个RTT,cwnd仅增加1个MSS,以线性增长缓慢逼近网络容量上限,降低触发拥塞的风险。+1MSS/RTTTCPCONGESTIONCONTROL快重传与快恢复:轻度拥塞的快速响应快重传在收到3个重复ACK后立即重传,快恢复避免窗口重置为1。3个重复ACK表明轻度拥塞,不必像超时那样激进降低发送速率。快重传触发条件连续收到3个相同确认号的重复ACK,发送方立即重传丢失报文段而不等待超时定时器到期。3ACK快恢复操作ssthresh设为当前cwnd的一半,cwnd设为新的ssthresh值而非重置为1,直接进入拥塞避免阶段。cwnd/2与超时的区别超时意味严重拥塞,cwnd重置为1并重新慢开始;3个重复ACK为轻度拥塞,采用温和的快恢复策略。MildTRANSPORTLAYER·CHAPTER08TCP拥塞控制四种算法总结TCP拥塞控制由慢开始、拥塞避免、快重传和快恢复四种算法协同构成。慢开始与拥塞避免控制窗口的增长模式(指数vs线性),快重传与快恢复处理丢包事件的响应策略。四种算法根据网络反馈信号(正常确认/重复ACK/超时)自动切换,形成完整的自适应拥塞控制体系。TCP拥塞控制四种算法对照表算法名称触发条件窗口变化方式设计目的慢开始连接建立/超时后每个RTT翻倍(指数增长)从小起点快速探测网络可用带宽拥塞避免cwnd≥ssthresh每个RTT增加1个MSS(线性增长)谨慎逼近网络容量上限避免拥塞快重传连续3个重复ACK立即重传丢失报文段加速丢包恢复减少等待超时的延迟快恢复快重传之后ssthresh=cwnd/2,cwnd=ssthresh轻度拥塞下避免过度降低发送速率四种算法根据网络反馈信号自动切换,形成"探测—增长—检测—恢复"的完整拥塞控制闭环。CHAPTER05TCP协议的实际应用与对比TCP与UDP的特性对比及典型应用场景分析Chapter8·TransportLayerUDP协议特性:轻量高效的传输选择UDP(用户数据报协议)提供无连接的、尽最大努力的数据报传输服务。虽然没有TCP的可靠传输保障,但UDP凭借零连接开销、极短首部(仅8字节)和低延迟特性,在实时音视频、DNS查询、游戏等对速度敏感且能容忍少量丢包的场景中具有不可替代的优势。UDP在实时视频通话中的典型应用——低延迟传输保障流畅体验01无连接零开销:发送数据前不需要建立连接,发送完毕也不需要释放连接,大幅减少了通信前的时延和控制报文开销02首部极简仅8字节:相比TCP的20字节固定首部,UDP首部只包含源端口、目的端口、长度和校验和四个字段,额外协议开销极低03支持多种通信模式:不仅支持一对一的单播,还支持一对多的多播和广播通信,适用于服务发现、消息通知等群组通信场景TRANSPORTLAYERPROTOCOLSTCP与UDP核心特性全面对比TCP和UDP是运输层的两大协议,设计理念截然不同:TCP追求可靠性(面向连接、确认重传、流量/拥塞控制),UDP追求效率(无连接、尽最大努力交付、极低开销)。两者互补覆盖了互联网从文件传输到实时通信的全谱需求。TCP与UDP核心特性对比表对比维度TCPUDP连接方式面向连接(三次握手建立)

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论