WebSockets построен на TCP.TCP гарантирует доставку и заказ пакетов.Кроме того, в отличие от TCP, WebSockets основан на сообщениях, что означает, что сообщения WebSocket принимаются как целое сообщение (TCP потоковый, а «сообщения» могут быть фрагментированы с точки зрения слушателя)
В node.js два выбросакоторые вызываются из одного и того же контекста (одной и той же функции) один за другим, будут доставлены в этом порядке.Однако, если ваши выпуски выполняются в двух разных обратных вызовах, вы не всегда можете гарантировать, что Node.js запланирует эти обратные вызовы, и поэтому выпуски могут быть переупорядочены, потому что запланированные обратные вызовы были переупорядочены.
Обновление:
Ниже приведен пример, объясняющий, почему управляемый событиями характер Node.js может привести к неожиданному переупорядочению передачи / отправки WebSocket:
fs.readFile(file1,function(e,data) { ws.send(data); });
fs.readFile(file2,function(e,data) { ws.send(data); });
Порядок доставки файлов file1 и file2 в браузер непредсказуем (даже размер файла не гарантирует, когда они сработают из-за таких вещей, как кэширование, фрагментация файловой системы и т. Д.).Даже если readFile из file2 вызывается через 1 секунду с использованием setTimeout, браузер все равно может получить их не по порядку (например, если file1 намного больше и для чтения требуется 3 с, тогда отправка file1 произойдет после отправки для file2).
Так что да, отправка / отправка будет осуществляться в браузере в порядке их вызова в Node.js, но из-за асинхронного характера Node.js, управляемого событиями, отправка / отправка может не происходить вожидаемый порядок.
Асинхронный характер Node.js, управляемый событиями, - это то, что дает Node.js отличную эффективность и производительность, но если вы не привыкли к этому типу программирования на основе обратных вызовов, у него могут быть некоторые неожиданностирезультаты.