F4V/M3U8/比特率/LocalDNS/HttpDNS/traceroute

最新推荐文章于 2023-06-09 13:54:47 发布

chenxiaoning87

最新推荐文章于 2023-06-09 13:54:47 发布

阅读量2.3k

点赞数

文章标签： F4VM3U8比特率LocalDNSHt

一、F4V是什么格式

　　F4V是Adobe公司为了迎接高清时代而推出继FLV格式后的支持H.264的F4V流媒体格式。它和FLV主要的区别在于，FLV格式采用的是H263编码，而F4V则支持H.264编码的高清晰视频，码率最高可达50Mbps。

　　现在主流的视频网站(如奇艺、土豆、酷6、优酷)等其他网站都开始用H264编码的F4V文件，H264编码的F4V文件，相同文件大小情况下，清晰度明显比On2 VP6和H263编码的FLV要好。土豆和56发布的视频大多数已为F4V，但下载后缀为FLV，这也是F4V特点之一。

　　二、F4V怎么打开

　　作为一种更小更清晰，更利于在网络传播的格式，F4V已经逐渐取代了传统FLV，也已经被大多数主流播放器兼容播放，而不需要通过转换等复杂的方式。如果有播放器不能打开F4V格式的视频，那么可以将后缀名改为FLV的即可，不会影响播放和视频效果。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

M3U本质上说不是音频文件，它是音频文件的列表文件，是纯文本文件。你下载下来打开它，播放软件并不是播放它，而是根据它的记录找到网络地址进行在线播放。

M3U文件的大小很小，也就是因为它里面没有任何音频数据。把M3U文件直接转换为音频文件是不可能的，除非你把它指向的音频文件下载下来再作处理。m3u格式的文件只是存储多媒体播放列表，提供了一个指向其他位置的音频视频文件的索引，你播放的还是那些被指向的文件，用记事本打开m3u文件可以查看所指向文件的地址及文件的属性，以选用合适播放器播放。

-----------------------------------------------

M3U8也是一种M3U，只是它的编码格式是UTF-8格式。M3U用Latin-1字符集编码。

M3U是歌曲的目录信息，下载.FLAC无损格式的音频时候，会伴随一个M3U目录文件。。

---------------------

HLS科普1 HLS和M3U8简介

http://blog.csdn.net/cabbage2008/article/details/50522190

HLS(HTTP Live Streaming)是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的基于HTTP协议的流媒体解决方案。在 HLS 技术中 Web 服务器向客户端提供接近实时的音视频流。但在使用的过程中是使用的标准的 HTTP 协议，所以这时，只要使用 HLS 的技术，就能在普通的 HTTP 的应用上直接提供点播和直播。在App Store中的视频相关的应用，基本都是应用的此种技术。该技术基本原理是将视频文件或视频流切分成小片(ts)并建立索引文件(m3u8)。支持的视频流编码为H.264，音频流编码为AAC。

Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。常用的流媒体协议主要有 HTTP 渐进下载和基于 RTSP/RTP 的实时流媒体协议，这二种基本是完全不同的东西，目前比较方便又好用的是用 HTTP 渐进下载方法。在这个中 apple 公司的 HTTP Live Streaming 是这个方面的代表。它最初是苹果公司针对iPhone、iPod、iTouch和iPad等移动设备而开发的流.现在见到在桌面也有很多应用了，HTML5 是直接支持这个。但是HLS协议的小切片方式会生成大量的文件，存储或处理这些文件会造成大量资源浪费。如果要实现数天的时移，索引量将会是个巨额数字，并明显影响请求速度。因此，HLS协议对存储I/O要求相当苛刻。对此，也有公司提出了非常好的解决方案。新型点播服务器系统，独创了内存缓存数据实时切片技术，颠覆了这种传统实现方法，从根本上解决了大量切片的碎片问题，使得单台服务器的切片与打包能力不再是瓶颈。其基本原理如下：不将TS切片文件存到磁盘，而是存在内存当中，这种技术使得服务器的磁盘上面不再会有“数以吨计”的文件碎片，极大减少了磁盘的I/O次数，延长了服务器磁盘的使用寿命，极大提高了服务器运行的稳定性。同时，由于使用这种技术，使得终端请求数据时直接从服务器的内存中获取，极大提高了对终端数据请求的反应速度，优化了视频观看体验。

简单归纳起来就是：首先将一个完整视频分成多个TS视频文件，用户下载m3u8文件，通过m3u8文件的索引地址播放具体的每个小段视频

