TCP 滑动窗口停等与多路径传输

这篇具有很好参考价值的文章主要介绍了TCP 滑动窗口停等与多路径传输。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

滑动窗口停等与多路径乱序传输天然不容。

多路径传输,每条路径对数据的接收是平等的,因此乱序是自然的,如果 receiver 从某条路径收到了不连续数据,回sack 吗?如果不回,回什么?如果回,sender 会频繁误解,切换拥塞状态机。

而 mptcp 则将简单问题复杂化了,它明显是把一条 flow 拆分成了多条 subflow,每一条 subflow 依然会有同样问题,规模小些罢了。

同样的,flowlet 方案也是小改,算是时间版本的 mptcp,在一个相对大但又足够小的时间窗口中乱序传输,保证 receiver 按序接收,和 mptcp 一样,依然还是没有摆脱 flow 的本质。

原罪在于 tcp 一开始那个基于停等的滑动窗口,它产生了积累确认,而积累确认必须要求保序,这就是 flow 的起源。但在多路径传输时,保序到达才最不自然,它只是诸多种数据到达方式排列组合中的一种,并不特殊,这得多小的概率啊。

去掉积累确认,完全 sack 就是了,多路径 nak 可能更复杂,因为这条路径的 hole,可能被别的路径补了。sack 反而可以各自顾各自,因为除非报文被复制,否则不会收到多次。

再说数据的交付接收。

流式接收同样不自然,即便流式应用,其流语义也只有应用本身最了解,组装及丢弃工作应由应用本身负责,而不是传输层无条件流式交付。

这也许因为在 tcp 初始时期只有块文件传输和远程登录传输两种流式应用,而原罪则是 bsd socket 接口,直到现在 rcv 接口依然是一小块一小块接收,socket 下面几乎只有 tcp 和 udp(不抬杠,肯定有别的,但都很别扭,特别对于多路径逻辑,非常不好用)。自然的方式应该像 rdma 那样,而内存倒也未必必须连续,重组工作解耦给 cpu 即可,执行一个插入(目前 ofo 队列就是这样管理),传输层本身不必操心。

“套接” 实际上是英文单词 “socket” 的直接翻译,它是指将两个东西联结在一起的过程,一般描述的是针对某种物体或设备而言。进程间通信其实没有必要抽象到如此地步。我们知道,分组交换的数据报通信需要先将数据报装进 “箱子”,再将箱子放进 “管子” 里,套接字直接抽象到了管子层次,也就不在乎放进管子里的是箱子还是散货了。事实上,只要抽象到箱子就够了,甚至散货本身(rdma 即是如此),这样多路径乱序传输就是自然而然的了。

但现实不似你所愿,即使端到端协议支持多路径乱序,ip 路由也难支持,大概率所有这些 “逻辑多路径” 会被ip路由收敛到现实中同一条路径,经历相同的拥塞。ecmp 也解决不了问题而只能缓解。

说了这么多,还是老话重复,应用的流抽象不必在传输中被保证,参见 现代操作系统和 TCP/IP(第二篇) 以及 mapreduce 逻辑。不自然的逻辑在我们看来竟然如此自然,因为一开始 tcp/ip 选择了不自然的方式,而这一切竟然都是历史(电路交换)的包袱。

这是一则在路上发的朋友圈,但有点长了,写成一篇文字吧。

浙江温州皮鞋湿,下雨进水不会胖。文章来源地址https://www.toymoban.com/news/detail-463312.html

