QUIC成为了HTTP/3的标准传输协议！

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

动机和缘起

记得大概是三四天前，朋友圈被《 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.