채팅을 위한 노력의 역사 그리고 WebRTC

웹에서 기본적으로 클라이언트와 서버의 통신은 HTTP 방식으로 이루어진다. 클라이언트는 필요에따라 서버에 요청을 보내고 서버는 요청에 대한 응답을 보낸다. HTTP의 특징인 "단방향성"과 "비연결성"은 위와 같은 일반적인 웹상황에서 부족함이 없었다. 하지만 웹이 발전하고 풍부해짐에 따라 문제가 발생했다. 이제 사람들은 단순히 웹에서 정보 조회 뿐 아니라 사람들과 소통하고 싶어했고, 서비스 제공자들은 웹에서 채팅기능을 추가하고 싶었다. 하지만 지금까지 문제 없었던 "단방향성"과 "비연결성"이 발목을 잡았다. 

 

---

 

처음 사람들이 생각해낸 방법은 짧은 주기로 계속 요청을 보내는 것이다(이를 Polling Request라고 부른다). 예를들어 1초마다 새로 올라온 채팅내역이 있는지 계속 요청하는 것이다. 이를 통해 어느정도 채팅 기능을 구현 할 수 있었다. 하지만 이 무식한 방법은 많은 문제점이 존재했다.

• 요청 주기에 따라 채팅 내역이 업데이트 된다. 즉 엄밀한 의미의 실시간 채팅이 아니다. 요청주기가 1초라면, 1초동안은 서로의 메시지 내역을 주고 받을 수 없다.
• 아무런 채팅내역이 없어도 계속 요청이 반복된다. 즉 무의미한 요청과 응답이 계속될 수 있다.
• 당연한 얘기겠지만 반복적인 요청은 서버에 부담이 된다. 위의 문제 때문에 주기를 줄이려 할 수록 서버에는 부담이 된다. 마치 스스로의 서버에 DDOS를 거는것과 같다...

 

---

사람들은 다시 생각했다. 스스로의 서버에 DDOS를 걸지 않기 위해 고민했고, Long Polling 방식이 등장했다. HTTP 방식의 "비연결성"이 문제니까, 연결을 억지로 붙잡고 늘려본 것이다. 클라이언트는 서버에 요청을 보내고, 정해진 Timeout까지 서버의 응답을 기다립니다. 그리고 서버는 요청을 받고, 그 요청을 붙잡고 잠이 듭니다.... 새로운 채팅 내역이 생기면 잠에서 깨어나서 붙잡고있던 요청으로 응답을 보냅니다. 그리고 클라이언트는 응답을 받고 바로 다시 서버로 요청을 보내고 기다리고, 이를 반복합니다. 

• HTTP의 특징인 "비연결성"과는 다르게, 서버와 클라이언트는 사실상 항시 연결되어있는 상태이다.
• 하지만... 이 방법 역시, 채팅이 짧은 주기로 계속 올라온다면 미칠듯한 요청과 응답이 발생한다. 

 

 

---

결론적으로 "단방향성"과 "비연결성"을 특징으로 가지고있는 HTTP로는 문제를 해결할 수 없었다. 그래서 사람들은 WebSocket이라는 새로운 프로토콜을 만들었다. WebSoket은 무려 "양방향성"과 "연결성"을 가지고 있다...! 이제 클라이언트와 서버는 한번의 연결로 지속적으로 데이터를 주고받을 수 있게되었다. 채팅을 입력하면 클라이언트에서 서버로, 또 서버에서 다른 클라이언트로 낭비없이 자연스럽게 데이터가 흐를 수 있게 되었다. 해피엔딩!

 

 

---

 

해피엔딩이었는데, 누군가 발칙한 상상을 떠올리기 시작했다. "아니?! 클라이언트끼리 채팅하는데... 서버가 왜 필요해?" 다른 사람들은 그게 무슨 말이냐고 물었다. 그러자 그 사람은 "괜히 서버를 거칠 필요없이, 클라이언트끼리 바로 통신하면 되잖아!"라고 답했다. 천재인가? 그렇게 WebRTC가 등장했다.

 

 

 

 

클라이언트는 Stun Server를 통해 본인이 누군지 알고, 이를 본래의 Server에게 알려준다. 그리고 통신할 상대 클라이언트가 누군지에 대한 정보를 듣는다. 이렇게 둘 모두 서로에 대한 정보를 알게되면, 비로소 둘은 연결되고 서버없는 둘만의 대화를 시작한다. 얘기만 들으면 너무나도 좋은 기술이지만 여러가지 현실적인 문제로 인해, 제한적인 부분에서만 사용되고 있다.

• 본인의 IP를 서버와 상대방 클라이언트에 알려줘야하기에, 사용자에게 브라우저를 통한 허락을 구해야한다.
• P2P통신의 근본적 한계로 인해, 연결이 불안정하다.
• Stun Server를 통해 본인이 누군지 알아도, 대부분의 디바이스가 NAT의 뒤에 존재하는 현재의 네크워크 환경으로 인해 높은 확률로 연결을 할 수 없다.

 

예제

Client1: https://webrtc-study.s3.ap-northeast-2.amazonaws.com/chat_local2.html

Client2: https://webrtc-study.s3.ap-northeast-2.amazonaws.com/chat_remote2.html