Android 上的持久 HttpURLConnections
我在尝试让 Android 应用程序(好吧,服务,它的情况下它有任何区别)使用持久 HTTP 1.1 连接时遇到问题。
以下循环(简化的测试用例)通过桌面 JRE 上的单个 TCP 会话进行工作,但在 Android 设备上会导致整个套接字创建/拆卸周期。
while (true) {
URL url;
try {
url = new URL("http://10.0.0.125:8080/SRV?");
URLConnection connection = url.openConnection();
HttpURLConnection httpConnection = (HttpURLConnection) connection;
int responseCode = httpConnection.getResponseCode();
} catch (MalformedURLException e) {
} catch (IOException e) {
}
}
Oracle 的 JDK 描述了一种称为“系统属性”的东西:
http.keepAlive= 默认值:true
http.maxConnections= 默认值:5
Android 运行时中是否有类似的东西可以阻止维持持久连接?
I've got an issue trying to get the Android application (well, Service, it case it makes any difference) to use persistent HTTP 1.1 connections.
The following loop (simplified test case) works through a single TCP session on a desktop JRE, but on an Android device results in the whole socket creation/teardown cycle.
while (true) {
URL url;
try {
url = new URL("http://10.0.0.125:8080/SRV?");
URLConnection connection = url.openConnection();
HttpURLConnection httpConnection = (HttpURLConnection) connection;
int responseCode = httpConnection.getResponseCode();
} catch (MalformedURLException e) {
} catch (IOException e) {
}
}
The Oracle's JDK describes something called 'system properties':
http.keepAlive=
default: truehttp.maxConnections=
default: 5
Is there something similar in Android's runtime that prevents persistent connections from being maintained?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Android 的 JVM 在底层使用 Apache HTTP 组件库进行 HTTP 连接(甚至是使用 java.net 接口完成的连接):因此其行为与 Oracle JVM 略有不同。
理论上,底层 Harmony 代码尊重
http.keepAlive
系统属性,但我不确定 Google 的副本是否保留该行为。如果您想绝对确定发生了什么,则必须使用 HttpComponents 代码。这是漫长而痛苦的,但如果你看看 http:// hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html 它概述了 http 组件的连接管理方法。请参阅第 2.11 节,其中详细介绍了如何使用 HTTP 组件显式控制连接管理。
祝你好运。
Android's JVM uses the Apache HTTP Components library under the hood for HTTP connections (even those that are done using the java.net interface): as such the behavior is subtly different from the Oracle JVM.
In theory the underlying Harmony code respects the
http.keepAlive
system property, but whether Google's copy preserves that behavior isn't certain to me.If you want to be absolutely certain what's happening you have to use the HttpComponents code. It is long and painful, but if you look at http://hc.apache.org/httpcomponents-client-ga/tutorial/html/connmgmt.html it outlines the connection management approach for http components. Look at section 2.11 which details how to explicitly control the connection management using HTTP components.
Good luck.
我看到了同样的问题,即未建立持久 HTTP 1.1 连接。我编写了一个快速测试应用程序来获取更多详细信息。
首先,我对应用程序中的流量进行了 TCP 转储,以了解发生了什么情况。 “连接:保持活动”已正确发送到我的服务器。然后我的服务器响应“连接:保持活动”。然而,在我的应用程序关闭其连接的 InputStream 后,底层套接字也被 Android 关闭......而不是被持久化。
为了更深入地挖掘,我编写了使用两种不同方法进行连接的应用程序:
HttpURLConnection con = (HttpURLConnection) url.openConnection();
AND
HttpClient 客户端 = new DefaultHttpClient();
事实证明,HttpClient 并未保留底层套接字,但 HttpURLConnection 却保留了底层套接字。因此,如果您想要最佳性能,请使用 HttpURLConnections,直到 Android 解决 DefaultHttpClient 中的此错误。
看起来像是 Android HTTP 1.1 实现中的一个错误?
I was seeing the same issue with persistent HTTP 1.1 connections not being established. I wrote a quick test app to obtain more details.
First I performed a TCP dump of traffic from my app to see what was happening. "Connection:keep-alive" is being sent properly to my server. My server was then responding with "Connection:keep-alive". However after my app closed its connection's InputStream, the underlying socket was closed by Android as well...instead of being persisted.
To dig deeper, I wrote my app to connect using two different approaches:
HttpURLConnection con = (HttpURLConnection) url.openConnection();
AND
HttpClient client = new DefaultHttpClient();
It turn out that HttpClient was not persisting the underlying sockets but HttpURLConnection does. So if you want the best performance, use HttpURLConnections until Android resolves this bug in DefaultHttpClient.
Seems like a bug in Android HTTP 1.1 implementation?