月度归档:2014年11月

中国北京电信DNS服务器IP地址​

中国北京电信DNS服务器IP地址分别有:218.30.10.50,20.132.165.61,还有详细北京电信DNS地址配置的详细用户比例。

DNS 用户数 国家 省份 地区 运营商 用户数排名(省份) 用户数比例(省份)
218.30.10.50 12900 中国 北京 电信 40 0.11%
120.132.165.61 6000 中国 北京 电信 86 0.05%
218.30.26.68 5400 中国 北京 电信 91 0.05%
220.181.66.213 3400 中国 北京 电信 119 0.03%
220.181.66.212 3200 中国 北京 电信 127 0.03%

中国安徽省电信DNS服务器IP地址

中国安徽省电信DNS服务器IP地址,包括淮南电信,芜湖电信,蚌埠电信,阜阳电信,合肥电信的DNS:1.132.163.68,202.102.213.68,还有详细安徽省电信DNS地址配置的详细用户比例。

DNS 用户数 国家 省份 地区 运营商 用户数排名(省份) 用户数比例(省份)
61.132.163.68 2844800 中国 安徽 电信 1 26.81%
202.102.213.68 2813100 中国 安徽 电信 2 26.51%
202.102.192.68 1648200 中国 安徽 淮南 电信 3 15.53%
202.102.199.68 1266600 中国 安徽 芜湖 电信 4 11.94%
202.102.200.101 54100 中国 安徽 蚌埠 电信 11 0.51%
202.102.196.68 5900 中国 安徽 芜湖 电信 26 0.06%
202.102.192.69 4400 中国 安徽 阜阳 电信 34 0.04%
202.102.198.68 4400 中国 安徽 合肥 电信 32 0.04%
202.102.192.168 3300 中国 安徽 阜阳 电信 35 0.03%
202.102.198.30 2300 中国 安徽 合肥 电信 38 0.02%

国内外CDN运营商列表及关键技术内幕

现在有许多商业CDNs (如Akamai公司, CDNetworks ,Mirror Image, Level 3, LimeLight网络,LocalMirror等) 。下表提供了现有CDN在基础服务和覆盖方面的简要概述。

CDNs

Overview

Accelia

[www.accelia.net]

Accelia公司成立于2000年,是日本的一个内容分发服务(CDS)供应商。它通过提供互联网架构和技术,方便可靠、及时分发互联网数据和内容。Accelia为静态和流媒体内容提供分布式内容分发服务。 Accelia的负载平衡网络服务,通过在互联网上设置分布的缓存服务器,来分散在地方和全球互联网流量,避免延误网络服务。用户请求的内容将通过DNS服务器的请求重定向,直接到附近的Accelia缓存(代理)。缓存服务器提供到源服务器同步,包括最新内容的同步。 Accelia的DNS服务器监控每个cache网站,评估其流量模式。

Accelia的CDS“ DuraSite ”被活动地点在日本的主要媒体公司,互联网广告公司广泛使用。目前, Accelia为互联网数据中心,互联网服务供应商和分布在亚太地区的5个国家的其它carrier公司提供服务。

Accellion

[www.accellion.com]

Accellion是一家私人控股公司,总部设在加利福尼亚州帕洛阿尔托,并在北美,亚洲和欧洲设有办公地点。它提供了大规模的文件分发服务。 Accellion的产品都建立在SeOS的(SmartEdge操作系统)技术。这是一个企业级应用的分布式文件存储和传输架构。SeOS技术可以全球范围内扩展,使Accellion高效和智能化移动,复制和管理大型文件。它采用了一系列的传输和分发协议,在地理上分散的地点之间,统一管理多种存储类型。

Accellion信使安全文件传输设备(SFTA)是一种按需文件传输解决方案,可以安全地交换文件。 Accellion courier在e-mail架构之外发送大附件,在发送者和接收者之间提供便利的e-mail。发件人通过一个基于Web的界面发送大文件(包括G字节的文件),接收者收到一封带有嵌入式,安全HTTP链接的电子邮件。它允许企业淘汰FTP服务器,提高电子邮件基础架构的性能,降低IT管理要求。Accellion还通过Accellion备份和恢复解决方案(BRS),提供在线台式机和服务器备份和恢复解决方案 。 Accellion客户的行业,包括广告/媒体生产,制造,医疗保健,消费品,高等教育等

Activate
[www.active.com]

Active是一个企业对企业的数字媒体解决方案供应商,它提供的白色标签数字音乐平台遍及欧洲各地。它是一个流和媒体缓存的供应商。Active提供端到端的数字媒体解决方案,包括白色标签和定制,下载和流媒体音乐服务,个人电脑,移动电话和机顶盒。Activate使用空中下载和通过充分的目录搜索,浏览,和Wishlist功能, 提供了完全集成的移动服务特色。Activate通过提供Web服务层,开发出可以接入企业级的服务层系统,并提供单点登录服务和综合性的“direct-to-operator-bill”服务。

它已在欧洲和世界其他地区(包括20多个国家和多种语言),提供超过75个Live服务。Active的典型客户是音乐零售商,互联网服务提供商,移动运营商,消费电子产品制造商和媒体公司。跨越20个国家,Active拥有75个客户,包括可口可乐,MSN (泛欧洲) , MTV公司,诺基亚, Tiscali公司, Wanadoo公司,等等。

Akamai
[www.akamai.com]

Akamai技术由麻省理工学院的研究工作发展而来,旨在解决flash crowd问题。它是提供内容分发服务市场的领导者。它在70个国家拥有超过18,000的服务器和超过1000网络。 Akamai公司的解决方法基于它观察到,由单一地点提供网页内容的服务,将在网站的可扩展性,可靠性和性能方面遇到严重的问题。因此,系统被设计为:为一个请求提供服务的源服务器的代理服务器的数目是可变的,且在网络的边缘。 Akamai公司服务器分发静态,动态内容和流音频和视频。

Akamai公司的架构可以处理flash crowd问题,它通过分配更多的服务器并从就近服务器为所用客户提供服务,来达到高负荷。该系统将客户端请求直接定向到最近的可能有要求的内容的服务器上。 Akamai公司通过映射(即请求内容服务器的方向)提供自动化网络控制技术,它使用一个动态的,容错DNS系统。映射系统解析了基于服务请求,用户位置和网络状态的主机名。它还使用DNS的网络负载平衡。Akamai公司的名字服务器通过mapping请求,把主机名解析为IP地址。Akamai的代理与某些边界路由器作对等通信;mapping系统使用BGP信息来确定网络拓扑结构。Akamai的Mapping系统将网络拓扑结构信息的统计与活的网络(如:跟踪路由的数据)相结合,为不同的mapping提供了详细、动态网络结构和质量评估视图。

Akamai公司的DNS的负载平衡系统连续监测服务状态,服务器和网络。为了提供整个系统端到端的监测, Akamai公司通过代理商,模拟最终用户行为,如:下载网站资源并衡量其故障率和下载时间。 Akamai公司使用此信息监测系统的总体性能,自动检测并暂停有问题的数据中心或服务器。每一个内容服务器经常向monitor应用报告其负载,并由monitor应用汇集和发布负荷报告给当地的DNS服务器。之后,当解析DNS名称后,DNS服务器确定哪些IP地址(两个或两个以上)需要返回。如果某服务器的负载超过某一阈值时, DNS服务器同时将某些服务器已经分配的内容,分配给另外一些服务器。如果服务器的负荷超过了另一个门槛,服务器的IP地址将不再提供给客户。服务器可以因此从高负荷下跌一小部分负荷。Akamai公司的监测系统还可以转送数据中心的负载到顶层DNS解析器,使流量远离超负荷的数据中心。此外,对于负载平衡, Akamai公司的监测系统为每个客户和内容服务器的内容服务提供集中式报告。这一信息是对网络业务和诊断非常有用

AppStream [www.appstream.com]

AppStream是一家私营公司,由Draper Fisher Jurvetson公司, JK和B Capital,高盛,Evergreen Partners, Sun和Computer Associates创立 。它为不断扩张的企业提供On-demand软件分发和软件许可管理工具技术。AppStream平台的可扩展性很好,它的硬件投资最小可以使用一台服务器,处理大约1000个用户。AppStream允许用户从一个浏览器或从传统的桌面快捷方式启动任何应用程序。通过AppStream ,软件可以在企业内部提供服务并可管理。因此,企业内的用户可以在桌面和企业应用中进行流和缓存 ,所有的应用功能由AppStream维护 ,包括与外设的交互和传统安装的应用程序。

AppStream在四个关键领域提供解决方案:自助服务软件发布,软件许可证管理,远程软件访问,虚拟映像分布。其产品AppStream软件5.0,是一个自助服务软件发布和许可证管理的平台。 当收到客户端的启动程序的请求后,AppStream软件将应用分成segment( streamlets ),并基于用户的使用行为,将streamlets分发给用户。用户可以以自己的习惯使用完全安装的产品,而从企业的角度来看,AppStream提供了一种高级功能,可以允许集中访问和灵活扩展由本地安装的应用程序。APPStream服务器与软件流传输协议(SSTP)之间的通信,使用HTTP,采用传统的Web应用程序方式,SSTP运行在HTTP之上,为应用segment提供高效的分发[63]。AppStream公司的客户包括财富1,000公司,教育机构和政府。

EdgeStream[www.edgestream.com]

EdgeStream,总部设在南加州,在公众互联网之上提供中断视频流应用。EdgeStream提供视频点播和IPTV流媒体软件,使高码率视频可在互联网上低成本无差错的传输。它可以在世界各地的consumer电缆或ADSL模式下,确保不间断的DVD质量的视频流传送,甚至可以忍受服务器和终端用户之间有有20个路由跨越(router hops)。 EdgeStream开发了连续路径优化(CROS)和拥塞隧道穿越(ICTT)技术,可以处理延迟,包丢失,和瓶颈拥挤。EdgeStream的网络架构使运营商能够建立一个低投资和维护费用,高效的分发网络。

EdgeStream软件是用于高品质的视频流。嵌入式应用的消费电子设备,无线手持设备,IP机顶盒,以及先进的数字电视可以使用EdgeStream软件获得高品质视频流。EdgeStream软件的典型用户包括网络供应商,电信运营商,门户网站,CDNs,互联网服务供应商,企业,内容提供商和内容集成商。 EdgeStream为了向潜在用户提供性能展示,维护一个流媒体服务器网络,同时可以为快速和低成本推出的视频应用,提供短期和长期的视频托管服务。

Globix
[www.globix.com]

Globix是提供互联网架构和网络服务的公司。它提供了一个完整、安全的媒体流、配置服务,包括从网络带宽,到管理Web应用程序,服务器,数据库等。Globix提供四种类型的服务:网络服务,托管服务,管理服务,以及媒体服务。Globix服务是灵活,可扩展,并具有成本效益,有高可靠性和SLA。 Globix托管服务提供安全和冗余,并连接到高速Globix网络。除了管理服务, Globix还提供安全,存储,信息传递,灾后恢复,监测,应用程序和数据库管理服务。Globix还提供了媒体服务,用于从实时事件(如:编码,演示工具和流量分析)中获取,存储,寄存和分发媒体内容。

Globix负载平衡服务在多个服务器间分发流量,它将请求发送到服务器集群中,负载最轻的服务器上。与基于软件的负载平衡器不同,该服务是基于ASIC的硬件架构建立的,可以提供更优越的流量性能。 Globix提供全面的监测服务,以衡量物理网络和服务器硬件,网络和应用服务,以及后端数据库的性能。

