计算机网络：第3章 运输层

第3章:运输层本章目的:

理解运输层服务的原理:复用/分用可靠数据传输流量控制拥塞控制了解Internet运输层协议:UDP：无连接运输TCP:基于连接的运输TCP拥塞控制2025/12/221目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的运输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/222运输服务和协议为不同主机上运行的应用进程之间提供逻辑通信(logicalcommunication)运输协议发送方：把应用数据划分成报文段(segments),交给网络层接收方：把报文段重组成应用数据，交付给应用层应用程序可以使用多种运输层协议：因特网:TCP和UDP应用层运输层网络层数据链路层物理层应用层运输层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层网络层数据链路层物理层逻辑端到端传输2025/12/223运输层为相互通信的应用进程提供了逻辑通信54321运输层提供应用进程间的逻辑通信主机A主机B应用进程应用进程路由器1路由器2AP1LAN2WANAP2AP3AP4IP层LAN1AP1AP2AP4端口端口54321IP协议的作用范围运输层协议TCP和UDP的作用范围AP32025/12/224运输层和网络层网络层:

不同主机之间的逻辑通信运输层:

应用进程之间的逻辑通信类似于家庭间通信:12个孩子要与另一个家庭的12个孩子相互通信进程=孩子们进程间报文=信封中的信笺主机=家庭的房子运输协议=张三

和李四网络层协议=邮局提供的服务2025/12/225Internet运输层协议Internet的运输层有两个不同的协议用户数据报协议UDP(UserDatagramProtocol)传输控制协议TCP(TransmissionControlProtocol)2025/12/226Internet运输层协议两个对等运输实体在通信时传送的数据单位叫作运输协议数据单元

TPDU(TransportProtocolDataUnit)。TCP传送的数据单位协议是TCP报文段(segment)UDP传送的数据单位协议是UDP报文或用户数据报。2025/12/227Internet运输层协议TCP和UDP的基本任务多路复用、多路分解TCP可靠的数据传输流量控制拥塞控制UDP没有对IP协议的尽力而为服务提供任何扩展不提供的服务延时承诺、带宽承诺2025/12/228目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的运输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/229复用和分用(multiplexing/Demultiplexing)应用层传输层网络层数据链路层物理层P1应用层传输层网络层数据链路层物理层应用层传输层网络层数据链路层物理层P2P3P4P1主机1主机2主机3=进程=套接字（socket）将收到的报文段交付给正确的套接字接收方主机的分用:从不同套接字收集数据块，为每个数据块封装传输层首部信息（这将在分用时使用）发送方主机的复用:2025/12/2210复用和分用(multiplexing/Demultiplexing)回顾:segment（段）-运输层实体间交换数据的单位TPDU:运输层数据单元应用层运输层网络层MP2应用层运输层网络层接收方HtHnsegment报文段M应用层运输层网络层P1MMMP3P4报文段首部应用层数据2025/12/2211复用和分用(multiplexing/Demultiplexing)应用层运输层网络层TCP

报文段UDP用户数据报应用进程TCP

复用

IP

复用UDP复用

TCP

报文段UDP用户数据报

应用进程端口端口TCP

分用UDP

分用IP

分用IP数据报IP数据报发送方接收方2025/12/2212端口端口的作用就是让应用层的各种应用进程都能将其数据通过端口向下交付给运输层，以及让运输层知道应当将其报文段中的数据向上通过端口交付给应用层相应的进程。从这个意义上讲，端口是用来标志应用层的进程。端口用一个16bit端口号进行标志。2025/12/2213两类端口一类是熟知端口，其数值一般为0~1023。当一种新的应用程序出现时，必须为它指派一个熟知端口。另一类则是一般端口，用来随时分配给请求通信的客户进程。2025/12/2214套接字TCP使用“连接”(而不仅仅是“端口”)作为最基本的抽象，同时将TCP连接的端点称为套接字(socket)。套接字和端口、IP地址的关系是：IP地址3端口号1500

3,1500套接字(socket)2025/12/2215分用是如何工作的？主机收到IP包每个数据包都有源IP地址和目的IP地址每个数据包都携带一个传输层的数据报文段每个数据报文段都有源、目的端口号

