使用OpenDNS的好处是，该DNS服务器位于国外，所以不会因为大家都知道的原因在解析某些DNS的时候故意犯错。

OpenDNS的DNS IP如下。

• 主力DNS: 208.67.222.222
• 备份DNS: 208.67.220.220

中国没有根域名服务器，所以对于.com和.net域名的访问，原则上会传递到国外的根域名服务器进行解析。但是中国有根域名镜像服务器，一样可以对于此类国际域名解析进行故意犯错，但是犯错率不可能很高，有的时候镜像服务器会被绕开。直接设置为国外DNS，可以保障不被故意犯错。

根域名服务器是互联网域名解析系统中最高级别的域名服务器，共13台，全部设置在中国以外。由于技术上的限制，不可能再增加根域名服务器，中国想拥有自己的根域名服务器，或者拥有某个根域名服务器的管理权，除非向其他国家购买并且其他国家有意愿出售，这在现实上的可能性为零。

根域名服务器

现在共有13个根域名服务器，域名为“字母.root-servers.net”。其中“字母”的范围是从“A”到“M”。根服务器是互联网域名解析(DNS)系统中最高级别的域名服务器，目前的分布是：主根服务器美国1个，设置在弗吉尼亚州的杜勒斯；辅根服务器美国9个，英国、瑞典、日本各1个。

由于DNS规格的所限，不会再增加任何根域名服务器，它规定UDP协议中最大的包长度为512字节。这个限制产生的理由是，网络传输中不可拆分的最小的IP包大小为576字节。DNS信息交换已经占用了差不多512字节。不过，C, F, I, J, K, L和M服务器已经在不同大洲的多个地点设立，通过任意播(anycast)地址公告提供分散服务，及镜像服务器，其结果是与其说在名义上不如说在物理上，根域名服务器已经设置在美国以外。

截至2006-12-29的根域名服务器和根域名镜像服务器

截至2006-12-29，分布在世界各地的根域名服务器和根域名镜像服务器(anycast)共123个。

根域名服务器分布图，点击放大

DNS解析过程

•  第一步：客户机提出域名解析请求，并将该请求发送给本地的域名服务器。
• 第二步：当本地的域名服务器收到请求后，就先查询本地的缓存，如果有该纪录项，则本地的域名服务器就直接把查询的结果返回。
• 第三步：如果本地的缓存中没有该纪录，则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域(根的子域)的主域名服务器的地址。
• 第四步：本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没有该纪录，则返回相关的下级的域名服务器的地址。
• 第五步：重复第四步，直到找到正确的纪录。
• 第六步：本地域名服务器把返回的结果保存到缓存，以备下一次使用，同时还将结果返回给客户机。

任意播(Anycast)

任意播拓扑图示

任意播（Anycast）是指某组中任意发送方对应拓朴结构中几个最接近的接收方之间的通信。与之比较，组播（Multicast）是指单个发送方对应一组选定接收方的一种通信，单播（Unicast）是指单个发送方对应单个接收方的一种通信。

任意播是 IPv6 中更新路由表时所采用的一种方法。某台主机在更新一个主机组的路由表时，先发送数据到最接近的主机上，IPv6 决定哪个网关主机最接近并发送数据包到该主机，就如单播通信一样，然后主机发送信息到其最接近的路由器上，该过程直至组中的所有路由表都被更新为止。

中国现有的根域名镜像服务器

2003年，F根镜像，由互联网软件联盟(ISC)和中国电信共同建立。
2005年9月，I根镜像，由瑞典国家互联网交换中心(Autonomatic)在CNNIC设立。
2006年12月，J根镜像，由Verisign和网通共同设立。

据称，不愿意透露姓名的互联网信息安全专家表示，在中国设立根域名镜像服务器，中方没有丝毫的管理权限，对于服务器中的日志文件、程序文件，中方根本无法接触，中方对服务器只有供应电源和接通网线的权利。

中国将开通新的根域名镜像服务器

2008年12 月19日消息，网通集团宣布，已与美国威瑞信(VeriSign)公司达成协议，将开通根域名中国镜像服务器，今后中国网民访问.com以及.net网站时，域名解析将不再由设置在境外的域名服务器提供服务，长期以来在中国访问.com以及.net网站的安全性问题得到了保障，上网速度也将提升。网通集团表示，已于12月14日与美国Verisign公司在北京举行签字仪式，正式开通互联网根域名中国镜像服务器。

与目前现有的内容发布模式相比较，CDN强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。在传统的内容发布模式中，内容的发布由ICP的应用服务器完成，而网络只表现为一个透明的数据传输通道，这种透明性表现在网络的质量保证仅仅停留在数据包的层面，而不能根据内容对象的不同区分服务质量。此外，由于IP网的”尽力而为”的特性使得其质量保证是依靠在用户和应用服务器之间端到端地提供充分的、远大于实际所需的带宽通量来实现的。在这样的内容发布模式下，不仅大量宝贵的骨干带宽被占用，同时ICP的应用服务器的负载也变得非常重，而且不可预计。当发生一些热点事件和出现浪涌流量时，会产生局部热点效应，从而使应用服务器过载退出服务。这种基于中心的应用服务器的内容发布模式的另外一个缺陷在于个性化服务的缺失和对宽带服务价值链的扭曲，内容提供商承担了他们不该干也干不好的内容发布服务。

纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革，在这条价值链上的角色越来越多也越来越细分。比如内容／应用的运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的选择。而这就是内容发布网(CDN)服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或缺的最优网站加速服务。

CDN的应用
目前的CDN服务主要应用于证券、金融保险、ISP、ICP、网上交易、门户网站、大中型公司、网络教学等领域。另外在行业专网、互联网中都可以用到，甚至可以对局域网进行网络优化。利用CDN，这些网站无需投资昂贵的各类服务器、设立分站点，特别是流媒体信息的广泛应用、远程教学课件等消耗带宽资源多的媒体信息，应用CDN网络，把内容复制到网络的最边缘，使内容请求点和交付点之间的距离缩至最小，从而促进Web站点性能的提高，具有重要的意义。CDN 网络的建设主要有企业建设的CDN网络，为企业服务；IDC的CDN网络，主要服务于IDC和增值服务；网络运营上主建的CDN网络，主要提供内容推送服务；CDN网络服务商，专门建设的CDN用于做服务，用户通过与CDN机构进行合作，CDN负责信息传递工作，保证信息正常传输，维护传送网络，而网站只需要内容维护，不再需要考虑流量问题。
CDN能够为网络的快速、安全、稳定、可扩展等方面提供保障。

IDC建立CDN网络，IDC运营商一般需要有分布各地的多个IDC中心，服务对象是托管在IDC中心的客户，利用现有的网络资源，投资较少，容易建设。例如某IDC全国有10个机房，加入IDC的CDN网络，托管在一个节点的Web服务器，相当于有了10个镜像服务器，就近供客户访问。宽带城域网，域内网络速度很快，出城带宽一般就会瓶颈，为了体现城域网的高速体验，解决方案就是将Internet网上内容高速缓存到本地，将Cache部署在城域网各POP点上，这样形成高效有序的网络，用户仅一跳就能访问大部分的内容，这也是一种加速所有网站CDN的应用。

CDN的技术原理

在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程，以便了解CDN缓存访问方式与未加缓存访问方式的差别：

什么是CDN
CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户可以就近取得所需的内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。
实际上，内容分发布网络(CDN)是一种新型的网络构建方式，它是为能在传统的IP网发布宽带丰富媒体而特别优化的网络覆盖层；而从广义的角度， CDN代表了一种基于质量与秩序的网络服务模式。简单地说，内容发布网(CDN)是一个经策略性部署的整体系统，包括分布式存储、负载均衡、网络请求的重定向和内容管理４个要件，而内容管理和全局的网络流量管理(Traffic Management)是CDN的核心所在。通过用户就近性和服务器负载的判断，CDN确保内容以一种极为高效的方式为用户的请求提供服务。总的来说，内容服务基于缓存服务器，也称作代理缓存(Surrogate)，它位于网络的边缘，距用户仅有”一跳”(Single Hop)之遥。同时，代理缓存是内容提供商源服务器（通常位于CDN服务提供商的数据中心）的一个透明镜像。这样的架构使得CDN服务提供商能够代表他们客户，即内容供应商，向最终用户提供尽可能好的体验，而这些用户是不能容忍请求响应时间有任何延迟的。据统计，采用CDN技术，能处理整个网站页面的 70%～95％的内容访问量，减轻服务器的压力，提升了网站的性能和可扩展性。

与目前现有的内容发布模式相比较，CDN强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。在传统的内容发布模式中，内容的发布由ICP的应用服务器完成，而网络只表现为一个透明的数据传输通道，这种透明性表现在网络的质量保证仅仅停留在数据包的层面，而不能根据内容对象的不同区分服务质量。此外，由于IP网的”尽力而为”的特性使得其质量保证是依靠在用户和应用服务器之间端到端地提供充分的、远大于实际所需的带宽通量来实现的。在这样的内容发布模式下，不仅大量宝贵的骨干带宽被占用，同时ICP的应用服务器的负载也变得非常重，而且不可预计。当发生一些热点事件和出现浪涌流量时，会产生局部热点效应，从而使应用服务器过载退出服务。这种基于中心的应用服务器的内容发布模式的另外一个缺陷在于个性化服务的缺失和对宽带服务价值链的扭曲，内容提供商承担了他们不该干也干不好的内容发布服务。

纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革，在这条价值链上的角色越来越多也越来越细分。比如内容／应用的运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的选择。而这就是内容发布网(CDN)服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或缺的最优网站加速服务。

CDN的应用
目前的CDN服务主要应用于证券、金融保险、ISP、ICP、网上交易、门户网站、大中型公司、网络教学等领域。另外在行业专网、互联网中都可以用到，甚至可以对局域网进行网络优化。利用CDN，这些网站无需投资昂贵的各类服务器、设立分站点，特别是流媒体信息的广泛应用、远程教学课件等消耗带宽资源多的媒体信息，应用CDN网络，把内容复制到网络的最边缘，使内容请求点和交付点之间的距离缩至最小，从而促进Web站点性能的提高，具有重要的意义。CDN 网络的建设主要有企业建设的CDN网络，为企业服务；IDC的CDN网络，主要服务于IDC和增值服务；网络运营上主建的CDN网络，主要提供内容推送服务；CDN网络服务商，专门建设的CDN用于做服务，用户通过与CDN机构进行合作，CDN负责信息传递工作，保证信息正常传输，维护传送网络，而网站只需要内容维护，不再需要考虑流量问题。
CDN能够为网络的快速、安全、稳定、可扩展等方面提供保障。

IDC建立CDN网络，IDC运营商一般需要有分布各地的多个IDC中心，服务对象是托管在IDC中心的客户，利用现有的网络资源，投资较少，容易建设。例如某IDC全国有10个机房，加入IDC的CDN网络，托管在一个节点的Web服务器，相当于有了10个镜像服务器，就近供客户访问。宽带城域网，域内网络速度很快，出城带宽一般就会瓶颈，为了体现城域网的高速体验，解决方案就是将Internet网上内容高速缓存到本地，将Cache部署在城域网各POP点上，这样形成高效有序的网络，用户仅一跳就能访问大部分的内容，这也是一种加速所有网站CDN的应用。

CDN的技术原理

在描述CDN的实现原理，让我们先看传统的未加缓存服务的访问过程，以便了解CDN缓存访问方式与未加缓存访问方式的差别：

用户提交域名－－－浏览器对域名解析－－－得到目的主机的IP地址－－－根据IP地址发出请求－－－得到回应

由上图可见，用户访问未使用CDN缓存网站的过程为:

用户向浏览器提供要访问的域名；
浏览器调用域名解析函数库对域名进行解析，以得到此域名对应的IP地址；
浏览器使用所得到的IP地址，域名的服务主机发出数据访问请求；
浏览器根据域名主机返回的数据显示网页的内容。

通过以上四个步骤，浏览器完成从用户处接收用户要访问的域名到从域名服务主机处获取数据的整个过程。CDN网络是在用户和服务器之间增加Cache 层，如何将用户的请求引导到Cache上获得源服务器的数据，主要是通过接管DNS实现，下面让我们看看访问使用CDN缓存后的网站的过程：

用户提交域名－－－浏览器对域名解析－－－CDN域名服务器返回指定域名的CNAME记录－－－对CNAME记录进行再解析－－－得到CDN缓存服务器的地址－－－根据IP地址发出请求－－－缓存服务器通过内部DNS得到真实主机地址－－－向真实主机发出请求，并把请求返回客户端－－－客户端浏览器得到请求数据并回显

通过上图，我们可以了解到，使用了CDN缓存后的网站的访问过程变为：

