Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Consider disabling WebSocket message splitting when permessage-deflate is off

Aperta
#7,724 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
typescript, vscode
Ambito
networking, performance

Direzione di ricerca

Inizia esaminando ipc.net.ts, in particolare MaxWebSocketMessageLength e il comportamento di enableMessageSplitting descritto nell’issue. Confronta i percorsi con splitting e senza splitting su connessioni proxied ad alta latenza, quindi definisci se il completamento significa un’impostazione configurabile tramite CLI o un valore predefinito modificato, supportato da controlli sulla latenza e sulla sicurezza della compressione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

code-server enhancement needs-investigation

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:

File size Splitting ON Splitting OFF Improvement
145 KB 2,212ms 2,251ms ~0%
1 MB 1,988ms 1,707ms 14%
1.5 MB 2,093ms 1,412ms 33%
5.6 MB 4,255ms 2,193ms 48%
10.3 MB 7,262ms 2,888ms 60%
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.

Lingua principale
TypeScript
Stelle
79.4k
Fork
6.9k
Merge medio
2g 13h
PR unite (30g)
39

Guida per i contributori

Apri la guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/code-server

Tutte le issue di coder/code-server

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.