[이벤트] 아이펀팩토리 흔적을 찾아라!

안녕하세요!!! 아이펀팩토리 사업팀입니다.

오늘은 따끈따끈한 이벤트 소식을 들고 왔습니다. >_<

아래 미션을 성공하신 모든 분들에게 아이펀팩토리에서 준비한 기념품을 드립니다.

STEP 1   아이펀팩토리 페이스북 ‘좋아요’ 누르기

STEP 2   G-STAR 2016 아이펀팩토리 부스(BTB관 1층 #F25)에 와서 아이펀팩토리 흔적 찾기

STEP 3  페이스북에 #아이펀팩토리  해시태크와 함께 아이펀팩토리 흔적 올리기

아래 미션 성공 확인 후 아이펀팩토리 부스에서 준비한 기념품을 드립니다!!

 

지스타 페이스북 친구 이벤트 이미지4.png

네트워크 관련 용어들의 개념적 정리

영어권이 아닌 우리 한국 사람들은 영어로 표현된 단어의 미묘한 느낌을 캐치하기 보다는 그걸 전공 용어로 취급해서 그대로 외워버리는 경우가 많다. 하지만, 단어의 개념을 명확히 이해하면 그 개념이 다른 상황에서 사용되더라도 쉽게 이해할 수 있다는 장점이 있다. 아래 내용은 다들 알고 있는 단어들을 조금 다른 각도에서 설명을 시작하여 최근 많이 회자되는 Software Defined Networking (SDN) 과 관련된 기본 용어들까지에 대한 내용이다.

네트워크 : 일반화된 개념으로 네트워크는 점 들의 연결 관계를 선으로 표시한 것을 의미한다. 여기서 점과 선이 무엇을 의미하는지는 네트워크가 표현하려는 것에 따라 달라지는데, 점을 개인으로, 선을 개인간 관계로 생각하면 소셜 네트워크가 되는 것이고, 점을 옥천 허브 같은 물류 기지, 선을 도로라고 생각하면 물류 네트워크가 된다. 그리고 점을 컴퓨터로, 선을 회선으로 생각한다면 우리가 익숙한 컴퓨터 네트워크가 되는 식이다. 네트워크는 굳이 복잡한 모습일 필요는 없다. 단지 점 두 개가 이어진 것도 네트워크고 복잡하게 얽히고 설킨 것도 네트워크다.
8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%801

그림1 : 점들의 연결 관계가 네트워크이다. 그리고 단 2개의 점을 연결하더라도 마찬가지다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

스위치: 네트워크 상에서 한 점이 다른 둘 이상의 점에 연결되는 일은 흔하게 발생한다. 이 때 그 점은 들어온 입력을 여러 방향 (즉, ‘선’)으로 보낼 수 있고, 이처럼 경로를 결정한다는 의미에서 스위치라고 이야기한다. 마치 교차로에서 길을 선택하는 것과 같다고 생각하면 된다. 우리가 컴퓨터 네트워크에서 일반적으로 말하는 스위치는 OSI 모델상 제2계층인 “데이터링크 계층”에 해당하는 Ethernet 상의 데이터들의 경로를 결정한다고 해서 Layer 2 (또는 L2) 스위치라고 부른다. “스위치와 허브의 차이는..” 하는 식의 지식을 외우고 있는 사람들도 많을 것이다. 그것도 나쁘지 않지만, 경로의 결정을 하는 것이 스위치라고 이해하면 “ATM 스위치”, “패킷 스위칭” 이런 표현들이 무엇을 뜻하는 것인지 보다 쉽게 감이 올 것이다.

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%802
그림2 : 어떤 점들은 여러 점들과 연결될 수도 있다. 그렇게 되면 그 점은 여러 경로를 선택할 수 있게 된다. 이런 점을 스위치라고 한다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

브릿지 : 브릿지는 ‘다리’라고 번역된다. 하지만, 브릿지를 ‘다리’가 아닌 ‘이어주는 것’ 이라고 생각하는 것이 더 편리하다. 그렇게 이해하면 치과의 ‘치아 브릿지’ 라는 시술이 더 이상 암호 같은 의미가 아니라, 치아가 중간에 빠져서 떨어져 있던 두 치아사이에 보철물을 끼워넣는 것으로 이해될 수 있기 때문이다. 그리고 이렇게 이해하면, 앞서 설명한대로 여러 점을 ‘이어주는’ 스위치는 브릿지라고 쉽게 이해할 수 있다. 위의 그림에서 보면 왼쪽의 (서브)네트워크와 오른쪽의 (서브)네트워크 를 가운데 스위치가 이어주고 있다는 것을 알 수 있다. 그리고 “IP 네트워크를 브릿징한다” 라는 의미도 쉽게 이해될 것이다. 그렇다. 두 개의 IP 네트워크를 어떤 장비로 이어주는 것이다.

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%803
그림3: 위의 스위치는 양쪽의 네트워크를 이어주는 역할을 한다. 이어주는 역할을 하는 것을 브릿지라고 한다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

그럼 XenServer 와 같은 가상 서버에서 사용하는 네트워크 브릿지라는 표현은 어떤 의미일까? 이는 가상 서버안의 네트워크 카드와 물리 서버의 네트워크 카드를 이어주는 역할을 하는 매개체로 생각할 수 있다. VMware 의 경우 “가상 스위치” 라는 이름으로 같은 개념이 존재한다. 이와 관련해서는 아래에서 다시 설명하겠다.
8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%804

그림4 : 가상 솔루션들은 가상서버의 네트워크 카드와 물리 서버의 네트워크 카드를 연결하기 위해서 브릿지를 사용한다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

라우팅과 포워딩: 우리는 크게 신경을 쓰고 있지 않지만, router 나 switch 라고 말하는 장비들은 엄밀히 말해 크게 두 가지 일을 한다. 특정 목적지로 가기 위해서는 어떤 경로들이 있는지에 대한 정보들을 수집하는 것과, 그 정보들 중에 실제로 선택된 경로를 기반해서 패킷을 전달하는 일. 전자를 경로(route) 를 알아내는 일이라고 해서 라우팅(routing) 이라고 하고 후자를 실제로 패킷을 전달(forward) 하는 일이라고 해서 포워딩(forwarding) 이라고 한다. 우리가 보통 패킷을 전달하는 것을 라우팅이라고 부르는 경우가 많은데 이는 틀린 표현이다. 라우팅은 IP 패킷을 전달하는 것이라고 이해하고 있다면 이 역시 잘못된 것이다. 물론 많은 경우에 라우팅이 IP 패킷 전달을 의미하는 것으로 쓰이지만, 라우팅과 포워딩이라는 단어는 IP 와 같은 Layer 3 에 국한되는 것이 아닌 일반적인 개념으로 이해하는 것이 더 바람직하다.

Control plane과 data plane : Control plane 에 해당하는 라우팅은 경로 정보를 수집하는 것이라고 했다. 그리고 이들이 경로를 수집하는 방식은 자신이 알고 있는 정보를 이웃과 교환하는 것이다. 교환하는 정보가 선에 대한 정보 (Link state) 일 수도 있고, 자신이 알고 있는 경로 (Distance Vector) 에 대한 것일 수도 있다. 전자의 예로는 OSPF 같은 것이 있고 후자의 예로는 RIP 같은 것을 들 수 있다.

어쨌거나 자신이 알고 있는 정보는 그렇게 자주 바뀌지 않는다. 그때문에 정보의 교환 역시 빈번하게 발생하지 않는다. 이때문에 경로를 알아내는 라우팅 자체는 고성능일 필요는 없다. 그래서 대부분의 경우 control-plane 인 라우팅은 소프트웨어로 구현한다. 대신 라우팅에서는 각 지점들이 주고 받은 정보를 통해서 각 지점들이 최종적으로 똑같은 정보에 도달하는 것이 매우 중요하다. 그렇지 않으면 중간에 어떤 지점에서는 잘못된 경로를 알게 되기 때문이다. 즉, 라우팅은 각 지점들이 서로 주고 받은 경로 정보를 이용해서 독립적으로 연산을 수행해서 전체 경로들에 대해서 동일한 정보를 가지게 되어야 하는 것이다. 동일한 정보를 가지게 되는 것을 수렴한다고 말한다. 그리고 독립적인 연산을 하기 때문에 라우팅 알고리즘들은 분산 알고리즘이다. 라우팅 알고리즘들은 어떻게 하면 더 빨리 수렴할 수 있을까 하는 고민을 한다.

그러나 data plane 인 패킷 포워딩의 경우는 이야기가 달라진다. 얼마나 빨리 패킷을 전달할 수 있는지가 관건이다. 이를 소프트웨어로 구현을 하면, 매 패킷에 대해서 처리를 해줘야 되기 때문에 CPU 가 병목이 되게 된다. 그래서 이를 ASIC 형태의 하드웨어로 만들어버리게 되었다. 특히나 스위칭 패브릭이라고 하는 핵심 부분이 더욱 그렇다. 그리고 그 분야에서 가장 두각을 보인 것이 시스코다. (시스코는 샌프란시스코 도시 이름에서 시스코라는 이름을 따왔고, 회사 로고 역시 샌프란시스코의 금문교를 모델로 하고 있다.)

그러나 이런 하드웨어 접근 방식은 주어진 네트워크 환경에서 효율적인 성능을 낸다는 장점은 있었지만, 동시에 새로운 것들을 시도해볼 수 없다는 심각한 문제가 발생했다. 일례로, IPv4 에서 IPv6 로 넘어가기 위해서는 장비가 IPv4 스위칭 뿐만 아니라 IPv6 스위칭까지도 지원해야 되는데 하드웨어로 이미 박혀있는 것을 바꿀 수 있는 방법이 없는 것이다. 그리고 비록 control-plane 인 라우팅 부분을 하드웨어로 구현을 할 필요가 없지만 그 소프트웨어가 같은 장비 안에 있는 flash 메모리 등에 박혀있는 한 그걸 마음대로 바꾸기도 어려웠다. 이 때문에 네트워크는 기존 프로토콜들 관련해서는 10Mbps, 100Mbps, 1Gbps, 10Gbps 등 높은 고도화를 이루었지만, 새로운 프로토콜 관련해서는 상당 기간 정체를 앓게 된다.

2000년대 중후반에는 Internet Architecture 연구가 한창 붐을 이루었다. “우리가 새로 인터넷을 설계한다면 어떤 내용들이 포함되어야 할까?” 라는 주제의 연구들이었는데, 이는 기존의 인터넷이 설계될 때와 오늘날 가장 중요하게 생각하는 요소들이 많이 바뀌었기 때문에 생긴 자연스러운 움직임이었다. 하지만 대부분의 노력은 탁상 공론으로 끝나고 말았다. 바로 현재의 하드웨어 중심의 네트워크 구성 때문이었다.

이런 하드웨어 중심의 네트워크는 새로운 것을 시도하지 않는 한 크게 문제가 되지 않았다. 그렇지만 예전에 만들어진 인터넷이라는 옷은 지금에는 맞지 않은 것들이 많아서 새로운 기능들이 종종 필요해졌다. 예를 들어 데이터 센터 안에는 많은 수의 스위치가 들어가는데, 네트워크 구성을 기존의 단순 tree 형태로 하게 되면 최상위 스위치가 병목이 되어 링크가 아무리 빨라도 그만큼을 못 쓰게 된다.

그리고 데이터 센터 안에는 수 많은 스위치가 들어가는데 그 중 하나가 죽으면 다른 스위치들이 경로 정보를 주고 받고 수렴할 때까지 기다려야 된다. 그리고 라우팅 정보가 수렴하지 않으면 포워딩 역시 제대로 이루어질 수 없게 된다. 데이터센터 안의 네트워크 구성은 너무나 뻔해서 굳이 분산 알고리즘을 돌릴 필요가 없는데도 말이다.

이런 여러 이유 때문에 하드웨어 중심의 네트워크를 벗어나기 위한 노력이 시도되었다. 이름하여 Software Defined Networking 이다.

Software Defined Networking (SDN) : SDN 의 기본 아이디어는 “패킷 포워딩에 특화된 프로그래밍 가능한 더미 하드웨어” + “라우팅과 더미 하드웨어의 포워딩 테이블을 제어하는 현명한 외부 소프트웨어 (컨트롤러)” 로 정리할 수 있다. 이는 기존의 완전 소프트웨어 기반 솔루션과 완전 하드웨어 기반 솔루션의 하이브리드 형태로 이해할 수 있다. 소프트웨어 기반 솔루션은 포워딩 성능이 나오기 힘들었다. 하드웨어 기반 솔루션은 프로그래밍이 안됐다. 그래서 그 둘을 섞어서 포워딩 규칙을 프로그래밍할 수 있는 포워딩에 특화된 하드웨어와 이 포워딩 규칙을 제어하는 소프트웨어라는 방식을 채택한 것이다.

그리고 SDN 는 기존에 장비들이 분산 알고리즘을 돌리던 것에서 벗어나 외부 소프트웨어가 모든 하드웨어를 중앙 집중식으로 관리하게 된다. 그 때문에 오랜 시간이 걸릴 수 있는 분산 알고리즘의 수렴 과정을 피할 수 있게 되었다. 외부 소프트웨어 (콘트롤러) 가 바로 어떻게 하면 되는지 알려주면 되기 때문이다. 그리고 외부 소프트웨어가 네트워크를 정의한다(제어한다) 는 뜻에서 Software-Defined 라는 이름을 쓰게 된 것이다.

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%805

그림5: SDN 는 포워딩에 특화된 하드웨어들을 외부의 소프트웨어 중앙 집중방식으로 통제하는 형태이다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

잠깐. 그런데 포워딩에 특화된 하드웨어이면서 프로그래밍 가능하다고 했는데 어떻게 이런 게 가능할까? 앞서 하드웨어로 포워딩을 구현하면 바꾸는 것이 안된다고 했는데 말이다. 사실 여기서 말하는 하드웨어는 기존 ASIC 기반의 하드웨어와는 다르다. SDN 에서의 하드웨어는 입력으로 들어오는 패킷의 패턴 매칭 하드웨어라고 이해하는 것이 더 좋을 것이다. “이 패턴의 패킷은 여기로, 저 패턴의 패킷은 저기로” 이런 방식이다. 그 때문에 하드웨어는 특정 프로토콜에 종속되지도 않고, 외부의 소프트웨어는 패킷 패턴에 따른 경로만 프로그래밍하면 되는 것이다. 신박하지 않은가?

OpenFlow : 이처럼 SDN 에서 가정하는 하드웨어는 기존의 ASIC 기반 하드웨어와는 확연하게 달랐고, 이렇게 패턴 매칭 형태로 프로그래밍 가능한 스위치에 대한 Spec 이 OpenFlow 라는 이름으로 이루어졌다. 그리고 HP, DELL, IBM 등 메이저 스위치 제조업체들이 이 규격에 따라 OpenFlow 스위치들을 만들기 시작했다. 보다 자세한 내용은 여기를 참고하기 바란다. http://www.openflow.org/

가상화 (Virtualization) : 나는 virtualization 을 가상화로 번역하는 것이 상당히 많은 오해를 불러 일으키고 있다고 생각한다. 가상화는 왠지 가짜의 느낌을 주기 때문이다. 실은 Virtualization 이 가짜라기 보다 “나만이 쓰는 것처럼” 라는 의미에 가까운데 말이다. Server virtualization 은 나만이 쓰는 것 같은 서버, Storage virtualization 은 나만이 쓰는 것 같은 스토리지 이런 식이다. 그러니 Network virtualization 은 나만이 쓰는 것 같은 네트워크라는 뜻이 된다.

가상화 기술이 “나만이 쓰는 것처럼” 하는 기술이기 때문에, 필연적으로 자원의 공정한 분배와 분리를 지원해줘야 된다. 예를 들어 서버 가상화 기술은 각 가상 서버들이 공정하게 자원을 분배 받고, 다른 가상 서버가 자원을 쓰는 것 때문에 또 다른 가상 서버가 영향 받지 않게끔 하는 것이 핵심이다. 그리고 스토리지 가상화는 각 가상 스토리지가 공정하게 디스크 IO 를 분배 받을 수 있게끔 하고 다른 가상 스토리지 때문에 내 가상 스토리지의 IO 성능이 영향 받지 않게 해줘야 된다. 네트워크 가상화도 마찬가지다. 내 가상 네트워크가 일정 수준의 밴드위스를 보장 받아야 되고 이는 다른 가상 네트워크때문에 영향을 받아서는 안 된다.

이런 가상화 기술은 물리 자원 위에 소프트웨어적으로 만들어 주는 것이다 보니, 자원의 할당량을 변경하거나 다른 곳으로 이동 시키는 것이 자유롭다는 장점이 있다. 예를 들어 가상 서버에 CPU 를 추가한다거나 다른 물리 기계로 이동하는 것이 가능한 것처럼 말이다. 그리고 가상 네트워크에 밴드위스를 추가한다거나 다른 물리 네트워크로까지 가상 네트워크를 확장하는 것 등이 가능한 것처럼 말이다.

가상 스위치 : 이처럼 네트워크 자원의 배정과 분리, 그리고 제어가 가능하게 하려면 네트워크 가상화를 위해서 뭔가가 더 필요한 것은 당연하다. 바로 가상 스위치라는 개념이다. 가상 스위치는 보통 가상화 프로그램 안에 내장된다.

가상 스위치가 없는 경우 어떤 일이 벌어질까? 아래 그림을 보기 바란다.

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%806

그림6: 만일 가상 스위치가 존재하지 않는다면 같은 물리 머신안 가상 머신들이라도 통신을 위해서는 외부 스위치까지 갔다가 돌아와야 된다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)


