SPDY For iOS

It has come to my attention that work is being done (3rd party) to bring SPDY to iOS. Awesome!

However, I can’t help but think that Apple is already working to bring SPDY to iOS perhaps as soon as iOS 6. I say this simply because it would bring a speed improvement without involving more Tx/Rx or upping CPU power consumption. It just improves network utilization. In fact since it improves utilization it possibly could improve battery life by reducing the radio usage.

I’d also like to see the Nitro JavaScript engine available outside of Safari so UIWebView implementations could take advantage. Supposedly that’s a WebKit2 thing, but I’ve heard/seen little of WebKit2. I suspect SPDY will happen first.

7 thoughts on “SPDY For iOS

  1. I do hope Apple does do a SPDY implementation. However, after working on the server side of SPDY before, my fear is that Apple would hold back on SPDY until they have the server side done as well.

  2. That’s great news. Assuming that Safari & QuickTime player on iOS would have access to SPDY, I’m predicting some interesting improvements to MPEG-TS (Apple HTTP Live Streaming) delivered video.

    Cool.

    • I don’t think you’d see much improvement for video streaming. SPDY’s main benefits are for multiple requests (doesn’t apply) and compressed headers (video doesn’t have that problem either). In fact, I’m skeptical anyone would even serve video over SPDY. It would likely use more resources with no gain.

      • Have a closer look at MPEG-TS streaming.

        There is, under Apple recommendation, no one request for one video quality. Rather each video quality “stream” is broken up into many small clips (1-5s in length). And the client decides what quality it wants to use, and switches qualities on the fly depending on how the bandwidth is working out.

        This is true for both on-demand and live video.

        Example:
        – one source
        – 10s video
        – encoded at four different qualities
        – 96kbps
        – 256kbps
        – 512kbps
        – 1024kbps
        – 2s segment length

        …results in 20 MPEG-TS video files + 5 M3U8 index files.

        While not all of those files will be called, the client will be, at least in the beginning, making multiple calls to discover what qualities are available, what the files are called, and various media files depending on the bandwidth.

        I could see a benefit of SPDY in this context, if I’m not missing anything.

      • You still likely wouldn’t see any real benefit in quality. Perhaps a slightly quicker start over mobile connections.

        Besides. You should really be using RTMP or UDP as TCP if you’re trying to get the most for your bandwidth. The main benefit of HTTP is ease of setting up and scaling servers at the expense of quality and speed.

        Lastly, it’s a handful of requests made by the media client, not the browser. The media client tends to be well tuned to take advantage of the connection. It’s a very different world than web browsers.

  3. RTMP and iOS don’t mix. Apple has embraced the HTTP route.

    Another huge, huge benefit of HTTP streaming is firewall transversal. The sad fact is getting RTMP, RTSP, et al past corporate firewalls is problematic.

    As to your final point, do not many media clients outsource their request handling to browser?

Leave a Reply

Your email address will not be published. Required fields are marked *