TCP可靠传输的实现

TCP可靠传输的实现从三个方面来说:

1、传输的所有数据都能到达对端

通过32位确认号、超时重传、滑动窗口、拥塞控制等来实现

2、数据不乱序

通过TCP报头中的32位序号可对其保证,序号还可处理重复的报文段

3、数据不出错(不被修改或失真)

通过TCP报头中的16位校验和保证(CRC)。不仅可校验TCP头部,而且可校验数据部分。

下面分别阐述上述提到的机制:

目录

1.滑动窗口

2.超时重传

3.利用滑动窗口进行流量控制

4、TCP的拥塞控制

1.慢开始和拥塞避免

3.快重传和快恢复


1.滑动窗口

TCP的滑动窗口是以字节为单位的。TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。现假定数据传输只在一个方向上进行,即A发送数据,B给出确认。现假定A收到了B发来的确认报文段,其中窗口是20字节,而确认号是31 (这表明B期望收到的下一个序号是31,而序号30为止的数据已经收到了)。根据这两个数据,A就构造出自己的发送窗口,如图5-15所示。

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

发送方发送窗口的大小不能超过接收方接收窗口的大小,并且还要受到当时网络拥塞的制约。

如图,发送窗口后沿的后面部分表示已发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的,因为接收方都没有为这部分数据保留临时存放的缓存空间。

发送窗口的位置由窗口前沿和后沿的位置共同确定。发送窗口后沿的变化情况有两种可能,即不动(没有收到新的确认)和前移(收到了新的确认)。发送窗口后沿不可能向后移动,因为不能撤销掉已收到的确认。发送窗口前沿通常是不断向前移动,但也有可能不动。这对应于两种情况:一 是没有收到新的确认,对方通知的窗口大小也不变;二是收到了新的确认但对方通知的窗口缩小了,使得发送窗口前沿正好不动。

发送窗口前沿也有可能向后收缩。这发生在对方通知的窗口缩小了。但TCP的标准强烈不赞成这样做。因为很可能发送方在收到这个通知以前已经发送了窗口中的许多数据,现在又要收缩窗口,不让发送这些数据,这样就会产生一些错误。

现在假定A发送了序号为31 ~ 41的数据。这时,发送窗口位置并未改变(图5-16),但发送窗口内靠后面有11 个字节(灰色小方框表示)表示已发送但未收到确认。而发送窗口内靠前面的9个字节(42 ~ 50)是允许发送但尚未发送的。

从以上所述可以看出,要描述一个发送窗口的状态需要三个指针: P,P2和P3 (图5-16)。指针都指向字节的序号。这三个指针指向的几个部分的意义如下:

小于P1的是已发送并已收到确认的部分,而大于P3的是不允许发送的部分。

P3-P1=A的发送窗口
P2-P1=已发送但尚未收到确认的字节数
P3-P2=允许发送但当前尚未发送的字节数(又称为可用窗口或有效窗口)

再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面,到30号为止的数据是已经发送过确认,并且已经交付主机了。因此在B可以不再保留这些数据。接收窗口内的序号(31 ~ 50)是允许接收的。在图5-16中,B收到了序号为32和33的数据。这些数据没有按序到达,因为序号为31的数据没有收到( 也许丢失了,也许滞留在网络中的某处)。请注意,B只能对按序收到的数据中的最高序号给出确认,因此B发送的

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值