关于java:网络协议之haproxy的Proxy-Protocol代理协议

简介

代理大家应该都很相熟了，比拟闻名的像是nginx,apache HTTPD，stunnel等。

咱们晓得代理就是代替客户端向服务器端进行音讯申请，并且心愿在代理的过程中保留初始的TCP连贯信息，例如源和指标IP和端口等，以提供一些个性化的操作。

个别状况下，为了实现这个指标，有一些现成的解决办法，比方在HTTP协定中，能够应用“X-Forwarded-For”标头，来蕴含无关原始源地址，还有”X-Original-To”用来携带目标地址的信息。

又比方在SMTP协定中，能够特地应用XCLIENT协定来进行邮件替换。

或者能够通过编译内核，把你的代理作为你服务器的默认网关。

这些形式尽管可用，然而或多或少有一些限度，要么与协定相干，要么批改批改零碎架构，从而可扩展性不强。

尤其是在多个代理服务器链式调用的状况下，上述办法简直是不可能实现的。

这就须要一个对立的代理协定，通过所有的节点都兼容这个代理协定就能够无缝实现代理的链式调用。这个代理协定就是haproxy在2010年提出的proxy Protocol。

这个代理协定的长处是：

• 它与协定无关（能够与任何7层协定一起应用，即便在加密的状况也可用）
• 它不须要任何基础架构更改
• 能够穿透NAT防火墙
• 它是可扩大的

而haproxy自身就是一个十分优良的开源负载平衡和代理软件，提供了高负载能力和优良的性能，所以在很多公司得以宽泛的应用，比方：GoDaddy, GitHub, Bitbucket,Stack Overflow,Reddit, Slack,Speedtest.net, Tumblr, Twitter等。

明天要介绍的就是haproxy的Proxy Protocol代理协定的底层细节。

Proxy Protocol的实现细节

下面咱们提到了Proxy Protocol的目标就是能够携带一些能够标记初始的TCP连贯信息的字段，比方IP地址和端口等。

如果是客户端和服务器端直连，那么服务器端能够通过getsockname和getpeername取得如下的信息：

• address family: AF_INET for IPv4, AF_INET6 for IPv6, AF_UNIX
• socket protocol: SOCK_STREAM for TCP, SOCK_DGRAM for UDP
• 网络层的源和指标地址
• 传输层的源和指标的端口号

所以Proxy Protocol的目标就是封装下面的这些信息，而后将上述信息放到申请头中去，这样服务器端就能够正确读取客户端的信息。

在Proxy Protocol中，定义了两个版本。

在版本1中，头文件信息是文本模式的，也就是人类可读的，采纳这种形式，次要是为了在协定利用的晚期保障更好的可调试性，从而疾速景修改。

在版本2中，提供了对头文件的二进制编码性能，在版本1的性能曾经根本欠缺的前提下，提供二进制编码，能够无效的进步利用的传输和解决性能。

因为有两个版本，所以在服务器的接收端也须要实现对相应版本的反对。

为了更好的利用Proxy Protocol，Proxy Protocol理论只定义了一个header信息，这个申请头会在连贯发起者发动连贯的时候放在每个连贯的结尾。并且该协定是无状态的，因为它不冀望发送者在发送标头之前期待接收者，也不冀望接收者发送回任何内容。

接下来，咱们具体察看一下两个版本协定的实现。

版本1

在版本1中，proxy header是由一串US-ASCII编码的字符串组成的。这个proxy header将会在客户端和服务器端建设连贯，并且发送任何实在数据之前发送。

先来看一个应用了proxy header的http申请的例子：

    PROXY TCP4 192.168.0.1 192.168.0.102 12345 443\r\n
    GET / HTTP/1.1\r\n
    Host: 192.168.0.102\r\n
    \r\n

下面的例子中，\r\n示意的是回车换行，也就是行完结的标记。该代码向host:192.168.0.102发送了一个HTTP申请，第一行的内容就是应用的proxy header。

具体什么含意呢？

首先是字符串”PROXY”,示意这是一个proxy protocol的header,并且是v1版本的。

接着是一个空格分隔符。

