zoukankan      html  css  js  c++  java
  • 计算机网络--->7. 传输层(2)

    7. UDP用户数据包协议

    7.1 UDP主要特点

    • 很适合多媒体通信的要求是指:广播屏幕
    • TCP只是1对1

    7.2 UDP首部

    UDP首部具体格式如下

    • 首部中两个字节的长度标识的是首部加数据部分的总长度
    • 检验和:计算“伪首部”+“首部”+“数据”来进行检验和的计算
    • 伪首部:就是为了与首部一起凑够20个字节再加上数据,方便检验和运算。说明:在传输层的检验和这里,需要使用网络层首部的一些信息来进行计算。伪首部的17表示协议号
    • UDP检验和计算过程如下

    8. TCP传输控制协议

    8.1 概述

    • TCP是面向连接的传输协议(计算机A和B在传数据前,要确保网络是通的,然后才可以传数据,AB在进行通信之前要进行3次握手)
    • 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的(一对一)。
    • TCP提供全双工通信(必须是全双工,B从A那里下载500M文件,用的是TCP,就算是A一直给B传数据,B也要每隔一段时间给A一个反馈(告知A已经收到、或让A传快、传慢一点等),让A知道文件已经被B正确接收)
    • 面向字节流(图中的每个小格子代表一个字节【8位二进制】,计算机键盘上的一个字母或者特殊符号代表一个字节,一个字符等于一个字节)
      如图应用程序在发送文件的时候是一部分一部分的传,每次将要传的部分放在一个缓存中,这个缓存是TCP协议用到的缓存(这里叫做TCP缓存),同样接收端的计算机中也有一个TCP缓存。(1)发送方的应用程序往缓存中放数据块:每次选取的数据块包含的字节数是随机的,如:15//68//910等。(2)根据TCP协议传缓存区里面的字节:将数据块加上头部地址等信息构成数据包,在网上传输,每次选取的数据库占多少个自己也是随机的,如13//4~5等。(3)到达接收端的缓存后,就会将数据包的头部去掉,将来到的字节流按照顺序组装起来。(4)接收端的应用程序从缓冲区读这些字节,每次读一个数据块(数据块里包含的字节也是随机的)

    TCP解决以下3个问题

    • TCP提供可靠交付的服务
    • TCP提供流量控制
    • TCP提供拥塞控制(当网络中的很多计算机都在使用某一条链路进行通信的时候,网络堵塞,导致该链路上的路由器处理不过来到达的数据包,导致数据包丢失,TCP协议必须有一种机制来避免网络拥塞)

    8.2 TCP的连接

    TCP协议是点到点的通信,每一条TCP连接有两个端点,TCP连接的端点不是主机、不是主机的ip地址、不是应用进行、也不是传输层的协议端口,而是“套字节”。对应用程序而言从一个点到另一个点是通过TCP+端口号来表示的。端口号拼接到IP地址即构成了套字节。

    8.3 TCP如何实现可靠传输

    8.3.1 可靠传输工作原理:停止等待协议

    1. 无差错的or超时重传

    如下图A给B发数据包M,A发送数据包后必须等待B确认数据包已经接收到,这样A才会发下一个数据包,否则A就一直等待B的确认信息。
    若A给B发送数据包的时候,数据包丢失,A等待一个时间t(t略大于一个数据包的往返时间RTT),之后A再发一遍同样的数据包

    2. 确认丢失or确认迟到

    (a)B收到A发过来的数据包M1后,传一个确认包给A,但是这个确认包丢失,A没收到B的确认包则继续等待一个时间t,之后再重复发M1。M1到达B之后,B丢掉重复的包,再给A发一个确认包,之后A再继续发下一个数据包。
    (b)A给B发M1,B传一个确认包给A,但是这个确认包走了远路,A发现到了时间t也没有受到B的确认包,这个时候A再发M1给B,B将重复的M1丢掉,重新给A一个确认包(让A发M2),A就接着发M2。过了一段时间B发的第一个确认包到A(让A发M2),A受到迟到的确认包,什么也不做。

    总结:只有B没告诉A已经收到了,那么A就认为B没收到。使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信。这种可靠的传输协议被称为ARQ。ARQ表面重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。
    3. 信道利用率

    上述停止等待协议的优点:简单;缺点:信道利用率低

    • TD是A发某个数据包所用的时间,B计算机收数据包的时间
    • t0单程传输时间
    • TA收数据包所用时间
    • RTT是往返时间,数据包尾部离开A,到确认包头部到达A所用的时间
    • 信道利用率U=TD/(TD+RTT+TA),看出TD相比较总时间非常小,大部分时间都在等,而发送数据包的时间太短了,要想提高U则必须要提高TD,因为RTT和TA相对比较固定。提高TD的方法就是让A一直发数据包

    8.3.2 流水线传输

    发送方可以连续发送多个分组,不必每发完一个分组就停下来等待对方确认。由于信道上一直有数据不间断地传送,这种传输方式可以获得很高的信道利用率。我们的计算机通信、上网、聊天都是用的流水线传输

    • A一直发数据包给B,中间不停下来等待B的确认包。可能A发到第10个数据包的时候,才等到B的第一个确认包。

    1. 流水线传输实现可靠传输:利用滑动窗口技术实现可靠传输

    要求发送方维持一个发送窗口,发送窗口是5就意味着框住了5个数据包,表面者5个数据包可以连续发送,不用等确认。这5个数据包都发送出去后,开始等待确认。得到第一个数据包确认之后,窗口就往右边移动一格框住数据包6。这个时候数据包1就从缓存中扔掉了,因为数据包1已经被接收方收到了。同时可以发送数据包6,这个时候数据包2的确认也受到了,发送窗口再往右边移动一格,在缓存区删除数据包2

    • 窗口里的数据都是可以发的,等待确认包到来时才可以删
    2. 累积确认
    • 流水线传输每个数据包都还是有一个确认,效率还是不够高,所以在接收端还可以采用累积确认的方法:
      计算机A个B发数据包,数据包1,2,3都被计算机B收到了,这时候B给A发一个确认告知A我收到数据包3了,你该发第4个了。这是数据包1,2就不用发确认了,B说收到了数据包3那就意味着1,2,3都收到了。

      若A发数据给B,B受到了数据包1,2。数据包3没有收到,收到数据包4。这种情况下B给A一个确认,收到了数据包2。B指确定收到了连续的数据包。这个时候A开始重发第3个数据包,之后再发第4个数据包。
    • 累积确认虽然效率高,但是后面收到的数据包,A也不知道,还是要重发

    8.4 TCP报文段的首部格式

    • 应用层将要传输的数据放在缓存中。传输层将缓存中的数据分段,得到TCP的数据部分。

    • TCP报文段 = TCP的数据部分+TCP的首部

    • TCP首部 = 20字节的固定部分+可变长部分。大部分数据包没有可变部分

    • 序号:占4个字节,上文说过TCP协议面向字节流,要传输的数据分块按照顺序存放在TCP缓存中,发送时将缓存区的某几个字节分成一段再加上头部(将来在网络层还要加上IP地址,当成一个数据包发出去)序号就表示这个段的第一个字节位于整个文件的第多少个字节。

    • 确认号:若位于接收端返回的确认数据包中,告知发送端下一个数据包该发送第多少个字节的数据段了。
      计算机A给B传文件,第一个数据端到达B的缓存区后,一检查,发现收到了数据包1、2、3、4,将数据段的头部去掉。之后B会给A一个确认包,告知A:“自己收到该数据段了,这个数据段的最后一个字节是4,让A发第五个字节开始的那个数据段。之后A就发第5个字节开始的数据段。

    • 数据偏移:接收端收到TCP报文段后,要判断首部的起始位置,数据偏移用于记录TCP报文段第多少个字节之后就开始是数据了。数据偏移占据4位二进制,但是并不代表数据偏移为015(0001111),数据偏移每个1代表4个字节,所以数据偏移的范围0~15x4个字节。说明首部最多60个字节。固定20个字节,所以选项部分最多40个字节。

    • 保留:没有用(6位2进制)

    • 标记位URG:用于告诉计算机,这个数据段里存的数据是比较高级的数据,要优先传,不用排队了。URG=1,则这个数据段直接放在缓存区的第一位,直接优先传送。

    • PSH:在接收端的缓存区,也是将接收得到的数据段排好顺序,再依次提交给应用程序。此时若来一个数据包的PSH=1,则这个数据段直接放在缓存区的最前面,提交给应用程序,优先提交。

    • ACK=0则确认号无效,ACK=1确认号有效。确认号是对之前有接收的数据的确认
      (1)所以当计算机XP要访问WEB站点的时候,XP首先发起一个会话的请求数据包中ACK=0,确认号=0,序号=0;
      (2)当web站点返回给XP的数据包,确认号是1,ACK=1,序号是0
      (3)之后的ACK都是1

    • SYN:
      (1)当计算机XP要访问WEB站点的时候,XP会发起一个会话的请求。SYN=1说明这是一个建立会话请求的数据包。
      (2)WEB站点同意建立会话返回给XP的一个数据包的SYN也等于1
      (3)会话建立完成之后,以后SYN都等于0

    • RST=1说明TCP会话发生了严重的错误,必须释放连接,要想重新通信还要重新建立连接
      打开IE浏览器就等于和WEB服务器建立连接了,这个时候点击右上角的❌,则次会话异常结束,此时后面传来的几个数据包的RST=1,拒绝后面的数据通信

    • FIN:计算机A访问WEB服务器,WEB服务器给A的数据传送完成,那么后面几个数据包的FIN=1,表面数据传输完成,即将释放连接

    • 窗口:计算机A是一个网站,B计算机要访问这个网站。
      (1)在AB通信之前,B计算机要通知A计算机,自己的接收缓存可以放多少个字节(65535个字节);这时服务器A就要设置一个和B通信的发送缓存(也是65535个字节)。
      (2)同时A也要告诉B自己的接收缓存是多大(比如是64032个字节);那么B计算机就要设置一个和A进行通信的发送缓存,也要设成64034个字节。
      访问网站的时候一定要协商以下各自的接收窗口,根据对方的接收窗口来设置发送窗口。其中的字节数就被看作是窗口大小。

    • 校验和:检验和的数据范围是首部和数据两个部分。和UDP一样,在计算校验和的时候要在TCP报文段的前面加上12个字节的伪首部进行计算,但是需要把伪首部第4个字段的17改为6,因为TCP的协议号是6.

    • 紧急指针:只有在URG=1的时候,紧急指针才起作用,紧急指针指明了紧急数据在本数据包中结束的位置。紧急指针的值若是50,则表示TCP报文段数据部分的前1~50个字节,是需要紧急处理的,第50字节后面的数据不着急。

    • 选项:(1)选项1:规定最大数据包的长度是多少。计算机在通信之前利用这个选项可以通知对方自己能够接收的最大数据包是多大。(2)选项2:确认时是否支持选择性确认SACK。

    8.5 TCP如何实现可靠传输(接近真实的计算机通信过程)

    1. 以字节为单位的滑动窗口计算

    • A的发送窗口由B的接收窗口决定。

    • A传数据给B,若窗口中的字节(1~20)全部以数据包的形式发出去了,却还没有等到B的确认,此时A不能继续发送后面的内容,且由于没有收到B的回应,A发送缓存中的内容不能删。

    • 123456到达B之后,B给A一个确认包(ACK=1,确认号:7),此时A窗口右移6个字节,并把前6个字节删除。

    • 此时21~26字节可用继续在网上传输,78910到达B后,B知道刚才A已经收到了自己的确认包,那么也将数据窗口后移6位。B的应用程序就开始读123456

    • 缓存区>窗口

    2. 数据包在传输过程中发生丢失的情况

    • 丢失了数据包789,B发给A的确认包中的确认号是7,但是B还收到了10 11 12,这个时候B的数据包中还会有一个选择性确认SACK,SACK会告知A计算机具体哪一段缺失了,那么A将窗口向后移动6位,并只发丢失的数据段789,A不再发10 11 12

    • A补发之后,B收到一段连续的字节流了,那么A收到确认后,A就又可以往后移动窗口了

    • 其实,A每次收到一个确认都会移动窗口,包括之前A收到的的选择性确认也将窗口后移动了6位。

    3. 超时重传需要等多长时间

    A给B传文件,A发一个数据包,B没有回应,A等多久重传比较合适呢?

    • TCP每发送一个报文段,就对这个报文段设置一次计时器。只有计时器设置的重传时间到但还没有收到确认,就需要重传这一报文段。
    • RTT是往返时间
    • RTTS是平均往返时间:A给B发送多个数据包,记录每个数据包的往返时间,取平均值后,得到的就是平均往返时间。
    • 超时重传等待时间应该略大于RTTS
    • 但是在网络中的往返时间不是固定的值,网络中的线路有时忙有时闲。RTTS也应该变化才比较合理
    新的RTTS = (1-a)x(旧的RTTS) + ax(新的RTT样本)
    
    • a越小,说明RTTS比较依赖于旧值;a越大,说明RTTS比较依赖于新值,修正的比较及时。推荐a=1/8;
    • 若网速波动很大,则a值应该大些;若网速波动很小则a值应该小些。

    8.6 TCP如何实现流量控制

    1. 流量控制

    计算机XP访问WEB服务器的的时候,服务器的发送缓存给XP的接收缓存传数据,XP的处理能力可能比较差,当XP的接收缓存满了之后,若WEB还是用以前的速度给XP发数据,XP就开始崩溃了,这个时候WEB服务器必须给WEB发一个数据包,告诉WEB,让WEB发慢一点或停止;当XP将接收缓存中的数据处理完了,将缓存清空后,再发一个数据包给WEB,让WEB继续发,这就是流量控制。

    • 流量控制用于解决通信两端处理速度不一样的问题。

    2. TCP进行流量控制

    • A给B传数据,通信之前AB建立会话:B根据自己的缓存设定了一下自己的接收窗口是10个字节,在建立会话的时候B要给A发一个数据包,告知确认号(ACK=0)和接收窗口(rwnd=10)等。A就要根据B的接收窗口设置自己的发送窗口,也是10。那么A的前10个字节就可用连续发送了。
    • 1234都到达B了,56丢失,这时B给A一个确认包(ACK=5),此时B的接收缓存若较小,可用将接收窗口设置的小一点(wnd=8)。
    • A收到确认后,A的窗口也应该改为8,A窗口向右移动4格。此时A发送78910 11 12,之后A再发送56,这时B再给A一个确认包,ACK=13,wnd=2
    • A收到确认后,A的窗口也应该改为2,A窗口向右移动,此时A发13 14,B收到后给A一个确认包(ACK=15,wnd=0)
    • A收到确认后,A的窗口也应该改为0
    • 之后B开始处理数据1~14,处理完成后缓存就空出来了。这时B重新调整接收窗口,再给A发一个确认包ACK=15,wnd=10
    • 问题:B处理完积压在缓存中的数据后,重新给A发的数据包丢失了怎么办?答:为了避免这个问题,A计算机会定时给B发送一个窗口测定的数据包,看看B计算机现在的接收窗口是多少。
    • TCP的流量控制就是通过接收端告诉发送端当前的接收窗口有多大来实现的。

    8.7 TCP实现拥塞控制

    1. 拥塞控制的一般原理

    • 出现资源拥塞的条件:对资源需求的总和>可用资源
    • 拥塞控制是一个全局性的过程

    2. 拥塞控制起到的作用

    • 提供的负载,即每秒钟在网络中传输的数据。

    • 吞吐量:每秒钟通过这个网络的所有人产生的流量(若一个网线连接设备ABCD,网线的带宽是100M,那么该网络的吞吐量最高就是100M)

    • 提供的负载指发送方发的流量,吞吐量指可用通过网络的流量

    • 理想的拥塞控制,网络永远不堵塞,当网线带宽是100M,AB传数据到CD,就算AB传的数据为150M,该网络也只传100M,将剩余的50M丢弃。

    • 无拥塞控制时,路由器处理不过来达到的数据包导致数据丢失。扔的越多未必过的越多,当扔特别多的数据包后,路由器完全处理不过来,就死机了,死锁:吞吐量为0

    • 实际的拥塞控制:避免网络吞吐量为0的情况。

    3. 拥塞控制的实现

    (1)慢开始和拥塞避免(1988年提出)

    发送方维持拥塞窗口(拥塞窗口就是之前说的发送窗口)。发送方控制拥塞窗口的原则是:只要网络没有出现拥塞,拥塞窗口就再增大一些,以便把更多的分组发送出去;只要网络出现拥塞,拥塞窗口就减小一些,以减少到网络中的分组数。

    • 慢开始算法原理

      刚开始的时候,发送方不知道网络堵还是不堵,所以先发一个数据包;发现网络目前不堵,就提高下发送速度,提高到一次发2个数据包;发现网络还是ok的那么在第三轮发的时候,就一次发4个数据包。。。(每次发送的数据包个数1,2,4,8,16...)

    • 拥塞避免算法的原理:让拥塞窗口缓慢增大,即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1,而不是加倍,使用拥塞窗口按线性规律缓慢增长

    • 慢开始门限:增长速度开始变慢的点
      当拥塞窗口<慢开始门限:使用慢开始算法。
      当拥塞窗口>慢开始门限:停止使用慢开始算法而改用拥塞避免算法。
      当拥塞窗口=慢开始门限:既可以使用慢开始算法也可以使用拥塞避免算法。

    • 上图在拥窗口是24的时候,出现了丢包,网络开始堵塞。则(1)重新计算新的慢开始门限24/2=12;(2)拥塞窗口从1开始用慢启动算法增长124~8,然后到12.

    • 无论在慢开始阶段还是拥塞避免阶段,只要发送方判断网络出现用晒(其根据是没有按时收到确认),就要把慢开始门限设置为出现拥塞时的发送窗口值的一半(但不小于2);之后把拥塞窗口重新设置为1,执行慢开始算法。这样做的目的就是迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够的时间把队列中积压的分组处理完毕。

    • 强调:“拥塞避免”并非指完全能够避免拥塞。利用以上的措施要完全避免网络拥塞是不可能是。“拥塞避免”是说在拥塞避免阶段把拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。

    (2)快重传和快恢复(1990年新增)
    • 快重传:A计算机给B计算机发数据,若采用累积确认的方式,假定B接收到5个数据包的时候给A一个确认。A发数据包12345,若第3个数据包丢失,B只收到124的时候就立刻可以断定3丢失,但是由于是累积确认的原因,B非要等到第5个数据包到达才给A确认,确认号是3,让A重传345,这就耽误时间了。而快重传是指,当B一发现数据包3丢失就立即连续给A发送3次确认包,让A重传345,之后A就立即发345,这就是快重传。

    • 当A收到3个确认后,A的拥塞窗口如何变化呢?

    • 原理:快重传算法首先要求接收方每收到一个失序的报文段后就立即发出重复确认。这样做可以让发生方及时知道有报文段落没有达到接收方。当发送端收到连续3个重复确认时,就执行“乘法减小”算法,把慢开始门限减半,但是拥塞窗口现在不置为1,而是设置为慢开始门限减半后的数值,然后开始执行拥塞避免算法,使得拥塞窗口缓慢地线性增大。

    • 发送窗口的实际上限值:发送方的发送窗口的上限值应当取为接收方窗口和拥塞窗口这两个变量中较小的一个,即:
      发送窗口上限值 = Min(rwnd,cwnd)
      在AB建立会话的时候,B首先会告知A自己的接收窗口。但是在刚开始建立通信的时候,A的发送窗口是由cwnd来控制的(1,2,4,8,16...),若这个网不拥塞,则cwnd一直增大但是不能超过rwnd

    8.8 TCP的传输连接管理

    传输连接有3个阶段:连接建立、数据传送、连接释放。TCP连接的建立都是采用客户服务器方式。
    主动发起连接建立的应用进程叫做客户
    被动等待连接建立的应用进程叫做服务器

    1. TCP的连接建立:用3次握手建立TCP连接

    • 第1次握手:A主动给B发一个数据包(SYN=1),B收到之后看到SYN=1,则知道这是要和自己主动建立连接的数据包。

    • 第2次握手:那么B数据包就给A一个数据包作为回应(SYN=1)

    • 第3次握手:同时A在给B发一个数据包(SYN=0)

    • 第1次握手和第2次握手足以证明这个网络是畅通的,且这两个数据包足以协商数据通信所需要的参数,为什么会有第3次握手来进行再次确认呢?

    • 答:若没有第三次握手,当A发第一个请求建立会话的数据包x1给B的时候,数据包x1可能选择了远路,A等了很久都没有等到B的回应,这个时候A就会再给B发同样的数据包x2,数据包x2走近路,很快达到B,B也立马给了A一个回应数据包y1。这时若数据包x1达到B之后,B又会发一个数据包y2给A,但是A是不认这个数据包的,因为之前已经同意建立了呀,这就会导致B一直等待,浪费了B的资源,这种情况出现的多了,B就会瘫痪。所以必须进行3次确认,才开始正常通信。

    • 第3次A到B数据包的确认,数据包里面就不是同步信息了,

    2. TCP的连接建立:用3次握手建立TCP连接的各个状态

    (1)A给B发送了一个建立连接的请求之后,A的状态就变成了SYN-SENT
    (2)B收到之后给A一个确认,B的状态就变成了SYN-RCVD
    (3)A收到B的确认后,A的状态就变成了ESTABLISHED
    (4)当B再次受到A的确认之后,B的状态就变成了ESTABLISHED
    (5)AB状态都变成ESTABLISHED之后就开始传数据了

    3. TCP的连接释放

    • 何时连接释放:A打开一个网页,该网页的内容全部显示在A上了,这个时候连接就该释放了。
    • 客户A主动发一个数据包(FIN=1)给B,主动关闭TCP连接,等待B确认。
    • B计算机受到之后,B给A一个确认,此时A不可以给B发数据了,但是B没说结束,所以B还可以给A发
    • 当B把数据发完,B会发给A一个确认,FIN=1意味着B也要结束了
    • A收到之后A再给B一个确认,此时AB直接不可以再相互发数据。

    4. TCP的连接释放的状态

    • 最长报文寿命默认2MSL(MSL=2分钟)
    • 客户机收到服务器最后一次确认后,必须在等4分钟才会关闭
    • TCP连接必须经过时间4分钟后才会真正释放。
    • 等4分钟的原因:A收到服务器最后一次确认后,A发最后一个确认包之后直接变为closed状态,若是这个确认包丢失,服务器等待过久会又给A发一个过来,但是A是closed状态,那么这个会话永远关闭不掉了。
  • 相关阅读:
    annotation:@Override出现The method of type must override asuperclass解决方案
    把Object对象转换成XML格式的数据
    把用SQL查询的分页对象转化为内容为Object的分页对象
    java实现webservice实例
    把Excel表中的数据导入sql service数据库的语句
    把汉字串转成对应的汉语拼音
    JDBC连接mySQL数据库流程及其原理
    oracle将多列进行合并
    源码分析 | ClickHouse和他的朋友们(13)ReplicatedMergeTree表引擎及同步机制
    源码分析 | ClickHouse和他的朋友们(1)编译、开发、测试
  • 原文地址:https://www.cnblogs.com/deer-cen/p/12324860.html
Copyright © 2011-2022 走看看