通过阅读该文章，你可以学到

HTTP的传输原理

HTTP的首部

HTTPS的原理

HTTP的传输原理

HTTP想要发送一条报文的时候，需要经过以下两个步骤：

TCP三次握手建立起连接管道，HTTP报文会以流的形式通过该管道按顺序传输；
TCP会将这些数据分别切割成数据块，并且封装在IP分组中，通过IP去传输；

使用TCP作为传输层：

传输可靠
有序

一个典型的HTTP请求过程如下图所示：

HTTP协议首部

标准的HTTP协议共有GET、POST、PUT、DELETE、PATCH、HEAD、OPTIONS、TRACE。

GET

无副作用
可被缓存
请求参数附带在query中
POST
有副作用
不可被缓存
请求参数在body中

HEAD

只会传输HTTP首部

OPTIONS

嗅探请求，用于判断服务器支持的方法

从字面上理解GET、POST，一个是获取，一个是发送，所以一般情况下我们在想读取一个服务器资源的时候我们会用GET请求，当需要修改服务器数据的时候，用POST提交操作。
我们来看一个典型的GET协议，

我们来看里面几个重要字段：

Connection

在http1.0中一个http在传输完成之后就会断开tcp链接，受到tcp慢启动的特点，每次建立http都会消耗大量的时间，所以各个浏览器定义了一个不标准的协议叫keep-alive，当然在http1.1中已经默认开启keep-alive，标识该请求在结束之后不会被断开，也就是下一个请求可以不用进行DNS查询，TCP三次握手，直接利用上一个通道进行传输。

上面两张图是我抓的天猫的两个接口请求，可以看到，在第二个请求比第一个请求中少了DNS Lookup、Initial connection与SSL的过程，提升了差不多100ms左右的时间，性能提升非常明显。
值得注意的是，因为keep-alive会复用一个tcp通道进行数据传输，怎样知道一个数据传输完成了呢，这就必须用到Content-length，通过该属性客户端可以知道一个资源在什么时候结束。

Cache-Control

上面的keep-alive对请求中的链路做了优化，在浏览器还有一个非常重要的字段，Cache-control，该消息头被用于在http 请求和响应中通过指定指令来实现缓存机制。
在response中服务器可以通过max-age=x指定该资源的过期时间，标识在x秒之后同样的请求直接走客户端缓存逻辑。

当然客户端可以通过加入cache-control：no-cache去强制强求服务器资源。

上图是浏览器的一些操作对缓存的影响，实际原理就是强制修改request头去影响缓存，具体每个浏览器实现不一样，这里给出的是chrome浏览器的操作影响。

协商缓存

当客户端的cache-control过期了怎么办，是否必须向服务器请求资源呢？
HTTP的设计者们当然没有那么傻，这个时候就要用到协商缓存了。

Last-Modified

在服务端第一次返回资源的时候，如果带上一个last-modified参数，也就是告知客户端，这个资源在这个时间我更新过了，下次你记得给我带过来，我验证一下在这个时间之后是否有被更新过，如果没有，那就返回304，你客户端直接取本地缓存即可，如果有更新，那会返回200，并且附上最新的last-modified值。

Etag

用Last-Modified有个问题，比如说我在一秒钟更新了多次资源，那这个资源只要第一次被缓存了，1秒钟更新再多次请求的时候还是会返回304。另外有些文件会被定时touch，这个时候文件内容可能没有变化，但是也会返回200。针对以上问题，出现了Etag，在第一次Response的时候，服务端会返回一个Etag，一般Etag是根据文件散列计算出来的，所以只要文件内容没变，该Etag也唯一，这样客户端下次请求的时候带上上次服务器返回的Etag给服务器校验，如果两次一样，服务器就会返回304。

encoding

客户端通过Accept-Encoding字段告知服务器支持哪些压缩算法，服务器收到后会选出一个最优算法对数据进行压缩，然后通过Content-Encoding返回给客户端，告知客户端去调用相关的算法进行解压。

用户状态追踪器，一般在浏览一个网站的时候，该网站都会通过set-cookie植入一个sessionId在我们的cookie中来标识用户身份。因为cookie会自动附带在同域或者子域的请求上，通过cookie，广告联盟可以在任何站点嵌入一个iframe页，植入广告，这就是为什么我们在上网的时候经常看到在某度、某东搜索的信息，当然我们可以打开浏览器的隐私模式来避免信息被盗取与滥用。

HTTPS

为什么要进行升级HTTPS？

在互联网出现之前，如果远在天边的两个人想要联系只能通过写信。让我们看一下在中国的A要寄一封信给美国的B要经过哪些步骤。
A->中国邮局->邮递员A.....->邮递员Z->美国邮局->B
可以看到中间经过了很多链路，在每个环节都可以被任意偷窥甚至篡改，那么信件到了B很可能就不是A的信了。
同样在HTTP传输的过程中，我们可以把运营商类比为邮局，路由类比为邮递员，因为HTTP在网络上是明文传输，可以被任何偷窥修改，典型的运营商劫持就是通过这种手段去操作的。
为了偷窥的问题，A跟B事先约定了一个办法，A给了B一个密码本，每个单词字母都用对应的密码表示，每次A按照密码本写信，B收到后再通过密码本解密，这样在传输的过程中只要保证密码本不落入他人手里，其他人就没法看得懂这封信了，这就是对称加密。这样看起来不错，但是有个非常严重的问题，A的密码本怎么给到B，如果还是通过邮寄的方式，这样密码本被copy了，后面的所有的加密也是白瞎。
为了解决这种问题，B放出了一个公开的密码本，说所有跟我通信的人都按照这个密码本的方式去加密，但是因为不是一一映射的关系，所以A加完密后连A自己都无法解密，但是B自己有密钥，通过该密钥可以解密信件。
这样看起来解决了被偷窥的问题了，但是有一天B收到了一峰信件，发现用自己的密钥解密后看不懂信件的内容，跟A沟通后，发现信件被篡改了。
为了解决这个问题，A每次寄信的时候都会按上自己的指纹，B收到信后首先确定这个指纹是不是A，然后再决定是否去解密，这样问题差不多就解决了。

HTTPS的原理

HTTPS缺点

慢，初次建立SSL连接，算法复杂，消耗资源
贵，需要每年交一定的费用给证书颁发机构