路由交换与linux备忘录

如果本博客观赏有问题，请使用非IE浏览器！~~

.基于位置服务（Location Based Service）

基于位置的服务(Location Based Service，LBS)，它是通过电信移动运营商的无线电通讯网络（如GSM网、CDMA网）或外部定位方式(如GPS)获取移动终端用户的位置信息（地理坐标，或大地坐标），在GIS(Geographic Information System，地理信息系统)平台的支持下，为用户提供相应服务的一种增值业务。

念　　LBS英文全称为Location Based Services, 它包括两层含义：首先是确定移动设备或用户所在的地理位置；其次是提供与位置相关的各类信息服务。意指与定位相关的各类服务系统，简称”定位服务”，另外一种叫法为MPS-Mobile Position Services, 也称为”移动定位服务”系统。如找到手机用户的当前地理位置，然后在上海市6340平方公里范围内寻找手机用户当前位置处1公里范围内的宾馆、影院、图书 馆、加油站等的名称和地址。所以说LBS就是要借助互联网或无线网络，在固定用户或移动用户之间，完成定位和服务两大功能。

休闲娱乐型

　　1. 签到（Check-In）模式： 主要是以Foursquare为主，还有一些国外同类服务还有Gowalla、Whrrl等，而国内则有：嘀咕、玩转四方、街旁、开开、多乐趣、在哪等几十家。 　　该模式的基本特点如下： 　　1) 用户需要主动签到（Check-In）以记录自己所在的位置 　　2) 通过积分、勋章以及领主等荣誉激励用户 Check-In，满足用户的虚荣感 　　3) 通过与商家合作，对获得的特定积分或勋章的用户提供优惠或折扣的奖励，同时也是对商家品牌的营销 　　4) 通过绑定用户的其它社会化工具，以同步分享用户的地理位置信息 　　5) 通过鼓励用户对地点（商店、餐厅等）进行评价以产生优质内容 　　该模式的最大挑战在于要培养用户每到一个地点就会签到（Check-In）的习惯。而它的商业模式也是比较明显，可以很好地为商户或品牌进行各种形式的营销与推广。而国内比较活跃的街旁网现阶段则更多地与各种音乐会、展览等文艺活动合作，慢慢向年轻人群推广与渗透，积累用户。 　　2. 大富翁游戏模式： 国外的代表是Mytown，国内则是16Fun。主旨是游戏人生，可以让用户利用手机购买现实地理位置里的虚拟房产与道具，并进行消费与互动等将现实和虚拟真正进行融合的一种模式。这种模式的特点是更具趣味性，可玩性与互动性更强，比Check-In模式更具粘性，但是由于需要对现实中的房产等地点进行虚拟化设计，开发成本较高，并且由于地域性过强导致覆盖速度不可能很快。

在商业模式方面，除了借鉴Check-In模式的联合商家营销外，还可提供增值服务，以及类似第二人生（Second Life）的植入广告等。

生活服务型

　　1. 周边生活服务的搜索： 以点评网或者生活信息类网站与地理位置服务结合的模式，代表 大众点评网、台湾的“折扣王”等。主要体验在于工具性的实用特质，问题在于信息量的积累和覆盖面需要比较广泛。 　　2. 与旅游的结合： 旅游具有明显的移动特性和地理属性，LBS和旅游的结合是十分切合的。分享攻略和心得体现了一定的社交性质，代表是游玩网。 　　3. 会员卡与票务模式： 实现一卡制，捆绑多种会员卡的信息，同时电子化的会员卡能记录消费习惯和信息，充分的使用户感受到简捷的形式和大量的优惠信息聚合。代表是国内的“Mokard（M卡）”、还有票务类型的Eventbee。这些移动互联网化的应用正在慢慢渗透到生活服务的方方面面，使我们的生活更加便利与时尚。

社交型

　　1. 地点交友，即时通讯：不同的用户因为在同一时间处于同一地理位置构建用户关键，代表是兜兜友。 　　2. 以地理位置为基础的小型社区： 地理位置为基础的小型社区，代表是“区区小事” 　　四、商业型 　　1. LBS+团购 ：两者都有地域性特征，但是团购又有其差异性，如何结合？美国的GroupTabs给我们带来了新的想象： GroupTabs的用户到一些本地的签约商家，比如一间酒吧，到达后使用GroupTabs的手机应用进行Check In。当Check In的数量到达一定数量后，所有进行过Check In的用户就可以得到一定的折扣或优惠。 　　2. 优惠信息推送服务 ：Getyowza就为用户提供了基于地理位置的优惠信息推送服务,Getyowza的盈利模式是通过和线下商家的合作来实现利益的分成。 　　3. 店内模式 : ShopKick将用户吸引到指定的商场里，完成指定的行为后便赠送其可兑换成商品或礼券的虚拟点数。

编辑本段构成

　　总体上看LBS由移动通信网络和计算机网络结合而成，两个网络之间通过网关实现交互。移动终端通过移动通信网络发出请求，经过网关传递给LBS服务平台；服务平台根据用户请求和用户当前位置进行处理。并将结果通过网关返回给用户。 　　其中移动终端可以是移动电话、个人数字助理(Personal Digital Assistant,PDA)、

   LBS

手持计算机（Pocket PC），也可以是通过Internet通讯的台式计算机（desktop PC）。服务平台主要包括WEB服务器（Web Server）、定位服务器（Location Server）和LDAP（Lightweight Directory Access Protocol）服务器

休闲娱乐型

　　1. 签到（Check-In）模式： 主要是以Foursquare为主，还有一些国外同类服务还有Gowalla、Whrrl等，而国内则有：嘀咕、玩转四方、街旁、开开、多乐趣、在哪等几十家。

　　该模式的基本特点如下：

　　1) 用户需要主动签到（Check-In）以记录自己所在的位置

　　2) 通过积分、勋章以及领主等荣誉激励用户 Check-In，满足用户的虚荣感

　　3) 通过与商家合作，对获得的特定积分或勋章的用户提供优惠或折扣的奖励，同时也是对商家品牌的营销

　　4) 通过绑定用户的其它社会化工具，以同步分享用户的地理位置信息

　　5) 通过鼓励用户对地点（商店、餐厅等）进行评价以产生优质内容

　　该模式的最大挑战在于要培养用户每到一个地点就会签到（Check-In）的习惯。而它的商业模式也是比较明显，可以很好地为商户或品牌进行各种形式的营销与推广。而国内比较活跃的街旁网现阶段则更多地与各种音乐会、展览等文艺活动合作，慢慢向年轻人群推广与渗透，积累用户。

　　2. 大富翁游戏模式： 国外的代表是Mytown，国内则是16Fun。主旨是游戏人生，可以让用户利用手机购买现实地理位置里的虚拟房产与道具，并进行消费与互动等将现实和虚拟真正进行融合的一种模式。这种模式的特点是更具趣味性，可玩性与互动性更强，比Check-In模式更具粘性，但是由于需要对现实中的房产等地点进行虚拟化设计，开发成本较高，并且由于地域性过强导致覆盖速度不可能很快。

在商业模式方面，除了借鉴Check-In模式的联合商家营销外，还可提供增值服务，以及类似第二人生（Second Life）的植入广告等。

生活服务型

　　1. 周边生活服务的搜索： 以点评网或者生活信息类网站与地理位置服务结合的模式，代表 大众点评网、台湾的“折扣王”等。主要体验在于工具性的实用特质，问题在于信息量的积累和覆盖面需要比较广泛。

　　2. 与旅游的结合： 旅游具有明显的移动特性和地理属性，LBS和旅游的结合是十分切合的。分享攻略和心得体现了一定的社交性质，代表是游玩网。

　　3. 会员卡与票务模式： 实现一卡制，捆绑多种会员卡的信息，同时电子化的会员卡能记录消费习惯和信息，充分的使用户感受到简捷的形式和大量的优惠信息聚合。代表是国内的“Mokard（M卡）”、还有票务类型的Eventbee。这些移动互联网化的应用正在慢慢渗透到生活服务的方方面面，使我们的生活更加便利与时尚。

社交型

　　1. 地点交友，即时通讯：不同的用户因为在同一时间处于同一地理位置构建用户关键，代表是兜兜友。

　　2. 以地理位置为基础的小型社区： 地理位置为基础的小型社区，代表是“区区小事”

　　四、商业型

　　1. LBS+团购 ：两者都有地域性特征，但是团购又有其差异性，如何结合？美国的GroupTabs给我们带来了新的想象： GroupTabs的用户到一些本地的签约商家，比如一间酒吧，到达后使用GroupTabs的手机应用进行Check In。当Check In的数量到达一定数量后，所有进行过Check In的用户就可以得到一定的折扣或优惠。

　　2. 优惠信息推送服务 ：Getyowza就为用户提供了基于地理位置的优惠信息推送服务,Getyowza的盈利模式是通过和线下商家的合作来实现利益的分成。

　　3. 店内模式 : ShopKick将用户吸引到指定的商场里，完成指定的行为后便赠送其可兑换成商品或礼券的虚拟点数。

编辑本段构成

　　总体上看LBS由移动通信网络和计算机网络结合而成，两个网络之间通过网关实现交互。移动终端通过移动通信网络发出请求，经过网关传递给LBS服务平台；服务平台根据用户请求和用户当前位置进行处理。并将结果通过网关返回给用户。

　　其中移动终端可以是移动电话、个人数字助理(Personal Digital Assistant,PDA)、

手持计算机（Pocket PC），也可以是通过Internet通讯的台式计算机（desktop PC）。服务平台主要包括WEB服务器（Web Server）、定位服务器（Location Server）和LDAP（Lightweight Directory Access Protocol）服务器

背景　　其实LBS并不是什么新东西，建设GPS系统的目的就是为了给用户提供位置服务。早在上个世纪70年代，美国颁布了911服务规范。 　　基本的911业务(Basic 911)是要求FCC定义的移动和固定运营商实现的一种关系国家和生命安全的紧急处理业务。和我国的110/120等紧急号码一样。要求电信运营商在紧急情况下，可以跟踪到呼叫911号码的电话的所在地。在有线时代，实现起来相对来说容易一些。 　　1993年11月美国一个叫做詹尼弗·库恩的女孩遭绑架之后被杀害，在这个过程当中，库恩用手机拨打了911电话，但是911呼救中心无法通过手机信号确定她的位置。 　　由于这个事件，导致美国的FCC(美国通信委员会)在1996年推出了一个行政性命令E911，要求强制性构建一个公众安全网络，即无论在任何时间和地点，都能通过无线信号追踪到用户的位置。E911有有线和无线之分。有线中由ISUP协议进行了保证，主要与有线网络有关。而FCC定义的无线E911有两个版本。第一个版本要求运营商通过本地PSAP(Public Safety Answering Point)进行呼叫权限鉴权，并且获取主叫用户的号码和主叫用户的基站位置；第二个版本要求运营商提供主叫用户所在位

CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络”边缘”，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度。

CDN技术简介　　（Content Delivery Network） 　　CDN技术是近年来在美国首先兴起并迅速发展起来的一种解决互联网性能不佳问题的有效手段。 其基本思路就是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。通过在网络各处放置节点服务器所构成的在现有的互联网基础之上的一层智能虚拟网络，CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

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

CDN的特点　　与目前现有的内容发布模式相比较，CDN强调了网络在内容发布中的重要性。通过引入主动的内容管理层的和全局负载均衡，CDN从根本上区别于传统的内容发布模式。在传统的内容发布模式中，内容的发布由ICP的应用服务器完成，而网络只

表现为一个透明的数据传输通道，这种透明性表现在网络的质量保证仅仅停留在数据包的层面，而不能根据内容对象的不同区分服务质量。此外，由于IP网的”尽力而为”的特性使得其质量保证是依靠在用户和应用服务器之间端到端地提供充分的、远大于实际所需的带宽通量来实现的。在这样的内容发布模式下，不仅大量宝贵的骨干带宽被占用，同时ICP的应用服务器的负载也变得非常重，而且不可预计。当发生一些热点事件和出现浪涌流量时，会产生局部热点效应，从而使应用服务器过载退出服务。这种基于中心的应用服务器的内容发布模式的另外一个缺陷在于个性化服务的缺失和对宽带服务价值链的扭曲，内容提供商承担了他们不该干也干不好的内容发布服务。 　　纵观整个宽带服务的价值链，内容提供商和用户位于整个价值链的两端，中间依靠网络服务提供商将其串接起来。随着互联网工业的成熟和商业模式的变革，在这条价值链上的角色越来越多也越来越细分。比如内容／应用的运营商、托管服务提供商、骨干网络服务提供商、接入服务提供商等等。在这一条价值链上的每一个角色都要分工合作、各司其职才能为客户提供良好的服务，从而带来多赢的局面。从内容与网络的结合模式上看，内容的发布已经走过了ICP的内容（应用）服务器和IDC这两个阶段。IDC的热潮也催生了托管服务提供商这一角色。但是，IDC并不能解决内容的有效发布问题。内容位于网络的中心并不能解决骨干带宽的占用和建立IP网络上的流量秩序。因此将内容推到网络的边缘，为用户提供就近性的边缘服务，从而保证服务的质量和整个网络上的访问秩序就成了一种显而易见的选择。而这就是内容发布网(CDN)服务模式。CDN的建立解决了困扰内容运营商的内容”集中与分散”的两难选择，无疑对于构建良好的互联网价值链是有价值的，也是不可或缺的最优网站加速服务。

应用举例　　目前，国内访问量较高的大型网站如新浪、网易等，均使用CDN网络加速技术，虽然网站的访问巨大，但无论在什么地方访问都会感觉速度很快。而一般的网站如果服务器在网通，电信用户访问很慢，如果服务器在电信，网通用户访问又很慢。 　　它采取了分布式网络缓存结构（即国际上流行的web cache技术），通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的cache服务器内，通过DNS负载均衡的技术，判断用户来源就近访问cache服务器取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度，如同提供了多个分布在各地的加速器，以达到快速、可冗余的为多个网站加速的目的。 　　CDN服务最初用于确保快速可靠地分发静态内容，这些内容可以缓存，最适合在速网庞大的网络中存储和分发，该网络在几十多个国家的十几个网络中的覆盖CDN网络服务器。 由于动态内容必须通过互联网来传输，因此要提供快速的网络体验，以满足当今用户的要求，只能通过对互联网流量的独特视角来达到。必须使用先进技术来了解通过互联网的最佳路由，充分利用这些最佳路由，加速通过互联网协议的数据通讯,以改善用户的网络体验。

首先简单表述一下传统的动态系统的访问方法： 如右图示（一）表述的是用户的请求过程，用户经过网络中的路由A、B的传输，最终将发送的请求交于动态系统来处理，但是由于HTTP本身的“尽力而为的原则”、网络链路中复杂的环境及硬件的不可靠性的确实存在，致使用户要出现重复发送的请求的现状，所以最终导致用户的请求在提交的过程中出现等待、数据加载时间过长的一些现象的普遍存在，这些在线提交式系统的缓慢直接地影响到办公人员的工作效率，这也是制约着很多大型企业在协同办公OA、ERP、SAP等信息化建设中，出现最多的问题。 　　而CDN分发解决方案解决了与静态网站相关的性能和可靠性问题，而在当今在线业务体验中，与分发静态和动态元素和应用相关的独特挑战，则由速网 的动态网站加速（动态网站加速）来解决。

