Ответ 1
Когда вы отправляете байты из буфера с обычным сокетом TCP, функция send возвращает количество байтов отправляемого буфера. Если это неблокирующий сокет или неблокирующая передача, тогда количество отправленных байтов может быть меньше размера буфера. Если это блокирующий сокет или блокировка отправки, то возвращаемый номер будет соответствовать размеру буфера, но вызов может блокироваться. С помощью WebSockets данные, передаваемые методу отправки, всегда отправляются как "сообщение" или вообще не передаются. Кроме того, реализация браузера WebSocket не блокирует вызов отправки.
Но есть более важные различия в принимающей стороне вещей. Когда получатель выполняет recv (или чтение) в сокете TCP, нет гарантии, что количество возвращенных байтов соответствует одной отправке (или записи) на стороне отправителя. Это может быть одно и то же, оно может быть меньше (или равно нулю), и может быть даже больше (в этом случае принимаются байты из нескольких отправлений/записей). С помощью WebSockets получение сообщения управляется событиями (обычно вы регистрируете процедуру обработчика сообщений), а данные в событии всегда являются целым сообщением, отправленным другой стороной.
Обратите внимание, что вы можете осуществлять связь на основе сообщений с использованием сокетов TCP, но вам нужен дополнительный слой/инкапсуляция, которая добавляет данные кадрирования/сообщения в сообщения, чтобы исходные сообщения могли быть собраны повторно из фрагментов. Фактически, WebSockets построен на обычных сокетах TCP и использует заголовки кадров, которые содержат размер каждого кадра и указывают, какие кадры являются частью сообщения. API WebSocket повторно собирает TCP-фрагменты данных в фреймы, которые собраны в сообщения, прежде чем вызывать обработчик событий сообщения один раз за сообщение.