Socket连接超时

Socket.connect连接超时有二种情况：

1.由于网络的问题，TCP/IP三次握手时间>timeout的设置时间。这在国外访问weibo时，并且网络环境极差的情况下有可能发生。
解决的办法：调大socket.connect方法中的timeout参数值，比如50s，linux默认最高是70s，如果超过70s没有意义，linux会采用70s.
但是当调大之后，发现不到10s就报timeout exception。
通过国外的机器ping api.weibo.com发现unreachable。
说明客户端在传输层之下的网络层就发现连个Syn的报文都发不出去，更不用说三次握手了，客户端直接失败并抛timeout exception。

经验：在connection timeout诊断的第一步应该是ping一下确认网络层没有问题。
注：客户端设置了timeout，但并不会等到超时才返回异常。客户端只要第一时间发现连接失败，就会抛timeout exception。


2.如果timeout设置的时间足够，但是由于服务器端的处理能力较差，比如缓冲连接队列较小，而应用层的处理能力没有连接缓冲快，导致缓冲连接占满，而拒绝新的连接。
在服务端因为连接队列占满而拒绝服务的期间，客户端的通过TCP协议重试三次。每次的时间翻倍。
如果三次时间的累加<timeout参数值且能连接上，属于正常情况，表示队列腾出空位放当前连接。
如果三次时间的累加<timeout参数值且未能连接上，则客户端会立刻抛出timeout exception,而不等timeout到期才抛。

 

附：读写超时

1.读写超时

read超时设置有意义,在服务器处理能力差，但最终会响应的情况下，可以将客户端的等待响应时间设长一些。如果太长的话，由于客户端使用的是BIO的方式，线程会一直阻塞在IO而导致挂起。当客户端的处理能力明显快于服务端，这样挂起的线程会很多。

不管客户端还是服务器端，当有很多线程阻塞时，对机器的性能都会影响。我在weibo的论坛上看到有人在read timed out后，将soTimeout的时间设为100s。这是很危险的，新浪的服务器一旦崩溃，自己的服务器也会由于大量线程积压崩溃。

因为线程在挂起之后，它掌握的资源并不会释放，比如内存，直到阻塞完成。同时大量线程的挂起就意味着系统要做大量上下文的恢复并调度执行。

解决办法：

如果客户端使用NIO的方式，如果服务端的响应能标出客户端的请求，则线程在客户端请求之后，完全可以把请求放入一个BlockQueue，然后利用Future或Wait/Notify等机制在带着请求标志的响应返回的时候，唤想队列中的请求接着处理，从而实现异步处理，可以用少量线程服务大量请求。

同样，如果服务器端可以使用NIO做到请求每线程处理，而不是连接每线程，可以大大减少线程挂起导致资源的浪费，NIO适用于连接很多，请求很少的场合。另外，Commet又称为服务器推技术，它的主要特点是长连接。避免客户端低效的请求轮询。主要用于聊天室，WEIBO，因为连接多，请求不一定多，同样也适合在服务器端使用NIO

注：read timeout异常时，并不需要ping远程机器，因为它是辅助定位connection timeout，如果ping不通，肯定是conneciton timeout而不会到read timeout。read timeout exception不会导致连接中断。为重试提供了机会。

 

2.write超时一般不象connection timeout和read timeout可以在客户端显示调值，TCP有写重传的概念，一般8m内会重试，否则，直接断开连接。