Today I Learned

Web Socket?

서버와 클라이언트 간의 메시지 교환을 위한 통신 규약(프로토콜)

1. 특징

1) 양방향 통신(Full-Duplex)

• 데이터 송수신을 동시에 처리
• HTTP -> client 가 요청을 보내는 경우에만 Server가 응답 (단방향 통신)
• Web Socket -> 쌍방간에 서로 정보교환이 가능 (양방향 통신)

2) 실시간 네트워킹 (Real Time Networking)

• 웹 환경에서 연속된 데이터를 빠르게 노출 (채팅, 주식 등)

2. Web Socket 이전의 통신 방법

1) HTTP

HTTP의 특징

2) 폴링(Polling)

폴링의 특징

• 클라이언트가 서버에 일정한 주기로 request
• 서버는 해당 요청의 응답으로 현재 상태의 데이터를 반환
• setTimeout, setInterval 등으로 일정 주기마다 서버에 요청(Request)

단점

• 불필요한 Request & Connection 생성 -> 서버에 부담
• 요청 주기가 짧을 수록 부하 ⬆️
• '일정 주기마다' 요청을 보내는 것이기 때문에 실제로는 실시간 ❌
• HTTP 통신을 하기 때문에 Request, Response 헤더가 불필요하게 크다.

Polling 방식을 선택하는 경우

• 응답을 실시간으로 받지 않아도 되는 경우
• 다수의 사용자가 동시에 사용하는 경우
• 예시 : facebook 웹 채팅, google 메신저, msn 웹 메신저

3) 롱 폴링(Long Polling)

롱 폴링의 특징

• 클라이언트가 일정한 주기로 서버에 데이터를 request
• 서버는 데이터가 업데이트되거나 타임아웃이 발생하면 응답을 반환

장점

• Polling에 비해 불필요한 네트워크 트래픽을 줄이고, 실시간성을 보다 효과적으로 구현

단점

• 클라이언트의 연결 유지와 서버의 동시 접속 처리에 대한 고려가 필요
• 동시 다발적인 요청과 응답이 생기면 부하가 발생
• Polling과 마찬가지로 헤더가 불필요하게 큼

Long Polling 방식을 선택하는 경우

• 응답을 실시간으로 받아야하는 경우
• 적은 수의 사용자가 동시에 사용하는 경우

4) Streaming

스트리밍의 특징

• 이벤트가 발생했을 때 응답을 내려주되, 응답을 완료시키지 않고 계속 연결을 유지

장점

• Long Polling에 비해 응답마다 다시 요청을 하지 않아도 되므로 효율적

단점

• 연결 시간이 길어질 수록 연결 유효성 관리의 부담이 발생
• HTTP 통신이기 때문에 마찬가지로 헤더가 불필요하게 큼

3. 웹소켓 동작 과정

1) Opening Handshake

Request Header

GET /chat HTTP/1.1
Host: localhost:8080
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==
Sec-WebSocket-Protocol: chat, superchat
Sec-WebSocket-Version: 13
Origin: http://localhost:9000

• 접속 요청은 HTTP(GET)로 한 뒤, 웹소켓 프로토콜로 변경
• GET /chat HTTP/1.1 : HTTP 버전은 1.1 이상, GET 메서드를 사용
• Upgrade : 프로토콜을 전환하기 위해 사용, 이 값이 없거나 다른 값이면 cross-protocol attack으로 간주, 웹 소켓 접속을 중지
• Connection : 현재의 전송이 완료 후 네트워크 접속 유지를 희망하는지에 대한 정보, 이 값이 없거나 다른 값이면 마찬가지로 웹 소켓 접속 중지
• Sec-WebSocket-Key : 유효한 요청인지 확인하기 위해 사용하는 키 값
• Sec-WebSocket-Protocol : 사용하고자 하는 하나 이상의 웹 소켓 프로토콜 지정
  필요한 경우에만 사용
• Sec-WebSocket-Version : 클라이언트가 사용하고자 하는 웹소켓 프로토콜 버전
• Origin : CORS 정책과 관련, Cross-Site Websocket Hijacking과 같은 공격을 피하기 위함

Response Header

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat

• HTTP/1.1 101 Switching Protocols : 프로토콜 전환 요청이 승인되었다는 응답코드
• Sec-WebSocket-Accept : 요청 헤더의 Sec-WebSocket-Key에 유니크 아이디를 더해서 SHA-1로 해싱한 후 base64로 인코딩한 결과, 웹 소켓 연결이 개시되었음을 알림

2) Data transfer

• Opening HandShake에서 승인이후 Data transfer 진행
• 데이터는 메시지라는 단위로 전달

메시지

• 여러 프레임(frame)이 모여서 구성되는 하나의 논리적인 단위

프레임

• 데이터 링크계층 통신에서 가장 작은 단위의 데이터
• 작은 헤더 + payload 로 구성

3) Closing Handshake

• 클라이언트와 서버 모두 커넥션을 종료하기 위한 컨트롤 프레임을 전송
• 서버가 커넥션을 종료한다는 프레임을 보내고, 클라이언트가 이에 대한 응답으로 Close 프레임을 전송 -> 웹소켓 연결 종료