1. HTTP 协议介绍

HTTP 协议是超文本传输协议，属于应用层协议，基于 TCP/IP 通信协议来传递数据，是无状态的协议。
HTTP 报文由起始行，首部以及数据主体三个部分

HTTP 请求方法

GET： 请求指定的页面信息，并返回实体主体
HEAD:： 类似于 get 请求，返回的内容不包含实体部分，用于获取报头
POST： 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）
PUT： 从客户端向服务器传送的数据取代指定的文档的内容
DELETE： 请求服务器删除指定的页面
OPTIONS：允许客户端查看服务器的性能。询问支持请求的方法
TRACE： 将服务器收到的请求回送到客户端，主要用于测试或诊断。

GET和POST对比

特性	GET	POST
​​语义​	获取资源	提交/修改数据
​​可缓存性​	可缓存	不可缓存
​​数据位置​	URL 中	请求体中
​​数据长度限制​	受 URL 长度限制（约 2048 字符）	无限制
参数显示	暴露在 URL 中	参数在请求体中不可见
书签​	可收藏为书签	不可收藏
后退/刷新​	无害	数据会重新提交（浏览器警告）

2. TCP/IP 协议

• TCP/IP 协议族是由一个四层协议组成的系统，这四层分别为：应用层、传输层、网络层和数据链路层

应用层： 一般是我们编写的应用程序，其决定了向用户提供的应用服务。（如 FTP、HTTP、DNS）等
传输层： 通过系统调用向应用层提供处于网络连接中的两台计算机之间的数据传输功能。（如 TCP、UDP）

• 应用层协议

  • 1. HTTP​​（超文本传输协议）：用于万维网服务
  • 2. FTP​​（文件传输协议）：用于交互式文件传输
  • 3. ​​SMTP​​（简单邮件传输协议）：用于电子邮件传送
  • 4. ​​DNS​​（域名系统）：实现域名到IP地址的映射
  • 5. SNMP​​（简单网络管理协议）：用于网络设备管理与监控
  • 6. ​​Telnet​​：实现远程登录功能
  • 7. ​SSH​​（安全外壳协议）：加密的安全远程登录
  • 8. ​​HTTPS​​：HTTP的安全版本（HTTP over SSL）
  • 9. NFS​​（网络文件系统

• 传输层协议

  • 1. TCP​​（传输控制协议）
  • 2. UDP​​（用户数据报协议）
  • 3. ​​SCTP​​（流控制传输协议）

TCP、UDP、HTTP/1.1 对比

特性	TCP (双向)	UDP (可单向)	HTTP/1.1 (半双工)
连接建立	需要三次握手	无连接	需要TCP连接
数据传输	同时双向	可单向发送	请求-响应轮流
可靠性	有确认机制	无确认	依赖TCP
流量控制	双向窗口	无	单向控制
典型应用	SSH、WebSocket	DNS查询、视频流	传统网页浏览

TIP

udp 和 tcp 的区别
1、TCP 是面向连接；UDP 是无连接的
2、TCP 提供可靠的服务(三次握手)，而 UDP 尽最大努力交付,TCP 不会出现丢包并且能够保证数据的顺序
3、TCP 传输的速度比 UDP 慢
4、TCP 适用于传输大量数据，而 UDP 适用于传输少量数据

3. TCP三次握手（建立连接）​

目的​​：确保客户端和服务端双方的发送和接收能力正常。

流程​​：

• ​第一次握手（SYN=1, seq=x）​​

  • 客户端发送 SYN 报文（同步序列号），并随机生成初始序列号 seq=x，进入 SYN_SENT 状态。
  • ​作用​​：服务端确认客户端的发送能力正常。

• 第二次握手（SYN=1, ACK=1, seq=y, ack=x+1）​​

  • 服务端收到 SYN 后，返回 SYN+ACK 报文，随机生成自己的序列号 seq=y，并确认客户端的序列号 ack=x+1，进入 SYN_RCVD 状态。
  • ​作用​​：客户端确认服务端的接收和发送能力正常。

• 第三次握手（ACK=1, seq=x+1, ack=y+1）​​

  • 客户端收到 SYN+ACK 后，发送 ACK 报文确认，序列号为 seq=x+1，确认号为 ack=y+1，进入 ESTABLISHED 状态。
  • 服务端收到 ACK 后也进入 ESTABLISHED 状态。
  • ​​作用​​：服务端确认客户端的接收能力正常。

• TCP flag表示TCP标志位，主要介绍两个ACK和SYN：
  • SYN同步序号，用于建立连接过程。
  • ACK确认序号标识，标识表示发送信息已确认接收。

为啥 TCP 需要三次握手，不是两次，四次？

TCP三次握手是为了确认双方的序列号，这就像一个发送—应答机制，客户端发序列号，服务端返回确认号，此时确认了客户端的序列号。