用户向浏览器提供要访问的域名；
浏览器调用域名解析库对域名进行解析，由于CDN对域名解析过程进行了调整，所以解析函数库一般得到的是该域名对应的CNAME记录，为了得到实际IP地址，浏览器需要再次对获得的CNAME域名进行解析以得到实际的IP地址；在此过程中，使用的全局负载均衡DNS解析，如根据地理位置信息解析对应的IP 地址，使得用户能就近访问。
此次解析得到CDN缓存服务器的IP地址，浏览器在得到实际的IP地址以后，向缓存服务器发出访问请求；
缓存服务器根据浏览器提供的要访问的域名，通过Cache内部专用DNS解析得到此域名的实际IP地址，再由缓存服务器向此实际IP地址提交访问请求；
缓存服务器从实际IP地址得得到内容以后，一方面在本地进行保存，以备以后使用，二方面把获取的数据返回给客户端，完成数据服务过程；
客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程。 通过以上的分析我们可以得到，为了实现既要对普通用户透明(即加入缓存以后用户客户端无需进行任何设置，直接使用被加速网站原有的域名即可访问)，又要在为指定的网站提供加速服务的同时降低对ICP的影响，只要修改整个访问过程中的域名解析部分，以实现透明的加速服务，下面是CDN网络实现的具体操作过程。
作为ICP，只需要把域名解释权交给CDN运营商，其他方面不需要进行任何的修改；操作时，ICP修改自己域名的解析记录，一般用cname方式指向CDN网络Cache服务器的地址。
作为CDN运营商，首先需要为ICP的域名提供公开的解析，为了实现sortlist，一般是把ICP的域名解释结果指向一个CNAME记录；
当需要进行sorlist时，CDN运营商可以利用DNS对CNAME指向的域名解析过程进行特殊处理，使DNS服务器在接收到客户端请求时可以根据客户端的IP地址，返回相同域名的不同IP地址；
由于从cname获得的IP地址，并且带有hostname信息，请求到达Cache之后，Cache必须知道源服务器的IP地址，所以在CDN运营商内部维护一个内部DNS服务器，用于解释用户所访问的域名的真实IP地址；
在维护内部DNS服务器时，还需要维护一台授权服务器，控制哪些域名可以进行缓存，而哪些又不进行缓存，以免发生开放代理的情况。

CDN的网络架构
CDN网络架构主要由两大部分，分为中心和边缘两部分，中心指CDN网管中心和DNS重定向解析中心，负责全局负载均衡，设备系统安装在管理中心机房，边缘主要指异地节点，CDN分发的载体，主要由Cache和负载均衡器等组成。
当用户访问加入CDN服务的网站时，域名解析请求将最终交给全局负载均衡DNS进行处理。全局负载均衡DNS通过一组预先定义好的策略，将当时最接近用户的节点地址提供给用户，使用户能够得到快速的服务。同时，它还与分布在世界各地的所有CDNC节点保持通信，搜集各节点的通信状态，确保不将用户的请求分配到不可用的CDN节点上，实际上是通过DNS做全局负载均衡。

对于普通的Internet用户来讲，每个CDN节点就相当于一个放置在它周围的WEB。通过全局负载均衡DNS的控制，用户的请求被透明地指向离他最近的节点，节点中CDN服务器会像网站的原始服务器一样，响应用户的请求。由于它离用户更近，因而响应时间必然更快。

每个CDN节点由两部分组成：负载均衡设备和高速缓存服务器

负载均衡设备负责每个节点中各个Cache的负载均衡，保证节点的工作效率；同时，负载均衡设备还负责收集节点与周围环境的信息，保持与全局负载DNS的通信，实现整个系统的负载均衡。

高速缓存服务器（Cache）负责存储客户网站的大量信息，就像一个靠近用户的网站服务器一样响应本地用户的访问请求。

CDN的管理系统是整个系统能够正常运转的保证。它不仅能对系统中的各个子系统和设备进行实时监控，对各种故障产生相应的告警，还可以实时监测到系统中总的流量和各节点的流量，并保存在系统的数据库中，使网管人员能够方便地进行进一步分析。通过完善的网管系统，用户可以对系统配置进行修改。

理论上，最简单的CDN网络有一个负责全局负载均衡的DNS和各节点一台Cache，即可运行。DNS支持根据用户源IP地址解析不同的IP，实现就近访问。为了保证高可用性等，需要监视各节点的流量、健康状况等。一个节点的单台Cache承载数量不够时，才需要多台Cache，多台Cache同时工作，才需要负载均衡器，使Cache群协同工作。

目录名称 目录内容
apm 高级电源管理信息
cmdline 内核命令行
Cpuinfo 关于Cpu信息
Devices 可以用到的设备（块设备/字符设备）
Dma 使用的DMA通道
Filesystems 支持的文件系统
Interrupts 中断的使用
Ioports I/O端口的使用
Kcore 内核核心印象
Kmsg 内核消息
Ksyms 内核符号表
Loadavg 负载均衡
Locks 内核锁
Meminfo 内存信息
Misc 杂项
Modules 加载模块列表
Mounts 加载的文件系统
Partitions 系统识别的分区表
Rtc 实时时钟
Slabinfo Slab池信息
Stat 全面统计状态表
Swaps 对换空间的利用情况
Version 内核版本
Uptime 系统正常运行时间

并不是所有这些目录在你的系统中都有，这取决于你的内核配置和装载的模块。另外，在/proc下还有三个很重要的目录：net，scsi和sys。 Sys目录是可写的，可以通过它来访问或修改内核的参数（见下一部分），而net和scsi则依赖于内核配置。例如，如果系统不支持scsi，则scsi 目录不存在。

除了以上介绍的这些，还有的是一些以数字命名的目录，它们是进程目录。系统中当前运行的每一个进程都有对应的一个目录在/proc下，以进程的 PID号为目录名，它们是读取进程信息的接口。而self目录则是读取进程本身的信息接口，是一个link。Proc文件系统的名字就是由之而起。进程目录的结构如下：

目录名称 目录内容
Cmdline 命令行参数
Environ 环境变量值
Fd 一个包含所有文件描述符的目录
Mem 进程的内存被利用情况
Stat 进程状态
Status 进程当前状态，以可读的方式显示出来
Cwd 当前工作目录的链接
Exe 指向该进程的执行命令文件
Maps 内存映象
Statm 进程内存状态信息
Root 链接此进程的root目录

用户如果要查看系统信息，可以用cat命令。例如：

# cat /proc/interrupts
CPU0
0: 8728810 XT-PIC timer
1: 895 XT-PIC keyboard
2: 0 XT-PIC cascade
3: 531695 XT-PIC aha152x
4: 2014133 XT-PIC serial
5: 44401 XT-PIC pcnet_cs
8: 2 XT-PIC rtc
11: 8 XT-PIC i82365
12: 182918 XT-PIC Mouse
13: 1 XT-PIC fpu PS/2
14: 1232265 XT-PIC ide0
15: 7 XT-PIC ide1
NMI: 0

用户还可以实现修改内核参数。在/proc文件系统中有一个有趣的目录：/proc/sys。它不仅提供了内核信息，而且可以通过它修改内核参数，来优化你的系统。但是你必须很小心，因为可能会造成系统崩溃。最好是先找一台无关紧要的机子，调试成功后再应用到你的系统上。

要改变内核的参数，只要用vi编辑或echo参数重定向到文件中即可。下面有一个例子：

