Как предотвратить непрерывные ACK-пакеты на мой сервер

339
K Joe

Я обнаружил, что мой сервер получает непрерывные ACK-пакеты с разных сайтов, никогда не останавливаясь, как показано ниже (я использовал tcpdump для захвата)

  1. удаленные сайты используют https.
  2. содержит akamai, amazon .. и т. д., который должен быть законным.

Мне интересно, что раньше были неудачные соединения с этими сайтами, потом это случилось.

Я хотел бы знать, как не получить эти пакеты ACK.

23:12:37.555238 IP prg02s12-in-f1.1e100.net.https > 192.168.192.128.52285: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.555242 IP 17.167.192.152.https > 192.168.192.128.49292: Flags [FP.], seq 0, ack 1, win 64239, length 0 23:12:37.555246 IP prg02s12-in-f14.1e100.net.https > 192.168.192.128.49961: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 23:12:37.555253 IP 17.164.1.38.https > 192.168.192.128.49844: Flags [FP.], seq 0:37, ack 1, win 64240, length 37 23:12:37.555293 IP a2-16-84-128.deploy.akamaitechnologies.com.https > 192.168.192.128.49850: Flags [FP.], seq 0:31, ack 1, win 64240, length 31 23:12:37.555301 IP 125.209.252.12.https > 192.168.192.128.49929: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.555307 IP prg02s12-in-f4.1e100.net.https > 192.168.192.128.49964: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 23:12:37.655195 IP fra07s31-in-f1.1e100.net.https > 192.168.192.128.58291: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.655227 IP ec2-54-193-107-210.us-west-1.compute.amazonaws.com.https > 192.168.192.128.50448: Flags [FP.], seq 0:7, ack 1, win 64240, length 7 23:12:37.655233 IP fra07s31-in-f1.1e100.net.https > 192.168.192.128.41618: Flags [FP.], seq 0:110, ack 1, win 64240, length 110 23:12:37.655238 IP ec2-54-154-38-161.eu-west-1.compute.amazonaws.com.5223 > 192.168.192.128.48941: Flags [FP.], seq 0:7, ack 1, win 64240, length 7 23:12:37.655243 IP fra07s31-in-f1.1e100.net.https > 192.168.192.128.54130: Flags [FP.], seq 0:110, ack 1, win 64240, length 110 23:12:37.655247 IP prg02s12-in-f1.1e100.net.https > 192.168.192.128.52285: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.655254 IP 17.167.192.152.https > 192.168.192.128.49292: Flags [FP.], seq 0, ack 1, win 64239, length 0 23:12:37.655259 IP prg02s12-in-f14.1e100.net.https > 192.168.192.128.49961: Flags [FP.], seq 0:55, ack 1, win 64240, length 55 23:12:37.655265 IP 17.164.1.38.https > 192.168.192.128.49844: Flags [FP.], seq 0:37, ack 1, win 64240, length 37 23:12:37.655271 IP a2-16-84-128.deploy.akamaitechnologies.com.https > 192.168.192.128.49850: Flags [FP.], seq 0:31, ack 1, win 64240, length 31 23:12:37.655275 IP 125.209.252.12.https > 192.168.192.128.49929: Flags [FP.], seq 0, ack 1, win 64240, length 0 23:12:37.655281 IP prg02s12-in-f4.1e100.net.https > 192.168.192.128.49964: Flags [FP.], seq 0:55, ack 1, win 64240, length 55
1
почти каждый пакет в соединении TCP должен иметь флаг ACK, установленный на 1. Кроме того, для числа наполовину открытых соединений я бы ожидал много входящих запросов соединения с установленным SYN и без ACK. для каждого другого пакета в соединении будет установлен флаг ACK. Frank Thomas 8 лет назад 2
Вы правы, я захватил некоторые пакеты с Wireshark, эти пакеты должны быть [SYN, ACK], а не [ACK]. Есть несколько неизвестных причин, по которым нет пакетов ACK. Можно ли автоматически отбрасывать такие пакеты? K Joe 8 лет назад 0
Вы отправляете данные на эти веб-серверы, и они это подтверждают. Что заставляет вас думать, что это что-то иное, чем то, на что это похоже - подтверждение достоверных данных? David Schwartz 8 лет назад 1
Как сказал @DavidSchwartz, это нормальное поведение для TCP. Единственный известный мне способ уменьшить ACK - это SACK, но обе стороны должны согласиться использовать его. При использовании SACK ACK отправляется после группы пакетов, а не только одного, и детализирует все не полученные фрагменты. https://www.ietf.org/rfc/rfc2018.txt MaQleod 8 лет назад 0

0 ответов на вопрос

Похожие вопросы