背景
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。
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对象进行设置。
