计算机网络第三章 传输层

news2024/11/16 9:55:57
  • 本文部分图片(PPT截图)来自中科大计算机网络top down

3.0 目录

[TOC]

3.1 概述

  • 传输层TCP和UDP协议可以在IP协议主机到主机通信的基础上,实现进程到进程之间的通信(利用端口号)真正实现端到端的通信【通过多路复用于解复用】

  • 传输层的TCP协议可以提供可靠性的服务(RDT),但是并不能改进延时和吞吐量的性能,也不能提供安全性的保障(应用层中的SSL: Secure Socket Layer)

3.2 多路复用与解复用

A. 形象理解
  • 生活中的示例:Anne家12个小孩,Bill家10个小孩,每个月Anne家的每个孩子都要给Bill家的每个孩子写邮件,示意图如下:

  • 120封信通过邮局发出相当于多路复用过程,Bill家大孩子分信相当于解复用的过程

B. 原理分析
  • 多路复用的过程:创建套接字socket,与应用进程的进程号相互关联,并利用套接字的源端与目的端IP和Port创建TCP\UDP报文段和IP数据报的头部

  • 解复用的过程:传输层获取到源IP,目标IP,源Port以及目标Port之后即可查询本地的Socket表,便可以得知创建该套接字的应用进程

3.3 UDP协议

  • UDP:User Datagram Protocol用户数据报协议

  • UDP有什么用武之地呢?【流媒体应用】(要求实时性较高)、【DNS域名系统】(典型的事务性应用)、【SNMP简单网络管理协议】

A. UDP报文头部
  • UDP是面向报文的协议【报文是有界的】,TCP是面向字节流的协议【字节流是无界的】

  • UDP报文的头部总共8个字节(2*32bits = 8Bytes)

  • 报文长度是以字节为单位的报文长度(包含头部的8个字节)

B. UDP差错检验EDC(校验和)
  • EDC:Error_Detection and Correction差错检测与纠错

  • 将整个UDP数据报切成一个个16bits的段(头部也要切),并将所有段加起来

  • 得到校验和需要两个技巧:进位回滚+按位取反

3.4 可靠数据传输RDT

  • 本节采用渐进的方式讲述RDT即从下层完全可靠开始,逐步加入不可靠的因素,并了解相应的RDT可靠数据传输机制的可靠性措施

  • 且本节采用有限状态机FSM:Finite State Machine的形式来描述发送和接收方的状态,有限状态机的形式如下:

A. RDT1.0 下层可靠信道的可靠数据传输
  • 下层提供的服务无比特差错,无分组丢失,完全可靠

  • 本层只需要增加多路复用与解复用服务即可

  • 因此,对于应用层交到传输层的报文,只需要进行封装并递交给网络层,对于接收方网络层上交的报文段也只需要解封装并通过解复用上传给应用层进程即可

  • 其有限状态机如下:

B.RDT2.0 具有比特差错的下层信道
  • 下层信道可以具有bit差错(把0传成1)因此需要有传输确认的机制(ACK+NAK),以及校验和checksum校验的机制(进位回滚+按位取反)

  • 因此,发送方发送报文段后进入等待确认的阶段,如果受到ACK,则说明接收方成功受到并校验通过报文段,因而发送发可以进入下一个等待上层调用的周期

  • 而接收方接收到报文段后,需要利用校验和校验报文,校验不通过,返回标志NAK,并丢弃错误报文,等待报文重新传输;校验通过,返回标志ACK,并解封装报文,通过解复用传递给应用层进程

  • 其有限状态机如下图所示:

C. RDT2.1:解决2.0中ACK,NAK传输出错问题
  • RDT2.0中有个致命的不足,若ACK或NAK在传输的过程中发生错误,或无法到达,那么发送端将一直处于等待回复的状态,接收端也将一直处于等待包裹的状态,系统死锁

  • 因此,RDT2.1中加入了序号机制以及对ACK与NAK的校验机制

  • 首先,对ACK与NAK的校验机制目的是验证ACK与NAK在传输的过程中是否有发生错误

  • 接着,引入编号对解决ACK以及NAK传输错误的问题有什么作用呢?不是加入校验机制就可以了吗?

  • 对于发送方而言,确实不需要编号的机制,只要收到一个不知道是啥的反馈,再将本分组发出去即可,因此,引入编号对发送方是没影响的

  • 但是对于接收方而言,如果不引入编号,那么我们可以假设以下两种情景:

  1. 发送方给接收方的报文校验不通过,接收方本来要返回NAK,但NAK在返回的图中挂了,那么发送方重新传递该报文是没问题的

  1. 发送方给接收方的报文校验通过了,而接收方本来要返回ACK,ACK在半路挂了。如果没有序号,那么接收方将回到等待下层报文到来的阶段,如果再次收到原报文,那么接收方也会当作正常的报文解封装传递给应用层进程,导致同样的报文重复传递。即原本应该传递pkg0和pkg1但是现在由于返回的ACK半路挂了,因而接收方向其应用进程输送了两次pkg0,显然是有问题的

  • 因此,编号机制对于接收方不重复传递是有重要意义的

  • RDT2.1的有限状态机如下:

D. RDT2.2:NAK_free版本的协议
  • 在RDT2.2版本中,用上一个分组的确认号代表本分组的拒绝,从而实现了NAK_free的协议,从而有利于后面pipeline高效可靠数据传输的实现

  • RDT2.2的实现示意图如下:

  • 即若发送方发送的分组1校验失败,则接收方发送ACK0表示收到分组0,未收到分组1,因此发送方将重新发送分组1。特别地,若第一个分组未收到,则发送ACK1,代表校验失败。

E. RDT3.0:完备的停止等待(stop and wait)协议
  • 上述的RDT2.1和RDT2.2协议虽然解决了ACK和NAK在传输过程中发生错误的问题,但由第一章中分组交换的知识知道:当中间交换节点队满时,到来的分组会直接被丢失,使得丢包的出现。

  • 若线路出现丢包,发送方处于等待回复的状态,而接收方处于等待分组的状态,那么系统又会进入死锁的状态中,需要新的机制打破死锁。

  • RDT3.0中采用了超时重传的机制打破上述的死锁,发送方在发送了分组之后开始计时,当时间超过设定的时间后,则重新发送该分组。【超时时间如何计算将在TCP协议部分进行详述】

  • RDT3.0的有限状态机如下两图所示:

  • 需要特别说明的是,上面⭐A的部分,A部分代表什么都不干。可能你会有问题:在前面协议RDT2.1里面,如果收到了NAK或者是收到了错误的回复,不是应该要重传该报文吗?为什么这里啥也不干呢?

  • 其实,这里有点版本兼容性的原因,在RDT3.0中,采用了超时重传的机制,因此不论什么情况,只要达到超时时间,都需要重传分组。因此,在收到拒绝或者错误的回复时,RDT3.0协议不急着立马重传,而是等着超时时间到再重传。

  • 为了理解更加深入,我们再就着上面的有限状态机推演一遍停止等待协议的循环:

  1. 首先应用层调用原语要发送分组0,则发送端保存分组0的副本,并向接收端发送数据+校验和+分组序号0。发送端进入等待回复0的状态。

  1. 接收端接收到分组0,校验正确,并向发送端发送ACK0的回复,将分组0解封装,解复用后发送给应用层应用进程。接收端进入等待分组1的状态。

  1. 接收端发送的ACK0在传输过程中发生错误,传送到发送端,发送端啥也不干,等着超时事件的到来。

  1. 超时时间到,发送端重新发送分组0,并重新开始计时,继续进入等待回复0的状态。

  1. 接收端再次收到分组0,校验通过,于是接收端将分组直接丢弃,并向发送端发送ACK0。

  1. 成功接收到ACK0后,发送端停止计时,并进入等待应用层调用发送分组1的请求,循环完成。

F. Pipeline流水线协议
  • 停止等待协议是每次发送一个分组,并且等待收到正确回复之后才能发送第二个分组,这种方式在局域网还能凑活,如果到了广域网就明显效率太低了,就像华南快速干线每次只能通过一辆车,这辆车走完了才允许第二辆车走,明显不行。

  • 我们做一个小计算:现有发送方Sender与接收方Receiver建立了联系,两者建立联系的往返延时RTT = 30ms,现有报文的大小为L = 1000kB = 8000kbits,网络带宽为R = 1Gbps。则发送时延为t = L/R = 8μs,因此,网络的利用率为:

  • 因此,对于较大型的网络,流水线协议非常有必要

