标签归档：quic

HTTP / 3用UDP替换TCP以提高网络速度，可靠性

为站点和服务获得HTTP / 2的性能和安全性优势意味着进行体系结构更改，因为它颠覆了用于提高网站性能的分片等原则; 这可能就是为什么只有大约35％的网站目前使用HTTP / 2。

HTTP / 3加倍，提供非常相似的功能，但用UDP替换TCP。这一次可能需要对网络基础设施进行更根本的改变，以便利用比较差的连接和移动网络更好的性能，但对于大多数开发人员来说，这种改变将是透明的。

HTTP / 3是该协议的第三个主要版本，它包括TLS 1.3和一种称为QUIC（Quick UDP Internet Connection）的新传输协议; 根据最初由Google设计的2013协议，现在有多个贡献者和公司通过互联网工程任务组（IETF）参与其中。

不可靠是一个机会

放弃HTTP一直用于UDP的TCP连接并不像看起来那么奇怪。U有时会扩展为“不可靠”而不是用户数据报协议，因为它不保证消息传递或数据包顺序。但是对于今天的网络，这实际上是一个提高HTTP / 2引入的多路复用连接性能的机会。“凭借HTTP / 3，我们将在同一个旧的不可靠互联网之上构建一个新的可靠协议，” Cloudflare首席技术官John Graham-Cumming告诉New Stack。

HTTP / 2通过在同一连接上发送多个HTTP请求，允许应用程序同时处理请求，从而更好地利用网络带宽。但只有在网络运行良好时才能实现这些收益。“你可以最大限度地提高吞吐量和带宽，因为TCP可以达到它可以达到的最大速度，并且所有并行连接都能以最快的速度运行，”Graham-Cumming说。

这很好，直到网络连接出现打嗝，例如网络拥塞或移动网络上从一个小区移动到另一个小区并且数据包丢失。“TCP保证发送数据包的顺序是应用程序接收的顺序 – 所以如果你错过了，那么一切都必须停止，直到特定数据包被重新传输。如果将多个请求复用到单个TCP连接上，则所有这些请求都必须停止并等待，即使丢失的数据包可能只影响其中一个。

Graham-Cumming解释说，这种“线路阻塞问题”是TCP固有的问题，使用UDP通过允许应用程序控制数据包的重传来修复它。“它可以说’数据包丢失，但它只影响这一个数据流，而其他数据流可以继续运行’。”这使得QUIC 在恶劣的网络条件下更加强大。

HTTP / 3的连接迁移提议可以扩展在不同网络之间移动的稳健性，例如从Wi-Fi到移动宽带，这通常会因为IP地址的变化而破坏网络连接。“通过此提议，您和服务器之间的标识符将不是IP地址，而是协议本身内的标识符。这样您就可以在新网络上自动重启整个连接，这样您就可以无缝地从Wi-Fi转移到移动连接。原始互联网的一些假设是，存在相当固定的连接，我们现在正在进入一个非常移动的异构世界。“

Graham-Cumming解释说，HTTP / 3还直接集成了TLS，QUIC对数据包传输的额外控制也具有优势。“当事情通过互联网发送时，它们会被分解成数据包; 在TLS中，有一个传输数据缓冲区的概念。如果你想要真正有效率，你想要把所有这些事情排好; 这是一个请求，我将对它进行加密并通过互联网进行传输，以便一次性收到所有这些请求，并且不会分成较小的数据包，其中一些不会被延迟。如果您控制所有级别，如果您只是假设互联网是一种不可靠的发送数据包的方式，那么您可以控制发送内容的顺序，您可以控制加密它们的方式以及这些加密块如何传输。“

与HTTP服务器的初始连接将更快，因为HTTP / 3取出了通常需要建立连接的往返之一安全解释说，Mozilla首席工程师Martin Thomson是QUIC规范的编辑之一。