CDN的特点　　1、本地Cache加速 提高了企业站点（尤其含有大量图片和静态页面站点）的访问速度，并大大提高以上性质站点的稳定性 　　2、镜像服务 消除了不同运营商之间互联的瓶颈造成的影响，实现了跨运营商的网络加速，保证不同网络中的用户都能得到良好的访问质量。 　　3、远程加速 远程访问用户根据DNS负载均衡技术 智能自动选择Cache服务器，选择最快的Cache服务器，加快远程访问的速度 　　4、带宽优化 自动生成服务器的远程Mirror（镜像）cache服务器，远程用户访问时从cache服务器上读取数据，减少远程访问的带宽、分担网络流量、减轻原站点WEB服务器负载等功能。 　　5、集群抗攻击 广泛分布的CDN节点加上节点之间的智能冗余机制，可以有效地预防黑客入侵以及降低各种D.D.o.S攻击对网站的影响，同时保证较好的服务质量 。

CDN中的关键技术　　（1）内容发布：它借助于建立索引、缓存、流分裂、组播（Multicast）等技术，将内容发布或投递到距离用户最近的远程服务点（POP）处； 　　（2）内容路由：它是整体性的网络负载均衡技术，通过内容路由器中的重定向（DNS）机制，在多个远程POP上均衡用户的请求，以使用户请求得到最近内容源的响应； 　　（3）内容交换：它根据内容的可用性、服务器的可用性以及用户的背景，在POP的缓存服务器上，利用应用层交换、流分裂、重定向（ICP、WCCP）等技术，智能地平衡负载流量； 　　（4）性能管理：它通过内部和外部监控系统，获取网络部件的状况信息，测量内容发布的端到端性能（如包丢失、延时、平均带宽、启动时间、帧速率等），保证网络处于最佳的运行状态。

CDN的产品优势　　CDN能几乎涵盖国内所有线路。而在可靠性上， CDN 在结构上实现了多点的冗余，即使某一个节点由于意外发生故障，对网站的访问能够被自动导向其他的健康节点进行响应。CDN能轻松实现网站的全国铺设，不必考虑服务器的投入与托管、不必考虑新增带宽的成本、不必考虑多台服务器的镜像同步、不必考虑更多的管理维护技术人员。

CDN在我国的发展状况　　初期我国CDN市场发展缓慢，2006年后市场陡然升温。国内整体CDN市场规模、运营成熟度、服务能力和技术研发均较国外存在一定的差距。目前我们存在以下类型的CDN服务商： 　　

 CDN 服务商

 优势

 劣势

 专业CDN服务商，代表企业：蓝汛、帝联科技等

 专注核心业务发展，易扩大经营规模进入市场较早，具有成熟的运营机制和较高的服务能力。

 受制于电信运营商带宽租用费用，带宽成本是刚性的，不能形成价格优势。由于电信运营商运营支撑系统的不灵活导致带宽资费设置不灵活，不能按需索取，导致CDN的价格居高不下

 提供CDN服务的IDC 运营商代表企业：网宿科技、世纪互联等

 拥有带宽资源优势，进入市场较容易

 需要添置大量的服务器、网络设备及存储设备，投资成本高

 电信运营商，代表企业：中国电信、原中国网通

 1.拥有巨大的带宽和网络优势，其带宽成本是弹性的，可以配置最优的CDN服务网络资本雄厚，有实力建设规模庞大的CDN网络，拥有品牌优势，与众多互联网公司关系密切，能够引导互联网公司使用CDN服务。
2.已建成流媒体等专用CDN网络在此基础上进行升级和改造，可快速推出多种CDN业务。

 1.CDN行业属于技术驱动型产业，电信运营商的CDN技术储备较薄弱。
2.互联互通问题导致运营商只能在自己的网络上做CDN业务，跨网络运营的问题较难解决
3.CDN不是电信运营商的主营业务，缺乏运营经验和服务能力。

 自建CDN的互联网企业，代表企业：优酷，百度等

 1.节约服务成本，可控性高
2.免受CDN市场价格波动的困扰，利于成本降低

 1.初期投资较大，且增加运营和研发成本
2.非核心业务，易分散对主营业务的精力
3.节点数少，不能完全满足需求

 国外CDN服务商，代表企业：Akamai、Limelight Networks等

 1.资金雄厚，具备技术、运营和服务实力，利于业务开展。
2.在国内开始建设节点，利于市场开拓。

 1.与国内一些IDC和ISP采取代理合作的方式来销售自己的服务，难以大规模开展业务
2.非正规竞争，存在安全隐患，将域名解析权掌控在国外运营商的手里

 免费自助CDN，国内的Webluker，国外的cloudflare

 1.CDN产品免费提供，专注于对对网站运维技术的一站式解决。
2.自助式的CDN解决方案，简单易用，监控解析功能齐全。

 1.现在处于起步阶段，功能和服务能力比较弱
2.对于CDN服务内容有限制，需要备案

http://baike.baidu.com/view/2677528.html

NoSQL，指的是非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

简介　　NoSQL，意即反SQL运动，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

现今状况

　　现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性①，而NoSQL致力于改变这一现状。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。 　　NoSQL项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。 　　这场革命目前仍然需要等待。的确，NoSQL对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据。 　　“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“只是给你所需要的”。 　　1.水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。

我们为什么要使用NOSQL非关系数据库?

　　随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如： 　　1、High performance – 对数据库高并发读写的需求 　　web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。 　　2、Huge Storage – 对海量数据的高效率存储和访问的需求 　　对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。 　　3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求 　　在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？ 　　在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如： 　　1、数据库事务一致性需求 　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。 　　2、数据库的写实时性和读实时性需求 　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。 　　3、对复杂的SQL查询，特别是多表关联查询的需求 　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。 　　因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。 　　NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。 　　当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有其它很多。

特点

　　它们可以处理超大量的数据。 　　它们运行在便宜的PC服务器集群上。 　　PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。 　　它们击碎了性能瓶颈。 　　NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。 　　“SQL并非适用于所有的程序代码，” 对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。 　　没有过多的操作。 　　虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么多。 　　Bootstrap支持 　　因为NoSQL项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。

缺点

　　但是一些人承认，没有正式的官方支持，万一出了差错会是可怕的，至少很多管理人员是这样看。 　　“我们确实需要做一些说服工作，”，“但基本在他们看到我们的第一个原型运行良好之后，我们就能够说服他们，这是条正确的道路。” 简介　　NoSQL，意即反SQL运动，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于目前铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入。

现今状况

　　现今的计算机体系结构在数据存储方面要求具备庞大的水平扩展性①，而NoSQL致力于改变这一现状。目前Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库。

　　NoSQL项目的名字上看不出什么相同之处，但是，它们通常在某些方面相同：它们可以处理超大量的数据。

　　这场革命目前仍然需要等待。的确，NoSQL对大型企业来说还不是主流，但是，一两年之后很可能就会变个样子。在NoSQL运动的最新一次聚会中，来自世界各地的150人挤满了CBS Interactive的一间会议室。分享他们如何推翻缓慢而昂贵的关系数据库的暴政，怎样使用更有效和更便宜的方法来管理数据。

　　“关系型数据库给你强加了太多东西。它们要你强行修改对象数据，以满足RDBMS （relational database management system，关系型数据库管理系统）的需要，”在NoSQL拥护者们看来，基于NoSQL的替代方案“只是给你所需要的”。

　　1.水平扩展性(horizontal scalability)指能够连接多个软硬件的特性,这样可以将多个服务器从逻辑上看成一个实体。

我们为什么要使用NOSQL非关系数据库?

　　随着互联网web2.0网站的兴起，非关系型的数据库现在成了一个极其热门的新领域，非关系数据库产品的发展非常迅速。而传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，例如：

　　1、High performance – 对数据库高并发读写的需求

　　web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。其实对于普通的BBS网站，往往也存在对高并发写请求的需求。

　　2、Huge Storage – 对海量数据的高效率存储和访问的需求

　　对于大型的SNS网站，每天用户产生海量的用户动态，以国外的Friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，例如腾讯，盛大，动辄数以亿计的帐号，关系数据库也很难应付。

　　3、High Scalability && High Availability- 对数据库的高可扩展性和高可用性的需求

　　在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像web server和app server那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？

　　在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：

　　1、数据库事务一致性需求

　　很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。

　　2、数据库的写实时性和读实时性需求

　　对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应用来说，并不要求这么高的实时性。

　　3、对复杂的SQL查询，特别是多表关联查询的需求

　　任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂SQL报表查询，特别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

　　因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。

　　NoSQL 是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与ACID理论大一统的局面。NoSQL 数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。该术语在 2009 年初得到了广泛认同。

　　当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而 NoSQL 存储就是为了实现这个需求。Google 的BigTable与Amazon的Dynamo是非常成功的商业 NoSQL 实现。一些开源的 NoSQL 体系，如Facebook 的Cassandra， Apache 的HBase，也得到了广泛认同。从这些NoSQL项目的名字上看不出什么相同之处：Hadoop、Voldemort、Dynomite，还有其它很多。

特点

　　它们可以处理超大量的数据。

　　它们运行在便宜的PC服务器集群上。

　　PC集群扩充起来非常方便并且成本很低，避免了“sharding”操作的复杂性和成本。

　　它们击碎了性能瓶颈。

　　NoSQL的支持者称，通过NoSQL架构可以省去将Web或Java应用和数据转换成SQL友好格式的时间，执行速度变得更快。

　　“SQL并非适用于所有的程序代码，” 对于那些繁重的重复操作的数据，SQL值得花钱。但是当数据库结构非常简单时，SQL可能没有太大用处。

　　没有过多的操作。

　　虽然NoSQL的支持者也承认关系数据库提供了无可比拟的功能集合，而且在数据完整性上也发挥绝对稳定，他们同时也表示，企业的具体需求可能没有那么多。

　　Bootstrap支持

　　因为NoSQL项目都是开源的，因此它们缺乏供应商提供的正式支持。这一点它们与大多数开源项目一样，不得不从社区中寻求支持。

缺点

　　但是一些人承认，没有正式的官方支持，万一出了差错会是可怕的，至少很多管理人员是这样看。

　　“我们确实需要做一些说服工作，”，“但基本在他们看到我们的第一个原型运行良好之后，我们就能够说服他们，这是条正确的道路。”

LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。它是基于X.500标准的，但是简单多了并且可以根据需要定制。与X.500不同，LDAP支持TCP/IP，这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。

详细信息

LDAP简介

　　简单说来，LDAP是一个得到关于人或者资源的集中、静态数据的快速方式。 　　LDAP是一个用来发布目录信息到许多不同资源的协议。通常它都作为一个集中的地址本使用，不过根据组织者的需要，它可以做得更加强大。 　　LDAP最新的rfc规范文档时RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol

LDAP的实质

　　LDAP其实是一电话簿，类似于我们所使用诸如NIS(Network Information Service)、DNS (Domain Name Service)等网络目录，也类似于你在花园中所看到的树木。 　　不少LDAP开发人员喜欢把LDAP与关系数据库相比，认为是另一种的存贮方式，然后在读性能上进行比较。实际上，这种对比的基础是错误的。LDAP和关系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网格数据库，对象数据库），前者是存贮模式和访问协议。LDAP是一个比关系数据库抽象层次更高的存贮概念，与关系数据库的查询语言SQL属同一级别。LDAP最基本的形式是一个连接数据库的标准方式。该数据库为读查询作了优化。因此它可以很快地得到查询结果，不过在其它方面，例如更新，就慢得多。

特殊的数据库

　　从另一个意义上 LDAP是实现了指定的数据结构的存贮，它是一种特殊的数据库。但是LDAP和一般的数据库不同，明白这一点是很重要的。 LDAP对查询进行了优化，与写性能相比LDAP的读性能要优秀很多。 　　就象Sybase、Oracle、Informix或Microsoft的数据库管理系统（DBMS）是用于处理查询和更新关系型数据库那样，LDAP服务器也是用来处理查询和更新LDAP目录的。换句话来说LDAP目录也是一种类型的数据库，但不是关系型数据库。要特别注意的是，LDAP通常作为一个 hierarchical数据库使用，而不是一个关系数据库。因此，它的结构用树来表示比用表格好。正因为这样，就不能用SQL语句了。 　　现在LDAP技术发展得很快令人激动人心。在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应用程序从LDAP目录中获取信息。LDAP目录中可以存储各种类型的数据：电子邮件地址、邮件路由信息、人力资源数据、公用密匙、联系人列表，等等。通过把LDAP目录作为系统集成中的一个重要环节，可以简化员工在企业内部查询信息的步骤，甚至连主要的数据源都可以放在任何地方。

编辑本段LDAP目录的优势

开发的方式

　　如果需要开发一种提供公共信息查询的系统一般的设计方法可能是采用基于WEB的数据库设计方式，即前端使用浏览器而后端使用WEB服务器加上关系数据库。后端在Windows的典型实现可能是Windows NT + IIS + Acess数据库或者是SQL SERVER，IIS和数据库之间通过ASP技术使用ODBC进行连接，达到通过填写表单查询数据的功能；

Linux的典型

　　后端在Linux系统的典型实现可能是Linux+ Apache + postgresql，Apache和数据库之间通过PHP3提供的函数进行连接。使用上述方法的缺点是后端关系数据库的引入导致系统整体的性能降低和系统的管理比较繁琐，因为需要不断的进行数据类型的验证和事务的完整性的确认；并且前端用户对数据的控制不够灵活，用户权限的设置一般只能是设置在表一级而不是设置在记录一级。 　　目录服务的推出主要是解决上述数据库中存在的问题。目录与关系数据库相似，是指具有描述性的基于属性的记录集合，但它的数据类型主要是字符型，为了检索的需要添加了BIN（二进制数据）、CIS（忽略大小写）、CES（大小写敏感）、TEL（电话型）等语法（Syntax），而不是关系数据库提供的整数、浮点数、日期、货币等类型，同样也不提供象关系数据库中普遍包含的大量的函数，它主要面向数据的查询服务（查询和修改操作比一般是大于10:1），不提供事务的回滚（rollback）机制，它的数据修改使用简单的锁定机制实现All-or-Nothing，它的目标是快速响应和大容量查询并且提供多目录服务器的信息复制功能。 　　现在该说说LDAP目录到底有些什么优势了。现在LDAP的流行是很多因素共同作用的结果。可能LDAP最大的优势是：可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。

LDAP的协议

　　LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。厂商都很愿意在产品中加入对LDAP的支持，因为他们根本不用考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开放源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是，如果软件厂商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务器单独定制。不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费。大多数的LDAP服务器安装起来很简单，也容易维护和优化。

LDAP的服务器

　　LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据，例如：可以把数据“推”到远程的办公室，以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能，数据库产商就会要你支付额外的费用，而且也很难管理。

LDAP的使用权限

　　LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。 　　LDAP（Lightweight Directory Acess Protocol）是目录服务在TCP/IP上的实现（RFC 1777 V2版和RFC 2251 V3版）。它是对X500的目录协议的移植，但是简化了实现方法，所以称为轻量级的目录服务。在LDAP中目录是按照树型结构组织，目录由条目（Entry）组成，条目相当于关系数据库中表的记录；条目是具有区别名DN（Distinguished Name）的属性（Attribute）集合，DN相当于关系数据库表中的关键字（Primary 　　Key）；属性由类型（Type）和多个值（Values）组成，相当于关系数据库中的域（Field）由域名和数据类型组成，只是为了方便检索的需要，LDAP中的Type可以有多个Value，而不是关系数据库中为降低数据的冗余性要求实现的各个域必须是不相关的。LDAP中条目的组织一般按照地理位置和组织关系进行组织，非常的直观。LDAP把数据存放在文件中，为提高效率可以使用基于索引的文件数据库，而不是关系数据库。LDAP协议集还规定了DN的命名方法、存取控制方法、搜索格式、复制方法、URL格式、开发接口等 　　LDAP对于这样存储这样的信息最为有用，也就是数据需要从不同的地点读取，但是不需要经常更新。 　　例如，这些信息存储在LDAP目录中是十分有效的： 　　l 公司员工的电话号码簿和组织结构图 　　l 客户的联系信息 　　l 计算机管理需要的信息，包括NIS映射、email假名，等等 　　l 软件包的配置信息 　　l 公用证书和安全密匙 　　什么时候该用LDAP存储数据 　　大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此，当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化，大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据。例如，用LDAP服务器来存储电话号码是一个很好的选择，但是它不能作为电子商务站点的数据库服务器。 　　如果下面每一个问题的答案都是“是”，那么把数据存在LDAP中就是一个好主意。 　　l 需要在任何平台上都能读取数据吗？ 　　l 每一个单独的记录项是不是每一天都只有很少的改变？ 　　l 可以把数据存在平面数据库（flat database）而不是关系型数据库中吗？换句话来说，也就是不管什么范式不范式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。 　　最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。例如，一条公司员工的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法：如果可以把数据存在一张张的卡片里，就可以很容易地把它存在LDAP目录里。

