美文网首页
关于TCP连接与关闭的问题总结

关于TCP连接与关闭的问题总结

作者: 落雨松 | 来源:发表于2019-03-24 15:53 被阅读0次

首先介绍一下TCP连接三次握手和四次挥手

一、TCP三次握手

假如是客户端向服务端建立连接

①第一次握手: 客户端发送一个 SYN 包(这个SYN包包括:seq = x)给服务端,进入“SYN_SEND”状态。
②第二次握手:服务端收到SYN包后,发回一个确认包SYN(这个包包括:ack = x + 1),同时自己也发送一个SYN包(seq = y)
③第三次握手:客户端就发送一个ACK(这个ACK = 收到的ack + 1)。

然后三次握手建立,客户端开始发送数据

******重点问题******:

1、为什么要三次握手而不是两次握手?

反证法:假如tcp连接是两次握手,当客户端发起第一次握手后,服务端发出确认连接的第二次握手,如果第二次握手在网络中丢失,那么客户端将会重新发起连接,但是服务端并不知道客户端是否已经收到连接,如果一段时间内没有收到数据,那么就会重传这次确认,这样客户端和服务端就会形成一个死锁,我在等你确认,你在等我确认。

2、什么是TCP半连接和全连接?

所谓的半连接和全连接其实就是两个队列,也就是半连接队列和全连接队列,当TCP第一次握手时候,被请求连接方就会进入一个半连接状态,并且把这个状态保存到一个半连接队列中去,然后第二次握手,主动连接的一方收到确认连接后,这个连接状态就变成全连接状态,也就是移到了全连接队列中,这其实就是一个状态的标识,依次来告诉服务器是否准备就绪,可以发送数据。

二、TCP四次挥手

假如是客户端主动关闭
①第一次挥手:客户端发送一个FIN关闭连接的包,包含确认序号
②第二次挥手:服务端收到FIN包,发送给客户端一个ACK确认包(这个确认包中确认序号为收到的确认序号+1),然后进入close-wait状态
③第三次挥手:服务端发送FIN包,确认关闭连接,也发送一个ACK给客户端。
④第四次挥手:客户端收到这个FIN后,发送一个确认序号(ACK),类似第二次挥手,这个确认序号为收到的确认序号+1。然后进入“time-wait”状态。

*******重点问题********:

1、time-wait的目的?

time-wait发生在TCP挥手的第四次挥手之后,这个状态的主要目的在于,客户端要确认最后一个ACK能够顺利的发送到服务端,当服务端没有收到ACK确认报文,那么一定是会重传这个FIN包。

2、time-wait为什么是2倍的msl?

当第四次挥手发送完一个ACK报文的时候,它到达服务端的最大报文段传输时间为msl,在极端情况下,刚好一个msl的时候ACK报文段丢失,那么服务端就会重传一个FIN,那么它发送到客户端的时间就又是一个msl,那么这种情况是极端的情况,也就是最大会有2倍的msl时间间隔,当丢失后重传的FIN到达客户端的时候,那客户端就会重新设置为2倍的msl,并且重传ACK。

3、close-wait得目的?

close-wait发生在第二次挥手后:当客户端第一次挥手,发送一个FIN报文,然后服务端不会立即发送FIN关闭连接的请求,而是发送一个ACK确认客户端关闭,这个时候客户端无法再向服务端发送数据,但是服务端会有一个close-wait,在这close-wait期间将未发送完的数据全部发送给客户端,当数据发送完了以后呢,就开始第三次挥手,发送一个FIN确认关闭连接。

4、客户端有非常多的close-wait如何处理?

首先出现这个问题的原因是服务端长时间没有发送FIN给客户端造成的,这种问题情况比较多,很关键的在于程序的编写问题,比如我们开启一个socket循环不断的监听端口信息,还有就是数据连接没有关闭,都可能会造成这种情况,在写代码的时候要尽量避免这些情况,再则就是服务器默认的close-wait时间没有修改,我记得好像是7200秒,也就是2个小时,这样就非常容易造成大量的close-wait堆积,这里我们可以修改一下tcp_keepalive的参数值,这个参数值就是长连接的超时关闭自动发送FIN的一个时间。

三、其他

1、KCP协议

KCP是一个快速可靠协议。它主要的设计目的是为了解决在网络拥堵的情况下TCP协议网络速度慢的问题,增大网络传输速率,但相当于TCP而言,会相应的牺牲一部分带宽。
kcp没有规定下层传输协议,一般用UDP作为下层传输协议。kcp层协议的数据包在UDP数据报文的基础上增加控制头。当用户数据很大,大于一个UDP包能承担的范围时(大于MSS),kcp会将用户数据分片存储在多个kcp包中。因此每个kcp包称为一个分片。

2、为什么TCP连接要三次而关闭要四次?

这是因为TCP关闭是半关闭的,也就是是TCP关闭连接是需要两方都要关闭并且都要确认对方已经收到关闭的消息,而TCP连接是被动连接,一方知道要连接而另一方知道被连接的一方知道已经连接的请求即可。

3、tcp滑动窗口和拥塞窗口机制原理

首先基本概念:
①滑动窗口:主要是为了进行流量控制的窗口,目的是让发送方知道接收方所能接收的缓存大小。

基本原理:这里必须知道ACK的概念,ACK包含两个信息,第一个信息就是确认序号,这个确认序号的意义在于接收方和发送方的数据传输的顺序和正确性,比如接收方收到 1到n-1 的数据,那么接收方就会发送一个确认序号 n ,然后发送方如果再次发送数据,如果不是 n后面的数据,那么接收方还是会重传这个 n,以保证数据的正确和顺序。然后ACK包含的第二信息就是滑动窗口的大小,这里如果设置为m,那么发送方下一次能够发送的数据就等于y = m - (x - n),这个公式里面的m 代表窗口大小,x 代表已经发送的数据量,n就是上面说的确认号。然后滑动窗口的大小是可以根据这个数据量的大小变化的,主要的目的在于降低接收方数据的溢出。总之:滑动的窗口的目的就在于流量控制。

②拥塞窗口:而拥塞窗口的主要目的在于拥塞控制,为了避免网络在传输过程中传输的数据量一下子过大或者过小,造成网络资源的紧张和浪费,所以拥塞窗口就是为了提高网络吞吐量的机制。

基本原理:其基本原理就在于拥塞控制算法,比如慢开始和拥塞避免,快重传和快恢复。

4、拥塞控制算法

“慢开始”:
对于慢开始是这样的:首先在最初的时候,拥塞窗口的值为一个mss,也就是最大报文段 为 1,然后每一次新的ACK确认号到达就增加 1 ,直到达到一个慢开始门阀。

“拥塞避免”:
当达到这个慢开始门阀以后呢,就开始拥塞避免的算法,拥塞避免的算法其实就是比慢开始更慢增长的算法,也就是一个RTT时间继续增加1 , 当然不可能无限的增长下去,当网络出现拥塞后,慢开始门阀就变成原来的一半,然后拥塞窗口的值变为原来的1,然后继续重复之前的过程。

“快重传”与“快恢复”:
达到重传的情况有两种:第一是超时,第二是如果收到3个相同的ACK ,如果是超时,说明出现了严重的拥塞,那么久采取慢开始算法快恢复,重新将窗口值设为1 , 如果是收到3个相同的ACK,那么可能是轻度拥塞,这时采用快重传,然后启动拥塞避免算法进行快恢复,重新设置这时的窗口值为慢开始门阀。

相关文章

网友评论

      本文标题:关于TCP连接与关闭的问题总结

      本文链接:https://www.haomeiwen.com/subject/hxduvqtx.html