“使用TCP和TLS，连接设置以TCP握手开始：客户端发送SYN，服务器响应SYN + ACK，客户端使用ACK完成。然后在发送任何请求之前有一个TLS握手 – 它需要另一个类似的三个消息交换。QUIC在大多数情况下将其压缩到单个交换。一个关键特性是0-RTT，允许客户端立即发送请求; 这是TCP和TLS的一个选项，但你仍然需要等待TCP握手完成。“

默认安全

集成TLS还可以提高安全性，因为身份验证和加密是由网络协议提供的，而不是像TLS这样的高级协议提供的 – 而且在HTTP / 3中内置了TLS，使用它也不是可选的。Graham-Cumming指出：“业界正试图在默认情况下保证一切安全。” 当站点使用HTTPS时，浏览器现在会在站点没有加密连接时向您发出警告，而不是显示锁定。HTTP / 3和QUIC是这个方向的另一个举措。

“更多的QUIC是加密的，”汤姆森解释道。这包括攻击者可能尝试使用的元数据。“除了一些有助于将数据包识别为QUIC数据包的比特之外，未加密的QUIC数据包的唯一部分是连接的不透明标识符。这包括TCP和TLS无法保护的内容，例如确认（’我从你那里得到5个字节’）。“

Thomson还认为加密实际上将简化部署QUIC。将新协议部署到需要更新的防火墙，路由器，NAT和其他网络设备上的复杂性阻碍了在浏览器中  创建新的，更有效的传输协议和延迟采用TLS 1.3的努力。“这是部署QUIC的可能性的一部分。互联网往往会干扰新的协议，加密将保护QUIC免受干扰。“

他坚持认为，这是UDP是一个不错的选择的另一个原因。“新的协议不能直接部署在IP之上，如TCP或UDP，因为这需要更新的互联网。考虑更换或升级每个想要使用此新协议的房屋中的每个路由器的前景。UDP在这种情况下是理想的，因为它做得很少。它非常轻巧，因此我们可以在顶部构建所有必要的部件。UDP的主要缺点是已经显示阻止或降级UDP的少量网络。在极少数情况下，我们有HTTP / 2可以依靠。“

当用户访问站点时，他们的初始连接将通过HTTP或HTTP / 2，服务器将提供HTTP / 3作为替代; 了解提供该连接的标头的浏览器将记住它以供下次访问，但较旧的浏览器和设备将继续使用旧协议。格雷厄姆 – 卡明预测说：“我们预计HTTP / 2和1.1将会存在很长时间。”

网络变化

HTTP / 3可能有它的名字，但它仍在开发中; Graham-Cumming表示，情况稳定前几个月。尽管有一些HTTP / 3端点可用于测试Cloudflare等服务，但Facebook和Litespeed 已经证明了  2018年11月的HTTP / 3实现之间的互操作性，浏览器和Web服务器还没有支持HTTP / 3（Chrome的实验支持除外）对于谷歌的原始版本的QUIC）。

一旦他们这样做，服务提供商和托管公司将遵循，但可能需要更新旧的网络设备。“对于UDP的NAT遍历并不像TCP那样发达，一些家庭路由设备会假设UDP用于流媒体视频，而不是网络，”Graham-Cumming说。

Thomson说，如果你托管自己的网络服务器，你还有更多工作要做。“服务器管理员会发现QUIC需要的不仅仅是软件升级。启用UDP将需要网络和负载平衡基础架构的新支持。“网络运营商可能需要研究可以在软件中实现的更智能的第4层负载平衡解决方案，如Facebook的Katran项目。

但由于HTTP / 3旨在解决HTTP / 2的问题，因此对HTTP / 2进行的优化（如域分片的更改）将在可用时自动应用。如果是这样的话，Graham-Cumming希望它能够推动网络的发展。“我们希望的是更快的网络下载和API。它应该使互联网更加可靠和快速，并且希望对于开发者来说，我们可以获得更丰富的API和Web应用程序，因为我们可以通过这种新协议更多地依赖互联网。

https://thenewstack.io/http-3-replaces-tcp-with-udp-to-boost-network-speed-reliability/