F1. 滑动窗口协议(Sliding Window)
  • 发送缓冲区与发送窗口

  • 首先,在前面讲到分组交换的时候我们曾提到过发送缓冲区,用来保存要发送的分组,如果发送缓冲区满,那么后来的数据分组将被直接抛弃,造成丢包。

  • 而发送窗口是发送缓冲区的子集,是可以发送的数据。例如发送缓冲区可以存储10个数据分组,而发送缓冲区的最大尺寸为4。因此对于报文0,1,2,3而言,可以直接发送,而报文4则需要等待

  • 发送窗口类似于一个队列,有头尾两个指针,初始状态头尾指针同时指向发送缓冲区的头部,当应用层发送来一个报文,头指针前移,尾指针不变【在发送窗口不超过最大值的情况下,循环上述操作】

  • 在发送窗口内的报文可以发送,发送却未收到回复的报文依旧保留在发送窗口中,并用超时重传定时器控制是否需要重发(不同协议的定时器设置不同),如果发送窗口的分组得到正确的确认,那么发送窗口尾指针后移。

  • 旧的分组完成正确确认,新的分组可以进入发送窗口中,实现发送窗口的滑动。且由于发送缓冲区的大小是有限的,因而双指针在滑动的过程中需要进行取模的操作【类似循环队列的操作】

  • 接收窗口

  • 接收窗口限定了网络可以同时接收的分组的数目,如果接收窗口的大小为1,那么发送方发送的数据必须顺序到达,而如果接受窗口大于1,那么允许发送方发送的数据乱序到达

  • Sliding Window与Stop and wait``Go Back N以及Selective Repeat

  • 发送窗口的大小为:SW,接收窗口的大小为RW

  1. SW = 1 && RW = 1:停止等待协议Stop and wait

  1. SW > 1 && RW = 1:回退N步协议Go Back N

  1. SW = 1 && RW = 1:选择性重传Selective Repeat

F2. 回退N步协议(Go Back N)
  • 发送窗口大小大于1,接收窗口值等于1

  • 发送端发送窗口内的所有报文(P0,P1,P2),并打开超时重传定时器【GBN协议只维持一个超时重传定时器】。接收端的接收窗口等待接收P0

  • 如果发送端P0最早到达,那么接收端将返回ACK0,代表P0接收成功,并将接收窗口移动到P1

  • 如果发送端成功接收到ACK0,那么发送端将定时器重新开始计时,并将发送窗口后移一位,可以发送新的分组

  • 但是,分组1在传输过程中丢包了,因而发送端发送的分组P2比P1先到达接收端,接收端接收到P2分组,返回ACK0,代表没有接收到期望的分组P1,发送窗口不动,继续等包裹

  • 此时,发送端接又一次收到了ACK0,重启计时,并且等着超时。到了超时时间,发送端就把从P1开始的所有分组又重新发出去,重新计时,等待ACK1的到来

  • GBN协议的有限状态机如下图所示:

F3. 选择性重传协议(Selective Repeat)
  • 发送窗口和接收窗口都大于1

  • 允许出现传输的乱序,并可以利用接收窗口的容量实现乱序分组的纠正

  • 选择性重传协议的示意图如下:

  • 我们跟着上图推演一下过程,深入理解协议的过程:

  1. 首先发送方向接收方发送分组P0,P1,P2,P3,其中,P0,P2,P3都正常传递,而P1在传递的过程中发生的丢包

  1. 因此,接收端最先接收到分组P0,则直接将P0解封装上交给应用进程,并将接收窗口后移一位

  1. 由于分组P1丢包,因此接收端无法收到该分组,但可以正常接收分组P2和P3。但是在接收了分组P2和P3之后,接收端并不解封装上交,而是等着P1分组的到来。并且向发送端发送确认报文ACK2和ACK3,那么确认报文ACK2和ACK3会让发送端的P2,P3对应的超时重传定时器停止计时。

  1. 分组1丢包必然导致P1对应的超时重传定时器到时,因而发送方会重传P1分组。该分组成功传达后,接收端会对P1,P2,P3进行解封装,并将三个分组称递给应用进程,实现顺序的纠正

