Различия между сокетами TCP и веб-сокетами, еще раз
Пытаясь понять, насколько я могу различать TCP-сокет и websocket, я уже нашел много полезной информации в этих вопросах:
- фундаментальное различие между websockets и чистым TCP
- Как установить соединение TCP Socket из веб-браузера (на стороне клиента)?
и так далее…
В моих исследованиях я просмотрел это предложение по википедии :
- «ab» программа зависает после множества запросов, почему?
- Отправка значения с сервера на клиент с сокетами
- В чем разница между BeginConnect и ConnectAsync?
- Простой сервер сокетов в Unity
- Каковы могут быть причины отказа отказались?
Websocket отличается от TCP тем, что он включает stream сообщений вместо streamа байтов
Я не совсем уверен, что это значит. Каковы ваши интерпретации?
- Нужно ли мне бить сердце, чтобы открыть TCP-соединение?
- Может ли два приложения прослушивать один и тот же порт?
- Что означает «сброс соединения с помощью сверстника»?
- Ошибка соединения Bluetooth "java.io.IOException: чтение не выполнено, сокет может быть закрыт или таймаут, read ret: -1"
- TCP: могут ли два разных сокета совместно использовать порт?
Когда вы отправляете байты из буфера с обычным сокетом TCP, функция send возвращает количество байтов отправляемого буфера. Если это неблокирующий сокет или неблокирующая передача, тогда количество отправленных байтов может быть меньше размера буфера. Если это блокирующий сокет или блокировка отправки, то возвращаемый номер будет соответствовать размеру буфера, но вызов может блокироваться. С помощью WebSockets данные, передаваемые методу отправки, всегда отправляются как «сообщение» или вообще не передаются. Кроме того, реализация браузера WebSocket не блокирует вызов отправки.
Но есть более важные различия в принимающей стороне вещей. Когда получатель выполняет recv (или чтение) в сокете TCP, нет гарантии, что количество возвращенных байтов соответствует одной отправке (или записи) на стороне отправителя. Это может быть одно и то же, оно может быть меньше (или равно нулю), и может быть даже больше (в этом случае принимаются байты из нескольких отправлений / записей). С помощью WebSockets получение сообщения управляется событиями (обычно вы регистрируете процедуру обработчика сообщений), а данные в событии всегда являются целым сообщением, отправленным другой стороной.
Обратите внимание, что вы можете осуществлять связь на основе сообщений с использованием сокетов TCP, но вам нужен дополнительный слой / инкапсуляция, которая добавляет данные кадрирования / сообщения в сообщения, чтобы исходные сообщения могли быть собраны повторно из fragmentов. Фактически, WebSockets построен на обычных сокетах TCP и использует заголовки кадров, которые содержат размер каждого кадра и указывают, какие кадры являются частью сообщения. API WebSocket повторно собирает TCP-fragmentы данных в фреймы, которые собираются в сообщениях, прежде чем вызывать обработчик события сообщения один раз за сообщение.
WebSocket – это в основном протокол приложений (со ссылкой на сетевой стек ISO / OSI), ориентированный на сообщения, который использует TCP в качестве транспортного уровня.
Идея протокола WebSocket заключается в повторном использовании установленного TCP-соединения между клиентом и сервером. После установления связи HTTP клиент и сервер начинают говорить по протоколу WebSocket, обмениваясь конвертами WebSocket. Подтверждение HTTP используется для преодоления любого барьера (например, межсетевых экранов) между Клиентом и сервером, предлагающим некоторые услуги (обычно порт 80 доступен из любого места, кем угодно). Клиент и сервер могут в любой момент переключать разговор HTTP, используя одно и то же TCP-соединение (которое никогда не выпускается).
За кулисами WebSocket восстанавливает фреймы TCP в согласованных конвертах / сообщениях. Полнодуплексный канал используется сервером для асинхронного обновления обновлений по отношению к клиенту: канал открыт, и Клиент может вызывать любые фьючерсы / обратные вызовы / обещания для управления любым асинхронным принятым сообщением WebSocket.
Проще говоря, WebSocket – это протокол высокого уровня (например, сам HTTP), построенный на основе TCP (надежный транспортный уровень, на основе каждого кадра), который позволяет создавать эффективные приложения реального времени с JS Clients (ранее кометы и методы долгосрочного опроса были использованы для загрузки обновлений с Сервера до того, как были внедрены WebSockets. См. сообщение Stackoverflow: Различия между веб-windowsми и длинным опросом для пошагового игрового сервера ).