Caddy nginx服务器QUIC部署

Caddy 简介

Caddy是一个Go语言写的，易于使用的通用Web服务器。它具有如下的一些功能：

  • 配置简单：Caddy服务器的运行可以通过Caddyfile配置文件进行配置，Web服务配置起来非常简单。
  • 自动的HTTPS：它可以自动地为我们申请 Let’s Encrypt 域名证书，管理所有的密码学设施，并进行配置。
  • HTTP/2：默认支持HTTP/2（由Go标准库支持）
  • 虚拟主机托管：Caddy支持TLS的SNI。SNI是在2006年加入TLS的一个TLS扩展。客户端在TLS握手的Client Hello消息中，通过SNI扩展将请求的资源的域名发送给服务器，服务器根据SNI的域名来下发TLS证书。这样就可以在具有单个公网IP的同一台主机上部署多个不同的域名的服务。可以为Caddy服务的不同域名配置不同的证书和密钥。
  • QUIC支持：Caddy实验性地支持QUIC协议，以获取更好的性能。
  • TLS session ticket key rotation for more secure connections
  • 良好的可扩展性：因此Caddy非常方便针对自己的需求做定制。
  • 随处运行：这主要与Go应用程序的特性有关。Go的模块都被编译为静态库，这使得Go的应用程序在编译为可执行文件时都是静态链接的，因而依赖的动态库极少，这使得部署使用非常方便。

自动的HTTPS、HTTP/2支持、QUIC支持和随处运行这些特性非常有吸引力，特别是对QUIC的支持。

此外，Caddy的性能非常好。下面两幅图是我的静态个人博客站点，分别是用Caddy和nginx作为Web服务器，打开主页所需的加载时间对比：
Service with Caddy

Service with nginx

上面的图显示了以Caddy作为Web服务器，主页的加载时间只有680ms；下面的图显示以nginx作为Web服务器，主页的加载时间则长达1.99s，要慢接近2倍。

Caddy部署

Caddy应用程序不依赖于其它组件，且官方已经为不同的平台提供了二进制可执行程序。可以通过如下三种方式之一安装Caddy：

  • 在 下载页，通过浏览器定制自己需要的功能集，并下载相应的二进制可执行程序。
  • 预编译的 最新发行版 二进制可执行程序。
  • curl getcaddy.com 来自动安装：curl https://getcaddy.com | bash。

将caddy的路径加如PATH环境变量中。之后可以 cd 进入网站的文件夹，并运行 caddy来提供服务。默认情况下，Caddy在2015端口上为网站提供服务。

要定制网站提供服务的方式，可以为网站创建名为Caddyfile的文件。当运行 caddy 命令时，它会自动地在当前目录下寻找并使用Caddyfile文件来为自己做配置。

要了解更多关于Caddyfile文件的写法，可以参考 Caddyfile 文档。

注意生产环境网站默认是通过HTTPS提供服务的。

Caddy还有命令行接口。运行caddy -h 可以查看基本的帮助信息，或参考 CLI文档 来了解更多详情。

以Root运行：建议不要这样做。但依然可以通过像这样使用setcap来监听端口号小于1024的端口：sudo setcap cap_net_bind_service=+ep ./caddy

由源码运行

注意：需要安装 Go 1.7或更新的版本才可以。

  1. go get github.com/mholt/caddy/caddy
  2. cd 进入网站的目录
  3. 执行caddy（假设 $GOPATH/bin 已经在 $PATH 中了）

Caddy的 main() 再caddy子目录下。要编译Caddy，可以使用在那个目录下找到的 build.bash。

在生产环境运行

Caddy项目官方不维护任何系统特有的集成方法，但下载的文档中包含了社区共享的 非官方资源，用以帮助在生产环境运行Caddy。

以何种方式运行Caddy全由自己决定。许多用户使用 nohup caddy & 就可以满足需求了。其他人使用 screen。有些用户需要再重启之后就运行Caddy，可以在触发重启的脚本中来做到这一点，通过给init脚本添加一个命令，或给操作系统配置一个service。

