The first 100ms to 160ms of the Yahoo call is RTB[1] delay. I don't see how HTTP/2 will fix that. Also notice all the various analytics beacons that will still be third party in the future. I know many people hate this stuff but when you're Yahoo! and most of your income is from advertisements on your web site you will still have to sell that inventory and prove to third parties they got what they paid for via various "pixels".
I don't doubt there is a lot of room to improve, clearly a lot was learned from SPDY and other projects. But I do worry that what we're actually doing is rewarding large companies who can bring all the stuff into one stream and the small sites will be yet more disadvantaged. I could see a world where this is used as a way for PHB's[2] to justify "just move our stuff to Google/Amazon/Apple". These sort of initiatives may incentivize more centralization and IMHO that is not a good thing.
Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. Before you explode on that comment think about the balance of JSON -vs- various binary serialization solutions. How many of us have chosen a serialization protocol because "we can read it". I'm not arguing that as a perfect argument, but if you're already pushing TLS and HPACK then why not at least leave the textual data in there? I guess I worry that now we head down the RFC hell where only large bodies can get extensions in the protocol because we only have 256 options on this header and each bit counts. To be fair I've not deep dove the protocol yet, I suppose theses are just rantings of a guy who read a slide show.. :)
> Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way.
This is definitely a loss. It's real, it's unfortunate. But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it.
The actual problem here is that HTTP/2 is highly stateful. Connection state, stream state, and header compression state are all required to actually reliably debug a HTTP/2 flow. In practice, that means either your HTTP/2 implementation needs to be able to dump its state, or you need to capture the entire session to understand it.
For my part, I will not mourn the ability to telnet to a port and type HTTP. In practice, that approach lacks value in most modern cases. However, I will mourn the loss of tcpdump as a single HTTP debugging tool. Your implementations now need to make debugging possible in their own right.
> But the binary-vs-text change is actually pretty minor: a well-crafted binary protocol permits simple tools that can be used to debug it.
I think the fundamental change is that, given a classic Internet protocol, I can look at it and learn how it works without having to already have a tool to understand it. I can look at a stream of POP, SMTP, HTTP, FTP, IRC, NNTP, IMAP... the list really does go on and on... and even if I've never seen the protocol before, even if I don't know what the protocol is called, I can sort of figure out how to speak it.
The downside, of course, being that people then think they can speak these protocols, and build horrible "almost sort of" clients for them that fail to interoperate correctly :/. BUT, there is still this interesting egalitarian concept that these protocols are designed for people in some very real way. I love network protocols. I've implemented a ton of them over the years. I got into them at a very young age. Part of the reason why I got into them is because they were just so darned accessible. It makes me a little sad to see this aspect go away.
I don't doubt there is a lot of room to improve, clearly a lot was learned from SPDY and other projects. But I do worry that what we're actually doing is rewarding large companies who can bring all the stuff into one stream and the small sites will be yet more disadvantaged. I could see a world where this is used as a way for PHB's[2] to justify "just move our stuff to Google/Amazon/Apple". These sort of initiatives may incentivize more centralization and IMHO that is not a good thing.
Also being an old guy(tm) I worry about loosing the ability for humans to talk to these services or see the conversation in a textual way. Before you explode on that comment think about the balance of JSON -vs- various binary serialization solutions. How many of us have chosen a serialization protocol because "we can read it". I'm not arguing that as a perfect argument, but if you're already pushing TLS and HPACK then why not at least leave the textual data in there? I guess I worry that now we head down the RFC hell where only large bodies can get extensions in the protocol because we only have 256 options on this header and each bit counts. To be fair I've not deep dove the protocol yet, I suppose theses are just rantings of a guy who read a slide show.. :)
[1] http://en.wikipedia.org/wiki/Real-time_bidding [2] http://en.wikipedia.org/wiki/Pointy-haired_Boss