참새가 방앗간 지나치지 못하는 기사들이 나왔군요.
통신사에서 보이스톡(카카오톡에서 서비스하는 음성 통화 서비스)의 음질을 저하시킨다는 내용입니다. 관련 기사를 검색해 보았습니다.
카카오톡 vs 이통사, 무엇을 위한 대립인가
http://media.daum.net/digital/others/view.html?cateid=100031&newsid=20120614153706873
뿔난 카카오톡 "통신사, 보이스톡에 품질 제한"
http://media.daum.net/culture/others/view.html?cateid=1026&newsid=20120614210009121
저 또한 카카오톡 애용자입니다. 카카오톡에서 음성 통화 서비스를 한다는 얘기를 들은 것이 얼마 되지 않는 것으로 알고 있습니다.
기사를 종합해 보면 통신사에서 보이스톡을 전면 차단하지는 않고, 음질을 떨어 뜨리고 있다라는 얘기가 있는데, 이는 엔지니어의 입장에서 봤을 때 석연치 않는 점들이 많이 있습니다.
얘기에 앞서 먼저 양심 선언(?)을 하겠습니다. 저는 이전에 다니던 회사에서 특정 어플의 통신을 차단하는 일을 담당했었습니다. 제가 담당했던 일 중의 하나가, 현재 P2P의 대명사인 Torrent Traffic을 판단하고 제어(차단)하는 업무였습니다(Torrent는 관련된 아류작 Protocol들이 많이 있음). Torrent 를 사용하고 있는 도중에 상대방(peer)과 접속이 되자 마자 끊기는 현상을 자주 목격할 수 있을 겁니다. 그게 바로 전 회사에서 만든 로직에 의해서 장비(ISP에 납품된) 레벨 에서 해당 Traffic을 차단시켜 버리게 되는 겁니다. 당시에 Torrent 차단하는 로직을 코드로 구현하는 것보다는, 오히려 사전 패킷 분석, 분석 결과 보고서 작성, 내부 테스트, QA, ISP 업체 실 사이트 테스트 등에 더 많은 시간들이 들었었죠.
특정 어플을 차단(혹은 이번과 같이 음질을 떨어 뜨리기 )을 구현하여 실 사이트(ISP)에 적용되려고 한다면 다음과 같은 과정을 거치게 됩니다.
1. 네트워크상으로 특정 어플의 차단에 대한 제어 기능을 제공해 줄 것을 ISP가 네트워크 장비 업체에게 요구를 함(보통 ISP 업체는 자체적인 개발 능력을 보유하고 있지는 아니 하며, 네트워크 트래픽 전문 업체에게 이러한 기능을 요구하게 됨).
2. 네트워크 업체는 해당 어플에 대한 면밀한 분석 작업에 들어 가서 해당 어플에 대한 룰(rule)을 만들어 냄. 여기에서 false positive(오탐)나 true negative(미탐)을 가급적 줄여야 하는데, (어플에 따라 다르지만) 이부분에 대해서는 상당한 기술을 요구하게 됨.
3. 업체에서 룰을 만들어 냈다 하더라고 바로 ISP 업체에서 적용할 수 있는 것은 아님. 자체적인 QA 과정을 거쳐야 하고, 또한 만들어 진 로직(룰)이 실제 ISP에 적용되기 위해서는 또 다른 복잡한 과정들을 거치게 됨. ISP에서도 네트워크 업체에서 보내 준 모듈을 보통 한달 이상 테스트를 하는 것이 일반적임. 장비 업체에 다녀 본 사람들을 알겠지만, 장비 업그레이드(SW or HW)도 보통 밤에서부터 시작을 해서 새벽에 끝이 나는 고된 작업임.
4. Web Filtering(domain name 기반 탐지)과 같은 일반적인 것은 이전에도 계속 사용해 왔고 구현에서부터 적용이 쉽게 이루어 질 수 있으나, 이번과 같이 특정 어플에 대한 분석과 실제 사이트 적용은 많은 시간이 필요로 함.
카카오톡에서 무료 음성 통화 서비스를 한다는 얘기가 흘러 나온 것을 불과 한달이 되지 않는 것으로 알고 있는데, ISP에서 보이스톡 음질 저하 기능을 만들어 내고 가동까지 시키고는 것을 한달 안에 완료했을 것이라는 것은 제가 가지고 있는 상식으로는 이해가 되지 않습니다. 더군다나 세션을 확 끊어 버리는 게 아닌, 하나의 세션(TCP or UDP)에서 패킷을 random하게 drop시키는 기능이 탑재된 장비가 실제 ISP에서 사용하고 있다는 얘기는 아직 들어 본 적이 없는 것 같군요(기능 구현이 어렵다는 것이 아니라 이러한 요구가 현업에서는 한번도 요구된 적이 없었음).
저는 예전에 Dialpad라는 VoIP 서비스를 하는 업체에서 일을 했었고, 그러기 때문에 All IP 시대가 언젠가는 올 것이며, ISP는 기존 음성 통신(유선/무선)에 대한 수익에 집착해서는 안된다는 것을 주장하는 입장입니다만, 이번 언론 보도처럼, ISP가 현재 고의적으로 보이스톡 음질을 저하시키고 있다고 단정지을 수는 없다고 봅니다. 최소한 ISP 업체에 들어가 있는 장비의 MRTG 정도는 보고 얘기를 해야 할 것입니다.
![[Level:16]](http://www.gilgil.net/modules/point/icons/default/16.gif "Point:23265point (7%), Level:16/30"){kind=icon}
gilgil
안녕하세요. gilgil님. (길길이라고 읽는 건가요?) 링크를 타고 들어왔는데 좋은 정보가 많아 열심히 익히고 있습니다. 하나 궁금한게 있는데요. 모바일에서 동작하는 보이스톡은 아마도 앱에 설정된 서버로 접속해야하니까.(3g망은 서버역할을 할 수 없으니...) 라우터에서 해당 IP만 체크해도 위에서 말한 동작이 가능할것이라고 생각하는데요. 아마 이 말이 15일날 다신 뎃글의 의미인것 같습니다. 토렌트나 p2p같은 경우 그 말 자체 처럼 p2p이거나 서버가 무한하기 때문에 IP가 얼마든지 바뀔수 있지만 보이스톡(3g)같은 경우는 무조건 서비스업체의 서버를 거쳐야 하기때문에 서버의 개수에 종속적을 수 밖에 없고 할당받은 IP는 연속적이든 비연속적이든 그러니까 대역이랑은 상관없이 체크가 가능하다고 생각이 되는데 본문에서 말씀하신 경우를 보면 보이스톡은 어떤 방식을 통해 이런 한계를 벗어 날 수 있는 궁금합니다.
ps. gilgil님 공간을 통해 많은 것을 배우는것 같습니다. 감사히 생각하고 있고, 계속 좋은 정보 부탁드립니다~
gilgilMultimedia 통신(화상& 음성) 방식에는 여러가지가 있습니다. 일반 문자 기반의 통신보다가 화상이나 음성은 데이터 전송량이 많이 때문에 가급적이면 서버 경유 방식보다가 P2P 방식을 선호하는 것이 일반적입니다. 그런데 양 화자간에 P2P 통신을 할 수 없는 경우라면 어쩔 수 없이 서버 경유 방식을 재택해야 하겠죠.
일반적으로 UDP 기반이라고 한다면 양 화자간에 STUN(Hole Punching) 방식을 통해서 P2P 를 구현할 수 있는 방법이 있기는 합니다만, 패킷 분석 결과 보이스톡은 서버 경유 방식을 사용하는 것으로 판단이 됩니다. 이 경우에는 서버 IP를 조사하여 네트워크 장비단에서 QoS를 제어할 수도 있다는 생각을 해 봅니다.
ISP에서 보이스톡 서버 IP를 조사해서 QoS를 걸었을까요? 저는 잘 모르겠습니다. 제가 임시적으로 분석을 한 것이 100% 확실하다는 것도 아니고, 제가 보이스톡 개발자도 아니고, 반대로 ISP 네트워크 운영자도 아니고... 그냥 추측만 할 뿐입니다. ^^
답변 감사합니다. STUN 또 하나 배웠네요. 아.. 그리고 사실 보이스톡 관련한 이슈에 대해서는 관심이 없습니다. 그냥 글을 쭉읽다가 궁금한게 있어서 뎃글을 남겨서 도움을 청했습니다. 하지만 생각을 해본다면 3G망에선 ISP업체가 곧 이통사인 점과, 특정 어플에서 패킷의 손실률이 비정상적으로 높다면 이해관계가 직접적으로 연결된 상황에서는 합리적 의심이 아닐까라고는 생각합니다. 물론 보이스톡에서 좀 더 다양한 케이스에 대해 테스트 없이 단순히 손실률과 이해관계에 대한 접근으로 성급한 결론을 내린것 같은 생각도 들지만요. 여튼 이건 개인적인 생각입니다. 당사자들끼리만 아는 일이고, 당사자도 서로 모르는 일에 대한 그냥 개인적인 견해였어요. 제가 궁금했던건 말씀드렸지만 3g망에서 p2p통신이 가능하지 않아 서버를 경유해야만 한다고 생각을 했는데, 다른 방법이 있는지 였고, gilgil님은 고수답게 STUN이라는 방법으로 p2p가 가능하다고 알려주셔서 정말 감사 할 따름입니다. 배운다음에 한번 직접 시도해봐야겠어요. 지금까지 그렇게 알고 그렇게 생각했거든요. 감사합니다~
gilgil음... 제가 첫번째 다녔던 회사가 Dialpad를 개발하고 서비스하던 새롬 기술 연구소라는 곳이었습니다. 저도 학생때부터 VoIP에 관심이 많았었고, 회사도 관련 회사를 다녔었고, 지금가지 관련된 프로그램도 개발하여 왔었고 VoIP 기술과 국내 상황에 대해서는 어느 정도는 알고 있습니다. VoIP와 관련되어 제 경험만 해도 족히 10년은 넘으니 국내 VoIP 기술은 그보다는 더 길겠죠? ^^
저는 예전에 Dialpad 회사를 다니면서 코덱의 성능을 판단하기 위해서(패킷 drop이 났을 경우 코덱이 이를 어떻게 처릴를 할까를 보기 위해 네트워크단에서 고의적으로(10~20%) 패킷을 drop시키는 프로그램을 개발하여 연구소 개발팀 내부에서 테스트에 사용하기도 했습니다. 어찌 보면 이번 사태의 기술적인 요지는 제가 10년 전에 만든 프로그램만으로도 충분히 구현이 가능할 정도로 어렵지 않은 기술입니다.
이번에 보이스톡 패킷을 캡쳐해 보니, 서버 경유 방식을 사용하는 것으로 판단됩니다. 특히 서버 경유 방식이라면 특정 IP 대역 설정을 ACL로만 설정을 해 줘도 탐지는 쉽게 됩니다. L3, L4 레벨에서 탐지가 가능하니 L7까지 갈 필요도 없죠. 그리고 보이스톡은 전형적인 RTP format을 준수하고 있습니다. 이 것은 UDP header의 앞의 2바이트만 보면 됩니다. 탐지의 false positive를 막기 위해 좀더 판단 조건을 넣게 되면 오탐도 줄일 수 있습니다. 결론적으로 보이스톡은 탐지는 쉽다는 결론을 내릴 수 있습니다.
문제는 고의적으로 보이스톡의 packet drop을 ISP에서 자행하고 있느냐 하는 겁니다. 네트워크 라우터 장비들이 TCP starvation을 막기 위해서 TCP packet을 우선적으로 염두에 두는 기능 정도는 널리 보편화되어 있지만, 특정 UDP session에 대해 packet을 고의적으로 drop시켜라는 명령어 체계를 가지는 장비는 저는 아직까지 보지 못했습니다.
결론적으로 제가 말씀드리고 싶은 것은 이번 보이스톡과 관련된 detection이나 packet drop이 기술적으로 어려운 것은 아니나, 실제로 ISP망에서 그 기능(보이스톡의 패킷을 고의적으로 drop시키기)을 구현하기 위해서는 기술적인 사안보다가는 ISP 트래픽망에 네트워크 패킷 처리 기술이 들어 간 장비를 돌리기 위한 현업상의 특징(검증되지 않은 회사 제품은 일단 지양, 조낸 빡신 테스트를 거쳐야만 겨우 겨우 실제망에 적용 가능, 적용을 했다 하더라도 탐지만 보통 몇개월 하고 남 다음에 가야 제어 기능 들어 감)을 이해하고 있다면 이번 기사에 대해서 의구심을 가질 수 밖에 없다는 겁니다.
gilgilSession에 대한 packet을 막는 방법은 많습니다. in path 장비라고 하면 routing을 null interface로 해도 되고, iptable을 이용해도 되고, out-of-path 방식에서는 session을 끊는 packet(TCP의 경우에는 RST 필드를 set시켜서) 방법은 무궁무진합니다. L7에서는 netflow를 이용해서 특정 어플로 판단되는 경우 kernel level이 아닌 user level에서도 충분히 drop시킬 수 있습니다. 요즘에는 L7레벨에서 drop 정책이 결정되면 해당 session에 대해 L3/L4레벨에서 H/W적으로 처리를 해서 CPU부하도 거의 들지 않습니다. 저도 네트워크 업체를 다니기 때문에 그러한 기능들은 익히 잘 알고 있습니다. 이러한 기능을 구현하는 장비는 널려 있습니다.
하지만 말씀하신 부분은 all or nothing이죠. 이번 사건과 같은 VoIP 음질 저하는 그것과는 다른 얘기입니다. VoIP 음질 저하는 session에 대한 packet drop을 확률적으로(random)으로, 혹은 n개 패킷에서 하나씩 drop을 시켜야 하는 기능이 장비에 구현되어 있어야 합니다. 제가 말씀드리는 것이 바로 이런 방식(확률적 or 주기적인 패턴을 이용하는)으로 packet 을 drop시키는 것을 말씀드리는 겁니다.
글로벌 벤더 제품에 이러한 기능(고의적인 음질 저하를 위한 특정 session에 대한 패턴 기반 drop)이 들어가 있다는 얘기는 들어 본적이 없습니다(물론 packet이 몰렸을 때 QoS management 정책에 의해서 drop되는 packet과도 또 다른 얘기). 당연히 ISP 측에서 요청을 해서 어느 업체인가는 customizing 개념으로 구현을 한다라는 것인데, 그렇게 된다면 결국 그러한 기능을 구현하게 되는 업체는 국내 업체가 된다라는 가정을 할 수가 있겠죠. 그런다면 과연 어느 업체에서?
gilgil7.7 DDoS를 겪으신 NE라고 한다면 떠오를 장비는 딱 하나뿐이지요
글쎄요, DDoS 를 막는게 장비만으로 가능할까요? 어느 업체에 계신지는 모르겠지만, 제가 보기에는 좀...
DDoS 는 물리적인 다구리 공격(다량의 트래픽)을 커버할 수 있는 CDN 서비스, 빠른 DNS 변경, 실시간으로 패킷을 경유시켜 주는 proxy, packet의 유해 여부를 판단해서 white, gray 혹은 black 레벨로 구분해 줄 수 있는 장비, 그리고 이들을 총체적으로 결합하여 운영하는 인터넷 대피소 등등... 많은 업체들의 장비 및 서비스들이 총체적으로 결합을 해야 막을 수 있는 겁니다. 제가 사람들 만나면서 "우리 회사에서 이번에 DDoS 막았어" 하는 얘기도, 최소 열번 이상은 들은 거 같군요.
Jay님은 그러한 장비를 운영을 하는 입장이었겠지만, 저는 그러한 장비를 만드는 업체에 있었습니다. 직접 코딩으로 이런 것들을 구현을 해야 실무진의 책임 레벨에 있었는데, 기술적으로 보나 그간의 History를 보나 이러한 것들을 모른다는 건 말이 안되겠죠? ^^
routing 시켜 줘야 할 packet의 양(bps, pps)이 적을 때는 상관이 없습니다만, packet이 많아 지면 그 때부터 packet loss가 발생하게 되죠. 그런데 packet loss가 어떠한 패턴으로 나게 될 런지는 아무도 예측할 수가 없습니다.
등등을 봤을 때, 실제로 packet loss가 어떠한 패턴으로 발생할 런지는 TCP/IP를 디자인한 사람의 할배가 와도 예측할 수 없다고 봅니다.