Globix互联网基础设施包括一个trans-Atlantic/trans-continental IP骨干网以及光纤网络,它们分布在整个东北部和大西洋沿岸中部地区。 Globix IP骨干网通过高容量,完全拥有和经营的Globix网络连接到互联网用户。它已超过1200的客户。

LimeLight Networks[www.limelightnetworks.com]

Limelight Networks是一个内容交付网络,它提供分布式的on-demand,实时传输视频、音乐、游戏和下载。为了分发数字媒体给观众,它建立了一个可扩展的系统。它以下产品:Limelight ContentEdge,通过HTTP分发内容交付 ;Limelight MediaEdge Streaming,通过流分发视频和音乐;Limelight Custom CDN,自定义分发交付解决方案。

Limelight ContentEdge提供了一个高度可靠,可扩展和高效率的交付平台,保证内容交付时间,满足了服务水平协议( SLA ) 。Limelight MediaEdge Streaming是一个功能强大的分布式平台,它可以为互联网上的现场直播和点播的音频、视频内容,提供高性能服务。Limelight网络有一个灵活的CDN平台,使它能够定制CDN,以满足任何内容供应商的具体需要和环境。

典型Limelight Networks的客户包括:使用互联网提供产品,并提供大量内容,以服务大量观众的公司。LimelightNetworks的代理服务器设在世界各地的72处,包括纽约,洛杉矶,圣何塞,伦敦,阿姆斯特丹,东京和香港。

LocalMirror[www.localmirror.com]

LocalMirror是一家私人公司,它提供内容分发服务,其特色在于使用全球分散的缓存节点,先进的算法和智能路由技术。它为最终用户提供了超高速静态内容下载和音频/视频流。通过使用LocalMirror内容交付网络(CDN)技术,内容被推送到更接近用户的点,因此可以更快速和低成本的分发。根据缓存节点位置和客户端的流量需求,LocalMirror CDN服务支持几乎无限数量的同时连接的静态和非静态的音频和视频数据流。LocalMirror的CDN技术从最接近的位置,较低的延迟,来分发文件下载和音频/视频流,从而提供更好的互联网体验。

LocalMirror内容交付网络是由UltraRoute ?和criticalDNS ?技术支持的。 LocalMirror的全球网络负载平衡承诺没有单点故障,因为客户的流量是分布在多个缓存节点之间的。 LocalMirror的CDNs缓存节点和应用服务器,设在多个国家和数据中心,利用全球各地的Tier- 1和Tier – 2的ISP光纤连接。

Mirror Image
[www.mirror-image.com]

Mirror Image是一个全球性的网络,致力于提供在线内容,应用和交易,并分发给世界各地的用户。它提供了内容分发,流媒体,网络计算和报告服务。它提供了一种解决方案,使客户以更智能的方式,为全球用户创造更吸引人的网站经验。

Mirror Image利用一个全球性的内容接入点( CAP )的基础,在Internet架构之上,为内容提供商,服务提供商和企业提供了一个平台,可以提供网站内容给最终用户。作为在Internet之上的安全和可管理的一层,每个CAP通过智能的将内容地点放置到更接近用户,使服务器和网络负载更小。Mirror Image在位于网络peering point的22个国家有代理服务器,跨越北美,欧洲和亚洲,那里的网络流量和用户数目是最高的。Mirror Image的客户包括Creative,Open system,和SiteRock 。

Netli

Now Acquired by Akamai
[www.netli.com]

Netli是一家私人拥有的公司,总部设在美国加州Mountain View。它提供高质量的互联网业务。它解决互联网上的限制。NetliOne平台是一个全球应用交付网络(Application Delivery Network,ADN) ,可以在互联网上确保快速响应时间,更高的可视性和对应用的控制功能。Netli和它的服务由NetliOne平台分发。


NetliOne平台包括一系列全球分布式虚拟数据中心(Virtual Data Centers,VDCs)和应用访问点(Application Access Pointes,AAPs),是一家全球性的DNS重定向和IP地址映射系统,高性能的协议和内容优化软件,在线监测和报告系统,并提供24×7全天候的网络运营中心。

Netli的服务-NetLightning?优化分发Web应用和内容,提供亚秒响应时间以及更高的可靠性; NetliOffloadTM ,提供可靠和高性能的基础设施,以满足企业的要求; NetliViewTM提供近实时的性能,可永兴和商业应用使用模型的信息;NetliContinuityTM可以获得战略控制和数据中心资源的管理。Netli在世界各地的13个城市有计算机集群。客户包括:惠普,Thomson,Millipore和Nielsen / NetRatings。

SyncCast
[www.synccast.com]

SyncCast是一家领先的内容交付网络。它使用全球负载均衡,Tier-1层骨干互联网。SyncCast提供完整的解决方案,从应用软件开发,虚拟主机和Internet连接到部署和系统集成。它提供了数字内容及相关数据通过因特网和其他媒体进行分发的解决方案。 Synccast目的是以低成本的方式,提供最高质量的内容。

Synccast通过使用负载平衡设备的主要部件,如F5,Cisco和Foundry,来对客户流量进行负载平衡 。因此,Synccast允许用户在多个数据中心选择最有效的网络路径,快速连接到流媒体服务器,用户可以得到更好的网络性能。 SyncCast为流媒体客户提供点对点( P2P )的流媒体技术。Synccast P2P技术智能监测每个用户的音频/视频流质量,如果某个流服务器服务质量降低,用户将被切换到另一个服务器上。

SyncCast也是很多领先的技术公司的合作伙伴,如微软,戴尔,和FotoKem 。 SyncCast的客户包括美国电影协会,沃尔玛音乐,Lions Gate影业,微软,百代音乐集团的Technicolor和Billboard Radio。

Tata Communications

[www.tatacommunications.com]

塔塔通信是一个有$62.5 billion的Tata集团成员,它是一家全球领先的新的通信公司。该公司利用其先进的解决方案的能力和专业知识在其全球网络,为全球服务供应商提供解决方案。其客户在80多个城市,分布在40个国家和地区,塔塔通信公司的服务范围包括传输,IP,融合语音,移动性和业务转化。该公司拥有和经营的塔塔的全球网络,其中一个最先进和最大的海底电缆网络连接200多个国家和地区的300个POP点。塔塔通信系统提供第一个真正的全球性CDN服务,单个ASN全球IP网络遍及欧洲,亚洲,北美和印度。塔塔通信的下一代CDN服务,技术支持BitGravity的技术,它可以提供最高的性能和可靠性,同时为最终用户提供即时访问的内容,包括没有任何拖延或抖动的高清晰度视频,以及最高级别的吞吐量。快速转发,缓存交换,交换分解(resolutioin switching)和速率控制(rate throttling)只是其中的几种功能,这些可以使客户能够建立一个强有力的,保证Flash Player的应用。

塔塔通信公司的全套产品包括塔塔通信CDN,作为下一代的CDN,可在全球范围内的为应用提供最高性能和可靠性;塔塔通信CDN和CDN安全,为分发和保护媒体资产做了专门设计;Tata通信LiveBroadcast ,一个高品质的,基于闪存的流媒体业务,可以为广播的现场活动提供服务。

Value CDN

[www.valuecdn.com]

Value CDN通过使用分布的缓存服务器,为各种大小的web网站提供低成本内容交付网络。Value CDN将内容推送到更接近最终用户和服务器,文件延迟比传统的单点网络托管的解决方案低得多。我们通过使用SilverNET CDN服务,可以提供业界领先的低成本内容交付。Value CDN是欧洲公司,可在北美和欧洲,包括德国,英国,瑞典和其他国家提供多个POP点。(应该和China Cache类似)

VitalStream

[www.vitalstream.com]

VitalStream是一个供应商,可以提供视频和音频流媒体、广播服务给用户。 VitalStream小企业服务是一个完全的分布式网络,它采用先进的“最优同步”(Synchronous-When-Optimal)路由服务,从最优化的数据中心,在拥挤的互联网上提供内容交换点。VitalStream的路由技术可以连续监测流量情况,对所有主要互联网骨干和路由器的关键任务数据,可以提供更快更可靠和管理方式。

End

抓包工具Wireshark常见问题解析

1.   tcp out-of-order(tcp有问题)

解答tcpdum

1)、    应该有很多原因。但是多半是网络拥塞,导致顺序包抵达时间不同,延时太长,或者包丢失,需要重新组合数据单元 因为他们可能是通过不同的路径到达你电脑上面的。

2)、    CRM IT 同仁上礼拜来跟我反应一个问题,由他们客服系统藉由邮件主机要寄送给客户的信件,常常会有寄送失败的问题,查看了一下 Log,发现正常的信件在主机接收 DATA 完成后会记录收到的邮件大小,然后开始进行后续寄送出去的处理,但这些有问题的寄送,都会发生 DATA 没有传送完,Server 就记录已读取到 EOF,然后结束连线,也因此这封信就不算顺利的送到 Server 上来。

初步看了一下排除是 Timeout 问题,因为连线断的时间都还未达设定的连线 Timeout 时间,由于 CRM 系统是外面厂商写的,为了厘清问题我只好抓封包来看是不是用户端送出来结束传送的指令的。

抓了一下结果如下:

整封邮件的传送过程,包含了大量的 TCP Retransmission 或是 Segment Lost,到后来还有跑出 TCP Out-Of-Order,看起来是网路的问题,网路上对于 TCP Out-Of-Order 的建议是说,有些 Packet 可能 Lost,所以重新传送造成,另一个可能是因为 Client 到 Server 间有两条网路路径,像是 Load Balance 之类的架构,因此若两个封包走不同路径,晚送的封包却比早送的到达,就会发生 Out-Of-Order。

因此在断定有可能是网路造成,加上 CRM 系统上的网卡同事是把两张做成一张 Virtual,再请他拿掉 Bonding 只用单一张跑以后,问题就不存在了,观察流量还跑的比原本两张合起来的 Virtual 单张跑的高,所以 M$ 在 Bonding 网卡上是不是还有什么需要调整的就不得而之了,至少找出造成大量寄送失败的原因就好。

2.  tcpdump报 tcp segment of a reassembled PDU

解答:1)在连个连接建立的时候,SYN包里面会把彼此TCP最大的报文段长度,在局域网内一般都是1460.如果发送的包比最大的报文段长度长的话就要分片了,被分片出来的包,就会被标记了“TCP segment of a reassembled PDU”,可以参考下图,看一下,被标记了的包的SEQ和ACK都和原来的包一致:

2)上周在公司里遇到一个问题,用wireshark抓系统给网管上报的数据发现里面有好多报文被标识为“TCP segment of a reassembled PDU”,并且每一段报文都是180Byte,当时看到这样的标识,觉得是IP报文分片,以为系统的接口MTU值为设置小了,通过命令查询发现是1500,没有被重设过,当时有点想不通。

回来查了一下,发现自己的理解是错的,“TCP segment of a reassembled PDU”指的不是IP层的分片,IP分片在wireshark里用“Fragmented IP protocol”来标识。详细查了一下,发现“TCP segment of a reassembled PDU”指TCP层收到上层大块报文后分解成段后发出去。于是有个疑问,TCP层完全可以把大段报文丢给IP层,让IP层完成分段,为什么要在TCP层分呢?其实这个是由TCP的MSS(Maximum Segment Size,最大报文段长度)决定的,TCP在发起连接的第一个报文的TCP头里通过MSS这个可选项告知对方本端能够接收的最大报文(当然,这个大小是TCP净荷的大小),以太网上这个值一般设置成1460,因为1460Byte净荷+20Byte TCP头+20Byte IP头= 1500字节,正好符合链路层最大报文的要求。

至于收到一个报文后如何确定它是一个”TCP segment”?如果有几个报文的ACK序号都一样,并且这些报文的Sequence Number都不一样,并且后一个Sequence Number为前一个Sequence Number加上前一个报文大小再加上1的话,肯定是TCP segment了,对于没有ACK标志时,则无法判断。

既然收到的TCP报文都是180Byte的segment,那么应该是协商的时候PC端告知了MSS为180Byte,至于为什么这样,只能等抓包后确认是MSS的问题再排查了。另外,有一种情况也可能导致这个问题:被测系统因为MTU为220Byte而设置MSS为180Byte,但是这种情况现在可以排除,因为前面讲过,已经查询过MTU值为1500。

3.   tcpdump报 Tcp previous segment lost(tcp先前的分片丢失)

解答:

(1)、“TCP Previous segment lost” errors are not “fatal” errors. They simply indicate that the sequence number in the arriving packet is higher than the next-expected sequence number, indicating that at least one segment was dropped/lost. The receiving station remedies this situation by sending duplicate ACKs for each additional packet it receives until the sender retransmits the missing packet(s). TCP is designed to recover from this situation, which is why the image is downloaded correctly despite having a (briefly) missing packet.

If you are getting a large number of lost packets, then there is likely a communication problem between the sender and receiver. A common cause of this is un-matched duplex settings between the PC and the switch.

We (our lab) recently upgraded to Ethereal 0.10.14 with WinPCap 3.1.  If I remember correctly, we had previously been using 0.10.2 with WinPCap 3.0.  However, since the upgrade we have been noticing several issues.

The first issue is with “TCP Previous segment lost” and “TCP CHECKSUM INCORRECT” messages appearing in the Packet Listing window.  We do not remember seeing these in the previous version of Ethereal, or at least not nearly as many as we are seeing now.  For example, one task for the student instructional part of the lab involves visiting a website containing two images and observing the network activity.  After the two GET requests are sent for the images, it is not uncommon for one image to be returned with a typical 200 OK response packet, but the response packet for the other image will be displayed as “TCP Previous segment lost.”  However, both images are downloaded and displayed perfectly fine in the browser.  I would think that the segment lost error would mean the object wasn’t returned correctly and shouldn’t be able to be displayed, but apparently that is not the case.  (The cache had been cleared when this was performed, so it was not defaulting to a local copy of the image.)

Another problem we’ve been noticing is that some packets simply aren’t displayed in the Packet Listing window, even when they are obviously received.  Using the same example as above, after the two GET requests are sent for the images, it is not uncommon for one image to be returned with a typical 200 OK response, but the other response will not appear.  Yet both images are successfully displayed in the browser.  Is this a problem with Ethereal not detecting the packets?

I’m not sure how typical this is, but we seem to be experiencing these issues often with 0.10.14 while we never did with 0.10.2.  Could it also be an issue with WinPCap, and not necessarily Ethereal?  I’m just trying to find some answers as to why we are seeing a sudden abundance of TCP related errors and uncaptured packets.  Thanks.

(2)、I have a network client application that runs fine while I am debugging (no TCP errors),

but when I run the release version, it runs incredibly slow.  It runs as a series of

transactions, where each transaction is a separate connection to the server.  Wireshark

analysis has determined that about 50% of all transactions involve the series:

TCP Previous Segment Lost

TCP Dup ACK

RST

The RST consumes 3 seconds per transaction, which is a Big Deal.  So to prevent it, I must

prevent the initial “TCP Previous Segment Lost” (which seems, on the surface, to merely be

a time-out on a particular segment).

In the following clip, the SYN packet suffers from the “TCP Previous Segment Lost” condition.

0.000640 seconds seems like too short of a time to declare this condition, as many previous

successful transactions took much longer to be successfully SYN-ACK’ed.

Can somebody explain “TCP Previous Segment Lost” in this context to help me troubleshoot my

problem?

Any help would be appreciated.

Here is a clip of a problem transaction:

fffgs

4.   Tcpacked lost segment(tcp应答丢失)

5.   Tcp window update(tcp窗口更新)

6.   Tcp dup ack(tcp重复应答)

TCP may generate an immediate acknowledgment (a duplicate ACK) when an out- of-order segment is received. This duplicate ACK should not be delayed. The purpose of this duplicate ACK is to let the other end know that a segment was received out of order, and to tell it what sequence number is expected.

当收到一个出问题的分片,Tcp立即产生一个应答。这个相同的ack不会延迟。这个相同应答的意图是让对端知道一个分片被收到的时候出现问题,并且告诉它希望得到的序列号。

Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. TCP then performs a retransmission of what appears to be the missing segment, without waiting for a retransmission timer to expire.

7.   Tcp keep alive(tcp保持活动)

在TCP中有一个Keep-alive的机制可以检测死连接,原理很简单,TCP会在空闲了一定时间后发送数据给对方:

1.如果主机可达,对方就会响应ACK应答,就认为是存活的。

2.如果可达,但应用程序退出,对方就发RST应答,发送TCP撤消连接。

3.如果可达,但应用程序崩溃,对方就发FIN消息。

4.如果对方主机不响应ack, rst,继续发送直到超时,就撤消连接。这个时间就是默认

的二个小时。

uses WinSock2;

procedure TForm1.IdTCPServer1Connect(AThread: TIdPeerThread);

type

TCP_KeepAlive = record

OnOff: Cardinal;

KeepAliveTime: Cardinal;

KeepAliveInterval: Cardinal

end;

var

Val: TCP_KeepAlive;

Ret: DWord;

begin

Val.OnOff:=1;

Val.KeepAliveTime:=6000; //6s

Val.KeepAliveInterval:=6000; //6s

WSAIoctl(AThread.Connection.Socket.Binding.Handle, IOC_IN or IOC_VENDOR or 4,

@Val, SizeOf(Val), nil, 0, @Ret, nil, nil)

end;

——————————————————–

KeepAliveTime值控制 TCP/IP 尝试验证空闲连接是否完好的频率。如果这段时间内没有活动,则会发送保持活动信号。如果网络工作正常,而且接收方是活动的,它就会响应。如果需要对丢失接收方敏感,换句话说,需要更快地发现丢失了接收方,请考虑减小这个值。如果长期不活动的空闲连接出现次数较多,而丢失接收方的情况出现较少,您可能会要提高该值以减少开销。缺省情况下,如果空闲连接 7200000 毫秒(2 小时)内没有活动,Windows 就发送保持活动的消息。通常,1800000 毫秒是首选值,从而一半的已关闭连接会在 30 分钟内被检测到。

KeepAliveInterval值定义了如果未从接收方收到保持活动消息的响应,TCP/IP 重复发送保持活动信号的频率。当连续发送保持活动信号、但未收到响应的次数超出TcpMaxDataRetransmissions的值时,会放弃该连接。如果期望较长的响应时间,您可能需要提高该值以减少开销。如果需要减少花在验证接收方是否已丢失上的时间,请考虑减小该值或TcpMaxDataRetransmissions值。缺省情况下,在未收到响应而重新发送保持活动的消息之前,Windows 会等待 1000 毫秒(1 秒)。

KeepAliveTime根据你的需要设置就行,比如10分钟,注意要转换成MS。

XXX代表这个间隔值得大小

8.   Tcp retransmission(tcp重传)

作为一个可靠的传输协议,传输控制协议(TCP)在发送主机需要从目标主机收到一个包时确认。If the sender does not receive that acknowledgment within a certain amount of time, it acts under the assumption that the packet did not reach its destination and retransmits the packet.如果发件人没有收到的时间内一定之金额,确认,它的行为假设下,该数据包没有到达其目的地,以及转发数据包。

trafficserver完胜nginx、squid的高性能CDN服务器

一 trafficserver介绍-一个高性能的、模块化的 HTTP 代理和缓存服务器

Apache Traffic Server(ATS或TS)是一个高性能的、模块化的 HTTP 代理和缓存服务器。Traffic Server 最初是 Inktomi 公司的商业产品,该公司在 2003 年被 Yahoo 收购,之后Traffic Server 一直在 Yahoo 内部使用长达 4 年,直到 2009 年 8 月 Yahoo 向 Apache 软件基金会(ASF)贡献了源代码,并于 2010 年 4 月成为了 ASF 的顶级项目(Top-Level Project)。Apache Traffic Server 现在是一个开源项目,开发语言为C++。

Traffic Server 的开发团队曾经由 Chuck Neerdaels 领导,他也是 Harvest 项目的早期创始人之一,Harvest 项目后来发展为十分流行的 Squid 项目;Leif Hedstrom 直接管理着现在的 Traffic Server 开发团队。目前 Chuck Neerdaels 和 Leif Hedstrom都已加盟知名 CDN 服务提供商Akamai。
 
HTTP 代理服务器是 HTTP 服务器的一种实现,处于客户端(一般为浏览器)与另一个 HTTP服务器之间(通常指源服务器,Origin Server)。HTTP 代理通常分为正向代理、反向代理和透明代理,我们主要关注的是反向代理(Reverse Proxy,见下图)反向代理服务器根据明确配置的映射规则来处理用户请求。反向代理服务器通常会设置一个较大的缓存区,服务器处理请求的同时将请求的内容缓存在服务器本地,当下次用户请求同一个对象时,服务器可直接从缓存区里取出对象,而不用去源服务器去取,起到了加速的效果。另外,配置反向代理的映射规则也能实现负载均衡的功能。除了 Traffic Server,常见的开源代理服务器还有 Squid,Varnish,Nginx,HAProxy。 
Apache <wbr>Traffic <wbr>Server <wbr>简介

        Traffic Server 在 Yahoo 内部使用了超过 4 年,主要用于 CDN 服务,CDN 用于分发特定的HTTP 内容,通常是静态的内容如图片、JavaScript、CSS。下面是Traffic Server 在 Yahoo CDN应用的一些情况:
超过 4 年的使用中,缓存中没有出现已知的数据损坏(data corruption);
作为反向代理,服务器方便部署和管理,并且大部分配置的更改可直接在线上服务器完成,而不用重启服务;
在高并发情况下扩展良好,支持 HTTP/1.1 协议特性,如 SSL、Keep-Alive;
在世界范围内部署了超过 100 台服务器;
在实际CDN中,每秒处理超过 350,000 次请求,达到 30 Gbps,最大容量至少十倍于普通使用,以应对高峰时的大量请求;
在实际 CDN 中,每台服务器有 20,000 到 30,000 的 keep-alive 并发连接,其中有 1,000 到 2,000 的连接是一直很活跃的;
实验环境中,单台服务器每秒处理 105,000 次请求,请求的对象是被缓存住的小文件;
实验环境中,请求大文件时,单台服务器达到 3.6 Gbps(4x GigE NIC bonded)。
二 组件、机制

