IP模拟器

http代理如何抓取数据？  Web代理是存在于网络中间并提供各种功能的实体。 在现代网络系统中，Web 代理无处不在。 在我之前关于 HTTP 的博文中，我多次提到代理对 HTTP 请求和响应的影响。 在今天的文章中，我打算谈谈HTTP代理本身的一些原理以及如何用Node.js快速实现代理。  

 

HTTP代理有两种形式，简单介绍如下： 

第一种是RFC 7230-HTTP/1.1： 消息语法和路由（即修订后的 RFC 2616，HTTP/1.1 协议的第一部分）描述了普通代理。 这种代理扮演着“中间人”的角色。 对于连接到它的客户端来说，它是服务器； 对于要连接的服务器，它是客户端。 它负责在两端之间来回发送 HTTP 消息。  

 

第二个是通过 Web 代理服务器通过基于 TCP 的隧道协议描述的隧道代理。 它通过HTTP协议体完成通信，以HTTP的方式实现任何基于TCP的应用层协议代理。 此代理使用 HTTP CONNECT 方法建立连接，但 CONNECT 最初不是 RFC 2616-HTTP/1.1 的一部分。 直到 2014 年发布的 HTTP/1.1 修订版才添加了 CONNECT 和隧道代理的描述。 请参阅 RFC 7231-HTTP/1.1：语义和内容。 事实上，这种机构早已广泛实施。  

 

第一种Web代理原理很简单：

HTTP客户端向代理发送请求消息，代理服务器需要正确处理请求和连接（例如正确处理Connection:keep-alive），同时向服务器发送请求，将接收到的响应转发给客户端。  

 

下图来自《HTTP权威指南》，直观演示了上述行为： 

 

访问A的网站，对于A来说，它把代理当成一个客户端，完全不知道真实客户端的存在。 这样就达到了隐藏客户端IP的目的。 当然，代理也可以修改HTTP请求头，通过自定义的头，比如X-Forwarded-IP，告诉服务器真实的客户端IP。 但是，服务器无法验证这个自定义头是否真的是代理添加的，还是客户端修改了请求头，因此从HTTP头字段中获取IP时需要格外小心。 这部分内容可以参考我之前的文章《X-Forwarded-For in HTTP Request Header》。  

 

为浏览器显式指定代理，需要手动修改浏览器或操作系统相关设置，或者指定PAC的自动设置（Proxy Auto-Configuration，自动配置 proxy) 文件，并且某些浏览器支持 WPAD（Web 代理自动发现协议）。 显式指定浏览器代理的方法一般称为正向代理。 浏览器启用转发代理后，会对HTTP请求报文做一些修改，避免旧代理服务器的一些问题。 这部分内容可以参考。 我之前的文章“Http 请求头中的代理连接”。  

 

另一种情况是，当你访问A网站时，你实际上访问了代理。 代理收到请求消息后，向实际提供服务的服务器发起请求，并响应转发给浏览器。 这种情况一般称为反向代理，可以用来隐藏服务器IP和端口。 一般使用反向代理后，需要修改DNS，将域名解析为代理服务器IP。 此时浏览器无法检测到真实服务器的存在。无需修改配置。 反向代理是 Web 系统最常见的部署方式。 比如本篇博客使用Nginx的proxy_pass函数将浏览器请求转发给它背后的Node.js服务。  

 

隧道代理 

 

第二个Web代理的原理也是 很简单：

 

HTTP客户端通过CONNECT方法请求隧道代理建立到任意目的服务器和端口的TCP连接，在客户端和服务器之间盲目转发后续数据。  

 

下图同样来自《HTTP权威指南》，直观地展示了上述行为： 

 

如果我通过代理访问A网站，浏览器首先通过CONNECT请求请求代理建立到A网站的TCP连接； 一旦TCP连接建立，代理就可以不假思索地转发后续流量。 所以这种代理理论上适用于任何基于TCP的应用层协议。 当然也可以使用HTTPS网站使用的TLS协议。 这就是为什么这种代理被称为隧道的原因。  （部分转载）