golang 实现了 HTTP 代理和反向代理。
大家好,又见面了,我是你们的朋友全栈君。
代理的核心功能可以用一句话概括:接受客户端的请求,转发到后端服务器,获得应答之后返回给客户端。下图是 《HTTP 权威指南》一书中给出的图例,可以很清晰地说明这一流程:
代理的功能有很多,事实上整个互联网到处都充斥着代理服务器。如果所有的 HTTP 访问都是客户端和服务器端直接进行的话,我们的网络不仅会变得缓慢,而且性能会大打折扣。
代理服务器根据不同的配置和使用,可能会有不同的功能,这些功能主要包括:
- 内容过滤:代理可以根据一定的规则限制某些请求的连接。比如有些公司会设置内部网络无法访问某些购物、游戏网站,或者学校的网络不让学生访问色情暴力的网站等
- 节省成本:代理服务器可以作为缓存使用,对于某些资源只需要第一次访问的时候去下载,以后代理直接把缓存的结果返回给客户端,节约网络带宽的开销
- 提高性能:通过代理服务器的缓存(比如 CDN)和负载均衡(比如 nginx lb)功能,服务器端可以加速请求的访问,在更快的时间内返回结果)
- 增加安全性:公司可以在内网和外网之间通过代理进行转发,这样不仅对外隐藏了实现的细节,而且可以在代理层对爬虫、病毒性请求进行过滤,保护内部服务
所有的这些功能的实现都依赖于代理的特性,它可以在客户端和服务器端做一些事情,根据代理做的事情不同,它的角色和功能也就不同。那么,代理具体可以做哪些事情呢?比如:
- 修改 HTTP 请求:url、header、body
- 过滤请求:根据一定的规则丢弃、过滤请求
- 决定转发到哪个后端(可以是静态定义的,也可以是动态决定)
- 保存服务器的应答,后续的请求可以直接使用保存的应答
- 修改应答:对应答做一些格式的转换,修改数据,甚至返回完全不一样的应答数据
- 重试机制,如果后端服务器暂时无法响应,隔一段时间重试
- ……
正向代理和反向代理
代理可以分为正向代理和反向代理两种。
正向代理需要客户端来配置,一般来说我们会通过浏览器或者操作系统提供的工具或者界面来配置。这个时候,代理对客户端不是透明的,客户端需要知道代理的地址并且手动配置。配置了代理,浏览器在发送请求的时候会对报文做特殊的修改。
反向代理对客户端是透明的,也就是说客户端一般不知道代理的存在,认为自己是直接和服务器通信。我们大部分访问的网站就是反向代理服务器,反向代理服务器会转发到真正的服务器,一般在反向代理这一层实现负载均衡和高可用的功能。而且这里也可以看到,客户端是不会知道真正服务器端的 ip 地址和端口的,这在一定程度上起到了安全保护的作用。
代理服务器怎么知道目的服务器的地址?
在反向代理中,代理服务器要转发的服务器地址都是事先知道的(包括静态配置和动态配置)。比如 使用 nginx 来配置负载均衡 。
而对于正向代理来说,客户端可能访问的服务器地址是无法事先知道的。因为HTTP 协议活动在应用层,它无法获取网络层(IP层)信息,那么该协议要有一个地方可以拿到这个信息。HTTP 中可能保存这个信息的地方有两个:URL 和 header。默认情况下,HTTP 请求的 status line 有三部分组成:方法、uri 和协议版本,比如:
GET /index.html HTTP/1.0
User-Agent: gohttp 1.0
如果客户端(比如浏览器)知道自己在通过正向代理进行报文传输,那么它会在 status line 加上要访问服务器的真实地址。这个时候发送的报文是:
GET http://www.marys-antiques.com/index.html HTTP/1.0
User-Agent: gohttp 1.0
代理路径
客户端不管是通过代理服务器,还是直接访问后端服务器对于最终的结果是没有区别的,也就是说大多数情况下客户端根本不关心它访问的到底是什么,只需要(准确快速地)拿到想要的信息就够了。但是有时候,我们还是希望知道请求到底在中间经历了哪些代理,比如用来调试网络异常,或者做数据统计,而 HTTP 协议也提供了响应的功能。
虽然 RFC 2616 定义了 Via
头部字段来跟踪 HTTP 请求经过的代理路径,但在实际中用的更多的还是 X-Forwarded-For 字段, X-Forwarded-For
是 Squid
缓存代理服务软件引入的,目前已经在规范化在 RFC 7239 文档。
X-Forwarded-For
头部格式也比较简单,比如某个服务器接受到请求的对应头部可能是:
X-Forwarded-For: client, proxy1, proxy2
对应的值有多个字段,每个字段代表中间的一个节点,它们之间由逗号和空格隔开,从左到右距离当前节点越来越近。
每个代理服务器会在 X-Forwarded-For
头部填上前一个节点的 ip 地址,这个地址可以通过 TCP 请求的 remote address 获取。为什么每个代理服务器不填写自己的 ip 地址呢?有两个原因,如果由代理服务器填写自己的 ip 地址,那么代理可以很简单地伪造这个地址,而上一个节点的 remote address 是根据 TCP 连接获取的(如果不建立正确的 TCP 连接是无法进行 HTTP 通信的);另外一个原因是如果由当前节点填写 X-Forwarded-For
,那么很多情况客户端无法判断自己是否会通过代理的。
NOTE:
- 最终客户端或者服务器端接受的请求,
X-Forwarded-For
是没有最邻近节点的 ip 地址的,而这个地址可以通过 remote address 获取 - 每个节点(不管是客户端、代理服务器、真实服务器)都可以随便更改
X-Forwarded-For
的值,因此这个字段只能作为参考
代理服务器实现
这个部分我们会介绍如何用 golang 来实现 HTTP 代理服务器,需要读者了解一些 HTTP 服务器端编程的知识,可以参考我之前的文章:go http 服务器编程。
正向代理
按照我们之前介绍的代理原理,我们可以编写出这样的代码:
package main
import (
"fmt"
"io"
"net"
"net/http"
"strings"
)
type Pxy struct {}
func (p *Pxy) ServeHTTP(rw http.ResponseWriter, req *http.Request) {
fmt.Printf("Received request %s %s %s\n", req.Method, req.Host, req.RemoteAddr)
transport := http.DefaultTransport
// step 1
outReq := new(http.Request)
*outReq = *req // this only does shallow copies of maps
if clientIP, _, err := net.SplitHostPort(req.RemoteAddr); err == nil {
if prior, ok := outReq.Header["X-Forwarded-For"]; ok {
clientIP = strings.Join(prior, ", ") + ", " + clientIP
}
outReq.Header.Set("X-Forwarded-For", clientIP)
}
// step 2
res, err := transport.RoundTrip(outReq)
if err != nil {
rw.WriteHeader(http.StatusBadGateway)
return
}
// step 3
for key, value := range res.Header {
for _, v := range value {
rw.Header().Add(key, v)
}
}
rw.WriteHeader(res.StatusCode)
io.Copy(rw, res.Body)
res.Body.Close()
}
func main() {
fmt.Println("Serve on :8080")
http.Handle("/", &Pxy{})
http.ListenAndServe("0.0.0.0:8080", nil)
}
这段代码比较直观,只包含了最核心的代码逻辑,完全按照最上面的代理图例进行组织。一共分成几个步骤:
- 代理接收到客户端的请求,复制了原来的请求对象,并根据数据配置新请求的各种参数(添加上
X-Forward-For
头部等) - 把新请求发送到服务器端,并接收到服务器端返回的响应
- 代理服务器对响应做一些处理,然后返回给客户端
上面的代码运行之后,会在本地的 8080
端口启动代理服务。修改浏览器的代理为 127.0.0.1::8080
再访问网站,可以验证代理正常工作,也能看到它在终端打印出所有的请求信息。
虽然这段代码非常简短,但是你可以添加更多的逻辑实现非常有用的功能。比如在请求发送之前进行过滤,根据一定的规则直接阻止某些请求的访问;或者对请求进行限流,某个客户端在一定的时间里执行的请求有最大限额;统计请求的数据进行分析等等。
这个代理目前不支持 HTTPS 协议,因为它只提供了 HTTP 请求的转发功能,并没有处理证书和认证有关的内容。如果了解 HTTPS 协议的话,你会明白这种模式下是无法完成 HTTPS 握手的,虽然代理可以和真正的服务器建立连接(知道了对方的公钥和证书),但是代理无法代表服务器和客户端建立连接,因为代理服务器无法知道真正服务器的私钥。
反向代理
编写反向代理按照上面的思路当然没有问题,只需要在第二步的时候,根据之前的配置修改 outReq
的 URL Host 地址可以了。不过 Golang 已经给我们提供了编写代理的框架: httputil.ReverseProxy 。我们可以用非常简短的代码来实现自己的代理,而且内部的细节问题都已经被很好地处理了。
这部分我们会实现一个简单的反向代理,它能够对请求实现负载均衡,随机地把请求发送给某些配置好的后端服务器。使用 httputil.ReverseProxy
编写反向代理最重要的就是实现自己的 Director
对象,这是 GoDoc
对它的介绍:
Director must be a function which modifies the request into a new request to be sent using Transport. Its response is then copied back to the original client unmodified. Director must not access the provided Request after returning.
简单翻译的话, Director
是一个函数,它接受一个请求作为参数,然后对其进行修改。修改后的请求会实际发送给服务器端,因此我们编写自己的 Director
函数,每次把请求的 Scheme 和 Host 修改成某个后端服务器的地址,就能实现负载均衡的效果(其实上面的正向代理也可以通过相同的方法实现)。看代码:
package main
import (
"log"
"math/rand"
"net/http"
"net/http/httputil"
"net/url"
)
func NewMultipleHostsReverseProxy(targets []*url.URL) *httputil.ReverseProxy {
director := func(req *http.Request) {
target := targets[rand.Int()%len(targets)]
req.URL.Scheme = target.Scheme
req.URL.Host = target.Host
req.URL.Path = target.Path
}
return &httputil.ReverseProxy{Director: director}
}
func main() {
proxy := NewMultipleHostsReverseProxy([]*url.URL{
{
Scheme: "http",
Host: "localhost:9091",
},
{
Scheme: "http",
Host: "localhost:9092",
},
})
log.Fatal(http.ListenAndServe(":9090", proxy))
}
NOTE:这段代码来自 http://blog.charmes.net/2015/07/reverse-proxy-in-go.html。
我们让代理监听在 9090
端口,在后端启动两个返回不同响应的服务器分别监听在 9091
和 9092
端口,通过 curl
访问,可以看到多次请求会返回不同的结果。
➜ curl http://127.0.0.1:9090
116064a9eb83
➜ curl http://127.0.0.1:9090
8f7ccc11718f
同样的,这段代码也只是一个 demo,存在着很多问题,比如没有错误处理机制,如果后端某个服务器挂了,代理会返回 502 错误,更好的做法是把请求转发到另外的可用服务器。当然也可以添加更多的特性让它更好用,比如动态地添加后端服务器列表;根据后端服务器的负载情况进行负载转发等等。
上一篇: 获取机器的 mac 地址和 IP 地址
下一篇: 使用 Goland 破解永久版进行安装
推荐阅读
-
一种结构设计模式,允许在对象中动态添加新行为。它通过创建一个封装器来实现这一目的,即把对象放入一个装饰器类中,然后把这个装饰器类放入另一个装饰器类中,以此类推,形成一个封装器链。这样,我们就可以在不改变原始对象的情况下动态添加新行为或修改原始行为。 在 Java 中,实现装饰器设计模式的步骤如下: 定义一个接口或抽象类作为被装饰对象的基类。 公共接口 Component { void operation; } } 在本例中,我们定义了一个名为 Component 的接口,该接口包含一个名为 operation 的抽象方法,该方法定义了被装饰对象的基本行为。 定义一个实现基类方法的具体装饰对象。 公共类 ConcreteComponent 实现 Component { public class ConcreteComponent implements Component { @Override public void operation { System.out.println("ConcreteComponent is doing something...") ; } } 定义一个抽象装饰器类,该类继承于基类,并将装饰对象作为一个属性。 公共抽象类装饰器实现组件 { protected Component 组件 public Decorator(Component component) { this.component = component; } } @Override public void operation { component.operation; } } } 在这个示例中,我们定义了一个名为 Decorator 的抽象类,它继承了 Component 接口,并将被装饰对象作为一个属性。在操作方法中,我们调用了被装饰对象上的同名方法。 定义一个具体的装饰器类,继承自抽象装饰器类并实现增强逻辑。 公共类 ConcreteDecoratorA extends Decorator { public ConcreteDecoratorA(Component 组件) { super(component); } } public void operation { super.operation System.out.println("ConcreteDecoratorA 正在添加新行为......") ; } } 在本例中,我们定义了一个名为 ConcreteDecoratorA 的具体装饰器类,它继承自装饰器抽象类,并实现了操作方法的增强逻辑。在操作方法中,我们首先调用被装饰对象上的同名方法,然后添加新行为。 使用装饰器增强被装饰对象。 公共类 Main { public static void main(String args) { Component 组件 = new ConcreteComponent; component = new ConcreteDecoratorA(component); 组件操作 } } 在这个示例中,我们首先创建了一个被装饰对象 ConcreteComponent,然后通过 ConcreteDecoratorA 类创建了一个装饰器,并将被装饰对象作为参数传递。最后,调用装饰器的操作方法,实现对被装饰对象的增强。 使用场景 在 Java 中,装饰器模式被广泛使用,尤其是在 I/O 中。Java 中的 I/O 库使用装饰器模式实现了不同数据流之间的转换和增强。 让我们打开文件 a.txt,从中读取数据。InputStream 是一个抽象类,FileInputStream 是专门用于读取文件流的子类。BufferedInputStream 是一个支持缓存的数据读取类,可以提高数据读取的效率,具体代码如下: @Test public void testIO throws Exception { InputStream inputStream = new FileInputStream("C:/bbb/a.txt"); // 实现包装 inputStream = new BufferedInputStream(inputStream); byte bytes = new byte[1024]; int len; while((len = inputStream.read(bytes)) != -1){ System.out.println(new String(bytes, 0, len)); } } } } 其中 BufferedInputStream 对读取数据进行了增强。 这样看来,装饰器设计模式和代理模式似乎有点相似,接下来让我们讨论一下它们之间的区别。 第三,与代理模式的区别: 代理模式的目的是控制对对象的访问,它在对象外部提供一个代理对象来控制对原对象的访问。代理对象和原始对象通常实现相同的接口或继承相同的类,以确保两者可以相互替换。 装饰器模式的目的是动态增强对象的功能,而这是通过对象内部的包装器来实现的。在装饰器模式中,装饰器类和被装饰对象通常实现相同的接口或继承自相同的类,以确保两者可以相互替代。装饰器模式也被称为封装器模式。 在代理模式中,代理类附加了与原类无关的功能。
-
golang 实现了 HTTP 代理和反向代理。
-
如何使用 Nginx 实现反向代理和端口转发?
-
反传销网8月30日发布:视频区块链里的骗子,币里的韭菜,杜子建骂人了!金融大V周召说区块链!——“一小帮骗子玩一大帮小白,被割韭菜,小白还轮流被割,割的就是你!” 什么区块链,统统是骗子 作者:周召(知乎金融领域大V,毕业于上海财经大学,目前任职上海某股权投资基金合伙人) 有人问我,区块链现在这么火,到底是不是骗局? 我的回答是: 是骗局。而且我并不是说数字货币是骗局,而是说所有搞区块链的都是骗局。 -01- 区块链是一种鸡肋技术 人类社会任何技术的发明应用,本质都是为了提高社会的生产效率。而所谓区块链技术本质不过是几种早已成熟的技术的大杂烩,冗余且十分低效,除了提高了洗钱和诈骗的效率以外,对人类社会的进步毫无贡献。 真正意义上的区块链得包含三个要素:分布式系统(包括记账和存储),无法篡改的数据结构,以及共识算法,三者互为基础和因果,就像三体世界一样。看上去挺让人不明觉厉的,而经过几年的瞎折腾,稍微懂点区块链的碰了几次壁后都已经渐渐明白区块链其实并没有什么卵用,区块链技术已经名存实亡,沦为了营销工具和传销组织的画皮。 因为符合上述定义的、以比特币为代表的原教旨区块链技术,是反效率的,从经济学角度来说,不但不是一种帕累托改进,甚至还可以说是一种帕累托倒退。 原教旨区块链技术的效率十分低下,因为要遍历所有节点,只能做非常轻量级的数据应用,一旦涉及到大量的数据传输与更新,区块链就瞎了。 一方面整条链交易速度会极慢,另一方面数据库容量极速膨胀,考虑到人手一份的存储机制,区块链其实是对存储资源和能源的一种极大的浪费。 这里还没有加上为了取得所谓的共识和挖矿消耗的巨大的能源,如果说区块链技术是屎,那么这波区块链投机浪潮可谓人类历史上最大规模的搅屎运动。 区块链也验证不了任何东西。 所谓的智能合约,即不智能,也非合约。我看有人还说,如果有了智能合约,就可以跟老板签一份放区块链上,如果明年销售业绩提升30%,就加薪10%,由于区块链不能篡改,不能抵赖,所以老板必须得执行,说得有板有眼,不懂行的愣一看,好像还真是那么回事。 但仔细一想,问题就来了。首先,在区块链上如何证明你真的达到了30%业绩提升?即便真的达到老板耍赖如何执行? 也就是说,如果区块链真这么厉害,要法院和仲裁干什么。 人类社会真正的符合成本效益原则的是代理制度。之前有人说要用区块链改造注册会计师行业,我不知道他准备怎么设计,我猜想他思路大概是这样的,首先肯定搞去中心化,让所有会计师到链上来,然后一个新人要成为注册会计师就要所有会计师同意并记录在链上。 那我就请问了,我每天上班累死累活,为什么还要花时间去验证一个跟我无关的的人的专业能力?最优做法当然是组织一个委员会,让专门的人来负责,这不就是现在注册会师协会干的事儿吗?区块链的逻辑相当于什么事情都要拿出来公投,这个绝对是扯淡的。 当然这么说都有点抬举区块链了,区块链技术本身根本没有判断是非能力,如果这么高级的人工智能,靠一个无脑分布式记账就能实现的话,我们早就进入共产主义社会了。 虽然EOS等数字货币采用了超级节点,通过再中心化的方式提高效率,有点行业协会的意思,是对区块链原教旨主义的一种修正,但是依然无法突破区块链技术最本质的局限性。有人说,私有链和联盟链是区块链技术的未来,也是扯淡,因为区块链技术没有未来。如果有,说明他是包装成区块链的伪区块链技术。 区块链所涉及的所有底层技术,不管是分布式数据库技术,加密技术,还是点对点传输技术等,基本都是早已存在没什么秘密可言的技术。 比特币系统最重要的特性是封闭性和自洽性,他验证不了任何系统自身以外产生的信息的真实性。 所谓系统自身产生的信息,就是数据库数据的变动信息,有价值的基本上有且只有交易信息。所以说比特币最初不过是中本聪一种炫技的产物,来证明自己对几种技术的掌握,你看我多牛逼,设计出了一个像三体一样的系统。因此,数字货币很有可能是区块链从始至终唯一的杀手应用。 比特币和区块链概念从诞生到今天已经快10年了,很多人说区块链技术在爆发的前夜,但这个前夜好像是不是有点过长了啊朋友,跟三体里的长夜有一拼啊。都说区块链技术像是90年代初的互联网,可是90年代初的互联网在十年发展后,已经出现了一大批伟大的公司,阿里巴巴在99年都成立了,区块链怎么除了币还是币呢? 正规的数字货币未来发展的形式无外乎几种,要么就是论坛币形式,或者类似股票的权益凭证等。问题是论坛币和股票之前,本来也都电子化了,区块链来了到底改变了什么呢? 所有想把TOKEN和应用场景结合起来的人最后都很痛苦,最后他们会发现区块链技术就是脱裤子放屁,自己辛苦搞半天,干嘛不自己作为中心关心门来收钱?最后这些人都产生了价值的虚无感,最终精神崩溃,只能发币疯狂收割韭菜,一边嘴里还说着我是个好人之类的奇怪的话。 因此,之前币圈链圈还泾渭分明,互相瞧不起,但这两年链圈逐渐坐不住了,想着是不是趁着泡沫没彻底破灭之前赶快收割一波,不然可能什么都捞不着了。 前段时间和一个名校毕业的链圈朋友瞎聊天,他说他们“致力于用区块链技术解决数字版权保护问题”,我就问他一个问题,你们如何保证你链的版权所有权声明是真实的,万一盗版者抢先一步把数据放在链上怎么办。他说他们的解决方案是连入国家数字版权保护中心的数据库进行验证…… 所以说区块链技术就是个鸡肋,研究到最后都会落入效率与真实性的黑洞,很多人一头扎进链圈后才发现,真正意义上的区块链技术,其实什么都干不了。 -02- 不是蠢就是坏的区块链媒体 空气币和区块链的造富神话,让区块链自媒体也开始迎风乱扭。一群群根本不知道区块链为何物的妖魔鬼怪纷纷进驻区块链自媒体战场,开始大放厥词胡编乱造。 任何东西,但凡只要和区块,链,分,分布式,记账,加密,验证,可追溯等等这些个关键词沾到哪怕一点点,这些所谓的区块链媒体人就会像狗闻到了屎了一样疯狂地把区块链概念往上套。 这让我想起曾经一度也是热闹非凡的物联网,我曾经去看过江苏一家号称要改变世界的“物联网”企业,过去一看是生产路由器的,我黑人问号脸,对方解释说没有路由器万物怎么互联,我觉得他说得好有道理,竟无言以对。 好,下面让我们进入奇葩共赏析时间,来看看区城链媒体经常有哪些危言耸听的奇谈怪论 区块链(分布式记账)的典型应用是*?? 正如前面所说,真正意义上的区块链分布式记账,不光包括“记”这个动作,还包括分布式存储和共识机制等。而*诞生远远早于区块链这个词的出现,勉强算是“分布式编辑”吧,就被很多区块链媒体拿来强行充当区块链技术应用的典范。 其实事实恰恰相反,*恰恰是去中心化失败的典范,现在如果没有精英和专业人士的编辑和维护,*早就没法看了。 区块链会促进社会分工?? 罗振宇好像就说过类似的话,虽然罗振宇说过很多没有逻辑的话,但这句话绝对是最没逻辑思维的。很多区块链自媒体也常常用这句话来忽悠老百姓,说分工代表效率提高社会进步,而区块链“无疑”会促进分工,他们的理由仅仅是分工和分布式记账都共用一个“分”字,就强行把他们扯到一起。 实际情况恰恰相反,区块链是逆分工的,区块链精神是号召所有人积极地参与到他不擅长也不想掺合的事情里面去。 区块链不能像上帝一样许诺他的子民死后上天国,只能给他们许诺你们是六度人脉中的第一级,我可以赚后面五级人的钱,你处于金字塔的顶端。
-
Nginx 配置]使用上游和代理通行证实现反向代理和负载平衡
-
终于有人清楚地解释了正向代理和反向代理!
-
使用frp和proxifier实现内网socks5反向代理
-
*访问内网机器:通过腾讯云服务器和 SSH 正反向代理实现