主机根据“IP地址＋端口号”将报文段定向到相应的套接字源端口#目的端口#32位应用数据(报文)其他首部字段TCP/UDP报文段格式2025/12/2216无连接的复用与分用根据端口号创建socket:DatagramSocketmySocket1=newDatagramSocket(99111);DatagramSocketmySocket2=newDatagramSocket(99222);UDPsocket由一个二元组来标识:(目的IP地址,目的端口号)当主机收到UDP报文段时:检查报文段中的目的端口号将UDP报文段定向到相应的套接字具有不同源IP地址和/或源端口但具有相同的目的IP地址和端口的IP包定向到相同的套接字2025/12/2217无连接的复用与分用(续)DatagramSocket

serverSocket=newDatagramSocket(6428);客户IP:BP2客户IP:AP1P1P3服务器IP:CSP:6428DP:9157SP:9157DP:6428SP:6428DP:5775SP:5775DP:6428SP提供“返回地址”（完整的返回地址是源IP地址和源端口号）2025/12/2218面向连接的复用与分用TCP套接字由一个四元组来标识:源IP地址源端口号目的IP地址目的端口号接收方主机根据这四个值将报文段定向到相应的套接字服务器主机同时支持多个并发的TCP套接字:每一个套接字都由其四元组来标识Web服务器为每一个客户连接都产生不同的套接字非持久HTTP对每一个请求都建立不同的套接字（会影响性能）2025/12/2219面向连接的复用与分用(续)客户IP:BP1客户IP:AP1P2P4服务器IP:CSP:9157DP:80SP:9157DP:80P5P6P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B2025/12/2220面向连接的复用与分用:

多线程的Web服务器客户IP:BP1客户IP:AP1P2服务器IP:CSP:9157DP:80SP:9157DP:80P4P3D-IP:CS-IP:AD-IP:CS-IP:BSP:5775DP:80D-IP:CS-IP:B2025/12/2221复用/分用:举例主机A服务器Bsourceport:xdest.port:23sourceport:23dest.port:x端口的使用:简单的telnet应用Web客户端主机AWeb服务器BWeb客户端主机CSourceIP:CDestIP:Bsourceport:xdest.port:80SourceIP:CDestIP:Bsourceport:ydest.port:80端口的使用:Web服务器SourceIP:ADestIP:Bsourceport:xdest.port:802025/12/2222目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的运输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/2223UDP:用户数据报协议

[RFC768]只提供必要服务的最简化的Internet运输协议“尽力而为”服务，UDP报文段可能会:丢失应用数据不按序到达无连接:在UDP发送方和接收方之间无握手过程UDP报文段之间是相互独立的为什么会选择UDP?无需建立连接(建立连接会增加延迟)简单:发送方和接收方无需维护连接状态段首部开销小无拥塞控制:UDP可按需要随时发送2025/12/2224UDP:(续)多用于流媒体应用允许丢包对传输速率要求高其他使用UDP的应用DNSSNMP若希望实现基于UDP的可靠传输:在应用层增加可靠性保证，应用程序要有差错恢复机制源端口#目的端口#32位应用数据(报文)UDP报文段结构长度检查和包括首部在内的UDP报文段长度,（以字节为单位）2025/12/2225UDP校验和(checksum)发送方:把报文段看作是16比特字的序列检查和：对报文段的所有16比特字的和进行1的补运算发送方将计算校验和的结果写入UDP校验和字段中接收方:计算接收到的报文段的校验和检查计算结果是否与收到报文段的校验和字段中的值相同:不同–检测到错误相同–没有检测到错误(但仍可能存在错误)目标:

检测收到的报文段的“差错”(例如,出现突变的比特)2025/12/2226Internet中计算校验和的例子例子:将两个16比特字相加1111001100110011011101010101010101110111011101110111101110111011110010100010001000011回卷和检查和注意最高有效位的进位要回卷加到结果当中2025/12/2227目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的运输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/2228可靠数据传输的原理在应用层、运输层和链路层都很重要网络中最重要的top-10问题之一!不可靠信道的特性决定了可靠数据传输协议(rdt)的复杂性。2025/12/2229可靠数据传输(rdt)发送方接收方rdt_send():

由上层（如应用层）调用，将数据发送给接收方的上层udt_send():

由rdt调用,将分组通过不可靠通道传给接收方rdt_rcv():

当分组到达接收方时调用deliver_data():

由

rdt

调用，将数据交付上层2025/12/2230可靠数据传输(rdt)我们将要:逐步地开发可靠数据传输协议(rdt)的发送方和接收方只考虑单向数据传输(unidirectionaldatatransfer)的情况但控制信息是双向传输的!用有限状态机(FSM)来描述发送方和接收方状态1状态2事件引起状态变迁状态转换过程中的动作状态:

由事件引起一个状态到另一个状态的变迁。事件动作2025/12/2231Rdt1.0:可靠信道上的可靠传输底层信道完全可靠不会产生比特错误不会丢失分组分别为发送方和接收方建立FSM:发送方将数据发送给底层信道接收方从底层信道接收数据packet=make_pkt(data)udt_send(packet)rdt_send(data)extract(packet,data)deliver_data(data)等待来自下层的调用rdt_rcv(packet)发送方接收方等待来自上层的调用2025/12/2232Rdt2.0:具有比特差错的信道上的rdt底层信道中分组可能出现比特跳变回顾：UDP用校验和来检测比特错误问题：如何从差错中恢复：确认——acknowledgements(ACKs):

接收方明确告诉发送方正确收到分组否认——negativeacknowledgements(NAKs):

接收方明确告诉发送方分组有错发送方在收到NAK时重传分组rdt2.0

中新的机制:差错检测接收方反馈:控制信息(ACK,NAK)接收方->发送方重传2025/12/2233rdt2.0:FSM说明等待来自上层的调用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&

isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&

corrupt(rcvpkt)等待

ACK或NAK等待来自下层的调用发送方接收方rdt_send(data)L2025/12/2234rdt2.0:无差错的处理等待来自上层的调用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&

isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&

corrupt(rcvpkt)等待

ACK或NAK等待来自下层的调用rdt_send(data)L发送方接收方2025/12/2235rdt2.0:有差错的情况等待来自上层的调用snkpkt=make_pkt(data,checksum)udt_send(sndpkt)extract(rcvpkt,data)deliver_data(data)udt_send(ACK)rdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)rdt_rcv(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&

isNAK(rcvpkt)udt_send(NAK)rdt_rcv(rcvpkt)&&

corrupt(rcvpkt)等待

ACK或NAK等待来自下层的调用rdt_send(data)L发送方接收方2025/12/2236rdt2.0有一个致命的缺陷!如果ACK/NAK受损会出现什么情况?发送方不知道接收方发生了什么!如果只考虑重传：可能会出现大量重复分组对重复分组的处理:发送方对每一个分组增加序号(equencenumber

)发送方只重传没有收到ACK/NAK的分组接收方丢弃重复分组(不向上递交)发送方发出一个分组，然后等待接收方的应答停止等待(stop-and-wait)2025/12/2237rdt2.1:发送方对ACK/NAK的处理等待来自上层的调用0sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)rdt_send(data)等待

ACK或NAK0udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))sndpkt=make_pkt(1,data,checksum)udt_send(sndpkt)rdt_send(data)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isNAK(rcvpkt))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt)

等待来自上层的调用1等待ACK或NAK1LL2025/12/2238rdt2.1:接收方对ACK/NAK的处理等待来自下层的0sndpkt=make_pkt(NAK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq0(rcvpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)

extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)等待来自下层的1rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq0(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)sndpkt=make_pkt(ACK,chksum)udt_send(sndpkt)sndpkt=make_pkt(NAK,chksum)udt_send(sndpkt)2025/12/2239rdt2.1:讨论发送方:分组中增加序号两个序号(0,1)是否足够，为什么?如果收到乱序的ACK/NAK必须进行检查状态数是以前的两倍状态必须反映出当前正在发送的分组的序号是0还是1接收方:如果收到重复的分组必须检查状态必须反映出当前希望接收的分组的序号是0还是1注意:接收方不知道它最后发出的ACK/NAK是否被发送方正确接收2025/12/2240rdt2.2:在具有比特差错信道上的无NAK的可靠数据传输协议功能等同于rdt2.1，但只使用ACK取消了NAK,接收方对最后一个正确收到的分组发送ACK接收方必须明确指出被确认的分组的序号发送方收到的重复的ACK将按照NAK来进行处理重传正确的分组2025/12/2241rdt2.2:发送方和接收方等待来自上层的调用0sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)rdt_send(data)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||

isACK(rcvpkt,1))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,0)

等待ACK0发送方部分FSM等待来自下层的0rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&has_seq1(rcvpkt)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(ACK1,chksum)udt_send(sndpkt)rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||

has_seq1(rcvpkt))udt_send(sndpkt)接收方部分FSML2025/12/2242rdt3.0:在具有比特差错的丢包信道上的可靠数据传输新的假设:

