PCEVA,PC绝对领域,探寻真正的电脑知识
开启左侧

老黄等弄网络的来……

[复制链接]
ach9999 发表于 2010-5-1 16:35 | 显示全部楼层 |阅读模式
点击数:4157|回复数:8
问个问题啊  现在我在用代理玩游戏  
来自 202.167.234.249 的回复: 字节=32 时间=29ms TTL=53
来自 202.167.234.249 的回复: 字节=32 时间=28ms TTL=53
这样数据是测试代理服务器的, 时间当然是越小越好

但是TTL是什么?  有什么意义?  对于用玩游戏代理 大还是小 比较好呢?
neeyuese 发表于 2010-5-1 16:45 | 显示全部楼层
存活時間(Time To Live,簡寫TTL)是電腦網路技術的一個術語,指一個封包在通過一個網路時,最長可以逗留的時間。每當封包經過一個路由器,其存活時間就會減一。當其存活時間是 0 時,主機便取消封包,並傳送一個ICMP TTL‎封包給原封包的發出者。其目的為預防封包因不正確的路由表等等的因素造成循環而無法送達。

评分

参与人数 1活跃度 +1 收起 理由
ach9999 + 1 我很赞同

查看全部评分

ach9999  楼主| 发表于 2010-5-1 17:14 | 显示全部楼层
按照这个意思  一般来说 TTL越大越好吧?
在野 发表于 2010-5-1 17:51 | 显示全部楼层
回复 3# ach9999


    一般都足够大了

所以没有多大影响

所以这个跟性能无关

这个选多少完全是随意的

不同的系统有它固定的偏好

评分

参与人数 1活跃度 +1 收起 理由
ach9999 + 1 恶意灌水

查看全部评分

gmx168 发表于 2010-5-1 19:14 | 显示全部楼层
自己摆渡一下嘛,多了去了。


TTL是IP协议包中的一个值,它告诉网络路由器包在网络中的时间是否太长而应被丢弃。有很多原因使包在一定时间内不能被传递到目的地。例如,不正确的路由表可能导致包的无限循环。所以需要在包中设置这样一个值,包在每经过一个节点,将这个值减1,反复这样操作,最终可能造成两个结果:包在这个值还为正数的时候到达了目的地,或者是在经过一定数量的节点后,这个值减为了0。前者代表完成了一次正常的传输,后者代表包可能选择了一条非常长的路径甚至是进入了环路,这显然不是我们期望的,所以在这个值为0的时候,网络设备将不会再传递这个包而是直接将他抛弃,并发送一个通知给包的源地址,说这个包已死。 第二个问题,通过TTL值我们能得到什么 其实TTL值这个东西本身并代表不了什么,对于使用者来说,关心的问题应该是包是否到达了目的地而不是经过了几个节点后到达。但是TTL值还是可以得到有意思的信息的。 每个操作系统对TTL值得定义都不同,这个值甚至可以通过修改某些系统的网络参数来修改,例如Win2000默认为128,通过注册表也可以修改。而Linux大多定义为64。不过一般来说,很少有人会去修改自己机器的这个值的,这就给了我们机会可以通过ping的回显TTL来大体判断一台机器是什么操作系统。如你看到112,可能是初始128,跳了16个节点,或者是初始160,跳了48次。  
  不同的操作系统,它的TTL值默认值是不相同的。默认情况下,Linux系统的TTL值为64或255,Windows NT/2000/XP系统的TTL值为128,Windows 98系统的TTL值为32,UNIX主机的TTL值为255。  

  以我公司2台机器为例 看如下命令 ping 61.152.93.131   

Pinging 61.152.93.131 with 32 bytes of data:   
Reply from 61.152.93.131: bytes=32 time=21ms TTL=118   
Reply from 61.152.93.131: bytes=32 time=19ms TTL=118   
Reply from 61.152.93.131: bytes=32 time=18ms TTL=118   
Reply from 61.152.93.131: bytes=32 time=22ms TTL=118   
Ping statistics for 61.152.93.131: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss   
Approximate round trip times in milli-seconds:  
Minimum = 18ms, Maximum = 22ms, Average = 20ms   

ping 61.152.104.40 Pinging 61.152.104.40 with 32 bytes of data:   
Reply from 61.152.104.40: bytes=32 time=28ms TTL=54   
Reply from 61.152.104.40: bytes=32 time=18ms TTL=54   
Reply from 61.152.104.40: bytes=32 time=18ms TTL=54   
Reply from 61.152.104.40: bytes=32 time=13ms TTL=54   
Ping statistics for 61.152.104.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss   
Approximate round trip times in milli-seconds:   
Minimum = 13ms, Maximum = 28ms, Average = 19ms   
第一台TTL为118,则基本可以判断这是一台Windows机器,从我的机器到这台机器经过了10个节点,因为128-118=10。而第二台应该是台Linux,理由一样64-54=10。 了解了上面的东西,可能有人会有一些疑问,例如以下: 1,不是说包可能走很多路径吗,为什么我看到的4个包TTL都是一样的,没有出现不同? 这是由于包经过的路径是经过了一些最优选择算法来定下来的,在网络拓扑稳定一段时间后,包的路由路径也会相对稳定在一个最短路径上。具体怎么算出来的要去研究路由算法了,不在讨论之列。 2,对于上面例子第二台机器,为什么不认为它是经过了74个节点的Windows机器?因为128-74=54。 对于这个问题,我们要引入另外一个很好的ICMP协议工具。不过首先要声明的是,一个包经过74个节点这个有些恐怖,这样的路径还是不用为好。 要介绍的这个工具是tracert(*nix下为traceroute),让我们来看对上面的第二台机器用这个命令的结果 tracert 61.152.104.40   
Tracing route to 61.152.104.40 over a maximum of 30 hops   
1 13 ms 16 ms 9 ms 10.120.32.1   
2 9 ms 9 ms 11 ms 219.233.244.105   
3 12 ms 10 ms 10 ms 219.233.238.173   
4 15 ms 15 ms 17 ms 219.233.238.13   
5 14 ms 19 ms 19 ms 202.96.222.73   
6 14 ms 17 ms 13 ms 202.96.222.121   
7 14 ms 15 ms 14 ms 61.152.81.86   
8 15 ms 14 ms 13 ms 61.152.87.162   
9 16 ms 16 ms 28 ms 61.152.99.26   
10 12 ms 13 ms 18 ms 61.152.99.94   
11 14 ms 18 ms 16 ms 61.152.104.40   
Trace complete.   
从这个命令的结果能够看到从我的机器到服务器所走的路由,确实是11个节点(上面说10个好像是我犯了忘了算0的错误了,应该是64-54+1,嘿嘿),而不是128的TTL经过了70多个节点。 既然已经说到这里了,不妨顺便说说关于这两个ICMP命令的高级一点的东西。 首先是ping命令,其实ping有这样一个参数,可以无视操作系统默认TTL值而使用自己定义的值来发送ICMP Request包。 例如还是用那台Linux机器,用以下命令: ping 61.152.104.40 -i 11   
Pinging 61.152.104.40 with 32 bytes of data:  
Reply from 61.152.104.40: bytes=32 time=10ms TTL=54   
Reply from 61.152.104.40: bytes=32 time=13ms TTL=54   
Reply from 61.152.104.40: bytes=32 time=10ms TTL=54   
Reply from 61.152.104.40: bytes=32 time=13ms TTL=54   
Ping statistics for 61.152.104.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),   
Approximate round trip times in milli-seconds:   
Minimum = 10ms, Maximum = 13ms, Average = 11ms   
这个命令我们定义了发包的TTL为11,而前面我们知道,我到这台服务器是要经过11个节点的,所以这个输出和以前没什么不同。现在再用这个试试看: ping 61.152.104.40 -i 10   
Pinging 61.152.104.40 with 32 bytes of data:   
Reply from 61.152.99.94: TTL expired in transit.   
Reply from 61.152.99.94: TTL expired in transit.   
Reply from 61.152.99.94: TTL expired in transit.   
Reply from 61.152.99.94: TTL expired in transit.   
Ping statistics for 61.152.104.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),   
Approximate round trip times in milli-seconds:   
Minimum = 0ms, Maximum = 0ms, Average = 0ms   
可以看到,结果不一样了,我定义了TTL为10来发包,结果是TTL expired in transit.就是说在到达服务器之前这个包的生命周期就结束了。注意看这句话前面的ip,这个ip恰好是我们前面tracert结果到服务器之前的最后1个ip,包的TTL就是在这里减少到0了,根据我们前面的讨论,当TTL减为0时设备会丢弃包并发送一个TTL过期的ICMP反馈给源地址,这里的结果就是最好的证明。 通过这里再次又证明了从我机器到服务器是经过了11个节点而不是70多个,呵呵。 最后再巩固一下知识,有人可能觉得tracer这个命令很神奇,可以发现一个包所经过的路由路径。其实这个命令的原理就在我们上面的讨论中。 想象一下,如果我给目的服务器发送一个TTL为1的包,结果会怎样? 根据前面的讨论,在包港出发的第一个节点,TTL就会减少为0,这时这个节点就会回应TTL失效的反馈,这个回应包含了设备本身的ip地址,这样我们就得到了路由路径的第一个节点的地址。 因此,我们继续发送TTL=2的包,也就受到第二个节点的TTL失效回应 依次类推,我们一个一个的发现,当最终返回的结果不是TTL失效而是ICMP Response的时候,我们的tracert也就结束了,就是这么简单。 顺便补一句ping命令还有个-n的参数指定要发包的数量,指定了这个数字就会按照你的要求来发包了而不是默认的4个包。如果使用-t参数的话,命令会一直发包直到你强行中止它。

评分

参与人数 1活跃度 +5 收起 理由
ach9999 + 5 我很赞同

查看全部评分

xxy 发表于 2010-5-1 21:31 | 显示全部楼层
菜绵羊爬过
NUMB 发表于 2010-5-2 10:07 | 显示全部楼层
ping -n (次数) -l (长度)
世纪冰雷 发表于 2010-5-2 13:49 | 显示全部楼层
一般我们把他叫他吓一跳{:3_48:}
这个值嘛。不会对速度有所影响的。不用理~
ach9999  楼主| 发表于 2010-5-2 14:40 | 显示全部楼层
本帖最后由 ach9999 于 2010-5-2 14:42 编辑

谢谢  我明白了  

我学习到的是这一段话  哈哈

老黄的解释让我学习不少东西   

搞定
您需要登录后才可以回帖 登录 | 注册

本版积分规则

快速回复 返回顶部