构造HttpClient三部曲

2011年5月16日 | 分类: 代理工具 | 标签: , , , , ,

构造HttpClient三部曲之一:支持代理的Socket封装

最近在重构闪印的网络部分的代码——原因不外乎当时写的时候太着急,很多东西都没有好好的封装,将就着能用就行了。而挪到Ebox中为了传说中的平台无 关,像FileStream,Socket之类的用了大量JUCE的封装,觉得异常恶心,而由于种种原因目前很清闲,于是开始重构这部分的代码(实际上是 自己从头写起……),目前也整了个大概了,于是可以写写总结:《构造HttpClient三部曲》。

话说工欲善其事,必先利其器,而构造HttpClient的器就是可支持代理的Socket封装类——当初自己写HttpClient而不是使用 WinInet之类的库很大部分原因就是WinInet只支持Http代理而不支持Socks的代理,所以只能自己动手丰衣足食了。(话说很奇怪微软的很 多东西都是这样只支持HTTP代理,比如C#中比较有名的ProxySocket都是别人写的)而C++方面貌似也没有支持代理的HTTP库,倒是C方面有个curl,如果自己懒得封装Http倒是可以拿来用。

言归正传,说ProxySocket的封装。大体来说代理服务器分为三种:http,ftp和socks,更有透明代理(比如公司的翻墙代理就是种透明代 理)和非透明代理之分。而这里我只关心http和socks这两种比较常见的非透明代理,至于ftp代理貌似只能从文献中听闻了,基本很少有什么服务器提 供这样的代理。当机器通过代理服务器上网时,整个通讯过程是分为两个部分的:机器和代理通讯,代理和目的地址通讯,这样一来客户端需要关心的就只有:和代 理服务器完成一次对传输协议协商握手过程,在这之后就可以把代理服务器看成目标地址了。

 

HTTP代理

当客户端连接上一个HTTP代理服务器后并通过它发送请求,代理服务器做的事情就是:建立和目标地 址的连接,发送请求,接受反馈并将反馈发回客户端。为了实现这一点,在HTTP协议中规定了这么一个特殊方法:CONNECT。当客户端和HTTP代理服 务器连接后,只需要发送如下格式的HTTP请求即可:

CONNECT <destanation_address> : <destanition_port> <http_version><CR><LF>
Host: <destanation_address> : <destanition_port><CR><LF>
<optional_header_line><CR><LF>
<optional_header_line><CR><LF>
……
<CR><LF>

 

而如果代理需要验证用户名密码则需要将”用户名:密码”进行Base64编码后填入:

CONNECT <destanation_address> : <destanition_port> <http_version><CR><LF>
Host: <destanation_address> : <destanition_port><CR><LF>
Authorization: Basic <base64后的验证字段><CR><LF>
Proxy-Authorization: <Basic base64后的验证字段><CR><LF>
<optional_header_line><CR><LF>
……
<CR><LF>

即:(再次怨念一下狗屎的代码格式化插件)

01if (!_proxy_config._host_name.empty())
02{
03 std::string auth = _proxy_config._host_name + ":" + _proxy_config._password;
04 std::string base64_encode_auth;
05 Util::base64Encode(auth,base64_encode_auth);
06 sprintf_s(buff,max_buffer_length,"CONNECT %s:%d HTTP/1.1\r\nHost: %s:%d\r\nAuthorization: Basic %s\r\nProxy-Authorization: Basic %s\r\n\r\n",
07 _host_name,_port_number,_host_name,_port_number,base64_encode_auth,base64_encode_auth);
08}
09else
10{
11 sprintf_s(buff,max_buffer_length,"CONNECT %s:%d HTTP/1.1\r\nHost: %s:%d\r\n\r\n",
12 _host_name,_port_number,_host_name,_port_number);
13}

而在请求后如果收到正确反馈即表示代理连接成功。(一般就是code = 200)这里值得说明的一点是:上述代码只是对Basic这种验证方式做了处理,这种明文传输的形式是很不安全的。当然还有一种验证方式是NTLM,相对 而言比较复杂,不赘述。(实际上是没空去看…)

 

Socks4代理

Socks4的代理连接请求相比Http代理要简单不少,而且Socks4是不支持用户验证的。整个Socks4的请求就包含5个字段而已:

字段一:Socks版本号,即0×04,占一个字节。

字段二:命令码,占一个字节,其中0×01:TCP/IP连接,而0×02:端口绑定。

字段三:网络字节序端口,占两个字节。

字段四:网络字节序IP地址,占四个字节。

字段五:用户ID字段,可变,以null(0)结尾。

而服务器返回的反馈则更加简单,一共包含4个字段:

字段一:一个空字节

字段二:一个字节,表示反馈状态码,其中0x5A(即90)表示请求被接受。

字段三:两个字节,可被忽略

字段四:四个字节,可被忽略

可以看出实际上整个Sock4的请求和反馈都是异常简单:SOCK4的反馈甚至只有一个字节是有意义的,很轻松就可以搞定:

01//Socks4没有用户密码验证
02struct Sock4Reqeust
03{
04 char VN;
05 char CD;
06 unsigned short port;
07 unsigned long ip_address;
08 char other[256]; // 变长
09} sock4_request;
10
11struct Sock4Reply
12{
13 char VN;
14 char CD;
15 unsigned short port;
16 unsigned long ip_address;
17} sock4_reply;
18
19sock4_request.VN = 0x04; // VN是SOCK版本,应该是4;
20sock4_request.CD = 0x01; // CD是SOCK的命令码,1表示CONNECT请求,2表示BIND请求;
21sock4_request.port= ntohs(_port_number);
22sock4_request.ip_address = SocketHelper::getIntAddress(_host_name.c_str());
23sock4_request.other[0] = '\0';
24
25if (sock4_request.ip_address == INADDR_NONE)
26 return false;
27
28//发送SOCKS4连接请求
29int ret =  _socket.write((char*)&sock4_request,9);
30if (ret <= 0)
31{
32 return false;
33}
34//获得Socks4代理的回复
35ret = _socket.read((char *)&sock4_reply, sizeof(sock4_reply));
36if (ret <= 0)
37{
38 return false;
39}
40/*
41CD是代理服务器答复,有几种可能:
4290,请求得到允许;
4391,请求被拒绝或失败;
4492,由于SOCKS服务器无法连接到客户端的identd(一个验证身份的进程),请求被拒绝;
4593,由于客户端程序与identd报告的用户身份不同,连接被拒绝。
46*/
47return sock4_reply.CD == 90;

值得注意的是由于代码中是用结构体表示相应的字段集合,要考虑到字节对齐对结构体字段排放的影响需要指定

#pragma pack(1)。强制以一个字节对齐。Socks4还有一种变种叫做Socks4a,具体就不介绍了,可以参看这里

 

Socks5代理

Socks5是Socks4的一个升级版本,增加了很多Socks4不支持的特性,比如对IPv6的支持。一个完整的Socks5代理握手协议可以分为如下五个步骤:

1.客户端发起握手请求,参数为可支持的验证方法列表

2.服务器选择一种验证方式并返回(如果无可支持的验证方式直接返回失败)

3.根据所选验证方式,客户端和服务端进行验证方式上的协商(比如选择了用户名/密码这种方式进行验证,客户端就需要发送用户和密码过去,然后服务器进行验证并返回结果)

4.客户端发起一个类似于Socks4的请求

5.服务端返回一个类似Socks4的反馈

这样经过五个步骤,客户端和服务端的握手就算完成了,接下来就是直接进行数据传输即可。

Socks5可支持的验证方式包括:

0×00:无验证

0×01:GSSAPI

0×02:用户名/密码

0×03-0x7F:IANA指定的方法

0×80-0xFE:保留方法

对于我们这个简单的ProxySocket来说完全可以只关心0×00和0×02即可,其他几种方式一来不常见,二来也没有太大的实现必要。

客户端发起的第一个请求总共包括三个字段:

字段1:Socks版本号,即0×05

字段2:支持的验证方式数,一个字节

字段3:验证方法列表,变长,一个字节表示一个方法

服务端在收到这个请求后,返回一个验证方法的反馈,一共就两个字段:

字段1:Socks版本号,一个字节,即0×05

字段2:选择的验证方法,一个字节,如果在客户端发来的验证方法列表中没有服务端支持的方法,则返回0xFF

这个时候客户端可以根据服务端饭回来的验证方法进行验证:0×00则直接跳过第三步。一个典型的用户名/密码验证请求如下:

字段1:版本号,一个字节,必须指定为0×01

字段2:用户名长度,一个字节

字段3:用户名,变长

字段4:密码长度,一个字节

字段5:密码,变长

服务端返回如下的反馈:

字段1:版本号,一个字节 (这个其实可以忽略)

字段2:状态码,一个字节,0×00表示成功,其他值则表示验证失败,连接需要断开。

这以后的工作就基本和Sock4相似了,客户端发起一个连接请求:

字段1:Socks版本号,一个字节,即0×05

字段2:命令码,一个字节,0×01:TCP/IP连接,0×02:TCP/IP端口绑定,0×03:关联UDP端口

字段3:保留字段,一个字节,必须指定为0×00

字段4:地址类型,一个字节,0×01:IPv4地址,0×03:域名,0×04:IPv6地址

字段5:目标地址:4字节表示的IPv4地址,或者16字节表示的IPv6地址,如果是域名则是变长:一字节表示域名长度,紧随其后的是域名

字段6:网络序的端口号,两个字节

服务器的反馈为:

字段1:Sock协议版本,一个字节,必须为0×05

字段2:状态码,0×00表示请求成功,其余的状态码可参考相应的RFC文档

字段3:保留字段,一个字节,必须制定为0×00

字段4:地址类型,一个字节,0×01:IPv4地址,0×03:域名,0×04:IPv6地址

字段5:目标地址,4字节表示的IPv4地址,或者16字节表示的IPv6地址,如果是域名则是变长:一字节表示域名长度,紧随其后的是域名

字段6:网络序的端口号,两个字节

这样一个完整的Socks5握手协议就算完成了,但是鉴于代码篇幅太长了,这里就不上了,等整个HttpClient介绍完毕后再统一上代码…….(实际上是…某些地方的代码还没整清爽,无颜见公婆啊)

 

参考资料:

1.Wiki中关于Sock5的介绍:http://en.wikipedia.org/wiki/SOCKS

2.《Http Tunneling》:http://www.codeproject.com/KB/IP/httptunneling.aspx

3.《CAsyncProxySocket – CAsyncSocket derived class to connect through proxies》:http://www.codeproject.com/KB/IP/casyncproxysocket.aspx

 

构造HttpClient三部曲之二:GET方法实现

继续HttpClient构造的博文,第二篇:GET方法的实现。HTTP协议定义了和服务器交互的不同方法,包括 GET,POST,PUT,DELETE,CONNECT等等,但是最基本的同时也是用的最多的两个方法就是GET和POST。这篇先讲讲GET方法的一 些细节.

HTTP协议的交互主要有请求和响应组成:客户端发起请求,服务端返回响应。而一个简单的HTTP请求又可以分成信息头和信息体。对于GET来说,它的请求只有HTTP消息头而已。

HTTP请求之GET

一个最简单的HTTP GET请求可以写成:

GET <resouce_path> <http_version> <CR><LF>
HOST : <host_address><CR><LF>
<CR><LF>

而复杂的请求往往会加入很多的请求头域,如:

GET /logos/2011/hargreaves11-hp-15.jpg HTTP/1.1
Host: www.google.com.hk
Connection: keep-alive
Referer: http://www.google.com.hk/
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3

每一个头域都有一个域名,冒号(:)和域值组成。域名是大小写无关, 而域值前面可以添加数个空格。之所以将前面那段字特地高亮是因为碰到很多“不太规范”的HTTP Server返回的域名经常是不“正规”的:比如将Content-Type写成Content-type—-这只是从视觉上不太美观,但是绝对是符合规 范的,所以客户端在解析的时候特别要注意忽略大小写的影响。

一些典型的头域有:

 

Host:指定请求资源的主机和端口

Connection:指定连接状态,HTTP1.1和1.0协议的一个很大区别就是HTTP1.1可以保持连接,HTTP1.1默认是持久连接,一次连接可以发起多个请求。

User-Agent:包含发出请求的用户信息,多用于系统和浏览器检测。关于它的八卦可以参考这里

Referer:请求URI的源地址。一般可用于反盗链。

Accept:可接受的文件类型

当然我们也可以往HTTP头中塞入一些自定义的头域,这样的效果和在URL添加请求参数的效果是一样的。

 

HTTP响应

无论是GET方法还是POST方法,HTTP的响应都是一致的:一个HTTP消息头和一个 HTTP消息体。在HTTP消息头的第一行指定了:HTTP版本号,HTTP响应码和详细消息。而接下来就是一个个头域,直到接受到两 个<CR><LF>为止。一个典型的HTTP相应的消息头如下:

HTTP/1.1 200 OK

Cache-Control: private, max-age=30

Content-Type: text/html; charset=utf-8

Content-Encoding: gzip

Expires: Mon, 25 May 2009 03:20:33 GMT

Last-Modified: Mon, 25 May 2009 03:20:03 GMT

Vary: Accept-Encoding

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

Date: Mon, 25 May 2009 03:20:02 GMT

Content-Length: 12173

对于客户端来说需要着重关注的头域一般只有Content-LengthTransfer-Encoding而 已。如果返回的HTTP消息头中有Content-Length这个头域则说明HTTP体是定长的,客户端只需要继续接受Content-Length指 定的数据长度的内容即可。而如果服务器在返回数据给客户端时是一边生成数据一边发送,那么很可能就会采用chunked的形式,将Transfer- Encoding指定为chunked。这样客户端对HTTP消息体的处理就会稍显复杂。

在HTTP协议的RFC中对chunk传输的定义如下:

Chunked-Body   = *chunk
last-chunk
trailer
CRLF
chunk          = chunk-size [ chunk-extension ] CRLF
chunk-data CRLF
chunk-size     = 1*HEX
last-chunk     = 1*(“0”) [ chunk-extension ] CRLF
chunk-extension= *( “;” chunk-ext-name [ “=” chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val  = token | quoted-string
chunk-data     = chunk-size(OCTET)
trailer        = *(entity-header CRLF)

简单来说就是:一个chunked编码的body可以分为四个部分:一系列的chunk段,last chunk,trailer和CRLF。一个chunk又可以分为chunk-size和chunk-data两部分。通过解析chunk- size(16进制)可以获取到真正的chunk-data长度并进行拼接得到最后的HTTP体内容。RFC中关于chunk的解析伪代码如下:

length := 0
  read chunk-size, chunk-ext (if any) and CRLF
  while (chunk-size > 0) {
  read chunk-data and CRLF
  append chunk-data to entity-body
  length := length + chunk-size
  read chunk-size and CRLF
  }
  read entity-header
  while (entity-header not empty) {
  append entity-header to existing header fields
  read entity-header
  }
  Content-Length := length
  Remove "chunked" from Transfer-Encoding

为了构造这个HTTPClient我也相应写了C++版的处理方法,不过没有考虑chunk-extension和entity-header的处理(在我测试的几个网站来看都没有这两个值,所以即使写了也无法验证其正确性),将这部分片段摘录如下:

01//接受并解析chunk内容
02while(true)
03{
04 //如果在上次已经查询到第一块chunk的大小
05 if (find_first_chunk)
06 {
07 if (chunk_size == 0)//如果是最后一块了
08 {
09 complete = true;
10 break;
11 }
12 else //否则分析chunk内容并进行切割
13 {
14 size_t length        = body.length();
15 size_t first_chunk    = chunk_size_length + 2 + chunk_size + 2;
16 if (length >= first_chunk) //如果已经接受到一整块chunkdata了则进行切割,否则重新接受
17 {
18 find_first_chunk        = false;
19 std::string chunk_data    = body.substr(chunk_size_length + 2, chunk_size);
20 body.erase(0,first_chunk);
21 if (!response_receiver->write(chunk_data.c_str(),chunk_data.length()))
22 {
23 setErrorCode(HTTPERROR_IO);
24 break;
25 }
26 }
27 else
28 {
29 if (!continueToReceiveBody(body))
30 {
31 setErrorCode(HTTPERROR_TRANSPORT);
32 break;
33 }
34 }
35 }
36 }
37 else//查找chunk_size
38 {
39 size_t index = body.find("\r\n");
40 if (index != std::string::npos) //找到,做标记
41 {
42 find_first_chunk            = true;
43 chunk_size_length            = (int)index;
44 std::string raw_chunk_size    = body.substr(0,chunk_size_length);
45 chunk_size                    = (int)strtoul(raw_chunk_size.c_str(),0,16);
46
47 }
48 else //没有找到,继续接受信息
49 {
50 if (!continueToReceiveBody(body))
51 {
52 setErrorCode(HTTPERROR_TRANSPORT);
53 break;
54 }
55 }
56 }
57}

至此一个完整的GET方法HTTP请求响应就完成了,相应的代码checkout这里:http://amaoproject.googlecode.com/svn/trunk/

 

构造HttpClient三部曲终篇:POST方法实现

手机新买,新鲜感未过,几乎一天都在安装试用卸载各种搞毛软件中度过,差点忘了要在这周结束掉HttpClient的博文,趁着还有3个小时才12点赶紧写完。

上一篇介绍了GET方法的实现,这篇主要就介绍介绍POST。从上层来看,GET和POST最大的区别在于GET是一种从服务器获取数据的请求,而POST是向服务器传送数据,进行站点更新。而从协议上来看,POST和GET的最大区别在于:POST请求是包含HTTP消息体的,较GET能够实现更复杂的数据交互。通过上一篇我们已经知道一个GET请求是只有HTTP消息头的,虽然它也能够带上参数:将参数和请求的URL以?分开,但是一来请求的数据量很少,二来因为请求格式的固定化导致不能有效表达一些复杂的请求,而POST则没有这样的问题了。

HTTP请求之POST

和GET方法不同,POST有自己的HTTP请求体,这样也必然要求POST方法必须在HTTP请求头指明请求体的类型和长度:即content- type和content-length。content-type指明了Http消息体内的数据以怎样的结构进行组织,而content-length 则指明了http消息体的长度。一个典型的POST请求如下:

POST /cwf_nget?param=[] HTTP/1.1
Host: friend.renren.com
Connection: keep-alive
Referer: http://friend.renren.com/ajaxproxy.htm
Content-Length: 24
Origin: http://friend.renren.com
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24
Content-Type: application/x-www-form-urlencoded
Accept: */*
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3

requestToken=-1000000000

例子中的content-type为application/x-www-form-urlencoded,即需要对HTTP体进行URL编码。而 content-length为24,即后面requestToken=-1000000000的长度。当然Content-Type有很多种,比如 text/plain,text/xml等等,具体的意义可以参考这里。 而唯一值得拿出来说的一种content-type是multipart/form-data的情况。顾名思义这种content-type要求HTTP 体是以多段的格式发送,主要是为了能够通过HTTP协议上传文件。当然也可以只用这种编码方式来分段上传请求数据,不过不免有点脱裤子放屁之嫌。

 

 

一个典型的以multipart/form-data上传文件的Http包如下:

POST /upload HTTP/1.1
Host: upload.buzz.163.com
Connection: keep-alive
Referer: http://t.163.com/
Content-Length: 8993
Cache-Control: max-age=0
Origin: http://t.163.com
User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.60 Safari/534.24
Content-Type: multipart/form-data; boundary=—-WebKitFormBoundaryoF81IsooBo64lBY2
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Encoding: gzip,deflate,sdch
Accept-Language: zh-CN,zh;q=0.8
Accept-Charset: GBK,utf-8;q=0.7,*;q=0.3
Cookie: _ntes_nuid=b243d3e6005fcc75916dcf6a05a1231d; vjuids=-115573d47.12ba116f81c.0.6e77627f; ALLYESID4=00101015004134494510218; isGd=0; isFs=0; OUTFOX_SEARCH_USER_ID=-1937482032@10.130.10.67; __utmz=187553192.1299506530.4.3.utmcsr=blog.163.com|utmccn=(referral)|utmcmd=referral|utmcct=/lgh_2002/; USERTRACK=60.186.110.113.1302880928690537; __utma=187553192.1936313005.1288621751.1301116115.1304778661.6; MAIL163_SSN=xiang.wangfeng; Province=0571; City=0571; NTES_LOGINED=true; vjlast=1286897859.1305430125.11;

——WebKitFormBoundaryoF81IsooBo64lBY2
Content-Disposition: form-data; name=”callback”

uploadImageCallback
——WebKitFormBoundaryoF81IsooBo64lBY2
Content-Disposition: form-data; name=”watermark”

t.163.com/amao
——WebKitFormBoundaryoF81IsooBo64lBY2
Content-Disposition: form-data; name=”Filedata”; filename=”head_5685p40.jpg”
Content-Type: image/jpeg

??.JFIF…..x.x..?C………………….
…..

..

…………………….?C…….    ..    .
.
…………………………………………..?…d.d……….?………………………?B…………
…………..!1A.”Q..2aq?.#態?Rbr偙$4DSUct儞擦佯?……………..曘膇X.s菢t=5Y鰦.?.敠婂糩輾纽脡昍獛.h塱7鶛フ3?xA/.[B}.渀hn提挮mN笢菨扦.跍Ni?胘?祻?牛S喁膷
;.g 鉉`.逽枻%.9歩)<€?芋s    鼠狿鍸h?P竐>犚倳攧侽!Θ.俰F?!Z €u€币雽?j.頎??雙iZG%? ?堈..Ie湊趻?.r.-l?.n(#洓’b.,$? y@)虏J堧蟁訷YF攬偧I蘵嶮診    繡`|摥薫?. PG?
(此处删去N多字节….)

——WebKitFormBoundaryoF81IsooBo64lBY2–

HTTP消息头中指明了content-type为multipart/form-data并给出了boundary。boundary的主要作用 是进行分割HTTP消息体中的内容,一般的格式都是前面带几个“-”号,然后跟一堆随机字符。整个HTTP消息体以boundary+两个”-“做结尾。

至于HTTP响应就和GET方法是一样的,不赘述了。关于POST相关的代码可以参考这里

 

原文:

http://www.xiangwangfeng.com/2011/05/06/%E6%9E%84%E9%80%A0httpclient%E4%B8%89%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%B8%80%EF%BC%9A%E6%94%AF%E6%8C%81%E4%BB%A3%E7%90%86%E7%9A%84socket%E5%B0%81%E8%A3%85/

http://www.xiangwangfeng.com/2011/05/09/%E6%9E%84%E9%80%A0httpclient%E4%B8%89%E9%83%A8%E6%9B%B2%E4%B9%8B%E4%BA%8C%EF%BC%9Aget%E6%96%B9%E6%B3%95%E5%AE%9E%E7%8E%B0/

http://www.xiangwangfeng.com/2011/05/15/%E6%9E%84%E9%80%A0httpclient%E4%B8%89%E9%83%A8%E6%9B%B2%E7%BB%88%E7%AF%87%EF%BC%9Apost%E6%96%B9%E6%B3%95%E5%AE%9E%E7%8E%B0/

目前还没有任何评论.