一、Https握手过程

Https.png

图片的握手过程和文字并不是完全对应的，文字叙述的更具体一些。 图片仅供参考。

1. client_hello

   客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数，扩展字段等信息，相关信息如下：
   • 支持的最高TSL协议版本version，从低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，当前基本不再使用低于 TLSv1 的版本
   • 客户端支持的加密套件 cipher suites 列表， 每个加密套件对应前面 TLS 原理中的四个功能的组合：认证算法 Au (身份验证)、密钥交换算法 KeyExchange(密钥协商)、对称加密算法 Enc (信息加密)和信息摘要 Mac(完整性校验)
   • 支持的压缩算法 compression methods 列表，用于后续的信息压缩传输
   • 随机数 random_C，用于后续的密钥的生成
   • 扩展字段 extensions，支持协议与算法的相关参数以及其它辅助信息等，常见的 SNI 就属于扩展字段，后续单独讨论该字段作用

2. server_hello+server_certificate+sever_hello_done

   • server_hello, 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 等，其中随机数用于后续的密钥协商
   • server_certificates, 服务器端配置对应的证书链，用于身份验证与密钥交换
   • server_hello_done，通知客户端 server_hello 信息发送结束

3. 证书校验

   客户端验证证书的合法性，如果验证通过才会进行后续通信，否则根据错误情况不同做出提示和操作，合法性验证包括如下：
   • [证书链]的可信性 trusted certificate path，方法如前文所述
   • 证书是否吊销 revocation，有两类方式离线 CRL 与在线 OCSP，不同的客户端行为会不同
   • 有效期 expiry date，证书是否在有效时间范围
   • 域名 domain，核查证书域名是否与当前的访问域名匹配，匹配规则后续分析

4. client_key_exchange+change_cipher_spec+encrypted_handshake_message

   • client_key_exchange，合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器
   • 此时客户端已经获取全部的计算协商密钥需要的信息：两个明文随机数 random_C 和 random_S 与自己计算产生的 Pre-master，计算得到协商密钥
     enc_key=Fuc(random_C, random_S, Pre-Master)
   • change_cipher_spec，客户端通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信
   • encrypted_handshake_message，结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证

5. change_cipher_spec+encrypted_handshake_message

   • 服务器用私钥解密加密的 Pre-master 数据，基于之前交换的两个明文随机数 random_C 和 random_S，计算得到协商密钥:enc_key=Fuc(random_C, random_S, Pre-Master)
   • 计算之前所有接收信息的 hash 值，然后解密客户端发送的 encrypted_handshake_message，验证数据和密钥正确性
   • change_cipher_spec, 验证通过之后，服务器同样发送 change_cipher_spec 以告知客户端后续的通信都采用协商的密钥与算法进行加密通信
   • encrypted_handshake_message, 服务器也结合所有当前的通信参数信息生成一段数据并采用协商密钥 session secret 与算法加密并发送到客户端

6. 握手结束

   客户端计算所有接收信息的 hash 值，并采用协商密钥解密 encrypted_handshake_message，验证服务器发送的数据和密钥，验证通过则握手完成

7. 加密通信

   开始使用协商密钥与算法进行加密通信

8. 注意:

   • 服务器也可以要求验证客户端，即双向认证，可以在过程2要发送 client_certificate_request 信息，客户端在过程4中先发送 client_certificate与certificate_verify_message 信息，证书的验证方式基本相同，certificate_verify_message 是采用client的私钥加密的一段基于已经协商的通信信息得到数据，服务器可以采用对应的公钥解密并验证
   • 根据使用的密钥交换算法的不同，如 ECC 等，协商细节略有不同，总体相似
   • sever key exchange 的作用是 server certificate 没有携带足够的信息时，发送给客户端以计算 pre-master，如基于 DH 的证书，公钥不被证书中包含，需要单独发送
   • change cipher spec 实际可用于通知对端改版当前使用的加密通信方式，当前没有深入解析
   • alter message 用于指明在握手或通信过程中的状态改变或错误信息，一般告警信息触发条件是连接关闭，收到不合法的信息，信息解密失败，用户取消操作等，收到告警信息之后，通信会被断开或者由接收方决定是否断开连接

二、相关的一些名词解释

1. RTT(Round Trip Time)

   表示客户端从发出一个请求数据，到接收到响应数据之间间隔的时间

2. Pipiline

   HTTP 1.1 协议 中就把 Connection 的默认值改成了Keep-Alive，这样同一个域名下的多个 HTTP 请求就可以复用同一个 TCP 连接

3. 队头阻塞(Head of line blocking，下文简称 HOC)

   串行请求执行时，如果第一个请求不执行完，后续的请求也无法执行

4. SPDY

   基于TCP实现，采用多路复用技术
   SPDY 为各个数据包做好标记，指明他们属于哪个 HTTP 请求，至于这些包能不能到达客户端，SPDY 并不关心，因为数据可达性由 TCP 协议保证。既然客户端一定能收到包，那就只要排序、拼接就行了。

5. 多路复用(Multiplexing)

   允许多个 HTTP 请求共享同一个 TCP 连接. 这么做的代价是数据会略微有一些冗余，每一个资源的数据包都要带上标记，用来指明自己属于哪个资源，这样客户端最后才能把他们正确的拼接起来

6. TCP 窗口

   只要你还在用 TCP 链接，HOC就是逃不掉的噩梦，TCP。协议会保证数据的可达性，如果发生了丢包或者错包，数据就会被重传，会有重传就会有HOC问题。于是有了滑动窗口的概念。
   eg:
   如果TCP 窗口大小是 4，所以相当于一次发送4个包，4个包中只要有1个返回（文章里面说的是只要第四个包的ACK返回了，我理解的是其中一个返回就行），就可以确信是另三个 ACK 丢了而不是数据包丢了。因此发送方可以大胆的把窗口向后滑动四位。

7. QUIC

   基于 UDP 实现，由于UDP协议和TCP协议不同，只负责发送数据，并不保证数据可达性。所以QUIC 协议需要自己保证数据可达性。

8. 前向恢复(FEC: Fowrard Error Correcting):

   利用已有数据就能进行错误恢复的技术
   使用异或: a ^ a = 0 a ^ 0 = a

   假设初始状态:
   A1 ^ A2 ^ A3 ^ ... ^ An = T

   (A1 ^ A1) ^ A2 ^ A3 ^ ... ^ An = T ^ A1

   A2 ^ A3 ^ ... ^ An = T ^ A1

   A3 ^ ... ^ An = T ^ A1 ^ A2

   Ai = T ^ A1 ^ A2 ^ ... Ai-1 ^ Ai+1 ^ Ai+2 ^ ... ^ An
   假设有5个数据包要发送，我可以额外发送一个包(上面例子中的T)，它的值是前五个包的异或结果。这样不管是前五个包中丢失了任何一个，或者某个包数据有错(可以当成丢包来处理)，都可以用另外四个包和这个冗余的包T进行异或运算，从而恢复出来。
   当然要注意的是，这种方案仅仅在只发生一个错包或丢包时有效，如果丢失两个包就无能为力了(这也就是为什么只发一个冗余包就够的原因)。因此数据包和冗余包之间的比值需要精心设计，如果比值过高，很容易出现丢两个包的情况，如果比值过低，又会导致冗余度太高，需要设计者根据概率计算结果进行权衡。