本文版权归xmeter.net 所有。欢迎转载，转载请注明出处。
摘要
本文描述了如何利用JMeter来测试TCP/IP Socket应用的性能。文章先对Socket作了一点简单介绍，然后提供并解释了两个样例Socket应用，最后介绍如何利用JMeter来对它们进行测试。
Socket简介
基于TCP/IP协议的Socket（套接字）应用是构成现在互联网的基础，HTTP协议就是建立在端口80上的套接字应用。现在还是有很多应用直接建立套接字，接受客户端的请求并进行相应的业务处理，那么随着业务量的增加，如何对基于套接字的应用进行性能测试呢？本文将介绍如何利用开源的JMeter对基于TCP/IP协议的套接字应用进行性能测试。
套接字应用一般至少需要一对套接字，其中一个运行于客户端，称为ClientSocket ，另一个运行于服务器端，称为ServerSocket 。
服务器和客户端套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。
- 服务器监听：服务器端套接字打开后处于等待连接的状态，等待客户端的连接请求
- 客户端请求：指客户端的套接字发出建立连接请求，要连接的目标是服务器端的套接字。客户端的套接字在连接的时候需要指定服务器端套接字的地址和端口号，然后才能发出连接请求
- 连接确认：当服务器端套接字接收到客户端套接字的连接请求时，就响应客户端套接字的请求，处理完客户端发出的数据后，返回给客户端处理结果。
服务器端一般通过多线程的方式来接受不同用户发出的处理请求，因此同时可以接受多个客户端发出的处理请求。套接字应用中客户端和服务器端之间沟通的数据格式根据应用的设计而定，可以是可读的文本格式，也可以是二进制流的格式，对于这两种不同的格式，JMeter有不同的处理方式。
测试基于文本套接字应用
被测应用的源码请参见这里. 如果想运行该程序，请点击该链接下载socket_echo-0.0.1-SNAPSHOT.jar，并且在命令行下执行:
java -cp socket_echo-0.0.1-SNAPSHOT.jar net.xmeter.echo.TextServer
（请确保您的机器上已经安装了Java）。 该程序会在4700端口建立一个ServerSocket，等待来自客户端的请求，客户端如果发送了一个字符串，服务器端返回“Echo: “ + 客户端发送的字符串。如下图所示，如果我们使用telnet连接到服务器端的套接字应用，双方就可以直接进行通信了。
服务器端：接收到请求并返回客户端“Echo: hello”字符串。
客户端通过telnet连接到服务器端的4700端口，并输入hello
使用JMeter对套接字进行测试，有以下的选项可以做控制：
- TCPClient classname: 缺省的org.apache.jmeter.protocol.tcp.sampler。TCPClientImpl, TCPClient只能实现基于文本格式的套接字应用的测试。随JMeter提供的还有另外的两个实现，分别是BinaryTCPClientImpl和LengthPrefixedBinaryTCPClientImpl，用于处理二进制格式的数据，后文将对这两个做详细的介绍。
- ServerName or IP: 套接字服务器应用的地址
- Port Number: 套接字服务器应用的端口
- Re-use connection: 如果选中，连接会一直处于打开状态，否则读取到数据之后就关闭
- Close connection： 如果选中，在TCP Sampler运行完毕之后就会被关闭
- SO_LINGER：该配置项用于控制在关闭连接之前是否要等待缓冲区中的数据发送完成。如果SO_LINGER选项指定了值，则在得到关闭连接的请求之后还会等待指定的秒数以完成缓冲区中数据的发送，在指定的SO_LINGER秒数完成后，关闭连接。因此，如果你把该选项设置成0，那么所有连接在收到关闭连接的时候都会立即关闭，避免产生很多处于TIME_WAIT状态的套接字。
- End of line(EOL) byte value：判断行结束的byte值，如果你指定的值大于127或者小于-128，则会跳过EOL检测。比如服务器端返回的字符串都是以回车符结尾，那么我们可以将该选项设置成10。
- Connect Timeout：与服务器套接字应用连接超时时间（毫秒）。
- Response Timeout：响应超时时间（毫秒），这个值的设置跟End of line(EOL) byte value有关系，如果End of line(EOL) byte value中的值设置不正确，会导致JMeter一直在等待无法结束，但是如果指定了Response Timeout这个值的话，在到达这个值的时候就关闭连接。
- Set NoDelay：是否使用Nagle算法，是否需要使用该选项，需要跟实际的业务情况结合。
- Text to Send：发送的文本，跟“CSV dataset config”一起使用能够从文件中直接读取。
- Username和Password：这两个选项在TCP相关的Sampler中都未使用，请忽略这两个选项。
针对我们的样例应用，我们的配置如下所示，具体的含义在前面都已经有描述，在这里不再赘述。如果想增加压力，只需调整ThreadGroup中的数目即可。
测试基于二进制套接字应用
被测应用的源码请参见BinaryServer.java。如果想运行该程序，请点击该链接下载socket_echo-0.0.1-SNAPSHOT.jar，并且在命令行下执行:
java -cp socket_echo-0.0.1-SNAPSHOT.jar net.xmeter.echo.BinaryServer
该应用场景是服务器端的套接字应用在接受来自客户端发送的物联网数据的请求，并进行解析及处理（处理逻辑就是在控制台上打印客户端发送过来的值）。客户端发送过来的值的格式如下：
byte[0]: 开始界定符，用于标识数据的开始，值为126，十六进制值为7E
byte[1]: 发送的数据条数，如果一次发送了温度、光照强度和湿度3条数据，则该值为3
byte[2]: 数据1的类型，1为温度，2为光照强度，3为湿度
byte[3]: 数据1的值
byte[4]: 数据2的类型，1为温度，2为光照强度，3为湿度
byte[5]: 数据2的值
…
byte[last]: 校验和
服务器套接字应用在完成处理后，返回给客户端如下格式的值：
byte[0]: 开始界定符，用于标识数据的开始，值为126，十六进制值为7E
byte[1]: 返回码，0为成功，1为失败
byte[3]: 校验和
byte[4]: 回车符作为结束符
JMeter测试脚本中与字符类型相同的在这里就不做解释了，下面描述一下二进制格式测试的不同点：
1）因为现在需要发送的是二进制的数据，所以在“TCPClient classname” 字段中输入的是 org.apache.jmeter.protocol.tcp.sampler.BinaryTCPClientImpl
2）End of line(eol)，服务器端返回的是以回车符为结束的，因此这里输入回车符的ascii码值10，如果你的被测应用不是10结尾，请输入别的值
3）Text to send：发送的数据7E0301010214031EC9，7E是开始界定符，03表示此次传输3条数据，第一条数据为温度，值是0x01；第二条数据类型是光照强度，值为0x14；第三条数据为湿度，值为0x1E，C9为校验和
另外针对该Sampler，脚本里还加了一个断言，验证返回的数据是否正确，可以看到对结果的验证期望是7e00ff0a，其中7e是开始界定符，00是返回码，ff是校验和，0a是回车符。
运行成功的话，在服务器端套接字应用的控制台上能看到下面的信息。
Find the start delimiter at 0.
Received data 1 for sensor temperature.
Received data 20 for sensor brightness.
Received data 30 for sensor humidity.
Correct data. Return with correct response code.
如果读者测试的基于套接字的应用比较复杂，JMeter本身提供的Sampler不能处理，那么可能需要自己扩展TCP Sampler（一般可以通过继承类org.apache.jmeter.protocol.tcp.sampler.TCPClient来实现）。JMeter提供了灵活的插件扩展机制，允许用户实现一些比较个性化的需求。读者可以参见我们写的这篇文章来了解如何扩展JMeter插件。
大规模套接字应用的测试 － XMeter帮您提高效率，降低成本
单台机器能够模拟的套接字客户端是有限的，如果针对大规模的套接字应用的测试，可能需要准备大量的测试机器对被测系统进行打压，这个过程需要大量的准备机器环境，以及管理这些环境的工作，导致工作效率比较低、而且容易出错。XMeter将这些过程迁移至云端，弹性伸缩管理这些压力机，用户只要关注测试脚本的实现过程，而无需关心这些测试环境的管理，从而大大降低了大规模性能测试的复杂度。另外XMeter提供了丰富的测试报告，让性能问题一目了然。
关于我们
XMeter成立于2016年，核心团队都来自于IBM，是一家领先技术的性能测试持续集成咨询与服务提供商。我们致力于提供给客户可靠,简单,低成本的性能测试解决方案。
