Вот как Socket.io работает в двух словах:
Во-первых, socket.io представляет собой тонкий слой протокола поверх WebSocket, так на самом деле, мы собираемся обсудить, как WebSocket работы.
соединение WebSocket начинается с обычным запросом HTTP с одним специальным набором заголовков, обновлением заголовком, который запрашивает обновление от протокола HTTP к протоколу WebSocket.
Когда сервер получает запрос и видит заголовок обновления, если он поддерживает этот протокол, он отвечает на 101 ответ (протоколы переключения) и некоторые другие заголовки. Когда клиент получает этот ответ (и некоторые другие заголовки, связанные с безопасностью), то оба конца переключают протокол на этот самый сокет на протокол webSocket.
Поскольку протокол webSocket предназначен для непрерывного подключения, клиент и сервер сохраняют исходный разъем открытым для будущей связи и, фактически, он остается открытым, пока обе стороны не решают, что в конечном итоге они будут выполнены с каналом связи webSocket и затем закрывает сокет.
Таким образом, гнездо остается открытым в течение длительного времени. Это позволяет любой стороне отправлять сообщение другому в любое время. Таким образом, это позволяет избежать опроса. Вместо временного HTTP-запроса от клиента, который запрашивает сервер: «У вас есть новые данные для m?», Клиент может просто сидеть там и слушать входящие сообщения. Когда у сервера есть что-то новое для отправки клиенту, у него уже есть это открытое соединение с WebSocket, и он может просто отправить сообщение клиенту в любое время.
Socket.io добавляет несколько функций поверх webSocket. Главные вещи, которые он добавляет, это: 1) автоматическое повторное соединение, если соединение сокета теряется по какой-либо причине; 2) регулярные пинги с одного конца на другой, чтобы обнаружить, когда соединение потеряно, и 3) слой обмена сообщениями, который делает его тривиальным отправлять именованные сообщения с одного конца на другой.
Я хотел бы знать, как socket.io метода работы для излучения определенного события, я прочитал, что это не так, как методы давно опроса, но в другую, которая может работать на все различных браузеров
Это длинный опрос, потому что он держит соединение сокета открытым в течение всего срока действия клиента. Это долгоживущее открытое соединение может использоваться для простого отправки сообщений с любого клиента на сервер или с сервера на клиент без необходимости создавать новое соединение каждый раз, когда вы хотите отправить. Это будет работать в любом браузере, поддерживающем протокол webSocket.
Как клиент может поддерживать контакт с сервером без длинного запроса на опрос ?
Соединение с WebSocket предназначено для долговременного подключения, а не для типичного временного HTTP-соединения.
Если вы хотите узнать больше о самой WebSocket протокола, вы можете увидеть довольно хорошее описание здесь, в этой статье MDN: Writing webSocket Servers.
Вот пример первоначального запроса клиента, чтобы открыть WebSocket:
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
И вот типичный ответ сервера, который подтверждает переход на протокол WebSocket:
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Затем, когда протокол был изменен, вот как выглядит рамка данных webSocket:
0 1 2 3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len | Extended payload length |
|I|S|S|S| (4) |A| (7) | (16/64) |
|N|V|V|V| |S| | (if payload len==126/127) |
| |1|2|3| |K| | |
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
4 5 6 7
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Extended payload length continued, if payload len == 127 |
+ - - - - - - - - - - - - - - - +-------------------------------+
8 9 10 11
+ - - - - - - - - - - - - - - - +-------------------------------+
| |Masking-key, if MASK set to 1 |
+-------------------------------+-------------------------------+
12 13 14 15
+-------------------------------+-------------------------------+
| Masking-key (continued) | Payload Data |
+-------------------------------- - - - - - - - - - - - - - - - +
: Payload Data continued ... :
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Payload Data continued ... |
+---------------------------------------------------------------+
Socket.io использует фрейм данных webSocket, но вставляет свой собственный формат сообщения внутри полезной нагрузки этого фрейма, что позволяет ему отправлять именованные сообщения.
Если вы хотите «изобретать колесо», чтобы понять, что происходит, я предлагаю вам просмотреть источник для [серверной стороны] (https://github.com/socketio/socket.io) и [client- side] (https://github.com/socketio/socket.io-client) репозитории ... FYI, реализация 'socket.emit' совсем не легка и фактически опирается на несколько резервных копий, один из которых _does_ включает длительный опрос, если другие транспорты, такие как WebSockets, не существуют. –
Вы прочитали этот вопрос http://stackoverflow.com/questions/16719282/how-does-socket-io-work? –
@Wahib Спасибо за ваш комментарий. Да, я прочитал этот вопрос, но я бы хотел попросить более интересные вещи, такие как jfriend00, указал – pippo