前端开发者应该知道的HTTP知识

99 阅读17分钟

1.HTTP的基本概念:

首先HTTP是什么:

HTTP就是超文本传输协议

超文本是什么:

  1. HTTP传输的内容就是超文本。
  2. 文本可以由文字,视频,图片组成而超文本里面写到了链接,可以从一个超文本跳到另外一个超文本。
  3. 而HTML就是最常见的超文本,里面就是又有文字又有画面

传输:

  1. 现在任何HTTP的传输都是双向的。
  2. 浏览器向服务器传递一个请求要获取数据,而服务器会携带数据传输给浏览器,浏览器再进行渲染。

协议:

对传输做一些行为规范和约束,同时又两个参与者

2.HTTP常见的状态码

image-20241219100605711转存失败,建议直接上传图片文件

  • 200代表成功
  • 300代表重定向,资源的位置可能发生了改变
  • 400代表请求的报文有错误,一般表现为没有这种url
  • 500代表服务器错误,一般传参传的有问题 就是会出现服务器错误

3.HTTP的常见字段

HOST:

客户端发送请求给服务器的域名:

host:www.A.com

Content-Length:

这个字段代表服务器传输过来的数据是多少字节,同时也可以表示服务器传输过来的数据的大小是多少

Connection:

  • 这个字段代表了让链接是否保持。
  • 我们都知道TCP要经过4次握手然后再进行断开链接,而如果我们将请求设置为keep-alive
  • 这个链接就不会断开就会一直存在,除非用户主动进行断开
  • 而链接之后每次请求就可以通过本次的链接来获取数据

Content-Encoding:

这代表了服务器传回的数据是什么格式的一般都是gzip

4.GET和POST的区别

GET

  1. GET的就是从服务器端获取数据,这个数据可以是图片,文本,视频,一般来说GET的参数位置一般都写在URL里面。
  2. 但是这样的缺点就是参数容易被截取不太安全,也就是quary传参,所以如果我们使用body传参会比较好一些。
  3. 同时url也设定了一定的长度

POST:

  1. 简单来理解就是对指定的资源发送给服务器端。
  2. post的数据一般来说会和报文body写在一起,通过TCP协议之后,以此来传递给服务器端。

GET 和 POST 方法都是安全和幂等的吗?

GET由于是向服务器获取数据,所以它每次都不会改变,所以它是幂等的。而且每次请求都不会改变服务器中的数据所以它是安全的

POST请求是向服务器发送请求,这就导致每次传递数据的时候,服务器都会在本地去开辟一块新的数据,这就会导致改变服务器的数据所以它是不安全的,所以它也不是幂等的。

但是根据不同的方法去发送请求也有可能导致相反的结果

GET进行增加和删除

POST进行数据查询

5.HTTP缓存机制

我们都知道,每次我们获取资源的时候都会给服务器端发请求来获取资源,但是如果网页内的请求比较多而且请求总是在时刻的发起就容易出现高并发的问题,同时如果服务器端出现问题,请求的内容也不一定能够拿得。所以就出现了缓存机制,对于一些重复性的请求,我们就可以把请求的资源存在本地。因此诞生了强缓存与协商缓存

强缓存:

在强缓存中,如果浏览器中缓存的资源没有过期,那么我们可以直接在强缓存中拿数据来用。

如何开启强缓存一般来说是基于两个响应头:

Expires:缓存在本地保存的绝对时间

cache-control:缓存在本地保存的相对时间

由于Cache-control的优先级一般来说是大于Expires,所以我们通常使用设置Cache-control。因为后者的设置更加的精密

请求过程:

1.浏览器发送请求给服务器

2.服务器返回资源并携带响应头Response(cache-control并设置好了过期的时间)

3.浏览器再次请求的时候服务器会根据传递过来的请求中查看并对比数据的资源与设置的Cache-control的时间是否过期,如果没有过期就直接使用本地的缓存的数据。

4.服务器再次返回并跟新response中Cache-control和设置新的过期时间

协商缓存:

