答应我不要问TCP三次握手四次挥手
衍生头疼问题如下。
- 请画出三次握手和四次挥手的示意图
- 为什么连接的时候是三次握手?
- 什么是半连接队列?
- ISN(Initial Sequence Number)是固定的吗?
- 三次握手过程中可以携带数据吗?
- 如果第三次握手丢失了,客户端服务端会如何处理?
- SYN攻击是什么?
- 挥手为什么需要四次?
- 四次挥手释放连接时,等待2MSL的意义?
1. 三次握手
三次握手(Three-way Handshake)其实就是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口,建立TCP连接,并同步连接双方的序列号和确认号,交换TCP窗口大小
信息。
刚开始客户端处于 Closed 的状态,服务端处于 Listen 状态。
进行三次握手:
第一次握手:客户端给服务端发一个 SYN 报文,并指明客户端的初始化序列号 ISN。此时客户端处于
SYN_SENT
状态。首部的同步位SYN=1,初始序号seq=x,SYN=1的报文段不能携带数据,但要消耗掉一个序号。
第二次握手:服务器收到客户端的 SYN 报文之后,会以自己的 SYN 报文作为应答,并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值,表示自己已经收到了客户端的 SYN,此时服务器处于
SYN_RCVD
的状态。在确认报文段中SYN=1,ACK=1,确认号ack=x+1,初始序号seq=y。
第三次握手:客户端收到 SYN 报文之后,会发送一个 ACK 报文,当然,也是一样把服务器的 ISN + 1 作为 ACK 的值,表示已经收到了服务端的 SYN 报文,此时客户端处于
ESTABLISHED
状态。服务器收到 ACK 报文之后,也处于ESTABLISHED
状态,此时,双方已建立起了连接。确认报文段ACK=1,确认号ack=y+1,序号seq=x+1(初始为seq=x,第二个报文段所以要+1),ACK报文段可以携带数据,不携带数据则不消耗序号。
发送第一个SYN的一端将执行主动打开(active open),接收这个SYN并发回下一个SYN的另一端执行被动打开(passive open)。
在socket编程中,客户端执行connect()时,将触发三次握手。
1.1 为什么需要三次握手,两次不行吗?
弄清这个问题,我们需要先弄明白三次握手的目的是什么,能不能只用两次握手来达到同样的目的。
- 第一次握手:客户端发送网络包,服务端收到了。
这样服务端就能得出结论:客户端的发送能力、服务端的接收能力是正常的。 - 第二次握手:服务端发包,客户端收到了。
这样客户端就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 - 第三次握手:客户端发包,服务端收到了。
这样服务端就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。
如客户端发出连接请求,但因连接请求报文丢失而未收到确认,于是客户端再重传一次连接请求。后来收到了确认,建立了连接。数据传输完毕后,就释放了连接,客户端共发出了两个连接请求报文段,其中第一个丢失,第二个到达了服务端,但是第一个丢失的报文段只是在某些网络结点长时间滞留了,延误到连接释放以后的某个时间才到达服务端,此时服务端误认为客户端又发出一次新的连接请求,于是就向客户端发出确认报文段,同意建立连接,不采用三次握手,只要服务端发出确认,就建立新的连接了,此时客户端忽略服务端发来的确认,也不发送数据,则服务端一致等待客户端发送数据,浪费资源。
1.2 什么是半连接队列?
服务器第一次收到客户端的 SYN 之后,就会处于 SYN_RCVD 状态,此时双方还没有完全建立其连接,服务器会把此种状态下请求连接放在一个队列里,我们把这种队列称之为半连接队列。
当然还有一个全连接队列,就是已经完成三次握手,建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。
1.3 ISN(Initial Sequence Number)是固定的吗?
1.4 三次握手过程中可以携带数据吗?
其实第三次握手的时候,是可以携带数据的。但是,第一次、第二次握手不可以携带数据
1.5 SYN攻击是什么?
netstat -n -p TCP | grep SYN_RECV
2. 四次挥手
TCP 连接的拆除需要发送四个包,因此称为四次挥手(Four-way handshake),客户端或服务端均可主动发起挥手动作。
刚开始双方都处于ESTABLISHED
状态,假如是客户端先发起关闭请求。四次挥手的过程如下:
- 第一次挥手:客户端发送一个 FIN 报文,报文中会指定一个序列号。此时客户端处于
FIN_WAIT1
状态。
即发出连接释放报文段(FIN=1,序号seq=u),并停止再发送数据,主动关闭TCP连接,进入FIN_WAIT1(终止等待1)状态,等待服务端的确认。 - 第二次挥手:服务端收到 FIN 之后,会发送 ACK 报文,且把客户端的序列号值 +1 作为 ACK 报文的序列号值,表明已经收到客户端的报文了,此时服务端处于
CLOSE_WAIT
状态。
即服务端收到连接释放报文段后即发出确认报文段(ACK=1,确认号ack=u+1,序号seq=v),服务端进入CLOSE_WAIT(关闭等待)状态,此时的TCP处于半关闭状态,客户端到服务端的连接释放。客户端收到服务端的确认后,进入FIN_WAIT2(终止等待2)状态,等待服务端发出的连接释放报文段。 - 第三次挥手:如果服务端也想断开连接了,和客户端的第一次挥手一样,发给 FIN 报文,且指定一个序列号。此时服务端处于
LAST_ACK
的状态。
即服务端没有要向客户端发出的数据,服务端发出连接释放报文段(FIN=1,ACK=1,序号seq=w,确认号ack=u+1),服务端进入LAST_ACK(最后确认)状态,等待客户端的确认。 - 第四次挥手:客户端收到 FIN 之后,一样发送一个 ACK 报文作为应答,且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值,此时客户端处于
TIME_WAIT
状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态,服务端收到 ACK 报文之后,就处于关闭连接了,处于CLOSED
状态。
即客户端收到服务端的连接释放报文段后,对此发出确认报文段(ACK=1,seq=u+1,ack=w+1),客户端进入TIME_WAIT(时间等待)状态。此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL后,客户端才进入CLOSED状态。
收到一个FIN只意味着在这一方向上没有数据流动。客户端执行主动关闭并进入TIME_WAIT是正常的,服务端通常执行被动关闭,不会进入TIME_WAIT状态。
在socket编程中,任何一方执行close()操作即可产生挥手操作。
2.1 挥手为什么需要四次?
2.2 2MSL等待状态
这种2MSL等待的另一个结果是这个TCP连接在2MSL等待期间,定义这个连接的插口(客户的IP地址和端口号,服务器的IP地址和端口号)不能再被使用。这个连接只能在2MSL结束后才能再被使用。
2.3 四次挥手释放连接时,等待2MSL的意义?
MSL是Maximum Segment Lifetime的英文缩写,可译为“最长报文段寿命”,它是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃。
为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失,从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK,接着客户端再重传一次确认,重新启动时间等待计时器
。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL,而是在发送完ACK之后直接释放关闭,一但这个ACK丢失的话,服务器就无法正常的进入关闭连接状态。
两个理由:
保证客户端发送的最后一个ACK报文段能够到达服务端。
这个ACK报文段有可能丢失,使得处于LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认,服务端超时重传FIN+ACK报文段,而客户端能在2MSL时间内收到这个重传的FIN+ACK报文段,接着客户端重传一次确认,重新启动2MSL计时器,最后客户端和服务端都进入到CLOSED状态,若客户端在TIME-WAIT状态不等待一段时间,而是发送完ACK报文段后立即释放连接,则无法收到服务端重传的FIN+ACK报文段,所以不会再发送一次确认报文段,则服务端无法正常进入到CLOSED状态。
防止“已失效的连接请求报文段”出现在本连接中。
客户端在发送完最后一个ACK报文段后,再经过2MSL,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失,使下一个新的连接中不会出现这种旧的连接请求报文段。
2.4 为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态?
理论上,四个报文都发送完毕,就可以直接进入CLOSE状态了,但是可能网络是不可靠的,有可能最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
3. 总结
答应我不要问TCP三次握手四次挥手相关推荐
- java锁一次交互二次握手_Java后台开发面试实战(二):TCP三次握手四次挥手
感谢牛客网网友提供的面试经验! 1. 解释一下TCP三次握手四次挥手 图片来源于微信公众号:码农求职小助手 答: 嗯(稍作思考)- 三次握手简单来说,在数据传输开始前: 第一次握手:客户端向服务端发送 ...
- [计算机网络][总结][常见问题][TCP][三次握手][四次挥手]
TCP三次握手 四次挥手 三次握手 目的:保证传输的可靠性,为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误.主要防止资源的浪费. 具体过程:当客户端发出第一个连接请求报文段时并没有丢 ...
- TCP三次握手四次挥手(图解)
<TCP-IP协议栈概略图与TCP三次握手四次挥手> 目录 1 TCP过程详解 1.1 三次握手 1.2 四次挥手 2 使用tcpdump分析三次握手的过程 2.1 tcpdump抓包和t ...
- TCP三次握手四次挥手过程及其中的状态量
网上看到过一些有关TCP三次握手四次挥手的过程,觉得有必要总结一下了,对于了解TCP的过程还是有帮助的 1.变量含义 SYN表示建立连接, FIN表示关闭连接, ACK表示响应, PSH表示有 DAT ...
- java 中的网络编程(Socket、TCP三次握手四次挥手、TCP/UDP/URL)
文章目录 前言 一.网络编程概述 二.网络通信要素概述 1.如何实现网络中的主机互相通信 2.网络通信协议 3.IP和端口号 4.InetAddress类 5.网络协议 6.TCP/IP协议簇 7.T ...
- TCP三次握手四次挥手简介
TCP三次握手四次挥手简介 图解三次握手.四次挥手 建立连接:三次握手 关闭连接:四次挥手 上图传递过程中出现的几个字符(SYN,ACK,FIN,seq,ack)各代表什么意思 SYN,ACK,FIN ...
- TCP三次握手四次挥手详解
TCP三次握手四次挥手 1. TCP报文格式 2. TCP连接需要解决的问题 3. 三次握手 4. 四次挥手 5. 一些补充问题 1. TCP报文格式 在了解三次握手和四次挥手之前,先知道TCP报文内 ...
- TCP三次握手四次挥手(三国版)
TCP的三次握手四次挥手 TCP的三次握手和四次挥手不管是我们自己使用还是面试都是需要掌握的,本文先将原理,然后以三国为例讲个小栗子帮助理解.先来一张图: 标志位 TCP在其协议头中使用大量的标志位或 ...
- 深入浅出TCP三次握手四次挥手
每每想起TCP三次握手这个问题,就会陷入如下的困惑: var forget = ? while(forget) {百度/Google } 而重点在于forget永远等于true,无情的消耗着我这颗只有 ...
最新文章
- 2019年上半年收集到的人工智能深度学习方向干货文章
- python怎么建立画板_Python基于opencv实现的简单画板功能示例
- ubuntu12.04LTS 安装eclipse和cdt
- mybatis-generator 插件扩展,生成支持多种数据库的分页功能
- 十八、MySQL之TCL事务控制语言(详解)
- PHP7革新与性能优化
- 爬虫-使用xpath拿36KR的数据-xpath的学习与演练
- 有可能导致HttpQueryInfo 执行时出现12150 错误的一个原因
- python基础-第六篇-6.2模块
- THUSC2016 游记
- 转载:【Oracle 集群】RAC知识图文详细教程(四)--缓存融合技术和主要后台进程
- 深圳华为 C++面试题
- 指定的網域的名稱或安全性識別碼(用磁碟映像檔部署的電腦無法加入AD網域 )...
- 个人 易混淆 高频 高级单词
- 物联网-智能家居相关知识了解
- # Linux备份系统并还原到另一块硬盘
- 关于织梦后台dedecms管理员后台权限、新增后台管理员的功能
- 赛力斯华为智选SF5入驻华为旗舰店,将通过华为零售渠道销售
- eip协议通信_工业通讯 | EtherNET/IP协议基础知识(Part 3)||附视频讲解
- 指向类成员/函数的指针