Traffic Server(TS) 的组成
1.Traffic Server缓存
TS 缓存包含一个高速的对象数据库,数据库根据 URL 和相关头部来索引对象,对于同一对象可以缓存不同版本(如不同的编码、语言)。
当缓存空间满后,TS 会移除过期的数据。
当磁盘出错时,TS 将不再使用该块磁盘,转而使用剩下的磁盘。所有磁盘都出错时,TS 将切换至 proxy-only 模式,即只代理,不缓存。
可分区,即可以给指定的协议和源服务器划分一定数量的磁盘空间
2.RAM 缓存
        内存缓存区储存比较热门的对象,在流量的高峰期时能加快处理速度和降低磁盘负载。
 
3.主机数据库
储存 DNS 信息,方便主机名到 IP 地址的快速转换
储存每个主机的 HTTP 版本,方便高级协议特性的使用
储存主机的可靠性和可用性信息
4.DNS 解析器
                TS 原生实现了 DNS 解析器,不依赖较慢的传统解析库。同时也降低了 DNS 的流量。
 
5.Traffic Server 进程
traffic_server 进程负责接受连接,处理协议请求,然后从缓存或源服务器获取对象并返回
traffic_manager 进程是 TS 的命令和控制设施,负责启动、监控和配置 traffic_server 进程,它也负责代理的端口配置、统计信息的接口、集群管理和虚拟 IP 的故障转移。
如果 traffic_manager 检测到 traffic_server 进程失效,它立即重启 traffic_server 进程并且维护一个连接队列,保存此时到来的请求,完全重启后这个队列里的连接将按顺序被处理。
traffic_cop 进程监视 traffic_server 和 traffic_manager 进程,此进程周期性的查询 traffic_server 和 traffic_manager 进程的健康状况,如果查询在一定间隔时间内未返回或者返回信息不正确,traffic_cop 将重启 traffic_manager 和 traffic_server 进程。
Apache <wbr>Traffic <wbr>Server <wbr>简介
6.管理工具
Traffic Line 是命令行程序,可以用来快速监视 Traffic Server 的性能和网络流量,也能配置 TS。
Traffic Shell 也是命令行工具,进入该 shell 后有自己一套语法,可代替 Traffic Line 完成监控、配置任务。
通过 Traffic Line 和 Traffic Shell  对配置作出的修改将会自动写入配置文件中。
 
Traffic Server 的底层机制

Apache Traffic Server 不同于大部分开源代理服务器,它结合了两种技术来处理高并发:
异步事件处理(Asynchronous event processing)
多线程(Multi-threading)
Traffic Server 在多 CPU、多核的硬件上扩展良好,能充分利用所有可用的 CPU 和其他资源。
 
HTTP 代理缓存相关机制
 
1. Traffic Server 处理请求的过程
  1)用户请求一个 web 对象,TS 收到请求
  2)TS 通过对象的地址,在对象数据库(缓存)中去定位该对象
      a.如果对象在缓存中,TS 会检查对象是否新鲜(fresh)
           如果新鲜,TS 从缓存里返回该对象给用户,此时称为缓存命中(cache hit)
           如果不新鲜(stale),TS 会连接源服务器去验证对象是否仍然新鲜,即重新验证(revalidation),如果仍然新鲜,TS 立即将缓存中的副本返回给用户
      b.如果对象不在缓存中(缓存未命中,cache miss),或者缓存的副本不再有效,TS 会去源服务器获取对象,然后同时做下面两件事
           将对象返回给用户
           将对象放到本地缓存中
2. Traffic Server 判断 HTTP 对象是否新鲜(fresh)的过程
如果有 Expires 或者 max-age 头部直接定义缓存的过期时间,TS将对比当前时间和过期时间去判断对象是否新鲜
如果没有上述头部,TS 将检查 Last-Modified 和 Date 头部(其中Date是源服务器返回对象的时间,如果没有 Last-Modified 头部,TS 会用对象写入缓存的时间以作代替),然后用以下公式算出新鲜的时间范围(freshness_limit,可理解为保质期):
                     freshness_limit = ( Date – Last-Modified ) x 0.1
0.1 这个参数可以作调整,并且能限制 freshness_limit 的上下限,默认最小是 1 小时,最大是 1 天
如果没有 Expires 头部或者没有 Last-Modified、Date 头部,TS 将使用默认的 fressness limit
另外,TS 还会检查 cache.config 配置文件中的 revalidate 规则,该规则可以对特定的 HTTP 对象设置特定的验证时间(特定的域名、IP、一定规则的 URL、特定的客户端等等)
3. 缓存过期(stale),Traffic Server 去源服务器重新验证对象可能的情况
仍然 fresh,TS 重置 freshness_limit,并返回对象
对象新副本可用,TS 缓存新对象,并同时返回给用户
源服务器上的对象不再存在,TS 也不再返回该副本给用户
源服务器没有响应,TS 返回过期的对象并发出警告。
更详细的说明请查看 Traffic Server 管理文档中的 HTTP Proxy Caching 部分

三 安装、使用
    Apache Traffic Server 开源后添加了 64 位支持,也移植到了常见的 Linux 发行版、FreeBSD、OpenSolaris 和 Mac OS X,开源之前 Yahoo Traffic Server 一直运行在 32-bit Linux 上。
 
(以 Apache Traffic Server 2.1.1 unstable 为例在 32-bit Linux 环境下进行安装测试)
 
安装
 
1. 下载、解压
 
wget http://www.apache.org/dist/trafficserver/trafficserver-2.1.1-unstable.tar.bz2
wget http://www.apache.org/dist/trafficserver/trafficserver-2.1.1-unstable.tar.bz2.md5
md5sum -c trafficserver-2.1.1-unstable.tar.bz2.md5
tar jxvf trafficserver-2.1.1-unstable.tar.bz2
cd trafficserver-2.1.1-unstable
 
2. 编译、安装
 
    查看 README 说明文档,安装编译依赖的库(centos 可参照 fedora 依赖的软件包,pcre包替换为 pcre-devel 即可)
 
./configure –help   查看编译的一些选项
./configure  (默认安装在 /usr/local,如需修改,使用 –prefix=PREFIX;参数中还有用户和用户组选项,这是 TS 进程运行的身份,默认均为 nobody,centos 可以不作修改,其他发行版可能需要修改,如 ./configure –with-group=nogroup)
make
make install  以管理员身份执行

目录结构
 
 
默认目录
内容
/usr/local/var/log/trafficserver
运行时创建的日志文件
/usr/local/var/trafficserver
运行时的一系列文件
/usr/local/etc/trafficserver
配置文件
/usr/local/bin
可执行文件
/usr/local/libexec/trafficserver
插件
 
 
初步配置
 
records.config 是 key-value 格式的配置文件,负责大部分全局的选项设置,即主配置文件。
storage.config 用于指定磁盘存储。
remap.config   定义映射规则,用于请求的重写(rewrite),反向代理即在此配置。
records.config 中关键的配置
CONFIG proxy.config.exec_thread.autoconfig INT 1
CONFIG proxy.config.exec_thread.autoconfig.scale FLOAT 2.0
CONFIG proxy.config.exec_thread.limit INT 2   # 经观察是每个核创建的线程数,官方文档中未提及
 
CONFIG proxy.config.cluster.ethernet_interface STRING eth0 # 设置以太网接口
CONFIG proxy.config.http.server_port INT 8080  # 监听端口,反向代理通常为80
LOCAL proxy.local.incoming_ip_to_bind STRING 0.0.0.0 # 绑定的 IP,可省略,默认即为 0.0.0.0
 
CONFIG proxy.config.http.cache.http INT 1 # 打开缓存功能
CONFIG proxy.config.cache.ram_cache.size INT 512M  # RAM 缓存大小
 
CONFIG proxy.config.reverse_proxy.enabled INT 1   # 打开
CONFIG proxy.config.url_remap.remap_required INT 1 # 1为只反向代理,0为正向+反向代理
CONFIG proxy.config.url_remap.pristine_host_hdr INT 0
 
CONFIG proxy.config.ssl.enabled INT 0 # 关闭SSL
CONFIG proxy.config.ssl.server.cert.filename STRING server.pem
 
CONFIG proxy.config.http.server_max_connections INT 2000  # 同源服务器的最大连接数
CONFIG proxy.config.http.keep_alive_no_activity_timeout_out INT 60 # 当一个事务结束后同原服务器保持连接的时间
 
remap.config  配置
 
         map http://cdn.example.com/js           http://js.example.com  # 通过 DNS 轮询可实现负载均衡
         reverse_map http://js.example.com     http://cdn.example.com/js   # reverse_map 能在源服务器 有 HTTP重定向跳转时,修改重定向请求,即重写 Location 头部内容
 
        map http://cdn.example.com/css        http://css.example.com
        reverse_map http://css.example.com  http://cdn.exampe.com/css
 
        map http://cdn.example.com/img        http://img.example.com
        reverse_map http://img.example.com  http://cdn.example.com/img
 
 storage.config 配置
    /data1 67108864   # 指定一个或多个目录,注明缓存大小,也可直接指定 raw 分区,详见storage.config 中的注释说明
 
更详细的配置可参考官方管理指南 http://trafficserver.apache.org/docs/v2/admin/

服务控制
运行 /usr/local/bin/trafficserver start
结束 /usr/local/bin/trafficserver stop
重启 /usr/local/bin/trafficserver restart 
命令行工具、监控
 /usr/local/bin/traffic_line 需用管理员身份执行
查看帮助 traffic_line -h
查看变量的值 traffic_line -r 变量名 (变量名见官方管理指南附录C,含 TS 运行时统计数据)
给变量赋值 traffic_line -s 变量名 -v 值  (变量名见records.config)
不重启TS 使配置生效 traffic_line -x
 /usr/local/bin/traffic_shell 需用管理员身份执行,进入后提示符为“%”
查看帮助 man traffic_shell (由于开发者疏忽,暂不能用)
show 命令,如 %show:cache-stats 查看缓存统计,如命中情况,缓存大小;如%show:proxy-stats 查看命中率
config 命令,如 %config:logging event disable 关闭日志;如 %config:cache clear,清除缓存,config命令作出的修改都会立即生效
 /usr/local/bin/traffic_logcat 日志查看工具
traffic_logcat -h 获得帮助
查看二进制日志 traffic_logcat 日志文件名
Traffic Server 系统自身的运行日志可在 /var/log/message 中查看(centos),用于排错
traffic_logstats 提供了基于日志的统计功能
四 结论
    Apache Traffic Server 开源后功能在不断被开发,性能得到很大提升,社区也在逐渐发展,但除了 Yahoo 之外还很少有其他实践,很多功能(如集群)的文档有待完善。Traffic Server 丰富的插件开发是其一大亮点,模块化的特点使其拥有很好的扩展性和灵活性,再加上它的高性能,相信 Apache Traffic Server 未来将在很多场景中替代传统的代理和缓存服务器而成为大家的首选。


squid与Apache TrafficServer压力测试对比

SQUIDATS (Apache Traffic Server) 压力测试

一.测试环境

1CPU:双核  Intel(R) Core(TM)2 Duo CPU     E7500  @ 2.93GHz

2.内存:2G

3.系统版本:CentOS release 6.2 (2.6.32-220.el6.x86_64)

4.磁盘读写速度:disk reads:  308 MB in  3.01 seconds = 102.28 MB/sec

 

二.软件版本

1SQUID squid-3.0.STABLE18

2ATS   trafficserver-3.3.0-dev.tar.bz2

3Ab :     Version 2.3

 

注:

1.由于压力测试命令SQUID ATS服务在一台机器上,测试得出的数值偏小,测试总连接数都为20000,并发数逐步增加。

