理解可靠传输协议的设计理念掌握Tcp协议的强大功课件

---理解可靠传输协议的设计理念---掌握Tcp协议的强大功能传输层江西师范大学计算机学院万宇文1课程索引传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节2学习内容传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节3传输层的概念传输层负责端(主机)到端(主机)之间的数据传输控制传输层依赖于网络层的服务，对应用层提供传输服务应用层传输层网络层链路层物理层应用层传输层网络层链路层物理层4传输层与网络层的关系网络层为主机之间数据如何经过路由器选路到达对方提供服务传输层加强了网络层的服务，在数据能到达对方的前提下，为数据的传输进行控制，为进程间进行通信提供服务5因特网传输层提供的服务不可靠的(“尽力而为”),无序的传输(UDP)可靠(正确、按序)的端到端传输(TCP)面向连接的服务流量控制拥塞控制因特网上不能提供的服务:实时性带宽承诺可靠的广播通信6应用层传输层网络层M主机2接收方HtHnsegmentM主机1MMM进程3进程4应用层传输层网络层应用层传输层网络层传输层的分用和复用分用：接收方传输层根据端口号分用到不通的应用层进程复用：发送方不同的应用层进程根据不同端口号复用到同一传输层中段传输层首部应用层的数据传输层根据目的端口分用到不同应用进程7套接字的回顾源IP:C目标IP:B源端口:x目标端口:80源IP:C目标IP:B源端口:y目标端口:80源IP:A目标IP:B源端口:x目标端口:80Web客户端主机AWeb服务器BWeb客户端主机C客户端A向服务器B端请求网页源端口随机从可用端口取，目标端口为80C打开两个浏览器，向B发送两个网页请求8学习内容传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节9UDP协议概述“最简单的”Internet传输协议提供不可靠的数据传输，又称“尽力而为的”的服务,其本质是宁缺勿滥，尽力传输UDP协议允许:数据丢失应用数据乱序到达无连接的协议在UDP收发双方之间,无需握手建立连接每个UDP数据段的操作都互相独立10UDP协议的首部源端口目的端口长度校验和数据首部IP数据报数据首部UDP用户数据报源端口和目标端口定义发送方和接收方的通信进程长度字段定义UDP数据报的总长度(包括首部和数据)校验和用于数据传输的差错检查，UDP协议宁缺勿滥11UDP校验和查错机制注意：UDP查错的数据包括IP首部的12字节，称为伪首部，作为网络层数据的冗余检查，求和是按二进制反码运算求和8字节UDP首部153.19.8.104171.3.14.1112字节伪首部7字节数据填充全0171510871315全0数据数据数据数据数据数据数据全0校验和是网络通信的查错方式之一，广泛应用于传输层和网络层，发送方将需检验的数据按照一定的大小求和，得到的和取反得到为校验码12学习内容传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节13可靠传输协议概述可靠传输协议保证数据能够正确、按序的到达对方可靠传输协议可以用于数据链路层、网络层、传输层和应用层可靠传输协议属于网络前10位的重要课题讨论：如果物理信道100%可靠，还需要可靠传输协议吗？14停止等待协议SW(stopandwait)停止等待协议,发送方每发送一个报文，必须收到对方的回复后才能发送发送下一个报文SW协议类似于非流水线作业方式可靠传输协议的讨论从SW协议开始15可靠协议开始起步rdt_send():

可靠的数据传输处理函数，处理完将数据交给下层udt_send():不可靠的数据传输处理函数，将分组通过不可靠的信道传到接收方rdt_rcv():可靠的数据接收处理函数，deliver_data():向上层递交数据，由rdt调用16rdt1.0信道完全可靠前提：信道完全可靠数据不会出错数据不会乱序到达，也不会丢失可靠协议本身无需做额外的处理17rdt2.0信道可能出错前提：信道可能在分组数据中出现位错，但不会丢失讨论：需要解决的问题，如何查错，如何从错误中恢复从错误中恢复的办法：纠错机制(代价太大)使用确认(ACKs)和否认(NAKs)机制:

