提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
文章目录
- HTTP简介
- 一、URL
-
- [1.1 URL的基本结构](#1.1 URL的基本结构)
- [1.2 示例解析](#1.2 示例解析)
- [1.3 urlencode 和 urldecode](#1.3 urlencode 和 urldecode)
- [二、HTTP 协议请求与响应格式](#二、HTTP 协议请求与响应格式)
-
- 2.1HTTP请求
- [2.2 HTTP响应](#2.2 HTTP响应)
- [2.3 HTTP常见header](#2.3 HTTP常见header)
-
- [Cookie 与 Session 特性对比](#Cookie 与 Session 特性对比)
- 部分关键HTTP请求和响应头字段的表格内容
- 三、HTTP请求方法
-
- [3.1 GET](#3.1 GET)
- [3.2 POST](#3.2 POST)
- 四、HTTP状态码
HTTP简介
HTTP（Hypertext Transfer Protocol，超文本传输协议）
虽然说应用层的协议我们程序员可以自己定制（其过程大概遵守OSI七层协议的上三层，通过业务需求模块（应用层），通信数据结构设计以及序列化和反序列化模块（表示层），服务通信的传输协议的封装模块（会话层）来实现）。但在实际使用中已经有完善和好用的协议供我们使用了。
它是互联网中最核心的应用层的协议之一，用于在客户端（如浏览器）和服务器之间传输超文本（如 HTML 文档、图片、视频等）。它是构建万维网（WWW）的基础，我们日常浏览网页、发送表单、加载资源等操作都依赖于 HTTP。
一、URL
URL（Uniform Resource Locator，统一资源定位符）是互联网上用于标识和定位资源（如网页、图片、文件等）的字符串，通俗来说就是我们常说的 "网址"。通过 URL，客户端（如浏览器）可以准确找到并访问服务器上的资源。
在网络中我们已经有了IP和端口号来标识一个主机上的某个服务器，为什么还要设计出URL这种东西呢？
其实主要目的就是便于使用
1.1 URL的基本结构
一个完整的 URL 通常由以下几个部分组成（部分可选），格式如下：
协议://用户名:密码@主机名:端口号/路径?查询参数#片段标识符
1.2 示例解析
以常见的网页 URL 为例：
https://www.example.com:8080/blog?category=tech\&sort=time#comment5
- 协议：https（使用 HTTPS 加密协议）
- 主机名：www.example.com（服务器域名）
- 端口号：8080（非默认端口，需显式指定）
- 路径：/blog（服务器上的blog资源路径）
- 查询参数：category=tech&sort=time（传递分类为 "tech"、排序方式为 "time" 的参数）
- 片段标识符：comment5（定位到资源内的comment5部分）
1.3 urlencode 和 urldecode
URL 中只能包含部分 ASCII 字符（如字母、数字、-_.~等），若包含特殊字符（如空格、中文、&?#等），需进行URL 编码（也叫百分号编码），将特殊字符转换为%XX的形式（XX 为字符的十六进制 ASCII 码）。
例如：
- 空格编码为%20（或+，在查询参数中常用）
- 中文 "测试" 的 UTF-8 编码为%E6%B5%8B%E8%AF%95
- 问号?编码为%3F（避免被解析为查询参数的开始）
转义的规则如下:
将需要转码的字符转为 16 进制，然后从右到左，取 4 位(不足 4 位直接处理)，每 2 位做一位，前面加上%，编码成%XY 格式例如:
"+" 被转义成了 "%2B"
这个过程一般发生在客户端（浏览器）中，urldecode 就是 urlencode 的逆过程
二、HTTP 协议请求与响应格式
HTTP的请求和响应就是两者数据的序列化和反序列化的过程，它使用特殊字符"/r/n等"来进行字符串之间的拼接，不需要依赖任何第三方库
而我们要做的就是对数据字符进行处理即可。
2.1HTTP请求
客户端发送的请求由三部分组成：请求行、请求头（header）、请求体 (body) /（可选）。当使用HTTP发送请求时，发送的就是如下字符串：
- 首行：请求方法与地址：POST http://job.xjtu.edu.cn/companyLogin.do HTTP/1.1
- 请求报头: 请求的属性, 冒号分割的键值对;每组属性之间使用\r\n 分隔;遇到空行
表示 Header 部分结束- 请求正文: 空行后面的内容都是 Body. Body 允许为空字符串. 如果 Body 存在,则在Header 中会有一个 Content-Length 属性来标识 Body 的长度-
2.2 HTTP响应
响应通常是我们自己的服务器发送的请求给客户端，因此这一部分的状态行还有各项数据通常需要我们自己做处理，同样也是对字符串的处理：
- 首行: 版本号 + 状态码 + 状态码解释
- 请求报文: 请求的属性, 冒号分割的键值对;每组属性之间使用\r\n 分隔;遇到空行表示 Header 部分结束
- 请求正文: 空行后面的内容都是 Body. Body 允许为空字符串. 如果 Body 存在, 则在
Header 中会有一个 Content-Length 属性来标识 Body 的长度; 如果服务器返回了
个 html 页面, 那么 html 页面内容就是在 body 中.
以下是响应的格式：
2.3 HTTP常见header
- Content-Type: 数据类型(text/html 等)
- Content-Length: Body 的长度
- Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
- User-Agent: 声明用户的操作系统和浏览器版本信息;
- referer: 当前页面是从哪个页面跳转过来的;
- Location: 搭配 3xx 状态码使用, 告诉客户端接下来要去哪里访问;
- Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能;
以下是基于提供的信息生成的对比表格，采用 Markdown 格式：
Cookie 与 Session 特性对比
HTTP是一种无状态无连接的协议，每次建立连接都需要建立新连接，因此服务器不会保存任何客户端信息。
使用cookie面临的最大问题就是隐私数据安全问题，session作为辅助来解决这一问题。
| 特性 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端（浏览器本地文件或内存） | 服务器端（内存、数据库、文件等） |
| 存储内容 | 小型文本数据（键值对，通常 <4KB） | 任意类型数据（对象、字符串等，容量较大） |
| 安全性 | 较低（存储在客户端，可能被篡改或窃取） | 较高（存储在服务器，客户端仅获 session_id） |
| 生命周期 | 可设置过期时间（持久 Cookie）或会话结束后失效（会话 Cookie） | 通常随会话结束（如浏览器关闭）失效，或服务器设置超时时间 |
| 网络传输 | 每次请求自动携带在 HTTP 头中 | 仅通过 Cookie 或 URL 携带 session_id（核心标识） |
| 跨域限制 | 受域名、路径限制（同域才能访问） | 依赖 session_id 的传递，本质同 Cookie 限制 |
- 数据存储差异：Cookie 存储容量有限且仅支持文本，Session 可存储复杂对象。
- 安全机制：Session 通过服务端存储敏感数据，仅传递标识符（session_id），降低泄露风险。
- 生命周期控制：Cookie 的过期时间由客户端或代码显式设置，Session 通常依赖会话状态或服务端配置。
部分关键HTTP请求和响应头字段的表格内容
| 字段名 | 含义 | 样例 |
|---|---|---|
| Accept | 客户端可接受的响应内容类型 | Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 |
| Accept-Encoding | 客户端支持的数据压缩格式 | Accept-Encoding: gzip, deflate, br |
| Accept-Language | 客户端可接受的语言类型 | Accept-Language: zh-CN,zh;q=0.9,en;q=0.8 |
| Host | 请求的主机名和端口号 | Host: www.example.com:8080 |
| User-Agent | 客户端的软件环境信息 | User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/91.0.4472.124 |
| Cookie | 客户端发送的HTTP cookie信息 | Cookie: session_id=abcdefg12345; user_id=123 |
| Referer | 请求的来源URL | Referer: http://www.example.com/previous_page.html |
| Content-Type | 实体主体的媒体类型 | Content-Type: application/x-www-form-urlencoded 或 application/json |
| Content-Length | 实体主体的字节大小 | Content-Length: 150 |
| Authorization | 认证信息（如用户名和密码） | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==（Base64编码） |
| Cache-Control | 缓存控制指令 | 请求：Cache-Control: no-cache；响应：Cache-Control: public, max-age=3600 |
| Connection | 请求后是否保持连接 ，注意这是tcp的特性 | Connection: keep-alive 或 Connection: close |
| Date | 请求或响应的日期和时间 | Date: Wed, 21 Oct 2023 07:28:00 GMT |
| Location | 重定向的目标URL（与3xx状态码配合） | Location: http://www.example.com/new_location.html |
| Server | 服务器类型 | Server: Apache/2.4.41 (Unix) |
| Last-Modified | 资源的最后修改时间 | Last-Modified: Wed, 21 Oct 2023 07:20:00 GMT |
| ETag | 资源的唯一标识符（用于缓存） | ETag: "3f80f-1b6-5f4e2512a4100" |
| Expires | 响应过期的日期和时间 | Expires: Wed, 21 Oct 2023 08:28:00 GMT |
三、HTTP请求方法
在HTTP中最常用的就是GET和POST也就是相当于网络上的IO操作。而两者的区别在于一个是提交数据到请求行的uri上而一个是将数据放到正文中。
3.1 GET
- 作用：从服务器获取资源（如网页、图片、数据等）。
特点：- 请求参数附加在 URL 中（如 https://example.com/user?id=123），有长度限制（取决于浏览器和服务器）。不适合传输敏感信息（参数暴露在 URL 中）。
- 场景：浏览网页、查询数据（如搜索、获取用户信息）。
特性：指定资源经服务器端解析后返回响应内容。
3.2 POST
-作用：向服务器提交数据，通常用于创建新资源或修改服务器状态。
特点：
- 请求参数放在请求体（Body）中，无长度限制，可传输大量数据（如表单、JSON、文件）。
- 场景：用户注册、提交表单、上传文件、创建数据（如发布文章）。
特性：可以发送大量的数据给服务器，并且数据包含在请求体中。
四、HTTP状态码
由于当代的浏览器功能已经很强大了，所以对于状态码的解释和设置在前端上大部分都会忽略或者随便写状态码。
这里主要介绍下重定向的状态码
301 Moved Permanently（永久重定向）
含义：请求的资源已永久移动到新位置，新 URL 会在响应头的 Location 字段中返回。
特点：浏览器会缓存该重定向关系，后续请求相同 URL 时，会直接跳转到新地址（无需再次向原服务器请求）。
常用于网站域名变更（如 old.com 迁移到 new.com）、页面永久移除并替换为新页面。
示例：访问 https://old-domain.com/page 时，服务器返回 301 并指定 Location: https://new-domain.com/new-page，浏览器自动跳转到新地址。
302 Found（临时重定向，原 302 Moved Temporarily）
含义：请求的资源临时位于新位置，新 URL 在 Location 字段中返回，未来可能再次变更。
特点：浏览器不会缓存重定向关系，每次请求原 URL 都会先向服务器确认新地址。
历史上存在语义歧义（早期规范要求客户端不能修改请求方法，如 POST 被转为 GET，但现代浏览器通常会保留原方法）。
场景：临时维护页面跳转（如 site.com 临时跳转到 site.com/maintenance）、活动页面临时替换。