http调用，走的是http协议，但网络层走的是TCP/IP协议
所以一定是需要先建立连接的，所以存在两个超时参数：
1、连接超时 ConnectTimeout , 配置用户建立连接的最长时间
2、读取超时 ReadTimeout ,控制socket 上读取数据的最长等待时间
连接超时设置的比较长的问题，会导致一直在尝试进行连接，创建大量的线程，最终崩溃
如果是客户端直接连服务端，那连接超时大概率是服务端的问题
如果是经过了一层nginx , 那连接超时就要考虑nginx的问题了
读取超时： 如果读取超时，那服务端的执行会中断 ？
其实类似tomcat的web服务器都把服务端请求提交到线程池处理的，只要服务端收到了请求，网络层的超时与断开便不会影响服务端的执行
所以读取超时，并不能说明服务器那儿没干事儿
大部分的读取超时，可以认为是服务器业务逻辑的时间
大部分的连接超时，可以认为是网络问题或者服务不在线
通常读取超时设置不超过30秒
重试 get,head请求在浏览器上会主动进行重试
最终总结：
| 误区一 | 误区二 | 概念 | ||
| 读取超时 | 读取超时时，服务端的执行也停止 其实不是，服务端的线程池接收到任务， 网络的情况就与实际服务端操作无关了 |
读取超时设置越长服务的成功率越高？ 客服端遇到服务超时，可能会受到拖累而创建 大量线程，最终崩溃 |
可以把读取超时的时间大概率认为是服务端业务处理时间 | |
| 连接超时 | 连接超时设置很大 |
连接的是哪儿？ 有的是客户端与服务端直接连接，所以超时 |
||
| 重试机制 | 对于get,head请求一般都会有个重试机制 API的设计里，如果是get请求一般是无状态的 如果有状态的接口一般不定义为get |
如果进行重试，一定要保证服务的幂等性 | ||
| 并发限制 | ||||
为啥没有写超时？
因为数据都写入到TCP缓冲区，从缓冲区写入到服务端，属于本地的操作，不存在超时之说。