I was reading and trying to find out about WebRTC's RTCDataChannel. As I understand Websockets are on top of TCP and have higher latency than SCTP that underlies WebRTC, when for example sending binary data between server and browser, that also could be 2 peers in WebRTC. When RTCDataChannel is set to unreliable mode (possible package loss but faster), its underlying SCTP becomes analogous to User Datagram Protocol (UDP) and when set to reliable it becomes TCP-like.
Is RTCDataChannel, when configured to be reliable (“TCP-like”), still faster then Websockets (TCP) and if so, how much faster?
Related
I am trying to do some tests in Chromium with HTTP/2, HTTP1.1, QUIC, and TCP. I want to try different combinations of the protocols. I am experiencing some very strange behaviour in my browser though. When I want to try HTTP1.1+QUIC I start my browser with:
chromium-browser --disable-http2 --enable-quic
And I can see at chrome://net-internals/ that HTTP2 is disabled and QUIC is enabled. However, when I do a web request to a server supporting HTTP2 and QUIC I get this:
Why would it say that the HTTP/2 is used when it so clearly says that http2 enabled: false at chrome://net-internals/ ?
I have previously been successful in running HTTP1.1 with QUIC. Has QUIC been updated to only work with HTTP/2? Or does the 'Protocol'-field display the wrong protocol?
I would love to if someone else have been successful is using QUIC with HTTP1.1
Many thanks!
QUIC only works with HTTP/2 and doesn’t make sense with HTTP/1.1.
HTTP/1.1 sends one request at a time on its one TCP connection. Browsers open 6-8 connections to allow some level of parallelisation but, other than that hack, HTTP/1.1 is basically synchronous - you send a request and can’t use that connection again until that request is responded to in its entirety. So HTTP/1.1 has a Head of Line (HOL) blocking problem as a slow, or delayed, response will block the connection so it can’t be used for a resource that could be responded to.
HTTP/2 is a binary, multiplexed protocol, which basically means requests and responses are split into packets which can be sent on a single TCP connection and intermingled. This is great as TCP connections are relatively expensive over the Internet due to the time to set up the TCP connection, to set up HTTPS potentially on top of that and then to build up the TCP slow start rate limiting window to an optimal size. So HTTP/2 being able to send and receive multiple HTTP requests and responses over one TCP connection is a massive improvement and solves the HOL Blocking problem at a HTTP level.
Unfortunately the HOL blocking problem is moved from HTTP layer to TCP layer. TCP is a guaranteed protocol - if a single TCP packet is lost then it is re-requested and the whole connection waits for that missed packet to come back. This is great as higher level protocols (like HTTP) can build upon this without worry about checking if pieces have made it or not or in the right order - TCP takes care of that. The downside with this is that protocols like HTTP/2 may not need this strict level of guarantees. If a server is sending 6 HTTP/2 responses on one connection at the same time, and one TCP packet gets dropped it will only be for one of those responses - the other 5 could in theory continue to be sent and then be processed by the browser. But TCP forbids this.
So QUIC aims to solve this by replacing the TCP part with a UDP based protocol that guarantees delivery at a stream level rather than a connection level. This could have been done by enhancing TCP but that’s so embedded into lots of servers, clients, operating systems, network infrastructure... etc. that it was easier to build upon UDP instead. Eventually learnings from this might be incorporated into TCP. Until then QUIC allows quick experimentation and innovation as UDP is very, very light and any additions to it (e.g. delivery guarantees) are basically implemented in the user-space land rather than lower level internals where it can’t be upgraded. QUIC will likely eventually be used for protocols other than HTTP but for the moment that’s it’s primary use case.
So QUIC effectively replaces the TCP part, but it also needs to change the lower level parts of HTTP/2 which means it also needs to implement the in between TLS part. The best diagram for explain it’s place is this diagram (taken from this presentation):
I have previously been successful in running HTTP1.1 with QUIC.
I seriously doubt this. As per above explanation QUIC only makes sense over a multiplexed protocol like HTTP/2. Perhaps Chrome used to call it QUIC rather than HTTP/2 + QUIC but it would always have been using HTTP/2 (or its similar predecessor SPDY).
Also HTTP/2 really only changes how the messages are sent on the wire. At a higher level, as used by web developers and users, it often acts the same way as HTTP/1.1 with the same verbs (GET, POST... etc.) and HTTP Headers (mostly). So since QUIC just improves how those HTTP/2 messages are sent on the wire, rather than the higher level “HTTP” protocol it really doesn’t make sense to discuss or measure how HTTP/1.1 over QUIC (if it did exist) would differ from HTTP/2 over QUIC - since HTTP/1.1 over QUIC would basically become HTTP/2 over QUIC.
Finally when QUIC has completed standardisation (as opposed to the non-standard Google QUIC version often called gQUIC), it will use a modified version of HTTP/2 which will be called HTTP/3. For now browsers will only use gQUIC and HTTP/2.
If you want a quick test, head to https://http3.is.
It’s a test website created by fastly.
I saw that SCTP is going to be used for Data Channels starting in Chrome 31, and officially RTP based channels are going to be deprecated sometimes in February 2014 according to this google group thread:
https://groups.google.com/forum/#!topic/discuss-webrtc/y2A97iCByTU
Does this also mean that webrtc audio and video channels are also going to be transported over SCTP eventually(if not already in the works)?
How does RTP fit in the whole SCTP transport effort? Does that mean SRTP packets will flow over SCTP data channel? Or perhaps just the payload will be sent over SCTP transport protocol.
If I am reading info on SCTP, it combines best of TCP and UDP protocols; but it does not include encryption by default; so in mind the traffic flowing over should still be encrypted.
Any additional info would be helpful. Thanks!
The audio and video will keep going over RTP (actually SRTP which is the secure version or RTP) but the data channel will uses SCTP over DTLS over UDP. Both Firefox and Chrome are implementing this and you can find it described in the IETF draft specifications. For some types of NAT / Firewall traversal, the UDP packets may get tunneled in TURN over TCP.
Glad to provide you pointers to the draft specifications if that helps.
SCTP stands for Stream Control Transmission Protocol.
SCTP as a protocol can be seen as a hybrid of UDP and TCP.
At its core, SCTP holds the following characteristics:
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC
Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not
Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not
Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent
Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested
SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.
Google is experimenting with the QUIC protocol as a future replacement to SCTP
I'm going to implement Java VoiP server to work with WebRtc. Implementation of browser p2p connection is really straightforward. Server to client connection is slightly more tricky.
After a quick look at RFC I wrote down what should be done to make Java server as browser. Kindly help me to complete list below.
Implement STUN server. Server should be abke to respond binding
request and keep-alive pings.
Implement DTLS protocol along with DTLS handshake. After the DTLS
handshake shared secret will be used as keying material within SRTP
and SRTCP.
Support multiplexing of SRTP and SRTCP stream. SRTP and SRTCP use
same port to adress NAT issue.
Not sure whether should I implement SRTCP. I believe connection will
not be broken, if server does not send SRTCP reports to client.
Decode SRTP stream to RTP.
Questions:
Is there anything else which should be done on server-side ?
How webRtc handles SRTCP reports ? Does it adjust sample rate/bit
rate depends on SRTCP report?
WebRtc claims that following issues will be addressed:
packet loss concealment
echo cancellation
bandwidth adaptivity
dynamic jitter buffering
automatic gain control
noise reduction and suppression
Is is webRtc internals or codec(Opus) internals? Do I need to do anything on server side to handle this issues, for example variable bitrate etc ?
The first step would be to implement Interactive Connectivity Establishement (RFC 5245). Whether you make use of a STUN/TURN server or not is irrelevant, your code needs to issue connectivity checks (which use STUN messages) to the browser and respond to the brower's connectivity checks. ICE is a fairly complex state machine, but it's doable.
You don't have to reinvent the wheel. STUN / TURN servers are external components. Use as they are. WebRTC source code is available which you can use in your application code and call the related methods.
Pls. refer to similar post - Server as WebRTC data channel peer
I saw that SCTP is going to be used for Data Channels starting in Chrome 31, and officially RTP based channels are going to be deprecated sometimes in February 2014 according to this google group thread:
https://groups.google.com/forum/#!topic/discuss-webrtc/y2A97iCByTU
Does this also mean that webrtc audio and video channels are also going to be transported over SCTP eventually(if not already in the works)?
How does RTP fit in the whole SCTP transport effort? Does that mean SRTP packets will flow over SCTP data channel? Or perhaps just the payload will be sent over SCTP transport protocol.
If I am reading info on SCTP, it combines best of TCP and UDP protocols; but it does not include encryption by default; so in mind the traffic flowing over should still be encrypted.
Any additional info would be helpful. Thanks!
The audio and video will keep going over RTP (actually SRTP which is the secure version or RTP) but the data channel will uses SCTP over DTLS over UDP. Both Firefox and Chrome are implementing this and you can find it described in the IETF draft specifications. For some types of NAT / Firewall traversal, the UDP packets may get tunneled in TURN over TCP.
Glad to provide you pointers to the draft specifications if that helps.
SCTP stands for Stream Control Transmission Protocol.
SCTP as a protocol can be seen as a hybrid of UDP and TCP.
At its core, SCTP holds the following characteristics:
Connection oriented. Similar to TCP, SCTP is connection oriented. It also offers a multi-homing capability that isn’t used by WebRTC
Optional reliability. Reliability is optional in SCTP and is up to the implementer using SCTP to decide if he needs this capability or not
Optional ordering. Ordering of packets sent via SCTP is optional and is left for the implementer to decide if this is necessary for him or not
Message oriented. SCTP makes sure that each message sent is properly parsed on the receiver end in the same manner in which it was sent
Flow control. Similar to TCP, SCTP provides a flow control mechanism that makes sure the network doesn’t get congested
SCTP is not implemented by all operating systems. In such cases, an application level implementation of SCTP will usually be used.
SCTP is used in WebRTC for the implementation and delivery of the Data Channel.
Google is experimenting with the QUIC protocol as a future replacement to SCTP
WebRTC DataChannels use SCTP. Looking at the graph of bits received from chrome://webrtc-internals, there is a regular sending of a small amount of data. Is this the SCTP heartbeat?
From what I understand, this is the ICE heartbeat.
I am just elaborating Sam's answer.
WebRTC DataChannel uses Stream Control Transport Protocol (SCTP) for sending
and receiving arbitrary data. Since, WebRTC requires that all WebRTC traffic be
encrypted, DTLS is used. However, most routers and NAT devices don't handle this
protocol well. Hence, SCTP is tunneled over DTLS and UDP. Now, even when two
peers are exchanging arbitrary data, it is happening over UDP. Hence, I too
believe that it is not a SCTP heartbeat.
As you might know, RTCPeerConnection uses ICE for resolving connectivity issues between
peers. ICE uses STUN keep-alives to check the connectivity status between
the peers. Currently, I believe chrome sends out STUN Binding Request every 450 ms to perform connectivity checks, but there is an ongoing discussion on extending that time interval.