浙江温州皮鞋湿,下雨进水不会胖。

动机和缘起

记得大概是三四天前,朋友圈被《Google QUIC正式更名 HTTP/3 协议》这篇文章刷了屏,当时第一感觉就是“我靠,HTTP/2还没普及呢,怎么3就来了,TCP真的这么快就要下课了吗?”。我真的是虚惊一场,我虽然不喜欢TCP,但还要靠着它吃饭呢…TCP要是下课了,我岂不是有丢饭碗的危险?谢特了。又爱又恨的TCP啊!

读了全文,发现不是,我也就放了心,至少还能保住饭碗,但同时心里大骂,TMD垃圾TCP怎么还不赶紧滚蛋??!!矛盾,虚伪,贪婪,欺骗,幻想,疑惑,简单,善变…

我的微信朋友圈里大几百号人绝大多数都是干互联网这一行的,所以当业界出现一个比较轰动的大新闻时,刷屏就是必然的了。

这里先给出这篇文章的英文原文链接:
HTTP/3 :https://daniel.haxx.se/blog/2018/11/11/http-3/
大家可以连同评论一起来看。请先阅读原文或者译文,本文不再包含原文的内容和评论。

我并没有第一时间发出感概,依然如故地,我要让事情冷却几天,在忘却的救主将要降临之前,沉淀出一些剥离了主观刺激的东西,然后再写下来。


正文

当一个新的东西出现时,首先是绝大多数人的欢呼,紧接着是少数人的批判,然后是较多的人的批评,最后这个新的东西是否逐渐趋于平庸,泯然众人,取决于是否有人有破有立。做一个批评者容易,做一个建设者很难,做一个批判者更难,后者决定了新东西是否可以持续蓬勃发展。

QUIC出来已经好几个年头了,但是一直都局限在给TCP补刀的位置,比如哪里哪里说TCP性能不好了,然后有人会说,用QUIC试试吧。这是头一次,让QUIC成为HTTP/3的标准传输协议,用于取代TCP。当然,这并不是一蹴而就的,但如果这是真的,那么TCP就是传统的,而QUIC则是新生代。

这段故事和墨洛温王朝的丕平向加洛林王朝的过渡何其相似。日光之下,并无新事。

TCP作为传统的传输控制协议,诞生在上世纪70年代那个特殊的环境里。最初的需求就是一对一的Telnet远程登录,计算机网络诞生伊始的第一个传输实验就是字符的传输,这为远程控制计算机提供了依据。在那次实验中,由于误码传丢了几个字符,在这样的背景下,TCP协议似乎是唯一正确的协议。

基于单字符的停等协议,字符流水线化传输的GBN协议,基于块传输的SR协议,三者中,似乎只有GBN是唯一正确的选择,停等协议在长RTT时效率太低,SR协议会乱序,对接收端内存要求很高且会影响终端响应度。于是,TCP协议的模版就是GBN。事情开始进化。

众所周知,后来的TCP引入了SR,即SACK机制,但这个SR却是阉割版的,我们知道,TCP的option里面的SACK段的数量是有限制的,所以TCP并没有实现严格的SR。随后为了应对互联网的拥塞,为了提高带宽的利用率,各种拥塞控制算法层出不穷,然而TCP的本质问题依然存在,即 TCP的GBN基因决定了TCP是适合串行字符传输的,而不适合块传输

这导致了TCP的大文件传输性能非常不佳。

我考虑过很久这个问题,TCP的问题到底出在哪里。曾经我以为TCP的性能消耗应该归咎于握手,按序,确认,现在很多人依然是这样认为的,但是那只是小Tips,虽然在短连接中,0-RTT势在必行,但在长连接中,握手开销可以忽略,此外,保序性是由传输的内容决定的,这也无关协议,就算TCP不保序,应用层自己也要保序。

问题出在传输本身,即 :

  • 是要在传输过程中保序,还是在接收过程中保序;
  • 是要在传输过程中保持连接,还是在应用程序中保持连接
  • 连接的目标是一个服务还是一个地址。