# cat /proc/sys/fs/file-max
4096
# echo 8192 > /proc/sys/fs/file-max
# cat /proc/sys/fs/file-max
8192

如果你优化了参数，则可以把它们写成添加到文件rc.local中，使它在系统启动时自动完成修改。

/proc文件系统中网络参数

在/proc/sys/net/ipv4/目录下，包含的是和tcp/ip协议相关的各种参数，下面我们就对这些网络参数加以详细的说明。

ip_forward 参数类型：BOOLEAN
0 – 关闭(默认值)
not 0 – 打开ip转发

在网络本地接口之间转发数据报。该参数非常特殊，对该参数的修改将导致其它所有相关配置参数恢复其默认值(对于主机参阅RFC1122，对于路由器参见RFC1812)

ip_default_ttl 参数类型：INTEGER
默认值为 64 。表示IP数据报的Time To Live值。

ip_no_pmtu_disc 参数类型：BOOLEAN
关闭路径MTU探测，默认值为FALSE

ipfrag_high_thresh 参数类型：整型
用来组装分段的IP包的最大内存量。当ipfrag_high_thresh数量的内存被分配来用来组装IP包，则IP分片处理器将丢弃数据报直到ipfrag_low_thresh数量的内存被用来组装IP包。

ipfrag_low_thresh 参数类型：整型
参见ipfrag_high_thresh。

ipfrag_time 参数类型：整型
保存一个IP分片在内存中的时间。

inet_peer_threshold 参数类型：整型
INET对端存储器某个合适值，当超过该阀值条目将被丢弃。该阀值同样决定生存时间以及废物收集通过的时间间隔。条目越多﹐存活期越低﹐GC 间隔越短

inet_peer_minttl 参数类型：整型
条目的最低存活期。在重组端必须要有足够的碎片(fragment)存活期。这个最低存活期必须保证缓冲池容积是否少于 inet_peer_threshold。该值以 jiffies为单位测量。

inet_peer_maxttl 参数类型：整型
条目的最大存活期。在此期限到达之后﹐如果缓冲池没有耗尽压力的话(例如﹐缓冲池中的条目数目非常少)﹐不使用的条目将会超时。该值以 jiffies为单位测量。

inet_peer_gc_mintime 参数类型：整型
废物收集(GC)通过的最短间隔。这个间隔会影响到缓冲池中内存的高压力。 该值以 jiffies为单位测量。

inet_peer_gc_maxtime 参数类型：整型
废物收集(GC)通过的最大间隔，这个间隔会影响到缓冲池中内存的低压力。 该值以 jiffies为单位测量。

tcp_syn_retries 参数类型：整型
对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于255，默认值是5，对应于180秒左右。

tcp_synack_retries 参数类型：整型
对于远端的连接请求SYN，内核会发送SYN ＋ ACK数据报，以确认收到上一个 SYN连接请求包。这是所谓的三次握手( threeway handshake)机制的第二个步骤。这里决定内核在放弃连接之前所送出的 SYN+ACK 数目。

tcp_keepalive_time 参数类型：整型
当keepalive打开的情况下，TCP发送keepalive消息的频率，默认值是2个小时。

tcp_keepalive_probes 参数类型：整型
TCP发送keepalive探测以确定该连接已经断开的次数，默认值是9。

tcp_keepalive_interval 参数类型：整型
探测消息发送的频率，乘以tcp_keepalive_probes就得到对于从开始探测以来没有响应的连接杀除的时间。默认值为75秒，也就是没有活动的连接将在大约11分钟以后将被丢弃。

tcp_retries1 参数类型：整型
当出现可疑情况而必须向网络层报告这个可疑状况之前﹐需要进行多少次重试。最低的 RFC 数值是 3 ﹐这也是默认值﹐根据RTO的值大约在3秒 – 8分钟之间。

tcp_retries2 参数类型：整型
在丢弃激活的TCP连接之前﹐需要进行多少次重试。RFC1122规定，该值必须大于100秒。默认值为15，根据RTO的值来决定，相当于13-30分钟，

tcp_orphan_retries 参数类型：整型
在近端丢弃TCP连接之前﹐要进行多少次重试。默认值是 7 个﹐相当于 50秒 – 16分钟﹐视 RTO 而定。如果您的系统是负载很大的web服务器﹐那么也许需要降低该值﹐这类 sockets 可能会耗费大量的资源。另外参的考 tcp_max_orphans 。

tcp_fin_timeout 参数类型：整型
对于本端断开的socket连接，TCP保持在FIN-WAIT-2状态的时间。对方可能会断开连接或一直不结束连接或不可预料的进程死亡。默认值为 60 秒。过去在2.2版本的内核中是 180 秒。您可以设置该值﹐但需要注意﹐如果您的机器为负载很重的web服务器﹐您可能要冒内存被大量无效数据报填满的风险﹐FIN-WAIT-2 sockets 的危险性低于 FIN-WAIT-1 ﹐因为它们最多只吃 1.5K 的内存﹐但是它们存在时间更长。另外参考 tcp_max_orphans。

tcp_max_tw_buckets 参数类型：整型
系统在同时所处理的最大timewait sockets 数目。如果超过此数的话﹐time-wait socket 会被立即砍除并且显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的 DoS 攻击﹐千万不要人为的降低这个限制﹐不过﹐如果网络条件需要比默认值更多﹐则可以提高它(或许还要增加内存)。

tcp_tw_recycle 参数类型：布尔
打开快速 TIME-WAIT sockets 回收。默认值是1。除非得到技术专家的建议或要求﹐请不要随意修改这个值。

tcp_max_orphans 参数类型：整型
系统所能处理不属于任何进程的TCP sockets最大数量。假如超过这个数量﹐那么不属于任何进程的连接会被立即reset，并同时显示警告信息。之所以要设定这个限制﹐纯粹为了抵御那些简单的 DoS 攻击﹐千万不要依赖这个或是人为的降低这个限制

tcp_abort_on_overflow 参数类型：布尔
当守护进程太忙而不能接受新的连接，就象对方发送reset消息，默认值是false。这意味着当溢出的原因是因为一个偶然的猝发，那么连接将恢复状态。只有在你确信守护进程真的不能完成连接请求时才打开该选项，该选项会影响客户的使用。

tcp_syncookies 参数类型：整型
只有在内核编译时选择了CONFIG_SYNCOOKIES时才会发生作用。当出现syn等候队列出现溢出时象对方发送syncookies。目的是为了防止syn flood攻击。默认值是false。

注意：该选项千万不能用于那些没有收到攻击的高负载服务器，如果在日志中出现synflood消息，但是调查发现没有收到synflood攻击，而是合法用户的连接负载过高的原因，你应该调整其它参数来提高服务器性能。参考: tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow.

