如果我们要看新闻，假设访问这个网址：http://www.163.com，http://www.163.com是个URL，叫做统一资源定位符。之所以叫统一，是因为它是有格式的。
HTTP称为协议，www.163.com是一个域名，表示互联网上的一个位置。正是因为这个东西是统一的，所以当我们使用浏览器访问的时候，浏览器才知道如何进行统一处理。
HTTP请求的准备
浏览器会将ww.163.com这个域名发送给DNS服务器，让它解析为IP地址，由于HTTP是基于TCP的，所以会先建立TCP连接。目前使用的HTTP协议大部分都是1.1的，在1.1的协议里面，默认是开启了Keep-Alive的，这样建立的TCP连接，就可以在多次请求中复用。
HTTP请求的构建
建立了连接以后，浏览器就要发送HTTP的请求了，
HTTP请求的格式：
HTTP的报文大概分为三大部分：请求行，请求头，请求体。
第一部分：请求行：
在请求行中，URL就是http://www.163.com，版本为1.1，方法有好几种：
对于访问网页来说，最常用的类型就是GET。GET就是去服务器获取一些资源。
还有一种是POST，它需要主动告诉服务器一些信息，这些信息一般放在正文里面，正文里面可以有各种各样的格式，最常见的是JSON格式的。
还有一种是[UT，就是向指定资源位置上传最新内容。
在实际使用过程中，POST往往是用来创建一个资源的，PUT往往是用来修改资源的。
还有一个常见的就是DELETE，用来删除资源的。
第二部分：首部字段：
首部是key：value的形式，这里面往往保存了一些非常重要的字段。
如：
Accpte-Charset：表示客户端可以接受的字符量。防止传过来的是另外的字符集，从而导致乱码。
Content-Type：是指正文格式，如果我们进行POST请求，正文的格式是JSON，那么我们就应该把这个值设为JSON。
对于高并发场景下的系统，在真正的业务逻辑之前，都需要有个接入层，将这些静态资源的请求拦在最外面。
这个架构的图就像这样：
对于静态资源，有Vanish缓存层。当缓存过期的时候，才会访问真正的Tomcat应用集群。
在HTTP头里面，Cache-Control时用来控制缓存的。当客户端发送的请求中包含max-age指令时，如果判断缓存层中，资源的缓存事件数值比指定时间的数据小，那么客户端就可以接受缓存的资源。当指定的max-age值为0，那么缓存层通常需要将请求转发给应用集群。
另外，If-Modified-Since也是一个关于缓存的。也就是说，如果服务器的资源在某个时间之后更新了，那么客户端就应该下载最新的资源；如果没有更新，服务端就会返回“304 Not Modified”的响应，那么客户端就不用下载了，也会节省带宽。
HTTP请求的发送
HTTP协议是基于TCP协议的，所以它使用面向连接的方法发送请求，通过stream二进制的方式传给对方。当然，到了TCP层，它会把二进制流变成一个报文段发送给服务器。
在发送每个报文段的时候，都需要对方有一个回应ACK，来保证报文可靠地到达了对方。如果没有回应，那么TCP这一层会进行重新传输，直到可以达到。同一个包有可能被传了好多次，但是HTTP这一层不需要知道这一点，因为是TCP在一层在埋头苦干。
TCP层发送每一个报文的时候，都需要加上自己的地址和目标地址，将这两个信息放到IP头里面，交给IP层传输。
IP层需要查看目标地址和自己是否在同一个局域网。如果是，就发送ARP协议来请求这个目标地址对应的MAC地址，然后将源MAC和目标MAC放入MAC头，发送出去即可。如果不在同一个局域网，就需要发送到网关，还需要发送ARP协议，来获取网关的MAC地址，然后将源MAC个网关的MAC放入MAC头，发送出去。
网关收到包发现MAC符合，取出目标IP地址，根据路由协议找到下一跳的路由器，获取下一跳路由器的MAC地址，将包发给下一跳路由器。
这样路由器一跳一跳终于到达目标的局域网。这个时候，最后一跳的路由器能够发现，目标地址就在自己的某一个出口的局域网上。于是，在这个局域网上发送ARP，获得这个目标地址的MAC地址，将包发出去。
目标的机器发现MAC地址符合，就将包收起来，发现IP地址符合，根据IP头中协议项，知道自己上一层是TCP协议，于是解析TCP头，里面有序列号，需要看一看这个序列包是不是我要的，如果是就放入缓存然后返回一个ACK，如果不是就丢弃。
TCP头里面还有端口号，HTTP的服务器正在监听这个端口号，于是目标机器自然之道是HTTP服务器这个进程想要这个包，于是将包发送给HTTP服务器。HTTP服务器的进程看到，原来这个请求是要访问一个网页，也是就把这个网页发送给客户端。
HTTP返回的构建
状态码会反应HTTP请求的结果，我们就喜欢看到的就是200，最不想见的就是404；
接下来是返回首部的key : value
在里面，Rety-After表示客户端应该在多长时间以后再尝试一下；
Content-Type表示返回的是HTML还是JSON。
构造好了返回HTTP报文，接下来就是把这个报文发送出去。还是叫给Socket去发送，还是交给TCP层，让TCP层将返回的HTML分成一个个小的端，并且保证每个段都可靠到达。
这些段加上TCP头后会交给IP层，把刚才发送的流程再走一遍。
当浏览器拿到了HTTP的报文，发送返回200，一切正常，于是就从正文中将HTML拿出来。
HTTP 2.0
HTTP 1.0在应用层以纯文本的形式进行通信。每次通信都要带完整的HTTP头，而且不考虑pipeline模式的话，每次的过程总是想上面描述的那样一去一回。这样在实时性，并发性都存在问题。
为了解决这些问题，HTTP 2.0会对HTTP的头进行一定的压缩，将原来每次都携带的大量key-value在两端建立一个索引表，对相同的头只发送索引表中的索引。
另外，在HTTP 2.0协议将一个TCP的连接中，切分成多个流，每个流都有自己的ID，而且流可以是客户端发送服务器，也可以是服务器发往客户端。它其实只是一个虚拟的通道。流是有优先级的。
HTTP 2.0还将所有的传输信息分割为更小的消息和帧，并对它们采用二进制格式编码。常见的帧有Header帧，用于传输Header内容，并且会开启一个新的流。再就是Data帧，用来传输正文实体。多个Data帧属于同一个流。
通过这两种机制，HTTP 2.0的客户端可以将多个请求分别到不同的流中，然后将请求内容拆成帧，进行二进制传输。这些真可以打散乱序发送，然后根据每个帧首部的流标识符重新组装，并且可以根据优先级，决定优先处理哪个流的数据。
举一个例子；
假设我们的一个页面要发送三个独立的请求，一个获取css，一个获取js，一个获取图片jpg。如果使用HTTP 1.0就是串行的，但是如果使用HTTP 2.0，就可以在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一对一对应。
HTTP 2.0其实是将三个请求变成三个流，将数据分成帧，乱序发送到一个TCP连接中。
HTTP 2.0成功解决了HTTP 1.1的对首阻塞问题，同时，也不需要通过HTTP 1.X的pipeline机制用多条TCP连接来实现并行请求与响应；减少了TCP连接数对服务器性能的影响，同时将页面的多个数据css，js，jpg等通过一个数据链接进行传输，能够加快页面组件的传输速度。
我们知道HTTP是不安全的，HTTPS是安全的。这个安全也就是加密。
加密分为两种：一种是对称加密，一种是非对称加密。
在对称加密算法中，加密和解密使用的迷药是相同的。也就是说，加密和解密使用的是同一个秘钥。因此，对称加密算法要保证秘钥的私密性，不能对外公开。
在非对称加入算法中，加密使用的密钥和解密使用的密钥是不相同的。一把是作为公开的公钥，另一把是作为谁不能给的私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。
假设我们点外卖的时候，客户端给外卖网站发送消息，用外卖网站的公钥加密，这个报文只能用私钥解密，所以其他人就算拿到了，也解不开。但是有一个问题就是黑客模拟发送“我要订外卖”这个过程，因为它也有外卖网站的公钥，为了解决这个问题，只有一对私钥公钥是不够，客户端也需要自己的公钥和私钥，并且客户端要把自己的公钥给外卖网站。
这样，客户端给外卖网站发送的时候，用的是外卖网站的公钥，而外卖网站给客户端发送消息的时候，使用客户端的公钥。这样就算客户端企图模拟客户端获取一些内容，由于它是没有私钥的，这些信息它还是打不开。
数字证书
不对称加密要如果将公钥给对方呢？一种是放在公网的地址上，让对方下载；另一种就是在建立连接的时候，传给对方。
这两种方法有相同的问题，那就是，作为一个普通的网民，怎么鉴定别人给你的公钥是对的呢？也有可能是有人冒充外卖网站，发给你一个公钥。
这个时候，就需要权威部门的介入了。这个权威部分办法的称为证书，这个证书里面有公钥，还有证书的所有者，证书的发布机构和证书的有效期。
生成证书需要发起一个证书请求，然后将这个请求发给同一个权威机构去认证，这个权威机构我们称为CA
证书请求可以通过这个命令生成：
openssl req -key cliu8siteprivate.key -new -out cliu8sitecertificate.req
将这个请求发送给权威机构，权威机构会给这个证书卡一个章，我们称为签名算法，那么怎么签名才能保证真的是权威机构签名呢？当然只有用掌握在权威机构手里的东西签名了才行，这就是CA的私钥。
签名算法的大概工作流程：一般是对信息做一个Hash计算，得到一个Hash值，这个过程是不可逆的，。在把信息发送出去时，把这个Hash值加密后，作为一个签名和信息一起发出去。
CA给外卖网站的公钥签名，就相当于给外卖网站背书，形成了外卖网站的证书
这样，我们会从外卖网站上得到有个公钥，只要得到VA的公钥，去解密外卖网站证书的签名，如果解密成功了，Hash也对的上，就说明这个外卖网站的公钥没有问题。
HTTPS 的工作模式
我们知道，非对称加密的性能上不如对称加密，那是否能将两者结合起来呢？例如，公钥私钥主要用于传输对称加密的密钥，而真正的双方大数据量的通信都是通过对称加密进行的。
当然是可以的，HTTPS协议的总体思路就是这样的。
当我们登录一个外卖网站的时候，由于是HTTPS，客户端会发送Client Hello消息到服务器，以明文传输TLS版本信息，加密套件候选列表，压缩算法候选列表等信息。另外，还有有一个随机数，在协商对称密钥的时候使用。
然后，外卖网站返回Server Hello消息，告诉客户端，服务器选择使用的版本协议，加密套件，压缩算法，还有一个随机数，用于后溪的密钥协商。
然后外卖网站会给一个服务器端的证书。然后我们从自己信任的CS仓库中，拿CA的证书里面的公钥去解密外卖网站的证书，如果能够成功，则说明外卖网站是可信的。在这个过程中，我们可能会不断的往上追溯CA，CA的CA等，知道一个授信的CA。
证书验证完毕后，觉得这个外卖网站可信，于是客户端计算产生随机数字Pre-master，发送Client Key Exchange，用证书中的公钥加密，再发送给服务器，服务器就可以通过私钥解密出来，
到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是自己的，对端的以及刚生产的Pre-master随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称加密密钥。
有了对称密钥，客户端就可以说“Change Sipher Spec，我们以后都采用协商的通信密钥和加密算法进行加密通信了。”
然后发送一个Excrypted Handshake Message，将已经商定好的参数等，采用协商密钥进行加密，发送给服务器用于数据与握手验证。
同样，服务器也可以发送Change Cipher Spec，说：“没问题，我们以后都采用协商的通信密钥和加密算法进行加密通信了”，并且也发送Excrypted Handshake Message的消息试试。当双方握手结束之后，就可以通过对称加密进行加密传输了。
这个过程除了加密解密之外，其他的过程和HTTP是一样的，过程也非常复杂。
上面的过程只包含了HTTPS的单向认证，即客户端验证服务端的证书，是大部分的场景，也可以在更加严格安全要求的情况下，启用双向认证，双方互相验证证书。