博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
tcp/ip----三次握手及四次挥手
阅读量:5323 次
发布时间:2019-06-14

本文共 2938 字,大约阅读时间需要 9 分钟。

三次握手与四次挥手

1. 序列号seq

占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生,给字节编上序号后,就给每一个报文段指派一个序号,序列号seq就是这个报文段中的第一个字节的数据编号。

2. 确认号ack

占4个字节,期待收到对方下一个报文段的第一个数据字节的序号,序列号表示报文段携带数据的第一个字节的编号,而确认号指的是期望接受到下一个字节的编号,因此挡墙报文段最后一个字节的编号+1即是确认号。

3. 确认ACK

占1个比特位,仅当ACK=1,确认号字段才有效。ACK=0,确认号无效。

4. 同步SYN

连接建立时用于同步序号。当SYN=1,ACK=0表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使用SYN=1,ACK=1.因此,SYN=1表示这是一个连接请求,或连接接收报文,SYN这个标志位只有在TCP建立连接才会被置为1,握手完成后SYN标志位被置为0.

5. 终止FIN

用来释放一个连接。

 

下图为tcp/ip建立连接到断开连接的流程图

建立连接(三次握手)

第一次握手:客户端会向服务器发出连接请求,其中包括(syn=1,seq=x,ack=0),其含义为,syn=1表示请求建立连接,seq=x表示客户端发送一个x的序列号,假如服务器接收到,请回应一个为x+1的确认号给我。

第二次握手:服务端收到客户端发送过来的连接请求,回复给客户端一个数据包,其中包括(syn=1,seq=y,ack=x+1),其含义为,我收到了你的请求,给你回复了一个x+1的确认号,并给你发送一个为y的序列号,如果服务端收到,请回复一个为y+1的确认号。

第三次握手:客户端收到服务端的回复,发送一个数据包给服务端,其中包括(seq=x+1,ack=y+1),其含义为,我收到了你的回复,并给你发送一个y+1的确认号,现在连接正式建立。

 

中间是连接建立的状态

1.客户端向服务器发出data请求

2.服务端向客户端回复一个确认号,表示已经收到客户端的请求。

3.服务端向客户端发送相应的data。

4.客户端向服务器回复一个确认号,表示已经收到服务端的data。

以此不断循环。

 

断开连接(四次挥手)

step1:第一次挥手

首先,客户端发送一个FIN,关闭客户端到服务器的数据传送,然后等待服务器的确认。其中终止标志位FIN=1,表示断开连接,序列号seq=u。

step2:第二次挥手

服务器收到这个FIN,向客户端回复一个u+1的确认号,表示收到客户端的断开连接请求。

step3:第三次挥手

关闭服务器到客户端的连接,发送一个FIN给客户端,seq=n。

step4:第四次挥手

客户端收到FIN后,回复服务器一个n+1的确认号,表示已经收到服务端的断开连接信息。

首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭。

 

常见面试题一:

1.为什么需要三次握手,两次不可以吗?或者四次、五次可以吗?
我们来分析一种特殊情况,假设客户端请求建立连接,发给服务器SYN包等待服务器确认,服务器收到确认后,如果是两次握手,假设服务器给客户端在第二次握手时发送数据,数据从服务器发出,服务器认为连接已经建立,但在发送数据的过程中数据丢失,客户端认为连接没有建立,会进行重传。假设每次发送的数据一直在丢失,客户端一直SYN,服务器就会产生多个无效连接,占用资源,这个时候服务器可能会挂掉。这个现象就是我们听过的“SYN的洪水攻击”。

总结:

第三次握手是为了防止:如果客户端迟迟没有收到服务器返回确认报文,这时会放弃连接,重新启动一条连接请求,但问题是:服务器不知道客户端没有收到,所以他会收到两个连接,浪费连接开销。如果每次都是这样,就会浪费多个连接开销。

 

常见面试题二:

1.为什么需要四次挥手?

