Bootstrap

TCP可靠传输的工作原理

介绍

在这里插入图片描述

  • IP 网络层所提供的是不可靠的传输
  • TCP发送的报文段是交给伊层传送的,因此,TCP必须采用适当的措施才能使得两个运输层之间的通信变得可靠

理想的传输条件有以下两个特点:

  1. 传输信道不产生差错。
  2. 不管发送方以多快的速度发送数据,接收方总是来得及处理收到的数据。
  • 在这样的理想传输条件下,不需要采取任何措施就能够实现可靠传输。
  • 然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议,在不可靠的传输信道实现可靠传输。

停止等待协议

  • "停止等待"就是每发送完一个分组就停止发送,等待对方的确认。在收到确认后再发送下一个分组。
  • 全双工通信的双方既是发送方也是接收方。
  • 为了讨论问题的方便,我们仅考虑 A 发送数据,而 B 接收数据并发送确认。因此 A 叫做发送方,而 B 叫做接收方。
1. 无差错情况

在这里插入图片描述
A 发送分组 M1,发完就暂停发送,等待 B 的确认 (ACK)。B 收到了 M1 向 A 发送 ACK。A 在收到了对 M1 的确认后,就再发送下一个分组 M2。

2. 出现差错

在这里插入图片描述
在接收方 B 会出现两种情况:

  1. B 接收 M1 时检测出了差错,就丢弃 M1,其他什么也不做(不通知 A 收到有差错的分组)。
  2. M1 在传输过程中丢失了,这时 B 当然什么都不知道,也什么都不做。

在这两种情况下,B 都不会发送任何信息。
但A都必须重发分组,直到B正确接收为止,这样才能实现可靠通信。

问题:A如何知道 B 是否正确收到了 M1 呢?
解决方法:超时重传

  1. A 为每一个已发送的分组都设置了一个超时计时器。
  2. A 只要在超时计时器到期之前收到了相应的确认,就撤销该超时计时器,继续发送下一个分组 M2 。
  3. 若A在超时计时器规定时间内没有收到B的确认,就认为分组错误或丢失,就重发该分组。

问题:若分组正确到达B,但B回送的确认丢失或延迟了,A未收到B的确认,会超时重发。B 可能会收到重复的 M1 。B如何知道收到了重复的分组,需要丢弃呢?
解决方法:编号

  • A为每一个发送的分组都进行编号(每一个TCP报文都含有标识)。若B收到了编号相同的分组,则认为收到了重复分组,丢弃重复的分组,并回送确认
  • B为发送的确认也进行编号,指示该确认是对哪一个分组的确认。
  • A根据确认及其编号,可以确定它是对哪一个分组的确认,避免重发发送。若为重复的确认,则将其丢弃。

需要注意几点

  • A在发送完一个分组后,必须暂时保留已发送的分组的副本(在发生超时重传时使用)。只有在收到相应的确认后才能清除暂时保留的分组副本。
  • 分组和确认分组都必须进行编号。这样才能明确是哪一个发送出去的分组收到了确认,而哪一个分组还没有收到确认。
  • 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些。
3. 确认丢失和确认迟到

在这里插入图片描述

确认丢失

若 B 所发送的对 M1 的确认丢失了,那么 A 在设定的超时重传时间内不能收到确认,但 A 并无法知道:是自己发送的分组出错、丢失了,或者 是 B 发送的确认丢失了。因此 A 在超时计时器到期后就要重传 M1。 假定 B 又收到了重传的分组 M1。这时 B 应采取两个行动:

  • 第一,丢弃这个重复的分组 M1,不向上层交付。
  • 第二,向 A 发送确认。不能认为已经发送过确认就不再发送,因为 A 之所以重传 M1 就表示 A 没有收到对 M1 的确认。