가상 서버는 물리 서버와 마찬가지로 각각의 IP 를 받을 것이다. 그런데 같은 기계 안에 있더라도 가상 서버들끼리 통신을 하기 위해서는 물리 기계를 벗어나 외부 스위치 까지 가야되는 일이 발생한다. 이는 엄청나게 비효율적이다. 그럼 가상 스위치가 있는 경우는 어떨까? 아래를 보면 알겠지만 훨씬 더 효율성이 높아진다.

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%807그림 7 : 가상 스위치가 존재하는 경우 같은 물리 장비 안의 가상 서버들간의 통신이 훨씬 효율적으로 된다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

그 외에도 같은 물리 머신의 네트워크 카드로 통신하더라도, 가상 스위치를 분리함으로써 가상 서버들이 다른 네트워크에 존재하게 하는 것도 가능하고, 다른 기계에서 도는 가상 서버들이 같은 네트워크에 있도록 하는 것도 가능하다.

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%808

그림 8 : 가상 스위치를 분리해서 가상 서버들이 다른 네트워크에 존재하게 만들 수 있다. 맨 왼쪽의 가상 서버는 다른 두 가상 서버와 다른 네트워크에 포함된다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

8%ed%9a%8c%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%809
그림 9 : 가상 스위치는 서로 다른 물리 서버에 있는 가상 서버들간에 같은 네트워크 안에 있게 만드는 것도 가능하다. 이때 물리서버간 통신은 가상 스위치간 터널링으로 이루어진다. (아이콘 출처: WPZOOM, iconfinder.com, Creative Commons License)

