무엇을 만들면 좋을까 고민!

사실 점심 먹을 카뎃 찾기 서비스는 42 평가방식처럼 스케줄러가 화면에 나오고 그에 따라 클릭해서 미리 예약하는 방식이 가장

좋지 않을까 싶지만! 심심해서 만들어 보는 것인데~ 이왕 재밌는 기술을 사용하는게 좋다고 생각했다.

그래서 선택 한 것은 WebRTC!

프로젝트가 궁금하면 클릭!!! 열심히 작동하고 있어요!

https://randommeal.du.r.appspot.com/ Bob Muk Za – BMZ randommeal.du.r.appspot.com

짜잔!! 일주일동안 열심히 만들었다.  JS와 html, css 부분을 잘 몰라서 완전히 하드 코딩하여 만든 결과물이다.

이호준멘토님께서 아시면 혼나실 일이지.. 컴포넌트화  해야 하는데!! 일단 작동하는데 급급해서!! 똑같은 기능이지만 조오금 다른데도

불구하고 손수 한땀 한땀 인형 눈알 붙이듯! 하드코딩해버렸다! 아주 독립적이란말이기도 합니다… 헛소리…..

자 이제 어떻게 만들었는지! 살펴보죠!

처음 접하는 WebRTC이기 때문에 생소하고 어려웠습니다.

지금까지 연습 해온 것은 REST API로 요청응답하는거 CORS외엔 신경쓰지 않았습니다.

클라이언트(사용자)가 자신이 사용 할 공인 IP를 알지 못한다는 사실을 이번에 처음 알게 되었습니다.

이번 프로젝트는 구글 STUN서버를 사용했고, 대부분 클라이언트 작업을 했습니다.

서버는 시그널링 서버로 메타 데이터를 교환할 때 사용합니다 (무지 단순하단 소리)

프로젝트를 설명하기위해 간략하게 설명하지만 자세한 내용은 링크를 참고해주세요!

저두 잘 모르기에 틀릴수도 있으니 고쳐야 할 것이 있으면 호다닥 알려주세요!

이해를 돕기 위해 그림 위주로 설명합니다!

WebRTC란?

WebRTC는 P2P 통신을 가능하게 합니다.

현재 우리가 주로 사용하고 있는 카톡도 서버를 통해 전송 된다는 사실!!

  • 시그널링(Signaling)이라 불리는, 클라이언트들의 통신을 조정하기 위한 메타데이터의 교환 서버
  • 네트워크 주소 변환기(NAT) 및 방화벽 대응을 위한 서버

그래서 우리가 해야 할 일은?

프론트엔드 : 소켓 연결 및 WebRTC API를 통한 P2P 연결

백엔드 : 시그널링, 네트워크 주소 변환 서버

시그널링은 통신 연결을 위한 프로세스입니다.

  • 통신을 열고 닫는데 사용되는 세션 컨트롤 메세지들.
  • 에러 메세지들.
  • 코덱이나 코덱 설정, 대역폭, 미디어 타입 같은 미디어 메타데이터.
  • 보안 연결을 수립하기 위해 사용되는 키 데이터.
  • 밖에서 보이는 것처럼 호스트의 IP 주소와 포트와 같은 네트워크 데이터

STUN(Session Traversal Utilities for NAT)이란?

STUN 프로토콜이 필요한 이유는 사설망에 위치한 클라이언트는 자신의 공인 IP를 알지 못하기 때문입니다.

클라이언트는 자신의 공인 IP주소를 확인하기 위해 STUN 서버에 요청하고 STUN 서버는 클라이언트가 사용하는 공인 IP주소로 응답합니다. STUN에서 두 클라이언트가 같은 NAT환경에 있다면 동작하지 않습니다. 또한 SYmmetric NAT으로 동작하는 사설망 환경에서는 

애플리케이션이 다르면 NAT 매핑 테이블이 바뀌기 때문에 사용 할 수 없습니다.

TURN (Traversal Using Relays around NAT)이란?

TURN 프로토콜은 릴레이 서버를 이용하여 통신하게 합니다. TURN 클라이언트는 P2P 통신을 하는게 아니라 서버를 경유합니다.

클라이언트는 자신의 Private IP가 포함된 TURN 메세지를 서버로 보냅니다. 서버는 메세지에 포함된 Network Layer IP 주소와 Transport Layer의 UDP 포트 넘버와의 차이를 확인하고 클라이언트의 Public IP로 응답하게 된다.

NAT는 NAT 매핑테이블에 기록되어 있는 정보에 따라서 내부 네트워크에 있는 클라이언트의 Private IP 로 메세지를 전송합니다.

ICE(Interactive Connectivity Establishment)

