The same criticism with equivalent merit could be leveled against TCP because it lives as far the Physical Layer (OSI Layer 1) as HTTP lives from the transport layer...e.g. "TCP is implementing Ethernet's responibilities."
But of course, though we rarely worry about Token Ring these days, we do run TCP over IEEE 802.11 all the time.
OSI's higher levels are abstractions. As is the case with all useful abstractions, they serve to implement the functionality of lower levels without requiring attention to their actual implementation. Not having to manage TCP allows a lot of useful JavaScript to be easily written.
That's a disingenuous and self contradictory description of how the OSI stack works.
There are upwards guarantees at each layer that the stack makes. All implementations within the layer must be equal to the next layer even if one of the implementations provides capability of higher layers. Nothing is said however about adding further guarantees in layers 8, 9, 10, 11, 12...and so forth because they have already been made.
I suppose I shouldn't use parity bits on serial connections then?
"Not having to manage TCP allows a lot of useful JavaScript to be easily written"
That's absurd. It makes no difference.
As for UPnP, which I know well having written an entire UPnP stack, it's a broadcast messaging layer, not a connection based protocol. All the HTTP messages stay within the size of a UDP datagram and it is expected to be wholly unreliable. Even though it's ugly, it's hardly a comparison.
I get the feeling a lot of people here are web developers with little experience of protocol stacks and not system programmers!
I suppose I shouldn't use parity bits on serial connections then?
If you're writing at the level of serial connections and parity, by all means pay attention to those details. If you're writing at higher level, consider abstracting away such details in an interface, library or module.
I miss Wildcat BBS as much as the next person: by which I mean, not very much. HN is full of really fucking smart people not the idiots implied by your comment.
This is nothing to do with BBS's or code abstractions. On the former, there is no OSI stack; it's terminals down serial connections. On the latter, it's datagrams or sockets. It's about the guarantees that the link layer makes or doesn't. Parity doesn't pass up the layers because the guarantees are made further up (TCP).
You can still run token ring, serial, thick ether, thin ether, paper aeroplanes thrown between buildings. It doesn't matter above the data link layer.
Yes there are really fucking smart people here, as you put it but it appears there is a normal distribution of people as well.
Where's the research that says that the connection overhead is destroying humanity?
Back when we I had a 14.4k SLIP dialup and RTT of 200ms+ connection overhead and TCP channel overhead was a major drag on throughput but it's not like that now. I'd be surprised if there was a tangible difference to the end user.
> Where's the research that says that the connection overhead is destroying humanity?
It's destroying big business who push lots and lots of resources to the browser:
- From an admin POV, you have to shard your domain => more work, more maintenance.
- From a browser POV, you have to open multiple TCP connections => you take slow start and TLS handshake in your face for each connection + the connections have to fight each other because the OS wants to be fair among TCP connections
- From a web admin POV, you want to inline your content to reduce round trips => you have more work to do on your resources
SPDY is certainly not necessary for everyone (it mostly benefits those who push lots of different resources), that's true. We're talking about businesses who lose a month worth of revenue if the latency to their site explodes from 50 ms to 500 ms.
But it still is interesting because the actual usage _on top of HTTP_ doesn't change: you still have your websockets or your Server-Sent events, you still have your keepalive, you can do a simple-stupid "one HTTP call per resource" and it will be handled efficiently, sometimes SPDY will work underneath to push content so that the next HTTP call will actually hit the cache without you knowing about it... all at the cost of changing (or updating) your library. Because you certainly don't write HTTP text directly to your TCP socket.
The interesting point will be for those library developers. The added complexity will certainly make it harder, but on the other hand the binary format and strict rules will make it easier to parse the messages... I'd like to see where it goes here.
The issue is that HTTP/2 is basically working around deficiences in TCP, and doing it badly, because it appears to be easier to get buyin for that than for fixing TCP or deploying alternatives.
HTTP/2 is implementing TCP's responsibilities. Again. Badly.