2.echo 10 > /proc/sys/net/ipv4/tcp_fin_timeout 减少大量的TIMEOUT回收时间,否则影响测试结果

3.ulimit -SHn 655350 增加文件描述符限制

4.SQUID缓存目录建立在了/dev/shm/cache mount –bind /cache /dev/shm/cache

 

三.测试结果

1.测试分为两种情况:

1)1.6K 在小的图片文件

2)771K aac音频文件

2.       ATS 采用了EPOLL,KQUEUE 的异步IO框架,比较早的select模式在大并发量的情况下优势显著,图中可以看出各项指标均比SQUID 优秀很多。

3.       SQUID在处理小文件时,命中率不是很稳定,而在处理大文件里命中率接近100%

4.       在测试中,ATSSQUID连接处理所需的时间少很多,同时每秒处理请求数翻倍。

5.       在本机与其它机器使用 –header=” Host: www.xxx.com” ,–H “Host: www.xxx.com”,命令测试时,ATSSQUID穿透没有问题,查看日志TCP_HIT,MEM_HIT,均有带www.xxx.com的头信息连接命中。

 1.6K 在小的图片文件



 771K aac音频文件,由于压力测试命令 SQUID ATS服务在一台机器上,测试得出的数值偏小,(测试机同时建立并处理压力测试连接)SQUID并在并发为 2500的时候,没有了处理能力,机器反应缓慢,停止了测试。

PHP的file_get_contents超时502,curl替换性能大幅优化

很多网站做过好多抓取别家网站内容,php上习惯了使用方便快捷的file_get_contents函数,但是总是会遇到获取失败返回502的问题,尽管按照手册中的例子设置了超时,可多数时候不会奏效:

使用 top 命令查看,很多 php-cgi 进程 CPU 使用率接近100%。后来,我通过跟踪发现,这类情况的出现,跟 PHP 的 file_get_contents() 函数有着密切的关系。

 

$config[‘context’] = stream_context_create(array(‘http’ => array(‘method’ => “GET”,
   ’timeout’ => 5//这个超时时间不稳定,经常不奏效
   )
  ));

 

默认值为 0 秒,也就是说,PHP 脚本会一直执行下去。这样,当所有的 php-cgi 进程都卡在 file_get_contents() 函数时,这台 Nginx+PHP 的 WebServer 已经无法再处理新的 PHP 请求了,Nginx 将给用户返回“502 Bad Gateway”。修改该参数,设置一个 PHP 脚本最大执行时间是必要的,但是,治标不治本。例如改成 <value name=”request_terminate_timeout”>30s</value>,如果发生 file_get_contents() 获取网页内容较慢的情况,这就意味着 150 个 php-cgi 进程,每秒钟只能处理 5 个请求,WebServer 同样很难避免“502 Bad Gateway”。
要做到彻底解决,只能让 PHP 程序员们改掉直接使用 file_get_contents(“http://example.com/”) 的习惯,而是稍微修改一下,加个超时时间,用以下方式来实现 HTTP GET 请求。要是觉得麻烦,可以自行将以下代码封装成一个函数。

 

<?php  
$ctx = stream_context_create(array(  
   ‘http’ => array(  
       ‘timeout’ => 1 //设置一个超时时间,单位为秒  
       )  
   )  
);  
file_get_contents(“http://example.com/”, 0, $ctx);  
?>  
首先,使用 top 命令查看 CPU 使用率较高的 php-cgi 进程。
top – 10:34:18 up 724 days, 21:01,  3 users,  load average: 17.86, 11.16, 7.69
Tasks: 561 total,  15 running, 546 sleeping,   0 stopped,   0 zombie
Cpu(s):  5.9%us,  4.2%sy,  0.0%ni, 89.4%id,  0.2%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   8100996k total,  4320108k used,  3780888k free,   772572k buffers
Swap:  8193108k total,    50776k used,  8142332k free,   412088k cached
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                                                               
10747 www       18   0  360m  22m  12m R 100.6 0.3    0:02.60 php-cgi                                                                                                              
10709 www       16   0  359m  28m  17m R 96.8  0.4    0:11.34 php-cgi                                                                                                               
10745 www       18   0  360m  24m  14m R 94.8  0.3    0:39.51 php-cgi                                                                                                               
10707 www       18   0  360m  25m  14m S 77.4  0.3    0:33.48 php-cgi                                                                                                               
10782 www       20   0  360m  26m  15m R 75.5  0.3    0:10.93 php-cgi                                                                                                               
10708 www       25   0  360m  22m  12m R 69.7  0.3    0:45.16 php-cgi                                                                                                               
10683 www       25   0  362m  28m  15m R 54.2  0.4    0:32.65 php-cgi                                                                                                               
10711 www       25   0  360m  25m  15m R 52.2  0.3    0:44.25 php-cgi                                                                                                               
10688 www       25   0  359m  25m  15m R 38.7  0.3    0:10.44 php-cgi                                                                                                               
10719 www       25   0  360m  26m  16m R  7.7  0.3    0:40.59 php-cgi
找其中一个 CPU 100% 的 php-cgi 进程的 PID,用以下命令跟踪一下:
strace -p 10747
如果屏幕显示:
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})
poll([{fd=6, events=POLLIN}], 1, 0)     = 0 (Timeout)
select(7, [6], [6], [], {15, 0})        = 1 (out [6], left {15, 0})

这时候,看一下服务器的连接池,会发现一堆类似的错误,让你头疼万分:

