文章目录
-
- [一、 HTTP 请求方法深度对比](#一、 HTTP 请求方法深度对比)
-
- [1. GET vs POST](#1. GET vs POST)
- [2. POST vs PUT](#2. POST vs PUT)
- [二、 HTTP 协议版本](#二、 HTTP 协议版本)
- [三、HTTP 与 HTTPS 之间区别](#三、HTTP 与 HTTPS 之间区别)
- [四、当在浏览器中输入 Google.com 并且按下回车之后发生了什么？](#四、当在浏览器中输入 Google.com 并且按下回车之后发生了什么？)
- [五、HTTP 缓存策略](#五、HTTP 缓存策略)
-
- [1. 强缓存 (不发请求)](#1. 强缓存 (不发请求))
- [2. 协商缓存 (发请求询问)](#2. 协商缓存 (发请求询问))
- [六、HTTP 报文结构](#六、HTTP 报文结构)
-
- [1. HTTP 请求报文 (Request)](#1. HTTP 请求报文 (Request))
- [2. HTTP 响应报文 (Response)](#2. HTTP 响应报文 (Response))
- [七、 URL 的解构](#七、 URL 的解构)
- [八、HTTP 协议的优缺点](#八、HTTP 协议的优缺点)
- [九、OSI 七层模型](#九、OSI 七层模型)
- 十、TCP/IP五层协议
- [十一、TCP 与 UDP](#十一、TCP 与 UDP)
-
- [1. UDP (User Datagram Protocol) ------ 用户数据报协议](#1. UDP (User Datagram Protocol) —— 用户数据报协议)
- [2. TCP (Transmission Control Protocol) ------ 传输控制协议](#2. TCP (Transmission Control Protocol) —— 传输控制协议)
- [3. 深度对比：TCP vs UDP](#3. 深度对比：TCP vs UDP)
- [4. 应用场景的选择](#4. 应用场景的选择)
- [十二、 三次握手与四次挥手](#十二、 三次握手与四次挥手)
-
- [1. 三次握手：同步与确认](#1. 三次握手：同步与确认)
- [2. 四次挥手](#2. 四次挥手)
- 十三、WebSocket
-
- [1. 深度理解 WebSocket](#1. 深度理解 WebSocket)
- [2. 即时通讯方案比较](#2. 即时通讯方案比较)
- [3. WebSocket 实战代码片段](#3. WebSocket 实战代码片段)
一、 HTTP 请求方法深度对比
1. GET vs POST
- 幂等性：GET 是幂等的（多次执行结果相同），POST 是非幂等的（多次执行会创建多个资源）
- 安全性：GET 参数暴露在 URL 中，会被浏览器历史记录保留；POST 数据在 Body 中，相对更私密
- 缓存：GET 默认可缓存；POST 除非特别设置，否则不缓存
2. POST vs PUT
- POST：侧重于"新建"，向服务器发送数据以创建新资源
- PUT：侧重于"更新"，通过发送完整数据来修改现有资源。PUT 也是幂等的
二、 HTTP 协议版本
| 版本 | 核心改进 | 解决的问题 |
|---|---|---|
| HTTP 1.0 | 基本请求-响应模式 | 建立基础连接 |
| HTTP 1.1 | 持久连接 (Keep-Alive)、断点续传、Host 字段 | 减少 TCP 建连开销，支持虚拟主机 |
| HTTP 2.0 | 多路复用、二进制分帧、首部压缩 (HPACK)、服务器推送 | 解决"队头阻塞"，提高并发效率 |
| HTTP 3.0 | 基于 UDP 的 QUIC 协议、0-RTT 建连 | 彻底解决 TCP 层的队头阻塞，提升移动端连接稳定性 |
三、HTTP 与 HTTPS 之间区别
| 维度 | HTTP (HyperText Transfer Protocol) | HTTPS (HTTP over SSL/TLS) |
|---|---|---|
| 安全性 | 明文传输，内容可能被窃听或篡改。 | 加密传输，确保数据的私密性与完整性。 |
| 证书 | 无需证书。 | 需要从 CA（数字证书认证机构） 申请证书。 |
| 默认端口 | 80 | 443 |
| 身份认证 | 无，无法确认对方真实身份。 | 有，通过证书验证服务器身份，防止钓鱼。 |
四、当在浏览器中输入 Google.com 并且按下回车之后发生了什么？
- 解析URL： 首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径
- 缓存判断： 浏览器会判断所请求的资源是否在缓存里，如果请求的资源在缓存里并且没有失效，那么就直接使用，否则向服务器发起新的请求
- DNS解析： 下一步首先需要获取的是输入的 URL 中的域名的 IP 地址，首先会判断本地是否有该域名的 IP 地址的缓存，如果有则使用，如果没有则向本地 DNS 服务器发起请求。本地 DNS 服务器也会先检查是否存在缓存，如果没有就会先向各级域名服务器发起请求，最终获得域名的 IP 地址后，本地 DNS 服务器再将这个 IP 地址返回给请求的用户
- 获取MAC地址： 当浏览器得到 IP 地址后，通过 ARP 协议来询问目标 IP 的 MAC
- TCP三次握手： 首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态
- HTTPS握手： 如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程
- 返回数据： 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程
- 页面渲染： 浏览器首先会根据 html 文件构建 DOM 树，根据解析到的 css 文件构建 CSSOM 树。当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树（Render Tree ）。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制
- TCP四次挥手： 若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，当前服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（60s 最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态
五、HTTP 缓存策略
1. 强缓存 (不发请求)
Cache-Control:max-age=3600(HTTP/1.1 推荐，相对时间)Expires: 绝对时间 (HTTP/1.0，受限于本地时间)
2. 协商缓存 (发请求询问)
- Etag / If-None-Match: 基于内容 Hash，最精确
- Last-Modified / If-Modified-Since: 基于最后修改时间，秒级精度
六、HTTP 报文结构
HTTP 报文是前后端交互的载体。无论是请求还是响应，它们都遵循相似的四段式结构
1. HTTP 请求报文 (Request)
- 请求行 ：告诉服务器"干什么、去哪干、按什么规矩干"（如
POST /login HTTP/1.1） - 请求头 ：补充信息。如
Host（目标域名）、User-Agent（什么浏览器）、Cookie（身份凭证） - 空行：法定的分隔符，告诉服务器"头结束了，下面是正文"
- 请求体：具体的负载数据（如登录时的用户名密码）
2. HTTP 响应报文 (Response)
- 状态行 ：告诉客户端"结果如何"（如
HTTP/1.1 200 OK） - 响应头 ：服务器信息。如
Content-Type（数据类型）、Set-Cookie（种下凭证） - 空行：分隔符
- 响应体：服务器回传的实际内容（HTML、图片、JSON 等）
七、 URL 的解构
URL（统一资源定位符）就像是一个坐标，指引浏览器找到互联网上的特定资源
以 http://www.example.com:80/news/index.html?id=10#top 为例：
- 协议 (
http://)：通信的语言 - 域名 (
www.example.com)：服务器的名字 - 端口 (
:80)：服务器的"房号"。HTTP 默认 80，HTTPS 默认 443 - 路径 (
/news/index.html)：资源在服务器上的物理或逻辑位置 - 查询参数 (
?id=10)：传递给服务器的额外指令 - 锚点 (
#top)：页面内的"书签"，不会发送给服务器，仅由浏览器跳转位置
八、HTTP 协议的优缺点
优点
- 简单灵活：报文清晰易懂，且能传输任何类型的数据（图片、视频、文本）
- 无连接 ：处理完即断开，节省服务器维持连接的资源（注：HTTP/1.1 后通过
Keep-Alive优化） - 无状态：服务器不记得你是谁，处理速度快，适合大规模并发
缺点
- 无状态（双刃剑）：需要借助 Cookie/Session 才能实现登录状态保持
- 明文传输：数据在网络中"裸奔"，极易被窃听（Wireshark 抓包可见）
- 不安全：不验证对方身份（可能连到伪造网站），不验证内容完整性（数据可能被篡改）
九、OSI 七层模型
-
应用层 (Application)：直接为用户提供网络服务（HTTP, FTP, SMTP, DNS）
-
表示层 (Presentation)：负责数据格式化、加密解密、压缩解压（如 Base64 编解码、JSON 转化）
-
会话层 (Session)：负责建立、管理和终止应用程序间的会话连接
-
传输层 (Transport) ：解决数据怎么发的问题（TCP 可靠传输、UDP 尽力而为），关注的是端口
-
网络层 (Network)：负责 IP 寻址和路由选择，决定数据包走哪条路
-
数据链路层 (Data Link) ：将比特流封装成帧 ，通过 MAC 地址在物理媒介上进行差错检测
-
物理层 (Physical)：传输 0 和 1 的电信号，涉及网线、光纤、集线器等硬件
十、TCP/IP五层协议
- 应用层：整合了 OSI 的上三层（应用、表示、会话）
- 传输层 ：核心协议是 TCP （面向连接，稳）和 UDP（无连接，快）
- 网络层 ：核心协议是 IP
- 数据链路层：主要负责物理寻址（ARP 协议在此工作）
- 物理层：最底层的物理介质
十一、TCP 与 UDP
1. UDP (User Datagram Protocol) ------ 用户数据报协议
- 特点解析
- 无连接：像寄平信，不需要预先建立连接，想发就发
- 面向报文：不拆分、不合并，保留应用层交下来的报文边界。应用层给多大，UDP 就发多大
- 不可靠但实时 ：没有确认机制，没有重传。即使网络拥塞，它也按恒定速率发送。这使得它在视频会议、在线游戏等对延迟敏感的场景中表现卓越
- 开销极小 ：头部仅 8 字节，包含源端口、目的端口、长度和校验和
2. TCP (Transmission Control Protocol) ------ 传输控制协议
- 特点解析
- 面向连接：发送数据前必须进行"三次握手"，确保双方都准备好了
- 可靠传输 ：
- 序列号与确认应答 (ACK)：给每个包编号，收到后回传确认
- 超时重传：没收到确认就重发
- 流量控制与拥塞控制：通过"滑动窗口"调整发送速度，防止把网络或接收方"压垮"
- 面向字节流：数据像水流一样传输，没有明确的边界
- 全双工：双方可以同时收发数据
3. 深度对比：TCP vs UDP
| 特性 | UDP | TCP |
|---|---|---|
| 连接性 | 无连接 | 面向连接 |
| 可靠性 | 不可靠，尽力而为 | 可靠，保证不丢、不重、不乱 |
| 传输单位 | 报文（保留边界） | 字节流（无边界） |
| 首部开销 | 8 字节 (固定) | 20~60 字节 (变长) |
| 通信目标 | 一对一、一对多、多对多 | 只能一对一 |
| 拥塞控制 | 无，不减速 | 有，根据网络状况动态调整 |
4. 应用场景的选择
- 什么时候选 TCP？
- 对数据准确性要求 100% 的场景
- 例如：浏览器网页 (HTTP/HTTPS) 、文件传输 (FTP) 、邮件 (SMTP) 、远程登录 (SSH)。在这些场景中，丢一个字节都可能导致文件损坏或登录失败
- 什么时候选 UDP？
- 对实时性要求高，能容忍少量丢包的场景
- 例如：视频直播/会议 （卡一下能接受，重发旧帧没意义）、语音通话 、在线竞技游戏 （位置同步需要极低延迟）、DNS 查询（请sh求小，UDP 更快）
十二、 三次握手与四次挥手
1. 三次握手：同步与确认
三次握手是为了解决"网络延迟导致旧连接重连"和"同步初始化序列号（ISN）"的问题
流程拆解
- 第一次握手 (SYN=1, seq=x) ：客户端发送连接请求。意义：证明客户端有发送能力
- 第二次握手 (SYN=1, ACK=1, seq=y, ack=x+1) ：服务端收到并同意连接，发回确认。意义：证明服务端有接收能力和发送能力
- 第三次握手 (ACK=1, seq=x+1, ack=y+1) ：客户端再次确认。意义：证明客户端有接收能力，且双方序列号已同步
为什么两次不行？
- 防止失效的连接请求突然传送到服务端：如你所说，网络拥堵可能导致旧的请求在连接释放后才到达。如果没有第三次握手，服务端一发回确认连接就建立了，会导致服务端一直等待一个早已不存在的客户端，白白浪费资源
2. 四次挥手
TCP 是全双工的，这意味着客户端和服务器都能同时收发数据。断开时，每一方都要单独关闭自己的发送通道
流程拆解
- 第一次挥手 (FIN=1, seq=u) ：客户端告诉服务端："我没数据要发了。"（客户端进入
FIN_WAIT1） - 第二次挥手 (ACK=1, ack=u+1, seq=v) ：服务端回复："收到，但我可能还有数据没发完，你等我一下。"（此时处于半关闭 状态，服务端进入
CLOSE_WAIT） - 第三次挥手 (FIN=1, ACK=1, ack=u+1, seq=w) ：服务端发完了，告诉客户端："好了，我也可以关了。"（服务端进入
LAST_ACK） - 第四次挥手 (ACK=1, ack=w+1, seq=u+1) ：客户端回复："收到，拜拜。"（客户端进入
TIME_WAIT）
为什么需要四次？
- 异步性：当服务端收到 FIN 时，它可能还有数据在缓冲区没发完。它只能先回一个 ACK 告知已收到，等自己处理完了再发 FIN
十三、WebSocket
1. 深度理解 WebSocket
WebSocket 是一种在单个 TCP 连接上进行全双工通信的协议
WebSocket原理：
客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件
核心优势
- 双向性：服务器可以主动"推"，客户端可以主动"发"
- 轻量化：连接建立后，数据包头部非常小（通常只有几个字节），远小于 HTTP 报头
- 低延迟：不需要频繁建立和断开连接
2. 即时通讯方案比较
| 技术 | 机制 | 优点 | 缺点 |
|---|---|---|---|
| 短轮询 (Polling) | 客户端定时（如每 5s）发 HTTP 请求。 | 兼容性极好，实现简单。 | 大量无效请求，浪费带宽和 CPU。 |
| 长轮询 (Long Polling) | 服务器收到请求后"挂起"，有数据才返回。 | 比短轮询节省资源。 | 服务器连接依然被占用，体验有延迟。 |
| SSE (Server-Sent Events) | 基于 HTTP，服务器持续发送"流"数据。 | 实现简单，自动重连，支持轻量推。 | 单向（仅服务器到客户端），IE 不支持。 |
| WebSocket | 独立协议，全双工持久连接。 | 全双工，性能最优，延迟最低。 | 实现相对复杂，需考虑心跳检测。 |
3. WebSocket 实战代码片段
客户端 (浏览器端)
javascript
const socket = new WebSocket('ws://chat.example.com');
// 连接成功
socket.onopen = () => socket.send('Hello Server!');
// 接收消息
socket.onmessage = (event) => console.log('收到：', event.data);
// 关闭连接
socket.onclose = () => console.log('连接已关闭');