TCP协议把传输内容的属性和传输协议进行了强绑定,导致了TCP很多问题是解决不了或者很难解决的,比如:

  • 队头拥塞问题
    由于TCP采用了GBN机制,只要有一个数据包丢失,接收滑动窗口就会塞住,直到这个丢失的数据包造成的空洞被补上。而QUIC则采用完全的SR机制,解决了这个问题。
    对于需要保序的内容,只要在应用接收时保序就可以了,QUIC并不care传输的过程,这是QUIC解决队头拥塞问题的关键。
    HTTP/2在使用TCP时,其队头拥塞问题已经成了HTTP/2的Stream机制的严重阻碍,幸运的是,HTTP/3将会将其扫除!
    TCP是在传输过程中保序,QUIC则是在应用接收过程中保序。
  • 移动问题
    TCP协议把连接和TCP四元组进行了强绑定,其中只要有一个因素变了,连接就变了。我们知道IP标识了一个网络接口(在OSI模型下则是一个终端)的位置,TCP的四元组强绑定直接导致了TCP无法支持IP地址的漂移。
    QUIC不再采用IP地址和端口来标识连接,这便可以支持IP地址和端口的任意漂移。
    TCP是在传输过程中保持连接,QUIC则是在应用程序中保持连接。
  • 组播问题
    在计算机联网的直接且迫切的需求驱动下,TCP必然只需要实现一对一的连接就可以了,TCP端口号本身就是在同一台计算机内部,端到端的传输控制多路复用的产物,所以TCP无法支持一对多的传输。
    QUIC基于UDP,而UDP是可以支持组播的,虽然QUIC本身并未直接声称支持组播,但这并不难。换句话说,QUIC“连接”的只是一个IP/UDP对,该地址对如何解释,是解释成一个应用程序,还是解释成一组应用程序,和传输协议无关。

嗯?是不是忘记了评价一下安全特性?

是的,我是故意的。

安全问题是比较特殊的。非常特殊。

任何人都希望在任何机制上加入安全模块,但任何人都不希望安全模块发生作用。这就像警察机构,没有警察,人们会觉得不安全,但是警察一旦出动,必然意味着某些不好的事情发生了。换句话说,人们只是希望安全模块静静地待在那里就好了。

这意味着如果最初没有直接且迫切的需求,侥幸心理总是让人忽略安全模块的设计。安全模块本身就是一种懒惰机制,出了事才会想到。最初的村落和城市是不设防的,受到侵略后才开始筑墙,TCP/IP网络最初也是裸奔的,后来出现了安全问题才开始出现IPSec,VPN等。如今网络安全问题相关的需求已经是直接迫切的需求了,如果要设计一个新的协议,那么安全机制必然内置其中。

IPv6也好,QUIC也好,都是新的协议,内置安全机制是必须且正确的选择,如果没有内置安全机制,那才是不应该的。所以,我并不认为QUIC协议内置安全机制是多么多么轰动的一件事。


TCP在发展了30多年以后,似乎TCP本身就成了TCP/IP网络的代名词。在我的职业生涯里,自从我毕业开始,就一直被笼罩在其阴影或者光环之下。

我找的第一份正式的工作是长春一家做教学软件的公司,面试的时候问了我一大堆关于TCP的东西,虽然最后一直在离职也没用到,但确实问了,我记得我把书上能背下来的都背下来了,结果还不错。后来我换了很多工作,几乎每一次面试都有TCP的内容,从默写协议头,描述三次握手,到拥塞控制算法,BBR原理,从socket参数的含义到TCP在Linux内核的实现,我的天啊,TCP的内容越来越多,以至于我最近的一份工作面试期间,几乎所有的问题都是TCP相关,当我这么多年逐渐对TCP有了从表面到本质的认知之后,我想我有资格喷它几句了。

不光我自己,几年来我也面试过别人,自己问的很多问题也是TCP相关,只要是做网络的,那就必然要懂TCP,虽然我并不是这么认为的,但我并不是拍板的人,我只是一个执行者。

就在前几个月,我推荐了几个网络技术功底了不得的朋友去华为,大概推荐了三个部门,最后都是以“不了解TCP”为理由而bypass,包括BAT在内的几家国内“大牌”互联网公司,我也推荐过很多人,失败的点均和“对TCP不了解”相关。就好像网络技术和TCP之间是可以划等号的。

确实,现在人们普遍的认知就是,如果不懂TCP,你很难被认为非常精通网络。

但在主观层面上客观地讲,TCP真的就是一个解决问题的协议吗?它在解决问题的同时是否带来了更多的问题呢?

