别人或命运弄痛我的时候 我一定会大笑 我不认输

发布新日志

  • 接口测试注意事项

    agatha1113 发布于 2013-06-05 17:02:21


    接口测试主要考虑的问题:

    1.各个模块连接集成起来的时候,穿越模块接口的数据会不会丢失;  -----确定数据完整

    2.各个子功能组合起来,能否达到预期要求的父功能;   ------集合后，达到需求目标

    3.一个模块的功能是否对另一个模块的功能产生不利影响; -----集成后，不影响相关模块功能

    4.全局数据结构是否有问题;                     ------集成后，保证系统数据的正确性

    5.单个模块的误差积累起来,是否会放大,从而达到不可接受的程度。 -------集成后，确保误差不影响系统功能及性能     

    Service层接口测试，大致有三种测试类型：接口逻辑测试、出错测试、路径测试
    接口逻辑测试，对开发人员输写的JavaDoc进行测试，后根据JavaDoc来编写测试用例，（一般情况下JavaDoc需要包含前提条件，业务逻辑，输入参数，输出值的描述），在接口逻辑测试中主要是根据所描述的业务逻辑，进行用例的设计，主要目标是测试在正常输入的情况下能得出正确的结果，测试用例的设计方法跟黑盒测试差不多，主要运用等价类，边界值两种方法。
    出错测试，做了接口逻辑测试后，可以正常使用了。为了保证数据的安全，及程序在异常情况的逻辑正确性，因此需要测试出错测试。出错测试主要考虑：空值输入（如当传入一个对象参数时，需进行NULL值的参数）、参数属性的测试（如输入一个未赋值参数）、异常的测试（制造一些异常的测试场景，测试的异常描述是否清晰）
    路径测试，经过了上述处理后，单个的接口服务已经得到了保证，但是在业务流中是否满足了业务需求其实还是没有得到保证，路径测试的目的就是设计尽可能少的用例，来保证各种业务场景下数据是安全可操作的。

    6 接口测试
    在很多情况下，web 站点不是孤立。Web 站点可能会与外部服务器通讯，请求数据、验证数据或提交订单。
    6.1服务器接口
    第一个需要测试的接口是浏览器与服务器的接口。测试人员提交事务，然后查看服务器记录，并验证在浏览器上看到的正好是服务器上发生的。测试人员还可以查询数据库，确认事务数据已正确保存。
    这种测试可以归到功能测试中的表单测试和数据校验测试中
    6.2 外部接口
    有些 web 系统有外部接口。例如，网上商店可能要实时验证信用卡数据以减少欺诈行为的发生。测试的时候，要使用 web 接口发送一些事务数据，分别对有效信用卡、无效信用卡和被盗信用卡进行验证。如果商店只使用 Visa 卡和 Mastercard 卡， 可以尝试使用 Discover 卡的数据。(简单的客户端脚本能够在提交事务之前对代码进行识别，例如 3 表示 American Express，4 表示 Visa，5 表示 Mastercard，6 代表Discover。)通常，测试人员需要确认软件能够处理外部服务器返回的所有可能的消息。
    这种情况在远程抄表中可能会体现到
    6.3 错误处理
    最容易被 测试人员忽略的地方是接口错误处理。通常我们试图确认系统能够处理所有错误，但却无法预期系统所有可能的错误。尝试在处理过程中中断事务，看看会发生什么情况？订单是否完成？尝试中断用户到服务器的网络连接。尝试中断 web 服务器到信用卡验证服务器的连接。在这些情况下，系统能否正确处理这些错误？是否已对信用卡进行收费？如果用户自己中断事务处理，在订单已保存而用户没有返回网站确认的时候，需要由客户代表致电用户进行订单确认。
    采取措施：在理解需求的基础上，充分发挥想象力，尽量比较全面的列出各种异常情况。


    查看(8143) 评论(1) 收藏 分享 管理

  • Web性能测试术语

    piaolingxue423 发布于 2008-10-10 13:19:25

    WEB性能测试主要通过自动化的测试工具模拟多种正常,峰值以及异常负载条件来对系统的各项性能指标进行测试.WEB性能测试中出现频繁的术语主要有并发用户，并发用户数量，请求响应时间，事务响应时间，吞吐量，吞吐率，TPS，点击率，资源利用率等。

    　　并发用户：并发一般分为2种情况。一种是严格意义上的并发，即所有的用户在同一时刻做

    同一件事情或者操作，这种操作一般指做同一类型的业务。比如在信用卡审批业务中，一定数

    目的用户在同一时刻对已经完成的审批业务进行提交；还有一种特例，即所有用户进行完全一

    样的操作，例如在信用卡审批业务中，所有的用户可以一起申请业务，或者修改同一条记录。

    　　另外一种并发是广义范围的并发。这种并发与前一种并发的区别是，尽管多个用户对系统

    发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。对整个

    系统而言，仍然是有很多用户同时对系统进行操作，因此也属于并发的范畴。

    　　可以看出，后一种并发是包含前一种并发的。而且后一种并发更接近用户的实际使用情况

    ，因此对于大多数的系统，只有数量很少的用户进行“严格意义上的并发 ”。对于WEB性能测

    试而言，这2种并发情况一般都需要进行测试，通常做法是先进行严格意义上的并发测试。严格

    意义上的用户并发一般发生在使用比较频繁的模块中，尽管发生的概率不是很大，但是一旦发

    生性能问题，后果很可能是致命的。严格意义上的并发测试往往和功能测试关联起来，因为并

    发功能遇到异常通常都是程序问题，这种测试也是健壮性和稳定性测试的一部分。

    　　用户并发数量：关于用户并发的数量，有2种常见的错误观点。一种错误观点是把并发用户

    数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；还有一种比较接

    近正确的观点是把在线用户数量理解为并发用户数量。实际上在线用户也不一定会和其他用户

    发生并发，例如正在浏览网页的用户，对服务器没有任何影响，但是，在线用户数量是计算并

    发用户数量的主要依据之一。

    　　请求响应时间：指的是客户端发出请求到得到响应的整个过程的时间。在某些工具中，请

    求响应时间通常会被成为"TLLB"，即"Time to last byte"，意思是从发起一个请求开始，到客

    户端接收到最后一个字节的响应时间所耗费的时间。请求响应时间过程的单位一般为"秒"或者"

    毫秒"。

    　　事务响应时间：事务可能由一系列请求组成，事务的响应时间主要是针对用户而言，属于

    宏观上的概念，是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就

    是由一系列的请求组成的。事务响应时间和后面的业务吞吐率都是直接衡量系统性能的参数。

    　　吞吐量：指的是在一次性能测试过程中网络上传输的数据量的总和。吞吐量/传输时间，就

    是吞吐率。

    　　TPS：每秒钟系统能够处理的交易或者事务的数量。它是衡量系统处理能力的重要指标。

    　　点击率：每秒钟用户向WEB服务器提交的HTTP请求数。这个指标是WEB应用特有的一个指标

    ：WEB应用是"请求-响应"模式， 用户发出一次申请，服务器就要处理一次，所以点击是WEB应

    用能够处理的交易的最小单位。如果把每次点击定义为一个交易，点击率和TPS就是一个概念。

    容易看出，点击率越大，对服务器的压力越大。点击率只是一个性能参考指标，重要的是分析

    点击时产生的影响。需要注意的是，这里的点击并非指鼠标的一次单击操作，因为在一次单击

    操作中，客户端可能向服务器发出多个HTTP请求。

    　　资源利用率：指的是对不同的系统资源的使用程度，例如服务器的CPU利用率，磁盘利用率

    等。资源利用率是分析系统性能指标进而改善性能的主要依据，因此是WEB性能测试工作的重点

    。

    　　资源利用率主要针对WEB服务器，操作系统，数据库服务器，网络等，是测试和分析瓶颈的

    主要参考。在WEB性能测试中，更根据需要采集相应的参数进行分析。


    查看(516) 评论(0) 收藏 分享 管理

  • 性能测试监控点

    zcq 发布于 2008-12-22 11:12:46

    Unix主机

    • CPU使用率；
    • 内存使用状况；
    • Disk I/O；
    数据库服务器
    • Cache命中
    • Long Transaction
    • 索引使用情况
    • 数据库进程CPU使用状况
    • 数据库内存使用状况
    • 数据库连接数量
    应用服务器
    • MQ的主要进程内存使用状况
    • MQ的进程数量
    • TEMIP主要进程内存使用状况
    WEB服务器
    • 进程的CPU和内存使用状况
    • Cache命中
    • 平均响应时间等
    对这些内容的记录需要通过操作系统提供的性能观测工具或是应用自身提供的性能观测工具：
    1. 在Unix环境中，可以用top、vmstat、iostat程序观察需要记录的内容，更好的方法是自己写一个简单脚本，把时间信息和输出信息一同存入本地日志文件。在本测试中，我们用Perl和Unix的Shell脚本实现了对输出信息的抽取和格式化，生成的记录文件可以方便地被Excel等程序进行处理；
    2. 对于数据库环境，可以用Oracle自带的性能监测工具或是第三方软件（如TOAD等）观察性能并存成文件；
    3. 对WEB服务器，可以用WEB Server自带的性能监测工具监测其性能。

    查看(148) 评论(0)

  • 性能测试续2 基准测试

    2007-6-07

    基准测试
    基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。

    图1.随着负载的增加，系统吞吐量的曲线（单位：页面/秒）
    注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。
    在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。



    图2. 随着负载的增加，系统执行队列长度的曲线
    注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。
    当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。



    图3. 随着负载的增加，系统中两个事务的响应时间曲线
    注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。
    为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。
    您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。



    图4. flat测试的情况（所有的用户都是同时加载的）
    与此相对应的是“ramp-up”测试。



    图5. ramp-up测试的情况（在测试期间，用户以稳定速度（每秒x个）增加）
    ramp-up    测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。
    这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。
    Flat    测试的问题是系统会遇到“波动”效果。



    图6. 一次flat测试中所测得的系统吞吐量的曲线（单位：页面/秒）
    注意波动的出现，吞吐量不再是平滑的。
    这在系统的各个方面都有所体现，包括CPU的使用量。



    图7. 一次flat测试中所测得的系统CPU使用量随时间变化的曲线
    注意，每隔一段时间就会出现一个波形。CPU使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。
    此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。



    图8. 一次flat测试中所测得的系统执行队列的曲线
    注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。
    最后，系统中事务的响应时间也遵循着这个波动模式。



    图9. 一次flat测试中所测得的系统事务的响应时间
    注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。
    当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。
    性能规划测试
    对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。
    要确定系统的容量，需要考虑几个因素。通常，服务器的用户总数非常大（以十万计），但是实际上，这个数字并不能说明什么。真正需要知道的是，这些用户中有多少是并发与服务器通信的。其次要知道的是，每个用户的“考虑时间”即请求间时间是多少。这非常重要，因为考虑时间越短，系统所能支持的并发用户越少。例如，如果用户的考虑时间是1秒，那么系统可能只能支持数百个这样的并发用户。但是，如果用户的考虑时间是30秒，那么系统则可能支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。
    于是就引入了随机性。如果知道普通用户的考虑时间是5秒，误差为20%，那么在设计负载测试时，就要确保请求间的时间为5×（1 +/- 20%）秒。此外，可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1 +/- 25%）秒），然后再继续执行下一套请求。将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。
    现在该进行实际的容量规划测试了。接下来的问题是：如何加载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个用户。或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如，如果进行ramp-up类型的测试，系统可以以4秒或更短的响应时间支持5,000个用户。而执行flat测试，您会发现，对于5,000个用户，系统的平均响应时间要大于4秒。这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。
    这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up 查看(581) 评论(0) 收藏 分享 管理

  • 转载性能测试的学习点

    风过无痕 发布于 2008-09-12 11:16:17

    请在文本框输入文字
    如果想真的做好性能测试，需要学习的东西还是比较多的。简单列一下吧。

    1. 精通性能测试的基本概念，过程，方法论，了解性能工程；
    2. 精通1个商业性能测试工具+1个开源性能测试工具，知道工具可以做什么，不可以做什么，以及工具使用中常见的问题和解决思路；
    3. 扎实的计算机专业基础知识，包括计算机组成原理、操作系统、数据库原理、计算机网络原理；
    4. 熟悉至少1个常用的数据库产品，例如SQL Server或者 Oracle，能进行一般的数据库管理操作，熟悉SQL脚本的使用，熟悉常用的数据调优工具和常用的counter；
    5. 熟悉至少一个操作系统的原理，Windows或者Linux都可以，熟悉操作系统的体系架构、操作系统的重要基础概念，以及内存管理、存储/文件系统、驱动/硬件的管理、网络协议的实现及构成、性能的监控方法和原理，熟悉常用的counter；
    6. 熟悉至少一个web server 产品，例如apache，了解一般的配置和常用的counter；
    7. 熟悉至少一个应用服务器产品，例如tomcat，了解一般的配置，熟悉常用的服务器性能监控方法和原理，熟悉常用的counter；
    8. 至少熟悉TCP/IP协议，熟悉HTTP协议，至少见过并了解三层、四层交换或者路由器的使用和配置。了解常用的与网络性能相关的counter；
    9. 了解一般的大型企业应用的部署架构和应用架构；
    10. 了解知名大型web应用、高并发量、高流量、实时响应要求高的超大规模网站的架构和优化历程；
    11. 熟悉统计学的基础知识、常用分析方法以及实验设计方法，了解数学建模相关的知识；
    12. 熟悉专属行业的业务知识和用户场景，例如电信行业的OSS系统所涉及的业务知识和用户场景，证券交易系统所涉及的业务知识和用户场景；
    13. 大量的实际性能测试及优化经验；
    14. 积极的参与到各类圈子、社团的讨论和交流、分享中。

    查看(454) 评论(1) 收藏 分享 管理

  • 性能测试

    zcq 发布于 2008-12-22 11:12:46

    性能测试


          性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。 

    一、概述

          性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。

        ·应用在客户端性能的测试

    　　应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。

          并发性能测试是重点

    　　并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接收的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试（Load Testing）是确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相应输出项，例如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接收的性能过程。压力测试（Stress Testing）是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

    　　并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

    　　当一家企业自己组织力量或委托软件公司代为开发一套应用系统的时候,尤其是以后在生产环境中实际使用起来,用户往往会产生疑问,这套系统能不能承受大量的并发用户同时访问? 这类问题最常见于采用联机事务处理(OLTP)方式数据库应用、Web浏览和视频点播等系统。这种问题的解决要借助于科学的软件测试手段和先进的测试工具。

          举例说明：电信计费软件

    　　众所周知,每月20日左右是市话交费的高峰期，全市几千个收费网点同时启动。收费过程一般分为两步,首先要根据用户提出的电话号码来查询出其当月产生费用,然后收取现金并将此用户修改为已交费状态。一个用户看起来简单的两个步骤,但当成百上千的终端，同时执行这样的操作时，情况就大不一样了,如此众多的交易同时发生,对应用程序本身、操作系统、中心数据库服务器、中间件服务器、网络设备的承受力都是一个严峻的考验。决策者不可能在发生问题后才考虑系统的承受力, 预见软件的并发承受力, 这是在软件测试阶段就应该解决的问题。

    　　目前，大多数公司企业需要支持成百上千名用户，各类应用环境以及由不同供应商提供的元件组装起来的复杂产品，难以预知的用户负载和愈来愈复杂的应用程序，使公司担忧会发生投放性能差、用户遭受反应慢、系统失灵等问题。其结果就是导致公司收益的损失。

    　　如何模拟实际情况呢? 找若干台电脑和同样数目的操作人员在同一时刻进行操作,然后拿秒表记录下反应时间？ 这样的手工作坊式的测试方法不切实际，且无法捕捉程序内部变化情况,这样就需要压力测试工具的辅助。

    　　测试的基本策略是自动负载测试，通过在一台或几台PC机上模拟成百或上千的虚拟用户同时执行业务的情景，对应用程序进行测试，同时记录下每一事务处理的时间、中间件服务器峰值数据、数据库状态等。通过可重复的、真实的测试能够彻底地度量应用的可扩展性和性能，确定问题所在以及优化系统性能。预先知道了系统的承受力,就为最终用户规划整个运行环境的配置提供了有力的依据。

          并发性能测试前的准备工作

    　　测试环境：配置测试环境是测试实施的一个重要阶段，测试环境的适合与否会严重影响测试结果的真实性和正确性。测试环境包括硬件环境和软件环境，硬件环境指测试必需的服务器、客户端、网络连接设备以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境指被测软件运行时的操作系统、数据库及其他应用软件构成的环境。

    　　一个充分准备好的测试环境有三个优点：一个稳定、可重复的测试环境，能够保证测试结果的正确；保证达到测试执行的技术需求；保证得到正确的、可重复的以及易理解的测试结果。

    　　测试工具：并发性能测试是在客户端执行的黑盒测试，一般不采用手工方式，而是利用工具采用自动化方式进行。目前，成熟的并发性能测试工具有很多，选择的依据主要是测试需求和性能价格比。著名的并发性能测试工具有QALoad、LoadRunner、Benchmark Factory和Webstress等。这些测试工具都是自动化负载测试工具，通过可重复的、真实的测试，能够彻底地度量应用的可扩展性和性能，可以在整个开发生命周期、跨越多种平台、自动执行测试任务，可以模拟成百上千的用户并发执行关键业务而完成对应用程序的测试。

    　　测试数据：在初始的测试环境中需要输入一些适当的测试数据，目的是识别数据状态并且验证用于测试的测试案例，在正式的测试开始以前对测试案例进行调试，将正式测试开始时的错误降到最低。在测试进行到关键过程环节时，非常有必要进行数据状态的备份。制造初始数据意味着将合适的数据存储下来，需要的时候恢复它，初始数据提供了一个基线用来评估测试执行的结果。

    　　在测试正式执行时，还需要准备业务测试数据，比如测试并发查询业务，那么要求对应的数据库和表中有相当的数据量以及数据的种类应能覆盖全部业务。

    　　模拟真实环境测试，有些软件，特别是面向大众的商品化软件，在测试时常常需要考察在真实环境中的表现。如测试杀毒软件的扫描速度时，硬盘上布置的不同类型文件的比例要尽量接近真实环境，这样测试出来的数据才有实际意义。

          并发性能测试的种类与指标

    　　并发性能测试的种类取决于并发性能测试工具监控的对象，以QALoad自动化负载测试工具为例。软件针对各种测试目标提供了DB2、DCOM、ODBC、ORACLE、NETLoad、Corba、QARun、SAP、SQLServer、Sybase、Telnet、TUXEDO、UNIFACE、WinSock、WWW、Java scrīpt等不同的监控对象，支持Windows和UNIX测试环境。

    　　最关键的仍然是测试过程中对监控对象的灵活应用，例如目前三层结构的运行模式广泛使用，对中间件的并发性能测试作为问题被提到议事日程上来，许多系统都采用了国产中间件，选择Java scrīpt监控对象，手工编写脚本，可以达到测试目的。

    　　采用自动化负载测试工具执行的并发性能测试，基本遵循的测试过程有：测试需求与测试内容，测试案例制定，测试环境准备，测试脚本录制、编写与调试，脚本分配、回放配置与加载策略，测试执行跟踪，结果分析与定位问题所在，测试报告与测试评估。

    　　并发性能测试监控的对象不同，测试的主要指标也不相同，主要的测试指标包括交易处理性能指标和 UNIX资源监控。其中，交易处理性能指标包括交易结果、每分钟交易数、交易响应时间（Min：最小服务器响应时间；Mean：平均服务器响应时间；Max：最大服务器响应时间；StdDev：事务处理服务器响应的偏差，值越大，偏差越大；Median：中值响应时间；90％：90％事务处理的服务器响应时间）、虚拟并发用户数。

          应用实例：“新华社多媒体数据库 V1.0”性能测试

    　　中国软件评测中心（CSTC）根据新华社技术局提出的《多媒体数据库（一期）性能测试需求》和GB/T 17544《软件包质量要求和测试》的国家标准，使用工业标准级负载测试工具对新华社使用的“新华社多媒体数据库 V1.0”进行了性能测试。

    　　性能测试的目的是模拟多用户并发访问新华社多媒体数据库，执行关键检索业务，分析系统性能。

    　　性能测试的重点是针对系统并发压力负载较大的主要检索业务，进行并发测试和疲劳测试，系统采用B/S运行模式。并发测试设计了特定时间段内分别在中文库、英文库、图片库中进行单检索词、多检索词以及变检索式、混合检索业务等并发测试案例。疲劳测试案例为在中文库中并发用户数200，进行测试周期约8小时的单检索词检索。在进行并发和疲劳测试的同时，监测的测试指标包括交易处理性能以及 UNIX（Linux）、Oracle、Apache资源等。

    　　测试结论：在新华社机房测试环境和内网测试环境中，100M带宽情况下，针对规定的各并发测试案例，系统能够承受并发用户数为200的负载压力，最大交易数/分钟达到78.73，运行基本稳定，但随着负载压力增大，系统性能有所衰减。

    　　系统能够承受200并发用户数持续周期约8小时的疲劳压力，基本能够稳定运行。

    　　通过对系统UNIX（Linux）、Oracle和Apache资源的监控，系统资源能够满足上述并发和疲劳性能需求，且系统硬件资源尚有较大利用余地。

    　　当并发用户数超过200时，监控到HTTP 500、connect和超时错误，且Web服务器报内存溢出错误，系统应进一步提高性能，以支持更大并发用户数。

    　　建议进一步优化软件系统，充分利用硬件资源，缩短交易响应时间。

          疲劳强度与大数据量测试

    　　疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。

    　　疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占的比例较大。

    　　一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。

    　　大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。

    　　速度测试目前主要是针对关键有速度要求的业务进行手工测速度，可以在多次测试的基础上求平均值，可以和工具测得的响应时间等指标做对比分析。

          ·应用在网络上性能的测试

    　　应用在网络上性能的测试重点是利用成熟先进的自动化技术进行网络应用性能监控、网络应用性能分析和网络预测。

          网络应用性能分析

    　　网络应用性能分析的目的是准确展示网络带宽、延迟、负载和TCP端口的变化是如何影响用户的响应时间的。利用网络应用性能分析工具，例如Application Expert，能够发现应用的瓶颈，我们可知应用在网络上运行时在每个阶段发生的应用行为，在应用线程级分析应用的问题。可以解决多种问题：客户端是否对数据库服务器运行了不必要的请求？当服务器从客户端接受了一个查询，应用服务器是否花费了不可接受的时间联系数据库服务器？在投产前预测应用的响应时间；利用Application Expert调整应用在广域网上的性能；Application Expert能够让你快速、容易地仿真应用性能，根据最终用户在不同网络配置环境下的响应时间，用户可以根据自己的条件决定应用投产的网络环境。

          网络应用性能监控

    　　在系统试运行之后，需要及时准确地了解网络上正在发生什么事情；什么应用在运行，如何运行；多少PC正在访问LAN或WAN；哪些应用程序导致系统瓶颈或资源竞争，这时网络应用性能监控以及网络资源管理对系统的正常稳定运行是非常关键的。利用网络应用性能监控工具，可以达到事半功倍的效果，在这方面我们可以提供的工具是Network Vantage。通俗地讲，它主要用来分析关键应用程序的性能，定位问题的根源是在客户端、服务器、应用程序还是网络。在大多数情况下用户较关心的问题还有哪些应用程序占用大量带宽，哪些用户产生了最大的网络流量，这个工具同样能满足要求。

          网络预测

    　　考虑到系统未来发展的扩展性，预测网络流量的变化、网络结构的变化对用户系统的影响非常重要。根据规划数据进行预测并及时提供网络性能预测数据。我们利用网络预测分析容量规划工具PREDICTOR可以作到：设置服务水平、完成日网络容量规划、离线测试网络、网络失效和容量极限分析、完成日常故障诊断、预测网络设备迁移和网络设备升级对整个网络的影响。

    　　从网络管理软件获取网络拓扑结构、从现有的流量监控软件获取流量信息（若没有这类软件可人工生成流量数据），这样可以得到现有网络的基本结构。在基本结构的基础上，可根据网络结构的变化、网络流量的变化生成报告和图表，说明这些变化是如何影响网络性能的。 PREDICTOR提供如下信息：根据预测的结果帮助用户及时升级网络，避免因关键设备超过利用阀值导致系统性能下降；哪个网络设备需要升级，这样可减少网络延迟、避免网络瓶颈；根据预测的结果避免不必要的网络升级。

          ·应用在服务器上性能的测试

    　　对于应用在服务器上性能的测试，可以采用工具监控，也可以使用系统本身的监控命令，例如Tuxedo中可以使用Top命令监控资源使用情况。实施测试的目的是实现服务器设备、服务器操作系统、数据库系统、应用在服务器上性能的全面监控，测试原理如下图。

    UNIX资源监控指标和描述

    　　监控指标 描述
    　　平均负载 系统正常状态下，最后60秒同步进程的平均个数
    　　冲突率 在以太网上监测到的每秒冲突数
    　　进程/线程交换率 进程和线程之间每秒交换次数
    　　CPU利用率 CPU占用率（％）
    　　磁盘交换率 磁盘交换速率
    　　接收包错误率 接收以太网数据包时每秒错误数
    　　包输入率 每秒输入的以太网数据包数目
    　　中断速率 CPU每秒处理的中断数
    　　输出包错误率 发送以太网数据包时每秒错误数
    　　包输入率 每秒输出的以太网数据包数目
    　　读入内存页速率 物理内存中每秒读入内存页的数目
    　　写出内存页速率 每秒从物理内存中写到页文件中的内存页数
    　　 目或者从物理内存中删掉的内存页数目
    　　内存页交换速率 每秒写入内存页和从物理内存中读出页的个数
    　　进程入交换率 交换区输入的进程数目
    　　进程出交换率 交换区输出的进程数目
    　　系统CPU利用率 系统的CPU占用率（％）
    　　用户CPU利用率 用户模式下的CPU占用率（％）
    　　磁盘阻塞 磁盘每秒阻塞的字节数

    二、为什么进行性能测试？

          目的是验证软件系统是否能够达到用户提出的性能指标，同时发现软件系统中存在的性能瓶颈，优化软件，最后起到优化系统的目的。

          包括以下几个方面

    1．评估系统的能力，测试中得到的负荷和响应时间数据可以被用于验证所计划的模型的能力，并帮助作出决策。
    2．识别体系中的弱点：受控的负荷可以被增加到一个极端的水平，并突破它，从而修复体系的瓶颈或薄弱的地方。
    3．系统调优：重复运行测试，验证调整系统的活动得到了预期的结果，从而改进性能。
    检测软件中的问题：长时间的测试执行可导致程序发生由于内存泄露引起的失败，揭示程序中的隐含的问题或冲突。
    4．验证稳定性（resilience）可靠性（reliability）：在一个生产负荷下执行测试一定的时间是评估系统稳定性和可靠性是否满足要求的唯一方法。

          性能测试类型包括负载测试，强度测试，容量测试等

          负载测试：负载测试是一种性能测试指数据在超负荷环境中运行，程序是否能够承担。

          强度测试： 强度测试是一种性能测试，他在系统资源特别低的情况下软件系统运行情况。

          容量测试：确定系统可处理同时在线的最大用户数  

          观察指标：

          性能测试主要是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。

          在实际中作中我们经常会对两种类型软件进行测试：bs和cs，这两方面的性能指标一般需要哪些内容呢？

    Bs结构程序一般会关注的通用指标如下（简）：

    Web服务器指标指标：

    * Avg Rps: 平均每秒钟响应次数＝总请求时间 / 秒数；

    * Avg time to last byte per terstion （mstes）:平均每秒业务角本的迭代次数 ,有人会把这两者混淆；

    * Successful Rounds：成功的请求；

    * Failed Rounds ：失败的请求；

    * Successful Hits ：成功的点击次数；

    * Failed Hits ：失败的点击次数；

    * Hits Per Second ：每秒点击次数；

    * Successful Hits Per Second ：每秒成功的点击次数；

    * Failed Hits Per Second ：每秒失败的点击次数；

    * Attempted Connections ：尝试链接数；

    CS结构程序，由于一般软件后台通常为数据库，所以我们更注重数据库的测试指标：

    * User 0 Connections ：用户连接数，也就是数据库的连接数量；

    * Number of deadlocks：数据库死锁；

    * Butter Cache hit ：数据库Cache的命中情况

          当然，在实际中我们还会察看多用户测试情况下的内存，CPU，系统资源调用情况。这些指标其实是引申出来性能测试中的一种：竞争测试。什么是竞争测试，软件竞争使用各种资源（数据纪录，内存等），看他与其他相关系统对资源的争夺能力。

          我们知道软件架构在实际测试中制约着测试策略和工具的选择。如何选择性能测试策略是我们在实际工作中需要了解的。一般软件可以按照系统架构分成几种类型：

    c/s

    client/Server 客户端/服务器架构

    基于客户端/服务器的三层架构

    基于客户端/服务器的分布式架构

    b/s

    基于浏览器/Web服务器的三层架构

    基于中间件应用服务器的三层架构l

    基于Web服务器和中间件的多层架构l


     
    三、性能测试的步骤

          在每种不同的系统架构的实施中，开发人员可能选择不同的实现方式，造成实际情况纷繁复杂。我们不可能对每种技术都详细解说，这里只是介绍一种方法提供给你如何选择测试策略，从而帮助分析软件不同部分的性能指标，进而分析出整体架构的性能指标和性能瓶颈。

          由于工程和项目的不同，所选用的度量,评估方法也有不同之处。不过仍然有一些通用的步骤帮助我们完成一个性能测试项目。步骤如下

    1．  制定目标和分析系统
    2．  选择测试度量的方法
    3．  学习的相关技术和工具
    4．  制定评估标准
    5．  设计测试用例
    6．  运行测试用例
    7．  分析测试结果

    ·制定目标和分析系统

        每一个性能测试计划中第一步都会制定目标和分析系统构成。只有明确目标和了解系统构成才会澄清测试范围，知道在测试中要掌握什么样的技术。   

    目标：

    1．  确定客户需求和期望

    2．  实际业务需求

    3．  系统需求

    系统组成

        系统组成这里包含几方面含义：系统类别，系统构成，系统功能等。了解这些内容的本质其实是帮助我们明确测试的范围，选者适当的测试方法来进行测试。

        系统类别：分清系统类别是我们掌握什么样的技术的前提，掌握相应技术做性能测试才可能成功。例如：系统类别是bs结构,需要掌握 http协议，java，html等技术 。或者是cs结构，可能要了解操作系统，winsock，com等。所以甄别系统类别对于我们来说很重要。

        系统构成：硬件设置，操作系统设置是性能测试的制约条件，一般性能测试都是利用测试工具模仿大量的实际用户操作，系统在超负荷情形下运作。不同的系统构成性能测试就会得到不同的结果。

        系统功能：系统功能指系统提供的不同子系统，办公管理系统中的公文子系统，会议子系统等，系统工能是性能测试中要模拟的环节，了解这些是必要的。

    ·选择测试度量的方法

    经过第一步，将会对系统有清醒的认识。接下来我们将把精力放在软件度量上，收集系统相关的数据。

    度量的相关方面：

    * 制定规范

    * 制定相关流程, 角色，职责

    * 制定改进策略

    * 制定结果对比标准

    ·学习的相关技术和工具

         性能测试是通过工具，模拟大量用户操作，对系统增加负载。所以需要掌握一定的工具知识才能进行性能测试。大家都知道性能测试工具一般通过 winsock,http等协议纪录用户操作。而协议选择是基于软件的系统架构实现（web一般选择http协议,cs选择winsock协议），不同的性能测试工具，脚本语言也不同，比如rational robot中vu脚本用类c语言实现。

          开展性能测试需要对各种性能测试工具进行评估，因为每一种性能测试工具都有自身的特点，只有经过工具评估，才能选择符合现有软件架构的性能测试工具。确定测试工具后，需要组织测试人员进行工具的学习，培训相关技术。

    ·制定评估标准

             任何测试的目的都是确保软件符合预先规定的目标和要求。性能测试也不例外。所以必须制定一套标准。

          通常性能测试有四种模型技术可用于评估：

             *线性投射：用大量的过去的，扩展的或者将来可能发生的数据组成散布图，利用这个图表不断和系统的当前状况对比。

             *分析模型：用排队论公式和算法预测响应时间，利用描述工作量的数据和系统本质关联起来

             *模仿：模仿实际用户的使用方法测试你的系统

             *基准：定义测试和你最初的测试作为标准，利用它和所有后来进行的测试结果进行对比

    ·设计测试用例

        设计测试用例是在了解软件业务流程的基础上。设计测试用例的原则是受最小的影响提供最多的测试信息，设计测试用例的目标是一次尽可能的包含多个测试要素。这些测试用例必须是测试工具可以实现的，不同的测试场景将测试不同的功能。因为性能测试不同于平时的测试用例，尽可能把性能测试用例设计的复杂，才有可能发现软件的性能瓶颈。

    ·运行测试用例

        通过性能测试工具运行测试用例。同一环境下作的性能测试得到的测试结果是不准确的，所以在运行这些测试用例的时候，需要用不同的测试环境，不同的机器配置上运行。

    ·分析测试结果

          运行测试用例后，收集相关信息，进行数据统计分析，找到性能瓶颈。通过排除误差和其他因素，让测试结果体现接近真实情况。不同的体系结构分析测试结果的方法也不同，bs结构我们会分析网络带宽，流量对用户操作响应的影响，而cs结构我们可能更关心会系统整体配置对用户操作的影响。

    四、性能测试方法

    　　对于企业应用程序，有许多进行性能测试的方法，其中一些方法实行起来要比其他方法困难。所要进行的性能测试的类型取决于想要达到的结果。例如，对于可再现性，基准测试是最好的方法。而要从当前用户负载的角度测试系统的上限，则应该使用容量规划测试。本文将介绍几种设置和运行性能测试的方法，并讨论这些方法的区别。

    　　如果不进行合理的规划，对J2EE应用程序进行性能测试将会是一项令人望而生畏且有些混乱的任务。因为对于任何的软件开发流程，都必须收集需求、理解业务需要，并在进行实际测试之前设计出正式的进度表。性能测试的需求由业务需要驱动，并由一组用例阐明。这些用例可以基于历史数据（例如，服务器一周的负载模式）或预测的近似值。弄清楚需要测试的内容之后，就需要知道如何进行测试了。

    　　在开发阶段前期，应该使用基准测试来确定应用程序中是否出现性能倒退。基准测试可以在一个相对短的时间内收集可重复的结果。进行基准测试的最好方法是，每次测试改变一个且只改变一个参数。例如，如果想知道增加JVM内存是否会影响应用程序的性能，就逐次递增JVM内存（例如，从1024 MB增至1224 MB，然后是1524 MB，最后是2024 MB），在每个阶段收集结果和环境数据，记录信息，然后转到下一阶段。这样在分析测试结果时就有迹可循。下一小节我将介绍什么是基准测试，以及运行基准测试的最佳参数。

    　　开发阶段后期，在应用程序中的bug已经被解决，应用程序达到一种稳定状态之后，可以运行更为复杂的测试，确定系统在不同的负载模式下的表现。这些测试被称为容量规划测试、渗入测试(soak test)、峰谷测试(peak-rest test)，它们旨在通过测试应用程序的可靠性、健壮性和可伸缩性来测试接近于现实世界的场景。对于下面的描述应该从抽象的意义上理解，因为每个应用程序的使用模式都是不同的。例如，容量规划测试通常都使用较缓慢的ramp-up（下文有定义），但是如果应用程序在一天之中的某个时段中有快速突发的流量，那么自然应该修改测试以反映这种情况。但是，要记住，因为更改了测试参数（比如ramp-up周期或用户的考虑时间(think-time)），测试的结果肯定也会改变。一个不错的方法是，运行一系列的基准测试，确立一个已知的可控环境，然后再对变化进行比较。

    基准测试

    　　基准测试的关键是要获得一致的、可再现的结果。可再现的结果有两个好处：减少重新运行测试的次数；对测试的产品和产生的数字更为确信。使用的性能测试工具可能会对测试结果产生很大影响。假定测试的两个指标是服务器的响应时间和吞吐量，它们会受到服务器上的负载的影响。服务器上的负载受两个因素影响：同时与服务器通信的连接（或虚拟用户）的数目，以及每个虚拟用户请求之间的考虑时间的长短。很明显，与服务器通信的用户越多，负载就越大。同样，请求之间的考虑时间越短，负载也越大。这两个因素的不同组合会产生不同的服务器负载等级。记住，随着服务器上负载的增加，吞吐量会不断攀升，直到到达一个点。


    图1.随着负载的增加，系统吞吐量的曲线（单位：页面/秒）

    　　注意，吞吐量以稳定的速度增长，然后在某一个点上稳定下来。

    　　在某一点上，执行队列开始增长，因为服务器上所有的线程都已投入使用，传入的请求不再被立即处理，而是放入队列中，当线程空闲时再处理。


    图2. 随着负载的增加，系统执行队列长度的曲线

    　　注意，最初的一段时间，执行队列的长度为零，然后就开始以稳定的速度增长。这是因为系统中的负载在稳定增长，虽然最初系统有足够的空闲线程去处理增加的负载，最终它还是不能承受，而必须将其排入队列。

    　　当系统达到饱和点，服务器吞吐量保持稳定后，就达到了给定条件下的系统上限。但是，随着服务器负载的继续增长，系统的响应时间也随之延长，虽然吞吐量保持稳定。


    图3. 随着负载的增加，系统中两个事务的响应时间曲线

    　　注意，在执行队列（图2）开始增长的同时，响应时间也开始以递增的速度增长。这是因为请求不能被及时处理。

    　　为了获得真正可再现的结果，应该将系统置于相同的高负载下。为此，与服务器通信的虚拟用户应该将请求之间的考虑时间设为零。这样服务器会立即超载，并开始构建执行队列。如果请求（虚拟用户）数保持一致，基准测试的结果应该会非常精确，完全可以再现。

    　　您可能要问的一个问题是：“如何度量结果？”对于一次给定的测试，应该取响应时间和吞吐量的平均值。精确地获得这些值的唯一方法是一次加载所有的用户，然后在预定的时间段内持续运行。这称为“flat”测试。


    图4. flat测试的情况（所有的用户都是同时加载的）

    　　与此相对应的是“ramp-up”测试。


    图5. ramp-up测试的情况（在测试期间，用户以稳定速度（每秒x个）增加）

    　　ramp-up测试中的用户是交错上升的（每几秒增加一些新用户）。ramp-up测试不能产生精确和可重现的平均值，这是因为由于用户的增加是每次一部分，系统的负载在不断地变化。因此，flat运行是获得基准测试数据的理想模式。

    　　这不是在贬低ramp-up测试的价值。实际上，ramp-up测试对找出以后要运行的flat测试的范围非常有用。ramp-up测试的优点是，可以看出随着系统负载的改变，测量值是如何改变的。然后可以据此选择以后要运行的flat测试的范围。

    　　Flat测试的问题是系统会遇到“波动”效果。


    图6. 一次flat测试中所测得的系统吞吐量的曲线（单位：页面/秒）

    　　注意波动的出现，吞吐量不再是平滑的。

    　　这在系统的各个方面都有所体现，包括CPU的使用量。


    图7. 一次flat测试中所测得的系统CPU使用量随时间变化的曲线

    　　注意，每隔一段时间就会出现一个波形。CPU使用量不再是平滑的，而是有了像吞吐量图那样的尖峰。

    　　此外，执行队列也承受着不稳定的负载，因此可以看到，随着系统负载的增加和减少，执行队列也在增长和缩减。


    图8. 一次flat测试中所测得的系统执行队列的曲线

    　　注意，每隔一段时间就会出现一个波形。执行队列曲线与上面的CPU使用量图非常相似。

    　　最后，系统中事务的响应时间也遵循着这个波动模式。


    图9. 一次flat测试中所测得的系统事务的响应时间

    　　注意，每隔一段时间就会出现一个波形。事务的响应时间也与上面的图类似，只不过其效果随着时间的推移逐渐减弱。

    　　当测试中所有的用户都同时执行几乎相同的操作时，就会发生这种现象。这将会产生非常不可靠和不精确的结果，所以必须采取一些措施防止这种情况的出现。有两种方法可以从这种类型的结果中获得精确的测量值。如果测试可以运行相当长的时间（有时是几个小时，取决于用户的操作持续的时间），最后由于随机事件的本性使然，服务器的吞吐量会被“拉平”。或者，可以只选取波形中两个平息点之间的测量值。该方法的缺点是可以捕获数据的时间非常短。

    性能规划测试

    　　对于性能规划类型的测试来说，其目标是找出，在特定的环境下，给定应用程序的性能可以达到何种程度。此时可重现性就不如在基准测试中那么重要了，因为测试中通常都会有随机因子。引入随机因子的目的是为了尽量模拟具有真实用户负载的现实世界应用程序。通常，具体的目标是找出系统在特定的服务器响应时间下支持的当前用户的最大数。例如，您可能想知道：如果要以5秒或更少的响应时间支持8,000个当前用户，需要多少个服务器？要回答这个问题，需要知道系统的更多信息。

    　　要确定系统的容量，需要考虑几个因素。通常，服务器的用户总数非常大（以十万计），但是实际上，这个数字并不能说明什么。真正需要知道的是，这些用户中有多少是并发与服务器通信的。其次要知道的是，每个用户的“考虑时间”即请求间时间是多少。这非常重要，因为考虑时间越短，系统所能支持的并发用户越少。例如，如果用户的考虑时间是1秒，那么系统可能只能支持数百个这样的并发用户。但是，如果用户的考虑时间是30秒，那么系统则可能支持数万个这样的并发用户（假定硬件和应用程序都是相同的）。在现实世界中，通常难以确定用户的确切考虑时间。还要注意，在现实世界中，用户不会精确地按照间隔时间发出请求。

    　　于是就引入了随机性。如果知道普通用户的考虑时间是5秒，误差为20%，那么在设计负载测试时，就要确保请求间的时间为5×（1 +/- 20%）秒。此外，可以利用“调步”的理念向负载场景中引入更多的随机性。它是这样的：在一个虚拟用户完成一整套的请求后，该用户暂停一个设定的时间段，或者一个小的随机时间段（例如，2×（1 +/- 25%）秒），然后再继续执行下一套请求。将这两种随机化方法运用到测试中，可以提供更接近于现实世界的场景。

    　　现在该进行实际的容量规划测试了。接下来的问题是：如何加载用户以模拟负载状态？最好的方法是模拟高峰时间用户与服务器通信的状况。这种用户负载状态是在一段时间内逐步达到的吗？如果是，应该使用ramp-up类型的测试，每隔几秒增加x个用户。或者，所有用户是在一个非常短的时间内同时与系统通信？如果是这样，就应该使用flat类型的测试，将所有的用户同时加载到服务器。两种不同类型的测试会产生没有可比性的不同测试。例如，如果进行ramp-up类型的测试，系统可以以4秒或更短的响应时间支持5,000个用户。而执行flat测试，您会发现，对于5,000个用户，系统的平均响应时间要大于4秒。这是由于ramp-up测试固有的不准确性使其不能显示系统可以支持的并发用户的精确数字。以门户应用程序为例，随着门户规模的扩大和集群规模的扩大，这种不确定性就会随之显现。

    　　这不是说不应该使用ramp-up测试。对于系统负载在一段比较长的时间内缓慢增加的情况，ramp-up测试效果还是不错的。这是因为系统能够随着时间不断调整。如果使用快速ramp-up测试，系统就会滞后，从而报告一个较相同用户负载的flat测试低的响应时间。那么，什么是确定容量的最好方法？结合两种负载类型的优点，并运行一系列的测试，就会产生最好的结果。例如，首先使用ramp-up测试确定系统可以支持的用户范围。确定了范围之后，以该范围内不同的并发用户负载进行一系列的flat测试，更精确地确定系统的容量。

    渗入测试

    　　渗入测试是一种比较简单的性能测试。渗入测试所需时间较长，它使用固定数目的并发用户测试系统的总体健壮性。这些测试将会通过内存泄漏、增加的垃圾收集(GC)或系统的其他问题，显示因长时间运行而出现的任何性能降低。测试运行的时间越久，您对系统就越了解。运行两次测试是一个好主意——一次使用较低的用户负载（要在系统容量之下，以便不会出现执行队列），一次使用较高的负载（以便出现积极的执行队列）。

    　　测试应该运行几天的时间，以便真正了解应用程序的长期健康状况。要确保测试的应用程序尽可能接近现实世界的情况，用户场景也要逼真（虚拟用户通过应用程序导航的方式要与现实世界一致），从而测试应用程序的全部特性。确保运行了所有必需的监控工具，以便精确地监测并跟踪问题。

    峰谷测试

    　　峰谷测试兼有容量规划ramp-up类型测试和渗入测试的特征。其目标是确定从高负载（例如系统高峰时间的负载）恢复、转为几乎空闲、然后再攀升到高负载、再降低的能力。

    　　实现这种测试的最好方法就是，进行一系列的快速ramp-up测试，继之以一段时间的平稳状态（取决于业务需求），然后急剧降低负载，此时可以令系统平息一下，然后再进行快速的ramp-up；反复重复这个过程。这样可以确定以下事项：第二次高峰是否重现第一次的峰值？其后的每次高峰是等于还是大于第一次的峰值？在测试过程中，系统是否显示了内存或GC性能降低的有关迹象？测试运行（不停地重复“峰值/空闲”周期）的时间越长，您对系统的长期健康状况就越了解。

    结束语

    　　本文介绍了进行性能测试的几种方法。取决于业务需求、开发周期和应用程序的生命周期，对于特定的企业，某些测试会比其他的更适合。但是，对于任何情况，在决定进行某一种测试前，都应该问自己一些基本问题。这些问题的答案将会决定哪种测试方法是最好的。

    　　这些问题包括：

    结果的可重复性需要有多高？
    测试需要运行和重新运行几次？
    您处于开放周期的哪个阶段？
    您的业务需求是什么？
    您的用户需求是什么？
    您希望生产中的系统在维护停机时间中可以持续多久？
    在一个正常的业务日，预期的用户负载是多少？
    　　将这些问题的答案与上述性能测试类型相对照，应该就可以制定出测试应用程序的总体性能的完美计划。

  • 性能测试（并发负载压力）测试分析－简要篇

    2007-6-05

    分析原则：

    • 具体问题具体分析（这是由于不同的应用系统，不同的测试目的，不同的性能关注点）
    • 查找瓶颈时按以下顺序，由易到难。
      服务器硬件瓶颈-〉网络瓶颈（对局域网，可以不考虑）-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）-〉应用瓶颈（SQL语句、数据库设计、业务逻辑、算法等）
      注：以上过程并不是每个分析中都需要的，要根据测试目的和要求来确定分析的深度。对一些要求低的，我们分析到应用系统在将来大的负载压力（并发用户数、数据量）下，系统的硬件瓶颈在哪儿就够了。
    • 分段排除法 很有效

    分析的信息来源：

    • 1 根据场景运行过程中的错误提示信息
    • 2 根据测试结果收集到的监控指标数据

    一．错误提示分析

    　分析实例：

    • Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
    • Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

    分析：

    • A、应用服务死掉。
      （小用户时：程序上的问题。程序上处理数据库的问题）
    • B、应用服务没有死
      （应用服务参数设置问题）
      例：在许多客户端连接Weblogic应用服务器被拒绝，而在服务器端没有错误显示，则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息，说明应提高该值，每次增加25％
    • C、数据库的连接
    　(1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数（跟硬件的内存有关）)
    　  2 Error: Page download timeout (120 seconds) has expired

    分析：可能是以下原因造成

    • A、应用服务参数设置太大导致服务器的瓶颈
    • B、页面中图片太多
    • C、在程序处理表的时候检查字段太大多

    二．监控指标数据分析

    　1．最大并发用户数：

    　应用系统在当前环境（硬件环境、网络环境、软件环境（参数配置））下能承受的最大并发用户数。

    　在方案运行中，如果出现了大于3个用户的业务操作失败，或出现了服务器shutdown的情况，则说明在当前环境下，系统承受不了当前并发用户的负载压力，那么最大并发用户数就是前一个没有出现这种现象的并发用户数。

    　如果测得的最大并发用户数到达了性能要求，且各服务器资源情况良好，业务操作响应时间也达到了用户要求，那么OK。否则，再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

    2．业务操作响应时间：

    • 分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图，可以确定在方案执行期间响应时间过长的事务。
    • 细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的？问题是否与网络或服务器有关？
    • 如果服务器耗时过长，请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长，请使用“网络监视器”图确定导致性能瓶颈的网络问?/li>
    　3．服务器资源监控指标：

    　内存：
    　1 UNIX资源监控中指标内存页交换速率（Paging rate），如果该值偶尔走高，表明当时有线程竞争内存。如果持续很高，则内存可能是瓶颈。也可能是内存访问命中率低。

    2 Windows资源监控中，如果Process\Private Bytes计数器和Process\Working Set计数器的值在长时间内持续升高，同时Memory\Available bytes计数器的值持续降低，则很可能存在内存泄漏。

    内存资源成为系统性能的瓶颈的征兆:
    　很高的换页率(high pageout rate);
    　进程进入不活动状态;
    　交换区所有磁盘的活动次数可高;
    　可高的全局系统CPU利用率;
    　内存不够出错(out of memory errors)

    处理器：
    　1 UNIX资源监控（Windows操作系统同理）中指标CPU占用率（CPU utilization），如果该值持续超过95%，表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。如果服务器专用于SQL Server,可接受的最大上限是80-85% 合理使用的范围在60%至70%。
    　2 Windows资源监控中，如果System\Processor Queue Length大于2，而处理器利用率（Processor Time）一直很低，则存在着处理器阻塞。

    CPU资源成为系统性能的瓶颈的征兆:
    　很慢的响应时间(slow response time)
    　CPU空闲时间为零(zero percent idle CPU)
    　过高的用户占用CPU时间(high percent user CPU)
    　过高的系统占用CPU时间(high percent system CPU)
    　长时间的有很长的运行进程队列(large run queue size sustained over time)

    磁盘I/O：
    　1 UNIX资源监控（Windows操作系统同理）中指标磁盘交换率（Disk rate），如果该参数值一直很高，表明I/O有问题。可考虑更换更快的硬盘系统。
    　2 Windows资源监控中，如果 Disk Time和Avg.Disk Queue Length的值很高，而Page Reads/sec页面读取操作速率很低，则可能存在磁盘瓶径。

    I/O资源成为系统性能的瓶颈的征兆 :
    　过高的磁盘利用率(high disk utilization)
    　太长的磁盘等待队列(large disk queue length)
    　等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
    　太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
    　过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
    　太长的运行进程队列，但CPU却空闲(large run queue with idle CPU)

    4．数据库服务器：
    　SQL Server数据库：
    　1 SQLServer资源监控中指标缓存点击率（Cache Hit Ratio），该值越高越好。如果持续低于80%，应考虑增加内存。
    　2 如果Full Scans/sec（全表扫描/秒）计数器显示的值比1或2高，则应分析你的查询以确定是否确实需要全表扫描，以及SQL查询是否可以被优化。
    　3 Number of Deadlocks/sec(死锁的数量/秒)：死锁对应用程序的可伸缩性非常有害，并且会导致恶劣的用户体验。该计数器的值必须为0。
    　4 Lock Requests/sec(锁请求/秒)，通过优化查询来减少读取次数，可以减少该计数器的值。

    Oracle数据库：
    　1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90，那么需要增加SHARED_POOL_SIZE的大小。
    快存（共享SQL区）和数据字典快存的命中率：

    　select(sum(pins-reloads))/sum(pins) from v$librarycache;
    　select(sum(gets-getmisses))/sum(gets) from v$rowcache;
    　自由内存： select * from v$sgastat where name=’free memory’;

    2 如果数据的缓存命中率小于0.90，那么需要加大DB_BLOCK_BUFFERS参数的值（单位：块）。
    　缓冲区高速缓存命中率：

    　select name,value from v$sysstat where name in ('db block gets’,
    'consistent gets','physical reads') ; Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))

    3 如果日志缓冲区申请的值较大，则应加大LOG_BUFFER参数的值。
    　日志缓冲区的申请情况 ：

    select name,value from v$sysstat where name = 'redo log space requests' ;

    4 如果内存排序命中率小于0.95，则应加大SORT_AREA_SIZE以避免磁盘排序 。
    　内存排序命中率 ：

    select round((100*b.value)/decode((a.value+b.value), 0, 1, (a.value+b.value)), 2)from v$sysstat a, v$sysstat b where 　a.name='sorts (disk)' and b.name='sorts (memory)'

     

    UNIX资源监控指标和描述

    　　监控指标 描述

    　　平均负载 系统正常状态下，最后60秒同步进程的

    　　平均个数

    　　冲突率 在以太网上监测到的每秒冲突数

    　　进程/线程交换率 进程和线程之间每秒交换次数

    　　CPU利用率 CPU占用率（％）

    　　磁盘交换率 磁盘交换速率

    　　接收包错误率 接收以太网数据包时每秒错误数

    　　包输入率 每秒输入的以太网数据包数目

    　　中断速率 CPU每秒处理的中断数

    　　输出包错误率 发送以太网数据包时每秒错误数

    　　包输入率 每秒输出的以太网数据包数目

    　　读入内存页速率 物理内存中每秒读入内存页的数目

    　　写出内存页速率 每秒从物理内存中写到页文件中的内存页数

    　　目或者从物理内存中删掉的内存页数目

    　　内存页交换速率 每秒写入内存页和从物理内存中读出页的个数

    　　进程入交换率 交换区输入的进程数目

    　　进程出交换率 交换区输出的进程数目

    　　系统CPU利用率 系统的CPU占用率（％）

    　　用户CPU利用率 用户模式下的CPU占用率（％）

    　　磁盘阻塞 磁盘每秒阻塞的字节数

    注：上述SQL Server和Oracle数据库分析，只是一些简单、基本的分析，特别是Oracle数据库的分析和优化，是一门专门的技术，进一步的分析可查相关资料。

    查看(125) 评论(0)

