，我们之前有提到过CDN的知识，也分析过通过抓包建立TCP连接的过程。今天来聊聊应用层协议HTTP/HTTPS；这是应用工程师在日常生活中接触时间最长的协议。但是你真的了解他吗？今天我们不讲HTTP协议的几种请求方式，主要介绍HTTP和HTTPS发送数据的整个过程。消息结构大家还记得上面提到的DNS流程吗？我们通过DNS获取到服务器的IP地址，然后通过TCP协议完成浏览器与应用服务器的连接。HTTP协议建立在TCP协议之上（上层协议必须依赖于下层协议）。建立连接后，自然而然的就开始通信了。那么通信的格式是什么？看上图，HTTP请求和响应格式基本一致。我们分开说吧。对于请求报文，由三部分组成：请求行、请求头、请求体；所谓请求行就是POST/HTTP/1.1的内容。接下来就是请求头，也就是我们常说的HTTP头；那么紧跟在换行符之后的内容就是请求体，也就是发送给应用程序的参数。对于响应消息，也是由三部分组成：状态行、响应头、响应体；响应行是标记本次请求的结果是什么，这里主要是：20X,30X,40X,50X这几个范围状态码需要记忆。响应头中重要的东西主要是缓存相关的东西。这部分内容会知道浏览器、CDN等缓存的缓存行为。你需要有一定的了解；最终的实体就是你的请求想要的结构，比如：HTML,Json等。传输流程消息构造完成后，如何发送进行传输呢？上图中我们看到的是字符串内容。HTTP本身不能进行网络传输。它必须依赖底层TCP协议建立的连接来发送数据。因此，它实际上是将这些构造好的字符串传输给底层的TCP。至于TCP是如何传输的，可以看之前的文章，这里不再展开。WebService收到数据后，会对数据进行处理，然后交给应用服务器。应用服务器自然会将请求的Body作为输入，然后根据要求生成输出。输出行为由请求头中的一些信息控制，例如：格式（Content-Type）、编码（Accept-Charset）等。生成的输出也会根据响应头进行处理。看到这里，是不是发现了几个问题：HTTP依赖底层的TCP连接，即每次HTTP都需要三次握手，效率会不会很慢？这种方式总是需要浏览器发起一个链接，而服务器是无力主动推送东西的；针对以上问题，HTTP2.0协议诞生了。当然，上述问题在HTTP1.1时代也有一些解决方案。HTTP2.0主要解决协议头压缩问题，传输同义内容，占用带宽更少，速度更快；将上述单向链接方式改为二进制流方式，服务端具备主动推送数据的能力；一条链路支持多个数据流的传输。关于HTTP2.0的内容不是正文主要想说的，大家可以自行了解。接下来是核心部分，解释为什么HTTPS是安全的以及它是如何加密的。这部分内容是面试的重要考点。HTTPS为什么可靠现在各大网站大多都使用HTTPS协议，那么它和HTTP有什么关系呢？它实际上是HTTP加上一个TLS（SSL）安全层，合起来称为HTTPS。为什么用这一层处理数据是安全的？很简单，要想安全就得加密。现在加密的方式无非就是：对称加密和非对称加密。对称加密：加密和解密使用同一个密钥，所以用这种方式加密数据时密钥不能丢失。非对称加密：有两个密钥，私钥和公钥。用私钥加密的数据必须用公钥解密，反之亦然。安全的代价看起来非对称加密是非常安全的。但是，对称加密的效率非常高。HTTPS结合使用这两种加密方式，使得整个传输过程是安全的。让我们看看这个过程是如何完成的。我们先来看看对称加密。如果HTTPS只使用对称加密，是否能满足安全需求？由于本例中只有一个密钥，那么服务器如何将密钥交给客户端呢？在线传输肯定会泄漏。因此，单靠对称加密是无法满足需求的。看来得换个方式了。非对称加密使用非对称加密的私钥来加密数据并将其发送给客户端。客户端使用公钥解密数据。看起来没什么问题。但是这里有个问题，因为服务器发送的数据是用的私钥，而公钥既然是公开的，这就相当于没有加密。每个人都可以看到它。而服务器发送公钥的过程也可能被篡改。你怎么知道你收到的公钥是服务器给你的呢？就像现在很多骗子公司一样，表面上看起来不错，但实际上是一个钱包公司。为了解决上述问题，出现了所谓的CA组织。它如何解决这个信任问题？它将服务器的公钥放在CA证书中，传给客户端（这里指浏览器），浏览器获取。最后验证证书是否真实有效，因为CA组织是有限的，是可追溯的。就像你的护照一样，你可以辨别真伪，所以CA证书证明是有效的，CA证书中携带的公钥自然就证明了你的身份。整个过程是不是好像很麻烦？没有办法安全，这个代价是值得的。这就是为什么我们常说HTTPS的效率略低于HTTP的原因。工作模式了解了以上知识后，我们来看看HTTPS是如何工作的。客户端发起https请求，包括版本信息、密码套件候选列表、压缩算法候选列表、随机数random_c、扩展字段等信息。这个过程现在是明确的。然后服务器会回复。服务端会根据客户端支持的算法信息和套件，选择一个告诉客户端，我们就用这个吧，同时还会返回一个随机数random_s，对后面协商密钥很有用。服务器通过指向用于密钥交换的证书的链接来响应客户端。客户端查看接收到的数据，先拉下证书，再查看各项指标。如果不合法，它会看到浏览器提醒它不安全。如果验证通过，会生成一个随机数Pre-master，用证书公钥加密（非对称加密），发送给服务器。此时客户端已经有了生成证书的所有内容，它会计算出协商密钥（对称密钥），然后告诉服务器以后使用协商的通信密钥和加密算法进行加密通信。然后，会用协商好的密钥加密一段数据，发送给服务器看是否正常。在上面的步骤中，客户端发送了三个请求。服务器首先用自己的私钥对收到的Pre-master进行解密。然后使用对称加密验证客户端发送的数据。如果通过，它还会通知客户端，后续通信将使用协商好的密钥和算法进行加密通信。并且服务端也会使用对称加密生成一段加密信息给客户端，供客户端试用（对称密钥）。客户端使用对称密钥正确完成解密。握手结束。开始使用对称密钥进行数据传输。总结为了不让文章看起来太复杂，我只介绍了最简单的单向认证。这种安全感不是最高的，在日常生活中足够了。本文从源头上讲为什么只有对称加密不能解决这个问题；一步步演进HTTPS的全过程。第一，为了效率，全程只使用一次非对称加密对Pre-master进行加密；第二，客户端和服务端分别使用一次对称加密来验证密钥的有效性，防止中间人攻击。最后，说一下为什么整个过程需要CA机构的参与。
