三次握手Three-wayHandshake
--转自liucaixia
一个虚拟连接的建立是通过三次握手来实现的
1. (Client) –> [SYN] –> (Server)
假如Client和Server通讯. 当Client要和Server通信时,Client首先向Server发一个SYN(Synchronize) 标记的包,告诉Server请求建立连接.
注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要,只有当Server收到Client发来的SYN包,才可建立连接,除此之外别无他法。因此,如果你的防火墙丢弃所有的发往外网接口的SYN包,那么你将不 能让外部任何主机主动建立连接。
如下图红框,三次握手的首次SYN,Source为我的教学平台所在的IP:192.168.102.64 Destination为平台的IP:192.168.102.241
2. (Client) <– [SYN/ACK] <–(Server)
接着,Server收到来自Client发来的SYN包后,会发一个对SYN包的确认包(SYN/ACK)给Client,表示对第一个SYN包的确认,并继续握手操作.
注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.
如下图红框,三次握手的服务端给客户端的响应SYN,ACK,Source为平台的IP:192.168.102.241,Destination为我的教学平台所在的IP:192.168.102.64
3. (Client) –> [ACK] –> (Server)
Client收到来自Server的SYN/ACK 包,Client会再向Server发一个确认包(ACK),通知Server连接已建立。至此,三次握手完成,一个TCP连接完成。
Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后,TCP连接的每个包都会设置ACK位。
如下图红框,三次握手的最后确认ACK,Source为我的教学平台所在的IP:192.168.102.64 Destination为平台的IP:192.168.102.241
到此为止,客户端完成了与服务端进行数据传输的准备工作,类似人们见面后先进行握手后,接下来就进行正题交流了。
四次握手Four-way Handshake
四次握手用来关闭已建立的TCP连接,当客户端和服务端完成了数据包的传输后,又客户端或者服务端主动发起握手。来进行连接的断开。
1. (Client) –> ACK/FIN –>(Server)
2. (Client) <– ACK <–(Server)
3. (Client) <– ACK/FIN <–(Server)
4. (Client) –> ACK –>(Server)
如下图蓝框为四次握手,首先的发起放时为平台,IP:192.168.102.241,Destination为我的教学平台所在的IP:192.168.102.64。接下来客户端进行了ACK响应 ,紧接着自己也发了一个结束包。服务端对结束包进行响应。
注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包,并且通常被认为是恶意的。
连接复位Resetting a connection
四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送. 注意在,由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记
到目前为止,你已经看到了 SYN, ACK, FIN, 和RST 标记. 另外,还有PSH (Push) 和URG(Urgent)标记.
最常见的非法组合是SYN/FIN 包. 注意:由于 SYN包是用来初始化连接的, 它不可能和 FIN和RST标记一起出现. 这也是一个恶意攻击.
由于现在大多数防火墙已知 SYN/FIN 包, 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明显,当网络中出现这种包时,你的网络肯定受到攻击了。
别的已知的非法包有FIN (无ACK标记)和”NULL”包。如同早先讨论的,由于ACK/FIN包的出现是为了关闭一个TCP连接,那么正常的FIN包总是带有ACK 标记。”NULL”包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)。
到目前为止,正常的网络活动下,TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时,肯定有人对你的网络不怀好意。
抓报分析问题实例:
问题:梦幻西游在网维大师无盘上容易掉线的问题
当时捕捉到梦幻西游掉线时的数据包是这样的。注意下图中的红色数据,123.58.184.241是梦幻西游的服务器,而192.168.1.41是玩梦幻西游的客户机,在掉线时,发现是先有梦幻西游的服务器向客户机发送一个[FIN,ACK]数据包,根据上面的解释,FIN标记的数据包是代表要断开连接的意思,而接着客户机又回给服务器一个确认断开链接包。当看到这个抓包数据时,就意识到,大家说的在网维大师系统虚拟盘上梦幻爱掉线的问题,并非普通的网络问题,因为通过数据包的信息来看,是梦幻服务器主动要求断开链接,产生这个情况无非是以下几个原因:
1、服务器发现客户端非法,比如有外挂什么的,踢掉了客户机;
2、服务器压力大,踢掉了客户机;
3、总之不是客户端问题导致的掉线;
那么既然结论是如此,为什么会有在网维大师系统虚拟盘上容易出现梦幻掉线问题呢?原因是由于网维大师系统虚拟盘是模拟真实硬盘方式来实现的,而在模拟过程中,将硬盘的序列号设置为固定过的OSDIY888了,而梦幻西游刚好后识别客户机硬盘信息,发现大量客户端的硬盘序列号都是一样的,就认为是作-bi或者使用挂机外-挂了,结果就导致随机被服务器踢下线的情况发生,后来我们将硬盘序列号设置为空,则没再出现该问题。这个问题在未来的新版本中会解决掉。
相关推荐
本文介绍了几种常见的导致 TCP 连接断连的原因,并在此基础上,以 AIX 系统为例,借助相应的网络分析工具,解开TCP 断连的原因,并给出两种可行的解决方案。
实现SOCKET TCP断开连接后,重新连接 比如TCP通信过程中,网断了或者拨了网线,如何在代码中自动重新连接TCP服务器.这是常见需求
怎样及时检测出非正常断开的TCP连接,有实现代码
手写简化版tcp长链接的socket实现,主要功能有断开重连,以及收发读取解码解析,适用于需要用到长链接的原生开发。
linux下使用libevent实现断网重连的tcp客户端,自动检测tcp连接断开,断开后能自动重连;如果连不上服务器,则一直尝试连接服务器,直至连接成功。
tcp连接,前后端通信,通过ip,端口号进行连接,用到了线程
本文链接:https://blog.csdn.net/tt1995cc/article/details/70770042在用QT写服务端时想要知道客户端是否断开
一种解决wincc modbus tcp通讯不稳的思路
1.请检查端口服务类型(服务端端口是TCP/UDP)。 2.检查网络环境。 3.默认回车换行断包。所以注意发送内容后面一定要添加回车换行。 注:由于时间问题,加了心跳机制,但是没加客户端回应,也没加服务端接收到心跳...
本实验采用LWIP的RAW编程方法实现TCP Server功能,默认开启DHCP自动获取IP地址。电脑端打开网络调试助手,网络调试助手做客户端,所以选择TCP Client协议。开发板做TCP服务器。
实时检测网络的通断情况,以实现网络的无缝重连
tcp 粘包 拆包解决思路以代码,提供DEMO,采用 包长+内容缓冲区 组织方法,未采用分隔符以及定长包,因为我觉得包长+内容缓冲区比较灵活
用c#语言编写,使用TCP/CP协议,服务器端监听端口,客户端连接服务端,向服务端发送数据,服务端接收并自动回复,主要用于演示TCP/IP通信。
下下来即可使用 非常好 一个客户端 一个服务器段
TcpListener类以同步阻塞方式提供于监听和接收外来连接请求的方法。 TcpClient类实现了使用发送和接收数据的套接字。 在c# .NET中,远程连接被表示为流,所以可以用流处理方式读取和写入而进行通信。
摘 要:研究TCP/IP网络的监听, “三次握手”建立连接的过程,以及拆断TCP“三次握手”的方法。以RedHat 9.0(Linux)、Windows 2000 Server、Windows XP Professional、Windows XP Home、Windows 2003 为主要操作系统...
C语言编写,采用CS模型,TCP、UDP网络协议实现的内网多人聊天室。 服务器:采用多线程以及线程锁处理客户端的所有请求以及信息转发任务。服务端实时显示客户的登录与登出信息;保存客户上传的共享文件(网盘功能);...
文档内有客户端和服务端socket,实际项目中只用到了客户端,会比较详细,支持断开重连
本程序只有TCP客户端这块,程序读取配置文件ini中设置的IP地址和端口号。才有进程监听,是否有服务器端。如果有,自动连接。如果中途断了,会一直监听直至下次打开服务器端再次连接。——备注:新手请多多指教
当SSH远程命令或者远程工具登录阿里云服务器,ssh root@47.107.* 时,经常会发现SSH连接后一会儿客户端就被服务器T掉。一般上,是因为SSH连接没有设置保活 解决方法有两个:1、设置SSH客户端保活,2、要不设置SSH...