我认为TCP还助长了一些很不好的风气,除了大型互联网公司的招聘偏见之外,我认为还有下面的点:

  • TCP破坏了IP网络的节点对等性
    TCP的连接保持让 一条流很容易被识别,只需要解析协议头即可。这让透明的IP层或者TCP层代理变得很容易实现,直接导致了各种中间NAT设备以及中间防火墙的出现。
    被洗脑了30年的专家们可能认为防火墙并不完全是坏事,但请再次注意安全问题,安全本应该是一个协议自己要保证的内秉属性,一切依靠在外部实现的安全都只是助力。
    IP网络本身就是一个完全对等的网络,后来IPv4感觉地址不够用了,提出了NAT方案,然而NAT最终更多的解决的是地址隐藏的问题,而不是地址不够用的问题,这让IP网络变得不再对等。这非常讽刺。本来应该在应用层实现的服务代理,在IP层更加容易实现,只要修改一下被识别的TCP流的IP地址和端口就可以了,这非常简单易行。试想,如果最终流行起来的协议不是TCP而是UDP,NAT还会这么容易实现吗?
    想想TCP和UDP哪个打洞更加容易些?哪个更容易,哪个地址隐藏的效果就不好,如果效果不好,那么大量成本就不会砸在上面。
  • 拥塞控制问题
    这是1988年以后的事了。在批判TCP之前,我首先要证明AIMD用在UDP上不会出现类似的问题。而这个非常难。
    TCP协议非常严格,但是背后的GBN却是非常鲁莽,我们看GBN原理中导致问题的根源:

    原始的GBN设计留给了 如何重传 太多的操作空间,而如何重传这件事又直接取决于 如何判断丢包, 这导致了大量的拥塞控制算法的出现!如果算法不统一,那么公平性就难以保证,TCP/IP网络的公平博弈便无法保证,资源共享将会成为一句空话。
    虽然后来的SACK缓解了丢包的误判导致的重传,但本质并没有变化,随着带宽越来越大,SACK受到的限制将会越来越严重。
    QUIC以及其基于的UDP有这个问题吗?原则上你也可以设计一个 一个包发两遍 的QUIC拥塞控制算法,但是可能没有人会那么做。当有一种保证公平的可操作方案时,当留下的灰色空间很小时,便没有人会去破坏公平。QUIC基于完全的SR,它可以很精确地判断丢包和选择重传,成为劣币的博弈成本比较高,那便无法驱逐良币。
    世界从此美好。

评价一个技术本不应该带入主观情绪,但这本来就是一篇散文,而不是什么技术文档,所以也就随性了。

纵使TCP问题再多,它至少给我和我的家庭带来了收入,依靠TCP我们全家生活地还不错,哈哈。


曾经,我是不Care HTTP协议的,我一直把自己定位成搞底层的,比如内核,比如网卡,比如IP路由这些才是底层,而HTTP则只是一个Web服务使用的应用层协议而已,无非也就是一个Apache/Nginx这种,没意思。后来我发现很多Apache/Nginx玩的很溜的,对TCP也玩的很溜,然后我就对HTTP协议有了新的认知。

所有TCP/IP内核的问题都是由上层顺势被发现的。当解决了select/poll的问题以及主机进程调度的问题后,最终问题一定会压向TCP。随着互联网应用场景的越发丰富,HTTP是最先感受到变化并传递变化的,事实上,在Google等公司的主导下,HTTP最终还拥抱了变化,HTTP/2似乎解决了HTTP/1的任何问题。然而一成不变的是TCP。

嗯,高铁跑在了普通轨道上降速150km/h运行,车没有问题,是路不好。

所有问题都是TCP的问题。

于是HTTP/3彻底抛弃了TCP。那么HTTP/3何时到来?


先看一个链接:
【重要】通信品質向上にむけた取り組みについてのお知らせ:https://www.ocn.ne.jp/info/announce/2018/06/22_1.html
这是2018年6月份的一个公告,可以一键翻译。

你猜,把互联网应用从TCP切到QUIC需要多久?面临什么问题?

站在当代,我们很容易评价历史,却无法预知未来。我们很容易说出我们有什么问题,却无法用一种平滑的方案去解决这个问题。

QUIC取代TCP很难,因为TCP的历史包袱太重。

几乎所有的有状态防火墙,状态NAT设计,负载均衡设备,均完全依赖TCP的状态机,如果换成QUIC,这些设备将一夜之间全部失效!我们知道,我们之所以可以上网,可以使用互联网做我们想做的事情,几乎严重依赖这些设备,甚至大型运营商也都会在所谓的 出入口 设备上做一些基于状态的动作,如果说一条 UDP连接 的源IP由一个运营商切到另一个运营商了,基于固定IP进行数据包分类的策略是不是就失效了呢?

就想象一下IPv6的部署难度就知道QUIC也将面临同样体量的问题,但它们之间的不同点在于,IPv6的部署是自底而上的,终端用户完全感觉不到变化,然而QUIC却直接是由业务驱动的,QUIC可能就是快,用户能感知体验变好了。

当然了,很多人会怼我,认为我好像已经被QUIC洗了脑,或者说对TCP过于憎恶,现在终于有第二个选择了。其实,我是用看待新事物的普遍观点来分析 QUIC事件 的,还是那句话, 新的东西纵然它有很多不足,你要谅解它的不足,给它发展的空间和时间,而不是一味地怼。

QUIC目前依然尚未得到大规模的部署,依然有很多坑,比如它的扩展性确实很不好,这意味着大规模商用部署的路程还非常遥远,但这至少确实是第二个选择,有选择,就有机会。

总之吧,要乐观,事情总是往好的一面去发展,所有的问题都是能解决的问题。

附上几篇比较好的文章链接:
The Road to QUIC :https://blog.cloudflare.com/the-road-to-quic/
UDP/QUICを使用した高速化 - AKAMAI MEDIA ACCELERATION :https://blogs.akamai.com/jp/2017/05/udpquic---akamai-media-acceleration.html


附文:关于批判和辩证

这篇文章源自于我对TCP的批判,然而在我没找到更好的替代者之前,我只能在朋友圈或者博客上骂骂咧咧。现在有人提出QUIC作为HTTP/3的标准传输协议了,我便可以放心喷了。

其实我自觉自己的辩证性批判做的很好,一直都很好。我不会盲目地去怼一个东西,也不会去盲目吹捧一个东西。

比较令我痛苦的是,我不喜欢中国传统文化,但我却很赞同中国传统文化,这是很难做到的,很难做到的事,过程一定是痛苦的。不信你试试。

到了杭州入职,我感到非常幸运,我突然发现有很多人能和我一起讨论那些 乱七八糟毫无意义 的东西了。

临时租住在公司附近,室友是个练太极的,我们经常聊一些“没有意义”的东西,最近的培训中,又接触到一位超级辩证但却不那么唯物主义的高人。我想有机会真的就可以“举酒属客,诵明月之诗,歌窈窕之章。”了吧。


  • 为什么喜欢寻找外星人
    因为我们希望通过寻找外星人,从而更好地界定我们自己,区分出来“我们”和“他们”。
    如果没有这种欲望,先人在造词的时候,如何会造出“他们”呢?不是我们无聊,而是我们孤独和迷茫,所以我们一定要不断寻找“他们”。和“他们”不一样的地方,那就是“我们”!
  • 希腊的和谐和中国的和谐
    希腊人喜欢辩论,喜欢争论,视为和谐,中国人强调不争,视为和谐。站在类别间和谐立场上,争论才能区别你我他,彼此公平,才是和谐,否则便是立场不清晰,视为混沌;站在整体的立场上,不争则无损,总能量最大,视为和谐,否则则大伤元气。都对,也都不对。
  • 对人和对事
    把一个人的本性和这个人所持有的观点区分开来,是困难的。当我在为一个罪犯辩护的时候,我其实也在给自己抹黑。
    所以不要轻易和自己的领导进行争吵。
  • 中国文化和西方文化
    中国文化是封闭自省的,西方文化是一路走到黑的并冠以“进步”的代名词。西方文明会持续作恶而不会自省,最终世界灭亡。
  • 田园生活和汽车空调
    汽车的意义是什么?它真的代表比田园生活更好的生活工具吗?你坐车是去干什么?去上班,上班干什么?挣钱,挣钱干什么?换车换房装逼…
    所以现代化生活的意义是什么?是在维持现代化生活而已?是真的吗?
  • 取消关注“微信运动”
    作为一个狂热的徒步爱好者,我终于在上周日把微信运动取消关注了,那天我一路小跑两个小时完成了西湖景区东面山脊的穿越。自己自觉找爽点就好了,没有必要通过一颗争强好胜不服输的心去激励自己多走几步了。

浙江温州皮鞋湿,下雨进水不会胖。
zhejiang wenzhou skinshoe wet,rain flooding water will not fat.

