ICMP识别二层为广播帧则不发送ICMP目的端口不可达报文
2022/7/16 6:20:15
本文主要是介绍ICMP识别二层为广播帧则不发送ICMP目的端口不可达报文,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
拓扑图:
前提:二层交换机转发数据时不改变帧头中任何字段的数据。
正常情况下,在主机0上构造一个普通的UDP用户数据报报文给主机1,报文中的UDP首部中的目的端口字段填写一个不可能使用的端口号,则主机1在收到此报文后发现本主机上没有进程监听这个目的端口,就会向源发送主机发送一个ICMP目的端口不可达报文。
可如果精心构造的报文的二层帧头中的目的MAC地址字段内容为全F,其他内容与正常情况下完全相同,则主机1就不会回复ICMP目的端口不可达报文。
此时就有了一个疑问,正常理解的概念是,协议每读取完一层数据后,就会把本层的首部和尾部(如果有的话)完全剥离,只把对于本层来说的数据部分根据刚才读取出来的类型字段、协议号、端口号等递交给下一层相应的协议或应用来做进一步的处理。那么在这种理解下,应用层的UDP协议已经发现目的端口不可达之后,则此时数据中的二层帧头应该已经被剥离,还怎么判断出帧头首部中的目的MAC地址字段中的内容为全F进而决定不发送ICMP目的端口不可达报文呢???
其实所谓的首部和尾部剥离之后再递交到下一层协议只是为了方便教学和辅助理解的一种衍生说法。实际开发中所谓的递交到下一层并剥离首部和尾部只是将指针进行移位,而数据本身从来没有任何变化,也就是说所有数据信息都还有保留。所以即便已经到了UDP来读取数据,依旧可以倒回到二层帧头中读取目的MAC地址字段中的内容来决定是否需要回复ICMP目的端口不可达报文。
这篇关于ICMP识别二层为广播帧则不发送ICMP目的端口不可达报文的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-05-13PingCAP 戴涛:构建面向未来的金融核心系统
- 2024-05-09flutter3.x_macos桌面os实战
- 2024-05-09Rust中的并发性:Sync 和 Send Traits
- 2024-05-08使用Ollama和OpenWebUI在CPU上玩转Meta Llama3-8B
- 2024-05-08完工标准(DoD)与验收条件(AC)究竟有什么不同?
- 2024-05-084万 star 的 NocoDB 在 sealos 上一键起,轻松把数据库编程智能表格
- 2024-05-08Mac 版Stable Diffusion WebUI的安装
- 2024-05-08解锁CodeGeeX智能问答中3项独有的隐藏技能
- 2024-05-08RAG算法优化+新增代码仓库支持,CodeGeeX的@repo功能效果提升
- 2024-05-08代码报错不用愁,CodeGeeX一键完成代码修复、错误解释的功能上线了!