做网站 智域大连,哈尔滨市城乡和建设局网站,台州网站设计,做网站后台怎么弄四、安全 1、TLS是什么 #xff08;1#xff09;为什么要有HTTPS 简单的回答是“因为 HTTP 不安全”。由于 HTTP 天生“明文”的特点#xff0c;整个传输过程完全透明#xff0c;任何人都能够在链路中截获、修改或者伪造请求 / 响应报文#xff0c;数据不具有可…四、安全 1、TLS是什么 1为什么要有HTTPS 简单的回答是“因为 HTTP 不安全”。由于 HTTP 天生“明文”的特点整个传输过程完全透明任何人都能够在链路中截获、修改或者伪造请求 / 响应报文数据不具有可信性。 比如前几讲中说过的“代理服务”。它作为 HTTP 通信的中间人在数据上下行的时候可以添加或删除部分头字段也可以使用黑白名单过滤 body 里的关键字甚至直接发送虚假的请求、响应而浏览器和源服务器都没有办法判断报文的真伪。 这对于网络购物、网上银行、证券交易等需要高度信任的应用场景来说是非常致命的。如果没有基本的安全保护使用互联网进行各种电子商务、电子政务就根本无从谈起。 对于安全性要求不那么高的新闻、视频、搜索等网站来说由于互联网上的恶意用户、恶意代理越来越多也很容易遭到“流量劫持”的攻击在页面里强行嵌入广告或者分流用户导致各种利益损失。 对于你我这样的普通网民来说HTTP 不安全的隐患就更大了上网的记录会被轻易截获网站是否真实也无法验证黑客可以伪装成银行网站盗取真实姓名、密码、银行卡等敏感信息威胁人身安全和财产安全。 2什么是安全 通常认为如果通信过程具备了四个特性就可以认为是“安全”的这四个特性是机密性、完整性身份认证和不可否认。
机密性Secrecy/Confidentiality是指对数据的“保密”只能由可信的人访问对其他人是不可见的“秘密”简单来说就是不能让不相关的人看到不该看的东西。完整性Integrity也叫一致性是指数据在传输过程中没有被窜改不多也不少“完完整整”地保持着原状。身份认证Authentication是指确认对方的真实身份也就是“证明你真的是你”保证消息只能发送给可信的人。不可否认Non-repudiation/Undeniable也叫不可抵赖意思是不能否认已经发生过的行为不能“说话不算数”“耍赖皮”。 3什么是HTTPS HTTPS为 HTTP 增加了四大安全特性。HTTPS 其实是一个“非常简单”的协议RFC 文档很小只有短短的 7 页里面规定了新的协议名“https”默认端口号 443至于其他的什么请求 - 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP没有任何新的东西。 HTTPS 把 HTTP 下层的传输协议由 TCP/IP 换成了SSL/TLS由“HTTP over TCP/IP”变成了“HTTP over SSL/TLS”让 HTTP 运行在了安全的 SSL/TLS 协议上收发报文不再使用 Socket API而是调用专门的安全接口。 所以说HTTPS 本身并没有什么特别全是靠下层的SSL/TLS。 4SSL/TLS SSL 即安全套接层Secure Sockets Layer在 OSI 模型中处于第 5 层会话层由网景公司于 1994 年发明有 v2 和 v3 两个版本而 v1 因为有严重的缺陷从未公开过。 SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议于是互联网工程组 IETF在 1999 年把它改名为 TLS传输层安全Transport Layer Security正式标准化版本号从 1.0 重新算起所以 TLS1.0 实际上就是 SSLv3.1。 到今天 TLS 已经发展出了三个版本分别是 2006 年的 1.1、2008 年的 1.2 和去年2018的 1.3每个新版本都紧跟密码学的发展和互联网的现状持续强化安全和性能已经成为了信息安全领域中的权威标准。 目前应用的最广泛的 TLS 是 1.2而之前的协议TLS1.1/1.0、SSLv3/v2都已经被认为是不安全的各大浏览器即将在 2020 年左右停止支持所以接下来的讲解都针对的是TLS1.2。 TLS 由记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。 浏览器和服务器在使用 TLS 建立连接时需要选择一组恰当的加密算法来实现安全通信这些算法的组合被称为“密码套件”cipher suite也叫加密套件。 TLS 的密码套件命名非常规范格式很固定。基本的形式是“密钥交换算法 签名算法 对称加密算法 摘要算法”比如ECDHE-RSA-AES256-GCM-SHA384的意思就是“握手时使用 ECDHE 算法进行密钥交换用 RSA 签名和身份认证握手后的通信使用AES 对称算法密钥长度 256 位分组模式是 GCM摘要算法 SHA384 用于消息认证和产生随机数。” 5OpenSSL OpenSSL它是一个著名的开源密码学程序库和工具包几乎支持所有公开的加密算法和协议已经成为了事实上的标准许多应用软件都会使用它作为底层库来实现 TLS 功能包括常用的 Web 服务器 Apache、Nginx 等。 OpenSSL 是从另一个开源库 SSLeay 发展出来的曾经考虑命名为“OpenTLS”但当时1998 年TLS 还未正式确立而 SSL 早已广为人知所以最终使用了“OpenSSL”的名字。 由于 OpenSSL 是开源的所以它还有一些代码分支比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL这些分支在 OpenSSL 的基础上删除了一些老旧代码也增加了一些新特性虽然背后有“大金主”但离取代 OpenSSL 还差得很远。 2、对称加密与非对称加密 加密实现机密性最常用的手段是加密encrypt就是把消息用某种方式转换成谁也看不懂的乱码只有掌握特殊“钥匙”的人才能再转换出原始文本。 这里的“钥匙”就叫做“密钥”key加密前的消息叫“明文”plain text/clear text加密后的乱码叫“密文”cipher text用密钥还原明文的过程叫“解密”decrypt是加密的反操作加密解密的操作过程就是“加密算法”。 所有的加密算法都是公开的任何人都可以去分析研究而算法使用的“密钥”则必须保密。 由于 HTTPS、TLS 都运行在计算机上所以“密钥”就是一长串的数字但约定俗成的度量单位是“位”bit而不是“字节”byte。比如说密钥长度是 128就是 16字节的二进制串密钥长度 1024就是 128 字节的二进制串。 按照密钥的使用方式加密可以分为两大类对称加密和非对称加密。 1对称加密 对称加密就是指加密和解密时使用的密钥都是同一个是“对称”的。只要保证了密钥的安全那整个通信过程就可以说具有了机密性。 举个例子你想要登录某网站只要事先和它约定好使用一个对称密码通信过程中传输的全是用密钥加密后的密文只有你和网站才能解密。黑客即使能够窃听看到的也只是乱码因为没有密钥无法解出明文所以就实现了机密性。 TLS 里有非常多的对称加密算法可供选择比如 RC4、DES、3DES、AES、ChaCha20等但前三种算法都被认为是不安全的通常都禁止使用目前常用的只有 AES 和ChaCha20。 AES 意思是“高级加密标准”Advanced Encryption Standard密钥长度可以是128、192 或 256。它是 DES 算法的替代者安全强度很高性能也很好而且有的硬件还会做特殊优化所以非常流行是应用最广泛的对称加密算法。 ChaCha20是 Google 设计的另一种加密算法密钥长度固定为 256 位纯软件运行性能要超过 AES曾经在移动客户端上比较流行但 ARMv8 之后也加入了 AES 硬件优化所以现在不再具有明显的优势但仍然算得上是一个不错算法。 2加密分组模式 分组模式对称算法还有一个分组模式概念它可以让算法用固定长度的密钥加密任意长度的明文把小秘密即密钥转化为大秘密即密文。 最早有 ECB、CBC、CFB、OFB 等几种分组模式但都陆续被发现有安全漏洞所以现在基本都不怎么用了。最新的分组模式被称为 AEADAuthenticated Encryption with Associated Data在加密的同时增加了认证的功能常用的是 GCM、CCM 和Poly1305。 把上面这些组合起来就可以得到 TLS 密码套件中定义的对称加密算法。比如AES128-GCM意思是密钥长度为 128 位的 AES 算法使用的分组模式是 GCMChaCha20-Poly1305 的意思是 ChaCha20 算法使用的分组模式是 Poly1305。 3非对称加密 密钥交换对称加密看上去好像完美地实现了机密性但其中有一个很大的问题如何把密钥安全地传递给对方术语叫密钥交换。因为在对称加密算法中只要持有密钥就可以解密。如果密钥在传递途中被黑客窃取那他就可以随意解密收发的数据通信过程也就没有机密性可言了。所以就出现了非对称加密。 非对称加密也叫公钥加密算法。它有两个密钥一个叫“公钥”public key一个叫“私钥”private key。两个密钥是不同的“不对称”公钥可以公开给任何人使用而私钥必须严格保密。非对称加密可以解决“密钥交换”的问题。网站秘密保管私钥在网上任意分发公钥你想要登录网站只要用公钥加密就行了密文只能由私钥持有者才能解密。而黑客因为没有私钥所以就无法破解密文。
单向性公钥加密后只能用私钥解密反过来私钥加密后也只能用公钥解密。 非对称加密算法的设计要比对称算法难得多在 TLS 里只有很少的几种比如 DH、DSA、RSA、ECC 等。 RSA可能是其中最著名的一个几乎可以说是非对称加密的代名词它的安全性基于“整数分解”的数学难题使用两个超大素数的乘积作为生成密钥的材料想要从公钥推算出私钥是非常困难的。10 年前 RSA 密钥的推荐长度是 1024但随着计算机运算能力的提高现在 1024 已经不安全普遍认为至少要 2048 位。 ECCElliptic Curve Cryptography是非对称加密里的“后起之秀”它基于“椭圆曲线离散对数”的数学难题使用特定的曲线方程和基点生成公钥和私钥子算法 ECDHE 用于密钥交换ECDSA 用于数字签名。目前比较常用的两个曲线是 P-256secp256r1在 OpenSSL 称为 prime256v1和x25519。P-256 是 NIST美国国家标准技术研究所和 NSA美国国家安全局推荐使用的曲线而 x25519 被认为是最安全、最快速的曲线。ECC 名字里的“椭圆”经常会引起误解其实它的曲线并不是椭圆形只是因为方程很类似计算椭圆周长的公式实际的形状更像抛物线比如下面的图就展示了两个简单的椭圆曲线。 RSA vs ECC比起 RSAECC 在安全强度和性能上都有明显的优势。160 位的 ECC 相当于 1024 位的RSA而 224 位的 ECC 则相当于 2048 位的 RSA。因为密钥短所以相应的计算量、消耗的内存和带宽也就少加密解密的性能就上去了对于现在的移动互联网非常有吸引力。 4混合加密 性能问题虽然非对称加密没有“密钥交换”的问题但因为它们都是基于复杂的数学难题运算速度很慢即使是 ECC 也要比 AES 差上好几个数量级。如果仅用非对称加密虽然保证了安全但通信速度有如乌龟、蜗牛实用性就变成了零。 对比了 AES 和 RSA 这两种算法的性能下面列出了一次测试的结果 aes_128_cbc enc/dec 1000 times : 0.97ms, 13.11MB/s rsa_1024 enc/dec 1000 times : 138.59ms, 93.80KB/s rsa_1024/aes ratio 143.17 rsa_2048 enc/dec 1000 times : 840.35ms, 15.47KB/s rsa_2048/aes ratio 868.13 可以看到RSA 的运算速度是非常慢的2048 位的加解密大约是 15KB/S微秒或毫秒级而 AES128 则是 13MB/S纳秒级差了几百倍。 混合加密是不是能够把对称加密和非对称加密结合起来呢两者互相取长补短即能高效地加密解密又能安全地密钥交换。这就是现在 TLS 里使用的混合加密方式其实说穿了也很简单在通信刚开始的时候使用非对称算法比如 RSA、ECDHE首先解决密钥交换的问题。然后用随机数产生对称算法使用的“会话密钥”session key再用公钥加密。因为会话密钥很短通常只有 16 字节或 32 字节所以慢一点也无所谓。对方拿到密文后用私钥解密取出会话密钥。这样双方就实现了对称密钥的安全交换后续就不再使用非对称加密全都使用对称加密。 3、数字签名和证书 没有完整性黑客虽然拿不到会话密钥无法破解密文但可以通过窃听收集到足够多的密文再尝试着修改、重组后发给网站。因为没有完整性保证服务器只能“照单全收”然后他就可以通过服务器的响应获取进一步的线索最终就会破解出明文。 伪造公钥黑客也可以伪造身份发布公钥。如果你拿到了假的公钥混合加密就完全失效了。你以为自己是在和“某宝”通信实际上网线的另一端却是黑客银行卡号、密码等敏感信息就在“安全”的通信过程中被窃取了。 所以在机密性的基础上还必须加上完整性、身份认证等特性才能实现真正的安全。 1摘要算法 摘要算法实现完整性的手段主要是摘要算法Digest Algorithm也就是常说的散列函数、哈希函数Hash Function。它能够把任意长度的数据转换成固定长度、而且独一无二的“摘要”字符串不能从摘要逆推出原文。 摘要算法实际上是把数据从一个“大空间”映射到了“小空间”所以就存在“冲突”collision也叫碰撞的可能性可能会有两份不同的原文对应相同的摘要。好的摘要算法必须能够“抵抗冲突”让这种可能性尽量地小。 因为摘要算法对输入具有“单向性”和“雪崩效应”输入的微小不同会导致输出的剧烈变化所以也被 TLS 用来生成伪随机数PRFpseudo random function。 你一定在日常工作中听过、或者用过 MD5Message-Digest 5、SHA-1Secure Hash Algorithm 1它们就是最常用的两个摘要算法能够生成 16 字节和 20 字节长度的数字摘要。但这两个算法的安全强度比较低不够安全在 TLS 里已经被禁止使用了。 目前 TLS 推荐使用的是 SHA-1 的后继者SHA-2。SHA-2 实际上是一系列摘要算法的统称总共有 6 种常用的有 SHA224、SHA256、SHA384分别能够生成 28 字节、32 字节、48 字节的摘要。 2完整性 完整性摘要算法保证了“数字摘要”和原文是完全等价的。所以我们只要在原文后附上它的摘要就能够保证数据的完整性。如果黑客在中间哪怕改动了一个标点符号摘要也会完全不同网站计算比对就会发现消息被窜改是不可信的。 哈希消息认证码不过摘要算法不具有机密性如果明文传输那么黑客可以修改消息后把摘要也一起改了网站还是鉴别不出完整性。所以真正的完整性必须要建立在机密性之上在混合加密系统里用会话密钥加密消息和摘要这样黑客无法得知明文也就没有办法动手脚了。这有个术语叫哈希消息认证码HMAC。 3数字签名 端点安全加密算法结合摘要算法我们的通信过程可以说是比较安全了。但这里还有漏洞就是通信的两个端点endpoint。黑客可以伪装成网站来窃取信息。而反过来他也可以伪装成你向网站发送支付、转账等消息网站没有办法确认你的身份钱可能就这么被偷走了。 数字签名私钥摘要算法数字签名同时实现“身份认证”和“不可否认”。数字签名的原理就是把公钥私钥用法反过来私钥加密、公钥解密。但又因为非对称加密效率太低所以私钥只加密原文的摘要这样运算量就小的多而且得到的数字签名也很小方便保管和传输。签名和公钥一样完全公开任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开拿到摘要后再比对原文验证完整性就可以像签署文件一样证明消息确实是你发的。 签名和验签刚才的这两个行为也有专用术语叫做“签名”和“验签”。只要你和网站互相交换公钥就可以用“签名”和“验签”来确认消息的真实性因为私钥保密黑客不能伪造签名就能够保证通信双方的身份。 4数字证书和CA 公钥信任问题因为谁都可以发布公钥我们还缺少防止黑客伪造公钥的手段。我们可以用别的私钥来给公钥签名显然这又会陷入“无穷递归”。要终结这个“死循环”就必须引入“外力”找一个公认的可信第三方。 CACertificate Authority证书认证机构这个第三方就是我们常说的CA。它就像网络世界里的公安局、教育部、公证中心具有极高的可信度由它来给各个公钥签名用自身的信誉来保证公钥无法伪造是可信的。知名的 CA 全世界就那么几家比如 DigiCert、VeriSign、Entrust、Let’s Encrypt 等它们签发的证书分 DV、OV、EV 三种区别在于可信程度。DV只是域名级别的可信背后是谁不知道。EV 是最高的经过了法律和审计的严格核查可以证明网站拥有者的身份在浏览器地址栏会显示出公司的名字例如Apple、GitHub 的网站。 CA 对公钥的签名认证格式不是简单地把公钥绑定在持有者身份上就完事了还要包含序列号、用途、颁发者、有效时间等等把这些打成一个包再签名完整地证明公钥关联的各种信息形成数字证书。 自签名证书小一点的 CA 可以让大 CA 签名认证但链条的最后也就是Root CA就只能自己证明自己了这个就叫“自签名证书”Self-Signed Certificate或者“根证书”Root Certificate。你必须相信否则整个证书信任链就走不下去了。 有了这个证书体系操作系统和浏览器都内置了各大 CA 的根证书上网的时候只要服务器发过来它的证书就可以验证证书里的签名顺着证书链Certificate Chain一层层地验证直到找到根证书就能够确定证书是可信的从而里面的公钥也是可信的。
我们的实验环境里使用的证书是“野路子”的自签名证书在 Linux 上用 OpenSSL 命令行签发肯定是不会被浏览器所信任的所以用 Chrome 访问时就会显示成红色标记为不安全。但你只要把它安装进系统的根证书存储区里让它作为信任链的根就不会再有危险警告。 5证书体系的弱点 证书体系PKIPublic Key Infrastructure虽然是目前整个网络世界的安全基础设施但绝对的安全是不存在的它也有弱点还是关键的“信任”二字。
签发了错误的证书如果 CA 失误或者被欺骗签发了错误的证书虽然证书是真的可它代表的网站却是假的。针对这种情况开发出了 CRL证书吊销列表Certificate revocation list和 OCSP在线证书状态协议Online Certificate Status Protocol及时废止有问题的证书。
CA 被黑客攻陷或者 CA 有恶意因为它即根证书是信任的源头整个信任链里的所有证书也就都不可信了。针对这种情况就只能操作系统或者浏览器从根上“下狠手”了撤销对 CA 的信任列入“黑名单”这样它颁发的所有证书就都会被认为是不安全的。 4、TLS1.2连接过程解析 1HTTPS建立连接 当你在浏览器地址栏里键入“https”开头的 URI再按下回车浏览器首先要从 URI 里提取出协议名和域名。因为协议名是“https”所以浏览器就知道了端口号是默认的 443它再用 DNS 解析域名得到目标的 IP 地址然后就可以使用三次握手与网站建立 TCP 连接了。 在 HTTP 协议里建立连接后浏览器会立即发送请求报文。但现在是 HTTPS 协议它需要再用另外一个“握手”过程在 TCP 上建立安全连接之后才是收发 HTTP 报文。这个“握手”过程与 TCP 有些类似是 HTTPS 和 TLS 协议里最重要、最核心的部分。 2TLS协议的组成 TLS 包含几个子协议你也可以理解为它是由几个不同职责的模块组成比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。
记录协议Record Protocol规定了 TLS 收发数据的基本单位记录record。它有点像是 TCP 里的 segment所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个 TCP 包里一次性发出也并不需要像 TCP 那样返回 ACK。警报协议Alert Protocol的职责是向对方发出警报信息有点像是 HTTP 协议里的状态码。比如protocol_version 就是不支持旧版本bad_certificate 就是证书有问题收到警报后另一方可以选择继续也可以立即终止连接。握手协议Handshake Protocol是 TLS 里最复杂的子协议要比 TCP 的 SYN/ACK 复杂的多浏览器和服务器会在握手过程中协商 TLS 版本号、随机数、密码套件等信息然后交换证书和密钥参数最终双方协商得到会话密钥用于后续的混合加密系统。变更密码规范协议Change Cipher Spec Protocol它非常简单就是一个“通知”告诉对方后续的数据都将使用加密保护。那么反过来在它之前数据都是明文的。
下面的这张图简要地描述了 TLS 的握手过程其中每一个“框”都是一个记录多个记录组合成一个 TCP 包发送。所以最多经过两次消息往返4 个消息就可以完成握手然后就可以在安全的通信环境里发送 HTTP 报文实现 HTTPS 协议。 3ECDHE握手过程
刚才你看到的是握手过程的简要图我又画了一个详细图下面我就用这个图来仔细剖析 TLS 的握手过程。 在 TCP 建立连接之后浏览器会首先发一个“Client Hello”消息也就是跟服务器“打招呼”。里面有客户端的版本号、支持的密码套件还有一个随机数Client Random用于后续生成会话密钥。 Handshake Protocol: Client Hello Version: TLS 1.2 (0x0303) Random: 1cbf803321fd2623408dfe… Cipher Suites (17 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) 服务器收到“Client Hello”后会返回一个“Server Hello”消息。把版本号对一下也给出一个随机数Server Random然后从客户端的列表里选一个作为本次通信使用的密码套件在这里它选择了“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”。 Handshake Protocol: Server Hello Version: TLS 1.2 (0x0303) Random: 0e6320f21bae50842e96… Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) 这个的意思就是“版本号对上了可以加密你的密码套件挺多我选一个最合适的吧用椭圆曲线加 RSA、AES、SHA384。我也给你一个随机数你也得留着。” 然后服务器为了证明自己的身份就把证书也发给了客户端Server Certificate。 接下来是一个关键的操作因为服务器选择了 ECDHE 算法所以它会在证书后发送“Server Key Exchange”消息里面是椭圆曲线的公钥Server Params用来实现密钥交换算法再加上自己的私钥签名认证。 Handshake Protocol: Server Key Exchange EC Diffie-Hellman Server Params Curve Type: named_curve (0x03) Named Curve: x25519 (0x001d) Pubkey: 3b39deaf00217894e... Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature: 37141adac38ea4... 这相当于说“刚才我选的密码套件有点复杂所以再给你个算法的参数和刚才的随机数一样有用别丢了。为了防止别人冒充我又盖了个章。” 这样第一个消息往返就结束了两个 TCP 包结果是客户端和服务器通过明文共享了三个信息Client Random、Server Random 和 Server Params。 客户端这时也拿到了服务器的证书开始走证书链逐级验证确认证书的真实性再用证书公钥验证签名就确认了服务器的身份。 然后客户端按照密码套件的要求也生成一个椭圆曲线的公钥Client Params用“Client Key Exchange”消息发给服务器。 Handshake Protocol: Client Key Exchange EC Diffie-Hellman Client Params Pubkey: 8c674d0e08dc27b5eaa… 现在客户端和服务器手里都拿到了密钥交换算法的两个参数Client Params、Server Params就用 ECDHE 算法算出了一个新的东西叫“Pre-Master”其实也是一个随机数。算法可以保证即使黑客截获了之前的参数也是绝对算不出这个随机数的。 现在客户端和服务器手里有了三个随机数Client Random、Server Random 和 Pre-Master。用这三个作为原始材料就可以生成用于加密会话的主密钥叫“Master Secret”。而黑客因为拿不到“Pre-Master”所以也就得不到主密钥。 这就必须说 TLS 的设计者考虑得非常周到了他们不信任客户端或服务器伪随机数的可靠性为了保证真正的“完全随机”“不可预测”把三个不可靠的随机数混合起来那么“随机”的程度就非常高了足够让黑客难以猜测。 “Master Secret”究竟是怎么算出来的吧贴一下 RFC 里的公式 master_secret PRF(pre_master_secret, master secret, ClientHello.random ServerHello.random) 这里的“PRF”就是伪随机数函数它基于密码套件里的最后一个参数比如这次的SHA384通过摘要算法来再一次强化“Master Secret”的随机性。 主密钥有 48 字节但它也不是最终用于通信的会话密钥还会再用 PRF 扩展出更多的密钥比如客户端发送用的会话密钥client_write_key、服务器发送用的会话密钥server_write_key等等避免只用一个密钥带来的安全隐患。 有了主密钥和派生的会话密钥握手就快结束了。客户端发一个“Change Cipher Spec”然后再发一个“Finished”消息把之前所有发送的数据做个摘要再加密一下让服务器做个验证。 意思就是告诉服务器“后面都改用对称算法加密通信了啊用的就是打招呼时说的AES加密对不对还得你测一下。” 服务器也是同样的操作发“Change Cipher Spec”和“Finished”消息双方都验证加密解密 OK握手正式结束后面就收发被加密的 HTTP 请求和响应了。 4RSA握手过程 主流的 TLS 握手过程与传统的握手有两点不同。 第一个使用 ECDHE 实现密钥交换而不是 RSA所以会在服务器端发出“Server Key Exchange”消息。 第二个因为使用了 ECDHE客户端可以不用等到服务器发回“Finished”确认握手完毕立即就发出 HTTP 报文省去了一个消息往返的时间浪费。这个叫“TLS False Start”意思就是“抢跑”和“TCP Fast Open”有点像都是不等连接完全建立就提前发应用数据提高传输的效率。 大体的流程没有变只是“Pre-Master”不再需要用算法生成而是客户端直接生成随机数然后用服务器的公钥加密通过“Client Key Exchange”消息发给服务器。服务器再用私钥解密这样双方也实现了共享三个随机数就可以生成主密钥。 5双向认证 不过上面说的是“单向认证”握手过程只认证了服务器的身份而没有认证客户端的身份。这是因为通常单向认证通过后已经建立了安全通信用账号、密码等简单的手段就能够确认用户的真实身份。 但为了防止账号、密码被盗有的时候比如网上银行还会使用 U 盾给用户颁发客户端证书实现“双向认证”这样会更加安全。
双向认证的流程也没有太多变化只是在“Server Hello Done”之后“Client Key Exchange”之前客户端要发送“Client Certificate”消息服务器收到后也把证书链走一遍验证客户端的身份。 5、TLS1.3特性解析 TLS1.2 已经是 10多年前2008 年的“老”协议了虽然历经考验但毕竟“岁月不饶人”在安全、性能等方面已经跟不上如今的互联网了。 于是经过四年、近 30 个草案的反复打磨TLS1.3 终于在2018 年“粉墨登场”再次确立了信息安全领域的新标准。 TLS1.3 的三个主要改进目标兼容、安全与性能。 1最大化兼容性 由于 1.1、1.2 等协议已经出现了很多年很多应用软件、中间代理官方称为“MiddleBox”只认老的记录协议格式更新改造很困难甚至是不可行设备僵化。 为了保证这些被广泛部署的“老设备”能够继续使用避免新协议带来的“冲击”TLS1.3 不得不做出妥协保持现有的记录格式不变通过“伪装”来实现兼容使得TLS1.3 看上去“像是”TLS1.2。 这要用到一个新的扩展协议Extension Protocol它有点“补充条款”的意思通过在记录末尾添加一系列的“扩展字段”来增加新的功能老版本的 TLS 不认识它可以直接忽略这就实现了“后向兼容”。 在记录头的 Version 字段被兼容性“固定”的情况下只要是 TLS1.3 协议握手的“Hello”消息后面就必须有“supported_versions”扩展它标记了 TLS 的版本号使用它就能区分新旧协议。 Handshake Protocol: Client Hello Version: TLS 1.2 (0x0303) Extension: supported_versions (len11) Supported Version: TLS 1.3 (0x0304) Supported Version: TLS 1.2 (0x0303) TLS1.3 利用扩展实现了许多重要的功能比如“supported_groups”“key_share”“signature_algorithms”“server_name”等 2强化安全 TLS1.2 在十来年的应用中获得了许多宝贵的经验陆续发现了很多的漏洞和加密算法的弱点所以 TLS1.3 就在协议里修补了这些不安全因素。
伪随机数函数由 PRF 升级为 HKDFHMAC-based Extract-and-Expand Key Derivation Function明确禁止在记录协议里使用压缩废除了 RC4、DES 对称加密算法废除了 ECB、CBC 等传统分组模式废除了 MD5、SHA1、SHA-224 摘要算法废除了 RSA、DH 密钥交换算法和许多命名曲线。 经过这一番“减肥瘦身”之后TLS1.3 里只保留了 AES、ChaCha20 对称加密算法分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305摘要算法只能用 SHA256、SHA384密钥交换算法只有 ECDHE 和 DHE椭圆曲线也被“砍”到只剩 P-256 和 x25519 等 5种。 算法精简后带来了一个意料之中的好处原来众多的算法、参数组合导致密码套件非常复杂难以选择而现在的 TLS1.3 里只有 5 个套件无论是客户端还是服务器都不会再犯“选择困难症”了。 这里还要特别说一下废除 RSA 和 DH 密钥交换算法的原因。浏览器默认会使用 ECDHE 而不是 RSA 做密钥交换这是因为它不具有“前向安全”Forward Secrecy。 假设有这么一个很有耐心的黑客一直在长期收集混合加密系统收发的所有报文。如果加密系统使用服务器证书里的 RSA 做密钥交换一旦私钥泄露或被破解使用社会工程学或者巨型计算机那么黑客就能够使用私钥解密出之前所有报文的“Pre-Master”再算出会话密钥破解所有密文。 而 ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥每次通信的密钥对都是不同的也就是“一次一密”即使黑客花大力气破解了这一次的会话密钥也只是这次通信被攻击之前的历史消息不会受到影响仍然是安全的。 3提升性能 HTTPS 建立连接时除了要做 TCP 握手还要做 TLS 握手在 1.2 中会多花两个消息往返2-RTT可能导致几十毫秒甚至上百毫秒的延迟在移动网络中延迟还会更严重。 现在因为密码套件大幅度简化也就没有必要再像以前那样走复杂的协商流程了。TLS1.3压缩了以前的“Hello”协商过程删除了“Key Exchange”消息把握手时间减少到了“1-RTT”效率提高了一倍。 其实具体的做法还是利用了扩展。客户端在“Client Hello”消息里直接用“supported_groups”带上支持的曲线比如 P-256、x25519用“key_share”带上曲线对应的客户端公钥参数用“signature_algorithms”带上签名算法。 服务器收到后在这些扩展里选定一个曲线和参数再用“key_share”扩展返回服务器这边的公钥参数就实现了双方的密钥交换后面的流程就和 1.2 基本一样了。 除了标准的“1-RTT”握手TLS1.3 还引入了“0-RTT”握手用“pre_shared_key”和“early_data”扩展在 TCP 连接后立即就建立安全连接发送加密消息。 4握手分析 在 TCP 建立连接之后浏览器首先还是发一个“Client Hello”。因为 1.3 的消息兼容 1.2所以开头的版本号、支持的密码套件和随机数Client Random结构都是一样的不过这时的随机数是 32 个字节。 注意“Client Hello”里的扩展“supported_versions”表示这是TLS1.3“supported_groups”是支持的曲线“key_share”是曲线对应的参数。 服务器收到“Client Hello”同样返回“Server Hello”消息还是要给出一个**随机数Server Random**和选定密码套件。 表面上看和 TLS1.2 是一样的重点是后面的扩展。“supported_versions”里确认使用的是 TLS1.3然后在“key_share”扩展带上曲线和对应的公钥参数。 这时只交换了两条消息客户端和服务器就拿到了四个共享信息Client Random和Server Random、Client Params和Server Params两边就可以各自用 ECDHE 算出“Pre-Master”再用 HKDF 生成主密钥“Master Secret”效率比 TLS1.2 提高了一大截。 在算出主密钥后服务器立刻发出“Change Cipher Spec”消息比 TLS1.2 提早进入加密通信后面的证书等就都是加密的了减少了握手时的明文信息泄露。 这里 TLS1.3 还有一个安全强化措施多了个“Certificate Verify”消息用服务器的私钥把前面的曲线、套件、参数等握手数据加了签名作用和“Finished”消息差不多。但由于是私钥签名所以强化了身份认证和和防窜改。 这两个“Hello”消息之后客户端验证服务器证书再发“Finished”消息就正式完成了握手开始收发 HTTP 报文。 6、HTTPS对连接慢的优化 HTTPS 连接大致上可以划分为两个部分第一个是建立连接时的非对称加密握手第二个是握手后的对称加密报文传输。 由于目前流行的 AES、ChaCha20 性能都很好还有硬件优化报文传输的性能损耗可以说是非常地小小到几乎可以忽略不计了。所以通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间。 在 TCP 建连之后正式数据传输之前HTTPS 比 HTTP 增加了一个 TLS 握手的步骤这个步骤最长可以花费两个消息往返也就是 2-RTT。而且在握手消息的网络耗时之外还会有其他的一些“隐形”消耗比如
产生用于密钥交换的临时公私钥对ECDHE验证证书时访问 CA 获取 CRL 或者 OCSP非对称加密解密处理“Pre-Master”。
在最差的情况下也就是不做任何的优化措施HTTPS 建立连接可能会比 HTTP 慢上几百毫秒甚至几秒这其中既有网络耗时也有计算耗时就会让人产生“打开一个 HTTPS 网站好慢啊”的感觉。 我画了一张图把 TLS 握手过程中影响性能的部分都标记了出来对照着它就可以“有的放矢”地来优化 HTTPS。 1硬件优化 HTTPS 连接是计算密集型而不是 I/O 密集型。所以如果你花大价钱去买网卡、带宽、SSD 存储就是“南辕北辙”了起不到优化的效果。 首先你可以选择更快的 CPU最好还内建 AES 优化这样即可以加速握手也可以加速传输。 其次你可以选择“SSL 加速卡”加解密时调用它的 API让专门的硬件来做非对称加解密分担 CPU 的计算压力。不过“SSL 加速卡”也有一些缺点比如升级慢、支持算法有限不能灵活定制解决方案等。 所以就出现了第三种硬件加速方式“SSL 加速服务器”用专门的服务器集群来彻底“卸载”TLS 握手时的加密解密计算性能自然要比单纯的“加速卡”要强大的多。 2软件优化 不过硬件优化方式中除了 CPU其他的通常可不是靠简单花钱就能买到的还要有一些开发适配工作有一定的实施难度。比如“加速服务器”中关键的一点是通信必须是“异步”的不能阻塞应用服务器否则加速就没有意义了。 所以软件优化的方式相对来说更可行一些性价比高能够“少花钱多办事”。软件方面的优化还可以再分成两部分一个是软件升级一个是协议优化。 软件升级实施起来比较简单就是把现在正在使用的软件尽量升级到最新版本比如把Linux 内核由 2.x 升级到 4.x把 Nginx 由 1.6 升级到 1.16把 OpenSSL 由 1.0.1 升级到1.1.0/1.1.1。由于这些软件在更新版本的时候都会做性能优化、修复错误只要运维能够主动配合这种软件优化是最容易做的也是最容易达成优化效果的。 但对于很多大中型公司来说硬件升级或软件升级都是个棘手的问题有成千上万台各种型号的机器遍布各个机房逐一升级不仅需要大量人手而且有较高的风险可能会影响正常的线上服务。 所以在软硬件升级都不可行的情况下我们最常用的优化方式就是在现有的环境下挖掘协议自身的潜力。 3协议优化 从刚才的 TLS 握手图中你可以看到影响性能的一些环节协议优化就要从这些方面着手先来看看核心的密钥交换过程。 如果有可能应当尽量采用 TLS1.3它大幅度简化了握手的过程完全握手只要 1-RTT而且更加安全。 如果暂时不能升级到 1.3只能用 1.2那么握手时使用的密钥交换协议应当尽量选用椭圆曲线的 ECDHE 算法。它不仅运算速度快安全性高还支持“False Start”能够把握手的消息往返由 2-RTT 减少到 1-RTT达到与 TLS1.3 类似的效果。 另外椭圆曲线也要选择高性能的曲线最好是 x25519次优选择是 P-256。对称加密算法方面也可以选用“AES_128_GCM”它能比“AES_256_GCM”略快一点点。 在 Nginx 里可以用“ssl_ciphers”“ssl_ecdh_curve”等指令配置服务器使用的密码套件和椭圆曲线把优先使用的放在前面例如 ssl_ciphers TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:EECDHCHACHA20 ssl_ecdh_curve X25519:P-256; 4证书优化 除了密钥交换握手过程中的证书验证也是一个比较耗时的操作服务器需要把自己的证书链全发给客户端然后客户端接收后再逐一验证。 这里就有两个优化点一个是证书传输一个是证书验证。 服务器的证书可以选择椭圆曲线ECDSA证书而不是 RSA 证书因为 224 位的 ECC 相当于 2048 位的 RSA所以椭圆曲线证书的“个头”要比 RSA 小很多即能够节约带宽也能减少客户端的运算量可谓“一举两得”。 客户端的证书验证其实是个很复杂的操作除了要公钥解密验证多个证书签名外因为证书还有可能会被撤销失效客户端有时还会再去访问 CA下载 CRL 或者 OCSP 数据这又会产生 DNS 查询、建立连接、收发数据等一系列网络通信增加好几个 RTT。 CRLCertificate revocation list证书吊销列表由 CA 定期发布里面是所有被撤销信任的证书序号查询这个列表就可以知道证书是否有效。 但 CRL 因为是“定期”发布就有“时间窗口”的安全隐患而且随着吊销证书的增多列表会越来越大一个 CRL 经常会上 MB。想象一下每次需要预先下载几 M 的“无用数据”才能连接网站实用性实在是太低了。 所以现在 CRL 基本上不用了取而代之的是 OCSP在线证书状态协议Online Certificate Status Protocol向 CA 发送查询请求让 CA 返回证书的有效状态。 但 OCSP 也要多出一次网络请求的消耗而且还依赖于 CA 服务器如果 CA 服务器很忙那响应延迟也是等不起的。 于是又出来了一个“补丁”叫“OCSP Stapling”OCSP 装订它可以让服务器预先访问 CA 获取 OCSP 响应然后在握手时随着证书一起发给客户端免去了客户端连接 CA服务器查询的时间。 5会话复用 回想一下 HTTPS 建立连接的过程先是 TCP 三次握手然后是 TLS 一次握手。这后一次握手的重点是算出主密钥“Master Secret”而主密钥每次连接都要重新计算太浪费了如果能够把算出来的主密钥缓存一下“重用”就可以免去了握手和计算的成本这种做法就叫“会话复用”TLS session resumption和 HTTP Cache 一样也是提高 HTTPS 性能的“大杀器”被浏览器和服务器广泛应用。 会话复用分两种第一种叫“Session ID”就是客户端和服务器首次连接后各自保存一个会话的 ID 号内存里存储主密钥和其他相关的信息。当客户端再次连接时发一个 ID 过来服务器就在内存里找找到就直接用主密钥恢复会话状态跳过证书验证和密钥交换只用一个消息往返就可以建立安全通信。 服务器在“ServerHello”消息后直接发送了“Change Cipher Spec”和“Finished”消息复用会话完成了握手。 6会话票证 “Session ID”是最早出现的会话复用技术也是应用最广的但它也有缺点服务器必须保存每一个客户端的会话数据对于拥有百万、千万级别用户的网站来说存储量就成了大问题加重了服务器的负担。 于是又出现了第二种“Session Ticket”方案。它有点类似 HTTP 的 Cookie存储的责任由服务器转移到了客户端服务器加密会话信息用“New Session Ticket”消息发给客户端让客户端保存。 重连的时候客户端使用扩展“session_ticket”发送“Ticket”而不是“Session ID”服务器解密后验证有效期就可以恢复会话开始加密通信。 不过“Session Ticket”方案需要使用一个固定的密钥文件ticket_key来加密 Ticket为了防止密钥被破解保证“前向安全”密钥文件需要定期轮换比如设置为一小时或者一天。 7预共享密钥 “False Start”“Session ID”“Session Ticket”等方式只能实现 1-RTT而 TLS1.3 更进一步实现了“0-RTT”原理和“Session Ticket”差不多但在发送 Ticket 的同时会带上应用数据Early Data免去了 1.2 里的服务器确认步骤这种方式叫“Pre shared Key”简称为“PSK”。 但“PSK”也不是完美的它为了追求效率而牺牲了一点安全性容易受到“重放攻击”Replay attack的威胁。黑客可以截获“PSK”的数据像复读机那样反复向服务器发送。 解决的办法是只允许安全的 GET/HEAD 方法在消息里加入时间戳、“nonce”验证或者“一次性票证”限制重放。 7、迁移到HTTPS的必要性 1迁移的必要性 如果你做移动应用开发的话那么就一定知道Apple、Android、某信等开发平台在2017 年就相继发出通知要求所有的应用必须使用 HTTPS 连接禁止不安全的 HTTP。 在台式机上主流的浏览器 Chrome、Firefox 等也早就开始“强推”HTTPS把 HTTP 站点打上“不安全”的标签给用户以“心理压力”。 Google 等搜索巨头还利用自身的“话语权”优势降低 HTTP 站点的排名而给 HTTPS更大的权重力图让网民只访问到 HTTPS 网站。 这些手段都逐渐“挤压”了纯明文 HTTP 的生存空间“迁移到 HTTPS”已经不是“要不要做”的问题而是“要怎么做”的问题了。HTTPS 的大潮无法阻挡如果还是死守着HTTP那么无疑会被冲刷到互联网的角落里。
目前国内外的许多知名大站都已经实现了“全站 HTTPS”。 2迁移的顾虑 慢认为 HTTPS 会增加服务器的成本增加客户端的时延影响用户体验。其实现在服务器和客户端的运算能力都已经有了很大的提升性能方面完全没有担心的必要而且还可以应用很多的优化解决方案。根据 Google 等公司的评估在经过适当优化之后HTTPS 的额外 CPU 成本小于 1%额外的网络成本小于 2%可以说是与无加密的 HTTP 相差无几。 贵主要是指证书申请和维护的成本太高网站难以承担。为了推广 HTTPS很多云服务厂商都提供了一键申请、价格低廉的证书而且还出现了专门颁发免费证书的 CA其中最著名的就是“Let’s Encrypt”。 难是指 HTTPS 涉及的知识点太多、太复杂有一定的技术门槛不能很快上手。这第三个顾虑比较现实HTTPS 背后关联到了密码学、TLS、PKI 等许多领域不是短短几周、几个月就能够精通的。但实施 HTTPS 也并不需要把这些完全掌握只要抓住少数几个要点就好下面我就来帮你逐个解决一些关键的“难点”。 3申请证书 大型网站出于信誉、公司形象的考虑通常会选择向传统的 CA 申请证书例如DigiCert、GlobalSign而中小型网站完全可以选择使用“Let’s Encrypt”这样的免费证书效果也完全不输于那些收费的证书。 “Let’s Encrypt”一直在推动证书的自动化部署为此还实现了专门的 ACME 协议RFC8555。有很多的客户端软件可以完成申请、验证、下载、更新的“一条龙”操作比如 Certbot、acme.sh 等等都可以在“Let’s Encrypt”网站上找到用法很简单相关的文档也很详细几分钟就能完成申请。 不过我必须提醒你几个注意事项。 第一申请证书时应当同时申请 RSA 和 ECDSA 两种证书在 Nginx 里配置成双证书验证这样服务器可以自动选择快速的椭圆曲线证书同时也兼容只支持 RSA 的客户端。 第二如果申请 RSA 证书私钥至少要 2048 位摘要算法应该选用 SHA-2例如SHA256、SHA384 等。 第三出于安全的考虑“Let’s Encrypt”证书的有效期很短只有 90 天时间一到就会过期失效所以必须要定期更新。你可以在 crontab 里加个每周或每月任务发送更新请求不过很多 ACME 客户端会自动添加这样的定期任务完全不用你操心。 4配置HTTPS 这在 Nginx 上非常简单只要在“listen”指令后面加上参数“ssl”再配上刚才的证书文件就可以实现最基本的 HTTPS。 listen 443 ssl; ssl_certificate xxx_rsa.crt; #rsa2048 cert ssl_certificate_key xxx_rsa.key; #rsa2048 private key ssl_certificate xxx_ecc.crt; #ecdsa cert ssl_certificate_key xxx_ecc.key; #ecdsa private ke 为了提高 HTTPS 的安全系数和性能你还可以强制 Nginx 只支持 TLS1.2 以上的协议打开“Session Ticket”会话复用 ssl_protocols TLSv1.2 TLSv1.3; ssl_session_timeout 5m; ssl_session_tickets on; ssl_session_ticket_key ticket.key; 密码套件的选择方面我给你的建议是以服务器的套件优先。这样可以避免恶意客户端故意选择较弱的套件、降低安全等级然后密码套件向 TLS1.3“看齐”只使用 ECDHE、AES和 ChaCha20支持“False Start”。 ssl_prefer_server_ciphers on; ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128 如果你的服务器上使用了 OpenSSL 的分支 BorringSSL那么还可以使用一个特殊的“等价密码组”Equal preference cipher groups特性它可以让服务器配置一组“等价”的密码套件在这些套件里允许客户端优先选择比如这么配置 ssl_ciphers [ECDHE-ECDSA-AES128-GCM-SHA256|ECDHE-ECDSA-CHACHA20-POLY1305]; 如果客户端硬件没有 AES 优化服务器就会顺着客户端的意思优先选择与 AES“等价”的 ChaCha20 算法让客户端能够快一点。 全部配置完成后你可以访问“SSLLabs”网站测试网站的安全程度它会模拟多种客户端发起测试打出一个综合的评分。 5服务器名称指示 配置 HTTPS 服务时还有一个“虚拟主机”的问题需要解决。在 HTTP 协议里多个域名可以同时在一个 IP 地址上运行这就是“虚拟主机”Web服务器会使用请求头里的 Host 字段来选择。 但在 HTTPS 里因为请求头只有在 TLS 握手之后才能发送在握手时就必须选择“虚拟主机”对应的证书TLS 无法得知域名的信息就只能用 IP 地址来区分。所以最早的时候每个 HTTPS 域名必须使用独立的 IP 地址非常不方便。 那么怎么解决这个问题呢这还是得用到 TLS 的“扩展”给协议加个SNIServer Name Indication的“补充条款”。它的作用和 Host 字段差不多客户端会在“Client Hello”时带上域名信息这样服务器就可以根据名字而不是 IP 地址来选择证书。 Extension: server_name (len19) Server Name Indication extension Server Name Type: host_name (0) Server Name: www.chrono.com Nginx 很早就基于 SNI 特性支持了 HTTPS 的虚拟主机在 OpenResty 里可还以编写Lua 脚本利用 Redis、MySQL 等数据库更灵活快速地加载证书。 6重定向跳转 现在有了 HTTPS 服务但原来的 HTTP 站点也不能马上弃用还是会有很多网民习惯在地址栏里直接敲域名或者是旧的书签、超链接默认使用 HTTP 协议访问。 所以我们就需要用到“重定向跳转”技术了把不安全的 HTTP 网址用 301或 302“重定向”到新的 HTTPS 网站在 Nginx 里也很容易做到使“return”或“rewrite”都可以。 return 301 https://$host$request_uri; # 永久重定向 rewrite ^ https://$host$request_uri permanent; # 永久重定向 但这种方式有两个问题。一个是重定向增加了网络成本多出了一次请求另一个是存在安全隐患重定向的响应可能会被“中间人”窜改实现“会话劫持”跳转到恶意网站。 不过有一种叫“HSTS”HTTP 严格传输安全HTTP Strict Transport Security的技术可以消除这种安全隐患。HTTPS 服务器需要在发出的响应头里添加一个“Strict-Transport-Security”的字段再设定一个有效期例如 Strict-Transport-Security: max-age15768000; includeSubDomains 这相当于告诉浏览器我这个网站必须严格使用 HTTPS 协议在半年之内182.5 天都不允许用 HTTP你以后就自己做转换吧不要再来麻烦我了。 有了“HSTS”的指示以后浏览器再访问同样的域名的时候就会自动把 URI 里的“http”改成“https”直接访问安全的 HTTPS 网站。这样“中间人”就失去了攻击的机会而且对于客户端来说也免去了一次跳转加快了连接速度。 五、未来 1、HTTP/2特性概览 HTTP 有两个主要的缺点安全不足和性能不高。通过引入 SSL/TLS 在安全上达到了“极致”但在性能提升方面却是乏善可陈只优化了握手加密的环节对于整体的数据传输没有提出更好的改进方案还只能依赖于“长连接”这种“落后”的技术 所以在 HTTPS 逐渐成熟之后HTTP 就向着性能方面开始“发力”走出了另一条进化的道路。 在HTTP 历史中你也看到了Google 率先发明了SPDY 协议并应用于自家的浏览器 Chrome打响了 HTTP 性能优化的“第一枪”。随后互联网标准化组织 IETF 以 SPDY 为基础综合其他多方的意见终于推出了 HTTP/1的继任者也就是今天的主角“HTTP/2”在性能方面有了一个大的飞跃。 1为什么不是HTTP/2.0 他们认为以前的“1.0”“1.1”造成了很多的混乱和误解让人在实际的使用中难以区分差异所以就决定 HTTP 协议不再使用小版本号minor version只使用大版本号major version从今往后 HTTP 协议不会出现 HTTP/2.0、2.1只会有“HTTP/2”“HTTP/3”…… 2兼容HTTP/1 协议的修改必须小心谨慎兼容性是首要考虑的目标否则就会破坏互联网上无数现有的资产这方面TLS 已经有了先例为了兼容 TLS1.2 不得不进行“伪装”。 因为必须要保持功能上的兼容所以 HTTP/2 把 HTTP 分解成了“语义”和“语法”两个部分“语义”层不做改动与 HTTP/1 完全一致即 RFC7231。比如请求方法、URI、状态码、头字段等概念都保留不变这样就消除了再学习的成本基于 HTTP 的上层应用也不需要做任何修改可以无缝转换到 HTTP/2。 特别要说的是与 HTTPS 不同HTTP/2 没有在 URI 里引入新的协议名仍然用“http”表示明文协议用“https”表示加密协议。这是一个非常了不起的决定可以让浏览器或者服务器去自动升级或降级协议免去了选择的麻烦让用户在上网的时候都意识不到协议的切换实现平滑过渡。 在“语义”保持稳定之后HTTP/2 在“语法”层做了“天翻地覆”的改造完全变更了HTTP 报文的传输格式。 3头部压缩 HTTP/1 里可以用头字段“Content-Encoding”指定Body 的编码方式比如用 gzip 压缩来节约带宽但报文的另一个组成部分——Header却被无视了没有针对它的优化手段。 由于报文 Header 一般会携带“User Agent”“Cookie”“Accept”“Server”等许多固定的头字段多达几百字节甚至上千字节但 Body 却经常只有几十字节比如 GET 请求、204/301/304 响应成了不折不扣的“大头儿子”。更要命的是成千上万的请求响应报文里有很多字段值都是重复的非常浪费“长尾效应”导致大量带宽消耗在了这些冗余度极高的数据上。 不过 HTTP/2 并没有使用传统的压缩算法而是开发了专门的“HPACK”算法在客户端和服务器两端建立“字典”用索引号表示重复的字符串还釆用哈夫曼编码来压缩整数和字符串可以达到 50%~90% 的高压缩率。 4二进制格式 你可能已经很习惯于 HTTP/1 里纯文本形式的报文了它的优点是“一目了然”用最简单的工具就可以开发调试非常方便。 但 HTTP/2 在这方面没有“妥协”决定改变延续了十多年的现状不再使用肉眼可见的ASCII 码而是向下层的 TCP/IP 协议“靠拢”全面采用二进制格式。 这样虽然对人不友好但却大大方便了计算机的解析。原来使用纯文本的时候容易出现多义性比如大小写、空白字符、回车换行、多字少字等等程序在处理时必须用复杂的状态机效率低还麻烦。 而二进制里只有“0”和“1”可以严格规定字段大小、顺序、标志位等格式“对就是对错就是错”解析起来没有歧义实现简单而且体积小、速度快做到“内部提效”。 HTTP/2以二进制格式为基础把 TCP 协议的部分特性挪到了应用层把原来的“HeaderBody”的消息“打散”为数个小片的二进制“帧”Frame用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。 HTTP/2 数据分帧后“HeaderBody”的报文结构就完全消失了协议看到的只是一个个的“碎片”。 5虚拟的流 消息的“碎片”到达目的地后应该怎么组装起来HTTP/2 为此定义了一个“流”Stream的概念它是二进制帧的双向传输序列同一个消息往返的帧会分配一个唯一的流 ID。你可以把它想象成是一个虚拟的“数据流”在里面流动的是一串有先后顺序的数据帧这些数据帧按照次序组装起来就是 HTTP/1 里的请求报文和响应报文。 因为“流”是虚拟的实际上并不存在所以 HTTP/2 就可以在一个 TCP 连接上用“流”同时发送多个“碎片化”的消息这就是常说的“多路复用” Multiplexing——多个往返通信都复用一个连接来处理。 在“流”的层面上看消息是一些有序的“帧”序列而在“连接”的层面上看消息却是乱序收发的“帧”。多个请求 / 响应之间没有了顺序关系不需要排队等待也就不会再出现“队头阻塞”问题降低了延迟大幅度提高了连接的利用率。 为了更好地利用连接加大吞吐量HTTP/2 还添加了一些控制帧来管理虚拟的“流”实现了优先级和流量控制这些特性也和 TCP 协议非常相似。 HTTP/2 还在一定程度上改变了传统的“请求 - 应答”工作模式服务器不再是完全被动地响应请求也可以新建“流”主动向客户端发送消息。比如在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端减少等待的延迟这被称为“服务器推送”Server Push也叫 Cache Push。 6强化安全 出于兼容的考虑HTTP/2 延续了 HTTP/1 的“明文”特点可以像以前一样使用明文传输数据不强制使用加密通信不过格式还是二进制只是不需要解密。 但由于 HTTPS 已经是大势所趋而且主流的浏览器 Chrome、Firefox 等都公开宣布只支持加密的 HTTP/2所以“事实上”的 HTTP/2 是加密的。也就是说互联网上通常所能见到的 HTTP/2 都是使用“https”协议名跑在 TLS 上面。 为了区分“加密”和“明文”这两个不同的版本HTTP/2 协议定义了两个字符串标识符“h2”表示加密的 HTTP/2“h2c”表示明文的 HTTP/2多出的那个字母“c”的意思是“clear text”。 在 HTTP/2 标准制定的时候2015 年已经发现了很多 SSL/TLS 的弱点而新的 TLS1.3还未发布所以加密版本的 HTTP/2 在安全方面做了强化要求下层的通信协议必须是TLS1.2 以上还要支持前向安全和 SNI并且把几百个弱密码套件列入了“黑名单”比如 DES、RC4、CBC、SHA-1 都不能在 HTTP/2 里使用相当于底层用的是“TLS1.25”。 7协议栈 下面的这张图对比了 HTTP/1、HTTPS 和 HTTP/2 的协议栈你可以清晰地看到HTTP/2是建立在“HPack”“Stream”“TLS1.2”基础之上的比 HTTP/1、HTTPS 复杂了一些。 虽然 HTTP/2 的底层实现很复杂但它的“语义”还是简单的 HTTP/1之前学习的知识不会过时仍然能够用得上。 你可能还会注意到 URI 里的一个小变化端口使用的是“8443”而不是“443”。这是因为 443 端口已经被 HTTPS 协议占用Nginx 不允许在同一个端口上根据域名选择性开启 HTTP/2所以就不得不改用了“8443”。 2、HTTP/2内核剖析 1连接前言 由于 HTTP/2“事实上”是基于 TLS所以在正式收发数据之前会有 TCP 握手和 TLS 握手TLS 握手成功之后客户端必须要发送一个“连接前言”connection preface用来确认建立 HTTP/2 连接。 这个“连接前言”是标准的 HTTP/1 请求报文使用纯文本的 ASCII 码格式请求方法是特别注册的一个关键字“PRI”全文只有 24 个字节 PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n 在 Wireshark 里HTTP/2 的“连接前言”被称为“Magic”意思就是“不可知的魔法”。只要服务器收到这个“有魔力的字符串”就知道客户端在 TLS 上想要的是 HTTP/2 协议而不是其他别的协议后面就会都使用 HTTP/2的数据格式。 2头部压缩 确立了连接之后HTTP/2 就开始准备请求报文。因为语义上它与 HTTP/1 兼容所以报文还是由“HeaderBody”构成的但在请求发送前必须要用“HPACK”算法来压缩头部数据。 “HPACK”算法是专门为压缩 HTTP 头部定制的算法与 gzip、zlib 等压缩算法不同它是一个“有状态”的算法需要客户端和服务器各自维护一份“索引表”也可以说是“字典”这有点类似 brotli压缩和解压缩就是查表和更新表的操作。 为了方便管理和压缩HTTP/2 废除了原有的起始行概念把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式并且给这些“不是头字段的头字段”起了个特别的名字——“伪头字段”pseudo-header fields。而起始行里的版本号和错误原因短语因为没什么大用顺便也给废除了。 为了与“真头字段”区分开来这些“伪头字段”会在名字前加一个“:”比如“:authority” “:method” “:status”分别表示的是域名、请求方法和状态码。 现在 HTTP 报文头就简单了全都是“Key-Value”形式的字段于是 HTTP/2 就为一些最常用的头字段定义了一个只读的“静态表”Static Table。 下面的这个表格列出了“静态表”的一部分这样只要查表就可以知道字段名和对应的值比如数字“2”代表“GET”数字“8”代表状态码 200。 但如果表里只有 Key 没有 Value或者是自定义字段根本找不到该怎么办呢这就要用到“动态表”Dynamic Table它添加在静态表后面结构相同但会在编码解码的时候随时更新。 比如说第一次发送请求时的“user-agent”字段长是一百多个字节用哈夫曼压缩编码发送之后客户端和服务器都更新自己的动态表添加一个新的索引号“65”。那么下一次发送的时候就不用再重复发那么多字节了只要用一个字节发送编号就好。 随着在 HTTP/2 连接上发送的报文越来越多两边的“字典”也会越来越丰富最终每次的头部字段都会变成一两个字节的代码原来上千字节的头用几十个字节就可以表示了压缩效果比 gzip 要好得多。 3二进制帧 头部数据压缩之后HTTP/2 就要把报文拆成二进制的帧准备发送。HTTP/2 的帧结构有点类似 TCP 的段或者 TLS 里的记录但报头很小只有 9 字节非常地节省可以对比一下 TCP 头它最少是 20 个字节。 二进制的格式也保证了不会有歧义而且使用位运算能够非常简单高效地解析。 桢长度帧开头是 3 个字节的长度但不包括头的 9 个字节默认上限是 2^14最大是 2^24也就是说 HTTP/2 的帧通常不超过 16K最大是 16M。 帧类型大致可以分成数据帧和控制帧两类HEADERS 帧和 DATA帧属于数据帧存放的是 HTTP 报文而 SETTINGS、PING、PRIORITY 等则是用来管理流的控制帧。HTTP/2 总共定义了 10 种类型的帧但一个字节可以表示最多 256 种所以也允许在标准之外定义其他类型实现功能扩展。这就有点像 TLS 里扩展协议的意思了比如 Google 的gRPC 就利用了这个特点定义了几种自用的新帧类型。 帧标志可以保存 8 个标志位携带简单的控制信息。常用的标志位有END_HEADERS表示头数据结束相当于 HTTP/1 里头后的空行“\r\n”END_STREAM表示单方向数据发送结束即 EOSEnd of Stream相当于 HTTP/1 里 Chunked 分块结束标志“0\r\n\r\n”。 流标识符也就是帧所属的“流”接收方使用它就可以从乱序的帧里识别出具有相同流 ID 的帧序列按顺序组装起来就实现了虚拟的“流”。流标识符虽然有 4 个字节但最高位被保留不用所以只有 31 位可以使用也就是说流标识符的上限是 2^31大约是 21 亿。 好了把二进制头理清楚后我们来看一下 Wireshark 抓包的帧实例 桢长度开头的三个字节是“00010a”表示数据长度是 266 字节。 帧类型是 1表示 HEADERS 帧负载payload里面存放的是被 HPACK 算法压缩的头部信息。 帧标志标志位是 0x25转换成二进制有 3 个位被置 1。PRIORITY 表示设置了流的优先级END_HEADERS 表示这一个帧就是完整的头数据END_STREAM 表示单方向数据发送结束后续再不会有数据帧即请求报文完毕不会再有 DATA 帧 /Body 数据。 流标识符是整数 1表示这是客户端发起的第一个流后面的响应数据帧也会是这个 ID也就是说在 stream[1] 里完成这个请求响应。 4流与多路复用 弄清楚了帧结构后我们就来看 HTTP/2 的流与多路复用它是 HTTP/2 最核心的部分。流是二进制帧的双向传输序列。要搞明白流关键是要理解帧头里的流 ID。 在 HTTP/2 连接上虽然帧是乱序收发的但只要它们都拥有相同的流 ID就都属于一个流而且在这个流里帧不是无序的而是有着严格的先后顺序。 比如在这次的 Wireshark 抓包里就有“0、1、3”一共三个流实际上就是分配了三个流 ID 号把这些帧按编号分组再排一下队就成了流。 在概念上一个 HTTP/2 的流就等同于一个 HTTP/1 里的“请求 - 应答”。在 HTTP/1 里一个“请求 - 响应”报文来回是一次 HTTP 通信在 HTTP/2 里一个流也承载了相同的功能。 你还可以对照着 TCP 来理解。TCP 运行在 IP 之上其实从 MAC 层、IP 层的角度来看TCP 的“连接”概念也是“虚拟”的。但从功能上看无论是 HTTP/2 的流还是 TCP 的连接都是实际存在的所以你以后大可不必再纠结于流的“虚拟”性把它当做是一个真实存在的实体来理解就好。 HTTP/2 的流有如下特点
流是可并发的一个 HTTP/2 连接上可以同时发出多个流传输数据也就是并发多请求实现“多路复用”客户端和服务器都可以创建流双方互不干扰流是双向的一个流里面客户端和服务器都可以发送或接收数据帧也就是一个“请求- 应答”来回流之间没有固定关系彼此独立但流内部的帧是有严格顺序的流可以设置优先级让服务器优先处理比如先传 HTML/CSS后传图片优化用户体验流 ID 不能重用只能顺序递增客户端发起的 ID 是奇数服务器端发起的 ID 是偶数在流上发送“RST_STREAM”帧可以随时终止流取消接收或发送第 0 号流比较特殊不能关闭也不能发送数据帧只能发送控制帧用于流量控制。 这里我又画了一张图把上次的图略改了一下显示了连接中无序的帧是如何依据流 ID 重组成流的。 从这些特性中我们还可以推理出一些深层次的知识点。 比如说HTTP/2 在一个连接上使用多个流收发数据那么它本身默认就会是长连接所以永远不需要“Connection”头字段keepalive 或 close。 又比如下载大文件的时候想取消接收在 HTTP/1 里只能断开 TCP 连接重新“三次握手”成本很高而在 HTTP/2 里就可以简单地发送一个“RST_STREAM”中断流而长连接会继续保持。 再比如因为客户端和服务器两端都可以创建流而流 ID 有奇数偶数和上限的区分所以大多数的流 ID 都会是奇数而且客户端在一个连接里最多只能发出 2^30也就是 10 亿个请求。 所以就要问了ID 用完了该怎么办呢这个时候可以再发一个控制帧“GOAWAY”真正关闭 TCP 连接。 5流状态转换 流很重要也很复杂。为了更好地描述运行机制HTTP/2 借鉴了 TCP根据帧的标志位实现流状态转换。当然这些状态也是虚拟的只是为了辅助理解。 HTTP/2 的流也有一个状态转换图虽然比 TCP 要简单一点但也不那么好懂所以今天我只画了一个简化的图对应到一个标准的 HTTP“请求 - 应答”。 最开始的时候流都是“空闲”idle状态也就是“不存在”可以理解成是待分配的“号段资源”。 当客户端发送 HEADERS 帧后有了流 ID流就进入了“打开”状态两端都可以收发数据然后客户端发送一个带“END_STREAM”标志位的帧流就进入了“半关闭”状态。 这个“半关闭”状态很重要意味着客户端的请求数据已经发送完了需要接受响应数据而服务器端也知道请求数据接收完毕之后就要内部处理再发送响应数据。 响应数据发完了之后也要带上“END_STREAM”标志位表示数据发送完毕这样流两端就都进入了“关闭”状态流就结束了。 刚才也说过流 ID 不能重用所以流的生命周期就是 HTTP/1 里的一次完整的“请求 - 应答”流关闭就是一次通信结束。 下一次再发请求就要开一个新流而不是新连接流 ID 不断增加直到到达上限发送“GOAWAY”帧开一个新的 TCP 连接流 ID 就又可以重头计数。 你再看看这张图是不是和 HTTP/1 里的标准“请求 - 应答”过程很像只不过这是发生在虚拟的“流”上而不是实际的 TCP 连接又因为流可以并发所以 HTTP/2 就可以实现无阻塞的多路复用。 3、HTTP/3 1HTTP/2的队头阻塞 HTTP/2 虽然使用“帧”“流”“多路复用”没有了“队头阻塞”但这些手段都是在应用层里而在下层也就是 TCP 协议里还是会发生“队头阻塞”。 HTTP/2 把多个“请求 - 响应”分解成流交给TCP 后TCP 会再拆成更小的包依次发送其实在 TCP 里应该叫 segment也就是“段”。 在网络良好的情况下包可以很快送达目的地。但如果网络质量比较差像手机上网的时候就有可能会丢包。而 TCP 为了保证可靠传输有个特别的“丢包重传”机制丢失的包必须要等待重新传输确认其他的包即使已经收到了也只能放在缓冲区里上层的应用拿不出来只能“干着急”。
我举个简单的例子 客户端用 TCP 发送了三个包但服务器所在的操作系统只收到了后两个包第一个包丢了。那么内核里的 TCP 协议栈就只能把已经收到的包暂存起来“停下”等着客户端重传那个丢失的包这样就又出现了“队头阻塞”。 由于这种“队头阻塞”是 TCP 协议固有的所以 HTTP/2 即使设计出再多的“花样”也无法解决。Google 在推 SPDY 的时候就已经意识到了这个问题于是就又发明了一个新的“QUIC”协议让 HTTP 跑在 QUIC 上而不是 TCP 上。 而这个“HTTP over QUIC”就是 HTTP 协议的下一个大版本HTTP/3。它在 HTTP/2 的基础上又实现了质的飞跃真正“完美”地解决了“队头阻塞”问题。 这里先贴一下 HTTP/3 的协议栈图让你对它有个大概的了解。 2QUIC协议 从这张图里你可以看到 HTTP/3 有一个关键的改变那就是它把下层的 TCP“抽掉”了换成了 UDP。因为 UDP 是无序的包之间没有依赖关系所以就从根本上解决了“队头阻塞”。 UDP 是一个简单、不可靠的传输协议只是对 IP 协议的一层很薄的包装和TCP 相比它实际应用的较少。不过正是因为它简单不需要建连和断连通信成本低也就非常灵活、高效“可塑性”很强。 所以QUIC 就选定了 UDP在它之上把 TCP 的那一套连接管理、拥塞窗口、流量控制等“搬”了过来“去其糟粕取其精华”打造出了一个全新的可靠传输协议可以认为是“新时代的 TCP”。 QUIC 最早是由 Google 发明的被称为 gQUIC。而当前正在由 IETF 标准化的 QUIC 被称为 iQUIC。两者的差异非常大甚至比当年的 SPDY 与 HTTP/2 的差异还要大。 gQUIC 混合了 UDP、TLS、HTTP是一个应用层的协议。而 IETF 则对 gQUIC 做了“清理”把应用部分分离出来形成了 HTTP/3原来的 UDP 部分“下放”到了传输层所以 iQUIC 有时候也叫“QUIC-transport”。 接下来要说的 QUIC 都是指 iQUIC要记住它与早期的 gQUIC 不同是一个传输层的协议和 TCP 是平级的。 3QUIC的特点 QUIC 基于 UDP而 UDP 是“无连接”的根本就不需要“握手”和“挥手”所以天生就要比 TCP 快。 就像 TCP 在 IP 的基础上实现了可靠传输一样QUIC 也基于 UDP 实现了可靠传输保证数据一定能够抵达目的地。它还引入了类似 HTTP/2 的“流”和“多路复用”单个“流”是有序的可能会因为丢包而阻塞但其他“流”不会受到影响。 为了防止网络上的中间设备Middle Box识别协议的细节QUIC 全面采用加密通信可以很好地抵御窜改和“协议僵化”ossification。 而且因为 TLS1.3 已经在2018年正式发布所以 QUIC 就直接应用了 TLS1.3顺便也就获得了 0-RTT、1-RTT 连接的好处。 但 QUIC 并不是建立在 TLS 之上而是内部“包含”了 TLS。它使用自己的帧“接管”了TLS 里的“记录”握手消息、警报消息都不使用 TLS 记录直接封装成 QUIC 的帧发送省掉了一次开销。 4QUIC内部细节 由于 QUIC 在协议栈里比较偏底层所以我只简略介绍两个内部的关键知识点。 QUIC 的基本数据传输单位是包packet和帧frame一个包由多个帧组成包面向的是“连接”帧面向的是“流”。 QUIC 使用不透明的“连接 ID”来标记通信的两个端点客户端和服务器可以自行选择一组 ID 来标记自己这样就解除了 TCP 里连接对“IP 地址 端口”即常说的四元组的强绑定支持“连接迁移”Connection Migration。 比如你下班回家手机会自动由 4G 切换到 WiFi。这时 IP 地址会发生变化TCP 就必须重新建立连接。而 QUIC 连接里的两端连接 ID 不会变所以连接在“逻辑上”没有中断它就可以在新的 IP 地址上继续使用之前的连接消除重连的成本实现连接的无缝迁移。 QUIC 的帧里有多种类型PING、ACK 等帧用于管理连接而 STREAM 帧专门用来实现流。 QUIC 里的流与 HTTP/2 的流非常相似也是帧的序列你可以对比着来理解。但 HTTP/2里的流都是双向的而 QUIC 则分为双向流和单向流。 QUIC 帧普遍采用变长编码最少只要 1 个字节最多有 8 个字节。流 ID 的最大可用位数是 62数量上比 HTTP/2 的 2^31 大大增加。 流 ID 还保留了最低两位用作标志第 1 位标记流的发起者0 表示客户端1 表示服务器第 2 位标记流的方向0 表示双向流1 表示单向流。所以 QUIC 流 ID 的奇偶性质和 HTTP/2 刚好相反客户端的 ID 是偶数从 0 开始计数。 5HTTP/3协议 因为 QUIC 本身就已经支持了加密、流和多路复用所以 HTTP/3 的工作减轻了很多把流控制都交给 QUIC 去做。调用的不再是 TLS 的安全接口也不是 Socket API而是专门的 QUIC 函数。不过这个“QUIC 函数”还没有形成标准必须要绑定到某一个具体的实现库。 HTTP/3 里仍然使用流来发送“请求 - 响应”但它自身不需要像 HTTP/2 那样再去定义流而是直接使用 QUIC 的流相当于做了一个“概念映射”。 HTTP/3 里的“双向流”可以完全对应到 HTTP/2 的流而“单向流”在 HTTP/3 里用来实现控制和推送近似地对应 HTTP/2 的 0 号流。 由于流管理被“下放”到了 QUIC所以 HTTP/3 里帧的结构也变简单了。 HTTP/3 里的帧仍然分成数据帧和控制帧两类HEADERS 帧和 DATA 帧传输数据但其他一些帧因为在下层的 QUIC 里有了替代所以在 HTTP/3 里就都消失了比如RST_STREAM、WINDOW_UPDATE、PING 等。 头部压缩算法在 HTTP/3 里升级成了“QPACK”使用方式上也做了改变。虽然也分成静态表和动态表但在流上发送 HEADERS 帧时不能更新字段只能引用索引表的更新需要在专门的单向流上发送指令来管理解决了 HPACK 的“队头阻塞”问题。 另外QPACK 的字典也做了优化静态表由之前的 61 个增加到了 98 个而且序号从 0开始也就是说“:authority”的编号是 0。 6HTTP/3服务发现 HTTP/3 没有指定默认的端口号也就是说不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服务。 这就要用到 HTTP/2 里的“扩展帧”了。浏览器需要先用 HTTP/2 协议连接服务器然后服务器可以在启动 HTTP/2 连接后发送一个“Alt-Svc”帧包含一个“h3host:port”的字符串告诉浏览器在另一个端点上提供等价的 HTTP/3 服务。 浏览器收到“Alt-Svc”帧会使用 QUIC 异步连接指定的端口如果连接成功就会断开HTTP/2 连接改用新的 HTTP/3 收发数据。 4、是否要迁移到HTTP/2 与各大浏览器“强推”HTTPS 的待遇不一样HTTP/2 的公布可谓是“波澜不惊”。虽然它是 HTTP 协议的一个重大升级但 Apple、Google 等科技巨头并没有像 HTTPS 那样给予大量资源的支持。 直到今天HTTP/2 在互联网上还是处于“不温不火”的状态虽然已经有了不少的网站改造升级到了 HTTP/2但普及的速度远不及 HTTPS。 1HTTP/2的优点 兼容HTTP/2 最大的一个优点是完全保持了与 HTTP/1 的兼容在语义上没有任何变化因为兼容 HTTP/1所以 HTTP/2 也具有 HTTP/1 的所有优点并且“基本”解决了HTTP/1 的所有缺点。 安全HTTP/2 对 HTTPS 在各方面都做了强化。下层的 TLS 至少是 1.2而且只能使用前向安全的密码套件即 ECDHE这同时也就默认实现了“TLS False Start”支持1-RTT 握手所以不需要再加额外的配置就可以自动实现 HTTPS 加速。 性能影响网络速度的两个关键因素是“带宽”和“延迟”HTTP/2 的头部压缩、多路复用、流优先级、服务器推送等手段其实都是针对这两个要点。
头部压缩节约带宽的基本手段就是压缩在 HTTP/1 里只能压缩 body而 HTTP/2 则可以用HPACK 算法压缩 header这对高流量的网站非常有价值有数据表明能节省大概5%~10% 的流量这是实实在在的“真金白银”。多路复用与 HTTP/1“并发多个连接”不同HTTP/2 的“多路复用”特性要求对一个域名或者IP只用一个 TCP 连接所有的数据都在这一个连接上传输这样不仅节约了客户端、服务器和网络的资源还可以把带宽跑满让 TCP 充分“吃饱”。HTTP/1 里的长连接虽然是双向通信但任意一个时间点实际上还是单向的再加上“队头阻塞”实际的带宽打了个“对折”还不止。HTTP/2 里“多路复用”则让 TCP 开足了马力“全速狂奔”多个请求响应并发每时每刻上下行方向上都有流在传输数据没有空闲的时候带宽的利用率能够接近100%。所以HTTP/2 只使用一个连接就能抵得过 HTTP/1 里的五六个连接。流优先级不过流也可能会有依赖关系可能会存在等待导致的阻塞这就是“延迟”所以 HTTP/2的其他特性就派上了用场。“优先级”可以让客户端告诉服务器哪个文件更重要更需要优先传输服务器就可以调高流的优先级合理地分配有限的带宽资源让高优先级的 HTML、图片更快地到达客户端尽早加载显示。服务器推送也是降低延迟的有效手段它不需要客户端预先请求服务器直接就发给客户端这就省去了客户端解析 HTML 再请求的时间。 2HTTP/2的缺点 HTTP/2 在 TCP 级别还是存在“队头阻塞”的问题。所以如果网络连接质量差发生丢包那么 TCP 会等待重传传输速度就会降低。 在移动网络中发生 IP 地址切换的时候下层的 TCP 必须重新建连要再次“握手”经历“慢启动”而且之前连接里积累的 HPACK 字典也都消失了必须重头开始计算导致带宽浪费和时延。 HTTP/2 对一个域名只开一个连接所以一旦这个连接出问题那么整个网站的体验也就变差了。而这些情况下 HTTP/1 反而不会受到影响因为它“本来就慢”而且还会对一个域名开6~8 个连接顶多其中的一两个连接会“更慢”其他的连接不会受到影响。 3应该迁移到HTTP/2吗 HTTP/2 处于一个略“尴尬”的位置前面有“老前辈”HTTP/1后面有“新来者”HTTP/3即有“老前辈”的“打压”又有“新来者”的“追赶”也就难怪没有获得市场的大力“吹捧”了。 但这绝不是说 HTTP/2“一无是处”实际上 HTTP/2 的性能改进效果是非常明显的Top1000 的网站中已经有超过 40% 运行在了 HTTP/2 上包括知名的 Apple、Facebook、Google、Twitter 等等。仅用了四年的时间HTTP/2 就拥有了这么大的市场份额和巨头的认可足以证明它的价值。 因为 HTTP/2 的侧重点是“性能”所以“是否迁移”就需要在这方面进行评估。如果网站的流量很大那么 HTTP/2 就可以带来可观的收益反之如果网站流量比较小那么级到 HTTP/2 就没有太多必要了只要利用现有的 HTTP 再优化就足矣。 不过如果你是新建网站我觉得完全可以跳过 HTTP/1、HTTPS直接“一步到位”上HTTP/2这样不仅可以获得性能提升还免去了老旧的“历史包袱”日后也不会再有迁移的烦恼。 4配置HTTP/2 因为 HTTP/2“事实上”是加密的所以如果你已经成功迁移到了HTTPS那么在 Nginx 里启用 HTTP/2 简直可以说是“不费吹灰之力”只需要在 server配置里再多加一个参数就可以搞定了。 server { listen 443 ssl http2; server_name www.xxx.net; ssl_certificate xxx.crt; ssl_certificate_key xxx.key; 注意“listen”指令在“ssl”后面多了一个“http2”这就表示在 443 端口上开启了SSL 加密然后再启用HTTP/2。 配置服务器推送特性可以使用指令“http2_push”和“http2_push_preload” http2_push /style/xxx.css; http2_push_preload on; 不过如何合理地配置推送是个难题如果推送给浏览器不需要的资源反而浪费了带宽。这方面暂时没有一般性的原则指导你必须根据自己网站的实际情况去“猜测”客户端最需要的数据。 优化方面HTTPS 的一些策略依然适用比如精简密码套件、ECC 证书、会话复用、HSTS 减少重定向跳转等等。但还有一些优化手段在 HTTP/2 里是不适用的而且还会有反效果比如说常见的精灵图Spriting、资源内联inlining、域名分片Sharding等。 还要注意一点HTTP/2 默认启用 header 压缩HPACK但并没有默认启用 body 压缩所以不要忘了在 Nginx 配置文件里加上“gzip”指令压缩 HTML、JS 等文本数据。 5应用层协议协商ALPN 在 URI 里用的都是 HTTPS 协议名没有版本标记浏览器怎么知道服务器支持 HTTP/2 呢答案在 TLS 的扩展里有一个叫“ALPN”Application Layer Protocol Negotiation的东西用来与服务器就 TLS 上跑的应用协议进行“协商”。 客户端在发起“Client Hello”握手的时候后面会带上一个“ALPN”扩展里面按照优先顺序列出客户端支持的应用协议。 就像下图这样最优先的是“h2”其次是“http/1.1”以前还有“spdy”以后还可能会有“h3”。 服务器看到 ALPN 扩展以后就可以从列表里选择一种应用协议在“Server Hello”里也带上“ALPN”扩展告诉客户端服务器决定使用的是哪一种。因为我们在 Nginx 配置里使用了 HTTP/2 协议所以在这里它选择的就是“h2”。 这样在 TLS 握手结束后客户端和服务器就通过“ALPN”完成了应用层的协议协商后面就可以使用 HTTP/2 通信了。 六、优化
从 HTTP 最基本的“请求 - 应答”模型来着手。在这个模型里有两个角色客户端和服务器还有中间的传输链路考查性能就可以看这三个部分。 但因为我们是无法完全控制客户端的所以实际上的优化工作通常是在服务器端。这里又可以细分为后端和前端后端是指网站的后台服务而前端就是 HTML、CSS、图片等展现在客户端的代码和数据。 总的来说任何计算机系统的优化都可以分成这么几类硬件软件、内部外部、花钱不花钱。 投资购买现成的硬件最简单的优化方式比如换上更强的 CPU、更快的网卡、更大的带宽、更多的服务器效果也会“立竿见影”直接提升网站的服务能力也就实现了 HTTP优化。 花钱购买外部的软件或者服务也是一种行之有效的优化方式最“物有所值”的应该算是 CDN。CDN 专注于网络内容交付帮助网站解决“中间一公里”的问题还有很多其他非常专业的优化功能。把网站交给 CDN 运营就好像是“让网站坐上了喷气飞机”能够直达用户几乎不需要费什么力气就能够达成很好的优化效果。 在网站内部、“不花钱”的软件优化主要有三种方式开源、节流、缓存。 1、服务器 我们先来看看服务器它一般运行在 Linux 操作系统上用 Apache、Nginx 等 Web 服务器软件对外提供服务所以性能的含义就是它的服务能力也就是尽可能多、尽可能快地处理用户的请求。 衡量服务器性能的主要指标有三个吞吐量requests per second、并发数concurrency和响应时间time per request。
吞吐量就是我们常说的 RPS每秒的请求次数也有叫 TPS、QPS它是服务器最基本的性能指标RPS 越高就说明服务器的性能越好。并发数反映的是服务器的负载能力也就是服务器能够同时支持的客户端数量当然也是越多越好能够服务更多的用户。响应时间反映的是服务器的处理能力也就是快慢程度响应时间越短单位时间内服务器就能够给越多的用户提供服务提高吞吐量和并发数。 除了上面的三个基本性能指标服务器还要考虑 CPU、内存、硬盘和网卡等系统资源的占用程度利用率过高或者过低都可能有问题。 在 HTTP 多年的发展过程中已经出现了很多成熟的工具来测量这些服务器的性能指标开源的、商业的、命令行的、图形化的都有。在 Linux 上最常用的性能测试工具可能就是 abApache Bench了比如下面的命令指定了并发数 100总共发送 10000 个请求 ab -c 100 -n 10000 http://www.xxx.com 系统资源监控方面Linux 自带的工具也非常多常用的有 uptime、top、vmstat、netstat、sar 等等 top # 查看 CPU 和内存占用情况 vmstat 2 # 每 2 秒检查一次系统状态 sar -n DEV 2 # 看所有网卡的流量定时 2 秒检查 理解了这些性能指标我们就知道了服务器的性能优化方向合理利用系统资源提高服务器的吞吐量和并发数降低响应时间。 2、客户端 客户端是信息的消费者一切数据都要通过网络从服务器获取所以它最基本的性能指标就是“延迟”latency。所谓的“延迟”其实就是“等待”等待数据到达客户端时所花费的时间。但因为 HTTP 的传输链路很复杂所以延迟的原因也就多种多样。
光速因为地理距离而导致的延迟是无法克服的访问数千公里外的网站显然会有更大的延迟。带宽它又包括接入互联网时的电缆、WiFi、4G 和运营商内部网络、运营商之间网络的各种带宽每一处都有可能成为数据传输的瓶颈降低传输速度增加延迟。DNS 查询如果域名在本地没有缓存就必须向 DNS 系统发起查询引发一连串的网络通信成本而在获取 IP 地址之前客户端只能等待无法访问网站。TCP 握手你应该对它比较熟悉了吧必须要经过 SYN、SYN/ACK、ACK三个包之后才能建立连接它带来的延迟由光速和带宽共同决定。 对于 HTTP 性能优化也有一个专门的测试网站“WebPageTest”。它的特点是在世界各地建立了很多的测试点可以任意选择地理位置、机型、操作系统和浏览器发起测试。网站测试结果是一个直观的“瀑布图”Waterfall Chart清晰地列出了页面中所有资源加载的先后顺序和时间消耗比如下图就是对 GitHub 首页的一次测试。 Chrome 等浏览器自带的开发者工具也可以很好地观察客户端延迟指标面板左边有每个URI 具体消耗的时间面板的右边也是类似的瀑布图。点击某个 URI在 Timing 页里会显示出一个小型的“瀑布图”是这个资源消耗时间的详细分解延迟的原因都列的清清楚楚比如下面的这张图 图里面的这些指标都是什么含义呢我给你解释一下
Queued at因为有“队头阻塞”浏览器对每个域名最多开 6 个并发连接HTTP/1.1当页面里链接很多的时候就必须排队等待Queued、Queueing这里它就等待了 1.62 秒然后才被浏览器正式处理Stalled浏览器要预先分配资源调度连接花费了 11.56 毫秒;DNS Lookup连接前必须要解析域名这里因为有本地缓存所以只消耗了 0.41 毫秒Initial connection、SSL与网站服务器建立连接的成本很高总共花费了 270.87 毫秒其中有 134.89 毫秒用于TLS 握手那么 TCP 握手的时间就是 135.98 毫秒Request sent实际发送数据非常快只用了 0.11 毫秒TTFB之后就是等待服务器的响应专有名词叫 TTFBTime To First Byte也就是“首字节响应时间”里面包括了服务器的处理时间和网络传输时间花了 124.2 毫秒Content Dowload接收数据也是非常快的用了 3.58 毫秒。 从这张图你可以看到一次 HTTP“请求 - 响应”的过程中延迟的时间是非常惊人的总时间 415.04 毫秒里占了差不多 99%。所以客户端 HTTP 性能优化的关键就是降低延迟。 3、传输链路 以 HTTP 基本的“请求 - 应答”模型为出发点刚才我们得到了 HTTP 性能优化的一些指标现在我们来把视角放大到“真实的世界”看看客户端和服务器之间的传输链路它也是影响 HTTP 性能的关键。 如下是互联网示意图 第一公里是指网站的出口也就是服务器接入互联网的传输线路它的带宽直接决定了网站对外的服务能力也就是吞吐量等指标。显然优化性能应该在这“第一公里”加大投入尽量购买大带宽接入更多的运营商网络。中间一公里就是由许多小网络组成的实际的互联网其实它远不止“一公里”而是非常非常庞大和复杂的网络地理距离、网络互通都严重影响了传输速度。好在这里面有一个HTTP 的“好帮手”——CDN它可以帮助网站跨越“千山万水”让这段距离看起来真的就好像只有“一公里”。最后一公里是用户访问互联网的入口对于固网用户就是光纤、网线对于移动用户就是 WiFi、基站。以前它是客户端性能的主要瓶颈延迟大带宽小但随着近几年 4G 和高速宽带的普及“最后一公里”的情况已经好了很多不再是制约性能的主要因素了。第零公里就是网站内部的 Web 服务系统。它其实也是一个小型的网络当然也可能会非常大中间的数据处理、传输会导致延迟增加服务器的响应时间也是一个不可忽视的优化点。 在上面整个互联网传输链路中末端的“最后一公里”我们是无法控制的所以我们只能在“第零公里”“第一公里”和“中间一公里”这几个部分下功夫增加带宽降低延迟优化传输速度。 4、开源 这个“开源”是指抓“源头”开发网站服务器自身的潜力在现有条件不变的情况下尽量挖掘出更多的服务能力。 我们应该选用高性能的 Web 服务器最佳选择当然就是 Nginx/OpenResty 了尽量不要选择基于 Java、Python、Ruby 的其他服务器它们用来做后面的业务逻辑服务器更好。利用 Nginx 强大的反向代理能力实现“动静分离”动态页面交给 Tomcat、Django、Rails图片、样式表等静态资源交给 Nginx。 Nginx 或者 OpenResty 自身也有很多配置参数可以用来进一步调优举几个例子比如说禁用负载均衡锁、增大连接池绑定 CPU 等等。 对于 HTTP 协议一定要启用长连接。TCP 和SSL 建立新连接的成本是非常高的有可能会占到客户端总延迟的一半以上。长连接虽然不能优化连接握手但可以把成本“均摊”到多次请求里这样只有第一次请求会有延迟之后的请求就不会有连接延迟总体的延迟也就降低了。 另外在现代操作系统上都已经支持 TCP 的新特性“TCP Fast Open”Win10、iOS9、Linux 4.1它的效果类似 TLS 的“False Start”可以在初次握手的时候就传输数据也就是 0-RTT所以我们应该尽可能在操作系统和 Nginx 里开启这个特性减少外网和内网里的握手延迟。 下面给出一个简短的 Nginx 配置示例启用了长连接等优化参数实现了动静分离
server {listen 80 deferred reuseport backlog4096 fastopen1024; keepalive_timeout 60;keepalive_requests 10000;location ~* \.(png)$ {root /var/images/png/;}location ~* \.(php)$ {proxy_pass http://php_back_end;}
} 5、节流 “节流”是指减少客户端和服务器之间收发的数据量在有限的带宽里传输更多的内容。 “节流”最基本的做法就是使用 HTTP 协议内置的“数据压缩”编码不仅可以选择标准的 gzip还可以积极尝试新的压缩算法 br它有更好的压缩效果。 不过在数据压缩的时候应当注意选择适当的压缩率不要追求最高压缩比否则会耗费服务器的计算资源增加响应时间降低服务能力反而会“得不偿失”。gzip 和 br 是通用的压缩算法对于 HTTP 协议传输的各种格式数据我们还可以有针对性地采用特殊的压缩方式 HTML/CSS/JS 属于纯文本就可以采用特殊的“压缩”去掉源码里多余的空格、换行、注释等元素。这样“压缩”之后的文本虽然看起来很混乱对“人类”不友好但计算机仍然能够毫无障碍地阅读不影响浏览器上的运行效果。 图片在 HTTP 传输里占有非常高的比例虽然它本身已经被压缩过了不能被 gzip、br 处理但仍然有优化的空间。比如说去除图片里的拍摄时间、地点、机型等元数据适当降低分辨率缩小尺寸。图片的格式也很关键尽量选择高压缩率的格式有损格式应该用JPEG无损格式应该用 Webp 格式。 对于小文本或者小图片还有一种叫做“资源合并”Concatenation的优化方式就是把许多小资源合并成一个大资源用一个请求全下载到客户端然后客户端再用 JS、CSS切分后使用好处是节省了请求次数但缺点是处理比较麻烦。 刚才说的几种数据压缩都是针对的 HTTP 报文里的 body在 HTTP/1 里没有办法可以压缩header但我们也可以采取一些手段来减少 header 的大小不必要的字段就尽量不发例如 Server、X-Powered-By。 网站经常会使用 Cookie 来记录用户的数据浏览器访问网站时每次都会带上 Cookie冗余度很高。所以应当少使用 Cookie减少 Cookie 记录的数据量总使用 domain 和path 属性限定 Cookie 的作用域尽可能减少 Cookie 的传输。如果客户端是现代浏览器还可以使用 HTML5 里定义的 Web Local Storage避免使用 Cookie。 压缩之外“节流”还有两个优化点就是域名和重定向 DNS 解析域名会耗费不少的时间如果网站拥有多个域名那么域名解析获取 IP 地址就是一个不小的成本所以应当适当“收缩”域名限制在两三个左右减少解析完整域名所需的时间让客户端尽快从系统缓存里获取解析结果。 重定向引发的客户端延迟也很高它不仅增加了一次请求往返还有可能导致新域名的DNS 解析是 HTTP 前端性能优化的“大忌”。除非必要应当尽量不使用重定向或者使用 Web 服务器的“内部重定向”。 6、缓存 缓存不仅是 HTTP也是任何计算机系统性能优化的“法宝”把它和上面的“开源”“节流”搭配起来应用于传输链路就能够让 HTTP的性能再上一个台阶。 网站系统内部可以使用 Memcache、Redis、Varnish 等专门的缓存服务把计算的中间结果和资源存储在内存或者硬盘里Web 服务器首先检查缓存系统如果有数据就立即返回给客户端省去了访问后台服务的时间。 互联网上缓存更是性能优化的重要手段CDN 的网络加速功能就是建立在缓存的基础之上的可以这么说如果没有缓存那就没有 CDN。 利用好缓存功能的关键是理解它的工作原理为每个资源都添加 ETag 和 Last-modified 字段再用 Cache-Control、Expires 设置好缓存控制属性。其中最基本的是 max-age 有效期标记资源可缓存的时间。对于图片、CSS 等静态资源可以设置较长的时间比如一天或者一个月对于动态资源除非是实时性非常高也可以设置一个较短的时间比如 1 秒或者 5 秒。这样一旦资源到达客户端就会被缓存起来在有效期内都不会再向服务器发送请求也就是“没有请求的请求才是最快的请求。” 7、HTTP/2 在“开源”“节流”和“缓存”这三大策略之外HTTP 性能优化还有一个选择那就是把协议由 HTTP/1 升级到 HTTP/2。 HTTP/2 消除了应用层的队头阻塞拥有头部压缩、二进制帧、多路复用、流量控制、服务器推送等许多新特性大幅度提升了 HTTP 的传输效率。实际上这些特性也是在“开源”和“节流”这两点上做文章但因为这些都已经内置在了协议内所以只要换上 HTTP/2网站就能够立刻获得显著的性能提升。 一些在 HTTP/1 里的优化手段到了 HTTP/2 里会有“反效果”。对于 HTTP/2 来说一个域名使用一个 TCP 连接才能够获得最佳性能如果开多个域名就会浪费带宽和服务器资源也会降低 HTTP/2 的效率所以“域名收缩”在 HTTP/2 里是必须要做的。“资源合并”在 HTTP/1 里减少了多次请求的成本但在 HTTP/2 里因为有头部压缩和多路复用传输小文件的成本很低所以合并就失去了意义。而且“资源合并”还有一个缺点就是降低了缓存的可用性只要一个小文件更新整个缓存就完全失效必须重新下载。所以在现在的大带宽和 CDN 应用场景下应当尽量少用资源合并JS、CSS 图片合并数据内嵌让资源的粒度尽可能地小才能更好地发挥缓存的作用。 文章转载自： http://www.morning.xplng.cn.gov.cn.xplng.cn http://www.morning.pkggl.cn.gov.cn.pkggl.cn http://www.morning.cwgfq.cn.gov.cn.cwgfq.cn http://www.morning.sgfgz.cn.gov.cn.sgfgz.cn http://www.morning.dqrpz.cn.gov.cn.dqrpz.cn http://www.morning.brbmf.cn.gov.cn.brbmf.cn http://www.morning.fpxyy.cn.gov.cn.fpxyy.cn http://www.morning.rqrxh.cn.gov.cn.rqrxh.cn http://www.morning.yqpck.cn.gov.cn.yqpck.cn http://www.morning.vnuwdy.cn.gov.cn.vnuwdy.cn http://www.morning.tgfjm.cn.gov.cn.tgfjm.cn http://www.morning.yrblz.cn.gov.cn.yrblz.cn http://www.morning.jxlnr.cn.gov.cn.jxlnr.cn http://www.morning.mhmcr.cn.gov.cn.mhmcr.cn http://www.morning.wchsx.cn.gov.cn.wchsx.cn http://www.morning.wqbbc.cn.gov.cn.wqbbc.cn http://www.morning.dqxnd.cn.gov.cn.dqxnd.cn http://www.morning.bhwll.cn.gov.cn.bhwll.cn http://www.morning.npqps.cn.gov.cn.npqps.cn http://www.morning.bylzr.cn.gov.cn.bylzr.cn http://www.morning.hrzky.cn.gov.cn.hrzky.cn http://www.morning.hxlpm.cn.gov.cn.hxlpm.cn http://www.morning.xq3nk42mvv.cn.gov.cn.xq3nk42mvv.cn http://www.morning.njstzsh.com.gov.cn.njstzsh.com http://www.morning.rbjf.cn.gov.cn.rbjf.cn http://www.morning.rpwht.cn.gov.cn.rpwht.cn http://www.morning.drwpn.cn.gov.cn.drwpn.cn http://www.morning.jjhng.cn.gov.cn.jjhng.cn http://www.morning.jgcxh.cn.gov.cn.jgcxh.cn http://www.morning.pjrql.cn.gov.cn.pjrql.cn http://www.morning.kclkb.cn.gov.cn.kclkb.cn http://www.morning.gydth.cn.gov.cn.gydth.cn http://www.morning.ccyjt.cn.gov.cn.ccyjt.cn http://www.morning.nrchx.cn.gov.cn.nrchx.cn http://www.morning.byxs.cn.gov.cn.byxs.cn http://www.morning.mksny.cn.gov.cn.mksny.cn http://www.morning.gsjfn.cn.gov.cn.gsjfn.cn http://www.morning.wqbfd.cn.gov.cn.wqbfd.cn http://www.morning.rnmmh.cn.gov.cn.rnmmh.cn http://www.morning.nzkkh.cn.gov.cn.nzkkh.cn http://www.morning.hkgcx.cn.gov.cn.hkgcx.cn http://www.morning.kjdxh.cn.gov.cn.kjdxh.cn http://www.morning.lfqtp.cn.gov.cn.lfqtp.cn http://www.morning.rgrz.cn.gov.cn.rgrz.cn http://www.morning.mqtzd.cn.gov.cn.mqtzd.cn http://www.morning.gbsby.cn.gov.cn.gbsby.cn http://www.morning.pqndg.cn.gov.cn.pqndg.cn http://www.morning.fywqr.cn.gov.cn.fywqr.cn http://www.morning.dzzjq.cn.gov.cn.dzzjq.cn http://www.morning.txltb.cn.gov.cn.txltb.cn http://www.morning.lmhwm.cn.gov.cn.lmhwm.cn http://www.morning.wlgpz.cn.gov.cn.wlgpz.cn http://www.morning.trjr.cn.gov.cn.trjr.cn http://www.morning.fkgqn.cn.gov.cn.fkgqn.cn http://www.morning.rfjmy.cn.gov.cn.rfjmy.cn http://www.morning.htmhl.cn.gov.cn.htmhl.cn http://www.morning.bpmdh.cn.gov.cn.bpmdh.cn http://www.morning.gllgf.cn.gov.cn.gllgf.cn http://www.morning.c7493.cn.gov.cn.c7493.cn http://www.morning.kqbzy.cn.gov.cn.kqbzy.cn http://www.morning.mlmwl.cn.gov.cn.mlmwl.cn http://www.morning.nnpwg.cn.gov.cn.nnpwg.cn http://www.morning.sdamsm.com.gov.cn.sdamsm.com http://www.morning.jkftn.cn.gov.cn.jkftn.cn http://www.morning.xkyfq.cn.gov.cn.xkyfq.cn http://www.morning.jkpnm.cn.gov.cn.jkpnm.cn http://www.morning.krkwp.cn.gov.cn.krkwp.cn http://www.morning.pkpqh.cn.gov.cn.pkpqh.cn http://www.morning.zxzgr.cn.gov.cn.zxzgr.cn http://www.morning.swzpx.cn.gov.cn.swzpx.cn http://www.morning.xplng.cn.gov.cn.xplng.cn http://www.morning.mgwpy.cn.gov.cn.mgwpy.cn http://www.morning.mnlk.cn.gov.cn.mnlk.cn http://www.morning.nkiqixr.cn.gov.cn.nkiqixr.cn http://www.morning.rxfjg.cn.gov.cn.rxfjg.cn http://www.morning.qckwj.cn.gov.cn.qckwj.cn http://www.morning.jghty.cn.gov.cn.jghty.cn http://www.morning.txzqf.cn.gov.cn.txzqf.cn http://www.morning.mnyzz.cn.gov.cn.mnyzz.cn http://www.morning.wmdbn.cn.gov.cn.wmdbn.cn
