TCP为什么要三次握手与四次分手?
TCP协议简介
TCP协议是五层协议中运输层的协议,下面依赖网络层、链路层、物理层,对于一个报文想发到另一台机器(假设是服务器)上对等层,每一个所依赖的层都会对报文进行包装,例如TCP协议就依赖网络层的IP协议,所以发送的报文会经过如下封装:
当这个数据包到达服务器时,服务器的网络层会对IP相关协议内容解封装、校验,然后运输层对TCP层进行解封,解封涉及到一系列的步骤,例如这个数据包是要干嘛?是发给我的吗?这些操作需要根据TCP报文的首部信息来判断,首部包含以下内容:
主要通过首部信息来了解这个包是干嘛的,关于首部信息,这儿需要用到的几个如下:
ACK : TCP协议规定,只有ACK=1时有效,也规定连接建立后所有发送的报文的ACK必须为1
SYN(SYNchronization) : 在连接建立时用来同步序号。当SYN=1而ACK=0时,表明这是一个连接请求报文。对方若同意建立连接,则应在响应报文中使SYN=1和ACK=1. 因此, SYN置1就表示这是一个连接请求或连接接受报文。
FIN (finis)即完,终结的意思, 用来释放一个连接。当 FIN = 1 时,表明此报文段的发送方的数据已经发送完毕,并要求释放连接。
注意:URG、ACK、PSH、PST、RST、SYN、FIN只有一位,也就是只有0或者1两种状态。
TCP协议三次握手
下面这张图不是本人画的,如果作者看到可以联系我为图片设置您博文的外连接。
第一次握手,客户端先向服务端发送一个请求连接的报文段,这个报文段SYN
位设置为1,序列号Seq(Sequence Number)
设置为某一值,假设为X,发送出去之后客户端进入SYN_SEND
状态,等待服务器的确认;
第二次握手:服务器收到SYN
报文段。服务器收到客户端的SYN
报文段,需要对这个SYN
报文段进行确认,设置Acknowledgment Number为x+1(Sequence Number+1);
同时,自己自己还要发送SYN请求信息,将SYN
位置为1,Sequence Number
为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK
报文段)中,一并发送给客户端,此时服务器进入SYN_RECV
状态;
第三次握手:客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number
设置为y+1,向服务器发送ACK报文段,这个报文段发送完毕以后,客户端和服务器端都进入ESTABLISHED
状态,完成TCP三次握手。
完成了三次握手,客户端和服务器端就可以开始传送数据。以上就是TCP三次握手的总体介绍。
为什么要三次握手而不是两次?
为什么非要进行三次连接呢?两次行吗?在谢希仁的《计算机网络》中是这样说的:
为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。如下:
“已失效的连接请求报文段”的产生在这样一种情况下:client
发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server
。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用“三次握手”,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。”,防止了服务器端的一直等待而浪费资源。
第三次握手失败了怎么办?
在tcp三次握手中 第二次握手完成后connect 就成功返回了 如果第三次握手的ack包丢了 此时 客户端已认为连接是成功的,如果没有应用层的心跳包,客户端会一直维护这个连接 请问如何避免这种情况?
第二次握手服务器收到SYN包,然后发出SYN+ACK数据包确认收到并且请求建立连接,服务器进入SYN_RECV状态。而这个时候第三次握手时客户端发送ACK给服务器失败了,服务器没办法进入ESTABLISH状态,这个时候肯定不能传输数据的,不论客户端主动发送数据与否,服务器都会有定时器发送第二步SYN+ACK数据包,如果客户端再次发送ACK成功,建立连接。
如果一直不成功,服务器肯定会有超时(大概64s)设置,超时之后会给客户端发RTS报文(连接重置),进入CLOSED状态,防止SYN洪泛攻击,这个时候客户端应该也会关闭连接。
SYN洪泛攻击:
SYN攻击利用的是TCP的三次握手机制,攻击端利用伪造的IP地址向被攻击端发出请求,而被攻击端发出的响应 报文将永远发送不到目的地,那么被攻击端在等待关闭这个连接的过程中消耗了资源,如果有成千上万的这种连接,主机资源将被耗尽,从而达到攻击的目的。
TCP协议四次分手
还是这个图镇帖:
四次分手,意思是某一端(可以使客户端,也可以是服务器端)想结束会话断开连接,那么具体流程是:
第一次分手:主机1,设置序列号Seq(Sequence Number)
和确认包ACK(Acknowledgment Number)
,假设seq为x+2,ACK=y+1,再将FIN标志位设置为1,向主机2发送FIN报文段;之后主机1进入FIN_WAIT_1
状态;这表示主机1没有数据要发送给主机2了;
第二次分手:主机2收到了主机1发送的FIN报文段,向主机1回一个ACK
报文段(其值为接收到的FIN报文的seq值+1);主机1进入FIN_WAIT_2
状态,等待主机二的断开请求包FIN;
第三次分手:主机2向主机1发送FIN
报文段,意思是我可以断开连接了,请求关闭连接,同时主机2进入CLOSE_WAIT
状态;
第四次分手:主机1收到主机2发送的FIN
报文段,向主机2发送ACK
报文段,值为刚刚接收到的FIN包Seq值+1,然后主机1进入TIME_WAIT
状态;主机2收到主机1的ACK
报文段以后,就关闭连接;此时,主机1等待2MSL
后依然没有收到回复,则证明Server端已正常关闭,那好,主机1也可以关闭连接了。
为什么要四次挥手
TCP是全双工模式,这就意味着,当主机1发出FIN
报文段时,只是表示主机1已经没有数据要发送了,主机1告诉主机2,它的数据已经全部发送完毕了;但是,这个时候主机1还是可以接受来自主机2的数据;当主机2返回ACK
报文段时,表示它已经知道主机1没有数据发送了,但是主机2还是可以发送数据到主机1的;当主机2也发送了FIN
报文段时,这个时候就表示主机2也没有数据要发送了,就会告诉主机1,我也没有数据要发送了,之后彼此就会愉快的中断这次TCP连接。如果要正确的理解四次分手的原理,就需要了解四次分手过程中的状态变化。
四次挥手状态解释
FIN_WAIT_1
: 这个状态要好好解释一下,其实FIN_WAIT_1
和FIN_WAIT_2
状态的真正含义都是表示等待对方的FIN
报文。而这两种状态的区别是:FIN_WAIT_1
状态实际上是当SOCKET在ESTABLISHED
状态时,它想主动关闭连接,向对方发送了FIN
报文,此时该SOCKET即进入到FIN_WAIT_1
状态。也就是,发出FIN包之后进入FIN_WAIT_1状态
而当对方回应ACK
报文后,则进入到FIN_WAIT_2
状态,当然在实际的正常情况下,无论对方何种情况下,都应该马上回应ACK
报文,所以FIN_WAIT_1
状态一般是比较难见到的,而FIN_WAIT_2
状态还有时常常可以用netstat看到。也就是,发出ACK报文之后进入FIN_WAIT_2状态
主动方FIN_WAIT_2
:上面已经详细解释了这种状态,实际上FIN_WAIT_2
状态下的SOCKET,表示半连接,也即有一方要求close
连接,但另外还告诉对方,我暂时还有点数据需要传送给你(ACK
信息),稍后再关闭连接。
主动方CLOSE_WAIT
:这种状态的含义其实是表示在等待关闭。怎么理解呢?当对方close一个SOCKET后发送FIN
报文给自己,你系统毫无疑问地会回应一个ACK
报文给对方,此时则进入到CLOSE_WAIT
状态。接下来呢,实际上你真正需要考虑的事情是察看你是否还有数据发送给对方,如果没有的话,那么你也就可以 close这个SOCKET,发送FIN
报文给对方,也即关闭连接。所以你在CLOSE_WAIT
状态下,需要完成的事情是等待你去关闭连接。
被动方LAST_ACK
: 这个状态还是比较容易好理解的,它是被动关闭一方在发送FIN
报文后,最后等待对方的ACK
报文。当收到ACK
报文后,也即可以进入到CLOSED
可用状态了。也就是接收到了对方的FIN包,自己发出了ACK以及FIN包之后的状态
被动方TIME_WAIT
: 表示收到了对方的FIN
报文,并发送出了ACK
报文,就等2MSL
后即可回到CLOSED
可用状态了。如果FIN_WAIT1
状态下,收到了对方同时带FIN
标志和ACK
标志的报文时,可以直接进入到TIME_WAIT
状态,而无须经过FIN_WAIT_2
状态。
主动方CLOSED
: 表示连接中断。
TCP状态图
状态图解释
- CLOSED:起始点,在超时或者连接关闭时候进入此状态。
- LISTEN:svr端在等待连接过来时候的状态,svr端为此要调用socket, bind,listen函数,就能进入此状态。此称为应用程序被动打开(等待客户端来连接)。
- SYN_SENT:客户端发起连接,发送SYN给服务器端。如果服务器端不能连接,则直接进入CLOSED状态。
- SYN_RCVD:跟3对应,服务器端接受客户端的SYN请求,服务器端由LISTEN状态进入SYN_RCVD状态。同时服务器端要回应一个ACK,同时发送一个SYN给客户端;另外一种情况,客户端在发起SYN的同时接收到服务器端得SYN请求,客户端就会由SYN_SENT到SYN_RCVD状态。
- ESTABLISHED:服务器端和客户端在完成3次握手进入状态,说明已经可以开始传输数据了。
以上是建立连接时服务器端和客户端产生的状态转移说明。相对来说比较简单明了,如果你对三次握手比较熟悉,建立连接时的状态转移还是很容易理解。接下来服务器端和客户端就进行数据传输。。。。,当然,里面也大有学问,就此打住,稍后再表。下面,我们来看看连接关闭时候的状态转移说明,关闭需要进行4次双方的交互,还包括要处理一些善后工作(TIME_WAIT状态),注意,这里主动关闭的一方或被动关闭的一方不是指特指服务器端或者客户端,是相对于谁先发起关闭请求来说的: - FIN_WAIT_1:主动关闭的一方,由状态5进入此状态。具体的动作时发送FIN给对方。
- FIN_WAIT_2:主动关闭的一方,接收到对方的FIN ACK,进入此状态。由此不能再接收对方的数据。但是能够向对方发送数据。
- CLOSE_WAIT:接收到FIN以后,被动关闭的一方进入此状态。具体动作时接收到FIN,同时发送ACK。
- LAST_ACK:被动关闭的一方,发起关闭请求,由状态8进入此状态。具体动作时发送FIN给对方,同时在接收到ACK时进入CLOSED状态。
- CLOSING:两边同时发起关闭请求时,会由FIN_WAIT_1进入此状态。具体动作是,接收到FIN请求,同 时响应一个ACK。
- TIME_WAIT:最纠结的状态来了。从状态图上可以看出,有3个状态可以转化成它,我们一一来分析:
a.由FIN_WAIT_2进入此状态:在双方不同时发起FIN的情况下,
主动关闭的一方在完成自身发起的关闭请求后,接收到被动关闭一方的FIN后进入的状态。
b.由CLOSING状态进入:双方同时发起关闭,都做了发起FIN的请求,
同时接收到了FIN并做了ACK的情况下,由CLOSING状态进入。
c.由FIN_WAIT_1状态进入:同时接受到FIN(对方发起),ACK(本身发起的FIN回应),
与b的区别在于本身发起的FIN回应的ACK先于对方的FIN请求到达,
而b是FIN先到达。这种情况概率最小。
关闭的4次连接最难理解的状态是TIME_WAIT,存在TIME_WAIT的2个理由:
1.可靠地实现TCP全双工连接的终止。
2.允许老的重复分节在网络中消逝。
TCP为什么要三次握手与四次分手?的更多相关文章
- 通俗大白话来理解TCP协议的三次握手和四次分手
通俗理解: 但是为什么一定要进行三次握手来保证连接是双工的呢,一次不行么?两次不行么?我们举一个现实生活中两个人进行语言沟通的例子来模拟三次握手. 引用网上的一些通俗易懂的例子,虽然不太正确,后面会指 ...
- TCP/IP的三次握手和四次分手以及超时机制
使用INADDR_ANY的时候,往往针对多网卡情况,采用tcp连接方式,需要选择使用哪一个网卡发送,自己猜想应该是使用三次握手机制,如何判断目标地址不可达,应该使用的是超时机制,即握手超时则不可到达. ...
- TCP协议的三次握手和四次分手
HTTP连接 HTTP协议即超文本传送协议(Hypertext Transfer Protocol ),是Web联网的基础,也是手机联网常用的协议之一,HTTP协议是建立在TCP协议之上的一种应用. ...
- TCP/IP协议三次握手与四次握手流程解析
原文链接地址:http://www.2cto.com/net/201310/251896.html TCP/IP协议三次握手与四次握手流程解析 TCP/IP协议的详细信息参看<TCP/IP协议详 ...
- TCP/IP协议三次握手与四次握手流程解析(转载及总结)
原文地址:http://www.2cto.com/net/201310/251896.html,转载请注明出处: TCP/IP协议三次握手与四次握手流程解析 一.TCP报文格式 TCP/IP协议的详 ...
- 简析TCP的三次握手与四次分手【转】
转自 简析TCP的三次握手与四次分手 | 果冻想http://www.jellythink.com/archives/705 TCP是什么? 具体的关于TCP是什么,我不打算详细的说了:当你看到这篇文 ...
- TCP三次握手与四次分手超简单解析
关于TCP三次握手四次分手,之前看资料解释的都很笼统,很多地方都不是很明白,所以很难记,前几天看的一个博客豁然开朗,可惜现在找不到了.现在把之前的疑惑总结起来,方便一下大家. 先上个TCP三次握手和四 ...
- TCP/IP协议三次握手与四次握手
TCP/IP协议三次握手与四次握手流程解析 一.TCP报文格式 TCP/IP协议的详细信息参看<TCP/IP协议详解>三卷本.下面是TCP报文格式图:图1 TCP报文格式 上图中有几个 ...
- 通俗大白话来理解TCP协议的三次握手和四次断开
from : https://blog.csdn.net/Neo233/article/details/72866230?locationNum=15&fps=1%20HTTP%E6%8F%A ...
随机推荐
- Java基础:String类详解,案例用户登录实现,案例手机号截取实现,案例敏感词替换实现;StringBuilder类详解,StringBuilder和String相互转换,附练习案例.
1.API 1.1 API概述-帮助文档的使用 什么是API API (Application Programming Interface) :应用程序编程接口 java中的API 指的就是 JDK ...
- Java基础-方法的重写和重载
重载(Overload)和重写(Override) 重载是在同一个类里面,方法名字相同,而参数不同.返回类型可以相同也可以不同.每个重载的方法(或者构造函数)都必须有一个独一无二的参数类型列表. 重写 ...
- SQL Server中datetimeset转换datetime类型问题浅析
在SQL Server中,数据类型datetimeoffset转换为datetime类型或datetime2类型时需要特别注意,有可能一不小心你可能会碰到下面这种情况.下面我们构造一个简单案例,模拟一 ...
- Oracle中除数为0的两种解决办法(decode与nullif)
Oracle中Decode函数,语句DECODE(tag,''ZCGS'',0,1)=decode(''@corp-No@'',''6010'',1,0) decode(字段或字段的运算,值1,值2, ...
- jmeter+jdk环境配置
一:JDK 安装配置:https://www.oracle.com/java/technologies/javase/javase-jdk8-downloads.html ,下载JDK8 安装 1. ...
- css 自定义悬浮窗写法
HTML: css(sass): 复制代码 .info { } &:hover::after { content: attr(data-title); display: inline-bloc ...
- flink集群模式安装配置
一.手动下载安装包 wget http://mirrors.tuna.tsinghua.edu.cn/apache/flink/flink-1.6.1/flink-1.6.1-bin-hadoop27 ...
- Linux之远程登录和文件传输
一---导读 在实际开发过程中,程序员和Linux系统是远程的,并且可能有多个程序员一同在同一个linux系统上工作,那么这个时候就需要我们远程登录linux系统 二---软件介绍 xshell 和 ...
- mapboxgl实现带箭头轨迹线
最近在使用mapboxgl实现轨迹展示时,想实现类似高德地图导航轨迹效果,然而并未在网上找到类似示例.经一番研究与尝试,最终解决,效果如下. 添加箭头核心代码如下,只需在配置layout中添加symb ...
- 免费的java代码混淆,程序加密
java代码可以反编译,特别是放在客户端的程序很用被剽窃,盗用.保护程序一般都有以下几个方法: 1.将class文件加密,这个是最安全的,但也费事儿,因为要重写classloader来解密class文 ...