전체 앞뒤 프로토콜 구성표는 매우 잘 문서화되어 있습니다 here.
1) 브라우저가 업그레이드 된 프로토콜에 대한 답변을 기다리고 있습니까?
예, 고객이 전송 :
GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13
서버는이 응답 : 그것은 다음 않습니다
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
2) 무엇을?
이 확인 메시지가 서버와 101 응답 코드에서 수신되면 클라이언트는 서버가 현재 소켓을 webSocket 프로토콜로 전환했음을 알게됩니다. 이 현재 열린 소켓 (원래 http 요청에서)은 webSocket 소켓이됩니다. 클라이언트 또는 서버는 이제 webSocket 형식의 데이터 프레임을 다른 쪽 끝으로 자유롭게 보낼 수 있습니다.
3) 웹 소켓의 경우? 그것은 첫 핸드 셰이크 연결을 닫고 새로운 연결을 설정합니까?
아니요, 초기 http 요청의 원래 소켓은 webSocket 연결이됩니다.
다시는 그것은 각각의 끝이 원래의 소켓에 대해 유지 상태의 한 부분이다
사용하는 것을 protoc에 대한 정보를 캐시 않습니다. 새로운 소켓이 열리지 않습니다.
4) 내가 알고있는 WS 라이브러리가 많지만 고유 한 nodej 모듈 만 사용하는 경우 어떻게 작동하는지 알고 싶습니다.
이 어떻게 작동하는지 이해하는 것이 좋다, 그러나 이것은 단지 학문적 관심이나 프로젝트가 아닌 경우가 여러 번 다른 사람에 의해 수행되었습니다로 아마 자신의 웹 소켓 프로토콜을 작성하는 개발 시간의 비효율적 인 사용을 그리고 그것은이다 세부 사항의 공정한 양은 사양의 일부 변형과 함께 모든 것이 정확하고 상호 운용되도록해야합니다.
이미 여기에 설명 된 내용의 상단에
는, 당신은 단계별로 볼 수 있습니다
... 데이터 프레임 포맷, 암호화 키, 패킷 단편화, 핑 및 pongs, 하위 프로토콜 지원 등있다 여기에 서버에 대한 webSocket 연결을 만드는 프로세스 : https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers – jfriend00