12
webrtc에 대한 STUN 서버에 대한 나의 이해는 클라이언트가 NAT 뒤에있는 경우 (대부분이 아닌 모든 경우) STUN 서버는 webrtc 클라이언트가 자신의 주소와 포트를 식별하는 것을 도와줍니다. 또한 webrtc 클라이언트에 신호 서버가 필요하다는 일부 문서를 읽었습니다. 시그널링 서버는 웹 서버, socket.io이거나 URL을 전자 메일로 보낼 수도 있습니다. 내 첫 질문은 : STUN 서버가 신호 서버입니까? socket.io 기반 시그널링 서버를 사용하는 경우 webrtc에 STUN 서버가 절대적으로 필요합니까?
사실 지금은 다른 모든 클라이언트에 클라이언트의 세션 설명을 방송하는 매우 간단한 socket.io 기반 서비스를 구축. 그래서 socket.io 기반 서버는 클라이언트의 주소와 포트 정보에 대한 충분한 지식을 가지고 있어야한다고 생각합니다. 이 경우 다른 STUN 서버를 가지고 왜 귀찮게합니까?
매우 명확하고 유익한 답변 덕분에 @bwtrent에게 감사드립니다. STUN 서버는 언제 재생됩니까? 피어 연결이 시작될 때 또는 연결 중에 항상 있어야합니까? 응답이 연결의 시작 부분에만있는 경우? 시그널링 서버가 STUN 서버가 무엇을 하든지간에 무엇이든할까요? 신호 서버는 각 피어와 대화하기 위해 피어의 NAT 정보에 대해 충분히 알고 있어야한다고 생각하기 때문입니다. STUN 서버의 복잡성을 과소 평가 했나요? –
@ElgsQianChen STUN 서버 여야합니다. 신호 서버와 STUN 서버는 동일한 물리적 위치/동일한 물리적 상자/FQDN에있을 수 있지만 NAT 협상은 STUN (또는 대칭 NAT가 작동 중일 때 켜짐)으로 수행되어야합니다. 이것은 WebRTC spec/movement/그것이 현재 호출되고있는 것과 일치합니다. –
@BenjaminTrent가 언급했듯이, STUN과 시그널링 서버는 동일한 물리적 인 기계 IFF 둘 모두에 존재할 수 있습니다. 신호 서버 부분은 정보를 교환하기 위해 두 피어가 연결하기 바로 전에 작동합니다. 반면 STUN (또는 TURN)의 역할은 이전에 왔으며 각 피어에게 어떻게 도달 할 수 있는지 알려주거나 업데이트하는 것입니다. 이 정보는 시그널링 단계에서 연결을 설정하는 데 사용됩니다. 이것이 STUN이 두 동료에게 공개되어야하는 이유입니다. – karimyafi