The two "application data" records at the bottom are what would wrap around a request/response for an established connection - you can see how much is added to make the strings "ping" and "pong" (though some of that is padding to expand it to a multiple of 16 bytes).
And much of the rest of the records might go away completely if the session were resumed from the client's memory (this wasn't demonstrated here).
Unrelated but: based on your understanding of establishing a TLS session with a server, and then traffic through that connection, do you think the new Gmail user interface for the web (desktop) is sufficiently speedy?
The reason I ask in this thread is that this thread treats some of the low-level minimum traffic necessary between clients and servers.
The TLS overhead is pretty negligible for gmail. Even though there are a lot of steps here it is only 2 round trips for the handshake. Gmail will also use TLS 1.3 (this is 1.2) if your browser supports it which cuts that down to one round trip.[0]
Gmail was using TLS since day 1. If it's slow for you the first likely culprit is the sheer weight of Javascript and DOM work, followed by making more web requests than necessary.
>the sheer weight of Javascript and DOM work, followed by making more web requests than necessary.
can you (or anyone) put this into quantitative terms? How much are we talking about here? I realize this is a bit off-topic, but the topic is "every byte explained", so I think the people who are interested are in the right place to discuss it.
You can see a lot of what's going on with a e.g. DevTools in Chrome. Right click -> inspect
You'll want to go to the performance tab, and then record and reload the page (ctrl-shift-e). For me, about 3/4ths of the time is spent 'scripting' which is 'JS and DOM work'.
It's not terribly enlightening, though, because all the JS is minified and takes some work to understand.
A ping is very much different. A ping is (typically) simply an ICMP Echo Request, (not TCP, thus no TLS, etc). The receiving device, if accepting echo requests and configured to reply with echo replies, then responds with an ICMP Echo Reply - or some device in the middle (or the device itself could respond with an ICMP unreachable, or some other response - or quite simply drop the ICMP Echo Request entirely and silently).
*Edited an incorrect UDP reference out based on the below comment.
Ahh yeah - good call. Totally different protocol.
I guess ICMP more closely resembles UDP at the end of the day, but you're absolutely right. I edited out the incorrect UDP reference so that a person reading for the first time will not get misled. Thanks!
Which is also why some poorly configured network devices firewalls will eat pings - if they for example whitelist tcp and udp protocols and drop everything else (yes, that's a bad idea).
