http代理是如何爬取数据的?

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协议。 这就是为什么这种代理被称为隧道的原因。  (部分转载)