Many thanks to those of you that responded with Netflix details (special thanks to Volcker for sending me the packet capture). Immediately after someone mentioned firewalls, I knew what the most sensible answer should be: to get across almost anything, use HTTP. No surprise, Netflix chose to use it. However, they’ve managed to deploy streaming video over TCP, which is not a trivial task. So, how did they do it?

The first trick is relatively easy: instead of streaming the whole content, the player reads smaller chunks of video files from the server. If the next chunk is downloaded before the previous one is completely played, you have an uninterrupted viewing experience.

They encode the chunks in the URL. They could have used the Range HTTP headers, but obviously decided to go with a more straightforward approach.

The next trick is the variable bit rate: they can switch between different encodings of the same content on-the-fly, making it easy to adapt to bandwidth fluctuations. You can view different video sources being fetched for the same movie in the summary of capture I’ve received.

The content is hosted within Level-3 network. I checked the IP address of the CDN server in the capture with ARIN WHOIS, but even the HTTP response headers tell the whole story:

HTTP/1.1 200 OK
Cache-Control: no-store
Pragma: no-cache
Content-Type: video/x-ms-wmv
ETag: "e8020c2-36c741-45f94afbc62c0"
Last-Modified: Sat, 03 Jan 2009 14:15:15 GMT
Accept-Ranges: bytes
Server: Level-3 Origin Storage/1.0
Date: Mon, 13 Jul 2009 18:50:59 GMT
Content-Length: 24
Connection: keep-alive

To summarize: nothing revolutionary (but you wouldn’t expect new protocols in residential environment where you have to keep a tight control on the support costs), but a lot of good ideas and sound engineering. I’m impressed.