G. GBN与SR协议的对比
  • GBN协议维持一个超时重传定时器,但是遇到超时的情况需要将发送区内的所有内容都发送出去

  • SR协议维持多个超时重传定时器,遇到超时的情况可以有针对性地发送不能正常传递的分组

  • GBN协议较简单,但出错的代价比较大,因此适合于出错几率比较低的网络

  • SR的协议较复杂一些,但是出错的代价小,因而适合于比较容易出现传输乱序的网络

3.5 TCP协议

  • 由于需要建立连接,仅能提供一对一的服务,而UDP可以提供一对多,多对多的服务

  • TCP是面向字节流的协议,而UDP是面向报文的协议,TCP不维护报文的界限,而是将报文切成一个个MSS:Max Segment Size大小的报文段

  • TCP是流水线形式的;且为了匹配发送和接收的速率,设置发送和接收缓存;且全双工通信,即发送和接收是同时同步进行的

  • TCP具有流量控制和拥塞控制

A. MSS最大报文段大小
  • 对于任何物理网络,都具有MTU:Max Transfer Unit最大传输端元。对于以太网而言,最大的数据传输单元的大小是1500Bytes

  • 而每一个报文段需要加上TCP头部以及IP头部需要恰好可以封装成帧的载荷部分

  • 而TCP头部和IP头部都是20Bytes因此MSS为1460

B. TCP报文结构
  • 序号(以字节为单位):序号和前面RDT中的PDU序号是不一样的,TCP报文中的序号是每个MSS的第一个字节相对整个字节流首位的偏移量

  • 两个应用进程在建立TCP连接时初始的字节号不是为0的,因为需要防止滞留在网络中的分组对其造成影响

  • 确认号ACK(以字节为单位):确认号的含义:如对方发回来的ACK=555,代表我已经收到了554以及以前的所有字节,期待你从555字节开始发送。这个定义和我们讲RDT时候的定义是不太一样的

  • 用一个例子在加深序号Seq与确认号ACK:

C. TCP超时定时器时间的设置
  • 超时时间太短,会使得分组出现没有必要的重发;超时时间太长,会使得网络过于消极,等待时间太长

  • 且对于多跳的网络,其超时时间波动较大,即概率密度函数较为矮胖,难以挑一个固定的时间,但是对于每一个短的时间而言,其分布比较集中,概率密度函数比较高瘦,可以选出一个合适的值,因此要采用一个适应式的时间设定策略

  • 上一时刻的平均往返时延为EstimateRTT0,本时刻测定其中一个分组的往返延时SampleRTT,因而本时刻平均往返时延为(移动平均值):

  • 上一时刻的偏差为DevRTT0,本时刻的偏差为|SampleRTT-EstimateRTT1|,因此同样由滑动平均的策略可以得出本时刻的往返时延偏差(可以认为是方差):

  • 因此我们设定的超时时间间隔为(类似概率中的3σ原则):

D. TCP的可靠数据传输
  • TCP的RDT是GBN与SR协议的混合体

  • TCP采用累计确认的方式,而不是逐段确认

  • TCP仅设置一个定时器,这一点和GBN协议是一样的

  • 但是TCP定时器是随着最老的段发出开始计时的,而当定时器到时,TCP协议会仅将最老的段发出,而不是把窗口内所有报文发出,这一点和SR协议很像

  • 如果TCP收到了乱序报文段,报文段怎么处理是可以自定义的。像GBN一样抛弃,或者像SR一样存下来都可以

D1. TCP的重传机制
  • 如果超时定时器到时,肯定要重传

  • 如果在收到一个正确的报文段确认后,又收到三个冗余的报文段确认,而超时时间依然没到,那么会进行快速重传。

  • 也就是发送端发送了P0,P1,P2,P3,P4,P0报文段正常送达,但是P1丢包了,P2,P3,P4都陆续送到,因此又传回了三个冗余的确认,因此,TCP启动快速重传机制,传出发送窗口中最老的一个报文P1

D2. TCP的有限状态机(不包括流量和拥塞控制)
  • 在收到ACK的部分,实际的TCP协议会加入快速重传算法,快速重传前文已经讲解,不再赘述