1. M3U8文件概念 M3U8文件是指UTF-8编码格式的M3U文件。M3U文件是记录了一个索引纯文本文件，打开它时播放软件并不是播放它，而是根据它的索引找到对应的音视频文件的网络地址进行在线播放。

2. M3U8文件举例 例如使用云图TV点播直播节目时，发送请求： http://121.199.63.236:7613/m3u8/cckw1/szws.m3u8?from=bab&fun=yes&chk=y&chunk=xax&ppw=yuntutv&auth=yuntutvyuntutvyuntutv&auth=yuntutvyuntutvyuntutv&nwtime=1406515232&sign=033d5483609e6bc87987fc7d2f30a024 返回M3U8文件，文件内容如下

[cpp]view plaincopy
#EXTM3U  
#EXT-X-MEDIA-SEQUENCE:140651513  
#EXT-X-TARGETDURATION:10  
#EXTINF:8,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651513[140651513].ts  
#EXTINF:9,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651514[140651514].ts  
#EXTINF:11,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651515[140651515].ts  
#EXTINF:10,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651516[140651516].ts  
#EXTINF:12,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651517[140651517].ts  
#EXTINF:8,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651518[140651518].ts  
#EXTINF:12,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651519[140651519].ts  
#EXTINF:8,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651520[140651520].ts  
#EXTINF:9,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651521[140651521].ts  
#EXTINF:13,  
http://vapp1.fw.live.cntv.cn/cache/289_/seg0/index140651522[140651522].ts  

然后根据索引的中链接请求下载音视频并进行播放

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

比特率

锁定

本词条由 “科普中国”百科科学词条编写与应用工作项目审核。

比特率是指每秒传送的比特(bit)数。单位为 bps(Bit Per Second)，比特率越高，传送数据速度越快。声音中的比特率是指将模拟声音信号转换成数字声音信号后，单位时间内的二进制数据量，是间接衡量音频质量的一个指标。视频中的比特率（码率）原理与声音中的相同，都是指由模拟信号转换为数字信号后，单位时间内的二进制数据量。

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

所谓视频编码方式就是指通过特定的压缩技术，将某个视频格式的文件转换成另一种视频格式文件的方式。视频流传输中最为重要的编解码标准有国际电联的H.261、H.263、H.264，运动静止图像专家组的M-JPEG和国际标准化组织运动图像专家组的MPEG系列标准，此外在互联网上被广泛应用的还有Real-Networks的RealVideo、微软公司的WMV以及Apple公司的QuickTime等。

--------------------------------------------------------------------------------------------------NAT（Network Address Translation，网络地址转换）

----------------------------------------------------------------------------------

1） DNS：域名系统。
2）LocalDNS：提供缓存和递归的服务。
3）授权DNS：提供权威解析。

用户发送DNS请求到LDNS系统，首先到达缓存模块，如果缓存模块缓存有该问题的答案，直接组建DNS响应包返回给用户；如果缓存模块没有该问题的答案，将该请求交给递归模块处理，递归模块递归查找该问题的答案。递归模块在递归查找过程中，有权威服务器返回问题的答案时，缓存模块缓存该答案，并将结果返回给用户。所有来自权威服务器的DNS响应包，需要将包中的记录缓存到缓存系统中，以便下一次直接从缓存系统中查找。

Local DNS：就是负责执行递归查询的。由各大运行商提供。

----------------------------------------

https://jingyan.baidu.com/article/48b37f8d38069f1a6564887f.html--

什么是DNS呢:

DNS（Domain Name System，域名系统），Internet上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。

通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。

DNS协议运行在UDP协议之上，使用端口号53。

最关键的是下面这句，DNS协议是运行在UDP协议之上的

重要的事情说三遍，

DNS协议是运行在UDP协议之上的

DNS协议是运行在UDP协议之上的

DNS协议是运行在UDP协议之上的
现在有DNS可能存在的问题：

UDP协议不是可靠的传输协议，会丢包的

人家设计的时候就没有要求实时、准确，丢就丢了
现有DNS解析存在的其它问题：

域名劫持：

域名劫持是互联网攻击的一种方式，通过攻击域名解析服务器（DNS），

或伪造域名解析服务器（DNS）的方法，

把目标网站域名解析到错误的地址从而实现用户无法访问目标网站的目的。
HTTPDNS和上面说的DNS有什么差别呢

细心的tx已经发现HTTP这个关键字

是的，差别就在传输协议上