在数据传输的过程中,数据的传输是双向的。当一方认为自己没有数据需要发送给对方了,便发起了断开连接的请求,并断开了自己到对端的连接,但是此时并不代表对端已经没有数据需要传输给自己了,此时对方会先回复一个确认号,表示已经收到请求,但是由于数据还在传输,对端需要先把数据传输完成再断开连接。最后发送一个fin过来表示对端到自己的连接已经关闭了,自己发送一个确认号给对端表示收到,此时连接才完全断开。

 

客户端发送FIN后,进入终止等待状态,服务器收到客户端连接释放报文段后,就立即给客户端发送确认,服务器就进入CLOSE_WAIT状态,此时TCP服务器进程就通知高层应用进程,因而从客户端到服务器的连接就释放了。此时是“半关闭状态”,即客户端不可以发送给服务器,服务器可以发送给客户端。

此时,如果服务器没有数据报发送给客户端,其应用程序就通知TCP释放连接,然后发送给客户端连接释放数据报,并等待确认。客户端发送确认后,进入TIME_WAIT状态,但是此时TCP连接还没有释放,然后经过等待计时器设置的2MSL后,才进入到CLOSE状态。

2.为什么需要2MSL时间?

首先,MSL即Maximum Segment Lifetime,就是最大报文生存时间,是任何报文在网络上的存在的最长时间,超过这个时间报文将被丢弃。《TCP/IP详解》中是这样描述的:MSL是任何报文段被丢弃前在网络内的最长时间。RFC 793中规定MSL为2分钟,实际应用中常用的是30秒、1分钟、2分钟等。

TCP的TIME_WAIT需要等待2MSL,当TCP的一端发起主动关闭,三次挥手完成后发送第四次挥手的ACK包后就进入这个状态,等待2MSL时间主要目的是:防止最后一个ACK包对方没有收到,那么对方在超时后将重发第三次握手的FIN包,主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用,要等到2MSL时间结束才可以继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。

3.为什么是四次挥手,而不是三次或是五次、六次?

双方关闭连接要经过双方都同意。所以,首先是客服端给服务器发送FIN,要求关闭连接,服务器收到后会发送一个ACK进行确认。服务器然后再发送一个FIN,客户端发送ACK确认,并进入TIME_WAIT状态。等待2MSL后自动关闭。

 

总结:

(1)为了保证客户端发送的最后一个ACK报文段能够到达服务器。即最后一个确认报文可能丢失,服务器会超时重传,然后服务器发送FIN请求关闭连接,客户端发送ACK确认。一个来回是两个报文生命周期。

如果没有等待时间,发送完确认报文段就立即释放连接的话,服务器就无法重传,因此也就收不到确认,就无法按步骤进入CLOSE状态,即必须收到确认才能close。

(2)防止已经失效的连接请求报文出现在连接中。经过2MSL,在这个连续持续的时间内,产生的所有报文段就可以都从网络消失。

 

原文:https://blog.csdn.net/ZWE7616175/article/details/80432486 

 

转载于:https://www.cnblogs.com/QicongLiang/p/9811328.html

你可能感兴趣的文章
SQL Server中利用正则表达式替换字符串
查看>>
[poj1006]Biorhythms
查看>>
Hyper-V虚拟机上安装一个图形界面的Linux系统
查看>>
Hover功能
查看>>
js千分位处理
查看>>
Mac---------三指拖移
查看>>
字符串类型的相互转换
查看>>
HTTP状态码
查看>>
iOS如何过滤掉文本中特殊字符
查看>>
基础学习:C#中float的取值范围和精度
查看>>
javaagent 简介
查看>>
python升级安装后的yum的修复
查看>>
Vim配置Node.js开发工具
查看>>
web前端面试题2017
查看>>
ELMAH——可插拔错误日志工具
查看>>
MySQL学习笔记(四)
查看>>
【Crash Course Psychology】2. Research & Experimentation笔记
查看>>
两数和
查看>>
移动设备和SharePoint 2013 - 第3部分:推送通知
查看>>
SOPC Builder中SystemID
查看>>