E. TCP的流量控制
  • 发送方发送的文件速度太快,而接收方处理不过来

  • TCP报文的头部有一个Receive Window的字段,通过报文返回,发送方即可得知现在接收方接收窗口的大小,并可以以此来控制发送方发送窗口的大小。发送窗口的计算公式如下:

  • 其中,SendWindow是发送窗口的大小,ReceiveWindow是接收窗口的大小,CongestionWindow是拥塞窗口的大小

  • 接收窗口的计算公式如下:

  • 其中,RcvBuffer是原始整个接收窗口的大小,LastByteRcv-LastByteRead是已经占用的接收窗口大小,LastByteRcv是最近收到的最后一个字节,LastByteRead是最近完成读取的最后一个字节

  • 捎带技术Piggybacking:捎带技术就是把数据和确认信息合并在一起(相当于农夫1给农夫2送了一头🐖,农夫2会送给农夫1送回一头🐏,并且在🐏屁股上贴一张纸条,说我已经收到你的🐖了【确认ACK】,我的农场还要5头🐖的位置【接收窗口大小】)

F. 连接管理:连接建立+连接拆除
F1. 两次握手可以吗?
  • 两次握手即连接请求+连接建立有什么问题呢?

  • 两次握手失败的场景如下图所示:

  • 上图左边的情况,如果仅有两次握手,那么服务器端必定在接收到请求报文之后就会进入连接状态,同时发回连接确认报文。这就造成了服务器先进入连接状态,而用户后进入连接状态,那么如果连接确认报文传输有误,或者连接请求报文超时重传,而在重传的过程中连接被用户断掉了,就有可能出现只有服务器在傻傻地处于连接状态【半连接】,而用户其实并没有维持连接状态

  • 右边的失败情景也是由于服务器先进入连接状态,而把旧的数据当成新的数据接收了

F2. 三次握手
  1. TCP三次握手的示意图:

  1. TCP解决两次挥手的失败情景:

  • 对于可能存在的半连接情况:服务器端接收到迟到的连接请求,并发回连接确认,此时这个连接确认会直接被客户端拒绝

  • 对于可能存在旧数据被当成新数据接收的情况,由于连接根本没有建立起来,所以当然不会接收该数据

  1. 诡异的可能失败情景以及解决办法:

  • 对于上述右边情况,可能会存在一种更诡异的情形:假定客户端的端口为555,服务器的端口为80,第一次连接建立,有一个报文(图中的data(x+1))一直在网络里面飘。等到第二次客户端又以555端口与服务器的80端口建立连接,那个报文才到,这就有旧报文被当成新的报文接收的风险。

  • 解决:我们不选择固定的值作为序号,而是随机选择一个32位比特作为序号的开始【可能利用时间作为随机数产生器】,这样可以最大程度避免老数据对新连接的影响

F3. 连接结束(四次挥手)
  • 分两个方向进行连接拆除

  • 首先,客户端向服务器发起连接拆除,服务器回复确认,那么就没有数据从用户传递给服务器了,但服务器还可能有数据传回来客户端

  • 接着,服务器也传完了数据,那么就再次向客户端发来连接拆除请求,得到客户端的确认,之后没有数据从服务器传给客户端,整个连接完全拆除

  • 依然不完美,存在两军问题,都有可能存在一方维持连接的问题

3.6 拥塞控制

A. 拥塞控制与流量控制的区别
  • 流量控制是我和你的问题,即发送方与接收方的问题

  • 而拥塞控制是针对公共网络的控制

  • 就像某博物馆一天只能容纳100人,而一个学校一个年级10000人,那么流量控制就是学校每天只能有100人去博物馆,而拥塞控制则是这100个人在去往博物馆的图中尽量不要遇到塞车等情况

