雨季来得猛烈突然，不知道你的城市有没有在看海，总之还是希望不会遇上这种事，大家出...
最近是不是 iPhone 频繁要求你输入密码解锁，Touch ID 形同虚设？不要以为是 Touch ID...
“喝酒”、“撩妹”的中年大叔也照样能拿个第一，走上人生巅峰啊！
使用竞争对手的产品本来也没什么，毕竟知己知彼，才更好抄袭。
苹果暂时还没有获得在印度开设零售店的许可，不过庆幸的是大门也没有完全被关上。
也许你已经猜到了，没有中国大陆。不过，中国香港倒是上榜了。
不过当技术成熟或者条件允许之后，库克会不会改变今天的说法呢？
尽管苹果一直都不愿公布Apple Watch的销量，但库克从来没有失去信心。
刀塔的故事背景我想不少朋友已经很熟悉，再重复灌输难免显得有些啰嗦，详细的剧情小...
在这里我们会率领众多英雄级人物完成各种战斗使命，从原来的一方据点逐渐将整片土地拿...
近日，游戏开发商
在苹果商店当中推出了其体育类休闲游戏《冰球明星（Ho...
曾经开发过《战争之手》、《子弹男孩》等多部上乘小游的游戏开发商 Kongregate 于上周...
Grzegorz Flor 新作《四季：自然的逻辑（4 Seasons - logic of nature）》讲述了一个...
而对于普通人来说，可能我们并没有这么高的智商去解决什么世界上的难题，但是在游戏里...
此前威锋网曾经报道了著名游戏开发商 Glu Games将会为布兰妮量身打造一款手游，而近日...
苹果与飞利浦其实也是老搭档了~
耳机的造型设计借鉴了黑胶唱片标志性的圆碟造型，在享有优良音质的同时迎合时尚品味。
说得我都想天天呆厨房里做甜品了~
尽管有缺陷，但它应该称得上是一款很优秀的，适配iPhone的VR设备。
BookBook 保护壳能够将用户的 iPad Pro 变成一本尺寸较大的皮革装订书。
这两款镜头都非常薄，这种厚度令其放置于钱包中都毫无压力。
自带鼓风机和美光效果，对于那些自拍狂魔来说，这款产品应该就是标配了。
轻便的移动电源很容易就电量耗尽，而大容量的移动电源往往都比较笨重，这样的体验远远...
一台mbp,firefox上网正常，但safari就不能上网，也不能访问apple store，，总提示无法连接服务器，什么毛病
注册时间 最后登录
在线时间43 小时 UID
主题帖子人气
小苹果, 积分 40, 距离下一级还需 10 积分
一台mbp,firefox上网正常，但safari就不能上网，也不能访问apple store，，总提示无法连接服务器，用网络诊断，结果也是“您的互联网连接看起来正常：，什么毛病
注册时间 最后登录
在线时间43 小时 UID
主题帖子人气
注册时间 最后登录
在线时间37 小时 UID
主题帖子人气
帮你顶上去，等大神
注册时间 最后登录
在线时间336 小时 UID
主题帖子人气
提示: 作者被禁止或删除 内容自动屏蔽
签名被屏蔽
注册时间 最后登录
在线时间376 小时 UID
主题帖子人气
系统偏好设置———网络————高级————dai li ————把所有的钩去掉～～就可以了～～
注册时间 最后登录
在线时间110 小时 UID
主题帖子人气
楼上的太强了，但补充一下：
“系统偏好设置———网络————高级————Da1L1————把所有的钩去掉～～就可以了～～ ”中的“Da1L1”是“代
理”的意思哦。。
威锋旗下产品
Hi~我是威威！
沪公网安备 29号　|　沪ICP备号-1
新三板上市公司威锋科技（836555）
增值电信业务经营许可证：
Powered by Discuz!二次元同好交流新大陆
扫码下载App
汇聚2000万达人的兴趣社区下载即送20张免费照片冲印
扫码下载App
温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(6135)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_095066',
blogTitle:'解决Firefox经常弹出输入代理服务器用户名和密码提示对话框的问题',
blogAbstract:'我一直在使用Firefox浏览器，但是公司的网络环境必须设置代理服务器，使用代理的时候，经常会弹出提示对话框，要求输入代理服务器用户名和密码，好不烦人啊！
　　百度了一番，没有找到解决办法，全是求救的贴子。于是
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}使用实现的HTTP响应功能。但是在通过反复刷新访问:8416时，有时可以得到正常的响应，但更多的时候无法得到正常响应，显示连接被重置。如下：首先是main函数：public static void main(String[] args) {
acceptCount
serverSocket
ServerSocket httpServer = new ServerSocket(port, backlog);
.out.println("server:httpy");
while(true){
// 从等待队列中取出一个连接请求，建立socket连接
serverSocket = httpServer.accept();
acceptCount ++;
// 对每次的请求都使用一个独立的线程来响应
HttpResponse response = new HttpResponse(serverSocket);
Thread thread = new Thread(response);
thread.start();
// 打出已经接受并处理请求数
System.out.println(acceptCount);
} catch (IOException e) {
e.printStackTrace();
} }然后是服务端进行响应的线程类（HttpResponse）：class HttpResponse implements Runnable{ // 与客户端进行连接的socket Socket
serverSocket
= // 回车换行 String
= "\r\n"; // 服务端进行响应的输出流 BufferedWriter responseWriter
= BufferedReader br
= HttpResponse(Socket _socket){
serverSocket = _ } public void run(){
response(); } /**
* 对客户端请求进行响应的处理方法
* @return none
*/ public void response(){
responseWriter =
new BufferedWriter(
new OutputStreamWriter(
serverSocket.getOutputStream()));
// 服务端进行响应的响应内容
StringBuffer content = new StringBuffer();
content.append("&html&");
content.append("&head&");
content.append("&title&");
content.append("httpy web server");
content.append("&/title&");
content.append("&/head&");
content.append("&body&");
content.append("&div&");
content.append("&a&server:httpy&/a&");
content.append("&/div&");
content.append("&/body&");
content.append("&/html&");
// 服务端进行响应的响应头
StringBuffer header = new StringBuffer();
header.append("HTTP/1.1 200 OK");
header.append(crlf);
header.append("Content-Length:");
header.append(content.toString().getBytes("utf-8").length);
header.append(crlf);
header.append("Content-Type:text/UTF-8");
header.append(crlf);
header.append(crlf);
// 输出响应头
responseWriter.write(header.toString());
// 输出响应内容
responseWriter.write(content.toString());
} catch (Exception e) {
e.printStackTrace();
// 关闭资源连接
if(responseWriter != null){
responseWriter.close();
if(serverSocket != null){
serverSocket.close();
} catch (IOException e) {
e.printStackTrace();
}}客户端访问使用浏览器：firefox访问地址
：localhost:8416如果反复快速的进行访问（不管是反复回车请求，F5刷新请求，还是Ctrl + F5刷新请求），就会出现，有时浏览器得到正常页面显示，而更多的时候却显示连接被重置，不知道是什么原因导致的。以下是页面正常显示的效果：以下是请求异常的时候页面显示的效果：另外，本人下载了一个java开源的HTTP服务器，在本机上测试时一切正常，排除浏览器，系统环境的影响。
--------------------------------------
试试不要再一台机器上发布http server和访问这个http server.可以换换将server发布到的另外的机器，然后访问。
--------------------------------------
我是一只掉队的员，没工作，没，没机器，就一个人呆在住的地方敲代码学习。其实所有的代码就上面那一点，各位不介意可以copy到自己的机器上跑跑看，整个过程大概耗时30秒。
--------------------------------------
拷贝到本机并运行了，因为没有装firefox浏览器，我只用了IE和这2个浏览器测试。测试结果一切正常。了“firefox 连接被重置”，好多人都遇到了类似的问题。建议楼主也可以从firefox这里找找原因，不一定是你的代码的问题。/?p=268最后找到了真正的解决办法，应该是火狐的一些设置或插件的问题。办法如下：删除C:\Documents and Settings\Administrator\Application Data\目录下。前提是你没有安装的其他。
--------------------------------------
感谢u的辛苦测试，但是我机器上使用IE跑，还是会出现问题，不过显示的不是连接被重置，而是“无法显示当前页面”。你是怎么测试的，有没有反复的刷新，就是按着F5不动。浏览器断断续续的请求几次可能没问题，高频率的刷新问题就出现了。期待u再测试一次，是高频率刷新哦
--------------------------------------
貌似当接收缓存区还存在数据时关闭socket会导致异常关闭，即发送RST立即关闭TCP连接。当接收方收到RST时系统会丢弃TCP的发送和接收缓冲区，如果在此之前浏览器进程没有完全接收TCP缓冲区的数据的话，数据就不完整，浏览器就会报错。因为你没读取发送的数据，所以会出现这种情况。
--------------------------------------
引用 5 楼 fei1710 的回复:貌似当接收缓存区还存在数据时关闭socket会导致异常关闭，即发送RST立即关闭TCP连接。当接收方收到RST时系统会丢弃TCP的发送和接收缓冲区，如果在此之前浏览器进程没有完全接收TCP缓冲区的数据的话，数据就不完整，浏览器就会报错。因为你没读取发送的数据，所以会出现这种情况。我想确认一下，你说的接受缓存区是指服务端的接收缓存区，还是指客户端（浏览器）的接收缓存区。测试中，如果在服务端添加读取socket接收缓冲区的代码后，问题就消息了，从这个现象上看，有点支持你的观点。但问题是，上面的代码中，服务端根本就没有读取自身接收缓存区的数据，如果是你说的这个原因，那么，测试的时候，应该一次也不会成功，但为什么测试的结果却是有时成功，有时失败呢？
--------------------------------------
还有下面一条测试线索：如果加入以下代码（$$$$$$$$$$$$$$$$$$$$$$$$标示出的中间部分），问题就消息了。[下面是加入新代码后的程序片段，其他地方都不作改变]public void response(){
responseWriter =
new BufferedWriter(
new OutputStreamWriter(
serverSocket.getOutputStream()));
// 此处是新加入的代码片段$$$$$$$$$$$$$$$$$$$$$$$$
new BufferedReader(
new OutputStreamReader(
serverSocket.getInputStream()));
br.read();
// 以上是新加入的代码片段$$$$$$$$$$$$$$$$$$$$$$$$
// 服务端进行响应的响应内容
StringBuffer content = new StringBuffer();
content.append("&html&");
--------------------------------------
引用 6 楼 wuliuxu 的回复:Quote: 引用 5 楼 fei1710 的回复:貌似当接收缓存区还存在数据时关闭socket会导致异常关闭，即发送RST立即关闭TCP连接。当接收方收到RST时系统会丢弃TCP的发送和接收缓冲区，如果在此之前浏览器进程没有完全接收TCP缓冲区的数据的话，数据就不完整，浏览器就会报错。因为你没读取发送的数据，所以会出现这种情况。我想确认一下，你说的接受缓存区是指服务端的接收缓存区，还是指客户端（浏览器）的接收缓存区。测试中，如果在服务端添加读取socket接收缓冲区的代码后，问题就消息了，从这个现象上看，有点支持你的观点。但问题是，上面的代码中，服务端根本就没有读取自身接收缓存区的数据，如果是你说的这个原因，那么，测试的时候，应该一次也不会成功，但为什么测试的结果却是有时成功，有时失败呢？这是一个时机问题，如果在收到RST之前已经读取了接收缓冲区的数据就不会报错，否则就会报错。我测试了一下java下报的是这个错误java.net.SocketException:
caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method)
--------------------------------------
引用 8 楼 fei1710 的回复:Quote: 引用 6 楼 wuliuxu 的回复:Quote: 引用 5 楼 fei1710 的回复:貌似当接收缓存区还存在数据时关闭socket会导致异常关闭，即发送RST立即关闭TCP连接。当接收方收到RST时系统会丢弃TCP的发送和接收缓冲区，如果在此之前浏览器进程没有完全接收TCP缓冲区的数据的话，数据就不完整，浏览器就会报错。因为你没读取发送的数据，所以会出现这种情况。我想确认一下，你说的接受缓存区是指服务端的接收缓存区，还是指客户端（浏览器）的接收缓存区。测试中，如果在服务端添加读取socket接收缓冲区的代码后，问题就消息了，从这个现象上看，有点支持你的观点。但问题是，上面的代码中，服务端根本就没有读取自身接收缓存区的数据，如果是你说的这个原因，那么，测试的时候，应该一次也不会成功，但为什么测试的结果却是有时成功，有时失败呢？这是一个时机问题，如果在收到RST之前已经读取了接收缓冲区的数据就不会报错，否则就会报错。我测试了一下java下报的是这个错误java.net.SocketException: Software caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method)我想再次确认一下，你说的缓冲区（上面加粗加下划线标明）是指服务端的缓冲区还是客户端（浏览器）的缓冲区？
--------------------------------------
引用 9 楼 wuliuxu 的回复:Quote: 引用 8 楼 fei1710 的回复:Quote: 引用 6 楼 wuliuxu 的回复:Quote: 引用 5 楼 fei1710 的回复:貌似当接收缓存区还存在数据时关闭socket会导致异常关闭，即发送RST立即关闭TCP连接。当接收方收到RST时系统会丢弃TCP的发送和接收缓冲区，如果在此之前浏览器进程没有完全接收TCP缓冲区的数据的话，数据就不完整，浏览器就会报错。因为你没读取发送的数据，所以会出现这种情况。我想确认一下，你说的接受缓存区是指服务端的接收缓存区，还是指客户端（浏览器）的接收缓存区。测试中，如果在服务端添加读取socket接收缓冲区的代码后，问题就消息了，从这个现象上看，有点支持你的观点。但问题是，上面的代码中，服务端根本就没有读取自身接收缓存区的数据，如果是你说的这个原因，那么，测试的时候，应该一次也不会成功，但为什么测试的结果却是有时成功，有时失败呢？这是一个时机问题，如果在收到RST之前已经读取了接收缓冲区的数据就不会报错，否则就会报错。我测试了一下java下报的是这个错误java.net.SocketException: Software caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method)我想再次确认一下，你说的缓冲区（上面加粗加下划线标明）是指服务端的缓冲区还是客户端（浏览器）的缓冲区？socket缓冲区
--------------------------------------
兄弟你的问题太有意思了。我之前测试，确实只是间隔的刷新页面，没有持续的刷新。这次测试，使用ie按住f5键，后台有对应的错误日志：938939java.net.SocketException: Connection reset by peer: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method) at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92) at java.net.SocketOutputStream.write(SocketOutputStream.java:136) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:297) at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:130) at java.io.OutputStreamWriter.close(OutputStreamWriter.java:216) at java.io.BufferedWriter.close(BufferedWriter.java:248) at httpserver.HttpResponse.response(HttpResponse.java:76) at httpserver.HttpResponse.run(HttpResponse.java:24) at java.lang.Thread.run(Thread.java:619)940941942因为ie不断的刷新，所以肉眼比较难分辨出对应这个错误日志时ie展示了什么。不过我有抓包如下：请求有167往165发起图中，从上往下看，是三次请求，在最左边我用三个方框标了出来。第一次正常的，第二次异常，第三次正常（就没给出完整的截图）。因为http基于tcp，所以每个http报文前肯定要经过tcp三次握手，http结束后要有4个tcp断开的报文（暂时不关心）。图中小圆形标出来的，就是http之前的三次握手。最后一列就是握手过程的几个关键flag。再看第一个小圆形下方紧跟着的http请求和响应，就是HTTP GET和HTTP 200OK。可见第一个请求是正常的。看第二个小圆形下方紧跟着的http请求，只有HTTP GET，没见到200 OK。14405这一行，我用一个椭圆和一个标了出来，其中有个RST报文。网上摘录一段话“RST一般是在FIN之后才会出现为1的情况，表示的是连接重置。”我想：如果连接都重置了，服务器端就会出现写失败。正好和上面的错误日志吻合。那么现在只是抓包和日志对上了，但是为什么客户端会发一个RST的报文，我就不清楚了。
--------------------------------------
http://blog.csdn.net/sureyonder/article/details/5633647网上又找了个看看，希望对你有帮助！
--------------------------------------
非常感谢u的辛苦测试和解答，提供的博文也非常的有用。结合你的测试和分析来看，好像问题集中到了“客户端为什么会发一个RST报文这点了”，接下来我得再好好考虑这点了。
--------------------------------------
这个问题有点意思，所以大致看了一下。需要分析原因1 用浏览器不大好分析原因，所以使用httpclient模拟浏览器来进行模拟多用户并发提交以下是具体的代码，主要是模拟n个线程来提交m个http request. import java.io.IOE import java.util.concurrent.ExecutorS import java.util.concurrent.E import java.util.concurrent.TimeU
import org..http.HttpE import org..http.HttpR import org.apache.http.client.methods.HttpP import org.apache.http.client.params.HttpClientP import org.apache.http.impl.client.DefaultHttpC import org.apache.http.impl.client.DefaultHttpRequestRetryH import org.apache.http.params.BasicHttpP import org.apache.http.params.HttpConnectionP import org.apache.http.params.HttpP import org.apache.http.util.EntityU
public class HttpClientTest {
* @param args
* @throws InterruptedException
public static void main(String[] args) throws InterruptedException {
ExecutorService service =
service = Executors.newFixedThreadPool(100);
final Runnable runnableImpl = new Runnable() {
public void run() {
System.out.println(Thread.currentThread().getName());
postCommunication("http://192.168.1.83:8416/");
(int i = 0; i & 100; i++) {
service.submit(runnableImpl);
service.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS);
} finally {
if (service != null) {
service.shutdown();
public static final void postCommunication(final String url) {
DefaultHttpClient httpClient =
HttpPost httpPost =
String body =
int statusCode = -1;
// create instance httpClient with hTTP parameter
// set the retry handler
httpClient = new DefaultHttpClient(setParam());
httpClient
.setHttpRequestRetryHandler(new DefaultHttpRequestRetryHandler(
0, false));
// create post instance
httpPost = new HttpPost(url);
httpPost.addHeader("Connection", "close");
// get the status code and body message.
HttpResponse response = httpClient.execute(httpPost);
statusCode = response.getStatusLine().getStatusCode();
HttpEntity reEntity = response.getEntity();
if (reEntity != null) {
bodyMessage = EntityUtils.toString(reEntity);
} catch (IOException e) {
e.printStackTrace();
} catch (Exception e) {
e.printStackTrace();
} finally {
if (httpPost != null) {
httpPost.releaseConnection();
if (httpClient != null) {
httpClient.getConnectionManager().shutdown();
System.out.println("statusCode:" + statusCode + ",bodyMessage:"
+ bodyMessage);
private static final HttpParams setParam() {
final HttpParams httpParams = new BasicHttpParams();
HttpConnectionParams.setConnectionTimeout(httpParams, 2000);
HttpConnectionParams.setSoTimeout(httpParams, 2000);
HttpConnectionParams.setSocketBufferSize(httpParams, 1024 * 2);
HttpClientParams.setRedirecting(httpParams, true);
return httpP
} } 以上的代码模拟100个用户并发执行100个http request. 但是经常会出现问题。 错误为以下 java.net.SocketException: Software caused connection abort: recv failed 这是什么原因呢，那我们就分析一下。 首先看一下出错在什么地方。 我们的代码错误在
HttpResponse response = httpClient.execute(httpPost);
到底在什么情况下出现这种问题，那就看一下httpclinet的。 发现在这种情况下会出现错误。 1 server端
responseWriter.write(header.toString()); responseWriter.write(content.toString());
以后会立即关闭responseWriter 2 客户端httpclient在read response的时候根本还没有来得及read的时候，因为服务端已经主动关闭了。抛出了IOException
httpclient出错的具体位置
DefaultHttpResponseParser.java
method parseHead
int i = sessionBuffer.readLine(this.lineBuf); // 这里出错了，由于服务端的socketoutputstream已经关闭了 这里的sessionBuffer readline也就会抛出io exception.
所以说总结一下，出现这种错误的原因是因为当服务端向socket写数据的时候，由于没有等待客户端的读数据操作完成，就关闭了socket的outputstream和socket对象，导致客户端抛出了异常 下面说一下解决方法
解决方法 我想是不是可以在服务端写数据以后，有一个缓冲的时间，让客户端将数据读好呢。所以就先加了一个thread.sleep，这样测试下来，错误明显减少了不少，但是这并不能解决根本的问题
所以想当客户端将response读完以后，肯定对服务端有个回应才对，即告诉服务端我这边已经读取好了，你可以关闭了，所以在再服务端的代码中加入了对socket inputstream的读取，是加载write以后的。代码比较简单，如下
BufferedWriter responseWriter = BufferedReader reader =
responseWriter = new BufferedWriter(new OutputStreamWriter(
socket.getOutputStream()));
reader = new BufferedReader(new InputStreamReader(
socket.getInputStream()));
StringBuffer content = new StringBuffer();
content.append("&html&");
content.append("&head&");
content.append("&title&");
content.append("httpy web server");
content.append("&/title&");
content.append("&/head&");
content.append("&body&");
content.append("&div&");
content.append("&a&server:httpy&/a&");
content.append("&/div&");
content.append("&/body&");
content.append("&/html&");
StringBuffer header = new StringBuffer();
header.append("HTTP/1.1 200 OK");
header.append(BR);
header.append("Content-Length:");
header.append(content.toString().getBytes("utf-8").length);
header.append(BR);
header.append("Content-Type:text/UTF-8");
header.append(BR);
header.append(BR);
responseWriter.write(header.toString());
responseWriter.write(content.toString());
// 这里的flush也是必须的。
responseWriter.flush();
// Thread.sleep(10);
// 这里等待客户端读取完response返回通知。
String line =
while ((line = reader.readLine()) != null) {
System.out.println(line);
} catch (Exception e) {
e.printStackTrace(); } finally {
try { if (responseWriter != null) {
responseWriter.close(); }
} catch (IOException e) { e.printStackTrace();
try { if (socket != null) {
socket.close(); }
} catch (IOException e) { e.printStackTrace();
} } 综上所述，修改好以上的代码，1000线程做1000个http request也是没有什么问题的。代码可以优化的地方 thread的地方可以使用线程池，不需要一个request对应一个thread.只需要线程池就可以了。
--------------------------------------
加几个细节的问题，调试了一下代码，发现reader.readLine()的block分成2个部分，客户端读取第一部分 POST / HTTP/1.1 Content-Length: 0 Host: 192.168.1.83:8416 Connection: Keep-Alive的时间节点是在读取服务端的response之前。之后的第二部分又会block,这次block的release是在客户端的connection关闭后release.也就是在以下代码之后 if (httpPost != null) {
httpPost.releaseConnection(); } if (httpClient != null) {
httpClient.getConnectionManager().shutdown(); }这也就保证了服务端的socket in out的关闭是在客户端主动关闭以后服务端才释放资源的。
--------------------------------------
String line =while ((line = reader.readLine()) != null) {
System.out.println(line);}改成String line =while (!(line = reader.readLine()).isEmpty()) {
System.out.println(line);}当接收到空的时候就退出等待
--------------------------------------
感谢shnulaa，辛苦做了这么多测试。其实，发帖之前我也考虑过你说的这种原因——服务端在客户端未获取到全部数据前就关闭socket引发异常。但是之后发现这个分析还是有疑点：1、按照TCP/IP的4次握手原则，主动关闭的一方在发送fin包之后会停止向接收方发送数据，而被动关闭的一方在接到fin包之后也不再从主动关闭的一方那里读取数据，那出现了上面的情况到底是哪个环节出了问题呢？2、我之前也试过在关闭前让线程sleep一会给客户端留出时间，但是后来一想，服务器在设计的时候真的会在close前sleep一段时间吗，服务器要的就是快速响应，阻塞一段时间的做法就是在降低响应速度，而且，从我下的一个开源的HTTP服务器来看，它的服务端完全没有采取sleep之类的做法。3、我在7楼提供了一种解决方法，就是在服务端添加一个BufferReader来读取客户端发送的消息，问题就不会出现了，不用sleep，也不用在客户端接受服务端关闭信息。如果是因为服务端提前关闭的原因，上面这种做法是无法掩盖问题的。当然，shnulaa所作的分析确实揭示了问题的一个现象，后续的分析我觉得需要结合这两种解决方法分析，当然还是感谢各位的解答。待续..
--------------------------------------
这几天做别的事没好好处理这个问题，不过最近看到这样一篇介绍好像能很好的解释我所遇到的问题，链接是：http://my.oschina.net/costaxu/blog/127394，其中介绍的第3中发送RST的情况大概就是我这种情况，大概意思也跟fei1710先前的说法类似。最近事较多没来得及验证，验证主要是解释下面两个问题：1、服务端发送RST包的情况；2、浏览器在接到RST包后显示正常与异常的时机问题。初步解释参考上面链接的第3点，测试待续，测试完毕就结贴..}