QUIC

关于QUIC协议的论文、IETF进展、博客、视频等等 QUIC 的全称是 Quick UDP Internet Connections protocol, 由 Google 设计提出，目前由 IETF 工作组推动进展。其设计的目标是替代 TCP 成为 HTTP/3 的数据传输层协议。熹乐科技在物联网（IoT）和边缘计算（Edge Computing）场景也一直在打造底层基于 QUIC 通讯协议的低时延边缘计算框架 YoMo ，长时间关注 QUIC 协议的发展，遂整理该文集并配以适当的中文翻译，方便更多关注 QUIC 协议的人学习。 在线社区：🍖 discord/quic 维护者：🦖 YoMo QUIC Weekly - 20201118期 📽 Throwback to 乘坐时光机回到2016年7月QUIC工作组的成立会议 ，这次会议是基于 Google 当时的实践经验，讨论 QUIC 是否应该成为 IETF 的标准 📽 Robin Marx 讲述 QUIC 和 HTTP/3 的基本功能，开放了他研究的问题及他再 qlog 和 qvis 这两个调试工具上的进展 。 lsquic 发布了 v2.24.4 , 修复了拥塞控制和 CID 生命周期的相关问题。 iOS 14 和 macOS Big Sur 包含了 HTTP/3 实验版本的支持 ，并讲述了如何开启 QUIC 的使用，比如在

关于QUIC协议的论文、IETF进展、博客、视频等等 QUIC 的全称是 Quick UDP Internet Connections protocol, 由 Google 设计提出，目前由 IETF 工作组推动进展。其设计的目标是替代 TCP 成为 HTTP/3 的数据传输层协议。熹乐科技在物联网（IoT）和边缘计算（Edge Computing）场景也一直在打造底层基于 QUIC 通讯协议的低时延边缘计算框架 YoMo ，长时间关注 QUIC 协议的发展，遂整理该文集并配以适当的中文翻译，方便更多关注 QUIC 协议的人学习。 在线社区：🍖 discord/quic 维护者：🦖 YoMo QUIC Weekly - 20201125期 Wikipedia 上更新了关于 HTTP/3 的章节： HTTP/3 - Wikipedia IETF-QUIC 的标准依赖树 Daniel Stenberg 的新 Keynote HTTP/3 是下一代 HTTP QUIC 在 5G 网络中的实验： QUIC Throughput and Fairness over Dual Connectivity Google's cloud gaming platform Stadia is using QUIC 跟坚哥学QUIC系列：4 - 连接迁移（Connection Migration）

Chromium 官方宣布 Chrome 正在 部署到 HTTP/3 与 IETF QUIC 。 QUIC（Quick UDP Internet Connections）是 Google 推出的一个项目，旨在降低基于 TCP 通讯的 Web 延迟。QUIC 非常类似 TCP+TLS+SPDY ，但是基于 UDP 实现的。它是 HTTP/3 的基础协议。 2015 年，Google 将 QUIC 引入负责维护互联网协议的标准组织 IETF，并且 IETF 一直在对 QUIC 进行改进，目前有两个相似但不同的 QUIC 协议：Google QUIC 与 IETF QUIC。 Chrome 中使用的是 Google QUIC，同步地 Google 也在参与 IETF 对 QUIC 的改进，发展到现在最新的 Google QUIC 版本 Q050 与 IETF QUIC 有许多相似之处，不过大多数 Chrome 用户通常无法与 IETF QUIC 服务器进行通信。 Chromium 团队表示，其发现 IETF QUIC 的性能优势特别高，使得 Google 搜索延迟减少了 2％ 以上，YouTube 的重新缓冲时间减少了 9％ 以上，PC 客户端吞吐量增加了 3％ 以上，移动设备的客户端吞吐量增加了 7％ 以上，因此宣布 Chrome 即将引入对 IETF QUIC h3-29 版本的支持