DNS基于UDP协议

HTTPDNS基于HTTP协议

HTTPDNS：

HTTPDNS使用HTTP协议进行域名解析，代替现有基于UDP的DNS协议
使用HTTPDNS有什么好处呢

防劫持

精准调度

0ms解析延迟
6

使用HTTPDNS的场景

App使用的比较多，因为传统的DNS已经满足现在的需要了，但手机App对DNS解析有更高的要求

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

HttpDNS:

http://www.ttlsa.com/web/httpdns-detailed-service/

摘要

对于互联网，域名是访问的第一跳，而这一跳很多时候会“失足”，导致访问错误内容，失败连接等，让我们在互联网上畅游的爽快瞬间消失，而对于这关键的第一跳，鹅厂也在持续深入研究和思考对策，今天小编就邀请了我们负责这块域名解析的好伙伴—廖伟健同学跟我们做一个分享。同时，今天小编也非常希望了解大伙对这块内容的感受，所以今天文中加入了投票功能，希望您投上神圣的一票哦。事不延迟，我们启程！

但凡使用域名来给用户提供服务的互联网企业，都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。那么对于腾讯这样的域名数量在10万级别的互联网公司来讲，域名解析异常的情况到底有多严重呢？每天腾讯的分布式域名解析监测系统在不停地对全国所有的重点LocalDNS进行探测，腾讯域名在全国各地的日解析异常量是已经超过了80万条。这给腾讯的业务带来了巨大的损失。为此腾讯建立了专业的团队与各个运营商进行了深度沟通，但是由于各种原因，处理效率及效果均不能达到腾讯各业务部门的需求。除了和运营商进行沟通，有没有一种技术上的方案，能从根源上解决域名解析异常及用户访问跨网的问题呢？

一、问题根源：

要解决问题，我们得先得了解下现在国内各ISP的LocalDNS的基本情况。国内运营商LocalDNS造成的用户访问异常可以归为下三类：

1、域名缓存：

域名缓存很好理解，就是LocalDNS缓存了腾讯的域名的解析结果，不向腾讯权威DNS发起递归，示意图如下：

为何LocalDNS要把域名解析结果进行缓存呢？原因有以下几个：

（1）保证用户访问流量在本网内消化：国内的各互联网接入运营商的带宽资源、网间结算费用、IDC机房分布、网内ICP资源分布等存在较大差异。为了保证网内用户的访问质量，同时减少跨网结算，运营商在网内搭建了内容缓存服务器，通过把域名强行指向内容缓存服务器的IP地址，就实现了把本地本网流量完全留在了本地的目的。

（2）推送广告：有部分LocalDNS会把部分域名解析结果的所指向的内容缓存，并替换成第三方广告联盟的广告。

这种类型的行为就是我们常说的域名缓存，域名缓存会导致用户产生以下的访问异常：

A、仅对80端口的http服务做了缓存，如果域名是通过https协议或其它端口提供服务的，用户访问就会出现失败。比如支付服务、游戏通过指定端口连接connect server服务等。

B、缓存服务器的运维水平参差不齐，时有出现缓存服务器故障导致用户访问异常的问题。

2、解析转发：

除了域名缓存以外，运营商的LocalDNS还存在解析转发的现象。解析转发是指运营商自身不进行域名递归解析，而是把域名解析请求转发到其它运营商的递归DNS上的行为。正常的LocalDNS递归解析过程是这样的：

而部分小运营商为了节省资源，就直接将解析请求转发到了其它运营的递归LocalDNS上去了：

这样的直接后果就是腾讯权威DNS收到的域名解析请求的来源IP就成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。

3、LocalDNS递归出口NAT：

LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归，但是因为在网络上存在多出口且配置了目标路由NAT，结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址：

这样的直接后果就是GSLB DNS收到的域名解析请求的来源IP还是成了其它运营商的IP，最终导致用户流量被导向了错误的IDC，用户访问变慢。

二、现有的解决方案及存在的问题：

运营商的LocalDNS解析域名异常，给对用户访问腾讯业务的体验造成了非常大的损害。那么我们是如何处理这些域名解析异常的问题的呢？

1、实时监控+商务推动：

这种方案是目前腾讯的运营团队一直在使用的方案。这种方案就是周期比较长，毕竟通过行政手段来推动运营商来解决这个问题是比较耗时的。另外我们通过大数据分析，得出的结论是Top 3的问题用户均为移动互联网用户。对于这部分用户，我们有什么技术手段可以解决以上的问题呢？