B. 网络拥塞的原理
  • 网络拥塞的表现1:延时特别大(当流量强度->1时,排队延时->+∞)

  • 由第一章的排队延时与流量强度的关系可以知道,当网络阻塞程度增加,流量强度I->1因此延时t_queue->+∞

  • 网络拥塞的表现2:降低了goodput,为了达到有效的输出,我得输入更多的数据(因为超时重传的比例越来越大)。而且造成重复,由于网络延时急剧增加,因此非常多的分组原本并没有丢,但是都进行了重发,导致严重的重复,进而拥塞的情况越来越严重,相当于一个正反馈

  • 网络拥塞的表现3:网络死锁+浪费上游传输能力

  • 在上图可以发现,当红色流量处于上游的时候(就是红色流量刚刚发出,流量最大,竞争力最强的时候),与之竞争的是蓝色的下游流量【上面的路由器】,因此红色流量竞争力大,导致蓝色流量大量丢包

  • 同样到了红色流量的下游路由器【右边的路由器】,红色流量减小,竞争力减小,而恰好遇到绿色的上游流量,因此红色流量丢包率大大上升。

  • 其他的流量也是如此,整个网络进入死锁,上游流量传输到下游被大量丢包

C. 拥塞控制方法
C1. 端到端的拥塞控制方法(TCP)
  • 端系统自身判断网络是否发生拥塞

  • TCP依靠如分组丢包,冗余确认等指标进行判断

C2. 网络辅助信息的拥塞控制
  • 网络核心会提供拥塞信息给端系统

  • 端系统根据信息控制发送

D.ATM异步传输网络的拥塞控制方法(网络辅助信息拥塞控制)
  • ATM网络的数据单位是信元(短小53Byte)

  • 线路交换的每个节点消耗1Byte的时间,而分组交换在每个节点消耗1分组的时间(1个分组通常1000+字节),因而ATM网路介于两者之间

  • ABR:Available Bit Rate,例如ATM网路的正常带宽是1Mbps,那么在不发生拥塞的时候可以尽可能发送,而发生拥塞的时候,必须控制发送的速度不能超过1Mbps

  • 信元分成两类,数据信元以及资源管理RM信元,RM信元中有NI bit:No Increase in rate轻微拥塞信元以及CI bit:Congestion Indication拥塞指示信元,ATM交换设备发现网路出现拥塞的情况,那么会将报文的对应位置位,因此就可以让端主机知道网络的拥塞情况

  • 且资源管理信元中还有ER:Explicit Rate字段,代表网络可以为该对连接提供多少带宽,信元每次经过交换设备,交换设备会将可以提供的带宽与现有的ER字段的值进行对比,如果比现有的值小,那么就存入作为新的ER值

3.7 TCP拥塞控制(端到端拥塞控制)

  • 网络辅助信息拥塞控制的不足:网络交换设备的负担较大,对于大型网络,成本开销很大

  • 而TCP协议的端到端拥塞控制,将最复杂的部分放在网络边缘,而网络核心部分采用最简单的设计

A. 如何检测拥塞?
  • 超时时间的发生【拥塞】:超时说明网络发生拥塞,延时增大,此时应该降低发送速度;也可能是分组在传输过程中受到干扰,导致出错,无法通过校验和的校验,此时不应该降低发送网络,但是这种情况发生的概率是非常低的,所以问题不大

  • 冗余确认【轻微拥塞】:某一个分段丢了,但后面的几个段都顺利到达了,说明拥塞传不到的情况还不是很普遍,因此是轻微拥塞【冗余确认与快速重传算法见前面TCP网络部分】

B. 如何控制发送速率?
  • 在发送端维持了一个变量,rate是拥塞控制的速度,CongWin是在对方未确认的情况下可以向网络注入多少字节

  • 超时或者3个重复ACK,CongWin↓

  • 超时:CongWin降为1MSS,在SS慢启动阶段,然后倍增到CongWin/2(每个RTT),然后进入CA阶段

  • 3个重复ACK:CongWin降低为CongWin/2,进入CA拥塞避免阶段

  • 正常收到ACK的时候,CongWin↑

  • SS:Slow Start慢启动阶段:每个RTT,拥塞窗口值CongWin加倍

  • CA:Congestion Avoidence拥塞避免阶段:每个RTT,拥塞窗口值CongWin线性增加

C. TCP拥塞控制与流量控制联合控制动作
  • 发送窗口的大小由空闲缓冲区(接收窗口值)以及拥塞窗口值的大小限定 ,可以同时满足拥塞控制和流量控制的要求

