WinInet 和 WinHttp 有何区别?

背景

 WinInet和WinHttp是windows平台下提供了两套独立的网络库,按照微软官方的说法, WinInet的优势在于client-端的应用,而WinHttp更适用于server-端编程。从名称上我们可以看出WinHttp在Http协议应用方面要比WinInet更加专业,WinInet支持的协议包括Gopher\HTTP\HTTPS\FTP较为杂乱,而WinHttp库专门是为HTTP\HTTPS服务的。WinInet支持如此多协议的原因在于其自身是IE浏览器的网络层,所以它必须提供全方位的服务,包括各种协议的封装以及Cache机制。同时WinInet API的行为也被IE的设置所影响,具体表现为:用户通过“IE菜单->工具->连接->添加”可以为WinInet API指定专用的网络连接, autodialing服务没有从WinInet模块中分离出来;用户通过“IE菜单->工具->连接->局域网设置”可以为特定协议请求设置代理服务器,这一设置会影响到WinInetAPI 的行为;如果代理服务器需要用户/密码验证,则直接读取IE默认代理配置会使WinInet API访问失败,IE代理设置中不保存验证信息;WinInet API提供了持久化Cookie的机制,连接请求发起前必须手动清空Cookie,否则它们会在后续的请求中出现;WinInet的Cookie设置是针对特定URL而不是某次特定的请求,这种方式适用于IE浏览器应用,但对于我们目前的产品需求而言,降低了安全性。WinHttp程序库不存上述问题,它是专门为Http应用量身定制的网络库。

 在平台要求方面,WinInet程序库要求客户运行在windows 2000 以及后续版本,而WinHttp程序库要求客户运行在Windows XP,Windows 2000 sp3以及后续版本,对于大多数Windows平台上的Http应用,官方推荐使用WinHttp,并给出了将现有WinInet API应用向WinHttp API转换的解决方案。

编程模型

 利用WinInet或WinHttp进行Http协议编程时,有三种对象非常重要,即Session, Connection以及Request。使用者创建一个Session通知WinInet或WinHttp模块初始化内部的数据结构,每个Session有自己的一些属性,如代理服务器的设置;发送Http请求时标识自己名称的User-Agent Http头部;标识Session是否支持异步请求的标记字段等等。在一个Session之上可以存在多个Connection对象,每个Connection对应于一个目标服务器和端口号。在一个Connection之上可以存在多个Request对象,每个Request对应于Connection之上的URI资源地址以及HTTP动作(GET或POST等)。当使用者得到一个合法Request对象的句柄后,就可以与对应的服务器进行Http交互了。下图分别描述了WinInet和WinHttp实现的Http协议栈的主要操作函数。


   网络交互是一个耗时的操作,针对这一特点,WinInet和WinHttp作为Htpp协议的Windows网络实现库,提供了两种编程模型:即同步编程模型和异步编程模型。同步编程模型可以理解为在调用API的线程中启动网络请求并进入到阻塞状态,当网络请求返回或者内部发生错误时,阻塞被解除,程序继续顺序执行。而在异步编程模型中,当调用API的线程发出请求时,在WinInet或WinHttp模块内部会启动一个工作线程来完成耗时的网络操作,请求的结果通过回调报告给调用者线程所注册的函数,但是回调函数的执行环境还是在工作线程中,所以需要对临界区做互斥保护。异步编程模型比同步编程模型更灵活,工作线程的管理工作也在模块内部被透明的完成,譬如同时启动大量的请求,WinInet和WinHttp都会将请求排队,而不是立即启动数量相同的工作线程,破坏系统的整体稳定性。虽然WinInet和WinHttp都提供了异步编程模型,但两者在易用性上却有很大的区别,WinHttp API使用起来更加的统一和一致,而WinInet由于利用Session/Connection/Request的框架支持多种协议,虽然提供了丰富的功能,但却损失了易用性。譬如WinInet中创建Connection对象的API中有username和password的参数,对于Http Connection显然是多余的或者语义不清晰,但又是必要的,因为WinInet中利用同样的函数创建Ftp Connection,毕竟WinInet太古老了,作为IE的网络层,在那个年代,此种设计也许是可以被接受的。

代理支持

 WinInet和WinHttp都支持代理服务器的设置,但正如前文提到的WinInet API的代理设置会受到本地IE浏览器设置的影响,而WinHttp编程操作性更强、外部依赖性更小。WinInet提供了自动拨号的功能,如果IE设置了特定了网络连接,当调用WinInet API进行网络请求时,若指定的网络连接不可用,就会启动自动拨号程序,即使有本地有可用的网络连接,WinInet也不会使用;但对于WinHttp来说就不会存在这种情况,它可以智能的选择本地可用的网络连接,而不被外部设置所影响。WinInet支持自动代理检测以及代理检测脚本,对应于IE配置对话框中的“自动配置”面板,同时提供了相关的API接口。WinHttp API中也提供了对自动代理的支持。

在WinInet API中可以对四种协议设置代理服务器,它们分别为HTTP/HTTPS/FTP/SOCKS4,而在WinHttp API中仅能对HTTP/HTTPS设置代理服务器。不过,对于仅仅使用HTTP协议的应用来说,这不是WinHttp的劣势,因为其本身仅仅支持HTTP/HTTPS。下图为IE的代理设置对话框。

       在代理设置的粒度方面,WinInet代理需要设置在Session级别,而WinHttp的代理可以设置在Request级别,从而增加了灵活性。

WinInet 和 WinHttp都提供了工具,可以将代理配置保存在注册表中,只需在创建Session时指定相关的标识,就可以使用全局代理。但当IE配置了某些连接或代理项目后,WinInet API的行为就有些诡异或莫名其妙的连接不上,所以才有了本篇总结报告,结论是推荐使用WinHttp来代替WinInet。


HTTP Headers以及Cookie的支持

WinInet 和 WinHttp都提供HTTPHeader的设置接口,操作对象是Request句柄,也就是说,针对每次Http请求,编程人员可以根据需求设置附加的Http头。Cookie在Http协议中也是以HTTPHeader的形式存在的。在浏览器中,Cookie相关的Http头对象被进行了特殊的处理,通过分析Cookie的有效期(Http请求的返回包通过Set-Cookie来对Cookie以及有效期进行设置),对其进行持久化操作或存储在内存中。当再次和服务器进行交互时,同一url域下的有效Cookie会以Http头的形式发送给服务器。WinInet作为IE浏览器的网络层继承了浏览器对Cookie的处理方式,并且支持Cookie的持久化。利用InternetSetCookie对特定的Url域设置Cookie,一旦设置成功,后续对此Url的Http访问都会携带被设置的Cookie,除非用户手动清除。在WinHttp中并没有提供对Cookie设置的相关接口,如果服务器对Http请求方的Cookie数据有需求,那么编程人员需要利用设置Http 头的编程接口,对于特定的Reqeust对象进行设置。

你可能感兴趣的:(WinInet 和 WinHttp 有何区别?)