去年冬天，下载我在一台老旧的下载 CentOS 7 服务器上部署了一个静态博客。文件传完了，下载Nginx 也跑起来了，下载但打开浏览器输入 IP 之后，下载页面空白一片。下载我盯着那个空白的下载窗口愣了几秒，然后才反应过来——我压根没配下载路径的下载权限。

这件事让我意识到，下载web 服务器下载这件事，下载表面上看就是下载把文件从服务器传到用户电脑上，但中间要经过的下载环节比大多数人想象的多。你写一个 wget http://example.com/file.zip，下载这条命令背后至少发生了五件事：DNS 解析、下载TCP 握手、下载HTTP 请求、服务器读取文件、数据分块传输。任何一个环节卡住，下载就断了。

HTTP 不是唯一的选择，但它是默认的

绝大多数 web 下载走的是 HTTP 或 HTTPS。浏览器输入一个文件链接，服务器返回 Content-Type 和 Content-Length，浏览器根据这些头信息决定是直接打开还是弹出保存对话框。这里有个细节容易被忽略：如果服务器没有正确设置 Content-Disposition，浏览器可能会尝试在标签页里直接渲染文件。PDF 还好，顶多是在线预览；但如果是 .exe 或者 .apk，浏览器直接下载反而更安全。

我见过一个案例：某公司的内部文档服务器用 Python 的 http.server 模块临时搭的，结果所有 .docx 文件在 Chrome 里都变成了乱码预览。原因就是那个模块默认不发送 Content-Disposition: attachment，浏览器只能猜。后来换成 Nginx，加了一行 add_header Content-Disposition "attachment"; 就解决了。

断点续传不是每个服务器都支持

下载大文件的时候，断点续传是刚需。但服务器端要支持 Range 请求头才行。Nginx 默认开启，Apache 需要 mod_headers 配合，而很多用 Flask 或 Express 手写的下载接口压根没处理这个头。用户下载到 80% 断网了，只能从头再来。

我自己写过一个 Go 的下载服务，一开始没处理 Range，结果一个 2GB 的镜像文件被用户骂了三次。后来加上 http.ServeContent，它自动处理了范围请求和 If-Modified-Since，代码反而更短了。这件事告诉我：能用标准库就别自己造轮子，尤其是涉及 HTTP 协议细节的时候。

带宽和并发是两回事

很多人以为服务器下载慢就是带宽不够。其实并发连接数、磁盘 I/O、甚至 TCP 拥塞控制算法都会影响下载速度。我做过一次测试：同一台服务器，用 ab 压测 100 个并发下载，Nginx 的 sendfile 开启和关闭，吞吐量差了将近 40%。sendfile 让内核直接把文件从磁盘缓冲区送到网卡，省掉了用户态和内核态之间的数据拷贝。

另一个容易被忽视的点是 gzip。对文本文件开 gzip 能显著减小传输体积，但对已经压缩过的 .zip 或 .jpg 再压一遍，纯属浪费 CPU。Nginx 的 gzip_types 指令就是干这个的，只对特定 MIME 类型启用压缩。

CDN 把下载变成了边缘计算问题

现在稍微大一点的下载站都会上 CDN。用户请求 download.example.com/file.zip，实际上是从离他最近的边缘节点拿数据。源站只负责在缓存未命中时回源。但 CDN 有个坑：如果文件更新了但缓存没刷新，用户下载到的还是旧版本。我见过一个游戏补丁下载，因为 CDN 缓存了 7 天，玩家装了补丁之后版本号对不上，论坛直接炸了。

解决办法通常是给文件名加哈希，比如 app-v2.3.1-a1b2c3.zip，这样每次更新都是新 URL，CDN 自然回源。代价是旧文件会一直堆在源站上，需要定期清理。

Web 服务器下载这件事，说简单也简单，配个 Nginx 就能跑。但真要跑得稳、跑得快，从 HTTP 头到内核参数，每一层都有可以抠的细节。我现在的习惯是：每次部署完下载服务，先用 curl -I 看一眼响应头，再用 wget --continue 测一次断点续传。这两个命令花不了十秒钟，但能省掉很多半夜被叫起来修服务器的麻烦。