For those you are wondering, this is a webserver that serves an HTML page in a single TCP packet. I guess ≤ 1500 bytes to avoid fragmentation - shows as 1.1KB in Chrome's network view. The HTML contains embedded JavaScript that runs a simple demo with animated ASCII and playing a LOUD changing audio tone.
Sure but on the actual internet how often are IP headers larger than 20 bytes because options are turned on? Not very often. The 20 bytes each for TCP and IPv4 is a pretty good assumption.
From the paper "IP Options are not an option" which is good quick read:
"We have studied the dependability of IP options-enabled
network packets in the Internet. We found that overall, approximately half of Internet paths drop packets with options"[1]
Sure I know how to view them. I guess the commenter meant the HTTP headers for just this site were 63 bytes. I thought they were speaking on average like they were for 40 bytes for TCP/IP headers.
This would be really great without the audio. Due to the sound of the audio my initial reaction is to be fascinated, followed immediately by discomfort.
Pro-tip: If you are doing additive synthesis and want to stack sine-waves in a harmonic series, please scale each successive n harmonic to an amplitude of 1/n. It creates a much more tolerable experience.
Interesting to see DEFLATE over GZIP here, as it is something I used to recommend maybe 7 or so years ago. I collected results for several years and began seeing more browsers dropping support for raw deflate (or switching to zlib deflate).
I accidentally let my hosting account expire years ago and lost the server code and db for it, but managed to pull the HTML from the way back machine. I've backed up the results here: https://davidmurdoch.com/compression-tests-results/. It's all pretty outdated now, but rather fun to look at.
Anyone know if this is using raw DEFLATE or ZLIB (HTTP 1.1 DEFLATE)?
HTTP/1.1 200 k
Content-Length: 1163
content-encoding: deflate
I guess the '200 k' instead of '200 OK' saves an extra byte! :)
However, since they don't do any HTTP keep-alives (the connection sends a HTTP response and closes before you even send it anything), couldn't they save some space by dropping the Content-Length? It's an optional header.
True, their server should be returning HTTP/1.0. It's a shame that you can't get away with replacing the initial HTTP/1.0 with HTTP/1 and shave off another couple of bytes :)
Edit: I wonder if you could go full retro and just return a HTTP/0.9 response (no HTTP headers at all, just the page contents). If they then put back the DEFLATE/GZIP header bits, perhaps a browser would spot that the contents are compressed and do the decompression...
It's still pretty sad that so many roundtrips are necessary...
One could imagine a merged DNS and TCP syn packet, which goes to a DNS server who converts it to a TCP packet, and gets forwarded to the origin server.
They spend nearly 75% of the page weight on that party parrot image - if they dropped that, the rest of the page could probably be a lot more impressive (and less screechy!)
Probably the two round trips. A semi-nearby server might be 50ms per round trip, and in that case any connection beating 1mbps can transfer 14KB in less than two round trips. A server could easily be 150-250ms away and make those round trips far worse.
Some routers might only buffer 1 millisecond of line-rate data or less. If that's the case, that initial congestion window of 10 could overflow the buffer, causing loss and a much more costly double-round-trip to resend.
1 millisecond of buffering is geat on a high speed core link. But if you apply that to a 5 megabit connection you've basically decided you'll only buffer one packet. A slow-speed bottleneck link needs to have more capacity. The charts in http://www.nctatechnicalpapers.com/Paper/2011/2011-right-siz... suggest that 64KB is often a good buffer size for end links, and that can absorb 10 packets fine.
They are producing a waveform that is constantly at the peak range of the digital-to-analog conversion. Most real-life audio recordings only very rarely, if ever, reach peak levels.
Some (older?) Hi-Fi equipment was in fact designed with this assumption and playing a constant sine wave at peak levels would very quickly burn something out.
You can visit the demonstration website here: http://packet.city/
You can see a screenshot of the demo here: http://www.p01.org/128b_raytraced_checkboard/