底层信道会丢包(数据或ACK)检查和，序号，ACK和重传可以有助于解决问题，但这些远远不够Q:

如何处理数据丢失?发送方可以等待，当某些数据或ACK丢失时,进行重传想一想:缺点?解决方法:

发送方对ACK等待“适当的”时间如果在这个时间内没有收到ACK则重传如果分组或ACK仅仅是延迟到达（而非丢失）:重传将造成重复，但序号可以解决这个问题接收方必须指出确认的分组序号需要倒计时的计时器2025/12/2243rdt3.0发送方sndpkt=make_pkt(0,data,checksum)udt_send(sndpkt)start_timerrdt_send(data)等待ACK0rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,1))等待来自上层的调用1sndpkt=make_pkt(1,data,checksum)udt_send(sndpkt)start_timerrdt_send(data)rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,0)

rdt_rcv(rcvpkt)&&(corrupt(rcvpkt)||isACK(rcvpkt,0))rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)&&isACK(rcvpkt,1)

stop_timerstop_timerudt_send(sndpkt)start_timertimeoutudt_send(sndpkt)start_timertimeoutrdt_rcv(rcvpkt)等待来自上层的调用0等待ACK1Lrdt_rcv(rcvpkt)LLL2025/12/2244rdt3.0时序图2025/12/2245rdt3.0时序图2025/12/2246rdt3.0的性能rdt3.0功能可用,但性能不尽如人意例如:1Gbps的链路,15ms的端到端延迟,分组大小为1KB:Ttransmit=8kb/pkt109b/sec=8μsUsender:利用率

–发送方用于发送的时间片每30ms内只能发送1KB：1Gbps

的链路只有33kB/sec的吞吐量网络协议限制了物理资源的利用率!L(比特为单位的分组大小)R(传输速率,bps)=2025/12/2247rdt3.0:停等操作首个分组的第1个比特被传输,t=0发送方接收方RTT

首个分组的最后1比特被传输,

t=L/R首个分组的第1个比特到达首个分组的最后1个比特到达,发送ACKACK到达,发送下一个分组,t=RTT+L/R2025/12/2248流水线协议流水线(Pipelining):

允许发送方发送多个分组而无需等待确认必须增大序号范围协议的发送方和接收方必须对分组进行缓存两种流水线协议:回退N步(go-Back-N)和选择重传(selectiverepeat)2025/12/2249流水线:提高利用率发送方接收方RTT

利用率提高3倍!首个分组的第1个比特被传输,t=0首个分组的最后1比特被传输,

t=L/RACK到达,发送下一个分组,t=RTT+L/R首个分组的第1个比特到达首个分组的最后1个比特到达,发送ACK第2个分组的最后1个比特到达,发送ACK第3个分组的最后1个比特到达,发送ACK2025/12/2250Go-Back-N发送方:分组首部用k-比特字段表示序号已被传输但还未确认的分组的许可序号范围可以看作是一个在序号范围内大小为N的“窗口(window)”2025/12/2251Go-Back-N(续)ACK(n):对序号n之前包括n在内的所有分组进行确认

-“累积ACK”为每一个已发送但未确认的分组设置定时器超时(n):

重传分组n和窗口中所有序号大于n的分组2025/12/2252GBN:发送方的扩展FSM等待start_timerudt_send(sndpkt[base])udt_send(sndpkt[base+1])…udt_send(sndpkt[nextseqnum-1])timeoutrdt_send(data)

if(nextseqnum<base+N){

sndpkt[nextseqnum]=make_pkt(nextseqnum,data,chksum)

udt_send(sndpkt[nextseqnum])if(base==nextseqnum)

start_timer

nextseqnum++}else

refuse_data(data)base=getacknum(rcvpkt)+1If(base==nextseqnum)

stop_timerelse

start_timerrdt_rcv(rcvpkt)&&

notcorrupt(rcvpkt)base=1nextseqnum=1rdt_rcv(rcvpkt)&&corrupt(rcvpkt)

L2025/12/2253GBN:接收方的扩展FSMACK-only:只对正确按序到达的分组中最高的序号发送ACK可能会产生重复的ACK只需要记住期待序号