可以看一下我的个人博客站点的完整Caddyfile内容： 

					

						1
					


					

						2
					


					

						3
					


					

						4
					


					

						5
					


					

						6
					


					

						7
					


					

						8
					


					

						9
					


					

						10
					


					

						11
					


					

						12
					


					

						13
					


					

						14
					


					

						15
					


					

						wolfcstech.com:80 www.wolfcstech.com:80 {
					


					

						root /home/www-data/www/hanpfei-documents/public
					


					

						redir 301 {
					


					

						if {>X-Forwarded-Proto} is http
					


					

						/  https://{host}{uri}
					


					

						}
					


					

						}
					


					

						
					


					

						wolfcstech.com:443 www.wolfcstech.com:443 {
					


					

						tls /home/www-data/www/ssl/chained.pem /home/www-data/www/ssl/domain.key
					


					

						#tls test@admpub.com
					


					

						root /home/www-data/www/hanpfei-documents/public
					


					

						gzip
					


					

						log ../access.log
					


					

						}

启用QUIC

Caddy 0.9 已经实验性地提供了对QUIC的支持，这主要通过 lucas-clemente/quic-go 来实现。要尝试这个特性，可以在运行caddy时加上 -quic 标记： 

					

						1
					


					

						$ caddy -quic

这样执行之后，则带有TLS加密的Web服务，在客户端支持QUIC时，将默认通过QUIC协议来完成数据的传输。

不启用QUIC时，在启动caddy之后，在服务器端查看已打开的端口号： 

					

						1
					


					

						2
					


					

						3
					


					

						4
					


					

						5
					


					

						6
					


					

						7
					


					

						# lsof -i -P
					


					

						COMMAND     PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
					


					

						AliYunDun 1120 root 10u  IPv4 2023899 0t0  TCP 139.196.224.72:40309->106.11.68.13:80 (ESTABLISHED)
					


					

						. . . . . .
					


					

						caddy 6163 root 6u  IPv6 2338478 0t0  TCP *:80 (LISTEN)
					


					

						caddy 6163 root 8u  IPv6 2338479 0t0  TCP *:443 (LISTEN)
					


					

						. . . . . .

而在通过如下命令： 

					

						1
					


					

						# nohup ./caddy -quic &

启用QUIC提供Web服务之后，在服务器端查看已打开端口号，则可以看到如下内容： 

					

						1
					


					

						2
					


					

						3
					


					

						4
					


					

						5
					


					

						6
					


					

						7
					


					

						8
					


					

						9
					


					

						# lsof -i -P
					


					

						COMMAND     PID  USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
					


					

						AliYunDun  1120  root   10u  IPv4 2023899  0t0  TCP 139.196.224.72:40309->106.11.68.13:80 (ESTABLISHED)
					


					

						. . . . . .
					


					

						caddy  6222  root    6u  IPv6 2338880  0t0  TCP *:80 (LISTEN)
					


					

						caddy  6222  root    8u  IPv6 2338881  0t0  TCP *:443 (LISTEN)
					


					

						caddy  6222  root    9u  IPv6 2338883  0t0  UDP *:80
					


					

						caddy  6222  root   10u  IPv6 2338885  0t0  UDP *:443
					


					

						. . . . . .

Caddy 除了监听http的TCP 80端口和https 的TCP 443端口之外，还监听了UDP的80和443端口。

客户端支持

Chrome 52+ 支持QUIC而无需白名单，但需要确认 #enable-quic 标记已经被启用了。通过在Chrome浏览器的地址栏输入chrome://flags/：

Enable QUIC

并根据需要启用QUIC。

然后通过Chrome打开你的网站，则它应该是以QUIC提供服务的！可以通过打开inspector 工具并进入Security tab来验证这一点。重新加载页面并点击来查看连接详情：

caddy005.png

如果你使用老版的Chrome，则为了省事，可以升级一下。

