在搭建文件分发服务时，大文件传输最容易遇到网络抖动导致下载失败的问题。Apache作为老牌Web服务器，天然支持基于HTTP Range机制的断点续传，可以让客户端从断开的位置继续拉取剩余字节，而不必重新下载整个文件。这种能力依赖请求头中的Range字段以及服务器返回的206 Partial Content响应，理解其底层交互对系统稳定性至关重要。
Apache中Range请求的基础工作原理
当浏览器或下载工具向Apache请求一个大文件时，如果之前已经获取过部分内容，它会在请求头中加入Range: bytes=2000-这样的字段，表示希望从第2000字节开始继续接收。Apache接收到该头后，会调用核心模块 mod_core 中的相关处理逻辑，检查文件是否存在、区间是否合法，然后只读取对应的字节段返回给客户端，状态码设为206而非常见的200。
在响应中，Apache会自动添加 Content-Range 头，例如 Content-Range: bytes 2000-9999/10000，告知客户端当前片段的起始结束位置以及文件总大小。同时 Accept-Ranges: bytes 响应头也会出现在第一次普通请求中，用来声明服务器支持字节级范围请求。若客户端发来的Range不合法，比如起始大于文件大小，Apache则返回416 Requested Range Not Satisfiable。
默认情况下，Apache 2.4版本对静态文件的Range处理是开启的，不需要额外加载特殊模块。但对于使用了反向代理或者某些CGI输出的情况，范围请求可能会被忽略，因为后端动态脚本往往没有实现分片逻辑。运维人员可以通过 Header 指令或者 mod_headers 来强制输出 Accept-Ranges，但真正的切片仍取决于内容来源是否可被随机读取。
配置与代码层面验证断点续传
要在Apache中确认断点续传可用，最简单的办法是用curl命令模拟Range请求。执行 curl -H "Range: bytes=0-1023" -I http://127.0.0.1/bigfile.iso 后，若返回 HTTP/1.1 206 Partial Content 以及 Content-Range，说明配置无误。若看到200且返回了整个文件头，则可能是被某些中间件缓存层吞掉了Range。
在虚拟主机配置中，可以通过以下指令显式控制范围请求行为：
<Directory "/var/www/files">
# 允许范围请求（默认就是On）
EnableMMAP On
ForceType application/octet-stream
Header set Accept-Ranges bytes
</Directory>
上面的配置确保该目录下文件以二进制流形式输出，并声明支持字节范围。要注意的是，如果文件是通过PHP等脚本读取后 echo 给客户端的，那么Apache无法自动切片，必须在脚本内自己解析 $_SERVER['HTTP_RANGE'] 并调用 fseek 定位输出，否则断点续传会失效。下面是一段简化的PHP分片输出示例：
<?php
$file = '/var/www/files/bigfile.iso';
$size = filesize($file);
if (isset($_SERVER['HTTP_RANGE'])) {
list($unit, $range) = explode('=', $_SERVER['HTTP_RANGE']);
list($start, $end) = explode('-', $range);
$start = intval($start);
$end = $end ? intval($end) : $size - 1;
header('HTTP/1.1 206 Partial Content');
header("Content-Range: bytes $start-$end/$size");
header('Content-Length: ' . ($end - $start + 1));
$fp = fopen($file, 'rb');
fseek($fp, $start);
echo fread($fp, $end - $start + 1);
fclose($fp);
exit;
}
header('Accept-Ranges: bytes');
header("Content-Length: $size");
readfile($file);
?>
这段脚本展示了如何在应用层弥补Apache动态内容的不足。实际上，多数生产环境建议直接让Apache托管静态文件，避免用脚本做流输出，这样既减轻CPU负担，也能利用sendfile机制提升吞吐。只有当文件权限校验复杂时才考虑脚本层介入，但此时务必正确处理Range，否则客户端重试时会重复下载。
大文件场景下的性能与避坑要点
面对超过10GB的镜像文件，Apache的Range处理仍然高效，因为它基于操作系统的 lseek 和 sendfile 实现，不会把整个文件加载进内存。然而若开启了 mod_deflate 压缩，Range通常会被禁用，因为压缩后的字节区间无法与原始文件一一对应，服务器只能返回200全量内容。因此大文件分发时应关闭该目录的压缩。
另一个常见误区是以为反向代理Nginx转发到Apache后续传依然透明。实际上Nginx默认会缓冲上游响应，若未设置 proxy_set_header Range $http_range; 以及 proxy_pass_request_headers on;，Apache根本收不到Range头。同样，CDN边缘节点也可能合并或丢弃范围请求，需要在源站观察日志中的206比例来判断真实命中情况。
从安全角度看，恶意客户端可能发送大量重叠或细碎的Range来制造分片轰炸，Apache提供了 LimitRequestBody 以及 mod_reqtimeout 来约束请求速率。对于极度敏感的下载接口，可以限定单个Range最大跨度，或者在应用层做令牌校验后再放行。总体而言，只要静态托管、关闭压缩、链路透传Range，Apache处理大文件断点续传是非常稳健的方案。