协商缓存顾名思义就是协商能否使用缓存嘛,一般来说我们可以在返回的状态码中能看到304,这就是意思我们可以使用本地的缓存的意思。

这里需要注意的一个点就是:资源过期了,不代表它就消失了,资源还是存在的只是因为过期了强缓存不能够使用而已,所以要进行协商是否能够使用

请求过程:

在第一次请求中:

1.浏览器发送请求给服务器,服务器发送资源给浏览器并存储在本地

第二次请求中:

1.再次请求时使用本地资源发现资源已经过期,此时发送过去的请求中响应头里面携带Response(Etag)

2.比较本地的资源是否与传输过来的Etag是否一致

3.一致的时候就会返回304给浏览器代表可以使用本地已经过期的资源

协商缓存的响应头:

首先每次请求过程中都肯会带有强缓存的响应头Cache-control进行的。当发现无法使用强缓存的时候才会使用协商缓存。

  • 响应头部last-modifited:代表资源的最后修改时间
  • 请求头部的If-Modified-Since:当发送请求过去的时候,服务器端会更具If-Modified-Since与请求资源的最后时间进行比较,如果最后时间大,说明资源被修改过直接返回最新的资源,200.
  • 如果时间比较小,则直接返回304使用缓存资源

响应头部Etag:唯一表示响应资源

请求头部中的 If-None-Match:当发送请求给服务器的时候,浏览器会将If-None-Match中的值设置为Etag值,服务器通过比较Etag值和In-None-match中的值来判断资源是否有更新。如果更新返回200,没有返回304

通常来说我们会使用Etag的优先级要大于last-modified

1.因为Etag只需要去判断值是否对应就可以看出来数据是否发生过更新

2.如果使用后者的时间来算的话,精密程度最大也就只能到秒的级别,所以这种时候如果对于毫秒的请求过程中就会表现得比较弱势

3.有些服务器不能够获取最新的时间

6.HTTP的特性

1.简单

报文格式就是head+body,头部信息也是key-value的组合,易于理解

2.灵活易于扩展

  • URL,URI,状态码,头字段都没有被限制住可以自己自定义来玩
  • HTTPS就是再HTTP与TCP中间加了SSL安全传输层
  • HTTP1.0 2.0都是用TCP协议,HTTP3.0就是用UDP协议

3.HTTP/1.1的缺点有什么

1.无状态传输

  • 无状态的好处就是可以节省性能以此来对服务进行提升
  • 坏处就是没有记忆能力

就比如我们每次登录b战的时候,b战不会记住我们的登录状态这就导致我们每次访问的时候都需要登录很麻烦。

所以Cookie就诞生了!

Cookie就像一个小贴纸上面写着我们的登录信息,所以当我们访问网页的时候这个小贴纸就会带给服务器端,他记得看到我们就记得起来我们了所以就有登陆状态了

2.明文传输

相当于信息裸奔,抓包的时候能够直接看到你的信息的内容是什么

3.不安全

  • 明文也许会被监听
  • 会访问假的网站
  • 无法验证报文的完整性,可以再报文里面添加垃圾代码来导致崩溃

4.HTTP1.1的性能如何

长链接:

  • 防止每次请求的是时候会,都会重新建议一次TCP的三次握手这就导致非常的占用资源
  • 所以我们设置Connect:keep-live这样就可以使得出现长链接,就不用每次请求的时候都进行TCP的链接了,当用户主动中断的时候才会中断

管道网络传输:

  • 这个意思就是只要建立了一个传输的管道,那么久可以通过这个管道来进行发送请求。
  • 发一个 大家 一起用 而不是每个人发一个 每个人自己用,大大提升了效率
  • 但是服务器返回资源的时候就得按照发送的顺序来进行返回,这就出现了对头阻塞,如果返回的过程中,第一次返回阻塞了这就会* 致后续的都会阻塞*

5.HTTP与HTTPS

HTTPHTTPS
只有TCP的三次握手除了TCP的三次握手之外还有一层SSL安全协议握手
明文传输加密传输
端口:80端口443
需要向CA申请数字证书来证明服务器可信

