Les cadres websocket sont-ils automatiquement compressés après l'ajout de l'en-tête de réponse permessage-deflate?

Question

La ligne de fond:

Je ne vois pas websocket messages compressés, même si les perMessage-dégonflage têtes existent à la fois sur la demande et la réponse.

Quelques détails:

J'ai un serveur nodejs, et je l'utilise Primus (avec engine.io moins). J'utilise la fonction 'compression' de Primus, afin de prendre en charge le delta-permessage. Après que je l'ai allumé, je commence à voir l'en-tête permessage-deflate sur les réponses.

Mais je ne vois pas les cadres websocket eux-mêmes être compressés.

Je renifle le trafic en utilisant charlesproxy, et encore - les cadres sont identiques à ce qu'ils étaient avant d'activer la fonction 'compression'.

Illustration:

Voici un exemple de demande de la poignée de main de websocket:

Accept-Encoding:gzip, deflate, br 
Accept-Language:en-US,en;q=0.8,he;q=0.6,fr;q=0.4 
Cache-Control:no-cache 
Connection:Upgrade 
Cookie:[some cookies] 
Host:[our host] 
Origin:https://[our host] 
Pragma:no-cache 
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits 
Sec-WebSocket-Key:6nMxnGd0E8GrDg2s1B4tHQ== 
Sec-WebSocket-Version:13 
Upgrade:websocket 
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 

Et ceci est la réponse correspondante:

Connection:upgrade 
Date:Tue, 11 Jul 2017 14:10:18 GMT 
Sec-WebSocket-Accept:lLjOXWbLRVIHw2inxrhx0U1ryrM= 
Sec-WebSocket-Extensions:permessage-deflate; client_no_context_takeover 
Sec-WebSocket-Version:13 
Server:nginx 
Upgrade:websocket 
WebSocket-Server:uWebSockets 

Ces exemples sont tirés de la dev Chrome inspecteur de réseau d'outils. Je vois quelque chose de similaire dans le renifleur charlesproxy.

Autre référence:

J'ai vu ceci:

Implementing permessage-deflate in WebSockets

Mais je ne pouvais pas trouver tout à fait une réponse valable il.

Alors ...

Qu'est-ce que je manque ici? Dois-je implémenter quelque chose de plus? Dois-je inclure une bibliothèque?

Versions:

• nœud - 4.2.4
• primus - 7.0.2
• chrome: 59.0.3071.115
• FF: 54.0.1
• Charles: 4,1. 4

Merci beaucoup!

Answer 1

Je pense que je l'ai compris.

Dans le sniffer de charlesproxy - j'ai trouvé où voir une vue des données compressées (à ceux qui veulent savoir - j'ai regardé la vue du wss, qui décompose les cadres de socket Web. sur l'entrée http/https, qui représente la prise de contact websocket, et a un onglet 'compressé').

Je suppose que le sniffer de réseau des outils de développement Chrome affiche simplement les données après la compression, donc il est lisible par l'homme.

Pour répondre à ma propre question, je ne pense pas avoir besoin d'implémenter quelque chose de plus pour compresser les données.

Answer 2

Le problème est que uws ne compresse pas les données même si on lui demande de le faire.

Voir cette question https://github.com/socketio/engine.io/issues/474

Il devrait fonctionner si vous dites engine.io utiliser ws au lieu de uws. Vous pouvez le faire en définissant la variable d'environnement EIO_WS_ENGINE sur ws ou en utilisant l'option wsEngine de engine.io.

Je pense qu'il existe également un seuil de taille sous lequel les messages ne sont pas compressés. Si je ne me trompe pas, c'est 1 KiB.