计算机网络第5章 运输层(下)

《计算机网络(第七版)-谢希仁》 第5章 运输层(下)

TCP协议 相关内容详细介绍

TCP可靠传输的实现

假定数据传输只在一个方向进行

以字节为单位的滑动窗口

发送窗口表示:在没有收到B的确认的情况下,A 可以连续把窗口内的数据都发送出去。凡是已经发送过的数据,在未收到确认之前都必须暂时保留,以便在超时重传时使用。

发送窗口后沿的变化情况有两种可能,即不动(没有收到新的确认)和前移(收到了新的确认)。

这里写图片描述

  • 第一,虽然A的发送窗口是根据B的接收窗口设置的,但在同一时刻,A的发送窗口并不总是和B的接收窗口一样大,时间滞后和拥塞

  • 第二,对于不按序到达的数据应如何处理,TCP标准并无明确规定。

    通常对不按序到达的数据是先临时存 放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。

  • 第三,TCP要求接收方必须有累积确认的功能,这样可以减小传输开销。TCP标准规定,确认推迟的时间不应超过0.5秒。

超时重传时间的选择

TCP采用了一种自适应算法设置超时重传时间。

TCP采用了一种自适应算法,它记录一个报文段发出的时间,以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了 RTT的一个加权平均往返时间RTT~S~ (这又称为平滑的往返时间,S表示Smoothed。因为进行的是加权平均,因此得出的结果更加平滑)。每当第一次测量到RTT样本时,RTT~S~值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本,就按下式重新计算一次RTT~S~ :

己成为建议标准的RFC 6298推荐 的a值为1/8,即0.125

超时计时器设置的超时重传时间RTO (RetransmissionTime-Out)应略大于上面得 出的加权平均往返时间RTTs。RFC 6298建议使用下式计算RTO:

RTT~D~是RTT的偏差的加权平均值,它与RTTS和新的RTT样本之差有关。RFC 6298建议这样计算RTT~D~。当第一次测量时,RTT~D~值取为测量到的RTT样本值的一半。在 以后的测量中,则使用下式计算加权平均的RTT~D~:

这里β是个小于1的系数,它的推荐值是1/4,即0.25。

Kam提出了一个算法:在计算加权平均RTTS时,只要报文段重传 了,就不采用其往返时间样本。这样得出的加权平均RTTS和RTO就较准确。

对Kam算法进行修正。方法是:报文段每重传一次,就把超时重传时间RTO增 大一些。典型的做法是取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时,才根据上面给出的公式计算超时重传时间。

选择确认SACK

若收到的报文段无差错,只是未按序号,中间还缺少一些序号的数据,只传送缺少的数据而不重传已经正确到达接收方的数 据选择确认就是一种可行的处理方法。

TCP的首部没有哪个字段能够提供上述这些字节块的边界信息。RFC 2018 规定,如果要使用选择确认SACK,那么在建立TCP连接时,就要在TCP首部的选项中加 上“允许SACK”的选项,而双方必须都事先商定好。

SACK文档并没有指明发送方应当怎样响应SACK。因此大多数的实现还是重传所有未被确认的数据块。

TCP的流量控制

利用滑动窗口实现流量控制

所谓流量控制(flow control)就是让发送方的发送速率不要太快,要让接收方来得及接收。

设A向B发送数据。在连接建立时,B告诉了 A: “我的接收窗口 rwnd = 400”(这里 rwnd表示receiver window)。因此,发送方的发送窗口不能超过接收方给出的接收窗口的数值。请注意,TCP的窗口单位是字节,不是报文段。

图中箭头上面大写ACK表示首部中的确认位ACK,小写ack表示确认字段的值。

TCP为每一个连接设有一个持续计时器(persistence timer)。只要TCP连接的一方收到对方的零窗口通知,就启动持续计时器。若持续计时器设置的时间到期,就发送一个零窗口探测报文段(仅携带1字节的数据),而对方就在确认这个探测报文段时给出了现在的窗口值。如果窗口仍然是零,那么收到这个报文段的一方就重新设置持续计时器。

TCP的传输效率

控制TCP报文段的发送机制

  • 第一种机制是TCP维持一个变量,它等于最大报文段长度MSS。只要缓存中存放的数据达到MSS字节时,就组装成一个TCP报文段发送出去。
  • 第二种机制是由发送方的应用进程指明要求发送报文段,即TCP支持的推送(push)操作。
  • 第三种机制是发送方的一个计时器期限到了,这时就把当前己有的缓存数据装入报文段(但长度不能超过MSS)发送出去。

