[GPG 5 글 6.5] GPG 5권의 홀펀칭 관련 아티클을 읽고

GPG 시리즈 관련 질답, 논의 공간.

Moderator: 류광

비회원

GPG 5권의 홀펀칭 관련 아티클을 읽고

Post by 비회원 »

잡담

헐헐. 읽은 것은 꽤 되었는데 이제서야 글을 쓰게 되었습니다. ^^;
지난주에 삼성역 서점에서 바닥에 궁듸 붙이고 열심히 읽었던 부분을
살살 기억을 더듬어 작성해보도록 하겠습니다.

summary
본 글은 최소한 "홀펀칭"이라는 용어를 잘 알고 있고 거부감 없이 사용하는 분들을 대상으로 쓰여졌습니다.
또, 이 글을 읽기 전에 GPG5권을 구하실 수 있으면 원본을 먼저 보시기를 강력히 추천드립니다.
지극히 개인적인 지식을 바탕으로 쓰여진 글이니 틀린점이 있다면 따끔한 지적 부탁드리겠습니다.


Overview
P2P 통신은 서비스 서버의 부하를 주지 않으면서 네트워크 서비스를 수행할 수 있는 모델로서
현재 많은 온라인 서비스의 주류를 이루고 있는 네트워크 방식이라고 할 수 있습니다.
하지만 IP주소의 부족, 혹은 홈 네트워크 구축의 보편화로 IP공유기 라는 장비가 인기를 끎에 따라
공유기의 수요가 증가함은 물론이고 실제로 많은 가정에서 공유기를 사용하고 있습니다.
공유기라는 장비 덕분에 홀펀칭 이라는 테크닉이 거론되었고 P2P 서비스를 시도하기 위해서는
필수적인 테크닉이 되어버렸습니다.

홀 펀칭을 위해 알아야 하는 기본 지식 중에는 "NAT 타입"이라는 필수적인 지식이 수반됩니다.
아래는 각 NAT 타입의 간략한 설명입니다.

types of NAT
-Full Cone, Port Restricted Cone, Restricted Cone 은 하나의 내부 (*)세션에 대해
NAT에 맵핑되는 external 포트는 변하지 않지만 외부에서 내부로 들어오는 패킷의 주소 또는
포트의 번호에 따라 제약을 주는 NAT 방식입니다.
각 제약의 수준은 아래와 같습니다.
Full Cone < (IP)Restricted Cone < Port Restricted Cone

-Symmetric NAT 는 하나의 내부 세션에 대해 NAT에 맵핑되는 external포트 번호가
외부 원격지의 IP주소와 PORT 번호에 따라 맵핑되는 포트가 변경되는 NAT 타입 입니다.

(*)세션 : IP주소와 Port가 바인드 된 네트워크 통신이 가능한 소켓으로 "통신이 가능한 유닛"의 뜻으로 사용했습니다.



그럼 각 NAT 타입에서의 홀펀칭에 대한 제 짧은 생각을 펴보도록 하겠습니다.


Full Cone & Full Cone
Full Cone은 아무런 제약이 없으니 랑데뷰 서버에서 캡춰한 IP주소와 포트를
해당 Peer에 연결하고자 하는 세션들에게 나눠주어 P2P (*)터미널을 생성할 수 있겠습니다.

(*)터미널 : 통신 가능한 두 세션의 연결을 본 용어로 사용했습니다.



Full Cone & Other || Other & Full Cone
우선적으로 제약이 없는 Full Cone을 (*)서버로 두고 역시 랑데뷰 서버에서 캡춰한 IP주소와 포트를
해당 Peer에 연결하고자 하는 세션들에게 나눠주어 P2P (*)터미널을 생성할 수 있습니다.

(*)서버 : 방장, 혹은 통신상 서버의 역할이 필요한 시스템 에서 "메인 서비스 제공자"의 뜻으로 사용했습니다.



