Почему SIgnalR предпочитает Forever Frames над опросом?

Question

Я учусь использовать SignalR, и до сих пор у меня был успех в этом. Я могу реализовать Hubs, я могу реализовать бизнес-логику, я могу вызывать функции на стороне клиента с сервера, для которого я хочу, я могу ссылаться на серверные методы с клиентской стороны, этот материал замечательный. Меня озадачивает теория.

Фактически, я собрал информацию об этом video. SignalR использует WebSockets, которые предоставляют full duplex channel по одному соединению TCP. Если нет доступных WebSockets, тогда резервный протокол будет EventSource. Если это недоступно, тогда будет использоваться Forever Frame. Если это недоступно, будет использоваться Long Polling. Для меня довольно странно, что очень устаревшее решение, как и всегда, предпочтительнее старой конвенции, и меня интересует обоснование решения SignalR о том, чтобы навсегда использовать кадры в качестве третьего варианта и опроса в качестве четвертого варианта.

Я попытался выяснить ответ на этот вопрос, и я узнал, что, по слухам, это there is a 3x max latency time in the case of long polling compared to forever frames. Это факт, и если да, то это факт для всех браузеров или для подмножества?

Answer 1

foreverFrame работает немного как serverSentEvents - существует один длинный HTTP-запрос, который сервер никогда не завершает, а использует для передачи данных клиенту. longPolling работает по-другому - есть HTTP-запрос опроса, который закрывается сервером каждый раз, когда есть данные для чтения клиентом (или истекает время ожидания). Если клиент хочет прочитать больше данных, ему нужно открыть новый HTTP-запрос, который снова будет закрыт сервером, как только будут какие-либо данные для клиента. Другими словами, в случае foreverFrame сервер нажимает данные клиенту с использованием уже установленного канала, тогда как в случае longPolling клиент постоянно создает http-запросы для получения данных с сервера.