이처럼 가상 스위치는 네트워크 가상화를 구현하기 위한 필수적인 기술이라고 할 수 있다. 그 때문에 최근 가상화 솔루션들은 모두 가상 스위치 기능들을 포함하고 있다. 그 중에서 Open vSwitch 는 오픈 소스 기반의 가상 스위치 구현이며, XenServer 의 가상 브릿지 구현은 Open vSwitch 을 활용하고 있다. (OpenFlow 와 Open vSwitch 는 이름도 유사하지만, 실제로도 같은 사람들이 만들었다)

이번 컬럼에서는 네트워크 관련 용어들을 정리해보았다. 서두에 이야기한 것처럼 비영어권인 우리는 많은 용어를 그냥 전공 용어겠거니 하며 외우는 경우가 많은데, 용어의 의미를 좀 더 명확히 이해하면 해당 용어의 확장이나 응용 역시 쉽게 이해할 수 있는 경우가 많으니 다소 이단적인 이번 컬럼에서의 용어 설명이 도움이 됐길 바란다.

아이펀팩토리 문대경 대표

[인벤기고컬럼 6] TCP, 그리고 UDP 쉽게 알아보는 두 개념과 차이점

벌써 여섯 번째 연재다. 처음에 이렇게 길게 연재할 수 있을까 생각했는데, 인내를 가지고 기회를 주신 인벤 측과 재미도 없는 글을 가끔 들러주는 독자분들께 깊은 감사를 드린다. 이번 칼럼에서는 TCP/IP의 계층화와 게임 구현에 사용되는 TCP 와 UDP 의 차이점에 대한 이야기를 해보겠다.

