ICMP的两个常见的应用是分组网间探测PING(用来测试两个主机之间的连通性)和traceroute(UNIX中的名字,在Windows中是tracert,可以用来跟踪分组经过的路由)。其中PING使用了ICMP回送报文和回答报文,traceroute(tracert)使用了ICMP时间超过报文。
PING工作在应用层,它直接使用网络层的ICMP协议,而没有使用传输层的TCP或UDP协议。Traceroute/tracert工作在网络层。
在考研书上看到这样的说法,google搜索未果。新手求问,这两个协议不都是利用ICMP的吗?
考研书上的每一个字单独看,都是对的。组合一起全是错的,一点价值没有,还会耗时间与精力。
对计算机网络真的感兴趣,放弃“弯道超车”惯性思维。学好英文阅读,找一本纯英文原版教材,从简单的看起,一步步深入,直到到达终点。过程看似慢,实则快。至少不会把你带到沟里,跌倒沟里还不自知,嘴里还喃喃自语,怎么google搜索未果?
无论用TCP、UDP、ICMP编写的Ping程序,都是OSI七层参考模型的第七层,它的名字是Application,中文应用层。 加亮的3处是等价的,可以互相替代使用。
假设用ICMP编写的Ping,通过call raw_socket,由raw_socket工厂完成Ping包的生产,并由物理网络接口发出。
Ping8.8.8.8
ping包(Echo Request)到达8.8.8.8的网卡并deliver给IP(网络层),IP层尝试用8.8.8.8与本地接口IP地址链表一一match,matched到之后做完IP层的处理工作,根据IP头的protocol = 1,知道这是ICMP报文,需要ICMP模块处理,提交给ICMP函数集处理。
TCP/IP函数集位于内核空间,ICMP属于TCP/IP的成员,自然也是内核空间。
ICMP函数,发现packet 的ICMP type =echo request,于是立马同步将该packet反弹回去。反弹之前,需要做以下update工作。
ICMP type = echo reply
IP源地址(1.1.1.1)与目的地址(8.8.8.8)互换
TTL 被Reset成64、128、255
IP id由IP层update
IP重新计算checksum
当Ping包返回时,先到达网卡,deliver给IP层。IP层用目的IP=1.1.1.1尝试匹配本地接口链表的IP。成功匹配,packet被标记为local。IP检查protocol =ICMP(1),于是delivery给ICMP函数集。
ICMP函数集提取ICMP type=echo reply,知道自己不能继续处理。
用三元组:ICMP、1.1.1.1、8.8.8.8来尝试match本地的socket的hash链表。
成功matched到该socket,将Ping包放入该socket的receive queue。并wake up该socket关联的Ping进程。被唤醒的Ping进程通过recv将receive queue里的packet读出,根据echo reply的sequence number与本地发出的echo request的sequence number进行match,matched到了计算2者的时间差,得到RTT时间,然后打印到屏幕上。
如果在默认timeout=2秒时间没有matched到echo request的sequence number,timer自动call timeout处理函数,打印timeout。
这就是基于ICMP报文传输的Ping的完整工作流程。 由于Ping报文从离开原始主机的网卡开始其,在中继路由节点、终点(反弹)工作在IP层。于是就有了,Ping程序开始检测从源主机到目的主机之间的IP层的连通性,或者网络层的连通性,或者OSI参考模型的第三层的连通性,加亮的三处是等价的。
但是光靠Ping有时是不够的,比如Ping 8.8.8.8 不通,接下来怎么办?
接下来要判断在你的主机、8.8.8.8之间到底是哪里不通。需要用另外一个工具,traceroute。
Traceroute主要用UDP socket编写,traceroute使用UDP socket工厂生成udp报文。
Traceroute 8.8.8.8
第一轮三次:TTL=1
到达first hop路由器,TTL-1=0,于是发出ICMP ttl expired的ERROR。
第2轮三次:TTL=2
到达first hop路由器,TTL-1=0,于是发出ICMP ttl expired 的ERROR。
经过N次,到达8.8.8.8主机。
到达网卡,deliver给IP层。Protocol=17,deliver给UDP函数集。UDP根据五元组:UDP、源IP、目的IP、源端口、目的端口进行查询socket。
很抱歉,没有matched,于是发出ICMP Port Unreachable的ERROR。
ICMP Port Unreachable的ERROR报文,抵达你的主机,deliver给IP,protocol=ICMP,delivery给ICMP函数。ICMP函数无法继续处理。提取ICMP Port Unreachable的ERROR报文里的(肇事的原始报文UDP、源IP、目的IP、源端口、目的端口),查询socket,成功matched。于是将该ICMP Port Unreachable的ERROR报文放入socket 的error queue,并wake up该socket关联的进程,这里为traceroute。
Traceroute被wake up之后,recv自己的error queue里的ICMP Port Unreachable的ERROR报文,知道抵达终点。
于是traceroute打印trace complete。
上文的很抱歉,没有matched,为什么没有matched?
traceroute程序随机挑选了一个目的端口,比如56388,恰好8.8.8.8没有这个进程绑定该端口号,自然不会matched。
如果8.8.8.8上恰好有一个进程绑定56388端口,且UDP socket的状态为dis-connected状态,你猜会发生什么?
traceroute报文会被该进程接收,不会发出ICMP Port Unreachable的ERROR报文。
源主机的traceroute就会超时,继续TTL++,然后继续超时。。。
推荐站内搜索:最好用的开发软件、免费开源系统、渗透测试工具云盘下载、最新渗透测试资料、最新黑客工具下载……




还没有评论,来说两句吧...