Linux网络原理及编程(5)——第十五节 TCP的连接(三次握手、四次挥手)

目录

三次握手

四次挥手

我们来重点说说两个状态:CLOSE_WAIT和TIME_WAIT

【CLOSE_WAIT】

【TIME_WAIT】


各位好,博主新建了个公众号《自学编程村》,拉到底部即可看到,有情趣可以关注看看哈哈,关注后还可以加博主wx呦~~~

本节我们来介绍TCP连接的建立和断开。我们主要介绍两个过程、两个状态。

两个过程即三次握手和四次挥手;两个状态指TIME_WAIT和COLSE_WAIT状态。

我们本节,会始终围绕着这张图来展开:

三次握手

我们还是按照列点是来分析,这样会使得条理比较清晰:

1、当客户端向服务器发起第一次请求(SYN)时,其自身就会处于一种SYN_SEND的状态(即等待发送)

2、处于listen状态的服务器接收到客户端发起的请求之后,会进入SYN_RCVD状态(即等待接收)

3、服务器向客户端发出SYN+ACK,服务器收到之后,由原来的SYN_SEND状态变为ESTABLISED(连接)状态。

4、当服务器收到这个ACK之后,便同样会进入到ESTABLISED状态

过程比较简单,就是上述那样。

【注意】

链接本身是有成本的:耗费空间+时间,而TCP是面向连接的,即三次握手成功之后,需要client和server共同维护

注意到,我们这里的ACK和SYN有一次压缩起来了,所以如果硬要说的话,是四次握手,但是其默认都是压缩起来了,所以我们就按照三次握手来说。

a.那为啥是要有三次握手?一次、两次、四次不行?

首先一次肯定是不行的,为什么呢?如果发出去一个SYN就算建立连接了,那这和udp有什么区别呢,即便服务器没有拿到这个SYN请求,我的客户端已经认为建立连接了?况且服务器连接的维护是需要成本的。如果一次就建立连接的话,如果一个恶意软件在短时间内对我进行大量的SYN,那我的服务器不就崩掉了?

b.那两次呢?

如果是这样的话,那服务器发回去一个ACK之后,它就直接认为自己建立连接了。这本质上和一次握手并没有什么差别。

一次和两次握手极容易收到SYN洪水攻击:无条件的发SYN就建立连接的话,那我大量的发SYN,服务器就直接挂掉了。

c.那为什么要三次呢?

我们说TCP是全双工的,所以,双方在通信之前,需要讲信道的状况验证一下是否通畅。即客户端和服务器都至少有一次收、有一次发。  故:用最小的成本验证全双工。

如果是四次握手的话,那前三次的报文丢失我们不怕,但是第四次的报文我们还是害怕丢失的,多这个一次就没有意义了。更多的也是一样的道理。(并且不要让服务器出现连接建立误判的清空,从而减少服务器的资源浪费)

我们再来说说四次挥手

四次挥手

首先,为什么要四次挥手?理由很简单:

TCP是全双工的,即服务器和客户端二者是双向的,地位是对等的。那么二者都要断开连接,客户端关闭后,服务器给个ACK,服务器关闭后,客户端再给个ACK。

即我们双方达成共识之后才可以断开连接。(一定是双方都断开了连接)

【四次挥手的状态变化】

1、当我将断开连接的FIN发出去之后,我就进入了FIN_WAIT_1状态

2、服务器返回ACK(这里的ACK还是可以携带数据的),然后服务器进入CLOSE_WAIT状态。(关闭等待)

 此时,我们认为客户端向服务器的通信信道关闭了,即客户端就不会再给服务器发送数据了。即在客户都应用层表现为close(sock)。

3、客户端在收到服务器的ACK后,就处于FIN_WAIT_2状态。

4、紧接着,服务器给客户端又发了一个FIN,表示服务器也要关闭自己到客户端的信道。这个时候,服务器进入到LAST_ACK状态

5、在客户端收到服务器的FIN之后,再次向服务器发送ACK,此时,客户端进入TIME_WAIT状态。

6、当客户端经历了一段时间之后,由TIME_WAIT状态进入CLOSE状态

我们来重点说说两个状态:CLOSE_WAIT和TIME_WAIT

主动断开的一方会最终进入TIME_WAIT状态,而另一方如果不关闭连接,则会处于CLOSE_WAIT状态。

【CLOSE_WAIT】

为什么会进入到CLOSE_WAIT状态?本质上就是因为你的代码有bug——没有把使用完的套接字关掉。这样会浪费大量的系统资源

(半关闭问题)

就是服务器先退出了。但是客户端还没有退出。

解决方法:很简单,把你的socket文件描述符close掉就行了。

【TIME_WAIT】

对于最后一个ACK,其也是有可能丢失的。

可是在发送完ACK后,假如没有这个TIME_WAIT,客户端会认为连接已经断开,然后释放连接资源。那这个ACK丢失了怎么办?我们的服务器会进行超时重传。可是这个时候客户端已经把连接关了。那么这个服务器会一直挂在LAST_ACK的状态,就会浪费服务器的资源。

所以就衍生出了TIME_WAIT。就是客户端(主动断开连接的一方)先等等,等待的意义:

(1)防止最后一个ACK丢失,进而尽快释放服务器的资源;(2)等待历史数据在网络上消散,即有可能通信结束的报文优先收到,之前还有数据(历史数据)没有被客户端收到。

(等待的时间是通信一个来回最多花费的时间:2MSL)

如果服务器重传了若干次都没有响应,那其也就强行关闭了。(但是这种情况是比较小的)

 在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的:

 1、服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).

2、这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.

3、由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip,源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题

 

使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1即可, 表示允许创建端口号相同但IP地址不同的多个socket描述符

好啦,本节的内容就到这里啦~~

原创不易,如果觉得写的不错,就点个赞呗~~~笔芯~~~~

下面是笔者的微信公众号,也欢迎来关注呀~~~

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

jxwd

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值