■ IP. 모든 것의 허리
 
아마 많은 프로그래머들에게 익숙할 이름인 TCP/IP 라는 프로토콜 체계는 나중에 두 개로 분리된 것이 아니라, 인터넷 프로토콜 표준이 제정될 때부터 지금처럼 두 개로 분리되어 제안되었다. David Clark 교수님의 88년 논문은 TCP/IP 를 설계할 때 어떤 우선순위로 설계되었는지에 대해서 설명하고 있는데, 그중에서 “여러 종류의 데이터 전달 방식을 지원할 것 (multiple types of delivery services)” 이라는 목적을 달성하기 위해서 가장 기본이 되는 기능만을 IP 에 포함시키고, 그 위에 TCP 라는 새로운 계층을 얹는 형태가 된 것이다. (관련해서 설명이 더 필요한 분들은 블로그에 별도로 정리한 “인터넷은 어떤 기준으로 설계되었을까” 라는 글과 “모듈화, end-to-end 원칙, 그리고 fate-sharing” 이라는 글을 참고하길 바란다.) 그리고 이를 도식화 하면 TCP/IP의 관계는 다음 그림처럼 모래 시계 모양으로 표시한다.
.
i12467896678.jpg
▲ TCP/IP 모델은 IP 가 허리인 모래시계 형태로 표현된다.(출처 : ifew)

이 그림에서 주의 깊게 바라볼 부분은 잘록한 허리 부분인 IP 다. 이건 후세의 누군가가 꿈보다 좋은 해몽으로 붙여놓은 것도 아니고, 우연의 결과물도 아닌 TCP/IP 의 의도된 디자인인데, 어떤 통신 관련 하드웨어 기술이든 IP 만 구현하면 되고, 어떤 응용 프로그램이든 IP 위에서만 동작하게 하면 된다는 실로 엄청난 의미를 내포한다.

유선 랜 (Ethernet 이라 불림)과 WiFi 모두 IP 주소를 쓰고, 우리가 잘 인식하지는 못하지만, Bluetooth, LTE 나 3G 도 통신을 할 때는 IP 주소를 부여받아 통신한다. 그 덕에 까페의 WiFi 에서나 길을 걸으면서 LTE 상에서도 똑같은 앱을 이용해 스마트폰에서 음악을 들을 수 있다. 즉 어떤 통신 방법이든 IP 를 구현하는 한, IP 위에서 동작하던 응용 프로그램을 지원하는 데 문제가 없으며, 어떤 응용 프로그램이든 IP 로 통신한다는 것을 전제만 하면 IP 를 지원하는 어떤 하드웨어 기술에서도 동작할 수 있다.

인벤기고컬럼 본문 더보기>

[IGC 2016] 아이펀팩토리 문대경 CEO 강연 현장 공개!

안녕하세요, 아이펀팩토리 사업팀입니다^^

지난 10월 6일 진행된 제 2회 IGC(INVEN Game Conference)에 아이펀팩토리 문대경 CEO 강연 현장 공개합니다!!