确认丢失

  1. 传输过程中没有出现差错,但 B 对分组 M1 的确认迟到了。
  2. A 会收到重复的确认。对重复的确认的处理很简单:收下后就丢弃。
  3. B 仍然会收到重复的 M1,并且同样要丢弃重复的 M1,并重传确认分组。
  • 通常 A 最终总是可以收到对所有发出的分组的确认。如果 A 不断重传分组但总是收不到确认,就说明通信线路太差,不能进行通信。
  • 使用上述的确认和重传机制,我们就可以在不可靠的传输网络上实现可靠的通信。
  • 像上述的这种可靠传输协议常称为自动重传请求 ARQ (Automatic Repeat reQuest)。意思是重传的请求是自动进行的,接收方不需要请求发送方重传某个出错的分组。
4. 信道利用率

停止等待协议的优点是简单,缺点是信道利用率太低。
在这里插入图片描述

  • A发送分组需要的时间是Td。显然,Td等于分组长度除以数据率。再假定分组正确到达B后,B处理分组的时间可以忽略不计,同时立即发回确认。
  • 假定B发送确认分组需要时间Ta。
  • RTT是往返时间。
  1. 可以看出,当往返时间 RTT 远大于分组发送时间 TD 时,信道的利用率就会非常低。
  2. 若出现重传,则对传送有用的数据信息来说,信道的利用率就还要降低。

流水线传输
在这里插入图片描述

  • 为了提高传输效率,发送方可以不使用低效率的停止等待协议,而是采用流水线传输。
  • 流水线传输就是发送方可连续发送多个分组,不必每发完一个分组就停顿下来等待对方的确认。这样可使信道上一直有数据不间断地传送。
  • 由于信道上一直有数据不间断地传送,这种传输方式可获得很高的信道利用率。

总结停止等待协议要点

  • 停止等待。发送方每次只发送一个分组。在收到确认后再发送下一个分组。
  • 编号。对发送的每个分组和确认都进行编号。
  • 自动重传请求。发送方为每个发送的分组设置一个超时计时器。若超时计时器超时,发送方会自动重传分组。
  • 简单,但信道利用率太低。

连续 ARQ 协议

基本思想:

  • 发送方一次可以发出多个分组。
  • 使用滑动窗口协议控制发送方和接收方所能发送和接收的分组的数量和编号。
  • 每收到一个确认,发送方就把发送窗口向前滑动。
  • 接收方一般采用累积确认的方式。
  • 采用回退N(Go-Back-N)方法进行重传。

累积确认
在这里插入图片描述

  • 接收方一般采用累积确认的方式。即不必对收到的分组逐个发送确认,而是对按序到达的最后一个分组发送确认,这样就表示:到这个分组为止的所有分组都已正确收到了。
  • 优点:容易实现,即使确认丢失也不必重传。
  • 缺点:不能向发送方反映出接收方已经正确收到的所有分组的信息。

Go-back-N(回退 N)
在这里插入图片描述

  • 如果发送方发送了前 5 个分组,而中间的第 3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落,而只好把后面的三个分组都再重传一次。
  • 这就叫做 Go-back-N(回退 N),表示需要再退回来重传已发送过的 N 个分组。
  • 可见当通信线路质量不好时,连续 ARQ 协议会带来负面的影响。

滑动窗口协议

TCP 连接的每一端都必须设有两个窗口—— 一个发送窗口和一个接收窗口。
滑动窗口:
在这里插入图片描述
发送方和接收方分别维持发送窗口和接收窗口
在这里插入图片描述
发送后,在收到确认前,发送窗口会变小
在这里插入图片描述
接收的分组正确,向前滑动接收窗口
在这里插入图片描述
收到确认后,向前滑动发送窗口,窗口变大
在这里插入图片描述

  • 滑动窗口协议比较复杂,是 TCP 协议的精髓所在。
  • 发送方维持的发送窗口,它的意义是:位于发送窗口内的分组都可连续发送出去,而不需要等待对方的确认。这样,信道利用率就提高了。
  • 连续 ARQ 协议规定,发送方每收到一个确认,就把发送窗口向前滑动一个分组的位置。

连续 ARQ 协议与停止等待协议比较

在这里插入图片描述

;