HTTP 1.1流水线 [英] HTTP 1.1 Pipelining

查看:2518
本文介绍了HTTP 1.1流水线的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我必须在Java中实现HTTP客户端,并且根据我的需要,似乎最有效的方法是实现HTTP管道(根据 RFC2616

I have to implement an HTTP client in Java and for my needs it seems that the most efficient way to do it, is implement HTTP pipeline (as per RFC2616).

顺便说一句,我想管道POST。 (我也不是在谈论多路复用。我在谈论流水线操作,即在接收任何响应之前通过一个连接的许多请求 - 批量处理HTTP请求)

As an aside, I want to pipeline POSTs. (Also I am not talking about multiplexing. I am talking about pipelining i.e. many requests over one connection before receiving any response- batching of HTTP requests)

我找不到显式声明它支持流水线操作的第三方库。但我可以使用,例如 Apache HTTPCore 构建此类客户端,或者如果必须,构建它我自己。

I could not find a third party library that explicitly states it supports pipelining. But I could use e.g. Apache HTTPCore to build such a client, or if I have to, build it by myself.

我遇到的问题是它是不是一个好主意。我没有找到任何权威的参考资料,HTTP流水线技术不仅仅是理论模型,而是由HTTP服务器正确实现。此外,所有支持流水线操作的浏览器都默认关闭此功能。

The problem I have is if it is a good idea. I have not found any authoritative references that HTTP pipelining is something more than a theoretical model and is properly implemented by HTTP servers. Additionally all browsers that support pipelining have this feature off by default.

因此,我应该尝试实现这样的客户端,否则我将因为服务器而遇到很多麻烦实现(或代理)。是否有任何参考文献给出了这些指导原则?

So, should I try to implement such a client or I will be in a lot of trouble due to server's implementations (or proxies). Is there any reference that gives guidelines on these?

如果不知道什么是效率的替代编程模型?单独的TCP连接?

If it is a bad idea what would be the alternative programming model for efficiency? Separate TCP connections?

推荐答案

我实现了一个流水线的HTTP客户端。基本概念听起来很容易,但错误处理非常困难。性能提升是如此微不足道,以至于我们很久以前就放弃了这些概念。

I've implemented a pipelined HTTP client. The basic concept sounds easy but error handling is very hard. The performance gain is so insignificant that we gave up on the concepts long time ago.

在我看来,它对正常用例没有意义。当请求具有逻辑连接时,它只有一些好处。例如,您有一个3请求事务,您可以批量发送它们。但通常你可以将它们组合成一个请求,如果它们可以流水线化。

In my opinion, it doesn't make sense to normal use-case. It only has some benefits when the requests have logic connections. For example, you have a 3-requests transaction and you can send them all in a batch. But normally you can combine them into one request if they can be pipelined.

以下只是我记得的一些障碍,

Following are just some hurdles I can remember,


  1. TCP的keepalive不保证持久连接。如果在连接中有3个管道请求,则服务器会在第一次响应后断开连接。您应该重试下两个请求。

  1. TCP's keepalive is not guaranteed persistent connection. If you have 3 requests piped in the connection, server drops connection after first response. You supposed to retry the next two requests.

当您有多个连接时,负载平衡也很棘手。如果没有空闲连接,您可以使用繁忙连接或创建一个新连接。

When you have multiple connections, load balance is also tricky. If no idle connection, you can either use a busy connection or create a new one.

超时也很棘手。当一个请求超时时,您必须放弃所有请求,因为它们必须按顺序返回。

Timeout is also tricky. When one request times out, you have to discard all after it because they must come back in order.

这篇关于HTTP 1.1流水线的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