测试客户端

3 篇文章 0 订阅

项目要求

目的

自己模拟一个curl函数,但是curl命令是自己构造一个HTTP请求发送给我们的目标服务器,而我们是自己构造一个HTTP请求发送给我们的命令行参数第二个参数(url),然后再从服务器端接受响应打印到标准输出

 

我们的执行命令是

./client https://www.baidu.com/

 

程序开始执行之后根据提示从标准输入中一行一行的读取字符串然后去构造HTTP请求

 

HTTP报文的一些知识

HTTP请求格式

1.无body

 

2.有body

例子

而我们要构造的HTTP请求是这样的,这是我从fidder中从浏览器中随便抓包出来的一个HTTP请求,其中第一行是首行,从第二行开始就是header,其实我们随便什么请求都可以都是从标准输入中读取的而已,我们下面的这个只是举个栗子而已


 

CONNECT www.baidu.com:443 HTTP/1.1

Host: www.baidu.com:443

Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.99 Safari/537.36

 

项目过程

 

1.首先用域名解析函数来解析我们输入的域名解析出我们的IP,端口号一般的浏览器是都80

我们所用的域名解析函数如下

此函数的一般使用方法如下,我下面写了一个例子

#include <netdb.h>

struct hostent *gethostbyname(const char * hostname);

例子:从标准输入中读一个url,并对它进行解析,解析出IP,输出

int main(int argc, char *argv[])

{

struct hostent *h;

char hostname[40];

printf("请输入域名\n");

scanf("%s",hostname);

getchar();

if((h=gethostbyname(hostname))==NULL)

{

fprintf(stderr,"不能得到IP\n");

exit(1);

}

printf("HostName :%s\n",h->h_name);

printf("IP Address :%s\n",inet_ntoa(*((struct in_addr *)h->h_addr)));

return EXIT_SUCCESS;

}

 

2.解析出IP之后进行socket的连接,使用connect函数

connect函数

函数定义:int connect(SOCKET s, const struct sockaddr * name, int namelen);



函数说明:

s:标识一个未连接socket

name:指向要连接套接字的sockaddr结构体的指针

namelen:sockaddr结构体的字节长度

 

3.连接成功服务器之后开始根据提示构造HTTP请求

write函数

函数定义:ssize_t write (int fd, const void * buf, size_t count); 



函数说明:

write()会把参数buf所指的内存写入count个字节到参数放到所指的文件内。

如果顺利write()会返回实际写入的字节数。当有错误发生时则返回-1,错误代码存入errno中。

 

4.发送成功了之后,再使用read函数从socket中读取HTTP响应


 

read函数

函数定义:ssize_t read(int fd, void * buf, size_t count);



函数说明:

read()会把参数fd所指的文件传送count 个字节到buf 指针所指的内存中。

返回值为实际读取到的字节数, 如果返回0, 表示已到达文件尾或是无可读取的数据。若参数count 为0, 则read()不会有作用并返回0。

 

5.最后我们将我们读到的HTTP响应进行处理了之后打印到标准输出上

 

贴上处理HTTP响应的函数

 

 

 

服务器性能测试的常用指标

【吞吐量】 固定时间间隔内的处理完毕事务个数。通常是1秒内处理完毕的请求个数,单位:事务/秒(tps)。

【平均吞吐量】一段时间内吞吐量的平均值。无法体现吞吐量的瞬间变化。

【峰值吞吐量】一段时间内吞吐量的最大值。是用来评估系统容量的重要指标之一。

【最低吞吐量】一段时间内吞吐量的最小值。如果最小值接近0,说明系统有“卡”的现象。

【70%的吞吐量集中区间】通过统计15%和85%的吞吐量边界值,计算出70%的吞吐量集中区间。区间越集中,吞吐量越稳定。

【响应时间】一次事务的处理时间。通常指从一个请求发出,到服务器进行处理后返回,再到接收完毕应答数据的时间间隔,单位:毫秒。

【平均响应时间】 一段时间内响应时间的平均值。无法体现响应时间的波动情况。

【中间响应时间】一段时间内响应时间的中间值,50%响应时间,有一半的服务器响应时间低于该值而另一半高于该值。

【90%响应时间】一段时间内90%的事务响应时间比此数值要小。反应总体响应速度,和高于该值的10%超时率。是用来评估系统容量的重要指标之一。

【最小响应时间】响应时间的最小值。反映服务最快处理能力。

【最大响应时间】响应时间的最大值。反映服务器最慢处理能力。

【CPU占用率】1-CPU空闲率,表示CPU被使用情况,反映了系统资源利用情况。

 

项目感悟

最后通过这次的项目,对HTTP请求又有了更深入的了解,遇到了一些困难但是最后还是都完美解决,虽然项目中存在一些小细节的问题,总体来说还是大致正确的能发送给服务器请求还能从服务器端接受响应并打印,之后再在慢慢修改吧

 

最后贴上项目的码云地址,有兴趣的可以下载看看

