Skype와 같은 P2P 소프트웨어는 UDP 구멍 펀칭을 사용하고 있습니다. 하지만 클라이언트 중 하나가 다른 클라이언트 (UDP 대신 TCP 연결)에서 파일을 다운로드해야하는 웹 브라우저 인 경우 어떻게해야합니까? 그런 경우에 어떤 기술이 있습니까?방화벽 뒤에 두 클라이언트 (그 중 하나는 브라우저)를 연결하는 방법
나는 클라이언트와 결혼 할 수있는 중간 공용 서버를 가질 수 있지만 이러한 클라이언트 간의 모든 트래픽은이 서버를 통과 할 수는 없습니다. 공용 서버는 Skype처럼 클라이언트 간의 연결 만 설정할 수 있습니다. 그게 전부입니다. 그리고 이것은 TCP (더 정확히는 HTTP)를 통해 다운로드 클라이언트가 웹 브라우저가되도록해야합니다.
두 클라이언트는 라우터 나 그 밖의 어떤 것에도 설정을해서는 안됩니다.
이 코드를 C/C++로 작성할 계획입니다.하지만이 시점에서이 아이디어가 가능한지 궁금합니다.
필자는 이전에 P2P가 다양한 프로토콜 및 해당 오픈 소스 라이브러리에 대한 토론과 함께 어떻게 작동하는지에 대해 매우 통합 된 대략적인 답변을 작성했습니다. 당신은 그것을 here 읽을 수 있습니다.
P2P의 신뢰성은 궁극적으로 고객 코딩 관점과 서비스 구성 (즉, 신호 서버 및 릴레이)에서 투자 한 금액의 결과입니다. 방화벽을 지원하지 않고 NAT를 쉽게 통과 할 수 있습니다. 어쩌면 조금 더 노력하면 TCP 연결을 얻을 수 있습니다. 그리고 "모든 방법"으로 갈 수 있으며, 가장 어려운 방화벽 뒤에있는 클라이언트를위한 HTTPS 리스너가있는 릴레이를 사용할 수 있습니다.
방화벽에 관한 질문에 대한 답과 관련하여. 방화벽 구성 방법에 따라 다릅니다. 많은 방화벽은 특정 포트에 대한 트래픽을 제한하고 원하지 않는 들어오는 연결을 차단하는 보안 기능을 갖춘 눈부신 NAT입니다. 다른 것들은 매우 제한적이며 프록시를 통한 HTTP/HTTPS 트래픽 만 허용합니다.
화상 회의 응용 프로그램은 궁극적으로 PC의 구성된 프록시 서버를 통해 원격 연결 서버의 포트 443 (또는 80)에 HTTPS 연결을 에뮬레이션하는 것으로 대체됩니다 (직접 연결할 수없는 경우). (어떤 경우에는 원격 클라이언트가 포트 80 또는 포트 443에서 수신 대기하므로 직접 연결할 수 있습니다.)
릴레이를 통과하는 모든 클라이언트가 유지 보수하는 데 비용이 많이 든다고 가정하는 것은 당연한 것입니다. 귀하의 목표가 백엔드의 방화벽 유형에 관계없이 100 % 연결이면 일부 릴레이 솔루션이 존재해야합니다. 릴레이 솔루션을 지원하지 않는다면 직접 연결이 안정적으로 작동하도록 투자하고 소수의 고객 만 차단할 수 있습니다.
희망이 도움이됩니다.
감사합니다. 단 한가지 질문 (다른 의견 작성자와 동일). 동료 중 하나가 STUN, TURN 등을 모르는 HTTP 브라우저 일 때 (적어도 이론상으로)이 작업을 수행 할 수 있습니까? 클라이언트가 일반 브라우저 여야하기 때문에 반드시이 경우에 사용해야합니다 (그리고 다른 서버는 적어도 대부분의 경우 공용 서버를 통해 실제 파일 트래픽을 릴레이 할 수 있어야합니다). 가능하지 않다면 다른 P2P 앱을 만들려고하지 않기 때문에 NAT를 통과하는 방법을 자세히 조사하는 것은 시간 낭비 일 것입니다. 수신자가 웹 브라우저가 될 수 없다면 그것은 이야기의 끝입니다. – Alex
흠 ... 나는 대략 "타당하지 않을 것"이라고 치려고했지만, 그때 나는 이것을 생각했다. 브라우저는 30x 메시지로 브라우저를 리디렉션하는 웹 서비스를 공격하여 웹 서버를 에뮬레이트하는 원격 피어에 연결할 수 있습니다. 하지만 원격 피어 (peer)의 NAT를 통과하는 것은 어려운 일입니다. 브라우저는 후속 연결마다 다른 로컬 TCP 포트를 선택할 가능성이 높기 때문에 다른 쪽 NAT를 통과하기가 어려워집니다. (실현하기 위해 시도하는 시나리오는 무엇입니까? – selbie
BTW, 첫 번째 서버가 랑데부 인 두 개의 공용 서버가있는 시나리오는 괜찮습니다. 두 번째 서버 (다른 네트워크에 상주)는 (홀 펀칭 단계). 연결이 성공하면 얻은 설정 (포트 및 IP)을 수신 측 (홀 펀칭을 수행 할 수없는 웹 브라우저이므로 이에 대한 도움이 필요함)으로 전달할 수 있습니다. 물론, 이것은 수신 측이 제 2의 공개 서버가 송신 측에 접속했을 때와 동일한 종단점을 사용할 수 있다고 가정합니다. 작동 여부는 확실하지 않습니다 – Alex
PeerConnection, WebRTC 부분은 최신 브라우저에서이를 해결합니다.
NAT 구멍 펀칭을 위해 RFC 인 ICE을 사용합니다.
구형 브라우저의 경우 플래시에서 P2P 지원을 사용할 수 있습니다.
stunovertcp 라이브러리가 유망 해 보입니다. – Alex
뻔뻔한 플러그 - 스턴트맨을 사용하십시오. 적극적으로 지원되며 TCP를 포함한 STUN의 다중 구성을 지원합니다. www.stunprotocol.org – selbie
감사합니다. 한가지 더 궁금한 점이 있습니다. - 이론상으로 한 면만이 모든 STUN 정보를 알고 있다면 이것을 사용할 수 있습니까?내 상황에서는 제 3 자 (파일을 다운로드하는 클라이언트 피어)가 HTTP를 통해 작동하는 일반 브라우저 인 반면 통신의 특성을 인식하는 전용 IP 주소를 가진 서버 피어 및 공용 서버가 있습니다. 그런 시나리오에서 STUN을 사용할 수 있습니까? 또는 모든 당사자가이 프로토콜을 통해 통신해야한다고 가정합니다. – Alex