第03章 传输层服务与协议

《计算机网络与信息安全》第三章传输层服务与协议主要内容本章学习目标理解传输层服务掌握传输层复用/分解方法掌握UDP协议掌握TCP协议TCP协议特点TCP段结构TCP可靠数据传输TCP流量控制TCP连接控制TCP拥塞控制主要内容第一节

传输层服务第二节传输层多路复用与分解第三节停等协议与滑动窗口协议第四节UDP协议第五节TCP协议一、TCP段结构二、TCP连接管理三、TCP可靠数据传输四、TCP流量控制五、TCP拥塞控制2本章重点与难点本章重点可靠数据传输的基本原理停-等协议典型滑动窗口协议（GBN、SR协议）TCP的段结构TCP的连接建立与断开过程TCP序列号以及确认序列号TCP可靠数据传输的机制TCP流量控制TCP拥塞控制方法本章难点停-等协议与滑动窗口协议的理解停-等协议与滑动窗口协议信道利用率的计算TCP协议的连接管理TCP段序列号TCP协议的拥塞控制慢启动拥塞避免TCP发送窗口的变化3第一节

传输层服务李全龙传输层？3第一节

传输层服务物理层数据链路层网络层物理层数据链路层网络层传输层应用层物理层数据链路层网络层传输层应用层主机A主机B路由器传输介质传输介质协议协议协议协议协议协议协议物理层数据链路层交换机协议协议协议传输介质互联网互联网传输层？3第一节

传输层服务传输层服务和协议传输层协议为运行在不同Host上的进程提供了一种逻辑通信机制端系统运行传输层协议发送方：将应用递交的消息分成一个或多个的Segment，并向下传给网络层。接收方：将接收到的segment组装成消息，并向上交给应用层。传输层可以为应用提供多种协议Internet的TCPInternet的UDP3applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport第一节

传输层服务传输层vs.网络层网络层：提供主机之间的逻辑通信机制传输层：提供应用进程之间的逻辑通信机制位于网络层之上依赖于网络层服务对网络层服务进行（可能的）增强4家庭类比:12个孩子给12个孩子发信应用进程=孩子应用消息=信封里的信主机=房子传输层协议=李雷和韩梅梅网络层协议=邮政服务第一节

传输层服务Internet传输层协议可靠、按序的交付服务(TCP)拥塞控制流量控制连接建立不可靠的交付服务(UDP)基于“尽力而为(Best-effort)”的网络层，没有做（可靠性方面的）扩展两种服务均不保证延迟带宽4applicationtransportnetworkdatalinkphysicalapplicationtransportnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicalnetworkdatalinkphysicallogicalend-endtransport第一节

传输层服务第二节

传输层多路复用与分解李全龙为什么需要多路复用/分用？3第二节

传输层多路复用/分解NPP1P2P3N+1层N层PDU上层协议IDQ：为什么需要实现复用与分解？如何实现复用与分解？A：如果某层的一个协议/实体直接为上层的多个协议/实体提供服务，

则需要复用/分用复用与分解只在传输层进行吗？传输层多路复用/分用？3传输层如何实现复用与分解功能？可能通过其他方式实现复用与分解吗？第二节

