TCP的三次握手与四次挥手
来源:互联网 发布:c语言的头文件怎么写 编辑:程序博客网 时间:2024/05/17 06:05
为什么建立TCP连接需要三次握手?
原因:为了应对网络中存在的延迟的重复数组的问题
例子:假设client发起连接的连接请求报文段在网络中没有丢失,而是在某个网络节点长时间滞留了,导致延迟到达server。本来这是一个已经失效的连接报文,但是server接收到这个连接报文之后,误认为client发起了新的连接,于是向client发送确认报文段。此时因为没有了连接的3次握手,client不会对server的确认报文作出回应,也不会向server发送数据,server就以为连接已经建立,一直在空等client的数据,这样server的这一部分网络资源就被浪费了。
为什么断开TCP连接需要进行四次挥手 ?
因为TCP连接是全双工的网络协议,允许同时通信的双方同时进行数据的收发,同样也允许收发两个方向的连接被独立关闭,以避免client数据发送完毕,向server发送FIN关闭连接,而server还有发送到client的数据没有发送完毕的情况。所以关闭TCP连接需要进行四次挥手,每次关闭一个方向上的连接需要FIN和ACK两次挥手。
握手,挥手过程中各状态介绍:
3次握手过程状态:
LISTEN: 表示服务器端的某个SOCKET处于监听状态,可以接受连接了。
SYN_SENT: 当客户端SOCKET执行CONNECT连接时,它首先发送SYN报文,因此也随即它会进入到了SYN_SENT状态,并等待服务端的发送三次握手中的第2个报文。SYN_SENT状态表示客户端已发送SYN报文。(发送端)
SYN_RCVD: 表示接受到了SYN报文,在正常情况下,这个状态是服务器端的SOCKET在建立TCP连接时的三次握手会话过程中的一个中间状态。收到客户端的ACK报文后,它会进入到ESTABLISHED状态。(服务器端)
ESTABLISHED:表示连接已经建立了。
4次挥手过程状态:(可参考下图)
FIN_WAIT_1: FIN_WAIT_1状态实际上是当SOCKET在ESTABLISHED状态时,它想主动关闭连接,向对方发送了FIN报文,此时该SOCKET即进入到FIN_WAIT_1状态。(主动方)
FIN_WAIT_2:FIN_WAIT_2状态下的SOCKET,表示半连接,也即有一方要求close连接,但另外还告诉对方,我暂时还有点数据需要传送给你(ACK信息),稍后再关闭连接。(主动方)
TIME_WAIT: 表示收到了对方的FIN报文,并发送出了ACK报文,就等2MSL后即可回到CLOSED可用状态了。如果FIN_WAIT_1状态下,收到了对方同时带FIN标志和ACK标志的报文时,可以直接进入到TIME_WAIT状态,而无须经过FIN_WAIT_2状态。(主动方)
CLOSING(比较少见): 这种状态比较特殊,实际情况中应该是很少见,属于一种比较罕见的例外状态。正常情况下,当你发送FIN报文后,按理来说是应该先收到(或同时收到)对方的 ACK报文,再收到对方的FIN报文。但是CLOSING状态表示你发送FIN报文后,并没有收到对方的ACK报文,反而却也收到了对方的FIN报文。什么情况下会出现此种情况呢?其实细想一下,也不难得出结论:那就是如果双方几乎在同时close一个SOCKET的话,那么就出现了双方同时发送FIN报文的情况,也即会出现CLOSING状态,表示双方都正在关闭SOCKET连接。
CLOSE_WAIT: 这种状态的含义其实是表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己,你系统毫无疑问地会回应一个ACK报文给对方,此时则进入到CLOSE_WAIT状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close这个SOCKET,发送FIN报文给对方,也即关闭连接。所以你在CLOSE_WAIT状态下,需要完成的事情是等待你去关闭连接。(被动方)
LAST_ACK: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN报文后,最后等待对方的ACK报文。当收到ACK报文后,也即可以进入到CLOSED可用状态了。(被动方)
CLOSED: 表示连接中断。
在TCP连接中,当被动关闭连接的一方发送的FIN报文到达时,被动关闭连接的一方会发送ACK确认报文,并且进入TIME_WAIT状态,并且等待2MSL时间段(MSL:maximum segment life)。这么做有下述两个原因:
(1)被动关闭连接的一方在一段时间内没有收到对方的ACK确认数据包,会重新发送FIN数据包,因而主动关闭连接的一方需要停留在等待状态以处理对方重新发送的FIN数据包。否则他会回应一个RST数据包给被动关闭连接的一方,使得对方莫名其妙。
(2)在TIME_WAIT状态下,不允许应用程序在当前ip和端口上和之前通信的client(这个client的ip和端口号不变)建立一个新的连接。这样就能避免新的连接收到之前的ip和端口一致的连接残存在网络中的数据包。这也是TIME_WAIT状态的等待时间被设置为2MSL的原因,以确保网络上当前连接两个方向上尚未接收的TCP报文已经全部消失
。
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- TCP的三次握手与四次挥手
- Tcp三次握手与四次挥手
- Tcp三次握手与四次挥手
- TCP/IP三次握手与四次挥手
- TCP/IP三次握手与四次挥手
- TCP/IP三次握手与四次挥手
- TCP三次握手与四次挥手!
- TCP三次握手与四次挥手
- TCP三次握手与四次挥手
- TCP/IP三次握手与四次挥手
- TCP/IP三次握手与四次挥手
- 异常类自定义封装
- MFC中 OnPaint()与OnDraw的区别
- mysql事务简述
- TCP协议中的URG和PSH标志位的区别
- Socket复制文件编程Demo
- TCP的三次握手与四次挥手
- 反射代码块
- SQL Server 中WITH (NOLOCK)浅析(大自然的搬运工)
- Map的排序Demo
- 图像处理动机(课堂笔记)
- MFC UpdateData()用法
- redis集群安装踩过的坑
- 编译安装PHP
- 刷清橙OJ--A1084.快速傅里叶变换