QUIC成为了HTTP/3的标准传输协议!相关推荐

  1. STGW 下一代互联网标准传输协议QUIC大规模运营之路

    作者:wentaomao,腾讯 TEG 后台开发工程师 前言 QUIC 作为互联网下一代标准传输协议,能够明显提升业务访问速度,提升弱网请求成功率以及改善网络变化场景下的平滑体验. STGW 作为公司 ...

  2. RaySync 传输协议的有效带宽利用率分析介绍

    最近在评论区收到不少朋友反应[RaySync FTP]文件传输的效果挺好,谢谢大家的鼓励.也有部分熟悉技术的同学希望介绍下原理,有部分同学咨询RaySync传输协议会不会是通过超量发包来达到快速传输, ...

  3. 超文本传输协议 - 白话篇

    再给大家介绍另一个小编,他也是一名在校学生,为什么会有写网络相关的想法呢?因为这几天在给图书馆的服务器装环境,在配置网络上面一直停滞不前,决定重新学习一遍计算机网络,他会将每天学到的知识通过大白话的方 ...

  4. Facebook如何将QUIC应用于数十亿流量传输

    随着IETF很快完成QUIC标准定稿,越来越多的企业和开发者投入到QUIC开发实现与部署中.阿里巴巴实现了XQUIC:B站.快手在2019年就公开了QUIC的应用实践:Akamai等CDN服务商则很早 ...

  5. 网络摄像机编码标准及传输协议简析

    视频监控系统从第一代模拟系统(VCR)到第二代部分数字化系统(DVR/NVR),再到第三代完全数字化系统(网络摄像机,网络视频服务器),三个阶段的发展演变预示着全数字化视频监控系统不久将成为安防市场的 ...

  6. QUIC:基于UDP的多路复用安全传输(部分翻译)

    文档信息 Workgroup: QUIC Internet-Draft: draft-ietf-quic-transport-32 Published: 20 October 2020 Intende ...

  7. QUIC 之类的可靠传输协议

    互联网是一个分组(或者称为数据包)交换网络,其中传输的数据的基本单位是数据包.互联网中时时刻刻在发生的是距离有限的两个路由节点之间通过物理链路的数据包交换.那互联网中远距离复杂环境下的数据传输究竟如何 ...

  8. WCF标准绑定以及传输协议与编码格式

    WCF 定义了9 种标准绑定: 基本绑定(Basic Binding) 由BasicHttpBinding类提供.基本绑定能够将WCF服务公开为旧的ASMX Web服务,使得旧的客户端能够与新的服务协 ...

  9. 【计算机网络笔记】数据链路层(封装成帧,差错检测,可靠传输)

    链路:从一个结点到相邻结点的一段物理线路,中间没有任何其他的交换结点. 数据链路:把实现通信协议的硬件和软件加到链路上 数据链路层以帧为单位传输和处理数据. 三个过程:封装成帧,差错检测,可靠传输 封 ...

  10. UDP可靠性传输协议(QUIC)

    目录 UDP与TCP对比 可靠性机制 ACK机制 重传机制 流控控制 序号机制 重排机制 窗口机制 UDP可靠性设计 UDP窗口流控 KCP(出于实时性考虑) QUIC 简述 优点 缺点 报文格式 建 ...

最新文章

  1. 最强写作AI竟然学会象棋和作曲,语言模型跨界操作引热议,在线求战
  2. 【Groovy】闭包 Closure ( 闭包中调用 Groovy 脚本中的方法 | owner 与 delegate 区别 | 闭包中调用对象中的方法 )
  3. c语言如何输出斜杠星号,Excel 如何提取出最后一个斜杠开始的数字
  4. socket java 服务器端_Java 简单的Socket通讯的服务器端实现
  5. Vue全家桶 - 电商后台管理系统项目开发实录(详)
  6. mysql-外键操作-级联删除
  7. 修改WordPress主题,中文显示乱码的解决办法
  8. 【es】es API源码分析
  9. zoj 1100 - Mondriaan#39;s Dream
  10. Java购票系统实训总结_Java 购票系统实现
  11. 【转】区块链:胖协议
  12. oracle怎么看今天星期几,oracle 判断今天是星期几
  13. POJ 1723(中位数+连续排列)
  14. Typora导入CSDN
  15. 2022年机动车新规,外地人上京牌不需要居住证啦
  16. 可兼容所有浏览器的“收藏本站”、“设为首页”js代码
  17. 中南设计集团BIM云实践,泽塔云超融合GPU云功不可没
  18. 使用()关键字来创建python的自定义函数_17.python自定义函数
  19. 教程:简单几步制作出酷炫网页版简历
  20. java获取指定日期的下一天

热门文章

  1. ibm tivoli_IBM Tivoli Directory Server中的安全复制
  2. Contest1389 - 2018年第三阶段个人训练赛第四场. Transit Tree Path(DFS)
  3. 达内php第一次月考题,五年级英语下册第一次月考题
  4. LeetCode——跳跃游戏
  5. NorFlash与NandFlash对比
  6. Chrome快捷键与Vimium
  7. 计算机硬件找不到网络适配器,图文学习网络适配器不见了 【操作教程】 的恢复方法_...
  8. Assets, Objects and serialization Assets, Objects与序列化 最佳实践系列3
  9. GD32 定时器+一个IO实现SIF读取
  10. 微信邮箱怎么弄怎么写?手机可以移动办公吗?