传输层多路复用/分解传输层分用如何工作？主机接收到IP数据报(datagram)每个数据报携带源IP地址、目的IP地址。每个数据报携带一个传输层的段(Segment）。每个段携带源端口号和目的端口号主机收到Segment之后，传输层协议提取IP地址和端口号信息，将Segment导向相应的SocketTCP做更多处理13源端口号#目的端口号#32bits应用数据(message)其他头部信息TCP/UDP段格式第二节

传输层多路复用/分解传输层无连接分用创建Socket并绑定端口号UDP的Socket用二元组标识(目的IP地址，目的端口号)主机收到UDP段后检查段中的目的端口号将UDP段导向绑定在该端口号的Socket来自不同源IP地址和/或源端口号的IP数据包被导向同一个Socket14第二节

传输层多路复用/分解传输层无连接分用15第二节

传输层多路复用/分解传输层面向连接的分用TCP的Socket用四元组标识源IP地址源端口号目的IP地址目的端口号接收端利用所有的四个值将Segment导向正确的Socket16服务器可能同时支持多个TCPSocket每个Socket用自己的四元组标识Web服务器为每个客户端创建不同的Socket第二节

传输层多路复用/分解传输层面向连接的分用17第二节

传输层多路复用/分解第三节

停等协议与滑动窗口协议18李全龙可靠数据传输原理什么是可靠？不错、不丢、不乱、不多可靠数据传输协议可靠数据传输对应用层、传输层、链路层都很重要网络Top-10问题信道的不可靠特性决定了可靠数据传输的复杂性实现可靠数据传输的主要措施：差错检测确认（ACK/NAK）重传序号计时器19第三节

停等协议与滑动窗口

协议停-等协议发送方发送经过差错编码和编号的报文段，等待接收方的确认；接收方如果正确接收报文段，即差错检测无误、且序号正确，则接收报文段，并向发送方发送ACK，否则丢弃报文段，并向发送方发送NAK；发送方如果收到ACK，则继续发送后续报文段，否则重发刚刚发送的报文段。几个要点：关于差错检测，报文段和ACK或NAK数据包均需进行差错编码关于序列号，序列号字段只需要1位即可关于ACK和NAK，可以只使用ACK进行确认，只需在ACK数据包中带上所确认的报文段序列号关于ACK或NAK差错，“有错推断”原则20第三节

停等协议与滑动窗口

协议停-等协议典型交互场景21第三节

停等协议与滑动窗口

协议停等协议的信道利用率22

第三节

停等协议与滑动窗口

协议停-等协议性能分析停-等协议能够正确工作，但性能很差停-等协议信道利用率：

其中，是报文段的传输时延，是ACK报文段的传输时延，RTT是往返时间。例如：1Gbps链路，15ms端到端传播延迟，1KB分组，忽略ACK报文段大小，则发送方利用率：发送方发送时间百分比为0.027%在1Gbps链路上每30毫秒才发送一个分组33KB/sec网络协议限制了物理资源的利用23第三节

停等协议与滑动窗口

协议停等操作24发送数据包的第一个比特,t=0senderreceiverRTT

发送数据包的最后一个比特,t=L/R第一个比特到达最后一个比特到达，发送ACKACK到达，发送下一个包

t=RTT+L/R第三节

停等协议与滑动窗口

协议流水线机制：提高信道利用率25senderreceiverRTT利用率提高到3倍第三节

停等协议与滑动窗口

协议发送数据包的第一个比特,t=0发送数据包的最后一个比特,t=L/R第一个比特到达最后一个比特到达，发送ACKACK到达，发送下一个包

t=RTT+L/R流水线协议允许发送方在收到ACK之前连续发送多个分组更大的序列号范围发送方和/或接收方需要更大的存储空间以缓存分组典型的流水线可靠传输协议是滑动窗口协议窗口允许使用的序列号范围窗口尺寸为N：最多有N个等待确认的消息滑动窗口随着协议的运行，窗口在序列号空间内向前滑动滑动窗口协议：GBN,SR26第三节

停等协议与滑动窗口

协议滑动窗口协议27第三节

停等协议与滑动窗口

协议滑动窗口协议的信道利用率28

第三节

停等协议与滑动窗口

协议Go-Back-N(GBN)协议:发送方分组头部包含k-bit序列号窗口尺寸为Ws，最多允许Ws个分组未确认ACK(n):确认到序列号n(包含n)的分组均已被正确接收累积确认可能收到重复ACK为“空中”的分组设置计时器(timer)超时Timeout(n)事件:重传序列号大于等于n，还未收到ACK的所有分组29第三节

停等协议与滑动窗口

协议GBN:接收方30接收窗口WR=1ACK机制:发送拥有最高序列号的、已被正确接收的分组的ACK可能产生重复ACK只需要记住唯一的期望接收序号乱序到达的分组：直接丢弃

接收方没有缓存重新确认序列号最大的、按序到达的分组第三节

停等协议与滑动窗口

协议GBN示例31sendpkt0sendpkt1sendpkt2sendpkt3(wait)senderreceiverreceivepkt0,sendack0receivepkt1,sendack1

receivepkt3,discard,(re)sendack1sendpkt2sendpkt3sendpkt4sendpkt5Xlosspkt2timeoutreceivepkt4,discard,(re)sendack1receivepkt5,discard,(re)sendack1rcvpkt2,deliver,sendack2rcvpkt3,deliver,sendack3rcvpkt4,deliver,sendack4rcvpkt5,deliver,sendack5ignoreduplicateACKsenderwindow(Ws=4)012345678012345678012345678012345678rcvack0,sendpkt4012345678012345678012345678012345678012345678012345678rcvack1,sendpkt5第三节

停等协议与滑动窗口

协议例题32【例1】数据链路层采用后退N帧（GBN）协议，发送方已经发送了编号为0～7的帧。当计时器超时时，若发送方只收到0、2、3号帧的确认，则发送方需要重发的帧数是多少？分别是那几个帧？【解】根据GBN协议工作原理，GBN协议的确认是累积确认，所以此时发送端需要重发的帧数是4个，依次分别是4、5、6、7号帧。第三节

停等协议与滑动窗口

协议SelectiveRepeat（SR）协议GBN有什么缺陷？SR协议：接收方对每个分组单独进行确认设置缓存机制，缓存乱序到达的分组发送方只重传那些没收到ACK的分组为每个分组设置定时器发送方窗口N个连续的序列号限制已发送且未确认的分组数接收窗口可以接收的无差错到达的分组序号33第三节

停等协议与滑动窗口

协议SR协议：发送方/接收方窗口34第三节

停等协议与滑动窗口

协议SR协议-发送方35上层调用，请求发送数据:如果“下一可用序号”位于发送方窗口内，则将数据封装成SR分组，并用“下一可用序号”进行编号，发送分组；否则或者将数据缓存或者返回给上层以便以后传输。定时器超时，timeout(n):重发n号分组，并重启计时器收到ACK(n)，n在当前窗口范围内：标记n号分组已接收如果n是当前未被确认分组序号的最小序号，则滑动窗口到下一个最小未被确认分组序号发送方第三节

停等协议与滑动窗口

协议SR协议-接收方36接收到n号分组，n在当前接收窗口范围内：发送ACK(n)序号不连续：缓存序号连续：向上层提交数据（包括缓存中连续的分组），滑动窗口接收到n号分组，n在[当前窗口基序号-Ws，基序号-1]范围丢弃分组，发送ACK(n)其他事件：

忽略接收方思考：SR协议还可以有其他设计吗？第三节

停等协议与滑动窗口

协议SR协议示例37sendpkt0sendpkt1sendpkt2sendpkt3(wait)senderreceiversendpkt2(butnot3,4,5)Xlosspkt2timeoutsenderwindow(N=4)012345678012345678012345678012345678rcvack0,sendpkt4012345678012345678012345678012345678012345678012345678rcvack1,sendpkt5receivepkt0,sendack0receivepkt1,sendack1

receivepkt3,buffer,

sendack3recordack3arrivedreceivepkt4,buffer,sendack4receivepkt5,buffer,sendack5rcvpkt2;deliverpkt2,pkt3,pkt4,pkt5;sendack2Q:当ack2到达发送方会怎么样？第三节

停等协议与滑动窗口

协议SR协议：困境序列号:0,1,2,3窗口尺寸：3接收方能区分开右侧两种不同的场景吗？(a)中，发送方重发0号分组,接收方收到后会如何处理？38第三节

停等协议与滑动窗口

协议窗口大小与序号空间的约束条件？问题：序列号空间大小与窗口尺寸需满足什么关系？Ws发送窗口，Wr接收窗口，k序号位数对于GBN协议：Wr=1对于典型的Ws=Wr=W的SR协议对于停-等协议，即Ws=Wr=139

第三节

停等协议与滑动窗口

协议滑动窗口协议的窗口大小讨论：1.滑动窗口协议的窗口大小影响协议哪些性能？2.哪些因素会影响滑动窗口大小的确定？性能：信道利用率吞吐率……因素：序号空间缓存大小流量控制拥塞控制……40第三节

停等协议与滑动窗口

协议第四节UDP协议李全龙UDP:用户数据报协议[RFC768]基于InternetIP协议复用/分用简单的错误校验“Besteffort”服务，UDP段可能丢失非按序到达无连接UDP发送方和接收方之间不需要握手每个UDP段的处理独立于其他段3为什么需要UDP?无需建立连接

(减少延迟)实现简单：无需维护连接状态头部开销少没有拥塞控制:应用可更好地控制发送时间和速率第四节UDP协议UDP:用户数据报协议[RFC768]常用于流媒体应用容忍丢失速率敏感UDP还用于DNSSNMP在UDP上实现可靠数据传输？在应用层增加可靠性机制应用特定的错误恢复机制例如：停等协议、滑动窗口协议43源端口号目的端口号32bits应用数据

(报文/消息)UDP报文段格式长度校验和UDP段的长度（包含头部）第四节UDP协议UDP校验和(checksum)发送方将参与校验和计算的所有内容视为16-bit整数序列校验和计算：计算整数序列的和（sum）进位也要加在和的后面将和按位求反（即反码），得到校验和（checksum）发送方将校验和放入校验和字段44接收方针对收到的UDP报文段，按发送方同样的方法构建16位整数序列按相同算法计算整数序列的和（sum）若sum=1111111111111111，则无错；否则，有错目的：检测UDP段在传输中是否发生错误（如位翻转）第四节UDP协议UDP校验和(checksum)3部分:伪首部

（Pseudohead）UDP首部应用数据45UDP首部源IP地址(32)目的IP地址(32)0(8)协议/17(8)UDP总长度(16)伪首部应用数据填充/0(8)第四节UDP协议校验和计算示例示例：注意：最高位进位必须被加进去461111001100110011011101010101010101110111011101110111110111011101111001

0100010001000011sumchecksum回卷第四节UDP协议第五节TCP协议李全龙TCP概述点对点一个发送方，一个接收方可靠的、按序字节流流水线机制TCP拥塞控制和流量控制机制设置窗口尺寸发送方/接收方缓存48全双工(full-duplex)同一连接中能够传输双向数据流面向连接通信双方在发送数据之前必须建立连接。连接状态只在连接的两端中维护，在沿途节点中并不维护状态。TCP连接包括：两台主机上的缓存、连接状态变量、socket等流量控制机制拥塞控制第五节TCP协议TCP段结构源端口号与目的端口号字段分别占16位多路复用/分解49第五节TCP协议TCP段结构序号字段与确认序号字段分别占32位对每个应用层数据的每个字节进行编号确认序号是期望从对方接收数据的字节序号，累计确认50第五节TCP协议TCP段结构首部长度字段占4位4字节为计算单位51第五节TCP协议TCP段结构保留字段占6位目前值为052第五节TCP协议TCP段结构6位标志位（字段）URG=1时，表明紧急指针字段有效ACK=1时，标识确认序号字段有效PSH=1时，尽快将段中数据交付接

收应用进程53RST=1时，重新建立TCP连接SYN=1时，表示该TCP段是一个建立新连接请求控制段FIN=1时，表明请求释放TCP连接第五节TCP协议TCP段结构接收窗口字段占16位流量控制54第五节TCP协议TCP段结构校验和字段占16位包括TCP伪首部、TCP首部和应用层数据三部分55第五节TCP协议TCP段结构紧急指针字段占16位URG=1时才有效指出紧急数据最后一个字节在数据中的位置56第五节TCP协议TCP段结构选项字段的长度可变最大段长度MSS时间戳SACK57TCP段结构填充字段，长度为0~3个字节取值全058第五节TCP协议TCP连接管理TCPsender和receiver在传输数据前需要建立连接初始化TCP变量Seq.#Buffer和流量控制信息Client：连接发起者SocketclientSocket=newSocket("hostname","portnumber");

Server:等待客户连接请求SocketconnectionSocket=welcomeSocket.accept();59三次握手:Step1:

客户向服务器发送

SYN报文段确定初始序号不封装数据Step2:

服务器接收SYN段，

响应SYNACK报文段服务器分配缓存确定服务器初始序号Step3:

客户接收SYNACK，响应

ACK段，可以携带数据第五节TCP协议TCP连接管理：建立60第五节TCP协议TCP连接管理：断连过程61第五节TCP协议TCP连接管理62TCPclientlifecycleTCPserverlifecycle第五节TCP协议TCP:序列号和ACK63HostAHostBSeq=42,ACK=79,data=‘C’Seq=43,ACK=80Usertypes‘C’hostACKsreceiptofechoed‘C’Seq=79,ACK=43,data=‘C’简单telnettimetime序列号:序号是段（Segment）中第1个字节的编号，而不是段的“连续”编号建立TCP连接时，双方随机选择序列号ACKs:期望接收到的下一个字节的序列号累计确认：该序列号之前的所有字节均已被正确接收到Q:

接收方如何处理乱序到达的段？A:TCP规范中没有规定，由TCP的实现者做出决策第五节TCP协议TCP可靠数据传输概述TCP在IP层的不可靠服务基础上实现可靠数据传输服务流水线机制累积确认TCP使用单一重传定时器触发重传的事件超时收到重复ACK渐进式64第五节TCP协议TCPRTT和超时65问题：如何设置定时器的超时时间？大于RTT但是RTT是变化的过短：不必要的重传过长：对段丢失时间反应慢问题：如何估计RTT？SampleRTT:测量从段发出去到收到ACK的时间忽略重传SampleRTT变化测量多个SampleRTT，求平均值，形成RTT的估计值EstimatedRTTEstimatedRTT=(1-

)*EstimatedRTT+

*SampleRTT指数加权移动平均

典型值：0.125第五节TCP协议TCPRTT和超时66定时器超时时间的设置?EstimatedRTT+“安全边界”EstimatedRTT变化大

较大的边界测量RTT的变化值:SampleRTT与EstimatedRTT的差值定时器超时时间的设置：DevRTT=(1-

)*DevRTT+

*|SampleRTT-EstimatedRTT|(typically,

=0.25)TimeoutInterval=EstimatedRTT+4*DevRTT第五节TCP协议TCP发送方事件67从应用层收到数据创建Segment序列号是Segment第一个字节的编号开启计时器设置超时时间：TimeOutInterval超时重传引起超时的段重启定时器收到ACK如果确认此前未确认的段更新SendBase如果窗口中还有未被确认的分组，重新启动定时器第五节TCP协议TCP发送端程序68

NextSeqNum=InitialSeqNumSendBase=InitialSeqNum

loop(forever){

switch(event)

event:datareceivedfromapplicationabovecreateTCPsegmentwithsequencenumberNextSeqNumif(timercurrentlynotrunning)starttimerpasssegmenttoIPNextSeqNum=NextSeqNum+length(data)

event:timertimeoutretransmitnot-yet-acknowledgedsegmentwithsmallestsequencenumberstarttimer

event:ACKreceived,withACKfieldvalueofyif(y>SendBase){SendBase=yif(therearecurrentlynot-yet-acknowledgedsegments)starttimer}

}/*endofloopforever*/

第五节TCP协议TCP重传示例69第五节TCP协议TCP重传示例70第五节TCP协议TCPACK生成:RFC1122,RFC258171EventatReceiverArrivalofin-ordersegmentwithexpectedseq#.Alldatauptoexpectedseq#alreadyACKedArrivalofin-ordersegmentwithexpectedseq#.OneothersegmenthasACKpendingArrivalofout-of-ordersegmenthigher-than-expectseq.#.GapdetectedArrivalofsegmentthatpartiallyorcompletelyfillsgapTCPReceiveractionDelayedACK.Waitupto500msfornextsegment.Ifnonextsegment,sendACKImmediatelysendsinglecumulativeACK,ACKingbothin-ordersegmentsImmediatelysendduplicateACK,indicatingseq.#ofnextexpectedbyteImmediatesendACK,providedthatsegmentstartsatlowerendofgap第五节TCP协议快速重传机制TCP的实现中，如果发生超时，超时时间间隔将重新设置，即将超时时间间隔加倍，导致其很大重发丢失的分组之前要等待很长时间通过重复ACK检测分组丢失Sender会背靠背地发送多个分组如果某个分组丢失，可能会引发多个重复的ACK72如果sender收到对同一数据的3个ACK，则假定该数据之后的段已经丢失快速重传：在定时器超时之前即进行重传第五节TCP协议快速重传算法73

event:ACKreceived,withACKfieldvalueofyif(y>SendBase){SendBase=yif(therearecurrentlynot-yet-acknowledgedsegments)starttimer}else{incrementcountofdupACKsreceivedforyif(countofdupACKsreceivedfory=3){resendsegmentwithsequencenumbery}

aduplicateACKforalreadyACKedsegmentfastretransmit第五节TCP协议快速重传示例74第五节TCP协议TCP流量控制75接收方为TCP连接分配buffer速度匹配机制上层应用可能处理buffer中数据的速度较慢发送方不会传输的太多、太快以至于淹没接收方（buffer溢出）flowcontrol第五节TCP协议TCP流量控制76(假定TCPreceiver丢弃乱序的segments)Buffer中的可用空间(spareroom)=RcvWindow=RcvBuffer-[LastByteRcvd-LastByteRead]Receiver通过在Segment的头部字段将RcvWindow

告诉SenderSender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RcvWindow尺寸Receiver告知SenderRcvWindow=0,会出现什么情况？第五节TCP协议拥塞控制拥塞(Congestion)非正式定义：“太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理”表现：分组丢失（路由器缓存溢出）分组延迟过大（在路由器缓存中排队）发生拥塞的主要原因：缓冲区容量有限。传输线路的带宽有限。网络结点的处理能力有限。网络中某些部分发生了故障。拥塞控制vs.流量控制top-10问题77第五节TCP协议拥塞的后果78拥塞的代价:

时延显著增加吞吐量快速下降分组被丢弃传输能力被浪费第五节TCP协议拥塞控制的方法传输层端到端拥塞控制：网络层不需要显式的提供支持端系统通过观察loss，delay等网络行为判断是否发生拥塞TCP采取这种方法网络层（辅助）拥塞控制：路由器向发送方显式地反馈网络拥塞信息简单的拥塞指示(1bit)：SNA,DECbit,TCP/IPECN,ATM)指示发送方应该采取何种速率79第五节TCP协议TCP拥塞控制的基本原理80Sender限制发送速率LastByteSent-LastByteAcked

<=CongWinCongWin:动态调整以改变发送速率反映所感知到的网络拥塞问题：如何感知网络拥塞？Loss事件=timeout或3个重复ACK发生loss事件后，发送方降低速率如何合理地调整发送速率？加性增—乘性减:AIMD慢启动:SSrate≈CongWin

RTT

Bytes/sec第五节TCP协议加性增—乘性减:AIMD原理：逐渐增加发送速率，谨慎探测可用带宽，直到发生丢包方法:AIMDAdditiveIncrease:每个RTT将CongWin增大1个MSS-拥塞避免MultiplicativeDecrease:发生丢包后将CongWin减半81timecongestionwindowsize锯齿行为:探测可用带宽第五节TCP协议TCP慢启动:SSTCP连接建立时，CongWin=1例：MSS=500byte,RTT=200msec初始速率=20kbps可用带宽可能远远高于初始速率：希望快速增长原理：当连接开始时，指数性增长82initialize:Congwin=1for(eachsegmentACKed)Congwin++until(losseventORCongWin>threshold)Slowstartalgorithm第五节TCP协议TCP慢启动:SS指数性增长每个RTT将CongWin翻倍收到每个ACK进行CongWin++操作初始速率很慢，但是快速攀升83HostAonesegmentRTTHostBtimetwosegmentsfoursegments第五节TCP协议TCP慢启动:SS84第五节TCP协议Threshold变量85Q:何时应该指数性增长切换为线性增长(拥塞避免)?A:

当CongWin达到Loss事件前值的1/2时.

实现方法:变量

Threshold

Loss事件发生时,Threshold被设为Loss事件前CongWin值的1/2。第五节TCP协议Loss事件的处理863个重复ACKs:CongWin切换到一半然后线性增长Timeout事件:CongWin直接设为1个MSS然后指数增长达到threshold后,再线性增长

3个重复ACKs表示网络还能够传输一些segmentstimeout事件表明拥塞更为严重Philosophy:第五节TCP协议TCP拥塞控制:总结WhenCongWinisbelowThreshold,senderinslow-startphase,windowgrowsexponentially.WhenCongWinisaboveThreshold,senderisincongestion-avoidancephase,windowgrowslinearly.WhenatripleduplicateACKoccurs,ThresholdsettoCongWin/2andCongWinsettoThreshold.Whentimeoutoccurs,ThresholdsettoCongWin/2andCongWinissetto1MSS.

87第五节TCP协议TCP拥塞控制88StateEventTCPSenderActionCommentarySlowStart(SS)ACKreceiptforpreviouslyunackeddataCongWin=CongWin+MSS,If(CongWin>Threshold)setstateto“CongestionAvoidance”ResultinginadoublingofCongWineveryRTTCongestionAvoidance(CA)ACKreceiptforpreviouslyunackeddataCongWin=CongWin+MSS*(MSS/CongWin)

Additiveincrease,resultinginincreaseofCongWinby1MSSeveryRTTSSorCALosseventdetectedbytripleduplicateACKThreshold=CongWin/2,CongWin=Threshold,Setstateto“CongestionAvoidance”Fastrecovery,implementingmultiplicativedecrease.CongWinwillnotdropbelow1MSS.SSorCATimeoutThreshold=CongWin/2,CongWin=1MSS,Setstateto“SlowStart”EnterslowstartSSorCADuplicateACKIncrementduplicat