English explanation of WebRTC
Feb. 1st, 2016 08:57 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
madbernardWebRTC (Web Real-Time Communication) is a plan to let there be plugin-less peer-to-peer sharing... In real time... Of anything. Back in the day, you had to download Flash or Silverlight or some other godawful program to use your webcam with the internet. Since HTML5, the ability for a browser to ask you for access to your webcam or microphone is built in to the spec.
There are three legs of WebRTC: the first, mentioned above, is the "getUserMedia" API, added to browser javascript, part of HTML5. The second and third are for WebRTC alone: the ability to maintain a direct computer to computer connection (forget the rest of the internet! We got us!), and the ability to exchange arbitrary data along that connection (for now, mostly live video). These second and third, which are specifically called RTCPeerConnection and RTCDataChannel, are something the browser makers should build in; but as of today, not all of them have.
Chrome, Firefox, and Microsoft Edge are up to speed on WebRTC: if you have one of them, go check out https://webcamtoy.com/ . It's a surprisingly fun website, and a source of great userpics. (I just tried visiting with Safari, to see what happened: the page let me know that I'd have to install Flash to continue. Good on them for having their ducks in a row, bad on Safari for not getting with the times.)
Sidenote: The "of anything" part up there surprises me. I suspect, in a couple years, we'll be hearing the MPAA screaming their heads off about this casual built-into-the-internet, doesn't-need-a-special-program, encrypted exchange. Right now, the only fully-baked sites using WebRTC are things like https://talky.io/ and https://appear.in/ ... Webcam-focused challengers to Google Hangouts. But there are half-baked demonstration WebRTC file sharing sites scattered around, and my money says that soon it'll be even more of a wild west out there.
What is the difference between FTP and WebRTC and HTTP and the other various protocols that exist out on the internet? I'm not fully conversant on how all the various kinds of traffic move, I'm afraid. My understanding is, HTTP will send packets of info hopping on lengthy journeys through possibly dozens of computers; the info is in plaintext (unless HTTPS); anyone could look at it. WebRTC, in my understanding, is like HTTPS without the need for everyone involved to spend a day setting it up properly. The packets are encrypted, the servers that pass them along see only routing information, and the unencryption at each end is done by the browser, just as it does with HTTPS. The other difference with, say, HTTP, is that WebRTC is realtime, using the old UDP standard for sending constant streams of information back and forth, without caring too terribly much if some packets are lost.
To start a WebRTC connection to someone else, there's a signaling stage where both computers explain what type of encoding they're expecting, what ports they can receive on, etc. One site mentioned that this could technically happen by snail mail, and the rest of the WebRTC could then go merrily on its encrypted real-time peer-to-peer way...
Most sites that explain the signaling spend a lot of pixels on ICE, the simultaneous showing of the hands to figure out which paths are open between two computers. I think the poker-game metaphor covers it.
The other signaling server component is TURN, which in simple terms is a server that when you say "Hey, where does it look like I'm coming from, port-wise?" says "Here, this is your address, so far as I can see. This is what your ISP and firewall and router have cooked up between them." Very few of us have a static IP address with only one thing plugged in to it; most people have various devices that translate internet traffic into intranet traffic. This is where WebRTC (and various gamers on PlayStations and Xboxes) runs into trouble: some routers, in their wild wisdom, use "symmetric NAT" which means that every request that comes in to your computer gets routed differently. The TURN server sends you a fair response and you can't use it, because your router has moved on, man! It's a free spirit!
In that last case, both you, and the person at the other end of the WebRTC, have to connect to a third server which pretends to be just another person sharing the stream. This server, called a STUN server, takes the packets you would have exchanged if your router was less of a jerk, and forwards them on to your peer, and likewise the other way. Technically, it's not supposed to be set up to read them. Metaphorically, this is when WebRTC acts basically just like the rest of the internet.
The tl:dr is, WebRTC: the browsers that care about security have set up a more secure real-time sharing service, and you don't need crummy programs any more to do interesting webcam things.
There are three legs of WebRTC: the first, mentioned above, is the "getUserMedia" API, added to browser javascript, part of HTML5. The second and third are for WebRTC alone: the ability to maintain a direct computer to computer connection (forget the rest of the internet! We got us!), and the ability to exchange arbitrary data along that connection (for now, mostly live video). These second and third, which are specifically called RTCPeerConnection and RTCDataChannel, are something the browser makers should build in; but as of today, not all of them have.
Chrome, Firefox, and Microsoft Edge are up to speed on WebRTC: if you have one of them, go check out https://webcamtoy.com/ . It's a surprisingly fun website, and a source of great userpics. (I just tried visiting with Safari, to see what happened: the page let me know that I'd have to install Flash to continue. Good on them for having their ducks in a row, bad on Safari for not getting with the times.)
Sidenote: The "of anything" part up there surprises me. I suspect, in a couple years, we'll be hearing the MPAA screaming their heads off about this casual built-into-the-internet, doesn't-need-a-special-program, encrypted exchange. Right now, the only fully-baked sites using WebRTC are things like https://talky.io/ and https://appear.in/ ... Webcam-focused challengers to Google Hangouts. But there are half-baked demonstration WebRTC file sharing sites scattered around, and my money says that soon it'll be even more of a wild west out there.
What is the difference between FTP and WebRTC and HTTP and the other various protocols that exist out on the internet? I'm not fully conversant on how all the various kinds of traffic move, I'm afraid. My understanding is, HTTP will send packets of info hopping on lengthy journeys through possibly dozens of computers; the info is in plaintext (unless HTTPS); anyone could look at it. WebRTC, in my understanding, is like HTTPS without the need for everyone involved to spend a day setting it up properly. The packets are encrypted, the servers that pass them along see only routing information, and the unencryption at each end is done by the browser, just as it does with HTTPS. The other difference with, say, HTTP, is that WebRTC is realtime, using the old UDP standard for sending constant streams of information back and forth, without caring too terribly much if some packets are lost.
To start a WebRTC connection to someone else, there's a signaling stage where both computers explain what type of encoding they're expecting, what ports they can receive on, etc. One site mentioned that this could technically happen by snail mail, and the rest of the WebRTC could then go merrily on its encrypted real-time peer-to-peer way...
Most sites that explain the signaling spend a lot of pixels on ICE, the simultaneous showing of the hands to figure out which paths are open between two computers. I think the poker-game metaphor covers it.
The other signaling server component is TURN, which in simple terms is a server that when you say "Hey, where does it look like I'm coming from, port-wise?" says "Here, this is your address, so far as I can see. This is what your ISP and firewall and router have cooked up between them." Very few of us have a static IP address with only one thing plugged in to it; most people have various devices that translate internet traffic into intranet traffic. This is where WebRTC (and various gamers on PlayStations and Xboxes) runs into trouble: some routers, in their wild wisdom, use "symmetric NAT" which means that every request that comes in to your computer gets routed differently. The TURN server sends you a fair response and you can't use it, because your router has moved on, man! It's a free spirit!
In that last case, both you, and the person at the other end of the WebRTC, have to connect to a third server which pretends to be just another person sharing the stream. This server, called a STUN server, takes the packets you would have exchanged if your router was less of a jerk, and forwards them on to your peer, and likewise the other way. Technically, it's not supposed to be set up to read them. Metaphorically, this is when WebRTC acts basically just like the rest of the internet.
The tl:dr is, WebRTC: the browsers that care about security have set up a more secure real-time sharing service, and you don't need crummy programs any more to do interesting webcam things.