이것은 NAT 뒤에있는 두 호스트 사이에 P2P 연결을 설정하는 합리적인 기술입니까?

Question

두 개의 다른 NAT 뒤에있는 두 호스트가 P2P 연결을 설정할 수 있으려면 둘 다 서로의 공용 끝점 (주소/포트)을 가져야합니다. 각 호스트가 자신의 공용 끝점을 인식하게하려면 서버에서 볼 수있는 공용 끝점을 호스트에 반환하는 알려진 공개 서버와 통신 할 수 있습니다. STUN (RFC5389)을 참조하십시오.

이 메커니즘이 작동하려면 NAT에서 대상 끝점과 상관없이 동일한 개인 끝점을 동일한 공용 끝점으로 일관되게 변환해야합니다.

이 특정 NAT 동작에 따라 P2P 응용 프로그램을 구현하는 것이 좋습니다 (즉, 일반적으로 충분합니까). Skype 및/또는 다른 인기있는 P2P 응용 프로그램에는 다른 대체 메커니즘이 있습니까?

EDIT : 대상마다 다른 포트를 선택하는 NAT를 "대칭 NAT"라고합니다. 또한 일부 대칭 NAT는 포트 번호를 증가시켜 적절한 포트를 추측 할 수 있습니다.

이제는 NAT의 몇 퍼센트가 대칭 NAT입니까? 그리고 임의의 포트 할당을 사용하는 비율이 증가하는 것과 비교하여 어떤 비율입니까?

Answer 1

당신은 IETF에서 표준 STUN/TURN/ICE 프로토콜을 사용할 수 있습니다 http://rtcbits.blogspot.com/2012/10/what-is-ice-interactive-connectivity.html

구글 GTalk을 통계에 따르면 이러한 메커니즘이 경우 92 %의 트래픽을 중계하지 않고 P2P 연결을 해결한다. https://developers.google.com/talk/libjingle/important_concepts

Answer 2

STUN은 사례의 85 % 만 처리 할 수 ​​있습니다! TURN은 100 %를 처리 할 수 ​​있지만 실제로 사용하는 데 비용이 많이 듭니다. 그래서 무엇을 사용해야합니까? 두 가지 중 어느 것도 없습니다.

ICE를 사용하십시오. STUN 서버와 TURN 서버의 직접적인 조합입니다! 그렇게하면 100 %의 안정성을 갖지만 트래픽의 15 % 만 서버에서 릴레이합니다.