syncookie严重的违背TCP协议，不允许使用TCP扩展，可能对某些服务导致严重的性能影响(如SMTP转发)。

tcp_stdurg 参数类型：整型
使用 TCP urg pointer 字段中的主机请求解释功能。大部份的主机都使用老旧的 BSD解释，因此如果您在 Linux 打开它﹐或会导致不能和它们正确沟通。默认值为为﹕FALSE

tcp_max_syn_backlog 参数类型：整型
对于那些依然还未获得客户端确认的连接请求﹐需要保存在队列中最大数目。对于超过 128Mb 内存的系统﹐默认值是 1024 ﹐低于 128Mb 的则为 128。如果服务器经常出现过载﹐可以尝试增加这个数字。警告﹗假如您将此值设为大于 1024﹐最好修改 include/net/tcp.h 里面的 TCP_SYNQ_HSIZE ﹐以保持 TCP_SYNQ_HSIZE*16<=tcp_max_syn_backlog ﹐并且编进核心之内。

tcp_window_scaling 参数类型：布尔
正常来说，TCP/IP 可以接受最大到65535字节的 windows。对于宽带网络，该值可能是不够的，通过调整该参数有助于提高宽带服务器性能。

tcp_timestamps 参数类型：布尔
Timestamps 用在其它一些东西中﹐可以防范那些伪造的 sequence 号码。一条1G的宽带线路或许会重遇到带 out-of-line数值的旧sequence 号码(假如它是由于上次产生的)。Timestamp 会让它知道这是个 ‘旧封包’。

tcp_sack 参数类型：布尔
使用 Selective ACK﹐它可以用来查找特定的遗失的数据报— 因此有助于快速恢复状态。

tcp_fack 参数类型：布尔
打开FACK拥塞避免和快速重传功能。

tcp_dsack 参数类型：布尔
允许TCP发送”两个完全相同”的SACK。

tcp_ecn 参数类型：布尔
打开TCP的直接拥塞通告功能。

tcp_reordering 参数类型：整型
TCP流中重排序的数据报最大数量默认值是 3 。

tcp_retrans_collapse 参数类型：布尔
对于某些有bug的打印机提供针对其bug的兼容性。

tcp_wmem – 三个整数的向量： min, default, max
min：为TCP socket预留用于发送缓冲的内存最小值。每个tcp socket都可以在建议以后都可以使用它。默认值为4K。

default：为TCP socket预留用于发送缓冲的内存数量，默认情况下该值会影响其它协议使用的net.core.wmem_default 值，一般要低于net.core.wmem_default的值。默认值为16K。

max: 用于TCP socket发送缓冲的内存最大值。该值不会影响net.core.wmem_max，今天选择参数SO_SNDBUF则不受该值影响。默认值为128K。

tcp_rmem – 三个整数的向量： min, default, max
min：为TCP socket预留用于接收缓冲的内存数量，即使在内存出现紧张情况下tcp socket都至少会有这么多数量的内存用于接收缓冲，默认值为8K。

default：为TCP socket预留用于接收缓冲的内存数量，默认情况下该值影响其它协议使用的 net.core.wmem_default 值。该值决定了在tcp_adv_win_scale、tcp_app_win和tcp_app_win:0是默认值情况下，tcp 窗口大小为65535。

max：用于TCP socket接收缓冲的内存最大值。该值不会影响 net.core.wmem_max，今天选择参数 SO_SNDBUF则不受该值影响。默认值为 128K。默认值为87380*2 bytes。

tcp_mem – 三个整数的向量： low, pressure, high
low：当TCP使用了低于该值的内存页面数时，TCP不会考虑释放内存。

pressure：当TCP使用了超过该值的内存页面数量时，TCP试图稳定其内存使用，进入pressure模式，当内存消耗低于low值时则退出pressure状态。

high：允许所有tcp sockets用于排队缓冲数据报的页面量。

一般情况下这些值是在系统启动时根据系统内存数量计算得到的。

tcp_app_win – 整数

保留max(window/2^tcp_app_win, mss)数量的窗口由于应用缓冲。当为0时表示不需要缓冲。默认值是31。