많은 분들이 관심 갖고 강연장을 채워주셔서 뜨거운 열기를 느낄 수 있었습니다!

감사합니다!

발표자료는 아래 링크를 통해서 보실 수 있습니다.^^

강연제목 : PC와 모바일에서의 P2P 게임 구현에서의 차이점 비교

발표자 : 아이펀팩토리 문대경 CEO

발표자료 보러 가기 : http://www.slideshare.net/iFunFactory/pc-p2p

img_1871_%ec%9a%a9%eb%9f%89%ec%88%98%ec%a0%95
▲ 네오위즈 1층 강연장 가득찬 열기!!!

img_1872_%ec%9a%a9%eb%9f%89%ec%88%98%ec%a0%95
▲ 왕년에 CD/DVD 구워보신 분 손!!

img_1880_%ec%9a%a9%eb%9f%89%ec%88%98%ec%a0%95
▲ 발표중이신 아이펀팩토리 문대경 대표님!

img_1903_%ec%9a%a9%eb%9f%89%ec%88%98%ec%a0%95
▲ 강연 참석자분들의 엄청난 집중력이 느껴지네요

img_1907_%ec%9a%a9%eb%9f%89%ec%88%98%ec%a0%95
▲ 전체 사용자 풀에서 어떻게 통신 대상을 찾아낼까요?

img_1918_%ec%9a%a9%eb%9f%89%ec%88%98%ec%a0%95
▲ 각 망이 가지고 있는 특징 비교!

[IGC 2016] 아이펀팩토리 문대경 CEO 강연을 놓치지 마세요!

안녕하세요, 아이펀팩토리 사업팀입니다!

이번 제 2회 인벤 게임 컨퍼런스에 ‘아이펀팩토리 문대경 CEO’강연이 있습니다!

강연에 오시는 분들에게는 선착순 서프라이즈 기념품이 준비되어 있사오니 많은 참여 부탁 드립니다^^

IGC 대표님 강연 홍보 이미지2.jpg

 

게임 서버 – 클라이언트 안전하게 통신하기

상황 요약

게임 서버와 클라이언트 사이의 통신을 누가 엿보거나 수정할 수 있다면 어떤 일이 생길까? 특히 게임 서버와 클라이언트 중간에 끼어들 수 있다면 여려가지 시도를 해볼 수 있다. 예를 들어,

  • 클라이언트의 로그인 메시지를 가로채서 대신 로그인하거나
  • 클라이언트가 보낸 결제 토큰을 가로챈다거나
  • 해당 유저인척 다른 유저에게 메시지를 보낸다거나 (혹은 보내는 메시지를 엉뚱하게 위조하거나) 같은 일을 할 수도 있다.

어떻게 하면 중간 공격자가 있어도 열어볼 수 없는 메시지를 보낼까? (feat. 국정원)

예를 들어, 엄청난 인기를 끌고 있는 게임에서 딱 하나 존재하는 아이템을 가지고 있는 유저가 있다고 치자. 그리고 국정원 직원 한 명이 이 아이템이 너무 가지고 싶어서 중간에 도청+조작을 해서 뺏어가려는 상황이라고 치자. 국정원에선 통신사 장비를 감청할 수 있으니 중간에 끼어들어서 로그인 메시지를 가로채려는 상황이라고 해보면 어떻게 하면 이 아이템을 지킬 수 있을까?

일반적으로 다음과 같은 처리를 한다:

  1. 서버와 클라이언트 양쪽에서만 알고 있는 공유 비밀 을 만들고
  2. 공유 비밀 에서 암호화 키를 생성하고
  3. 이 암호화 키로 암호화 알고리즘을 적용한다.

중간에 국정원 직원이 듣고 있는 상황에서, 어떻게 하면 이 공유 비밀 을 만들까?

디피 헬만 키 교환

%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%801

여기서 디피-헬만 키 교환 알고리즘 을 쓴다.

  1. 양쪽에서 미리 공통 염료를 정한다. (여기선 노란색)
  2. 각자 비밀 염료를 한가지씩 고른다. (각각 다홍색과 청록색을 골랐다)
  3. 2에서 고른 염료를 공통 염료와 섞는다.
  4. 3에서 섞은 결과물을 서로 교환한다. (이건 누가 알아도 상관없다)
  5. 전달 받은 상대방의 혼합 염료에 자기가 고른 비밀 염료를 섞는다.
  6. 이제 결과물로 나온 색이 공유 비밀 이 된다.

여기선 색을 섞는 것으로 비유했는데, 실제 알고리즘에서는 “정수의 거듭제곱을 소수로 나눈 나머지” 를 이용한다.

상대방 확인하기