查看(776) 评论(0) 收藏 分享 管理

  • 转载~tcprepaly使用命令手册（翻译中文）

    pp1984829 发布于 2008-11-24 11:17:47

    前言
      工具的名称就能猜到工具的作用，就是重放TCP的报文，但是这个工具究竟功能如何，是不是仅仅局限于在一个网卡上回放报文，这篇说明书主要介绍tcprelay的一些与测试有关的使用，在介绍tcpreplay命令的使用之前，先要介绍与之密切相关的一个命令：tcpprep，中文直译就是tcp准备的意思，它的作用可以参见官方网站的介绍说明：

      tcpprep is the pcap pre-processor for tcpreplay and tcprewrite. The purpose of tcpprep is to create a cache file which is used to "split" traffic into two sides (often called primary/secondary or client/server). If you are intending to use tcpreplay with two NIC's, then tcpprep is what decides which interface each packet will use. By using a seperate process to generate cache files, tcpreplay can send packets at a much higher rate then if it had to do the calculations to split traffic itself.

    CET-4翻译：（建议大家看man文件，阅读3次就能够比较好的理解了）

      tcpprep是一个在tcpreplay和tcprewrite（3.0.beta11版本才有，这里不讨论）之前使用的pcap文件的处理程序。使用tcpprep的目的就是建立一个cache文件，用于分离通信流量中的两方（通常叫做 主要的/次要的 或者 客户端/服务器）。如果你正打算在两块网卡上使用tcpreplay的话，那么tcpprep就是用来决定每一个报文（packet）从哪一个接口发出。通过使用这样一个分离的程序来建立一个cache文件，tcpreplay就可以根据这个cache文件通过自身的计算来分离流量，高速率的发送报文。

      cache文件的作用解释，主要是加速报文的发送，cache文件中存放着pcap文件中每个帧的编号和时间戳等信息，以达到tcpreplay回放时可以更加快速的发送报文的目的。

      其实我们要使用tcpreplay的功能的话，肯定就是它的重放功能，而重放的话肯定是一个客户端和服务器的交互过程，例如ftp、tftp、sqlnet、rtsp、mms等应用层协议的交互过程，我们只要有正确和足够的pcap文件，只需要制作cache文件，使用tcpreplay的命令，就不需要每次都搭建一个真实的测试环境来测试DUT对该协议的支持程度。所以在介绍tcpreplay之前先介绍tcpprep这个命令的使用。tcprewrite提供的功能暂时不做研究。
    Tcpprep帮助文件说明

      由于时间问题，这次不能对man文件一一做解释，这个说明文档主要是对-h打印出来的命令参数作一个说明，结合几个实际的例子来说明tcpprep的使用。强烈建议大家去官方网站去阅读他们提供的文档，http://tcpreplay.synfin.net/trac/，我这里有打印的内容，有兴趣的可以拿去看一下。

      Usage: tcpprep [-a -n <mode> -N <type> | -c <cidr> | -p | -r <regex>] \

      -o <out> -i <in> <args>

    -a Split traffic in Auto Mode

    一般情况下都需要该参数，表示按模式自动分离的通讯流量生成cache文件，这个参数一半都和-n参数一起使用，表示自动分离采取的拓扑模式，来决定采取那种模式分离通讯流量的双方。

    -c CIDR1,CIDR2,... Split traffic in CIDR Mode

    可选参数，表示分离流量时采用CIDR（无类别域间路由选择）模式。格式：tcpprep -ac 10.10.0.0/24，表示把源地址匹配10.10.0.0/24网段的报文全部由主网卡发送，剩下的报文由从网卡发送出来，这里还有一点需要补充，就是tcpreplay在重放报文时对两个网卡的定义很明确，一个主网卡（primary interface），一个是从网卡（secondary interface），不同的模式，两块网卡的属性不一样。该参数不能和-r,-a一起使用。

    -C <comment> Embed comment in tcpprep cache file

    可选参数，表示在cache文件中嵌入注释内容，可以用于注释说明cache文件的内容，注意使用时参数位置，不要放在最后，我测试时放在-o参数值的后面就报错，放到-i参数之前就可以。生成cache文件后使用-P可以查看写入的内容。

    -h Help

    显示帮助文件。

    -i <capfile> Input capture file to process

    生成cache文件的必带参数，后面紧跟pcap文件名，表示这个pcap文件需要处理。

    -m <minmask> Minimum mask length in Auto/Router mode

    可选参数，在选用router模式时使用，表示最小掩码，默认是30（2个有效ip地址）。

    -M <maxmask> Maximum mask length in Auto/Router mode

    可选参数，在选用router模式时使用，表示最大掩码，默认是8（1600万个ip地址）。

    -n <auto mode> Use specified algorithm in Auto Mode

    生成cache文件的必带参数，后面紧跟模式名称，可选项有(bridge|router|client|server)，目前2.3.5版本只支持这4种模式。模式的选择很关键，例如在客户端使用ftp软件下载文件，那么你在客户端抓到的报文生成的pcap文件，那么就选用client模式，在服务器端抓到的报文生成的pcap文件就选用server模式。只有模式选对了，才能正确的分离流量从正确的接口发出正确的报文。注意：Server端的报文由主网卡发送出去，Client端的报文由从网卡发送出去。怎么确定主从网卡由tcpreplay的命令（-i –j两个参数）来决定。

    -N client|server Classify non-IP traffic as client/server

    可选参数，表示非IP的流量（例如ARP报文）从哪个接口送出，因为很多的tcpprcp支持的模式中，都依赖于IP头部中的IP地址信息来决定报文是从client端还是从server端发送出去。但是并不是所有的报文都是IPv4结构的，所以这种情况下，tcpprep不能确定这些非IPv4类型的报文应该从哪个接口发送出去，所以，默认的配置就是从client的接口发送出去。如果你硬要正确的分离出非IPv4报文的话，可以使用MAC address模式（--mac）。3.0版本才支持。

    -o <outputfile> Output cache file name

    生成cache文件的必带参数，后面紧跟cache文件名，表示这个输出的cache文件以这个名字命名。

    -p Split traffic based on destination port

      可选参数，基于目的端口来分离通讯流量，它区分的依据是认为0-1023端口都是服务器的端发出的报文，其它的端口都是客户端发出的报文，具体的端口对应的/etc/services文件里的的内容。使用的格式：-p /etc/services，可以根据自己的需要来制作一个文件也可以。

    -P <file> Print comment in tcpprep file

      可选参数，查看cache文件的内容。

    -r <regex> Split traffic in Regex Mode

      可选参数，表示使用Regex模式分离通讯流量，有点类似于CIDR模式，但是它匹配的是服务器的源IP。man文件提示不能和-a、-c参数一起使用，但是我使用了也没有报错，格式：-r "(192)"或-r "(192|172)\.....*"，具体应用还有待实验。

    -R <ratio> Specify a ratio to use in Auto Mode

      可选参数，一个比例值，这个比例值的意义是服务器端发起的连接数和客户端发起的连接数的比例，这个值大于2的话就视为server端。这个英文原意我也不是太肯定，大家可以参考一下原文：

    The ratio of server connections to client connections necessary to be classified as a server in auto mode. A system is classified as a server if [# server connections] >= ([# client connections] * [ratio]). Default is: 2.0

    -s <file> Specify service ports in /etc/services format

      可选参数，在man文件中没有对该参数的解释，估计就是按/etc/services文件里的格式来定义服务的端口，没有太多的研究意义。

    -x <match> Only send the packets specified

      重要的可选参数，表示按照参数定义的需求来定义发送报文。后面还有具体的参数，因为在我们的抓包过程中，可能会由于网络环境原因，抓到了许多我们不需要回放的报文，我们就可以根据这个参数决定我们需要回放哪些报文内容。具体的参数意思如下：

      S:<CIDR1>,... - Src IP must match specified CIDR(s)

      在CIDR模式下必须匹配源IP，格式：-xS:100.1.1.0/24,10.10.10.0/26。多个用逗号隔开，参数个数没有试过，3个没有问题。

    D:<CIDR1>,... - Dst IP must match specified CIDR(s)

    在CIDR模式下必须匹配目的IP，格式同上。

    B:<CIDR1>,... - Both src and dst addresses must match

    必须同时匹配源和目的IP，格式同上。

    E:<CIDR1>,... - Either src or dst address must match

    匹配源或目的IP，格式同上。

    P:<list> - Must be one of the listed packets where the list corresponds to the packet number in the capture file. 

    Ex: -xP:1-5,9,15 would only send packets 1 through 5, 9 and 15.

    根据参数后的参数值（报文编号）发送指定的报文。可以在ethereal中确认报文的编号，然后把需要的报文发送。可以用于排除ARP报文。

    F:"<filter>" - BPF filter. See the tcpdump(8) man page for syntax.

    未知，以后补充。

    -X <match> Send all the packets except those specified

      可选参数，就是-x参数的取反，参数内容也是一样。

    -v Verbose

      可选参数，显示trpprep生成cache文件的处理过程，就是一些信息的即时打印。

    -V Version

      显示版本号。
    Tcpprep使用小结

      再构造cache文件的过程中我用的比较多的选项参数就-v、-P、-xB、-xP，一般都是client和server的模式，其它两种模式没有实验过，暂时还不知道怎么使用，bridge模式我使用过一次，结果发现报文是从一个网卡送出。

      对于tcp和udp协议都做了测试，是可以支持的，icmp还没有成功。对于网络上的BT报文，只要你有pcap文件，也是可以构造cache文件来模拟完全真实的BT流量。

      目前的使用就是这么多，感觉还是很有用的，tcpreplay的参数有一部分是和tcpprep重复，下面的帮助文件说明就不详细说明了，但是特殊有好用的参数会使用蓝色字体标记出来给予重视。存在的不足是还没有学会在nat模式下重放报文，现在所有的报文重放都是在透明模式下完成的。

     

     
    Tcpreplay帮助文件说明

      Usage: tcpreplay [args] <file(s)>

    -A "<args>" Pass arguments to tcpdump decoder (use w/ -v)

      可选参数，在使用tcpdump风格打印输出信息时，同时再调用tcpdump中的参数，默认已经带有“-n,-l”，所以一般看到的都是ip地址，而没有主机名的打印，注意这个是在tcpreplay使用了-v参数时，才能使用，不带-v不会报错，但是没有实际意义。格式：-vA “nnt”表示以tcpdump风格输出报文信息，并且不打印时间戳、主机名、端口服务名称。注意不要使用-c参数来指定打印的数据报文的个数，这样发送出去的报文也会变少。

    -b Bridge two broadcast domains in sniffer mode

      可选参数，没有用过

    -c <cachefile> Split traffic via cache file

      双网卡回放报文必选参数，后面紧跟cache文件名，该文件为tcpprep根据对应的pcap文件构造出来。

    -C <CIDR1,CIDR2,...> Split traffic by matching src IP

      可选参数，

    -D Data dump mode (set this BEFORE -w and -W)

    可选参数，把应用层的数据，使用dump mode写入到指定文件中去，和-w、-W参数一起使用。

    -e <ip1:ip2> Specify IP endpoint rewriting

      可选参数，指定端点的ip，即把发送报文的和接收的报文的ip都修改称对应的参数值中指定的ip，但是这样发送的出的报文不会区分client和server，还没有发现使用的地方。

    -f <configfile> Specify configuration file

      可选参数，指定配置文件，目前不会使用。

    -F Fix IP, TCP, UDP and ICMP checksums

      可选参数，在发送报文时，自动纠正错误的校验和。对测试DUT的校验和检验还是有用的。

    -h Help

      显示帮助文件。

    -i <nic> Primary interface to send traffic out of

      双网卡回放报文必选参数，指定主接口。

    -I <mac> Rewrite dest MAC on primary interface

      可选参数，重写主网卡发送出报文的目的MAC地址。

    -j <nic> Secondary interface to send traffic out of

      双网卡回放报文必选参数，指定从接口。

    -J <mac> Rewrite dest MAC on secondary interface

      可选参数，重写从网卡发送出报文的目的MAC地址。

    -k <mac> Rewrite source MAC on primary interface

      可选参数，重写主网卡发送报文的源MAC地址。

    -K <mac> Rewrite source MAC on secondary interface

      可选参数，重写从网卡发送报文的源MAC地址。

    -l <loop> Specify number of times to loop

      可选参数，指定循环的次数，测试过程发现不是那么好用，有待确认。

    -L <limit> Specify the maximum number of packets to send

      可选参数，指定最大的发包数量。可以在确认连接的调试时使用。

    -m <multiple> Set replay speed to given multiple

      可选参数，指定一个倍数值，就是必默认发送速率要快多少倍的速率发送报文。加大发送的速率后，对于DUT可能意味着有更多的并发连接和连接数，特别是对于BT报文的重放，因为连接的超时是固定的，如果速率增大的话，留在session表中的连接数量增大，还可以通过修改连接的超时时间来达到该目的。

    -M Disable sending martian IP packets

      可选参数，表示不发送“火星”的ip报文，man文件中的定义是0/8、172/8、255/8。

    -n Not nosy mode (not promisc in sniff/bridge mode)

      可选参数，在使用-S参数，不对混杂模式进行侦听。没有测试过。

    -N <CIDR1:CIDR2,...> Rewrite IP's via pseudo-NAT

      可选参数，通过伪造的NAT，重写IP地址。这个参数应该有很重要的应用，目前没有测试使用。

    -O One output mode

      可选参数，没有测试使用

    -p <packetrate> Set replay speed to given rate (packets/sec)

      可选参数，指定每秒发送报文的个数，指定该参数，其它速率相关的参数被忽略，最后的打印信息不会有速率和每秒发送报文的统计。

    -P Print PID

      可选参数，表示在输出信息中打印PID的信息，用于单用户或单帐户模式下暂停和重启程序。

    -r <rate> Set replay speed to given rate (Mbps)

      可选参数，指定发送的速率。目前-m/-r/-p这3个参数的相互关系还需要确认。

    -R Set replay speed to as fast as possible

      可选参数，让报文线速发送。

    -s <seed> Randomize src/dst IP addresses w/ given seed

      可选参数，

    -S <snaplen> Sniff interface(s) and set the snaplen length

      可选参数，

    -t <mtu> Override MTU (defaults to 1500)

      可选参数，指定MTU，标准的10/100M网卡的默认值是1500。

    -T Truncate packets > MTU so they can be sent

      可选参数，截去报文中MTU大于标准值的部分再发送出去，默认是不发送，skip掉。目前还有疑问，为什么会产生MTU大于1500字节的包，在BT报文中，这种包比较常见。

    -u pad|trunc Pad/Truncate packets which are larger than the snaplen

      可选参数，后面的参数值二选一，snaplen是指保留数据包的长度，这里的trunc参数值和MTU没有任何关系，不要混淆。

    -v Verbose: print packet decodes for each packet sent

      可选参数，没发送一个报文都以tcpdump的风格打印出对应的信息。

    -V Version

      查看版本号。

    -w <file> Write (primary) packets or data to file

      可选参数，将主网卡发送的报文写入一个文件中，参数后紧跟文件名。

    -W <file> Write secondary packets or data to file

      可选参数，将从网卡发送的报文写入一个文件中，参数后紧跟文件名。

    -x <match> Only send the packets specified

      可选参数，发送匹配参数值的报文，这里各个参数具体的含义和tcpprep中的一样，

    S:<CIDR1>,... - Src IP must match specified CIDR(s)

      在CIDR模式下必须匹配源IP，格式：-xS:100.1.1.0/24,10.10.10.0/26。多个用逗号隔开，参数个数没有试过，3个没有问题。

    D:<CIDR1>,... - Dst IP must match specified CIDR(s)

    在CIDR模式下必须匹配目的IP，格式同上。

    B:<CIDR1>,... - Both src and dst addresses must match

    必须同时匹配源和目的IP，格式同上。

    E:<CIDR1>,... - Either src or dst address must match

    匹配源或目的IP，格式同上。

    P:<list> - Must be one of the listed packets where the list corresponds to the packet number in the capture file. 

    Ex: -xP:1-5,9,15 would only send packets 1 through 5, 9 and 15.

    根据参数后的参数值（报文编号）发送指定的报文。可以在ethereal中确认报文的编号，然后把需要的报文发送。可以用于排除ARP报文。

    F:"<filter>" - BPF filter. See the tcpdump(8) man page for syntax.

    未知，以后补充。

    -X <match> Send all the packets except those specified

      可选参数，-x的参数内容取反。参数内容一样。

    -1 Send one packet per key press

      可选参数，参数内容就是阿拉伯数字1，这个参数对于确定连接的建立，相当好用，根据按回车键发送报文，可以将报文一个一个发送，来判断连接的状态。也可以用于故障定位。

    -2 <datafile> Layer 2 data

      可选参数，在2层加入数据。

    -4 <PORT1:PORT2,...> Rewrite port numbers

      可选参数，重写端口号，对于测试特殊端口的应用比较实用。

    <file1> <file2> ... File list to replay

      可选参数，没有实验过。
    配置实例

    1、 重放在客户端ftp连接的报文

    a、 在客户端使用ethereal抓包，存为ftp.pcap文件

    b、 将ftp.pcap文件进行tcpprep操作，制作cache文件。

    [root@A ~]# tcpprep -an client -i ftp.pcap -o ftp.cache –v

    c、 将DUT设备的两个接口和PC的两个接口使用网线连接，使用tcpreplay重放报文。注意防火墙的配置为网桥（透明）模式。

    [root@A ~]# tcpreplay -c ftp.cache -i eth0 -j eth1 ftp.pcap -R –v

    -R参数表示全速发送，-v显示打印信息。

    2、 重放在客户端BT连接的报文

    a、 在实验室BT下载一些台湾的娱乐节目和热门的大片，使用ethereal抓包，存为bt.pcap文件。注意pcap文件大小的控制，对pc的内存要求比较高，我保存了一个600多M的pcap文件用了40多分钟，大家有需要可以直接从实验室copy。

    b、 将bt.pcap文件进行tcpprep操作，制作cache文件。

    [root@A ~]# tcpprep -an client -i bt.pcap -o bt.cache -C "100M BT Packet" –v

      制作cache文件，在cache文件中写入“100M BT Packet”的注释。

    c、 使用tcpreplay重放报文。

    [root@A ~]# tcpreplay -c bt.cache -i eth0 -j eth1 bt.pcap -v –R

    3、 重放tftp服务器上抓到的报文

    a、 在tftp服务器上使用ethereal抓包，存为tftp.pcap文件。

    b、 将pcap文件进行tcpprep的操作，制作cache文件。

    [root@A ~]# tcpprep -an server -i tftp.pcap -o tftp.cache –v

    注意：我在测试的时候犯了一个错误，使用DUT的tftp升级来做实验，同时穿过DUT重放报文，结果在网卡发送报文的后，DUT的mac地址做了的回应，导致交互过程没有穿过DUT，这个问题比较搞笑，上午弄了半天才发现原因，开始还以为udp的连接不能重放。

    c、 使用tcpreplay重放报文。

    [root@A ~]# tcpreplay -c tftp.cache -i eth0 -j eth1 tftp.pcap –v

    查看(1960) 评论(0) 收藏 分享 管理

  • 如何测试TCP/IP协议

    欧阳 发布于 2008-12-02 12:59:18

       因为今天中午休息的时间比较多，所以找了点小东西学习下，不敢独占，所以发出来看看

       安装网络硬件和网络协议之后，我们一般要进行TCP/IP协议的测试工作，那么怎样测试才算是比较全面的测试呢?我们认为，全面的测试应包括局域网和互联网两个方面，因此应从局域网和互联网两个方面测试，以下是我们在实际工作中利用命令行测试TCP/IP配置的步骤：
    　　1、 单击“开始”/“运行”，输入CMD按回车，打开命令提示符窗口。

    　　2、 首先检查IP地址、子网掩码、默认网关、DNS服务器地址是否正确，输入命令ipconfig /all,按回车。此时显示了你的网络配置，观查是否正确。

    　　3、 输入ping 127.0.0.1，观查网卡是否能转发数据，如果出现“Request timed out”，表明配置差错或网络有问题。

    　　4、 Ping一个互联网地址，如ping 202.102.128.68,看是否有数据包传回，以验证与互联网的连接性。

    　　5、 Ping 一个局域网地址，观查与它的连通性。

    　　6、 用nslookup测试DNS解析是否正确，输入如nslookup www.163.com，查看是否能解析。

    　　如果你的计算机通过了全部测试，则说明网络正常，否则网络可能有不同程度的问题。在此不展开详述。不过，要注意，在使用 ping命令时，有些公司会在其主机设置丢弃ICMP数据包，造成你的ping命令无法正常返回数据包，不防换个网站试试。

    ping命令详解

    ping [-n count][-l size][-w timeout]

    -n 发送的ICMP数据包数，默认是4个

    -l 发送的ICMP数据包大小，一般是56K+8K=64K

    -w 超时时间

    另外因为经常被问到帧和IP数据包是怎么回事，所以也找了找这方面的资料。

    数据格式：
    数据帧：帧头＋IP数据包＋帧尾 (帧头包括源和目标主机MAC地址及类型,帧尾是校验字)
    IP数据包：IP头部＋TCP数据信息 (IP头包括源和目标主机IP地址、类型、生存期等)
    TCP数据信息：TCP头部+实际数据 (TCP头包括源和目标主机端口号、顺序号、确认号、校
    验字等)

    查看(4604) 评论(0) 收藏 分享 管理

  • tcpdump在服务器维护方面的使用

    jevens17 发布于 2008-10-10 15:17:05

    在表达式中一般如下几种类型的关键字：

       第一种是关于类型的关键字，主要包括host，net，port

       例如  host 210.27.48.2， 指明 210.27.48.2是一台主机

       net 202.0.0.0，指明202.0.0.0是一个网络地址

       port 23 指明端口号是23。如果没有指定类型，缺省的类型是host。

       第二种是确定传输方向的关键字，主要包括src，dst，dst or src，dst and src，这些关键字指明了传输的方向。

       举例说明，src 210.27.48.2 ，指明ip包中源地址是 210.27.48.2 ， dst net 202.0.0.0 指明目的网络地址是202.0.0.0。

       第三种是协议的关键字，主要包括fddi，ip，arp，rarp，tcp，udp等类型。

       还有三种逻辑运算，取非运算是not，!  ；与运算是and，&& ；或运算是or ，||

       example：

         1. tcpdump port 23 and \( host 192.168.1.101 \) ：    过滤主机192.168.1.101（不管src还是dst）且端口为23的包

         2. tcpdump host 192.168.1.1：    截获所有192.168.1.1主机收到的和发出的所有的包

         3. tcpdump ip host 210.27.48.1 and ! 210.27.48.2：    获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包

         4. tcpdump host 210.27.48.1 and \(210.27.48.2 or 210.27.48.3 \)：    截获主机210.27.48.1 和主机210.27.48.2或210.27.48.3的通信

         5. 先 tcpdump 一看，信息太多。 想了想我要做的是什么，主要是想看看，局域网中访问internet那些东西，跟那些机器有连接，而且要探测不明链接。从而可以发现是否有木马，病毒一些在作怪！ tcpdump dst net not 192.168.123.0/24 不监视跟网内机子的链接，过滤很多信息。迅速进入主题， 不想看发邮件的情况，一般的80网页访问，domain访问，还有要排除网内已有服务器的一些端口。

    查看(318) 评论(0) 收藏 分享 管理

  • TCPDUMP简介及测试中的应用

    gaowei302 发布于 2008-08-25 11:23:21Top 3 Digest 2

        在传统的网络分析和测试技术中，嗅探器(sniffer)是最常见，也是最重要的技术之一。sniffer工具首先是为网络管理员和网络程序员进行网络分析而设计的。对于网络管理人员来说，使用嗅探器可以随时掌握网络的实际情况，在网络性能急剧下降的时候，可以通过sniffer工具来分析原因，找出造成网络阻塞的来源。对于网络程序员来说,通过sniffer工具来调试程序。

    用过windows平台上的sniffer工具(例如，netxray和sniffer pro软件)的朋友可能都知道，在共享式的局域网中，采用sniffer工具简直可以对网络中的所有流量一览无余！Sniffer工具实际上就是一个网络上的抓包工具，同时还可以对抓到的包进行分析。由于在共享式的网络中，信息包是会广播到网络中所有主机的网络接口，只不过在没有使用sniffer工具之前，主机的网络设备会判断该信息包是否应该接收，这样它就会抛弃不应该接收的信息包，sniffer工具却使主机的网络设备接收所有到达的信息包，这样就达到了网络监听的效果。

    Linux作为网络服务器，特别是作为路由器和网关时，数据的采集和分析是必不可少的。所以，今天我们就来看看Linux中强大的网络数据采集分析工具——TcpDump。

    用简单的话来定义tcpdump，就是：dump the traffice on a network，根据使用者的定义对网络上的数据包进行截获的包分析工具。

    作为互联网上经典的的系统管理员必备工具，tcpdump以其强大的功能，灵活的截取策略，成为每个高级的系统管理员分析网络，排查问题等所必备的东东之一。

    顾名思义，TcpDump可以将网络中传送的数据包的“头”完全截获下来提供分析。它支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

    tcpdump提供了源代码，公开了接口，因此具备很强的可扩展性，对于网络维护和入侵者都是非常有用的工具。tcpdump存在于基本的FreeBSD系统中，由于它需要将网络界面设置为混杂模式，普通用户不能正常执行，但具备root权限的用户可以直接执行它来获取网络上的信息。因此系统中存在网络分析工具主要不是对本机安全的威胁，而是对网络上的其他计算机的安全存在威胁。

    普通情况下，直接启动tcpdump将监视第一个网络界面上所有流过的数据包。
    －－－－－－－－－－－－－－－－－－－－－－－
    bash-2.02# tcpdump
    tcpdump: listening on eth0
    11:58:47.873028 202.102.245.40.netbios-ns > 202.102.245.127.netbios-ns: udp 50
    11:58:47.974331 0:10:7b:8:3a:56 > 1:80:c2:0:0:0 802.1d ui/C len=43
    0000 0000 0080 0000 1007 cf08 0900 0000
    0e80 0000 902b 4695 0980 8701 0014 0002
    000f 0000 902b 4695 0008 00
    11:58:48.373134 0:0:e8:5b:6d:85 > Broadcast sap e0 ui/C len=97
    ffff 0060 0004 ffff ffff ffff ffff ffff
    0452 ffff ffff 0000 e85b 6d85 4008 0002
    0640 4d41 5354 4552 5f57 4542 0000 0000
    0000 00
    ^C
    －－－－－－－－－－－－－－－－－－－－－－－－

    首先我们注意一下，从上面的输出结果上可以看出来，基本上tcpdump总的的输出格式为：系统时间 来源主机.端口 > 目标主机.端口 数据包参数

    TcpDump的参数化支持

    tcpdump支持相当多的不同参数，如使用-i参数指定tcpdump监听的网络界面，这在计算机具有多个网络界面时非常有用，使用-c参数指定要监听的数据包数量，使用-w参数指定将监听到的数据包写入文件中保存，等等。

    然而更复杂的tcpdump参数是用于过滤目的，这是因为网络中流量很大，如果不加分辨将所有的数据包都截留下来，数据量太大，反而不容易发现需要的数据包。使用这些参数定义的过滤规则可以截留特定的数据包，以缩小目标，才能更好的分析网络中存在的问题。tcpdump使用参数指定要监视数据包的类型、地址、端口等，根据具体的网络问题，充分利用这些过滤规则就能达到迅速定位故障的目的。请使用man tcpdump查看这些过滤规则的具体用法。

    显然为了安全起见，不用作网络管理用途的计算机上不应该运行这一类的网络分析软件，为了屏蔽它们，可以屏蔽内核中的bpfilter伪设备。一般情况下网络硬件和TCP/IP堆栈不支持接收或发送与本计算机无关的数据包，为了接收这些数据包，就必须使用网卡的混杂模式，并绕过标准的TCP/IP堆栈才行。在FreeBSD下，这就需要内核支持伪设备bpfilter。因此，在内核中取消bpfilter支持，就能屏蔽tcpdump之类的网络分析工具。

    并且当网卡被设置为混杂模式时，系统会在控制台和日志文件中留下记录，提醒管理员留意这台系统是否被用作攻击同网络的其他计算机的跳板。

    May 15 16:27:20 host1 /kernel: fxp0: promiscuous mode enabled

    虽然网络分析工具能将网络中传送的数据记录下来，但是网络中的数据流量相当大，如何对这些数据进行分析、分类统计、发现并报告错误却是更关键的问题。网络中的数据包属于不同的协议，而不同协议数据包的格式也不同。因此对捕获的数据进行解码，将包中的信息尽可能的展示出来，对于协议分析工具来讲更为重要。昂贵的商业分析工具的优势就在于它们能支持很多种类的应用层协议，而不仅仅只支持tcp、udp等低层协议。

    从上面tcpdump的输出可以看出，tcpdump对截获的数据并没有进行彻底解码，数据包内的大部分内容是使用十六进制的形式直接打印输出的。显然这不利于分析网络故障，通常的解决办法是先使用带-w参数的tcpdump 截获数据并保存到文件中，然后再使用其他程序进行解码分析。当然也应该定义过滤规则，以避免捕获的数据包填满整个硬盘。

    TCP功能

    数据过滤

    不带任何参数的TcpDump将搜索系统中所有的网络接口，并显示它截获的所有数据，这些数据对我们不一定全都需要，而且数据太多不利于分析。所以，我们应当先想好需要哪些数据，TcpDump提供以下参数供我们选择数据：

    -b 在数据-链路层上选择协议，包括ip、arp、rarp、ipx都是这一层的。

    例如：tcpdump -b arp 将只显示网络中的arp即地址转换协议信息。

    -i 选择过滤的网络接口，如果是作为路由器至少有两个网络接口，通过这个选项，就可以只过滤指定的接口上通过的数据。例如：

    tcpdump -i eth0 只显示通过eth0接口上的所有报头。

    src、dst、port、host、net、ether、gateway这几个选项又分别包含src、dst 、port、host、net、ehost等附加选项。他们用来分辨数据包的来源和去向，src host 192.168.0.1指定源主机IP地址是192.168.0.1，dst net 192.168.0.0/24指定目标是网络192.168.0.0。以此类推，host是与其指定主机相关无论它是源还是目的，net是与其指定网络相关的，ether后面跟的不是IP地址而是物理地址，而gateway则用于网关主机。可能有点复杂，看下面例子就知道了：

    tcpdump src host 192.168.0.1 and dst net 192.168.0.0/24

    过滤的是源主机为192.168.0.1与目的网络为192.168.0.0的报头。

    tcpdump ether src 00:50:04:BA:9B and dst……

    过滤源主机物理地址为XXX的报头（为什么ether src后面没有host或者net？物理地址当然不可能有网络喽）。

    Tcpdump src host 192.168.0.1 and dst port not telnet

    过滤源主机192.168.0.1和目的端口不是telnet的报头。

    ip icmp arp rarp 和 tcp、udp、icmp这些选项等都要放到第一个参数的位置，用来过滤数据报的类型。
    例如：

    tcpdump ip src……

    只过滤数据-链路层上的IP报头。

    tcpdump udp and src host 192.168.0.1

    只过滤源主机192.168.0.1的所有udp报头。

    数据显示/输入输出

    TcpDump提供了足够的参数来让我们选择如何处理得到的数据，如下所示：

    -l 可以将数据重定向。

    如tcpdump -l ＞tcpcap.txt将得到的数据存入tcpcap.txt文件中。

    -n 不进行IP地址到主机名的转换。

    如果不使用这一项，当系统中存在某一主机的主机名时，TcpDump会把IP地址转换为主机名显示，就像这样：eth0 ＜ ntc9.1165＞ router.domain.net.telnet，使用-n后变成了：eth0 ＜ 192.168.0.9.1165 ＞ 192.168.0.1.telnet。

    -nn 不进行端口名称的转换。

    上面这条信息使用-nn后就变成了：eth0 ＜ ntc9.1165 ＞ router.domain.net.23。

    -N 不打印出默认的域名。

    还是这条信息-N 后就是：eth0 ＜ ntc9.1165 ＞ router.telnet。

    -O 不进行匹配代码的优化。
    -t 不打印UNIX时间戳，也就是不显示时间。
    -tt 打印原始的、未格式化过的时间。
    -v 详细的输出，也就比普通的多了个TTL和服务类型。


    TCPDUMP的安装

    在linux下tcpdump的安装十分简单，一般由两种安装方式。一种是以rpm包的形式来进行安装。另外一种是以源程序的形式安装。
    1． rpm包的形式安装
    #rpm -ivh tcpdump-3_4a5.rpm
    这样tcpdump就顺利地安装到你的linux系统中。怎么样，很简单吧。
    2． 源程序的安装
    #tar xvfz tcpdump-3_4a5.tar.Z
    rpm的包可以使用如下命令安装:
    #rpm -ivh tcpdump-3_4a5.src.rpm
    这样就把tcpdump的源代码解压到/usr/src/redhat/SOURCES目录下.

    第二步 做好编译源程序前的准备活动

    在编译源程序之前，最好已经确定库文件libpcap已经安装完毕，这个库文件是tcpdump软件所需的库文件 。同样，你同时还要有一个标准的c语言编译器。在linux下标准的c 语言编译器一般是gcc。 在tcpdump的源程序目录中。有一个文件是Makefile.in，configure命令就是从Makefile.in文件中自动产生Makefile文件。在Makefile.in文件中，可以根据系统的配置来修改BINDEST 和 MANDEST 这两个宏定义，缺省值是
    BINDEST = @sbindir@
    MANDEST = @mandir@

    第一个宏值表明安装tcpdump的二进制文件的路径名，第二个表明tcpdump的man 帮助页的路径名,你可以修改它们来满足系统的需求。

    第三步 编译源程序

    使用源程序目录中的configure脚本，它从系统中读出各种所需的属性。并且根据Makefile.in文件自动生成Makefile文件，以便编译使用.make 命令则根据Makefile文件中的规则编译tcpdump的源程序。使用make install命令安装编译好的tcpdump的二进制文件。

    总结一下就是:

    # tar xvfz tcpdump-3_4a5.tar.Z
    # vi Makefile.in
    # . /configure
    # make
    # make install

    关于tcpdump更详细的信息，请查看Man tcpdump。

     

    tcpdump在服务器维护方面的使用

    在表达式中一般如下几种类型的关键字：

       第一种是关于类型的关键字，主要包括host，net，port

       例如  host 210.27.48.2， 指明 210.27.48.2是一台主机

       net 202.0.0.0，指明202.0.0.0是一个网络地址

       port 23 指明端口号是23。如果没有指定类型，缺省的类型是host。

       第二种是确定传输方向的关键字，主要包括src，dst，dst or src，dst and src，这些关键字指明了传输的方向。

       举例说明，src 210.27.48.2 ，指明ip包中源地址是 210.27.48.2 ， dst net 202.0.0.0 指明目的网络地址是202.0.0.0。

       第三种是协议的关键字，主要包括fddi，ip，arp，rarp，tcp，udp等类型。

       还有三种逻辑运算，取非运算是not，!  ；与运算是and，&& ；或运算是or ，||

       example：

         1. tcpdump port 23 and \( host 192.168.1.101 \) ：    过滤主机192.168.1.101（不管src还是dst）且端口为23的包

         2. tcpdump host 192.168.1.1：    截获所有192.168.1.1主机收到的和发出的所有的包

         3. tcpdump ip host 210.27.48.1 and ! 210.27.48.2：    获取主机210.27.48.1除了和主机210.27.48.2之外所有主机通信的ip包

         4. tcpdump host 210.27.48.1 and \(210.27.48.2 or 210.27.48.3 \)：    截获主机210.27.48.1 和主机210.27.48.2或210.27.48.3的通信

         5. 先 tcpdump 一看，信息太多。 想了想我要做的是什么，主要是想看看，局域网中访问internet那些东西，跟那些机器有连接，而且要探测不明链接。从而可以发现是否有木马，病毒一些在作怪！ tcpdump dst net not 192.168.123.0/24 不监视跟网内机子的链接，过滤很多信息。迅速进入主题， 不想看发邮件的情况，一般的80网页访问，domain访问，还有要排除网内已有服务器的一些端口。

    查看(352) 评论(0) 收藏 分享 管理

  • 认识TCP/IP协议

    sdxyyouyou 发布于 2008-02-29 18:08:23

    不同层次的协议关系（图1-3）：

     

    1、各层包含的协议：

    《1》应用层协议：F T P、Telnet、SMTP（简单邮件管理协议）、SNMP（简单网络管理协议）。

    《2》运输层协议：T C P、UDP。

    《3》网络层协议：I P、ICMP（Internet互联网控制管理协议）、IGMP（I n t e r n e t组管理协议）。

    《4》链路层协议：太网和令牌网使用协议包含A R P（地址解析协议）和R A R P（逆地址解析协议）

    2、T C P和U D P是两种最为著名的运输层协议，二者都使用I P作为网络层协议。

    《1》TCP：虽然T C P使用不可靠的I P服务，但它却提供一种可靠的运输层服务。T C P为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。

         TCP的应用：Telnet\FTP\SMTP\SNMP，这些应用通常都是用户进程。

    《2》U D P：为应用程序发送和接收数据报。一个数据报是指从发送方传输到接收方的  一个信息单元，但是与T C P不同的是，U D P是不可靠的，它不能保证数据报能安全无误地到达最终目的。任何必需的可靠性必须由应用层来提供。

               UDP的应用：DNS（域名系统）、TFTP（简单文件传输协议）、BOOTP（引导程序协议）、SNMP。

    2、I P：是网络层上的主要协议，同时被T C P和U D P使用。T C P和U D P的每组数据都通过端系统和每个中间路由器中的I P层在互联网中进行传输。在图1 - 3中，我们给出了一个直接访问I P的应用程序。

    3、I C M P（Internet互联网控制管理协议）：是I P协议的附属协议。I P层用它来与其他主机或路由器交换错误报文和其他重要信息。尽管I C M P主要被I P使用，但应用程序也有可能访问它。两个流行的诊断工具，P i n g和Tr a c e r o u t e（可以知道信息从你的计算机到互联网另一端的主机是走的什么路径，确认目的地的路由），它们都使用了I C M P。

    4、I G M P协议（I n t e r n e t组管理协议）：用来把一个U D P数据报多播到多个主机。

    5、A R P（地址解析协议）和R A R P（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换I P层和网络接口层使用的地址。

     

    查看(589) 评论(3) 收藏 分享 管理

  • TCP/IP网络性能测试工具 - Iperf

    zeus 发布于 2007-10-05 19:21:00

    简介

    Iperf 是一个 TCP/IP 和 UDP/IP 的性能测量工具，能够提供网络吞吐率信息，以及抖动、丢包率、最大段和最大传输单元大小等统计信息，从而能够帮助我们测试网络性能，定位网络瓶颈。其设计 从根本上克服了原来的一些工具，如 ttcp 和 nettest 等的固有的缺陷。

    下载:

    Offical Site: http://dast.nlanr.net/Projects/Iperf2.0/iperf-2.0.2.tar.gz

    安装:

    在指定目录下，按老三步进行：(1)./configure (2)make (3)make install

    功能介绍
    • TCP

    测量网络带宽

    报告MSS/MTU（最大传输单元）值的大小和观测值

    支持TCP窗口值通过套接字缓冲

    当P线程或Win32线程可用时，支持多线程。客户端与服务端支持同时多重连接

    • UDP

    客户端可以创建指定带宽的UDP流

    测量丢包

    测量延迟

    支持多播

    当P线程可用时，支持多线程。客户端与服务端支持同时多重连接（不支持Windows）

    • 在适当的地方，选项中可以使用K（kilo-）和M（mega-）。例如131072字节可以用128K代替。
    • 可以指定运行的总时间，甚至可以设置传输的数据总量。
    • 在报告中，为数据选用最合适的单位。
    • 服务器支持多重连接，而不是等待一个单线程测试。
    • 在指定时间间隔重复显示网络带宽，波动和丢包情况。
    • 服务器端可作为后台程序运行。
    • 服务器端可作为Windows 服务运行。 使用典型数据流来测试链接层压缩对于可用带宽的影响。
    参数与说明

    命令行选项 环境变量选项 描述
    客户端与服务器端选项
     -f, --format $IPERF_FORMAT 格式化带宽数输出。支持的格式有： 'b'=bits/sec  'B'=Bytes/sec 
    'k'=Kbits/sec 'K'=KBytes/sec 
    'm'=Mbits/sec 'M'=MBytes/sec 
    'g'=Gbits/sec 'G'=GBytes/sec 
    'a'=adaptive bits/sec 'A'=adaptive Bytes/sec
    自适应格式是kilo-和mega-二者之一。除了带宽之外的字段都输出为字     节，除非指定输出的格式，默认的参数是a。 
    注意：在计算字节byte时，Kilo=1024， Mega=1024^2，Giga= 1024^3。通常，在网络中，Kilo=1000， Mega=1000^2， and Giga=1000^3，所以，Iperf也按此来计算比特（位）。
     -i, --interval $IPERF_INTERVAL 设置每次报告之间的时间间隔，单位为秒。如果设置为非零值，就会按照此时间间隔输出测试报告。默认值为零。
     -l, --len $IPERF_LEN 设置读写缓冲区的长度。TCP方式默认为8KB，UDP方式默认为1470字节。
     -m, --print_mss $IPERF_PRINT_MSS 输出TCP MSS值（通过TCP_MAXSEG支持）。MSS值一般比MTU值小40字节。
    -p, --port $IPERF_PORT 设置端口，与服务器端的监听端口一致。默认是5001端口，与ttcp的一样。
    -u, --udp $IPERF_UDP 使用UDP方式而不是TCP方式。参看-b选项。
    -w, --window $TCP_WINDOW_SIZE 设置套接字缓冲区为指定大小。对于TCP方式，此设置为TCP窗口大小。对于UDP方式，此设置为接受UDP数据包的缓冲区大小，限制可以接受数据包的最大值。
    -B, --bind host $IPERF_BIND 绑定到主机的多个地址中的一个。对于客户端来说，这个参数设置了出栈接口。对于服务器端来说，这个参数设置入栈接口。这个参数只用于具有多网络接口的主机。在Iperf的UDP模式下，此参数用于绑定和加入一个多播组。使用范围在224.0.0.0至239.255.255.255的多播地址。参考-T参数。
    -C, --compatibility $IPERF_COMPAT 与低版本的Iperf使用时，可以使用兼容模式。不需要两端同时使用兼容模式，但是强烈推荐两端同时使用兼容模式。某些情况下，使用某些数据流可以引起1.7版本的服务器端崩溃或引起非预期的连接尝试。
    -M, --mss $IPERF_MSS 通过TCP_MAXSEG选项尝试设置TCP最大信息段的值。MSS值的大小通常是TCP/IP头减去40字节。在以太网中，MSS值 为1460字节（MTU1500字节）。许多操作系统不支持此选项。
    -N, --nodelay $IPERF_NODELAY 设置TCP无延迟选项，禁用Nagle's运算法则。通常情况此选项对于交互程序，例如telnet，是禁用的。
    -V   绑定一个IPv6地址 服务端：$ iperf -s –V 
    客户端：$ iperf -c <Server IPv6 Address> -V 
    注意：在1.6.3或更高版本中，指定IPv6地址不需要使用-B参数绑定，在 1.6之前的版本则需要。在大多数操作系统中，将响应IPv4客户端映射的IPv4地址。
    服务器端专用选项
    -s, --server $IPERF_SERVER Iperf服务器模式
    -D   (仅用于Windows)Unix平台下Iperf作为后台守护进程运行。在Win32平台下，Iperf将作为服务运行。
    -R   (仅用于Windows)卸载Iperf服务（如果它在运行）。
    -o  

    (仅用于Windows)重定向输出到指定文件

    -c, --client host $IPERF_CLIENT

    如果Iperf运行在服务器模式，并且用-c参数指定一个主机，那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。

    -P, --parallel $IPERF_PARALLEL 服务器关闭之前保持的连接数。默认是0，这意味着永远接受连接。
    客户端专用选项
    -b, --bandwidth $IPERF_BANDWIDTH UDP模式使用的带宽，单位bits/sec。此选项与-u选项相关。默认值是1 Mbit/sec。
    -c, --client host $IPERF_CLIENT 运行Iperf的客户端模式，连接到指定的Iperf服务器端。
    -d, --dualtest $IPERF_DUALTEST 运行双测试模式。这将使服务器端反向连接到客户端，使用-L 参数中指定的端口（或默认使用客户端连接到服务器端的端口）。这些在操作的同时就立即完成了。如果你想要一个交互的测试，请尝试-r参数。
    -n, --num $IPERF_NUM 传送的缓冲器数量。通常情况，Iperf按照10秒钟发送数据。-n参数跨越此限制，按照指定次数发送指定长度的数据，而不论该操作耗费多少时间。参考-l与-t选项。
    -r, --tradeoff $IPERF_TRADEOFF 往复测试模式。当客户端到服务器端的测试结束时，服务器端通过-l选项指定的端口（或默认为客户端连接到服务器端的端口），反向连接至客户端。当客户端连接终止时，反向连接随即开始。如果需要同时进行双向测试，请尝试-d参数。
    -t, --time $IPERF_TIME 设置传输的总时间。Iperf在指定的时间内，重复的发送指定长度的数据包。默认是10秒钟。参考-l与-n选项。
    -L, --listenport $IPERF_LISTENPORT 指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
    -P, --parallel $IPERF_PARALLEL 指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
    -S, --tos $IPERF_TOS 出栈数据包的服务类型。许多路由器忽略TOS字段。你可以指定这个值，使用以“0x”开始的16进制数，或以“0”开始的8进制数或10进制数。例如，16进制'0x10' = 8进制'020' = 十进制'16'。TOS值1349就是： 
    IPTOS_LOWDELAY     minimize delay        0x10
    IPTOS_THROUGHPUT   maximize throughput   0x08
    IPTOS_RELIABILITY  maximize reliability  0x04
    IPTOS_LOWCOST      minimize cost       
    -T, --ttl $IPERF_TTL 出栈多播数据包的TTL值。这本质上就是数据通过路由器的跳数。默认是1，链接本地。
    -F   使用特定的数据流测量带宽，例如指定的文件。 $ iperf -c <server address> -F <file-name>
    -I   与-F一样，由标准输入输出文件输入数据。
    杂项
    -h, --help   显示命令行参考并退出 。
    -v, --version   显示版本信息和编译信息并退出。

    举例：

    1）TCP测试
    服务器执行：./iperf -s -i 1 -w 1M
    客户端执行：./iperf -c host   -i  1  -w 1M
    其中-w表示TCP window size，host需替换成服务器地址。
    2）UDP测试
    服务器执行：./iperf -u -s
    客户端执行：./iperf -u -c 10.255.255.251 -b 900M  -i 1  -w 1M  -t 60
    其中-b表示使用多少带宽，1G的线路你可以使用900M进行测试。

    查看(11689) 评论(0) 收藏 分享 管理

  • TCP/IP常用服务

    andycai 发布于 2007-06-12 11:14:51

    1.DHCP（动态主机配置协议）
    a.概念：它是一种用于简化主机IP配置管理的TCP/IP标准。DHCP标准为DHCP服务器的使用提供了一种有效的方法：即动态管理TCP/IP参数的分配。
    b.使用DHCP服务的好处：
    ·安全可靠的配置：DHCP避免了由于需要手动在每个计算机上键入参数而引起的配置错误。DHCP还有助于由于网络上配置新的计算机时重用以前指派的IP地址而引起的地址冲突。
    ·提高了配置管理的效率：使用DHCP服务器可以大大的降低用于配置和重新配置网上计算机的时间。另外，DHCP刷新过程还有助于确保及时反映出客户机配置信息经常更新的情况。
    c.APIPA是指Automatic Private IP Addressing,Widows的新特性,它是指在客户机无法从dhcp中获得Ip时自动配置一个IP地址

    2.DNS(域名系统)
    a.DNS是一种Internet和Tcp/Ip标准命名服务。DNS服务允许网络上的客户机注册和解析DNS域名。这些名称用户搜索和访问由您的网络或其他网络上的其他计算机提供的资源。
    b.DNS的名称解析不同于WINS的名称解析。WINS是将NetBIOS名称解析成IP地址。而DNS是将主机名或全称域名（FQDN）解析成IP地址
    c.采用DNS或其他方式解析的IP主机名具有如下优点：
    ·主机名具有用户友好的特性，较IP地址更容易被用户记住。
    ·主机名较IP地址更稳定，IP地址可以改变，但是其主机名可以保持不变。
    ·主机名允许用户使用与internet相同的命名约定来同本地服务器连接。
    d.域名空间（NAME SPACE）：是指DNS数据库提供等级结构的命名方案，每个节点代表DNS数据库中的一部分，这些节点称为域。它的层次结构是由根域，顶级域，次级域和主机名构成。
    e.每个域必须有一个名称，当你将域添加到层次结构中去时，父域名相应添加到子域上。每个域名即标识出它在层次中的位置。例如：域名microsoft.com表示microsoft域是com域的一个子域，而com域又是根域的子域。
    f.DNS工作过程：在DNS名称解析过程中，最简单的形式只有两个步骤，即DNS客户向DNS服务器发出查询请求，DNS服务器接收到请求后查找数据库，找到对应的IP后返回结果给客户。对于这种将名称映为IP地址的过程，通常称为正向查找（forward lookup）,反之，如果你已经知道IP地址，但是你想知道与该IP地址相关联的域名称，那么可以进行逆向查找（reverse lookup）.
    g.无论是正向还是逆向查找，都可以执行两种类型的查询：
    ·迭代查询（iterative）:在这种查询中服务器根据它的缓存或者区域中的数据，返回它能够提供的最佳答案。如果被查询的服务器中没有相匹配的数据，它就提供一个指针，该指针指向较低的域名空间中的一个有权威的服务器。然后客户机查询这一个有权威的服务器，客户机继续这一过程，直到它找到了一个有权威的服务器，而这一服务器有权访问所请求的名称，或者直到出现了错误或者满足了超时限条件为止。
    ·递归查询（recursive）:在这一查询中，该服务器承担全部工作量和责任，为该查询提供完全的答案，这样，该DNS服务器将对其他服务器执行独立的迭代查询（代表该客户机），以协助为递归查询提供答案。
    h.DNS诊断工具
    诊断DNS服务主要有以下两种方式：
    ·DNS的管理工具的”监视“（monitoring）标签:通过执行两种类型查询来测试DNS服务器："简单查询"和"递归查询"
    `Nslookup命令,有两种运行模式:a.交互模式(interactive):要求多种数据时使用;b.非交互模式(non-interactive):只要求一种数据时使用.

    3.WINS
    a.WINS为注册和查询网络上计算机和用户组NETBIOS名称的动态映射提供分布式数据库。WINS将NetBIOS名称映射为IP地址，并设计以解决路由环境的NetBIOS名称解析中所出现的问题。
    b.WINS减少使用NetBIOS名称解析的本地IP广播，并允许用户很容易地定位远程网络上的系统。因为WINS注册在每次客户启动并加入网络时自动执行。因此WINS数据库在进行更改动态地址配置时会自动更新。
    c.WINS工作工程：完整的WINS工作过程包括名称注册，名称解析，名称刷新和名称的释放。
    每一项任务一般只需两个步骤（客户请求和服务器响应）即可完成。表现在网络流量上，就是只需要两个帧。



    查看(977) 评论(0) 收藏 分享 管理

  • [转]基本应用层的TCP/IP协议介绍 (HTTP/FTP/POP/SMTP)

    annayin 发布于 2007-05-10 10:13:09

    基本应用层的TCP/IP协议介绍 (HTTP/FTP/POP/SMTP)

    来源：http://www.networkdictionary.com/chinese/protocols/tcpip.php

     

    HTTP：超文本传输协议

    更详细的HTTP协议头信息参考我blog之前的文章。

    HTTP：超文本传输协议
      HTTP：Hypertext Transfer Protocol

    　　超文本传输协议（HTTP）是应用层协议，由于其简捷、快速的方式，适用于分布式和合作式超媒体信息系统。自 1990 年起， HTTP 就已经被应用于 WWW 全球信息服务系统。

    　　HTTP 允许使用自由答复的方法表明请求目的，它建立在统一资源识别器（URI）提供的参考原则下，作为一个地址（URL）或名字（URN），用以标志采用哪种方法，它用类似于网络邮件和多用途网际邮件扩充协议（MIME）的格式传递消息。

    　　HTTP 也可用作普通协议，实现用户代理与连接其它 Internet 服务（如 SMTP 、 NNTP 、 FTP 、 GOPHER 及 WAIS ）的代理服务器或网关之间的通信，允许基本的超媒体访问各种应用提供的资源，同时简化了用户代理系统的实施。

    　　HTTP 是一种请求 / 响应式的协议。一个客户机与服务器建立连接后，发送一个请求给服务器，请求的格式是：统一资源标识符（URI）、协议版本号，后面是类似 MIME 的信息，包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式是：一个状态行包括信息的协议版本号、一个成功或错误的代码，后面也是类似 MIME 的信息，包括服务器信息、实体信息和可能的内容。

    　　HTTP 的第一版本 HTTP/0.9 是一种简单的用于网络间原始数据传输的协议。而由 RFC 1945 定义的 HTTP/1.0 ，在原 HTTP/0.9 的基础上，有了进一步的改进，允许消息以类 MIME 信息格式存在，包括请求 / 响应范式中的已传输数据和修饰符等方面的信息。但是， HTTP/1.0 没有充分考虑到分层代理服务器、高速缓冲存储器、持久连接需求或虚拟主机等方面的效能。相比之下， HTTP/1.1 要求更加严格以确保服务的可靠性。关于安全增强版的 HTTP （即S-HTTP），将在相关文件中再作介绍。


    协议结构

    　　 HTTP报文由从客户机到服务器的请求和从服务器到客户机的响应构成。 请求报文格式如下：

    请求行 通用信息头 请求头 实体头 报文主体

    　　请求行以方法字段开始，后面分别是 URL 字段和 HTTP 协议版本字段，并以 CRLF 结尾。SP 是分隔符。除了在最后的 CRLF 序列中 CF 和 LF 是必需的之外，其他都可以不要。有关通用信息头，请求头和实体头方面的具体内容可以参照相关文件。

    　　应报文格式如下：


    状态行 通用信息头 响应头 实体头 报文主体

    　　状态码元由3位数字组成，表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述，状态码用来支持自动操作，而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头，响应头和实体头方面的具体内容可以参照相关文件。

    相关协议 WWW、FTP、STMP、NNTP、Gopher、WAIS、DNS、S-HTTP
    组织来源 HTTP 定义在 IETF (http://www.ietf.org) 的 RFC 1945和2616中。
    相关链接 http://www.javvin.com/protocol/rfc1945.pdf ：Hypertext Transfer Protocol – HTTP 1.0
    http://www.javvin.com/protocol/rfc2616.pdf ：Hypertext Transfer Protocol – HTTP 1.1

     

     

    FTP：文件传输协议

    FTP：文件传输协议
      （FTP：File Transfer Protocol）


    　　文件传输协议（FTP）使得主机间可以共享文件。 FTP 使用 TCP 生成一个虚拟连接用于控制信息，然后再生成一个单独的 TCP 连接用于数据传输。控制连接使用类似 TELNET 协议在主机间交换命令和消息。

    　　FTP 的主要功能如下：

    • 提供文件的共享（计算机程序 / 数据）；
    • 支持间接使用远程计算机；
    • 使用户不因各类主机文件存储器系统的差异而受影响；
    • 可靠且有效的传输数据。

    　　FTP ，尽管可以直接被终端用户使用，但其应用主要还是通过程序实现。

    　　FTP 控制帧即指 TELNET 交换信息，包含 TELNET 命令和选项。然而，大多数 FTP 控制帧是简单的 ASCII 文本，可以分为 FTP 命令或 FTP 消息。 FTP 消息是对 FTP 命令的响应，它由带有解释文本的应答代码构成。


    协议结构


    命令 描述
    ABOR 中断数据连接程序
    ACCT <account> 系统特权帐号
    ALLO <bytes> 为服务器上的文件存储器分配字节
    APPE <filename> 添加文件到服务器同名文件
    CDUP <dir path> 改变服务器上的父目录
    CWD <dir path> 改变服务器上的工作目录
    DELE <filename> 删除服务器上的指定文件
    HELP <command> 返回指定命令信息
    LIST <name> 如果是文件名列出文件信息，如果是目录则列出文件列表
    MODE <mode> 传输模式（S=流模式，B=块模式，C=压缩模式）
    MKD <directory> 在服务器上建立指定目录
    NLST <directory> 列出指定目录内容
    NOOP 无动作，除了来自服务器上的承认
    PASS <password> 系统登录密码
    PASV 请求服务器等待数据连接
    PORT <address> IP 地址和两字节的端口 ID
    PWD 显示当前工作目录
    QUIT 从 FTP 服务器上退出登录
    REIN 重新初始化登录状态连接
    REST <offset> 由特定偏移量重启文件传递
    RETR <filename> 从服务器上找回（复制）文件
    RMD <directory> 在服务器上删除指定目录
    RNFR <old path> 对旧路径重命名
    RNTO <new path> 对新路径重命名
    SITE <params> 由服务器提供的站点特殊参数
    SMNT <pathname> 挂载指定文件结构
    STAT <directory> 在当前程序或目录上返回信息
    STOR <filename> 储存（复制）文件到服务器上
    STOU <filename> 储存文件到服务器名称上
    STRU <type> 数据结构（F=文件，R=记录，P=页面）
    SYST 返回服务器使用的操作系统
    TYPE <data type> 数据类型（A=ASCII，E=EBCDIC，I=binary）
    USER <username>> 系统登录的用户名


    标准 FTP 信息如下：


    响应代码 解释说明
    110 新文件指示器上的重启标记
    120 服务器准备就绪的时间（分钟数）
    125 打开数据连接，开始传输
    150 打开连接
    200 成功
    202 命令没有执行
    211 系统状态回复
    212 目录状态回复
    213 文件状态回复
    214 帮助信息回复
    215 系统类型回复
    220 服务就绪
    221 退出网络
    225 打开数据连接
    226 结束数据连接
    227 进入被动模式（IP 地址、ID 端口）
    230 登录因特网
    250 文件行为完成
    257 路径名建立
    331 要求密码
    332 要求帐号
    350 文件行为暂停
    421 服务关闭
    425 无法打开数据连接
    426 结束连接
    450 文件不可用
    451 遇到本地错误
    452 磁盘空间不足
    500 无效命令
    501 错误参数
    502 命令没有执行
    503 错误指令序列
    504 无效命令参数
    530 未登录网络
    532 存储文件需要帐号
    550 文件不可用
    551 不知道的页类型
    552 超过存储分配
    553 文件名不允许


    相关协议 TELNET
    组织来源 FTP 由 IETF（http://www.ietf.org）在 RFC 959 中，并由2228、2640 和 2773 重新更新。
    相关链接 http://www.javvin.com/protocol/rfc959.pdf ：File Transfer Protocol（FTP）


     

    POP & POP3：邮局协议(邮局协议第3版)

    POP & POP3：邮局协议(邮局协议第3版)
      POP & POP3：Post Office Protocol

    　　POP 协议允许工作站动态访问服务器上的邮件，目前已发展到第三版，称为 POP3 。 POP3 允许工作站检索邮件服务器上的邮件。 POP3 传输的是数据消息，这些消息可以是指令，也可以是应答。

    　　创建一个分布式电子邮件系統有多种不同的技术支持和途径： POP （邮局协议）、 DMSP （分层式电子邮件系统协议）和 IMAP （因特网信息访问协议）。其中， POP 协议创建最早因此也最为人们了解； DMSP 具有较好的支持“无连接”操作的性能，但其很大程度上仅限于单个应用程序（PCMAIL ）； IMAP 提供了 POP 和 DMSP 的扩展集并提供对远程邮件访问的三种支持方式：离线、在线和无连接。  

    　　POP 协议支持“离线”邮件处理。其具体过程是：邮件发送到服务器上，电子邮件客户端调用邮件客户机程序以连接服务器，并下载所有未阅读的电子邮件。这种离线访问模式是一种存储转发服务，将邮件从邮件服务器端送到个人终端机器上，一般是 PC 机或 MAC 。一旦邮件发送到 PC 机或 MAC 上，邮件服务器上的邮件将会被删除。  

    　　POP3 并不支持对服务器上邮件进行扩展操作，此过程由更高级的 IMAP4 完成。 POP3 使用 TCP 作为传输协议。


    协议结构

    　　POP3 是发送在客户机和服务器间的 ASCII 信息。POP3 命令摘要：

    命令 描述
    USER 用户名
    PASS 用户密码
    STAT 服务器上的邮件信息
    RETR 获取的信息数
    DELE 删除的信息数
    LIST 显示的信息数
    TOP <messageID> <nombredelignes> 从头开始（包含协议头）打印X行信息
    QUIT 退出POP3服务器

    可选POP3命令：

    APOP name digest                             AUTHORIZATION 状态有效；

    TOP msg n                                    TRANSACTION 状态有效；

    UIDL [msg]

    POP3 Replies：

      + OK

      - ERR。


    相关协议 SMTP、IMAP4、TCP、POP
    组织来源 POP3 由 IETF（www.ietf.org）定义在 RFC 1939中。
    相关链接 http://www.javvin.com/protocol/rfc1939.pdf：Post Office Protocol – Version 3

     

    SMTP：简单邮件传输协议

    SMTP：简单邮件传输协议
      （SMTP：Simple Mail Transfer Protocol）

    　　SMTP 是一种提供可靠且有效电子邮件传输的协议。 SMTP 是建模在 FTP 文件传输服务上的一种邮件服务，主要用于传输系统之间的邮件信息并提供来信有关的通知。

    　　SMTP 独立于特定的传输子系统，且只需要可靠有序的数据流信道支持。 SMTP 重要特性之一是其能跨越网络传输邮件，即“ SMTP 邮件中继”。通常，一个网络可以由公用互联网上 TCP 可相互访问的主机、防火墙分隔的 TCP/IP 网络上 TCP 可相互访问的主机，及其它 LAN/WAN 中的主机利用非 TCP 传输层协议组成。使用 SMTP ，可实现相同网络上处理机之间的邮件传输，也可通过中继器或网关实现某处理机与其它网络之间的邮件传输。

    　　在这种方式下，邮件的发送可能经过从发送端到接收端路径上的大量中间中继器或网关主机。域名服务系统（DNS）的邮件交换服务器可以用来识别出传输邮件的下一跳 IP 地址。


    协议结构

    　　SMTP 命令是发送于 SMTP 主机之间的 ASCII 信息，可能命令如下所示：

    命令 描述
    DATA 开始信息写作
    EXPN <string> 在指定邮件表中返回名称
    HELO <domain> 返回邮件服务器身份
    HELP <command> 返回指定命令中的信息
    MAIL FROM <host> 在主机上初始化一个邮件会话
    NOOP 除服务器响应确认以外，没有引起任何反应
    QUIT 终止邮件会话
    RCPT TO <user> 指明谁收到邮件
    RSET 重设邮件连接
    SAML FROM <host> 发送邮件到用户终端和邮箱
    SEND FROM <host> 发送邮件到用户终端
    SOML FROM <host> 发送邮件到用户终端或邮箱
    TURN 接收端和发送端交换角色
    VRFY <user> 校验用户身份

    相关协议 POP3、IMAP4、TCP、POP、FTP
    组织来源 SMTP 由 IETF（www.ietf.org）定义在 RFC2821中。
    相关链接 http://www.javvin.com/protocol/rfc2821.pdf：Simple Mail Transfer Protocol



    Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=845209


    [收藏到我的网摘]   heiyeluren发表于 2006年06月28日 11:35:00

    相关文章：


    特别推荐：

    查看(974) 评论(0) 收藏 分享 管理

  • TCP/IP与UDP报文结构

    cagemm 发布于 2008-04-18 23:21:04

    UDP包
    UDP报头由4个域组成，其中每个域各占用2个字节，具体如下：
    源端口号
    目标端口号
    数据报长度
    校验值
    UDP协议使用端口号为不同的应用保留其各自的数据传输通道。UDP和TCP协议正是采用这一机制实现对同一时刻内多项应用同时发送和接收数据的支持。数据发送一方（可以是客户端或服务器端）将UDP数据报通过源端口发送出去，而数据接收一方则通过目标端口接收数据。有的网络应用只能使用预先为其预留或注册的静态端口；而另外一些网络应用则可以使用未被注册的动态端口。因为UDP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。一般来说，大于49151的端口号都代表动态端口。


    TCP包
    每个tcp都包含源端口号和目标端口号，加上ip头中的源ip和目的ip，唯一确定一个tcp连接。序号用来标识从tcp发端向tcp收端发送的数据字节流，它表示在这个报文段中的第一个数据字节。序号字段包含由这个主机选择的该连接的初始序号isn（Initial Sequence Number）。该主机要发送数据的第一个字节，序号为isn 1，因为syn占用了一个序号。

    IP包
    IPV4报头有12个必需的字段和可选IP选项字段，位于要发送的数据之前。如果使用IP层已有的库或其他组件，一般不必考虑报头中的大多数字段，但程序代码需要提供源端和目的端地址。
    1、版本（4比特）
    IP协议版本已经经过多次修订，1981年的RFC0791描述了IPV4，RCF2460中介绍了IPV6。
    2、报头长度（4比特）
    报头长度是报头数据的长度，以4字节表示，也就是以32字节为单位。报头长度是可变的。必需的字段使用20字节（报头长度为5，IP选项字段最多有40个附加字节（报头长度为15）。
    3、服务类型（8比特）
    该字段给出发送进程建议路由器如何处理报片的方法。可选择最大可靠性、最小延迟、最大吞吐量和最小开销。路由器可以忽略这部分。
    4、数据报长度（16比特）
    该字段是报头长度和数据字节的总和，以字节为单位。最大长度为65535字节。
    5、标识符（16比特）
    原是数据的主机为数据报分配一个唯一的数据报标识符。在数据报传向目的地址时，如果路由器将数据报分为报片，那么每个报片都有相同的数据标识符。
    6、标志（3比特）
    标志字段中有2为与报片有关。
    位0：未用。
    位1：不是报片。如果这位是1，则路由器就不会把数据报分片。路由器会尽可能把数据报传给可一次接收整个数据报的网络；否则，路由器会放弃数据报，并返回 差错报文，表示目的地址不可达。IP标准要求主机可以接收576字节以内的数据报，因此，如果想把数据报传给未知的主机，并想确认数据报没有因为大小的原 因而被放弃，那么就使用少于或等于576字节的数据。
    位2：更多的报片。如果该位为1，则数据报是一个报片，但不是该分片数据报的最后一个报片；如果该位为0，则数据报没有分片，或者是最后一个报片。
    7、报片偏移（13比特）
    该字段标识报片在分片数据报中的位置。其值以8字节为单位，最大为8191字节，对应65528字节的偏移。
    例如，将要发送的1024字节分为576和424字节两个报片。首片的偏移是0，第二片的偏移是72（因为72×8＝576）。
    8、生存时间（8比特）
    如果数据报在合理时间内没有到达目的地，则网络就会放弃它。生存时间字段确定放弃数据报的时间。
    生存时间表示数据报剩余的时间，每个路由器都会将其值减一，或递减需要数理和传递数据报的时间。实际上，路由器处理和传递数据报的时间一般都小于1S，因此该值没有测量时间，而是测量路由器之间跳跃次数或网段的个数。发送数据报的计算机设置初始生存时间。
    9、协议（8比特）
    该字段指定数据报的数据部分所使用的协议，因此IP层知道将接收到的数据报传向何处。TCP协议为6，UDP协议为17。
    10、报头检验和（16比特）
    该字端使数据报的接收方只需要检验IP报头中的错误，而不校验数据区的内容或报文。校验和由报头中的数值计算而得，报头校验和假设为0，以太网帧和TCP报文段以及UDP数据报中的可选项都需要进行报文检错。
    11、源IP地址（32比特）
    表示数据报的发送方。
    12、目的IP地址（32比特）
    表示数据报的目的地。

    查看(551) 评论(0) 收藏 分享 管理

  • TCP/UDP

    Spark.lee 发布于 2007-04-18 10:10:36

    UDP为用户数据报协议，提供无连接服务，每个数据报都有一定长度。UDP不关心数据是否发送成功，这一切需要上层来保证。
    TCP为传输控制协议，提供面向连接，给用户提供全双工的字节流。TCP关心确认、超时和重传等细节。tcp提供流量控制，告诉对方自己的通告窗口（advertised window）

    TCP连接的三次握手
    TCP在建立连接的时候需要三次交互：
    首先，服务器端需要创建SOCKET，并执行bind,listen，监听端口
    1。客户端调用connect函数，这将导致客户端发送一个SYN分节，在SYN中将标明客户端在后续的发送数据中使用的初始序列号k。
    2。服务器端对该SYN进行确认，返回一个ACK(确认应答acknowledge),在ACK中含有服务器期待客户端后续数据的序列号，通常为K+1，另外服务器还发送一个同步分节SYN,里面标明服务器端即将发送数据的初始序列号J。
    3。客户端对该SYN进行确认，同时含有J+1。
    一般每个SYN中含有MSS选项，用来通知对方自己的所能接受的最大分节大小。

    关闭TCP连接
    1。某个应用程序调用close，称这一端为主动关闭（active close）。该端将向另一端发送一个FIN分节，表明数据发送完毕。
    2。收到FIN的一端执行被动关闭（passive close）。TCP对该FIN进行确认，并将该FIN作为文件结束符传递给应用程序。
    3。一段时间后，收到FIN的应用程序调用close。这将导致该另一端发送一个FIN。
    4。主动关闭这一方对该FIN进行确认。
    主动关闭一方在发送FIN后将进入TIME_WAIT状态。该状态将持续最长分节生命期MSL的两倍。

    主要是为了:
     1.实现终止TCP全双工连接的可靠性
     2.允许老的重复分节在网络中消失

    在IPv4中，一个ip数据报的最大大小是65535字节，包括ip头部。当一个IP数据报发出时，如

    果他的大小超过相应链路的MTU,IPv4将会对数据报执行分片。IPv4主机会对其产生的数据报

    执行分片，IPv4路由器对其转发的数据报也会执行分片。另外，IPv4头部有一个选项DF,用来

    表示该数据报不允许分片。如果一个路由器收到一DF设置的数据报且该数据报大小超过MTU,

    则会产生一个ICMPv4的出错消息。

    每个TCP套接字有一个发送缓冲区，当调用write时，内核将从应用程序的缓冲区中拷贝所有

    数据到套接口的发送缓冲区。当套接字的缓冲区不够大，应用程序将被挂起直到套接字的缓

    冲区可以容纳应用程序的缓冲区。在TCP将缓冲区的数据发送出去后，他将在收到对方的确认

    后才将发送数据删除。
    TCP以MSS（Maximum Segment Size最大报文段长度）大小或更小的块发送数据到IP，其中MSS是由对方通告的。如果对方为通告则用536

    查看(648) 评论(0) 收藏 分享 管理

  • UDP 协议

    hililen 发布于 2008-05-04 12:24:01

     

      （UDP：User Datagram Protocol）

    　　用户数据报协议（UDP）是 ISO 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务。 UDP 协议基本上是 IP 协议与上层协议的接口。 UDP 协议适用端口分辨运行在同一台设备上的多个应用程序。  

    　　由于大多数网络应用程序都在同一台机器上运行，计算机上必须能够确保目的地机器上的软件程序能从源地址机器处获得数据包，以及源计算机能收到正确的回复。这是通过使用 UDP 的“端口号”完成的。例如，如果一个工作站希望在工作站 128.1.123.1 上使用域名服务系统，它就会给数据包一个目的地址 128.1.123.1 ，并在 UDP 头插入目标端口号 53 。源端口号标识了请求域名服务的本地机的应用程序，同时需要将所有由目的站生成的响应包都指定到源主机的这个端口上。 UDP 端口的详细介绍可以参照相关文章。  

    　　与 TCP 不同， UDP 并不提供对 IP 协议的可靠机制、流控制以及错误恢复功能等。由于 UDP 比较简单， UDP 头包含很少的字节，比 TCP 负载消耗少。  

    　　UDP 适用于不需要 TCP 可靠机制的情形，比如，当高层协议或应用程序提供错误和流控制功能的时候。 UDP 是传输层协议，服务于很多知名应用层协议，包括网络文件系统（NFS）、简单网络管理协议（SNMP）、域名系统（DNS）以及简单文件传输系统（TFTP）。


    协议结构

    16 32bit
    Source port Destination port
    Length Checksum
    Data

    • Source Port — 16位。源端口是可选字段。当使用时，它表示发送程序的端口，同时它还被认为是没有其它信息的情况下需要被寻址的答复端口。如果不使用，设置值为0。
    • Destination Port — 16位。目标端口在特殊因特网目标地址的情况下具有意义。
    • Length — 16位。该用户数据报的八位长度，包括协议头和数据。长度最小值为8。
    • Checksum — 16位。IP 协议头、UDP 协议头和数据位，最后用0填补的信息假协议头总和。如果必要的话，可以由两个八位复合而成。
    • Data — 包含上层数据信息。

    查看(556) 评论(0) 收藏 分享 管理

  • TCP/UDP网络性能测试工具 - Netperf

    zeus 发布于 2007-10-05 20:28:54

    概述

        在构建或管理一个网络系统时，我们更多的是关心网络的可用性，即网络是否连通，而对于其整体的性能往往考虑不多，或者即使考虑到性能的问题，但是却发现没有合适的手段去测试网络的性能。 
        当开发出一个网络应用程序后，我们会发现，在实际的网络环境使用中，网络应用程序的使用效果不 是很理想，问题可能出现在程序的开发上面，也有可能由于实际的网络环境中存在着瓶颈。面对这种问题，程序员一般会一筹莫展，原因就在于不掌握一些网络性能测量的工具。  
        在本文中，首先介绍网络性能测量的一些基本概念和方法，然后结合 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 一次往返所花费时间就是响应时间。有很多因素会影响到响应时间，如网段的负荷，网络主机的负荷，广播风暴，工作不正常的网络设备等等。 
    在网络工作正常时，记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。 字串9
    3． 网络利用率 字串9
        网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，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）。 字串3

    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是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。 字串1
        第二行显示的就是远端系统接收的情况，由于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等。这些工具有其各自的特色和不同的侧重点，我们可以根据具体的应用环境，有选择的使用它们，这样就可以使这些工具发挥出最大的功效。虽然都是开 放源代码的软件，但是这些工具的功能与商业的网络测试工具同样强大，而且也得到了广泛的应用，熟悉这些工具对我们的实际工作一定会有很大的帮助。 

    参考资料

    Network Performance Open Source Toolkit, Richard Blum, Wiley Publishing, Inc.
    netperf website, http://www.netperf.org

    查看(3928) 评论(3) 收藏 分享 管理

  • TCP and UDP

    andycai 发布于 2007-06-11 11:30:43

    一、TCP
    1、TCP（transport control protocol--传输控制协议）：提供可靠的，面向连接的数据传输服务。
    2、TCP工作原理
    TCP基于两个网络主机之间的点对点通讯，TCP从应用程序接收数据并将数据处理成数据流，数据分成“段”（segment），然后TCP对“段”进行编号和排序以便传递。在两个TCP主机可以交换数据之前，必须先相互建立会话。TCP会话通过“三次握手”的过程初始化。这个过程使序号同步，并提供两个主机之间虚拟连续所需的控制信息。一旦处事的三次握手完成，在发送和接收主机之间按顺序发送和确认段，关闭连接之前TCP使用类似的握手过程验证两个主机都完成发送和接收全部数据。
    3、端口是用来定义，标识计算机上一个应用程序。它分为TCP端口和UDP端口。
    常见的TCP端口号及说明如下：
    20：FTP服务器（数据通道）
    21：FTP服务器（控制通道）
    23：Telnet服务器
    53：域名系统区域传送
    80：WEB服务器（HTTP）
    139：NetBIOS会话服务
    二、UDP
    1、UDP（user datagram protocol--用户数据报协议）：提供快速的，无连接的，无确认的数据包传输服务。
    2.不同于TCP，UDP提供无连接数据报服务，不要求确认信息的返回，不保证数据报的有序性以及不提供出错包的重传机制。UDP常用于网络上的广播和多播通讯，也用于传输少量不重要的数据。
    3、UDP端口提供了发送和接收UDP消息的位置。UDP端口作为单独消息队列工作，接收由每个协议端口号所指定的程序想要的所有数据报。
    4、UDP端口号及说明
    53：DNS名称查询
    69：零碎文件传输协议（TFTP)
    137:NetBIOS名称服务
    138：NetBIOS数据报服务
    161:简单网络管理协议（SNMP)
    520:路由信息协议（RIP）

    查看(667) 评论(0) 收藏 分享 管理

  • mercury系列工具（QTP，LR，TD）下载地址

    jifeng 发布于 2007-12-03 10:22:18

    查看(1955) 评论(3) 收藏 分享 管理

    • 数据统计

    • 访问量: 6834
    • 日志数: 9
    • 图片数: 1
    • 建立时间: 2007-01-10
    • 更新时间: 2017-07-07

    RSS订阅

    Open Toolbar