【计算机网络】正/反向代理服务器，有状态/无状态应用

一、正向代理 vs 反向代理 对比表

对比项 正向代理 反向代理 代理对象 代理客户端（替用户向目标服务器请求） 代理服务器（替后端服务器接收用户请求） 用户感知 用户知道自己在使用代理（需手动配置代理） 用户不知道代理存在（直接访问代理服务器） 核心作用 隐藏用户真实IP、突破网络限制（如访问境外网站） 隐藏服务器真实IP、负载均衡、提高安全性 典型场景 访问被封锁的网站、规避地域限制 大型网站分流（如电商服务器集群）、保护后端服务器 举例 V2R、 Shadows 等代理工具 Nginx 转发请求到后端多台服务器

二、有状态应用 vs 无状态应用 对比表

对比项 有状态应用 无状态应用 状态存储 会保存用户历史交互数据（如登录状态、购物车） 不保存用户历史数据，每次请求独立处理 请求依赖 后续请求依赖之前的会话状态 每个请求自带所有必要信息，不依赖历史 扩展难度 难扩展（状态需同步到新服务器） 易扩展（新增服务器直接接收请求） 故障影响 服务器重启可能丢失状态（需重新登录/恢复） 服务器重启不影响（请求可重新发送） 典型例子 在线购物车、网银系统、即时通讯软件 搜索引擎（如百度）、天气API、静态网页服务

三、Nginx vs V2Ray 工具定位表

工具 核心定位 所属代理类型 主要功能 Nginx 高性能服务器软件 反向代理为主 1. 接收用户请求并转发到后端服务器（反向代理）；
2. 实现负载均衡（分配请求到多台服务器）；
3. 作为静态网页服务器 V2R 网络代理工具 正向代理为主 1. 替用户向目标服务器发送请求（正向代理）；
2. 加密流量以绕过网络封锁；
3. 隐藏用户真实网络轨迹

---

相关解释

正向代理

• 是客户端的“代言人”。当你无法直接访问目标网站时（比如被封锁），可以通过正向代理服务器去替你请求，目标网站只会看到代理服务器的IP，隐藏了你的真实身份。常见用途：突破网络限制、访问国外网站。

反向代理

• 是服务器的“保镖”。客户端直接访问的是反向代理服务器，但实际上请求会被转发到内部的真实服务器处理。用户并不知道真正提供服务的服务器是谁。常见用途：负载均衡、隐藏服务器真实IP、提高安全性。

Nginx

• 是一款高性能的反向代理服务器，也可作为负载均衡器、HTTP服务器使用。它能接收所有客户端请求，然后根据规则将请求转发给不同的后端服务器，常用于大型网站以提高性能和稳定性。

V2R

• 是一个网络代理工具，主要用作正向代理。它可以帮助用户绕过网络封锁，访问被限制的内容，通过加密流量来隐藏用户的网络活动。

有状态应用 vs 无状态应用

有状态应用
就像一个“记性好”的服务员。它会记住用户的历史交互信息（如登录状态、购物车内容），并且依赖这些信息来处理后续请求。如果服务器崩溃或重启，用户可能需要重新登录或恢复之前的操作。
例子：银行网银系统、在线购物车。

无状态应用
如同一个“只看当前菜单”的服务员。每个请求都是独立的，不依赖之前的会话信息。服务器不会存储用户的历史状态，每次请求都需要携带所有必要信息。这种设计使得应用更易于扩展和维护。
例子：搜索引擎、天气预报API。

---

有状态应用 vs 无状态应用（后端开发视角 + Java/Go 示例）

分类 核心特征 Java 示例 Go 示例 有状态应用 1. 服务器需存储用户会话状态（如登录信息、临时数据）
2. 后续请求依赖前序状态
3. 水平扩展需同步状态（如用Redis共享会话） 在线聊天室服务
- 场景：用户A向用户B发送消息，服务器需记录“两人正在聊天”的会话关系
- 实现：用HashMap在内存中存储用户-会话映射，或用Spring Session绑定用户登录状态到服务器
- 关键：若服务器重启，未持久化的会话会丢失，需重新建立连接 游戏房间服务
- 场景：玩家进入游戏房间后，服务器需记录“房间内玩家列表、当前游戏进度”
- 实现：用map[string]Room存储房间状态（Room结构体含玩家ID、分数等）
- 关键：新增服务器时，需将房间状态同步到新节点，否则玩家切换节点会丢失房间信息 无状态应用 1. 服务器不存储任何会话状态
2. 每个请求自带所有必要信息（如Token、参数）
3. 水平扩展无需同步（直接加服务器即可） 商品详情查询API
- 场景：用户请求/api/goods/{id}，只需传入商品ID即可返回详情
- 实现：用Spring Boot写接口，接收ID后直接查数据库，不存储任何用户相关数据
- 关键：即使重启服务器，下次请求只要ID正确，结果完全一致 订单支付结果回调接口
- 场景：支付平台回调/callback/pay，携带“订单号、支付状态、签名”等参数
- 实现：用Gin框架接收参数，验证签名后更新数据库，不保留任何回调历史
- 关键：多台服务器可同时接收回调，无需关心“之前是否处理过该订单”（由数据库保证唯一性）

补充说明（后端开发重点）

1. 状态的本质：是否依赖“服务器内存中的临时数据”。比如：
   • 有状态：依赖 Java的HttpSession 或 Go的内存map 存储的用户信息。
   • 无状态：依赖 JWT Token（客户端携带）或 数据库主键（请求参数携带）。
2. 扩展区别：
   • 有状态：加服务器时需用 Redis 等工具同步状态（如 Java 的 Spring Session + Redis 共享会话）。
   • 无状态：直接加服务器，通过 Nginx 负载均衡即可（无需额外配置）。
3. 常见误区：“读写数据库的应用就是有状态”——错！数据库是独立存储，服务器本身不存状态，仍算无状态（如上述商品API查数据库，但服务器内存不存数据）。

---

有状态应用：处理请求时依赖服务器本地存储的历史会话数据（如内存中的用户登录状态），换服务器可能丢失状态；
无状态应用：每个请求自带所有必要信息（如 Token、参数），不依赖服务器本地历史数据，换服务器不影响处理结果。

---

https://github.com/0voice

LRC歌词