如果是两次握手，只能确认客户端的序列号，无法确认服务端的序列号。三次握手是确认两个序列号最小的连接次数。 四次也可以，但是没有必要，需要减少握手的次数，加快连接速度。

4. TCP 四次挥手（断开连接）

​目的​​：双方安全关闭连接，确保数据完整传输。

​流程​​：

• ​第一次挥手（FIN=1, seq=u）​​

  • 主动关闭方（客户端）发送 FIN 报文，序列号为 seq=u，进入 FIN_WAIT_1 状态。
  • ​作用​​：通知服务端“客户端不再发送数据”。

• ​​第二次挥手（ACK=1, ack=u+1）​​

  • 服务端收到 FIN 后，返回 ACK 报文，确认号为 ack=u+1，进入 CLOSE_WAIT 状态。
  • 客户端收到 ACK 后进入 FIN_WAIT_2 状态。
  • ​作用​​：服务端确认收到关闭请求，但可能还有数据未发送完。

• ​第三次挥手（FIN=1, ACK=1, seq=v, ack=u+1）​​

  • 服务端完成剩余数据发送后，发送 FIN+ACK 报文，序列号为 seq=v，进入 LAST_ACK 状态。
  • 作用​​：通知客户端“服务端也准备关闭”。 ​

• ​第四次挥手（ACK=1, ack=v+1）​​

  • 客户端收到 FIN 后，发送 ACK 报文，确认号为 ack=v+1，进入 TIME_WAIT 状态（等待 2MSL 后关闭）。
  • 服务端收到 ACK 后立即关闭连接。
  • ​作用​​：确保服务端收到最后的确认（防止 FIN 重传）。

​为什么需要四次挥手？​​

• TCP 是全双工的，需分别关闭两个方向的连接：
  • 客户端主动关闭发送方向（第一次挥手）。
  • 服务端确认后关闭接收方向（第二次挥手）。
  • 服务端再关闭自己的发送方向（第三次挥手）。
  • 客户端确认后完全关闭（第四次挥手）

为什么握手是三次，挥手是四次？​​

握手时，服务端的 SYN 和 ACK 可以合并发送；
而挥手时，服务端可能还有未发送完的数据，需先发 ACK 再发 FIN。

5.http 状态码

200 OK 服务器成功处理了请求（这个是我们见到最多的）
301/302 Moved Permanently（重定向）请求的 URL 已移走。Response 中应该包含一个 Location URL, 说明资源现在所处的位置
404 Not Found(页面丢失)未找到资源
501 Internal Server Error 服务器遇到一个错误，使其无法对请求提供服务

• 1 开头：（被接受，需要继续处理。）
   100：客户端继续请求
   101：客户端切换协议

• 2 开头：（请求成功）
   200：请求成功
   202：服务器已接受请求，但尚未处理
   204：服务器成功处理了请求，但未返回内容

• 3 开头：（请求被重定向）
   301：(永久重定向)
   302： (临时重定向)
   303：http1.1 协议，禁止被缓存
   304：(协商缓存成功（资源未修改）的返回值)

• 4 开头：（客户端请求错误）
   400：客户端请求的语法错误，服务器无法理解
   403：服务器理解请求客户端的请求，但是拒绝执行此请求(一般客户端没有权限)
   404：服务器无法根据客户端的请求找到资源（网页）

• 5 开头：（服务器错误）

6.http 和 https 的区别

http: 超文本传输协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从 WWW 服务器传输超文本到本地浏览器的传输协议
http 的默认端口：80
https 的默认端口：443
https 是在应用层(HTTP)和传输层(TCP)之间添加一个 SSL 的安全层

HTTPS 的缺点：

 （1）HTTPS 协议握手阶段比较费时，会使页面的加载时间延长近 50%，增加 10%到 20%的耗电
 （2）HTTPS 连接缓存不如 HTTP 高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响
 （3）SSL 证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
 （4）SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗

7. 浏览器输入 url 发生了什么

参考 (opens new window)

一、URL 解析阶段

1. ​地址栏输入处理​​

• 浏览器检查输入内容是否符合 URL 格式
• 如果不是有效 URL，可能作为搜索查询提交给搜索引擎

2. 解析 URL 结构​​

https://www.example.com:443/path/page.html?query=string#fragment
├─ 协议 https://
├─ 主机名 www.example.com
├─ 端口号 :443
├─ 路径 /path/page.html
├─ 查询参数 ?query=string
└─ 片段标识 #fragment

3. 检查 HSTS 列表

• 浏览器检查该域名是否在 HSTS (HTTP Strict Transport Security) 预加载列表中
• 如果在列表中，自动将 HTTP 请求转为 HTTPS

二、DNS 解析阶段

1. ​DNS 查询过程

查找浏览器自身缓存 => 查找本地 hosts 文件 => 本地域名服务器 => 根域名服务器..