周一，IETF透露它将HTTP-over-QUIC实验协议重命名为HTTP / 3。HTTP-over-QUIC是一种HTTP重写，用TCP替换TCP。 如果这看起来有点为时过早，那么它与IETF的历史运作方式并不完全不符。就像TLS 1.3在每个网站甚至已经切换到TLS 1.2之前推出的那样（尽管到8月份绝大多数都有）并且SHA-3已经建立，尽管几年前SHA-2开始使用。因此，尽管事实上只有31.2％的前1000万网站甚至使用 HTTP / 2 ，但HTTP / 3已经出现。 已经有1000万支持QUIC的1.2％。那是大约120,000个网站。 那么，什么是HTTP-over-QUIC - 或者我想现在它是HTTP / 3 - 这个新协议对于 SSL / TLS 行业意味着什么？ 什么是HTTP / 3（又名HTTP-over-QUIC） HTTP-over-QUIC是一种实验性的Google协议，它是一种HTTP重写，它在QUIC中交换传统上位于互联网核心的标准TCP。 TCP是传输控制协议，与IP（互联网协议）一起，它已成为定义互联网多年的基本规则之一。它足够老，它有一个三位数的RFC编号。这是一个IETF的笑话，TCP是在1981年定义的.TCP是一种面向连接的协议，它旨在提供无差错的数据传输，它控制数据如何分解成数据包并传播到连接的另一端。 不幸的是

在SIGCOMM的众多研究方向中，传输协议TCP优化是一个经典的课题，与TCP优化相关的工作必须达到一个极高的“阈值”才可能被录用。笔者论文“TACK: Improving Wireless Transport Performance by Taming Acknowledgments”作为传输协议方向的文章成功入围，多年苦心钻研没有白费，努力有被看到，不禁备感幸运。这篇文章除了得到网络界大佬谭焜博士和郑凯博士的指导外，还受到了清华大学徐恪教授也就是我博士导师的财力（支持我实习的房租）和学术上的大力支持，感激无法言表。这篇文章也受到了斯坦福大学大牛Keith Winstein的指导和支持，Keith在自己的 个人主页 是这么介绍我们的合作过程的： 今天给大家简单地对文章进行通俗化的解析，算作导读。 进入正题。 TACK技术背景：无线网络干扰难题 作为万物互联 “最后100米”的通信网络技术，无线局域网（WLAN）技术催生了各式各样新型的移动应用。无论是通过无线路由器把手机、平板、电脑和电视等智能化设备接入到互联网，还是通过WiFi直连技术架起设备与设备之间的捷径，WLAN为生活数字化和新型应用（如4K无线投屏、AR/VR交互式游戏等）的涌现，提供了无限可能。​ WLAN最常用的技术就是WiFi。WiFi通常工作在非授权公共频段（2.4GHz或5GHz），非常容易受到“外部干扰”

HTTP请求的构建 请求行 请求方法，如get post put delete 首部字段 key value，如Accept-Charset 表示客户端可以接受的字符集，防止传过来是另外的字符集，导致乱码出现。 Content-Type指正文格式，例如进行post请求，如果正文是json就应该将这个值设为json HTTP请求的发送 面向链接的方式发送，通过stream二进制流的方式传送诶对方，到了tcp层，会把二进制流转化为一个个的报文发给服务器。 发送每个报文对需要对方回应ack，如果没有回应就一直发送，tcp每发送一个报文都需要加上源地址喝目标地址，放到ip头里面，交给ip层传输。 ip层查看目标地址和自己是否是同一个局域网，如果是就发送arp协议请求这个目标地址对应的mac地址，将源mac和目标mac放入mac头发送，如果不在同一个局域网，发送到网管，还需要发送arp协议，获取网关mac，将源mac和网关mac放入mac头发送。 网关收到包发现mac符合，取出目标ip，根据路由协议找到下一跳路由，获取下一跳路由mac，将包发给下一跳路由器。最终到达目标的局域网，这个时候最后一跳发现目标地址在自己的某一个出口的局域网，于是在整个局域网发送arp，得到目标mac地址，将包发出去。 目标及其发现mac地址符合，ip地址符合，解析tcp的头，查看序列号，如果正确就返回一个ack

QUIC 的全称是 Quick UDP Internet Connections protocol，由 Google 设计提出，目前由 IETF 工作组推动进展，其设计的目标是替代 TCP 成为 HTTP/3 的数据传输层协议。熹乐科技在物联网（IoT）和边缘计算（Edge Computing）场景也一直在打造底层基于 QUIC 通讯协议的边缘计算微服务框架 YoMo ，长时间关注 QUIC 协议的发展，本文章简单介绍了 QUIC 协议的特点和术语。 在线社区： discord/quic 维护者： YoMo QUIC 是一种多路复用和安全的通用传输协议，它提供： 流（stream）多路复用 流（stream）和连接（connection）级别的流量控制 建立低延迟连接（1-RTT 或者 0-RTT） 连接迁移（Connection migration）和弹性 NAT 重绑定 经过身份验证和加密的头部（header） 和有效载荷（payload） QUIC 建立了客户端（client）和服务端（server）之间有状态的交互连接。连接的主要目的是通过应用协议支持结构化的数据交换。 应用协议通过 QUIC 连接的流（streams）交换信息，流（stream）是有序序列的字节（bytes）。可以创建两种类型的流：双向流（bidirectional streams）