하지만 위 알고리즘엔 문제가 있다. 국정원 직원이 단순히 엿듣기만 하는게 아니라, 주고 받는 염료 통을 가로챈 뒤에 자기가 고른 거랑 바꿔치기하면 어떻게 될까? 그리고 서버에겐 자기가 클라이언트인 척, 클라이언트한텐 서버인 척 속이는게 가능해진다. 어떻게 하면 이런 문제를 피해갈까?

다음과 같은 방법이 가능하다:

  1. 믿을 수 있는 인증서 서비스 (PKI) 를 쓴다. 그리고 이걸 가지고 전자 서명한 공개키(=3에서 섞은 염료)를 보낸다.
  2. 3에서 서버가 보내는 결과물을 항상 미리 알고 있는 값으로 한다.

보통은 1을 쓰겠지만, 국정원에서 한국의 루트 인증서 서비스 제공자인 KISA에 영향력을 행사할 수 있을지 누가 아는가? [^2] 영향력을 행사 못할거라 생각하면 1을, 아니라면 2를 추천한다. 혹은 1의 방법과 유사하지만, 공인 루트 인증서 대신 서명키를 스스로 만든걸 쓰고, 미리 서명키(=공개키)를 클라이언트에 넣어두는 방법도 있다.


메시지 암호화하기

여기까지 진행했다면,

  • 상대방이 내가 연결하려는 서버임이 확실하고 (PKI 혹은 미리 전달한 공개키 이용)
  • 서로 같은 공유 비밀을 가진 상태가 되었다.

이제 공유 비밀에서 비밀키 암호화에서 쓸 비밀키를 만든다. [^3] 여기서부터는 비밀키와 몇 가지 추가 정보 (nonce 등등)으로 보통 말하는 암호화를 수행한다. HTTPS 같은 걸 쓸 때 들어봤을 3DES, RC4, AES, ChaCha20 같은 알고리즘이 여기에 속한다. [^4]

상대가 보낸 메시지가 맞는지 확인하기

국정원처럼 중간에 메시지를 들여다보고, 수정까지 할 수 있는 경우, 실제로 메시지를 수정하거나, 암호화된 메시지인척 추가로 메시지를 보내는 공격도 가능하다. 이런 경우를 어떻게 발견할까?

SSL/TLS 에서는 메시지 인증 코드 (Message Authentication Code; MAC ) 를 쓴다. 보낸 메시지에 대해서 공유 비밀을 이용해서 추가적인 인증 정보를 붙여서 보낸다.

모바일 환경에선 어떻게 해야할까? (feat. 종량제 통신 요금 & 배터리)

유선 인터넷 환경과 달리, 모바일 환경에서는 대부분 종량제 요금을 사용한다. 그래서 암호화 때문에 데이터 요금이 더 나온다면 그걸 좋아할 사람은 별로 없다. 그리고 유선 전원 대신 배터리에서 전원을 얻어와야 하기 때문에, 배터리가 빨리 닳는 것 역시 암호화로 인한 문제가 될 수 있다. 그래서 이 두 가지를 고려하면서 어떤 알고리즘이 좋을지 얘기해보겠다.

키 교환

국가 수준의 돈과 노력을 들이는 상대로부터 안전한 수준으로 권고하는 값이 있다. 대략 AES-128 정도의 보안을 제공하는 수준인데, NIST 권고안에선 다음과 같은 값을 갖는다.

  • 위에서 언급한 디피-헬만 알고리즘의 경우 적어도 3072-bit (384 bytes) 크기의 메시지를 서로 주고 받아야 한다
  • RSA 알고리즘을 이용해서 키를 보내려고 하면 역시 3072-bit 크기의 메시지가 가야한다.
  • 타원곡선 디피-헬만 알고리즘을 쓴다면 이 크기가 256-bit (32 bytes) 로 줄어든다.

그래서 요즘 모바일 환경에서는 타원곡선 디피-헬만 알고리즘 (ECDH)를 많이 쓴다.

비밀키 암호화

현재 널리 쓰이는 알고리즘 몇 가지를 Unity3D + C 라이브러리로 만들어서 테스트 해본 결과가 아래와 같다. 64 bytes 길이의 메시지를 100,000 번 반복 암호화하는데 걸린 시간을 ms 단위로 측정했다.

%ec%bb%ac%eb%9f%bc-%ec%9d%b4%eb%af%b8%ec%a7%802

구글 크롬 모바일 버전이 구글과 통신할 때 괜히 ChaCha20 을 이용하는게 아니다. 각 기기에서 AES-128 보다 ChaCha20 이 10배-30배 정도 빠르다.

메시지 인증 코드

  • 널리 쓰이는 해시 MAC (HMAC) 으로 SHA-256을 쓴다면 32 bytes 만큼 추가 태그를 붙인다.
  • AES128 에서 주로 쓰는 GCM 태그의 경우 16 bytes 만큼 추가 태그가 붙는다.
  • Poly1305 를 이용한다면 역시 16 bytes 추가 태그가 붙는다.

