haproxy-настройка кэша TCP-соединений для HTTP-сервера

Я пытаюсь настроить локальный кэш TCP-подключения, чтобы обеспечить доступ к удаленному серверу HTTP для нескольких локальных приложений.

Я начал настраивать haproxy так:

global
    log         /dev/log local0
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    daemon
    stats socket /var/lib/haproxy/stats

defaults
    log global
    mode http
    option http-keep-alive
    timeout http-keep-alive 60000ms
    timeout connect 5000ms
    timeout client 50000ms
    timeout server 50000ms

frontend  http-in
    option httplog
    bind  127.0.0.1:4443
    default_backend facebook

backend facebook
    server fb graph.facebook.com:443 maxconn 32 ssl verify none

который должен позволить мне использовать локальный прокси (http://localhost:4443), чтобы поговорить с https://graph.facebook.com

и да, оно вроде работает:

$ curl -4 -x http://127.0.0.1:4443 -vvv 'http://graph.facebook.com/v2.4/me?fields=id%2Cname&access_token=CAACEdEose0cBAPvPqQIAjacV1whsrRfcchVVOXZAgi9ZC56HBVOh5PfI9IZBA12nAmsu9Q9Pznv1e6iZBsnbr4u2nCASnvZBGimBjdWErUXTRQetn0fdV0HLZB68tS0idelR35ybiWnehK5oec9dM9LxjRvFwTpuHSUkeA9nBAyFZBrGf4FcZAXuhT2uj5vjbvYkzupyi4mBFlBGfBEIjpeb'

однако, когда я tcpdump мой локальный интерфейс, чтобы увидеть, что происходит на graph.facebook.com, я вижу, что каждый раз, когда я выполняю выше, создается новое TCP-соединение:

19:06:34.409962 IP (tos 0x0, ttl 64, id 51970, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.80.42560 > 31.13.64.1.https: Flags [S], cksum 0xc6fe (correct), seq 1868596651, win 29200, options [mss 1460,sackOK,TS val 37375657 ecr 0,nop,wscale 7], length 0
19:06:34.486631 IP (tos 0x0, ttl 86, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    31.13.64.1.https > 192.168.1.80.42560: Flags [S.], cksum 0xc226 (correct), seq 2991458091, ack 1868596652, win 13980, options [mss 1410,sackOK,TS val 3177564556 ecr 37375657,nop,wscale 8], length 0
19:06:34.486705 IP (tos 0x0, ttl 64, id 51971, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.80.42560 > 31.13.64.1.https: Flags [.], cksum 0x262d (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 37375733 ecr 3177564556], length 0
19:06:34.486852 IP (tos 0x0, ttl 64, id 51972, offset 0, flags [DF], proto TCP (6), length 569)
    192.168.1.80.42560 > 31.13.64.1.https: Flags [P.], cksum 0x2730 (correct), seq 1:518, ack 1, win 229, options [nop,nop,TS val 37375733 ecr 3177564556], length 517
19:06:34.578182 IP (tos 0x0, ttl 86, id 52940, offset 0, flags [DF], proto TCP (6), length 52)
    31.13.64.1.https > 192.168.1.80.42560: Flags [.], cksum 0x2474 (correct), seq 1, ack 518, win 59, options [nop,nop,TS val 3177564650 ecr 37375733], length 0
...

отсюда и мой вопрос: что я сделал неправильно здесь ? Я хотел бы, чтобы мой локальный сервер haproxy продолжал открывать TCP-соединения graph.facebook.com как можно дольше, чтобы иметь возможность повторно использовать их на нескольких клиентах и запросах, но похоже, что haproxy создает и разрывает TCP-соединения по мере необходимости, несмотря на опцию http-keep-alive.

любые идеи ?

29
задан barlop
14.12.2022 14:03 Количество просмотров материала 3015
Распечатать страницу

1 ответ

на документация HAproxy, в 1.1. The HTTP transaction model раздел, говорит следующее:

по умолчанию HAProxy работает в туннельном режиме относительно постоянные соединения: для каждого соединения оно обрабатывает первое запросить и переслать все остальное (включая дополнительные запросы) на выбранный сервер. После установки соединение сохраняется на стороне клиента и сервера. Используйте опцию "http-Server-close" для сохранение постоянных клиентских соединений при обработке каждого входящего запрос индивидуально, отправляя их один за другим на серверы, в режиме закрытия HTTP. Используйте "option httpclose", чтобы переключиться с обеих сторон на Режим закрытия HTTP. "вариант пока вариант" и " http-pretend-keepalive" помощь в обходе серверов Режим закрытия HTTP.

вы определили http-keep-alive директива и не использовали ни один из описанных выше параметров, таким образом, вы должны работать в туннельный режим (кроме того, у меня есть несколько конфигураций HAproxy, очень похожих на ваши, и я могу заверить вас, что он работает, как говорится в документации).

Я думаю, что виновник так, как вы используете curl для проверки конфигурации. Вы передаете его -x флаг, который означает, что вы хотите использовать следующий параметр в качестве прокси, однако, HAproxy уже действует так. Поэтому просьба должна быть примерно такой:

curl 'http://127.0.0.1:4443/v2.4/me?fields=id%2Cname&access_token=CAACEdEose0cBAPvPqQ‌​IAjacV1whsrRfcchVVOXZAgi9ZC56HBVOh5PfI9IZBA12nAmsu9Q9Pznv1e6iZBsnbr4u2nCASnvZBGim‌​BjdWErUXTRQetn0fdV0HLZB68tS0idelR35ybiWnehK5oec9dM9LxjRvFwTpuHSUkeA9nBAyFZBrGf4Fc‌​ZAXuhT2uj5vjbvYkzupyi4mBFlBGfBEIjpeb

таким образом, вы отправляете запрос напрямую HAproxy и не использовать HAProxy в качестве прокси (потому что он будет вести себя таким образом сам).

1
отвечен nKn 2022-12-15 21:51

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх