5 ms·

At first glance, the spec appears to be re-implementing a TCP stack inside a TCP connection...

wmf 13y ago
Yes, the reason is that starting a new stream multiplexed inside an already-open TCP connection is faster than starting a new TCP connection. Attempts to improve TCP itself are slowed down by slow uptake of new Windows versions.
- joosters 13y ago
  That's not true. HTTP/2.0 (or at least the successor to HTTP/1.1) has been discussed for over a decade, there have been many OS releases since then! Inventing a whole new protocol to overcome a TCP deficiency is IMO a terrible motive...
  - pritambaral 13y ago
    These guys have something to say about that: http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm... A new protocol that runs on UDP precisely to side-step slow TCP changes.
    - nly 13y ago
      That's great, but it means it'll always be a userland library rather than a OS supported networking protocol... which means the API will never be a defacto standard akin to the BSD sockets API. The reference implementation is also in obtuse looking C++... which will hinder bindings to other languages. In short, don't expect to see this outside of Android or Chrome. On the plus side, this is exactly what UDP was for in the first place.
- bcoates 13y ago
  What efforts are these? That sounds much more interesting than mucking around with HTTP micro-optimizations.
  - wmf 13y ago
    See TCP Fast Open, MPTCP, ObsTCP, TCPCrypt, CurveCP, QUIC, MinimaLT, etc. I also get the impression that TLS SNI/Snap Start/False Start/Ludicrous Start were also hampered by browsers that used the Windows SSL stack, although I never understood why they would do that.
    - deleted 13y ago
      [deleted]
- lgg 13y ago
  While there have been some tweaks around the edges in terms of congestion control and the like, the TCP wire format has not changed in over 25 years and it has very little to do with Windows. It has to do with the all the middle boxes and routers in the ossified backbone of the internet that choke if they see anything over IP that is not exactly what they expect.
joosters 13y ago
HTTP/2.0: For all those people who thought 'the web' was 'the internet'. Well now it is! We've implemented TCP inside of HTTP. There's even a PING message there so you can do ICMP over HTTP as well :)
donpdonp 13y ago
I'd like to see increased adoption of SCTP to get multiplexing benefits for all protocols including HTTP.
- _delirium 13y ago
  Google mentions SCTP briefly here, along with some other alternatives: http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper Their main reason for going with SPDY seems to be that rolling out an application-level protocol is easier, while rolling out a transport-level protocol would require changing routers and such. That is almost certainly true. Fixing the multiplexing problem in an HTTP-specific way rather than generally does seem like an unfortunate hack, but it's probably the pragmatic approach.
  - Aloisius 13y ago
    Doesn't SCTP run over IP as a layer 4 (transport layer) protocol? Why would you need to change routers (mostly layer 3)?
ddalex 13y ago
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. Guess what the designers chose.
- drawkbox 13y ago
  Being open and readable is also a check on this. Compare for instance the HTTP spec or JSON or XML files to binary file formats of applications. If it is hidden from sight things get ugly fast. Case in point the PSD file format and any Office file format (http://www.joelonsoftware.com/items/2008/02/19.html http://www.joelonsoftware.com/items/2008/02/19.html). Binary formats are usually only a good idea on the onset, with change it becomes a pile. Binary formats only really work well when you control both endpoints (even then they get crufty), for exchanging information being unreadable leads to many bad things and it a great step backwards. I work in game development and application development and the former really loves binary formats (slowly changing away from that with server and editable needs). In many bugs or crashes the root of the problem is some offset in a binary file or some incorrect custom binary file format node that breaks everything after it. Readable, keyed and debuggable formats are so much better at their root (they can be binary, base64'd, compressed after but at the root they should be standard in some way and able to change without breaking the whole thing).

wmf 13y ago

Yes, the reason is that starting a new stream multiplexed inside an already-open TCP connection is faster than starting a new TCP connection. Attempts to improve TCP itself are slowed down by slow uptake of new Windows versions.

joosters 13y ago
That's not true. HTTP/2.0 (or at least the successor to HTTP/1.1) has been discussed for over a decade, there have been many OS releases since then! Inventing a whole new protocol to overcome a TCP deficiency is IMO a terrible motive...
- pritambaral 13y ago
  These guys have something to say about that: http://blog.chromium.org/2013/06/experimenting-with-quic.html http://blog.chromium.org/2013/06/experimenting-with-quic.htm... A new protocol that runs on UDP precisely to side-step slow TCP changes.
  - nly 13y ago
    That's great, but it means it'll always be a userland library rather than a OS supported networking protocol... which means the API will never be a defacto standard akin to the BSD sockets API. The reference implementation is also in obtuse looking C++... which will hinder bindings to other languages. In short, don't expect to see this outside of Android or Chrome. On the plus side, this is exactly what UDP was for in the first place.
bcoates 13y ago
What efforts are these? That sounds much more interesting than mucking around with HTTP micro-optimizations.
- wmf 13y ago
  See TCP Fast Open, MPTCP, ObsTCP, TCPCrypt, CurveCP, QUIC, MinimaLT, etc. I also get the impression that TLS SNI/Snap Start/False Start/Ludicrous Start were also hampered by browsers that used the Windows SSL stack, although I never understood why they would do that.
  - deleted 13y ago
    [deleted]
lgg 13y ago
While there have been some tweaks around the edges in terms of congestion control and the like, the TCP wire format has not changed in over 25 years and it has very little to do with Windows. It has to do with the all the middle boxes and routers in the ossified backbone of the internet that choke if they see anything over IP that is not exactly what they expect.

joosters 13y ago

HTTP/2.0: For all those people who thought 'the web' was 'the internet'. Well now it is! We've implemented TCP inside of HTTP. There's even a PING message there so you can do ICMP over HTTP as well :)

donpdonp 13y ago

I'd like to see increased adoption of SCTP to get multiplexing benefits for all protocols including HTTP.

_delirium 13y ago
Google mentions SCTP briefly here, along with some other alternatives: http://www.chromium.org/spdy/spdy-whitepaper http://www.chromium.org/spdy/spdy-whitepaper Their main reason for going with SPDY seems to be that rolling out an application-level protocol is easier, while rolling out a transport-level protocol would require changing routers and such. That is almost certainly true. Fixing the multiplexing problem in an HTTP-specific way rather than generally does seem like an unfortunate hack, but it's probably the pragmatic approach.
- Aloisius 13y ago
  Doesn't SCTP run over IP as a layer 4 (transport layer) protocol? Why would you need to change routers (mostly layer 3)?

ddalex 13y ago

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. Guess what the designers chose.

drawkbox 13y ago
Being open and readable is also a check on this. Compare for instance the HTTP spec or JSON or XML files to binary file formats of applications. If it is hidden from sight things get ugly fast. Case in point the PSD file format and any Office file format (http://www.joelonsoftware.com/items/2008/02/19.html http://www.joelonsoftware.com/items/2008/02/19.html). Binary formats are usually only a good idea on the onset, with change it becomes a pile. Binary formats only really work well when you control both endpoints (even then they get crufty), for exchanging information being unreadable leads to many bad things and it a great step backwards. I work in game development and application development and the former really loves binary formats (slowly changing away from that with server and editable needs). In many bugs or crashes the root of the problem is some offset in a binary file or some incorrect custom binary file format node that breaks everything after it. Readable, keyed and debuggable formats are so much better at their root (they can be binary, base64'd, compressed after but at the root they should be standard in some way and able to change without breaking the whole thing).