D. 拥塞控制策略
  • 慢启动

  • TCP建立的时候,CongWin设定为1MSS

  • 每受到一个确认,拥塞窗口值CongWin+1,也就是每一轮(每个RTT)CongWin翻倍

  • 翻倍的CongWin很快就会导致超时,假设超时的阈值为CongWin_0,那么超时之后,将CongWin = 1并且将CongWin_0/2作为警戒值,在[CongWin_0/2,CongWin_0]区间内进行拥塞避免阶段,在拥塞避免阶段即不能再翻倍了

  • 线性增加,乘性减小

  • 由拥塞控制决定的平均吞吐量(忽略慢启动阶段的时间),拥塞窗口值为W:

E. TCP的公平性
  • 情况一:AA'和BB'是两对主机,都建立了一对TCP连接,而且两者的往返时延是相同的,其中有一段主干链路都是两者的带宽瓶颈链路,且其带宽为Rbps,那么两者是公平享有一半的带宽的

  • 根据上面的图可以发现,每当AA'和BB'发生超时事件,AA'和BB'都会减半,朝着AA'和BB'相等的方向发展,最终达成公平

  • 情况二:AA'采用TCP协议进行通信,BB'采用UDP连接

  • 此情况是不公平的,因为TCP协议是有流量控制和拥塞控制的,但是UDP是没有的,因而UDP对带宽具有极强的侵略性,占据很大的带宽

  • 情况三:AA'中建立了9对TCP连接,而BB'只建立了1对TCP连接,两者的往返时延相同

  • 那AA'将占用0.9的带宽,BB'只占用0.1的带宽

  • 情况四:AA'与BB'都只建立了一对TCP连接,但是AA'的往返时延短一些

  • 根据上面吞吐量的公式,显然有AA'占据的带宽要大一些

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/186414.html

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!

相关文章

b站黑马Vue2后台管理项目笔记——(3)用户列表

说明: 此项目中使用的是本地SQL数据库,Vue2。 其他功能请见本人后续的其他相关文章。 本文内容实现的最终效果如下图: 三.用户列表的开发 目标效果: 点击二级菜单——用户列表,在右侧展示用户列表对应的内容&#xf…

羊了个羊,低配纯前端实现,代码开源

各位朋友们大家好,我是克隆窝。 我属实被“羊了个羊”气到了,就是通不过第二关,迫不得已自己弄了个网页版的“鱼了个鱼” 游戏的玩法非常简单,类似 “消消乐”,从一堆方块中找到相同图案的 3 个方块并消除即可。 文末…

火山引擎边缘计算在云边协同方面的探索与实践

作者:杜怀宇近期,由边缘计算产业联盟(ECC)主办的2022边缘计算产业峰会(ECIS2022)以云端直播形式成功举办,峰会以“边云智联 助力行业数字化转型”为主题,汇聚来自全球的商业领袖、国…

JavaScript基础复盘1

JS有三种书写位置,分别为行内,内嵌和外部。 注意,引用外部JS文件,script双标签内部不可以写代码了。 JavaScript输入输出语句 变量 变量的使用 变量再使用时分为两步:1.声明变量 2.赋值 实现用JavaScript接受用户输入…

最近公共祖先

