1) Почему протокол WebSockets лучше?
WebSockets лучше подходит для ситуаций, в которых используется коммуникация с малой задержкой, особенно с низкой задержкой для сообщений от клиента к серверу. Для данных от сервера к клиенту вы можете получить довольно низкую задержку, используя длительные соединения и частичную передачу. Однако, это не помогает с задержкой клиента к серверу, которая требует, чтобы новое соединение было установлено для каждого сообщения клиента к серверу.
Ваше 48-байтовое HTTP-рукопожатие нереально для реальных подключений через HTTP-браузер, где часто бывает несколько килобайт данных, отправленных как часть запроса (в обоих направлениях), включая множество заголовков и данных cookie. Вот пример запроса / ответа на использование Chrome:
Пример запроса (2800 байт, включая данные cookie, 490 байт без данных cookie):
GET / HTTP/1.1
Host: www.cnn.com
Connection: keep-alive
Cache-Control: no-cache
Pragma: no-cache
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.68 Safari/537.17
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: [[[2428 byte of cookie data]]]
Пример ответа (355 байт):
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 13 Feb 2013 18:56:27 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: CG=US:TX:Arlington; path=/
Last-Modified: Wed, 13 Feb 2013 18:55:22 GMT
Vary: Accept-Encoding
Cache-Control: max-age=60, private
Expires: Wed, 13 Feb 2013 18:56:54 GMT
Content-Encoding: gzip
И HTTP, и WebSockets имеют начальные квитирования соединения одинакового размера, но при соединении WebSocket начальное квитирование выполняется один раз, а затем небольшие сообщения имеют только 6 байтов служебной информации (2 для заголовка и 4 для значения маски). Затраты на задержку не столько зависят от размера заголовков, сколько от логики для анализа / обработки / хранения этих заголовков. Кроме того, задержка установки TCP-соединения, вероятно, является более важным фактором, чем размер или время обработки для каждого запроса.
2) Почему это было реализовано вместо обновления протокола HTTP?
Предпринимаются усилия по реинжинирингу протокола HTTP для повышения производительности и снижения задержек, таких как SPDY , HTTP 2.0 и QUIC . Это улучшит ситуацию для обычных HTTP-запросов, но вполне вероятно, что WebSockets и / или WebRTC DataChannel будут по-прежнему иметь меньшую задержку при передаче данных между клиентами, чем протокол HTTP (или он будет использоваться в режиме, который очень похож на WebSockets). в любом случае).
Обновление :
Вот структура для размышлений о веб-протоколах:
- TCP : транспортный уровень низкого уровня, двунаправленный, полный дуплекс и гарантированный порядок. Нет поддержки браузера (кроме как через плагин / Flash).
- HTTP 1.0 : транспортный протокол запрос-ответ, многоуровневый по TCP. Клиент делает один полный запрос, сервер дает один полный ответ, и затем соединение закрывается. Методы запроса (GET, POST, HEAD) имеют конкретное транзакционное значение для ресурсов на сервере.
- HTTP 1.1 : поддерживает природу ответа на запрос HTTP 1.0, но позволяет соединению оставаться открытым для нескольких полных запросов / полных ответов (один ответ на запрос). Все еще имеет полные заголовки в запросе и ответе, но соединение используется повторно и не закрывается. HTTP 1.1 также добавил некоторые дополнительные методы запроса (OPTIONS, PUT, DELETE, TRACE, CONNECT), которые также имеют определенные транзакционные значения. Однако, как отмечалось во введении к черновому предложению HTTP 2.0, конвейерная передача HTTP 1.1 не получила широкого распространения, поэтому это значительно ограничивает использование HTTP 1.1 для решения задержки между браузерами и серверами.
- Long-poll : своего рода «взлом» HTTP (либо 1.0, либо 1.1), когда сервер не отвечает немедленно (или только частично отвечает заголовками) на запрос клиента. После ответа сервера клиент немедленно отправляет новый запрос (используя то же соединение, если через HTTP 1.1).
- Потоковая передача HTTP : множество методов (многочастный / чанкированный ответ), которые позволяют серверу отправлять более одного ответа на один клиентский запрос. W3C стандартизирует это как отправленные сервером события, используя
text/event-streamтип MIME. API браузера (который довольно похож на API WebSocket) называется API EventSource.
- Комета / серверная рассылка : это общий термин, который включает как длинный опрос, так и потоковую передачу HTTP. Библиотеки комет обычно поддерживают несколько методов, позволяющих максимизировать кросс-браузерную и кросс-серверную поддержку.
- WebSockets : встроенный в TCP транспортный уровень, использующий дружественное HTTP обновление рукопожатия. В отличие от TCP, который является потоковым транспортом, WebSockets - это транспорт на основе сообщений: сообщения разграничиваются по проводам и перед сборкой передаются в сборку. Соединения WebSocket являются двунаправленными, полнодуплексными и долговечными. После первоначального запроса / ответа на рукопожатие транзакционная семантика отсутствует, и для каждого сообщения накладных расходов очень мало. Клиент и сервер могут отправлять сообщения в любое время и должны обрабатывать получение сообщений асинхронно.
- SPDY : инициированное Google предложение о расширении HTTP с использованием более эффективного проводного протокола, но с сохранением всей семантики HTTP (запрос / ответ, файлы cookie, кодирование). SPDY вводит новый формат кадрирования (с кадрами с префиксом длины) и определяет способ наложения пар HTTP-запросов / ответов на новый уровень кадрирования. Заголовки могут быть сжаты, а новые заголовки могут быть отправлены после установления соединения. Существуют реальные реализации SPDY в браузерах и на серверах.
- HTTP 2.0 : имеет те же цели, что и SPDY: уменьшить задержку HTTP и накладные расходы при сохранении семантики HTTP. Текущий черновик взят из SPDY и определяет рукопожатие при обновлении и формирование данных, которое очень похоже на стандарт WebSocket для рукопожатия и формирования кадров. Альтернативный черновой вариант HTTP 2.0 (httpbis-speed-mobility) фактически использует WebSockets для транспортного уровня и добавляет мультиплексирование SPDY и отображение HTTP в качестве расширения WebSocket (расширения WebSocket согласовываются во время рукопожатия).
- WebRTC / CU-WebRTC : предложения по разрешению однорангового подключения между браузерами. Это может обеспечить связь с более низкой средней и максимальной задержкой, поскольку в качестве основного транспорта используется SDP / дейтаграмма, а не TCP. Это позволяет осуществлять неупорядоченную доставку пакетов / сообщений, что позволяет избежать проблемы TCP с пиками задержки, вызванными потерянными пакетами, которые задерживают доставку всех последующих пакетов (чтобы гарантировать доставку по порядку).
- QUIC : это экспериментальный протокол, направленный на снижение задержки в сети по сравнению с TCP. На первый взгляд, QUIC очень похож на TCP + TLS + SPDY, реализованный в UDP. QUIC обеспечивает мультиплексирование и управление потоком, эквивалентные HTTP / 2, безопасность, эквивалентную TLS, а семантику соединения, надежность и управление перегрузкой, эквивалентную TCP. Поскольку TCP реализован в ядрах операционной системы и встроенном программном обеспечении, внесение существенных изменений в TCP практически невозможно. Однако, поскольку QUIC построен поверх UDP, он не имеет таких ограничений. QUIC разработан и оптимизирован для семантики HTTP / 2.
Рекомендации :
- HTTP :
- Отправленное сервером событие :
- WebSockets :
- SPDY :
- HTTP 2.0 :
- WebRTC :
- QUIC :
