1. 防火墙的拦截逻辑

问题：A 与 B 建立长连接后，防火墙会拦截 B 返回给 A 的流量吗？

长连接的本质：

长连接（例如 TCP 连接）一旦建立，通信双方可以在这个连接上持续交换数据。TCP 连接在防火墙看来是一个 “状态连接”（stateful connection）：防火墙记录了连接的源 IP、目的 IP、端口以及连接状态（SYN、ESTABLISHED 等）。

① 状态感知型（Stateful）防火墙：

• 允许返回流量：如果 A 发起到 B 的连接（比如 TCP SYN），防火墙会允许 B 的返回流量（SYN-ACK、数据包）通过。
• 对 已建立的连接，防火墙默认允许返回流量。
• 如果 B 主动发起新连接到 A，防火墙会按规则拦截，除非允许入站。

举例：企业防火墙、云安全组通常采用。

② 无状态型（Stateless）防火墙

• 每个包单独检查，不维护连接状态。
• 规则只看源 IP/端口和目的 IP/端口，无法“记住”连接状态。
• 可以完全阻止 B 的流量进入 A，即使是响应已有连接也不例外（可能导致 TCP 拆包、重传）。

举例：Linux iptables 里 不使用 state/conntrack 的纯过滤规则。

# 拦截所有去 80 端口的请求
iptables -A OUTPUT -p tcp --dport 80 -j DROP

# 也可以使用 state 实现精确控制
# 放行新建到端口 80 的请求 或者 已建立的连接
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
# 只放行已建立连接的返回流量通过
iptables -A INPUT  -p tcp --sport 80 -m state --state ESTABLISHED     -j ACCEPT

2. Nginx 动态切换 upstream

问题：在 Nginx 动态切换 upstream 服务器的过程中，若某客户端请求已发送至原 upstream 但未得到即时回复，此时切换 upstream 后，该客户端是否仍可接收到来自原 upstream 的响应？

可以。Nginx 在重新加载配置（例如使用 nginx -s reload 命令）时，会启动新的 worker 进程来处理新请求，并且旧的 worker 进程会继续处理已经接收但尚未完成的请求。具体来说，Nginx 的 reload 操作不会中断现有的连接和请求处理，而是平滑地过渡到新的配置。

3. 就地升级 与 跨机器升级

① 就地升级 In-Place Upgrade：

通常是在一台机器上跑两个版本（旧版+新版），再通过端口或反向代理进行流量切换。

② 跨机器升级

两套机器（集群/实例）分别运行旧版本和新版本，然后切换流量。

• Blue-Green Deployment（蓝绿发布）
  一套是 Blue（当前运行），一套是 Green（新版本），切流量时完成升级。需要临时开新机器，升级完成后直接关掉旧机器不浪费资源。

• Canary Release（金丝雀发布）
  部分机器切到新版本，验证无误后逐步放量。

• Rolling Upgrade / Rolling Deployment（滚动升级）
  集群里逐台机器切换版本，整体不中断。

应用场景的区别：

• 金丝雀：适合 新功能/灰度发布。
• 蓝绿：适合 大升级/高风险变更。
• 滚动：适合 日常迭代。

4. Nginx 中 变更 upstream 与 变更路由 两种方案比较

① 变更 upstream：简单粗暴，适合单一服务的升级切换或蓝绿发布。

② 变更路由：策略灵活，适合大规模灰度发布和复杂流量治理。

Nginx 中灰度发布的方案实现：

基于 upstream 的权重也可以实现灰度发布，下面可以简单实现 10% 流量灰度到 v2：

upstream backend {
    server 10.0.0.1:8080 weight=9; # v1
    server 10.0.0.2:8080 weight=1; # v2
}

server {
    listen 80;

    location / {
        proxy_pass http://backend;
    }
}

基于请求头进行灰度发布

http {
    upstream v1 {
        server 10.0.0.1:8080;
    }
    upstream v2 {
        server 10.0.0.2:8080;
    }

    # 定义 map，根据请求头 X-Test 判断使用哪个 upstream
    map $http_x_test $backend {
        default v1;   # 默认走 v1
        v2      v2;   # 如果请求头是 v2，就走 v2
    }

    server {
        listen 80;

        location / {
            proxy_pass http://$backend;
        }
    }
}

5. Nginx 自带的故障转移 与 Keepalived 的故障转移 各自的适用场景

① Nginx 自带的故障转移

作用范围：Nginx upstream 内部的后端节点。

机制：如果某个后端失败（超时/连接失败/返回错误），Nginx 会自动切换到其他节点。

适用场景：单机内的后端服务故障转移（例如 Nginx 代理两台应用服务器）。

② Keepalived 的故障转移

作用范围：Nginx 实例之间 / 主机之间。

机制：Keepalived 监控服务（如 Nginx 进程存活、端口可用）。如果主节点挂了，VIP 会漂移到备节点。

适用场景：Nginx / HAProxy 本身高可用，以及 数据库主备切换。