4. HTTP/HTTPS 启动加速：HTTP vs TFTP 性能对比、Web 服务器配置、缓存策略、并发下载优化

聊到网络启动，很多人第一反应还是 TFTP。这玩意儿确实经典，但说实话，在千兆甚至万兆网络环境下，TFTP 已经成了明显的瓶颈。我这些年经手过的项目，但凡启动镜像超过 200MB，基本都从 TFTP 迁移到了 HTTP 或 HTTPS。今天我们就来掰扯掰扯，为什么 HTTP 更快，以及怎么把它配置到极致。

4.1 HTTP vs TFTP：性能差距到底在哪？

先看一组我在实验室里实测的数据。测试环境是千兆直连，客户端从空载状态请求一个 500MB 的 vmlinuz + initrd 组合镜像。

协议	传输方式	单文件吞吐	并发能力	完成时间（500MB）
TFTP	停等协议（lock-step）	~8 MB/s	无（单线程）	~62 秒
HTTP/1.1	流水线 + 持久连接	~85 MB/s	支持 Range 分片	~6 秒
HTTPS/2	多路复用 + 头部压缩	~92 MB/s	原生多流并发	~5.5 秒

为什么会差这么多？核心原因就一个：TFTP 是停等协议。每次发一个 512 字节的数据块，必须等 ACK 回来才能发下一个。网络延迟每增加 1ms，吞吐就掉一截。而 HTTP 基于 TCP，有滑动窗口、有拥塞控制，说白了就是可以一口气发一堆数据，不用等。

我记得有一次帮客户排查 PXE 启动超时问题。他们的 initrd 有 1.2GB，用 TFTP 每次都要等 3 分钟以上，然后 DHCP 租约都过期了。换成 HTTP 后，启动时间直接降到 15 秒以内。嗯，这就是协议本身的差距。

4.2 Web 服务器选型与配置

HTTP 启动的服务器端，我推荐三个选择：Nginx、Lighttpd、Apache。个人习惯首选 Nginx，原因很简单——它的 epoll 模型在处理大量并发小文件时优势明显。

下面是一个经过生产验证的 Nginx 配置模板，专门为 PXE/iPXE 启动场景优化：

server {
    listen 80;
    root /var/lib/tftpboot;

    # 关闭访问日志，减少磁盘 I/O
    access_log off;
    error_log /var/log/nginx/pxe_error.log warn;

    # 关键：禁用 sendfile 对大文件的影响
    sendfile on;
    tcp_nopush on;

    # 针对启动镜像的缓存策略
    location ~* \.(vmlinuz|initrd|img|iso|efi)$ {
        # 启动镜像不缓存，避免客户端拿到过期版本
        add_header Cache-Control "no-store, no-cache, must-revalidate";
        # 允许 Range 请求，支持分片下载
        add_header Accept-Ranges bytes;
        # 大文件超时时间适当延长
        proxy_read_timeout 300s;
    }

    # 针对配置文件（如 boot.ipxe）的缓存策略
    location ~* \.(ipxe|txt|conf)$ {
        add_header Cache-Control "public, max-age=60";
    }
}

4.3 缓存策略：不是所有文件都该缓存

很多人一上来就给所有启动文件设置长缓存。这其实是个坑。你想想看，vmlinuz 和 initrd 每次构建都可能变化，如果客户端缓存了旧版本，启动到一半崩溃了，你找谁哭去？

我的策略是分三类：

• 不可缓存（no-store）：vmlinuz、initrd、ISO 镜像。这些文件每次启动都必须从服务器拉最新版。
• 短时缓存（max-age=60~300）：boot.ipxe、grub.cfg 等配置文件。允许客户端在几分钟内复用，减少重复请求。
• 长期缓存（max-age=86400）：字体文件、背景图片、UEFI 驱动等静态资源。这些几乎不变，缓存了能大幅减少并发压力。

另外，ETag 和 Last-Modified 一定要开。它们能让客户端用条件请求（If-None-Match / If-Modified-Since）来验证文件是否更新，而不是每次都全量下载。我在一个 500 台终端的项目中，靠这个把服务器带宽消耗降低了 70%。

4.4 并发下载优化：让客户端跑满带宽

单个 HTTP 连接下载大文件，其实很难跑满千兆。原因在于 TCP 的慢启动和窗口限制。解决方案有两个方向：

4.4.1 服务端：启用 HTTP Range 分片

iPXE 原生支持 Range 请求。客户端可以同时发起 4~8 个 TCP 连接，每个连接下载文件的不同片段。配置上只需要确保服务器返回 Accept-Ranges: bytes 即可。Nginx 默认就支持。

我建议在 iPXE 脚本中显式设置并发数：

# 设置并发下载线程数
set concurrency 8
# 启用 HTTP Range 分片
set http-range enabled
# 下载内核
kernel http://192.168.1.100/boot/vmlinuz
# 下载 initrd
initrd http://192.168.1.100/boot/initrd.img
boot

4.4.2 客户端：调整 iPXE 的 TCP 缓冲区

iPXE 默认的 TCP 窗口很小，只有 64KB。对于千兆网络，这远远不够。我习惯把它调到 1MB：

# 在 iPXE 编译时或脚本中设置
set tcp-window 1048576
# 同时增大重传超时，避免丢包时频繁重传
set tcp-timeout 5000

4.5 HTTPS 启动：要不要上？

HTTPS 启动的核心价值是安全——防止中间人篡改启动镜像。但代价也很明显：TLS 握手会增加 1~3 个 RTT 的延迟，而且 iPXE 的 TLS 实现比较轻量，不支持硬件加速，加解密会消耗 CPU。

我的建议是：

• 内网环境：用 HTTP 就够了。你想想看，攻击者都物理接入你的内网了，那问题已经不是 HTTPS 能解决的了。
• 跨公网或混合云启动：必须上 HTTPS。我曾经帮一个金融客户做灾备启动方案，他们的要求就是所有启动流量必须加密，否则合规过不了。

如果决定上 HTTPS，记得用 自签名证书 + iPXE 内嵌 CA 的方式，避免在启动阶段依赖外部 CA 验证。证书有效期设长一点，比如 10 年，省得每年都要重新编译 iPXE。

4.6 整体架构一览

下面这张图展示了 HTTP/HTTPS 启动场景下的核心组件和数据流。我把它画成了流程图，方便你理解整个链路。

4.7 实战调优清单

最后，我整理了一份快速检查清单。每次部署 HTTP 启动环境时，按这个顺序过一遍，基本不会出大问题：

1. 确认网络环境：千兆有线还是百兆？丢包率多少？这决定了 TCP 窗口大小和并发数。
2. 选择 Web 服务器：Nginx 优先，Lighttpd 次之。Apache 在超高并发下表现一般。
3. 配置缓存策略：启动镜像 no-store，配置文件 max-age=60，静态资源 max-age=86400。
4. 开启 Range 分片：服务端确认 Accept-Ranges，客户端设置 concurrency 4~8。
5. 调整 TCP 参数：iPXE 中 tcp-window 设为 256KB~1MB，根据网络质量动态调整。
6. 测试并发极限：用 10 台客户端同时启动，观察服务器 CPU 和带宽。如果 CPU 超过 80%，考虑加缓存或升级硬件。
7. 安全加固：内网用 HTTP，外网用 HTTPS。自签名证书记得内嵌到 iPXE 固件中。