3 ms·
In reality it's more like: - client requests X - server sends bytes 0-2k of X - client acknowledges bytes 0-2k of X - server sends bytes 2k-6k of X -
by crote 2y ago
In reality it's more like:
- client requests X
- server sends bytes 0-2k of X
- client acknowledges bytes 0-2k of X
- server sends bytes 2k-6k of X
- client acknowledges bytes 2k-6k of X
- server sends bytes 6k-14k of X
- client acknowledges bytes 6k-14k of X
- server sends bytes 14k-30k of X
- client acknowledges bytes 14k-30k of X
- server sends bytes 30k-62k of X
- client acknowledges bytes 30k-62k of X
- server sends bytes 62k-83k of X
- client acknowledges bytes 62k-83k of X
- client has received X, which contains a reference to Y
- therefore client requests Y
It's all about TCP congestion control here. There are dozens of algorithms used to handle it, but in pretty much all cases you want to have some kind of slow buildup in order to avoid completely swamping a slower connection and having all but the first few of your packets getting dropped.
- deleted 2y ago[deleted]
- notpushkin 2y ago> client acknowledges bytes 0-2k of X Doesn’t client see reference to Y at this point? Modern browsers start parsing HTML even before they receive the whole document.
- Timwi 2y agoNot just modern. This was even more significant on slow connections, so they've kind of always done that. One could even argue that HTML, HTTP (specifically, chunked encoding) and gzip are all intentionally designed to enable this.
- account42 2y agoChunked encoding is required for the server to start sending the document before it has been fully generated (or the size becomes known) but nothing stops the client from parsing not yet complete documents without it.