2、绕过自动分配DNS，使用114dns或Google public DNS：

这个方案看上去很美好，114dns是国内最大的中立缓存DNS，而Google又是秉承不作恶理念的互联网工程帝国巨鳄，而且腾讯的权威DNS又支持edns-client-subnet功能，能直接识别使用Google publicDNS解析腾讯域名的用户的IP地址，不会出现流量调度失效。但是问题来了：

（1）如何在用户侧构造域名请求：对于PC端的客户端来说，构造一个标准的DNS请求包并不算什么难事。但在移动端要向一个指定的LocalDNS上发送标准的DNS请求包，而且要兼容各种iOS和android的版本的话，技术上是可行的，只是兼容的成本会很高。

（2）推动用户修改配置极高：如果要推动用户手动修改PC的DNS配置的话，在PC端和手机客户端的WiFI下面还算勉强可行。但是要用户修改在移动互联网环境下的DNS配置，其难度不言而喻。

3、完全抛弃域名，自建connectcenter进行流量调度：

如果要采用这种这种方案的话，首先你就得要拿到一份准确的IP地址库来判断用户的归属，然后再制定个协议搭个connect center来做调度，然后再对接入层做调度改造。这种方案和2种方案一样，不是不能做，只是成本会比较高，尤其对于腾讯这种业务规模如此庞大的公司而言。

三、利用HttpDNS解决用户域名解析异常：

既然上面的方案都存在那么多的问题，那有没有一种调度精准、成本低廉、配置方便的基于域名的流量调度系统呢？答案是肯定的。腾讯公司的GSLB 团队推出了一种全新的域名解析调度系统：HttpDNS。HttpDNS是为移动客户端量身定做的基于Http协议和域名解析的流量调度解决方案，专治LocalDNS解析异常以及流量调度不准。详细介绍如下：

（1）HttpDNS基本原理：

HttpDNS的原理非常简单，主要有两步：

A、客户端直接访问HttpDNS接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP。（基于容灾考虑，还是保留次选使用运营商LocalDNS解析域名的方式）

B、客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例，通过在header中指定host字段，向HttpDNS返回的IP发送标准的Http请求即可。

（2）HttpDNS优势：

从原理上来讲，HttpDNS只是将域名解析的协议由DNS协议换成了Http协议，并不复杂。但是这一微小的转换，却带来了无数的收益：

A、根治域名解析异常：由于绕过了运营商的LocalDNS，用户解析域名的请求通过Http协议直接透传到了腾讯的HttpDNS服务器IP上，用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。

B、调度精准：HttpDNS能直接获取到用户IP，通过结合腾讯自有专利技术生成的IP地址库以及测速系统，可以保证将用户引导的访问最快的IDC节点上。

C、实现成本低廉：接入HttpDNS的业务仅需要对客户端接入层做少量改造，无需用户手机进行root或越狱；而且由于Http协议请求构造非常简单，兼容各版本的移动操作系统更不成问题；另外HttpDNS的后端配置完全复用现有权威DNS配置，管理成本也非常低。总而言之，就是以最小的改造成本，解决了业务遭受域名解析异常的问题，并满足业务精确流量调度的需求。

D、扩展性强：HttpDNS提供可靠的域名解析服务，业务可将自有调度逻辑与HttpDNS返回结果结合，实现更精细化的流量调度。比如指定版本的客户端连接请求的IP地址，指定网络类型的用户连接指定的IP地址等。

当然各位可能会问：用户将首选的域名解析方式切换到了HttpDNS，那么HttpDNS的高可用又是如何保证的呢？另外不同运营商的用户访问到同一个HttpDNS的服务IP，用户的访问延迟如何保证？

为了保证高可用及提升用户体验，HttpDNS通过接入了腾讯公网交换平台的BGP Anycast网络，与全国多个主流运营商建立了BGP互联，保证了这些运营商的用户能够快速地访问到HttpDNS服务；另外HttpDNS在多个数据中心进行了部署，任意一个节点发生故障时均能无缝切换到备份节点，保证用户解析正常。

四、接入效果及未来展望：

当前HttpDNS已在腾讯内部接入了多个业务，覆盖数亿用户，并已持续稳定运行超过一年时间。而接入了HttpDNS的业务在用户访问体验方面都有了非常大的提升。以某个接入HttpDNS的业务为例，该业务仅通过接入HttpDNS，在未做任何其它优化的情况下，用户平均访问延迟下降超过10%，访问失败率下降了超过五分之一，用户访问体验的效果提升非常显著。另外腾讯的HttpDNS服务除了在腾讯内部被广泛使用以外，也受到了业务同行的肯定。国内最大的publicDNS服务商114dns在受到腾讯DNS的启发下，也推出了HttpDNS服务。

