HTTP 调用超时、重试、并发？

http调用，走的是http协议，但网络层走的是TCP/IP协议

所以一定是需要先建立连接的，所以存在两个超时参数：

1、连接超时 ConnectTimeout , 配置用户建立连接的最长时间

2、读取超时 ReadTimeout ,控制socket 上读取数据的最长等待时间

 

连接超时设置的比较长的问题，会导致一直在尝试进行连接，创建大量的线程，最终崩溃

如果是客户端直接连服务端，那连接超时大概率是服务端的问题

如果是经过了一层nginx , 那连接超时就要考虑nginx的问题了

 

读取超时： 如果读取超时，那服务端的执行会中断 ？

其实类似tomcat的web服务器都把服务端请求提交到线程池处理的，只要服务端收到了请求，网络层的超时与断开便不会影响服务端的执行

所以读取超时，并不能说明服务器那儿没干事儿

大部分的读取超时，可以认为是服务器业务逻辑的时间

大部分的连接超时，可以认为是网络问题或者服务不在线

通常读取超时设置不超过30秒

 

重试 get,head请求在浏览器上会主动进行重试

 

最终总结：

	误区一	误区二	概念
读取超时	读取超时时，服务端的执行也停止 其实不是，服务端的线程池接收到任务， 网络的情况就与实际服务端操作无关了	读取超时设置越长服务的成功率越高？ 客服端遇到服务超时，可能会受到拖累而创建 大量线程，最终崩溃	可以把读取超时的时间大概率认为是服务端业务处理时间
连接超时	连接超时设置很大 如果连接不上，一般就是网络问题或者是 服务不在线，设置短一些反而可以快速失败； 如果是纯内网调用，更是应该设置更短	连接的是哪儿？ 有的是客户端与服务端直接连接，所以超时 可以直接服务端的服务情况；如果中间有nginx 就应该考虑nginx的问题了
重试机制	对于get,head请求一般都会有个重试机制 API的设计里，如果是get请求一般是无状态的 如果有状态的接口一般不定义为get		如果进行重试，一定要保证服务的幂等性
并发限制

为啥没有写超时？

因为数据都写入到TCP缓冲区，从缓冲区写入到服务端，属于本地的操作，不存在超时之说。