TCP нулевой размер окна и полный размер окна

Проблема, с которой мы сталкиваемся, заключается в том, что некоторые соединения http имеют время отклика> 60 с (около 5%). Я обнаружил, что проблема должна быть между веб-сервером и loadbalancer.

Вот мой вывод, мы попробовали два набора серверов:

Настройка A: только 1 веб-сервер (Сервер A), весь трафик tcp направлен непосредственно на этот сервер.

Настройка B: loadbalancer + Сервер A, вес Сервера A равен 100. С алгоритмом "Круглый Робин с Постоянным IP"

Для установки A соединение tcp действительно стабильно, коэффициент тайм-аута составляет менее 1%. Однако для настройки B коэффициент тайм-аута составляет более 5%, и здесь возникает проблема. (тайм-аут соединения, установленный на клиенте, составляет 60 с)

Мы протестировали эти два параметра в общей среде (с 10-минутным периодом времени), у которой есть номер ближайшего пакета (около 700000 пакетов) и трафик. В результате мы получили 2 набора tcpdump, я обнаружил несколько странных записей в журнале и сосчитал их следующим образом:

                            Setup A                Setup B
TCP Zero window size        0                      611
TCP Window Full             0                      3672
TCP Out-Of-Order            4147                   4577
TCP Retransmission          23665                  21551
TCP Dup Ack                 10592                  10121

Для приведенного выше результата, я вполне уверен, что эта проблема с окном TCP, поэтому я попытался включить net.ipv4.tcp_window_scaling > перезагрузка, но это не помогает. Я тоже пытался отключить iptables, тоже не помогает. Я не знаю, есть ли какие-либо настройки влияют на окно TCP.

Стоит знать, что наш ip loadbalancer - это xx.xx.117.128, все пакеты, помеченные как TCP Window Full, отправляются с сервера A на xx.xx.117.25, а все пакеты, помеченные как размер окна TCP Zero, относятся к xx.xx.117.25 на сервер А

Я спросил специалиста по программному обеспечению, что такое xx.xx.117.25, и они ответили: "xx.xx.117.25 - это адрес, с которого балансировщик нагрузки будет подключаться к вашим реальным серверам". Они предполагают, что это проблема брандмауэра, как я уже упоминал выше, Я проверил с выключенным Iptables. Таким образом, мы можем устранить этот фактор

Это то, что я обнаружил до сих пор.

Может быть, вы заинтересованы в конфигурации sysctl и вот оно:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
kernel.shmall = 4294967296
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_max_syn_backlog = 1000
net.core.netdev_max_backlog = 1000
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_fin_timeout = 20

вот снимок состояния tcp Сервера A в Установке A

604 TIME_WAIT
7 SYN_RECV
1 LISTEN
2 FIN_WAIT1
1 ESTABLISHED
1 CLOSING

Не совсем уверен, почему TIME_WAIT так высоко (у меня есть entable tcp_tw_reuse и tcp_tw_recycle). Я также отслеживал состояние tcp в настройке B, количество TIME_WAIT еще больше (около 300 - 400)

для конфигурации Apache:

KeepAlive Off
<IfModule prefork.c>
StartServers       5
MinSpareServers   10
MaxSpareServers   50
ServerLimit      500
MaxClients       500
MaxRequestsPerChild  4000
</IfModule>

Пожалуйста помоги. огромное спасибо