在未来的日子里，腾讯GSLB团队将会在腾讯内部进一步推广HttpDNS服务，并将在实际业务的需求下对HttpDNS服务进行升级，如提供更为通用、安全、简单的接入协议，进一步提升接入用户的网络访问体验等等。希望HttpDNS能为各位在解决域名解析异常及全局流量调度失效方面提供一个简单、可行的思路，也欢迎各位业界同行与腾讯一起，就如何进行更精准的全局流量调度方面进行更为深入的讨论！

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

traceroute

http://www.cnblogs.com/peida/archive/2013/03/07/2947326.html

通过traceroute我们可以知道信息从你的计算机到互联网另一端的主机是走的什么路径。当然每次数据包由某一同样的出发点（source）到达某一同样的目的地(destination)走的路径可能会不一样，但基本上来说大部分时候所走的路由是相同的。linux系统中，我们称之为traceroute,在MS Windows中为tracert。 traceroute通过发送小的数据包到目的设备直到其返回，来测量其需要多长时间。一条路径上的每个设备traceroute要测3次。输出结果中包括每次测试的时间(ms)和设备的名称（如有的话）及其IP地址。

在大多数情况下，我们会在linux主机系统下，直接执行命令行：

traceroute hostname

而在Windows系统下是执行tracert的命令：

tracert hostname

1.命令格式：

traceroute[参数][主机]

2.命令功能：

traceroute指令让你追踪网络数据包的路由途径，预设数据包大小是40Bytes，用户可另行设置。

具体参数格式：traceroute [-dFlnrvx][-f<存活数值>][-g<网关>...][-i<网络界面>][-m<存活数值>][-p<通信端口>][-s<来源地址>][-t<服务类型>][-w<超时秒数>][主机名称或IP地址][数据包大小]

3.命令参数：

-d 使用Socket层级的排错功能。

-f 设置第一个检测数据包的存活数值TTL的大小。

-F 设置勿离断位。

-g 设置来源路由网关，最多可设置8个。

-i 使用指定的网络界面送出数据包。

-I 使用ICMP回应取代UDP资料信息。

-m 设置检测数据包的最大存活数值TTL的大小。

-n 直接使用IP地址而非主机名称。

-p 设置UDP传输协议的通信端口。

-r 忽略普通的Routing Table，直接将数据包送到远端主机上。

-s 设置本地主机送出数据包的IP地址。

-t 设置检测数据包的TOS数值。

-v 详细显示指令的执行过程。

-w 设置等待远端主机回报的时间。

-x 开启或关闭数据包的正确性检验。

4.使用实例：

实例1：traceroute 用法简单、最常用的用法

命令：

traceroute www.baidu.com

输出：

 
   [root@localhost ~] 
  # 
   traceroute www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets 
  
  1  192.168.74.2 (192.168.74.2)  2.606 ms  2.771 ms  2.950 ms 
  
  2  211.151.56.57 (211.151.56.57)  0.596 ms  0.598 ms  0.591 ms 
  
  3  211.151.227.206 (211.151.227.206)  0.546 ms  0.544 ms  0.538 ms 
  
  4  210.77.139.145 (210.77.139.145)  0.710 ms  0.748 ms  0.801 ms 
  
  5  202.106.42.101 (202.106.42.101)  6.759 ms  6.945 ms  7.107 ms 
  
  6  61.148.154.97 (61.148.154.97)  718.908 ms * bt-228-025.bta.net.cn (202.106.228.25)  5.177 ms 
  
  7  124.65.58.213 (124.65.58.213)  4.343 ms  4.336 ms  4.367 ms 
  
  8  202.106.35.190 (202.106.35.190)  1.795 ms 61.148.156.138 (61.148.156.138)  1.899 ms  1.951 ms 
  
  9  * * * 
  
 30  * * * 
  
 [root@localhost ~] 
  #

说明：

记录按序列号从1开始，每个纪录就是一跳，每跳表示一个网关，我们看到每行有三个时间，单位是 ms，其实就是-q的默认参数。探测数据包向每个网关发送三个数据包后，网关响应后返回的时间；如果您用 traceroute -q 4 www.58.com ，表示向每个网关发送4个数据包。