安全和访问控制

　　LDAP提供很复杂的不同层次的访问控制或者ACI。因这些访问可以在服务器端控制，这比用客户端的软件保证数据的安全可安全多了。 　　用LDAP的ACI，可以完成： 　　l 给予用户改变他们自己的电话号码和家庭地址的权限，但是限制他们对其它数据（如，职务名称，经理的登录名，等等）只有“只读”权限。 　　l 给予“HR-admins”组中的所有人权限以改变下面这些用户的信息：经理、工作名称、员工号、部门名称和部门号。但是对其它域没有写权限。 　　l 禁止任何人查询LDAP服务器上的用户口令，但是可以允许用户改变他或她自己的口令。 　　l 给予经理访问他们上级的家庭电话的只读权限，但是禁止其他人有这个权限。 　　l 给予“host-admins”组中的任何人创建、删除和编辑所有保存在LDAP服务器中的与计算机主机有关的信息 　　l 通过Web，允许“foobar-sales”组中的成员有选择地给予或禁止他们自己读取一部分客户联系数据的读权限。这将允许他们把客户联系信息下载到本地的笔记本电脑或个人数字助理（PDA）上。（如果销售人员的软件都支持LDAP，这将非常有用） 　　l 通过Web，允许组的所有者删除或添加他们拥有的组的成员。例如：可以允许销售经理给予或禁止销售人员改变Web页的权限。也可以允许邮件假名（mail aliase）的所有者不经过IT技术人员就直接从邮件假名中删除或添加用户。“公用”的邮件列表应该允许用户从邮件假名中添加或删除自己（但是只能是自己）。也可以对IP地址或主机名加以限制。例如，某些域只允许用户IP地址以192.168.200.*开头的有读的权限，或者用户反向查找DNS得到的主机名必须为*.foobar点com。

LDAP目录树的结构

　　LDAP目录以树状的层次结构来存储数据。如果你对自顶向下的DNS树或UNIX文件的目录树比较熟悉，也就很容易掌握LDAP目录树这个概念了。就象DNS的主机名那样，LDAP目录记录的标识名（Distinguished Name，简称DN）是用来读取单个记录，以及回溯到树的顶部。后面会做详细地介绍。 　　为什么要用层次结构来组织数据呢？原因是多方面的。下面是可能遇到的一些情况： 　　l 如果你想把所有的美国客户的联系信息都“推”到位于到西雅图办公室（负责营销）的LDAP服务器上，但是你不想把公司的资产管理信息“推”到那里。 　　l 你可能想根据目录树的结构给予不同的员工组不同的权限。在下面的例子里，资产管理组对“asset-mgmt”部分有完全的访问权限，但是不能访问其它地方。 　　l 把LDAP存储和复制功能结合起来，可以定制目录树的结构以降低对WAN带宽的要求。位于西雅图的营销办公室需要每分钟更新的美国销售状况的信息，但是欧洲的销售情况就只要每小时更新一次就行了。 　　刨根问底：基准DN 　　LDAP目录树的最顶部就是根，也就是所谓的“基准DN”。基准DN通常使用下面列出的三种格式之一。假定我在名为FooBar的电子商务公司工作，这家公司在Internet上的名字是foobar 　　o=”FooBar, Inc.”, c=US 　　（以X.500格式表示的基准DN） 　　在这个例子中，o=FooBar, Inc. 表示组织名，在这里就是公司名的同义词。c=US 表示公司的总部在美国。以前，一般都用这种方式来表示基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着Internet的全球化，在基准DN中使用国家代码很容易让人产生混淆。现在，X.500格式发展成下面列出的两种格式。 　　o=foobar . com 　　（用公司的Internet地址表示的基准DN） 　　这种格式很直观，用公司的域名作为基准DN。这也是现在最常用的格式。 　　dc=foobar, dc=com 　　（用DNS域名的不同部分组成的基准DN） 　　就象上面那一种格式，这种格式也是以DNS域名为基础的，但是上面那种格式不改变域名（也就更易读），而这种格式把域名：foobar点com分成两部分 dc=foobar, dc=com。在理论上，这种格式可能会更灵活一点，但是对于最终用户来说也更难记忆一点。考虑一下foobar点com这个例子。当foobar点com和gizmo点com合并之后，可以简单的把“dc=com”当作基准DN。把新的记录放到已经存在的dc=gizmo, dc=com目录下，这样就简化了很多工作（当然，如果foobar点com和wocket点edu合并，这个方法就不能用了）。如果LDAP服务器是新安装的，我建议你使用这种格式。再请注意一下，如果你打算使用活动目录（Actrive Directory），Microsoft已经限制你必须使用这种格式。

在目录树中怎么组织数据

　　在UNIX文件系统中，最顶层是根目录（root）。在根目录的下面有很多的文件和目录。象上面介绍的那样，LDAP目录也是用同样的方法组织起来的。 　　在根目录下，要把数据从逻辑上区分开。因为历史上（X.500）的原因，大多数LDAP目录用OU从逻辑上把数据分开来。OU表示“Organization Unit”，在X.500协议中是用来表示公司内部的机构：销售部、财务部，等等。现在LDAP还保留ou=这样的命名规则，但是扩展了分类的范围，可以分类为：ou=people, ou=groups, ou=devices，等等。更低一级的OU有时用来做更细的归类。例如：LDAP目录树（不包括单独的记录）可能会是这样的： 　　dc=foobar, dc=com 　　ou=customers 　　ou=asia 　　ou=europe 　　ou=usa 　　ou=employees 　　ou=rooms 　　ou=groups 　　ou=assets-mgmt 　　ou=nisgroups 　　ou=recipes

单独的LDAP记录

　　DN是LDAP记录项的名字 　　在LDAP目录中的所有记录项都有一个唯一的“Distinguished Name”，也就是DN。每一个LDAP记录项的DN是由两个部分组成的：相对DN（RDN）和记录在LDAP目录中的位置。 　　RDN是DN中与目录树的结构无关的部分。在LDAP目录中存储的记录项都要有一个名字，这个名字通常存在cn（Common Name）这个属性里。因为几乎所有的东西都有一个名字，在LDAP中存储的对象都用它们的cn值作为RDN的基础。如果我把最喜欢的吃燕麦粥食谱存为一个记录，我就会用cn=Oatmeal Deluxe作为记录项的RDN。 　　l 我的LDAP目录的基准DN是dc=foobar,dc=com 　　l 我把自己的食谱作为LDAP的记录项存在ou=recipes 　　l 我的LDAP记录项的RDN设为cn=Oatmeal Deluxe 　　上面这些构成了燕麦粥食谱的LDAP记录的完整DN。记住，DN的读法和DNS主机名类似。下面就是完整的DN： 　　cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com 　　举一个实际的例子来说明DN 　　现在为公司的员工设置一个DN。可以用基于cn或uid（User ID），作为典型的用户帐号。例如，FooBar的员工Fran Smith（登录名：fsmith）的DN可以为下面两种格式： 　　uid=fsmith,ou=employees,dc=foobar,dc=com 　　（基于登录名） 　　LDAP（以及X.500）用uid表示“User ID”，不要把它和UNIX的uid号混淆了。大多数公司都会给每一个员工唯一的登录名，因此用这个办法可以很好地保存员工的信息。你不用担心以后还会有一个叫Fran Smith的加入公司，如果Fran改变了她的名字（结婚？离婚？或宗教原因？），也用不着改变LDAP记录项的DN。 　　cn=Fran Smith,ou=employees,dc=foobar,dc=com 　　（基于姓名） 　　可以看到这种格式使用了Common Name（CN）。可以把Common Name当成一个人的全名。这种格式有一个很明显的缺点就是：如果名字改变了，LDAP的记录就要从一个DN转移到另一个DN。但是，我们应该尽可能地避免改变一个记录项的DN。

定制目录的对象类型

　　你可以用LDAP存储各种类型的数据对象，只要这些对象可以用属性来表示，下面这些是可以在LDAP中存储的一些信息： 　　l 员工信息：员工的姓名、登录名、口令、员工号、他的经理的登录名，邮件服务器，等等。 　　l 物品跟踪信息：计算机名、IP地址、标签、型号、所在位置，等等。 　　l 客户联系列表：客户的公司名、主要联系人的电话、传真和电子邮件，等等。 　　l 会议厅信息：会议厅的名字、位置、可以坐多少人、电话号码、是否有投影机。 　　l 食谱信息：菜的名字、配料、烹调方法以及准备方法。 　　因为LDAP目录可以定制成存储任何文本或二进制数据，到底存什么要由你自己决定。LDAP目录用对象类型（object classes）的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中，你都要根据自己的需要扩展基本的LDAP目录的功能，创建新的对象类型或者扩展现存的对象类型。 　　LDAP目录以一系列“属性对”的形式来存储记录项，每一个记录项包括属性类型和属性值（这与关系型数据库用行和列来存取数据有根本的不同）。下面是我存在LDAP目录中的一部分食谱记录： 　　dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com 　　cn: Instant Oatmeal Deluxe 　　recipeCuisine: breakfast 　　recipeIngredient: 1 packet instant oatmeal 　　recipeIngredient: 1 cup water 　　recipeIngredient: 1 pinch salt 　　recipeIngredient: 1 tsp brown sugar 　　recipeIngredient: 1/4 apple, any type 　　请注意上面每一种配料都作为属性recipeIngredient值。LDAP目录被设计成象上面那样为一个属性保存多个值的，而不是在每一个属性的后面用逗号把一系列值分开。 　　因为用这样的方式存储数据，所以数据库就有很大的灵活性，不必为加入一些新的数据就重新创建表和索引。更重要的是，LDAP目录不必花费内存或硬盘空间处理“空”域，也就是说，实际上不使用可选择的域也不会花费你任何资源。

示例

　　作为例子的一个单独的数据项 　　让我们看看下面这个例子。我们用Foobar, Inc.的员工Fran Smith的LDAP记录。这个记录项的格式是LDIF，用来导入和导出LDAP目录的记录项。 　　dn: uid=fsmith, ou=employees, dc=foobar, dc=com 　　objectclass: person 　　objectclass: organizationalPerson 　　objectclass: inetOrgPerson 　　objectclass: foobarPerson 　　uid: fsmith 　　givenname: Fran 　　sn: Smith 　　cn: Fran Smith 　　cn: Frances Smith 　　telephonenumber: 510-555-1234 　　roomnumber: 122G 　　o: Foobar, Inc. 　　mailRoutingAddress: fsmith@foobar点com 　　mailhost: mail.foobar点com 　　userpassword: {crypt}3x1231v76T89N 　　uidnumber: 1234 　　gidnumber: 1200 　　homedirectory: /home/fsmith 　　loginshell: /usr/local/bin/bash 　　属性的值在保存的时候是保留大小写的，但是在默认情况下搜索的时候是不区分大小写的。某些特殊的属性（例如，password）在搜索的时候需要区分大小写。 　　让我们一点一点地分析上面的记录项。 　　dn: uid=fsmith, ou=employees, dc=foobar, dc=com 　　这是Fran的LDAP记录项的完整DN，包括在目录树中的完整路径。LDAP（和X.500）使用uid（User ID），不要把它和UNIX的uid号混淆了。 　　objectclass: person 　　objectclass: organizationalPerson 　　objectclass: inetOrgPerson 　　objectclass: foobarPerson 　　可以为任何一个对象根据需要分配多个对象类型。person对象类型要求cn（common name）和sn（surname）这两个域不能为空。persion对象类型允许有其它的可选域，包括givenname、telephonenumber，等等。organizational Person给person加入更多的可选域，inetOrgPerson又加入更多的可选域（包括电子邮件信息）。最后，foobarPerson是为Foobar定制的对象类型，加入了很多定制的属性。 　　uid: fsmith 　　givenname: Fran 　　sn: Smith 　　cn: Fran Smith 　　cn: Frances Smith 　　telephonenumber: 510-555-1234 　　roomnumber: 122G 　　o: Foobar, Inc. 　　以前说过了，uid表示User ID。当看到uid的时候，就在脑袋里想一想“login”。 　　请注意CN有多个值。就象上面介绍的，LDAP允许某些属性有多个值。为什么允许有多个值呢？假定你在用公司的LDAP服务器查找Fran的电话号码。你可能只知道她的名字叫Fran，但是对人力资源处的人来说她的正式名字叫做Frances。因为保存了她的两个名字，所以用任何一个名字检索都可以找到Fran的电话号码、电子邮件和办公房间号，等等。 　　mailRoutingAddress: fsmith@foobar点com 　　mailhost: mail.foobar点com 　　就象现在大多数的公司都上网了，Foobar用Sendmail发送邮件和处理外部邮件路由信息。Foobar把所有用户的邮件信息都存在LDAP中。最新版本的Sendmail支持这项功能。 　　Userpassword: {crypt}3x1231v76T89N 　　uidnumber: 1234 　　gidnumber: 1200 　　gecos: Frances Smith 　　homedirectory: /home/fsmith 　　loginshell: /usr/local/bin/bash 　　注意，Foobar的系统管理员把所有用户的口令映射信息也都存在LDAP中。FoobarPerson类型的对象具有这种能力。再注意一下，用户口令是用UNIX的口令加密格式存储的。UNIX的uid在这里为uidnumber。提醒你一下，关于如何在LDAP中保存NIS信息，有完整的一份RFC。在以后的文章中我会谈一谈NIS的集成。 　　LDAP复制 　　LDAP服务器可以使用基于“推”或者“拉”的技术，用简单或基于安全证书的安全验证，复制一部分或者所有的数据。 　　例如，Foobar有一个“公用的”LDAP服务器，地址为ldap.foobar点com，端口为389。Netscape Communicator的电子邮件查询功能、UNIX的“ph”命令要用到这个服务器，用户也可以在任何地方查询这个服务器上的员工和客户联系信息。公司的主LDAP服务器运行在相同的计算机上，不过端口号是1389。 　　你可能即不想让员工查询资产管理或食谱的信息，又不想让信息技术人员看到整个公司的LDAP目录。为了解决这个问题，Foobar有选择地把子目录树从主LDAP服务器复制到“公用”LDAP服务器上，不复制需要隐藏的信息。为了保持数据始终是最新的，主目录服务器被设置成即时“推”同步。这些种方法主要是为了方便，而不是安全，因为如果有权限的用户想查询所有的数据，可以用另一个LDAP端口。 　　假定Foobar通过从奥克兰到欧洲的低带宽数据的连接用LDAP管理客户联系信息。可以建立从ldap.foobar点com:1389到munich-ldap.foobar点com:389的数据复制，象下面这样： 　　periodic pull: ou=asia,ou=customers,o=sendmail点com 　　periodic pull: ou=us,ou=customers,o=sendmail点com 　　immediate push: ou=europe,ou=customers,o=sendmail点com 　　“拉”连接每15分钟同步一次，在上面假定的情况下足够了。“推”连接保证任何欧洲的联系信息发生了变化就立即被“推”到Munich。 　　用上面的复制模式，用户为了访问数据需要连接到哪一台服务器呢？在Munich的用户可以简单地连接到本地服务器。如果他们改变了数据，本地的LDAP服务器就会把这些变化传到主LDAP服务器。然后，主LDAP服务器把这些变化“推”回本地的“公用”LDAP服务器保持数据的同步。这对本地的用户有很大的好处，因为所有的查询（大多数是读）都在本地的服务器上进行，速度非常快。当需要改变信息的时候，最终用户不需要重新配置客户端的软件，因为LDAP目录服务器为他们完成了所有的数据交换工作。

