【HTTP】URL && HTTP报文格式 && 请求方法 && 常见报头 && 状态码 && Cookie && Session

Ⅰ. URL

统一资源描述定位符 URL（Uniform Resource Locator）是用来表示从互联网上得到的资源位置和访问这些资源的方法，说的简单直白一点，就是我们平时在访问页面时候输入的网址！

为什么要有这个 URL 呢❓❓❓

其实和 HTTP 协议的出现是差不多的情况，就是因为我们需要去统一怎么标志分布在整个互联网上的万维网文档，所以必须要有一个统一的格式去描述这些文档，那么万维网使用的就是 URL 来解决，并且它在整个互联网范围内是唯一的！

一个 URL 大致由如下几部分构成：

💥注意事项：

• 查询字符串以 ? 开头，字符串内容以键值对形式出现，多个字符串之间用 & 进行分割。
  • 查询字符串是由程序员自定义的。
• 片段标识符是前端开发负责的，可以理解为一个前端的跳转链接。例如 Vue官方文档，通过不同的片段标识跳转到文档的不同章节。
• URL 当中除了会对这些特殊符号做编码，对中文也会进行编码，第一是为了压缩文本，减少网络资源消耗；第二是为了保证中文不会出现乱码的情况，避免出现某些浏览器等解析 URL 失败导致跳转失败，带来损失！
• 在报文的正文中既可以存文本数据，也可以存二进制数据，但是查询字符串只能存放文本数据。为了能够在查询字符串中存放二进制数据，可以先将二进制数据，通过常用的 base64 编码转变成文本数据，然后再存放到查询字符串，相当于间接存放二进制数据，解析时候再通过 base64 解码得到原本的二进制数据！

Ⅱ. 报文格式

💥注意事项：

1. 在一行中用空格隔开不同内容，而行与行之间用 CRLF 来隔开。
2. HTTP 在报头中引入了 Content-Type 和 Content-Length 来解决 TCP 的粘包问题：
   1. 读取报文的时候，如果报头中不存在上述两个字段，说明没有正文，则读到一个空行 CRLF 之后就结束。
   2. 读取报文的时候，如果报头中存在上述两个字段，则浏览器会按照 Content-Length 来读取对应大小的请求正文内容，然后按照 Content-Type 选择对应的资源处理方式来处理信息！
   3. 如果报头中只出现了两个字段中的其中之一，则很有可能是违法的报文，通常浏览器会自动拦截！

Ⅲ. HTTP 请求方法

💥注意事项：

• 前后端开发中，建议遵循 Restful 风格，读用 GET、写用 POST、更新用 PUT、删除用 DELETE。
• GET 请求的 URL 的长度并没有任何限制，这取决于浏览器的实现和 HTTP 服务器端的实现。
• GET 请求的触发时机：
  • 用户访问页面
  • 点击超链接
  • 提交带 method="get" 的表单
  • 前端通过 AJAX 发送 GET 请求
  • 浏览器自动请求静态资源（比如加载 CSS、JS、图片等资源时自动发起 GET 请求）
• POST 请求的触发时机：
  • 提交带 method="post" 的表单（比如注册、登录）
  • 前端通过 AJAX 发送 POST 请求
  • 调用第三方接口或后端接口需要上传数据（比如上传图片、提交 JSON 或表单数据等）

💥 GET 和 POST 的区别

两者并没有本质区别，因为 GET 完全可以用于提交数据，POST 也完全可以用于获取数据，只不过在使用习惯和特点有些区别，如下所示：

1. GET 通常没有 body，通过查询字符串传递数据给服务器；而 POST 通常有 body，不需要通过查询字符串传递数据。
2. 语义上两者含义不同，GET 表示 "获取"；POST 表示 "提交"。
3. GET 通常要求幂等，故可以被缓存；POST 一般是不幂等的，故不能被缓存。
   1. 幂等：表示多次请求得到的结果是一致的

Ⅳ. HTTP 常见报头

Ⅴ. HTTP 状态码

💥重定向注意细节：

• 静态资源、页面重定向可用 301（永久）或 302（临时），但要清楚 方法可能变化（即可能从 POST 变成 GET，导致方法体丢失等情况）
• 表单、REST API 等需要保持方法的请求，应优先使用 307（临时）或 308（永久），方法不会变化
• 重定向的地址可以从响应报文中的 Location 字段获取！

Ⅵ. 会话保持

一、Cookie

要实现会话保持还是挺复杂的，但是 Cookie 技术就不一样了，它只是做到让人看起来就像是会话一直保持着一样，但实际还是原来的无状态通信，只是稍微做了一下修改：多携带一些状态信息！

cookie 信息是在服务端创建的，但最后保存在客户端。在 cookie 有效期内，后续的浏览器的请求就会带上对应的 cookie 信息，服务端收到请求后，识别 cookie 就可以知道当前发起请求的用户是哪一个，而且浏览器下次再次需要相同信息时，比如用户名什么的，可以直接从 cookie 里获取，而不用再次让用户发起请求获取。

我们可以通过在服务器的响应中设置 cookie 字段，这个字段名我们之前介绍过，叫做 Set-Cookie，其后面跟的就是给用户提供的鉴权信息，并且可以设置该 cookie 的最大生存时间，当过了该时间之后，在客户端会进行时间的对比，超时了 cookie 就失效了，就要重新在请求中带上账号密码等信息，对应到用户就是要重新输入密码进行登录了！

// 往后20秒，每次http请求时候都会自动携带曾经设置的所有cookie，帮助服务器进行鉴权行为
resphead += "Set-Cookie: name=lirendada; Max-Age=20\r\n"; 

二、Session

为了提高安全性，于是引入了 session 机制，其实就是将原来保存在客户端的 cookie，现在变成了由服务端来保存管理，如下图所示：

流程如下所示：

1. 用户第一次登录，后端创建一个 Session（服务器端）；
2. 后端生成一个 Session ID，通过 Set-Cookie 响应头发送给客户端；
3. 客户端浏览器将 Session ID 保存在 Cookie 中；
4. 后续每次请求浏览器都会自动带上该 Cookie，服务器通过 Session ID 找到用户的 Session 数据。

三、两者区别

四、理解 cookie、session、token 三者的区别

• cookie 存放在 客户端，可以存放任何数据，但是容易泄漏，所以通常存放的是 session id，而不是直接存放用户信息。
• session 存放在 服务端，一般存放用户信息（用于认证），然后据此生成 session id 发送给客户端，以后每次客户端访问服务器都会在 cookie 中带上该 session id，方便服务端验证。
  • 但是 session 存在这些问题：
    • 占用服务器资源
    • 在分布式集群中存在一致性问题
    • 依赖 cookie，所以存在跨域问题
    • session id 一旦泄漏，攻击者就能伪造身份进行登录，存在安全隐患
• token 通常存放在 客户端，是一种代表用户身份或会话的字符串凭证，本质上就是 "访问票据"。
  • token 应用时候有两种类型：
    • 随机字符串 token
      1. 后端生成随机 ID，存到 Redis 对应用户信息
      2. 前端请求带 token，服务器查 Redis 获取用户数据
      3. 优势：服务器可随时失效 token
    • JWT（JSON Web Token）
      1. 自包含 token，把用户信息和过期时间写进 token 本身，并用签名保护
      2. 不需要每次查 Redis，即可验证身份
      3. 缺点：一旦签发，服务器无法轻易强制失效（除非加黑名单）