有时我们traceroute 一台主机时，会看到有一些行是以星号表示的。出现这样的情况，可能是防火墙封掉了ICMP的返回信息，所以我们得不到什么相关的数据包返回数据。

有时我们在某一网关处延时比较长，有可能是某台网关比较阻塞，也可能是物理设备本身的原因。当然如果某台DNS出现问题时，不能解析主机名、域名时，也会有延时长的现象；您可以加-n 参数来避免DNS解析，以IP格式输出数据。

如果在局域网中的不同网段之间，我们可以通过traceroute 来排查问题所在，是主机的问题还是网关的问题。如果我们通过远程来访问某台服务器遇到问题时，我们用到traceroute 追踪数据包所经过的网关，提交IDC服务商，也有助于解决问题；但目前看来在国内解决这样的问题是比较困难的，就是我们发现问题所在，IDC服务商也不可能帮助我们解决。

实例2：跳数设置

命令：

traceroute -m 10 www.baidu.com

输出：

 
   [root@localhost ~] 
  # 
   traceroute -m 10 www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.105), 10 hops max, 40 byte packets 
  
  1  192.168.74.2 (192.168.74.2)  1.534 ms  1.775 ms  1.961 ms 
  
  2  211.151.56.1 (211.151.56.1)  0.508 ms  0.514 ms  0.507 ms 
  
  3  211.151.227.206 (211.151.227.206)  0.571 ms  0.558 ms  0.550 ms 
  
  4  210.77.139.145 (210.77.139.145)  0.708 ms  0.729 ms  0.785 ms 
  
  5  202.106.42.101 (202.106.42.101)  7.978 ms  8.155 ms  8.311 ms 
  
  6  bt-228-037.bta.net.cn (202.106.228.37)  772.460 ms bt-228-025.bta.net.cn (202.106.228.25)  2.152 ms 61.148.154.97 (61.148.154.97)  772.107 ms 
  
  7  124.65.58.221 (124.65.58.221)  4.875 ms 61.148.146.29 (61.148.146.29)  2.124 ms 124.65.58.221 (124.65.58.221)  4.854 ms 
  
  8  123.126.6.198 (123.126.6.198)  2.944 ms 61.148.156.6 (61.148.156.6)  3.505 ms 123.126.6.198 (123.126.6.198)  2.885 ms 
  
  9  * * * 
  
 10  * * * 
  
 [root@localhost ~] 
  #

说明：

实例3：显示IP地址，不查主机名

命令：

traceroute -n www.baidu.com

输出：

 
   [root@localhost ~] 
  # 
   traceroute -n www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets 
  
  1  211.151.74.2  5.430 ms  5.636 ms  5.802 ms 
  
  2  211.151.56.57  0.627 ms  0.625 ms  0.617 ms 
  
  3  211.151.227.206  0.575 ms  0.584 ms  0.576 ms 
  
  4  210.77.139.145  0.703 ms  0.754 ms  0.806 ms 
  
  5  202.106.42.101  23.683 ms  23.869 ms  23.998 ms 
  
  6  202.106.228.37  247.101 ms * * 
  
  7  61.148.146.29  5.256 ms 124.65.58.213  4.386 ms  4.373 ms 
  
  8  202.106.35.190  1.610 ms 61.148.156.138  1.786 ms 61.148.3.34  2.089 ms 
  
  9  * * * 
  
 30  * * * 
  
 [root@localhost ~] 
  # 
   traceroute www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets 
  
  1  211.151.74.2 (211.151.74.2)  4.671 ms  4.865 ms  5.055 ms 
  
  2  211.151.56.57 (211.151.56.57)  0.619 ms  0.618 ms  0.612 ms 
  
  3  211.151.227.206 (211.151.227.206)  0.620 ms  0.642 ms  0.636 ms 
  
  4  210.77.139.145 (210.77.139.145)  0.720 ms  0.772 ms  0.816 ms 
  
  5  202.106.42.101 (202.106.42.101)  7.667 ms  7.910 ms  8.012 ms 
  
  6  bt-228-025.bta.net.cn (202.106.228.25)  2.965 ms  2.440 ms 61.148.154.97 (61.148.154.97)  431.337 ms 
  
  7  124.65.58.213 (124.65.58.213)  5.134 ms  5.124 ms  5.044 ms 
  
  8  202.106.35.190 (202.106.35.190)  1.917 ms  2.052 ms  2.059 ms 
  
  9  * * * 
  
 30  * * * 
  
 [root@localhost ~] 
  #