编辑本段LDAP诠释

PART1

　　1.1. LDAP是什么 　　LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。它是基于X.500标准的，但是简单多了并且可以根据需要定制。与X.500不同，LDAP支持TCP/IP，这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。 　　简单说来，LDAP是一个得到关于人或者资源的集中、静态数据的快速方式。 　　LDAP是一个用来发布目录信息到许多不同资源的协议。通常它都作为一个集中的地址本使用，不过根据组织者的需要，它可以做得更加强大。 　　1.2. LDAP是电话簿 　　LDAP其实是一电话簿，类似于我们所使用诸如NIS(Network Information Service)、DNS (Domain Name Service)等网络目录，也类似于你在花园中所看到的树木。 　　1.3. LDAP是不是数据库 　　不少LDAP开发人员喜欢把LDAP与关系数据库相比，认为是另一种的存贮方式，然后在读性能上进行比较。实际上，这种对比的基础是错误的。LDAP和关系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网格数据库，对象数据库），前者是存贮模式和访问协议。LDAP是一个比关系数据库抽象层次更高的存贮概念，与关系数据库的查询语言SQL属同一级别。LDAP最基本的形式是一个连接数据库的标准方式。该数据库为读查询作了优化。因此它可以很快地得到查询结果，不过在其它方面，例如更新，就慢得多。 　　从另一个意义上 LDAP是实现了指定的数据结构的存贮，它是一种特殊的数据库。但是LDAP和一般的数据库不同，明白这一点是很重要的。 LDAP对查询进行了优化，与写性能相比LDAP的读性能要优秀很多。 　　就象Sybase、Oracle、Informix或Microsoft的数据库管理系统（DBMS）是用于处理查询和更新关系型数据库那样，LDAP服务器也是用来处理查询和更新LDAP目录的。换句话来说LDAP目录也是一种类型的数据库，但不是关系型数据库。要特别注意的是，LDAP通常作为一个hierarchal数据库使用，而不是一个关系数据库。因此，它的结构用树来表示比用表格好。正因为这样，就不能用SQL语句了。

PART2

　　2. LDAP的特点 　　2.1. LDAP的优势 　　2.1.1 跨平台 　　LDAP最大的优势是：可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。 　　LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持，因为他们根本不用考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开放源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是，如果软件产商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务器单独定制。 　　2.1.2 费用及维护 　　不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费。 　　大多数的LDAP服务器安装起来很简单，也容易维护和优化。 　　2.1.3 复制技术 　　LDAP服务器可以用”推”或”拉”的方法复制部分或全部数据，例如：可以把数据”推”到远程的办公室，以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能，数据库产商就会要你支付额外的费用，而且也很难管理。 　　2.1.4 允许使用ACI 　　LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。 　　2.2. LDAP存储什么数据 　　LDAP对于这样存储这样的信息最为有用：也就是数据需要从不同的地点读取，但是不需要经常更新。例如，这些信息存储在LDAP目录中是十分有效的： 　　l 公司员工的电话号码簿和组织结构图 　　l 客户的联系信息 　　l 计算机管理需要的信息，包括NIS映射、email假名，等等 　　l 软件包的配置信息 　　l 公用证书和安全密匙 　　2.3. 什么时候该用LDAP存储数据 　　大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此，当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化，大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据。例如，用LDAP服务器来存储电话号码是一个很好的选择，但是它不能作为电子商务站点的数据库服务器。 　　如果下面每一个问题的答案都是”是”，那么把数据存在LDAP中就是一个好主意。 　　l 需要在任何平台上都能读取数据吗？ 　　l 每一个单独的记录项是不是每一天都只有很少的改变？ 　　l 可以把数据存在平面数据库（flat database）而不是关系型数据库中吗？换句话来说，也就是不管什么范式不范式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。 　　最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。例如，一条公司员工的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法：如果可以把保数据存在一张张的卡片里，就可以很容易地把它存在LDAP目录里。

PART3

　　3. LDAP的基本模型 　　3.1 信息模型：描述LDAP的信息表示方式 　　在LDAP中信息以树状方式组织，在树状信息中的基本数据单元是条目，而每个条目由属性构成，属性中存储有属性值；LDAP中的信息模式，类似于面向对象的概念，在LDAP中每个条目必须属于某个或多个对象类（Object Class），每个Object Class由多个属性类型组成，每个属性类型有所对应的语法和匹配规则；对象类和属性类型的定义均可以使用继承的概念。每个条目创建时，必须定义所属的对象类，必须提供对象类中的必选属性类型的属性值，在LDAP中一个属性类型可以对应多个值。 　　在LDAP中把对象类、属性类型、语法和匹配规则统称为Schema，在LDAP中有许多系统对象类、属性类型、语法和匹配规则，这些系统Schema在LDAP标准中进行了规定，同时不同的应用领域也定义了自己的Schema，同时用户在应用时，也可以根据需要自定义Schema。这有些类似于XML，除了XML标准中的XML定义外，每个行业都有自己标准的DTD或DOM定义，用户也可以自扩展；也如同XML，在LDAP中也鼓励用户尽量使用标准的Schema，以增强信息的互联互通。 　　在Schema中最难理解的是匹配规则，这是LDAP中为了加快查询的速度，针对不同的数据类型，可以提供不同的匹配方法，如针对字符串类型的相等、模糊、大于小于均提供自己的匹配规则。 　　3.2 命名模型：描述LDAP中的数据如何组织 　　LDAP中的命名模型，也即LDAP中的条目定位方式。在LDAP中每个条目均有自己的DN和RDN。DN是该条目在整个树中的唯一名称标识，RDN是条目在父节点下的唯一名称标识，如同文件系统中，带路径的文件名就是DN，文件名就是RDN。 　　3.3 功能模型：描述LDAP中的数据操作访问 　　在LDAP中共有四类10种操作：查询类操作，如搜索、比较；更新类操作，如添加条目、删除条目、修改条目、修改条目名；认证类操作，如绑定、解绑定；其它操作，如放弃和扩展操作。除了扩展操作，另外9种是LDAP的标准操作；扩展操作是LDAP中为了增加新的功能，提供的一种标准的扩展框架，当前已经成为LDAP标准的扩展操作，有修改密码和StartTLS扩展，在新的RFC标准和草案中正在增加一些新的扩展操作，不同的LDAP厂商也均定义了自己的扩展操作。 　　3.4 安全模型：描述LDAP中的安全机制 　　LDAP中的安全模型主要通过身份认证、安全通道和访问控制来实现。 　　3.4.1 身份认证 　　在LDAP中提供三种认证机制，即匿名、基本认证和SASL（Simple Authentication and Secure Layer）认证。匿名认证即不对用户进行认证，该方法仅对完全公开的方式适用；基本认证均是通过用户名和密码进行身份识别，又分为简单密码和摘要密码认证；SASL认证即LDAP提供的在SSL和TLS安全通道基础上进行的身份认证，包括数字证书的认证。 　　3.4.2 通讯安全 　　在LDAP中提供了基于SSL/TLS的通讯安全保障。SSL/TLS是基于PKI信息安全技术，是目前Internet上广泛采用的安全服务。LDAP通过StartTLS方式启动TLS服务，可以提供通讯中的数据保密性、完整性保护；通过强制客户端证书认证的TLS服务，同时可以实现对客户端身份和服务器端身份的双向验证。 　　3.4.3 访问控制 　　虽然LDAP目前并无访问控制的标准，但从一些草案中或是事实上LDAP产品的访问控制情况，我们不难看出：LDAP访问控制异常的灵活和丰富，在LDAP中是基于访问控制策略语句来实现访问控制的，这不同于现有的关系型数据库系统和应用系统，它是通过基于访问控制列表来实现的，无论是基于组模式或角色模式，都摆脱不了这种限制。 　　在使用关系型数据库系统开发应用时，往往是通过几个固定的数据库用户名访问数据库。对于应用系统本身的访问控制，通常是需要建立专门的用户表，在应用系统内开发针对不同用户的访问控制授权代码，这样一旦访问控制策略变更时，往往需要代码进行变更。总之一句话，关系型数据库的应用中用户数据管理和数据库访问标识是分离的，复杂的数据访问控制需要通过应用来实现。 　　而对于LDAP，用户数据管理和访问标识是一体的，应用不需要关心访问控制的实现。这是由于在LDAP中的访问控制语句是基于策略语句来实现的，无论是访问控制的数据对象，还是访问控制的主体对象，均是与这些对象在树中的位置和对象本身的数据特征相关。 　　在LDAP中，可以把整个目录、目录的子树、制定条目、特定条目属性集或符合某过滤条件的条目作为控制对象进行授权；可以把特定用户、属于特定组或所有目录用户作为授权主体进行授权；最后，还可以定义对特定位置（例如IP地址或DNS名称）的访问权。 　　4. LDAP数据结构

PART4

　　LDAP是实现了指定的数据结构的存贮，它包括以下可以用关系数据库实现的结构要求：树状组织、条目认证、类型定义、许可树形记录拷贝。 　　4.1 树状组织 　　无论是X500还是LDAP都是采用树状方式进行记录。每一个树目录都有一个树根的入口条目，子记录全部是这一根条目的子孙。这是目录与关系数据类型最大的区别（关系数据库的应用结构也可实现树状记录）。因此，把目录看作是更高级的树状数据库也未尝不可，只不过除此外，它不能实现关系存贮的重要功能。 　　4.2 条目和条目认证 　　LDAP是以条目作为认证的根据。ROOT的权限认证与目录本身无关，但除此外所有条目的认证权限由条目本身的密码进行认证。LDAP可以配置成各种各样不同的父子条目权限继承方式。 　　每一个条目相当于一个单一的平面文本记录，由条目自身或指定的条目认证进行访问控制。因此，LDAP定义的存贮结构等同于一批树状组织的平面数据库，并提供相应的访问控制。 　　条目中的记录以名-值对的形式存在，每一个名值对必须由数据样式schema预定义。因此，LDAP可以看作是以规定的值类型以名值对形式存贮在一系列以树状组织的平面数据库的记录的集合。 　　4.3 数据样式（schema） 　　数据样式schema是针对不同的应用，由用户指定（设计）类和属性类型预定义，条目中的类(objectclass)和属性必须在在LDAP服务器启动时载入内存的schema已有定义。因此，AD活动目录中的条目记录就必须符合Active Directory的schema中。如果已提供的schema中的定义不够用，用户可以自行定义新的schema. 　　在http://ldap.akbkhome点com/index.php中可以看到常用的schema。 　　4.4 对象类型(objectClass) 　　因为LDAP目录可以定制成存储任何文本或二进制数据，到底存什么要由你自己决定。LDAP目录用对象类型（objectclass）的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中，你都要根据自己的需要扩展基本的LDAP目录的功能，创建新的对象类型或者扩展现存的对象类型。 　　条目中的记录通过objectclass实现分类，objectClass是一个继承性的类定义，每一个类定义指定必须具备的属性。如某一条目指定必须符合某个类型，则它必须具备超类所指定的属性。 　　通过objectclass分类，分散的条目中的记录就实际上建立了一个索引结构，为高速的读查询打下了基础。Objectclass也是过滤器的主要查询对象。 　　4.5 过滤器和语法 　　LDAP是一个查询为主的记录结构，无论是何种查询方式，最终都由过滤器缺点查询的条件。过滤器相当于SQL中的WHERE子句。任何LDAP的类过滤和字符串都必须放在括号内，如（objectclass=*）,指列出所有类型的记录（不过分类）。 　　可以使用=，>=，<=，~=（约等于）进行比较，如(number<=100)。合并条件是最怪的，必须把操作符放在两个操作对象的前面而不是中间，单一操作对象用括号括起来。如 　　l A与B，不是A&B，而是（&(A)(B)）。 　　l 或使用”|”表示； 　　l 非使用”！”表示。 　　l 对于”与”，或”或”在操作符后可以跟多个条件表达式，但非后则只参是单个表达式。 　　详见RFC1558。 　　4.6 树移植 　　LDAP最重要的特性和要求并不是读性能，而是扩展性。这一特性是通过树移植和树复制实现的。按LDAP的RFC要求，LDAP目录应该可以任意地在不同的目录间连接、合并并实现自动复制，及自动性同步。这意味着用户可以在任一LDAP中访问条目，而不用管其中某一部分是否复制自全世界另一目录中的记录，同时另一目录中的记录同样在正常运作。 　　这一特性如果在关系数据库中实现，意味着要使用程序化的非规范化预复制。类似于汇总帐目的设计。 　　4.7 LDIF交换文件 　　LDIF是LDAP约定的记录交换格式，以平面文本的形式存在，是大部分LDAP内容交换的基础，如拷贝、添加、修改等操作，都是基于LDIF文件进行操作。 　　4.8 JAVA或CORBA对象串行化存储 　　网络高效率的访问加上JAVA的跨平台能力，当把JAVA或CORBA对象串行化后存储到LDAP目录上时，可以产生非同一般的集成效果–实际上，这正是EJB和.NET的网络定位基础技术。 　　使用JAVA或CORBA对象存储时，必须首先让LDAP服务支持该对象定义，也就是说包含qmail.schema或corba.schema。 　　JAVA必须存储在objectclass=javacontainer的条目中，而且必须带有cn属性，这意味着除非该JAVA类专门实现了DirContext接口，对于大多数JAVA类来说，只能采用DirContext代替Context实现bind的添加操作。取出JAVA类相对要简单得多，只需使用context.lookup()获得该对象的句柄，然后强制造型成所需要的对象就可以了,如： 　　Person p=(Person)contex.lookup(“cn=elvis,dc=daifu,dc=com”); 　　这个句法在EJB的程序中，是经常用到的。 　　使用CORBA的跨语言性质，使用CORBA存储对象比JAVA更加诱人，这意味着所存储的对象可以被任何语言编写的客户端访问。其实，微软的.net说到底也非常简单，无非是把COM对象存储到微软自家的目录ActiveDirectory里面，从而可以在网络范围内使用任何微软平台的语言进行对象访问而已。众所周知，COM就是与CORBA相对的微软规范。 　　使用对象串行化技术，可以把常用对象如某个打印机，某个客户直接存储到LDAP中，然后快速获取该对象的引用，这样，就比把对象信息存储到关系数据库中，分别取出属性，然后再初始化对象操作的做法，效率要高得多了。这是LDAP目前比普通关系数据库存储要优秀的地方，而对象数据库还不成熟。

编辑本段LDAP协议常见的命名格式

　　LDAP协议中采用的命名格式， 因为我们需要通过名字信息访问目录对象，所以名字格式对于用户或者应用程序非常重要。活动目录支持大多数的名字格式类型。较为常用的格式有以下两种：

（1）RFC822命名法

　　这种命名法的标准格式为：object_name@domain_name，形式非常类似于电子邮件地址，比如Myname@mydomain点com。活动目录为所有的用户提供了这种式的好名字，所以用户可以直接使用该友好名字当作电子邮件地址，也可以用作登录系统时的账户名。

（2）LDAP URL 和X.500名字

