一、原因(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同时连接跟断开就好比是两个对的人(对的人指的是符合四元组,他们找的都是他们希望的那个)异口同声的说你们要在一起:
张三:我们在一起吧!(同时)
李四:我们在一起吧!(同时)
接着又一起异口同声的说了句:
张三:好啊!
李四:好啊!
也是同时说,但是我们要是知道,这种情况的出现的概率是非常小的,小的不能再小。