HTTPS 请求的大概过程及其工作原理

HTTPS 是对 HTTP 协议的扩展，我们可以使用它在互联网上安全地传输数据³，然而 HTTPS 请求的发起方第一次从接收方获取响应需要经过 4.5 倍的往返延迟（Round-Trip Time，RTT）。本文将详细介绍请求发起和响应的过程，分析为什么 HTTPS 协议需要通过 4.5-RTT 的时间获得服务提供方的响应：

• TCP 协议 — 通信双方通过三次握手建立 TCP 连接⁴；
• TLS 协议 — 通信双方通过四次握手建立 TLS 连接⁵；
• HTTP 协议 — 客户端向服务端发送请求，服务端发回响应；

这里的分析建立在特定版本的协议实现以及常见场景上，随着网络技术的发展，我们能够减少需要的网络通信次数，本文会在对应章节中提到一些常见的优化方案

TCP 三次握手

1. 客户端向服务端发送带有 SYN 的数据段以及客户端开始发送数据段（Segment）的初始序列号 SEQ = 100；
2. 服务端收到数据段时，向客户端发送带有 SYN 和 ACK 的数据段；
   1. 通过返回 ACK = 101 确认客户端数据段的初始序列号；
   2. 通过发送 SEQ = 300 通知客户端，服务端开始发送数据段的初始序列号；
3. 客户端向服务端发送带有 ACK 的数据段，确认服务端的初始序列号，其中包含 ACK = 301；

TLS 的作用是在可靠的 TCP 协议上构建安全的传输通道，其本身是不提供可靠性保障的，我们还是需要下层可靠的传输层协议。在通信双方建立可靠的 TCP 连接之后，我们就需要通过 TLS 握手交换双方的密钥了，在这里我们将介绍 TLS 1.2 的连接建立过程：

 TLS 1.2 建立连接

1. 客户端向服务端发送 Client Hello 消息，其中携带客户端支持的协议版本、加密算法、压缩算法以及客户端生成的随机数；
2. 服务端收到客户端支持的协议版本、加密算法等信息后；
   1. 向客户端发送 Server Hello 消息，并携带选择特定的协议版本、加密方法、会话 ID 以及服务端生成的随机数；
   2. 向客户端发送 Certificate 消息，即服务端的证书链，其中包含证书支持的域名、发行方和有效期等信息；
   3. 向客户端发送 Server Key Exchange 消息，传递公钥以及签名等信息；
   4. 向客户端发送可选的消息 CertificateRequest，验证客户端的证书；
   5. 向客户端发送 Server Hello Done 消息，通知服务端已经发送了全部的相关信息；
3. 客户端收到服务端的协议版本、加密方法、会话 ID 以及证书等信息后，验证服务端的证书；
   1. 向服务端发送 Client Key Exchange 消息，包含使用服务端公钥加密后的随机字符串，即预主密钥（Pre Master Secret）；
   2. 向服务端发送 Change Cipher Spec 消息，通知服务端后面的数据段会加密传输；
   3. 向服务端发送 Finished 消息，其中包含加密后的握手信息；
4. 服务端收到 Change Cipher Spec 和 Finished 消息后；
   1. 向客户端发送 Change Cipher Spec 消息，通知客户端后面的数据段会加密传输；
   2. 向客户端发送 Finished 消息，验证客户端的 Finished 消息并完成 TLS 握手；

TLS 握手的关键在于利用通信双方生成的随机字符串和服务端的公钥生成一个双方经过协商后的密钥，通信的双方可以使用这个对称的密钥加密消息防止中间人的监听和攻击，保证通信的安全。

在 TLS 1.2 中，我们需要 2-RTT 才能建立 TLS 连接¹⁰，但是 TLS 1.3 通过优化协议，将两次往返延迟降低至一次，大幅度减少建立 TLS 连接所需要的时间，让客户端可以在 1-RTT 之后就能向服务端传输应用层数据。

这里就不展开介绍 TLS 1.3 建立连接的过程了，除了减少常规握手下的网络开销，TLS 1.3 还引入了 0-RTT 的连接建立过程；60% 的网络连接都是用户在第一次访问网站或者间隔一段时间后访问时建立的，剩下的 40% 可以通过 TLS 1.3 的 0-RTT 策略解决¹¹，然而该策略与 TFO 的实现原理比较相似，都是通过重用会话和缓存来实现的，所以存在一定的安全风险，使用时也应该结合业务的具体场景。

HTTP

在已经建立好 TCP 和 TLS 通道上传输数据是比较简单的事情，HTTP 协议可以直接利用下层建立的可靠的、安全的通道传输数据。客户端通过 TCP 的套接字接口向服务端写入数据，服务端在接收到数据、进行处理后通过相同的途径返回。因为整个过程需要客户端发送请求以及服务端返回响应，所以耗时是 1-RTT。

HTTP 协议的数据交换只会消耗 1-RTT，当客户端和服务端仅处理一次 HTTP 请求时，从 HTTP 协议本身我们已经无法进行优化。不过随着请求的数量逐渐增加，HTTP/2 就可以复用已经建立的 TCP 连接减少 TCP 和 TLS 握手带来的额外开销。

总结

当客户端想要通过 HTTPS 请求访问服务端时，整个过程需要经过 7 次握手并消耗 9 倍的延迟。如果客户端和服务端因为物理距离上的限制，RTT 约为 40ms 时，第一次请求需要 ~180ms；不过如果我们想要访问美国的服务器，RTT 约为 200ms 时，这时 HTTPS 请求的耗时为 ~900ms，这就是一个比较高的耗时了。我们来总结一下 HTTPS 协议需要 9 倍时延才能完成通信的原因：

1. TCP 协议需要通过三次握手建立 TCP 连接保证通信的可靠性（1.5-RTT）；
2. TLS 协议会在 TCP 协议之上通过四次握手建立 TLS 连接保证通信的安全性（2-RTT）；
3. HTTP 协议会在 TCP 和 TLS 上通过一次往返发送请求并接收响应（1-RTT）；

需要注意的是，本文对往返延时的计算都基于特定的场景以及特定的协议版本，网络协议的版本在不断更新和演进，过去忽略的问题最开始都会通过补丁的方式更新，但是最后仍然会需要从底层完成重写。

HTTP/3 就是一个这样的例子，它会使用基于 UDP 的 QUIC 协议进行握手，将 TCP 和 TLS 的握手过程结合起来，把 7 次握手减少到了 3 次握手，直接建立了可靠并且安全的传输通道，将原本 ~900ms 的耗时降低至 ~500ms，我们会在后面的文章介绍 HTTP/3 协议相关的内容。到最后，我们还是来看一些比较开放的相关问题，有兴趣的读者可以仔细思考一下下面的问题：

• 作为传输层协议，QUIC 协议和 TCP 协议之间有什么异同？
• 为什么可以通过 0-RTT 建立客户端和服务端的连接？

如果对文章中的内容有疑问或者想要了解更多软件工程上一些设计决策背后的原因，可以在博客下面留言，作者会及时回复本文相关的疑问并选择其中合适的主题作为后续的内容。

参考资料

1. Walls, Colin (2005). Embedded Software: The Works. Newnes. p. 344. ISBN 0-7506-7954-9. Archived from the original on 2019-02-09. Retrieved 2018-10-20. https://books.google.com.hk/books?id=FLvsis4_QhEC&pg=PA344&redir_esc=y#v=onepage&q&f=false↩︎
2. What is an SSL Certificate? https://www.websecurity.digicert.com/security-topics/what-is-ssl-tls-https↩︎
3. Wikipedia: HTTPS https://en.wikipedia.org/wiki/HTTPS↩︎
4. RFC793 Transmission Control Protocol, September 1981 RFC793 https://tools.ietf.org/html/rfc793↩︎
5. RFC5246 The Transport Layer Security (TLS) Protocol. Version 1.2. Aug 2008 RFC5246 https://tools.ietf.org/html/rfc5246↩︎
6. 为什么 TCP 建立连接需要三次握手 https://draveness.me/whys-the-design-tcp-three-way-handshake↩︎
7. 为什么 TCP/IP 协议会拆分数据 https://draveness.me/whys-the-design-tcp-segment-ip-packet↩︎
8. Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, “TCP Fast Open”, RFC 7413, DOI 10.17487/RFC7413, December 2014, https://www.rfc-editor.org/info/rfc7413. ↩︎
9. The First Few Milliseconds of an TLS 1.2 Connection https://tlseminar.github.io/first-few-milliseconds/↩︎
10. TLS 1.3 Handshake: Taking a Closer Look https://www.thesslstore.com/blog/tls-1-3-handshake-tls-1-2/↩︎ 
11. Introducing Zero Round Trip Time Resumption (0-RTT) https://blog.cloudflare.com/introducing-0-rtt/ ↩︎