WebRTC：修订间差异
无编辑摘要 |
无编辑摘要 |
||
| 第2行： | 第2行： | ||
[[File:webrtc-workflow.png|600px]]<ref>https://www.wowza.com/blog/webrtc-server-what-it-is-and-why-you-need-one</ref> | [[File:webrtc-workflow.png|600px]]<ref>https://www.wowza.com/blog/webrtc-server-what-it-is-and-why-you-need-one</ref> | ||
= Signaling server = | |||
Let's imagine, we have 2 peers that want to establish a direct connection and transmit streams between each other. | |||
But they don't know anything about each other yet. So we need some third party service that will help them share the service information and start direct streams transmission. That's a job for a signaling server. | |||
Peers interact with a signaling server to share the handshakes and start a direct peer-to-peer transmission. | |||
NOTE: The traffic and calculation load of the signaling server is relatively low, but it's a core of your WebRTC connection system. We recommend you to deploy your own signaling server for production usage. | |||
=STUN server= | |||
The scheme above works perfectly in local area network where each peer has its own IP address and there are no firewalls and routers between them. | |||
But when it goes to the internet, peers can be hidden behind NAT and do not have any information about the external addresses of each other. | |||
That's the point when we need a STUN server. It allows to detect peers public network addresses and establish a peer-to-peer connection behind a NAT. | |||
NOTE: The traffic and calculation load of the STUN server is relatively low, so you can use a public one or deploy your own. | |||
=TURN server= | |||
This scheme works fine in most cases. But there is another problem that can prevent direct peer-to-peer transmission: a firewall. It can be placed at any point of the network and cut the direct WebRTC traffic. | |||
A way to solve this problem is to use a TURN server. It has a public address, so both peers can interact with TURN server even behind firewalls. So when no direct peer-to-peer connection available, TURN server transmits audio/video streams of both peers just like a common media server. | |||
NOTE: As TURN server transmits the media streams between peers it consumes a lot of traffic and requires a lot of calculation power, especially in a case of multiple peers processing. We strongly recommend you to have a dedicated server for this task and make sure that the traffic bandwidth is big enough to handle this task. | |||
=Summary= | |||
Signaling server is used to let peers share service information to start the peer-to-peer streams transmission. | |||
STUN server is used to let peers know each other's external address to start the peer-to-peer streams transmission behind the NAT. | |||
TURN server is used to let peers transmit streams to each other behind a firewall. There is no peer-to-peer streams transmission in this case. All media traffic goes through a TURN server.<ref>https://support.medialooks.com/hc/en-us/articles/360000213312-%D0%95nvironment-signaling-STUN-and-TURN-servers#:~:text=STUN%20server%20is%20used%20to,goes%20through%20a%20TURN%20server.</ref> | |||
[[Category:Network]] | [[Category:Network]] | ||
[[Category:Protocol]] | [[Category:Protocol]] | ||
2024年2月20日 (二) 09:59的最新版本
WebRTC (Web Real-Time Communication) is a free and open-source project providing web browsers and mobile applications with real-time communication (RTC) via application programming interfaces (APIs). It allows audio and video communication to work inside web pages by allowing direct peer-to-peer communication, eliminating the need to install plugins or download native apps.
Signaling server
Let's imagine, we have 2 peers that want to establish a direct connection and transmit streams between each other.
But they don't know anything about each other yet. So we need some third party service that will help them share the service information and start direct streams transmission. That's a job for a signaling server.
Peers interact with a signaling server to share the handshakes and start a direct peer-to-peer transmission.
NOTE: The traffic and calculation load of the signaling server is relatively low, but it's a core of your WebRTC connection system. We recommend you to deploy your own signaling server for production usage.
STUN server
The scheme above works perfectly in local area network where each peer has its own IP address and there are no firewalls and routers between them.
But when it goes to the internet, peers can be hidden behind NAT and do not have any information about the external addresses of each other.
That's the point when we need a STUN server. It allows to detect peers public network addresses and establish a peer-to-peer connection behind a NAT.
NOTE: The traffic and calculation load of the STUN server is relatively low, so you can use a public one or deploy your own.
TURN server
This scheme works fine in most cases. But there is another problem that can prevent direct peer-to-peer transmission: a firewall. It can be placed at any point of the network and cut the direct WebRTC traffic.
A way to solve this problem is to use a TURN server. It has a public address, so both peers can interact with TURN server even behind firewalls. So when no direct peer-to-peer connection available, TURN server transmits audio/video streams of both peers just like a common media server.
NOTE: As TURN server transmits the media streams between peers it consumes a lot of traffic and requires a lot of calculation power, especially in a case of multiple peers processing. We strongly recommend you to have a dedicated server for this task and make sure that the traffic bandwidth is big enough to handle this task.
Summary
Signaling server is used to let peers share service information to start the peer-to-peer streams transmission. STUN server is used to let peers know each other's external address to start the peer-to-peer streams transmission behind the NAT. TURN server is used to let peers transmit streams to each other behind a firewall. There is no peer-to-peer streams transmission in this case. All media traffic goes through a TURN server.[2]