Это займет немного творческой работы, потому что вам придется подождать, пока первые данные не поступят во вновь подключенный сокет, чтобы определить, каким типом соединения это должно быть. Оба начинаются с входящего TCP-соединения.
Соединения webSocket затем следуют за начальным соединением TCP с запросом http, который запрашивает обновление протокола до протокола webSocket. Вы можете проверить первые данные, которые поступают во вновь подключенный сокет TCP, и проверить, действительно ли первые данные в сокете являются http-запросом этой формы. Если это так, то это входящее соединение webSocket.
Если нет, то это должно быть ваше обычное TCP-соединение. В любом случае, после того, как вы определили тип подключения, вы должны передать начальные данные соответствующему обработчику для этого типа подключения, чтобы он мог взять на себя обработку этого сокета.
Несколько похожая модель используется, чтобы позволить серверу http и серверу webSocket использовать один и тот же порт. Для них это немного проще, так как оба протокола начинаются с HTTP-запроса, но идея та же, что когда сервер webSocket использует общий http-сервер, он проверяет входящий запрос, чтобы увидеть, похоже ли это на начало соединения webSocket. (HTTP-запрос с заголовком upgrade). Если это так, он передает запрос к коду обработки webSocket. Если нет, он обрабатывает его как обычный входящий http-запрос и передает его к коду обработки http-запроса.
Вы можете посмотреть, как выглядит исходное соединение webSocket: Как работает архитектура сервера WebSockets? и здесь: узел js net сокеты + websocket без socket.io . Оба покажут вам форму исходного http-запроса, который инициирует все соединения webSocket.