WebRTC 是如何工作的?

这里的缩略词:http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ 剩下的就是谷歌.其中大部分由 IETF (http://ietf.org/) 定义Firefox 和 Chrome(以及规范)已转向对 ICE 候选者使用涓流"，因此 ICE 候选者通常在面对面后添加到 PeerConnection 并独立于初始 SDP 进行交换(尽管您可以等到初始候选者在发送报价之前准备好，并将它们捆绑在一起).请参阅 https://webrtcglossary.com/trickle-ice/ 和 https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/I'm interested in Peer-to-Peer connections in the browser. Since this seems to be possible with WebRTC, I'm wondering how it works exaclty.I've read some explanations and saw diagrams about it and now it's clear to me, that the connection establishmet works over the server. The server seems to exchange some data between the client that are willing to connect to each other, so that they can start a direct connection, that is independent of the server.But that's exaclty what I don't understand. Until now, I thought the only way to create connections is to listen on a port on computer A and connect to that port from computer B. But this does not seem to be the case in WebRTC. I think none of the clients starts to listen on a port. Somehow, they can create a connection without listening on ports and accepting connections. Neither client A, nor client B starts acting as a server.But how? What data is exchanged over the WebRTC server, that the clients can use to connect to each other?Thanks for your explanations for this :)EditI found this article. It's not related to WebRTC, but I think it answers a part of my question. I'm not sure, tough. It still would be cool, if someone could explain it to me and give me some additional links. 解决方案 WebRTC gives SDP Offer to the client JS app to send (however the JS app wants) to the other device, which uses that to generate an SDP Answer.The trick is that the SDP includes ICE candidates (effectively "try to talk to me at this IP address and this port"). ICE works to punch open ports in the firewalls; though if both sides are symmetric NATs it won't be possible generally, and an alternative candidate (on a TURN server) can be used.Once they're talking directly (or via TURN, which is effectively a packet-mirror), they can open a DTLS connection and use it to key the SRTP-DTLS media streams, and to send DataChannels over DTLS.Edit:Acronyms here: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ for the rest, there is Google. Most of these are defined by the IETF (http://ietf.org/)Edit 2:Firefox and Chrome (and the spec) have moved to using "trickle" for ICE candidates, so the ICE candidates are generally added after-the-face to the PeerConnection and exchanged independently of the initial SDP (though you can wait until the initial candidates are ready before sending an offer, and bundle them together).See https://webrtcglossary.com/trickle-ice/ and https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ 这篇关于WebRTC 是如何工作的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！