当接收方正确收到分组，则向发送方发送确认信息，否则发送否认信息，当收到NAK时，发送方重传数据(发送方缓存数据，提高效率)18rdt2.0的运行(无错的情况)发送方FSM接收方FSM19rdt2.0运行(出错的情况)发送方FSM接收方FSM20rdt2.0存在的设计缺陷ACK/NAK报文出错?发送方将不会知道接收端发生了什么!ACK/NAK本身必须增加查错机制讨论：当发送方发现ACK/NAK出错怎么办?对ACK/NAK本身再发送ACK/NAK(不可行)直接重传分组接收方可能收到重复分组重复分组的问题(接收方收到一个分组无法分清该分组是重传的分组还是新的分组):21rdt2.1:信道出错的可靠协议改进发送方给每个分组加上序号(sequencenumber)接收方丢弃重复分组,并再次对分组确认讨论：序号需要多少个？不用NAK,只用ACK是否可行，如何处理rdt2.1:只使用ACK,分组采用0/1循环编号，接收方根据序号确定是否是重复分组22rdt2.1演示发送方接收方100101Ack0正确收到，发0号分组确认，期待1号分组发送0号分组正确收到0号分组确认，发送1号分组Ack01号分组出错，发0号分组确认1重发1号分组Ack1正确收到，发1号分组确认11号确认出错，重发1号分组Ack1正确收到，判断是重复分组，发1号分组确认正确收到1号分组确认，发下一个0号分组23rdt3.0数据可能出错和丢失讨论：谁通过何种方式发现数据丢失?发现数据丢失后如何处理？发送方通过“超时”时间发现数据丢失.对发送的分组定义一个超时时间(定时器)，若在超时时间里没有收到ACK，则重传该分组注意:数据超时并非一定丢失了如果分组(或ACK)仅仅被延迟了(没有丢失)将导致重复分组,但使用序号机制可以控制思考:超时时间如何确定,固定的还是变化的?24rdt3.0演示1发送方接收方发送0号分组收到ACK0,发送分组1收到分组0,发送ACK0收到分组1,发送ACK1超时，重传分组1收到ACK1,发送分组0收到分组0,发送ACK0pkt0ACK0分组1丢失pkt1×发送方接收方收到分组0,发送ACK0发送0号分组pkt0收到分组0,发送ACK0ACK0收到ACK0,发送分组1pkt1数据丢失情况确认丢失情况ACK1丢失×收到分组1,发送ACK1ACK1pkt1ACK1收到重复分组1,发送ACK1ACK1超时，重传分组1pkt1pkt0收到ACK1,发送分组0pkt025rdt3.0演示2发送方接收方数据超时未丢失情况pkt0发送0号分组pkt1收到ACK0,发送分组1ACK0收到分组0,发送ACK0ACK1收到分组1,重复分组，发送ACK1pkt1超时，重传分组1pkt0收到ACK1,发送分组0ACK0收到分组0,发送ACK0ACK1收到分组1,发送ACK1pkt0收到ACK1,重传分组0收到ACK0,发送分组1收到分组0,重复分组，发送ACK026停止等待协议(rdt3.0)讨论停等协议能否达到可靠传输的目的停等协议一定能100%正常工作吗？停止等待存在的性能问题例:1Gb/s链路,RTT=30ms,传播1KB分组Ttransmit=8kb109b/sec=8us利用率=U==8us(30000+8)us

