Cloudera  的定位在于 Bringing Big Data to the Enterprise with Hadoop
Cloudera为了让Hadoop的配置标准化，可以帮助企业安装，配置，运行hadoop以达到大规模企业数据的处理和分析。
既然是给企业使用，Cloudera的软件配置不是采用最新的hadoop 0.20，而是采用了Hadoop 0.18.3-12.cloudera.CH0_3的版本进行封装，并且集成了facebook提供的hive，yahoo提供的pig等基于 hadoop的sql实现接口，使得这些软件的安装，配置和使用的成本降低并且进行了标准化。当然除了集成和封装这些成熟的工具外，Cloudera一个 比较有意思的工具是sqoop,目前这个工具没有独立提供。

最近雅虎开发者博客发了一篇介绍Hadoop重构计划的文章。因为他们发现当集群的规模达到4000台机器的时候，Hadoop遭遇到扩展性的瓶颈，目前他们正准备开始对Hadoop进行重构。
Mapreduce面临的瓶颈
从集群大小和工作量中观察到的趋势是，MapReduce的JobTracker需要彻底改革，以解决其可扩展性，内存消耗，线程模型，可靠性和性能的几个缺陷。Mapreduce在过去5年框架不断的修复过程中发现成本在不断增加。目前Hadoop各个模块的紧耦合使得在现有设计的基础上继续改进变得举步维艰。这一点早已在社区内达成共识，所以他们正准备开始对Hadoop进行重构。不过从操作的角度来看，任何轻微的或修复Bug带来的巨大改动都会让Hadoop MapReduce强制进行全系统的升级。
下一代MapReduce构思
据该博客文章表示，新架构的主要思想是把原来JobTracker的功能一分为二：ResourceManager管理资源的分配，ApplicationMaster管理任务监控和调度。ResourceManager与原有的JobTracker类似，作为整个集群的控制中心；而ApplicationMaster则是每个application都有一个单独的实例，application是用户提交的一组任务，它可以由一个或多个job组成。每台slave运行一个NodeManager实例，功能类似于原来的TaskTracker。
1.层次化的管理
目前Hadoop的资源管理和任务调度都是在JobTracker中进行的，它需要复制所有task的资源分配和调度。而task是非常微观的调度单位，通常每个job都会产生成百上千个task，而系统同一时刻又会有大量的job同时运行，这让JobTracker的管理负担变得非常繁重。新架构将这一管理任务下放到各个ApplicationMaster，ResourceManager只管理每个application的资源分配。这样即使系统中存在很多application，ResourceManager的负担也能控制在一个合理的程度；这也是新架构最大的优势。
2.ApplicationMaster应该在Master还是Slave上运行？
新架构实际上将管理和调度的任务转移到ApplicationMaster上来，如果ApplicationMaster所在的节点挂掉，整个任务都需要重做。原来JobTracker可以跑在相对稳定的Master上，出错概率低；现在ApplicationMaster跑在好些Slave上，出错的概率就非常高了。而且新架构打破了原来简单的Master-Slave模型，节点之间的通讯和依赖关系变得更加复杂，增加了网络优化的难度。如果把ApplicationMaster全都放在Master上执行，则Master的负担会非常重（需要处理各种持续性的heartbeat和爆发性的如getTaskCompletionEvents这样的rpc请求），不过这个问题可以通过分布式的Master解决（Google已经实现）。
3.资源管理方式
原来单纯地以简单静态的slot作为资源单位确实不能很好描述集群的资源状况。新架构将更细粒度地控制CPU，内存，磁盘，网络这些资源。每个task都将在Container中执行，并只能使用其所分配到的系统资源。资源的分配可以用静态估计动态调整的方式实现。
4.支持其他编程模型
由于任务的管理和调度都由ApplicationMaster进行，ApplicationMaster又相对独立于系统的其他模块，用户甚至可以部署自己的ApplicationMaster，实现对其他编程模型的支持。这使得其他不大适合用MapReduce实现的应用程序也能在同一个Hadoop集群中运行。
可伸缩性实现
可伸缩性对当前的硬件发展趋势是非常重要的，目前MapReduce集群已经有4000台主机。然而2009年的集群中的4000台主机（8核心，16GB内存，4TB硬盘）只有2011年集群中4000台主机（16核心，48GB内存，24TB内存）一半的处理能力。此外，考虑到运营成本，迫使集群中运行6000台主机，以后可能会更多。
可用性实现
ResourceManager —— ResourceManager使用Apache的ZooKeeper实现故障转移。当ResourceManager失败时，可以通过Apache的ZooKeeper迅速恢复集群状态。在故障转移后，所有队列运行的应用程序都会重新启动。
ApplicationMaster —— MapReduce的NextGen支持为ApplicationMaster应用进行特定的检查。MapReduce的ApplicationMaster可以从失败中恢复，通过自身恢复到HDFS保存的状态。
兼容性实现
MapReduce的NextGen使用Wire-兼容协议（wire-compatible protocols）来允许不同版本的服务器和客户端进行信息交换。在未来的版本中，这一特性将一直保留，以保证集群升级后仍然兼容。
集群实现
MapReduce NextGen Resource使用常规的概念调度并将资源分配给各个应用程序。集群中的每台机器概念上都是由资源组成的，如内存，I/O带宽等。
支持其他的编程模型
MapReduce的NextGen提供了一个完全通用的计算框架，以支持MapReduce和其他范例。
该架构最终允许用户能够实现自定义ApplicationMaster，它可以要求ResourceManager的资源利用他们。因此，它支持多种编程，如MapReduce，MPI，Master-Worker以及Iterative models在Hadoop上。并允许为每个应用使用适当的框架。这对于应用程序（如K-Means, Page-Rank）在自定义框架外运行MapReduce。
结论
Apache的Hadoop，特别是Hadoop的MapReduce是一个非常成功的开源的处理大数据集的项目。我们建议Hadoop的MapReduce提高可用性、提高集群使用，并提供范式的编程架构以及
实现快速的发展。Yahoo将和Apache基金会一起将Hadoop在处理大数据的能力提高到一个新水平。