如果你不想升级，则可以：你将需要以特殊的参数来运行Chrome。再Mac上 (将YOUR_SITE替换为你的网站的实际域名)执行如下命令： 

					

						1
					


					

						2
					


					

						3
					


					

						4
					


					

						5
					


					

						$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
					


					

						--user-data-dir=/tmp/chrome \
					


					

						--no-proxy-server \
					


					

						--enable-quic \
					


					

						--quic-host-whitelist="YOUR_SITE" "YOUR_SITE"

QUIC的好处

QUIC是基于UDP的TLS+HTTP的可靠传输协议。它加速了TLS握手为只有一个往返，避免了TCP慢启动，并提供了网络切换时的可靠性。通过QUIC可以让网站加载更快且更可靠。

问题排解

首先，确保在Caddyfile文件中为域名做了适当的设置，还要确保在启动Chrome的命令行中为域名做了适当的设置。

接着，网站必须使用一个真实的可信的证书（至少，是在写的时候）。

如果那都是好的，而且你对Go语言比较了解，则你可以添加 import "github.com/lucas-clemente/quic-go/utils"，并在Caddy的main()函数的某个地方调用utils.SetLogLevel(utils.LogLevelDebug)。那将提供非常详细的输出。（注意这个log设施不是一个公共的API）。

当你进入chrome://net-internals/#events，你应该看到一些QUIC事件被标为红色。

Net Events

坚持原创技术分享，您的支持将鼓励我继续创作！

https://www.wolfcstech.com/2017/01/09/Caddy%20Web%E6%9C%8D%E5%8A%A1%E5%99%A8QUIC%E9%83%A8%E7%BD%B2/

访问Google的神器：Chrome的QUIC协议

在Google新版的Chrome浏览器中，支持QUIC协议，在 Chrome 浏览器中打开“实验性功能”页面（chrome://flags/），启用“实验性 QUIC 协议”和“经由实验性 QUIC 协议发出的 HTTPS 请求”，重启浏览器后可以正常登陆 Google 相关服务(被DNS污染的除外)。对于被DNS污染的Google服务，还需要设置Hosts的IP，然后通过HTTPS才能访问。

QUIC协议的原理介绍：

TCP、UDP都是计算机网络通信层的主要协议。TCP是面向连接的，更强调的是传输的可靠性，UDP是面向无连接的，也即在通信双方进行数据交换之前，无需建立连接,只要知道对方地址即可发送数据，由于UDP协议是无连接方式的协议，所以它的效率高，速度快，占资源少。

为了集合两者的优点，谷歌公司研制了一种UDP通信的改进版——Quick UDP Internet Connections（QUIC），快速UDP互联网连接。

QUIC的主要特点包括，具有SPDY（SPDY是谷歌研制的提升HTTP速度的协议，是HTTP/2.0的基础）所有的优点；0-RTT连接；减少丢包；前向纠错，减少重传时延；自适应拥塞控制， 减少重新连接；相当于TLS加密。

总之，QUIC系统能够降低网络通信的延迟，提供更好的用户互动体验，尽管随着互联网的发展，网络带宽会持续增加，QUIC等新型通信协议具有越来越重要的意义。

QUIC是Quick UDP Internet Connections的缩写，读作quick。由Google开发，概要设计文档放在google docshttps://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit，还在不断更新。传输格式的详细设计文档放在https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit。

概要设计文档从TCP/UDP特性、网络安全等考虑出发，做了非常多设计思路方面的论述，开头就阐述了SPDY的4个缺点：

  1. 单个包（packet）丢失会阻塞整个流（stream）。
  2. TCP避免拥堵的机制做的不好，导致带宽降低和序列化的等待时间开销。
  3. TLS会话重连的等待时间开销。握手机制带来额外的Round Trip。
  4. TLS解密的开销。先到的包必须等后面的包到来才能解密。

可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。

QUIC的文档还算未完成的状态，且Chromium的实现代码也在完善中，这还是个试验性的半成品，没有性能比较的数据。只浅浅研究即止，不深入了。