Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Consider disabling WebSocket message splitting when permessage-deflate is off

Offen
#7,724 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
typescript, vscode
Bereich
networking, performance

Rechercherichtung

Beginne mit der Durchsicht von ipc.net.ts, insbesondere von MaxWebSocketMessageLength und dem im Issue beschriebenen Verhalten von enableMessageSplitting. Vergleiche die Pfade mit und ohne Aufteilung unter proxied Verbindungen mit hoher Latenz und lege anschließend fest, ob der Abschluss eine über CLI konfigurierbare Einstellung oder ein geänderter Standardwert bedeutet, der durch Latenz- und Komprimierungssicherheitsprüfungen gestützt wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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.

Vorherrschende Sprache
TypeScript
Sterne
79.4k
Forks
6.9k
Ø Merge
2 T. 13 Std.
Gemergte PRs (30 T.)
39

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus coder/code-server

Alle Issues in coder/code-server

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.