　　任何一个支持LDAP 的客户都可以利用LDAP名通过LDAP 协议访问活动目录，LDAP 名不像普通的Internet URL 名字那么直观，但是LDAP 名往往隐藏在 应用系统的内部，最终用户很少直接使用LDAP 名。LDAP 名使用X.500 命名规 范，也称为属性化命名法，包括活动目录服务所在的服务器以及对象的属性信息。 详细信息

LDAP简介

　　简单说来，LDAP是一个得到关于人或者资源的集中、静态数据的快速方式。

　　LDAP是一个用来发布目录信息到许多不同资源的协议。通常它都作为一个集中的地址本使用，不过根据组织者的需要，它可以做得更加强大。

　　LDAP最新的rfc规范文档时RFC 4511 Lightweight Directory Access Protocol (LDAP): The Protocol

LDAP的实质

　　LDAP其实是一电话簿，类似于我们所使用诸如NIS(Network Information Service)、DNS (Domain Name Service)等网络目录，也类似于你在花园中所看到的树木。

　　不少LDAP开发人员喜欢把LDAP与关系数据库相比，认为是另一种的存贮方式，然后在读性能上进行比较。实际上，这种对比的基础是错误的。LDAP和关系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网格数据库，对象数据库），前者是存贮模式和访问协议。LDAP是一个比关系数据库抽象层次更高的存贮概念，与关系数据库的查询语言SQL属同一级别。LDAP最基本的形式是一个连接数据库的标准方式。该数据库为读查询作了优化。因此它可以很快地得到查询结果，不过在其它方面，例如更新，就慢得多。

特殊的数据库

　　从另一个意义上 LDAP是实现了指定的数据结构的存贮，它是一种特殊的数据库。但是LDAP和一般的数据库不同，明白这一点是很重要的。 LDAP对查询进行了优化，与写性能相比LDAP的读性能要优秀很多。

　　就象Sybase、Oracle、Informix或Microsoft的数据库管理系统（DBMS）是用于处理查询和更新关系型数据库那样，LDAP服务器也是用来处理查询和更新LDAP目录的。换句话来说LDAP目录也是一种类型的数据库，但不是关系型数据库。要特别注意的是，LDAP通常作为一个 hierarchical数据库使用，而不是一个关系数据库。因此，它的结构用树来表示比用表格好。正因为这样，就不能用SQL语句了。

　　现在LDAP技术发展得很快令人激动人心。在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应用程序从LDAP目录中获取信息。LDAP目录中可以存储各种类型的数据：电子邮件地址、邮件路由信息、人力资源数据、公用密匙、联系人列表，等等。通过把LDAP目录作为系统集成中的一个重要环节，可以简化员工在企业内部查询信息的步骤，甚至连主要的数据源都可以放在任何地方。

编辑本段LDAP目录的优势

开发的方式

　　如果需要开发一种提供公共信息查询的系统一般的设计方法可能是采用基于WEB的数据库设计方式，即前端使用浏览器而后端使用WEB服务器加上关系数据库。后端在Windows的典型实现可能是Windows NT + IIS + Acess数据库或者是SQL SERVER，IIS和数据库之间通过ASP技术使用ODBC进行连接，达到通过填写表单查询数据的功能；

Linux的典型

　　后端在Linux系统的典型实现可能是Linux+ Apache + postgresql，Apache和数据库之间通过PHP3提供的函数进行连接。使用上述方法的缺点是后端关系数据库的引入导致系统整体的性能降低和系统的管理比较繁琐，因为需要不断的进行数据类型的验证和事务的完整性的确认；并且前端用户对数据的控制不够灵活，用户权限的设置一般只能是设置在表一级而不是设置在记录一级。

　　目录服务的推出主要是解决上述数据库中存在的问题。目录与关系数据库相似，是指具有描述性的基于属性的记录集合，但它的数据类型主要是字符型，为了检索的需要添加了BIN（二进制数据）、CIS（忽略大小写）、CES（大小写敏感）、TEL（电话型）等语法（Syntax），而不是关系数据库提供的整数、浮点数、日期、货币等类型，同样也不提供象关系数据库中普遍包含的大量的函数，它主要面向数据的查询服务（查询和修改操作比一般是大于10:1），不提供事务的回滚（rollback）机制，它的数据修改使用简单的锁定机制实现All-or-Nothing，它的目标是快速响应和大容量查询并且提供多目录服务器的信息复制功能。

　　现在该说说LDAP目录到底有些什么优势了。现在LDAP的流行是很多因素共同作用的结果。可能LDAP最大的优势是：可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。

LDAP的协议

　　LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。厂商都很愿意在产品中加入对LDAP的支持，因为他们根本不用考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开放源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是，如果软件厂商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务器单独定制。不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费。大多数的LDAP服务器安装起来很简单，也容易维护和优化。

LDAP的服务器

　　LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据，例如：可以把数据“推”到远程的办公室，以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能，数据库产商就会要你支付额外的费用，而且也很难管理。

LDAP的使用权限

　　LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。

　　LDAP（Lightweight Directory Acess Protocol）是目录服务在TCP/IP上的实现（RFC 1777 V2版和RFC 2251 V3版）。它是对X500的目录协议的移植，但是简化了实现方法，所以称为轻量级的目录服务。在LDAP中目录是按照树型结构组织，目录由条目（Entry）组成，条目相当于关系数据库中表的记录；条目是具有区别名DN（Distinguished Name）的属性（Attribute）集合，DN相当于关系数据库表中的关键字（Primary

　　Key）；属性由类型（Type）和多个值（Values）组成，相当于关系数据库中的域（Field）由域名和数据类型组成，只是为了方便检索的需要，LDAP中的Type可以有多个Value，而不是关系数据库中为降低数据的冗余性要求实现的各个域必须是不相关的。LDAP中条目的组织一般按照地理位置和组织关系进行组织，非常的直观。LDAP把数据存放在文件中，为提高效率可以使用基于索引的文件数据库，而不是关系数据库。LDAP协议集还规定了DN的命名方法、存取控制方法、搜索格式、复制方法、URL格式、开发接口等

　　LDAP对于这样存储这样的信息最为有用，也就是数据需要从不同的地点读取，但是不需要经常更新。

　　例如，这些信息存储在LDAP目录中是十分有效的：

　　l 公司员工的电话号码簿和组织结构图

　　l 客户的联系信息

　　l 计算机管理需要的信息，包括NIS映射、email假名，等等

　　l 软件包的配置信息

　　l 公用证书和安全密匙

　　什么时候该用LDAP存储数据

　　大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此，当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化，大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据。例如，用LDAP服务器来存储电话号码是一个很好的选择，但是它不能作为电子商务站点的数据库服务器。

　　如果下面每一个问题的答案都是“是”，那么把数据存在LDAP中就是一个好主意。

　　l 需要在任何平台上都能读取数据吗？

　　l 每一个单独的记录项是不是每一天都只有很少的改变？

　　l 可以把数据存在平面数据库（flat database）而不是关系型数据库中吗？换句话来说，也就是不管什么范式不范式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。

　　最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。例如，一条公司员工的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法：如果可以把数据存在一张张的卡片里，就可以很容易地把它存在LDAP目录里。

安全和访问控制

　　LDAP提供很复杂的不同层次的访问控制或者ACI。因这些访问可以在服务器端控制，这比用客户端的软件保证数据的安全可安全多了。

　　用LDAP的ACI，可以完成：

　　l 给予用户改变他们自己的电话号码和家庭地址的权限，但是限制他们对其它数据（如，职务名称，经理的登录名，等等）只有“只读”权限。

　　l 给予“HR-admins”组中的所有人权限以改变下面这些用户的信息：经理、工作名称、员工号、部门名称和部门号。但是对其它域没有写权限。

　　l 禁止任何人查询LDAP服务器上的用户口令，但是可以允许用户改变他或她自己的口令。

　　l 给予经理访问他们上级的家庭电话的只读权限，但是禁止其他人有这个权限。

　　l 给予“host-admins”组中的任何人创建、删除和编辑所有保存在LDAP服务器中的与计算机主机有关的信息

　　l 通过Web，允许“foobar-sales”组中的成员有选择地给予或禁止他们自己读取一部分客户联系数据的读权限。这将允许他们把客户联系信息下载到本地的笔记本电脑或个人数字助理（PDA）上。（如果销售人员的软件都支持LDAP，这将非常有用）

　　l 通过Web，允许组的所有者删除或添加他们拥有的组的成员。例如：可以允许销售经理给予或禁止销售人员改变Web页的权限。也可以允许邮件假名（mail aliase）的所有者不经过IT技术人员就直接从邮件假名中删除或添加用户。“公用”的邮件列表应该允许用户从邮件假名中添加或删除自己（但是只能是自己）。也可以对IP地址或主机名加以限制。例如，某些域只允许用户IP地址以192.168.200.*开头的有读的权限，或者用户反向查找DNS得到的主机名必须为*.foobar点com。

LDAP目录树的结构

　　LDAP目录以树状的层次结构来存储数据。如果你对自顶向下的DNS树或UNIX文件的目录树比较熟悉，也就很容易掌握LDAP目录树这个概念了。就象DNS的主机名那样，LDAP目录记录的标识名（Distinguished Name，简称DN）是用来读取单个记录，以及回溯到树的顶部。后面会做详细地介绍。

　　为什么要用层次结构来组织数据呢？原因是多方面的。下面是可能遇到的一些情况：

　　l 如果你想把所有的美国客户的联系信息都“推”到位于到西雅图办公室（负责营销）的LDAP服务器上，但是你不想把公司的资产管理信息“推”到那里。

　　l 你可能想根据目录树的结构给予不同的员工组不同的权限。在下面的例子里，资产管理组对“asset-mgmt”部分有完全的访问权限，但是不能访问其它地方。

　　l 把LDAP存储和复制功能结合起来，可以定制目录树的结构以降低对WAN带宽的要求。位于西雅图的营销办公室需要每分钟更新的美国销售状况的信息，但是欧洲的销售情况就只要每小时更新一次就行了。

　　刨根问底：基准DN

　　LDAP目录树的最顶部就是根，也就是所谓的“基准DN”。基准DN通常使用下面列出的三种格式之一。假定我在名为FooBar的电子商务公司工作，这家公司在Internet上的名字是foobar

　　o=”FooBar, Inc.”, c=US

　　（以X.500格式表示的基准DN）

　　在这个例子中，o=FooBar, Inc. 表示组织名，在这里就是公司名的同义词。c=US 表示公司的总部在美国。以前，一般都用这种方式来表示基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着Internet的全球化，在基准DN中使用国家代码很容易让人产生混淆。现在，X.500格式发展成下面列出的两种格式。

　　o=foobar . com

　　（用公司的Internet地址表示的基准DN）

　　这种格式很直观，用公司的域名作为基准DN。这也是现在最常用的格式。

　　dc=foobar, dc=com

　　（用DNS域名的不同部分组成的基准DN）

　　就象上面那一种格式，这种格式也是以DNS域名为基础的，但是上面那种格式不改变域名（也就更易读），而这种格式把域名：foobar点com分成两部分 dc=foobar, dc=com。在理论上，这种格式可能会更灵活一点，但是对于最终用户来说也更难记忆一点。考虑一下foobar点com这个例子。当foobar点com和gizmo点com合并之后，可以简单的把“dc=com”当作基准DN。把新的记录放到已经存在的dc=gizmo, dc=com目录下，这样就简化了很多工作（当然，如果foobar点com和wocket点edu合并，这个方法就不能用了）。如果LDAP服务器是新安装的，我建议你使用这种格式。再请注意一下，如果你打算使用活动目录（Actrive Directory），Microsoft已经限制你必须使用这种格式。

在目录树中怎么组织数据

　　在UNIX文件系统中，最顶层是根目录（root）。在根目录的下面有很多的文件和目录。象上面介绍的那样，LDAP目录也是用同样的方法组织起来的。

　　在根目录下，要把数据从逻辑上区分开。因为历史上（X.500）的原因，大多数LDAP目录用OU从逻辑上把数据分开来。OU表示“Organization Unit”，在X.500协议中是用来表示公司内部的机构：销售部、财务部，等等。现在LDAP还保留ou=这样的命名规则，但是扩展了分类的范围，可以分类为：ou=people, ou=groups, ou=devices，等等。更低一级的OU有时用来做更细的归类。例如：LDAP目录树（不包括单独的记录）可能会是这样的：

　　dc=foobar, dc=com

　　ou=customers

　　ou=asia

　　ou=europe

　　ou=usa

　　ou=employees

　　ou=rooms

　　ou=groups

　　ou=assets-mgmt

　　ou=nisgroups

　　ou=recipes

单独的LDAP记录

　　DN是LDAP记录项的名字

　　在LDAP目录中的所有记录项都有一个唯一的“Distinguished Name”，也就是DN。每一个LDAP记录项的DN是由两个部分组成的：相对DN（RDN）和记录在LDAP目录中的位置。

　　RDN是DN中与目录树的结构无关的部分。在LDAP目录中存储的记录项都要有一个名字，这个名字通常存在cn（Common Name）这个属性里。因为几乎所有的东西都有一个名字，在LDAP中存储的对象都用它们的cn值作为RDN的基础。如果我把最喜欢的吃燕麦粥食谱存为一个记录，我就会用cn=Oatmeal Deluxe作为记录项的RDN。

　　l 我的LDAP目录的基准DN是dc=foobar,dc=com

　　l 我把自己的食谱作为LDAP的记录项存在ou=recipes

　　l 我的LDAP记录项的RDN设为cn=Oatmeal Deluxe

　　上面这些构成了燕麦粥食谱的LDAP记录的完整DN。记住，DN的读法和DNS主机名类似。下面就是完整的DN：

　　cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com

　　举一个实际的例子来说明DN

　　现在为公司的员工设置一个DN。可以用基于cn或uid（User ID），作为典型的用户帐号。例如，FooBar的员工Fran Smith（登录名：fsmith）的DN可以为下面两种格式：

　　uid=fsmith,ou=employees,dc=foobar,dc=com

　　（基于登录名）

　　LDAP（以及X.500）用uid表示“User ID”，不要把它和UNIX的uid号混淆了。大多数公司都会给每一个员工唯一的登录名，因此用这个办法可以很好地保存员工的信息。你不用担心以后还会有一个叫Fran Smith的加入公司，如果Fran改变了她的名字（结婚？离婚？或宗教原因？），也用不着改变LDAP记录项的DN。

　　cn=Fran Smith,ou=employees,dc=foobar,dc=com

　　（基于姓名）

　　可以看到这种格式使用了Common Name（CN）。可以把Common Name当成一个人的全名。这种格式有一个很明显的缺点就是：如果名字改变了，LDAP的记录就要从一个DN转移到另一个DN。但是，我们应该尽可能地避免改变一个记录项的DN。

定制目录的对象类型

　　你可以用LDAP存储各种类型的数据对象，只要这些对象可以用属性来表示，下面这些是可以在LDAP中存储的一些信息：

　　l 员工信息：员工的姓名、登录名、口令、员工号、他的经理的登录名，邮件服务器，等等。

　　l 物品跟踪信息：计算机名、IP地址、标签、型号、所在位置，等等。

　　l 客户联系列表：客户的公司名、主要联系人的电话、传真和电子邮件，等等。

　　l 会议厅信息：会议厅的名字、位置、可以坐多少人、电话号码、是否有投影机。

　　l 食谱信息：菜的名字、配料、烹调方法以及准备方法。

　　因为LDAP目录可以定制成存储任何文本或二进制数据，到底存什么要由你自己决定。LDAP目录用对象类型（object classes）的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中，你都要根据自己的需要扩展基本的LDAP目录的功能，创建新的对象类型或者扩展现存的对象类型。

　　LDAP目录以一系列“属性对”的形式来存储记录项，每一个记录项包括属性类型和属性值（这与关系型数据库用行和列来存取数据有根本的不同）。下面是我存在LDAP目录中的一部分食谱记录：

　　dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com

　　cn: Instant Oatmeal Deluxe

　　recipeCuisine: breakfast

　　recipeIngredient: 1 packet instant oatmeal

　　recipeIngredient: 1 cup water

　　recipeIngredient: 1 pinch salt

　　recipeIngredient: 1 tsp brown sugar

　　recipeIngredient: 1/4 apple, any type

　　请注意上面每一种配料都作为属性recipeIngredient值。LDAP目录被设计成象上面那样为一个属性保存多个值的，而不是在每一个属性的后面用逗号把一系列值分开。

　　因为用这样的方式存储数据，所以数据库就有很大的灵活性，不必为加入一些新的数据就重新创建表和索引。更重要的是，LDAP目录不必花费内存或硬盘空间处理“空”域，也就是说，实际上不使用可选择的域也不会花费你任何资源。

示例

　　作为例子的一个单独的数据项

　　让我们看看下面这个例子。我们用Foobar, Inc.的员工Fran Smith的LDAP记录。这个记录项的格式是LDIF，用来导入和导出LDAP目录的记录项。

　　dn: uid=fsmith, ou=employees, dc=foobar, dc=com

　　objectclass: person

　　objectclass: organizationalPerson

　　objectclass: inetOrgPerson

　　objectclass: foobarPerson

　　uid: fsmith

　　givenname: Fran

　　sn: Smith

　　cn: Fran Smith

　　cn: Frances Smith

　　telephonenumber: 510-555-1234

　　roomnumber: 122G

　　o: Foobar, Inc.

　　mailRoutingAddress: fsmith@foobar点com

　　mailhost: mail.foobar点com

　　userpassword: {crypt}3x1231v76T89N

　　uidnumber: 1234

　　gidnumber: 1200

　　homedirectory: /home/fsmith

　　loginshell: /usr/local/bin/bash

　　属性的值在保存的时候是保留大小写的，但是在默认情况下搜索的时候是不区分大小写的。某些特殊的属性（例如，password）在搜索的时候需要区分大小写。

　　让我们一点一点地分析上面的记录项。

　　dn: uid=fsmith, ou=employees, dc=foobar, dc=com

　　这是Fran的LDAP记录项的完整DN，包括在目录树中的完整路径。LDAP（和X.500）使用uid（User ID），不要把它和UNIX的uid号混淆了。

　　objectclass: person

　　objectclass: organizationalPerson

　　objectclass: inetOrgPerson

　　objectclass: foobarPerson

　　可以为任何一个对象根据需要分配多个对象类型。person对象类型要求cn（common name）和sn（surname）这两个域不能为空。persion对象类型允许有其它的可选域，包括givenname、telephonenumber，等等。organizational Person给person加入更多的可选域，inetOrgPerson又加入更多的可选域（包括电子邮件信息）。最后，foobarPerson是为Foobar定制的对象类型，加入了很多定制的属性。

　　uid: fsmith

　　givenname: Fran

　　sn: Smith

　　cn: Fran Smith

　　cn: Frances Smith

　　telephonenumber: 510-555-1234

　　roomnumber: 122G

　　o: Foobar, Inc.

　　以前说过了，uid表示User ID。当看到uid的时候，就在脑袋里想一想“login”。

　　请注意CN有多个值。就象上面介绍的，LDAP允许某些属性有多个值。为什么允许有多个值呢？假定你在用公司的LDAP服务器查找Fran的电话号码。你可能只知道她的名字叫Fran，但是对人力资源处的人来说她的正式名字叫做Frances。因为保存了她的两个名字，所以用任何一个名字检索都可以找到Fran的电话号码、电子邮件和办公房间号，等等。

　　mailRoutingAddress: fsmith@foobar点com

　　mailhost: mail.foobar点com

　　就象现在大多数的公司都上网了，Foobar用Sendmail发送邮件和处理外部邮件路由信息。Foobar把所有用户的邮件信息都存在LDAP中。最新版本的Sendmail支持这项功能。

　　Userpassword: {crypt}3x1231v76T89N

　　uidnumber: 1234

　　gidnumber: 1200

　　gecos: Frances Smith

　　homedirectory: /home/fsmith

　　loginshell: /usr/local/bin/bash

　　注意，Foobar的系统管理员把所有用户的口令映射信息也都存在LDAP中。FoobarPerson类型的对象具有这种能力。再注意一下，用户口令是用UNIX的口令加密格式存储的。UNIX的uid在这里为uidnumber。提醒你一下，关于如何在LDAP中保存NIS信息，有完整的一份RFC。在以后的文章中我会谈一谈NIS的集成。

　　LDAP复制

　　LDAP服务器可以使用基于“推”或者“拉”的技术，用简单或基于安全证书的安全验证，复制一部分或者所有的数据。

　　例如，Foobar有一个“公用的”LDAP服务器，地址为ldap.foobar点com，端口为389。Netscape Communicator的电子邮件查询功能、UNIX的“ph”命令要用到这个服务器，用户也可以在任何地方查询这个服务器上的员工和客户联系信息。公司的主LDAP服务器运行在相同的计算机上，不过端口号是1389。

　　你可能即不想让员工查询资产管理或食谱的信息，又不想让信息技术人员看到整个公司的LDAP目录。为了解决这个问题，Foobar有选择地把子目录树从主LDAP服务器复制到“公用”LDAP服务器上，不复制需要隐藏的信息。为了保持数据始终是最新的，主目录服务器被设置成即时“推”同步。这些种方法主要是为了方便，而不是安全，因为如果有权限的用户想查询所有的数据，可以用另一个LDAP端口。

　　假定Foobar通过从奥克兰到欧洲的低带宽数据的连接用LDAP管理客户联系信息。可以建立从ldap.foobar点com:1389到munich-ldap.foobar点com:389的数据复制，象下面这样：

　　periodic pull: ou=asia,ou=customers,o=sendmail点com

　　periodic pull: ou=us,ou=customers,o=sendmail点com

　　immediate push: ou=europe,ou=customers,o=sendmail点com

　　“拉”连接每15分钟同步一次，在上面假定的情况下足够了。“推”连接保证任何欧洲的联系信息发生了变化就立即被“推”到Munich。

　　用上面的复制模式，用户为了访问数据需要连接到哪一台服务器呢？在Munich的用户可以简单地连接到本地服务器。如果他们改变了数据，本地的LDAP服务器就会把这些变化传到主LDAP服务器。然后，主LDAP服务器把这些变化“推”回本地的“公用”LDAP服务器保持数据的同步。这对本地的用户有很大的好处，因为所有的查询（大多数是读）都在本地的服务器上进行，速度非常快。当需要改变信息的时候，最终用户不需要重新配置客户端的软件，因为LDAP目录服务器为他们完成了所有的数据交换工作。

编辑本段LDAP诠释

PART1

　　1.1. LDAP是什么

　　LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。它是基于X.500标准的，但是简单多了并且可以根据需要定制。与X.500不同，LDAP支持TCP/IP，这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。

　　简单说来，LDAP是一个得到关于人或者资源的集中、静态数据的快速方式。

　　LDAP是一个用来发布目录信息到许多不同资源的协议。通常它都作为一个集中的地址本使用，不过根据组织者的需要，它可以做得更加强大。

　　1.2. LDAP是电话簿

　　LDAP其实是一电话簿，类似于我们所使用诸如NIS(Network Information Service)、DNS (Domain Name Service)等网络目录，也类似于你在花园中所看到的树木。

　　1.3. LDAP是不是数据库

　　不少LDAP开发人员喜欢把LDAP与关系数据库相比，认为是另一种的存贮方式，然后在读性能上进行比较。实际上，这种对比的基础是错误的。LDAP和关系数据库是两种不同层次的概念，后者是存贮方式（同一层次如网格数据库，对象数据库），前者是存贮模式和访问协议。LDAP是一个比关系数据库抽象层次更高的存贮概念，与关系数据库的查询语言SQL属同一级别。LDAP最基本的形式是一个连接数据库的标准方式。该数据库为读查询作了优化。因此它可以很快地得到查询结果，不过在其它方面，例如更新，就慢得多。

　　从另一个意义上 LDAP是实现了指定的数据结构的存贮，它是一种特殊的数据库。但是LDAP和一般的数据库不同，明白这一点是很重要的。 LDAP对查询进行了优化，与写性能相比LDAP的读性能要优秀很多。

　　就象Sybase、Oracle、Informix或Microsoft的数据库管理系统（DBMS）是用于处理查询和更新关系型数据库那样，LDAP服务器也是用来处理查询和更新LDAP目录的。换句话来说LDAP目录也是一种类型的数据库，但不是关系型数据库。要特别注意的是，LDAP通常作为一个hierarchal数据库使用，而不是一个关系数据库。因此，它的结构用树来表示比用表格好。正因为这样，就不能用SQL语句了。

PART2

　　2. LDAP的特点

　　2.1. LDAP的优势

　　2.1.1 跨平台

　　LDAP最大的优势是：可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易定制应用程序为它加上LDAP的支持。

　　LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP得到了业界的广泛认可，因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持，因为他们根本不用考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开放源代码或商用的LDAP目录服务器（或者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器进行交互。与LDAP不同的是，如果软件产商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务器单独定制。

　　2.1.2 费用及维护

　　不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费。

　　大多数的LDAP服务器安装起来很简单，也容易维护和优化。

　　2.1.3 复制技术

　　LDAP服务器可以用”推”或”拉”的方法复制部分或全部数据，例如：可以把数据”推”到远程的办公室，以增加数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能，数据库产商就会要你支付额外的费用，而且也很难管理。

　　2.1.4 允许使用ACI

　　LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管理员可以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客户端的应用程序上是否要进行安全检查。

　　2.2. LDAP存储什么数据

　　LDAP对于这样存储这样的信息最为有用：也就是数据需要从不同的地点读取，但是不需要经常更新。例如，这些信息存储在LDAP目录中是十分有效的：

　　l 公司员工的电话号码簿和组织结构图

　　l 客户的联系信息

　　l 计算机管理需要的信息，包括NIS映射、email假名，等等

　　l 软件包的配置信息

　　l 公用证书和安全密匙

　　2.3. 什么时候该用LDAP存储数据

　　大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此，当从LDAP服务器中读取数据的时候会比从专门为OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化，大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据。例如，用LDAP服务器来存储电话号码是一个很好的选择，但是它不能作为电子商务站点的数据库服务器。

　　如果下面每一个问题的答案都是”是”，那么把数据存在LDAP中就是一个好主意。

　　l 需要在任何平台上都能读取数据吗？

　　l 每一个单独的记录项是不是每一天都只有很少的改变？

　　l 可以把数据存在平面数据库（flat database）而不是关系型数据库中吗？换句话来说，也就是不管什么范式不范式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。

　　最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。例如，一条公司员工的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法：如果可以把保数据存在一张张的卡片里，就可以很容易地把它存在LDAP目录里。

PART3

　　3. LDAP的基本模型

　　3.1 信息模型：描述LDAP的信息表示方式

　　在LDAP中信息以树状方式组织，在树状信息中的基本数据单元是条目，而每个条目由属性构成，属性中存储有属性值；LDAP中的信息模式，类似于面向对象的概念，在LDAP中每个条目必须属于某个或多个对象类（Object Class），每个Object Class由多个属性类型组成，每个属性类型有所对应的语法和匹配规则；对象类和属性类型的定义均可以使用继承的概念。每个条目创建时，必须定义所属的对象类，必须提供对象类中的必选属性类型的属性值，在LDAP中一个属性类型可以对应多个值。

　　在LDAP中把对象类、属性类型、语法和匹配规则统称为Schema，在LDAP中有许多系统对象类、属性类型、语法和匹配规则，这些系统Schema在LDAP标准中进行了规定，同时不同的应用领域也定义了自己的Schema，同时用户在应用时，也可以根据需要自定义Schema。这有些类似于XML，除了XML标准中的XML定义外，每个行业都有自己标准的DTD或DOM定义，用户也可以自扩展；也如同XML，在LDAP中也鼓励用户尽量使用标准的Schema，以增强信息的互联互通。

　　在Schema中最难理解的是匹配规则，这是LDAP中为了加快查询的速度，针对不同的数据类型，可以提供不同的匹配方法，如针对字符串类型的相等、模糊、大于小于均提供自己的匹配规则。

　　3.2 命名模型：描述LDAP中的数据如何组织

　　LDAP中的命名模型，也即LDAP中的条目定位方式。在LDAP中每个条目均有自己的DN和RDN。DN是该条目在整个树中的唯一名称标识，RDN是条目在父节点下的唯一名称标识，如同文件系统中，带路径的文件名就是DN，文件名就是RDN。

　　3.3 功能模型：描述LDAP中的数据操作访问

　　在LDAP中共有四类10种操作：查询类操作，如搜索、比较；更新类操作，如添加条目、删除条目、修改条目、修改条目名；认证类操作，如绑定、解绑定；其它操作，如放弃和扩展操作。除了扩展操作，另外9种是LDAP的标准操作；扩展操作是LDAP中为了增加新的功能，提供的一种标准的扩展框架，当前已经成为LDAP标准的扩展操作，有修改密码和StartTLS扩展，在新的RFC标准和草案中正在增加一些新的扩展操作，不同的LDAP厂商也均定义了自己的扩展操作。

　　3.4 安全模型：描述LDAP中的安全机制

　　LDAP中的安全模型主要通过身份认证、安全通道和访问控制来实现。

　　3.4.1 身份认证

　　在LDAP中提供三种认证机制，即匿名、基本认证和SASL（Simple Authentication and Secure Layer）认证。匿名认证即不对用户进行认证，该方法仅对完全公开的方式适用；基本认证均是通过用户名和密码进行身份识别，又分为简单密码和摘要密码认证；SASL认证即LDAP提供的在SSL和TLS安全通道基础上进行的身份认证，包括数字证书的认证。

　　3.4.2 通讯安全

　　在LDAP中提供了基于SSL/TLS的通讯安全保障。SSL/TLS是基于PKI信息安全技术，是目前Internet上广泛采用的安全服务。LDAP通过StartTLS方式启动TLS服务，可以提供通讯中的数据保密性、完整性保护；通过强制客户端证书认证的TLS服务，同时可以实现对客户端身份和服务器端身份的双向验证。

　　3.4.3 访问控制

　　虽然LDAP目前并无访问控制的标准，但从一些草案中或是事实上LDAP产品的访问控制情况，我们不难看出：LDAP访问控制异常的灵活和丰富，在LDAP中是基于访问控制策略语句来实现访问控制的，这不同于现有的关系型数据库系统和应用系统，它是通过基于访问控制列表来实现的，无论是基于组模式或角色模式，都摆脱不了这种限制。

　　在使用关系型数据库系统开发应用时，往往是通过几个固定的数据库用户名访问数据库。对于应用系统本身的访问控制，通常是需要建立专门的用户表，在应用系统内开发针对不同用户的访问控制授权代码，这样一旦访问控制策略变更时，往往需要代码进行变更。总之一句话，关系型数据库的应用中用户数据管理和数据库访问标识是分离的，复杂的数据访问控制需要通过应用来实现。

　　而对于LDAP，用户数据管理和访问标识是一体的，应用不需要关心访问控制的实现。这是由于在LDAP中的访问控制语句是基于策略语句来实现的，无论是访问控制的数据对象，还是访问控制的主体对象，均是与这些对象在树中的位置和对象本身的数据特征相关。

　　在LDAP中，可以把整个目录、目录的子树、制定条目、特定条目属性集或符合某过滤条件的条目作为控制对象进行授权；可以把特定用户、属于特定组或所有目录用户作为授权主体进行授权；最后，还可以定义对特定位置（例如IP地址或DNS名称）的访问权。

