How long does the DTLS handshake take?
WebRTC mandates DTLS for encrypting the voice, video and datachannel traffic on the wire. As of Chrome 74 it is possible to measure how much time the handshake takes “in the wild” instead of just the lab. We did so on the Houseparty web client.
The short answer is “about 200 millseconds” for peer-to-peer connections:
DTLS is a variant of the TLS protocol that runs over UDP instead of TCP. In WebRTC it is used (and even mandated) as a way to generate symmetric encryption keys for use in SRTP (see RFC 5764 for the details) as well as encyption of the datachannel (which runs on SCTP over DTLS). The DTLS handshake takes place after ICE has found a path through the NAT maze. How long does this handshake take?
Since Chrome 74 it is possible to measure this in production systems as support for RTCPeerConnection.connectionState was added and the previously incorrect definition of RTCPeerConnection.iceConnectionState (which included the DTLS handshake) was changed accordingly. We can therefore do something along the lines of
let startTime;
pc.oniceconnectionstatechange = () => {
if (pc.iceConnectionState === 'connected') {
startTime = Date.now();
}
};
pc.onconnectionstatechange = () => {
if (pc.connectionState === 'connected') {
console.log('DTLS handshake took', Date.now() - startTime, 'milliseconds');
}
};
rtcstats keeps on being my favorite tool for monitoring this kind of metrics. It measures both the time it takes ICE to connect as well as the time the connection state takes to reach connected. We can simply subtract these two to determine the time DTLS takes. Then it is a matter of running SQL query and visualizing the results:
SELECT
timestamp 'epoch' + date / 1000 * interval '1 second' AS day,
MIN(mediandtls) AS mediandtls, MIN(medianice) AS medianice
FROM (
SELECT date, usingicelite, percentile_cont(0.5) within group ( order by connectiontime) over(partition by date ) AS mediandtls, percentile_cont(0.5) within group ( order by iceconnectiontime) over(partition by date ) AS medianice
FROM rtcstats
WHERE (connectiontime > 0 or iceconnectiontime > 0) and browsername = 'Chrome'
and browsermajorversion > 52 and browsermajorversion < 90
and usingicelite = 'f'
) t1
GROUP BY day
ORDER BY day ASCThe following graph shows the result:
You can see when the definition changed in April as earlier versions of rtcstats measured connectionTime as the time until iceConnectionState became connected. It would have been interesting to see the effect of Chrome changing the definition of iceConnectionState not to include DTLS but we didn’t gather data when this happened earlier this year.
The difference is about 200ms and as Mozilla’s Nils Ohlmeier pointed out this is somewhat confirmed by the data Firefox telemetry gathered (in Firefox 53–59 Beta and Nightly):
Yes, SDES is faster, Hadriel Kaplan told us in 2013. But how many users will notice?
p.s.: while we are talking about DTLS… if you are developing a server make sure you support DTLS 1.2. Chrome tried to remove the fallback to DTLS 1.0 in Chrome 74 but that had to be postponed to Chrome 81 in early 2020 as it caused quite some breakage.
