HTTP总结

Posted 2023-02-16 xiao zhou

HTTP复习

• HTTP概念
• • HTTP特点
  • HTTP请求报文 & HTTP相应报文
  • • 头部字段
    • 状态码
    • 请求方法
  • POST与GET的区别
• HTTP缓存技术
• • 1、强制缓存
  • 2、协商缓存（条件GET）
• HTTP/1.1特性
• • 1、优点
  • 2、缺点
  • 性能
• HTTP与HTTPS
• • 1、HTTP与HTTPS区别
  • 2、HTTPS 解决了 HTTP 的哪些问题？
  • 3、HTTPS是如何做到安全的呢？
  • 4、HTTPS如何建立连接
• HTTP演变过程
• • HTTP/1.1 与 HTTP/1.0如何提高性能？
  • HTTP/2有什么优化
  • 4、服务器推送
  • HTTP/2的缺陷
  • HTTP/3的优化
  • • QUIC的特点

HTTP概念

HTTP【超文本传输协议】

HTTP特点

（1）无状态：没有状态保存，第一次、第二次。。。。第N次的请求与相应无区别。
（2）无连接：限制每次连接只能处理一个请求，服务器处理完客户端的请求并收到客户端的应答后即断开连接，采用这种方式可以节省时间。HTTP1.1后默认采用keep-alive长连接，服务器要等一段时间（timeout）后才能断开连接。

短连接：一个http连接只能传输一个对象
长连接：一个http连接可以传输多个对象（流水线【pipeline】）

（3）超文本传输：传输的内容【对象】不仅仅是文本内容，还可以传输音频、图片、视频等等。

HTTP请求报文 & HTTP相应报文

头部字段

1、Content-Type：传输的数据类型
2、Host：客户端发送请求时，用于指定服务器域名
3、Content-Length：回应的Body【实体主体】的长度
4、Connection：最常用于客户端要求服务器使用TCP持久连接，便于其他HTTP请求复用。【Connection:keep-alive】
5、User-Agent：声明用户的操作系统和浏览器的版本信息

正是通过User-Agent，这个字段描述，服务器才能更好的为客户端提供服务。因为服务器知道了客户端的身份，什么样的OS、移动端还是PC端。。。。

6、referer：当前页面是从哪一个页面跳转过来的
7、location：搭配【状态码】使用，告诉客户端接下来要跳转到那里访问
8、Cookie：用于在客户端存储”身份验证信息“，通常用于实现会话功能
9、Set-Cookie：第一次登录时，服务器生成session-id保存，并返回给客户端，客户端保存Set-Cookie中的Cookie

状态码

• 1xx 类状态码属于提示信息，是协议处理中的一种中间状态，实际用到的比较少。

• 2xx 类状态码表示服务器成功处理了客户端的请求，也是我们最愿意看到的状态。

「200 OK」是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。

「204 No Content」也是常见的成功状态码，与 200 OK 基本相同，但响应头没有 body 数据。

「206 Partial Content」是应用于 HTTP 分块下载或断点续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。

• 3xx 类状态码表示客户端请求的资源发生了变动，需要客户端用新的 URL 重新发送请求获取资源，也就是重定向。

「301 Moved Permanently」表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。以后再访问就直接使用新的URL

「302 Found」表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问。

301 和 302 都会在响应头里使用字段 Location，指明后续要跳转的 URL，浏览器会自动重定向新的 URL。

「304 Not Modified」不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，也就是告诉客户端可以继续使用缓存资源，用于缓存控制。

• 4xx 类状态码表示客户端发送的报文有误，服务器无法处理，也就是错误码的含义。

「400 Bad Request」表示客户端请求的报文有错误，但只是个笼统的错误。

「403 Forbidden」表示服务器禁止访问资源，并不是客户端的请求出错。

「404 Not Found」表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。

• 5xx 类状态码表示客户端请求报文正确，但是服务器处理时内部发生了错误，属于服务器端的错误码。

「500 Internal Server Error」与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。

「501 Not Implemented」表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。

「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。

「503 Service Unavailable」表示服务器当前很忙，暂时无法响应客户端，类似“网络服务正忙，请稍后重试”的意思。

请求方法

POST与GET的区别

1、语义
GET：从服务器获取指定的资源
POST：是根据请求负荷（报文body）对指定的资源做出处理
2、安全与幂等

安全指的是：是指请求方法不会改变服务器上的资源
幂等指的是：多次执行相同的操作，结果都是相同的

所以GET是安全且幂等
POST是不安全且不幂等
3、参数
GET的参数是显示在URL中
POST的参数是再实体主体中【正文中】
所以GET的URL不能太长，就是参数不能太多，但是POST就没有这种要求。
并且GET的URL中参数不能出现非ASCII字符（会被转义）POST可以出现
4、缓存
GET能被缓存【条件GET】
POST不能