Spring Hadoop 发布了首个里程碑版本，Spring Hadoop 提供了在 Spring 框架下编写 Hadoop 应用的支持。
Spring Hadoop 支持：

• Hadoop 配置
• MapReduce, Streaming Jobs and Tool
• HBase 配置
• Hive server and thrift client
• Pig configuration
• Embedded API for Hadoop FsShell and DistCp
• JSR-223/javax.scripting for HDFS interaction
• Spring Batch tasklets for vanilla Hadoop, Hive, Pig

相关链接：
Downloads | JavaDocs | Reference Documentation | Changelog

HDFS支持权限控制的设计是基于POSIX模型，支持按用户、用户组、其他用户的读写执行控制权限。
在linux命令行下，可以使用下面的命令修改文件的权限、文件所有者，文件所属组：
•hadoop fs –chmod （修改文件所有者，文件所属组，其他用户的读、写、执行权限）
•haddop fs –chown （修改文件所有者）
•hadoop fs –chgrp （修改文件所属组）
不同用户使用不同的linux帐户即可访问到特定文件。
启动hadoop hdfs系统的用户即为超级用户，可以进行任意的操作。

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司进行，提供了身份验证与加密通讯方法，现在它被广泛用于万维网上安全敏感的通讯，例如交易支付方面。
简介
它是由Netscape开发并内置于其浏览器中，用于对数据进行压缩和解压操作，并返回网络上传送回的结果。HTTPS实际上应用了Netscape的安全套接字层（SSL）作为HTTP应用层的子层。（HTTPS使用端口443，而不是象HTTP那样使用端口80来和TCP/IP进行通信。）SSL使用40 位关键字作为RC4流加密算法，这对于商业信息的加密是合适的。HTTPS和SSL支持使用X.509数字认证，如果需要的话用户可以确认发送者是谁。 　　也就是说它的主要作用可以分为两种：一种是建立一个信息安全通道，来保证数据传输的安全；另一种就是确认网站的真实性。
HTTPS和HTTP的区别
一、https协议需要到ca申请证书，一般免费证书很少，需要交费。 　　二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。 　　三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。 　　四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全.
HTTPS解决的问题
一、信任主机的问题.
采用https的服务器必 须从CA （Certificate Authority）申请一个用于证明服务器用途类型的证书。该证书只有用于对应的服务器的时候，客户端才信任此主机。所以目前所有的银行系统网站，关键 部分应用都是https 的。客户通过信任该证书，从而信任了该主机。其实这样做效率很低，但是银行更侧重安全。这一点对我们没有任何意义，我们的服务器，采用的证书不管是自己发 布的还是从公众的地方发布的，其客户端都是自己人，所以我们也就肯定信任该服务器。
二、通讯过程中的数据的泄密和被篡改
1． 一般意义上的https，就是服务器有一个证书。 　　a) 主要目的是保证服务器就是他声称的服务器，这个跟第一点一样。 　　b) 服务端和客户端之间的所有通讯，都是加密的。 　　i. 具体讲，是客户端产生一个对称的密钥，通过服务器的证书来交换密钥，即一般意义上的握手过程。 　　ii. 接下来所有的信息往来就都是加密的。第三方即使截获，也没有任何意义，因为他没有密钥，当然篡改也就没有什么意义了。 　　2． 少许对客户端有要求的情况下，会要求客户端也必须有一个证书。 　　a) 这里客户端证书，其实就类似表示个人信息的时候，除了用户名/密码，还有一个CA 认证过的身份。因为个人证书一般来说是别人无法模拟的，所有这样能够更深的确认自己的身份。 　　b) 目前少数个人银行的专业版是这种做法，具体证书可能是拿U盘（即U盾）作为一个备份的载体。
SSL介绍
SSL (Secure Socket Layer) 　　为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听。目前一般通用之规格为40 bit之安全标准，美国则已推出128 bit之更高安全标准，但限制出境。只要3.0版本以上之I.E.或Netscape浏览器即可支持SSL。 　　当前版本为3.0。它已被广泛地用于Web浏览器与服务器之间的身份认证和加密数据传输。 　　SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持。SSL协议可分为两层：SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
SSL协议提供的服务主要有哪些？
1）认证用户和服务器，确保数据发送到正确的客户机和服务器 　　2）加密数据以防止数据中途被窃取 　　3）维护数据的完整性，确保数据在传输过程中不被改变。
SSL协议的工作流程
服务器认证阶段：1）客户端向服务器发送一个开始信息“Hello”以便开始一个新的会话连接；2）服务器根据客户的信息确定是否需要生成新的主密钥， 如需要则服务器在响应客户的“Hello”信息时将包含生成主密钥所需的信息；3）客户根据收到的服务器响应信息，产生一个主密钥，并用服务器的公开密钥加密后传给服务器；4）服务器恢复该主密钥，并返回给客户一个用主密钥认证的信息，以此让客户认证服务器。
用户认证阶段
在此之前，服务器已经通过了客户认证，这一阶段主要完成对客户的认证。经认证的服务器发送一个提问给客户，客户则返回（数字）签名后的提问和其公开密钥，从而向服务器提供认证。 　　从SSL 协议所提供的服务及其工作流程可以看出，SSL协议运行的基础是商家对消费者信息保密的承诺，这就有利于商家而不利于消费者。在电子商务初级阶段，由于运作电子商务的企业大多是信誉较高的大公司，因此这问题还没有充分暴露出来。但随着电子商务的发展，各中小型公司也参与进来，这样在电子支付过程中的单一认证问题就越来越突出。虽然在SSL3.0中通过数字签名和数字证书可实现浏览器和Web服务器双方的身份验证，但是SSL协议仍存在一些问题，比如，只能提供交易中客户与服务器间的双方认证，在涉及多方的电子交易中，SSL协议并不能协调各方间的安全传输和信任关系。在这种情况下，Visa和MasterCard两大信用卡公组织制定了SET协议，为网上信用卡支付提供了全球性的标准。
SSL协议的握手过程
为了便于更好的认识和理解SSL 协议，这里着重介绍SSL 协议的握手协议。SSL 协议既用到了公钥加密技术又用到了对称加密技术，对称加密技术虽然比公钥加密技术的速度快，可是公钥加密技术提供了更好的身份认证技术。SSL 的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证，其主要过程如下： 　　①客户端的浏览器向服务器传送客户端SSL 协议的版本号，加密算法的种类，产生的随机数，以及其他服务器和客户端之间通讯所需要的各种信息。 　　②服务器向客户端传送SSL 协议的版本号，加密算法的种类，随机数以及其他相关信息，同时服务器还将向客户端传送自己的证书。 　　③客户利用服务器传过来的信息验证服务器的合法性，服务器的合法性包括：证书是否过期，发行服务器证书的CA 是否可靠，发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”，服务器证书上的域名是否和服务器的实际域名相匹配。如果合法性验证没有通过，通讯将断开；如果合法性验证通过，将继续进行第四步。 　　④用户端随机产生一个用于后面通讯的“对称密码”，然后用服务器的公钥（服务器的公钥从步骤②中的服务器的证书中获得）对其加密，然后将加密后的“预主密码”传给服务器。 　　⑤如果服务器要求客户的身份认证（在握手过程中为可选），用户可以建立一个随机数然后对其进行数据签名，将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。 　　⑥如果服务器要求客户的身份认证，服务器必须检验客户证书和签名随机数的合法性，具体的合法性 验证过程包括：客户的证书使用日期是否有效，为客户提供证书的CA 是否可靠，发行CA 的公钥能否正确解开客户证书的发行CA 的数字签名，检查客户的证书是否在证书废止列表（CRL）中。检验如果没有通过，通讯立刻中断；如果验证通过，服务器将用自己的私钥解开加密的“预主密 码”，然后执行一系列步骤来产生主通讯密码（客户端也将通过同样的方法产生相同的主通讯密码）。 　　⑦服务器和客户端用相同的主密码即“通话密码”，一个对称密钥用于SSL 协议的安全数据通讯的加解密通讯。同时在SSL 通讯过程中还要完成数据通讯的完整性，防止数据通讯中的任何变化。 　　⑧客户端向服务器端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知服务器客户端的握手过程结束。 　　⑨服务器向客户端发出信息，指明后面的数据通讯将使用的步骤⑦中的主密码为对称密钥，同时通知客户端服务器端的握手过程结束。 　　⑩SSL 的握手部分结束，SSL 安全通道的数据通讯开始，客户和服务器开始使用相同的对称密钥进行数据通讯，同时进行通讯完整性的检验。
证书各部分的含义
证书版本号，不同版本的证书格式不同 　　Serial Number　序列号，同一身份验证机构签发的证书序列号唯一 　　Algorithm Identifier 签名算法，包括必要的参数Issuer 身份验证机构的标识信息 　　Period of Validity 有效期 　　Subject　证书持有人的标识信息 　　Subject’s Public Key　证书持有人的公钥 　　Signature　身份验证机构对证书的签名 　　证书的格式　认证中心所发放的证书均遵循X.509 V3 标准，其基本格式如下： 　　证书版本号（Certificate Format Version） 　　含义：用来指定证书格式采用的X.509 版本号。 　　证书序列号（Certificate Serial Number） 　　含义：用来指定证书的唯一序列号，以标识CA 发出的所有公钥证书。 　　签名（Signature）算法标识（Algorithm Identifier） 　　含义：用来指定 CA 签发证书所用的签名算法。 　　签发此证书的 CA 名称（Issuer ） 　　含义：用来指定签发证书的 CA 的X.500 唯一名称（DN，Distinguished Name）。 　　证书有效期（Validity Period）起始日期（notBefore） 终止日期（notAfter） 　　含义：用来指定证书起始日期和终止日期。 　　用户名称（Subject） 　　含义：用来指定证书用户的X.500 唯一名称（DN，Distinguished Name）。 　　用户公钥信息（Subject Public Key Information）算法（algorithm） 算法标识（Algorithm　Identifier）用户公钥（subject　Public　Key） 　　含义：用来标识公钥使用的算法，并包含公钥本身。 　　证书扩充部分（扩展域）（Extensions） 　　含义：用来指定额外信息。　 　　X.509 V3 证书的扩充部分（扩展域）及实现方法如下： 　　CA 的公钥标识（Authority　Key　Identifier） 　　公钥标识（SET 未使用）（Key　Identifier） 　　签发证书者证书的签发者的甄别名（Certificate　Issuer） 　　签发证书者证书的序列号（Certificate Serial Number） 　　X.509 V3 证书的扩充部分（扩展域）及实现CA 的公钥标识（Authority　Key　Identifier） 　　公钥标识（SET 未使用）（Key　Identifier） 　　签发证书者证书的签发者的甄别名（Certificat签发证书者证书的序列号（Certificate Serial Number） 　　含义：CA 签名证书所用的密钥对的唯一标识用户的公钥标识（Subject　Key　Identifier）　 　　含义：用来标识与证书中公钥相关的特定密钥进行解密。 　　证书中的公钥用途（Key　Usage） 　　含义：用来指定公钥用途。 　　用户的私钥有效期（Private　Key　Usage　Period）起始日期（Note　Before） 终止日期（Note　After） 　　含义：用来指定用户签名私钥的起始日期和终止日期。 　　CA 承认的证书政策列表（Certificate Policies） 　　含义：用来指定用户证书所适用的政策，证书政策可由对象标识符表示。 　　用户的代用名（Substitutional　Name） 　　含义：用来指定用户的代用名。 　　CA 的代用名（Issuer　Alt　Name） 　　含义：用来指定 CA 的代用名。 　　基本制约（Basic　Constraints） 　　含义：用来表明证书用户是最终用户还是CA。 在SET 系统中有一些私有扩充部分（扩展域）Hashed　Root　Key 含义：只在根证书中使用，用于证书更新时进行回溯。 　　证书类型（Certificate　Type） 　　含义：用来区别不同的实体。该项是必选的。 　　商户数据（Merchant　Data） 　　含义：包含支付网关需要的所有商户信息。 　　持卡人证书需求（Card　Cert　Required） 　　含义：显示支付网关是否支持与没有证书的持卡人进行交易。 　　SET 扩展（SETExtensions） 　　含义：列出支付网关支持的支付命令的 SET 信息扩展。 　　CRL 数据定义版本（Version） 　　含义：显示 CRL 的版本号。 　　CRL 的签发者（Issuer） 　　含义：指明签发 CRL 的CA 的甄别名。 　　CRL 发布时间（this　Update）预计下一个 CRL 更新时间（Next　Update）撤销证书信息目录（Revoked　Certificates） CRL 扩展（CRL　Extension）CA 的公钥标识（Authority　Key　Identifier）CRL 号（CRL　Number）

localhost也叫local，正确的解释是，本地服务器。
127.0.0.1在windows等系统的正确解释是：本地地址（本机服务器）。
localhost（local）是不经网卡传输！这点很重要，它不受网络和网卡相关的限制。
127.0.0.1是通过网卡传输，依赖网卡，并受到网络防火墙和网卡相关的限制。
一般设置程序时本地服务用localhost是最好的，localhost不会解析成IP，也不会占用网卡，网络资源。用时候用localhost可以，用127.0.0.1就不可以的情况就是于此。猜想localhost访问时，系统带的本机当前用户的权限去访问，而用IP去访问的时候等于是本地是通过网络再去访问本机，可能涉及到网络用户的权限。

Buffer和Cache的区别
缓存（cache）是把读取过的数据保存起来，重新读取时若命中（找到需要的数据）就不要去读硬盘了，若没有命中就读硬盘。其中的数据会根据读取频率进行组织，把最频繁读取的内容放在最容易找到的位置，把不再读的内容不断往后排，直至从中删除。
缓存（cache）实际并不是缓冲文件的，而是缓冲块的，块是磁盘I/O操作的最小单元（在Linux中，它们通常是1KB）。这样，目录、超级块、其它文件系统的薄记数据以及非文件系统的磁盘数据都可以被缓冲了。
如果缓存有固定的大小，那么缓存太大了也不好，因为这会使得空闲的内存太小而导致进行交换操作（这同样是慢的）。为了最有效地使用实际内存，Linux自动地使用所有空闲的内存作为高速缓冲，当程序需要更多的内存时，它也会自动地减小缓冲的大小。
缓冲（buffer）是根据磁盘的读写设计的，把分散的写操作集中进行，减少磁盘碎片和硬盘的反复寻道，从而提高系统性能。linux有一个守护进程定期清空缓冲内容（即写磁盘），也可以通过sync命令手动清空缓冲。举个例子吧：我这里有一个ext2的U盘，我往里面cp一个3M的 MP3，但U盘的灯没有跳动，过了一会儿（或者手动输入sync）U盘的灯就跳动起来了。卸载设备时会清空缓冲，所以有些时候卸载一个设备时要等上几秒钟。
两者都是RAM中的数据。简单来说，buffer是即将要被写入磁盘的，而cache是被从磁盘中读出来的。
buffer是由各种进程分配的，由进程和系统一起管理.被用在如输入队列等方面，一个简单的例子如某个进程要求有多个字段读入，在所有字段被读入完整之前，进程把先前读入的字段放在buffer中保存。
cache经常被用在磁盘的I/O请求上，如果有多个进程都要访问某个文件，于是该文件便被做成cache以方便下次被访问，这样可提供系统性能。
综上所述可以理解为cache系统管理，buffer由进程和系统一起管理。