传输延迟实际的等待的时间=0.00027网络协议限制了物理资源的利用!27滑动窗口协议的讨论发送方在没有收到对方的ACK的时候可以发送多个数据包，类似于流水线作业方式发送方使用发送窗口限制没收到确认时允许发送的数据量序号的个数必须增加发送方和接收方需要增加缓存常见的两种滑动窗口协议:GBN(回退N步)和SR(选择性重传)28GBN的工作方式发送方：窗口不满则发送至窗口满，窗口满则等待，收到确认窗口向后移动，某个分组出错或丢失则重传该分组及其后面所有已发送但未被确认的分组接收方：对按序正确到达的分组确认，乱序或错误的分组丢弃且发送最后一次正确收到的分组的确认累积确认:发送方收到某个分组的确认意味着该分组及之前所有分组接收方都正确收到29GBN的演示发送窗口为4发送方接收方pkt0发送0号分组pkt1发送1号分组pkt2ACK2收到分组2,发送ACK2ACK1收到分组1,发送ACK1pkt3发送2号分组分组丢失pkt2×pkt4收到ACK0,窗口后移，发送分组4收到分组0,发送ACK0ACK0发送3号分组,窗口满pkt3pkt4pkt5分组2超时，重传分组2及分组3,4,5收到ACK1,发送分组5pkt5收到分组4,乱序丢弃，发送ACK1收到分组3,乱序丢弃，重发ACK1收到分组5,乱序丢弃，发送ACK1ACK1ACK1ACK1收到ACK2,发送分组630SR的工作方式讨论：GBN存在的不足及改进的方法？SR：选择性重传发送方某个分组出错或丢失只重传该分组。接收方增加接收窗口(接收缓存)，若收到的分组在接收窗口内且乱序，缓存该分组，等到分组按序后一起提交,接收窗口的大小一般等于发送方发送窗口的大小31SR的演示发送窗口为4发送方接收方01234560120123456012pkt00123456012pkt40123456012pkt5pkt10123456012pkt2分组丢失×0123456012pkt301234560120123456012ACK00123456012ACK1分组2超时.重传分组20123456012pkt2012345601201234560120123456012ACK3ACK4ACK50123456012ACK20123456012乱序在窗口内，缓存并确认32窗口大小和序号的关系GBN窗口的最大值等于序号的个数-1SR窗口的最大值等于序号的一半若SR窗口为3，序号为4，上述情况接收方无法判断收到的序号为0的分组是重传的0号分组还是新发送的0号分组。33本节小结可靠传输协议的总结查错机制序号机制确认机制超时重传机制缓存机制滑动窗口机制定时器机制34学习内容传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节35TCP协议TCP协议的设计理念TCP协议首部TCP协议的连接机制TCP协议的流量控制TCP协议的拥塞控制36TCP的设计理念TCP属于传输层，实现面向连接的可靠的传输可靠的传输不能保证传输一定到达对方，但是能保证如果数据到达对方，一定按序正确TCP使用了可靠的设计理念序号机制、确认机制、缓存机制、重传机制、滑动窗口机制TCP包含流量控制和拥塞控制机制注意：不同操作系统的TCP协议具体实现细节有所不同，但设计基本满足RFC793,RFC258137TCP协议首部TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充38TCP的首部细节1TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充源端口和目的端口字段——各占2字节。端口是传输层与应用层的服务接口,类似一个地址标识。传输层的复用和分用功能都要通过端口才能实现。39TCP的首部细节2TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充序号字段——占4字节。TCP连接中传送的数据流中的每一个字节都编上一个号。序号字段的值指的是本报文段所发送的数据的第一个字节的编号40TCP的首部细节3TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充确认号字段——占4字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。注意：当有数据要发送给对方时，顺便确认，当没有数据发给对方时，单独发一个确认报文。41TCP的首部细节4TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充首部长度——占4bit，它作为一个二进制数字，表示TCP报文段的首部包含的总的字节数(即20个固定首部长度加不固定的可选首部长度)，计算单位按照4个字节为单位，如1100表示首部为12*4=48字节。该字段限制了TCP的首部最大值为60字节保留字段——占6bit，保留为今后协议的扩展使用，目前置为0。42TCP的首部细节4TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充特殊标记(Flag),每个标记占一个bit.有特殊约定。URG——紧急比特标记，当URG置为1时，表明紧急指针字段有效。通知本报文段中有紧急数据，应尽快传送,紧急数据的优先级要高。ACK——只有当ACK置为1时，确认号字段才有效。正常情况下只有第一次握手时ACK=043TCP的首部细节5TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充PSH(PuSH)——推送比特，接收方收到推送比特置1的报文段，就尽快地将该报文段的数据交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。RST(ReSeT)——复位比特，当RST1时，表明TCP连接中出现严重差错（如由于主机崩溃或其他原因），必须强行释放连接,属于单方面强行断开连接。44TCP的首部细节6TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充SYN——同步比特,SYN置为1，表示这是一个连接请求报文。正常情况下只有第一次握手和第二次握手时SYN等于１,其余都等于0。FIN(Final)——终止比特,用来正常释放一个连接。当FIN1时，表明此报文段的发送端的数据已发送完毕，并请求对方释放连接，当对方确认后，会释放发送缓存。45TCP的首部细节7TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充窗口字段——占2字节。窗口字段是流量控制的关键，用来控制对方发送窗口的大小，单位为字节。接收方根据自身的缓存大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。检验和——占2字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP报文段的前面加上12字节的伪首部。46TCP的首部细节8TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充紧急指针字段——占16bit。紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。选项字段——长度可变。TCP只规定了一种选项，即最大报文段长度

