hsts http/2 群晖里面的 虚拟服务 配置 意思
什么是HSTS
HTTPS(SSL和TLS)确保用户和网站通讯过程中安全，使攻击者难于拦截、修改和假冒。当用户手动输入域名或http://链接，该网站的第一个请求是未加密的，使用普通的http。最安全的网站立即发送回一个重定向使用户引向到https连接，然而，中间人攻击者可能会攻击拦截初始的http请求，从而控制用户后续的回话。
自然而然HSTS应运而生为了解决这一潜在的安全问题。即时用户输入域名或http连接，浏览器将严格的升级到https连接。
HSTS如何工作的
HSTS策略是从安全的HTTPS站点发送的HTTP响应头部发布的。
| 1 | Strict-Transport-Security: max-age=31536000 |
当浏览器从HTTPS站点看到这个头部，就知道该域名只能通过HTTPS（SSL 或者 TLS）访问了。并将此信息缓存到31536000，也就是1年。
可选的参数includeSubDomains告诉浏览器该策略适用于当前域下的所有子域。
| 1 | Strict-Transport-Security: max-age=31536000; includeSubDomains |
nginx配置HSTS
在nginx配置文件上设置HSTS响应头部。
| 1 | add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; |
always 参数确保所有的响应设置该头部，包括内部产生的错误响应。nginx版本早于1.7.5不支持该always参数和内部产生的错误响应不设置该头部信息。
add_header指令继承规则：
nginx配置块继承add_header指令所在的封装块，因此只需将add_header指令放在顶级的server块。此外还有个重要的例外，如果一个块包含了add_header指令本身，它不会从封装块继承该头部，你需要重新定义所有的add_header指令。
| 123456789101112131415161718 | server { listen 443 ssl; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; # This 'location' block inherits the STS header location / { root /usr/share/nginx/html; } # Because this 'location' block contains another 'add_header' directive, # we must redeclare the STS header location /servlet { add_header X-Served-By "My Servlet Handler"; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; proxy_pass http://localhost:8080; }} |
测试HTTP严格传输安全：
一旦用户提出HSTS策略，它的缓存信息期由max-age指定。在此期间，浏览器将会拒绝通过未加密的HTTP访问web服务，并拒绝给予例外证书错误（如果该网站以前提交了一个有效可信的证书）。如果指定了一个includeSubDomanis参数，这些限制也同样适用于当前域下的所有子域。
当你测试HSTS时，max-age时间设置短点。
是否每个HTTPS响应需要有一个STS头部：
我们的目标是当用户开始HTTPS回话时，尽可能快的呈现HSTS策略。如果他们在回话期间接收到HSTS策略，他们仍然容易受到HTTP劫持攻击的。浏览器只需查看一次STS头部，因此它不是严格必要将它添加到每个位置块和每个响应。然而，只在主页或者登陆页面添加它可能是不够的，如果你只添加到缓存的响应，客户端可能无法看到它。确保尽可能多的合理的覆盖到你的URL，特别注意动态的内容。
HTTP和HTTPS并行
有时网站需要同时运行在HTTP和HTTPS下
| 12345 | server { listen 80; listen 443 ssl; ...} |
有时，需要将http请求重定向到https
| 123456789101112131415161718 | server { listen 80 default_server; listen [::]:80 default_server; server_name _; # Discourage deep links by using a permanent redirect to home page of HTTPS site return 301 https://$host; # Alternatively, redirect all HTTP links to the matching HTTPS page # return 301 https://$host$request_uri;} server { listen 443 ssl; server_name www.ttlsa.com; add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;} |
加强HSTS
保护客户端从HTTP拦截，从它看到STS头部到声明的max-age的期间内。然而，HSTS并不是HTTP回话劫持的完美解决方案。用户仍然容易受到攻击，如果他们通过HTTP访问HSTS保护的网站时：
- 以前从未访问过该网站
- 最近重新安装了其操作系统
- 最近重新安装了其浏览器
- 切换到新的浏览器
- 切换到一个新的设备如移动电话
- 删除浏览器的缓存
- 最近没访问过该站并且max-age过期了
为了解决这个问题，google坚持维护了一个“HSTS preload list”的站点域名和子域名，并通过https://hstspreload.appspot.com/提交其域名。该域名列表被分发和硬编码到主流的web浏览器。客户端访问此列表中的域名将主动的使用HTTPS，并拒绝使用HTTP访问该站点。
一旦设置了STS头部或者提交了你的域名到HSTS预加载列表，这是不可能将其删除的。这是一个单向的决定使你的域名通过HTTPS可用的。
HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。由互联网工程任务组（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论，于2015年2月17日被批准。HTTP/2标准于2015年5月以RFC 7540正式发表。
那 HTTP/2 到底有哪些具体变化呢？
二进制分帧
先来理解几个概念：
帧：HTTP/2 数据通信的最小单位消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。
流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID。
HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。
HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。
多路复用
多路复用，代替原来的序列和阻塞机制。所有就是请求的都是通过一个 TCP连接并发完成。 HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个的TCP链接请求限制，如下图，红色圈出来的请求就因域名链接数已超过限制，而被挂起等待了一段时间：
在 HTTP/2 中，有了二进制分帧之后，HTTP /2 不再依赖 TCP 链接去实现多流并行了，在 HTTP/2中：
- 同域名下所有通信都在单个连接上完成。
- 单个连接可以承载任意数量的双向数据流。
- 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。
这一特性，使性能有了极大提升：
- 同个域名只需要占用一个 TCP 连接，消除了因多个 TCP 连接而带来的延时和内存消耗。
- 单个连接上可以并行交错的请求和响应，之间互不干扰。
- 在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级， 数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。
服务器推送
服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。
服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。
头部压缩
HTTP 1.1请求的大小变得越来越大，有时甚至会大于TCP窗口的初始大小，因为它们需要等待带着ACK的响应回来以后才能继续被发送。HTTP/2对消息头采用HPACK（专为http/2头部设计的压缩格式）进行压缩传输，能够节省消息头占用的网络的流量。而HTTP/1.x每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。
HTTP每一次通信都会携带一组头部，用于描述这次通信的的资源、浏览器属性、cookie等，例如
为了减少这块的资源消耗并提升性能， HTTP/2对这些首部采取了压缩策略：
- HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
- 首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
- 每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。
例如：下图中的两个请求， 请求一发送了所有的头部字段，第二个请求则只需要发送差异数据，这样可以减少冗余数据，降低开销。
我们来看一个实际的例子，下面是用WireShark抓取的访问google首页的包：
上图是是访问https://www.google.com/抓到的第一个请求的头部，可以看到头部的内容，总共占用了437 bytes，我们选中头部的cookie，可以看到cookie总共占用了118 bytes。接下来我们看看第二个请求的头部：
从上图可以看到，得益于头部压缩，第二个请求中cookie只占用了1个字节，我们来看看变化了的Accept字段：
由于Accept字段与请求一中的内容不同，需要发送给服务器，所以占用了29 bytes。
相关推荐
浏览器和网络服务支持情况：http2支持清单
如何快速启用HTTP2: 又拍云文档中心
HTTP/2 和 HTTP/1 速度对比：HTTP/2: the Future of the Internet
关于又拍云
又拍云致力于为客户提供一站式的在线业务加速服务，为用户网页图片、文件下载、音视频点播、动态内容，全站整体提供加速服务，拥有智能控制台面板，具有SSL全链路加密优化，自定义边缘规则等特性，同时支持 WebP 、H.265 、Gzip 压缩、HTTP/2 等新特性，CDN 性能快人一步。另提供安全高可靠的融合云存储，一站式短视频、直播、点播解决方案，实时灵活多终端的云处理，以及流量营销等服务。
结语
HTTP/2的通过支持请求与响应的多路复用来减少延迟，通过压缩HTTP首部字段将协议开销降至最低，同时增加对请求优先级和服务器端推送的支持。
参考资料：