NDC Replay

공유기를 뚫어라!
송인권
넥슨코리아
현재 넥슨 코리아 기반기술팀에서 게임내 실시간 커뮤니케이션을 위한 기반 라이브러리 개발과 관련 기술 연구를 진행하고 있습니다. 과거에는 (주)위클레이에서 CTO로 재직하면서 실시간 화상/음성 통화 서비스인 "시드"에 대해 설계/개발을 수행하였습니다.
여러 유저가 네트워크를 통해 동시에 참여하는 게임에서 게임 클라이언트 간에 실시간 데이터(음성 채팅 데이터, 캐릭터 위치 정보 같은 실시간 게임 데이터)를 주고 받아야 하는 경우, 클라이언트 간에 직접 통신에 의해 데이터를 주고 받게 되면, 서버를 경유하여 데이터를 전달하는 것 보다 서버의 비용도 절감될 뿐만 아니라, 보다 빠른 클라이언트간 통신이 가능하다. 하지만 많은 곳에서 사용되는 공유기나 WiFi AP는 클라이언트의 정확한 네트워크 위치를 감추어 통신 체결을 어렵게 만든다. 본 발표에서는 공유기나 WiFi AP를 통과하여 클라이언트간에 네트워크 연결하는 기법에 대해 소개한다.
[새 창에서 슬라이드 보기]
안녕하세요. 넥슨 코리아 플레이본부 기반기술팀의 송인권입니다. 오늘 발표드릴 내용은 ‘공유기를 뚫어라!’ 라는 토픽으로 클라이언트 사이에, 피어 투 피어라고도 표현하는데, 서버를 경유하지 않고 직접 연결을 체결할 때 굉장히 어려운 부분 중에 하나인 공유기를 어떻게 뚫고 그 사이를 연결을 할 건가, 연결 체결을 할 것인가? 에 대한 네트워크 기법에 대해서 말씀을 드리고자 합니다. 그 전에 제 간단한 소개를 먼저 드리겠습니다. 저는 이니텍이라는 보안 회사에서 병역 특례로 실무를 시작했고요. 그래서 처음에는 네트워크와는 전혀 동떨어진 암호화 알고리즘을 작성하고 그것들을 라이브러리로 묶는 그런 작업들을 진행을 하다가 2년이 돼서 계속 네트워크 수준의 보안 기술, VPN이라든지, 파이어월, 그리고 SSL 같은 것들을 개발했고요. 그리고 대학원에 진학을 했습니다. 그래서 대학원에서 한 7년정도 분산 시스템에서 노드들 간에 주고 받는 프로토콜들을 설계를 할 때 동시성을 고려를 미처 못해서 생기는 오류들을 자동적으로 검증하는 그런 기술들을 연구를 했고요. 그러다가 잘 다니던 대학원을 휴학계를 내고 위클레이라는 회사에 조인을 하게 돼서 지금까지 해오던 게 네트워크라고 그 네트워크에다가 영상과 음성처리라는 도전 과제를 두고 그 세 가지를 어울려서 Seed라는 서비스와 시스템을 설계/개발을 했습니다. 이 Seed는 간단하게 생각하시면 애플의 facetime 생각하시면 되겠습니다. 그리고 현재는 넥슨에서 기반기술팀에 있고요. 기반기술팀에서는 위클레이에서 하던 영상/음성 기술을 이용해서 그것을 기반으로 게임에서 음성이나 영상 기술들을 잘 활용해서 보다 재미있게, 보다 게임의 집중도를 올릴 수 있는 그런 기술 플랫폼을 만들고 있고요. 그리고 그 밖에도 게임 플랫폼에 사용될 수 있는 근간 기술들에 대해서 연구하고 개발하고 있습니다. 오늘 주제가 되는 첫 번째는 직접 통신인데요. 클라이언트간에. 왜 클라이언트 간에 직접 통신이 필요한가? 옛날 얘기를 하나 보죠 .옛날에 몽룡이와 춘향이가 연애를 합니다. 그런데 조선시대 법도에 따라서 직접 대화를 못하죠. 방자가 필요합니다. 그래서 이몽룡이 방자한테 사랑한다고 전달을 해달라고 합니다. 그러면 방자는 사랑한다 라고 얘기를 하죠. 그러면 춘향은 다시 알았다고 전하라는 말 조차도 방자를 통해서 ECU를 날립니다. 그런데 만약에 몽룡이랑 춘향이가 둘이 현대처럼 직접 얘기를 한다면 뭐가 좋을까요? 일단 빠르겠죠? 전문용어로 latency가 좋아지죠. 그리고 방자 월급도 덜 들 겁니다. 방자가 필요가 없으니까요. 그래서 이거를 네트워크 상황으로 비춰보면 이처럼 나타날 겁니다. 그래서 서버를 경유하게 되면 서버가 당연히 더 필요하게 되고, 서버를 경유함에 따라서 생기는 네트워크 latency도 자연스럽게 생기게 될 겁니다. 보시면 자연스럽게 나타나겠지만 클라이언트 사이에 서버를 통해서 직접 통신을 할 경우에 얻어지는 장점은 당연히 서버가 없으니까 서버 비용이 절감이 되고 평균적인 응답 속도가 향상이 될 겁니다. 그런데 직접 통신을 클라이언트간에 하려면 참 여러 가지 난관이 많습니다. 이게 직접 통신. 그러니까 클라이언트 간에 서로 통신을 하기 시작하면 중앙에서 관제가 안되기 때문에 그에 의해서 어플리케이션 디자인도 상당히 많이 바뀌어야 되고 여러 가지 난제가 많죠. 그런데 직접 통신 자체를 어렵게 하는 게 큰 게 하나 있습니다. 바로 공유기입니다. 공유기 많이들 쓰시죠? 특히 WiFi 완전히 보급화 되면서 집에 WiFi 공유기, 인터넷 공유기, I 모사의 공유기. 그리고 이런 소형 공유기. 심지어 기업에서 사용하는 이런 대용량 공유기 같은 것들이 많이 사용이 되는데요. 공유기를 정의해보자면 인터넷 주소를 여러 개의 장치가 공유할 수 있도록 하는 것. 인터넷 주소는 사실 인터넷에서 장치 하나를 식별하는 식별자죠. 그런데 이 인터넷 주소를 여러 개의 장치가 공유할 수 있도록 한다는 것입니다. 그런데 공유는 도대체 어떻게 할까요? 공유기다. 공유기라고 했을 때는 일단 공유기는 NATN, Network Address Translation 이라는 기능을 무조건 갖게 됩니다. 그러면 network address를 번역을 한다고 하는데 뭘 번역하는 거냐 translation 한다고 하는데 뭘 하는 거냐?. 외부 IP 주소랑 내부 IP 주소간에 변환을 하는 거고요. 그래서 공유기를 가만 보면 일반적으로 인터넷과 공유기가 연결되어 있고 그리고 공유기 밑에 내부 네트워크가 있습니다. 그래서 공유기는 외부 IP 어드레스를 하나 가지고 있고 공유기 밑에 내부 네트워크에 연결된 장치들에는 내부 IP 주소를 공유기가 배분을 해주죠. 그래서 내부에 있던 장치가 어떤 패킷을 네트워크를 통해서 인터넷 망에 전달을 할 때는 내부 IP로 발생된 패킷이 공유기를 통함에 따라서 외부 IP로 변환돼서 인터넷 망으로 전달이 됩니다. 그런데 NAT가 사실은 복잡하게 설명하면 굉장히 복잡하게 설명될 수도 있지만 그 핵심은 굉장히 간단한 것 같아서 간단한 그림으로 설명을 해보려고 합니다. 산에는 산토끼가 살고요. 바다에는 에리얼도 살고, 용왕도 살고, 니모도 지금 살고 있습니다. 그런데 용왕님이 갑자기 아프셔서 간을 가져오라고 거북이한테 시켰습니다. 거북이는 바로 뭍으로, 산으로 가죠. 그런데 가다가 보니까 바다가 너무 넓어서 돌아올 때 어디로 돌아와야 될지 잘 모르겠다 싶어서 표시를 해놓고 갑니다. 그리고 산토끼한테 가죠. 그림은 집토끼 같습니다. 산토끼한테 가서 ‘간 줘!’ 토끼는 그냥 죽습니다. 그리고 간을 가지고 열심히 달려가는데 거북이가 역시 예상했던 대로 머리가 좀 안 좋아서 어디로 가야 될지 잘 모릅니다. 가만히 생각해보니까 적어놨습니다. 그래서 가운데로 다시 돌아와서 용왕님한테 잘 간을 전달을 합니다. 여기서 핵심은 적어놓는다는 겁니다. 실제 NAT 상황에서 다시 한번 말씀을 드리면 클라이언트PC, 내부 네트워크 쪽에 있는 클라이언트PC에서 서버 쪽으로 패킷을 쏘면 그 패킷을 공유기가 받아서 변환을 합니다. 그래서 내부 IP로 되어있던 패킷의 주소를 자신의 IP인 외부 IP로 바꿔치기 하는데, 이때 적어놓습니다. 맵핑을 적어놓습니다. 그런 다음에 서버 쪽으로 쏘죠. 그러면 서버는 이걸 받아서 response 보낼 건데, response에는 공유기부터로 온 거라고 되어 있었으니까 공유기로 다시 던지겠죠? Response를. 그럼 공유기는 이 패킷을 받아서 가만히 보니까 적어놓은 맵핑이 있어요. 그래서 그 맵핑을 보고 클라이언트PC한테 성공적으로 보내게 됩니다. 그러면 만약에 클라이언트끼리 직접 통신을 하거나 NAT 외부에서, 공유기 외부에서 패킷을 보낼 때 어떻게 해야 되는가? 어떤 상황이 일어나는가? 보면 클라이언트 A가 클라이언트B로 지금 패킷을 보냅니다. 우여곡절 끝에 공유기까지 왔어요. 그런데 공유기는 적어놓은 게 없죠. 맵핑이 없습니다. 그래서 변환을 할 수 없기 때문에 내부로 전달을 할 수가 없습니다. 그래서 일반적으로 NAT 내부로 외부에서 패킷을 전달을 할 수가 없습니다. 그래서 많은 시도들이 있었습니다. Hole punching 기술. 그리고 여기서 말씀 드린 Hole punching 기술이 대표적이고요. 그 다음에 UPMP라는 표준을 통해서 NAT 장비, 그러니까 공유기에서 포트 포워딩 하는 거를 일반 어플리케이션이나 내부의 장치들을 이용해서 포트포워딩을 할 수 있도록 도와주는 프로토콜 같은 것들도 제한이 됐고. 애플 같은 경우는 UPMP를 안 쓰고 NAT PMP라는 프로토콜을 사용하는 독특한 모습을 보여줍니다. 그래서 여기서는 일단 기본적으로 거의 대부분의 NAT에서 사용이 될 수 있는 Hole punching 기술을 설명을 드리겠습니다. Hole punching 기술은 사실 UDP용 Hole punching 기술이 있고 TCP용 Hole punching 기술이 있는데 TCP용은 사실 UDP Hole punching의 진화 버전 정도밖에 안되기 때문에 원리는 UDP Hole punching으로 충분히 이해하실 수 있을 거라 생각합니다. UDP Hole punching 설명 드리기 전에 예시 네트워크를 하나 잡았습니다. 지금 보시듯이 클라이언트A와 클라이언트B가 있고요. 클라이언트A는 공유기A 밑에 있고. 공유기B 밑에 클라이언트B가 있습니다. 그리고 랑데부 서버라는 게 하나 필요합니다. 랑데부 서버는 이따가도 보시겠지만 상호의 정보. IP정보와 포트 정보를 알기 위해서 필요합니다. 처음에는 지피지기라고 상대방을 알아야 됩니다. 처음에 클라이언트A와 클라이언트B가 연결을 체결하려고 하려고 하면 클라이언트A와 클라이언트B가 각자의 외부IP 포트를 등록을 합니다. 그런 다음에 클라이언트A가, 또는 클라이언트B가 될 수도 있는데 여기서는 클라이언트A가 클라이언트B가 통신을 개시하는 걸 요청한다. 라고 생각을 하면 클라이언트A가 랑데부 서버한테 ‘나 이제 B랑 통신할래.’ 라고 얘기를 합니다. 그러면 랑데부 서버는 양쪽에 상대방의 외부 IP포트를 전달하게 됩니다. 그러면 이제 상대방의 IP포트가 서로 공유가 됐죠. 그 상태에서 UDP 패킷. 여기서 이제 Hole punching 패킷이라고 하는데, 사실 아무 패킷이나 쏴도 됩니다. UDP 패킷을 상대방의 외부IP 포트로 막 쏩니다. 막 쏘면 맵핑이 없기 때문에 이쪽에 쏜 패킷도 막힐 거고요. 이쪽에서 쏘는 패킷도 막힐 겁니다. 그런데 시간이 계속 흐르다 보면 클라이언트B에서 공유기A 쪽으로, 외부 IP 쪽으로 쐈기 때문에 맵핑이 생기죠. 그리고 이쪽도 마찬가지고 맵핑이 생깁니다. 이 맵핑이 생겼기 때문에 언젠가는 뻥하고 뚫립니다. 그래서 Hole punching이라고 하고요. 그래서 이 이후부터는 서로간의 외부 IP 포트로 다른 데이터를 보내가 시작하면 되고요. 이제부터 연결이 체결이 되는 겁니다. 그런데 불행히도 Hole punching이 만능이 아닙니다. 이 자료는 2005년도에 USENIX에서 발표됐던 자료인데, 약간 제한적으로 테스트를 했기 때문에 좀 신뢰성은 100%라고 할 수는 없지만, 그리고 2005년도이기 때문에 지금으로부터 9년 전이죠. 9년전 얘기 때랑은 또 달라졌겠지만 어쨌든 UDP Hole punching을 지원하는 NAT라고 하더라도, 공유기라고 하더라도 100%가 안됩니다. 그리고 와중에 기업용. 또는 3G, LTE 같은 경우에는 효율성과 보안성 때문에 Hole punching을 허용 안 합니다. 알고리즘이 좀 다릅니다. NAT하는 알고리즘이. 그리고 이중으로, 어떤 거는 이렇게 hierachical하게 2중, 3중으로 NAT가 설치된 네트워크 환경이 있습니다. 그런 경우에 상황에 따라서는, 그것도 확률적이죠. 어떻게 보면, 네트워크 구조에 따라서 Hole punching이 불가능 합니다. 그리고 또 한가지 안 되는 경우가 있는데, 하나의 공유가 밑에 클라이언트A, B가 둘 다 달려있다고 생각을 해보죠. 그러면 Hole punching을 하려면 아까 말씀 드린 대로 외부 IP포트로 패킷을 쏩니다. 그러면 외부 IP포트로 쏘니까 패킷이 나가다가 말고 다시 공유기로 들어오겠죠. 그런데 이게 여기까지 전달이 잘 될까요? 비싼 공유기는 됩니다. 그런데 일반적이 공유기는 안 됩니다. 그리고 이렇게 되는 것에 이렇게 싹 꺾였다고 해서 헤어핀이라고 표현을 하는데요. 비싼 공유기만 됩니다. 그래서 저희가 보통 가정에서 쓰는 일반적으로 보급되어 있는 공유기 같은 경우는 이 헤어핀이 안되고 결국 Hole punching이 안 된다는 뜻입니다. 그래서 이런 경우에는 A에서 클라이언트B로 패킷을 쏘려면 B가 내부망에 연결 되어있는지 확인을 해서 내부 망간에 연결로 바로 직접 쏴줘야 되는 상황이 되는 거죠. 그래서 이런 모든 케이스에 불과하고 UDP Hole punching을 해서 직접 연결하는 건 굉장히 매력적이니까 이걸 어떻게든 써보자. 안 되는 케이스들에 대해서는 잘 핸들링을 해서 써보자. 라고 제시된 방법이 있습니다. 다시 한번 직접 연결을 하기 위해서 사용할 수 있는 방법을 세 가지로 요약해보면, 방금 전 말씀 드렸듯이 같은 공유기 하에 클라이언트들이 있는 경우는 내부 망간에 연결로 바로 연결을 해야 합니다. 반면에 Hole punching으로 가능한 케이스가 있겠고요. 그런데 이 두 가지 다 실패하는 케이스. 그러니까 잘 안 되는 케이스에는 결국에는 방자가 다시 등장을 해야죠. 그래서 릴레이 서버를 두고, 릴레이를 통해서 둘 간에 연결을 할 수 밖에 없습니다. 그러면 이 세 가지 방법 중에 Hole punching이나 직접 연결하는 게 제일 좋잖아요? 서버를 통하는 것 보다. 그러면 그 셋 중에 어떤걸 어떻게 선택해서 어떻게 연결할 것이냐에 대해서 솔루션이 있는데요. 제일 무식한 방법입니다. 세 가지 다 시도를 해보고 성공하면 성공한 걸 사용합니다. 성공한 걸 사용하는데 만약에 2개 이상의 방법이 성공했다. 그러면 서비스 운영자가 제일 좋아하는 방법으로 선택을 하면 됩니다. 물론 서버 사용하는 방법은 가장 싫어하겠죠? 그래서 이런 방법이 표준화돼서 Internet Connectivity Establishment 라고 ICE라고 하는 표준이 있습니다. 있는데, 본 발표에서는 이 ICE를 이러한 방식을 말하는 데 사용하겠습니다. ICE 설명 드리기 전에 간단하게 예제 네트워크고요. 클라이언트A와 클라이언트B가 역시 마찬가지로 공유기 A, B 밑에 달려있다고 생각을 합니다. 여기가 내부 네트워크가 되겠죠? 그리고 클라이언트B나 A에 대해서 각각 릴레이 서버가 존재한다. 라고 가정하겠습니다. 그러면 아까 말씀 드린 대로 세 가지 방법을 모두 트라이 해봅니다.  지금 여기서는 A에서 B쪽으로 ICE를 시도하는 케이스만 놓고 보도록 하겠습니다. 그래서 내부 IP포트로 클라이언트A에서 B로 한번 패킷을 쏴보고요. 외부 IP포트로도 시도를 해봅니다. 그러면 공유기를 통해서 이쪽으로 갈 수도 있겠죠? Hole punching을 통해서. 그리고 릴레이 서버로도 패킷을 쏩니다. 만약에 같은 공유기 하에 있다. 그래서 공유기 A와 공유기 B가 같았다. 그러면 내부 IP로 쐈던 패킷은 클라이언트 B에 도착을 할 거고요. 외부 IP로 쐈던 거는, 만약에 헤어핀이 안 된다면 도착하지 못할 겁니다. 그리고 릴레이 서버는 서버가 뻗지만 않았다면 클라이언트 B한테 도착을 하겠죠. 만약에 다른 공유기다. 클라이언트A, B가 다른 공유기다. 밑에 있다. 그러면 내부 망 연결은 당연히 실패를 할 거고요. 다른 내부 망에 있으니까요. 그리고 공유기 A, B를 통해서 Hole punching이 성공해서 패킷이 클라이언트 B로 전달이 될 겁니다. 그런데 만약에 똑 같은 상황인데 Hole punching이 실패하면 내부 망도 실패할 거고요. Hole punching이 실패했으니까 외부 IP로 쏜 이 경로도 패킷이 안 갈 겁니다. 릴레이 서버를 통해서 가는 건 언제나 가겠죠. 그러면 만약에 Hole punching이 성공했다. 그러면 외부 IP를 통해서 패킷이 하나 전달이 될 거고 릴레이 서버를 통해서 패킷이 하나 전달이 될 겁니다. 클라이언트B에. 그러면 클라이언트B는 각각의 경로를 통해서 reply를 던집니다. 그러면 클라이언트A는 클라이언트B한테 패킷을 쏘려면 어떤 경로로 쏘면 성공적으로 도착한다. 를 알 수 있습니다. 여기 같은 경우 두 개가 되겠죠. 그러면 서버를 통해서 가는 경로는 별로 바람직하지 못하니까 공유기를 통해서, UDP Hole punching을 통해서 뚫린 길을 통해서 패킷을 계속 쏘게 됩니다. 그래서 상호 연결이 되고요. 지금 클라이언트A에서 클라이언트B로 ICE를 시도하는 케이스만 설명을 드렸는데 동시에 클라이언트 A와 B가 반대 방향으로 반대 방향으로 ICE를 시도하고요. 그래서 패킷 6개가 동시에 돌아가게 되고, 이런 시도를 일반적으로 100~200ms마다 계속 던집니다. 그래서 여유가 되는 대로, 시간이 길면 길수록 성공률이 올라가고요. 그래서 계속 던져서 안정적으로 패킷들이 들어오는 경로를 선택하는 취할 수도 있습니다. 여기까지 ICE 라는 기법, Hole punching을 현실화 시키기 위한 ICE라는 기법에 대해서 설명을 드렸고요. ICE라는 기법을 쓰게 되면 보안 적인 고려사항이 꼭 하나 들어가게 되는데요. 그거에 대해서 말씀을 드리겠습니다. 릴레이 서버를 쓰기 때문에 생기는 건데요. 릴레이 서버는 DDOS의 유요한 도구죠. 그래서 릴레이 서버가 오남용 되는 걸 막아야 됩니다. 그래서 일반적으로 쓸 수 있는 방법은 각 패킹마다 MAC을 쓴다든지 HMAC을 쓴다든지 그런 방법을 통해서 인증 체계를 도입하는 거죠. 그런데 각 패킹마다 그런 인증 체계를 도입하면 성능이 굉장히 문제가 될 수 있기 때문에. 두 번째 방법은 각 클라이언트 별로, 클라이언트 간에 접속을 하려고 하는, 매우 릴레이 서버 인스턴스를 다 띄워줍니다. 그리고 그 릴레이 서버 인스턴스는 그 담당인 클라이언트로만 패킷을 쏘는 거죠. 그래서 그 부분을 해결을 할 수 있는데, 역시 이것도 마찬가지인 게 시스템에 접속하는 클라이언트가 100만개다. 그러면 서버 인스턴스가 100만개가 뜨는 셈이 되고 포트가 100만개 점유되는 꼴이라서 여기에 대해서는 시스템 설계를 적절히 잘 해주는 시스템 설계가 필요로 합니다. 발표를 조금 빨리 했는데요. 요약을 드리자면 직접 통신은 서버의 비용을 줄이기 위해서도 매우 필요로 하지만 실제 커넥션 자체의 퀄리티. Latency를 줄이기 위해서도 필요하다. 그리고 공유기는 사실 Network Address Translation 기능이 핵심이고 NAT라고도 부른다. Hole punching 기법을 소개를 드렸습니다. 그래서 Hole punching 기법에 의해서 NAT 하에 있는 클라이언트 들과의 통신이 가능하게 하는 방법을 말씀을 드렸고. 이 Hole punching 기법 만으로는 실제 서비스 구성할 수 없기 때문에 Hole punching외에도 다른 네트워크 경로를 찾아내는 ICE라는 기법에 대해서 말씀을 드렸습니다. 그리고 ICE 기법을 사용할 때 필히 고려하셔야 되는 보안 고려사항에 대해서도 간단히 말씀을 드렸습니다. 감사합니다. 
“TCP Hole punching이 UDP Hole punching보다 성공률이 낮은 이유를 자세히 설명해주실 수 있나요?”
라는 질문을 주셨는데요. TCD Hole punching같은 경우는 사실 TCP 라는 connection이 시작할 때 three way handshaking 을 하지 않습니까? 그래서 맨 처음에 심 패킷이 가고, 그 심 패킷에 대해서 ECU오고. 이런 과정을 겪게 되는데 심 패킷에 만약에 어플리케이션에서 마음대로 날릴 수 있다면 성공률이 UDP랑 똑같을 겁니다. 그런데 아쉽게도 우리가 어플리케이션을 짤 때 많은 OS에서 사용할 수 있는 거는 소켓이죠. 그래서 BSD 소켓에 인터페이스는 심 패킷만 날리는 거를 허용하지 않죠. 그리고 포트도 다양하게 사용을 할 수가 없죠. 그렇기 때문에 BSD 소켓을 약간 트윅해서 약간 해킹 느낌까지 들 정도의 방법으로 TCP Hole punching을 하게 됩니다. 그래서 TCP 포트 하나에다가 TCP 소켓 여러 개를 바인딩해서 하나는 listen하고 하나는, connect하고. 이런 이상한 방법을 사용하는데요. 그러다 보니까 자연스럽게 맵핑이 생기고, 맵핑이 사라지고 하는 그런 타이밍을 정확하게 잡아내기가 힘듭니다. 그래서 많은 시간이 걸리고요. 그런데 그렇다고 네트워크 연결 한번 하자고 몇 십 초 동안 기다릴 수도 없는 노릇이라서 보통 몇 초 내에 연결이 되야 되지 않습니까? 그러면 그 시간 내에 성공할 수가 없고. 그래서 실패율이 꾀 높습니다. TCP 같은 경우는.
그리고 “3G, LTE 같은 경우 릴레이 서버를 쓸 수 밖에 없나요?” 
라는 질문 주셨는데요. 네. 3G와 LTE 같은 경우 외국은 모르겠습니다만 적어도 우리나라에서는 3G, LTE에서 사용하는 NAT 장비가, 공유기 장비가 전부 쓸 수 없도록 막혀있는 경우가 많고요. 특정 중계기나 지방 쪽으로 내려가시면 그렇지 않은 저가형 공유기를 사용하는 중계기에 만약에 붙으신다면 릴레이 서버 없이 동작하는 기적을 바라보실 수도 있습니다. 사실 되게 확률적이거든요. 이게.
그리고 공유기가 수시로 바뀌는 경우가 많은 경우는요, 다시 해야 됩니다. 만약에 공유기가 바뀌면 ICE와 Hole punching 과정을 다시 해야 됩니다. 그래서 여기에 많은 테크닉들이나 트윅하는 방법들이 있게 되고요. 그래서 딱 바뀌면 기존에 미리 할당해놨던 릴레이 서버를 재활용 한다든지. 이런 기법들을 사용합니다. 자세하게 설명 드리기엔 지금 어려울 것 같고요.
“웹 RTC와는 무슨 차이가 있나요?” 
라는 말씀을 주셨는데요. 웹 RTC에서 당연히 ICE 합니다. ICE를 해서 그 다음에 영상과 음성을, 채널을 튼 다음에 통신을 하게 됩니다.
같은 질문인 것 같은데요. 모바일 상황에서 WiFi 상황과 LTE, 3G와 같은 다양한 상황이 생기는데 이 때는 ICE의 반복이 계속 생길텐데요. 이 때 좋은 방법이 없을까요?’ 좋은 방법이 딱히 있지는 않고요. 최대한 빨리 ICE를 재 시도할 수 있도록 네트워크 환경이 바뀌는 거를 detecting 하는 게 더 중요합니다. 왜냐면 특히 모바일 환경 같은 경우는 네트워크 환경이 바뀌었다는 사실을 알아내는데 심할 때는, 특히 Wifi에 물렸다가 갑자기 3G로 넘어갈 때는, 5초에서 10초 이상 걸리는 경우가 있거든요. 그 쪽이 오히려 딜레이의 원인이지 ICE가 원인은 아닙니다. 일반적으로.
IPV6는 상관 없습니다. “IPV6에서 Hole punching이 필요한가요?” 
라는 질문 주셨는데요. 마찬가지입니다. 그런데 IPV6인 경우는 사실 요즘 일반 유저들에게 이 IPV6를 쓰는 경우가 없어서 현재는 고려를 안 하고 있습니다. 저희는.
그리고 “LTE 같은 경우 같은 기지국에 붙어있으면 내부 IP로 연결이 가능하겠죠?” 
라는 질문 주셨는데요. 같은 기지국에 있는 경우도 내부 IP가 안 주어지는 경우가 많습니다. 거의 안 주어진다고 보시면 됩니다.
“한번 Hole punching이 성공한 컴퓨터와는 계속 Hole punching이 되는지요? 그리고 한참 통신 중에 통신이 끊길 일이 있나요?”
라고 말씀 주셨는데요. Hole punching된 맵핑은 공유기 설정에 따라서 라이프 타임이 결정이 되는데, 라이프 타임이 보통 5초정도는 갑니다. 그래서 계속 통신을 안 하고 idle상태로 세션을 놔둘 때는, 그러니까 heartbeat를 3초정도? 잡아서 이렇게 서로 날려주시면 Hole punching 계속 유지가 되고요. Hole punching 성공 시간은 일반적으로 1초 이내에 됩니다. 한국 네트워크에서는. 1초 이내에 되는데 안 될 때는 되게 안 되요. 그래서 안정적으로 봤을 때는 100~200ms 간격으로 2초정도 충분히 쏴주시는 게 안정적입니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