tcp_adv_win_scale – 整数
计算缓冲开销bytes/2^tcp_adv_win_scale(如果tcp_adv_win_scale > 0)或者bytes-bytes/2^(-tcp_adv_win_scale)(如果tcp_adv_win_scale <= 0），默认值为2。

ip_local_port_range – 两个整数
定于TCP和UDP使用的本地端口范围，第一个数是开始，第二个数是最后端口号，默认值依赖于系统中可用的内存数：
> 128Mb 32768-61000
< 128Mb 1024-4999 or even less.
该值决定了活动连接的数量，也就是系统可以并发的连接数

icmp_echo_ignore_all – 布尔类型
icmp_echo_ignore_broadcasts – 布尔类型
如果任何一个设置为true(>0)则系统将忽略所有发送给自己的ICMP ECHO请求或那些广播地址的请求。

icmp_destunreach_rate – 整数
icmp_paramprob_rate – 整数
icmp_timeexceed_rate – 整数
icmp_echoreply_rate – 整数(not enabled per default)
限制发向特定目标的ICMP数据报的最大速率。0表示没有任何限制，否则表示jiffies数据单位中允许发送的个数。

icmp_ignore_bogus_error_responses – 布尔类型
某些路由器违背RFC1122标准，其对广播帧发送伪造的响应来应答。这种违背行为通常会被以告警的方式记录在系统日志中。如果该选项设置为True，内核不会记录这种警告信息。默认值为False。

(1) Jiffie: 内核使用的内部时间单位，在i386系统上大小为1/100s，在Alpha中为1/1024S。在/usr/include/asm/param.h中的HZ定义有特定系统的值。

conf/interface/*:
conf/all/*是特定的，用来修改所有接口的设置，is special and changes the settings for all interfaces.
Change special settings per interface.

log_martians – 布尔类型
记录带有不允许的地址的数据报到内核日志中。

accept_redirects – 布尔类型
收发接收ICMP重定向消息。对于主机来说默认为True，对于用作路由器时默认值为False。

forwarding – 布尔类型
在该接口打开转发功能

mc_forwarding – 布尔类型
是否进行多播路由。只有内核编译有CONFIG_MROUTE并且有路由服务程序在运行该参数才有效。

proxy_arp – 布尔类型
打开proxy arp功能。

shared_media – 布尔类型
发送(路由器)或接收(主机) RFC1620 共享媒体重定向。覆盖ip_secure_redirects的值。默认为True。

secure_redirects – 布尔类型
仅仅接收发给默认网关列表中网关的ICMP重定向消息，默认值是TRUE。

send_redirects – 布尔类型
如果是router，发送重定向消息，默认值是TRUE

bootp_relay – 布尔类型
接收源地址为0.b.c.d，目的地址不是本机的数据报。用来支持BOOTP转发服务进程，该进程将捕获并转发该包。默认为False，目前还没有实现。

accept_source_route – 布尔类型
接收带有SRR选项的数据报。对于主机来说默认为False，对于用作路由器时默认值为True。

rp_filter 参数类型
1 – 通过反向路径回溯进行源地址验证(在RFC1812中定义)。对于单穴主机和stub网络路由器推荐使用该选项。
0 – 不通过反向路径回溯进行源地址验证。
默认值为0。某些发布在启动时自动将其打开。

　　fangVoIP，VoiceoverIP，俗称互联网电话，被称为颠覆美国电话业的一场新革命。随着宽带业务的普及，VoIP被越来越多的用户认可。在2003年底，VoIP终于被美国几大运营商列为正式服务项目面向用户推出，这是否预示着新的革命揭开了序幕？

　　VoIP之路方兴未艾

　　美国Jupiter分析公司预言：互联网电话正在从IT专业人士青睐的高科技摇身变为普通用户力所能及的事物。从2003年到2007年，全美上网播打电话的家庭预计将由10万猛增至400万。

　　这种强劲的发展态势和美国的宽松政策是密不可分的。

　　从一开始，美国就将互联网电话归类为增值业务，美国法院又将互联网电话定义为不受监管的领域，让服务提供商在提供互联网电话长途电话业务时，免于向本地电话公司交纳占长途电话费40%左右的接入费。宽松的政策和巨大的市场潜力，吸引了众多传统和新型的电信公司加入到VoIP的研究、开发和经营队伍中。

　　在VoIP公用业务的不断普及过程中，传统ISP服务商中分化出一些专营国际IP电话的网络经营公司，这些公司自建网络，配备网关和集中化的管理设施，具备端到端的管理能力，并且能提供各种特色服务，称为ITSP（电话ISP），如美国ITXC公司，通过其专供各通信公司连接Internet电话的网络来实现语音互通。

　　这种条件下，传统电信运营商顺势而为的选择就是和ITSP进行合作，作为美国骨干因特网接入提供商的Sprint积极通过投资建设下一代网络来为更多用户提供Internet服务和物美价廉的VoIP业务。

　　长途电话巨头AT&T公司也感到了来自各方的压力，通过建立全球清算中心及与Net2phone签约等方式，将网络扩展到其它ISP，把国际呼叫从租用线转到GlobalServices网上。2003年12月11日，AT&T终于一锤定音，宣布推出互联网电话服务，并计划在未来两年内用户达到百万人。除了首先在三个东海岸市场上推出互联网电话服务外，AT&T还将把VoIP拓展到现有的一些企业客户服务当中。

　　不甘落后的Quest通信国际也从2003年12月8日开始在其宽带用户内部推行互联网电话业务，此外，有线电视服务商也凭借其强大的有线电视网络前来分一杯羹，有线巨头时代华纳表示已经与斯普林特通信和MCI达成协议拓展VoIP服务。

　　看起来，新一轮的VoIP业务大战蓄势待发，而竞争也是让产业生命力旺盛的最佳方式

美国VoIP的经验和启示

　　1．互联网电话和互联网接入相结合

　　从美国乃至世界各国的情况来看，互联网电话和互联网的接入是密不可分的，高比率的互联网接入是互联网电话蓬勃发展的物质前提，而互联网电话的推广和普及则能够在一定程度上稳固互联网市场尤其是宽带市场。二者的结合，无论是技术上的整合，还是在销售上的捆绑，都可以建立一种新型的商业模式，从而在传统电话行业中找到一个突破口。不过，这也恰恰说明了不均匀的互联网接入率正在成为互联网电话的下一个障碍。互联网电话和互联网接入的结合很可能会导致现有的数字鸿沟加大加深，把这种高新技术的差异带入传统电话行业中。

　　2．政策监管：自由是把双刃剑

　　在监管政策上，美国和欧洲提供了两个不同的案例。如果说自由开放的美式政策为互联网电话提供了一个温暖的春天，那么，法规凌厉的欧洲则为它制造了一个严冬。二者的结果是有目共睹的。作为一种新兴技术，先发展而后规范是美国的传统，因此，美国也理所当然地成为互联网技术的根据地。但过速的发展同时也导致了不够成熟的技术被广泛普及，而一系列未能解决的问题则在用户享受高科技的同时带来了新的困扰。

　　自由是把双刃剑，为产业带来繁荣的同时也会让整个市场呈现出乱而无序的状态。

　　3．市场拓展的几个重点

　　由于技术本身的原因，互联网电话的用户往往要经历三个阶段的变化。首先是高新技术企业内部试用，然后是普通企业逐渐接受，最后是个人用户广泛普及。不同的用户群要求市场经营开发者必须有层次和针对性地对VoIP进行技术上和宣传上的规划。

　　在赢得用户的过程中，首要的重点是教育，互联网电话在美国的蓬勃发展的基础是用户对互联网本身的高度认知和信赖，这一点在互联网技术欠普及的南美地区就成为新技术推广的严重障碍。其次，价格并非永远的优势，对于企业用户来说，选择VoIP应该不仅仅是为了节约成本，还希望它能够包括更丰富而实用的功能，持续的技术创新才是长久之计。最后，不断进行市场细分将有助于针对不同类型的用户开发辅助功能。

VoIP在其他国家

　　和美国相比，欧洲VoIP的发展状况则不尽人意。这是因为当互联网电话在欧洲大规模发展时，欧洲委员会采取了严格的管制措施，以保障传统电话公司的利益。

　　在日本，VoIP的一些技术创新引起了人们的关注。日本软库企业(Softbank)的子公司BB科技公司2002年推出的“BBPhone”互联网电话服务把VoIP和SDN宽带接入相结合，让用户通过解调器而非电脑来享受VoIP服务，一度赢得用户好评如潮，却因为技术不够完善、话音质量欠佳而在发展过程中遇到了挫折。

　　在南美，有限的互联网接入率和互联网知识贫乏的用户群让VoIP需求平平，VoIP在2002年达到了70.9亿美元的收入，预计到2007年，这个数字将有21.5%的增长。

　　在新加坡，VoIP已经不再是高科技企业的特权，而被跨国大企业和中小企业广泛接受。学校、政府机关也越来越多地采用了这项新技术。随着宽带接入的突飞猛进，个人用户也成为未来的主流市场。

错误代码    错误类型      说明
———-   ————————       ——————————
0×800CCC00   LOAD_SICILY_FAILED             未加载身份验证。
0×800CCC01   INVALID_CERT_CN                证书内容无效。
0×800CCC02   INVALID_CERT_DATE              证书日期无效。
0×800CCC03   ALREADY_CONNECTED              用户已连接。
0×800CCC04   CONN
0×800CCC05   NOT_CONNECTED                  未连接到服务器。
0×800CCC06   CONN_SEND
0×800CCC07   WOULD_BLOCK
0×800CCC08   INVALID_STATE
0×800CCC09   CONN_RECV
0×800CCC0A   INCOMPLETE                     邮件下载未完成。
0×800CCC0B   BUSY                           服务器或邮箱忙。
0×800CCC0C   NOT_INIT
0×800CCC0D   CANT_FIND_HOST                 找不到服务器。
0×800CCC0E   FAILED_TO_CONNECT              无法连接到服务器。
0×800CCC0F   CONNECTION_DROPPED             连接已关闭。
0×800CCC10   INVALID_ADDRESS                服务器上的未知地址。
0×800CCC11   INVALID_ADDRESS_LIST           服务器上的未知邮件列表。
0×800CCC12   SOCKET_READ_ERROR              无法发送 WINSOCK 请求。
0×800CCC13   SOCKET_WRITE_ERROR             无法读取 Winsock 答复。
0×800CCC14   SOCKET_INIT_ERROR              无法初始化 Winsock。
0×800CCC15   SOCKET_CONNECT_ERROR           无法打开 Windows 套接字。
0×800CCC16   INVALID_ACCOUNT                用户帐户未识别。
0×800CCC17   USER_CANCEL                    用户取消了操作。
0×800CCC18   SICILY_LOGON_FAILED            登录尝试失败。
0×800CCC19   TIMEOUT
0×800CCC1A   SECURE_CONNECT_FAILED          无法使用安全套接字层 (SSL) 连接。

WINSOCK 错误
————–

错误代码    错误类型      说明
———-   ————————       ——————————
0×800CCC40   WINSOCK_WSASYSNOTREADY         网络子系统不可用。
0×800CCC41   WINSOCK_WSAVERNOTSUPPORTED     Windows 套接字无法支持此
应用程序。
0×800CCC42   WINSOCK_WSAEPROCLIM
0×800CCC43   WINSOCK_WSAEFAULT              错误地址。
0×800CCC44   WINSOCK_FAILED_WSASTARTUP      无法加载 Windows 套接字。
0×800CCC45   WINSOCK_WSAEINPROGRESS         操作正在进行中。如果在阻塞函数执行过程
中调用 Windows 套接字 API，则会出现此错误。

简单邮件传输协议 (SMTP) 错误
——————————————–

错误代码    错误类型      说明
———-   ————————       ——————————–
0×800CCC60   SMTP_RESPONSE_ERROR            无效的响应。
0×800CCC61   SMTP_UNKNOWN_RESPONSE_CODE     未知的错误代码。
0×800CCC62   SMTP_500_SYNTAX_ERROR          返回语法错误。
0×800CCC63   SMTP_501_PARAM_SYNTAX          参数语法不正确。
0×800CCC64   SMTP_502_COMMAND_NOTIMPL       命令未执行。
0×800CCC65   SMTP_503_COMMAND_SEQ           错误的命令序列。
0×800CCC66   SMTP_504_COMMAND_PARAM_NOTIMPL 命令未执行。
0×800CCC67   SMTP_421_NOT_AVAILABLE         命令不可用。
0×800CCC68   SMTP_450_MAILBOX_BUSY          邮箱被锁定和邮箱忙。
0×800CCC69   SMTP_550_MAILBOX_NOT_FOUND     找不到邮箱。
0×800CCC6A   SMTP_451_ERROR_PROCESSING      处理请求时出错。
0×800CCC6B   SMTP_551_USER_NOT_LOCAL        用户邮箱是已知的，但邮箱不在此服务器上。
0×800CCC6C   SMTP_452_NO_SYSTEM_STORAGE     没有存储邮件的空间。
0×800CCC6D   SMTP_552_STORAGE_OVERFLOW      超出存储限制。
0×800CCC6E   SMTP_553_MAILBOX_NAME_SYNTAX   无效的邮箱名语法。
0×800CCC6F   SMTP_554_TRANSACT_FAILED       事务失败。
0×800CCC78   SMTP_REJECTED_SENDER           未知的发件人。当“回复”字段中有不正确的
电子邮件地址时，会导致此错误。
0×800CCC79   SMTP_REJECTED_RECIPIENTS       服务器拒绝收件人。
0×800CCC7A   SMTP_NO_SENDER                 未指定发件人地址。
0×800CCC7B   SMTP_NO_RECIPIENTS             未指定收件人地址。

邮局协议版本 3 (POP3) 错误
——————————————–

错误代码    错误类型      说明
———-   ————————       —————————–
0×800420CB   POP3_NO_STORE                  邮件无法存储在服务器上。
0×800CCC90   POP3_RESPONSE_ERROR            客户端响应无效。
0×800CCC91   POP3_INVALID_USER_NAME         无效的用户名或未找到用户。
0×800CCC92   POP3_INVALID_PASSWORD          帐户的密码无效。
0×800CCC93   POP3_PARSE_FAILURE             无法解释响应。
0×800CCC94   POP3_NEED_STAT                 需要 STAT 命令。
0×800CCC95   POP3_NO_MESSAGES               服务器上无邮件。
0×800CCC96   POP3_NO_MARKED_MESSAGES        未标记要检索的邮件。
0×800CCC97   POP3_POPID_OUT_OF_RANGE        邮件标识号超出范围。

HTTPMail 错误
————–

错误代码    错误类型      说明
———-   ——————–      —————————
0×800CCC31                            错误的请求配置，错误的或含有恶意代码的请求。

网络新闻传输协议 (NNTP) 错误
———————————————

错误代码    错误类型      说明
———-   ————————   —————————
0×800CCCA0   NNTP_RESPONSE_ERROR        新闻服务器响应错误。
0×800CCCA1   NNTP_NEWGROUPS_FAILED      新闻组访问失败。
0×800CCCA2   NNTP_LIST_FAILED           发往服务器的 LIST 命令失败。
0×800CCCA3   NNTP_LISTGROUP_FAILED      无法显示列表。
0×800CCCA4   NNTP_GROUP_FAILED          无法打开组。
0×800CCCA5   NNTP_GROUP_NOTFOUND        组不在服务器上。
0×800CCCA6   NNTP_ARTICLE_FAILED        邮件不在服务器上。
0×800CCCA7   NNTP_HEAD_FAILED           未找到邮件标题。
0×800CCCA8   NNTP_BODY_FAILED           未找到邮件正文。
0×800CCCA9   NNTP_POST_FAILED           无法投递到服务器。
0×800CCCAA   NNTP_NEXT_FAILED           无法打开下一个邮件。
0×800CCCAB   NNTP_DATE_FAILED           无法显示日期。
0×800CCCAC   NNTP_HEADERS_FAILED        无法显示标题。
0×800CCCAD   NNTP_XHDR_FAILED           无法显示 MIME 标题。
0×800CCCAE   NNTP_INVALID_USERPASS      用户或密码无效。

远程访问服务 (RAS) 错误
———————————-

错误代码    错误类型               说明
———-   ————————   ——————————
0×800CCCC2   RAS_NOT_INSTALLED          RAS/DUN 未安装。
0×800CCCC3   RAS_PROCS_NOT_FOUND        未找到 RAS/DUN 进程。
0×800CCCC4   RAS_ERROR                  返回 RAS/DUN 错误。
0×800CCCC5   RAS_INVALID_CONNECTOID     Connectoid 被损坏或丢失。
0×800CCCC6   RAS_GET_DIAL_PARAMS        获取拨号设置时出错。

Internet 邮件访问协议 (IMAP) 错误
———————————————-

错误代码    错误类型      说明
———-   ————————       —————————–
0×800CCCD1   IMAP_LOGINFAILURE              登录失败。
0×800CCCD2   IMAP_TAGGED_NO_RESPONSE        邮件已标记。
0×800CCCD3   IMAP_BAD_RESPONSE              对请求的响应无效。
0×800CCCD4   IMAP_SVR_SYNTAXERR             语法错误。
0×800CCCD5   IMAP_NOTIMAPSERVER             不是 IMAP 服务器。
0×800CCCD6   IMAP_BUFFER_OVERFLOW           超出缓冲区限制。
0×800CCCD7   IMAP_RECVR_ERROR               恢复错误。
0×800CCCD8   IMAP_INCOMPLETE_LINE           数据不完整。
0×800CCCD9   IMAP_CONNECTION_REFUSED        连接不允许。
0×800CCCDA   IMAP_UNRECOGNIZED_RESP         未知的响应。
0×800CCCDB   IMAP_CHANGEDUID                用户 ID 已更改。
0×800CCCDC   IMAP_UIDORDER                  用户 ID 命令失败。
0×800CCCDD   IMAP_UNSOLICITED_BYE           连接意外断开。
0×800CCCDE   IMAP_IMPROPER_SVRSTATE         服务器状态无效。
0×800CCCDF   IMAP_AUTH_NOT_POSSIBLE         无法授权客户端。
0×800CCCE0   IMAP_OUT_OF_AUTH_METHODS       没有其他授权类型。

附录二 ISIS metric 与Bandwith 对应表
带宽大小（Mbps） METIRC值
2M以下 60
2M 55
5 50
10 45
20 40
30 35
50 30
70 25
100 15
120 10
150 5
附录三 三出口负责地区接入流量表
附录四 调整后的国际带宽分配和路由政策：
1 . 北京
1.1至美国 155M 一条
1.1.1 播出：北京负责地区路由不作控制；其它路由加4个AS
1.1.2 接收：不作控制
1.2至P-NAP 45M 一条
1.2.1播出：北京地址不作控制；河北、内蒙、山西、沈阳、河南、吉林、黑龙江、山东路由metric=50；其它路由加4个AS，metric=100
1.2.2 接收：P-NAP本身的路由不作控制；其它LOCAL PREFERENCE降低至90
1.3 至 verio 45M 一条
1.3.1播出：北京地址 2914：490；河北、内蒙、山西、沈阳、河南、吉林、黑龙江、山东路由加4个AS 2914：490；其它路由加4个AS，2914：460
1.3.2 接收：verio本身，UUNET，MCI-CW的路由不作控制；其它LOCAL PREFERENCE降低至90
1.4至 verio 8M 一条
1.4.1 播出：河北、内蒙、山西路由不作控制 2914：490；其它路由加4个AS，2914：460
1.4.2接收：verio本身，UUNET，MCI-CW的路由不作控制；其它LOCAL PREFERENCE降低至90
2 .上海
2.1 至美国 155M 一条
2.1.1 播出：上海负责地区路由不作控制；其它路由加4个AS
2.1.2 接收：不作控制
2.2 至P-NAP 45M 一条
2.2.1播出：上海地址不作控制；安徽、湖北、天津、江西、陕西、甘肃、青海、宁夏、新疆、广西metric=50；其它加 4个AS，metric=100
2.2.2 接收：P-NAP本身路由不作控制；其它路由LOCAL PREFERENCE降低至90
2.3 至 AT&T 45M 一条
2.3.1播出：上海地址不作控制；江苏、浙江、安徽、湖北、天津、江西、陕西、甘肃、青海、宁夏、新疆、广西加4个AS；其它加 6个AS
2.3.2 接收:不作控制
3 . 广州
3.1至美国 155M 一条
3.1.1播出：广州负责地区不作控制；其它路有加4个AS
3.1.2接收：不作控制
3.2至Global One 45M 一条
3.2.1播出：广东地址不作控制；福建、湖南、海南、四川、云南、贵州、西藏、重庆不作控制加4个AS；其它加6个AS 3.2.2接收：Global One本身路由、UUNET、MCI-CW路由不作控制；其它LOCAL PREFERENCE降低至90
3.3 至 verio 16M 一条
3.3.1 播出：福建、湖南、海南、四川、云南、贵州、西藏、重庆不作控制；其它加4个AS
3.3.2 接收：verio本身的路由不作控制；其它LOCAL PREFERENCE降低至90
4 . 国外对等网
国外对等网及其子网地址LOCAL PREFERENCE升高至500；对外广播地址一般不作控制,确实需要在多条链接上进行分担时采取对广播路由加metric的方式；
5 . 国内对等网
国内对等网的地址优先从北京出口广播；广州、上海广播时加4个AS；

101 usually from sri-nic
102 iso-tsap
103 ISO Mail
104 x400-snd
105 csnet-ns
109 Post Office
110 Pop3 服务器(邮箱发送服务器)
111 portmap 或 sunrpc
113 身份查询
115 sftp
117 path 或 uucp-path
119 新闻服务器
121 BO jammerkillah
123 network time protocol (exp)
135 DCE endpoint resolutionnetbios-ns
137 NetBios-NS
138 NetBios-DGN
139 win98 共享资源端口(NetBios-SSN)
143 IMAP电子邮件
144 NeWS – news
153 sgmp – sgmp
158 PCMAIL
161 snmp – snmp
162 snmp-trap -snmp
170 network Postscrīpt
175 vmnet
194 Irc
315 load
400 vmnet0
443 安全服务
456 Hackers Paradise
500 sytek
512 exec
513 login
514 shell – cmd
515 printer – spooler
517 talk
518 ntalk
520 efs
526 tempo – newdate
530 courier – rpc
531 conference – chat
532 netnews – readnews
533 netwall
540 uucp – uucpd