文章目录
- 1. HTTP介绍
- 认识URL
- 2. HTTP消息结构
- 请求request
- 响应response
- 3. HTTP请求方法
- 4. HTTP报头
- 5. HTTP响应状态码
- 6. Cookie和Session
1. HTTP介绍
HTTP（hypertext transfer protocol）是一种常用的应用层协议，用于在计算机之间传输超文本数据。 它是Web通信的基础，客户端（通常是浏览器）和服务器使用HTTP协议传输网页、视频、图片等资源。下面是HTTP协议的一些特性：
- 基于请求-响应模型。 浏览器客户端发送HTTP请求，请求中包含客户端欲获得的资源，服务器接收并处理请求，并返回响应到客户端，响应通常包含客户端请求的资源和状态信息。
- HTTP是无状态的。 “无状态”也可称为“无记忆”，即客户端每次HTTP请求都是独立的，服务器不会在多个请求之间保留关于客户端的状态信息，这意味着服务器看待每个请求都像是孤立的，新的事件。
- 持久连接： 为了提高性能，HTTP/1.1引入了持久连接，允许多个请求和响应在同一TCP连接上传输，减少了连接建立和拆除的开销。在此之前的HTTP/1.0是无连接的，即发送一次请求创建一个新连接。
认识URL
URL（uniform resource Locator）统一资源定位符，是HTTP标识某个特定资源的方式，可以定位资源的地址。
Scheme: 表明浏览器使用哪种协议，通常是http或https（安全版http，后面详谈）。
Domain Name: 服务器域名，标识申请资源在哪一台服务器上，本质上是一个ip地址，也可以直接用服务器的ip地址。
Port：服务器端口号。http/https协议规定了标准端口号（http: 80, https: 443），若URL此项为空则根据Scheme默认使用标准。
Path to the file: 请求资源在服务器上的路径。这个路径虽然看起来以根目录起始，但在服务器中一般是在某个wwwroot文件夹下的。
Parameters: 提交到服务器的一些参数，从
?开始，以key=value的形式保存并以&为分隔符隔开。服务器可以使用这些参数来执行额外的操作，具体作何操作由服务器决定。Anchor: 片段标识符，从
#开始。锚点表示资源中的一种“书签”，给浏览器显示位于该“加书签”位置的内容的方向。例如，在 HTML 文档上，浏览器将滚动到定义锚点的位置。
📝参考文章：
什么是URL？
2. HTTP消息结构
💭先认识HTTP请求和响应的宏观结构，再深入理解结构中的不同内容。
请求request
🔎HTTP请求（request）结构如下：
请求由四部分构成，分别为：请求行、请求报头、空行和正文。每部分由分隔符\r\n以行的形式隔开。
- 请求行（request line）：包含请求方法（最常见的是GET和POST）、URL和http协议版本（HTTP/1.0, HTTP/1.1），每部分以空格分隔。这里的URL不一定是携带域名和端口号的完整URL，一般只是服务器资源路径，因为HTTP客户端已经知道您要访问的资源来自哪个主机地址，通常会保存在请求报头的
Host字段中。 - 报头（headers）：请求的属性，以冒号分割的键值对，每组属性之间用
\r\n隔开。 - 空行：空行代表报头部分的结束，进入正文部分
- 正文（body）：若请求是POST/PUT等用于上传的方法，正文可以包含上传至服务器的数据资源。对于GET请求，请求正文通常是不包含数据的。
响应response
🔎HTTP响应（response）结构如下：
响应同样由四部分构成，分别为：状态行、响应报头、空行和正文。每部分由分隔符\r\n以行的形式隔开。
- 状态行（response line）：包含协议版本、状态码、（状态码对应的）状态描述
- 响应报头（headers）：响应的属性，以冒号分割的键值对，每组属性之间用
\r\n隔开。 - 空行：空行代表报头部分的结束，进入正文部分
- 正文（body）：发送给客户端的各种类型的资源，如：网页资源、视频、图像等。本质是二进制数据，客户端收到后会根据正文类型（Content-Type，响应header的一种）做解析，得到自己想要的资源。
3. HTTP请求方法
📝根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
HTTP/1.0定义了三种请求方法：GET, POST 和 HEAD 方法。
HTTP/1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。
| 请求方法 | 描述 |
|---|---|
| GET | 请求指定资源，返回资源实体 |
| POST | 向指定资源提交数据进行处理请求，如：提交表单、上传各种文件。数据包含在请求正文中，POST可能会导致新资源的创建或已有资源的修改。POST请求不会在客户端缓存，因此浏览器查无POST请求记录。 |
| HEAD | 类似于GET，不同的是请求后返回的响应没有具体的正文内容，只用于获取响应报头。 |
| PUT | 向服务器中指定的URL路径上传或更新完整的资源。 |
| DELETE | 请求服务器删除指定页面 |
| CONNECT | HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。 |
| OPTIONS | 允许客户端查看服务器的性能 |
| TRACE | 回显服务器收到的请求，主要用于测试或诊断 |
| PATCH | 是对 PUT 方法的补充，用来对已知资源进行局部更新 。 |
-
GET和POST方法都可以向服务器提交参数，区别在于GET通过URL提交，而POST通过请求正文提交。
例子：form表单提交参数，可选择提交参数的方式GET/POSE，可以对比两种方式服务器收到请求的区别。（测试环境为作者自行编写的一个简单的HTTP服务器）
若选择method=“GET”
若选择method=“POST”
-
POST和PUT的区别：POST通常用于执行各种不同的操作，提交某些请求数据，以供服务器完成特定的处理，如登录账号。PUT一般是向服务器指定路径上传或更新完整的文件资源，路径存在则更新，路径不存在则创建。
4. HTTP报头
💭HTTP Header有很多种，这里总结几个比较重要的Header，具体内容可以参考文章：
📝HTTP响应头和请求头信息对照表
| Header Key | 解释 | 示例 | 适用于 |
|---|---|---|---|
| Content-Type | 正文内容的类型 | Content-Type: text/html | 请求、响应 |
| Content-Length | 正文内容的长度 | Content-Length: 1024 | 请求、响应 |
| Host | 请求服务器的ip地址和端口号 | Host: ip:port | 请求 |
| User-Agent | 客户端信息（含OS、浏览器版本） | User-Agent: Mozilla/5.0 (Linux; X11) | 请求 |
| Cookie | 用户状态信息 | Cookie: sessionID=27 | 请求 |
| Set-Cookie | 设置用户状态信息 | Set-Cookie: sessionID=27 | 响应 |
| Location | 搭配3XX状态码使用，告知客户端重定向地址 | Location: /a/b/c.html | 响应 |
📝HTTP Content-Type 对照表
有关Cookie的两个header，后面详细分析。
5. HTTP响应状态码
服务器返回到客户端的响应，必须包含状态码，告知用户请求处理完毕的结果。常见的我们日常会遇到的网页404 Not Found错误，404就是一种状态码。
⭕ 状态码大致大致有五个范围：
- 1XX：提供某种附加信息
- 2XX：请求成功
- 3XX：重定向
- 4XX：客户端错误
- 5XX：服务端异常
⭕ 常见的几个状态码及对应的状态描述：
| 状态码 | 状态描述 | 解释 |
|---|---|---|
| 200 | OK | 请求成功 |
| 301 | Moved Permanently | 永久重定向 |
| 302 | Found | 临时重定向 |
| 400 | Bad Request | 请求语法错误，服务器无法理解 |
| 403 | Forbidden | 服务器拒绝用户请求 |
| 404 | Not Found | 服务器无法根据请求找到资源 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
⭕ 关于重定向
这里的重定向指的是：客户端接收到状态码为3XX的响应时，会重新定位新的资源，即发送新的请求。3XX状态码一般搭配报头Location使用，由Location指定新的URL。
301状态码是永久重定向，告知客户端请求资源已永久转移到另一个URL。客户端收到301响应后，会更新其书签、链接或缓存，以便下次请求时直接使用新的URL。对于搜索引擎来说，内部存储了大量的索引信息（关键词->URL），当访问某网站时收到301响应，则会修改搜索引擎内部的索引。
302状态码是临时重定向，告知客户端请求资源只是暂时转移到另一个URL，客户端收到302响应后并不会修改其缓存信息。临时重定向通常也被应用在一些需要做网页跳转的场景，如：用户登录、广告植入等等。
6. Cookie和Session
💭场景：当我们用浏览器登录一次b站后，接下来很长一段时间都不用重新登录了，每次访问b站都是直接用的。可这似乎和我们之前提及的http特性相悖：http不是无状态的吗？既然无状态，为什么登录一次之后，浏览器能“记住”我的登录信息呢？不应该是每次访问都要重新登录吗？
事实上，按照http“无状态”的特性来讲，确实每次访问都需要重新登录，可这会让用户的体验极差。因此，浏览器客户端使用了Cookie的概念，解决了这一问题。Cookie是一种维护用户状态和跟踪用户身份的机制，本质是一种保存在客户端（浏览器）的轻量级文本文件，当用户访问某个网站时，浏览器会将Cookie数据打包在请求中（以Header形式存在），发送给服务器。
为什么说Cookie能解决http无状态的问题，实现用户无需频繁重新登录的功能？下面模拟Cookie在用户两次访问b站期间的作用过程。
但是上面这种客户端直接发送Cookie的做法并不安全，因为传输过程中，黑客能够盗取用户的Cookie，获得用户的账号密码并进行非法操作。因此有了另外一种解决方案：Session。
Session会话是一种存储在服务器中的数据结构，用于存储和维护用户的状态信息。 每个用户登录后，服务器会为其创建一个新会话，以维护其状态信息。每个会话都有一个唯一的sessionID，客户端不再收取由服务器经处理确认后发回的原始Cookie信息，而是接收并保存由服务器为客户端创建的会话sessionID（sessionID同样保存在响应报头的Set-Cookie字段中）。
这样一来，由于客户端与服务器之间传递的是sessionID而不是原始状态信息，虽然无法保证sessionID不被中间人盗取，但是便于服务器更好地控制和保护会话数据（如检测到登录状态异常，自动删除session，要求重新登录），中间人盗取了sessionID也没用。
ENDING…
