报文结构

起始行 + 头部（header部分） + 空行 + 实体(body部分）

  1. 起始行：GET /home HTTP/1.1

请求方法

http/1.1规定了以下请求方法(注意，都是大写):

  • GET: 通常用来获取资源
  • POST: 提交数据，即上传数据
  • PUT: 修改数据
  • DELETE: 删除资源(几乎用不到)
  • OPTIONS: 列出可对资源实行的请求方法，用来跨域请求 —— 预检请求
  • HEAD: 获取资源的元信息
  • CONNECT: 建立连接隧道，用于代理服务器
  • TRACE: 追踪请求-响应的传输路径

GET与POST区别

最大区别：语义 和 传输参数的位置不一样

  • 长度限制角度：GET请求提交的数据有长度限制（HTTP 协议本身没有限制 URL 及正文长度,对 URL 的限制大多是浏览器和服务器的原因），POST请求没有内容长度限制；
  • 从缓存的角度，GET 请求会被浏览器主动缓存下来，留下历史记录，而 POST 默认不会。
  • 从安全性的角度，GET 一般放在 URL 中，因此不安全，POST 放在请求体中，更适合传输敏感信息。

特点：优缺

优点：

  1. 可靠传输。HTTP 基于 TCP/IP，因此把这一特性继承了下来。这属于 TCP 的特性；
  2. 请求-应答。也就是一发一收、有来有回
  3. 无状态。这里的状态是指通信过程的上下文信息，而每次 http 请求都是独立、无关的，默认不需要保留状态信息。

缺点：
无状态、明文传输、队头阻塞

无状态：在需要长连接的场景中，需要保存大量的上下文信息，以免传输大量重复的信息，那么这时候无状态就是 http 的缺点了。
队头阻塞：当 http 开启长连接时，共用一个 TCP 连接，同一时刻只能处理一个请求，那么当前请求耗时过长的情况下，其它的请求只能处于阻塞状态，也就是著名的队头阻塞问题

URL与URI?

URI, 全称为(Uniform Resource Identifier), 也就是统一资源标识符，它的作用很简单，就是区分互联网上不同的资源。
网址：google.com， URI: https://google.com
URI = URN + URL
由于 URL 过于普及，默认将 URI 视为 URL。

image.png

  1. https://www.xxx.com/s?wd=HTTP&rsv_spt=1

状态码

301 与 302

2XX 成功

  • 200 OK，表示从客户端发来的请求在服务器端被正确处理
  • 204 No content，表示请求成功，但响应报文不含实体的主体部分
  • 206 Partial Content，进行范围请求

3XX 重定向

  • 301 moved permanently，永久性重定向，表示资源已被分配了新的 URL
  • 302 found，临时性重定向，表示资源临时被分配了新的 URL
  • 303 see other，表示资源存在着另一个 URL，应使用 GET 方法丁香获取资源
  • 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
  • 307 temporary redirect，临时重定向，和302含义相同

4XX 客户端错误

  • 400 bad request，请求报文存在语法错误
  • 401 unauthorized，表示发送的请求需要有通过 HTTP 认证的认证信息
  • 403 forbidden，表示对请求资源的访问被服务器拒绝
  • 404 not found，表示在服务器上没有找到请求的资源

5XX 服务器错误

  • 500 internal sever error，表示服务器端在执行请求时发生了错误
  • 503 service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求

301 302：
字面上的区别就是 301 是永久重定向，而 302 是临时重定向。
301 比较常用的场景是使用域名跳转。302 用来做临时跳转, 比如未登陆的用户访问用户中心被重定向到登录页面

缓存

Cookie

HTTP 是一个无状态的协议，每次 http 请求都是独立、无关的，默认不需要保留状态信息
有时候需要保存一些状态
HTTP 为此引入了 Cookie

向同一个域名下发送请求，都会携带相同的 Cookie，服务器拿到 Cookie 进行解析，便能拿到客户端的状态。而服务端可以通过响应头中的Set-Cookie字段来对客户端写入Cookie

  1. // 请求头
  2. Cookie: a=xxx;b=xxx
  3. // 响应头
  4. Set-Cookie: a=xxx
  5. set-Cookie: b=xxx

不同域名可以携带cookie吗？SameSite是指定可携带cookie的域名的意思吗？

安全性：
预防 XSS 攻击：cookie 字段带上HttpOnly
预防CSRF 攻击：SameSite
SameSite可以设置为三个值，Strict、Lax和None。

a. 在Strict模式下，浏览器完全禁止第三方请求携带Cookie。比如请求sanyuan.com网站只能在sanyuan.com域名当中请求才能携带 Cookie，在其他网站请求都不能。
b. 在Lax模式，就宽松一点了，但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可以携带 Cookie，其他情况均不能。
c. 在None模式下，也就是默认模式，请求会自动携带上 Cookie。

cookie缺点：

  • 容量缺陷。Cookie 的体积上限只有4KB，只能用来存储少量的信息。
  • 性能缺陷。Cookie 紧跟域名，不管域名下面的某一个地址需不需要这个 Cookie ，请求都会携带上完整的 Cookie，这样随着请求数的增多，其实会造成巨大的性能浪费的，因为请求携带了很多不必要的内容。但可以通过Domain和Path指定作用域来解决。
  • 安全缺陷。由于 Cookie 以纯文本的形式在浏览器和服务器中传递，很容易被非法用户截获，然后进行一系列的篡改，在 Cookie 的有效期内重新发送给服务器，这是相当危险的。另外，在HttpOnly为 false 的情况下，Cookie 信息能直接通过 JS 脚本来读取。

扩展：
fetch 不会发送 cookies,除非你使用了credentials 的初始化选项, credentials指定请求啥时候带cookie
即使跨域也可以携带cookie的话，需要在fetch设置 credentials:include; （默认是同源same-origin)
fetch() 可以跨域 cookies；你也可以使用 fetch() 建立起跨域会话(其他网站的 Set-Cookie 头部字段将会被无视)

cookie、session、localstorage区别？
localstorage：存储size最大；
cookie与session都是会话级别的

cookie session
存储位置 客户端浏览器上 服务器上
存储容量 单个cookie保存的数据<=4KB，一个站点最多保存20个Cookie session来说并没有上限，但出于对服务器端的性能考虑，session内不要存放过多的东西，并且设置session删除机制
隐私策略 cookie对客户端是可见的，别有用心的人可以分析存放在本地的cookie并进行cookie欺骗，所以它是不安全的， session存储在服务器上，对客户端是透明的，不存在敏感信息泄漏的风险。
有效期 开发可以通过设置cookie的属性，达到使cookie长期有效的效果 关闭窗口该session就会失效，因而session不能达到长期有效的效果
跨域支持 cookie支持跨域名访问(二级域名是可以共享cookie的) session不支持跨域名访问。


ials

长短连接:keep-alive


HTTP1.0,2.0,3.0

http、https、http1.0、1.1、2.0、3.0的区别
http各个版本的区别是什么？解决了哪些问题？
比如头部缩减的优化，那你了解这个优化的具体策略吗？缩减了什么？又增加了什么？要深挖细节。

image.png

列头阻塞

Accept字段

参考资料

三元-（建议精读）HTTP灵魂之问，巩固你的 HTTP 知识体系