|
|
Log in / Subscribe / Register

HTTP 2.0 draft available

[Posted July 9, 2013 by corbet]

A "marked for implementation" draft of the HTTP 2.0 protocol specification has been released. "The HTTP/2.0 encapsulation enables more efficient use of network resources and reduced perception of latency by allowing header field compression and multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients."
to post comments

lost opportunity

Posted Jul 9, 2013 16:16 UTC (Tue) by b7j0c (guest, #27559) [Link] (1 responses)

http 1.1 will be the majority protocol until 2020 at least. http 2.0 should seek to take the web beyond that...i don't see a protocol being useful after 2020 if it isn't secure by default. if tls is cheap-enough for major sites to deploy everywhere in 2013 it will also be in 2020

lost opportunity

Posted Jul 19, 2013 0:02 UTC (Fri) by smithj (guest, #38034) [Link]

Chrome and Firefox will implement it fast (like they did with SPDY), and IE and Safari will follow in some subsequent major version. Site developers will be anxious to deploy because it'll dramatically speed up page load and interaction times. Folks are already using mod_spdy with Apache to do the same thing.

Proxies and such might take longer, but they're not the main targets.

HTTP 2.0 draft available

Posted Jul 9, 2013 16:58 UTC (Tue) by bokr (guest, #58369) [Link] (1 responses)

For those who pay by the GB, unsolicited push is unsolicited debit.

That would seem to present a moral hazard, not unlike "sprinkling" in
telephone billing.

Will this form of connectivity be opt-in?

HTTP 2.0 draft available

Posted Jul 9, 2013 17:59 UTC (Tue) by istenrot (subscriber, #69564) [Link]

A client may respond with a "GOAWAY" frame to a server trying to initiate a new stream. So yes, in theory one's client may be in mobile friendly mode by rejecting server initiated streams altogether. I'm still reading the draft, so something more obvious might come up.

HTTP 2.0 draft available

Posted Jul 9, 2013 17:32 UTC (Tue) by jgg (subscriber, #55211) [Link] (24 responses)

So, it is now 2013 and you still can't reliably use HTTP/1.1 features. The origin servers have been fine for years, but proxies (transparent, or otherwise) still mess it up horribly. Squid being a notable offender.

Not sure I have much hope in HTTP/2.0, considering it still has to traverse a transparent proxy designed for HTTP/1.0 and the proxy will still get to screw it up..

HTTP 2.0 draft available

Posted Jul 10, 2013 9:22 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (21 responses)

Well, proxies are not helped a little bit by browsers and specification (HTTP,TLS) writers. It seems a widespread belief among those people that if they screw up intermediary support far enough proxies will just go away. Since proxies serve a real social need the end result is not proxy disappearance but always more extreme hacks to get proxies to work anyway.

It would be all simpler if http/tls/browser authors just acknowledged the reality and wrote/implemented specs which had a chance to be used in a clean way by proxies instead of complaining of the mess they created themselves.

(and HTTP/2 is not likely to change anything since so far it just grandfathers HTTP/1 intermediary problems in a new spec instead of trying to solve them)

HTTP 2.0 draft available

Posted Jul 10, 2013 14:15 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (20 responses)

The HTTP 1.1 specification and its adjuncts are _full_ of vital information for proxy authors, crammed with injunctions and special cases that exist ONLY because of the proxies.

But I can tell you that the two responses from proxy authors are:

1. That sounds like a lot of work. I don't see why I should bother, this half-arsed solution worked pretty well in my tests. If a customer complains I already have their money, I'll tell them to bother the people giving away the free web browser while I laugh all the way to the bank.

2. Sssh. The proxy is _secret_. People aren't supposed to know it's there. I can't obey your specification because it would let people know I am using MitM on them 24/7 and they'd get mad about that.

Literally yesterday I received an enquiry, had we broken the customer services web UI for our multi-million dollar service? Nope. The corporate web proxy had tried to MitM the SSL connection, it had been unable to succeed (apparently incompetence triumphs over evil) and the customer service agent's browser had refused to continue the poisoned connection attempt.

There are probably a dozen or more places where specifications tell them not to do that, but given the choice between obeying and thus putting many extra man hours of work into the product or going home at 4pm on Friday, why wouldn't the developer of the (proprietary) corporate web proxy choose the easy option? Do you think my employers will get back a single cent for the resulting confusion and inconvenience? No. Indeed they will probably try to blame my team, since we should obviously just remove all the security and then the MitM would work perfectly...

HTTP 2.0 draft available

Posted Jul 10, 2013 16:14 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (19 responses)

And do you know why it tried to MITM the connexion? Because right now that's the only semi-reliable way left to setup a proxy. (same thing for captive portals in hotels people like to swear about). HTTP 1.1 proxy authentication and setup is woefully insufficient for modern needs (once you've passed the setup stage proxies work well, but setup is terrible)

After years of blocking progress in the name of some entitlement to direct access to the whole Internet, and scaremongering about bank interception and police states, it just became easier to MITM every access in corporate space rather than try to setup proxies in any other way.

The whole unrestricted end-to-end thing is *stupid* when you're not on your own network. No one would insist any corporate premise (possibly, dealing in life-critical areas such as utilities, hospitals, etc) should be kept wide open with no security to check people going in and out have some business doing so. But in the digital space, that is exactly what end-to-end-with-no-intermediary means. So *of course* corporations are going to break ssl on the network accesses that cross their security boundaries to allow their security to check nothing untowards is going on (usually, just running AV on the stuff their employees download from gods knows where). They'd rather do it nicely via explicit proxy setup the employee agrees to (just like local security is in a nice explicit uniform and not hiding away), but if left no choice, they just MITM.

And police states are delighted by all the of-the-shelf MITM equipment which is currently available on the market because some people couldn't allow proper proxy setup (that didn't need tricking browsers and users).

HTTP 2.0 draft available

Posted Jul 10, 2013 16:33 UTC (Wed) by raven667 (guest, #5198) [Link] (11 responses)

There are several different, valid, strategies for security, one is trying to build the security into the network via firewalls, IDS, MITM, proxies, etc. and the other is to build the security into the end point, leaving the network a dumb pipe just moving packets, with central management to control the device policy, host packet filter, HIDS, AV, etc. Even the crappiest hosts are much much better than what they used to be 10+ years ago, IP stacks have had a ton of engineering to add robustness and resiliency in the face of attack, even your WinXP SP2+ hosts can be put on the internet with appropriate local firewall policies configured.

HTTP 2.0 draft available

Posted Jul 10, 2013 16:52 UTC (Wed) by dlang (guest, #313) [Link] (10 responses)

In theory you can have a secure network with no firewalls, where you put all the security enforcement on the end hosts.

In practice, everyone who has tried this approach has been hacked. The problem is that it's much harder to manage thousands of rulesets than it is to manage the rulesets on one firewall.

now, you can't rely exclusively on firewalls (especially now that the term 'firewall' has been corrupted to just mean a packet filter), but there is a lot of value in providing perimeter defenses in firewalls rather than relying on protection on each individual system

HTTP 2.0 draft available

Posted Jul 10, 2013 19:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (8 responses)

That's my pet peeve.

Firewalls are WORSE THAN USELESS in modern corporate networks. They are easily bypassed and they simply lull into a false sense of security.

Proper network policies belong on the end-hosts. It's just all the current ways of doing that suck immensely.

HTTP 2.0 draft available

Posted Jul 10, 2013 21:05 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

well, part of that depends on how you define "modern corporate networks"

If you are talking about the network that your desktop sits in, I agree. Packet Filtering Firewalls are close to worthless (and almost nobody runs the more secure variety for these sorts of networks)

However, if you are talking about the networks that your banks servers live in, there firewalls (even the flimsy packet filtering ones) can be used very effectively. Packet Filtering Firewalls are not enough, but they are a very important first step.

HTTP 2.0 draft available

Posted Jul 10, 2013 21:15 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

> well, part of that depends on how you define "modern corporate networks"
Basically, anything with WiFi. Once you start using it, your network stops being trusted.

Sure, there is EAP, but nobody uses it.

HTTP 2.0 draft available

Posted Jul 10, 2013 21:48 UTC (Wed) by dlang (guest, #313) [Link] (5 responses)

If you connect Wifi directly to your network you are correct, but if you just create a "gues" Wifi network and then have your devices VPN from that network to your corporate network, Wifi isn't a problem (at least, no more of a problem than all the other untrusted networks users will VPN from)

It's the BYOD (Bring Your Own Device) mentality and the idea that people really need their connections open to see bouncing cows that are the hard things to deal with.

HTTP 2.0 draft available

Posted Jul 11, 2013 0:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

If you are using VPN everywhere then you're already pushing security to individual devices.

HTTP 2.0 draft available

Posted Jul 11, 2013 1:27 UTC (Thu) by dlang (guest, #313) [Link] (3 responses)

only for those devices that are mobile. They need to be hardened because they don't live on firewalled networks to begin with.

HTTP 2.0 draft available

Posted Jul 11, 2013 1:51 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

And normal devices too. A compromised mobile devices serves as a nice beachhead for attackers.

HTTP 2.0 draft available

Posted Jul 11, 2013 2:59 UTC (Thu) by raven667 (guest, #5198) [Link] (1 responses)

If you have to solve the management and security problem for mobile devices anyway then you can treat all your devices that way by default. You have some of the same problem with hosted servers (the cloud), which gets solved by defining local packet filter rules right in the provisioning process.

The idea of having a perimeter is one that may no longer be required in many cases.

HTTP 2.0 draft available

Posted Jul 11, 2013 5:49 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Packet filter rules are increasingly irrelevant in a world where every web site cowboy can try to evade packet filtering by tunneling his pet insecure protocol in an ssl connection on port 443 (Google have been sneaking the whole SPDY thing under firewall rules this way, as did Citrix and lots of other players; see also websockets).

That's why corps deploy ssl MITM boxes and protocol inspection means.

And some people feel that the browser should effectively belong to the web site operator, no the end-user (IIRC some Google? people stated as much a few months ago, before PRISM showed how laughable the whole "web sites are trusted, local IT is dangerous" concept was). When some cloud operators also own the major browsers are you surprised third parties do not trust delegating all network security to the browser?

Endpoint security has already been hopelessly compromised. It has been delegated to browsers but browsers are not neutral anymore (if they ever were). The next logical step is to restore some security intermediation, which means http firewalls (== proxies). And the setup problem is the same whether you run a local desktop proxy (privoxy...) or a LAN/WAN-wide one.

HTTP 2.0 draft available

Posted Jul 10, 2013 19:07 UTC (Wed) by raven667 (guest, #5198) [Link]

> In theory you can have a secure network with no firewalls, where you put all the security enforcement on the end hosts.
> In practice, everyone who has tried this approach has been hacked.

In practice everyone has been hacked, including those with traditional perimeter firewall and IDS, in fact mostly those with traditional setups as they are the most common 8-)

> The problem is that it's much harder to manage thousands of rulesets than it is to manage the rulesets on one firewall.

Managing a large number of hosts is a long standing problem but a ton of work has been put into automation, from puppet and cfengine to Group Policies and other proprietary management suites. There are plenty of server deployments such as for Amazon, Google or Netflix and Windows desktops to show the fundamentals of how to manage large numbers of systems in an automated fashion.

> there is a lot of value in providing perimeter defenses in firewalls rather than relying on protection on each individual system

Perimeter defenses have use when you don't have control of the endpoints but they have downsides as well. The network is fundamentally dumb and the middlebox dosen't know what is happening on the end host without a great deal of protocol inspection that is rarely implemented and so fundamentally doesn't have the information needed to make the most accurate decisions. Also perimeter defense often comes at the expense of host defense and leaves a lack of internal controls to defend against problems on the inside of the perimeter.

I think perimeter defense was absolutely the right thing to do when host security was non-existant but the pendulum has swung the other way now, even crappy appliances are running Linux and have access to the full Netfilter system should they wish it. Your desktop and phone and fancy internet connected thermostat have the same IP stack and filtering capability as your perimeter firewall anyway, it really just comes down to the management issue, the technical problems have been fixed.

HTTP 2.0 draft available

Posted Jul 10, 2013 19:11 UTC (Wed) by wmf (guest, #33791) [Link] (1 responses)

If HTTP 2.0 "allows" corporate MITM proxies, there's a sense that every ISP and government will immediately install them. I don't see a good solution here. There has been some discussion of a super-WPAD that would say "here's your proxy server and seriously, really, it's mandatory to use it" so that at least the user would have to consent to using the proxy; I think that approach has some promise.

HTTP 2.0 draft available

Posted Jul 11, 2013 5:33 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

Unfortunately, and even though everyone in the http wg had to recognize the current situation only leads to generalized MITM-ing, any move to drain the swamp had been postponed yet again with HTTP/2

HTTP 2.0 draft available

Posted Jul 11, 2013 12:57 UTC (Thu) by niner (guest, #26151) [Link] (2 responses)

"No one would insist any corporate premise (possibly, dealing in life-critical areas such as utilities, hospitals, etc) should be kept wide open with no security to check people going in and out have some business doing so."

Well actually this is how most corporate premises work. Only a tiny fraction of companies have their own security. And indeed, where I live, it's absolutely normal to be able to walk into any hospital without seeing any security at all and without getting asked by anyone.

HTTP 2.0 draft available

Posted Jul 11, 2013 13:35 UTC (Thu) by nim-nim (subscriber, #34454) [Link] (1 responses)

I believe this only applies to the public areas, and even there you'll find out there are some cameras feeding your movements to a security room.

(of course the smaller the premise is the less likely it is)

HTTP 2.0 draft available

Posted Jul 20, 2013 11:35 UTC (Sat) by tialaramex (subscriber, #21167) [Link]

Well you can believe whatever weird nonsense you want, and doubtless you will. The universe doesn't care what crazy stuff you believe.

I spent many months as an outpatient at by far the biggest hospital in my city, which is a major port in a powerful European country. I never showed anybody any ID in the entire time I was there (I don't carry any, a hidden privilege of looking like I belong), nor was I issued any sort of pass or token. I went to have X-rays, received prescription drugs, including drugs with a significant street value and others which are deadly poisons, had surgery performed under GA and more minor procedures without. I visited different floors of the main building, including administration and inpatient wards. Nobody once asked for any reason why I was there, the only time anyone showed any interest was when I was lost, and evidently looked it, and they offered directions. No cross-checking, no calling security.

Now I work (well, mostly from home, but when I don't) in a notionally "secure environment" in a building in a city which has an ongoing threat of terrorism, where the security guards are ex-military. In this summer's heatwave I didn't wear a jacket for the last two weeks and thus forgot the pass token that lives in the pocket of that jacket. I tailgated through security without any problem, as do hundreds of other employees every day. The second time I had some spare time, and I thought I'd try to do things by the book instead of tailgating. I went to the front desk, and announced that I had forgotten my pass, could I be issued a temporary one like a visitor? The front desk security person told me his PC had just rebooted itself, and it would take too long to wait for it to work again. So he just opened the nearest door. "All the internal locks are disabled, just walk around until you get to wherever your desk is". Remember, this isn't just some ordinary office building, this is supposedly a "secure environment". But because they've tried to scale it up to hundreds of people it's utterly ineffective.

That's the real world.

HTTP 2.0 draft available

Posted Jul 11, 2013 18:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

BTW, I have once designed a secure boot system with remote attestation for hospital usage. The main reason was that they were seriously worried about people stealing physical servers, from experience.

And I'm not joking.

HTTP 2.0 draft available

Posted Jul 12, 2013 11:54 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

Directly from the HTTP workgroup mailing list:

> The sad state of affairs is that the *only* type of middleware which
> benefits from the proposed HTTP/2 is those which performs transparent
> interception and passive monitoring/recording of users traffic (ie the
> worst kind). Anything which starts modifying or manipulating (ie doing
> something useful for the ISP or CDN) MUST implement a full
> compressor/decompressor pair in order to keep the HTTP/2 statefulness in
> order.

http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulS...

HTTP 2.0 draft available

Posted Jul 15, 2013 8:18 UTC (Mon) by Lennie (subscriber, #49641) [Link] (1 responses)

HTTP/2.0 is based on SPDY and SPDY basically demanded: on the public Internet only use it for HTTPS, this was the increase security, but also to prevent deployment problems.

HTTP 2.0 draft available

Posted Jul 18, 2013 18:21 UTC (Thu) by wmf (guest, #33791) [Link]

SPDY was SSL-only but HTTP/2.0 has an unencrypted mode which brings back all the problems that led to SPDY being SSL-only in the first place.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 9, 2013 19:17 UTC (Tue) by jorgegv (subscriber, #60484) [Link] (13 responses)

This is my first reading of the HTTP 2 draft, and I have become really surprised: its definition pretty much follows the basic definition of a byte-level communication protocol: 1) Framing; 2) Protocol syntax; 3) Multiplexing; 4) Flow control; 5) Quality of service; 6) Control plane traffic and supervision.

I have the feeling that this is a reimplementation of TCP on a TCP connection: three way handshake, flow control, windowing, stream QoS, multiplexing (TCP ports are... IP connection multiplexing!)... the draft even borrows the nomenclature from TCP (and the names of some messages! see PING :-)

I don't see exactly the point of HTTP 2, maybe someone could enlighten me? If the main reason is optimization, wouldn't it be easier to optimize the lower levels instead of reimplementing everything a couple of layers up?

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 9, 2013 20:07 UTC (Tue) by smurf (subscriber, #17840) [Link]

Why not just read the rationale at the document's beginning?

The major problem I have personally with this is that most, if not all, of these problems have already been solved. Just use SCTP as the underlying protocol … well, except for the fact that the number of firewalls out there which can be configured to pass along SCTP is only slightly larger than the number of firewalls which do it by default - a number which is too close to zero to matter. 

   This document addresses these issues by defining an optimized mapping
   of HTTP's semantics to an underlying connection.  Specifically, it
   allows interleaving of request and response messages on the same
   connection and uses an efficient coding for HTTP header fields.  It
   also allows prioritization of requests, letting more important
   requests complete more quickly, further improving perceived
   performance.

   The resulting protocol is designed to have be more friendly to the
   network, because fewer TCP connections can be used, in comparison to
   HTTP/1.x.  This means less competition with other flows, and longer-
   lived connections, which in turn leads to better utilization of
   available network capacity.

   Finally, this encapsulation also enables more scalable processing of
   messages through use of binary message framing.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 9, 2013 22:48 UTC (Tue) by khim (subscriber, #9252) [Link] (5 responses)

I don't see exactly the point of HTTP 2, maybe someone could enlighten me?

The Fundamental Truth #1.

If the main reason is optimization, wouldn't it be easier to optimize the lower levels instead of reimplementing everything a couple of layers up?

In a world where Windows XP released 11 years ago has the market share of some 20-30%? No.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 9, 2013 23:36 UTC (Tue) by wahern (subscriber, #37304) [Link] (3 responses)

Few of those people are going to be able to use HTTP 2.0, either, because browsers have been dropping support for XP for some time. IE dropped it altogether, and Mozilla and Chrome require SP2+.

By the same token, we can kiss IPv6 adoption goodbye if we presume that broken infrastructure will never be upgraded.

WebRTC uses SCTP, albeit atop UDP. Its funny how HTTP 2.0 is being ultra-conservative, while WebRTC perhaps a little too optimistic.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 9, 2013 23:41 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Not 'never' but 'very, very far in the future'.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 10, 2013 8:29 UTC (Wed) by khim (subscriber, #9252) [Link]

IE dropped it altogether, and Mozilla and Chrome require SP2+.

Well, SP2 was released nine years ago, while SP3 which was released measly five years ago is apparently too new to require, so difference is not as big as you want to portray.

By the same token, we can kiss IPv6 adoption goodbye if we presume that broken infrastructure will never be upgraded.

Why? As you've pointed out above "broken infrastructure" is upgraded - it's just now we are at stage where it's upgraded like any other infrastructure: it's not big deal to see someone with ten years old fridge on a kitchen, why should it surprise you when PC in a living room is five years old? Apparently HTTP 2.0 developers wanted something to use here and now, not in 2025.

WebRTC uses SCTP, albeit atop UDP. Its funny how HTTP 2.0 is being ultra-conservative, while WebRTC perhaps a little too optimistic.

Different expectations. When you develop something new you can be "a little optimistic": if it does not work then end-user is no worse then before. If you develop the replacement for something then bar is much, much higher: it has to work at least as well as before for most users. HTTP 2.0 is supposed to replace HTTP 1.x, so guess which way decisions went?

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 15, 2013 0:32 UTC (Mon) by Lennie (subscriber, #49641) [Link]

I thought WebRTC used DTLS, not SCTP but it seems the picture is a bit more complicated than that.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 11, 2013 11:35 UTC (Thu) by davecb (subscriber, #1574) [Link]

Common optimization for everyone at a low level is one of the reasons we have operating systems delivering TCP instead of doing it "mvs style" and making everything an application responsibility.

Of course, one does have to upgrade OSs every century or so (;-))

--dave

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 10, 2013 10:35 UTC (Wed) by gdt (subscriber, #6284) [Link] (3 responses)

I don't see exactly the point of HTTP 2, maybe someone could enlighten me?

Imagine a world where the bottleneck isn't bandwidth, but the latency of the speed of light in glass.

Imagine a world where we have run out of IPv4 addresses and missed the opportunity to deploy larger addresses. A world where NAT is used extensively, where NAT tables are the new DoS target, and thus hosts which open lots of parallel connections are penalised.

HTTP 2.0 is designed to work well in those worlds.

As for the layering argument, it's not like higher or lower layers have magical new tools appear. If you are trying to control resource allocation then you end up with flow control (although I do wonder if the resource allocation problem HTTP 2.0 is addressing is in practice an operational "problem").

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 10, 2013 11:08 UTC (Wed) by AndreiG (guest, #90359) [Link]

Excellent reply ! Couldn't have put it better myself.

After reading the HTTP/2.0 draft it is everything we are doing 'by hand' over HTTP/1.x to bypass Firewalls and NATs.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 11, 2013 12:58 UTC (Thu) by smitty_one_each (subscriber, #28989) [Link] (1 responses)

What, if any, effect will HTTP2.0 have on IPv6 adoption?
Perhaps it's more of a marketing question, but it seems like the argument "Hey, you can have a X% increase in throughput at a Y% decrease in administrative toothache-ery" would make a compelling business case.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 15, 2013 8:29 UTC (Mon) by jamesh (guest, #1159) [Link]

I don't think he was suggesting it would boost IPv6 adoption.

Rather that since IPv6 has not been widely adopted, more and more people are being placed behind NAT (e.g. at the ISP level). Since you can only run 2^16 TCP connections over a single IP address, there are incentives to build protocols that will allow you to place more customers behind a single IP address.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 11, 2013 22:26 UTC (Thu) by rnsanchez (guest, #32570) [Link] (1 responses)

It reminds me of RTMP, by the way.

Reimplementing TCP on top of TCP? (sort of...)

Posted Jul 14, 2013 4:28 UTC (Sun) by wahern (subscriber, #37304) [Link]

Or RTP interleaved inside an RTSP TCP stream. Or basically any other protocol that defines a framing mechanism and a way to establish multiple independent, simultaneous logical flows.

I've implemented interleaved RTSP/RTP tunneled through HTTP using two bonded HTTP streams, one GET and the other POST. This is how Apple implemented tunneling with RTSP. It was nasty, but at least it was somewhat easy to keep the HTTP, RTSP, Session management, and RTP code properly modularized. But of course I had to write everything from scratch, because nothing off-the-shelf is gonna make it easy to glue those things together.

I've also implemented much of RTMP. RTMP is evil because of the way ActionScript is abused for signaling. Not only do you need to write a bunch of parsers and composers for framing the multimedia, but you also have to parse friggin' ActionScript.

While I generally despise Microsoft designs, at least they support RTSP. WMA and the meta-information formats are hideous, but their RTSP implementation is only a little bit quirky. Not many people use it anymore, but it's still usually enabled by default, which means I haven't yet had to muck around with MMS over HTTP.

I've implemented and run a service that does real-time, live audio transcoding, going from Flash, Windows Media, Icecast, Quicktime, etc to RTSP, Flash, and various HTTP schemes, including transcoding all the low-level codecs (e.g. WMA -> Ogg). It detects the client player--agent string, etc--and returns the codec and container format that can play natively for that player, all using a single URL. ffmpeg, VLC, GStreamer, etc are too slow, too buggy, and hard to use in a sophisticated software architecture (mixing processes, threading, non-blocking I/O, plus splicing encoded frames for ad/announcement insertion), so I was stuck implementing almost everything, except the low-level codecs, from scratch. I can have over 10 full-blown real-time transcoding sessions serving as many client streams as the Cogent link can handle without the server breaking a sweat--only one core at less than 20%-30%, depending on how many needed to be resampled. Frankly, I'm stupified how ffmpeg, QuickTime, etc manage to blow so many CPU cycles just decoding stuff.

So, all I have to say about HTTP 2.0 is, "Bring it on, m****r f*****s". It's just another over-engineered protocol delaying roll-out of IPv6 and SCTP, providing more opportunities to sell my services.


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds