为什么linux下的traceroute默认选项不能工作呢?

问题:
在命令行下输入: 
traceroute www.google.com
屏幕打印是这样的:
traceroute to www.google.com (66.249.89.104), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
没有得到任何中间路由器的信息。

分析:
traceroute的基本原理就是发出TTL字段为1-n的ip包,然后等待路由器的ICMP超时回复,进而记录
下来经过的路由器。通过man traceroute 可以看到,traceroute可以在ip包中放三种数据:
1) 使用UDP包(默认选项是-U)
2)使用TCP包 选项是-T
3)使用ICMP包 选项是-I
而且每个包traceroute都发3次。
分别用-T,-I选项试试。
发现TCP包时候也不行,但是-I选项是有效果的:
 1  10.10.20.1 (10.10.20.1)  3.611 ms * *
 2  * * *
 3  10.10.10.1 (10.10.10.1)  3.590 ms * *
 4  * * *
 5  * * *
 6  * * 61.130.125.25 (61.130.125.25)  10.914 ms

但貌似不是全部的中间路由ip,有些包丢失了。
进一步查看traceroute的选项,有一个-z项,基本意思是设置探测包的发送间隔,默认是0,就是连续发送。设置这个的目的
是因为有些路由器设置了icmp rate limit. 继续研究为什么路由器要设置icmp的发送速率。
google之:原来是为了应付DOS攻击,进而限制端口发出的icmp的速率。

既然清楚了,那就尝试下:
sudo traceroute -I www.google.com -z 0.005 -q 1
traceroute to www.google.com (66.249.89.104), 30 hops max, 60 byte packets
 1  10.10.20.1 (10.10.20.1)  1.914 ms
 2  10.10.20.1 (10.10.20.1)  2.109 ms
 3  10.10.10.1 (10.10.10.1)  1.081 ms
 4  115.238.62.113 (115.238.62.113)  2.468 ms
 5  220.191.158.213 (220.191.158.213)  2.177 ms
 6  61.130.125.25 (61.130.125.25)  2.016 ms
 7  220.191.158.241 (220.191.158.241)  2.419 ms
 8  202.97.55.5 (202.97.55.5)  4.757 ms
 9  202.97.33.14 (202.97.33.14)  5.293 ms
10  202.97.33.2 (202.97.33.2)  5.161 ms
11  202.97.33.5 (202.97.33.5)  4.972 ms
12  202.97.5.138 (202.97.5.138)  41.524 ms
13  209.85.255.80 (209.85.255.80)  53.241 ms
14  209.85.249.195 (209.85.249.195)  68.928 ms
15  72.14.236.126 (72.14.236.126)  52.108 ms
16  66.249.89.104 (66.249.89.104)  48.105 ms

果真可以了。
如果想看具体traceroute发了什么包,路由器返回了什么包,可以用wireshark抓包看看.

<think>好的,用户问的是Linux系统默认的ping命令是否为traceroute,以及它们之间的关系。首先,我需要明确这两个工具的不同功能和用途。 Ping命令主要用于测试主机之间的连通性,发送ICMP Echo请求并等待回复。而traceroute则是用来探测数据包从源到目的地的路径,显示途径的每一跳。用户可能混淆了两者的功能,认为它们有从属关系,但实际上它们是独立的工具,用途不同。 接下来,需要解释它们的底层协议差异。Ping使用ICMP协议,而Linux下的traceroute默认使用UDP协议,目的端口从33435开始递增。但用户提到的情况中,防火墙可能会阻止UDP流量,导致traceroute不通,这时候可以用-I选项切换为ICMP协议。这和引用中的资料[^1][^2]一致,需要指出这一点。 另外,用户可能遇到traceroute不通的情况,需要给出解决方法,比如使用-I参数或改用mtr工具,这也是引用[^2]提到的内容。同时,需要提到Windows的tracert默认使用ICMP,和Linux不同,避免用户混淆。 还要注意traceroute的实现细节,比如TTL递增和端口变化,引用[^3]中的说明,解释为什么某些情况下结果可能不准确,比如目的端口被监听。这帮助用户理解工具的限制。 最后,总结两者的关系:都是网络诊断工具,但功能不同,协议和实现方式有差异。需要确保回答结构清晰,分点说明区别和联系,并附上相关问题供用户进一步学习。</think>### Linux默认的ping命令与traceroute的关系 #### 1. 功能定位 - **`ping`命令**:用于测试主机间的网络连通性,通过发送ICMP协议的$Echo\ Request$包并接收$Echo\ Reply$包,计算往返时间(RTT)和丢包率。 - **`traceroute`命令**:用于追踪数据包从源主机到目标主机的完整路径,通过TTL(Time-To-Live)值的递增实现路径探测[^3]。 #### 2. 协议与实现差异 | 特性 | ping (Linux) | traceroute (Linux) | |-------------------|-------------------------|-----------------------------| | **默认协议** | ICMP协议 | UDP协议(目的端口33435起)[^3] | | **数据包类型** | ICMP Echo Request/Reply | UDP包 + ICMP错误响应 | | **探测方式** | 单向连通性验证 | 路径节点逐跳探测 | | **参数关联** | 无 | 可通过`-I`切换为ICMP协议[^1] | #### 3. 典型问题场景 当Linux服务器能`ping`通但`traceroute`不通时,通常因为: 1. 中间路由节点过滤了UDP流量(防火墙默认行为) 2. 目标主机的33435+端口被占用 3. 网络设备禁用了ICMP错误报文返回 此时可通过以下方式解决: ```bash # 强制使用ICMP协议进行路由追踪 traceroute -I example.com # 或使用mtr工具(默认ICMP协议) mtr example.com ``` #### 4. 设计原理对比 - **`ping`实现**: 基于ICMP协议,通过计算$RTT = t_{reply} - t_{request}$评估网络质量,其丢包率计算为: $$ \text{丢包率} = \frac{\text{丢失包数}}{\text{发送包数}} \times 100\% $$ - **`traceroute`实现**: 1. 发送TTL=1的UDP包,触发第一跳路由返回ICMP$Time\ Exceeded$错误 2. 逐步递增TTL值直至到达目标主机 3. 目标主机返回ICMP$Destination\ Unreachable$(若端口未监听) #### 5. 工具关联性 虽然两者均为网络诊断工具,但: - **无依赖关系**:`ping`并非`traceroute`的前置条件 - **互补关系**: `ping`用于验证端到端连通性 `traceroute`用于定位路径故障点 - **协议可互通**:通过`traceroute -I`使两者均使用ICMP协议[^2]
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值