Restricted Cone & Restricted Cone || Port Restricted Cone & Port Restricted Cone
제 개인적인 생각은 Port Restricted Cone & Port Restricted Cone 의 터미널 생성이 가능하다면
Restricted Cone & Restricted Cone 역시 통신이 가능하다고 생각하기에
Port Restricted Cone & Port Restricted Cone에 대해 이야기 해보도록 하겠습니다.

먼저 A와 B 라는 두 개의 외부 NAT 세션을 가정하겠습니다.
랑데뷰 서버에서 A와 B의 external IP와 Port를 받아 A의 정보는 B로, B의 정보는 A로 보냅니다.
Full, Restricted, Port Restricted는 맵핑된 포트가 변하지 않기 때문에
Restricted 형제의 제약이 없다고 가정한다면, A와 B가 랑데뷰 서버로 부터 받은 주소와 포트로 패킷을 보냈을 때
성공적으로 sendto와 recvfrom이 호출 될 것 입니다.

전 여기서, 아직 테스트를 해보지 못했다는 죄송한 말씀을 드리며 아래의 상황을 가정할 수 밖에 없었습니다.
가정 상황. 내부 세션에서 보낸 패킷이 공유기를 통과하게 되면,
이후 패킷의 경과와는 상관 없이 내부 세션에 대한 외부 포트가 공유기에 맵핑되거나 제약을 해제합니다.

즉, IP 헤더를 달고있는 패킷이 공유기를 통과하기만 하면
해당 내부 세션에 대한 외부 포트가 공유기에 맵핑되거나 제약을 해제한다고 가정을 했습니다.

자 그럼 다시 Port Restricted Cone & Port Restricted Cone의 통신 이야기로 돌아와서 시퀀스를 작성해 보겠습니다.
1. 랑데뷰 서버에서 A의 정보는 B로, B의 정보는 A로 보냅니다.
2. 받은 정보로 A는 B로 패킷을 보냅니다.
2-1. A에서 B로 패킷을 보낼 때, 패킷은 A의 공유기를 통과하면서 세션 B에 대한 제약을 해제시킵니다.
2-2. B의 공유기는 아직 A에 대한 제약이 걸려있으므로 A로부터 전송된 패킷은 B의 공유기에서 걸려 전송에 실패합니다.
3. 받은 정보로 B는 A로 패킷을 보냅니다.
3-1. B에서 A로 패킷을 보낼 때, 패킷은 B의 공유기를 통과하면서 세션 A에 대한 제약을 해제시킵니다.
3-2. 2-1에서 A의 공유기에서 세션B에 대한 제약을 해제시켰으므로 B에서 보낸 패킷은 A가 받을 수 있습니다.
4. 다음 A에서 전송된 패킷은 3-1에 의거하여 B의 공유기를 통과해 B까지 성공적으로 도달하고 B는 A의 패킷을 받습니다.

이로써 Port Restricted Cone & Port Restricted Cone 간의 터미널 생성도 가능해졌습니다.



Symmetric & Symmetric
가장 까다로운 녀석 이로군요.
지금까지 Symmetric & Symmetric의 연결은 대부분 불가능 한 것으로 여겨졌으며 앞으로도
뚜렸한 해결책이 제시되지 않는 한 이 사실은 변하지 않을 것 같습니다.
(대부분 중계서버를 두는 식으로 해결을 했지요?)
참, GPG에서도 많은분들이 거론을 해주신 방법으로
게임 서버에서 가장 먼저 시행해야 할 부분은 터미널을 생성할 Peer들이 Symmetric & Symmetric 방식인지
확인을 하는 것이겠지요.
간략히 적으면, 서버에서 두 포트를 열어 하나의 세션에서 받은 패킷의 포트가 다를 때에
Symmetric 방식으로 판정하는 것입니다.
어떤 Symmetric 방식의 공유기는 다음번 맵핑되는 포트가 일정한 규칙이 있다고도 하셨는데
역시 특정 공유기에서만 그런 것 같아 보이니 응용할만한 가치는 조금 떨어지는 것 같습니다.
그냥 심신이 편안하게 중계 서버를 통해 UDP 통신을 하는 것이 좋을 것 같습니다.