HTTPS解决了HTTP的哪些问题:

1.窃取风险: 可以从链路上面获取资源

2.篡改风险: 在报文中添加而已代码

3.冒充风险: 会被植入冒充网站

SSL/TLS协议:

信息加密,校验机制,身份证书

解决方法:混合加密,摘要算法保持数据的完整性,数字证书里放公钥

1.混合加密

HTTPS通常使用的是 对称加密 和 非对称加密

对称加密: 使用相同的公钥和私钥进行加密,这使得加密和解密的过程的速度大大的提高,适合用于数据的传输

非对称加密: 会使用一对钥匙分别是公钥和私钥,公钥谁都可以拿来加密,但是只有拥有私钥的人才能解密。

握手阶段:

1.客户端发送请求,服务器返回证书

2.客户端验证证书是否合法

3.客户端使用服务器公钥加密一个会话密钥给服务器

4.服务器通过私钥解密来获得会话密钥

2.摘要算法+数字签名

1.当我们传递数据的时候,会在数据的内容中添加一个哈希值

2.服务器收到数据之后,会根据数据使用摘要算法解析出来一个哈希值

3.判断两个哈希值是否相同,相同则说明数据没有发生改变

哈希值唯一,哈希值无法逆向推断出代码内容

传输的过程中不能保证,内容+哈希值是否有没有被替换,因为缺少了客户端收到的数据是否来源于服务器端的证明

3.数字证书

就有点像是一个第三方的担保部门。传输过程需要得到第三方的认证才可以,同时第三方可以保证公钥私钥的安全性

传输过程

1.服务器将自己的公钥交给CA

2.CA用自己的私钥给公钥颁发数字证书给服务器 数字证书: 公钥+CA数字签名

3.客户端拿到数字证书之后,用他的公钥判断服务器的数字证书是否合法

4.获取服务器公钥加密传输数据给服务器

5.服务器根据自己的私钥来进行解密

HTTPS是如何建立连接的?交互了什么东西:

TLS的握手过程:

一CLIENTHello:

1.客户端发送加密通信请求:

TLS的协议版本

生成一个随机数发送

客户端支持的密码套件列表

二。ServeHello

服务器返回:

1,确认TLS的版本,浏览器不支持关闭链接

2.产生一个随机数

3.确认密码套件

4.返回服务器的数字证书

三。客户端回应

1.客户端根据CA证书中的公钥判断数字证书是否是合法的。

2.使用服务器中提供的公钥对数据进行加密生成会话密钥

3.发送如下信息:已给四技术,会话密钥,客户端握手结束的通知

四。服务器的回应

1.收到随机数后+协商算法,解密当下的会话密钥

向客户端发送:传递随后信息都用会话密钥的方式i传递,服务器端握手结束通知

客户端校验数字证书的流程是怎样的?

1.CA证书的签发过程:

首先会将持有者的公钥、作用、颁发者等信息打包成一个包然后生成一个hash值

然后CA用自己的私钥生成一个署名签名

最后将签名添加到文件的证书上面,形成数字证书

2.客户端校验服务端的数字证书的过程

首先使用同样的Hash算法拿到证书的Hash值1

然后再用CA的公钥解密那个签名拿到hash值2

如果hash1和hash2是相同的则说明是可以信任的

HTTPS的应用数据是如何保证完整性的?

TLS在实现上面分为握手协议记录协议两部分

  1. 握手协议就是TLS的四次握手过程用来生成密钥和保护应用程序
  2. 记录协议就是用来验证数据的完整性和来源

TLS记录协议主要负责消息的压缩,加密和数据的认证:

1.消息被分为多个消息片段

2.对消息片段进行压缩

3.给每个消息片段加上一个MAC的值

4.然后再一起进行加密成一种密文

5.最后加上版本号数据类型等压缩成报文数据

最后发送给TCP传输层进行传输

HTTPS一定可靠吗;

