use_backend main-ssl if { req.ssl_hello_type 1 }
#use_backend openvpn if !{ req.ssl_hello_type 1 } !{ req.len 0 } // j'ai pas de VPN sur mon serveur.
use_backend xmpp if { payload(0,5) 3c3f786d6c } !{ req.ssl_hello_type 1 } !{ req.len 0 }
use_backend xmpp if { payload(0,5) 3c3f20786d6c } !{ req.ssl_hello_type 1 } !{ req.len 0 }

3c3f786d6c pour <?xml

3c3féà786d6c pour <? xml (en fonction des logiciels... :/ )

Les versions 1.8.x d'HAProxy (premier représentant de la branche publié fin 2017) supportent le protocole HTTP/2 pour la communication frontale (section frontend). L'utiliser en

haproxy.conf. Here is sample config, tested on some not very small environments:

global
log /var/run/syslogd.sock local0
maxconn 60000
nosplice
chroot /usr/share/haproxy
uid 65534
gid 65534
pidfile /var/run/haproxy.pid
stats socket /usr/share/haproxy/haproxy-stats.sock
daemon
defaults
log global
mode tcp
retries 2
option redispatch
option tcplog
option tcpka
option clitcpka
option srvtcpka
timeout connect 5s #timeout during connect
timeout client 24h #timeout client->haproxy(frontend)
timeout server 60m #timeout haproxy->server(backend)

frontend access_clients 213.134.1.1:5222
default_backend cluster_clients

frontend access_clients_ssl 213.134.1.1:5223
default_backend cluster_clients_ssl

frontend access_servers 213.134.1.1:5269
default_backend cluster_servers

backend cluster_clients
log global
balance leastconn
option independant-streams
server server1 10.0.0.1:5222 check fall 3 id 1005 inter 5000 rise 3 slowstart 120000 weight 50
server server2 10.0.0.2:5222 check fall 3 id 1006 inter 5000 rise 3 slowstart 120000 weight 50
server server3 10.0.0.3:5222 check fall 3 id 1007 inter 5000 rise 3 slowstart 120000 weight 50

backend cluster_clients_ssl
log global
balance leastconn
option independant-streams
server server1 10.0.0.1:5223 check fall 3 id 1008 inter 5000 rise 3 slowstart 240000 weight 50
server server2 10.0.0.2:5223 check fall 3 id 1009 inter 5000 rise 3 slowstart 240000 weight 50
server server3 10.0.0.3:5223 check fall 3 id 1010 inter 5000 rise 3 slowstart 240000 weight 50

backend cluster_servers
log global
balance leastconn
option independant-streams
server server1 10.0.0.1:5269 check fall 3 id 1011 inter 5000 rise 3 slowstart 60000 weight 50
server server2 10.0.0.2:5269 check fall 3 id 1012 inter 5000 rise 3 slowstart 60000 weight 50
server server3 10.0.0.3:5269 check fall 3 id 1013 inter 5000 rise 3 slowstart 60000 weight 50

I will not explain every single option, as this is done in excellent documentation, but i will interpret shortly what is going on here. As you can see config reflects graph introduced before, we have 3 “frontend” services (5222, 5223, 5269 - for client TLS, client SSL, and server-2-server), pointing to three backend servers. HAproxy in this example will spread the load equally on all backend servers for all services (leastonn+weight) also it will start accepting connections gradually in the event of failure (slowstart) to prevent connection storm hitting servers when they start. There is couple of options that you can fine-tuned for your needs - like timeouts, fail counts. This is base for your experiments with LB topic. Go and play with it!
One of main advantages of HAproxy is that it is extremely simple, fast to setup, highly reliable and have low footprint on hardware too. Thanks to all that pros we can imagine variety of usages like geographically dislocated proxy servers for XMPP (super interesting topic - will write on that some day), or cross-proxy for better availability.
This is not my last post about LB and XMPP, next stop is Amazon Elastic Load Balancing (ELB), which is great solutions for admins who host their servers on AWS. Stay tuned!

frontend ft_ssl
bind 192.168.0.1:443
mode tcp
option tcplog
tcp-request inspect-delay 5s
tcp-request content accept if { req_ssl_hello_type 1 }
acl sslvpn req_ssl_sni -i vpn.example.net
use_backend bk_sslvpn if sslvpn
use_backend bk_web if { req_ssl_sni -m found }
default_backend bk_ssh

backend bk_sslvpn
mode tcp
source 0.0.0.0 usesrc clientip
server srvvpn vpnserver:1194
backend bk_web
mode tcp
source 0.0.0.0 usesrc clientip
server srvhttps webserver:443
backend bk_ssh
mode tcp
source 0.0.0.0 usesrc clientip
server srvssh sshserver:22

Gestion du routage entre serveur physique ou virtuel grâce à haproxy