모든 메시지에 대해서 위 만큼 길이가 늘어나야하는 것이니 HMAC 계열은 모두 불가. (최소 32바이트) AES128-GCM 의 경우 하드웨어 가속이 없는 대부분의 모바일 기기에서 느리다. 그러면 현재로써 남은 선택지는 Poly1305 MAC을 쓰는 정도.

그래서 어떻게 해야하는가?

요약하자면,

  • ECDH 로 키를 교환한다
  • ChaCha20 으로 메시지를 암호화한다
  • Poly1305 인증 코드를 사용한다

… 이걸 실제로 만드려면 아래와 같은 기능을 구현해야한다:

  • (암호학적으로)믿을 수 있는 랜덤 함수
  • 타원곡선 연산 함수
  • ChaCha20 암호화 함수
  • Poly1305 인증 코드 계산 함수

를 만들어야 한다.

그런데 만들면서 주의를 기울여야 할 부분도 많다:

타이밍 공격

모든 함수 내에서 메시지 길이 처리와 관련된 부분이 아닌 곳에서 if 문을 쓸 수 없다. 만약 메시지 내용에 따라 if 문으로 처리하게 되면 어떤 값을 다루고 있는지 추측할 수 있게 된다. 2003년 즈음의 OpenSSL에 포함된 RSA 알고리즘이 이런 식으로 구현되어서 RSA 비밀키를 추측할 수 있는 문제가 있었다.

올해 초에도 OpenSSL에 포함된 DSA 알고리즘이 타이밍 정보를 누출해서 키를 추측할 수 있는 문제가 다시 발견되기도 했다.

잘못 만든 랜덤함수

랜덤 함수 출력값이 예측 가능하거나, 일부 랜덤 값을 보고 다음 값을 추측할 수 있는 경우 안전하지 않은 암호화 알고리즘이 많다. Debian linux 포함된 OpenSSL에 들어있는 랜덤 함수를 잘못 수정했다가 수 많은 서버들의 보안 키가 불안전하게 생성된 적이 있다. (대략 2006년 – 2008년 동안)

재사용하면 안되는 값을 재사용

타원 곡선 디지털 서명 알고리즘 (ECDSA) 의 경우 재사용하면 안되는 난수 (nonce) 값을 쓴다. 만약 이 값을 재사용하면 서명키가 어떤 값인지 알 수 있다. 2010년에 Sony가 PS3 전자 서명할 때 같은 nonce 값을 썼다가 전자 서명키 값이 공개되서 망신당했다.

이런 문제를 다 해결하면서 만들 수 있는가? 그렇지 않다.

대안: SSL/TLS를 쓴다

HTTPS 처럼 사용 시나리오가 명확하다면 SSL/TLS 를 쓰고, 위에서 언급한 알고리즘을 지정해서 쓰는 방법이 있다.

대안: libsodium

위에서 언급한 알고리즘 대다수를 좀 더 고수준 API 형태로 제공하는 라이브러리다. 대부분의 모바일 OS와 서버 환경에서 사용할 수 있다. (Windows, linux, macOS, Android, iOS 지원)

  • 랜덤 함수: OS 별로 제공하는 암호학적으로 적당한 랜덤 함수를 래핑해서 제공한다
  • 키교환: 타원 곡선 알고리즘을 제공한다. 이 알고리즘으로 ECDH 를 구현할 수 있다.
  • 암호화 + MAC: AEAD 란 분류로 해당 알고리즘을 제공한다. (AES128-GCM / ChaCha20-Poly1305)

요약

  • 충분한 시간과 악의가 있는 공격자에 대해서도 게임에서 사용하는 메시지를 읽지 못하게 막을 수 있다
  • 모바일 환경에서 쓰기에 적당한 현대적인 알고리즘들이 존재한다 (ECDH, ChaCha20, Poly1305 MAC)
  • 해당 알고리즘을 안전하게 구현한 라이브러리 널리 쓰이는 라이브러리들이 있으니 가져다 쓰자: OpenSSL, libsodium

[^1]: 중간자 공격 (MITM; man-in-the-middle-attack) 이라고 부른다.

[^2]: KISA Root CA 같은 한국의 루트 인증서 제공자가 있다. 국정원 같은 국가 기관이 여기에 영향력을 행사 할 수 있다고 상상하는 사람은 이 곳을 신뢰하지 않는 루트 인증서로 처리하는게 좋을 것이다.

[^3]: Key Derivation Function. 랜덤한 여러 바이트를 가지고 특정 길이의 키, nonce 등을 생성하기 위해 쓴다.

[^4]: 미국 국립 표준기술연구소 (NIST) 에서는 3DES 대신 AES를 사용할 것을 권고하고 있다. TLS에 대한 표준안 갱신판인 RFC 7465에서 RC4 알고리즘 사용을 금지하고 있다.

아이펀팩토리 김진욱 CTO