Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP/2.0 Initial Draft Released

apiux.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: HTTP/2.0 Initial Draft Released

#11

Post by hobohacker »

inopinatus wrote: post #6

Why didn't they use SRV[1] records in DNS to resolve http2 requests? It has so many advantages: * Permitted at the domain apex (yes really! unlike CNAMEs!) * Allow weighted round-robin * Allows lower-priority fallback services * Unusual port numbers no longer required in URIs * Doesn't get confused with non-HTTP services located at the same FQDN. It's the modern way to federate services! And there's very wide DNS ser…

https://code.google.com/p/chromium/issues/detail?id=22423 discusses some of the issues with using SRV records in browsers.

SRV records could help clients discover server HTTP/2 support, but it does not mean that all intermediaries along the path support it.

Re: HTTP/2.0 Initial Draft Released

#12

Post by infofarmer »

cm3 wrote: post #10
ealexhudson wrote: post #4

Earlier quoted context omitted.

Not entirely. You have TCP_CORK to allow headers to be stuck in front; sendfile can also take ranges so you don't blow the frame limits. I would imagine that kind of set up is more trouble than it's worth though (is sendfile(2) still the fastest way of doing things? I thought it had been superceded anyway...)

You'd context switch to/from kernel way more often with small ranges. sendfile on Solaris, Linux, BSD and TransmitFile on Windows allow much larger ranges in one call. What's the replacement for sendfile(2)? Solaris has sendfilev which is still pretty much the same thing and sendfile(2) on Linux uses splice(2), vmsplice(2), tee(2) internally but I don't know of a replacement.

If needed, sendfile will most probably just learn enough to handle framing on its own, with a bit more parameters passed into it.

Re: HTTP/2.0 Initial Draft Released

#13

Post by X4 »

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more.

Here's stuff that backs my argument:s

a) http://rina.tssg.org/docs/PSOC-MovingBeyondTCP.pdf

b) http://users.ece.cmu.edu/~adrian/630-f04/readings/bellovin-t...

And here are more viable and real alternatives that not only increase the speed by a factor of n, but also increase security and compatibility to our mobile generation:

http://www.fujitsu.com/global/news/pr/archives/month/2013/20...

http://users.ece.cmu.edu/~adrian/630-f04/readings/bellovin-t...

http://roland.grc.nasa.gov/nrg/local/sctp.net-computing.pdf / http://tools.ietf.org/html/rfc4960

http://www.qualcomm.com/media/documents/why-raptor-codes-are...

PS: I was initially afraid that HTTP2.0 was optimized for Advertisers...pheww

Re: HTTP/2.0 Initial Draft Released

#14

Post by ErsatzVerkehr »

X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

> more efficiently compressed, more government resistant and more easily encryptable Protocol

Probably these things should not all be done at the same layer.

Re: HTTP/2.0 Initial Draft Released

#15

Post by qwerta »

X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

>and take a more advanced step than

Already done several times. Have look at UDP and its usages.

Re: HTTP/2.0 Initial Draft Released

#16

Post by jimktrains2 »

I think that the changes being made for "HTTP 2" are a terrible decision for HTTP. For SPDY, sure, make it as complex and as hard to work with as you want in the name of performance, but please keep my HTTP a nice, simple, text-based protocol that I can work with very easily.

I just feel that HTTP should not reïmplement TCP. SPDY/HTTP2 just seems much more complex than necessary.

http://jimkeener.com/posts/http is a 90% complete post of what I would like to see as HTTP 1.2 and some other things I think would be beneficial.

Re: HTTP/2.0 Initial Draft Released

#17

Post by jimktrains2 »

X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

> Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated.

You do realize HTTP and TCP/IP reside at very different OSI stack levels, right? Reïnventing TCP is not HTTP's job.

Re: HTTP/2.0 Initial Draft Released

#18

Post by wmf »

cm3 wrote: post #3

Does http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... and http://tools.ietf.org/html/draft-ietf-httpbis-http2-04#secti... mean sendfile(2) can't be used with HTTP/2.0?

With so much traffic over SSL now, I think sendfile's days are past.

Re: HTTP/2.0 Initial Draft Released

#19

Post by wmf »

X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

QUIC (which may become TCP 2.0 for HTTP/3.0 to run over) sounds like what you're looking for.

Re: HTTP/2.0 Initial Draft Released

#20

Post by digitalsushi »

X4 wrote: post #13

I think HTTP/2.0 should break backward compatibility and take a more advanced step than "little improvements like that". Killing TCP/IP completely and inventing a more efficiently compressed, more government resistant and more easily encryptable Protocol would be highly anticipated. The reason is that even adopting HTTP2.0 in that state would take at least a decade or more. Here's stuff that backs my argument:s a) ht…

What is so difficult about encrypting HTTP with an SSL Layer?

SSL is a key you keep and an unlocked padlock you give someone. They use it to give back a box with no idea how to open it.

You configure a web server with a key and a padlock. It keeps the key and serves the padlock. How can this be improved? (Serious question, maybe it can - this concept still seems esoteric to many)

Post reply on HN