《理解可靠传输协议的设计理念-掌握Tcp协议的强大功能.ppt》由会员分享，可在线阅读，更多相关《理解可靠传输协议的设计理念-掌握Tcp协议的强大功能.ppt（75页珍藏版）》请在三一办公上搜索。
1、-理解可靠传输协议的设计理念-掌握Tcp协议的强大功能,传输层,江西师范大学计算机学院万宇文,1,课程索引,传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节,2,学习内容,传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节,3,传输层的概念,传输层负责端(主机)到端(主机)之间的数据传输控制传输层依赖于网络层的服务，对应用层提供传输服务,4,传输层与网络层的关系,网络层为主机之间数据如何经过路由器选路到达对方提供服务,传输层加强了网络层的服务，在数据能到达对方的前提下，为数据的
2、传输进行控制，为进程间进行通信提供服务,5,因特网传输层提供的服务,不可靠的(“尽力而为”),无序的传输(UDP)可靠(正确、按序)的端到端传输(TCP)面向连接的服务流量控制拥塞控制因特网上不能提供的服务:实时性带宽承诺可靠的广播通信,6,传输层的分用和复用,分用：接收方传输层根据端口号分用到不通的应用层进程复用：发送方不同的应用层进程根据不同端口号复用到同一传输层中,段,传输层首部,应用层的数据,传输层根据目的端口分用到不同应用进程,7,套接字的回顾,客户端A向服务器B端请求网页,源端口随机从可用端口取，目标端口为80,C打开两个浏览器，向B发送两个网页请求,8,学习内容,传输层的概念和提
3、供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节,9,UDP协议概述,“最简单的”Internet 传输协议提供不可靠的数据传输，又称“尽力而为的”的服务,其本质是宁缺勿滥，尽力传输UDP 协议允许:数据丢失应用数据乱序到达无连接的协议在UDP收发双方之间,无需握手建立连接每个 UDP 数据段的操作都互相独立,10,UDP协议的首部,源端口和目标端口定义发送方和接收方的通信进程,长度字段定义UDP数据报的总长度(包括首部和数据),校验和用于数据传输的差错检查，UDP协议宁缺勿滥,11,UDP校验和查错机制,注意：UDP查错的数据包括IP首部的12字节
4、，称为伪首部，作为网络层数据的冗余检查，求和是按二进制反码运算求和,校验和是网络通信的查错方式之一，广泛应用于传输层和网络层，发送方将需检验的数据按照一定的大小求和，得到的和取反得到为校验码,12,学习内容,传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节,13,可靠传输协议概述,可靠传输协议保证数据能够正确、按序的到达对方可靠传输协议可以用于数据链路层、网络层、传输层和应用层可靠传输协议属于网络前10位的重要课题讨论：如果物理信道100%可靠，还需要可靠传输协议吗？,14,停止等待协议,SW(stop and wait)停止等待协议
5、,发送方每发送一个报文，必须收到对方的回复后才能发送发送下一个报文SW协议类似于非流水线作业方式可靠传输协议的讨论从SW协议开始,15,可靠协议开始起步,rdt_send():可靠的数据传输处理函数，处理完将数据交给下层,udt_send():不可靠的数据传输处理函数，将分组通过不可靠的信道传到接收方,rdt_rcv():可靠的数据接收处理函数，,deliver_data():向上层递交数据，由rdt调用,16,rdt1.0 信道完全可靠,前提：信道完全可靠数据不会出错数据不会乱序到达，也不会丢失可靠协议本身无需做额外的处理,17,rdt2.0 信道可能出错,前提：信道可能在分组数据中出现位错
6、，但不会丢失讨论：需要解决的问题，如何查错，如何从错误中恢复从错误中恢复的办法：纠错机制(代价太大)使用确认(ACKs)和否认(NAKs)机制:当接收方正确收到分组，则向发送方发送确认信息，否则发送否认信息，当收到NAK时，发送方重传数据(发送方缓存数据，提高效率),18,rdt2.0的运行(无错的情况),发送方 FSM,接收方 FSM,19,rdt2.0 运行(出错的情况),发送方 FSM,接收方FSM,20,rdt2.0 存在的设计缺陷,ACK/NAK 报文出错?发送方将不会知道接收端发生了什么!ACK/NAK本身必须增加查错机制讨论：当发送方发现ACK/NAK出错怎么办?对ACK/NAK
7、本身再发送ACK/NAK(不可行)直接重传分组接收方可能收到重复分组重复分组的问题(接收方收到一个分组无法分清该分组是重传的分组还是新的分组):,21,rdt2.1:信道出错的可靠协议改进,发送方给每个分组加上序号(sequence number)接收方丢弃重复分组,并再次对分组确认讨论：序号需要多少个？不用NAK,只用ACK是否可行，如何处理rdt2.1:只使用ACK,分组采用0/1循环编号，接收方根据序号确定是否是重复分组,22,rdt2.1 演示,发送方,接收方,1,0,0,1,0,1,Ack0,正确收到，发0号分组确认，期待1号分组,发送0号分组,正确收到0号分组确认，发送1号分组,A
8、ck0,1号分组出错，发0号分组确认,1,重发1号分组,Ack1,正确收到，发1号分组确认,1,1号确认出错，重发1号分组,Ack1,正确收到，判断是重复分组，发1号分组确认,正确收到1号分组确认，发下一个0号分组,23,rdt3.0 数据可能出错和丢失,讨论：谁通过何种方式发现数据丢失?发现数据丢失后如何处理？发送方通过“超时”时间发现数据丢失.对发送的分组定义一个超时时间(定时器)，若在超时时间里没有收到ACK，则重传该分组注意:数据超时并非一定丢失了如果分组(或 ACK)仅仅被延迟了(没有丢失)将导致重复分组,但使用序号机制可以控制思考:超时时间如何确定,固定的还是变化的?,24,rdt
9、3.0 演示1,发送方,接收方,发送0号分组,收到ACK0,发送分组1,收到分组0,发送ACK0,收到分组1,发送ACK1,超时，重传分组1,收到ACK1,发送分组0,收到分组0,发送ACK0,发送方,接收方,收到分组0,发送ACK0,数据丢失情况,确认丢失情况,25,rdt3.0 演示2,发送方,接收方,数据超时未丢失情况,收到ACK0,发送分组1,收到分组0,重复分组，发送ACK0,26,停止等待协议(rdt3.0)讨论,停等协议能否达到可靠传输的目的停等协议一定能100%正常工作吗？停止等待存在的性能问题例:1 Gb/s 链路,RTT=30ms,传播1KB 分组,网络协议限制了物理资源的
10、利用!,27,滑动窗口协议的讨论,发送方在没有收到对方的ACK的时候可以发送多个数据包，类似于流水线作业方式发送方使用发送窗口限制没收到确认时允许发送的数据量序号的个数必须增加发送方和接收方需要增加缓存常见的两种滑动窗口协议:GBN(回退N步)和SR(选择性重传),28,GBN的工作方式,发送方：窗口不满则发送至窗口满，窗口满则等待，收到确认窗口向后移动，某个分组出错或丢失则重传该分组及其后面所有已发送但未被确认的分组接收方：对按序正确到达的分组确认，乱序或错误的分组丢弃且发送最后一次正确收到的分组的确认累积确认:发送方收到某个分组的确认意味着该分组及之前所有分组接收方都正确收到,29,GBN
11、的演示,发送窗口为4,发送方,接收方,30,SR的工作方式,讨论：GBN存在的不足及改进的方法？SR：选择性重传发送方某个分组出错或丢失只重传该分组。接收方增加接收窗口(接收缓存)，若收到的分组在接收窗口内且乱序，缓存该分组，等到分组按序后一起提交,接收窗口的大小一般等于发送方发送窗口的大小,31,SR的演示,发送窗口为4,发送方,接收方,分组2超时.重传分组2,乱序在窗口内，缓存并确认,32,窗口大小和序号的关系,GBN窗口的最大值等于序号的个数-1SR窗口的最大值等于序号的一半,若SR窗口为3，序号为4，上述情况接收方无法判断收到的序号为0的分组是重传的0号分组还是新发送的0号分组。,33
12、,本节小结,可靠传输协议的总结查错机制序号机制确认机制超时重传机制缓存机制滑动窗口机制定时器机制,34,学习内容,传输层的概念和提供的服务UDP协议的工作原理和协议细节可靠传输协议的原理和设计TCP协议的工作原理和协议细节,35,TCP协议,TCP协议的设计理念TCP协议首部TCP协议的连接机制TCP协议的流量控制TCP协议的拥塞控制,36,TCP的设计理念,TCP属于传输层，实现面向连接的可靠的传输可靠的传输不能保证传输一定到达对方，但是能保证如果数据到达对方，一定按序正确TCP使用了可靠的设计理念序号机制、确认机制、缓存机制、重传机制、滑动窗口机制TCP包含流量控制和拥塞控制机制,注意：不
13、同操作系统的TCP协议具体实现细节有所不同，但设计基本满足RFC 793,RFC 2581,37,TCP协议首部,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,38,TCP的首部细节1,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0
14、 8 16 24 31,填 充,源端口和目的端口字段各占 2 字节。端口是传输层与应用层的服务接口,类似一个地址标识。传输层的复用和分用功能都要通过端口才能实现。,39,TCP的首部细节2,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,序号字段占 4 字节。TCP 连接中传送的数据流中的每一个字节都编上一个号。序号字段的值指的是本报文段所发送的数据的第一个字节的编号,40,TCP的首部细节3,TC
15、P首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,确认号字段占 4 字节，是期望收到对方的下一个报文段的数据的第一个字节的序号。注意：当有数据要发送给对方时，顺便确认，当没有数据发给对方时，单独发一个确认报文。,41,TCP的首部细节4,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SY
16、N,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,首部长度占4bit，它作为一个二进制数字，表示TCP报文段的首部包含的总的字节数(即20个固定首部长度加不固定的可选首部长度)，计算单位按照4个字节为单位，如1100表示首部为12*4=48字节。该字段限制了TCP的首部最大值为60字节,保留字段占6bit，保留为今后协议的扩展使用，目前置为0。,42,TCP的首部细节4,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,U
17、RG,比特 0 8 16 24 31,填 充,特殊标记(Flag),每个标记占一个bit.有特殊约定。,URG 紧急比特标记，当URG置为1时，表明紧急指针字段有效。通知本报文段中有紧急数据，应尽快传送,紧急数据的优先级要高。ACK 只有当 ACK置为1时，确认号字段才有效。正常情况下只有第一次握手时ACK=0,43,TCP的首部细节5,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,PSH(PuS
18、H)推送比特，接收方收到推送比特置1的报文段，就尽快地将该报文段的数据交付给接收应用进程，而不再等到整个缓存都填满了后再向上交付。,RST(ReSeT)复位比特，当 RST1 时，表明 TCP 连接中出现严重差错（如由于主机崩溃或其他原因），必须强行释放连接,属于单方面强行断开连接。,44,TCP的首部细节6,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,SYN同步比特,SYN 置为 1，表示这是
19、一个连接请求报文。正常情况下只有第一次握手和第二次握手时SYN等于,其余都等于0。,FIN(Final)终止比特,用来正常释放一个连接。当FIN1时，表明此报文段的发送端的数据已发送完毕，并请求对方释放连接，当对方确认后，会释放发送缓存。,45,TCP的首部细节7,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,窗口字段占2字节。窗口字段是流量控制的关键，用来控制对方发送窗口的大小，单位为字节。接收
20、方根据自身的缓存大小确定自己的接收窗口大小，然后通知对方以确定对方的发送窗口的上限。,检验和 占 2 字节。检验和字段检验的范围包括首部和数据这两部分。在计算检验和时，要在TCP 报文段的前面加上 12 字节的伪首部。,46,TCP的首部细节8,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,紧急指针字段 占 16 bit。紧急指针指出在本报文段中的紧急数据的最后一个字节的序号。,选项字段 长度可变
21、。TCP 只规定了一种选项，即最大报文段长度 MSS(Maximum Segment Size)。MSS 告诉对方TCP：“我的缓存所能接收的报文段的数据字段的最大长度是 MSS 个字节。,47,TCP的首部细节9,TCP首部,20字节固定首部,目 的 端 口,首部长度,检 验 和,选 项（长 度 可 变）,源 端 口,序 号,紧 急 指 针,窗 口,确 认 号,保 留,FIN,SYN,RST,PSH,ACK,URG,比特 0 8 16 24 31,填 充,填充字段 这是为了使整个首部长度是4字节的整数倍。从而保证首部长度字段的有效性和计算检验和的有效性,48,TCP 的数据编号与确认,序号基
22、于字节随机生成初始序号，之后每个字节都对应一个编号，序号是发送数据的第一个字节的编号确认号是期望对方发送的下一个数据的第一个字节的编号，即对方下一个报文段的序号TCP的确认属于累积确认,乱序到达的数据会缓存思考：TCP属于GBN还是SR,49,TCP的三次握手建立连接,A,B,第一次握手：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
23、第二次握手的序号加1,50,TCP的三次握手示例,发送 SYN，请求建立连接(seq=100 ctl=SYN),Host A,Host B,发送 SYN、ACK(seq=300 ack101 ctl=SYN、ACK),发送ACK(seq=101 ack301ctl=ACK),51,TCP释放连接的过程,异常释放,A,B,RST=1,ACK,正常释放,A,B,FIN=1,ACK,FIN=1,ACK,52,TCP四次断开示例,53,发送 FIN,请求断开连接(seq=101,ack=301,ctl=FIN，ACK),Host A,Host B,发送 ACK(seq=301,ack=102ctl=A
24、CK),发送ACK(seq=102,ack=302 ctl=ACK),Seq91 10Byte,Seq296 5Byte,Ack101,发送 FIN,请求断开连接(seq=301,ack=102 ctl=FIN，ACK),TCP状态图,54,TCP的重传机制,原则：当数据超时则需要重传问题：超时时间如何规定、如何提高效率？可靠传输协议需要对分组设置超时时间，超时时间应当动态地随着网络的有效带宽和拥塞程度不断的变化网络的拥塞程度可以通过往返时延RTT来衡量TCP的超时时间计算公式EstimatedRTT=(1-x)*EstimatedRTT+x*SampleRTT(x=1/8)Timeout=E
25、stimatedRTT+4*DeviationDeviation=(1-x)*Deviation+x*|SampleRTT-EstimatedRTT|Timeout=*EstimatedRTT(=2)某些TCP实现的方法,55,重传的进一步讨论,Karn算法(背景：往返时间有时很难估计）对重传的数据不计算RTT,timeout=2*timeout;快速重传提高效率当连续收到三个重复的冗余确认则重传对方期望收到的分组,56,TCP的流量控制,接收方:明确地通过TCP首部的窗口字段发送接收窗口大小，从而限制发送方发送窗口的最大值发送方:保证发送窗口大小不超过对方发送地接收窗口的大小,思考：TCP的
26、接收缓存是主机的所有TCP连接共享还是每个TCP连接独占？（需实验验证),57,TCP流量控制示例,Host A,Host B,Seq=300,ack=101,win=3,Seq=100,1Byte,Ack=104,win=1,Seq=101,1B,win=3,Seq=102,1B,win=3,Seq=103,1B,win=3,Seq=104,0,3,接收方的缓冲区,0,1,3,2,发送窗口大小为3,通报窗口大小为1,缓冲区满,应用程序读取了1个数据段,实际发送窗口大小变为1,通报窗口大小为3,TCP流量控制的特殊情况1,特殊场景：TCP连接的两端A和B,B接收缓存满，B此时无任何数据需要发送
27、给A问题：当A发送数据给B时，B发送确认，其中接收窗口大小为0,B的缓存逐渐出现空间，但A无法获得这一信息,使得A无法发送任何数据给B解决办法：当收到接收窗口为0的报文，A继续发送一个字节的数据（一般响应一个持续定时器后在再发送）,获得B确认报文中最新的接收窗口大小,59,TCP流量控制的特殊情况2,愚笨窗口综合症当接收端交互式应用每次读取一个字节数据时,或者发送端每次只发送一个字节数据，将会使得TCP的工作效率很低。解决办法：接收端如果接收缓存很小时，会等待一段时间(500ms)等缓存大到一定程度再发送接收窗口给发送端（Clark策略)，提高效率发送端如果发送的数据很小，第一次会照常发送，后
28、面的会等待一定时间（500ms)等发送数据较大时再放入Tcp段中发送。(Nagle算法),60,TCP的拥塞控制机制,讨论：什么是拥塞？为什么需要拥塞控制？谁应该负责拥塞控制？路由器还是TCP的发送端和接收端？如何发现拥塞，发现拥塞后该如何处理？如何保证效率？,61,TCP的拥塞控制思想,使用拥塞窗口cwnd控制发送窗口大小发送窗口的上限值 Min rwnd,cwnd分组超时意味着拥塞，分组收到确认则意味着网络未拥塞拥塞则少发(拥塞窗口减小)，没拥塞则多发(拥塞窗口增加)在网络未知的情况下拥塞窗口从最小开始，收到确认拥塞窗口大小增加为提高效率，开始窗口增加速度快，到了一定阶段窗口增加速度变慢,
29、62,TCP的拥塞窗口举例,63,快恢复算法,当发送端收到连续三个重复的确认时，就执行“乘法减小”算法，把慢开始门限 ssthresh 减半,直接进入拥塞避免阶段,64,TCP 拥塞控制总结,两个阶段慢启动阶段乘法增拥塞避免阶段加法增一个阈值定义了慢启动阶段和拥塞避免阶段的分界点超时发生时阈值变成超时的窗口大小的一半回到慢启动,思考：假设TCP的拥塞窗口被设置为18KB,并且出现了一个超时，如果接下来的四次传输都正确的话，则拥塞窗口将是多大？假设最大数据段长度为1KB。,65,TCP 定时器,retransmission timer（重传定时器）每个发送未被确认的分组都需要启动该定时器 per
30、sistence timer（持续定时器）keepalive timer（保活定时器）该定时器保证TCP的连接是否存在，当一个连接空闲很长时间以后，保活定时器到期，一方查看另一方是否存在。时间等待计时器连接终止期间使用的,66,重传计时器为了控制丢失的数据段,Host A,Host B,开启重传计时器，等待确认,Ack,撤消重传计时器，再发送其他数据,A在重传计时器超时之前接收到ack,A在重传计时器超时之前没有接收到ack,重传数据，并将重传计时器复位,TCP 定时器示例1,67,TCP 定时器示例2,持续计时器为了防止零窗口死锁,Host A,Host B,Ack win=0,A在坚持计时
31、器超时之前接收到通知窗口大小的ack,A在坚持计时器超时之前没有接收到通知窗口大小的ack,收到win=0的确认，等待对方发送确认来通知窗口的大小，并启动坚持计时器,Ack win=3,发送探测数据段，提醒接收端确认已丢失，如果没有坚持计时器和探测数据段，ack丢失时，双方将会进入等待死锁的状态,Ack win=3,丢失,68,TCP 定时器示例3,保活计时器防止两个TCP之间的连接长时间的空闲,Host A,Server在保活计时器超时前，没有收到客户端发来的数据,发送探测数据段，如果发送了10个探测数据段，还没有响应，则断开连接,建立了TCP连接，开启保活计时器,server,69,TCP
32、 定时器示例4,时间等待计时器连接终止期间使用的在发送了最后一个ACK后，不立即关闭连接，而是等待一段时间，保证能接收到重复的FIN数据段。,Host A,Host B,FIN,ACK,FIN,ACK,丢失,A发送了最后一个ACK后，不立即关闭连接，等时间等待计时器超时后再关闭，如果A立即关闭，而ACK又丢失了。B会再发送FIN，但是A已经断开了连接，不会发送ACK,70,TCP安全问题（LAND攻击）,71,TCP安全问题(SYN Flood 攻击),攻击方不断持续的发送连接请求的攻击当主机A接收到来自主机X的SYN请求时，它就必须在侦听队列中对此连接请求保持75秒的跟踪。当多个攻击方同时快
33、速发送SYN连接请求给被攻击方时，被攻击方会耗尽TCP相关资源而无法提供正常的服务SYN Flood攻击属于DoS(Denial of Services)攻击的一种,72,TCP安全问题(特殊攻击),利用TCP实现上的漏洞进行攻击例如：将TCP报文的SYN和FIN均置为1发送给对方，早期TCP的实现会导致系统崩溃。讨论：TCP的设计或实现上是否存在漏洞，如何改进？,73,本章小结,UDP协议的首部校验和的计算方法可靠数据传输协议的特性SW协议，ARQ协议GBN协议，SR协议TCP协议首部信息连接管理重传机制流量控制拥塞控制定时器,74,本章习题,简述可靠传输原理的机制简述GBN和SR的区别UDP协议的特点有哪些？TCP的特殊标记(flag)有哪些？TCP的三次握手发生了什么？TCP的确认机制如何实现？TCP的流量控制和拥塞控制的工作原理。,75,
