阅读 1643

你需要知道的HTTP常识

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

  • HTTP的传输原理
  • HTTP的首部
  • HTTPS的原理

HTTP的传输原理

Alt text
Alt text

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

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

使用TCP作为传输层:

  • 传输可靠
  • 有序

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

Alt text
Alt text

HTTP协议首部

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

GET

  • 无副作用
  • 可被缓存
  • 请求参数附带在query中

    POST

  • 有副作用
  • 不可被缓存
  • 请求参数在body中
  • 只会传输HTTP首部

OPTIONS

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

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

Alt text
Alt text

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

Connection

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

Alt text
Alt text

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

Cache-Control

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

Alt text
Alt text

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

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

协商缓存

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

Last-Modified

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

Alt text
Alt text

Etag

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

Alt text
Alt text

encoding

Alt text
Alt text

客户端通过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的原理

Alt text
Alt text

HTTPS缺点

  • 慢,初次建立SSL连接,算法复杂,消耗资源
  • 贵,需要每年交一定的费用给证书颁发机构
关注下面的标签,发现更多相似文章
评论