　　4. LDAP数据结构

PART4

　　LDAP是实现了指定的数据结构的存贮，它包括以下可以用关系数据库实现的结构要求：树状组织、条目认证、类型定义、许可树形记录拷贝。

　　4.1 树状组织

　　无论是X500还是LDAP都是采用树状方式进行记录。每一个树目录都有一个树根的入口条目，子记录全部是这一根条目的子孙。这是目录与关系数据类型最大的区别（关系数据库的应用结构也可实现树状记录）。因此，把目录看作是更高级的树状数据库也未尝不可，只不过除此外，它不能实现关系存贮的重要功能。

　　4.2 条目和条目认证

　　LDAP是以条目作为认证的根据。ROOT的权限认证与目录本身无关，但除此外所有条目的认证权限由条目本身的密码进行认证。LDAP可以配置成各种各样不同的父子条目权限继承方式。

　　每一个条目相当于一个单一的平面文本记录，由条目自身或指定的条目认证进行访问控制。因此，LDAP定义的存贮结构等同于一批树状组织的平面数据库，并提供相应的访问控制。

　　条目中的记录以名-值对的形式存在，每一个名值对必须由数据样式schema预定义。因此，LDAP可以看作是以规定的值类型以名值对形式存贮在一系列以树状组织的平面数据库的记录的集合。

　　4.3 数据样式（schema）

　　数据样式schema是针对不同的应用，由用户指定（设计）类和属性类型预定义，条目中的类(objectclass)和属性必须在在LDAP服务器启动时载入内存的schema已有定义。因此，AD活动目录中的条目记录就必须符合Active Directory的schema中。如果已提供的schema中的定义不够用，用户可以自行定义新的schema.

　　在http://ldap.akbkhome点com/index.php中可以看到常用的schema。

　　4.4 对象类型(objectClass)

　　因为LDAP目录可以定制成存储任何文本或二进制数据，到底存什么要由你自己决定。LDAP目录用对象类型（objectclass）的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中，你都要根据自己的需要扩展基本的LDAP目录的功能，创建新的对象类型或者扩展现存的对象类型。

　　条目中的记录通过objectclass实现分类，objectClass是一个继承性的类定义，每一个类定义指定必须具备的属性。如某一条目指定必须符合某个类型，则它必须具备超类所指定的属性。

　　通过objectclass分类，分散的条目中的记录就实际上建立了一个索引结构，为高速的读查询打下了基础。Objectclass也是过滤器的主要查询对象。

　　4.5 过滤器和语法

　　LDAP是一个查询为主的记录结构，无论是何种查询方式，最终都由过滤器缺点查询的条件。过滤器相当于SQL中的WHERE子句。任何LDAP的类过滤和字符串都必须放在括号内，如（objectclass=*）,指列出所有类型的记录（不过分类）。

　　可以使用=，>=，<=，~=（约等于）进行比较，如(number<=100)。合并条件是最怪的，必须把操作符放在两个操作对象的前面而不是中间，单一操作对象用括号括起来。如

　　l A与B，不是A&B，而是（&(A)(B)）。

　　l 或使用”|”表示；

　　l 非使用”！”表示。

　　l 对于”与”，或”或”在操作符后可以跟多个条件表达式，但非后则只参是单个表达式。

　　详见RFC1558。

　　4.6 树移植

　　LDAP最重要的特性和要求并不是读性能，而是扩展性。这一特性是通过树移植和树复制实现的。按LDAP的RFC要求，LDAP目录应该可以任意地在不同的目录间连接、合并并实现自动复制，及自动性同步。这意味着用户可以在任一LDAP中访问条目，而不用管其中某一部分是否复制自全世界另一目录中的记录，同时另一目录中的记录同样在正常运作。

　　这一特性如果在关系数据库中实现，意味着要使用程序化的非规范化预复制。类似于汇总帐目的设计。

　　4.7 LDIF交换文件

　　LDIF是LDAP约定的记录交换格式，以平面文本的形式存在，是大部分LDAP内容交换的基础，如拷贝、添加、修改等操作，都是基于LDIF文件进行操作。

　　4.8 JAVA或CORBA对象串行化存储

　　网络高效率的访问加上JAVA的跨平台能力，当把JAVA或CORBA对象串行化后存储到LDAP目录上时，可以产生非同一般的集成效果–实际上，这正是EJB和.NET的网络定位基础技术。

　　使用JAVA或CORBA对象存储时，必须首先让LDAP服务支持该对象定义，也就是说包含qmail.schema或corba.schema。

　　JAVA必须存储在objectclass=javacontainer的条目中，而且必须带有cn属性，这意味着除非该JAVA类专门实现了DirContext接口，对于大多数JAVA类来说，只能采用DirContext代替Context实现bind的添加操作。取出JAVA类相对要简单得多，只需使用context.lookup()获得该对象的句柄，然后强制造型成所需要的对象就可以了,如：

　　Person p=(Person)contex.lookup(“cn=elvis,dc=daifu,dc=com”);

　　这个句法在EJB的程序中，是经常用到的。

　　使用CORBA的跨语言性质，使用CORBA存储对象比JAVA更加诱人，这意味着所存储的对象可以被任何语言编写的客户端访问。其实，微软的.net说到底也非常简单，无非是把COM对象存储到微软自家的目录ActiveDirectory里面，从而可以在网络范围内使用任何微软平台的语言进行对象访问而已。众所周知，COM就是与CORBA相对的微软规范。

　　使用对象串行化技术，可以把常用对象如某个打印机，某个客户直接存储到LDAP中，然后快速获取该对象的引用，这样，就比把对象信息存储到关系数据库中，分别取出属性，然后再初始化对象操作的做法，效率要高得多了。这是LDAP目前比普通关系数据库存储要优秀的地方，而对象数据库还不成熟。

编辑本段LDAP协议常见的命名格式

　　LDAP协议中采用的命名格式， 因为我们需要通过名字信息访问目录对象，所以名字格式对于用户或者应用程序非常重要。活动目录支持大多数的名字格式类型。较为常用的格式有以下两种：

（1）RFC822命名法

　　这种命名法的标准格式为：object_name@domain_name，形式非常类似于电子邮件地址，比如Myname@mydomain点com。活动目录为所有的用户提供了这种式的好名字，所以用户可以直接使用该友好名字当作电子邮件地址，也可以用作登录系统时的账户名。

（2）LDAP URL 和X.500名字

　　任何一个支持LDAP 的客户都可以利用LDAP名通过LDAP 协议访问活动目录，LDAP 名不像普通的Internet URL 名字那么直观，但是LDAP 名往往隐藏在 应用系统的内部，最终用户很少直接使用LDAP 名。LDAP 名使用X.500 命名规 范，也称为属性化命名法，包括活动目录服务所在的服务器以及对象的属性信息。

一些常用快捷键