file_get_contents(http://***): failed to open stream…Spring上配置和更换DBCP的方法

不得已,安装了curl库,写了一个函数替换:



function curl_file_get_contents($durl){

   $ch = curl_init();

   curl_setopt($ch, CURLOPT_URL, $durl);

   curl_setopt($ch, CURLOPT_TIMEOUT, 5);

   curl_setopt($ch, CURLOPT_USERAGENT, _USERAGENT_);

   curl_setopt($ch, CURLOPT_REFERER,_REFERER_);

   curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

   $r = curl_exec($ch);

   curl_close($ch);

   return $r;

 }

如此,除了真正的网络问题外,没再出现任何问题。

这是别人做过的关于curl和file_get_contents的测试:

file_get_contents抓取google.com需用秒数:

2.31319094
        2.30374217
        2.21512604
        3.30553889
       2.30124092

curl使用的时间:

0.68719101
        0.64675593
        0.64326
        0.81983113
        0.63956594

差距很大吧?呵呵,从我使用的经验来说,这两个工具不只是速度有差异,稳定性也相差很大。建议对网络数据抓取稳定性要求比较高的朋友使用上面的curl_file_get_contents函数,不但稳定速度快,还能假冒浏览器欺骗目标地址哦!


emlog用nginx配置的rewrite规则

emlog用nginx配置的rewrite规则,在emlog站点的nginx配置文件里加入:

location / {

        index index.php index.html;

        if (!-e $request_filename)

        {

                rewrite ^/(.+)$ /index.php last;

        }

}

/usr/local/nginx/sbin/nginx -t -c /usr/local/nginx/conf/nginx.conf

看看配置是否有错误,如果没有reload一下配置就能生效了。

/etc/init.d/nginx reload

中国电信DNS IP地址大全(32个省)

中国电信DNS IP地址,包括广东电信DNS,上海电信DNS,北京电信DNS,浙江电信DNS,江苏电信DNS等共全国32个电信省份的DNS IP地址。

中国电信 辽宁省 沈阳市DNS 59.46.69.66
中国电信 辽宁省 大连市DNS 59.44.126.20
中国电信 青海省 西宁市DNS 202.100.138.68
中国电信 新疆 乌鲁木齐市DNS 61.128.114.133
中国电信 新疆 乌鲁木齐市DNS 61.128.114.166
中国电信 新疆 乌鲁木齐市DNS 61.128.114.85
中国电信 新疆 乌鲁木齐市DNS 61.128.114.70
中国电信 新疆 乌鲁木齐市DNS 61.128.99.133
中国电信 新疆 乌鲁木齐市DNS 61.128.99.134
中国电信 陕西省           124.115.214.58
中国电信 陕西省           124.115.4.91
中国电信 陕西省           61.150.82.68
中国电信 陕西省           61.150.82.65
中国电信 陕西省           61.150.82.69
中国电信 陕西省           124.115.5.52
中国电信 陕西省           61.134.55.252
中国电信 陕西省           124.115.211.42
中国电信 陕西省 咸阳市DNS 61.185.39.206
中国电信 陕西省 咸阳市DNS 219.145.105.47
中国电信 陕西省 西安市DNS 219.144.222.162
中国电信 陕西省 西安市DNS 218.30.19.40
中国电信 陕西省 西安市DNS 218.30.19.50
中国电信 陕西省 西安市DNS 218.30.82.31
中国电信 陕西省 西安市DNS 61.134.1.4
中国电信 陕西省 西安市DNS 61.150.69.6
中国电信 陕西省 西安市DNS 124.115.170.4
中国电信 陕西省 榆林市DNS 61.134.60.148
中国电信 陕西省 榆林市DNS 61.134.60.149
中国电信 陕西省 榆林市DNS 61.150.114.130
中国电信 上海市DNS 上海市DNS 58.34.8.36
中国电信 上海市DNS 上海市DNS 202.96.197.1
中国电信 上海市DNS 上海市DNS 222.73.226.119
中国电信 上海市DNS 上海市DNS 61.152.248.83
中国电信 上海市DNS 上海市DNS 202.96.247.194
中国电信 上海市DNS 上海市DNS 61.129.72.11
中国电信 上海市DNS 上海市DNS 202.101.10.135
中国电信 上海市DNS 上海市DNS 202.109.117.200
中国电信 上海市DNS 上海市DNS 61.152.117.9
中国电信 上海市DNS 上海市DNS 202.109.14.12
中国电信 上海市DNS 上海市DNS 202.109.117.203
中国电信 上海市DNS 上海市DNS 202.109.116.116
中国电信 上海市DNS 上海市DNS 222.73.75.110
中国电信 上海市DNS 上海市DNS 61.129.66.79
中国电信 上海市DNS 上海市DNS 202.96.199.132
中国电信 上海市DNS 上海市DNS 202.96.209.149
中国电信 上海市DNS 上海市DNS 202.96.209.17
中国电信 上海市DNS 上海市DNS 202.96.209.19
中国电信 上海市DNS 上海市DNS 202.96.209.22
中国电信 上海市DNS 上海市DNS 116.228.218.74
中国电信 上海市DNS 上海市DNS 222.69.242.61
中国电信 上海市DNS 上海市DNS 61.152.82.18
中国电信 上海市DNS 上海市DNS 61.129.88.123
中国电信 上海市DNS 上海市DNS 202.96.209.148
中国电信 上海市DNS 上海市DNS 202.96.209.147
中国电信 上海市DNS 上海市DNS 202.96.209.140
中国电信 上海市DNS 上海市DNS 202.96.209.16
中国电信 上海市DNS 上海市DNS 202.96.209.11
中国电信 上海市DNS 上海市DNS 202.96.209.12
中国电信 上海市DNS 上海市DNS 202.96.209.13
中国电信 上海市DNS 上海市DNS 202.96.209.137
中国电信 上海市DNS 上海市DNS 202.96.209.138
中国电信 上海市DNS 上海市DNS 202.96.209.139
中国电信 上海市DNS 上海市DNS 202.96.209.14
中国电信 上海市DNS 上海市DNS 202.96.209.141
中国电信 上海市DNS 上海市DNS 61.129.78.10
中国电信 上海市DNS 上海市DNS 61.129.73.196
中国电信 上海市DNS 上海市DNS 218.83.245.26
中国电信 上海市DNS 上海市DNS 222.66.120.179
中国电信 上海市DNS 上海市DNS 61.152.219.51
中国电信 上海市DNS 上海市DNS 124.74.238.91
中国电信 上海市DNS 上海市DNS 61.172.245.96
中国电信 上海市DNS 上海市DNS 61.129.93.83
中国电信 上海市DNS 上海市DNS 114.80.88.6
中国电信 上海市DNS 上海市DNS 61.172.196.100
中国电信 上海市DNS 上海市DNS 116.225.147.12
中国电信 上海市DNS 上海市DNS 116.233.170.179
中国电信 上海市DNS 上海市DNS 218.1.115.99
中国电信 上海市DNS 上海市DNS 222.73.207.166
中国电信 上海市DNS 上海市DNS 61.172.252.103
中国电信 上海市DNS 上海市DNS 124.74.243.10
中国电信 上海市DNS 上海市DNS 61.152.241.141
中国电信 上海市DNS 上海市DNS 222.73.27.15
中国电信 上海市DNS 上海市DNS 202.101.8.18
中国电信 上海市DNS 上海市DNS 116.228.160.4
中国电信 上海市DNS 上海市DNS 61.129.64.3
中国电信 上海市DNS 上海市DNS 116.231.108.224
中国电信 上海市DNS 上海市DNS 218.80.219.58
中国电信 上海市DNS 上海市DNS 202.101.10.10
中国电信 上海市DNS 上海市DNS 222.66.131.226
中国电信 上海市DNS 上海市DNS 61.129.39.70
中国电信 上海市DNS 上海市DNS 61.129.39.72
中国电信 上海市DNS 上海市DNS 114.80.108.60
中国电信 上海市DNS 上海市DNS 222.66.15.227
中国电信 上海市DNS 上海市DNS 222.73.127.66
中国电信 上海市DNS 上海市DNS 222.70.146.159
中国电信 上海市DNS 上海市DNS 222.66.115.99
中国电信 上海市DNS 上海市DNS 222.73.75.109
中国电信 上海市DNS 上海市DNS 202.96.209.15
中国电信 上海市DNS 上海市DNS 202.96.209.143
中国电信 上海市DNS 上海市DNS 202.96.199.133
中国电信 上海市DNS 上海市DNS 114.80.98.2
中国电信 上海市DNS 上海市DNS 202.101.6.2
中国电信 上海市DNS 上海市DNS 114.80.88.5
中国电信 上海市DNS 上海市DNS 61.172.0.26
中国电信 上海市DNS 上海市DNS 222.66.79.188
中国电信 四川省           218.6.145.111
中国电信 四川省           61.139.39.73
中国电信 四川省 乐山市DNS 218.89.0.124
中国电信 四川省 乐山市DNS 61.139.50.67
中国电信 四川省 乐山市DNS 218.89.0.116
中国电信 四川省 凉山州 61.139.54.66
中国电信 四川省 攀枝花市DNS 221.236.79.18
中国电信 四川省 攀枝花市DNS 221.236.77.83
中国电信 四川省 攀枝花市DNS 221.236.80.18
中国电信 四川省 内江市DNS 61.139.46.90
中国电信 四川省 成都市DNS 125.70.244.39
中国电信 四川省 成都市DNS 222.209.210.88
中国电信 四川省 成都市DNS 125.71.217.212
中国电信 四川省 成都市DNS 218.6.192.242
中国电信 四川省 成都市DNS 202.98.130.139
中国电信 四川省 成都市DNS 125.71.117.0
中国电信 四川省 成都市DNS 125.70.254.244
中国电信 四川省 成都市DNS 125.70.254.243
中国电信 四川省 成都市DNS 125.70.254.241
中国电信 四川省 成都市DNS 125.70.254.242
中国电信 四川省 自贡市DNS 61.139.44.68
中国电信 山西省           219.149.190.60
中国电信 山西省           59.48.133.60
中国电信 山东省           219.146.165.18
中国电信 山东省 青岛市DNS 222.173.95.53
中国电信 山东省 青岛市DNS 222.173.107.2
中国电信 山东省 日照市DNS 222.175.240.70
中国电信 山东省 东营市DNS 222.174.100.6
中国电信 山东省 东营市DNS 222.174.117.50
中国电信 山东省 东营市DNS 222.174.112.156
中国电信 山东省 东营市DNS 222.174.115.44
中国电信 山东省 济南市DNS 219.146.0.253
中国电信 山东省 济南市DNS 218.98.195.243
中国电信 山东省 济宁市DNS 222.175.169.91
中国电信 山东省 淄博市DNS 222.173.235.42
中国电信 山东省 淄博市DNS 222.173.245.130
中国电信 山东省 淄博市DNS 58.57.109.14
中国电信 山东省 淄博市DNS 222.173.249.162
中国电信 山东省 淄博市DNS 222.173.245.42
中国电信 山东省 淄博市DNS 222.173.252.210
中国电信 山东省 淄博市DNS 222.173.245.122
中国电信 山东省 淄博市DNS 222.173.245.46
中国电信 山东省 淄博市DNS 222.173.243.222
中国电信 山东省 淄博市DNS 222.173.252.226
中国电信 山东省 淄博市DNS 222.173.249.22
中国电信 山东省 淄博市DNS 222.173.245.54
中国电信 山东省 淄博市DNS 222.173.235.146
中国电信 天津市DNS 天津市DNS 221.238.23.102
中国电信 天津市DNS 天津市DNS 221.238.23.104
中国电信 天津市DNS 天津市DNS 221.238.23.101
中国电信 西藏           202.98.224.68
中国电信 西藏           202.98.239.78
中国电信 西藏           202.98.224.69
中国电信 西藏 日喀则市DNS 202.98.234.35
中国电信 浙江省           202.96.102.3
中国电信 浙江省           61.175.111.61
中国电信 浙江省           61.175.111.60
中国电信 浙江省           61.175.231.157
中国电信 浙江省           61.175.111.59
中国电信 浙江省           202.96.103.36
中国电信 浙江省           61.153.198.227
中国电信 浙江省           61.153.198.226
中国电信 浙江省 衢州市DNS 202.96.113.122
中国电信 浙江省 衢州市DNS 202.107.245.11
中国电信 浙江省 衢州市DNS 202.96.113.123
中国电信 浙江省 衢州市DNS 202.96.113.124
中国电信 浙江省 丽水市DNS 61.174.95.146
中国电信 浙江省 丽水市DNS 61.175.243.2
中国电信 浙江省 丽水市DNS 61.174.95.147
中国电信 浙江省 丽水市DNS 61.174.95.148
中国电信 浙江省 绍兴市DNS 220.187.246.18
中国电信 浙江省 绍兴市DNS 202.107.225.78
中国电信 浙江省 温州市DNS 125.109.134.86
中国电信 浙江省 温州市DNS 61.153.30.140
中国电信 浙江省 温州市DNS 60.190.78.226
中国电信 浙江省 温州市DNS 61.175.207.22
中国电信 浙江省 温州市DNS 61.153.33.179
中国电信 浙江省 温州市DNS 61.164.99.26
中国电信 浙江省 温州市DNS 60.190.84.110
中国电信 浙江省 温州市DNS 61.175.208.80
中国电信 浙江省 温州市DNS 61.164.136.154
中国电信 浙江省 温州市DNS 61.164.128.42
中国电信 浙江省 温州市DNS 60.190.79.90
中国电信 浙江省 温州市DNS 60.190.76.6
中国电信 浙江省 温州市DNS 61.164.129.123
中国电信 浙江省 温州市DNS 218.75.31.206
中国电信 浙江省 温州市DNS 61.164.98.218
中国电信 浙江省 温州市DNS 61.164.105.222
中国电信 浙江省 温州市DNS 61.164.104.62
中国电信 浙江省 温州市DNS 218.75.26.70
中国电信 浙江省 温州市DNS 218.75.28.78
中国电信 浙江省 温州市DNS 202.107.223.178
中国电信 浙江省 宁波市DNS 61.153.81.85
中国电信 浙江省 宁波市DNS 218.75.80.26
中国电信 浙江省 宁波市DNS 61.153.81.86
中国电信 浙江省 宁波市DNS 61.153.81.82
中国电信 浙江省 宁波市DNS 61.153.81.83
中国电信 浙江省 宁波市DNS 61.153.81.84
中国电信 浙江省 宁波市DNS 60.190.27.38
中国电信 浙江省 宁波市DNS 60.190.34.70
中国电信 浙江省 宁波市DNS 60.190.36.106
中国电信 浙江省 宁波市DNS 61.130.96.30
中国电信 浙江省 宁波市DNS 122.246.188.78
中国电信 浙江省 舟山市DNS 61.153.215.194
中国电信 浙江省 杭州市DNS 60.191.123.53
中国电信 浙江省 杭州市DNS 122.224.140.131
中国电信 浙江省 杭州市DNS 202.96.96.236
中国电信 浙江省 杭州市DNS 202.101.173.130
中国电信 浙江省 杭州市DNS 61.164.59.162
中国电信 浙江省 杭州市DNS 202.101.173.135
中国电信 浙江省 杭州市DNS 61.164.63.33
中国电信 浙江省 杭州市DNS 202.101.172.142
中国电信 浙江省 杭州市DNS 60.191.70.203
中国电信 浙江省 杭州市DNS 122.224.70.238
中国电信 浙江省 杭州市DNS 211.155.235.188
中国电信 浙江省 杭州市DNS 202.101.173.131
中国电信 浙江省 杭州市DNS 202.107.224.162
中国电信 浙江省 杭州市DNS 202.107.204.34
中国电信 浙江省 杭州市DNS 218.75.37.230
中国电信 浙江省 杭州市DNS 60.191.123.52
中国电信 浙江省 杭州市DNS 202.101.173.132
中国电信 浙江省 杭州市DNS 202.96.122.86
中国电信 浙江省 杭州市DNS 60.190.232.99
中国电信 浙江省 杭州市DNS 122.224.70.253
中国电信 浙江省 湖州市DNS 122.225.96.117
中国电信 浙江省 湖州市DNS 61.130.219.132
中国电信 浙江省 湖州市DNS 61.130.219.131
中国电信 浙江省 湖州市DNS 61.130.219.130
中国电信 浙江省 嘉兴市DNS 220.189.120.198
中国电信 浙江省 嘉兴市DNS 220.189.120.195
中国电信 浙江省 嘉兴市DNS 125.123.0.170
中国电信 浙江省 嘉兴市DNS 218.75.56.26
中国电信 浙江省 嘉兴市DNS 220.189.120.196
中国电信 浙江省 嘉兴市DNS 220.189.120.197
中国电信 浙江省 嘉兴市DNS 61.153.224.8
中国电信 浙江省 嘉兴市DNS 60.190.154.226
中国电信 浙江省 嘉兴市DNS 61.174.79.14
中国电信 浙江省 嘉兴市DNS 220.191.220.10
中国电信 浙江省 嘉兴市DNS 220.189.127.34
中国电信 浙江省 嘉兴市DNS 60.190.139.10
中国电信 浙江省 金华市DNS 60.191.208.110
中国电信 浙江省 金华市DNS 60.191.249.235
中国电信 浙江省 金华市DNS 125.112.124.204
中国电信 浙江省 金华市DNS 60.191.236.170
中国电信 浙江省 金华市DNS 202.96.125.106
中国电信 浙江省 金华市DNS 125.112.124.203
中国电信 浙江省 金华市DNS 125.112.124.205
中国电信 浙江省 金华市DNS 125.112.124.202
中国电信 浙江省 金华市DNS 61.164.183.134
中国电信 浙江省 金华市DNS 202.96.119.202
中国电信 浙江省 金华市DNS 122.227.12.212
中国电信 浙江省 金华市DNS 60.191.241.30
中国电信 浙江省 金华市DNS 122.227.44.178
中国电信 浙江省 金华市DNS 60.191.249.238
中国电信 浙江省 金华市DNS 125.112.124.206
中国电信 浙江省 金华市DNS 60.191.249.236
中国电信 浙江省 金华市DNS 60.191.249.234
中国电信 浙江省 金华市DNS 60.191.199.22
中国电信 浙江省 金华市DNS 60.191.249.237
中国电信 云南省           60.161.79.210
中国电信 云南省           60.161.14.90
中国电信 云南省 昆明市DNS 116.53.237.85
中国电信 内蒙古           222.74.242.189
中国电信 内蒙古 包头市DNS 222.74.39.50
中国电信 内蒙古 包头市DNS 222.74.49.22
中国电信 重庆市DNS 重庆市DNS 61.128.192.99
中国电信 重庆市DNS 重庆市DNS 119.85.59.106
中国电信 重庆市DNS 重庆市DNS 61.128.128.82
中国电信 重庆市DNS 重庆市DNS 61.128.128.67
中国电信 重庆市DNS 重庆市DNS 61.128.192.69
中国电信 重庆市DNS 重庆市DNS 61.128.128.85
中国电信 重庆市DNS 重庆市DNS 61.128.192.73
中国电信 重庆市DNS 重庆市DNS 61.128.192.76
中国电信 重庆市DNS 重庆市DNS 61.128.192.97
中国电信 重庆市DNS 重庆市DNS 61.128.128.80
中国电信 重庆市DNS 重庆市DNS 61.128.128.75
中国电信 重庆市DNS 重庆市DNS 61.128.128.71
中国电信 重庆市DNS 重庆市DNS 222.177.11.53
中国电信 重庆市DNS 重庆市DNS 219.153.20.171
中国电信 重庆市DNS 重庆市DNS 61.128.128.66
中国电信 重庆市DNS 重庆市DNS 61.128.128.69
中国电信 安徽省           60.170.27.24
中国电信 安徽省           202.102.200.101
中国电信 安徽省 芜湖市DNS 202.102.199.93
中国电信 安徽省 芜湖市DNS 202.102.199.92
中国电信 安徽省 芜湖市DNS 202.102.199.87
中国电信 安徽省 芜湖市DNS 202.102.199.88
中国电信 安徽省 芜湖市DNS 202.102.199.82
中国电信 安徽省 阜阳市DNS 202.102.192.74
中国电信 安徽省 阜阳市DNS 202.102.192.75
中国电信 安徽省 阜阳市DNS 202.102.192.73
中国电信 安徽省 阜阳市DNS 202.102.192.72
中国电信 安徽省 合肥市DNS 61.191.16.138
中国电信 安徽省 合肥市DNS 220.178.32.98
中国电信 安徽省 合肥市DNS 220.178.101.58
中国电信 安徽省 合肥市DNS 61.191.22.150
中国电信 安徽省 合肥市DNS 218.22.11.67
中国电信 安徽省 合肥市DNS 220.178.99.240
中国电信 安徽省 合肥市DNS 218.22.20.242
中国电信 安徽省 合肥市DNS 61.190.49.139
中国电信 安徽省 合肥市DNS 220.178.41.106
中国电信 安徽省 合肥市DNS 61.132.132.10
中国电信 安徽省 合肥市DNS 220.178.45.148
中国电信 安徽省 合肥市DNS 220.178.75.134
中国电信 北京市DNS 北京市DNS 219.238.239.155
中国电信 北京市DNS 北京市DNS 219.142.76.3
中国电信 北京市DNS 北京市DNS 219.141.244.2
中国电信 北京市DNS 北京市DNS 219.234.181.239
中国电信 北京市DNS 北京市DNS 218.30.103.185
中国电信 北京市DNS 北京市DNS 60.195.248.7
中国电信 北京市DNS 北京市DNS 219.234.181.249
中国电信 北京市DNS 北京市DNS 219.141.210.3
中国电信 北京市DNS 北京市DNS 219.141.185.2
中国电信 北京市DNS 北京市DNS 211.147.4.36
中国电信 北京市DNS 北京市DNS 219.141.231.161
中国电信 北京市DNS 北京市DNS 124.207.219.130
中国电信 北京市DNS 北京市DNS 124.193.221.177
中国电信 北京市DNS 北京市DNS 218.249.31.119
中国电信 北京市DNS 北京市DNS 218.249.201.133
中国电信 北京市DNS 北京市DNS 219.142.98.250
中国电信 北京市DNS 北京市DNS 219.142.41.58
中国电信 北京市DNS 北京市DNS 218.249.47.125
中国电信 北京市DNS 北京市DNS 219.142.41.3
中国电信 北京市DNS 北京市DNS 220.181.30.35
中国电信 北京市DNS 北京市DNS 218.30.108.179
中国电信 北京市DNS 北京市DNS 218.30.108.198
中国电信 北京市DNS 北京市DNS 218.30.111.254
中国电信 北京市DNS 北京市DNS 218.249.108.104
中国电信 北京市DNS 北京市DNS 219.141.185.129
中国电信 北京市DNS 北京市DNS 219.142.202.200
中国电信 北京市DNS 北京市DNS 219.141.216.253
中国电信 北京市DNS 北京市DNS 210.75.99.11
中国电信 北京市DNS 北京市DNS 219.141.148.39
中国电信 北京市DNS 北京市DNS 219.141.148.38
中国电信 北京市DNS 北京市DNS 219.141.148.37
中国电信 北京市DNS 北京市DNS 219.141.140.10
中国电信 北京市DNS 北京市DNS 211.100.30.41
中国电信 北京市DNS 北京市DNS 211.100.30.29
中国电信 北京市DNS 北京市DNS 219.143.38.232
中国电信 北京市DNS 北京市DNS 218.249.94.190
中国电信 北京市DNS 北京市DNS 218.247.141.66
中国电信 北京市DNS 北京市DNS 211.103.158.124
中国电信 北京市DNS 北京市DNS 211.167.237.204
中国电信 北京市DNS 北京市DNS 124.205.178.26
中国电信 北京市DNS 北京市DNS 124.207.215.71
中国电信 北京市DNS 北京市DNS 219.142.29.222
中国电信 北京市DNS 北京市DNS 202.97.7.17
中国电信 北京市DNS 北京市DNS 202.96.18.1
中国电信 北京市DNS 北京市DNS 202.97.7.6
中国电信 北京市DNS 北京市DNS 220.181.24.53
中国电信 北京市DNS 北京市DNS 218.30.26.68
中国电信 北京市DNS 北京市DNS 218.249.23.68
中国电信 北京市DNS 北京市DNS 211.103.241.168
中国电信 北京市DNS 北京市DNS 219.239.88.90
中国电信 北京市DNS 北京市DNS 220.192.0.130
中国电信 北京市DNS 北京市DNS 218.247.244.2
中国电信 北京市DNS 北京市DNS 218.30.26.70
中国电信 北京市DNS 北京市DNS 211.147.6.3
中国电信 北京市DNS 北京市DNS 211.103.158.182
中国电信 北京市DNS 北京市DNS 218.249.60.66
中国电信 甘肃省           61.178.152.40
中国电信 甘肃省 兰州市DNS 202.100.64.77
中国电信 甘肃省 兰州市DNS 61.178.0.93
中国电信 甘肃省 兰州市DNS 61.178.102.28
中国电信 甘肃省 兰州市DNS 61.178.40.8
中国电信 甘肃省 庆阳市DNS 61.178.172.2
中国电信 福建省           202.101.115.55

 中国电信 福建省 泉州市DNS 218.85.152.108
中国电信 福建省 泉州市DNS 218.85.152.106
中国电信 福建省 泉州市DNS 218.85.152.109
中国电信 福建省 泉州市DNS 218.85.152.105
中国电信 福建省 泉州市DNS 222.79.244.34
中国电信 福建省 泉州市DNS 61.131.46.245
中国电信 福建省 泉州市DNS 202.101.107.35
中国电信 福建省 泉州市DNS 218.85.152.104
中国电信 福建省 泉州市DNS 202.101.107.55
中国电信 福建省 泉州市DNS 61.131.46.251
中国电信 福建省 泉州市DNS 218.85.152.103
中国电信 福建省 泉州市DNS 61.131.46.250
中国电信 福建省 泉州市DNS 218.85.152.102
中国电信 福建省 泉州市DNS 218.85.152.101
中国电信 福建省 泉州市DNS 218.85.152.107
中国电信 福建省 泉州市DNS 61.131.46.246
中国电信 福建省 厦门市DNS 202.101.103.54
中国电信 福建省 厦门市DNS 222.76.243.28
中国电信 福建省 厦门市DNS 202.101.103.53
中国电信 福建省 厦门市DNS 202.101.103.55
中国电信 福建省 厦门市DNS 218.5.76.201
中国电信 福建省 漳州市DNS 202.101.112.55
中国电信 福建省 莆田市DNS 202.101.111.55
中国电信 福建省 莆田市DNS 202.101.138.8
中国电信 福建省 莆田市DNS 202.101.110.55
中国电信 广西省 南宁市DNS 124.227.192.102
中国电信 广西省 桂林市DNS 202.103.244.172
中国电信 广西省 河池市DNS 202.103.221.39
中国电信 广东省           220.192.32.103
中国电信 广东省           121.14.88.71
中国电信 广东省           202.103.180.28
中国电信 广东省           125.89.152.17
中国电信 广东省           119.147.6.208
中国电信 广东省 茂名市DNS 202.103.176.22
中国电信 广东省 汕头市DNS 61.141.22.62
中国电信 广东省 汕头市DNS 121.11.69.194
中国电信 广东省 汕头市DNS 61.141.21.102
中国电信 广东省 汕头市DNS 121.11.69.7
中国电信 广东省 深圳市DNS 61.145.163.34
中国电信 广东省 深圳市DNS 219.133.34.182
中国电信 广东省 深圳市DNS 121.15.143.129
中国电信 广东省 深圳市DNS 218.18.193.137
中国电信 广东省 深圳市DNS 202.96.154.133
中国电信 广东省 深圳市DNS 219.133.59.141
中国电信 广东省 深圳市DNS 219.133.38.93
中国电信 广东省 深圳市DNS 219.133.38.92
中国电信 广东省 深圳市DNS 202.103.190.8
中国电信 广东省 深圳市DNS 61.144.234.232
中国电信 广东省 深圳市DNS 202.96.136.216
中国电信 广东省 深圳市DNS 121.35.243.1
中国电信 广东省 深圳市DNS 58.60.188.173
中国电信 广东省 深圳市DNS 116.30.112.59
中国电信 广东省 深圳市DNS 219.133.0.2
中国电信 广东省 深圳市DNS 219.133.59.142
中国电信 广东省 深圳市DNS 119.145.71.129
中国电信 广东省 深圳市DNS 202.96.174.66
中国电信 广东省 深圳市DNS 202.96.174.67
中国电信 广东省 深圳市DNS 121.15.139.129
中国电信 广东省 深圳市DNS 61.144.222.154
中国电信 广东省 深圳市DNS 116.25.242.182
中国电信 广东省 深圳市DNS 113.106.194.226
中国电信 广东省 深圳市DNS 61.144.227.5
中国电信 广东省 深圳市DNS 113.106.194.232
中国电信 广东省 深圳市DNS 61.141.158.3
中国电信 广东省 深圳市DNS 119.145.29.50
中国电信 广东省 深圳市DNS 202.96.134.173
中国电信 广东省 深圳市DNS 202.96.171.114
中国电信 广东省 深圳市DNS 116.7.75.233
中国电信 广东省 湛江市DNS 219.132.16.194
中国电信 广东省 潮州市DNS 61.140.11.223
中国电信 广东省 潮州市DNS 61.140.11.226
中国电信 广东省 东莞市DNS 202.96.172.218
中国电信 广东省 东莞市DNS 125.93.188.250
中国电信 广东省 东莞市DNS 59.36.102.188
中国电信 广东省 东莞市DNS 218.16.97.149
中国电信 广东省 东莞市DNS 218.247.54.1
中国电信 广东省 东莞市DNS 211.148.156.199
中国电信 广东省 东莞市DNS 202.96.172.198
中国电信 广东省 东莞市DNS 59.39.176.10
中国电信 广东省 东莞市DNS 218.16.110.151
中国电信 广东省 东莞市DNS 218.16.87.87
中国电信 广东省 东莞市DNS 61.142.15.14
中国电信 广东省 东莞市DNS 121.13.250.10
中国电信 广东省 东莞市DNS 119.128.181.126
中国电信 广东省 东莞市DNS 202.96.172.168
中国电信 广东省 东莞市DNS 119.128.95.181
中国电信 广东省 东莞市DNS 121.12.154.130
中国电信 广东省 佛山市DNS 61.142.131.3
中国电信 广东省 佛山市DNS 202.103.188.28
中国电信 广东省 佛山市DNS 61.142.131.2
中国电信 广东省 广州市DNS 219.137.167.168
中国电信 广东省 广州市DNS 219.135.147.22
中国电信 广东省 广州市DNS 61.145.119.23
中国电信 广东省 广州市DNS 202.96.128.86
中国电信 广东省 广州市DNS 219.136.249.153
中国电信 广东省 广州市DNS 59.41.132.6
中国电信 广东省 广州市DNS 61.144.40.92
中国电信 广东省 广州市DNS 59.42.177.226
中国电信 广东省 广州市DNS 219.137.58.214
中国电信 广东省 广州市DNS 59.42.126.250
中国电信 广东省 广州市DNS 61.145.116.81
中国电信 广东省 广州市DNS 61.144.17.107
中国电信 广东省 广州市DNS 121.33.207.186
中国电信 广东省 广州市DNS 218.30.64.97
中国电信 广东省 广州市DNS 218.20.227.1
中国电信 广东省 惠州市DNS 59.33.249.3
中国电信 广东省 惠州市DNS 119.146.77.162
中国电信 广东省 惠州市DNS 119.146.73.66
中国电信 广东省 惠州市DNS 59.33.252.212
中国电信 广东省 惠州市DNS 59.39.145.178
中国电信 广东省 揭阳市DNS 61.143.154.42
中国电信 广东省 揭阳市DNS 61.143.153.103
中国电信 广东省 江门市DNS 125.92.39.163
中国电信 贵州省           119.1.42.35
中国电信 贵州省           202.98.198.167
中国电信 贵州省           219.141.116.227
中国电信 贵州省 贵阳市DNS 202.98.192.67
中国电信 河南省           222.88.212.186
中国电信 河南省           222.88.209.22
中国电信 河南省 郑州市DNS 222.88.49.150
中国电信 河南省 开封市DNS 219.150.150.150
中国电信 河北省 廊坊市DNS 124.238.251.165
中国电信 河北省 廊坊市DNS 124.238.253.131
中国电信 黑龙江省 齐齐哈尔市DNS 219.147.198.242
中国电信 海南省           202.100.209.123
中国电信 海南省 海口市DNS 218.77.186.132
中国电信 湖南省           220.168.208.6
中国电信 湖南省           220.168.208.3
中国电信 湖南省           218.76.192.101
中国电信 湖南省 湘潭市DNS 218.75.247.245
中国电信 湖南省 永州市DNS 218.76.248.100
中国电信 湖南省 永州市DNS 218.76.248.6
中国电信 湖南省 益阳市DNS 220.168.128.2
中国电信 湖南省 株洲市DNS 61.187.98.6
中国电信 湖南省 株洲市DNS 61.187.98.3
中国电信 湖南省 长沙市DNS 220.168.44.60
中国电信 湖南省 长沙市DNS 222.246.129.107
中国电信 湖南省 长沙市DNS 222.246.129.106
中国电信 湖南省 长沙市DNS 202.103.64.139
中国电信 湖南省 长沙市DNS 222.246.129.108
中国电信 湖南省 长沙市DNS 61.187.72.22
中国电信 湖南省 长沙市DNS 222.246.129.101
中国电信 湖南省 长沙市DNS 61.187.64.115
中国电信 湖南省 长沙市DNS 222.246.129.105
中国电信 湖南省 长沙市DNS 222.246.129.104
中国电信 湖南省 长沙市DNS 61.187.72.6
中国电信 湖南省 长沙市DNS 61.186.100.30
中国电信 湖南省 长沙市DNS 61.187.72.23
中国电信 湖南省 长沙市DNS 61.187.72.24
中国电信 湖南省 长沙市DNS 222.246.129.102
中国电信 湖南省 长沙市DNS 222.246.129.103
中国电信 湖南省 长沙市DNS 61.187.72.8
中国电信 湖南省 长沙市DNS 220.168.55.172
中国电信 湖南省 长沙市DNS 202.103.100.100
中国电信 湖南省 长沙市DNS 61.187.72.7
中国电信 湖南省 衡阳市DNS 59.51.78.238
中国电信 湖南省 衡阳市DNS 59.51.78.237
中国电信 湖南省 衡阳市DNS 59.51.78.231
中国电信 湖南省 衡阳市DNS 59.51.78.236
中国电信 湖南省 衡阳市DNS 59.51.78.235
中国电信 湖南省 衡阳市DNS 220.170.64.68
中国电信 湖南省 衡阳市DNS 59.51.78.234
中国电信 湖南省 衡阳市DNS 59.51.78.233
中国电信 湖南省 衡阳市DNS 59.51.78.232
中国电信 湖南省 吉首市DNS 218.76.64.138
中国电信 湖北省           58.51.197.194
中国电信 湖北省           61.136.178.230
中国电信 湖北省           58.54.252.94
中国电信 湖北省 十堰市DNS 58.53.147.250
中国电信 湖北省 咸宁市DNS 202.103.19.34
中国电信 湖北省 襄樊市DNS 61.136.152.73
中国电信 湖北省 襄樊市DNS 219.139.191.240
中国电信 湖北省 武汉市DNS 202.103.0.106
中国电信 湖北省 武汉市DNS 202.103.0.68
中国电信 湖北省 武汉市DNS 219.140.192.118
中国电信 湖北省 武汉市DNS 221.232.129.35
中国电信 湖北省 武汉市DNS 202.103.44.5
中国电信 湖北省 武汉市DNS 202.103.17.2
中国电信 湖北省 武汉市DNS 61.183.8.100
中国电信 湖北省 武汉市DNS 61.183.132.1
中国电信 湖北省 武汉市DNS 221.232.141.194
中国电信 湖北省 宜昌市DNS 202.103.6.46
中国电信 吉林省 长春市DNS 219.149.194.56
中国电信 江苏省           222.191.251.125
中国电信 江苏省           218.91.253.51
中国电信 江苏省           58.221.242.144
中国电信 江苏省           222.184.230.190
中国电信 江苏省 徐州市DNS 218.3.243.4
中国电信 江苏省 徐州市DNS 58.218.152.254
中国电信 江苏省 苏州市DNS 61.155.18.145
中国电信 江苏省 苏州市DNS 221.224.62.50
中国电信 江苏省 苏州市DNS 117.80.242.45
中国电信 江苏省 苏州市DNS 58.211.158.221
中国电信 江苏省 苏州市DNS 222.92.72.106
中国电信 江苏省 苏州市DNS 58.211.219.150
中国电信 江苏省 苏州市DNS 218.4.148.59
中国电信 江苏省 苏州市DNS 58.211.33.198
中国电信 江苏省 苏州市DNS 222.92.107.238
中国电信 江苏省 苏州市DNS 218.4.184.221
中国电信 江苏省 苏州市DNS 61.155.20.195
中国电信 江苏省 苏州市DNS 61.177.1.6
中国电信 江苏省 苏州市DNS 221.224.198.91
中国电信 江苏省 苏州市DNS 58.211.26.146
中国电信 江苏省 苏州市DNS 58.211.158.12
中国电信 江苏省 苏州市DNS 218.4.157.173
中国电信 江苏省 宿迁市DNS 218.93.202.125
中国电信 江苏省 无锡市DNS 58.215.88.10
中国电信 江苏省 无锡市DNS 218.90.175.166
中国电信 江苏省 无锡市DNS 58.215.84.1
中国电信 江苏省 无锡市DNS 58.215.76.163
中国电信 江苏省 无锡市DNS 218.90.147.102
中国电信 江苏省 无锡市DNS 218.90.175.165
中国电信 江苏省 扬州市DNS 61.177.182.153
中国电信 江苏省 扬州市DNS 58.220.235.10
中国电信 江苏省 盐城市DNS 202.102.11.141
中国电信 江苏省 南京市DNS 202.102.24.34
中国电信 江苏省 南京市DNS 202.102.24.35
中国电信 江苏省 南京市DNS 58.213.147.37
中国电信 江苏省 南京市DNS 222.190.124.180
中国电信 江苏省 南京市DNS 221.226.15.99
中国电信 江苏省 南京市DNS 218.94.97.18
中国电信 江苏省 南京市DNS 121.229.134.220
中国电信 江苏省 南京市DNS 218.94.97.21
中国电信 江苏省 南京市DNS 58.213.92.98
中国电信 江苏省 南京市DNS 61.132.73.245
中国电信 江苏省 南京市DNS 58.213.167.100
中国电信 江苏省 常州市DNS 218.93.20.103
中国电信 江苏省 常州市DNS 218.93.116.245
中国电信 江苏省 常州市DNS 222.185.235.196
中国电信 江苏省 常州市DNS 58.216.143.70
中国电信 江西省           218.64.119.55
中国电信 江西省           202.101.234.193
中国电信 江西省           218.65.49.133
中国电信 江西省 南昌市DNS 218.87.20.2
中国电信 江西省 南昌市DNS 218.65.89.130
中国电信 江西省 南昌市DNS 202.101.224.69
中国电信 江西省 南昌市DNS 220.175.13.35
中国电信 江西省 南昌市DNS 220.175.15.220
中国电信 江西省 南昌市DNS 202.109.129.8
中国电信 江西省 南昌市DNS 202.101.208.3
中国电信 江西省 南昌市DNS 218.87.6.206
中国电信 江西省 南昌市DNS 202.101.224.68