Comment by Anderkent | Hacker News Reader

Comment by Anderkent | Hacker News Reader

>HTTP pipelining is crucial here since it’s one of the optimizations that Japronto takes into account when executing requests.

https://en.wikipedia.org/wiki/HTTP_pipelining

> Of all the major browsers, only Opera based on Presto layout engine had a fully working implementation that was enabled by default. In all other browsers HTTP pipelining is disabled or not implemented.[3]

>Internet Explorer 8 does not pipeline requests, due to concerns regarding buggy proxies and head-of-line blocking.[7]

>Internet Explorer 11 does not support pipelining. [8]

>Mozilla browsers (such as Mozilla Firefox, SeaMonkey and Camino) support pipelining; however, it is disabled by default.[9][10] Pipelining is disabled by default to avoid issues with misbehaving servers.[11] When pipelining is enabled, Mozilla browsers use some heuristics, especially to turn pipelining off for older IIS servers.[12]

>Konqueror 2.0 supports pipelining, but it's disabled by default.[citation needed]

>Google Chrome previously supported pipelining, but it has been disabled due to bugs and problems with poorly behaving servers.[13]

That seems like optimizing for a benchmark.

HTTP/1.1 pipelining works beautifully for requesting web pages or other files in bulk from a single domain.

I would imagine "bots" like Googlebot make use of it.

I have been using it daily for 15 years with no problems. I mainly use netcat. This is how I digest large quantities of information as text not possible to do using a browser.

Most websites allow pipelining. Usual max is 100 requests per connection.

But there are rare exceptions where pipelining is disabled. For example, users cannot request pages of results for 100 different queries from Google in a single connection.

Efficient. But not allowed. Always wondered why.

Advertising-filled web pages opened in a "modern browser" are expected to auto-request files from many third party domains. I will call these "conglomerate" pages for lack of a better term.

Not sure HTTP/1.1 pipelining works very well for that. Hence HTTP/2.

HTTP/1.1 benefits users like me. HTTP/2 benefits advertisers, Google, and other companies in the web advertising racket, but not sure how it would benefit users except to serve them advertising and conglomerate pages more efficiently.

As has been posted to HN before the number of outgoing connections that "modern browsers" make to third party servers upon loading a single webpage is staggering. At least, it looks staggering if you have been using the web since the early days, before web advertising grew to its current proportions.

> But there are rare exceptions where pipelining is disabled. For example, users cannot request pages of results for 100 different queries from Google in a single connection.

> Efficient. But not allowed. Always wondered why.

The likelihood is that your HTTP requests are getting routed to a backend server/instance/whatever that knows about your query, and can thus return data about that query, but that a different search would get routed somewhere else, to an instance which knows about that query specifically.

> Advertising-filled web pages opened in a "modern browser" are expected to auto-request files from many third party domains. I will call these "conglomerate" pages for lack of a better term.

> Not sure HTTP/1.1 pipelining works very well for that. Hence HTTP/2.

> HTTP/1.1 benefits users like me. HTTP/2 benefits advertisers, Google, and other companies in the web advertising racket, but not sure how it would benefit users except to serve them advertising and conglomerate pages more efficiently.

I think you misunderstand how HTTP/2 works.

HTTP/1.1 pipelining allows you to send five requests to a server, in order, and receive five responses in order. Very straightforward.

HTTP/2 allows you to send any number of requests to a server, in any order, and for the client or server to provide a priority for each of them, and for them to download out of order or in parallel.

What doesn't change between the two is that you're still connecting to one specific server, the same as you were before in HTTP/1.x, and not any number of third party servers, for any reason, in any context. It has zero impact on third-party services like ad networks, trackers, or the like.

Let me clarify a few things about my usage. I like the responses to received be in order, and groups of say 100 responses to separated by a header (these can act as delimiters for my text filters as I import into my databases). I have no need for compressed headers especially huge cookies because I have no need for cookies. Nor have I any need for preferential serving of my requests because I only want what I ask for, not what the server thinks I need. Finally, I am not doing interactive "browsing" or "user experience" and do not need a "warm" connection for "pushing" anything to the server. I have no need for Javascript, CSS and other window dressing. I am requesting information, preferably 7-bit ASCII, in bulk. Boring and old, but useful. There is no room for advertising, garnering "impressions", etc. This is www information retrieval. For this usage, ye olde HTTP/1.1 pipelining works well. The companies/organizations behind HTTP/2 rely on advertising. If HTTP/2 has no benefit to the business of serving ads (i.e., serving very heavy pages which are heavy because they are full of ads), then I am not sure why it was introduced. It stands to reason that pages without ads, devoid of "interactive features" to entice users to click, and served without large cookies for tracking should not not need HTTP/2. But I am not an expert on HTTP/2, and I am not running a business that needs to serve web pages with ads. I am just an ordinary dump web user who prefers plain text, likes HTTP/1.1 pipelining but does not like ads and other web cruft.

So basically you have a very nonstandard workflow, and expect the protocol to be optimised towards your needs?

With all due respect for your comment, that is not how I see it. I adjusted my "workflow" to what was available for the past decades: HTTP/1.1 pipelining. It has worked for me with no problems. And I am sharing this experience with others.

As soon as I've read HTTP 1.1 and HTTP pipelining I was thinking the same. We want real world performance and tests with real world browsers out there. And HTTP/2 is the way to go for the future also (and not 1.1).

The client isn't always a browser though.

True, but that's not directly relevant to the observable problems with pipelining. Any client implementing the http/1.1 pipelining semantics will run into the same issues because of the limitations built into the design.

If you go like this:

client ---(HTTP/2)---> nginx ---(pipelining)---> japronto

Would that not take benefit of japronto's optimisation?

Correct me if I'm wrong, but nginx doesn't support pipelining outbound network requests.

Even if it did, the benefits described in the post (mostly due to making fewer syscalls and having fewer packets to parse) go away because now nginx has to do the work instead of Python. There's probably also some overhead required to collect multiple requests together to pipeline them. You'd just be moving the load around.

I would imagine that nginx would probably do a better job of dealing with web serving (pipelineless and otherwise) than python would, mostly due to age

And if the nginx process somehow ends up using more CPU than the python process, then using multiple nginx servers would be fairly easy, compared to multiple application servers

But it is often a proxy, and proxies are both clients and servers. The number of misbehaving proxies is large enough that it isn't reasonable to turn on pipelining globally, which is why browsers don't.

Would it make make sense to optimize for HTTP/2 then?

I guess the problem there is client support. The server still has to scale in the same way when legacy clients are connected, too.

That makes little sense. Of course it wouldn't scale in the same way for legacy clients that can't be optimized.

It'd probably be easier to put a reverse proxy in front of it that speaks HTTP/2 and reverse proxy the requests using HTTP/1.1 with pipelining enabled.

HTTP/2 is a big step forward, but I wish web servers and HTTP clients supported HTTP/2 over TCP (h2c), TLS encryption is useless for internal microservices.

Isn't that thinking what got google tapped by the NSA in those infamous prism slides? (Honest question, I don't know if there are other solutions)

Yes, and it wasn't just Google.

Client or even frontend https wouldn't have solved the problem in most cases (it is necessary but not sufficient).

The database (or key value store, etc) replication stream is a prime target, as are any backend protocols that let edge data center storage proxy internal requests for core data centers.

Can you elaborate?

I would interpret it as:

a) HTTP/2 is often only supported in encrypted mode (h2). E.g. all browsers only supported the encrypted version, and lots of server side libraries then went the same route.

b) encryption might not be needed, if the services already communicate to each other in a secure environment (e.g. are located on the same host, run in an encrypted/secure network, etc.) In such environments the additonal encryption on HTTP level will only show it's downsides, like lower performance and additional deployment/maintainence concerns (certificate deployments, etc.).

I'm no expert in cloud/microservice environments, so I don't know that the usual configuration is there. But in general I would agree that there are some environments where HTTPS is simply not needed, like using it for localhost IPC on trusted systems.

> TLS encryption is useless for internal microservices

This is very much untrue, especially if you have multiple datacenters, run in the cloud, or operate out of a colo facility.

Funny, TLS + internal CA + multiple roots is how my microservices determine who is allowed to talk to whom.

You probably don't want clear text. A number of major ISPs (and proxies) poorly implement HTTP. They are either buggy or intentionally modify your connection. There was a blogpost by Youtube a while back about how turning on SSL actually increased the speed and reliability of video serving.

I'm just thinking how safe of an optimization pipelining actually is. Let's say a browser has to issue 2 HTTP requests and decides to write them to a single connection using pipelining. Now the server decides that the first one requires a large response (file download) or even an infinite response (server-side streaming) -> The second response is stuck in that case. And the browser might not even be able to safely repeat it on another connection if it doesn't know that it causes idempotent behavior. Or is pipelining only allowed for GET requests?

Pipelining doesn't specify which requests are okay to be pipelined and which aren't, but pipelined requests should be idempotent, and POST requests should not be assumed to be idempotent, whereas GET and HEAD requests should be assumed to be idempotent.

I wish there was a header a server could send to declare it supports pipelining.

"HTTP/1.1"

Yeah. More like I wish implementors would follow standard.

Pipelining support is optional. It's up to the client to back off if its attempts fail.

  8.1.2.2
  Clients MUST also be prepared to resend their requests if
   the server closes the connection before sending all of the
   corresponding responses.

> HTTP/1.1 conforming servers are required to support pipelining. This does not mean that servers are required to pipeline responses, but that they are required to not fail if a client chooses to pipeline requests.

http://www-archive.mozilla.org/projects/netlib/http/pipelini...

8.1.2.2 that you quoted [RFC2616] continues:

> A server MUST send its responses to those requests in the same order that the requests were received.

> That seems like optimizing for a benchmark.

Perish the thought, we've never seen that before in claims about which languages are fastest

Reply on news.ycombinator.com