说明：

实例4：探测包使用的基本UDP端口设置6888

命令：

traceroute -p 6888 www.baidu.com

输出：

 
   [root@localhost ~] 
  # 
   traceroute -p 6888 www.baidu.com 
  
 traceroute to www.baidu.com (220.181.111.147), 30 hops max, 40 byte packets 
  
  1  211.151.74.2 (211.151.74.2)  4.927 ms  5.121 ms  5.298 ms 
  
  2  211.151.56.1 (211.151.56.1)  0.500 ms  0.499 ms  0.509 ms 
  
  3  211.151.224.90 (211.151.224.90)  0.637 ms  0.631 ms  0.641 ms 
  
  4  * * * 
  
  5  220.181.70.98 (220.181.70.98)  5.050 ms  5.313 ms  5.596 ms 
  
  6  220.181.17.94 (220.181.17.94)  1.665 ms !X * * 
  
 [root@localhost ~] 
  #

说明：

实例5：把探测包的个数设置为值4

命令：

traceroute -q 4 www.baidu.com

输出：

 
   [root@localhost ~] 
  # 
   traceroute -q 4 www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets 
  
  1  211.151.74.2 (211.151.74.2)  40.633 ms  40.819 ms  41.004 ms  41.188 ms 
  
  2  211.151.56.57 (211.151.56.57)  0.637 ms  0.633 ms  0.627 ms  0.619 ms 
  
  3  211.151.227.206 (211.151.227.206)  0.505 ms  0.580 ms  0.571 ms  0.569 ms 
  
  4  210.77.139.145 (210.77.139.145)  0.753 ms  0.800 ms  0.853 ms  0.904 ms 
  
  5  202.106.42.101 (202.106.42.101)  7.449 ms  7.543 ms  7.738 ms  7.893 ms 
  
  6  61.148.154.97 (61.148.154.97)  316.817 ms bt-228-025.bta.net.cn (202.106.228.25)  3.695 ms  3.672 ms * 
  
  7  124.65.58.213 (124.65.58.213)  3.056 ms  2.993 ms  2.960 ms 61.148.146.29 (61.148.146.29)  2.837 ms 
  
  8  61.148.3.34 (61.148.3.34)  2.179 ms  2.295 ms  2.442 ms 202.106.35.190 (202.106.35.190)  7.136 ms 
  
  9  * * * * 
  
 30  * * * * 
  
 [root@localhost ~] 
  #

说明：

实例6：绕过正常的路由表，直接发送到网络相连的主机

命令：

traceroute -r www.baidu.com

输出：

   [root@localhost ~] 
  # 
   traceroute -r www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.125), 30 hops max, 40 byte packets 
  
 connect: 网络不可达 
  
 [root@localhost ~] 
  #

说明：

实例7：把对外发探测包的等待响应时间设置为3秒

命令：

traceroute -w 3 www.baidu.com

输出：

 
   [root@localhost ~] 
  # 
   traceroute -w 3 www.baidu.com 
  
 traceroute to www.baidu.com (61.135.169.105), 30 hops max, 40 byte packets 
  
  1  211.151.74.2 (211.151.74.2)  2.306 ms  2.469 ms  2.650 ms 
  
  2  211.151.56.1 (211.151.56.1)  0.621 ms  0.613 ms  0.603 ms 
  
  3  211.151.227.206 (211.151.227.206)  0.557 ms  0.560 ms  0.552 ms 
  
  4  210.77.139.145 (210.77.139.145)  0.708 ms  0.761 ms  0.817 ms 
  
  5  202.106.42.101 (202.106.42.101)  7.520 ms  7.774 ms  7.902 ms 
  
  6  bt-228-025.bta.net.cn (202.106.228.25)  2.890 ms  2.369 ms 61.148.154.97 (61.148.154.97)  471.961 ms 
  
  7  124.65.58.221 (124.65.58.221)  4.490 ms  4.483 ms  4.472 ms 
  
  8  123.126.6.198 (123.126.6.198)  2.948 ms 61.148.156.6 (61.148.156.6)  7.688 ms  7.756 ms 
  
  9  * * * 
  
 30  * * * 
  
 [root@localhost ~] 
  #

说明：

Traceroute的工作原理：

Traceroute最简单的基本用法是：traceroute hostname

