罗剑锋透视HTTP协议学习笔记---21 | 良心中间商：HTTP的代理服务

21 | 良心中间商：HTTP的代理服务

代理服务
典型的HTTP的收发模型，只有客户端和服务端2个角色参与。但真实的HTTP应用场景，往往会在二者之间的传输链路上引入1个或多个代理服务器。代理服务器在HTTP通讯模型中扮演着双重的角色：从客户端看来，它是服务器；从服务器看来它是客户端。
代理服务器可以1个或多个，形成有序的数据传输链条，对任意2个临近的节点，它们仍然遵循HTTP一发一收的工作模式。代理服务器不产生数据，但会对数据进行加工，分发，缓存。
client — proxy server1 — proxy server2 — … proxy servern — origin server

代理服务器的作用
• 负载均衡，接收用户端请求，并把请求按一定算法，分发到后端的真实服务器
• 健康检查，用‘心跳’等机制从集群中剔除不可靠的服务器
• 安全防护，使用安全策略，如限IP限流，抵御外网攻击。
• 数据过滤，报文检查，修改，施加管理策略。
• 加密卸载，外网使用TLS加密通讯，认证，安全的内网不加密，消除加解密成本
• 内容缓存，缓存复用服务器响应

负载均衡算法：
轮询，一致性hash，随机，链路最短，最近最少使用

代理相关头字段

• 可以用通用字段Via标记HTTP传输路径中间经过的代理服务器
• 代理服务器代理发送请求，所以源客户端信息丢失，可以用X-Forwarded-For和X-Real-IP标记
• X-Forwarded-For,从源客户端开始，每经过一个代理服务器添加一个IP[非标准，但是事实标准头字段de-facto standard header]
• X-Real-IP,仅包含源客户端IP

代理协议
上述方法的缺点是，需要修改HTTP头字段，执行效率低，另外在HTTPS的情况下不可行，所以又引入HAProxy代理协议，通过在HTTP头部再封装一层头，来实现代理转发，格式如下
PROXY TCP4 1.1.1.1 2.2.2.2 55555 80
HTTP头部…
HTTP 实体…

此方案不修改HTTP头字段，执行效率高，方案实现了类似带X-Real-IP头字段的效果,缺点是没有携带每跳代理服务器的信息，即Via和/或X-Forwarded-For的功能。

补充：
via的格式，和本节描述的格式有所不同。

RFC7230 5.7.1Via的格式

Via = 1#( received-protocol RWS received-by [ RWS comment ] )

     received-protocol = [ protocol-name "/" ] protocol-version
                         ; see Section 6.7
     received-by       = ( uri-host [ ":" port ] ) / pseudonym
     pseudonym         = token

Via: [ <protocol-name> "/" ] <protocol-version> <host> [ ":" <port> ]
or
Via: [ <protocol-name> "/" ] <protocol-version> <pseudonym>

<protocol-name>

可选。所使用的协议名称，如 “HTTP”。

<protocol-version>

所使用的协议版本号， 例如 “1.1”。

<host> and <port>

公共代理的URL及端口号。

<pseudonym>

内部代理的名称或别名。

via的例子：

Via: 1.1 vegur
Via: HTTP/1.1 GWA
Via: 1.0 fred, 1.1 p.example.net

课后作业

你觉得代理有什么缺点？实际应用时如何避免？

• 增加了复杂度，无法避免
• 增加了时延，无法避免
• 增加了安全性风险，采用HTTPS

你知道多少反向代理中使用的负载均衡算法？它们有什么优缺点？
轮询，一致性hash，随机，链路最短，最近最少使用