到了这里,关于TCP 滑动窗口停等与多路径传输的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • TCP的滑动窗口与拥塞控制

    客户端每发送的一个包,服务器端都应该有个回复,如果服务器端超过一定的时间没有回复,客户端就会重新发送这个包,直到有回复。 为了保证顺序性,每一个包都有一个 ID。在建立连接的时候,会商定起始的 ID 是什么,然后按照 ID 一个个发送。为了保证不丢包,对于发

    2024年02月07日
    浏览(39)
  • TCP的滑动窗口和拥塞控制

    目录 滑动窗口 1.发送窗口和接收窗口 2.滑动窗口的分类 停止等待协议:发送窗口大小 = 1, 接收窗口大小= 1 后退N帧协议(GBN):发送窗口大小 1,接收窗口大小 = 1 选择重传协议(SR) :发送窗口大小 1, 接收窗口大小 1 拥塞控制 慢开始算法和拥塞避免: 快重传和快恢复:

    2024年04月10日
    浏览(36)
  • TCP滑动窗口原理终于清楚了!

    我们在学习计算机网络的时候,遇到很多知识点。即便是背的滚瓜烂熟,让你去 辨别知识点背后的深层逻辑的时候, 可能就手足无措了。 比如小邱去面A公司的时候就被问到: 事实上,这个问题很大程度弥补我计算机网络的“ 漏洞 ”。正应了那句古话“ 有心栽花花不开,

    2023年04月12日
    浏览(32)
  • 【计算机网络笔记】传输层——可靠数据传输之流水线机制与滑动窗口协议

    什么是计算机网络? 什么是网络协议? 计算机网络的结构 数据交换之电路交换 数据交换之报文交换和分组交换 分组交换 vs 电路交换 计算机网络性能(1)——速率、带宽、延迟 计算机网络性能(2)——时延带宽积、丢包率、吞吐量/率 计算机网络体系结构概念 OSI参考模型

    2024年02月06日
    浏览(42)
  • TCP重传机制、滑动窗口、拥塞控制

    一、总述 TCP,Transmission Control Protocol,是一个面向连接、基于 流式传输 的 可靠传输 协议,考虑到的内容很多,比如数据包的丢失、损坏、分片和乱序等,TCP协议通过多种不同的机制来实现可靠传输。今天,重点分析 重传机制 、 滑动窗口 ,以及 拥塞控制 。 二、重传机制

    2024年04月10日
    浏览(50)
  • TCP重传, 滑动窗口, 流量控制, 拥塞控制

    1. 重传机制 TCP 实现可靠传输的方式之一,是通过 序列号与确认应答 。 在 TCP 中,当发送端的数据到达接收主机时,接收端主机会返回一个确认应答消息,表示已收到消息。 针对数据可能丢失的情况, 用重传机制来解决, 四种常见的重传机制: 超时重传 快速重传 SACK D-SACK 1.

    2024年01月22日
    浏览(47)
  • TCP的滑动窗口协议有什么用?

    滑动窗口协议: TCP协议的使用 维持发送方/接收方缓冲区 缓冲区是 用来解决网络之间数据不可靠的问题,例如丢包,重复包,出错,乱序 在TCP协议中,发送方和接受方通过各自维护自己的缓冲区。通过商定包的重传机制等一系列操作,来解决不可靠的问题。 提出问题:在我

    2024年02月10日
    浏览(34)
  • TCP滑动窗口、流量控制及拥塞控制详解

    TCP虽然是面向字节流的,但是TCP传输的单元确实报文段。一个TCP报文段分为首部和数据部分。TCP首部前20个字节是固定的,后面有4N个字节是可选的。因此,TCP首部最小字节数是20个字节。 下面我们看下一TCP首部中几个重要的字段: 源端口 和 目的端口 各占两个字节 序号 ,占

    2024年02月02日
    浏览(36)
  • 网络编程(12): TCP重传、滑动窗口、流量控制、拥塞控制

    通过序列号和确认号确保可靠传输,当发送端发送数据给接收到,接收端会返回一个确认号,表示收到消息了 超时重传 :没有在指定时间内收到 ACK 报文 超时重传的两种可能: 数据包丢失 、 确认包丢失 超时重传时间 RTO : RTO 较大:重发就变慢了,丢包之后需要半天才能重

    2024年02月12日
    浏览(52)
  • 哈工大计算机网络传输层详解之:流水线机制与滑动窗口协议

    哈工大计算机网络课程传输层协议详解之:可靠数据传输的基本原理 哈工大计算机网络课程传输层协议详解之:TCP协议 哈工大计算机网络课程传输层协议详解之:拥塞控制原理剖析 在上一节中我们逐步分析了可靠传输协议的设计过程,最后讲到rdt3.0的设计和实现机制。但是

    2024年02月10日
    浏览(42)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包