Ethereal分析TCP三次握手

2023-12-30 11:50

本文主要是介绍Ethereal分析TCP三次握手,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

参考:

Wireshark分析三次握手

三次握手,四次握手

Ethereal使用方法以及相关实验分析

示意图1

由上至下分为是:

1)各个协议的数据包列表(显示的是捕获到的每个数据包的大概信息)

2)某一具体协议的各个层次的数据分析(某个数据包的层次结构和协议分析)

3)帧的十六进制具体数据展示(数据包在物理层上传递的数据)

Frame---------------------------------------------------数据链路层帧

Ethernet-------------------------------------------------以太网帧

Internet Protocol--------------------------------------IP数据报

Transmission Control Protocol--------------------运输层协议TCP/IP

                                 首先是三次握手的示意图:

三次握手示意图

这里面我按照书上理解的是:(先上抓的包,根据SYN=1   SYN=1,ACK=1  ACK=1很容易找)

示意图

第一步:Client向Server发出连接请求报文段(第七版书上很详细,但是我认为先了解个大概再慢慢去看细节),其中同步位SYN=1(SYN=1表示这是一个连接请求或接受报文,SYN=1&&ACK=0->连接请求报文,SYN=1&&ACK=1->对方同意建立连接,在发出的响应报文中使用),同时初始序号seq=x。(1:seq即序号,指出本报文段所发送的数据的第一个字节的序号,我理解为当前所传数据第一个字节的序号。2:ACK表示确认ACK,只有ACK为1时,ack才有效。3:ack是确认号,期望收到对方下一个报文段的第一个数据字节的序号,我理解为当前所收到的数据尾巴+1)注意:SYN报文段(即SYN=1)不能携带数据,但是要消耗掉一个序号。(有了这句话,我们就能够理解接下来ack=x+1了,之前的请求连接虽然不带数据,但是会消耗序号,所以我们在下一次Server响应Client自然是期望所收的数据从x+1处开始,我们在第二步中同样不能携带数据,却依旧会消耗一个序号。)

以分析Client发出的连接请求报文段为例子进行分析:

示意图

33号帧,显示到达时间,帧到达时间,编号,长度,帧的内部各个层次所用到的协议是ETH,IP,TCP。

示意图

示意图

以太网帧首部14个字节,源地址是我的网卡,目的地址假设为一个网页,两个字节类型字段0x0800表示里面的数据是IP数据报

示意图

示意图

示意图

对着上图看即可

示意图

示意图

只看关键点:  这里面SYN=1, seq=x=0

第二步:Server收到Client的连接请求报文后,若同意,则向Client发送确认。此时SYN=1,ACK=1,ack=x+1,同第一步一样,选择一个初始序号seq=y,注意:此报文不携带数据,依旧消耗一个序号,TCP服务器进入SYN-RCVD(同步收到状态)。

示意图

确认中的SYN=1,ACK=1,seq=y=0,ack=x+1=1

第三步:Client收到Server的确认,还要向Server给出确认,ACK置1,ack=y+1,因为第二步中ack=y+1(因为第二步中给出的初始序号是seq=y,虽然不携带数据但是会占用一个序号,所以我们从ack=y+1这个头开始标记),由于第一步中seq=x,此时seq则为x+1了,此时TCP连接已经建立,Client进入ESTABLISHED(已建立连接)状态,当Server收到Client的确认后,也进入ESTABLISHED状态。(开始可粗略将Client的seq与Server的ack有数学上的关系来理解,书上的滑动窗口很好的解释了seq与ack的关系。)也可将第三步拆为两种,先发送ACK=1,ack=x+1的确认报文段,再发送一个同步报文段(SYN=1,seq=y),此时就变为了四报文握手。

示意图

向Server给出的确认中ACK=1,seq=x+1=1,ack=y+1=1。

这篇关于Ethereal分析TCP三次握手的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/552758

相关文章

Nginx分布式部署流程分析