분위기상 Symmetric & Symmetric 부분을 기대하셨던 분들도 계실거라 생각합니다. -_-;
"결국은 이거잖아~ 뭐야~!" 라는 반응 예상하고 있습니다. 녜...; 무척 죄송스럽습니다;


Conclusion
도망치듯 결론을 적게 되었군요.
위 글은 공유기 환경에서의 UDP 통신을 다룬 레포트로서 잘못된 정보가 담겼을 가능성을 배제할 수 없습니다.
홀펀칭은 이미 GPG에서도 지겹도록 많이 거론된 스레드 라고 기억하고 있습니다.
홀펀칭에 대해 알고자 하는 초심자 분들이, 검색을 통해 본 레포트를 찾을 수 있기를 바라며
이만 줄이겠습니다.

GPG여러분들의 경험어린 지적과 질타 부탁드리겠습니다.
비회원

Re: GPG 5권의 홀펀칭 관련 아티클을 읽고

Post by 비회원 »

아이고 따끔해라. 난 고슴도치 인가BOA~

Summary의
본 글은 최소한 "홀펀칭"이라는 용어를 잘 알고 있고 거부감 없이 사용하는 분들을 대상으로 쓰여졌습니다.
부분은 무시해 주십시오. -_-;
해키스트
Posts: 398
Joined: 2004-02-14 20:11
Location: N거시기
Contact:

Post by 해키스트 »

개인적인 경험을 말씀드리겠습니다.
실제로 저 4가지 스타일의 NAT만 있다면 좋겠으나, 제가 사용한 몇몇 NAT중에는 symmetric의 특성을 지니는 restricted cone NAT도 있었습니다.

<b>즉, 벤더는 저 4가지 분류를 꼭 따르지 않는다는 것입니다.</b>

따라서 테스트가 동반되지 않은 분류는 그다지 큰 도움이 되지 않습니다.
작년에 이 문제를 해결하면서 얻은 결론은, NAT의 종류를

홀 펀칭이 되는가?
안되는가?

로 따지는게 훨씬 심플해지고, 그에 따른 대비를 하기가 쉬웠습니다.
Quitters no win, winners no quit.
비회원

Post by 비회원 »

해키스트 wrote:개인적인 경험을 말씀드리겠습니다.
실제로 저 4가지 스타일의 NAT만 있다면 좋겠으나, 제가 사용한 몇몇 NAT중에는 symmetric의 특성을 지니는 restricted cone NAT도 있었습니다.

<b>즉, 벤더는 저 4가지 분류를 꼭 따르지 않는다는 것입니다.</b>

따라서 테스트가 동반되지 않은 분류는 그다지 큰 도움이 되지 않습니다.
작년에 이 문제를 해결하면서 얻은 결론은, NAT의 종류를

홀 펀칭이 되는가?
안되는가?

로 따지는게 훨씬 심플해지고, 그에 따른 대비를 하기가 쉬웠습니다.
앙~ 그렇군요. 경험어린 조언 감사드립니다.

그러고보니 공유기 업체들이 여럿 있듯이 NAT 타입도 각 업체들만의 방식이 있다고 들은 것 같습니다.



혹여나 제가 쓴 글이 초심자 분들께(저도 초심자군요. 흐흐;) 안 좋은 영향을 줄 소지가 있다면 말씀 주십시오.

류광님께 삭제 요청을 부탁드리겠습니다.
해키스트
Posts: 398
Joined: 2004-02-14 20:11
Location: N거시기
Contact:

Post by 해키스트 »

아닙니다^^ 정말 좋은 글입니다 :)
이런글은 gpg에 계속 남아있어야 하죠.

나중에 술 한잔 쏘신다면 제가 테스트했던 내용들을.. 흐흐
Quitters no win, winners no quit.
Post Reply