expectedseqnum失序分组:丢弃(不缓存)->接收方无缓存!重发按序到达的最高序号分组的ACK等待udt_send(sndpkt)defaultrdt_rcv(rcvpkt)&¬currupt(rcvpkt)&&hasseqnum(rcvpkt,expectedseqnum)extract(rcvpkt,data)deliver_data(data)sndpkt=make_pkt(expectedseqnum,ACK,chksum)udt_send(sndpkt)expectedseqnum++expectedseqnum=1sndpkt=

make_pkt(expectedseqnum,ACK,chksum)L2025/12/2254GBN

时序图2025/12/2255选择重传接收方逐个对所有正确收到的分组进行确认如有必要，对接收到的（失序）分组进行缓存,以便最后对上层进行有序递交发送方只重发没有收到ACK的那些分组发送方为每一个没有收到ACK的分组设置定时器发送窗口大小为N限制已发送但未被确认的分组数2025/12/2256选择重传:发送方和接收方的窗口发送基序号下一个序号窗口长度N已被确认发送，还未确认可用，还未发送不可用不可用失序(已缓存)但未被确认可接收(窗口内)期待，还未收到窗口长度N接收基序号(a)发送方看到的序号(b)接收方看到的序号2025/12/2257选择重传从上层收到数据:如果下一个可用于该分组的序号在窗口内，则将数据打包并发送超时(n):重传分组n,重置定时器收到确认(n)在

[sendbase,sendbase+N]范围内标记分组n为已接收如果n是发送窗口基序号sendbase，则将窗口基序号前推到下一个未确认序号发送方2025/12/2258选择重传分组序号n在[rcvbase,rcvbase+N-1]范围内发送n的确认ACK(n)如果分组序号不连续(失序)：将其缓存按序分组:将该分组以及以前缓存的序号连续的分组一起交付给上层,将窗口前推到下一个未收到的分组分组序号n在[rcvbase-N,rcvbase-1]范围内：虽然曾经确认过，仍再次发送n的确认ACK(n)其他情况:忽略该分组接收方2025/12/2259选择重传时序图0123456789分组0发送0123456789分组1发送0123456789分组2发送0123456789分组3发送，窗口满1234056789ACK0收到，分组4发送1234056789分组0收到，交付，ACK0发送2345016789ACK1收到，分组5发送2345016789分组2超时，重发分组2

2345016789ACK3收到，无分组可发2345016789分组1收到，交付，ACK1发送

2345016789分组3收到，缓存，ACK3发送

2345016789分组4收到，缓存，ACK4发送2345016789分组5收到，缓存，ACK5发送6789012345分组2收到，分组2、3、4、5交付，ACK2发送×丢失2025/12/2260选择重传的问题:例如:分组序号范围为4个序号:0,1,2,3窗口长度=3两种情况对接收方来说没有差别。图(a)中接收方本要接收新的序号为0的分组，但收到的是重复的上一个分组0Q:

序号范围长度与窗口长度有何关系?012301201230120123012012301201230120123012分组0分组1分组2×××0123012超时重传分组0分组0接收具有序号0的分组ACK0ACK1ACK2（a）发送方窗口接收方窗口012301201230120123012012301201230120123012分组0分组1分组2×0123012分组0接收具有序号0的分组ACK0ACK1ACK2（b）发送方窗口接收方窗口0123012分组32025/12/2261目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的传输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/2262TCP:概述

RFCs:793,1122,1323,2018,2581全双工:一条连接上有双向数据传输MSS:(maximumsegmentsize)最大报文段长面向连接:

握手(交换控制信息)过程在数据交换之前初始化发送方和接收方的状态流量控制:使得发送方不会使接收方的缓存溢出点对点:单个发送方与单个接收方之间的连接可靠的按序字节流:没有“报文边界”流水线:TCP有拥塞控制，可以利用窗口进行流量控制发送和接收缓存2025/12/2263TCP的发送和接收缓存

端口…发送

TCP

报文段TCP…TCP接收缓存发送缓存报文段…报文段报文段端口发送端接收端向发送缓存写入数据块从接收缓存读取数据块应用进程应用进程

2025/12/2264TCP首部20字节的固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FIN32bitSYNRSTPSHACKURG比特08162431填充TCP

数据部分TCP首部TCP报文段IP数据部分IP首部发送在前TCP报文段结构2025/12/2265TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充源端口和目的端口字段——各占2字节。端口是运输层与应用层的服务接口。运输层的复用和分用功能都要通过端口才能实现。2025/12/2266TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充序号字段——占4字节。TCP连接中传送的数据流中的每一个字节都编上一个序号。序号字段的值则指的是本报文段所发送的数据的第一个字节在整个报文字节流中的序号。2025/12/2267TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充确认号字段——占4字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。2025/12/2268TCP序列号和确认序列号Q:

接收方如何处理非按序到达的报文段？A:TCPRFC未明确规定，由实现者自己去处理主机A主机BSeq=42,ACK=79,data=‘C’Seq=79,ACK=43,data=‘C’Seq=43,ACK=80用户键入‘C’主机确认收到回显的‘C’主机确认收到’C’,回显’C’时间简单的Telnet例子2025/12/2269TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充数据偏移——占4bit，它指出TCP报文段的数据起始处距离TCP报文段的起始处有多远。“数据偏移”的单位不是字节而是32bit字（4字节为计算单位）。2025/12/2270TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充保留字段——占6bit，保留为今后使用，但目前应置为0。2025/12/2271TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充紧急比特URG——当URG

1时，表明紧急指针字段有效。它告诉系统此报文段中有紧急数据，应尽快传送。（一般不使用）2025/12/2272TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充确认比特ACK——只有当ACK

1时确认号字段才有效。当ACK

0时，确认号无效。2025/12/2273TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充推送比特PSH(PuSH)——接收TCP收到推送比特置1的报文段，就尽快地交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。2025/12/2274TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充复位比特RST(ReSeT)——当RST

1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须释放连接，然后再重新建立运输连接。2025/12/2275TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充同步比特SYN——同步比特SYN置为1，就表示这是一个连接请求或连接接受报文。2025/12/2276TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充终止比特FIN(FINal)——用来释放一个连接。当FIN

1时，表明此报文段的发送端的数据已发送完毕，并要求释放运输连接。2025/12/2277TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充窗口字段——占2字节。窗口字段用来控制对方发送的数据量，单位为字节。TCP连接的一端根据设置的缓存空间大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。2025/12/2278TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充检验和——占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。2025/12/2279TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充紧急指针字段——占16bit。紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。

2025/12/2280TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充选项字段——长度可变。TCP只规定了一种选项，即最大报文段长度

MSS(MaximumSegmentSize)。MSS告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。”MSS是TCP报文段中的数据字段的最大长度。数据字段加上TCP首部才等于整个的TCP报文段。2025/12/2281TCP首部20字节固定首部目的端口数据偏移检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特08162431填充填充字段——这是为了使整个首部长度是4字节的整数倍。2025/12/2282TCP往返时延(RTT)与超时Q:

如何设置TCP的超时?应该大于RTT但RTT是变化的太短:造成不必要的重传太长:对丢包反应太慢Q:

如何估算RTT?样本RTT(SampleRTT):对报文段被发出到收到该报文段的确认之间的时间进行测量忽略重传样本RTT会有波动，要使得估算RTT更平滑将最近几次的测量进行平均，而非仅仅采用最近一次的SampleRTT2025/12/2283TCP往返时延(RTT)与超时EstimatedRTT=(1-

)*EstimatedRTT+

*SampleRTT指数加权移动平均(Exponentialweightedmovingaverage,EWMA)参考值:=0.1252025/12/2284估计RTT的例子:2025/12/2285TCP往返时延(RTT)与超时设置超时EstimtedRTT

加上“安全系数”EstimatedRTT波动较大

->

加大安全系数首先估计SampleRTT与EstimatedRTT偏差:TimeoutInterval=EstimatedRTT+4*DevRTTDevRTT=(1-

)*DevRTT+

*|SampleRTT-EstimatedRTT|(参考值,=0.25)然后设置超时间隔:2025/12/2286目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的传输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/2287TCP可靠数据传输TCP在IP的不可靠服务基础上提供可靠数据传输服务数据流累积确认TCP使用简单的重传定时器重传由以下情况触发:超时重复的ACK先考虑TCP发送方的简化描述:忽略重复的ACK忽略流量控制和拥塞控制2025/12/2288TCP发送方事件:从应用程序接收数据将数据封装入报文段中，每个报文段都包含一个序号序号是该报文段第一个数据字节的字节流编号启动定时器超时间隔:TimeOutInterval

超时:重传认为超时的报文段重启定时器收到Ack:如果是对以前的未确认报文段的确认更新SendBase如果当前有未被确认的报文段，TCP还要重启定时器2025/12/2289TCP

发送方

(简化情况)

NextSeqNum=InitialSeqNum

SendBase=InitialSeqNum

