HttpURLConnection和httpclient比较

本文比较了java.net.URLConnection与HTTPClient的功能差异,详细分析了包括方法支持、响应码处理、代理设置、身份验证等方面的不同,并给出了性能测试结果。

 

A Comparison of java.net.URLConnection and HTTPClient

Since java.net.URLConnection and HTTPClient have overlapping functionalities, the question arises of why would you use HTTPClient. Here are a few of the capabilites and tradeoffs.

Note that if you're running an applet, then things depend on which browser you're running under, as the browser provides the actual client implementation used by URLConnection; therefore the following just lists the differences as compared to Sun's http client (which is the default client used by URLConnection in applications).

 

URLConnection

HTTPClient

Methods

Only HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS.

Has HEAD, GET, POST, PUT, DELETE, TRACE and OPTIONS, plus any arbitrary method, such as those from WEBDav and IPP.

Response Codes

The response code, headers, and body can only be read if the response code was less than 400 - for any 4xx or 5xx response code, you only get IOException's when trying to get any response info.

The response code, all headers, and the body can always be read normally.

Proxies and SOCKS

Full support (SOCKS: Version 4 only)

Full support (SOCKS: both version 4 and 5)

Authorization

Support for Basic and an early version of Digest in JDK 1.2 or later, only. The current version of Digest authentication (which is the one supported by most servers) is not supported, and due to a bug of theirs they won't even recognize the digest info returned by Apache.

Support for Basic and Digest Authentication; other schemes can be added.

Cookies

No.

Yes.

True request output streams

No - all data is fully buffered before it is sent.

Yes - HttpOutputStream will stream directly to the socket.

True response input streams

Under JDK 1.2, yes; under JDK 1.3 only if the response is not sent using the chunked encoding (this excludes most server-push responses).

Yes.

Persistent Connections

HTTP/1.0 Keep-Alive's in JDK 1.1 and JDK 1.2; JDK 1.3 has HTTP/1.1 persistence.

Supports HTTP/1.0 Keep-Alive's and HTTP/1.1 persistence.

Pipelining of Requests

No.

Yes.

Can set Timeouts

No.

Yes.

Can handle protocols other than HTTP

Yes (e.g. ftp, gopher, mailto, and file are provided)

No.

Can do HTTP over SSL (https)

Appropriate SSL package (such as JSSE) which provides an appropriate client must be installed.

Patches are available for various free and commercial SSL packages

Source code available

No.

Yes.

 

 

某网友做过两个的性能测试,结果如下

use httpurlconnection: 47

use httpclient: 641

 

http://wj98127.javaeye.com/blog/617014

 

下载方式:https://pan.quark.cn/s/a4b39357ea24 布线问题(分支限界算法)是计算机科学电子工程领域中一个广为人知的议题,它主要探讨如何在印刷电路板上定位两个节点间最短的连接路径。 在这一议题中,电路板被构建为一个包含 n×m 个方格的矩阵,每个方格能够被界定为可通行或不可通行,其核心任务是定位从初始点到最终点的最短路径。 分支限界算法是处理布线问题的一种常用策略。 该算法与回溯法有相似之处,但存在差异,分支限界法仅需获取满足约束条件的一个最优路径,并按照广度优先或最小成本优先的原则来探索解空间树。 树 T 被构建为子集树或排列树,在探索过程中,每个节点仅被赋予一次成为扩展节点的机会,且会一次性生成其全部子节点。 针对布线问题的解决,队列式分支限界法可以被采用。 从起始位置 a 出发,将其设定为首个扩展节点,并将与该扩展节点相邻且可通行的方格加入至活跃节点队列中,将这些方格标记为 1,即从起始方格 a 到这些方格的距离为 1。 随后,从活跃节点队列中提取队首节点作为下一个扩展节点,并将与当前扩展节点相邻且未标记的方格标记为 2,随后将这些方格存入活跃节点队列。 这一过程将持续进行,直至算法探测到目标方格 b 或活跃节点队列为空。 在实现上述算法时,必须定义一个类 Position 来表征电路板上方格的位置,其成员 row col 分别指示方格所在的行列。 在方格位置上,布线能够沿右、下、左、上四个方向展开。 这四个方向的移动分别被记为 0、1、2、3。 下述表格中,offset[i].row offset[i].col(i=0,1,2,3)分别提供了沿这四个方向前进 1 步相对于当前方格的相对位移。 在 Java 编程语言中,可以使用二维数组...
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值