一 : IDC评述网：12月上旬全球域名解析服务商Top15
IDC评述网(idcps.com)12月23日报道：据WebHosting.info最新数据，截至2013年12月16日，全球域名解析服务商市场基本保持稳定。与上月相比，我国仍是仅有两名域名解析服务商跻身进全球前十五强榜单，且双双进入前十。下面，IDC评述网与大家一起关注12月上旬全球各域名解析服务商具体动态。
(图1)各域名解析服务商域名总量分布图(截至2013/12/16)
如图1所示，在全球域名解析市场上，美国域名解析服务商WILDWESTDOMAINS.COM独占鳌头，域名持有量已超过3500万个，遥遥领先于其他域名解析商。余下十四家域名解析服务商，域名总量均不足500万个，DNSPOD排名第9，中国万网排在第10名。
(图2)12月上旬全球域名解析服务商排名TOP15(截至2013/12/16)
在12月上旬全球域名解析服务商Top15榜单中，美国仍占据10个席位。其中，WILDWESTDOMAINS.COM域名持有量增至35,769,708个，相比11月底新增121,535个，市场份额上升至26.4032%。排名随后的是NETWORKSOLUTIONS.COM，域名总量小幅下滑至3,184,383个，份额小降至2.3505%。ENOM.COM排名第三，域名总量下滑至2,932,763个，份额降至2.1648%。
在此次Top15入围的名单中，中国仍占据两个席位。其中，DNSPOD排名第9，域名总量下滑至1,519,633个，市场份额亦呈现下滑，下降0.04%，至1.1217%;中国万网排名第10。域名总量增至1,447,771个，市场份额上涨0.012%，至1.0687%。
除美国、中国上榜之外，德国、法国和澳大利亚也各有一名域名解析服务商上榜。按目前市场格局来看，美国占据绝对领导地位。
二 : ANDROID DisplayManager 服务解析一
from://http://blog.csdn.net/goohong/article/details/8536102
http://www.tuicool.com/articles/FJVFnu
ANDROID从版本4.2开始提供了一个显示管理服务DisplayManagerService,支持多种显示类型的多个显示器的镜像显示，包括内建的显示类型（本地）、HDMI显示类型以及支持WIFI Display 协议( MIRACAST)，实现本地设备在远程显示器上的镜像显示。(www.61k.com)
整个架构类图如下：
显示管理服务通过DisplayManager提供对外接口，提供的接口包括如下几个：
1 、public Display getDisplay(int displayId)
根据displayId参数获得一个逻辑显示器的信息
2、 public Display[] getDisplays()
获得当前所有有效的逻辑显示器列表
3、public void registerDisplayListener(DisplayListener listener, Handler handler)
登记一个显示监听对象，用来监听显示器的新增、去除或改变通知事件。
4、public void unregisterDisplayListener(DisplayListener listener)
取消先前登记的一个显示监听对象
5、scanWifiDisplays()
启动WIFI显示器的扫描。
6、 public void connectWifiDisplay(String deviceAddress)
根据设备地址连接WIFI显示器
7、public void disconnectWifiDisplay()
断开WIFI显示器
8、 public void renameWifiDisplay(String deviceAddress, String alias)
为WIFI显示器命名
9、public void forgetWifiDisplay(String deviceAddress)
取消先前记忆的WIFI显示器
10、public WifiDisplayStatus getWifiDisplayStatus()
得到当前的WIFI显示器的状态
显示管理系统还与其它系统交互，实现WIFI显示器的发现、WIFI显示器在窗口系统中的登记、窗口内容在WIFI显示器的显示（源端镜像数据的获取、加密、编码，SINK端接收的镜像数据的解码和播放等）等功能。
通过WifiP2pManager接口与WifiP2pService交互，通过WIFI-DIRECT来实现WIFI显示器的自动发现。
窗口管理服务是显示管理服务的监听对象，窗口管理服务通过DisplayManager接口向DisplayManagerService进行登记，当WIFI显示器被发现和连接成功后以及WIFI显示器断开和状态改变后，都会通过回调向窗口管理服务发送事件，窗口管理服务的相应回调函数onDisplayAdded、onDisplayChanged、onDisplayRemoved被调用，用来在窗口系统中进行WIFI显示器的登记以及取消登记、状态改变等处理。
另外DisplayManagerService服务还通过WindowManagerFuncs窗口管理功能接口直接调用窗口管理服务（WindowManagerService是该接口的实现）的函数，实现窗口内容的刷新。同样DisplayManagerService服务还通过InputManagerFuncs接口直接调用输入管理服务的函数setDisplayViewports，用来设置输入系统需要的显示器的显示视图信息。
显示管理系统还通过IMediaPlayerService接口与MediaPlayerService服务交互。
如调用MediaPlayerService服务的listenForRemoteDisplay函数，用来在媒体服务中实例化一个远端显示器的本地代理对象RemoteDisplay，显示系统通过IRemoteDisplay接口调用媒体服务，目前IRemoteDisplay接口只有dispose一个接口函数，用来断开远端显示器，停止监听新的连接。
显示管理系统的WifiDisplaySource对象还调用MediaPlayerService服务的makeHDCP函数来实例化一个HDCP对象并返回给显示系统一个IHDCP接口，用来实现HDCP加密服务。
显示系统的SINK端的TunnelRenderer对象在其initPlayer中还调用MediaPlayerService服务的create函数来创建一个MediaPlayer对象，并返回一个IMediaPlayer接口给显示系统使用，用来实现SINK端接收的镜像数据的播放。
显示管理系统源端获取的镜像数据经过音视频编码（H264），然后进行HDCP加密和PES packetization及TS流化（转换为TS流）后 ，最后打包成RTP包经过UDP通道发送到SINK端，SINK端要经过相反的处理过程，从UDP通道接收RTP包，然后进行TS解析和PES去packetization化和HDCP解密，最后送给解码器进行解码。解码后的数据送给播放器的呈现器进行呈现。
源端和SINK端的音视频编解码都通过IOMX接口与底层的多媒体框架交互，实现音视频编解码功能。IOMX接口对应的对象OMX也是在MediaPlayerService服务端实例化的，在客户端对象OMXClient的connect函数中通过调用MediaPlayerService服务的getOMX函数返回OMX对应的IOMX接口。OMX对象是对多媒体框架OPENOMX的封装。
源端的音视频编码、TS流化、HDCP加密、RTP打包发送的流程都有PlaybackSession线程类管理和调度，PlaybackSession类初始化时实例化一个SurfaceMediaSource对象，SurfaceMediaSource对象内部实例化一个BufferQueue对象（BufferQueue从ISurfaceTexure中派生）。在与SINK端建立连接后，通过IRemoteDisplayClient接口的回调函数onDisplayConnected把BufferQueue对象传给JAVA层，JAVA层的WifiDisplayAdapter对象收到onDisplayConnected事件后调用Surface类的createDisplay函数在SurfaceFlinger服务中登记一个虚拟显示器,并调用Surface类的setDisplaySurface函数把BufferQueue传给SurfaceFlinger服务虚拟显示器对应的DisplayDeviceState变量中.。因此PlaybackSession可以使用BufferQueue对象从SurfaceFlinger服务读取要镜像的数据。
SINK端WifiDisplaySink对象接收的数据经RTP解码（由RTPSink对象负责）后,送给TunnelRenderer对象进进行呈现, TunnelRenderer对象在initPlayer函数中实例化一个PlayerClient播放客户端,并通过IMediaPlayerService接口调用MediaPlayerService服务的create函数创建一个MediaPlayer对象并返回TunnelRenderer对象IMediaPlayer接口, TunnelRenderer对象使用IMediaPlayer接口对接收到的镜像数据进行播放和呈现, TunnelRenderer对象还在initPlayer函数中通过SurfaceComposerClient对象实例化和获得一个Surface对象,并调用其getSurfaceTexture函数获得Surface对象对应的ISurfaceTexture,并调用IMediaPlayer接口的setVideoSurfaceTexture函数把ISurfaceTexture赋值给播放器,从而实现播放器解码后的显示数据送给SurfaceFlinger显示服务进行显示.
扩展：android解析服务器xml / easy display manager / dell display manager
SINK端的WifiDisplaySink对象和源端WifiDisplaySource的对象负责WIFI Display 交互协议的处理，两个对象都包含一个ANetworkSession对象负责两者之间的网络交互会话过程。
如下是WIFI Display 协议的框架图。
ANDROID4.2的开源代码提供了WIFI Display 协议的具体实现，但对SINK端只是作为一个本地测试命令来执行，并且没有提供图中的用户输入功能，而对于WFD Source端则提供了完整的实现代码，这主要是ANDROID系统主要是作为手机平板操作系统使用的缘故。
ANDROID4.2的WIFIDisplay的实现包括JAVA部分和C++部分。JAVA部分的功能主要对应DisplayManagerService服务，DisplayManagerService服务对于WIFIDisplay实例化和登记一个WifiDisplayAdapter对象（派生自DisplayAdapter）,用来与对应的显示设备建立连接，每个DisplayAdapter与一个显示设备DisplayDevice类一一对应 。每个显示设备在DisplayManagerService服务中 对应一个LogicalDisplay对象。
DisplayManager发起的对WIFI Display的请求都由DisplayManagerService服务转发给WifiDisplayAdapter对象处理,为了实现异步交互和避免死锁，WifiDisplayAdapter对象对于每个请求都启动一个线程来实际完成请求处理,并实例化一个WifiDisplayController对象来封装这些请求的调用。WifiDisplayAdapter对象内部也实例化一个WifiDisplayController.Listener对象用来监听请求的状态。 WifiDisplayController对象内部实例化一个WifiP2pManager对象用来通过其接口向WifiP2pService服务发起WI-FI DIRECT请求。在与WIFI Display连接时通过实例化一个RemoteDisplay 对象来启动监听底层WIFI Display的连接事件。
C++ 部分位于媒体框架层，处于libstagefright目录的wifi-display目录下，wifi-display目录包含两个sink和source两个子目录（分别对应wifi display的sink和source 对应的程序），wifi-display目录还包含source和SINK公用的程序。
主要包含如下文件：
Sink目录主要包含WifiDisplaySink.cpp、RTPSink.cpp、TunnelRenderer.cpp等C++类文件和相应的头文件，分别负责SINK端的协议协议，RTP接收和镜像数据的呈现过程。而TS解析和PES去packetization化及解码过程都有播放器NuPlayer完成，由于Sink端只是一个测试例程，因此暂没有提供HDCP解码流程。
Source目录主要包括WifiDisplaySource.cpp、PlaybackSession.cpp、MediaPuller.cpp、Converter.cpp、TSPacketizer.cpp、Sender.cpp等C++类文件和相应的头文件，分别负责Source端的协议交互，会话过程管理、镜像媒体读取、编码、TS打包及RTP打包发送等过程。Converter 对象中包括一个MediaCodec对象具体负责编码过程，MediaCodec对象实际通过ACodec对象调用IOMX接口使用OPENOMX媒体框架完成镜像数据的编码。
sink和source使用的公共类文件主要是ANetworkSession.cpp和对应头文件以及一个 启动WifiDisplaySink的主程序wfd.cpp，用来 生成命令wfd。
整个协议主要的流程包括WIFI Display显示设备的连接过程和镜像数据的打包发送和接收流程，具体流程在下一篇博文中阐述。
扩展：android解析服务器xml / easy display manager / dell display manager
三 : NAT和代理服务器解析
代理服务器是一个服务器，它作为一个中介用于从请求客户端从其他服务器寻求资源。客户端连接到代理服务器，请求一些服务，如一个文件，连接，网页，或可从不同的服务器和代理服务器等资源评估的要求，以此来简化和控制其复杂性。代理被发明出来的结构和封装添加到分布式系统。今天，大多数代理是网络代理，便利获取内容的万维网，并提供匿名。
类型
代理服务器可以驻留在用户的本地计算机上，或在互联网上的用户的计算机服务器和目标服务器之间的不同点。
传递请求和响应未修改的代理服务器通常被称为网关或有时一个隧道代理。
转发代理是用于从广泛的来源（在互联网上的任何地方大多数情况下）检索面向Internet的代理。
一个反向代理通常是用来作为前端，以控制和保护访问到服务器的专用网络上的面向内部的代理。反向代理服务器通常还执行任务，例如负载平衡，认证，解密或缓存。
开放代理
一个开放的代理是受任何互联网用户访问的转发代理服务器。一个匿名开放代理，用户可以隐瞒自己的IP地址，在浏览网页或使用其他互联网服务。有不同程度的匿名性，然而，以及若干“欺骗”的客户端的方法分为无论代理的揭示本身被使用。
(往返随时随地在互联网上开放代理转发请求)
反向代理一个反向代理（或代理）对客户端是一个普通服务器的代理服务器。请求被转发到哪个处理请求的一个或多个代理服务器。如同它直接从原始服务器来，让客户端没有原始服务器的知识被返回从代理服务器的响应。反向代理被安装在一个或多个网络服务器的附近。从互联网并与附近的网络服务器中的一个的目的地来的所有流量经过代理服务器。使用“反向”在其对应的起源“正向代理”，因为反向代理位于接近网络服务器和服务只有一组受限制的网站。
(反向代理从因特网接受请求，并在内部网络将其转发到服务器。那些发出请求连接到代理并可能不知道内部网络。)
有几个原因安装反向代理服务器：
加密/ SSL加速：在创建安全的网站时，该安全套接字层（SSL）加密往往不是由Web服务器本身完成的，而是由配有SSL加速硬件的反向代理。此外，主机可以提供一个单一的“SSL代理”来为主机任意数量的提供SSL加密; 不再需要为每个主机单独的SSL服务器证书，与下行的背后SSL代理的所有主机都共享一个共同的DNS名称或IP地址的SSL连接。这个问题可以部分通过使用可以克服的SubjectAltName特征X.509证书。使用
监控和过滤
内容控制软件
加密数据的筛选
Web过滤代理是无法安全套接字HTTP交易内情，假设链的信任的SSL / TLS（的传输层安全）没有被篡改。
在SSL / TLS链的信任依赖于受信任的根证书颁发机构。当客户端是由组织管理的工作环境，信任可能会被授予根证书的私钥是已知的代理。因此，由代理生成的根证书被安装到由IT人员的浏览器的CA列表。
在这种情况下，一个SSL / TLS事务的内容代理分析成为可能。代理是实现高效运营的中间人攻击，由根证书代理拥有的客户的信任允许的
日志记录和窃听
改善性能
一个缓存代理服务器通过检索由同一个客户端，甚至其他客户提出的前一个请求保存的内容加速服务请求。缓存代理保持频繁请求资源的本地副本，让大型机构显著减少其上行带宽使用情况和成本，同时显著提高性能。
种类
Web代理服务器
Web代理转发HTTP请求。某些Web代理允许HTTP连接建立通过连接任意数据转发;
SOCKS代理
SOCKS也连接阶段之后任意数据转发，并在Web代理类似于HTTP连接。
透明代理
也称为拦截代理，在线代理，或被迫代理，在一个透明的代理拦截正常通信网络层，而不需要任何特殊的客户端配置。客户无需知道所述代理的存在。透明代理通常位于客户机和因特网之间，与代理执行一些的的功能的网关或路由器。
网络地址转换（NAT）是一种方法，重新映射一个IP的地址空间通过修改到另一网络地址中的信息的互联网协议（IP）数据报分组报头，而他们在整个交通运输路由设备。该技术最初用于为便于重新路由IP网络流量，而不会重编的每个主机的。它已成为在保护中面对全局地址空间分配一个流行的和必要的工具，IPv4地址耗尽通过共享NAT网关的一个Internet路由的IP地址，整个专用网络。
NAT和TCP / UDP
“纯的NAT”信息，IP操作单独，可能或可能不正确地分析完全关心IP信息的协议，如ICMP，取决于有效载荷是否由主机解释的“内部”或翻译的“外” 。只要协议堆栈遍历，即使有这样的基本协议如TCP和UDP的协议将打破除非NAT采取行动超出网络层。
IP分组在每个分组首部，其只为头提供误差检测的校验和。IP数据报可能会变得支离破碎，这是必要的NAT重新组合这些片段，让更高级别的校验和正确的跟踪重新计算正确的哪些分组属于哪个连接。
主要的传输层协议，TCP和UDP，有一个校验和，它涵盖了所有携带的数据，以及在TCP / UDP头，加上包含携带包的源和目的IP地址的“伪首部” TCP / UDP报头。对于始发NAT通过TCP或UDP成功，就必须重新计算基于转换后的IP地址，而不是原来那些在TCP / UDP报头校验和，并将该校验到零散集的第一个数据包的TCP / UDP报头的数据包。接收的NAT必须重新计算在每个其传递给目标主机分组的IP校验，并且还利用重新翻译地址和伪首识别和重新计算的TCP / UDP报头。这不是一个完全解决问题。一种解决方案是对于接收的NAT重新组装整个段，然后再重新计算所有的数据包计算的校验和。
源主机可以进行最大传输单元（MTU）路径发现，以确定无分片传输的数据包大小，然后设置不分段在适当的数据包报头字段（DF）位。当然，这仅仅是一个单向解决方案，因为响应的主机能够发送任何大小，其可到达的NAT之前被分段的数据包
代理与NAT
大多数时候，“代理”是指在一个第7层应用OSI参考模型。但是，代理的另一种方式是通过第3层，被称为网络地址转换（NAT）。这两个代理技术之间的区别是在其运行的层次，并且该过程在配置代理客户端和代理服务器。
在3层代理（NAT）的客户端配置，配置网关就足够了。然而，对于一个层-7-代理的客户端配置，分组的客户端生成的目的地必须始终是代理服务器（第7层），则代理服务器读取每一个数据包，并查找出真目的地。
由于NAT在第3层进行操作，它是资源密集型小于7层代理，也不够灵活。当我们比较这两个技术，我们可能会遇到被称为“透明防火墙”一个术语。透明防火墙是指三层代理使用第7层代理优点，但没有客户端的知识。客户假定网关处于层-3在NAT，并且它不具有关于该分组的内部的任何想法，但通过该方法，第3层分组被发送到调查层-7-代理。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持61阅读。
本文标题：域名解析服务器-IDC评述网：12月上旬全球域名解析服务商Top1561阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1