Кодирование трафика WebSocket (GZip)

StackOverflow использует кодировку GZip на всех своих страницах; похоже, что это верно для их трафика в сети, поскольку он кажется полностью запутанным.

enter image description here

Как/Что они будут использовать для достижения этого; скорее, что мне нужно сделать, чтобы добиться того же, так как мой сервер websocket размещен на отдельном сервере без IIS и т.д.

Стоит также отметить, что http compression не установлен в запросе на соединение с веб-сервером.


Полный скриншот экрана: http://i44.tinypic.com/19s4yr.jpg

Ответ 1

Согласно RFC6455, полезная нагрузка WebSocket от клиента к серверу ДОЛЖНА быть скрыта, сервер к клиенту НЕ ДОЛЖЕН маскироваться. Маскирование выполняется с помощью полезной нагрузки XORring с 32-битной маской.. значение, которое вы видите в своем журнале.

В кулинарии есть расширение WS, которое обеспечивает сжатие (спуск) на основе кадра. Это не имеет никакого отношения к маскировке. Полезная нагрузка с активным сжатием для каждого кадра сжимает полезную нагрузку, а затем маскирует полезную нагрузку (клиент к серверу).

Ответ 2

Я не думаю, что здесь есть какой-нибудь gzipping. Похоже, что скрипач начал добавлять поддержку для websockets, но все еще продолжает работу.

В журнале отображается соединение
... затем первое сообщение из 12 байтов (461287-inbox. Исходные байты 81 8C показывают новый, полный, текстовый фрейм с 4 байтовой маской и 12 байтами данных. Fiddler правильно декодирует это.)
... затем второе сообщение из 19 байтов (байты 81 93 - 19 байт в поток) показывает новый, полный текстовый фрейм с 4 байтовой маской и 19 байтами данных)
... затем третье сообщение из 19 байтов (более поздние байты 81 93 - приблизительно 44 байта в потоке - показывают новый, полный текстовый фрейм с 4 байтовой маской и 19 байтами данных)