而后是proxy应用的INET protocol 和 family。对于v1版本来说，反对”TCP4″和”TCP6″这两种形式。下面的例子中，咱们应用的是TCP4.

如果要应用其余的协定，那么能够设置为”UNKNOWN”。如果设置为”UNKNOWN”，那么前面到CRLF之前的数据将会被疏忽。

接着是一个空格分隔符。

而后是网络层源的IP地址，依据选的是TCP4还是TCP6，对应的源IP地址也有不同的示意模式。

接着是一个空格分隔符。

而后是网络层指标地址的IP地址，依据选的是TCP4还是TCP6，对应的源IP地址也有不同的示意模式。

接着是一个空格分隔符。

而后是TCP源的端口号，取值范畴是0-65535。

接着是一个空格分隔符。

而后是TCP指标地址的端口号，取值范畴是0-65535。

接着是CRLF结束符。

这样一个v1版本的proxy protocol就定义完了，是不是很简略。

依据这样的定义，咱们很好来计算整个proxy protocol的最大长度，对于TC4来说，最大的长度示意为：

  - TCP/IPv4 :
      "PROXY TCP4 255.255.255.255 255.255.255.255 65535 65535\r\n"
    => 5 + 1 + 4 + 1 + 15 + 1 + 15 + 1 + 5 + 1 + 5 + 2 = 56 chars

对于TCP6来说，最大的长度示意为：

  - TCP/IPv6 :
      "PROXY TCP6 ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n"
    => 5 + 1 + 4 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 = 104 chars

对于UNKNOWN来说，可能有上面的最小长度和最大长度示意为：

  - unknown connection (short form) :
      "PROXY UNKNOWN\r\n"
    => 5 + 1 + 7 + 2 = 15 chars

  - worst case (optional fields set to 0xff) :
      "PROXY UNKNOWN ffff:f...f:ffff ffff:f...f:ffff 65535 65535\r\n"
    => 5 + 1 + 7 + 1 + 39 + 1 + 39 + 1 + 5 + 1 + 5 + 2 = 107 chars

所以，总体来说108个字符曾经足够v1版本应用了。

版本2

版本2次要是实现的二进制编码，尽管对人类可读不敌对，然而能够进步传输和解析效率。

版本2的header是以上面12 bytes结尾的block：

\x0D \x0A \x0D \x0A \x00 \x0D \x0A \x51 \x55 \x49 \x54 \x0A

接下来的一个byte(13 bytes)是protocol version 和 command。因为一个byte是8个bits，应用一个byte来保留有点太侈靡了。所以将其拆分成两局部。

高位的4个bits保留的是版本，这里版本号必须是”\x2″。

低位的4个bits保留的是command，有上面几个值：

• LOCAL(\x0): 示意连贯是由代理本人发动的，个别用在代理向服务器发送健康检查时。
• PROXY(\x1): 代表连贯是由另外一个节点发动的，这是一个proxy代理申请。 而后接收者必须应用协定块中提供的信息来获取原始地址。
• 其余：其余command都须要被抛弃，因为不可辨认。

接下来的一个byte(14 bytes)保留的是transport protocol 和 address family。

其中高4位保留的是address family,低4位保留的是transport protocol。

address family可能有上面的值：

• AF_UNSPEC(0x0): 示意的是不反对的，或者未定义的protocol。当sender发送LOCAL command或者解决为止protocol families的时候就能够应用这个值。
• AF_INET(0x1):示意的是IPv4地址,占用4bytes。
• AF_INET6(0x2):示意的是IPv6地址，占用16bytes。
• AF_UNIX(0x3):示意的是unix address地址，占用108 bytes。

transport protocol可能有上面的值：

• UNSPEC(0x0): 未知协定类型。
• STREAM(0x1):应用的是SOCK_STREAM protocol，比方TCP 或者UNIX_STREAM。
• DGRAM(0x2):应用的是SOCK_DGRAM protocol，比方UDP 或者UNIX_DGRAM。

低4位和高4位进行组合，能够失去上面几种值：

• UNSPEC(\x00)
• TCP over IPv4(\x11)
• UDP over IPv4(\x12)
• TCP over IPv6(\x21)
• UDP over IPv6(\x22)
• UNIX stream(\x31)
• UNIX datagram(\x32)