QUIC（Quick UDP Internet Connection）是谷歌制定的一种互联网传输层协议，它基于UDP传输层协议，同时兼具TCP、TLS、HTTP/2等协议的可靠性与安全性，可以有效减少连接与传输延迟，更好地应对当前传输层与应用层的挑战。 QUIC的由来：为什么是UDP而非TCP？ UDP和TCP都属于传输层协议。TCP是面向连接的，更强调的是传输的可靠性，通过TCP连接传送的数据，无差错，不丢失，不重复，按序到达，但是因为TCP在传递数据之前会有三次握手来建立连接，所以效率低、占用系统的CPU、内存等硬件资源较高；而UDP的无连接的（即发送数据之前不需要建立连接），只需要知道对方地址即可发送数据，具有较好的实时性，工作效率比TCP高，占用系统资源比TCP少，但是在数据传递时，如果网络质量不好，就会很容易丢包。 我们知道，大部分Web平台的数据传输都基于TCP协议。实际上，TCP在设计之初，网络环境复杂、丢包率高、网速差，所以TCP可以完美解决可靠性的问题。而如今的网络环境和网速都已经取得了巨大的改善，网络传输可靠性已经不再是棘手的问题。另外，TCP还有一个很大的问题是更新非常困难。这是因为：TCP网络协议栈的实现依赖于系统内核更新，一旦系统内核更新，终端设备、中间设备的系统更新都会非常缓慢，迭代需要花费几年甚至十几年的时间，这显然跟不上当今互联网的发展速度

2015-04-21 12:06 | DevStore编辑 陈儿 最近Google开始考虑用改进版的UDP协议QUIC给web提速。根据它近日公布的性能评估，这一融合了UDP与TCP优势的协议似乎提升效果明显。 那QUIC与其他协议的区别和优势又在那里，谷歌究竟是怎么想的呢？ 讨论这个问题前，先来普及一下网络协议的基础知识 QUIC协议是怎么回事 QUIC，Quick UDP Internet Connections）的缩写，一种实验性的传输层网络传输协议，由Google公司开发，在2013年实现出来。QUIC使用UDP协议，在两个端点间创建连接，支持多路复用连接。在设计之初，QUIC希望能够提供等同于SSL/TLS层级的网络安全保护。减少数据传输及创建连接时的延迟时间，双向控制带宽，以避免网络拥塞。Google希望使用这个协议，来取代TCP协议，使网页传输速度加快。 以往典型的安全TCP连接（TCP+TLS）往往需要在发送与接收端先进行2、3轮的握手通信才能正式开始数据传输。而利用QUIC协议，如果双方此前通信过的话马上就可以对话（即便双方此前未通信过时延也只有100毫秒，是TCP+TLS用时的1/3）。此外，QUIC还增加了拥塞控制和自动重传等功能，所以可靠性上要比UDP更高。 QUIC比UDP更快，那UDP究竟怎样 TCP/IP协议族是互联网的基础

转自：hez2010 cnblogs.com/hez2010/p/13963803.html 前言 双十一当天，个人觉得非常香，并且花了 10 分钟时间就把自己的 4 个 .NET Core 3.1 的项目升级到了 .NET 5，堪称无痛。 但是，.NET 5 中还有一些没有正式公开的隐藏特性，那么现在就开始介绍吧。 Crossgen 2 Crossgen 其实就是众所周知的 ReadyToRun 特性。该功能将你的程序集进行一定程度的 AOT 编译，然后在运行时跟踪热路径对一些方法进行带有更多优化的 JIT 编译，即分层编译，这使得程序集的加载速度大幅提高。 但是 .NET 5 其实带了 Crossgen 的下一个版本：Crossgen 2。 Crossgen 2 的代码几乎是从 CoreRT 继承而来，并在此基础上做了很大改进。CoreRT 可以对 .NET 程序集进行完全的原生优化编译，编译出来的东西就是完全 native 的，和 Go 的体验完全一致。 Crossgen 2 则使用了这套方法，将你的程序集在支持范围之内进行 Native AOT 编译，然后运行时直接加载启动，并根据运行情况再使用 JIT 编译器进行进一步的优化，是一种混合 AOT 策略。 为什么说在支持范围之内呢？因为 Native AOT 必然对动态加载和 Emit 等特性不友好，但是 Crossgen