일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 부트캠프 #CSS #개발일지 #TIL #박스모델
- textContent
- 부트캠프
- 깃허브오류
- Til
- 부트캠프 #개발일지 #TIL #FlexboxFroggy #displayflex #flexbox
- useState
- 개발일지
- 결합선택자
- 의사클래스
- CSS
- 부트캠프 #코딩 #개발일지 #프론트엔드 #CSS #TIL
- 부트캠프 #스파르타코딩클럽 #개발일지# #TIL #Javascript #confirm #location.href
- useEffect
- 부트캠프 #개발일지 #TIL #Position #위치
- 특성선택자
- js
- 부트캠프 #스파르타코딩클럽 #개발일지# #html
- 부트캠프 #개발일지 #TIL #CSS속성 #float #clear
- 부트캠프 #개발일지 #TIL #그리드 #CSS
- React
- appendChild
- 알고리즘
- querySelector
- JS예제
- 리액트
- 템플릿스트링
- 개발일지 #TIL #프론트엔드 #HTML
- ㅜㄹㄹ
- 부트캠프 #CSS #개발일지 #TIL
- Today
- Total
나의 개발일지
WebSocket | WebRTC 개념, 종류, 차이점 및 등장배경 본문
WebSocket | WebRTC 개념, 차이점 및 등장배경
우선 HTTP에 대한 개념부터 알아야 한다.
HTTP는 브라우저가 서버에게 요청(request)을 보내면 서버는 확인 후 브라우저에게 응답(response)을 준다.
이때 서버가 브라우저에게 데이터를 보낼 수 있는 것은 무조건 브라우저가 request를 했을 때만 가능하다.
서버가 그냥 브라우저에게 뭘 보낼 수가 없다!
우리가 만약 오직 HTTP만을 이용하여 채팅을 만든다면 새로운 메세지를 확인할 때, 계속해서 새로고침을 해야할 것이다.
이러한 문제점을 해결하기 위해 WebSocket이 생겨나게 되었다.
웹 소켓 프로토콜은 http와 다르다. request, response가 있는 것이 아니라 open-close로 커넥션이 이루어져 있다.
WebSocket은 서버와 클라이언트가 실시간으로 양방향 통신을 할 수 있게 해주는 프로토콜이다.
브라우저와 웹소켓을 이용해서 서버와 연결을 하면 브라우저 서버간 통신은 원하는 순간까지 계속 열려있을 것이다.
웹소켓은 리얼타임 경험을 위해 만들어졌는데 웹소켓을 이용하는 유저가 많아질수록 속도가 느려질 것이고, 더 많은 메모리가 필요하고, 이는 서버에 많은 비용을 써야 하는 것을 의미한다.
이러한 문제들 때문에 WebRTC(Web Real-Time Communications)가 등장한 것이다.
웹 어플리케이션 및 사이트들이 별도의 소프트웨어 없이 음성, 영상, 미디어 혹은 텍스트 파일 같은 데이터를 브라우저끼리 주고 받을 수 있게 만든 기술이다. WebRTC로 구성된 프로그램들은 별도의 플러그인이나 소프트웨어 없이 *P2P(Peer to Peer) 화상회의 및 데이터 공유를 한다.
WebRTC는 Web Socket에 비해 고성능, 고품질로 데이터 통신이 가능하고, 브라우저간 직접 통신하기 때문에 전송 속도가 훨씬 빠르다. 또한 네트워크 지연시간이 짧다.
다만, WebRTC만으로 제어하기 어려운 부분이 있으므로 WebSocket, 또는 Socket.io 를 사용해 신호를 주고받을 수 있는 Signaling 서버는 필요하다. 현재 Zoom, Google Meet, 매일 쓰고있는 Gather.town 에서도 이 WebRTC를 이용하여 화상회의 기능을 구현하였다.
socket.io란?
웹소켓을 사용할 수 없는 브라우저인 경우, 일정 간격마다 데이터를 받아오는 HTTP polling을 사용해 실시간 통신 기능을 구현하게끔 해주는 자바스크립트 라이브러리.
socket.io !== WebSocket
P2P (Peer to Peer)
인터넷에 연결된 다수의 개별 사용자들이 중개 기관을 거치지 않고 직접 데이터를 주고받는 것을 말한다. 영어로 Peer란 '동료'라는 뜻인데, 그 뜻에는 네트워크에 연결된 모든 컴퓨터들이 서로 대등한 동료의 입장에서 데이터나 주변장치 등을 공유할 수 있다는 의미를 담고 있다.
지금까지 인터넷에서 정보를 검색하기 위해서는 자료를 검색하기 위한 여러가지 검색사이트, 즉 중간에서 연결해 주는 서버가 필요했다. 이와는 다르게 피투피 방식에서는 이러한 서버의 필요 없이 동일 혹은 관련 프로그램에 접속한 사람들끼리 바로 서로의 정보를 공유할 수 있다는 장점이 있다. 이를 통해 공개된 웹사이트에 한정돼 있던 정보추출 경로를 개인이나 회사가 운영하는 데이터베이스로까지 확대할 수 있다. 즉 자신의 정보를 전국적으로 혹은 세계적으로 관리 및 운영하는 것이 가능하고, 회원 상호 간의 동일한 정보 공유뿐만 아니라 다양한 정보를 공유하고자 하는 회원 간의 커뮤니티 형성이 가능하며, 그룹웨어로서 역할을 통해 원격회의, 원격교육 등이 가능하다는 것이다.
WebRTC 서버 종류
1. Mesh(Signalling) 서버
- peer 간의 offer, answer라는 session 정보 signal만을 중계한다. 따라서 처음 webRTC가 peer간의 정보를 중계할 떄만 서버에 부하가 발생한다.
- 주로 1:1 연결에 사용된다.
- 서버에 부하가 없다.
2. SFU(Selective Forwarding Unit) 서버
- 미디어 트래픽을 중계하는 서버 방식
- 클라이언트 peer간 연결이 아닌 서버 <-> 클라이언트 간의 피어를 연결시킨다.
- 1:N 형식 또는 소규모 N:M 형식의 실시간 스트리밍에 적합하다.
- 클라이언트 받는 부하가 줄어든다
3. MCU(Multi-point Control Unit) 서버
- 다수의 송출 미디어를 중앙 서버에서 혼합 또는 가공하여 수신측으로 전달하는 중앙 서버 방식이다.
- 과부화로 Latency* 가 증가할 수 있다.
- 클라이언트 부하가 현저히 줄어들지만 서버 부담이 커진다.
* Latency (대기 시간)
하나의 데이터 패킷이 출발지에서 도착지까지 가는 데 걸리는 시간
사용자가 요청을 한 시점부터 해당 사용자에게 요청에 대한 응답을 받기까지 걸리는 시간
참고 사이트
https://requestum.com/blog/webrtc-vs-websockets