netperf 是围绕着基本的客户‐服务器模式设计的。主要有两个可执行部分：客户端程序netperf 和服务器端程序netserver.。netserver 可单独在一台机器上运行,也可与客户端程序netperf 在同一机器上运行。测试时，netperf 首先建立和远程系统的控制连接。该操作通过调用establish‐control(host‐name,test‐port)为测试打开一个使用相应协 议的端口.然后,根据测试者指定的测试类型,调用相应的函数(如测试TCP 流性能,则调用send‐tcp‐stream(hostname)函数)进行处理,并等待测试结果,当测试完成时显示测试结果,关闭连接,退出该次测 试。
服务器端运行的 netserver 是一个系统守护程序,它在一个指定的监听端口循环等待测试请求，当有测试请求时,进行初始化,读取测试的类型,调用相应的模块进行处理,并读取发送方和接 收方的套接字和消息大小以及此次测试所用的时间,计算出网络的吞吐量返回计算结果,然后继续等待下一轮测试。

在构建或管理一个网络系统时，我们更多的是关心网络的可用性，即网络是否连通，而对于其整体的性能往往考虑不多，或者即使考虑到性能的问题，但是却发现没有合适的手段去测试网络的性能。
当开发出一个网络应用程序后，我们会发现，在实际的网络环境使用中，网络应用程序的使用效果不是很理想，问题可能出现在程序的开发上面，也有可能由于实际的网络环境中存在着瓶颈。面对这种问题，程序员一般会一筹莫展，原因就在于不掌握一些网络性能测量的工具。
在本文中，首先介绍网络性能测量的一些基本概念和方法，然后结合 netperf 工具的使用，具体的讨论如何测试不同情况下的网络性能。
网络性能测试概述
网络性能测量的五项指标
测量网络性能的五项指标是：
•可用性（availability）
•响应时间（response time）
•网络利用率（network utilization）
•网络吞吐量（network throughput）
•网络带宽容量（network bandwidth capacity）
1． 可用性
测试网络性能的第一步是确定网络是否正常工作，最简单的方法是使用 ping 命令。通过向远端的机器发送 icmp echo request，并等待接收 icmp echo reply 来判断远端的机器是否连通，网络是否正常工作。
Ping 命令有非常丰富的命令选项，比如 -c 可以指定发送 echo request 的个数，-s 可以指定每次发送的 ping 包大小。
网络设备内部一般有多个缓冲池，不同的缓冲池使用不同的缓冲区大小，分别用来处理不同大小的分组（packet）。例如交换机中通常具有三种类型的 包缓冲：一类针对小的分组，一类针对中等大小的分组，还有一类针对大的分组。为了测试这样的网络设备，测试工具必须要具有发送不同大小分组的能力。 Ping 命令的 -s 就可以使用在这种场合。
2． 响应时间
Ping 命令的 echo request/reply 一次往返所花费时间就是响应时间。有很多因素会影响到响应时间，如网段的负荷，网络主机的负荷，广播风暴，工作不正常的网络设备等等。
在网络工作正常时，记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。
3． 网络利用率
网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，Ethernet 虽然是共享的，但同时却只能有一个报文在传输。因此在任一时刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
计算一个网段的网络利用率相对比较容易，但是确定一个网络的利用率就比较复杂。因此，网络测试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。
4． 网络吞吐量
网络吞吐量是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。
网络吞吐量可以帮组寻找网络路径中的瓶颈。比如，即使 client 和 server 都被分别连接到各自的 100M Ethernet 上，但是如果这两个 100M 的Ethernet 被 10M 的 Ethernet 连接起来，那么 10M 的 Ethernet 就是网络的瓶颈。
网络吞吐量非常依赖于当前的网络负载情况。因此，为了得到正确的网络吞吐量，最好在不同时间（一天中的不同时刻，或者一周中不同的天）分别进行测试，只有这样才能得到对网络吞吐量的全面认识。
有些网络应用程序在开发过程的测试中能够正常运行，但是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是因为测试只是在空闲的网络环境中，没有考虑到实际的网络环境中还存在着其它的各种网络流量。所以，网络吞吐量定义为剩余带宽是有实际意义的。
5． 网络带宽容量
与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。这是由组成网络的设备的能力所决定的。
测试网络带宽容量有两个困难之处：在网络存在其它网络流量的时候，如何得知网络的最大可用带宽；在测试过程中，如何对现有的网络流量不造成影响。网络测试工具一般采用 packet pairs 和 packet trains 技术来克服这样的困难。
收集网络性能数据的方式
当确定了网络性能的测试指标以后，就需要使用网络测试工具收集相应的性能数据，分别有三种从网络获取数据的方式：
1． 通过snmp协议直接到网络设备中获取，如net-snmp工具
2． 侦听相关的网络性能数据，典型的工具是tcpdump
3． 自行产生相应的测试数据，如本文中使用的netperf工具
——————————————————————————–
回页首
Netperf
Netperf是一种网络性能的测量工具，主要针对基于TCP或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即 批量数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统 发送数据，以及另外一个系统能够以多块的速度接收数据。
Netperf工具以client/server方式工作。server端是netserver，用来侦听来自client端的连接，client 端是netperf，用来向server发起网络测试。在client与server之间，首先建立一个控制连接，传递有关测试配置的信息，以及测试的结 果；在控制连接建立并传递了测试配置信息以后，client与server之间会再建立一个测试连接，用来来回传递着特殊的流量模式，以测试网络的性能。
TCP网络性能
由于TCP协议能够提供端到端的可靠传输，因此被大量的网络应用程序使用。但是，可靠性的建立是要付出代价的。TCP协议保证可靠性的措施，如建立并维护连接、控制数据有序的传递等都会消耗一定的网络带宽。
Netperf可以模拟三种不同的TCP流量模式：
1） 单个TCP连接，批量（bulk）传输大量数据
2） 单个TCP连接，client请求/server应答的交易（transaction）方式
3） 多个TCP连接，每个连接中一对请求/应答的交易方式
UDP网络性能
UDP没有建立连接的负担，但是UDP不能保证传输的可靠性，所以使用UDP的应用程序需要自行跟踪每个发出的分组，并重发丢失的分组。
Netperf可以模拟两种UDP的流量模式：
1） 从client到server的单向批量传输
2） 请求/应答的交易方式
由于UDP传输的不可靠性，在使用netperf时要确保发送的缓冲区大小不大于接收缓冲区大小，否则数据会丢失，netperf将给出错误的结果。因此，对于接收到分组的统计不一定准确，需要结合发送分组的统计综合得出结论。
Netperf的命令行参数
在unix系统中，可以直接运行可执行程序来启动netserver，也可以让inetd或xinetd来自动启动netserver。
当netserver在server端启动以后，就可以在client端运行netperf来测试网络的性能。netperf通过命令行参数来控制 测试的类型和具体的测试选项。根据作用范围的不同，netperf的命令行参数可以分为两大类：全局命令行参数、测试相关的局部参数，两者之间使用–分 隔：
netperf [global options]– [test-specific options]
这里我们只解释那些常用的命令行参数，其它的参数读者可以查询netperf的man手册。
-H host ：指定远端运行netserver的server IP地址。
-l testlen：指定测试的时间长度（秒）
-t testname：指定进行的测试类型，包括TCP_STREAM，UDP_STREAM，TCP_RR，TCP_CRR，UDP_RR，在下文中分别对它们说明。
在后面的测试中，netserver运行在192.168.0.28，server与client通过局域网连接（100M Hub）。
Netperf测试网络性能
测试批量（bulk）网络流量的性能
批量数据传输典型的例子有ftp和其它类似的网络应用（即一次传输整个文件）。根据使用传输协议的不同，批量数据传输又分为TCP批量传输和UDP批量传输。
1． TCP_STREAM
Netperf缺省情况下进行TCP批量传输，即-t TCP_STREAM。测试过程中，netperf向netserver发送批量的TCP数据分组，以确定数据传输过程中的吞吐量：
./netperf -H 192.168.0.28 -l 60
TCP STREAM TEST to 192.168.0.28
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.00 88.00 |
从netperf的结果输出中，我们可以知道以下的一些信息：
1） 远端系统（即server）使用大小为87380字节的socket接收缓冲
2） 本地系统（即client）使用大小为16384字节的socket发送缓冲
3） 向远端系统发送的测试分组大小为16384字节
4） 测试经历的时间为60秒
5） 吞吐量的测试结果为88Mbits/秒
在缺省情况下，netperf向发送的测试分组大小设置为本地系统所使用的socket发送缓冲大小。
TCP_STREAM方式下与测试相关的局部参数如下表所示：
参数 说明
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-m size 设置本地系统发送测试分组的大小
-M size 设置远端系统接收测试分组的大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项
通过修改以上的参数，并观察结果的变化，我们可以确定是什么因素影响了连接的吞吐量。例如，如果怀疑路由器由于缺乏足够的缓冲区空间，使得转发大的分组时存在问题，就可以增加测试分组（-m）的大小，以观察吞吐量的变化：
./netperf -H 192.168.0.28 -l 60 – -m 2048
TCP STREAM TEST to 192.168.0.28
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 2048 60.00 87.62 |
在这里，测试分组的大小减少到2048字节，而吞吐量却没有很大的变化（与前面例子中测试分组大小为16K字节相比）。相反，如果吞吐量有了较大的提升，则说明在网络中间的路由器确实存在缓冲区的问题。
2． UDP_STREAM
UDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是，此时测试分组的大小不得大于socket的发送与接收缓冲大小，否则netperf会报出错提示：
./netperf -t UDP_STREAM -H 192.168.0.28 -l 60
UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28
udp_send: data send error: Message too long
为了避免这样的情况，可以通过命令行参数限定测试分组的大小，或者增加socket的发送/接收缓冲大小。UDP_STREAM方式使用与TCP_STREAM方式相同的局部命令行参数，因此，这里可以使用-m来修改测试中使用分组的大小：
./netperf -t UDP_STREAM -H 192.168.0.28 – -m 1024
UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
65535 1024 9.99 114127 0 93.55
65535 9.99 114122 93.54 |
UDP_STREAM方式的结果中有两行测试数据，第一行显示的是本地系统的发送统计，这里的吞吐量表示netperf向本地socket发送分组的能力。但是，我们知道，UDP是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。
第二行显示的就是远端系统接收的情况，由于client与server直接连接在一起，而且网络中没有其它的流量，所以本地系统发送过去的分组几乎 都被远端系统正确的接收了，远端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是，在实际环境中，一般远端系统的socket缓冲大小不同于本地系统的 socket缓冲区大小，而且由于UDP协议的不可靠性，远端系统的接收吞吐量要远远小于发送出去的吞吐量。
测试请求/应答（request/response）网络流量的性能
另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易（transaction）中，client向server发出小的查询分组，server接收到请求，经处理后返回大的结果数据。如下图所示：
1． TCP_RR
TCP_RR方式的测试对象是多次TCP request和response的交易过程，但是它们发生在同一个TCP连接中，这种模式常常出现在数据库应用中。数据库的client程序与server程序建立一个TCP连接以后，就在这个连接中传送数据库的多次交易过程。
./netperf -t TCP_RR -H 192.168.0.28
TCP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 1 1 10.00 9502.73
16384 87380 |
Netperf输出的结果也是由两行组成。第一行显示本地系统的情况，第二行显示的是远端系统的信息。平均的交易率（transaction rate）为9502.73次/秒。注意到这里每次交易中的request和response分组的大小都为1个字节，不具有很大的实际意义。用户可以通 过测试相关的参数来改变request和response分组的大小，TCP_RR方式下的参数如下表所示：
参数 说明
-r req,resp 设置request和reponse分组的大小
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项
通过使用-r参数，我们可以进行更有实际意义的测试：
./netperf -t TCP_RR -H 192.168.0.28 – -r 32,1024
TCP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 32 1024 10.00 4945.97
16384 87380 |
从结果中可以看出，由于request/reponse分组的大小增加了，导致了交易率明显的下降。注：相对于实际的系统，这里交易率的计算没有充分考虑到交易过程中的应用程序处理时延，因此结果往往会高于实际情况。
2． TCP_CRR
与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP，每次HTTP交易是在一条单独的TCP连接中进行的。因此，由于需要不停地建立新的TCP连接，并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。
./netperf -t TCP_CRR -H 192.168.0.28
TCP Connect/Request/Response TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
131070 131070 1 1 9.99 2662.20
16384 87380 |
即使是使用一个字节的request/response分组，交易率也明显的降低了，只有2662.20次/秒。TCP_CRR使用与TCP_RR相同的局部参数。
3． UDP_RR
UDP_RR方式使用UDP分组进行request/response的交易过程。由于没有TCP连接所带来的负担，所以我们推测交易率一定会有相应的提升。
./netperf -t UDP_RR -H 192.168.0.28
UDP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
65535 65535 1 1 9.99 10141.16
65535 65535 |
结果证实了我们的推测，交易率为10141.16次/秒，高过TCP_RR的数值。不过，如果出现了相反的结果，即交易率反而降低了，也不需要担心，因为这说明了在网络中，路由器或其它的网络设备对UDP采用了与TCP不同的缓冲区空间和处理技术。
——————————————————————————–
结束语
除了netperf以外，还有很多其它的网络性能测试工具，如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。这些工具有其各自的特色和不同的侧重点，我们可以根据具体的应用环境，有选择的使用它们，这样就可以使这些工具发挥出最大的功效。虽然都是开 放源代码的软件，但是这些工具的功能与商业的网络测试工具同样强大，而且也得到了广泛的应用，熟悉这些工具对我们的实际工作一定会有很大的帮助。

启动防火墙
1) 重启后生效
开启： chkconfig iptables on
关闭： chkconfig iptables off
2) 即时生效，重启后失效
开启： service iptables start
关闭： service iptables stop
需要说明的是对于Linux下的其它服务都可以用以上命令执行开启和关闭操作。
在开启了防火墙时，做如下设置，开启相关端口。
修改/etc/sysconfig/iptables 文件，添加以下内容：
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 80 -j ACCEPT
-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 22 -j ACCEPT
查看所有进程，包括服务，命令里ps -aux是netconfig在redhat里面是字符界面下的网卡配置工具。
chkconfig –list
可以列出sysV和xinet服务在各个runlevel的默认启动状态。
service 服务名 参数
查看状态的参数好像是status 吧。
自启动服务