Кодирование трафика 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 байтами данных)