HTTP缓存技术

对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，这样的话 HTTP/1.1 的性能肯定肉眼可见的提升。
所以，避免发送 HTTP 请求的方法就是通过缓存技术，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。
HTTP 缓存有两种实现方式，分别是强制缓存和协商缓存。

1、强制缓存

概念：
指的是，服务器自己缓存数据，自行判断数据内容是否过期，决定是否使用缓存，而不再次通过网络向服务器发起请求、期望响应的方式。这种方式中，主动权在浏览器【客户端】一方。

强制缓存使用到了两个头部字段，他们都标识了资源在服务器上的有效期。
Cache-Control：是一个相对时间
Expires：是一个绝对时间
如果HTTP响应头部同时具备这两个字段，Cache-Control具有更高的优先级（Cache-Control选项更多，设置更精细）

流程：

• 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小；
• 浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器；
• 服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。

2、协商缓存（条件GET）

概念
协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。

第一种需要的头部字段：
响应报文头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。
请求报文头部中的 Last-Modified：最后一次修改的时间

第二种需要的头部字段：
请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。
响应头部中的 ETag：唯一标识响应资源

当报文中同时存在两种头部时，应该优先选择第二种方式。
原因：
（1）在没有修改文件内容情况下，文件的最后修改时间可能也会改变，这会导致客户端认为这文件被改动了，从而重新请求；
（2）可能有些文件是在秒级以内修改的，If-Modified-Since 能检查到的粒度是秒级的，使用 Etag就能够保证这种需求下客户端在 1 秒内能刷新多次；
（3）有些服务器不能精确获取文件的最后修改时间。

流程

<注>： 协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

HTTP/1.1特性

1、优点

1、简单：报文格式简单，易于理解
2、灵活、易扩展：HTTP协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。并且HTTP处于应用层，下层协议也可改变
3、应用广泛、跨平台

2、缺点

1、无状态：①虽然无状态就意味着不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。②但是服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。
2、明文传输：①明文传输意味着方便阅读报文，肉眼可看方便调试。②但也会让信息暴露，不安全
3、不安全：
①使用明文传输，内容被窃听
②不验证通信双方身份
③无法证明报文的完整性（可能被篡改）

HTTP 的安全问题，可以用 HTTPS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。

性能

1、长连接：HTTP/1.0是短连接，HTTP/1.1后就是长连接
也称非持久化连接 / 持久化链接

2、管道网络传输【pipeline】
即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但是服务器必须按照接收请求的顺序发送对这些管道化请求的响应。如果服务端在处理 A 请求时耗时比较长，那么后续的请求的处理都会被阻塞住，这称为【队头堵塞】。所以，HTTP/1.1 管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。

3、队头阻塞
因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」

HTTP与HTTPS

1、HTTP与HTTPS区别

1、HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。
2、HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。
3、HTTP 的端口号是 80，HTTPS 的端口号是 443。
4、HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。

2、HTTPS 解决了 HTTP 的哪些问题？

HTTP 由于是明文传输，所以安全上存在以下三个风险：

• 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险，比如冒充淘宝网站，用户钱容易没。

HTTPS在HTTP和TCP/IP层之间加入了SSL/TLS，解决了上述问题：

• 信息加密：交互信息无法被窃取，但你的号会因为「自身忘记」账号而没。
• 校验机制：无法篡改通信内容，篡改了就不能正常显示，但百度「竞价排名」依然可以搜索垃圾广告。
• 身份证书：证明淘宝是真的淘宝网，但你的钱还是会因为「剁手」而没。

3、HTTPS是如何做到安全的呢？

1、混合加密 解决 窃听风险
【混合加密】就是采用对称加密和非对称加密结合的方式。

在通信建立前采用非对称加密的方式交换「会话秘钥」，后续就不再使用非对称加密。
在通信过程中全部使用对称加密的「会话秘钥」的方式加密明文数据。

2、摘要算法+数字签名 解决 篡改风险
摘要算法

通过哈希算法可以确保内容不会被篡改，但是并不能保证「内容 + 哈希值」不会被中间人替换，因为这里缺少对客户端收到的消息是否来源于服务端的证明。

那为了避免这种情况，计算机里会用非对称加密算法来解决，共有两个密钥：

• 一个是公钥，这个是可以公开给所有人的；
• 一个是私钥，这个必须由本人管理，不可泄露。

这两个密钥可以双向加解密的，比如可以用公钥加密内容，然后用私钥解密，也可以用私钥加密内容，公钥解密内容。

