对于Traceroute程序的一个小问题
老师们好~！-82-在下最近碰到一个关于Traceroute程序的小疑问
在TCP/IP卷一中描述的Traceroute 在发出的数据包中携带一个大于30000的UDP端口号来用于判断返回的数据包是否到达目的主机，如果返回超时ICMP报文（type=11 code=0）则说明还没有到达目的主机，如果返回端口不可达ICMP（3,3）
在这里我做了一个实验~发现用CISCO的Packet Tracer来跟中数据包的时候，确实在IP包头发现协议号是0X11（17）UDP协议~也确实看到了跟在后面的UDP头~
问题在这里了~当我在GNS中用WireShark抓包的时候~情况却并非如此~在没有到达目的以前一切正常，超时ICMP（11,0）报文被返回，但是在到达目的之后返回的却不是端口不可达ICMP（3,3），而直接是ICMP的ping应答（type=0 code=0），这个时候我很纳闷~
我再返回去找源端发出的报文，发现源端发出的报文IP包头的协议字段是1，也就是说是一个ICMP请求（8,0）报文而不是UDP~
这个事情很奇怪~是否后来将Traceroute程序的判断和发送机制给改了？不用UDP来判断是否到达目的地了？
抑或是WireShark抓包工具的问题？
希望知道的老师们不吝赐教~！在下万分感谢~！-82-
................事情发生了戏剧性的变化=.=
俺刚才才突然想到，自己是在用真实计算机去
tracert -d 到某个目的，
然后我就换成CISCO的路由去traceroute 到某个目的~
这个时候抓包的返回结果显示，确实是和TCP/IP卷一里面描述的一样！发送的是UDP报文而不是ICMP的请求~
但是使用windows系列的操作系统去tracert -d 的时候，发送的却是ICMP的请求报文而非UDP报文~
关于这一点确实很让人惊讶~这说明Windows的tracert程序....似乎没有遵循标准...
关于这一点~不知道LINUX系列和FREEBSD系列是否如此？我想应该是会同TCP/IP卷一描述的一样吧~
问题解决...-woniu7-
希望能对以后遇到相同问题的朋友有所帮助~ 有两种实现方式：
window系统采用ICMP报文
linux等系统采用udp报文
TCP/IP只讲了其中一种，这个没什么标准的。 gekey 发表于 2011-12-8 12:28 static/image/common/back.gif
有两种实现方式：
window系统采用ICMP报文
linux等系统采用udp报文
谢谢-79-受教了~
其实个人感觉ICMP报文比UDP的实现好~因为那个UDP端口没准被占用了=。=那会发生什么情况？
...
Magic在看TCP/IP了，哈哈。加油！ jkrh9 发表于 2011-12-8 18:21 static/image/common/back.gif
Magic在看TCP/IP了，哈哈。加油！
-79-是的~最近终于每天给分出一点时间来可以研究这个了~一起加油！
我发现了解各种数据包各种封装的结构以及工作原理后对于理解路由交换间的工作方式有很大帮助~
(*^__^*) 嘻嘻……感觉就好像是用放大镜外加慢镜头看东西~很有趣~
magic_os 发表于 2011-12-8 20:42 static/image/common/back.gif
是的~最近终于每天给分出一点时间来可以研究这个了~一起加油！
我发现了解各种数据包各种封装的结构 ...
嗯，是啊，我也常没事抓包看，这个习惯也对学习挺有帮助的。-- jkrh9 发表于 2011-12-9 00:19 static/image/common/back.gif
嗯，是啊，我也常没事抓包看，这个习惯也对学习挺有帮助的。
--抓包流....抓好玩~管他抓住兔子还是猫...
页:
[1]