Пакеты WebSocket TCP сжимаются вместе?

Что касается слияния пакетов JavaScript и PHP WebSocket TCP, пример ниже.

По какой-то причине, когда вы быстро отправляете пакеты на моем VPS или получаете доступ к моему локальному хосту через домен, указывающий на мой IP-адрес, несколько пакетов будут сжиматься вместе. Я пытаюсь передать для этого примера 20 (@100 байт) пакетов в секунду. На концах серверов они действительно отправляются с постоянной скоростью ровно каждые 50 мс, составляя 20 в секунду. Однако, когда они добираются до клиента, клиент обрабатывает новые сообщения только каждые 1/4 секунды. Причинение новых пакетов только для приема со скоростью 4 в секунду или около того...

Что вызывает слияние пакетов вместе? Эта проблема не возникает, когда все через localhost. Что более странно, что он плавно переходит на iPhone iOS Mobile Safari, без каких-либо проблем. НО, это совсем не работает на ПК Safari (потому что я не установил, что это правильно работает со старым форматом Hixie-76 WebSocket, я предполагаю, что Mobile Safari уже использует новый RFC 6455 или более новый JavaScript компилятор) Я пробовал несколько хостинговых компаний с одинаковыми результатами каждый раз.

См. пример ниже, размещенный на InMotion VPS: http://www.hovel.me/script/serverControl.php

(Нажмите [Подключить] слева, затем [Посмотреть игру] справа).

Полученный текущий пакет будет прыгать около 5 каждый раз, так как каждые 5 пакетов принимаются сразу, каждые 1/4 секунды. Тем не менее, я видел примеры, которые могут отправлять постоянный, быстрый поток пакетов. Что заставляет это собираться вместе/пакеты ждать друг друга?

EDIT. Это должно быть связано с алгоритмом Nagle, который собирает и отправляет небольшие пакеты вместе? Я попытаюсь обойти это в PHP. Даже с этим TCP_NODELAY, установленным в PHP, проблема все еще стоит. Почему это работает на iPhone, но не на ПК, все еще бросает меня...
EDIT: настройка TCPNoDelay и TcpAckFrequency на 1 в реестре исправляет это, но я не могу ожидать, что каждый пользователь сделает это. Там должен быть клиентский, хлеб и масло JavaScript.

Как я могу восстановить функции node.js ' " socket.setNoDelay(true)" без использования node.js

Ответ 1

Этот TCP. Это помогает вам экономить на IP-пакетах. Часть его связана с алгоритмом Нагле, но часть его также может быть вызвана промежуточной сетью.

Ответ 2

В конце концов, клиент, который не распознает алгоритм Nagle, который отключен, а также частота подтверждения, все еще установленная на уровне около 200 мс, заставила промежуточную сеть удерживать следующие пакеты в буфере. Вручную отправив на сервер сообщение подтверждения, каждый раз, когда клиент получает сообщение, он сразу же "пробуждается" и продолжает обрабатывать следующие пакеты, а не удерживать их в буфере.

Пример:

conn = new WebSocket(url);
conn.onmessage = function(evt){
    Server.send('ACKNOWLEDGE BYTES'); // Send ACK to server immediately
    dispatch('message', evt.data); //Do regular event procedures
};

Это временное решение работает, однако это почти удваивает использование полосы пропускания среди других сетевых проблем. До тех пор, пока я не смогу получить WebSocket на конечных клиентах, чтобы он не был "резервным" для сервера ack и сети для немедленного нажатия на сообщения, это быстрее получает пакеты без проблемы укупорки буфера.