1 媒介

上文讲到 HTTPS 对用户会见速率的影响。

本文便为各人引见 HTTPS 正在会见速率，计较机能，宁静等圆里基于和谈战设置的SEO。

2 HTTPS 会见速率优化

2.1 Tcp fast open

HTTPS 战 HTTP 利用 TCP 和谈停止传输，也便意味着必需经由过程三次握脚成立 TCP 毗连，但一个 RTT 的工夫内只传输一个 syn 包是否是太华侈？能不克不及正在 syn 包收回的同时捎上使用层的数据？实在是能够的，那也是 tcp fast open 的思绪，简称 TFO。详细本理能够参考 rfc7413。

遗憾的是 TFO 需求下版本内核的撑持，linux 从 3.7 当前撑持 TFO，可是今朝的 windows 体系借没有撑持 TFO，以是只能正在公司内部效劳器之间阐扬做用。

2.2 HSTS

前里提到过将用户 HTTP 恳求 302 跳转到 HTTPS，那会有两个影响：

1、没有宁静，302 跳转不只表露了用户的会见站面，也很简单被中心者撑持。

2、低落会见速率，302 跳转不只需求一个 RTT，阅读器施行跳转也需求施行工夫。

因为 302 跳转究竟上是由阅读器触收的，效劳器没法完整掌握，那个需供招致了 HSTS 的降生：

HSTS(HTTP Strict Transport Security)。效劳端返回一个 HSTS 的 http header，阅读器获得到 HSTS 头部以后，正在一段工夫内，没有管用户输进百度借是百度，城市默许将恳求内部跳转成https://百度。

Chrome, firefox, ie 皆撑持了 HSTS（caniuse/#feat=stricttransportsecurity）。

2.3 Session resume

Session resume 望文生义便是复用 session，真现简化握脚。复用 session 的益处有两个：

1、削减了 CPU 耗损，果为没有需求停止非对称稀钥交流的计较。

2、提拔会见速率，没有需求停止完整握脚阶段两，节流了一个 RTT 战计较耗时。

TLS 和谈今朝供给两种机造真现 session resume，别离引见一下。

2.3.1 Session cache

Session cache 的本理是利用 client hello 中的 session id 查询效劳真个 session cache, 假如效劳端有对应的缓存，则间接利用已有的 session 疑息提早完成握脚，称为简化握脚。

Session cache 有两个缺陷：

1、需求耗损效劳端内存去存储 session 内容。

2、今朝的开源硬件包罗 nginx,apache 只撑持单机多历程间同享缓存，没有撑持多机间散布式缓存，关于百度大概其他年夜型互联网公司而行，单机 session cache 险些出有做用。

Session cache 也有一个十分年夜的长处：

session id 是 TLS 和谈的尺度字段，市情上的阅读器局部皆撑持 session cache。

百度经由过程对 TLS 握脚和谈及效劳器端真现的优化，曾经撑持齐局的 session cache，可以较着提拔用户的会见速率，节流效劳器计较资本。

2.3.2 Session ticket

上节提到了 session cache 的两个缺陷，session ticket 可以补偿那些不敷。

Session ticket 的本理参考 RFC4507。简述以下：

server 将 session 疑息减稀成 ticket 收收给阅读器，阅读器后绝握脚恳求时会收收 ticket，server 端假如能胜利解稀战处置 ticket，便能完成简化握脚。

隐然，session ticket 的长处是没有需求效劳端耗损年夜量资本去存储 session 内容。

Session ticket 的缺陷：

1、session ticket 只是 TLS 和谈的一个扩大特性，今朝的撑持率没有是很普遍，只要 60% 阁下。

2、session ticket 需求保护一个齐局的 key 去减解稀，需求思索 KEY 的宁静性战布置服从。

整体去讲，session ticket 的功用特性较着劣于 session cache。期望客户端真现劣先撑持 session ticket。

2.4 Ocsp stapling

Ocsp 齐称正在线证书形态查抄和谈 (rfc6960)，用去背 CA 站面查询证书形态，好比能否打消。凡是状况下，阅读器利用 OCSP 和谈倡议查询恳求，CA 返回证书形态内容，然后阅读器承受证书能否可托的形态。

那个历程十分耗损工夫，果为 CA 站面有能够正在外洋，收集没有不变，RTT 也比力年夜。那有无法子没有间接背 CA 站面恳求 OCSP 内容呢？ocsp stapling 便能真现那个功用。

具体引见参考 RFC6066 第 8 节。简述本理便是阅读器倡议 client hello 时会照顾一个 certificate status request 的扩大，效劳端看到那个扩大后将 OCSP 内容间接返回给阅读器，完成证书形态查抄。

因为阅读器没有需求间接背 CA 站面查询证书形态，那个功用对会见速率的提拔十分较着。

Nginx 今朝曾经撑持那个 ocsp stapling file，只需求设置 ocsp stapling file 的指令便能开启那个功用：

• ssl_stapling on;ssl_stapling_file ocsp.staple;

2.5 False start

凡是状况下，使用层数据必需等完整握脚局部完毕以后才气传输。那个实在比力华侈工夫，那能不克不及相似 TFO 一样，正在完整握脚的第两个阶段将使用数据一同收回去呢？谷歌 提出了 false start 去真现那个功用。具体引见参考https://tools.ietf/html/draft-bmoeller-tls-falsestart-00。

简朴归纳综合 False start 的本理便是正在 client_key_exchange 收回时将使用层数据一同收回去，可以节流一个 RTT。

False start 依靠于 PFS（perfect forward secrecy 完善前背减稀），而 PFS 又依靠于 DHE 稀钥交流系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），以是只管劣先撑持 ECDHE 稀钥交流算法真现 false start。

2.6 利用 SPDY 大概 HTTP2

SPDY 是 谷歌 推出的优化 HTTP 传输服从的和谈（https://chromium/spdy），它根本上相沿了 HTTP 和谈的语义, 可是经由过程利用帧掌握真现了多个特性，隐著提拔了 HTTP 和谈的传输服从。

SPDY 最年夜的特性便是多路复用，能将多个 HTTP 恳求正在统一个毗连上一同收回来，没有像今朝的 HTTP 和谈一样，只能串止天逐一收收恳求。Pipeline 固然撑持多个恳求一同收收，可是领受时仍然得根据次第领受，素质上没法处理并收的成绩。

HTTP2 是 IETF 2015 年 2 月份经由过程的 HTTP 下一代和谈，它以 SPDY 为本型，颠末两年多的会商战完美终极肯定。

本文便不外多引见 SPDY 战 HTTP2 的支益，需求阐明两面：

1、SPDY 战 HTTP2 今朝的真现默许利用 HTTPS 和谈。

2、SPDY 战 HTTP2 皆撑持现有的 HTTP 语义战 API，对 WEB 使用险些是通明的。

Google 颁布发表 chrome 阅读器 2016 年将抛却 SPDY 和谈，片面撑持 HTTP2，可是今朝海内部门阅读器厂商进度十分缓，不只没有撑持 HTTP2，连 SPDY 皆出有撑持过。

百度效劳端战百度脚机阅读器如今皆曾经撑持 SPDY3.1 和谈。

注：相干网站建立本领浏览请移步到建站教程频讲。