WebSocket vs HTTP for 文件传输: A Comparison
Compare WebSocket and HTTP protocols for 文件传输. Performance benchmarks, use cases, and implementation trade-offs explained.
《网络安全法》（CSL）第二十一条要求网络运营者采取技术措施保障网络数据完整性。从技术层面看，HTTP几乎在所有文件传输场景中都是更优选择：它无状态，能穿越所有企业代理，受益于HTTP/2多路复用和HTTP/3 QUIC，并能与CDN、预签名URL和S3等对象存储API无缝集成。WebSocket（RFC 6455）在实时双向消息通讯（聊天、协同编辑、实时仪表盘）场景中大放异彩，但在移动大文件上几乎没有优势，反而带来真实的缺陷：无原生缓存、CDN支持差、中间件兼容性问题，以及更复杂的服务端内存管理。
核心协议差异
HTTP是请求-响应式、无状态且可缓存的。每个请求携带请求头，命中服务器或CDN，返回响应。HTTP/2在单个TCP连接上多路复用多个请求；HTTP/3（RFC 9114）运行于QUIC，具有更好的丢包恢复能力和零RTT恢复。WebSocket以HTTP Upgrade请求开始，然后将TCP连接翻转为全双工的基于帧的协议。升级完成后，双方可以随时发送消息。这种持久双向信道对交互式应用非常强大，但对于流量方向绝大多数是单向的批量文件传输，架构上显得格格不入。
吞吐量与延迟基准测试
在东京客户端到美国东海岸服务器的千兆链路上，典型基准测试结果如下：HTTP/1.1单个PUT约40到80 Mbps（受TCP窗口缩放限制），HTTP/2多部分（8路并行流，每部分8 MB）约400到800 Mbps，HTTP/3 QUIC在丢包场景下比前者好10%到30%，WebSocket二进制帧约200到500 Mbps（受单连接流量控制瓶颈限制）。跨距离的测试结果模式相同：WebSocket并不更快，因为底层仍是TCP，而且其连接利用效率比并行HTTP请求低。
分块与断点续传上传
HTTP拥有成熟的分块上传标准：tus.io协议使用带Upload-Offset头的HTTP PATCH，S3多部分上传使用带分块编号和ETag的UploadPart。两者都能在网络中断后从上次成功的分块恢复，并在客户端重启后借助IndexedDB持久化状态继续传输。WebSocket分块是临时方案——每个团队自行定义帧格式、序列号和确认机制，重传逻辑通常比经过验证的HTTP方案差，且存在细微错误。SocketIO、Primus和各种自定义协议都在重新发明同一个轮子，却各有各的缺陷。
CDN与边缘兼容性
Cloudflare、CloudFront、Fastly和Akamai等CDN在边缘节点缓存HTTP响应，通常能将全球下载速度提升一倍。静态对象的GET请求可以通过URL或签名URL进行缓存。WebSocket流量通常可以穿过CDN但不会被缓存，很多企业代理还会禁用或限速WebSocket升级请求。配置了拦截TLS代理的企业网络有时会完全破坏WebSocket连接。对于面向全球用户的文件传输服务，仅凭这一点就足以偏向HTTP：Cloudflare 300多个节点让HTTP下载显著更快，但对WebSocket载荷帮助甚微。
服务端资源占用
HTTP服务器以极低的内存开销处理数千个并发连接，因为请求是短暂的。Nginx、Caddy和Go的net/http在每个节点可以支持10,000以上的并发连接，内存占用适中。每个WebSocket连接都是长期持有的，占用一个TCP socket、一个读缓冲区、一个写缓冲区，通常还有应用层状态。大规模部署时，WebSocket集群需要仔细调整ulimit、TCP keepalive和每连接内存参数。Kubernetes部署在滚动升级时会遇到WebSocket粘性会话和优雅关闭的问题。对于处理突发短时上传的传输服务，HTTP的模型更加轻松。
预签名URL与直传存储
HTTP在文件传输中的杀手级特性是预签名URL。应用服务器生成一个直接指向S3、R2或GCS的签名URL，客户端直接向对象存储上传数据，应用服务器完全不接触字节数据，既不消耗代理带宽，也不产生内存压力和文件I/O。WebSocket没有等价机制。使用WebSocket上传，通常需要通过应用服务器代理，再写入存储，带宽成本翻倍且增加延迟。10 GB文件通过WebSocket到应用服务器再到S3的路径消耗20 GB服务器带宽；HTTP直传S3只有小型元数据调用消耗服务器带宽。
WebSocket真正发挥优势的场景
WebSocket非常适合文件传输的周边工作流。跨标签页或设备的实时上传进度通知——WebSocket广播即时送达。协同文件编辑——yjs、Automerge等CRDT库使用WebSocket传输小型增量消息，而实际的大型资产通过HTTP传输。WebRTC点对点传输的信令——WebSocket是P2P数据通道打开之前的标准信令传输。传输接收方下载文件后的服务器推送通知——WebSocket让发送方无需轮询即可立即获得通知。核心模式是：WebSocket处理事件，HTTP传输字节。
HTTP/2与HTTP/3的优势
HTTP/2（RFC 7540）和HTTP/3（RFC 9114）填补了WebSocket曾经具有优势的大多数场景。HTTP/2在单个TCP连接上多路复用多个请求，消除了每源6连接的限制。服务器推送允许服务器主动发送资源，减少往返次数。HTTP/3运行于QUIC，按流处理丢包，而非阻塞整个连接——这对高丢包移动网络至关重要。服务器发送事件（EventSource）提供基于HTTP的单向服务器到客户端推送，比WebSocket更简单，适用于只有服务器需要推送数据的场景。
各场景胜负对比
| 评判标准 | HTTP | WebSocket | |---|---|---| | 大文件上传/下载 | 胜（多部分、预签名URL、CDN） | 败（单流、无缓存） | | 实时双向消息 | 败（轮询浪费资源） | 胜（原生全双工） | | CDN兼容性 | 胜（全球边缘缓存） | 败（几乎不缓存） | | 大规模服务端资源 | 胜（无状态、短连接） | 败（长期持有、每连接占用RAM） | | 企业代理兼容性 | 胜（标准HTTP） | 败（代理经常阻断Upgrade） | | 断点续传上传 | 胜（tus.io、S3多部分） | 临时方案（需自行实现） |
对于HexaTransfer这样的文件传输服务，HTTP加分块多部分加直传S3是正确的架构，可选地在顶层叠加WebSocket用于实时进度更新或接收方下载通知事件。
访问 https://hexatransfer.com — 免费，无需注册，最大10 GB。