두 단말 간 의 제안 및 수락 모델로 생성되는 실시간 UDP 미디어 스트림을 송수신하기 위한 것입니다.

ICE는 STUN, TURN 프레임워크로 확보된 통신 가능한 여러 IP 주소와 포트 넘버를 SDP Offer, Answer를 통해 상대방에게 전달합니다.

두 단말은 확보된 모든 주소에 대해 P2P 테스트를 진행하고 통신 가능한 주소로 미디어 스트림을 송수신 합니다.

ICE Candidate는 IP주소와 포트 넘버의 조합으로 표시된 주소를 의미합니다

나의 BMZ 서비스의 WebRTC 연결 과정 (STUN은 구글 서버 사용)

이번 프로젝트에서 고생 한 점

1. 브라우저 캐시로 인해 CSS 적용이 제대로 되지 않았던 점

서버 배포를 다시하고 아무리 열심히 확인해봐도 변경 된 CSS가 적용되지 않아서 대체 왜일까 하면서 한시간동안

계속 수정하고 디버깅모드로 확인하고 했지만 전혀 변경되지 않았었습니다. 그러던 중 프론트엔드를 전문으로 하는 kkang님의 도움으로

캐시 문제일걸요? 라고 하면서 시크릿모드로 확인해보세요 하니 아 이런?? 앞으로는 캐시를 조심해야겠습니다.

2. 보안 설정이 되어 있는 와이파이를 통한 접속 불가능

Local환경에서는 여러개를 동작시켜도 문제가 없었는데 말이죠! 그런데 배포하고나니 문제가 발생했습니다.

누구는 접속이 가능하고 누구는 접속이 불가능한 상황에 직면한것이죠!!

처음엔 브라우저의 버전 문제로 인해 되지 않았나라는 생각으로 브라우저 버전을 확인하고 버전을 맞춰도 접속 불가능

그렇다면 컴퓨터 자체 윈도우 OR 맥 그 차이점인것인지 궁금해서 그 차이인지 조사해보았지만 그것도 아니었습니다.

그래서 결국 아 그렇다면!! 내가 Socket io 코드를 잘못 작성한것이구나 싶어서 인터넷에 비슷한 사례 코드를 열심히 넣었지만

모두 FAIL……….. 이유를 알 수 없었습니다.

그러다가 kchoi가 와이파이가 달라서 그런가 했는데 바꾸자마자 작동 하기 시작….!

이래서 TURN 서버가 필요한것인지 ~ ! 아니면 시그널링 서버 구현이 잘못 된 것인지 확인해봐야 합니다.

3. 한땀 한땀 하드 코딩 무언가를 수정하기 어려워!

자바스크립트, html, css에 익숙하지 않았습니다. 지금은 이것을 작성하기전보다는 조금 익숙해진 것 같긴 합니다.

프론트엔드 개발 할때 컴포넌트화해서 재사용성을 생각해야 한다!! 라고 얼핏 들었지만 일단 돌아가게 하는게 중요하지!

라고 생각하면서 버튼 하나하나 한땀 한땀 작성하였습니다. 그래서 그런지 무언가를 수정해야 하면 한땀 한땀 수정해야해서

굉장히 오랜 시간이 걸렸습니다. 바퀴를 재발명하지 말란 소리가 아 이런 소리인가 싶었는데…..

여튼 장점은 독립적이기 때문에 하나가 연쇄적으로 영향을 주지 않는다는 점 뿐이었습니다.

총평

웹 백엔드 개발자가 되기 위해선 네트워크가 중요하다. HTTP부터 차근차근 열심히 지식을 쌓아 올리도록 하자!

그리고 혼자 무언가를 개발하려고 하면 간단하게 풀스텍 정돈 할 수 있어야 하나보다. 그런데 나는 자바스크립트에 관한 지식도 부족해!

할게 뭐이라 많을까~싶지만 재밌는것도 있으니 모르겠다 잘해보자! 아마 다들 나처럼 프론트 개발 해야지 하다보면 백엔드 필요하고

백엔드 하다보면 프론트 필요하다보니 고통 받으면서 하고 있지 않을가 싶기도하다.

이번 프로젝트에서 자바 백엔드 개발자로의 역활은 거의 하지 못했다. 왜냐하면 원래 STUN, TURN, SIGNALING 서버 3개를 만들어야 하는데 난 시그널링만 서버만 만들었기 때문이다. 앞으로 차근차근 공부해서 나머지 서버들도 다 만들어야겠다.

참고 자료

https://webrtc.github.io/samples/

https://developer.mozilla.org/ko/docs/Web/API/WebRTC_API

https://www.html5rocks.com/ko/tutorials/webrtc/infrastructure/

https://brunch.co.kr/@linecard/156