做数据备份时，你有没有遇到过这样的情况：备份到一半卡住，重试几次才成功；或者明明网络没问题，但备份任务老是中断重连？背后可能就藏着一个被忽略的细节——客户端请求到底支不支持长连接。
长连接不是“高级功能”，而是备份流畅的关键
HTTP/1.1 默认开启长连接（Keep-Alive），意思是同一个 TCP 连接可以复用多次请求响应，不用每次备份一个小文件都新建一次连接。而很多轻量级备份工具或自研脚本，默认用的是短连接，每传一个文件就建立、关闭一次连接，光握手和挥手就耗掉几十毫秒。100个文件？光连接开销就多出好几秒，还容易触发服务端连接数限制或防火墙超时拦截。
怎么判断你的客户端是否支持长连接？
看请求头最直接。用浏览器开发者工具或 curl 抓一下备份发起的请求：
curl -v https://backup.example.com/upload如果响应头里有 Connection: keep-alive，且请求头也带了 Connection: keep-alive，说明当前这一路走通了。但如果看到 Connection: close，哪怕协议是 HTTP/1.1，实际也在用短连接。
常见客户端的表现
Python 的 requests 库默认支持长连接，只要复用同一个 Session 对象：
import requests
s = requests.Session()
for file in backup_files:
s.post("https://api.backup.com/upload", files={"data": open(file, "rb")})而用 urllib.request.urlopen() 每次新建请求，就默认不复用连接，得手动加 headers 才行。
手机 App 做自动备份时，有些老版本 SDK 会把每个上传请求当成独立调用，没配连接池，结果凌晨批量备份时，服务器日志里全是 TIME_WAIT 状态连接暴增——这不是网不好，是客户端“太老实”，不会续着用。
服务端配合也很重要
光客户端支持不够。比如 Nginx 默认 keepalive_timeout 是 65 秒，如果你的单个大文件上传要花 2 分钟，中间没任何数据交互，连接就被关了。这时候得调长超时，或让客户端在空闲时发个轻量心跳包（比如 OPTIONS 请求），维持连接活性。
备份不是拼速度，而是拼稳定。一次完整的长连接跑完 50 个文件，比 50 次短连接更少出错、更省资源，也更不容易被误判为异常流量。