标签归档:HTTP2

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/

Nginx配置支持HTTP2

从 2015 年 5 月 14 日 HTTP/2 协议正式版的发布到现在已经快有一年了,越来越多的网站部署了 HTTP2,HTTP2 的广泛应用带来了更好的浏览体验,只要是 Modern 浏览器都支持,所以部署 HTTP2 并不会带来太多困扰。

虽然 h2 有 h2c (HTTP/2 Cleartext) 可以通过非加密通道传输,但是支持的浏览器初期还是比较少的,所以目前部署 h2 还是需要走加密的,不过由于 Let’s Encrypt 大力推行免费证书和证书的廉价化,部署 h2 的成本并不高。

介绍

HTTP 2.0即超文本传输协议 2.0,是下一代HTTP协议。是由互联网工程任务组(IETF)的Hypertext Transfer Protocol Bis (httpbis)工作小组进行开发。是自1999年http1.1发布后的首个更新。

HTTP/2 协议是从 SPDY 演变而来,SPDY 已经完成了使命并很快就会退出历史舞台(例如 Chrome 将在「2016 年初结束对 SPDY 的支持」;Nginx、Apache 也已经全面支持 HTTP/2 ,并也不再支持 SPDY)。

一般的大家把 HTTP2 简称为 h2,尽管有些朋友可能不怎么愿意,但是这个简称已经默认化了,特别是体现在浏览器对 HTTP2 都是这个简写的。

配置

普通的 HTTPS 网站浏览会比 HTTP 网站稍微慢一些,因为需要处理加密任务,而配置了 h2 的 HTTPS,在低延时的情况下速度会比 HTTP 更快更稳定!

现在电信劫持事件频发,网站部署了 HTTPS 加密后可以杜绝大部分劫持,但不是完全。像电子商务行业对 HTTPS 加密可是标配啊,因此部署 h2 更是势在必行。

证书

这里是 免费和便宜 SSL 证书介绍 ,大家可以从这里购买或者申请免费的 SSL 证书,免得 Chrome 弹出红色的页面令人不悦,从而拒绝了大多数访客。

Web 服务器

说明

默认编译的 Nginx 并不包含 h2 模块,我们需要加入参数来编译,截止发文,Nginx 1.9 开发版及以上版本源码需要自己加入编译参数,从软件源仓库下载的则默认编译。 Tengine 可以同时部署 h2 和 SPDY 保证兼容性,Nginx 则是一刀切不再支持 SPDY。

安装/编译

如果你编译的 Nginx 不支持,那么在 ./configure 中加入:--with-http_v2_module ,如果没有 SSL 支持,还需要加入 --with-http_ssl_module

然后 make && make install 即可。

配置

主要是配置 Nginx 的 server 块, 。
修改相关虚拟机的 .conf 文件,一般在 /usr/local/nginx/conf/vhost/ 或者 /etc/nginx/conf/,具体参考你的环境指导,不懂请回复。

server { listen 443 ssl http2 default_server; server_name www.mf8.biz; ssl_certificate /path/to/public.crt; ssl_certificate_key /path/to/private.key; 

注:将 server_name www.mf8.biz; 中的 www.mf8.biz 替换为你的域名。

然后通过 /usr/local/nginx/sbin/nginx -t 或者 nginx -t 来检测是否配置正确,然后重启 Nginx ,即可。

检验

在 Chrome 浏览器上可以通过,HTTP/2 and SPDY indicator 来检验,如果地址栏出现蓝色的闪电就是 h2

也可以在 chrome://net-internals/#http2 中检查。注意版本要新,姿势要帅!

配置进阶

大家都知道去年的心血漏洞将 SSL 推到了风口浪尖,所以单单支持了 h2 ,我们任然需要对 SSL 做一些安全的优化!

配置赫尔曼密钥

openssl dhparam -out dhparam.pem 2048 // 在 ssh 运行, openssl 生成 2048 位的密钥而不是当作参数写入 nginx.conf 文件。 ssl_dhparam /path/to/dhparam.pem; //在 .conf 中配置 

禁止不安全的 SSL 协议,使用安全协议

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

禁止已经不安全的加密算法

ssl_ciphers
'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4';

也可以参考:ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;

缓解 BEAST 攻击

ssl_prefer_server_ciphers on;``` **启用 HSTS**

此举直接跳过 301 跳转,还降低了中间人攻击的风险!配置在 .conf 中即可 `add_header Strict-Transport-Security max-age=15768000;` **301 跳转** 80 端口跳转到 443 端口

server {
listen 80;
add_header Strict-Transport-Security max-age=15768000;
return 301 https://www.yourwebsite.com$request_uri;
}

 **缓存连接凭据** 

ssl_session_cache shared:SSL:20m;
ssl_session_timeout 60m;

 **OCSP 缝合** 

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/cert/trustchain.crt;
resolver 119.29.29.29 233.6.6.6 valid=300s;

nginx支持http2,openssl 升级openssl-1.1.0h https A+

首先升级openssl 到 openssl-1.1.0h

wget https://www.openssl.org/source/openssl-1.1.0h.tar.gz

tar -zxvf openssl-1.1.0h.tar.gz
cd openssl-1.1.0h

./config –prefix=/usr

make

make install

openssl version -a

nginx配置参考:

listen 443 ssl http2;
add_header Strict-Transport-Security max-age=15768001;
ssl_certificate /usr/local/nginx/conf/vhost/Nginx/1_www.dnsdizhi.com_bundle.crt;
ssl_certificate_key /usr/local/nginx/conf/vhost/Nginx/2_www.dnsdizhi.com.key;
ssl_session_cache    shared:SSL:10m;
ssl_session_timeout  10m;
ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4:!DH:!DHE;
ssl_prefer_server_ciphers   on;

完毕后可以用:https://www.ssllabs.com/ssltest/  或者 https://myssl.com/ 检查就是能达到A+,当然其实达到A就不错了。如facebook、v.qq.com、www.google.com都是A。区别在哪里?就是没有配置add_header Strict-Transport-Security max-age=15768001;,说真的就是不用配置的,没必要。