搞懂HTTP、HTTPS协议

TCP

基本概念

三次握手与四次挥手

TIME_WAIT

TCP 四次握手结束后，连接双方都不再交换消息，但主动关闭的一方保持这个连接在一段时间内不可用。为什么呢？

假设A、B来代指 TCP 连接的两端，A 为主动关闭的一端，通过以下两种情况分析：

• 四次挥手中，A 发 FIN， B 响应 ACK，B 再发 FIN，A 响应 ACK 实现连接的关闭。而如果 A 响应的 ACK 包丢失，B 会以为 A 没有收到自己的关闭请求，然后会重试向 A 再发 FIN 包。如果没有 TIME_WAIT 状态，A 不再保存这个连接的信息，收到一个不存在的连接的包，A 会响应 RST 包，导致 B 端异常响应。此时， TIME_WAIT 是为了保证全双工的 TCP 连接正常终止
• 如果没有TIME_WAIT的存在，或者说停留在TIME_WAIT上的时间很短，则主动关闭的一方很快就进入了CLOSED状态。如果此时新建一个连接，源随机端口如果被复用，在connect发送SYN包后，由于被动方仍认为这条连接【五元组】还在等待ACK，但是却收到了SYN，则被动方会回复RST，造成主动创建连接的一方由于收到了RST，连接无法成功
• TCP 下的 IP 层协议是无法保证包传输的先后顺序的。如果双方挥手之后，一个网络四元组（src/dst ip/port）被回收，而此时网络中还有一个迟到的数据包没有被 B 接收，A 应用程序又立刻使用了同样的四元组再创建了一个新的连接后，这个迟到的数据包才到达 B，那么这个数据包就会让 B 以为是 A 刚发过来的。此时， TIME_WAIT 的存在是为了保证网络中迷失的数据包正常过期

结合以上三种情况，TIME_WAIT 状态的保持时长为2MSL也就可以理解了。MSL（Maximum Segment Lifetime），最大分段寿命，它表示一个 TCP 分段可以存在于互联网系统中的最大时间，由 TCP 的实现，超出这个寿命的分片都会被丢弃。一来一去两个来回即2MSL，RFC里建议的MSL其实是2分钟，但是很多实现都是30秒，可以通过 /proc/sys/net/ipv4/tcp_fin_timeout 这个文件查看和修改这个值。

参考：

• TCP的三次握手与四次挥手理解及面试题

HTTP和HTTPS协议

发展历史

HTTP/1.1和HTTP/2比对

多路复用：通过单一的HTTP/2连接请求发起多重的请求-响应消息，多个请求stream共享一个TCP连接，实现多留并行而不是依赖建立多个TCP连接

HTTP和HTTPS比对

HTTP特点：

• 无状态：协议对客户端没有状态存储，对事物处理没有“记忆”能力，比如访问一个网站需要反复进行登录操作（通过Cookie/Session技术解决）
• 无连接：HTTP/1.1之前，由于无状态特点，每次请求需要通过TCP三次握手四次挥手，和服务器重新建立连接（HTTP/1.1提供HTTP keep-alive机制）
• 基于请求和响应：基本的特性，由客户端发起请求，服务端响应
• 简单快速、灵活
• 通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性

HTTPS特点：

基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护，整个过程如下：

• client向server的443端口发送消息，主要包含随机值1和客户端支持的加密算法
• server接收到信息之后给予client响应握手信息，包括随机值2和匹配好的协商加密算法
• 随即server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面，这套证书其实就是一对公钥和私钥。传送证书，这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构、过期时间、服务端的公钥、第三方证书认证机构(CA)的签名、服务端的域名信息等内容
• 客户端解析证书，这部分工作是由客户端的TLS来完成的，首先会验证公钥是否有效（通过客户端内置的CA公钥解密数字签名得到摘要信息对比验证），比如颁发机构、过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。如果证书没有问题，那么就生成一个随即值（预主秘钥）
• 客户端认证证书通过之后，接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥，然后通过证书的公钥加密会话秘钥（非对称加密）
• 传送加密信息，这部分传送的是用证书公钥加密后的会话秘钥，目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥
• 服务端解密得到随机值1、随机值2和预主秘钥，然后组装会话秘钥，跟客户端会话秘钥相同（对称加密）
• 客户端通过会话秘钥加密一条消息发送给服务端，主要验证服务端是否正常接受客户端加密的消息
• 同样服务端也会通过会话秘钥加密一条消息回传给客户端，如果客户端能够正常接受的话表明SSL层连接建立完成了

HTTPS安全策略：

• 混合加密：结合非对称加密和对称加密技术。客户端使用对称加密生成会话密钥对传输数据进行加密，然后使用非对称加密的公钥再对秘钥进行加密。所以网络上传输的数据是被对称加密秘钥加密的密文和用非对称加密公钥加密后的秘密秘钥。因此即使被黑客截取，由于没有私钥，无法获取到加密明文的秘钥，便无法获取到明文数据
• 数字摘要：通过单向hash函数对原文进行哈希，将需加密的明文“摘要”成一串固定长度(如128bit)的密文，不同的明文摘要成的密文其结果总是不相同，同样的明文其摘要必定一致，并且即使知道了摘要也不能反推出明文
• 数字签名技术：数字签名建立在公钥加密体制基础上，是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来，形成了实用的数字签名技术

如何确保证书的安全性？

• 当客户端收到这个证书之后，使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名，数字签名经过CA公钥解密得到证书信息摘要
• 然后计算一下当前证书的信息摘要，与收到的信息摘要作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配

参考：

• 对称加密和非对称加密
• 漫画：什么是 HTTPS 协议？
• HTTP和HTTPS协议，看一篇就够了