《Nginx分布式部署流程分析》文章介绍Nginx在分布式部署中的反向代理和负载均衡作用,用于分发请求、减轻服务器压力及解决session共享问题,涵盖配置方法、策略及Java项目应用,并提及分布式事... 目录分布式部署NginxJava中的代理代理分为正向代理和反向代理正向代理反向代理Nginx应用场景

Redis中的有序集合zset从使用到原理分析

《Redis中的有序集合zset从使用到原理分析》Redis有序集合(zset)是字符串与分值的有序映射,通过跳跃表和哈希表结合实现高效有序性管理,适用于排行榜、延迟队列等场景,其时间复杂度低,内存占... 目录开篇:排行榜背后的秘密一、zset的基本使用1.1 常用命令1.2 Java客户端示例二、zse

Redis中的AOF原理及分析

《Redis中的AOF原理及分析》Redis的AOF通过记录所有写操作命令实现持久化,支持always/everysec/no三种同步策略,重写机制优化文件体积,与RDB结合可平衡数据安全与恢复效率... 目录开篇:从日记本到AOF一、AOF的基本执行流程1. 命令执行与记录2. AOF重写机制二、AOF的

MyBatis Plus大数据量查询慢原因分析及解决

《MyBatisPlus大数据量查询慢原因分析及解决》大数据量查询慢常因全表扫描、分页不当、索引缺失、内存占用高及ORM开销,优化措施包括分页查询、流式读取、SQL优化、批处理、多数据源、结果集二次... 目录大数据量查询慢的常见原因优化方案高级方案配置调优监控与诊断总结大数据量查询慢的常见原因MyBAT

分析 Java Stream 的 peek使用实践与副作用处理方案

《分析JavaStream的peek使用实践与副作用处理方案》StreamAPI的peek操作是中间操作,用于观察元素但不终止流,其副作用风险包括线程安全、顺序混乱及性能问题,合理使用场景有限... 目录一、peek 操作的本质:有状态的中间操作二、副作用的定义与风险场景1. 并行流下的线程安全问题2. 顺

MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决

《MyBatis/MyBatis-Plus同事务循环调用存储过程获取主键重复问题分析及解决》MyBatis默认开启一级缓存,同一事务中循环调用查询方法时会重复使用缓存数据,导致获取的序列主键值均为1,... 目录问题原因解决办法如果是存储过程总结问题myBATis有如下代码获取序列作为主键IdMappe

Java中最全最基础的IO流概述和简介案例分析

《Java中最全最基础的IO流概述和简介案例分析》JavaIO流用于程序与外部设备的数据交互,分为字节流(InputStream/OutputStream)和字符流(Reader/Writer),处理... 目录IO流简介IO是什么应用场景IO流的分类流的超类类型字节文件流应用简介核心API文件输出流应用文

Android 缓存日志Logcat导出与分析最佳实践

《Android缓存日志Logcat导出与分析最佳实践》本文全面介绍AndroidLogcat缓存日志的导出与分析方法,涵盖按进程、缓冲区类型及日志级别过滤,自动化工具使用,常见问题解决方案和最佳实... 目录android 缓存日志(Logcat)导出与分析全攻略为什么要导出缓存日志?按需过滤导出1. 按

Linux中的HTTPS协议原理分析

《Linux中的HTTPS协议原理分析》文章解释了HTTPS的必要性:HTTP明文传输易被篡改和劫持,HTTPS通过非对称加密协商对称密钥、CA证书认证和混合加密机制,有效防范中间人攻击,保障通信安全... 目录一、什么是加密和解密?二、为什么需要加密?三、常见的加密方式3.1 对称加密3.2非对称加密四、

Linux之UDP和TCP报头管理方式

《Linux之UDP和TCP报头管理方式》文章系统讲解了传输层协议UDP与TCP的核心区别:UDP无连接、不可靠,适合实时传输(如视频),通过端口号标识应用;TCP有连接、可靠,通过确认应答、序号、窗... 目录一、关于端口号1.1 端口号的理解1.2 端口号范围的划分1.3 认识知名端口号1.4 一个进程