最近公共祖先(Lowest Common Ancestor,LCA) 指两个点的公共祖先中,离根最远/深度最深的 性质: 1.LCA({u})uLCA\left(\left\{u\right\}\right) uLCA({u})u 2.若uuu是vvv的祖先,当且仅当LCA(u,v)uLCA\left(…

[Lua实战]Skynet-1.如何启动(linux环境启动)[开箱可用]

Skynet-如何启动1.依赖环境:可登录&联网的linux(Centos7)系统(可以是虚拟机)2.yum安装依赖库3.git clone skynet项目4.编译skynet4.1有可能遇到的错误(升级gcc到4.9以上即可解决):5.测试运行skynet6.运行结果最近用到了lua,想了解下云风大神的skynet,在网上看了半天也没入门…

Spire.Pdf for Java v9.1.4 Patcher

Spire.PDF for Java是一种 PDF API,它使 Java 应用程序无需使用第三方SDK 即可读取、写入和保存 PDF 文档。使用这个 Java PDF 组件,开发人员和程序员可以实现丰富的功能,从头开始创建 PDF 文件或完全在 Java 应用程序(J2SE 和 J2…

leetcode刷题记录总结-7.二叉树

文章目录零、二叉树理论二叉树的种类满二叉树完全二叉树二叉搜索树平衡二叉搜索树二叉树的存储方式二叉树的遍历方式二叉树的定义总结一、二叉树的遍历[144. 二叉树的前序遍历 ](https://leetcode.cn/problems/binary-tree-preorder-traversal/)题解递归实现迭代实现[94. 二叉树…

如何运营企业网站

企业网站的最终目的是给企业带来效益,树立企业形象。只要有这个目标定位,剩下的工作就是围绕这个定位去做和优化,米贸搜整理如下:1.增强被收录页面的重要性。收录页面的提升不仅仅是数量的提升,质量占据了很高的比重。…

网络安全协议

作者简介:一名云计算网络运维人员、每天分享网络与运维的技术与干货。 座右铭:低头赶路,敬事如仪 个人主页:网络豆的主页​​​​​​ 前言 本章将会进行网络安全协议的讲解 一.网络安全 1.什么是网络安全 网络安全&#xff…

导数的概念——“高等数学”

各位CSDN的uu们你们好呀,今天小雅兰的内容是导数的概念,其实在高中时期,我们就已经接触过导数了,但是那个时候学得并不是特别深入,依稀记得,我们当初的导数大题一般都是压轴题,很多学校每次讲解…

Oracle重写sql经典50题(代码)

上次发表的是写的时候遇到的问题,这次备份一下自己的代码(很冗余,也不保证正确率) mysql50题链接在此 Oracle重写sql经典50题创建数据库和表oracle数据库一个账户就一个库,不需要创建学生表 student创建学生表 student插入学生数据…

A-Star算法探索和实现(五)

本篇摘要在上一篇中我们对寻路的移动规则进行了制定,而在本篇我们将对最佳路径的查找方式进行优化,而这就会涉及到移动规则的检测改进、权值计算的改进、NextNode集的处理改进、寻路逻辑的改进,我们将从上述四个方面进行详细讲解。方案探讨&a…

3.堆排序和比较器

1. 堆 堆结构就是用数组实现的完全二叉树结构,对于结点i,左孩子2*i1、右孩子2*i2、父节点(i-1)/ 2。 完全二叉树中如果每棵子树的最大值都在顶部就是大根堆 完全二叉树中如果每棵子树的最小值都在顶部就是小根堆堆结构的heapInse…

【C++算法图解专栏】一篇文章带你入门二分算法

✍个人博客:https://blog.csdn.net/Newin2020?spm1011.2415.3001.5343 📣专栏定位:为 0 基础刚入门数据结构与算法的小伙伴提供详细的讲解,也欢迎大佬们一起交流~ 📚专栏地址:https://blog.csdn.net/Newin…

步进式PID控制算法及仿真

在较大阶跃响应时,很容易产生超调。采用步进式积分分离PID控制,该方法不直接对阶跃信号进行响应,而是使输入指令信号一步一步地逼近所要求的阶跃信号,可使对象运行平稳,适用于高精度伺服系统的位置跟踪。在步进式PID控…

【数据手册】CH340G芯片使用介绍

1.概述 CH340是一系列USB总线适配器,它通过USB总线提供串行、并行或IrDA接口。CH340G集成电路提供通用的MODEM信号,允许将UART添加到计算机上,或将现有的UART设备转换为USB接口。 2.特征 全速USB接口,兼容USB 2.0接口。使用最小…

Android核心技术【SystemServer加载AMS】

启动流程 Init 初始化Linux 层,处理部分服务 挂载和创建系统文件 解析rc文件: rc 文件中有很多action 进入无限循环 执行action:zygote 进程就在这里启动 for循环去解析参数,根据rc 文件中的action 执行相应操作 检测并重启需要…

细谈文件操作

该文章将详细的介绍文件操作这方面的知识,文件的打开,关闭,读取,写入,以及相关的函数都会在本文一一介绍,干货满满喔!1.为什么使用文件2.什么是文件2.1程序文件2.2数据文件2.3文件名3.文件的打开…

SpringBoot(java)操作elasticsearch

elasticsearch我已经装了ik,中文分词器。已经使用容器搭建了集群。之前在我的博客-elasticsearch入门中,已经介绍了http请求操纵es的基本功能,java API功能和他一样,只是从http请求换成了javaApi操作。springBoot里继承了elastics…