新时代高科技不计其数越来越发达，小伙伴们看过不少科技新闻吧，在我们生活中应该也用到很多这些高科技东西，有哪些小伙伴值的关注的呢，今天就跟大家分享一篇有关科技方面知识，希望大家会喜欢。

今天来说一下QUIC 是什么这方面的一些讯息，不少朋友对QUIC 是什么这方面的一些讯息颇感兴趣的，小编今天就整理了一些信息，希望对有需要的朋友有所帮助。

QUIC(快速 UDP 网络连接)是一种实验性的网络传输协议，位于 OSI 模型的传输层。由 Google 开发，在 2013 年实现。QUIC 使用 UDP 协议，它在两个端点间创建连线，且支持多路复用连线。

QUIC(快速 UDP 网络连接，Quick UDP Internet Connections)是一种实验性的网络传输协议，位于 OSI 模型的传输层。由 Google 开发，在 2013 年实现。QUIC 使用 UDP 协议，它在两个端点间创建连线，且支持多路复用连线。

在设计之初，QUIC 希望能够提供等同于 SSL/TLS 层级的网络安全保护，减少数据传输及创建连线时的延迟时间，双向控制带宽，以避免网络拥塞。Google 希望使用这个协议来取代 TCP 协议，使网页传输速度加快，计划将 QUIC 提交至互联网工程任务小组(IETF)，让它成为下一代的正式网络规范。

2015 年 6 月，QUIC 的网络草案被正式提交至互联网工程任务组。

2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP (英语：HTTP over QUIC) 重命名为 HTTP/3 以为确立下一代规范做准备。

介绍

QUIC 旨在提供几乎等同于 TCP 连接的可靠性，但延迟大大减少。它主要通过两个理解 HTTP 流量的行为来实现这一点。

第一个变化是在连接创建期间大大减少开销。由于大多数 HTTP 连接都需要 TLS，因此 QUIC 使协商密钥和支持的协议成为初始握手过程的一部分。 当客户端打开连接时，服务器响应的数据包包括将来的数据包加密所需的数据。这消除了 TCP 上的先连接并通过附加数据包协商安全协议的需要。其他协议可以以相同的方式进行服务，并将多个步骤组合到一个请求中。 然后，这些数据既可用于初始设置中的后续请求，也可用于未来的请求。

QUIC 使用 UDP 协议作为其基础，不包括丢失恢复。相反，每个 QUIC 流是单独控制的，并且在 QUIC 级别而不是 UDP 级别重传丢失的数据。这意味着如果在一个流中发生错误，协议栈仍然可以独立地继续为其他流提供服务。 这在提高易出错链路的性能方面非常有用，因为在大多数情况下 TCP 协议通知数据包丢失或损坏之前可能会收到大量的正常数据，但是在纠正错误之前其他的正常请求都会等待甚至重发。 QUIC 在修复单个流时可以自由处理其他数据，也就是说即使一个请求发生了错误也不会影响到其他的请求。

QUIC 包括许多其他更普通的更改，这些更改也可以优化整体延迟和吞吐量。例如，每个数据包是单独加密的，因此加密数据时不需要等待部分数据包。 在 TCP 下通常不可能这样做，其中加密记录在字节流中，并且协议栈不知道该流中的更高层边界。这些可以由运行在更上层的协议进行协商，但 QUIC 旨在通过单个握手过程完成这些。

QUIC 的另一个目标是提高网络切换期间的性能，例如当移动设备的用户从 WiFi 热点切换到移动网络时发生的情况。 当这发生在 TCP 上时，一个冗长的过程开始了：每个现有连接一个接一个地超时，然后根据需要重新建立。期间存在较高延迟，因为新连接需要等待旧连接超时后才会建立。 为解决此问题，QUIC 包含一个连接标识符，该标识符唯一地标识客户端与服务器之间的连接，而无论源 IP 地址是什么。这样只需发送一个包含此 ID 的数据包即可重新创建连接，因为即使用户的 IP 地址发生变化，原始连接 ID 仍然有效。

QUIC 在应用程序空间中实现，而不是在操作系统内核中实现。当数据在应用程序之间移动时，这通常会由于上下文切换而调用额外的开销。 但是在 QUIC 下协议栈旨在由单个应用程序使用，每个应用程序使用 QUIC 在 UDP 上托管自己的连接。最终差异可能非常小，因为整个 HTTP/2 堆栈的大部分已经存在于应用程序(或更常见的库)中。 将剩余部分放在这些库中，基本上是纠错，对 HTTP/2 堆栈的大小或整体复杂性几乎没有影响。

QUIC 允许更容易地进行未来更改，因为它不需要更改内核就可以进行更新。 QUIC 的长期目标之一是添加前向纠错和改进的拥塞控制。

关于从 TCP 迁移到 UDP 的一个问题是 TCP 被广泛采用，并且互联网基础设施中的许多中间设备被调整为 UDP 速率限制甚至阻止 UDP。 Google 进行了一些探索性实验来描述这一点，发现只有少数连接存在此问题。所以 Chromium 的网络堆栈同时打开 QUIC 和传统 TCP 连接，并在 QUIC 连接失败时以零延迟回退到 TCP 连接。

gGUIC 与 iQUIC

由 Google 创建并以 QUIC 的名称提交给 IETF 的协议与随后在 IETF 中创建的 QUIC 完全不同(尽管名称相同)。 最初的 Google QUIC(也称为 gQUIC)严格来说是通过加密 UDP 发送 HTTP/2 帧的协议，而 IETF 创建的 QUIC 是通用传输协议，也就是说 HTTP 以外的其他协议(如 SMTP、DNS、SSH、Telnet、NTP)也可以使用它。重要的是要注意并记住其差异。 自 2012 年以来，Google 在其服务及 Chrome 中使用的 QUIC 版本(直到 2019 年 2 月)为 Google QUIC。随着时间的推移，它正在逐渐变得类似于 IETF QUIC(也称为 iQUIC)。

以上就是关于QUIC 是什么对比这方面的一些信息了 小编整理的这些讯息希望对童鞋们有所帮助。