Большая задержка для ответа TCP ACK

среда k8s (4 узла, rke 1.21.5)

Мы заметили случайную значительную задержку при передаче данных сокета между разными модулями k8s. В некоторых случаях задержка может достигать 15 секунд.

Анализируя tcpdump, мы обнаружили, что в некоторых случаях стороне сервера требовалось довольно много времени, чтобы ответить ACK стороне клиента.

Вот дамп TCP на стороне сервера для одного сокета: 10.42.40.2:51702 (клиентская сторона) <-> 10.42.18.64:9099 (серверная сторона)

13:24:05.485173 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1353130:1361578, ack 615, win 3068, options [nop,nop,TS val 497835713 ecr 1074832978], length 8448
**13:24:05.489375 IP 10.42.18.64.9099 > 10.42.40.2.51702: Flags [.], ack 1330602, win 1285, options [nop,nop,TS val 1074832982 ecr 497835641], length 0**
13:24:05.489420 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1361578:1362986, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 1408
13:24:05.489424 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1362986:1367210, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 4224
13:24:05.489482 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1367210:1412266, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 45056
13:24:05.489532 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [P.], seq 1412266:1420714, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 8448
13:24:05.489534 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1420714:1457322, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 36608
13:24:05.489573 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1457322:1472810, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 15488
13:24:05.489688 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1472810:1475626, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 2816
13:24:05.489741 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1475626:1485482, ack 615, win 3068, options [nop,nop,TS val 497835717 ecr 1074832982], length 9856
13:24:05.671207 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1485482:1486890, ack 615, win 3068, options [nop,nop,TS val 497835899 ecr 1074832982], length 1408
13:24:06.155201 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1330602:1332010, ack 615, win 3068, options [nop,nop,TS val 497836383 ecr 1074832982], length 1408
13:24:07.115190 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1330602:1332010, ack 615, win 3068, options [nop,nop,TS val 497837343 ecr 1074832982], length 1408
13:24:09.003161 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1330602:1332010, ack 615, win 3068, options [nop,nop,TS val 497839231 ecr 1074832982], length 1408
13:24:12.843114 IP 10.42.40.2.51702 > 10.42.18.64.9099: Flags [.], seq 1330602:1332010, ack 615, win 3068, options [nop,nop,TS val 497843071 ecr 1074832982], length 1408
**13:24:17.658342 IP 10.42.18.64.9099 > 10.42.40.2.51702: Flags [.], ack 1361578, win 1255, options [nop,nop,TS val 1074845151 ecr 497835713], length 0**
13:24:17.658357 IP 10.42.18.64.9099 > 10.42.40.2.51702: Flags [.], ack 1486890, win 1133, options [nop,nop,TS val 1074845151 ecr 497835717,nop,nop,sack 1 {1330602:1332010}], length 0
13:24:17.658360 IP 10.42.18.64.9099 > 10.42.40.2.51702: Flags [.], ack 1486890, win 1133, options [nop,nop,TS val 1074845151 ecr 497835717,nop,nop,sack 1 {1330602:1332010}], length 0
13:24:17.658365 IP 10.42.18.64.9099 > 10.42.40.2.51702: Flags [.], ack 1486890, win 1133, options [nop,nop,TS val 1074845151 ecr 497835717,nop,nop,sack 1 {1330602:1332010}], length 0

Согласно tcpdump, сервер (9099) ответил на подтверждение 1330602 в 13:24:05.489375. Затем, в течение следующих 12 секунд, он не ответил ни на одно подтверждение до 13:24:17.658342. Я думаю, что это заблокировало сокет и помешало стороне клиента передать больше байтов. После 13:24:17 сокет вернулся в нормальное состояние и байты продолжали сбрасываться в него.

Мы пробовали TCP_NODELAY и TCP_QUICKACK, это не решает проблему. (И я так не думаю) Не могли бы вы указать причину, по которой ответ на TCP ACK может занять так много времени?

kubernetes tcpip tcpdump

0

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *