7 ms·

>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/HT

>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 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.

willvarfar 10y ago
I wish there was a header a server could send to declare it supports pipelining.
- OJFord 10y ago
  "HTTP/1.1"
  - burnbabyburn 10y ago
    headshot
  - sametmax 10y ago
    Yeah. More like I wish implementors would follow standard.
    - kevin_thibedeau 10y ago
      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.
      - OJFord 10y ago
        > 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/pipelining-faq.html 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.
dorianm 10y ago
Would it make make sense to optimize for HTTP/2 then?
- gcp 10y ago
  I guess the problem there is client support. The server still has to scale in the same way when legacy clients are connected, too.
  - treve 10y ago
    That makes little sense. Of course it wouldn't scale in the same way for legacy clients that can't be optimized.
- caleblloyd 10y ago
  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.
- KAdot 10y ago
  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.
  - mattnewton 10y ago
    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)
    - hedora 10y ago
      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.
Spiritus 10y ago
The client isn't always a browser though.
- jsd1982 10y ago
  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.
  - RX14 10y ago
    If you go like this: client ---(HTTP/2)---> nginx ---(pipelining)---> japronto Would that not take benefit of japronto's optimisation?
    - bastawhiz 10y ago
      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.
      - RubyPinch 10y ago
        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
- morecoffee 10y ago
  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.
therealmarv 10y ago
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).
pekk 10y ago
> That seems like optimizing for a benchmark. Perish the thought, we've never seen that before in claims about which languages are fastest
gwu78 10y ago
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.
- danudey 10y ago
  > 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.
Matthias247 10y ago
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?
- danudey 10y ago
  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.

willvarfar 10y ago

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

OJFord 10y ago
"HTTP/1.1"
- burnbabyburn 10y ago
  headshot
- sametmax 10y ago
  Yeah. More like I wish implementors would follow standard.
  - kevin_thibedeau 10y ago
    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.
    - OJFord 10y ago
      > 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/pipelining-faq.html 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.

dorianm 10y ago

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

gcp 10y ago
I guess the problem there is client support. The server still has to scale in the same way when legacy clients are connected, too.
- treve 10y ago
  That makes little sense. Of course it wouldn't scale in the same way for legacy clients that can't be optimized.
caleblloyd 10y ago
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.
KAdot 10y ago
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.
- mattnewton 10y ago
  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)
  - hedora 10y ago
    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.

Spiritus 10y ago

The client isn't always a browser though.

jsd1982 10y ago
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.
- RX14 10y ago
  If you go like this: client ---(HTTP/2)---> nginx ---(pipelining)---> japronto Would that not take benefit of japronto's optimisation?
  - bastawhiz 10y ago
    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.
    - RubyPinch 10y ago
      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
morecoffee 10y ago
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.

therealmarv 10y ago

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).

pekk 10y ago

> That seems like optimizing for a benchmark. Perish the thought, we've never seen that before in claims about which languages are fastest

gwu78 10y ago

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.

danudey 10y ago
> 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.

Matthias247 10y ago

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?

danudey 10y ago
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.