博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
你需要知道的HTTP常识
阅读量:6548 次
发布时间:2019-06-24

本文共 2782 字,大约阅读时间需要 9 分钟。

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

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

HTTP的传输原理

Alt text
HTTP想要发送一条报文的时候,需要经过以下两个步骤:
  • TCP三次握手建立起连接管道,HTTP报文会以流的形式通过该管道按顺序传输;
  • TCP会将这些数据分别切割成数据块,并且封装在IP分组中,通过IP去传输;

使用TCP作为传输层:

  • 传输可靠
  • 有序

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

Alt text

HTTP协议首部

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

GET

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

    POST

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

OPTIONS

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

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

我们来看一个典型的GET协议,

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

Connection

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

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
当然客户端可以通过加入
cache-control:no-cache去强制强求服务器资源。
Alt text
上图是浏览器的一些操作对缓存的影响,实际原理就是强制修改request头去影响缓存,具体每个浏览器实现不一样,这里给出的是chrome浏览器的操作影响。

协商缓存

当客户端的cache-control过期了怎么办,是否必须向服务器请求资源呢?

HTTP的设计者们当然没有那么傻,这个时候就要用到协商缓存了。

Last-Modified

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

Alt text

Etag

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

Alt text

encoding

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

HTTPS缺点

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

转载地址:http://degdo.baihongyu.com/

你可能感兴趣的文章
利用Simple-RTMP-Server(SRS)来进行直播
查看>>
[裴礼文数学分析中的典型问题与方法习题参考解答]5.1.13
查看>>
一个listener.ora配置细节的问题
查看>>
[转载]webarchive文件转换成htm文件
查看>>
家里蹲大学数学杂志期刊模式目录
查看>>
什么是 stack?- 每天5分钟玩转 Docker 容器技术(111)
查看>>
ConcurrentDictionary线程不安全么,你难道没疑惑,你难道弄懂了么?
查看>>
C# 利用BarcodeLib.dll生成条形码(一维,zxing,QrCodeNet/dll二维码)
查看>>
linux诡异的硬盘不足
查看>>
定时任务发展史(一)
查看>>
C语言 第六章 多重循环练习
查看>>
Attribute2Image --- Conditional Image Generation from Visual Attributes 论文笔记
查看>>
Linux卸载MySQL
查看>>
使用ash分析ORA-01652问题
查看>>
MongoDB 稀疏(间隙)索引(Sparse Indexes)
查看>>
windows 端口转发自带工具 配合n2n用(该工具在本地转发的端口只能在本地访问 ,这一点太不爽了,还是用https://boutell.com/rinetd/方便些)...
查看>>
linux命令之useradd
查看>>
gradle中使用cobertura做代码覆盖(转)
查看>>
java中文排序问题(转)
查看>>
mysql读注意事项
查看>>