Nagle算法

若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存,则发送方就把第一个数据字节先发送出去,把后面到达的数据字节都缓存起来。

当发送方收到对第一个数据字符的确认后,再把发送缓存中的所有数据组装成一个报文段发送出去,同时继续对随后到达的数据进行缓存。

只有在收到对前一个报文段的确认后才继续发送下一个报文段。

当数据到达较快而网络速率较慢时,用这样的方法可明显地减少所用的网络带宽。

Nagle算法还规定,当到达的数据己达到发送窗口大小的一半或己达到报文段的最大长度时,就立即发送一个报文段。这样做,就可以有效地提高网络的吞吐量。

糊涂窗口综合征(silly window syndrome)

要解决这个问题,可以让接收方等待一段时间,使得或者接收缓存已有足够空间容纳一个最长的报文段,或者等到接收缓存已有一半空闲的空间。只要出现这两种情况之一,接收方就发出确认报文,并向发送方通知当前的窗口大小。此外,发送方也不要发送太小的报文段,而是把数据积累成足够大的报文段,或达到接收方缓存的空间的一半大小。

TCP的拥塞控制

拥塞(congestion)

拥塞控制:防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不致过载。

拥塞控制所要做的都有一个前提,就是网络能够承受现有的网络负荷。

拥塞控制是一个全局性的过程,涉及到所有的主机、所有的路由器,以及与降低网络传输性能有关的所有因素。

流量控制往往是指点对点通信量的控制,是个端到端的问题(接收端控制发送端)。流量控制所要做的就是抑制发送端发送数据的速率,以便使接收端来得及接收。

TCP的拥塞控制方法

慢开始(slow-start)、拥塞避免(congestion avoidance)、快重传(fast retransmit)和快恢复(fast recovery)

慢开始和拥塞避免

下面讨论的拥塞控制也叫做基于窗口的拥塞控制。为此,发送方维持一个叫做拥塞窗口cwnd (congestion window)的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口

发送方控制拥塞窗口的原则是:只要没有出现拥塞,拥塞窗口就变大一些,只要出现了拥塞,拥塞窗口就小一些。

判断网络拥塞的依据就是出现了超时

慢开始算法:由小到大逐渐增大拥塞窗口数值。

限制初始拥塞窗口的字节数的规则:

  • 若 SMSS>2190 字节,则设置初始拥塞窗口cwnd = 2 x SMSS字节,且不得超过2个报文段。
  • 若(SMSS> 1095 字节)且(SMSSS2190 字节),则设置初始拥塞窗口 cwnd = 3 x SMSS字节,且不得超过3个报文段。
  • 若 SMSS<=1095 字节,则设置初始拥塞窗口 cwnd = 4 x SMSS字节,且不得超过4个报文段。

慢开始规定,在每收到一个对新的报文段的确认后,可以把拥塞窗口增加最多一个SMSS的数值

使用慢开始算法后,每经过一个传输轮次(transmission round),拥塞窗口cwnd就加倍。

在TCP的实际运行中,发送方只要收到一个对新报文段的确认,其拥塞窗口cwnd就立即加1,并可以立即发送新的报文段,而不需要等这个轮次中所有的确认都收到后(如图5-24所示的那样)再发送新的报文段。

为了防止拥塞窗口 cwnd增长过大引起网络拥塞,还需要设置一个慢开始门限ssthresh 状态变量。慢开始门限ssthresh的用法如下:

  • 当cwnd
快重传和快恢复

快重传算法可以让发送方尽早知道发生了个别报文段的丟失。

快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认,而是要立即发送确认,即使收到了失序的报文段也要立即发出对己收到的报文段的重复确认。

快重传

如图所示,接收方没有收到M3但却收到了 M4。按照快重传算法,接收方必须立即发送对M2的重复确认,以便让发送方及早知道接收方没有收到报文段M3。发送方接着发送M5和M6。接收方收到后也仍要再次分别发出对M2的重复确认。这样,发送方共收到了接收方的4个对M2的确认,其中后3个都是重复确认。