<Ctrl><Alt><F1>切换到第一个文本终端。在Linux 下你可以有多达六个不同的终端。这个命令的意思是：“同时按住<Ctrl>键和<Alt>键，然后按<F1>键，再释放所有的键”。
<Ctrl><Alt><Fn> (n=1..6)：切换到第n个文本终端。（你也可以使用不是很经常用到的命令chvt n 来实现，n指的是第n个文本终端）。在文本终端下（不是在X窗口）,你也可以简单使用<ALT><Fn>来实现切换，不需要<CTRL>键。打印出你正在使用的终端名称，如果你希望知道终端的名字，可以使用命令fgconsole。
<Ctrl><Alt><F7>：切换到第一个图形用户界面（一般来说X-window在第七个终端）
<Ctrl><Alt><Fn> (n=7到12)：切换到第n个图形用户街面。根据缺省，第一个X-Window在第7个终端运行，从第8到第12什么也没有，当然你可以逐个启动这些图形用户界面。
<Tab>：(在文本终端下）可以使用TAB自动完成命令，或者显示所有的可选项。这个快捷键真的非常好用，经常使用你会发觉它可以节约你很多的时间。
<ArrowUp>：(在文本终端或者X窗口下）滚动和编辑以前输入的命令。按<ENTER>执行一个历史命令。
<ArrowDown>：回滚。
<Shift><PgUp>：滚动终端输出。对于登录提示也起作用，所以你可以使用它回滚启动信息。你显卡的内存大小决定你可以回滚多少内容。
<Shift><PgDown>：回滚终端输出。
<Ctrl><Alt><+>： (在X窗口下) 改变X服务器的屏幕解析率 (如果你设置X服务器有多个不同的屏幕解析率)。比如对于我的标准SVGA卡和显示器，在文件/etc/X11/XF86Config有以下的设置行: （从缺省开始，到可以支持的最大虚拟屏幕解析率）Modes “1024×768″ “800×600″ “640×480″ “512×384″ “480×300″ “400×300″ “1152×864″Z当然，首先我必须设置我的X服务器，可以使用using Xconfigurator, xf86config, 也可以手工编辑文件：/etc/X11/XF86Config。XFdrake (Mandrake使用图形用户界面进行配置 )。你也可以参考命令xvidtune和xvidgen。
<Ctrl><Alt><->：(在X窗口下）把X服务器的屏幕解析率修改到上一次的设置。
<Ctrl><Alt><Esc>：(在X窗口，KDE下）关闭我鼠标将要指向的窗口（鼠标的光标形状会有所改变）。同样的效果也可以使用命令xkill（在X终端上）来实现。当一个程序窗口被挂住的时候特别有用。
<Ctrl><Alt><BkSpc>：(在X窗口下) 终止当前的 X窗口服务。如果X窗口不能正常退出时可以使用。
<Ctrl><Alt><Delete>：(适用于文本终端下）关机和重新启动。这是一个在文本终端下的正常关机命令，千万不要按计算机上的reset键来重新关机和重新启动！
<Ctrl>c：终止当前进程（对于一般的小型文本模式的应用程序）。
<Ctrl>d：(在一个空白的命令行上输入）退出当前的终端。参加下一个命令。
<Ctrl>d：给当前的进程送文件结束符合。不要按两次否则你会把自己退出系统。
<Ctrl>s：停止终端传输。
<Ctrl>q：从新开始终端传输。如果你的终端突然莫名其妙的停止响应，可以参考上一条命令。
<Ctrl>z：把当前进程送到后台处理。
exit：退出系统。我也可以使用logout命令达到同样效果。（如果你启动了第二个shell程序，比如，使用bash，这条命令将使你退出第二个shell回到第一个shell,但是不会退出系统。当然，可以再一次使用exit退出）
reset：恢复崩溃的终端（有些终端显示一些奇怪的字符）到缺省的设置。当你使用cat命令准备显示一个二进制文件时，你可能看不到你所输入的命令，尽管命令仍然照常工作。
< 鼠标的中间键>粘贴当前选择的文本。这是一个常规的Linux“复制－粘贴”操作。它是对被广泛采用的通信用户界面下“复制－粘贴”操作的一个非常有用的扩展（但是它不支持旧版本的NetScape，因为在旧版的NetScape只能使用MAC/Windows风格的“复制－粘贴”操作。如果你运行 “setup”程序进行设置，你可以在文本终端下使用这个功能。而且它在大多数的对话框里也能很好的工作，真的非常方便！）如果你有一个“Linux- Ready”的鼠标（logitec或者其类似产品）或者你通过使用“模拟三键鼠标”，这个功能可以得到最大限度的发挥。一般来说，“第三键”的模拟是通过同时点击左右两个鼠标键来实现。
~(水文符合)：我的主目录（一般来书是/home/我的登录名）。举例，命令~/my_dir将修改我的工作目录到我的主目录的子目录”my_dir”下。相对于输入”cd ~”，你也可以只输入”cd”，我把我的所有文件都放在自己的主目录下。
.(点符号)：当前目录。举例：./my_program 将试图执行当前目录下的”my_program”文件
..(两个点)：到当前的上一级目录（也叫“父目录”）。举个例子，命令“cd..”将修改我的当前工作目录到上一级目录。

一些KDE的快捷键（很有用，但不是非要不可的）

<Alt><Tab>：切换不同的程序窗口。往回切换，使用 <Alt><Shift><Tab>
<Ctrl><Tab>：切换不同的桌面。往回切换，使用 <Ctrl><Shift><Tab>
<Ctrl><Esc>：显示我系统里正在运行的进程列表。允许我终止那些由我启动的进程（或者送信号给这些进程)。
<Alt><F1>：访问K菜单 (对等于微软Windows的的“开始”菜单)。
<Alt><F12>：使用键盘上的箭号键模拟鼠标的操作。
<Alt><鼠标左键>：拖曳并移动一个窗口。一般来说，我通过拖曳窗口的题目栏来移动一个窗口。有些时候，我用它把一个窗口移动到屏幕之外。使用这个功能，我可以把窗口移动到屏幕的任何位置。
<Alt><PrintScreen>：把当前屏幕的快照存到剪贴板。
<Ctrl><Alt><PrintScreen>：把当前桌面的快照存到剪贴板。
<Ctrl><Alt><l>：锁定桌面。
<Ctrl><Alt><d>：切换隐藏/显示桌面的功能(当老板走过来的时候迅速藏起你的纸牌接龙游戏非常管用哦！)。
<Alt><SysRq><command_key>： (非必须掌握)这是在Linux的内核（底层内核）上支持的一组组合键。它意味着这些组合键在大部分情况下都是有效的。组合键主要是针对开发人员的程序调试目的或者在紧急场合下才使用；你也可以使用其他的办法，安全第一。<SysRq>键在PC上指的是PrintScreen键。组合键的功能可以通过设置相对应的内核参数来激活或者取消，比如： echo “1″ > /proc/sys/kernel/sysrq。
<Alt><SysRq><k>：终止在当前虚拟终端上运行的所有进程（包括X窗口）。这个组合键被称为“安全访问键“(SAK)。
<Alt><SysRq><e>：发送 TERM 信号（结束信号）到除了init进程以外的所有运行进程，要求其退出。
<Alt><SysRq><i>：发送 KILL （终止信号）到除了init进程以外的所有运行进程， 这个组合键比上一个更加有效，但是也可能引起一些程序被异常终止。
<Alt><SysRq><l>：发送KILL命令到所有运行进程（包括init），系统将不再能够使用
<Alt><SysRq><s>：在所有的挂载文件系统上运行紧急同步（缓存写） 。这可以保护数据丢失。
<Alt><SysRq><u>：以只读模式重新挂载所有已加载的文件系统。这和上面的同步组合键有相同的功能，但是另外有一个好处：如果操作顺利完成，下一次硬件重新启动时，fsck将不会重新检查所有的文件系统。
<Alt><SysRq><r>：关闭键盘的原始模式。当你的X窗口程序挂住没有响应时特别有用。使用这个组合键之后，你可能会接着使用<CTRL><ALT><DEL>程序启动。
<Alt><SysRq>：不进行同步和卸载就立刻重新启动系统。之后你可能会碰到一下错误信息。
<Alt><SysRq><o>：关机 （如果正确设置以后）。
<Alt><SysRq><p>：导出当前的寄存器和标志到控制台。
<Alt><SysRq><t>：导出当前任务和相关信息到控制台。
<Alt><SysRq><m>：导出内存的内容到控制台。
<Alt><SysRq><数字>：“数字”从0到9。设置控制台记录的级别，用于控制哪一些内核信息将被显示在控制台上。举例，“0”意味着只有象PANIC和OOPS的之类的紧急信息才被显示在控制台上。
<Alt><SysRq><h>：显示帮助信息。还有，任何其他不被支持的 <Alt><SysRq><key> 组合键将显示同样的帮助。

CTRL+TAB：切换工作桌面。
ALT+TAB：切换应用程序。
ALT+F1：打开应用程序菜单。
ALT+F2：打开命令窗口。
ALT+F3：打开窗口菜单。
ALT+F4：关闭窗口。
F1：HELP。
F2：在页面搜索。
F3：在页面搜索下一个。
SPACE：选中/取消选中文件。
CTRL+N：打开文件管理器。
CTRL+A：全选当前目录下的文件和目录。
CTRL+T：在当前目录下打开一个终端。
CTRL+W：关闭窗口。
CTRL+F：搜索文件。
CTRL+C：拷贝。
CTRL+r：粘贴

百度百科

简介　　光纤宽带就是把要传送的数据由电信号转换为光信号进行通讯。 在光纤的两端分别都装有“光猫”进行信号转换。 光纤是宽带网络中多种传输媒介中最理想的一种，它的特点是传输容量大，传输质量好，损耗小，中继距离长等。光纤传输使用的是波分复用，即是把小区里的多个用户的数据分别调制成不同波长的光信号在一根光纤里传输。 　　光纤宽带和ADSL接入方式的区别就是，ADSL是一人享用一根电话线上网，在这根电话线里还有你的电话机使用的语音信号。而光纤宽带则是通到小区，然后分别通过超5类网线通到各用户，这样上网是上网，打电话是打电话。小区里的用户共享一根光纤足够了。

光纤接入网　　光纤接入网是指接入网中传输媒介为光纤的接入网。光纤接入网从技术上可分为两大类：有源光网络(AON，Active Optical Network)和无源光网络(PON，Passive Optical Network)。有源光网络又可分为基于SDH的AON和基于PDH的AON；无源光网络可分为窄带PON和宽带PON。 　　由于光纤接入网使用的传输媒介是光纤，因此根据光纤深入用户群的程度，可将光纤接入网分为FTTC（光纤到路边）、FTTZ（光纤到小区）、 FTTB（光纤到大楼）、FTTO（光纤到办公室）和FTTH（光纤到户），它们统称为FTTx。FTTx不是具体的接入技术，而是光纤在接入网中的推进程度或使用策略。

接入网结构　　光纤接入网的三种系统结构分别为FTTN、FTTC和FTTH。在网络发展过程中，每种结构都有其应用优势，在网络向全业务演进过程中，每种结构都是关键的一环。FTTN给人们带来的好处是它将光纤进一步推向用户网络。它建立起一个接入平台，能提供话音、高速数据和视频业务给众多的家庭，而不需要完全重建接入环路和分配网络。根据需求，可以在光纤节点处增加一个插件，即可提供所需业务。在因业务驱动或网络重建使光纤节点移到路边FTTC或家庭（FTTH）之前，FTTN将叠加于并利用现有的铜线分配网络。 　　这种网络结构的基本要求是为了提供宽带数据业务与视频业务，节点与住宅的距离应当在4000到5000英尺的范围内。而当今的节点一般的服务距离可达12000英尺。因此，每个服务区需要设置3到5个FTTN节点。 　　FTTC比FTTN多几个优点。当采用FTTC重建现有网络时，可消除由电缆传输可能带来的延时与干扰。它使光纤更深入到用户网络中，这可减少潜在的网络问题的发生和由于现场操作引起的性能恶化。目前FTTC是最健壮和“可部署的”的网络，是将来可演进到FTTH的网络。它同样是新建区和重建区最经济的网络建设方案。 　　这种网络结构的一个缺点是需要提供铜线设备的供电系统。一个位于局端的远程供电系统能给50到100个路边光网络单元供电、每个路边节点采用单独的供电单元代价非常高而且在较长时间停电时会影响用户的业务要求。 　　作为提供光纤到家的最终网络形式，FTTH去掉了整个铜线设施：馈线、配线和引入线。对所有的宽带应用而言，这种结构是最可靠和长久的未来解决方案。它还去掉了铜线所需要的所有维护工作并大大延长了网络寿命。 　　网络的连接末端是用户住宅设备。在用户家里，需要一个网络终接设备将带宽和数据流转换成可接收的视频信号、数据业务及语音业务。 　　光纤接入的步骤： 　　⑴ 客户端的网卡或普通的路由器，与客户端光电转换器相连； 　　⑵ 客户端的光电转换器通过光纤直接与离客户端最近的城域网节点的光纤设备相连； 　　⑶ 最后通过ISP公司的骨干网出口接入到 Internet 。

光纤接入的适用范围　　不同的光纤接入技术有不同的适用场合。 　　有源光接入技术适用带宽需求大、对通信保密性高的企事业单位的接入。它也可以用在接入网的馈线段和配线段，并与基于无线或铜线传输的其他接入技术混合使用。 　　ATM-PON既可以用来解决企事业用户的接入，也可以解决住宅用户的接入。有的运营商利用“ATM-PON + xDSL”混合接入方案，解决住宅用户或企事业用户的宽带接入。 　　窄带PON主要面向住宅用户，也可用来解决中小型企事业用户的接入。 　　另外，PON的服务范围不超过20公里，但通过“有源光网络+无源光网络”混合组网方案，可弥补该不足。

光纤接入的方式　　光纤接入能够确保向用户提供10Mbps，100Mbps，1000Mbps的高速带宽，可直接汇接到CHINANET骨干结点。主要适用于商业集团用户和智能化小区局域网的高速接入与INTERNET高速互联。目前可向用户提供三种具体接入方式。

光纤 + 以太网接入

　　适用对象：已做好或便于综合布线及系统集成的小区光纤接入住宅与商务楼宇等。 　　所需的主要网络产品:交换机，光电转换器，超五类线等。

光纤 + HOMPEPNA

　　适用对象:未做好或不便于综合布线及系统集成的小区住宅与酒店楼宇等。 　　所需的主要网络产品：HOMEPNA专用交换机（HUB） HOMEPNA专用终端产品（MODEM）等。

光纤 +VDSL

　　适用对象：未做好或不便于综合布线及系统集成的小区住宅与酒店楼宇等。 　　所需的主要网络产品：VDSL专用交换机，VDSL专用终端产品。

光纤+五类缆接入（FTTx+ LAN）

　　以”千兆到小区、百兆到大楼、十兆到用户”为实现基础的光纤+五类缆接入方式尤其适合我国国情。它主要适用于用户相对集中的住宅小区、企事业单位和大专院校。FTTX是光纤传输到（路边、小区、大楼-），LAN为局域网。主要对住宅小区、高级写字楼及大专院校教师和学生宿舍等有宽带上网需求的用户进行综合布线，个人用户或企业单位就可通过连接到用户计算机内以太网卡的5类网线实现高速上网和高速互联。

光纤直接接入

　　是为有独享光纤高速上网需求的企事业单位或集团用户提供的，传输带宽2M-155M不等。 　　业务特点：可根据用户群体对不同速率的需求，实现高速上网或企业局域网间的高速互联。同时由于光纤接入方式的上传和下传都有很高的带宽，尤其适合开展远程教学、远程医疗、视频会议等对外信息发布量较大的网上应用。 　　适合的用户群体：居住在已经或便于进行综合布线的住宅、小区和写字楼的较集中的用户；有独享光纤需求的企事业单位或集团用户。 光纤接入的方式　　光纤接入能够确保向用户提供10Mbps，100Mbps，1000Mbps的高速带宽，可直接汇接到CHINANET骨干结点。主要适用于商业集团用户和智能化小区局域网的高速接入与INTERNET高速互联。目前可向用户提供三种具体接入方式。

光纤 + 以太网接入

　　适用对象：已做好或便于综合布线及系统集成的小区光纤接入住宅与商务楼宇等。

　　所需的主要网络产品:交换机，光电转换器，超五类线等。

光纤 + HOMPEPNA

　　适用对象:未做好或不便于综合布线及系统集成的小区住宅与酒店楼宇等。

　　所需的主要网络产品：HOMEPNA专用交换机（HUB） HOMEPNA专用终端产品（MODEM）等。

光纤 +VDSL

　　适用对象：未做好或不便于综合布线及系统集成的小区住宅与酒店楼宇等。

　　所需的主要网络产品：VDSL专用交换机，VDSL专用终端产品。

光纤+五类缆接入（FTTx+ LAN）

　　以”千兆到小区、百兆到大楼、十兆到用户”为实现基础的光纤+五类缆接入方式尤其适合我国国情。它主要适用于用户相对集中的住宅小区、企事业单位和大专院校。FTTX是光纤传输到（路边、小区、大楼-），LAN为局域网。主要对住宅小区、高级写字楼及大专院校教师和学生宿舍等有宽带上网需求的用户进行综合布线，个人用户或企业单位就可通过连接到用户计算机内以太网卡的5类网线实现高速上网和高速互联。

光纤直接接入

　　是为有独享光纤高速上网需求的企事业单位或集团用户提供的，传输带宽2M-155M不等。

　　业务特点：可根据用户群体对不同速率的需求，实现高速上网或企业局域网间的高速互联。同时由于光纤接入方式的上传和下传都有很高的带宽，尤其适合开展远程教学、远程医疗、视频会议等对外信息发布量较大的网上应用。

　　适合的用户群体：居住在已经或便于进行综合布线的住宅、小区和写字楼的较集中的用户；有独享光纤需求的企事业单位或集团用户。

以太网接入　　近一时期，服务提供商一直在推广高密度光纤骨干网，企业用户也在等待这类高速服务的提交。尽管保证提供海量可用带宽的高密度光纤网已经建成，但对网络服务的需求却被封闭在基于时分复用（TDM）的本地环路接入技术的框框之内。对带宽需求不断变化的企业用户由于为增加一条T-1线路需要等待数周或因升级到T-3线路而等上几个月而感到不满。 　　一种非常具有发展前景的解决方案将使现在正在部署的光纤宽带接入，能够利用软件来取代穿过僵化的TDM基础设施的硬连线网络接入来配置多种服务，并且每种服务可以具有不同的服务水平以及软件命令远程调节的速度保证。这类以满足对多种服务额外带宽需要为目标的软件可调服务，只需几天而不是数周的时间，并且无需高昂的工程费用或现场升级就可以完成配置，在需要时可以立即精确地提供所需带宽容量。以太网可以实现这一目标。以太网非常适于从光纤网络提交软件可调节的带宽，它具有普遍的可用性并且价格低廉，可以很容易达到1Gbps的速度，并且不久可以达到10Gbps的速度。如果目前连接到家门口的光纤支持以太网技术的话，一条连接线路可以达到从每秒64K到数千兆位的任何速度，并可以用于访问所有的广域网服务。 　　如此灵活提供的服务代表着目前DSL和基于有线电缆宽带服务之后的下一个高速技术，它们将使企业用户最终可以利用传输基础设施核心中的光纤部署。 　　提交基于以太网的服务所需的条件是智能的光纤接入平台，这种平台使服务提供商可以从传统的基于TDM的服务迁移到优化的数据包服务，并使用户可以在提供带宽保证的多服务光纤连接上传送如IP语音这类多服务、广域传输流。

主要优点　　光纤接入 　　⑴ 容量大。光纤工作频率比目前电缆使用的工作频率高出8–9个数量级，故所开发的容量大。 　　⑵ 衰减小。光纤每公里衰减比目前容量最大的通信同轴电缆每公里衰减要低一个数量级以上。 　　⑶ 体积小，重量轻。同时有利于施工和运输。 　　⑷ 防干扰性能好。光纤不受强电干扰、电气信号干扰和雷电干扰，抗电磁脉冲能力也很强，保密性好。 　　⑸ 节约有色金属。一般通信电缆要耗用大量的铜、铅或铝等有色金属。光纤本身是非金属，光纤通信的发展将为国家节约大量有色金属。 　　光导纤维是一种传输光束的细微而柔韧的媒质。光导纤维缆线是由一捆光纤组成 , 简称为光缆。光缆是数据传输中最有效的一种传输介质，它的优点和光纤的优点类似，主要有以下几个方面： 　　(1) 频带较宽。 　　(2) 电磁绝缘性能好。光缆中传输的是光束，由于光束不受外界电磁干扰与影响，而且本身也不向外辐射信号，因此它适用于长距离的信息传输以及要求高度安全的场合。当然，抽头困难是它固有的难题，因为割开的光缆需要再生和重发信号。 　　(3) 衰减较小。可以说在较长距离和范围内信号是一个常数。 　　(4) 中继器的间隔较大，因此可以减少整个通道中继器的数目，可降低成本，传输质量很好。而同轴电缆和双绞线每隔几百米就需要接一个中继器。

技术特点　　光纤接入–接入设备 　　1．有源光网络 　　顾名思义，有源光网络的局端设备（CE） 和远端设备（RE）通过有源光传输设备相连，传输技术是骨干网中已大量采用的SDH和PDH技术，但以SDH技术为主。远端设备主要完成业务的收集、接口适配、复用和传输功能。局端设备主要完成接口适配、复用和传输功能。此外，局端设备还向网元管理系统提供网管接口。在实际接入网建设中，有源光网络的拓扑结构通常是星形或环形。 有源光网络具有以下技术特点： 　　◆ 传输容量大，目前用在接入网的SDH传输设备一般提供155Mb/s或622Mb/s的接口，有的甚至提供2.5Gb/S的接口。将来只要有足够业务量需求，传输带宽还可以增加，光纤的传输带宽潜力相对接入网的需求而言几乎是无限的。 　　◆ 传输距离远，在不加中继设备的情况下，传输距离可达70～80公里。 　　◆ 用户信息隔离度好。有源光网络的网络拓扑结构无论是星形还是环形，从逻辑上看，用户信息的传输方式都是点到点方式。 　　◆ 技术成熟，无论是SDH设备还是PDH设备，均已在以太网中大量使用。 　　由于SDH/PDH技术在骨干传输网中大量使用，有源光接入设备的成本已大大下降，但在接入网中与其他接入技术相比，成本还是比较高。 　　2.ATM无源光网络（ATM-PON） 　　ATM-PON最重要的特点就是其无源点到多点式的网络结构。它综合了ATM技术和无源光网络技术，可以提供现有的从窄带到宽带等各种业务。ATM-PON由OLT、ONU/ONT和无源光分路器组成。其中，Splitter是光分路器，它根据光的发送方向，将进来的光信号分路并分配到多条光纤上，或是组合到一条光纤上。ONU/ONT主要完成业务的收集、接口适配、复用和传输功能；OLT主要完成接口适配、复用和传输功能。此外，OLT还向网元管理系统提供网管接口。 　　ODN（光配线网）中光分路器的工作方式是无源的，这就是无源光网络中“无源”一词的来历。但ONU和OLT还是工作在有源方式下，即需要外接电源才能正常工作。所以，采用无源光网络接入技术并不是所有设备都工作在不需要外接馈电的条件下，只是ODN部分没有有源器件。 　　3． 窄带无源光网络（窄带PON） 　　窄带PON的网络拓扑结构与ATM-PON基本一样，它与ATM-PON存在以下主要区别： 　　◆ ATM-PON是宽带接入技术，可以给用户提供大于2Mb/s的接入速率；窄带PON是窄带接入技术，只支持窄带业务，给用户提供的接入速率最大为2Mb/s。 　　◆ 窄带PON的线路速率远小于ATM-PON。其线路速率一般在20Mb/s到50Mb/s之间。 　　◆ 窄带PON的传输采用电路方式，而ATM-PON采用分组方式（ATM信元）。 　　◆ 窄带PON的网络侧接口一般为V5接口，用户侧接口为现有各种窄带业务接口；ATM-PON网络侧接口一般为ATM接口，用户侧接口包括各种宽窄带业务接口。 　　◆ 窄带PON的标准化程度不如ATM-PON。窄带PON是先有产品，后有标准；ATM-PON是产品和标准几乎同时出来。 　　除以上几点区别外，窄带PON的其他特点与ATM-PON相同。窄带PON的设备价格近年来下降很快，已经接近目前窄带接入中广泛应用的IDLC（综合数字环路载波）的价格。