复杂的应用层代理

最新推荐文章于 2024-10-13 21:30:19 发布

铁锹少年@神州网信

最新推荐文章于 2024-10-13 21:30:19 发布

阅读量6.2k

点赞数 22

分类专栏： network 文章标签：网络协议 http Powered by 金山文档

本文链接：https://blog.csdn.net/tieqiaoshaonian/article/details/128772611

版权

network 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

复杂的应用层代理

应用层代理为什么复杂

协议组合带来的复杂度

服务端的需求带来的复杂度

用户需求场景带来的复杂度

其他因素

主流浏览器支持代理的做法

基本功能

差异化设置

思考

参考

复杂的应用层代理

在《"混乱"的 Windows 10 更新系统代理》中，作者主要介绍了 Windows 系统的"内置"代理和这些代理在更新系统中的应用，因为更新过程涉及两个代理的不同配置，给人以混乱的感觉。

全文对 Windows 系统中代理做了一下梳理和简单分析，用张老师的话说是"没有一针见血地抓住问题本质"：这里的混乱来源于复杂，但我没有讲清楚为什么复杂(^_^)。在张老师的启发下，我重新查阅资料并整理，在本文中仍以http代理为例，说明应用层代理实现的复杂度，并进一步分析Chrome和FireFox的代理设计和实现思路，看看它们是如何处理复杂的代理问题的。

应用层代理为什么复杂

除指明外，文中所使用"代理"均指"http代理"。

协议组合带来的复杂度

应用层是OSI模型中的最顶层，用于建立进程间通信和提供用户服务。它是用户应用和底层网络之间的接口。有非常多的应用层协议支撑着成千上万的网络应用。

这些协议所对应的应用层协议数据单元格式各不相同，如果要在应用层实现代理，就意味着为每种应用层协议单独实现代理过程。相当于在原有的通信协议上进行扩展，产生一个新的代理协议。

另外，即使是同一个协议的代理实现可能对应着不同的方式。以http为例，在http/1.0中仅能通过"普通代理 1 "的方式实现，这种代理扮演的是「中间人」角色，对于连接到它的客户端来说，它是服务端；对于要连接的服务端来说，它是客户端。另外一种是在http/1.1中引入"隧道代理 2 "的方式实现，在客户端和代理服务器建立连接之后，代理服务器将在客户端和真正的服务端之间进行盲转发。两种方式都支持http代理。

这种代理协议与通信协议的组合以及协议实现的不同方式，增加了应用层代理的复杂度。

服务端的需求带来的复杂度

代理的服务端需求发展

http 代理是伴随着web出现的，早期的 http 代理非常简单，它们位于外网和局域网之间，提供一层功能和安全性。它们能够使局域网中多台机器共享同一条网络连接访问外网；通过如网址过滤这种手段实现简单的流量管控，允许或禁止一些对外访问；对频繁访问的内容进行缓存，节省网络带宽并提高网络效率。

代理服务器在应用层实现共享网络访问，这就决定了每一个客户端程序都要单独配置来访问代理服务器。如果用户仅有个别网络访问需求，这还可以接受；但对于企业组织的管理员来说，为每一台机器上的多个客户端程序做代理配置就是个负担。NAT的出现，很大程度上简化了配置代理的过程。但使用这种方式，加大了暴露内网的可能性，进而增加了内网的风险。网络防火墙能够提供对数据流量从网络层协议到应用层内容的多层管控。将二者集成到一起，成为了一种典型应用 3 4 。

仅使用NAT结合防火墙的方案只是在某些方面解决了问题，比如内容缓存的功能仍需要代理的支持。后来又有了代理验证用户身份的需求，代理服务器提供不同的用户匿名性支持，甚至有些网站广告过滤也是通过代理实现。有些代理还要支持黑白名单，这就使得现在我们看到的产品形态，往往是代理、NAT、防火墙组合使用或者组合出现的产品。有时候单一的代理软件并不能够满足所有的代理需求，可能会对代理服务端软件作嵌套部署。

代理的服务端软件发展

另外，代理服务器软件简直太多，用户量比较大的包括Apache，HAProxy，IIS，Nginx，Squid，WinGate，Tinyproxy等等，它们都实现了基本的代理功能，区别在于是否支持功能扩展、模块定制以及部署的便捷性。

