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

Http2 explained

daniel.haxx.se

Post reply on HN
Print view View original

61–67 of 67 posts

Re: Http2 explained

#61

Post by pdkl95 »

derefr wrote: post #25
jude- wrote: post #20

> 8.4.4. “Not being ASCII is a deal-breaker” > Yes, we like being able to see protocols in the clear since it makes debugging and tracing easier. But text based protocols are also more error prone and open up for much more parsing and parsing problems. > If you really can't take a binary protocol, then you couldn't handle TLS and compression in HTTP 1.x either and its been there and used for a very long time. First,…

Why not just have the wire sniffer decode the frames before presenting them. If you're interested in what's going on at the HTTP level, you aren't reading packetwise IP packet dumps, because it's hard to make sense of anything and everything is all mixed together; you're looking at abstracted, higher-level flows, where it's just taken for granted that you have a set of linear TCP streams. HTTP2 is a(n SCTPish) transp…

It is never a good idea to assume that a can opener[1] will always be available. While your decoder - an extra tool - may be available in "many" cases, there will always be a sizable minority of cases where it isn't. As the performance benefits of fixed-width fields are orthogonal to the fields being ASCII-vs-binary.

> SCTP / "transport-layer protocol"

So we move yet another step down the path of obsoleting TCP port numbers by adding another layer of indirection[2]. Re-implementing ports by tunneling everything over HTTP{,2} was a bad idea when it started over a decade ago, and it's still the wrong way to solve the problem.

[1] http://en.wikipedia.org/wiki/Assume_a_can_opener

[2] See RFC 1925, Section 2, rule 11a. ( https://tools.ietf.org/html/rfc1925 )

Re: Http2 explained

#62

Post by iso8859-1 »

pluma wrote: post #57
jerf wrote: post #3

"One of the drawbacks with HTTP 1.1 is that when a HTTP message has sent off with a Content-Length of a certain size, you can't easily just stop it. Sure you can often (but not always – I'll skip the lengthy reasoning of exactly why here) disconnect the TCP connection" Can someone give me more of a hint of that reasoning so that I can at least search for it? I'm intrigued, but the search terms I'm trying all come bac…

Basically, in HTTP 1.x there are only very specific times at which the server can respond throughout a request. In particular, there's no way to tell a client "please stop" when it is transmitting the request body. So how most web applications handle request bodies that are too big is to either kill the connection (which to the client looks like a network issue) or patiently pipe the entire message to /dev/null befor…

Most requests are GET, how would Content-Length help there?

Re: Http2 explained

#63

Post by derefr »

pdkl95 wrote: post #61
derefr wrote: post #25

Earlier quoted context omitted.

Why not just have the wire sniffer decode the frames before presenting them. If you're interested in what's going on at the HTTP level, you aren't reading packetwise IP packet dumps, because it's hard to make sense of anything and everything is all mixed together; you're looking at abstracted, higher-level flows, where it's just taken for granted that you have a set of linear TCP streams. HTTP2 is a(n SCTPish) transp…

It is never a good idea to assume that a can opener[1] will always be available. While your decoder - an extra tool - may be available in "many" cases, there will always be a sizable minority of cases where it isn't. As the performance benefits of fixed-width fields are orthogonal to the fields being ASCII-vs-binary. > SCTP / "transport-layer protocol" So we move yet another step down the path of obsoleting TCP port…

The real problem is that flow control needs to happen at the pair-of-machines level. If we had that, opening 1000 "stream" connections to a server would be exactly the same as opening a single 1000-channel SCTP connection.

Re: Http2 explained

#64

Post by getsat »

btmorex wrote: post #54
getsat wrote: post #36

Earlier quoted context omitted.

Linux starts to act weird around 200,000 concurrent connections in my experience, even with aggressive sysctl tuning. You end up with weird edge cases like netstat literally taking 15 minutes of CPU time (in kernel) before it dumps the list of connections to stdout. Not sure about FreeBSD or any other OSes.

Not saying netstat isn't slow, but: # time sh -c 'netstat -tn | wc -l' 486206 real 0m13.538s user 0m1.698s sys 0m10.380s It still works with a whole lost of connections. (in fairness, only about 130k were connected)

The problem is that it doesn't scale linearly. There's some O(n4) algorithm being used in netstat or some kernel syscalls or something. Once you go over 250k, things get _really_ weird.

Re: Http2 explained

#65

Post by patrickmcmanus »

getsat wrote: post #64
btmorex wrote: post #54

Earlier quoted context omitted.

Not saying netstat isn't slow, but: # time sh -c 'netstat -tn | wc -l' 486206 real 0m13.538s user 0m1.698s sys 0m10.380s It still works with a whole lost of connections. (in fairness, only about 130k were connected)

The problem is that it doesn't scale linearly. There's some O(n 4) algorithm being used in netstat or some kernel syscalls or something. Once you go over 250k, things get _really_ weird.

try ss -nt instead.. it uses netlink sockets instead of /proc and generally scales much better

Re: Http2 explained

#66

Post by getsat »

patrickmcmanus wrote: post #65
getsat wrote: post #64

Earlier quoted context omitted.

The problem is that it doesn't scale linearly. There's some O(n 4) algorithm being used in netstat or some kernel syscalls or something. Once you go over 250k, things get _really_ weird.

try ss -nt instead.. it uses netlink sockets instead of /proc and generally scales much better

Thanks for the tip!

Re: Http2 explained

#67

Post by gremlinsinc »

Wow - was expecting something scary, super technical and over my head - very easy overview - not that I'm not technical I do server support for a huge web hosting firm - but sometimes http docs get way too tech spec --this was very clear to understand.
Post reply on HN