https://gitee.com/zmmya/client

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
说明: 1, 暂未实现重传机制, 所以若抓包无响应, 请尝试停止后重发. 2, dhcp状态显示采用1s定时器刷新, 所以状态显示可能存在延时的情况; 3, xcap通过pcap导入报文会有部分字段自动变化, 且导入的报文DHCP数据部分无法正常解析, 建议通过新建的方式解决; 4, 添加报文格式举例: 1,2 说明: 1表示报文组1, 选中报文组后, 在状态栏会显示报文组的索引, 2表示第三个报文, 即索引为3的报文. 版本记录: V1.0.1(基础版本) 1, 支持连接xcap并读取报文功能; 2, 支持刷新按钮自动更新报文功能; 3, 支持选择网卡功能; 4, 支持通过pcap文件打开报文功能(已废弃); 5, 支持指定服务器交互; 6, 支持dhcp交互状态显示; 7, 支持输入框通过正则表达式限制输入字符; 8, 支持选择特定报文操作; V1.0.2 1, 将状态修改为自动显示, 即动态识别报文类型并显示结果; 2, 解决解析option字段, 若字段中存在多个value时存在丢失的问题; 3, 增加鼠标点击状态显示气泡信息; 4, 增加隔行显示不同颜色; V1.0.3 1, 修改dhcp的状态机, 之前的版本是收到报文则发送request, 之后收到报文则认为收到ack. 现修改为只有收到offer报文才发送request报文 , 收到ack报文才结束. 2, 增加dhcpv6功能; 3, 优化代码; V1.0.4 1, 修改request报文由于校验和和报文长度未初始化导致构造错误的问题 V1.0.5 1, 增加服务器地址的气泡提示; 2, 增加自动填充的气泡提示; 3, 添加的报文默认为选中状态; 4, 选择网卡下拉框中将虚拟网卡排放靠后; 5, 关闭程序时自动保存设置; V1.0.6 1, 优化代码, 将字段设置使用统一的函数处理; 2, 状态气泡显示格式化; 3, 双击表格表头实现全选和反选; 4, 增加renew(50%), rebind(87.5%)和release的自动发送功能; 5, 增加手动释放按钮和实现; 6, 增加部分打印信息用于调试; 暂未实现报文重传机制, 计划下一个版本实现 V1.0.7 1, 实现discover/solicit报文自动重传机制 2, renew, rebind以及release修改为手动发送 3, 解决报文发送错乱问题 4, 增加decline报文的发送 5, 解决设备无故发送discover报文问题 问题解决: 1, 停止后再次发送数据会出现数据错乱 分析: 停止客户端的时候, 删除过滤器是通过callback函数删除的, 这里应该是通过filter来进行删除. self.widget.sniff.del_filter(self.callback)修改为 self.widget.sniff.del_filter(self.filter) 2, 设备无故发送discover问题 分析: 由于发送discover报文使用的定时器, 定时器是通过判断当前的direction来确定是否重传的, 而当定时器老化时, 可能正好收到报文导 致direction被修改, 所以导致错误的发送discover报文的问题. 将接收逻辑修改为重传时判断当前状态是否为discover报文, 若是则重传, 否则不重传. V1.0.8 1, 增加inform实现 V1.0.9 1, 增加报文五元组的源mac地址和xid的气泡显示; 2, 增加步长和报文限制功能; 问题解决: 1, 修改ipv6报文添加失败的问题. 由于ipv4报文为xid, ipv6报文为trid, 需要区分处理. V1.0.10 1, 在发送dhcpv6报文之前, 先发送na报文触发服务器学习nd消息. V1.0.11 1, 增加发送solicit/request前, 自动响应ns报文. 自动响应ns报文的目标地址为solicit/request报文源mac地址生成的ipv6地址 2, 实现dhcpv6的renew续约功能. 3, 解决ipv6地址转换格式化不正确, 导致无法响应ns报文问题. 4, 增加日志输出到dhcp.log文件. V1.0.12 1, 增加dhcpv6的续约功能, 通过renew和rebind实现续约, 增加release、decline报文的实现; V1.0.13 1, 解决服务器无法设置ipv6地址的问题. 之前的输入框只允许输入数字和., 修改为运行输入数字.:和a-f 2, 解决多个客户端时, 若选中其中的部分客户端发送时报错. 由于客户端采用的是列表中包含元组的形式, 即[(row, [client1, client2])], 这样实际客户端无法直接通过row索引到clients, 导致列表读 取时溢出. 譬如有1、2、3三行数据, 这里只选中了第三行, 限制为1, 那么如果点击发送, 则clients = [(row, [client1]], 此时clients[2] 就会溢出. 所以这里讲clients修改为字典, 即通过row来索引客户端client = {3: [client1]} 3, 将数据发送放到线程中, 规避模拟大量客户端时界面假死的问题. 4, 当客户端限制小于等于50, 则气泡显示trid和ip地址信息. 当大于50, 则气泡显示获取ip地址的数量. V1.0.14 1, 解决监听报文使用的网卡不正确问题. V1.0.15 1, 解决dhcpv6的响应报文的IANA中包含Status code选项导致程序无法解析的问题. 兼容性处理, 即option为IAAddress时按照IAAddress解析, 当option为status code时按照Status code解析 V1.0.16 1, 解决DHCPv6的client_id的duid处理, 支持任意格式的duid.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值