HTTP连接要考虑超时，重试和并发之原因

一、原因（why)

连接超时配置得特别长，比如 60 秒。一般来说，TCP 三次握手建立连接需要的时间非常短，通常在毫秒级最多到秒级，不可能需要十几秒甚至几十秒。如果很久都无法建连，很可能是网络或防火墙配置的问题。这种情况下，如果几秒连接不上，那么可能永远也连接不上。因此，设置特别长的连接超时意义不大，将其配置得短一些（比如 1~5秒）即可。如果是纯内网调用的话，这个参数可以设置得更短，在下游服务离线无法连接的时候，可以快速失败。排查连接超时问题，却没理清连的是哪里。通常情况下，我们的服务会有多个节点，如果别的客户端通过客户端负载均衡技术来连接服务端，那么客户端和服务端会直接建立

二原理

首先，我们可以先看一下TCP是如何建立的？
一、TCP建立过程：
1、TCP的三次握手：

第一次握手：客服端向服务器发送请求（syn=1包）,seq=x，进入SYN_SENT状态，等待服务器的确认。
第二次握手：服务器收到了syn包，并且确认收到客服端发送的请求（ack+1），同时服务器也发送一个请求包（syn+ack包），seq=y,此时服务器进入SYN_RECV状态。
第三次握手：客户端收到服务器的SYN+ACK包（SYN+ACK包）后向服务器发送确认包（ACK+1），之后进入ESTABLISHED（此时TCP连接成功，完成三次握手）。

2、 同时打开（相当于四次握手建立）：
同时打开连接是指通信的双方在接收到对方的SYN包之前，都进行了主动打开的操作并发出了自己的SYN包。由于一个四元组（源IP、源端口、目的IP、目的端口）标识一个TCP连接，一个TCP连接要同时打开需要通信的双方知晓对方的IP和端口信息才行，这种场景在实际情况中很少发生。同时打开的流程如下图：

二、TCP连接的断开过程：
1、TCP的四次挥手：

1、Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。
2、Server收到FIN后，发送一个ACK给Client，确认序号为u +
1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
3、Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。
4、Client收到FIN后，Client进入TIME_WAIT状态(主动关闭方才会进入该状态），接着发送一个ACK给Server，确认序号为w

1，Server进入CLOSED状态，完成四次挥手。
2、 同时关闭连接：
同时关闭连接跟同时打开连接基本相似。

三、 常见问题

为什么要三次握手建立连接？ TCP连接是可靠的双工通信，在连接建立阶段必须确认双向通信都是OK的。理论上来讲这需要至少四次交互：
1、Client发送SYN
2、Server响应ACK
3、Server发送SYN
4、Client响应ACK(如果没有这一步，Server无法知道Client能否收到自己的消息）
@1、2两步让Client知道自己和Server之间的双向通信是OK的，3、4两步让Server知道自己和Client之间的双向通信是OK的。实际应用中，2、3两步合并了，所以最终就只有三次握手。
@三次握手还可以解决网络中延迟的重复分组问题。假设TCP连接建立过程只有两次握手：
1、Client发送SYN
2、Server响应ACK
如果出现下面的情况，服务端就会出问题：
3、Client发送SYN Client端超时未收到Server的ACK，重发SYN Server端收到Client重发的SYN，响应ACK
4、Client收到ACK后，和Server正常数据交互，然后关闭连接
5、 Client第一次发送的SYN并未丢失，而是由于网络延迟，现在才到达Server端
6、 Server发送ACK（Server认为TCP连接已建立）
7、Client收到Server的ACK，由于Client认为自己并未请求连接，所以会忽略该ACK（不同于SYN，ACK报文不需要回复）
8、这时Server认为连接已经建立，一直等待客户端数据；客户端却根本不知道有这么一条连接

为什么要四次挥手断开连接
@ TCP连接是全双工的，因此每个方向都必须单独进行关闭:当一方完成它的数据发送任务后就发送一个FIN来终止这个方向的连接，对端收到后回复一个ACK报文，这样双向就需要四次交互。
@ Client主动关闭的情况下，Server收到Client的FIN报文时，仅仅表示Client没有数据发送给Server了；但Server可能还有数据要发送给Client，所以Server可能并不会立即关闭SOCKET，而是先回复一个ACK报文，告诉Client“你发的FIN报文我收到了”。只有等到Server所有的报文都发送完了，才发送FIN报文。也就是说，被动关闭方的ACK和FIN报文多数情况下都是分开发送的，所以需要四次交互。

为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态
@ 为了保证主动关闭方发送的最后一个ACK报文能够到达被动关闭方。因为这个ACK有可能无法到达对端，这样对端会重发FIN报文，这时候主动关闭方需要重发ACK。
@ 保证本连接的所有报文在网络上消失。如果没有这个机制，可能会对新连接产生干扰。举例如下：
1、A和B正常建立TCP连接，数据传输，然后断开连接。但是由于网络传输原因，A发给B的seq为100的报文滞留在了网络上。
2、 A和B再次建立连接，所用IP和端口与1中相同，二者数据传输过程中，B正好请求A发送seq为100的数据，这时1中滞留的报文到达B，TCP认为该报文合法，就接收了这个报文。

总结：
前面讲这么多，都是废话，三次建立就好比打电话（我的另一篇文章有写）
说白了，三次握手之前还没建立关系，不存在数据是传输，当然可以把客户端发送的请求和回复合并一起发过去啦。

四次挥手还是打电话（结束通话那一刻的恋恋不舍）：
张三：先不跟你说了，我这边有事，
李四：好的（表面上我同意的你挂电话，但是我还要说完我没说的）
说完后…
李四：可以结束通话了。
张三：好的（四次挥手结束）
四次的目的完全就是为了确保把未传输完的数据传输过去，以免造成丢包问题。

而在TCP同时连接跟断开就好比是两个对的人（对的人指的是符合四元组，他们找的都是他们希望的那个）异口同声的说你们要在一起：
张三：我们在一起吧！（同时）
李四：我们在一起吧！（同时）
接着又一起异口同声的说了句：
张三：好啊！
李四：好啊！
也是同时说，但是我们要是知道，这种情况的出现的概率是非常小的，小的不能再小。