4 ms·

That size difference is large enough to make a difference in the number of round trips required (should be roughly one fewer roundtrip with any sensible modern

by jsnell 2y ago

That size difference is large enough to make a difference in the number of round trips required (should be roughly one fewer roundtrip with any sensible modern value for the initial congestion window). Won't be a 2.5x difference, but also not 0.001%.

BugsJustFindMe 2y ago
You don't need a new roundtrip for every packet. That would be devastating for throughput. One vs two vs three file packets get acked as a batch either way, not serially. Also when you get to the end, you then see > The actual savings here are moderate: the original is 88 KiB with gzip, and the WebP one is 83 KiB with gzip. In contrast, Brotli would provide 69 KiB. At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, one just has a bunch of extra overhead added for the extra JavaScript fetch, load, and execute. The time saved here is going to be negligible at best anyway, but there looks to be actually negative because we're burning time without reducing the number of needed packets at all.
- jsnell 2y ago
  Those numbers are for a different page. For the original page, the article quotes 44 kB with this method vs. 92 kB for gzip. > At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, What? No, they absolutely don't transmit the same number of packets. Did you mean some other word?
  - codetrotter 2y ago
    They were probably thinking of the max size for packets in TCP, which is 64K (65535 bytes). However, Ethernet has a MTU (Maximum Transmission Unit) of 1500 bytes. Unless jumbo frames are used. And so I agree with you, the number of packets that will be sent for 69 KiB vs 92 KiB will likely be different.
    - deleted 2y ago
      [deleted]
  - mananaysiempre 2y ago
    I expect what GP meant is the default TCP window size, so in a situation where bandwidth costs are dwarfed by roundtrip costs, these two cases will end up taking essentially the same time, because they will incur the same number of ACK roundtrips. Don’t know if the numbers work out, but they at least sound plausible.
    - BugsJustFindMe 2y ago
      Yes, sorry
    - jsnell 2y ago
      No, there is no way the numbers would work out to the same number of roundtrips. The sizes are different by a factor of 2.5x, and the congestion window will only double in a single roundtrip. The only way the number of roundtrips would be the same is if both transfers fit in the initial congestion window.
pierrec 2y ago
Interesting, how does that add a round trip? For the record here's what I believe to be the common definition of an additional "round trip", in a web development context: - client requests X - client gets X, which contains a reference to Y - therefore client requests Y So you're starting a new request that depends on the client having received the first one. (although upon closer inspection I think the technique described in the blog post manages to fit everything into the first response, so I'm not sure how relevant this is)
- jsnell 2y ago
  Unless a resource is very small, it won't be transmitted in a single atomic unit. The sender will only send a part of it, wait the client to acknowledge having received them, and only then send more. That requires a network roundtrip. The larger the resource, the more network roundtrips will be required. If you want to learn more, pretty much any resource on TCP should explain this stuff. Here's something I wrote years ago, the background section should be pretty applicable: https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-downloads/ https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-do...
- 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]

by jsnell 2y ago

BugsJustFindMe 2y ago

You don't need a new roundtrip for every packet. That would be devastating for throughput. One vs two vs three file packets get acked as a batch either way, not serially. Also when you get to the end, you then see > The actual savings here are moderate: the original is 88 KiB with gzip, and the WebP one is 83 KiB with gzip. In contrast, Brotli would provide 69 KiB. At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, one just has a bunch of extra overhead added for the extra JavaScript fetch, load, and execute. The time saved here is going to be negligible at best anyway, but there looks to be actually negative because we're burning time without reducing the number of needed packets at all.

jsnell 2y ago
Those numbers are for a different page. For the original page, the article quotes 44 kB with this method vs. 92 kB for gzip. > At 69 KiB you're still over the default TCP packet max, which means both cases transmit the same number of packets, What? No, they absolutely don't transmit the same number of packets. Did you mean some other word?
- codetrotter 2y ago
  They were probably thinking of the max size for packets in TCP, which is 64K (65535 bytes). However, Ethernet has a MTU (Maximum Transmission Unit) of 1500 bytes. Unless jumbo frames are used. And so I agree with you, the number of packets that will be sent for 69 KiB vs 92 KiB will likely be different.
  - deleted 2y ago
    [deleted]
- mananaysiempre 2y ago
  I expect what GP meant is the default TCP window size, so in a situation where bandwidth costs are dwarfed by roundtrip costs, these two cases will end up taking essentially the same time, because they will incur the same number of ACK roundtrips. Don’t know if the numbers work out, but they at least sound plausible.
  - BugsJustFindMe 2y ago
    Yes, sorry
  - jsnell 2y ago
    No, there is no way the numbers would work out to the same number of roundtrips. The sizes are different by a factor of 2.5x, and the congestion window will only double in a single roundtrip. The only way the number of roundtrips would be the same is if both transfers fit in the initial congestion window.

pierrec 2y ago

Interesting, how does that add a round trip? For the record here's what I believe to be the common definition of an additional "round trip", in a web development context: - client requests X - client gets X, which contains a reference to Y - therefore client requests Y So you're starting a new request that depends on the client having received the first one. (although upon closer inspection I think the technique described in the blog post manages to fit everything into the first response, so I'm not sure how relevant this is)

jsnell 2y ago
Unless a resource is very small, it won't be transmitted in a single atomic unit. The sender will only send a part of it, wait the client to acknowledge having received them, and only then send more. That requires a network roundtrip. The larger the resource, the more network roundtrips will be required. If you want to learn more, pretty much any resource on TCP should explain this stuff. Here's something I wrote years ago, the background section should be pretty applicable: https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-downloads/ https://www.snellman.net/blog/archive/2017-08-19-slow-ps4-do...
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]