QUIC 之类的可靠传输协议
互联网是一个分组(或者称为数据包)交换网络,其中传输的数据的基本单位是数据包。互联网中时时刻刻在发生的是距离有限的两个路由节点之间通过物理链路的数据包交换。那互联网中远距离复杂环境下的数据传输究竟如何完成的呢?它们正是借助于多次路由节点间直接的这种数据交换完成的。直觉上就让人觉得这种数据传输不是那么的可靠,不像电话网络连接那样。实际上互联网的数据传输确实不是百分之百的可靠,互联网上传输的数据天然地可能出现丢失,乱序,重复等等问题,但目前来看,绝大多数情况下,互联网还是比较有效。
互联网有效性的一个保证即是数据的可靠传输协议,如 TCP。TCP 对于当今的互联网是如此的重要,以至于整个网络协议栈被以 TCP/IP 来指代。通常情况下传输层协议及之下的协议由内核层实现,由硬件设备实现,之上的协议的数据,是我们平常写的应用程序可以比较方便的拿到的数据。TCP 在内核实现了一套复杂的可靠传输的字节流的语义,而 UDP 在发送时,是在数据包的前面简单的加个 IP 头部等就发送出去,接收时简单的剔除掉 IP 头部就抛给应用层的数据包。除了 TCP,互联网的可靠传输协议也多有基于 UDP 实现的,毕竟这类协议运行在用户空间,不管是部署还是更新,都要方便得多,比如 RUDP,UDT 等,当然还有 QUIC。
不管是 TCP,还是基于 UDP 并运行于用户空间的可靠传输协议,它们要解决的问题都是类似的,解决问题的方法也多有相似之处,在分析这些协议时也可以从类似的几个角度入手。
提供给应用方的操作。可靠传输协议提供给应用方的操作,通常包含:
- 等待连接/接受连接的 listen/accept
- 建立连接的 connect
- 发送数据的 send/write
- 接收数据的 receive/read
- 关闭连接的 close/shutdown
可靠传输协议的连接的生命周期,通常包含:
- 建立连接。
- 数据传输及传输控制。
- 断开连接。
断开连接的过程,通常主要涉及资源的清理和容错等,不太容易成为为了优化传输效率和安全性而开发的新协议的关注重点。而建立连接和数据传输控制方面,则是各种新方法新手段层出不穷。
连接建立过程主要为了协商传输参数及协议安全性而存在,不同的可靠传输协议有不同的看法及选择,如 TCP 的 3 次握手,UDT 则是 4 次握手,这是其一,即一般的连接握手过程需要经过几个 RTT。
数据传输过程中多一个 RTT,少一个 RTT 对于传输数据量很大的情况,可能没有太大的影响,但对于当今互联网中大量存在的数据量不大,如 REST API 访问这种请求则有着显著的影响,于是一些较新的协议会有减少连接建立过程中的 RTT 的尝试。为了减少连接建立过程的 RTT,一般来说有几种方法:一是尝试增加状态减少整体建连开销,即第一次连接建立耗时较长,后续再建立连接时,耗时减少,如 TLS 的会话恢复,TCP 的 Fast Open 优化,QUIC 的 0 RTT 建连等;二是尝试在建连的握手包中发送应用数据,如TCP 的 Fast Open 优化,QUIC 的 0 RTT 建连等;三是合并多个层次的协议的连接建立协商,如 QUIC 的合并可靠传输协议的协议协商和为了安全性的 TLS 的协议协商等;四是每次建立连接之后,试图多传一些数据,甚至是并发地传数据,比如 HTTP/2 的连接复用,QUIC 的连接复用等;五新的连接标识及连接维护方法,如 QUIC 的连接迁移特性。
我们写代码时,都讨厌状态,能少一个状态就少一个状态。状态几乎难免要增加不同代码和程序逻辑的耦合,增加部署维护成本,降低并发性,降低伸缩性等,然而为了更有效的网络数据传输,许许多多的协议将状态引入进来了。
然后是数据传输控制过程。无论哪种可靠传输协议,为了实现有效的可靠传输,发送缓冲区,接收缓冲区,数据包的接收确认,丢包/超时重传,快速重传,发送滑动窗口,接收滑动窗口,拥塞窗口拥塞控制等等几乎都是必不可少的。
数据传输过程主要由数据发送方控制,数据发送方依据接收方的接收能力,对于网络环境的探测感知,以及发送方的发送能力对发送过程进行控制。接收缓冲区和接收窗口代表数据接收方的数据接收能力,发送方的发送缓冲区代表发送方的发送能力,拥塞控制和拥塞窗口则代表发送方对于网络环境状态的感知,发送方主要综合考虑接收窗口和拥塞窗口,来控制发送窗口的大小。
为了探测网络状况,类似于 TCP 的 CUBIC 算法几乎总是无法避免的,慢启动,拥塞避免,快速重传,丢包/超时重传等。为了充分利用当前网络环境的网络带宽,慢启动过程的初始拥塞窗口可以适当地调整的比之前大一些,如 UDT 的做法。为了更精确地感知网络状态和接收方的接收能力的变化,如 RTT 等,QUIC 引入了单调递增的 Seqno,Ack Delay 时间,更多的 Ack 等特性,TCP 的数据包中总是会携带有接收窗口的大小,还有 HTTP/2 和 QUIC 中的 WINDOW_UPDATE 等。为了尽可能避免重传,FEC 也常常作为一种优化手段。探测到网络状况之后,对于传输更精细的控制,则可以专门再来探讨。
QUIC 之类的可靠传输协议相关推荐
- 计算机网络(九)——可靠传输协议
文章目录 1. 可靠数据传输协议 1.1 经完全可靠信道的可靠数据传输:rdt1.0 1.2 经具有比特差错信道的可靠数据传输 1.3 经具有比特差错的丢包信道的可靠数据传输:rdt3.0 2. 流水 ...
- 关于各种运输层的可靠传输协议
可靠传输协议 相信大家在学习计算机网络时,学到可靠传输协议这里会有一点乱,我把这几天所学的知识整理如下,希望对大家有所帮助. 全文基于对计算机网络有一定基础的人学习,文章中很多地方讲的不是很全很细,倘 ...
- 大白话了解TCP协议:了解TCP?先别急,来看看TCP的前世——“最简单的”可靠传输协议:停止等待协议
TCP是可靠传输协议的衍生.拓展 先了解可靠传输协议的基本概念就可以非常轻松得了解TCP协议了! 这是个有安全感的协议类型~ 在漫长的线路中,这些数据要经过路由器.网线,甚至还有风风雨雨--数据就很容 ...
- UDT:基于UDP的可靠传输协议
基于UDP 上的UDT ,比TCP传输效率高 UDT:基于UDP的数据传输协议(初译) (译者:Jack) Status of this Memo This Internet-Draft is sub ...
- 可靠传输的原理:停止等待协议、ARQ协议;TCP协议的可靠传输
停止等待协议 停止等待协议是最简单的可靠传输协议,停止等待就是每发送完一个分组就停止发送,等待对方的确认.在收到确认后再发送下一个分组.若接收方收到重复的分组,就会丢弃该分组,但同时还要向发送方发送确 ...
- 传输层 可靠传输 重传与确认 停止等待协议工作原理
谈谈你对停止等待协议的理解? 停止等待协议是为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认,在收到确认后再发下一个分组. 在停止等待协议中,若接收方收到重复分组,就丢弃该分 ...
- 26-tcp可靠传输——停止等待协议
1. tcp可靠传输 通过前面的学习可知,网络层传输数据时是尽最大努力传输到目的地,并不保障数据的可靠传输,对于网络拥塞,延迟,数据丢失等问题没有采取有效的措施.因此我们需要一种数据可靠传输的通信 ...
- 支付宝二面:如何用 UDP 实现可靠传输?
相信大家面试经常会被问到一个问题 "如何用UDP实现可靠传输",今天就给大家分享一个基于 UDP 实现的可靠传输协议:QUIC . 这几天看到一篇蚂蚁集团实战 QUIC 的文章,我 ...
- 流控制传输协议 SCTP
流控制传输协议(SCTP,Stream Control Transmission Protocol)是一种在网络连接两端之间同时传输多个数据流的协议.SCTP提供的服务于UDP和TCP类似 SCTP在 ...
最新文章
- Bioinformatics | 预测药物-药物相互作用的多模态深度学习框架
- XHTML 结构化:使用 XHTML 重构网站
- textarea标签内容为(英文或数字不自动换行)的解决方法
- rowid 对应mysql_请教一下相当于MySQL中Oracle的RowID
- 计算机资产管理,▪ 资产管理
- labelme标注文件转coco json,coco json转yolo txt格式,coco json转xml, labelme标注文件转分割,boxes转labelme json
- mysql中的trigger
- python窗口图形界面编程上传图片_python GUI编程(Tkinter) 创建子窗口及在窗口上用图片绘图实例...
- ZOJ 1315【Excuses, Excuses!】------2015年2月9日
- 英伟达最大gpu_摩尔定律未死,黄律定律已出!英伟达要用GPU推动AI性能逐年翻倍...
- 如何学习、如何画思维导图
- Redhat_rhel8.0_FTP服务配置
- 抖音搬运视频热门技巧 剪辑后会修改视频md5
- dotnet 读 WPF 源代码笔记 了解 WPF 已知问题 用户设备上不存在 Arial 字体将导致应用闪退...
- 用c语言写鸡兔同笼问题
- 存储故障时的ORA-7445错误
- 实时互动下视频 QoE 端到端轻量化网络建模
- 一个目标100亿的互联网金融创业项目完整思路(毫无保留,赤裸裸全部是干货分享)
- python 校验身份证号码 并输出对应省市县生日 demo
- 【POJ No. 1256】 字谜 Anagram