Hacker News Reader

Comment by jugg1es | Hacker News Reader

So does this happen for every single request? or is this based on a single session.

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).

Per session.

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.

Sufficiently speedy for what?

It's not clear what you're asking. Gmail obviously runs over TLS. It also seem pretty nippy to me, but TLS only has a minor impact on the speed.

>It also seem pretty nippy to me

OK. (my experience since the redesign is the opposite.)

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]

https://www.cloudflare.com/learning-resources/tls-1-3/

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.

how much time is that for you? How does it compare to another dynamic site such as the one we're on (HN) when you're logged in?

What does TLS have to do with the Gmail redesign? It used TLS before the redesign, didn't it?

It gives a target or minimum for a fast and lightweight secure web application.

This is what happens under the hood of every ping request.

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.

If I'm not mistaken, its not UDP, it's ICMP, like you said

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).

https://security.stackexchange.com/questions/22711/is-it-a-b...

ping would refer to https://en.wikipedia.org/wiki/Ping_(networking_utility) in this context, which is quite unrelated to TLS.

Reply on news.ycombinator.com