当今,正处于互联网高速发展的时代,每个人的生活都离不开互联网,互联网已经影响了每个人生活的方方面面。我们使用淘宝、京东进行购物,使用微信进行沟通,使用美图秀秀进行拍照美化等等。而这些每一步的操作下面,都离不开一个技术概念HTTP(Hypertext Transfer Protocol,超文本传输协议)。
举个:chestnut:,当我们打开京东APP的时候,首先进入的是开屏页面,然后进入首页。在开屏一般是广告,而首页是内容相关,包括秒杀,商品推荐以及各个tag页面,而各个tag也有其对应的内容。当我们在进入开屏之前或者开屏之后(这块依赖于各个app的技术实现),会向后端服务发送一个http请求,这个请求会带上该页面广告位信息,向后端要内容,后端根据广告位的配置,挑选一个合适的广告或者推荐商品返回给APP端进行展示。在这里,为了描述方便,后端当做一个简单的整体,实际上,后端会有非常复杂的业务调度,比如获取用户画像,广告定向,获取素材,计算坐标,返回APP,APP端根据坐标信息,下载素材,然后进行渲染,从而在用户端进行展示,这一切都是秒级甚至毫秒级响应,一个高效的HTTP Client在这里就显得尤为重要,本文主要从业务场景来分析,如何实现一个高效的HTTP Client。
一、概念
当我们需要模拟发送一个http请求的时候,往往有两种方式:
1、通过浏览器
2、通过 curl 命令进行发送请求
如果我们在大规模高并发的业务中,如果使用curl来进行http请求,其效果以及性能是不能满足业务需求的,这就引入了另外一个概念 libcurl。
二、实现
在开始实现client发送http请求之前,我们先理解两个概念:
同步请求
异步请求
客户端把请求发送给服务器之后,不会等待服务器返回,而是去做其他事情,待服务器处理完成之后,通知客户端该事件已经完成,客户端在获取到通知后,将服务器处理后的结果返回给调用方。
通过这俩概念,就能看出,异步在实现上,要比同步复杂的多。同步,即我们简单的等待处理结果,待处理结果完成之后,再返回调用方。而对于异步,往往在实现上,需要各种回调机制,各种通知机制,即在处理完成的时候,需要知道是哪个任务完成了,从而通知客户端去处理该任务完成后剩下的逻辑。
下面,我们将从代码实现的角度,来更深一步的理解libcurl在实现同步和异步请求操作上的区别,从而更近异步的了解同步和异步的实现原理。
同步
使用libcurl完成同步http请求,原理和代码都比较简单,主要是分位以下几个步骤:
1、初始化easy handle
2、在该easy handle上设置相关参数,在本例中主要有以下几个参数
-
CURLOPT_URL,即请求的url
-
CURLOPT_WRITEFUNCTION,即回调函数,将http server返回数据写入对应的地方
-
CURLOPT_FOLLOWLOCATION,是否获取302跳转后的内容
-
CURLOPT_POSTFIELDSIZE,此次发送的数据大小
-
CURLOPT_POSTFIELDS,此次发送的数据内容
-
更多的参数设置,请参考libcurl官网
3、 curl_easy_perform,调用该函数发送http请求,并同步等待返回结果
4、 curl_easy_cleanup,释放步骤一中申请的easy handle资源
代码实现(easy_curl.cc)
编译
结果
异步
接 触过网络编程的读者,都或多或少的了解多路复用的原理。 IO多路复用在Linux下包括了三种, select 、 poll 、 epoll ,抽象来看,他们功能是类似的,但具体细节各有不同:首先都会对一组文件描述符进行相关事件的注册,然后阻塞等待某些事件的发生或等待超时。
在使用Libcurl进行异步请求,从上层结构来看,简单来说,就是对easy handle 和 multi 接口的结合使用。其中,easy handle底层也是一个socket,multi接口,其底层实现也用的是epoll,那么我们如何使用easy handle和multi接口,来实现一个高性能的异步http 请求client呢?下面我们将使用代码的形式,使得读者能够进一步了解其实现机制。
multi 接口的使用是在easy 接口的基础之上,将easy handle放到一个队列中(multi handle),然后并发发送请求。与easy 接口相比,multi接口是一个异步的,非阻塞的传输方式。
multi接口的使用,主要有以下几个步骤:
-
curl_multi _init初始化一个multi handler对象
-
初始化多个easy handler对象,使用curl_easy_setopt进行相关设置
-
调用curl_multi _add_handle把easy handler添加到multi curl对象中
-
添加完毕后执行curl_multi_perform方法进行并发的访问
-
访问结束后curl_multi_remove_handle移除相关easy curl对象,先用curl_easy_cleanup清除easy handler对象,最后curl_multi_cleanup清除multi handler对象。
http_request.h
http_request.cc
main.cc
至此,我们已经可以使用libcurl来实现并发发送http请求,当然这个只是一个简单异步实现功能,更多的功能,还需要读者去使用libcurl中的其他功能去实现,此处留给读者一个问题(这个问题,也是笔者项目中使用的一个功能,该项目已经线上稳定运行4年,日请求量在20E ),业务需要,某一个请求需要并发发送给指定的几家,即该请求,需要并发发送给几个http server,在一个特定的超时时间内,获取这几个http server的返回内容,并进行处理,那么这种功能应该如何使用libcurl来实现呢?透露下,可以使用libcurl的另外一个参数CURLOPT_PRIVATE。
三、性能对比
至此,我们已经基本完成了 高性能http 并发功能的设计,那么到底性能如何呢?笔者从 以下几个角度来做了测试:
1、串行发送同步请求
2、多线程情况下,发送同步请求(此处线程为4个,笔者测试的服务器为4C)
3、使用multi接口
4、使用multi接口,并复用其对应的easy handle
5、使用dns cache(对easy handle设置CURLOPT_DNS_CACHE_TIMEOUT),即不用每次都进行dns解析
方法 |
平均耗时(ms) |
最大耗时(ms) |
串行 同步 |
21.381 |
30.617 |
多线程同步 |
4.331 |
16.751 |
multi接口 |
1.376 |
11.974 |
multi接口 连接复用 |
0.352 |
0.748 |
multi 接口使用dns cache |
0 .381 |
0.731 |
四、一点心得
libcurl是一个高性能,较易用的HTTP client,在使用其直接,一定要对其接口功能进行详细的了解,否则很容易入坑,犹记得在18年中的时候,上 线了某一个功能,会偶现coredump(在上线之前,也进行了大量的性能测试,都没有出现过一次coredump),为了分析这个原因,笔者将服务的代码一直精简精简,然后模拟测试,缩小coredump定位范围,最终发现,只有在超时的时候,才会导致coredump,这就说明了为什么测试环境没有coredump,而线上会产生coredump,这是因为线上的超时时间设置的是5ms,而测试环境超时时间是20ms,这就基本把原因定位到超时导致的coredump。
然后,分析libcurl源码,发送时一个libcurl的参数设置导致coredump,至此,笔者耗费了23个小时,问题才得以解决。