2. ​​DNS 优化技术

• DNS 预解析 (<link rel="dns-prefetch">)
• DNS over HTTPS (DoH) 加密查询

三、建立 TCP 连接

1. ​TCP 三次握手

2. TLS 握手 (HTTPS)​​

• 客户端发送 ClientHello (支持的加密套件等)
• 服务器返回 ServerHello (选择的加密方式) + 证书
• 客户端验证证书，生成预主密钥
• 双方根据预主密钥生成会话密钥

四、发送 HTTP 请求

1. ​请求报文结构​

GET /path/page.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml
Accept-Language: en-US,en
Connection: keep-alive

2. ​现代浏览器优化​​

• HTTP/2 多路复用，避免队头阻塞
• 请求优先级设置
• 服务器推送 (Server Push)

五、服务器处理请求，并返回 HTTP 报文

​1. ​服务器端处理流程​​

• Web 服务器 (如 Nginx) 接收请求
• 静态资源直接返回
• 动态请求转发给应用服务器 (如 Node.js、PHP)
• 可能涉及数据库查询、缓存检查等

​2. 响应报文结构

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Content-Length: 138
Cache-Control: max-age=3600
Set-Cookie: sessionid=12345; Path=/

<!DOCTYPE html>
<html>...</html>

六、浏览器渲染阶段

详解参考：浏览器渲染 以及 重绘与回流 (opens new window)

8. 正向代理和反向代理

参考 (opens new window)

正向代理：

 正向代理类似一个跳板机，代理访问外部资源
 比如我们国内访问谷歌，直接访问访问不到，我们可以通过一个正向代理服务器，请求发到代理服，代理服务器能够访问谷歌，这样由代理去谷歌取到返回数据，再返回给我们，这样我们就能访问谷歌了

正向代理的用途：
 1、访问原来无法访问的资源，如google
 2、可以做缓存，加速访问资源
 3、对客户端访问授权，上网进行认证
 4、代理可以记录用户访问记录（上网行为管理），对外隐藏用户信息

反向代理：

 反向代理（Reverse Proxy）实际运行方式是指以代理服务器来接受internet上的连接请求，
 然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器

反向代理的作用：
 1、保证内网的安全，阻止web攻击，大型网站，通常将反向代理作为公网访问地址，Web服务器是内网
 2、负载均衡，通过反向代理服务器来优化网站的负载

总结：
 正向代理即是客户端代理, 代理客户端, 服务端不知道实际发起请求的客户端.
 反向代理即是服务端代理, 代理服务端, 客户端不知道实际提供服务的服务端

 正向代理: 买票的黄牛
 反向代理: 租房的代理

9. WebSocket 协议详解

WebSocket 是一种在 单个 TCP 连接 上进行 全双工通信 的协议，旨在解决 HTTP 协议在实时通信中的局限性。

WebSocket 的握手过程

• 1. 客户端发起 HTTP 升级请求

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

• Upgrade: websocket 表示希望升级到 WebSocket 协议。
• Sec-WebSocket-Key 是一个随机生成的 Base64 字符串，用于安全验证。

• 2. 服务器响应确认升级

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

• 101 Switching Protocols 表示协议升级成功。
• Sec-WebSocket-Accept 是服务器对客户端 Sec-WebSocket-Key 的计算结果，用于验证握手合法性。

10.HTTP 版本 以及 http1.1和http2.0的区别

​​HTTP 版本演进​

版本	发布时间	核心改进​
HTTP/0.9	1991	仅支持 GET 方法，无头部，纯文本
HTTP/1.0	1996	引入头部、状态码、多方法（POST等）
​​HTTP/1.1​	1997	持久连接、管道化、缓存优化
​HTTP/2​	2015	二进制协议、多路复用、头部压缩
HTTP/3​	2022	基于 QUIC（UDP），解决队头阻塞

HTTP/1.1 与 HTTP/2 核心区别​

• 1. 传输方式

特性	HTTP/1.1	HTTP/2
数据格式​​	文本格式（明文）	二进制帧（Frame）
连接复用​	需多个 TCP 连接（6-8个并行限制）	单连接多路复用（Stream 并行）实际实现通常100+

• 2. 性能优化​

特性	HTTP/1.1	HTTP/2
​​队头阻塞（HOL）​	存在（管道化未彻底解决）	彻底解决（Stream 独立处理）
头部压缩​	重复发送完整头部	HPACK 压缩（减少 90% 头部体积）
​​服务器推送​	不支持	可主动推送资源（如 CSS/JS）

​​现代浏览器​​：默认支持 HTTP/2（需 HTTPS）。

多路复用（Multiplexing）​

// HTTP/1.1：顺序请求（队头阻塞）
请求1 → 响应1 → 请求2 → 响应2

// HTTP/2：并行处理
请求1 → 响应1
请求2 → 响应2 （同一连接）