TCP可靠传输的实现

TCP可靠传输的实现

TCP基于以字节为单位的滑动窗口来实现可靠传输

下图中发送方的发送窗口为20

image-20220926210017673

假设发送方发送的数据中只有32和33到达了接收方,此时接收方接收32,33,但是因为他们是未按序到达的数据,所以接收方只能对按序收到的数据中的最高序号给出确认,也就是发送ack=31表示希望收到31号数据

image-20220926211943876

接收方返回:ack=31,当发送方收到该重复指令时就知道31丢失了并重新发送

image-20220926212330705

注意:

虽然发送方的发送窗口是根据接收方的接收窗口设置的,但在同一时刻,发送方的发送窗口并不总是和接收方的接收窗口一样大。

  • 网络传送窗口值需要经历一定的时间滞后,并且这个时间还是不确定的。
  • 发送方还可能根据网络当时的拥塞情况适当减小自己的发送窗口尺寸。

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

  • 如果接收方把不按序到达的数据一律丢弃,那么接收窗口的管理将会比较简单,但这样做对网络资源的利用不利,因为发送方会重复传送较多的数据。
  • TCP通常对不按序到达的数据是先临时存放在接收窗口中,等到字节流中所缺少的字节收到后,再按序交付上层的应用进程。

TCP要求接收方必须有累积确认和捎带确认机制,这样可以减小传输开销。接收方可以在合适的时候发送确认,也可以在自己有数据要发送时把确认信息顺便捎带上。

  • 接收方不应过分推迟发送确认,否则会导致发送方不必要的超时重传,这反而浪费了网络的资源。
  • TCP标准规定,确认推迟的时间不应超过0.5秒。若收到一连串具有最大长度的报文段,则必须每隔一个报文段就发送一个确认[RFC 1122].
  • 捎带确认实际上并不经常发生,因为大多数应用程序很少同时在两个方向上发送数据。

TCP的通信是全双工通信。通信中的每一方都在发送和接收报文段。因此,每一方都有自己的发送窗口和接收窗口。在谈到这些窗口时,一定要弄清楚是哪一方的窗口。

猜你喜欢

转载自blog.csdn.net/perturb/article/details/127073353