loop(forever){

switch(event)

event:datareceivedfromapplicationabovecreateTCPsegmentwithsequencenumberNextSeqNum

if(timercurrentlynotrunning)starttimerpasssegmenttoIP

NextSeqNum=NextSeqNum+length(data)

event:timertimeoutretransmitnot-yet-acknowledgedsegmentwithsmallestsequencenumberstarttimer

event:ACKreceived,withACKfieldvalueofyif(y>SendBase){

SendBase=yif(therearecurrentlynot-yet-acknowledgedsegments)starttimer}

}/*endofloopforever*/

注释:SendBase-1:最后一个确认的字节例子:SendBase-1=71;

y=73,接收方期待73以后的字节;

y>SendBase,确认新的数据2025/12/2290TCP:重传情况主机ASeq=92,8字节数据ACK=100丢失超时由于ACK丢失而重传主机BXSeq=92,8字节数据ACK=100时间SendBase=100主机ASeq=100,20字节数据ACK=100时间由于超时过短而重传主机BSeq=92,8字节数据ACK=120Seq=92,8字节数据Seq=92超时ACK=120Seq=92超时SendBase=120SendBase=120Sendbase=1002025/12/2291TCP重传情况(续)主机ASeq=92,8字节数据ACK=100丢失超时累积确认避免了第一个报文的重传主机BXSeq=100,20字节数据ACK=120时间SendBase=1202025/12/2292产生TCPACK的建议

[RFC1122,RFC2581]接收方事件所期望序号的报文段按序到达。所有在期望序号及其以前的数据都已经被确认有期望序号的报文段按序到达。另一个按序报文段等待发送ACK比期望序号大的失序报文段到达，检测出数据流中的间隔能部分或完全填充接收数据间隔的报文段到达TCP接收方动作延迟的ACK。对另一个按序报文段的到达最多等待500ms。如果下一个按序报文段在这个时间间隔内没有到达，则发送一个ACK立即发送单个累积ACK，以确认两个按序报文段立即发送冗余ACK，指明下一个期待字节的序号(也就是间隔的低端字节序号)倘若该报文段起始于间隔的低端，则立即发送ACK2025/12/2293快速重传超时周期往往太长:增加重发丢失分组的延时通过重复的ACK检测丢失报文段.发送方常要连续发送大量报文段如果一个报文段丢失，会引起很多连续的重复ACK.如果发送收到一个数据的3个ACK，它会认为确认数据之后的报文段丢失:快速重传:

在超时到来之前重传报文段2025/12/2294

event:ACKreceived,withACKfieldvalueofyif(y>SendBase){

SendBase=yif(therearecurrentlynot-yet-acknowledgedsegments)starttimer}else{incrementcountofdupACKsreceivedforyif(countofdupACKsreceivedfory=3){resendsegmentwithsequencenumbery}

快速重传算法:重复的ACK报文快速重传2025/12/2295目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的运输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/2296TCP流量控制TCP连接的接收方有一个接收缓存:速度匹配服务:匹配发送方的发送速率与接收方应用进程的读取速率应用进程从缓冲区中读取数据可能很慢发送方不会由于传得太多太快而使得接收方缓存溢出流量控制空闲空间缓存中的TCP数据RcvWindow来自IP的数据应用进程RcvBufferRcvBuffer

=接收端的TCP缓存大小RcvWindow=缓存中空闲的部分2025/12/2297TCP流量控制:如何工作？(假设TCP接收方将失序到达的报文段丢弃掉)缓存中的空闲空间=RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead]接收方把RcvWindow的值放在报文段的接收窗口字段中来通知发送方它缓存中的空闲空间发送方将未被确认的数据量限制在RcvWindow允许范围内保证接收方缓存不会溢出空闲空间缓存中的TCP数据RcvWindow来自IP的数据应用进程RcvBuffer2025/12/2298目录3.1运输层服务3.2复用和分用3.3无连接传输:UDP3.4可靠数据传输的原理3.5面向连接的运输:TCP报文段结构可靠数据传输流量控制连接管理3.6拥塞控制原理3.7TCP拥塞控制2025/12/2299TCP连接管理回顾:

TCP的发送方和接收方在互发数据之前要先建立“连接”初始化:序号缓存，流量控制信息(如

RcvWindow)客户端:

连接发起者SocketclientSocket=newSocket("hostname","portnumber");

服务器端:

接收连接者SocketconnectionSocket=