quic 订阅
QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于UDP的低时延的互联网传输层协议。在2016年11月国际互联网工程任务组(IETF)召开了第一次QUIC工作组会议,受到了业界的广泛关注。这也意味着QUIC开始了它的标准化过程,成为新一代传输层协议 [1]  。 展开全文
QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于UDP的低时延的互联网传输层协议。在2016年11月国际互联网工程任务组(IETF)召开了第一次QUIC工作组会议,受到了业界的广泛关注。这也意味着QUIC开始了它的标准化过程,成为新一代传输层协议 [1]  。
信息
简    称
QUIC
主要特征
基于UDP的低时延的互联网传输层协议
作    用
解决传输层和应用层面临的需求
研发公司
谷歌
外文名
Quick UDP Internet Connection
发布时间
2016年11月
print单词发音
QUIC(Quick UDP Internet Connection)是谷歌制定的一种基于UDP的低时延的互联网传输层协议。我们知道,TCP/IP协议族是互联网的基础。其中传输层协议包括TCP和UDP协议。与TCP协议相比,UDP更为轻量,但是错误校验也要少得多。这意味着UDP往往效率更高(不经常跟服务器端通信查看数据包是否送达或者按序),但是可靠性比不上TCP。通常游戏、流媒体以及VoIP等应用均采用UDP,而网页、邮件、远程登录等大部分的应用均采用TCP。 [2]  QUIC很好地解决了当今传输层和应用层面临的各种需求,包括处理更多的连接,安全性,和低延迟。QUIC融合了包括TCP,TLS,HTTP/2等协议的特性,但基于UDP传输。QUIC的一个主要目标就是减少连接延迟,当客户端第一次连接服务器时,QUIC只需要1RTT(Round-Trip Time)的延迟就可以建立可靠安全的连接,相对于TCP+TLS的1-3次RTT要更加快捷。之后客户端可以在本地缓存加密的认证信息,在再次与服务器建立连接时可以实现0-RTT的连接建立延迟。QUIC同时复用了HTTP/2协议的多路复用功能(Multiplexing),但由于QUIC基于UDP所以避免了HTTP/2的线头阻塞(Head-of-Line Blocking)问题。因为QUIC基于UDP,运行在用户域而不是系统内核,使得QUIC协议可以快速的更新和部署,从而很好地解决了TCP协议部署及更新的困难 [1]  。如今,IETF的QUIC工作组正在负责QUIC协议的标准化进程。IETF社群对于QUIC的标准化工作展现出了很高的兴趣。一个初步的QUIC协议版本已经被使用在谷歌的服务以及Chrome浏览器当中,并且被少数第三方开发者部署。需要注意的是QUIC的标准化工作完全开放,IETF社群中的每个人都可以提出自己的建议,最终确定一个最佳方案。所以最后的标准化协议跟使用的版本可能会存在较大的不同 [1]  。
收起全文
精华内容
下载资源
问答
  • 2021-01-30 18:55:15

    缘从何起?

    HTTP/2 协议虽然大幅提升了 HTTP/1.1 的性能,然而,基于 TCP 实现的 HTTP/2 遗留下 3 个问题:

    • 有序字节流引出的队头阻塞,使得 HTTP/2 的多路复用能力大打折扣;

    • TCP 与 TLS 叠加了握手时延,建链时长还有 1 倍的下降空间;

    • 基于 TCP 四元组确定一个连接,这种诞生于有线网络的设计,并不适合移动状态下的无线网络,这意味着 IP 地址的频繁变动会导致 TCP 连接、TLS 会话反复握手,成本高昂。

    而 HTTP/3 协议恰恰是解决了这些问题:

    • HTTP/3 基于 UDP 协议重新定义了连接,在 QUIC 层实现了无序、并发字节流的传输,解决了队头阻塞问题(包括基于 QPACK 解决了动态表的队头阻塞);

    • HTTP/3 重新定义了 TLS 协议加密 QUIC 头部的方式,既提高了网络攻击成本,又降低了建立连接的速度(仅需 1 个 RTT 就可以同时完成建链与密钥协商);

    • HTTP/3 将 Packet、QUIC Frame、HTTP/3 Frame 分离,实现了连接迁移功能,降低了 5G 环境下高速移动设备的连接维护成本。

    创建一个新的独立于TCP/UDP的协议可以吗?
    成本太大

    为什么不使用基于UDP的SCTP?
    SCTP是一个支持数据流的可靠的传输层协议,而且在WebRTC上已有基于UDP的对它的实现。
    这看上去很好,但与QUIC相比还不够好,因为

    • 没有解决数据流的队头阻塞问题
    • 连接建立时需要决定数据流的数量
    • 没有稳固的TLS/安全性支持
    • 建立连接时候需要4次握手,而QUIC一次都不用(0-RTT)
    • QUIC是类TCP的字节流,而SCTP是信息流(message-based)
    • QUIC连接支持IP地址迁移,SCTP不行

    什么是QUIC?

    QUIC: Quick UDP Internet Connections 谷歌发明的新传输协议。

    就像 HTTP/2 协议一样,HTTP/3 并没有改变 HTTP/1 的语义。
    那什么是 HTTP 语义呢?在我看来,它包括以下 3 个点:

    • 请求只能由客户端发起,而服务器针对每个请求返回一个响应;

    • 请求与响应都由 Header、Body(可选)组成,其中请求必须含有 URL 和方法,而响应必须含有响应码;

    • Header 中各 Name 对应的含义保持不变。

    HTTP/3 在保持 HTTP/1 语义不变的情况下,更改了编码格式,这由 2 个原因所致:

    • 首先,是为了减少编码长度。下图中 HTTP/1 协议的编码使用了 ASCII 码,用空格、冒号以及 \r\n 作为分隔符,编码效率很低。HTTP/2 与 HTTP/3 采用二进制、静态表、动态表与 Huffman 算法对 HTTP Header 编码,不只提供了高压缩率,还加快了发送端编码、接收端解码的速度。

    • 其次,由于 HTTP/1 协议不支持多路复用,这样高并发只能通过多开一些 TCP 连接实现。然而,通过 TCP 实现高并发有 3 个弊端:

      • 实现成本高。TCP 是由操作系统内核实现的,如果通过多线程实现并发,并发线程数不能太多,否则线程间切换成本会以指数级上升;
      • 如果通过异步、非阻塞 socket 实现并发,开发效率又太低;每个 TCP 连接与 TLS 会话都叠加了 2-3 个 RTT 的建链成本;
      • TCP 连接有一个防止出现拥塞的慢启动流程,它会对每个 TCP 连接都产生减速效果。

    极客未完待续
    QUIC 和TCP的对比:
    在这里插入图片描述

    从图上可以看出,QUIC 底层通过 UDP 协议替代了 TCP,上层只需要一层用于和远程服务器交互的 HTTP/2 API。这是因为 QUIC 协议已经包含了多路复用和连接管理,HTTP API 只需要完成 HTTP 协议的解析即可。

    QUIC 与现有 TCP + TLS + HTTP/2 方案相比,有以下几点主要特征:
    1)利用缓存,显著减少连接建立时间;
    2)改善拥塞控制,拥塞控制从内核空间到用户空间;
    3)没有队头阻塞的多路复用;
    4)前向纠错,减少重传;
    5)连接平滑迁移,网络状态的变更不会影响连接断线

    核心特征

    连接建立延时低

    0RTT 建连可以说是 QUIC 相比 HTTP2 最大的性能优势。那什么是 0RTT 建连呢?
    这里面有两层含义:

    • 传输层 0RTT 就能建立连接;
    • 加密层 0RTT 就能建立加密连接。

    HTTPS 及 QUIC 建连过程:
    在这里插入图片描述
    另外,在实现前向加密的基础上,QUIC的 0RTT 的成功率相比 TLS 的 Sesison Ticket要高很多。

    改进的拥塞控制

    TCP 的拥塞控制实际上包含了四个算法:慢启动,拥塞避免,快速重传,快速恢复 [22]。
    QUIC 协议当前默认使用了 TCP 协议的 Cubic 拥塞控制算法 [6],同时也支持 CubicBytes, Reno, RenoBytes, BBR, PCC 等拥塞控制算法。
    从拥塞算法本身来看,QUIC 只是按照 TCP 协议重新实现了一遍。
    那么 QUIC 协议到底改进在哪些方面呢?主要有如下几点。

    改进方面

    可插拔

    什么叫可插拔呢?就是能够非常灵活地生效,变更和停止。体现在如下方面:

    • 1)应用程序层面就能实现不同的拥塞控制算法,不需要操作系统,不需要内核支持。这是一个飞跃,因为传统的 TCP 拥塞控制,必须要端到端的网络协议栈支持,才能实现控制效果。而内核和操作系统的部署成本非常高,升级周期很长,这在产品快速迭代,网络爆炸式增长的今天,显然有点满足不了需求;
    • 2)即使是单个应用程序的不同连接也能支持配置不同的拥塞控制。就算是一台服务器,接入的用户网络环境也千差万别,结合大数据及人工智能处理,我们能为各个用户提供不同的但又更加精准更加有效的拥塞控制。比如 BBR 适合,Cubic 适合;
    • 3)应用程序不需要停机和升级就能实现拥塞控制的变更,我们在服务端只需要修改一下配置,reload 一下,完全不需要停止服务就能实现拥塞控制的切换。

    STGW 在配置层面进行了优化,我们可以针对不同业务,不同网络制式,甚至不同的 RTT,使用不同的拥塞控制算法。

    【单调递增的 Packet Number】:

    TCP 为了保证可靠性,使用了基于字节序号的 Sequence Number 及 Ack 来确认消息的有序到达。

    QUIC 同样是一个可靠的协议,它使用 Packet Number 代替了 TCP 的 sequence number,并且每个 Packet Number 都严格递增,也就是说就算 Packet N 丢失了,重传的 Packet N 的 Packet Number 已经不是 N,而是一个比 N 大的值。而 TCP 呢,重传 segment 的 sequence number 和原始的 segment 的 Sequence Number 保持不变,也正是由于这个特性,引入了 Tcp 重传的歧义问题。
    Tcp 重传歧义性:
    在这里插入图片描述
    而 Quic 重传的 Packet 和原始 Packet 的 Pakcet Number 是严格递增的,所以很容易就解决了这个问题。
    Quic 重传没有歧义性:
    在这里插入图片描述
    如上图所示,RTO 发生后,根据重传的 Packet Number 就能确定精确的 RTT 计算。如果 Ack 的 Packet Number 是 N+M,就根据重传请求计算采样 RTT。如果 Ack 的 Pakcet Number 是 N,就根据原始请求的时间计算采样 RTT,没有歧义性。

    Stream Offset

    但是单纯依靠严格递增的 Packet Number 肯定是无法保证数据的顺序性和可靠性。QUIC 又引入了一个 Stream Offset 的概念。

    即一个 Stream 可以经过多个 Packet 传输,Packet Number 严格递增,没有依赖。但是 Packet 里的 Payload 如果是 Stream 的话,就需要依靠 Stream 的 Offset 来保证应用数据的顺序。如错误! 未找到引用源。所示,发送端先后发送了 Pakcet N 和 Pakcet N+1,Stream 的 Offset 分别是 x 和 x+y。

    假设 Packet N 丢失了,发起重传,重传的 Packet Number 是 N+2,但是它的 Stream 的 Offset 依然是 x,这样就算 Packet N + 2 是后到的,依然可以将 Stream x 和 Stream x+y 按照顺序组织起来,交给应用程序处理。
    Stream Offset 保证有序性:
    在这里插入图片描述

    不允许 Reneging

    什么叫 Reneging 呢?就是接收方丢弃已经接收并且上报给 SACK 选项的内容 [8]。TCP 协议不鼓励这种行为,但是协议层面允许这样的行为。主要是考虑到服务器资源有限,比如 Buffer 溢出,内存不够等情况。

    Reneging 对数据重传会产生很大的干扰。因为 Sack 都已经表明接收到了,但是接收端事实上丢弃了该数据。

    QUIC 在协议层面禁止 Reneging,一个 Packet 只要被 Ack,就认为它一定被正确接收,减少了这种干扰。

    更多的 Ack 块

    TCP 的 Sack 选项能够告诉发送方已经接收到的连续 Segment 的范围,方便发送方进行选择性重传。

    由于 TCP 头部最大只有 60 个字节,标准头部占用了 20 字节,所以 Tcp Option 最大长度只有 40 字节,再加上 Tcp Timestamp option 占用了 10 个字节 [25],所以留给 Sack 选项的只有 30 个字节。

    每一个 Sack Block 的长度是 8 个,加上 Sack Option 头部 2 个字节,也就意味着 Tcp Sack Option 最大只能提供 3 个 Block。

    但是 Quic Ack Frame 可以同时提供 256 个 Ack Block,在丢包率比较高的网络下,更多的 Sack Block 可以提升网络的恢复速度,减少重传量。

    Ack Delay 时间

    Tcp 的 Timestamp 选项存在一个问题 [25],它只是回显了发送方的时间戳,但是没有计算接收端接收到 segment 到发送 Ack 该 segment 的时间。这个时间可以简称为 Ack Delay。
    这样就会导致 RTT 计算误差。如下图:
    在这里插入图片描述
    在这里插入图片描述

    基于 stream 和 connecton 级别的流量控制

    QUIC 的流量控制 [22] 类似 HTTP2,即在 Connection 和 Stream 级别提供了两种流量控制。为什么需要两类流量控制呢?主要是因为 QUIC 支持多路复用。

    Stream 可以认为就是一条 HTTP 请求。

    Connection 可以类比一条 TCP 连接。多路复用意味着在一条 Connetion 上会同时存在多条 Stream。既需要对单个 Stream 进行控制,又需要针对所有 Stream 进行总体控制。

    QUIC 实现流量控制的原理比较简单:

    通过 window_update 帧告诉对端自己可以接收的字节数,这样发送方就不会发送超过这个数量的数据。

    通过 BlockFrame 告诉对端由于流量控制被阻塞了,无法发送数据。

    QUIC 的流量控制和 TCP 有点区别,TCP 为了保证可靠性,窗口左边沿向右滑动时的长度取决于已经确认的字节数。如果中间出现丢包,就算接收到了更大序号的 Segment,窗口也无法超过这个序列号。

    但 QUIC 不同,就算此前有些 packet 没有接收到,它的滑动只取决于接收到的最大偏移字节数。
    Quic Flow Control:
    在这里插入图片描述
    针对 Stream:
    在这里插入图片描述
    针对 Connection:
    在这里插入图片描述
    同样地,STGW 也在连接和 Stream 级别设置了不同的窗口数。

    最重要的是,我们可以在内存不足或者上游处理性能出现问题时,通过流量控制来限制传输速率,保障服务可用性。

    没有队头阻塞的多路复用

    QUIC 的多路复用和 HTTP2 类似。在一条 QUIC 连接上可以并发发送多个 HTTP 请求 (stream)。但是 QUIC 的多路复用相比 HTTP2 有一个很大的优势。

    QUIC 一个连接上的多个 stream 之间没有依赖。这样假如 stream2 丢了一个 udp packet,也只会影响 stream2 的处理。不会影响 stream2 之前及之后的 stream 的处理。

    这也就在很大程度上缓解甚至消除了队头阻塞的影响。

    多路复用是 HTTP2 最强大的特性 [7],能够将多条请求在一条 TCP 连接上同时发出去。但也恶化了 TCP 的一个问题,那就是队头阻塞
    HTTP2 队头阻塞:
    在这里插入图片描述
    HTTP2 在一个 TCP 连接上同时发送 4 个 Stream。其中 Stream1 已经正确到达,并被应用层读取。但是 Stream2 的第三个 tcp segment 丢失了,TCP 为了保证数据的可靠性,需要发送端重传第 3 个 segment 才能通知应用层读取接下去的数据,虽然这个时候 Stream3 和 Stream4 的全部数据已经到达了接收端,但都被阻塞住了。

    不仅如此,由于 HTTP2 强制使用 TLS,还存在一个 TLS 协议层面的队头阻塞
    TLS 队头阻塞:
    在这里插入图片描述
    Record 是 TLS 协议处理的最小单位,最大不能超过 16K,一些服务器比如 Nginx 默认的大小就是 16K。由于一个 record 必须经过数据一致性校验才能进行加解密,所以一个 16K 的 record,就算丢了一个字节,也会导致已经接收到的 15.99K 数据无法处理,因为它不完整。

    那 QUIC 多路复用为什么能避免上述问题呢?

    1)QUIC 最基本的传输单元是 Packet,不会超过 MTU 的大小,整个加密和认证过程都是基于 Packet 的,不会跨越多个 Packet。这样就能避免 TLS 协议存在的队头阻塞;
    2)Stream 之间相互独立,比如 Stream2 丢了一个 Pakcet,不会影响 Stream3 和 Stream4。不存在 TCP 队头阻塞。

    QUIC 多路复用时没有队头阻塞的问题:
    在这里插入图片描述
    当然,并不是所有的 QUIC 数据都不会受到队头阻塞的影响,比如 QUIC 当前也是使用 Hpack 压缩算法 [10],由于算法的限制,丢失一个头部数据时,可能遇到队头阻塞。

    总体来说,QUIC 在传输大量数据时,比如视频,受到队头阻塞的影响很小。

    加密认证的报文

    TCP 协议头部没有经过任何加密和认证,所以在传输过程中很容易被中间网络设备篡改,注入和窃听。比如修改序列号、滑动窗口。这些行为有可能是出于性能优化,也有可能是主动攻击。

    但是 QUIC 的 packet 可以说是武装到了牙齿。除了个别报文比如 PUBLIC_RESET 和 CHLO,所有报文头部都是经过认证的,报文 Body 都是经过加密的。

    这样只要对 QUIC 报文任何修改,接收端都能够及时发现,有效地降低了安全风险。

    如下图所示,红色部分是 Stream Frame 的报文头部,有认证。绿色部分是报文内容,全部经过加密。
    在这里插入图片描述

    连接迁移

    一条 TCP 连接 [17] 是由四元组标识的(源 IP,源端口,目的 IP,目的端口)。什么叫连接迁移呢?就是当其中任何一个元素发生变化时,这条连接依然维持着,能够保持业务逻辑不中断。当然这里面主要关注的是客户端的变化,因为客户端不可控并且网络环境经常发生变化,而服务端的 IP 和端口一般都是固定的。

    比如大家使用手机在 WIFI 和 4G 移动网络切换时,客户端的 IP 肯定会发生变化,需要重新建立和服务端的 TCP 连接。

    又比如大家使用公共 NAT 出口时,有些连接竞争时需要重新绑定端口,导致客户端的端口发生变化,同样需要重新建立 TCP 连接。

    针对 TCP 的连接变化,MPTCP[5] 其实已经有了解决方案,但是由于 MPTCP 需要操作系统及网络协议栈支持,部署阻力非常大,目前并不适用。

    所以从 TCP 连接的角度来讲,这个问题是无解的。

    那 QUIC 是如何做到连接迁移呢?很简单,任何一条 QUIC 连接不再以 IP 及端口四元组标识,而是以一个 64 位的随机数作为 ID 来标识,这样就算 IP 或者端口发生变化时,只要 ID 不变,这条连接依然维持着,上层业务逻辑感知不到变化,不会中断,也就不需要重连。

    由于这个 ID 是客户端随机产生的,并且长度有 64 位,所以冲突概率非常低。

    其他亮点

    此外,QUIC 还能实现前向冗余纠错,在重要的包比如握手消息发生丢失时,能够根据冗余信息还原出握手消息。

    QUIC 还能实现证书压缩,减少证书传输量,针对包头进行验证等。

    更多相关内容
  • quic:Go语言的QUIC协议

    2021-05-22 22:43:29
    Go语言的QUIC协议 正在为Golang中的QUIC程序进行高级API定义的工作。 有关QUIC协议的Google官方信息,请访问以下网站: 官方QUIC信息位于chromium.org: ChromeQUIC源代码: QUIC论坛: 目录: 超时 ing 起搏 ...
  • 纯Go中的QUIC实现 quic-go是Go中协议的实现。 它实现了和 。 版本兼容性 由于quic-go正在积极开发中,因此不能保证两个不同提交的构建版本可以互操作。 master分支中使用的QUIC版本只是一个占位符,不应视为稳定...
  • 该实现与quic-transport草案的第32版保持一致,并且尚未提供以下相关草案的实现: quic-tls 快速恢复 开始吧 最少的工作实例 预习 服务器 using System ; using System . Text ; using QuicNet ; using ...
  • 纯Go中的QUIC实现 quic-go是Go中协议的实现。 它实现了 ,和 。 版本兼容性 由于quic-go正在积极开发中,因此不能保证两个不同提交的构建可互操作。 master分支中使用的QUIC版本只是一个占位符,不应被认为是稳定的...
  • aioquic是Python中QUIC网络协议的库。 它具有最小的TLS 1.3实现,QUIC堆栈和HTTP / 3堆栈。 QUIC标准化尚未最终确定,但是aioquic密切跟踪规范草案,并定期测试其与其他互操作性。 要了解有关aioquic更多信息,请...
  • QUIC客户端Java库 Kwik是Java中协议的客户端实现。 QUIC是由IETF开发的全新传输协议,它将成为新HTTP3协议的传输层。 尽管QUIC对于HTTP3而言是必需的,但它不仅仅是HTTP3的传输协议:大多数人都将QUIC视为“下一代...
  • 它是跨平台的,用C语言编写,旨在用作通用QUIC库。 重要说明QUIC协议不是正式的RFC。 它已被IESG批准,现在在RFC编辑器队列中(最后一步)。 IETF草案:, ,,, 协议功能 与现有的“基于TCP的TLS”方案相比,...
  • QUIC的测试套件 该测试套件包括一个QUIC的最小Go实现,该实现当前可兼容草稿29和TLS-1.3,以及基于此实现构建的多个测试场景。 测试套件将其结果输出为JSON文件,其中包含结果,交换的解密数据包以及pcap文件和导出...
  • 基于SOCKS5和QUIC的安全代理。 客户端侦听新连接,然后通过QUIC将它们转发到远程服务器。 服务器充当SOCKS5服务器,但处理快速连接而不是TCP连接。 另外,服务器使用客户端证书进行客户端身份验证。 要求 客户端和...
  • 一个将QUIC套接字与TCP套接字的性能进行比较的项目。 动机 QUIC是最初由Google开发的传输层协议,目前由IETF开发和标准化。 QUIC的HTTP映射称为HTTP / 3,这是HTTP的最新版本。 默认情况下,通过QUIC进行的通信是...
  • quic协议
  • 互操作性测试运行程序旨在通过使用不同的QUIC实现运行多个测试用例来自动生成互操作性矩阵。 运行Interop Runner Interop Runner是用Python 3编写的。您需要安装一些Python模块才能运行它: pip3 install -r ...
  • QUIC协议 QUIC for ios QUIC framework 下载此库,五六个小时没了,前提是中间不断网, 编译此库 漫长且艰难,其中问题多多 总编译后文件 21G 这个chrome 太肉了
  • ns-3的QUIC实现 QUIC代码库 该存储库包含在ns-3中本机IETF QUIC实现的代码中。 描述了该实现。 请使用此查找错误/问题。 安装 先决条件 要使用此模块运行仿真,您将需要安装ns-3,在src目录中克隆此存储库,从quic...
  • go-libp2p-quic-transport go-libp2p-quic-transport使用quic- 为libp2p提供QUIC支持。 安装 go-libp2p-quic-transport是一个标准的Go模块,可以通过以下方式安装: go get github....
  • 适用于Zeek的Google QUIC分析器/检测器 该分析器可以使用以下描述的有线格式来解析和检测QUIC的Google实现(此处为简单起见,此处称为GQUIC): 。 Chrome在编写此分析器时使用的GQUIC版本是Q039,某些Google...
  • ... 包装好的conn接口goframe包含一个FrameConn接口和一些具体的FrameConn实现:类型FrameConn接口{ReadFrame()([] byte,error)WriteFrame(p [] byte)error Close()error Conn()net.Conn} NewXXXXXXX函数可...
  • 谷歌QUIC协议C++源代码,QUIC是谷歌开发的基于UPD的网络传输协议,重新实现了连接加密、数据包排序、丢包重传、流控等技术,相对于TCP协议有较大的改进,可能成为下一代HTTP3.0的传输协议。
  • IETF QUIC在Haskell中的实现 该程序包基于Haskell轻量级线程实现QUIC。 在模块中找到API。 可以在目录中找到示例客户端和服务器。 实施计划和状态在中找到。 该软件包涵盖: 以下是在中实现的: 博客文章: ...
  • libp2p有效 libp2p的QUIC传输。 执照 国际学习中心
  • SrsQuic 该项目使用从导出的srs-...我们为提供了quic补丁,现在还支持quic的rtmp模块。 rtmp附加配置 rtmp { log_format rtmp_log '$remote_addr [$time_local] $command "$app" "$name" "$args" ' '$bytes_rec
  • goquic:QUIC对Go的支持

    2021-02-20 09:13:53
    goquic,Go的QUIC支持 这是Go正在进行的QUIC实施。 这基于库,而库又基于上的原始QUIC实现。 QUIC是一种实验性协议,旨在通过TCP减少Web延迟。 从表面上看,QUIC与在UDP上实现的TCP + TLS + SPDY非常相似。 由于...
  • 纯Go中的QUIC实现纯Go Quic-go中的QUIC实现是Go中QUIC协议的实现。 尽管我们目前不完全支持任何草案版本,但它大致实现了IETF QUIC草案。 版本兼容性由于quic-go正在积极开发中,因此不能保证两个不同提交的内部版本...
  • Cronet-Quic-Log-Analytics

    2021-05-25 12:48:05
    Cronet日志对于QUIC客户端和服务器开发人员很重要,其中包括详细的Quic Connection / Stream / Frame日志。 但是通过netlog-viewer( )读取日志很痛苦,因此我决定制作自己的工具来加快该过程。 通过此工具,您...
  • libp2p-quic libp2p的QUIC传输 :warning: 在制品 安装 npm install libp2p-quic 用法 const QUIC = require ( 'libp2p-quic' ) const transport = new QUIC . Transport ( { upgrader } ) await transport . dial ...
  • QUIC加密协议.pdf

    2020-12-02 16:12:05
    QUIC加密协议.pdf 高清版,文档介绍的只是老版的quic协议,虽然版本较老,但介绍详细,具有一定的借鉴价值意义。
  • quic-protocol-java.zip

    2021-04-28 23:43:51
    quic-protocol:Google对QUIC(HTTP3)协议的纯Java实现-源码
  • 用法 生成测试文件: Linux head -c SIZE /dev/urandom > dummy 视窗 fsutil file createnew dummy SIZE 安装Caddy : : 创建CaddyFile localhost:8080 ...caddy -quic 打开浏览器并导航到
  • quic、prot_quic、goquic、libquic源码中文注释分析,增加C++ quic-client和quic-server example 程序,便于快速掌握学习谷歌quic库源码和学习quic协议,作为新的网络加速协议

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 7,177
精华内容 2,870
关键字:

quic