HTTP协议
HTTP（HyperText Transfer Protocol，超文本传输协议）是互联网上应用最广泛的网络协议。它定义了浏览器（客户端）与服务器之间交换数据的格式和规则。
基本特征
- 应用层协议：运行在 TCP/IP 协议栈的应用层，底层通常使用 TCP 作为传输协议。
- 无连接（Connectionless）：每次请求都建立一次连接,限制每次连接只处理一个请求。服务器处理完请求并收到客户端应答后即断开连接（HTTP/1.1 通过 Keep-Alive 实现了连接复用）。
- 无状态（Stateless）：协议对于事务处理没有记忆能力。每次请求都是独立的，服务器不知道当前请求和上个请求是否来自同一用户（服务器不保存客户端状态,通常使用 Cookie/Session 解决）。
- 媒体独立：只要客户端和服务器知道如何处理数据内容，任何类型的数据都可以通过HTTP 发送（由 Content-Type 决定）。
HTTP报文结构
- HTTP 报文分为请求报文和响应报文，两者结构高度统一。
- 请求报文 (Request)
- 请求行：方法（GET/POST等） + URL + 协议版本。
- 请求头(headers)：键值对形式，如 Host, User-Agent, Cookie。
- 空行：必须存在，用于分隔头部和主体。
- 请求体(body)：提交的数据（如表单数据、JSON）。
- 响应报文 (Response)
- 响应行：协议版本 + 状态码 + 状态描述（如 HTTP/1.1 200 OK）。
- 响应头：如 Content-Type, Set-Cookie, Server。
- 空行：分隔符。
- 响应体：服务器返回的数据（如 HTML 源码、图片二进制）。
常见请求方法
| 方法 |
描述 |
幂等性 |
| GET |
请求获取资源，参数在 URL 中，有长度限制 |
是 |
| POST |
提交数据（如注册、上传），数据在 Body 中 |
否 |
| PUT |
传输并替换指定资源 |
是 |
| DELETE |
删除指定资源 |
是 |
| HEAD |
只获取响应头，不获取 Body |
是 |
| OPTIONS |
查询服务器支持的方法 |
是 |
HTTP状态码
- 1xx：信息性提示，表示请求已接收，继续处理。
- 2xx：成功（如 200 OK, 201 created）。
- 3xx：重定向（如 301 永久移除, 302 临时移动, 304 使用缓存）。
- 4xx：客户端错误（如 403 禁止访问, 404 找不到资源）。
- 5xx：服务器错误（如 500 内部错误, 503 服务不可用）。
- 常见请求头:Host,User-Agent,Accept,Content-Type,Authorization,Cookie
- 常见响应头:Content-Type,Content-Length,Set-Cookie,Cache-Control,Location
HTTP 与 HTTPS 的区别
- HTTPS 是在 HTTP 的基础上加入了 SSL/TLS 安全层。
| 对比项 |
HTTP |
HTTPS |
| 是否加密 |
否 |
是 |
| 端口 |
80 |
443 |
| 安全性 |
低 |
高 |
| 证书 |
无 |
有 SSL/TLS |
HTTPS 的加密流程
HTTPS 的加密流程（即 SSL/TLS 握手）是其安全性的核心。它巧妙地结合了非对称加密（解决密钥分发问题）和对称加密（解决大规模数据传输效率问题）。
- 客户端发起请求 (Client Hello)：客户端（浏览器）向服务器发送一个消息。
- 内容：支持的协议版本（如 TLS 1.2/1.3）、支持的加密套件列表（Cipher Suites）以及一个随机数 A。
- 服务器响应 (Server Hello)：服务器从中选择一套加密算法，并回复客户端。
- 内容：确定的协议版本和加密套件、一个随机数 B。
- 发送证书：服务器还会发送自己的数字证书（包含服务器的公钥和CA机构的签名）。
- 客户端验证证书
- 客户端收到证书后，会通过内置在操作系统中的CA（证书颁发机构）根证书来验证该证书的合法性：检查证书是否过期、域名是否匹配、签名是否有效。
- 风险提示：如果验证不通过，浏览器会弹出警告。
- 生成预主密钥 (Pre-Master Secret)
- 证书验证通过后客户端会生成第三个随机数 C（称为 Pre-Master Secret）。客户端使用证书里的服务器公钥对随机数 C 进行加密，并发送给服务器。
- 服务器解密并合成会话密钥
- 服务器使用自己的私钥解密，得到随机数 C。
- 生成最终密钥：此时，客户端和服务器都拥有了相同的三个随机数（A、B、C）。双方通过约定的算法，将这三个随机数混合生成同一个“会话密钥”（Session Key）。
- 握手结束，开始对称加密传输
- 确认：双方各发一个“加密通信开始”的消息，并用刚刚生成的“会话密钥”加密一段测试数据。
- 数据传输：如果双方都能成功解密，说明握手成功。后续所有的 HTTP 请求和响应数据，都将使用这个会话密钥进行对称加密传输。
为什么不用非对称加密传数据
- 非对称加密计算开销大
- 对称加密速度快
- 所以：非对称加密用于密钥交换，对称加密用于数据传输
UDP的报文结构和注意事项
UDP（User Datagram Protocol）是一种 传输层、无连接、面向报文、不可靠的通信协议。
- UDP报文结构
- UDP首部非常短小，仅占用8个字节。它由4个字段组成，每个字段固定占用2字节（16 位）。
| 字段名称 |
长度 |
作用说明 |
| 源端口 (Source Port) |
2 字节 |
发送方的端口号，不需要回信时可全为 0。 |
| 目的端口 (Dest Port) |
2 字节 |
接收方的端口号。 |
| 长度 (Length) |
2 字节 |
UDP 报文的总长度（首部 + 数据），单位为字节。 |
| 校验和 (Checksum) |
2 字节 |
检测 UDP 报文在传输过程中是否出错。若出错则直接丢弃。 |
- UDP的核心特性
- 无连接：发送数据前不需要建立连接（没有三次握手），发送结束后也没有连接释放。
- 不保证可靠交付，没有确认机制（ACK），没有重传机制。
- 无拥塞控制：网络出现拥塞时，UDP不会降低发送速率。这对于某些实时应用（如视频会议）很重要，因为即使丢包，也要保证实时性。
- 支持多种交互：支持一对一、一对多（广播）、多对一和多对多的交互通信。
- 使用注意事项
- 不可靠，需要应用层自己保证，UDP 不提供：重传机制，顺序保证，确认机制
- UDP报文大小限制，UDP报文最大长度是65535字节
- IP分片问题：
- UDP报文过大 → IP层分片
- 任意一个分片丢失 → 整个报文丢失
- 顺序与重复问题，报文可能：乱序，重复，丢失
- 由于没有拥塞控制，高速发送UDP包可能会瞬间填满网络带宽，导致同一网络下的其他TCP连接极度缓慢。
TCP与UDP的区别请看另一篇博客