精华内容
下载资源
问答
  • HTTP 代理原理及实现

    万次阅读 2019-04-25 11:50:34
    Web 代理是一种存在于网络中间的...今天这篇文章,我打算谈谈 HTTP 代理本身的一些原理,以及如何用 Node.js 快速实现代理HTTP 代理存在两种形式,分别简单介绍如下: 第一种是RFC 7230 - HTTP/1.1: Message Sy...

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

    HTTP 代理存在两种形式,分别简单介绍如下:

    第一种是 RFC 7230 - HTTP/1.1: Message Syntax and Routing(即修订后的 RFC 2616,HTTP/1.1 协议的第一部分)描述的普通代理。这种代理扮演的是「中间人」角色,对于连接到它的客户端来说,它是服务端;对于要连接的服务端来说,它是客户端。它就负责在两端之间来回传送 HTTP 报文。

    第二种是 Tunneling TCP based protocols through Web proxy servers(通过 Web 代理服务器用隧道方式传输基于 TCP 的协议)描述的隧道代理。它通过 HTTP 协议正文部分(Body)完成通讯,以 HTTP 的方式实现任意基于 TCP 的应用层协议代理。这种代理使用 HTTP 的 CONNECT 方法建立连接,但 CONNECT 最开始并不是 RFC 2616 - HTTP/1.1 的一部分,直到 2014 年发布的 HTTP/1.1 修订版中,才增加了对 CONNECT 及隧道代理的描述,详见 RFC 7231 - HTTP/1.1: Semantics and Content。实际上这种代理早就被广泛实现。

    本文描述的第一种代理,对应《HTTP 权威指南》一书中第六章「代理」;第二种代理,对应第八章「集成点:网关、隧道及中继」中的 8.5 小节「隧道」。

    普通代理

    第一种 Web 代理原理特别简单:

    HTTP 客户端向代理发送请求报文,代理服务器需要正确地处理请求和连接(例如正确处理 Connection: keep-alive),同时向服务器发送请求,并将收到的响应转发给客户端。

    下面这张图片来自于《HTTP 权威指南》,直观地展示了上述行为:

    假如我通过代理访问 A 网站,对于 A 来说,它会把代理当做客户端,完全察觉不到真正客户端的存在,这实现了隐藏客户端 IP 的目的。当然代理也可以修改 HTTP 请求头部,通过 X-Forwarded-IP 这样的自定义头部告诉服务端真正的客户端 IP。但服务器无法验证这个自定义头部真的是由代理添加,还是客户端修改了请求头,所以从 HTTP 头部字段获取 IP 时,需要格外小心。这部分内容可以参考我之前的《HTTP 请求头中的 X-Forwarded-For》这篇文章。

    给浏览器显式的指定代理,需要手动修改浏览器或操作系统相关设置,或者指定 PAC(Proxy Auto-Configuration,自动配置代理)文件自动设置,还有些浏览器支持 WPAD(Web Proxy Autodiscovery Protocol,Web 代理自动发现协议)。显式指定浏览器代理这种方式一般称之为正向代理,浏览器启用正向代理后,会对 HTTP 请求报文做一些修改,来规避老旧代理服务器的一些问题,这部分内容可以参考我之前的《Http 请求头中的 Proxy-Connection》这篇文章。

    还有一种情况是访问 A 网站时,实际上访问的是代理,代理收到请求报文后,再向真正提供服务的服务器发起请求,并将响应转发给浏览器。这种情况一般被称之为反向代理,它可以用来隐藏服务器 IP 及端口。一般使用反向代理后,需要通过修改 DNS 让域名解析到代理服务器 IP,这时浏览器无法察觉到真正服务器的存在,当然也就不需要修改配置了。反向代理是 Web 系统最为常见的一种部署方式,例如本博客就是使用 Nginx 的 proxy_pass 功能将浏览器请求转发到背后的 Node.js 服务。

    了解完第一种代理的基本原理后,我们用 Node.js 实现一下它。只包含核心逻辑的代码如下:

    var http = require('http');
    var net = require('net');
    var url = require('url');
    
    function request(cReq, cRes) {
        var u = url.parse(cReq.url);
    
        var options = {
            hostname : u.hostname, 
            port     : u.port || 80,
            path     : u.path,       
            method     : cReq.method,
            headers     : cReq.headers
        };
    
        var pReq = http.request(options, function(pRes) {
            cRes.writeHead(pRes.statusCode, pRes.headers);
            pRes.pipe(cRes);
        }).on('error', function(e) {
            cRes.end();
        });
    
        cReq.pipe(pReq);
    }
    
    http.createServer().on('request', request).listen(8888, '0.0.0.0');

    以上代码运行后,会在本地 8888 端口开启 HTTP 代理服务,这个服务从请求报文中解析出请求 URL 和其他必要参数,新建到服务端的请求,并把代理收到的请求转发给新建的请求,最后再把服务端响应返回给浏览器。修改浏览器的 HTTP 代理为 127.0.0.1:8888 后再访问 HTTP 网站,代理可以正常工作。

    但是,使用我们这个代理服务后,HTTPS 网站完全无法访问,这是为什么呢?答案很简单,这个代理提供的是 HTTP 服务,根本没办法承载 HTTPS 服务。那么是否把这个代理改为 HTTPS 就可以了呢?显然也不可以,因为这种代理的本质是中间人,而 HTTPS 网站的证书认证机制是中间人劫持的克星。普通的 HTTPS 服务中,服务端不验证客户端的证书,中间人可以作为客户端与服务端成功完成 TLS 握手;但是中间人没有证书私钥,无论如何也无法伪造成服务端跟客户端建立 TLS 连接。当然如果你拥有证书私钥,代理证书对应的 HTTPS 网站当然就没问题了。

    HTTP 抓包神器 Fiddler 的工作原理也是在本地开启 HTTP 代理服务,通过让浏览器流量走这个代理,从而实现显示和修改 HTTP 包的功能。如果要让 Fiddler 解密 HTTPS 包的内容,需要先将它自带的根证书导入到系统受信任的根证书列表中。一旦完成这一步,浏览器就会信任 Fiddler 后续的「伪造证书」,从而在浏览器和 Fiddler、Fiddler 和服务端之间都能成功建立 TLS 连接。而对于 Fiddler 这个节点来说,两端的 TLS 流量都是可以解密的。

    如果我们不导入根证书,Fiddler 的 HTTP 代理还能代理 HTTPS 流量么?实践证明,不导入根证书,Fiddler 只是无法解密 HTTPS 流量,HTTPS 网站还是可以正常访问。这是如何做到的,这些 HTTPS 流量是否安全呢?这些问题将在下一节揭晓。

    隧道代理

    第二种 Web 代理的原理也很简单:

    HTTP 客户端通过 CONNECT 方法请求隧道代理创建一条到达任意目的服务器和端口的 TCP 连接,并对客户端和服务器之间的后继数据进行盲转发。

    下面这张图片同样来自于《HTTP 权威指南》,直观地展示了上述行为:

    假如我通过代理访问 A 网站,浏览器首先通过 CONNECT 请求,让代理创建一条到 A 网站的 TCP 连接;一旦 TCP 连接建好,代理无脑转发后续流量即可。所以这种代理,理论上适用于任意基于 TCP 的应用层协议,HTTPS 网站使用的 TLS 协议当然也可以。这也是这种代理为什么被称为隧道的原因。对于 HTTPS 来说,客户端透过代理直接跟服务端进行 TLS 握手协商密钥,所以依然是安全的,下图中的抓包信息显示了这种场景:

    CONNECT imququ.com:443 HTTP/1.1

    对于 CONNECT 请求来说,只是用来让代理创建 TCP 连接,所以只需要提供服务器域名及端口即可,并不需要具体的资源路径。代理收到这样的请求后,需要与服务端建立 TCP 连接,并响应给浏览器这样一个 HTTP 报文:

    HTTP/1.1 200 Connection Established

    浏览器收到了这个响应报文,就可以认为到服务端的 TCP 连接已经打通,后续直接往这个 TCP 连接写协议数据即可。通过 Wireshark 的 Follow TCP Steam 功能,可以清楚地看到浏览器和代理之间的数据传递:

    可以看到,浏览器建立到服务端 TCP 连接产生的 HTTP 往返,完全是明文,这也是为什么 CONNECT 请求只需要提供域名和端口:如果发送了完整 URL、Cookie 等信息,会被中间人一览无余,降低了 HTTPS 的安全性。HTTP 代理承载的 HTTPS 流量,应用数据要等到 TLS 握手成功之后通过 Application Data 协议传输,中间节点无法得知用于流量加密的 master-secret,无法解密数据。而 CONNECT 暴露的域名和端口,对于普通的 HTTPS 请求来说,中间人一样可以拿到(IP 和端口很容易拿到,请求的域名可以通过 DNS Query 或者 TLS Client Hello 中的 Server Name Indication 拿到),所以这种方式并没有增加不安全性。

    了解完原理后,再用 Node.js 实现一个支持 CONNECT 的代理也很简单。核心代码如下:

    var http = require('http');
    var net = require('net');
    var url = require('url');
    
    function connect(cReq, cSock) {
        var u = url.parse('http://' + cReq.url);
    
        var pSock = net.connect(u.port, u.hostname, function() {
            cSock.write('HTTP/1.1 200 Connection Established\r\n\r\n');
            pSock.pipe(cSock);
        }).on('error', function(e) {
            cSock.end();
        });
    
        cSock.pipe(pSock);
    }
    
    http.createServer().on('connect', connect).listen(8888, '0.0.0.0');

    以上代码运行后,会在本地 8888 端口开启 HTTP 代理服务,这个服务从 CONNECT 请求报文中解析出域名和端口,创建到服务端的 TCP 连接,并和 CONNECT 请求中的 TCP 连接串起来,最后再响应一个 Connection Established 响应。修改浏览器的 HTTP 代理为 127.0.0.1:8888 后再访问 HTTPS 网站,代理可以正常工作。

    最后,将两种代理的实现代码合二为一,就可以得到全功能的 Proxy 程序了,全部代码在 50 行以内(当然异常什么的基本没考虑,这是我博客代码的一贯风格):

    var http = require('http');
    var net = require('net');
    var url = require('url');
    
    function request(cReq, cRes) {
        var u = url.parse(cReq.url);
    
        var options = {
            hostname : u.hostname, 
            port     : u.port || 80,
            path     : u.path,       
            method     : cReq.method,
            headers     : cReq.headers
        };
    
        var pReq = http.request(options, function(pRes) {
            cRes.writeHead(pRes.statusCode, pRes.headers);
            pRes.pipe(cRes);
        }).on('error', function(e) {
            cRes.end();
        });
    
        cReq.pipe(pReq);
    }
    
    function connect(cReq, cSock) {
        var u = url.parse('http://' + cReq.url);
    
        var pSock = net.connect(u.port, u.hostname, function() {
            cSock.write('HTTP/1.1 200 Connection Established\r\n\r\n');
            pSock.pipe(cSock);
        }).on('error', function(e) {
            cSock.end();
        });
    
        cSock.pipe(pSock);
    }
    
    http.createServer()
        .on('request', request)
        .on('connect', connect)
        .listen(8888, '0.0.0.0');

    需要注意的是,大部分浏览器显式配置了代理之后,只会让 HTTPS 网站走隧道代理,这是因为建立隧道需要耗费一次往返,能不用就尽量不用。但这并不代表 HTTP 请求不能走隧道代理,我们用 Node.js 写段程序验证下(先运行前面的代理服务):

    var http = require('http');
    
    var options = {
        hostname : '127.0.0.1',
        port     : 8888,
        path     : 'imququ.com:80',
        method     : 'CONNECT'
    };
    
    var req = http.request(options);
    
    req.on('connect', function(res, socket) {
        socket.write('GET / HTTP/1.1\r\n' +
                     'Host: imququ.com\r\n' +
                     'Connection: Close\r\n' +
                     '\r\n');
    
        socket.on('data', function(chunk) {
            console.log(chunk.toString());
        });
    
        socket.on('end', function() {
            console.log('socket end.');
        });
    });
    
    req.end();

    这段代码运行完,结果如下:

    HTTP/1.1 301 Moved Permanently
    Server: nginx
    Date: Thu, 19 Nov 2015 15:57:47 GMT
    Content-Type: text/html
    Content-Length: 178
    Connection: close
    Location: https://imququ.com/
    
    <html>
    <head><title>301 Moved Permanently</title></head>
    <body bgcolor="white">
    <center><h1>301 Moved Permanently</h1></center>
    <hr><center>nginx</center>
    </body>
    </html>
    
    socket end.

    可以看到,通过 CONNECT 让代理打开到目标服务器的 TCP 连接,用来承载 HTTP 流量也是完全没问题的。

    最后,HTTP 的认证机制可以跟代理配合使用,使得必须输入正确的用户名和密码才能使用代理,这部分内容比较简单,这里略过。

     

    我们知道 TLS 有三大功能:内容加密、身份认证和数据完整性。其中内容加密依赖于密钥协商机制;数据完整性依赖于 MAC(Message authentication code)校验机制;而身份认证则依赖于证书认证机制。一般操作系统或浏览器会维护一个受信任根证书列表,包含在列表之中的证书,或者由列表中的证书签发的证书都会被客户端信任。

    提供 HTTPS 服务的证书可以自己生成,然后手动加入到系统根证书列表中。但是对外提供服务的 HTTPS 网站,不可能要求每个用户都手动导入你的证书,所以更常见的做法是向 CA(Certificate Authority,证书颁发机构)申请。根据证书的不同级别,CA 会进行不同级别的验证,验证通过后 CA 会用他们的证书签发网站证书,这个过程通常是收费的(有免费的证书,最近免费的 Let's Encrypt 也很火,这里不多介绍)。由于 CA 使用的证书都是由广泛内置在各系统中的根证书签发,所以从 CA 获得的网站证书会被绝大部分客户端信任。

    通过 CA 申请证书很简单,本文为了方便演示,采用自己签发证书的偷懒办法。现在广泛使用的证书是 x509.v3 格式,使用以下命令可以创建:

    openssl genrsa -out private.pem 2048
    openssl req -new -x509 -key private.pem -out public.crt -days 99999

    第二行命令运行后,需要填写一些证书信息。需要注意的是 Common Name 一定要填写后续提供 HTTPS 服务的域名或 IP。例如你打算在本地测试,Common Name 可以填写 127.0.0.1。证书创建好之后,再将 public.crt 添加到系统受信任根证书列表中。为了确保添加成功,可以用浏览器验证一下:

    接着,可以改造之前的 Node.js 代码了,需要改动的地方不多:

    var http = require('http');
    var https = require('https');
    var fs = require('fs');
    var net = require('net');
    var url = require('url');
    
    function request(cReq, cRes) {
        var u = url.parse(cReq.url);
    
        var options = {
            hostname : u.hostname, 
            port     : u.port || 80,
            path     : u.path,       
            method     : cReq.method,
            headers     : cReq.headers
        };
    
        var pReq = http.request(options, function(pRes) {
            cRes.writeHead(pRes.statusCode, pRes.headers);
            pRes.pipe(cRes);
        }).on('error', function(e) {
            cRes.end();
        });
    
        cReq.pipe(pReq);
    }
    
    function connect(cReq, cSock) {
        var u = url.parse('http://' + cReq.url);
    
        var pSock = net.connect(u.port, u.hostname, function() {
            cSock.write('HTTP/1.1 200 Connection Established\r\n\r\n');
            pSock.pipe(cSock);
        }).on('error', function(e) {
            cSock.end();
        });
    
        cSock.pipe(pSock);
    }
    
    var options = {
        key: fs.readFileSync('./private.pem'),
        cert: fs.readFileSync('./public.crt')
    };
    
    https.createServer(options)
        .on('request', request)
        .on('connect', connect)
        .listen(8888, '0.0.0.0');

    可以看到,除了将 http.createServer 换成 https.createServer,增加证书相关配置之外,这段代码没有任何改变。这也是引入 TLS 层的妙处,应用层不需要任何改动,就能获得诸多安全特性。

    运行服务后,只需要将浏览器的代理设置为 HTTPS 127.0.0.1:8888 即可,功能照旧。这样改造,只是将浏览器到代理之间的流量升级为了 HTTPS,代理自身逻辑、与服务端的通讯方式,都没有任何变化。

    最后,还是写段 Node.js 代码验证下这个 HTTPS 代理服务:

    var https = require('https');
    
    var options = {
        hostname : '127.0.0.1',
        port     : 8888,
        path     : 'imququ.com:80',
        method     : 'CONNECT'
    };
    
    //禁用证书验证,不然自签名的证书无法建立 TLS 连接
    process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0";
    
    var req = https.request(options);
    
    req.on('connect', function(res, socket) {
        socket.write('GET / HTTP/1.1\r\n' +
                     'Host: imququ.com\r\n' +
                     'Connection: Close\r\n' +
                     '\r\n');
    
        socket.on('data', function(chunk) {
            console.log(chunk.toString());
        });
    
        socket.on('end', function() {
            console.log('socket end.');
        });
    });
    
    req.end();

    这段代码和前面文章最后那段的区别只是 http.request 换成了 https.request,运行结果完全一样,这里就不贴了。本文所有代码可以从这个仓库获得:proxy-demo

    转自:

    https://imququ.com/post/web-proxy.html

    https://imququ.com/post/web-proxy-2.html

    展开全文
  • http代理原理及实现

    2013-10-24 17:15:10
    实例http代理。有客户端和服务器端。Soket实现
  • HTTP代理原理探索

    千次阅读 2017-07-04 19:26:04
    如果没有 Web 代理HTTP 客户端就要直接与 HTTP 服务器进行对话。有了 Web 代理,客户端就可以与代理进行对话,然后由代理代表客户端与服务器进行交流。客户端仍然会完成对事务的处理,但它是通过代理服务器提供的...

    Web 上的代理服务器是代表客户端完成事务处理的中间人。如果没有 Web 代理, HTTP 客户端就要直接与 HTTP 服务器进行对话。有了 Web 代理,客户端就可以与代理进行对话,然后由代理代表客户端与服务器进行交流。客户端仍然会完成对事务的处理,但它是通过代理服务器提供的优质服务来实现的。

    HTTP 代理存在两种形式,分别简单介绍如下:
    - 第一种是 RFC 7230 - HTTP/1.1: Message Syntax and Routing(即修订后的 RFC 2616,HTTP/1.1 协议的第一部分)描述的普通代理。这种代理扮演的是「中间人」角色,对于连接到它的客户端来说,它是服务端;对于要连接的服务端来说,它是客户端。它就负责在两端之间来回传送 HTTP 报文。
    - 第二种是 Tunneling TCP based protocols through Web proxy servers(通过 Web 代理服务器用隧道方式传输基于 TCP 的协议)描述的隧道代理。它通过 HTTP 协议正文部分(Body)完成通讯,以 HTTP 的方式实现任意基于 TCP 的应用层协议代理。这种代理使用 HTTP 的 CONNECT 方法建立连接,但 CONNECT 最开始并不是 RFC 2616 - HTTP/1.1 的一部分,直到 2014 年发布的 HTTP/1.1 修订版中,才增加了对 CONNECT 及隧道代理的描述,详见 RFC 7231 - HTTP/1.1: Semantics and Content。实际上这种代理早就被广泛实现。

    普通代理

    HTTP 客户端向代理发送请求报文,代理服务器需要正确地处理请求和连接(例如正确处理 Connection: keep-alive),同时向服务器发送请求,并将收到的响应转发给客户端。

    image

    实验验证

    网络连接: Tencent-DevWiFi

    代理设置: dev-proxy.oa.com:8080

    访问站点: http://www.cnbeta.com/

    Wireshark抓包分析:

    image

    image

    隧道代理

    HTTP 客户端通过 CONNECT 方法请求隧道代理创建一条到达任意目的服务器和端口的 TCP 连接,并对客户端和服务器之间的后继数据进行盲转发。

    image

    实验验证 I

    网络连接: Tencent-DevWiFi

    代理设置: dev-proxy.oa.com:8080

    访问站点: https://www.baidu.com/

    Wireshark抓包分析:

    image

    image

    可以看到,浏览器与代理进行 TCP 握手之后,发起了 CONNECT 请求,报文起始行如下:

    CONNECT www.baidu.com:443 HTTP/1.1

    代理收到这样的请求后,需要与服务端建立 TCP 连接,并响应给浏览器这样一个 HTTP 报文:

    HTTP/1.1 200 Connection established

    浏览器收到了这个响应报文,就可以认为到服务端的 TCP 连接已经打通,后续直接往这个 TCP 连接写协议数据即可。

    实验验证 II

    [tcp_echo_server]

    网络连接:腾讯云主机(外网: 139.199.76.147 内网: 10.186.8.226)

    image

    [tcp_echo_client]

    网络连接: Tencent-DevWiFi

    代理设置: dev-proxy.oa.com:8080

    image

    Wireshark抓包分析:

    image

    image

    附源码如下:

    # tcp_echo_server.py
    
    import sys, socket
    
    host = sys.argv[1]
    port = int(sys.argv[2])
    
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.bind((host, port))
    sock.listen(1)
    
    while True:
        connection, client_address = sock.accept()
    
        try:
            print >>sys.stderr, 'connection from', client_address
    
            while True:
                data = connection.recv(16)
                print >>sys.stderr, 'received "%s"' % data
                if data:
                    print >>sys.stderr, 'sending data back to the client'
                    connection.sendall(data)
                else:
                    print >>sys.stderr, 'no more data from', client_address
                    break
    
        finally:
            connection.close()
    # tcp_echo_client.py
    
    import sys, socket, socks
    
    host = sys.argv[1]
    port = int(sys.argv[2])
    
    sock = socks.socksocket(socket.AF_INET, socket.SOCK_STREAM)
    sock.set_proxy(socks.HTTP, "dev-proxy.oa.com", 8080)
    
    sock.connect((host, port))
    
    try:
        message = 'This is the message.  It will be repeated.'
        print >>sys.stderr, 'sending "%s"' % message
        sock.sendall(message)
    
        amount_received = 0
        amount_expected = len(message)
    
        while amount_received < amount_expected:
            data = sock.recv(16)
            amount_received += len(data)
            print >>sys.stderr, 'received "%s"' % data
    
    finally:
        print >>sys.stderr, 'closing socket'
        sock.close()
    
    展开全文
  • Linux配置http代理原理

    千次阅读 2020-07-05 17:58:00
    全局代理 如果要全局用户使用应用于所有的Shell,就需要修改 /etc/profile 文件 代理服务开启 设置全局代理,需要编辑profile文件 vi /etc/profile 文末添加以下代理配置,参考代理是否需要用户名密码 #无用户名...

    我们可以在很多地方设置Proxy,生产环境中最常见的还是在应用中直接调用一些库来为应用设置Proxy,但在测试Proxy的时候,就需要用到系统全局的Proxy设置以及部分应用的Proxy

    常见的Proxy一般就两种,SocksHTTP,HTTP是一种七层代理,而Socks则是封装过后的四层代理

    顾名思义,HTTP只能代理HTTP协议的流量,Socks则只接受Socks封装过的流量,对于大部分Web应用,我们会部署HTTP代理,因为如果经过了Socks封装,前置在应用和代理服务器之间的防火墙就无法看到URL了(你可能会奇怪防火墙为什么不是在最外面,事实上这里的防火墙专用于URL过滤,放在代理服务器外侧也可以,但如此一来,防火墙将看不到真正的源主机的地址,而只能看到代理服务器的地址了)

    而对于无法通过HTTP代理的协议,比如SSH和SFTP,就需要用到Socks代理了

    使用Socks代理,和使用的Socks Server有一定的相关性,日常大家用的最多的Socks代理是**************************,不过我们在一些环境中不会使用这么麻烦的,Dante Socks就是一个比较好的选择

    Windows以及部分浏览器(例如Firefox)可以设置Socks代理,Linux全局下似乎无法设置,但是一些其他方法可以在不安装Socks客户端的情况下使用Socks代理

    全局代理

    在/etc/profile下增加下列配置即可设置HTTP/HTTPS/FTP代理

    如果要全局用户使用应用于所有的Shell,就需要修改 /etc/profile 文件

    代理服务开启

    设置全局代理,需要编辑profile文件

    vi /etc/profile
    

    文末添加以下代理配置,参考代理是否需要用户名密码

    #无用户名密码
    export http_proxy=http://proxy_ip:prot
    export https_proxy=https://proxy_ip:prot
     
    #有用户名密码
    export http_proxy=http://username:password@proxy_ip:prot
    export https_proxy=https://username:password@proxy_ip:port
    export ftp_proxy=http://username:password@proxyserver:port
    

    export http_proxy=http://192.168.64.1:1080
    export https_proxy=http://192.168.64.1:1080
    
    # 或者建议这样配置
    http_proxy=proxy.abc.com:8080  
    https_proxy=$http_proxy  
    ftp_proxy=user:password@proxy.abc.com:8080  
    no_proxy=*.abc.com,10.*.*.*,192.168.*.*,*.local,localhost,127.0.0.1  
    export http_proxy https_proxy ftp_proxy no_proxy  
    

    其中:

    • http_proxy:http协议使用代理服务器地址;
    • https_proxy:https协议使用安全代理地址;
    • ftp_proxy:ftp协议使用代理服务器地址;
    • user:代理使用的用户名;
    • password:代理使用用户名的密码;
    • proxy.abc.com:代理地址,可以是IP,也可以是域名;
    • 8080:使用的端口;
    • no_proxy:不使用代理的主机或IP。

    备注:

    环境变量描述值示例
    http_proxy为http变量设置代理;默认不填开头以http协议传输10.0.0.51:8080
    user:pass@10.0.0.10:8080
    socks4://10.0.0.51:1080
    socks5://192.168.1.1:1080
    https_proxy为https变量设置代理;同上
    ftp_proxy为ftp变量设置代理;同上
    all_proxy全部变量设置代理,设置了这个时候上面的不用设置同上
    no_proxy无需代理的主机或域名;
    可以使用通配符;
    多个时使用“,”号分隔;
    *.aiezu.com,10.*.*.*,
    192.168.*.*,*.local,localhost,127.0.0.1

    1、在/etc/profile文件
    2、在~/.bashrc
    3、在~/.zshrc
    4、在/etc/profile.d/文件夹下新建一个文件xxx.sh

    写入如下配置:

    export proxy="http://192.168.5.14:8118"
    export http_proxy=$proxy
    export https_proxy=$proxy
    export ftp_proxy=$proxy
    export no_proxy="localhost, 127.0.0.1, ::1"
    

    而对于要取消设置可以使用如下命令,其实也就是取消环境变量的设置:

    unset http_proxy
    unset https_proxy
    unset ftp_proxy
    unset no_proxy
    

    此方法只适合配置http代理,使用socket代理上网的另有其他配置方法。

    生效配置文件

    source /etc/profile
    . /etc/profile
    

    查看当前已设置代理

    echo $http_proxy
    echo $https_proxy
    

    测试

    因为

    subversion的代理服务器配置

    要配置subversion的代理服务器,需要修改$HOME/.subversion/servers文件,在此文件的[global]段加上:

    http-proxy-host = 192.168.1.1
    http-proxy-port = 8080 
    http-proxy-username = easwy
    http-proxy-password = 123456 
    

    现在svn就可以使用代理服务器访问版本库了。

    yum的代理服务器配置

    针对yum配置走代理:
    经过测试其实只要设置上面的变量之后已经可以走代理了,但如果要单独设置,可以设置如下文件的变量:

    echo "proxy=http://127.0.0.1:8080/" >> /etc/yum.conf
    

    如果想让CentOS中的yum可以通过代理服务器更新程序,则需要修改文件/etc/yum.conf,在此文件中加上:

    proxy=http://easwy:123456@192.168.1.1:8080
    

    https://blog.csdn.net/weixin_34378969/article/details/94684696

    展开全文
  • HTTP代理服务器的工作原理

    千次阅读 2019-05-29 22:35:49
    ​ 在HTTP通信链上,客户端和目标服务器之间通常存在某些中转代理服务器,它们提供对目标资源的中转访问。一个HTTP请求可能被多个代理服务器转发,后面的服务器称为前面服务器的上游服务器。代理服务器按照其使用...

    ​ 在HTTP通信链上,客户端和目标服务器之间通常存在某些中转代理服务器,它们提供对目标资源的中转访问。一个HTTP请求可能被多个代理服务器转发,后面的服务器称为前面服务器的上游服务器。代理服务器按照其使用方式和作用,分为正向代理服务器,反向代理服务器和透明代理服务器

    正向代理要求客户端自己设置代理服务器的地址。客户的每次请求都将直接发送到该代理服务器,并由代理服务器来请求目标资源。比如处于防火墙内的局域网机器要访问Internet,或者要访问一些被屏蔽掉的国外网站,就需要使用正向代理服务器。

    ​ 反向代理则被设置在服务器端,因而客户端无需进行任何设置。反向代理是指用代理服务器来接收Internet上的连接请求,然后将请求转发给内部网络上的服务器,并将从内部服务器上得到的结果返回给客户端。这种情况下,代理服务器对外就表现为一个真实的服务器。各大网站通常分区域设置了多个代理服务器,所以在不同的地方ping同一个域名可能得到不同的IP地址,因为这些IP地址实际上是代理服务器的IP地址。
    在这里插入图片描述

    ​ 如图所示,正向代理服务器和客户端主机处于同一个逻辑网络中。该逻辑网络可以是一个本地LAN,也可以是一个更大的网络。反向代理服务器和真正的Web服务器也位于同一个逻辑网络中,这通常由提供网站的公司来配置和管理。

    ​ 透明代理只能设置在网关上。用户访问Internet的数据报必然都经过网关,如果在网关上设置代理,则该代理对用户来说显然是透明的。透明代理可以看作正向代理的一种特殊情况。

    ​ 代理服务器通常还提供缓存目标资源的功能,这样用户下次访问同一资源时速度将很快。优秀的开源软件squid,varnish都是提供了缓存能力的代理服务器软件,其中squid支持所有代理方式,而varnish仅能用作反向代理。

    展开全文
  • HTTP 代理原理与实现

    千次阅读 2019-04-16 14:07:48
    HTTP 代理原理与实现 HTTP 客户端向代理发送请求报文,代理服务器需要正确地处理请求和连接(例如正确处理 Connection: keep-alive),同时向服务器发送请求,并将收到的响应转发给客户端。 假如我通过代理访问 A ...
  • HTTP 代理原理及实现(一)

    万次阅读 2017-01-18 11:39:22
    Web 代理是一种存在于网络中间的...今天这篇文章,我打算谈谈 HTTP 代理本身的一些原理,以及如何用 Node.js 快速实现代理HTTP 代理存在两种形式,分别简单介绍如下: 第一种是 RFC 7230 - HTTP/1.1: Messag
  • HTTP代理原理以及HTTP隧道技术(经典)
  • 浅析HTTP代理原理

    千次阅读 2019-01-14 13:42:51
    关于HTTP代理的文章有很多,...本文主要介绍代理的事例,分析一个真实的案例来帮助理解HTTP代理原理HTTP代理原理 下面分析一个 http://iflow.uczzd.cn/iflow/api/v1/client_event?app=uc-iflow...经过...
  • HTTP代理服务器 - CONNECT SSL/TLS 原理

    千次阅读 2019-05-21 11:50:09
    HTTP代理服务器 - CONNECT SSL/TLS 原理 来自于《HTTP 权威指南》 其他资源 HTTP 隧道代理原理和实现 HTTP、HTTPS代理分析及原理 HTTP 代理原理及实现 http proxy原理 ...
  • 代理服务器的工作原理

    千次阅读 2019-04-17 17:44:27
    大家的了解应该不是特别的透彻,最直接的了解也就是代理服务器可以代理正常的服务器去获取我们想要了解的信息,隐藏我们真实的IP地址,代理服务器还可以应用在数据采集,网络营销等工作上面,那么代理服务器的原理是...
  • HTTP代理原理以及HTTP隧道技术

    千次阅读 2017-02-16 10:46:20
    HTTP代理原理 通过HTTP协议与代理服务器建立连接,协议信令中包含要连接到的远程主机的IP和端口号,如果有需要身份验证的话还需要加上授权信息,服务器收到信令后首先进行身份验证,通过后便与远程主机建立连接,...
  • ![图片说明](https://img-ask.csdn.net/upload/201703/08/1488942633_359786.png) 例如我在火狐中设置代理网络 jmeter中就可以记录火狐的所有请求和响应信息了 这背后的原理谁能简单的说下
  • C#实现HTTP代理服务器技术

    热门讨论 2013-03-13 15:42:44
    采用c#实现的代理服务器技术,绝对的通俗易懂,而且可以作为很好的学习案例进行分析。特别是和http协议打交道比较多的c#.net程序员可千万别错过哦!只要能够学到东西,积分都是浮云
  • nginx反向代理原理讲解

    千次阅读 2019-04-02 23:51:32
    反向代理(Reverse Proxy)方式是指以代理服务器来接受Internet上的连接请求,然后将请求转发给内部网络上的服务器;并将从服务器上得到的结果返回给Internet上请求连接的客户端,此时代理服务器对外就表现为一个...
  • Java JDK 动态代理(AOP)使用及实现原理分析

    万次阅读 多人点赞 2019-05-08 21:28:06
    代理是一种常用的设计模式,其目的就是为其他对象提供一个代理以控制对某个对象的访问。代理类负责为委托类预处理消息,过滤消息并转发消息,以及进行消息被委托类执行后的后续处理。 代理模式UML图: 简单结构...
  • 网络代理的基本原理

    千次阅读 2018-12-10 18:55:41
    HTTP代理服务器 :主要用于访问网页,一般有内容过滤和缓存功能,端口一般为80、8080、3128等。 SSL/TLS代理 :主要用于访问加密网站,一般有SSL或TLS加密功能(最高支持128位加密强度),端口一般为443。 ...
  • 各种代理IP背后的原理

    千次阅读 2019-04-24 17:06:46
    讲解各种代理IP背后的原理:知道代理IP的人越来越多了,不管是单纯的换IP,还是进行大量的数据采集,或者是游走于灰色之中,都是离不开代理IP这个工具的,但是很少人会关注各种代理IP背后的原理,今天就听小编来给...
  • HTTP代理穿透原理

    千次阅读 2015-04-27 17:00:07
    HTTP代理穿透原理  HTTP代理服务器中能够提供一种HTTP CONNECT代理服务,能够允许用户建立TCP连接到任何端口。通过CONNECT方法穿透代理的实现方法为:  CONNECT代理服务器的代理端口(如:8080);如果成功返回...
  • 【Spring基础】CGLIB动态代理实现原理

    万次阅读 多人点赞 2018-06-09 18:11:19
    * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is ...
  • 关于代理服务器的原理及用法

    千次阅读 2021-11-12 16:44:54
    关于代理服务器的原理及用法 一,什么是代理服务器(Proxy)? 答:以类似代理人的身份去取的用户需要的数据。由于它的【代理】能力,使得我们可以透过代理服务器来达成防火墙与用户数据的分析。除此之外我们还可以...
  • 详解动态代理及其实现原理

    千次阅读 2017-12-28 16:37:09
    1.什么是代理。比如(工厂,商店,客户),工厂是委托类,商店是代理类,工厂委托商店做代理来买产品,可以这样通俗理解。 2.代理的好处:(1.可以隐藏委托类的实现;2.可以实现客户与委托类间的解耦,在不修改委托...
  • 基于host的http代理--hproxy

    千次阅读 2019-08-29 22:35:51
    本文主要讲述,如何实现一个基于host方式的http代理,以及它与普通代理之间的区别。这种方式的代理主要可以应用于哪些实际的测试场景。 与普通代理的区别 所谓的普通代理,就是我们日常会用到的那种代理,通常需要...
  • nginx反向代理原理和配置讲解

    千次阅读 2018-08-09 21:12:34
     反向代理(Reverse Proxy)方式是指以代理服务器来接受Internet上的连接请求,然后将请求转发给内部网络上的服务器;并将从服务器上得到的结果返回给Internet上请求连接的客户端,此时代理服务器对外就表现为一个...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 188,358
精华内容 75,343
关键字:

原理http代理