看似这个过程是合理的,中间人可以查看这个数据的内容是什么

但事实上这得基于客户端点击中间人的证书才可以。而非法的证书浏览器是可以识别出来的。

为什么抓包工具能截取 HTTPS 数据?

抓包工具胡子哎根部证书的列表中导入抓包工具生成的证书,相当于给自己颁发了一个浏览器可以信任的CA证书,而客户端拿着中间人签发的证书去认证就会被当作是有效的

如何避免被中间人抓取数据?

HTTPS双向验证

6.HTTP/1.1、Http/2、Http/3演变

HTTP/1.1 相比 HTTP/1.0 提高了什么性能?

1.使用了长连接,减少了短链接造成的开销

2.添加了管道通信,只要发送一个请求过去可以接着发送第二个不用等响应回来之后再发,防止对内阻塞。

3.性能评价:(1)容易发生队头阻塞,服务器响应慢的话会一直收不到数据

(2)首部无法被压缩,如果发了过多冗长的首部会导致造成浪费

(3)请求只能从客户端开始,服务端是被动的接收

HTTP/2 做了什么优化?

  • 头部压缩
  • 二进制格式
  • 并发传输
  • 服务器主动推送资源

1.头部压缩

发送多个请求如果头部是一样的那就会消除这个重复的部分

HPACK算法:服务器和客户端会公用一个表,所有字段都会存在这个表中,将信息压缩为一个带有索引号存入表中,下次如果取数据的话只需要使用索引即可

2.二进制格式

将传输的信息全部转化为二进制,使得计算机对于信息的解读更加的迅速。

3.并发传输

对头阻塞是因为当我们发送一个请求的时候如果服务器不处理,就会一直等待,直到处理完了我们才能够发送下一个请求。

所以HTTP2就诞生了一个Stream,这个就是可以通过一个TCP链接来发送多个请求

请求都用streamID来进行描述,由于每个请求都是独一无二的ID所以服务器可以用过ID来进行组装请求。同时StreamID也可以进行乱序的发送。

4。服务器推送

服务器可以像客户端去主动发送数据。

因为服务器也可以通过StreamID来进行发送数据给服务器,但是客户端发送的是奇数的,服务端发送的就是偶数的。

HTTP2的缺点有什么:

  1. 虽然HTTP2在发送请求上面解决了对头阻塞的问题,但是它在TCP链接上面的阻塞依然存在的。
  2. TCP是字节流,TCP要保证收到的字节是连续而且完整的才会把数据从缓冲区传输给客户端。
  3. 如果传输的前一个字节没有拿到的话,就会把收到的字节数据放在内核缓冲区里面
  4. 只有当这个一个字节到达的时候才会返回数据

HTTP/3 做了哪些优化?

HTTP3解决了HTTP1发送请求时候的队头阻塞的问题

解决了HTTP2的TCP链接的队头阻塞的问题,因此TCP就变成了UDP!

基于UDP的QUIC协议可以实现类似TCP的可靠性传输:

  • 无队头阻塞
  • 更快的建立链接
  • 链接迁移

1.无队头阻塞

如果其中一个流的包丢失了只会阻塞改流,不会影响其他流的传递

2.更快的链接建立

HTTP1和HTTP2这两个协议中,他们的TCP协议和TLS的握手都是分开的。

虽然链接的过程需要QUIC协议进行链接,但是这个过程需要的比较少,而这个链接过程只是为了确认双方的链接ID。

QUIC中包含了TLS,所以当我们链接的时候,也会进行TLS的链接

3.链接迁移

基于TCP传输协议的HTTP协议,由于通过的是四元组,确定一条TCP的链接

当设备从4G的链接切换到WIFI的链接的话,这个过程就会改变,所以我们就需要重新链接。

而QUIC的链接相当于是使用ID来进行标定的,而且ID还可以保存在本地,所以我们重链接的时候就不会出现卡顿,而是直接复用就可以。

参考

小林Coding--HTTP

思维导图(如果面试前突击复习可以看这个!)

HTTP.png