Есть много блогов и обсуждений о websocket и HTTP, и многие разработчики и сайты сильно защищают веб-сайты, но я все еще не могу понять, почему.
например (аргументы любителей websocket):
HTML5 Web Sockets представляет собой следующую эволюцию веб-коммуникаций - полнодуплексный, двунаправленный канал связи, который работает через один сокет через Интернет. (http://www.websocket.org/quantum.html)
HTTP поддерживает потоковое вещание: потоковое вещание запроса (вы используете его при загрузке больших файлов) и потоковое тело ответа.
Во время соединения с WebSocket клиент и сервер обмениваются данными на каждый кадр, который по 2 байта, по сравнению с 8 килобайтами заголовка http при непрерывном опросе.
Почему эти 2 байта не включают в себя tcp и под потоки протоколов tcp?
GET /about.html HTTP/1.1
Host: example.org
Это HTTP-заголовок ~ 48 байтов.
http chunked encoding - http://ru.wikipedia.org/wiki/Chunked_transfer_encoding:
23
This is the data in the first chunk
1A
and this is the second one
3
con
8
sequence
0
Также оба протокола работают через TCP, поэтому все проблемы TCP с подключением с длительным подключением все еще существуют.
Вопрос:
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 в любом случае).
Обновить:
Вот основа для размышлений о веб-протоколах:
text/event-stream
MIME. API-интерфейс браузера (который довольно похож на API WebSocket) называется API-интерфейсом EventSource.Ссылки
Предполагается, что WebSocket заменяет HTTP. Это не. Это расширение.
Основным вариантом использования WebSockets являются приложения Javascript, которые запускаются в веб-браузере и получают данные в реальном времени с сервера. Хорошим примером являются игры.
Прежде чем WebSockets, единственный способ использования Javascript-приложений для взаимодействия с сервером - через XmlHttpRequest
. Но у них есть главный недостаток: сервер не может отправлять данные, если клиент явно не запросил его.
Но новая функция WebSocket позволяет серверу отправлять данные всякий раз, когда захочет. Это позволяет реализовать браузерные игры с гораздо более низкой задержкой и без необходимости использовать уродливые хаки, такие как AJAX для долгого опроса или плагинов браузера.
Итак, почему бы не использовать обычный HTTP с потоковыми запросами и ответами
В комментарии к другому ответу вы предложили просто передать клиентский запрос и тело ответа асинхронно.
Фактически, WebSockets в основном таковы. Попытка открыть соединение с WebSocket с клиентом сначала выглядит как HTTP-запрос, но специальная директива в заголовке (Upgrade: websocket) сообщает серверу начать общение в этом асинхронном режиме. Первые черновики протокола WebSocket были не намного больше, чем некоторые, и некоторые подтверждения, чтобы убедиться, что сервер действительно понимает, что клиент хочет общаться асинхронно. Но тогда было осознано, что прокси-серверы будут смущены этим, потому что они используются для обычной модели запроса/ответа HTTP. Был обнаружен потенциальный сценарий атаки на прокси-серверы. Чтобы этого избежать, необходимо было заставить трафик WebSocket выглядеть в отличие от любого обычного HTTP-трафика. Вот почему маскирующие клавиши были введены в окончательную версию протокола.
Для TL; DR, здесь 2 цента и более простая версия для ваших вопросов:
WebSockets предоставляет эти преимущества по HTTP:
Протокол WebSocket и HTTP был разработан для решения различных задач, I.E. WebSocket был разработан для улучшения двунаправленной связи, в то время как HTTP был разработан как безгражданный, распределенный с использованием модели запроса/ответа. Помимо совместного использования портов по устаревшим причинам (проникновение через брандмауэр/прокси), не так много общего, чтобы объединить их в один протокол.
Другие ответы, похоже, не затрагивают ключевой аспект здесь, и вы не упоминаете о необходимости поддержки веб-браузера в качестве клиента. Большинство ограничений простого HTTP выше предполагают, что вы будете работать с реализациями браузера /JS.
Протокол HTTP полностью поддерживает полнодуплексную связь; легально, чтобы клиент выполнял POST с передачей кодированных каналов, а сервер возвращал ответ с блоком закодированного кодирования. Это приведет к удалению накладных расходов заголовка только во время init.
Итак, если все, что вы ищете, полнодуплексное, управляйте как клиентом, так и сервером, и не заинтересованы в дополнительном оснащении/функциях веб-сайтов, тогда я бы сказал, что HTTP - это более простой подход с более низкой задержкой/хотя задержка будет действительно отличаться только в микросекундах или меньше для).