WebSocket과 WebRTC에 대해 공부한 내용을 기록하려 한다.
HTTP의 단점을 보완하기 위해 등장하였고, 클라이언트와 서버 사이의 동적인 양방향 연결 채널을 구성하는 통신 프로토콜
WebSocket API를 통해 서버로 메시지를 보내고, 요청없이 응답을 받아오는 것도 가능.
WebSocket은 HTML5 기술이기 때문에 오래된 버전의 웹브라우저는 지원하지 않는데 이를 해결하기 위해 나온 것 중 하나가 Socket.IO이다. Socket.IO는 지원하지 않는 브라우저에 대해 일반 HTTP를 이용하여 실시간 통신을 흉내냄.
HTTP 이용했을 때는 요청을 해야 응답이 오는데 이를 개선하여 자유롭게 데이터를 주고 받을 수 있게하면 불필요한 자원 소모를 줄일 수 있음.
HTTP는 지나치게 많은 Header(KB)를 가지고 있지만, WebSocket은 Byte 단위까지 압축 가능하여 네트워크 과부하 (오버헤드)를 줄일 수 있음.
서버 클라이언트 연결을 HTTP를 사용하고 TCP/IP 기반 연결.
일정 시간 후 HTTP 연결은 끊긴다.
Web Real-Time Communications의 약자이며, 웹브라우저 상에서 플러그인 도움 없이 서로 실시간 통신할 수 있도록 설계된 기술. (음성채팅, 화상채팅, 데이터 교환 가능)
WebRTC 기술은 P2P 통신 최적화
아래와 같이 크게 3가지 클래스가 있다.
개방형 프로토콜인 HTML5의 취약한 보안점을 해소, 다른 방식에 비해 프로그램 설치도 필요없고 운영체제에 부담을 주지 않음.
단순 P2P와 다르게 크게 4가지 Step을 거쳐 동작한다.
(() 내용은 프로토콜)
caller가 callee를 Call할 때 Signaling server가
양쪽의 signal OK를 확인 후 연결 및 서로의 IP주소 교환한다.(통신 방식 같은 기본 정보도 같이 전송)
Signaling을 하기 위해 도움을 주는 서버가 있다.
- STUN(Session Traversal Utilities for NAT)
- peer 연결을 가능하게 해줄 public IP를 제공.
- TURN(Network Address Translation)
- STUN의 확장으로 STUN을 통해 IP를 얻지 못한 경우 사용.
- TURN 서버는 인터넷망에 위치하고 각 Peer들이 private IP안에서 통신한다.
- 각 Peer들이 직접 통신하는 것이 아니라 릴레이 역할을 하는 TURN 서버를 통해 경유한다.
- TURN은 이러한 릴레이로부터 IP 주소와 포트를 클라이언트가 취득할 수 있는 릴레이 주소를 할당한다.
- STUN에 비해 리소스 낭비가 심하다.
프로젝트를 하면서 WebSocket과 WebRTC 방식 중 어떤 것을 택해야 하는 상황이 왔다.
WebSocket과 WebRTC를 크게 2가지로 생각해보았다.
- TCP vs UDP
- 서버에 부담 vs 클라이언트에 부담
프로젝트 특성상 실시간이라는 키워드와 클라이언트에 큰 부담을 주지 않을 수준이라 WebRTC를 선택하였다. 그리고 뭔가 새로운 기술이라 더 끌렸던 것 같다.
참고 사이트
https://gh402.tistory.com/45
https://post.naver.com/viewer/postView.nhn?volumeNo=30734315&memberNo=33264526&vType=VERTICAL
https://medium.com/@hyun.sang/webrtc-webrtc%EB%9E%80-43df68cbe511
https://www.html5rocks.com/ko/tutorials/webrtc/infrastructure/#how-can-i-build-a-signaling-service
https://doublem.org/webrtc-story-02/
https://lovejaco.github.io/posts/webrtc-connectivity-and-nat-traversal/