代理的功能增强，需求来自客户端，实现主要依赖服务端。

这么多的代理服务器软件，在实现代理协议的时候会存在部分差异，在客户端程序和这么多的代理服务器打交道的时候，只能做到适配主流代理中的几个。这对于应用程序的代理实现，又是个挑战。

用户需求场景带来的复杂度

大多数问题的复杂度都可以归结为用户需求带来的，但只说这么一句不免有些"耍流氓"的味道：用户到底有什么样的需求？

刚好找到一个chrome论坛上2009年的帖子，讨论的是当时chrome在 Windows 下只提供一个配置代理选项：仅支持配置IE代理作为chrome代理注。从这些跟帖中可以一窥用户的真实需求：

sc1: 公司限制内部使用IE通过代理访问Sharepoint。希望使用Chrome访问更多的其他网络服务，但当时的版本无法满足需求；

sc2: 因为防火墙的限制规则，需要使用不同的代理来连接不同的url；

sc3: FoxyProxy可以为每一个添加的代理配置规则，这使得代理选择变为动态，需要为不同的任务使用5个独立的proxy。

sc4: IE代理用于特定的办公 VPN 连接，其他浏览器如chrome应该能够使用特定设置；

sc5: 为满足不同通配符的主机名使用多个不同的代理；

....

甚至有的用户希望打开两个浏览器窗口，在不同的窗口中使用不同的代理!

了解过后，才知道用户的真实需求超乎想象。

其他因素

网络发展环境越来越复杂，可能使内置代理功能覆盖不全，比如之前在《哎，这是个 Windows 的bug》中提到的http跳转，就是代理需要考虑的实现细节。

有了上面这些内容，就能够体会 Windows 内置代理的不易之处和尴尬境地了。本来 Windows 提供的代理设置接口是为了简化代理的开发和使用，但由于应用层代理问题的复杂，这种代理方式不能够满足所有的使用要求：

设置一次对系统中所有使用IE代理的应用都生效，这意味着这些应用只能使用一个代理。这在代理发展的某个阶段可能是个优点，但随着各种各样的应用出现，可能会造成应用间冲突或者代理滥用。

现在回过头来看，也可以这样猜测：Windows 中最初的代理实现是依赖于WinINet库提供，后来它的使用出现一定的局限性，所以有了新的WinHttp库满足一些新的场景需求：在开发系统服务的时候，避免提供用户交互并且以特殊账户运行。

主流浏览器支持代理的做法

面对这么多的挑战，主流浏览器是如何支持代理的呢？

基本功能

以当前的firefox(v106.0.5)和chrome(v108.0.5359.99)为例,二者支持的功能包括以下几种：

自动检测当前网络代理设置，允许计算机查询本地网络以确定提供PAC文件的服务器。一般需要通过配置dhcp或者dns实现；

使用系统中设置的代理，Windows 系统下就是IE代理；

手动代理设置；

指定代理自动配置(PAC)文件url方式。

从功能上讲，很多系统和主流浏览器支持代理的方式都包括这几种，但大家具体的实现方式和为用户提供的配置方式各不相同。自动检测代理和PAC文件的方式在早期被爆出有安全漏洞，各个操作系统和应用程序的不同处理方式提供不同的安全保证，在chrome中，评估来自PAC文件的JavaScript代码发生在一个沙箱内。

差异化设置

firefox和chrome提供的功能基本相同，区别在于这两者是如何为用户提供配置接口来支持这些功能，而这又决定了二者能够覆盖的用户场景。

firefox的基本设置界面包含所有的设置选项：

而chrome在设置界面上仅支持一个设置选项，它会打开 Windows 的网络设置控制面板，默认使用系统提供的代理，如果想要单独设置代理，只能通过指定命令行参数和安装扩展的方式实现。

chrome对代理的支持经历了很大的变化：chrome代理最初的界面仅有设置IE代理的选项，除了能够在启动时接收简单的命令行参数外，再无其他代理支持功能。在被diss了两年 5 之后，很多用户以不再使用chrome做威胁，chrome终于在功能上增强了对代理的支持，只是需要通过安装扩展工具来实现，原来的界面仍只是保留了一个设置IE代理的选项。