Traceroute程序的设计是利用ICMP及IP header的TTL（Time To Live）栏位（field）。首先，traceroute送出一个TTL是1的IP datagram（其实，每次送出的为3个40字节的包，包括源地址，目的地址和包发出的时间标签）到目的地，当路径上的第一个路由器（router）收到这个datagram时，它将TTL减1。此时，TTL变为0了，所以该路由器会将此datagram丢掉，并送回一个「ICMP time exceeded」消息（包括发IP包的源地址，IP包的所有内容及路由器的IP地址），traceroute 收到这个消息后，便知道这个路由器存在于这个路径上，接着traceroute 再送出另一个TTL是2 的datagram，发现第2 个路由器...... traceroute 每次将送出的datagram的TTL 加1来发现另一个路由器，这个重复的动作一直持续到某个datagram 抵达目的地。当datagram到达目的地后，该主机并不会送回ICMP time exceeded消息，因为它已是目的地了，那么traceroute如何得知目的地到达了呢？

Traceroute在送出UDP datagrams到目的地时，它所选择送达的port number 是一个一般应用程序都不会用的号码（30000 以上），所以当此UDP datagram 到达目的地后该主机会送回一个「ICMP port unreachable」的消息，而当traceroute 收到这个消息时，便知道目的地已经到达了。所以traceroute 在Server端也是没有所谓的Daemon 程式。

Traceroute提取发 ICMP TTL到期消息设备的IP地址并作域名解析。每次，Traceroute都打印出一系列数据,包括所经过的路由设备的域名及 IP地址,三个包每次来回所花时间。

windows之tracert:

格式：

tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

参数说明：

tracert [-d] [-h maximum_hops] [-j computer-list] [-w timeout] target_name

该诊断实用程序通过向目的地发送具有不同生存时间 (TL) 的 Internet 控制信息协议 (CMP) 回应报文，以确定至目的地的路由。路径上的每个路由器都要在转发该 ICMP 回应报文之前将其 TTL 值至少减 1，因此 TTL 是有效的跳转计数。当报文的 TTL 值减少到 0 时，路由器向源系统发回 ICMP 超时信息。通过发送 TTL 为 1 的第一个回应报文并且在随后的发送中每次将 TTL 值加 1，直到目标响应或达到最大 TTL 值，Tracert 可以确定路由。通过检查中间路由器发发回的 ICMP 超时 (ime Exceeded) 信息，可以确定路由器。注意，有些路由器“安静”地丢弃生存时间 (TLS) 过期的报文并且对 tracert 无效。

参数：

-d 指定不对计算机名解析地址。

-h maximum_hops 指定查找目标的跳转的最大数目。

-jcomputer-list 指定在 computer-list 中松散源路由。

-w timeout 等待由 timeout 对每个应答指定的毫秒数。

target_name 目标计算机的名称。

实例：

 
 C:\Users\Administrator>tracert www.58.com 
 
 Tracing route to www.58.com [221.187.111.30] 
 
 over a maximum of 30 hops: 
 
   1     1 ms     1 ms     1 ms  10.58.156.1 
 
   2     1 ms    <1 ms    <1 ms  10.10.10.1 
 
   3     1 ms     1 ms     1 ms  211.103.193.129 
 
   4     2 ms     2 ms     2 ms  10.255.109.129 
 
   5     1 ms     1 ms     3 ms  124.205.98.205 
 
   6     2 ms     2 ms     2 ms  124.205.98.253 
 
   7     2 ms     6 ms     1 ms  202.99.1.125 
 
   8     5 ms     6 ms     5 ms  118.186.0.113 
 
   9   207 ms     *        *     118.186.0.106 
 
  10     8 ms     6 ms    11 ms  124.238.226.201 
 
  11     6 ms     7 ms     6 ms  219.148.19.177 
 
  12    12 ms    12 ms    16 ms  219.148.18.117 
 
  13    14 ms    17 ms    16 ms  219.148.19.125 
 
  14    13 ms    13 ms    12 ms  202.97.80.113 
 
  15     *        *        *     Request timed out. 
 
  16    12 ms    12 ms    17 ms  bj141-147-82.bjtelecom.net [219.141.147.82] 
 
  17    13 ms    13 ms    12 ms  202.97.48.2 
 
  18     *        *        *     Request timed out. 
 
  19    14 ms    14 ms    12 ms  221.187.224.85 
 
  20    15 ms    13 ms    12 ms  221.187.104.2 
 
  21     *        *        *     Request timed out. 
 
  22    15 ms    17 ms    18 ms  221.187.111.30 
 
 Trace complete.