快重传算法规定,发送方只要一连收到3个重复确认,就知道接收方确实没有收到报文段M3,因而应当立即进行重传(即“快重传”),这样就不会出现超时,发送方也不就会误认为出现了网络拥塞。使用快重传可以使整个网络的吞吐量提高约20%。

因此,在图5-25中的点❹,发送方知道现在只是丢失了个别的报文段。于是不启动慢开始,而是执行快恢复算法。这是发送发调整门限值ssthresh = cwnd / 2 = 8,同时设置拥塞窗口 cwnd = ssthresh = 8 (见图5-25中的点❺),并开始执行拥塞避免算法。

请注意,也有的快恢复实现是把快恢复开始时的拥塞窗口cwnd值再增大一些(增大3 个报文段的长度),即等于新的ssthresh + 3 x MSS。这样做的理由是:既然发送方收到3个重复的确认,就表明有3个分组已经离开了网络。

在拥塞避免阶段,拥塞窗口是按照线性规律增大的,这常称为加法增大AI (Additive Increase)。而一旦出现超时或3个重复的确认,就要把门限值设置为当前拥塞窗口值的一半,并大大减小拥塞窗口的数值。这常称为“乘法减小” MD(Multiplicative Decrease)。二者合在一起就是所谓的AIMD算法。

接收方窗口 rwnd 和拥塞窗口 cwnd

主动队列管理AQM

AQM实际上就是对路由器中的分组排队进行智能管理,而不是简单地把队列的尾部丢弃。

TCP的运输连接管理

运输连接就有三个阶段:连接建立、数据传送和连接释放

TCP的连接建立

上面给出的连接建立过程叫做三报文握手。

在图中B发送给A的报文段,也可拆成两个报文段。可以先发送一个确认报文段(ACK = 1,ack = x + 1),然后再发送一个同步报文段(SYN=l,seq = y)。这样的过程就变成了四报文握手。

TCP的连接释放

数据传输结束后,通信的双方都可释放连接。现在A和B都处于ESTABLISHED状态 。A的应用进程先向其TCP发出连接释放报文段,并停止再发送数据,主动关闭TCP连接。A把连接释放报文段首部的终止控制位FIN置1,其序号seq = u,它等于前面己传送过的数据的最后一个字节的序号加1。这时A进入FIN-WAIT-1 (终止等待1)状态,等待B的确认。请注意,TCP规定,FIN报文段即使不携带数据,它也消耗掉一个序号。

TCP连接释放

B收到连接释放报文段后即发出确认,确认号是ack = u+1,而这个报文段自己的序号是v,等于B前面已传送过的数据的最后一个字节的序号加1。然后B就进入CLOSE- WAIT (关闭等待)状态。TCP 服务器进程这时应通知高层应用进程,因而从A到B这个方向的连接就释放了,这时的TCP连接处于半关闭(half-dose)状态,即A己经没有数据要发送了,但B若发送数据,A仍要接收。也就是说,从B到A这个方向的连接并未关闭,这个状态可能会持续一段时间。

A收到来自B的确认后,就进入FIN-WAIT-2 (终止等待2)状态,等待B发出的连接释放报文段。

若B己经没有要向A发送的数据,其应用进程就通知TCP释放连接。这时B发出的连接释放报文段必须使FIN = 1。现假定B的序号为w (在半关闭状态B可能又发送了一些数据)。B还必须重复上次己发送过的确认号ack = u+ 1。这时B就进入LAST-ACK (最后确认)状态,等待A的确认。

A在收到B的连接释放报文段后,必须对此发出确认。在确认报文段中把ACK置1,确认号ack = w+l,而自己的序号是seq = u+l (根据TCP标准,前面发送过的FIN报文段要消耗一个序号)。然后进入到TIME-WAIT (时间等待)状态。请注意,现在TCP连接还没有释放掉。必须经过时间等待计时器(TIME-WAIT timer)设置的时间2MSL后,A才进入到CLOSED状态。时间MSL叫做最长报文段寿命(Maximum Segment Lifetime)。

除时间等待计时器外,TCP还设有一个保活计时器(keepalive timer)。客户己主动与服务器建立了TCP连接。但后来客户端的主机突然出故障。服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是两小时。若两小时没有收到客户的数据,服务器就发送一个探测报文段,以后则每隔75秒钟发送一次。若一连发送10个探测报文段后仍无客户的响应,服务器就认为客户端出 了故障,接着就关闭这个连接。

TCP的有限状态机

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值