• 公钥加密，私钥解密。这个目的是为了保证内容传输的安全，因为被公钥加密的内容，其他人是无法解密的，只有持有私钥的人，才能解密出实际的内容；
• 私钥加密，公钥解密。这个目的是为了保证消息不会被冒充，因为私钥是不可泄露的，如果公钥能正常解密出私钥加密的内容，就能证明这个消息是来源于持有私钥身份的人发送的。

所以非对称加密的用途主要在于通过 私钥加密，公钥解密 的方式，来确认消息的身份，我们常说的数字签名算法，就是用的是这种方式，不过私钥加密内容不是内容本身，而是对内容的哈希值加密。

3、数字证书 解决 冒充风险

简单来说，可以伪造一对公钥私钥，这样就冒充进行通信也是不行的。

解决方法：
通过权威的机构就是 CA （数字证书认证机构），「个人信息 + 公钥 + 数字签名」打包成一个数字证书(也就是将服务器公钥放在数字证书（由数字证书认证机构颁发）中），只要证书是可信的，公钥就是可信的。

4、HTTPS如何建立连接

HTTP演变过程

HTTP/1.1 与 HTTP/1.0如何提高性能？

HTTP/1.1 相比 HTTP/1.0 性能上的改进：

• 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

但 HTTP/1.1 还是有性能瓶颈：

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；
• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；
• 服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据，也就是队头阻塞；
• 没有请求优先级控制；
• 请求只能从客户端开始，服务器只能被动响应。

HTTP/2有什么优化

1、头部压缩
HTTP/2 会压缩头（Header）如果你同时发出多个请求，他们的头是一样的或是相似的，那么，协议会帮你消除重复的部分。
这就是所谓的 HPACK 算法：在客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就提高速度了。
2、二进制格式
HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧（frame）：头信息帧（Headers Frame）和数据帧（Data Frame）。

这样虽然对人不友好，但是对计算机非常友好，因为计算机只懂二进制，那么收到报文后，无需再将明文的报文转成二进制，而是直接解析二进制报文，这增加了数据传输的效率。
3、并发传输
为了解决队头阻塞的问题。
引出了 Stream 概念，多个 Stream 复用在一条 TCP 连接。

一个TCP连接可以包含多个Stream，一个Stream可以有多个Message（对应的就是HTTP/1的报文），每个Message里包含一条或者多个 Frame，Frame 是 HTTP/2 最小单位，以二进制压缩格式存放 HTTP/1 中的内容（头部和包体）。

针对不同的 HTTP 请求用独一无二的 Stream ID 来区分，接收端可以通过 Stream ID 有序组装成 HTTP 消息，不同 Stream 的帧是可以乱序发送的，因此可以并发不同的 Stream ，也就是 HTTP/2 可以并行交错地发送请求和响应。

4、服务器推送

服务端不再是被动地响应，可以主动向客户端发送消息。
客户端和服务器双方都可以建立 Stream， Stream ID 也是有区别的，客户端建立的 Stream 必须是奇数号，而服务器建立的 Stream 必须是偶数号。

HTTP/2的缺陷

HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区里的数据返回给 HTTP 应用，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区里，只有等到这 1 个字节数据到达时，HTTP/2 应用层才能从内核中拿到数据，这就是 HTTP/2 队头阻塞问题。
【TCP层面的队头阻塞】

HTTP/3的优化

因为只要使用TCP，就一定会有TCP层面的队头阻塞
所以， HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP！
但是UDP是不可靠的数据传输，但是基于UDP的QUIC协议就会实现类似于TCP的可靠数据传输。

QUIC的特点

1、无队头阻塞
QUIC 有自己的一套机制可以保证传输的可靠性的。当某个流发生丢包时，只会阻塞这个流，其他流不会受到影响，因此不存在队头阻塞问题。这与 HTTP/2 不同，HTTP/2 只要某个流中的数据包丢失了，其他流也会因此受影响。
所以，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，某个流发生丢包了，只会影响该流，其他流不受影响。
2、更快的连接建立

3、连接迁移
当移动设备的网络从 4G 切换到 WIFI 时，意味着 IP 地址变化了，那么就必须要断开连接，然后重新建立连接。而建立连接的过程包含 TCP 三次握手和 TLS 四次握手的时延，以及 TCP 慢启动的减速过程，给用户的感觉就是网络突然卡顿了一下，因此连接的迁移成本是很高的。

而 QUIC 协议没有用四元组的方式来“绑定”连接，而是通过连接 ID来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本，没有丝毫卡顿感，达到了连接迁移的功能。

所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。

文章总结自小林coding
https://www.xiaolincoding.com/network/2_http/http_interview.html#http-%E5%9F%BA%E6%9C%AC%E6%A6%82%E5%BF%B5