第15和16 bytes示意的剩下的字段的长度，综上，16-byte的v2能够用上面的构造体示意：

    struct proxy_hdr_v2 {
        uint8_t sig[12];  /* hex 0D 0A 0D 0A 00 0D 0A 51 55 49 54 0A */
        uint8_t ver_cmd;  /* protocol version and command */
        uint8_t fam;      /* protocol family and address */
        uint16_t len;     /* number of following bytes part of the header */
    };

从第17个byte开始，就是地址的长度和端口号信息，能够用上面的构造体示意：

    union proxy_addr {
        struct {        /* for TCP/UDP over IPv4, len = 12 */
            uint32_t src_addr;
            uint32_t dst_addr;
            uint16_t src_port;
            uint16_t dst_port;
        } ipv4_addr;
        struct {        /* for TCP/UDP over IPv6, len = 36 */
             uint8_t  src_addr[16];
             uint8_t  dst_addr[16];
             uint16_t src_port;
             uint16_t dst_port;
        } ipv6_addr;
        struct {        /* for AF_UNIX sockets, len = 216 */
             uint8_t src_addr[108];
             uint8_t dst_addr[108];
        } unix_addr;
    };

在V2版本中，除了address信息之外，header中还能够蕴含一些额定的扩大信息，这些信息被称为Type-Length-Value (TLV vectors),格局如下：

        struct pp2_tlv {
            uint8_t type;
            uint8_t length_hi;
            uint8_t length_lo;
            uint8_t value[0];
        };

字段的含意别离是类型，长度和值。

上面是目前反对的类型：

        #define PP2_TYPE_ALPN           0x01
        #define PP2_TYPE_AUTHORITY      0x02
        #define PP2_TYPE_CRC32C         0x03
        #define PP2_TYPE_NOOP           0x04
        #define PP2_TYPE_UNIQUE_ID      0x05
        #define PP2_TYPE_SSL            0x20
        #define PP2_SUBTYPE_SSL_VERSION 0x21
        #define PP2_SUBTYPE_SSL_CN      0x22
        #define PP2_SUBTYPE_SSL_CIPHER  0x23
        #define PP2_SUBTYPE_SSL_SIG_ALG 0x24
        #define PP2_SUBTYPE_SSL_KEY_ALG 0x25
        #define PP2_TYPE_NETNS          0x30

Proxy Protocol的应用状况

下面也提到了，一个协定的好坏不仅仅在与这个协定定义的好不好，也在于应用这个协定的软件多不多。

如果支流的代理软件都没有应用你这个代理协定，那么协定定义的再好也没有用。相同，如果大家都在应用你这个协定，协定定义的再差也是支流协定。

好在Proxy Protocol曾经在代理服务器界被宽泛的应用了。

具体应用该协定的软件如下：

• Elastic Load Balancing，AWS的负载均衡器，从2013年7月起兼容
• Dovecot，一个POP/IMAP邮件服务器从2.2.19版本开始兼容
• exaproxy，一个正向和反向代理服务器，从1.0.0版本开始兼容
• gunicorn ，python HTTP 服务器，从0.15.0开始兼容
• haproxy，反向代理负载均衡器，从1.5-dev3开始兼容
• nginx，正方向代理服务器，http服务器，从1.5.12开始兼容
• Percona DB，数据库服务器，从5.6.25-73.0开始兼容
• stud，SSL offloader,从第一个版本开始兼容
• stunnel，SSL offloader，从4.45开始兼容
• apache HTTPD，web 服务器，在扩大模块myfixip中应用
• varnish，HTTP 反向代理缓存，从4.1版开始兼容

基本上所有的支流服务器都兼容Proxy Protocol，所以咱们能够把Proxy Protocol当做是事实上的规范。

总结

在本文中，咱们介绍了Proxy Protocol的底层定义，那么Proxy Protocol具体怎么应用，能不能实现本人的Proxy Protocol服务器呢？敬请期待。

本文已收录于 http://www.flydean.com/20-haproxy-protocol/

最艰深的解读，最粗浅的干货，最简洁的教程，泛滥你不晓得的小技巧等你来发现！

欢送关注我的公众号:「程序那些事」,懂技术，更懂你！