Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Consider disabling WebSocket message splitting when permessage-deflate is off

Ouverte
#7,724 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Fonctionnalité
Clarté
À clarifier
Activité
Calme
Stack technique
typescript, vscode
Domaine
networking, performance

Piste de recherche

Commencez par examiner ipc.net.ts, en particulier MaxWebSocketMessageLength et le comportement de enableMessageSplitting décrit dans l’issue. Comparez les chemins avec et sans découpage sur des connexions proxied à latence élevée, puis déterminez si l’achèvement signifie un paramètre configurable via CLI ou une valeur par défaut modifiée, étayée par des vérifications de latence et de sécurité de la compression.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
TypeScript
Étoiles
79.4k
Forks
6.9k
Merge moyen
2 j 13 h
PR mergées (30 j)
39

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de coder/code-server

Toutes les issues de coder/code-server

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.