Ultrafast single TCP packet audio/visual experience | Hacker News Reader

Ultrafast single TCP packet audio/visual experience

github.com

265 pointswilllll75 comments

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.

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/

Caution: loud

Opened this on my phone with headphones. I had an heartattack.

Counts as experience :)

Branded with bleeding ears. Dolby.

So they're using p01's effect and they want to put ADs around it?

Here's hoping it's a joke. ;- )

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.

Over the last 5 years I've learnt to set the default sound level on my computer to "mute"

one settings I'd like to have is "unmute for the next 15 minutes" to be able to hear a funny vid without forgetting to reset it back to muted

You can also set your browser windows to automatically mute on chrome. I think in high sierra macOS will do it by default.

The limit is 1460 - the IP and TCP headers occupy 40 bytes.

Out of those another 63 are consumed by the HTTP headers.

The full TCP payload is only 1226 bytes though, and the full HTTP payload 1163 bytes. The decoded HTML document is 1546 bytes.

>"Out of those another 63 are consumed by the HTTP headers"

I am curious how you ended up at 63 for that, can you elaborate?

Viewed the http headers and counted?

Which you can do with curl, Chrome/Safari/FF dev tools, and lots of other tools besides.

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.

IP header has flexible size, up to 60 bytes: https://networkengineering.stackexchange.com/questions/6855/...

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]

[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/2005/EECS-2005-...

Thanks, that's good to know. I've wondered if these options are used in the past.

Wow how'd it autoplay audio on my mobile chrome

That audio demo is CRAZY loud. I had my headphones on my desk since I'm on the phone and thought it was playing music through my laptop speakers.

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.

also maybe the title could have [LOUD!!!] or something like that. I didn't realize my system could make a noise that loud with vol at 50%.

I set my system's volume to the lowest possible value before mute (1/64) and it was still extremely loud and unpleasant. I'm actually impressed.

Further reading: https://en.wikipedia.org/wiki/Fletcher–Munson_curves

Hi, this website is really loud and if you are using Headphones I would mute it or turn them down a bunch. It also will autoplay the sound.

ultrafast and ultra annoying.

...it did say "audio/visual" 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)?

Response headers:

   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.

Not unless they switch to http/1.0. in 1.1 you need one of: content length, connection close, chunked encoding.

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

http://packet.city/

summary: A demo scene page that is smaller than a single IP frame and uses some flags to avoid other round trips.

view-source:http://packet.city/

The page itself and view-source only work on some browsers. Use wireshark etc to see what it actually does.

Wiresharked the thing. Here's the packet sequence it reported:

    -> DNS query A
    -> DNS query AAAA
    <- DNS reply A
    <- DNS reply AAAA
    -> TCP SYN
    <- TCP SYN,ACK
    -> TCP ACK
    -> HTTP GET
    <- HTTP reply <= That's the content!
    -> TCP ACK
    <- TCP FIN,ACK
    -> TCP FIN,ACK
    <- TCP RST
    <- TCP RST

So, the full traffic is 14 packet, all small (DNS, TCP handshaking) except the one HTTP reply packet containing the full website.

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.

>the greatest website to ever fit in a single TCP packet

a blank page would be an improvement - that was seizure inducing

CAUTION: This is just about popped my speakers and my eardrums, this is pretty obnoxious behaviour regardless of the technical cleverness going on.

Does the high pitched sound make my Amazon Echo order something?

You'll know in a day or two.

This will upset any cat in the vicinity

Confirmed, my cat freaked out.

same here - lol

Cat freakout confirmed

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

Wow, 25% of page weight wasted on extraneous cruft.

Also ultraloud. Turn down the volume before clicking.

Looks like the browser spends most of the loading time resolving DNS.

The website should fit in the DNS response.

Get a better DNS server... 4.2.2.2 or 8.8.8.8 are good choices.

What is it? Nothing happens on mobile Safari.

Nor mobile chrome.

Guess I'll have to check it out later.

Works for me in mobile Chrome 63 and in mobile Firefox 55.

My cat had opinions about the sound this website makes.

Nice work. I guess it'd just as quick if it sent up to ~4kB - that's the normal TCP initial window? https://tools.ietf.org/html/rfc3390

At least in Linux, ICWND is set to 10 now: https://tools.ietf.org/html/rfc6928

Hm. I what the distribution of latency vs bandwidth is like, whether 14kB or 2 round trips takes longer for most people?

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.

It also depends on the buffer size.

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.

All hail the rise of the Single Packet Web App.

Wanted: Web developer with 10+ years SPWA experience.

How is it that loud? It's not tolerable even on minimum settings on my iMac.

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.

Tip: Shift + Option + Volume(up/down) adjusts volume by 1/4 of a bar.

Wow. I have been using OS X for quite a long time and this is the first i'm hearing of it! Thanks!

Holy crud! That's so hidden

Wow! How did you learn that?

Desktop Safari: Can't find variable: AudioContext

No room for vendor specific prefixes :|

Why is the tcp socket set to busy poll for 1 microsecond?

Web Scale?

Now I'm curious, could one minimize this further? As in, making Chrome accept UDP to get rid of SYN/ACK etc.

Been years since I went through Beej's socket programming tutorial but I still recognize his code ;)

Nice. I was just reviewing some TCP fundamentals with my friend for his class, specifically sliding windows and window control, etc.

It's as if they took what we were just reading in a compsci textbook for class and directly monetized it.

It might be fast but does it handle load? Did you try to benchmark it with a service like https://ddostest.me

Is there a breakdown of the expanded HTML/JS?

Any direct link? Do I need to build this mofo?

Reply on news.ycombinator.com