MSS(MaximumSegmentSize)。MSS告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最大长度是MSS个字节。47TCP的首部细节9TCP首部20字节固定首部目的端口首部长度检验和选项（长度可变）源端口序号紧急指针窗口确认号保留FINSYNRSTPSHACKURG比特081624

31填充填充字段——这是为了使整个首部长度是4字节的整数倍。从而保证首部长度字段的有效性和计算检验和的有效性48TCP的数据编号与确认序号基于字节随机生成初始序号，之后每个字节都对应一个编号，序号是发送数据的第一个字节的编号确认号是期望对方发送的下一个数据的第一个字节的编号，即对方下一个报文段的序号TCP的确认属于累积确认,乱序到达的数据会缓存思考：TCP属于GBN还是SR49TCP的三次握手建立连接AB第一次握手：A随机初始化自己的序号SN(A),确认号为0,初始化A的接收窗口大小，SYN=1表示希望和B做朋友第二次握手：B随机初始化自己的序号SN(B),确认号为A第一次握手的序号加1,表示向A作确认,初始化B的接收窗口大小，SYN=1，表示希望和A做朋友第三次握手：A对B作确认，SYN=0,ACK=1,确认号为B第二次握手的序号加150TCP的三次握手示例发送SYN，请求建立连接(seq=100ctl=SYN)HostAHostB1发送SYN、ACK(seq=300ack＝101ctl=SYN、ACK)23发送ACK(seq=101ack＝301ctl=ACK)51TCP释放连接的过程异常释放ABRST=1ACK正常释放ABFIN=1ACK…FIN=1ACK52TCP四次断开示例发送FIN,请求断开连接(seq=101,ack=301,ctl=FIN，ACK)HostAHostB1发送ACK(seq=301,ack=102ctl=ACK)24发送ACK(seq=102,ack=302ctl=ACK)Seq＝91

