【JavaSE】十八、URL HTTP请求格式 常见报头 状态码 会话保持

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