A bank portal waterfall shows the TLS handshake taking most of the load time while the HTML document itself stays tiny. Which part of the waterfall explains the delay?
Select an answer to reveal the explanation.
Short Explanation
A long greeting at the door can delay you even when the note inside is only a few lines. The TLS handshake that fills the waterfall is the delay, and the tiny HTML document is not the bulk of the time. A WAN loss alarm, a hijack conclusion from the setup, or a QoS change because the HTML is small misreads which bar is long.
Full Explanation
In this waterfall the TLS handshake occupies most of the load time and the HTML document is tiny, so the delay is the handshake rather than the size of the page body. That reading follows the bar that is actually long. A loss alarm on the WAN circuit sitting in front of the banking portal would explain dropped traffic on the path, and a dominant handshake with a tiny document is not the same evidence as loss. A DNS hijack conclusion drawn from the long connection setup time treats handshake time as proof that the name was captured, and a hijack is about where the name resolves, not about how long the TLS negotiation takes once the connection is underway. A QoS change that reprioritizes portal traffic because the HTML is small acts on marking or scheduling because the document is small, which inverts the waterfall: the HTML is not where the time went. Exam caveat: the long bar is the TLS handshake, so do not relabel it as WAN loss, a DNS hijack, or a QoS change prompted by the small HTML document. Operational check: expand the portal request, confirm the handshake bar is the long segment and the HTML transfer is short, and leave WAN loss, hijack, and QoS actions for evidence that matches those causes.