0. 글을 작성하는 이유
최근에 Web RTC 관련 프로젝트를 진행하게 되었습니다.🤓
Web RTC에 관한 정보를 찾아 보던 와중에 Web Socket 에 관한 정보를 읽게 되었고, 결국 Web RTC는 Web Socket을 내부적으로 사용하는 사실을 알았습니다.
따라서 사용해야 하는 최종 기술을 잘 사용하기 위해서 핵심이 되는 웹 소켓 통신을 공부하고 정리하고자 이 글을 작성합니다. 🧑🏻💻
[사전 지식]
- Socket : 네트워크 세계에서 데이터를 받기 위한 창구를 의미하며, 프로토콜, IP주소, 포트 넘버로 정의됩니다.
- HTTP 통신 포트 : 80
- HTTPS 통신 포트 : 443
1. 웹 소켓 (Web Socket)
전송 프로토콜의 일종으로 두 프로그램 간의 메시지를 교환하기 위한 통신 방법 중 하나입니다.
- 2014년 10월 28일 HTML5 버전이 나올 때 함께 등장 했습니다.
- W3C와 IETF에 의해 자리잡은 표준 프로토콜 중 하나 입니다.
- 현재 인터넷 환경 (HTML5) 에서 많이 사용됩니다.
- 웹 소켓은 단순한 API로 구성되어있습니다.
- 전송 프로토콜의 일종으로 서버와 클라이언트 간의 효율적인 양방향 통신을 실현하기 위한 구조입니다.
- 웹 소켓이 나오기 이전에는 서버는 클라이언트의 요청이 없을 경우 서버로부터 응답을 받을 수 없는 구조였습니다.
[웹 소켓 특징]
- 웹 소켓을 지원하는 브라우저의 경우 웹 소켓 프로토콜을 지원합니다.
- 양방향 통신 (Full-Duplex)
- 데이터 송수신을 동시에 처리할 수 있는 방법
- 클라이언트와 서버가 서로에게 원할 때 데이터를 주고 받을 수 있습니다.
- 통상적인 HTTP 통신은 Client가 요청을 보내는 경우에만 Server가 응답하는 단방향 통신 입니다. (Stateless) (Half-Duplex)
- 실시간 네트워킹 (Real Time-Networking)
- 웹 환경에서 연속된 데이터를 빠르게 노출
- Ex) 채팅, 주식, 비디오 데이터
- 여러 단말기에 빠르게 데이터를 교환
- 일반 Socket 통신과 달리 HTTP 80 Port를 사용하므로 방화벽에 제약이 없으며 통상 Web Socket 으로 불립니다.
2. 웹 소켓 동작 방법
웹 소켓 연결은 HTTP 프로토콜을 통해 이루어집니다.
연결이 정상적으로 이루어진다면 서버와 클라이언트 간에 웹 소켓 연결(TCP/IP기반)이 이루어지고 일정 시간이 지나면 HTTP 연결은 자동으로 끊어집니다.
- 요청
GET/chat HTTP/1.1: HTTP 1.1 버전 이상, GET 메소드만 사용 가능합니다.
Upgrade : websocket: 현재 클라이언트, 서버, 전송 프로토콜 연결에서 다른 프로토콜로 업그레이드 또는 변경하기 위한 규칙
Connection : Upgrade: Upgrade 헤더 필드가 명시되었을 경우, 송신자는 반드시 Upgrade 옵션을 지정한 Connection 헤더 필드도 전송 해줘야 합니다.
Sec-WebSocket-Key : {키 값}: 길이가 16바이트인 임의로 선택된 숫자를 base64로 인코딩한 값 - 응답
HTTP/1.1 101 Switching Protocols: 101 Switching Protocls가 Response로 오면 웹 소켓이 연결된 것 입니다.
Sec-WebSocket-Accept : {키 값}: 클라이언트로부터 받은 Sec-WebSocket-Key를 사용하여 계산된 값 - 데이터 전송
- 프로토콜이 ws로 변경
- 데이터 보안을 위해서 SSL을 적용한 프로토콜인 wss도 사용 가능합니다.
- Message : 여러 frame이 모여서 구성하는 하나의 논리적 메시지 단위
- frame : communication에서 가장 작은 단위의 데이터, 작은 헤더 + payload로 구성
- 웹 소켓 통신에 사용되는 데이터는 UTF8 인코딩
Ex) 0x00 (보내고 싶은 데이터) oxff
- 연결 종료
- Close Frame을 주고 받으며 연결을 종료
[웹 소켓 프로토콜의 특징]
- 최초 접속에서만 HTTP 프로토콜 위에서 handshaking을 하기 때문에 HTTP Header를 사용합니다.
- 웹 소켓을 위한 별도의 포트는 없으며, 기존 포트 (http-80, https-443)을 사용합니다.
- 프레임으로 구성된 메시지라는 논리적 단위로 송수신합니다.
- 메시지에 포함될 수 있는 교환 가능한 메시지는 텍스트와 바이너리 뿐 입니다.
3. 웹 소켓 이전의 비슷한 기술
아래의 3가지 방법 모두 HTTP를 통해 통신하기 때문에 Request, Response 둘 다 Header가 불필요하게 큽니다.
- Polling
- 서버로 일정 주기 요청 송신
- Real-Time 통신에서는 언제 통신이 발생할지 예측이 불가능
- 불필요한 Request와 Connection을 생성
- Long Polling
- 메시지가 있으면 가져오고 없으면 대기합니다.
- Streaming
- 서버에 요청을 보내고 끊기지 않은 연결 상태에서 끊임없이 데이터를 수신
- 클라이언트에서 서버로의 데이터 송신이 어려움
4. 웹 소켓 한계
- 웹 소켓은 HTML5 이후에 나왔습니다. HTML5 이전 버전의 웹 브라우저에서는 웹 소켓을 지원하지 않습니다.
- 이를 해결하기 위해 나온 여러 기술 중 하나가 Socket.io(양방향 통신 JS 라이브러리) 입니다.
- 웹페이지가 열리는 브라우저가 웹 소켓을 지원하면 웹 소켓 방식으로 동작하고, 지원하지 않는 브라우저라면 일반 HTTP를 이용해서 실시간 통신을 흉내냅니다.
5. 웹 소켓 쓰는 이유
- 변경 사항에 빠르게 반응해야 하는 경우에 사용합니다. Ex) 실시간 채팅
- 리소스 상태에 대한 지속적 업데이트가 필요한 경우 사용합니다. Ex) 문서 동시 편집
6. 웹 소켓 단점
- 서버와 클라이언트 간의 Socket 연결 유지 비용이 많이 듭니다.
- 오래된 버전의 웹 브라우저에서는 지원하지 않습니다.
- 서버와 클라이언트 간의 연결이 끊어졌을 때 생성되는 에러 메시지가 구체적이지 않아서 디버깅 하기 어렵습니다.
7. 결론
Web Socket은 HTML5 이전 버전, 서버로 부터 응답을 받을 수 없는 Half-Duplex 구조를 개선하고자 나온 통신 방법으로 양방향 통신 Full-Duplex 구조 입니다.
따라서 실시간 양방향 데이터 통신이 필요한 경우에 사용합니다.
Ex) 화상 채팅, 증권 거래 정보 사이트, 구글 Doc
하지만 한계와 단점이 존재하므로 상황에 맞게 쓰는 것이 중요합니다.🤔
출처
