Consider disabling WebSocket message splitting when permessage-deflate is off

首先查看 ipc.net.ts，尤其是 MaxWebSocketMessageLength 以及 issue 中描述的 enableMessageSplitting 行为。在高延迟的 proxied 连接下比较 splitting 和不 splitting 的路径，然后确定完成是指 CLI 可配置的设置，还是由延迟和压缩安全性检查支持的默认值变更。

WebSocket message splitting adds significant latency for large files on proxied connections

When serving code-server behind a proxy (which is the common production deployment), the 256KB WebSocket message splitting introduced in microsoft/vscode#174278 multiplies per-message RTT overhead significantly for large file operations like image previews.

Background

VS Code splits large IPC messages into 256KB chunks (MaxWebSocketMessageLength = 256 * 1024 in ipc.net.ts) to avoid blocking the Node.js event loop during zlib compression. Each chunk becomes a separate WebSocket message.

The latency problem in proxied deployments

In a proxied deployment (e.g. a gateway in front of a devbox), each WebSocket message incurs a full round-trip. With 100ms RTT between the proxy and the devbox:

• A 10MB file generates ~40 chunks (10MB ÷ 256KB)
• Each chunk = one WebSocket message = one round-trip
• Total overhead: ~40 × 100ms = ~4 seconds of pure latency

We tested image preview times (time from opening a file in the explorer to the image fully rendering) across different file sizes at 100ms simulated RTT:

Is disabling splitting safe? (Does zlib actually block?)

A few basic tests didn't seem to indicate this issue in our case, but more investigation may be needed

Question

Would you consider making enableMessageSplitting configurable via a CLI flag, or defaulting it to false for single-user deployments?

Happy to submit a PR if there's agreement on the right approach.