10ByteSeq＝2965ByteAck＝1013发送FIN,请求断开连接(seq=301,ack=102ctl=FIN，ACK)53TCP状态图54TCP的重传机制原则：当数据超时则需要重传问题：超时时间如何规定、如何提高效率？可靠传输协议需要对分组设置超时时间，超时时间应当动态地随着网络的有效带宽和拥塞程度不断的变化网络的拥塞程度可以通过往返时延RTT来衡量TCP的超时时间计算公式EstimatedRTT=(1-x)*EstimatedRTT+x*SampleRTT(x=1/8)Timeout=EstimatedRTT+4*DeviationDeviation=(1-x)*Deviation+x*|SampleRTT-EstimatedRTT|Timeout=β*EstimatedRTT(β=2)－－某些TCP实现的方法55重传的进一步讨论Karn算法(背景：往返时间有时很难估计）对重传的数据不计算RTT,timeout=2*timeout;快速重传提高效率当连续收到三个重复的冗余确认则重传对方期望收到的分组56TCP的流量控制接收方:明确地通过TCP首部的窗口字段发送接收窗口大小，从而限制发送方发送窗口的最大值发送方:保证发送窗口大小不超过对方发送地接收窗口的大小思考：TCP的接收缓存是主机的所有TCP连接共享还是每个TCP连接独占？（需实验验证)57TCP流量控制示例HostAHostB123Seq=300,ack=101,win=3Seq=100,1ByteAck=104,win=1Seq=101,1B,win=3Seq=102,1B,win=3Seq=103,1B,win=3Seq=10403接收方的缓冲区0132发送窗口大小为3通报窗口大小为1缓冲区满应用程序读取了1个数据段实际发送窗口大小变为1通报窗口大小为3TCP流量控制的特殊情况1特殊场景：TCP连接的两端A和B,B接收缓存满，B此时无任何数据需要发送给A问题：当A发送数据给B时，B发送确认，其中接收窗口大小为0,B的缓存逐渐出现空间，但A无法获得这一信息,使得A无法发送任何数据给B解决办法：当收到接收窗口为0的报文，A继续发送一个字节的数据（一般响应一个持续定时器后在再发送）,获得B确认报文中最新的接收窗口大小59TCP流量控制的特殊情况2愚笨窗口综合症当接收端交互式应用每次读取一个字节数据时,或者发送端每次只发送一个字节数据，将会使得TCP的工作效率很低。解决办法：接收端如果接收缓存很小时，会等待一段时间(500ms)等缓存大到一定程度再发送接收窗口给发送端（Clark策略)，提高效率发送端如果发送的数据很小，第一次会照常发送，后面的会等待一定时间（500ms)等发送数据较大时再放入Tcp段中发送。(Nagle算法)60TCP的拥塞控制机制讨论：什么是拥塞？为什么需要拥塞控制？谁应该负责拥塞控制？路由器还是TCP的发送端和接收端？如何发现拥塞，发现拥塞后该如何处理？如何保证效率？61TCP的拥塞控制思想使用拥塞窗口cwnd控制发送窗口大小发送窗口的上限值

Min[rwnd,cwnd]分组超时意味着拥塞，分组收到确认则意味着网络未拥塞拥塞则少发(拥塞窗口减小)，没拥塞则多发(拥塞窗口增加)在网络未知的情况下拥塞窗口从最小开始，收到确认拥塞窗口大小增加为提高效率，开始窗口增加速度快，到了一定阶段窗口增加速度变慢62TCP的拥塞窗口举例246810121416182022004812162024传输次数拥塞窗口cwnd进入拥塞避免发生超时指数规律增长线性规律增长ssthresh=16慢启动慢启动拥塞避免拥塞避免更新后的ssthresh=12进入拥塞避免63快恢复算法当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限ssthresh减半,直接进入拥塞避免阶段242468101214161820220048121620传输轮次拥塞窗口cwnd收到3个重复的确认执行快重传算法慢开始“乘法减小”拥塞避免“加法增大”TCPReno版本TCPTahoe版本(已废弃不用）ssthresh的初始值拥塞避免“加法增大”新的ssthresh值慢开始快恢复64TCP拥塞控制总结两个阶段慢启动阶段－－－乘法增拥塞避免阶段－－加法增一个阈值定义了慢启动阶段和拥塞避免阶段的分界点超时发生时阈值变成超时的窗口大小的一半回到慢启动 思考：假设TCP的拥塞窗口被设置为18KB,并且出现了一个超时，如果接下来的四次传输都正确的话，则拥塞窗口将是多大？假设最大数据段长度为1KB。65TCP定时器retransmissiontimer（重传定时器）每个发送未被确认的分组都需要启动该定时器persistencetimer（持续定时