У меня есть tcpdump для HTTP-запроса, который мне нужно проанализировать. Он состоит из трех подключений. Сначала устанавливается одно, затем другое. Затем, после ~ 190 сегментов, клиент внезапно закрывает первое соединение с помощью флага RST и запускает третье, предположительно для замены первого.
Но до первого сегмента RST все шло нормально, поэтому я не уверен, почему это могло произойти. Еще одна странность заключается в том, что сервер продолжает отправлять данные, еще 9 сегментов в течение 900 микросекунд, даже если клиент отвечает RST на каждый сегмент. Может ли это быть из-за того, что сервер получил и обработал RST за 900 микросекунд, поэтому до этого продолжал отправлять данные? Или есть еще одна причина, по которой он будет продолжать отправлять данные?
Вот соответствующий сегмент данных:
15:08:01.189085 IP 128.186.6.14.80 > 172.16.2.1.45243: P 24904:25243(339) ack 3359 win 49248
15:08:01.189657 IP 172.16.2.1.45243 > 128.186.6.14.80: P 3359:3760(401) ack 25243 win 8610 <nop,nop,timestamp 3136070386 173340265>
15:08:01.226055 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 59543 win 8312 <nop,nop,timestamp 3136070423 173340249>
15:08:01.318224 IP 128.186.6.14.80 > 172.16.2.1.45242: . 59543:60923(1380) ack 3458 win 49248
15:08:01.318328 IP 128.186.6.14.80 > 172.16.2.1.45242: . 60923:62215(1292) ack 3458 win 49248
15:08:01.318346 IP 172.16.2.1.45242 > 128.186.6.14.80: . ack 62215 win 8312 <nop,nop,timestamp 3136070515 173340249>
15:08:01.318475 IP 128.186.6.14.80 > 172.16.2.1.45242: . 62215:63595(1380) ack 3458 win 49248
15:08:01.318537 IP 172.16.2.1.45242 > 128.186.6.14.80: R 3458:3458(0) ack 63595 win 8312 <nop,nop,timestamp 3136070515 173340249>
15:08:01.318612 IP 128.186.6.14.80 > 172.16.2.1.45242: . 63595:64975(1380) ack 3458 win 49248
15:08:01.318629 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.318727 IP 128.186.6.14.80 > 172.16.2.1.45242: . 64975:66355(1380) ack 3458 win 49248
15:08:01.318740 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.318825 IP 172.16.2.1.45244 > 128.186.6.14.80: S 1580873046:1580873046(0) win 5840 <mss 1460,sackOK,timestamp 3136070515 0,nop,wscale 2>
15:08:01.318849 IP 128.186.6.14.80 > 172.16.2.1.45242: . 66355:67735(1380) ack 3458 win 49248
15:08:01.318860 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.318984 IP 128.186.6.14.80 > 172.16.2.1.45242: . 67735:69115(1380) ack 3458 win 49248
15:08:01.318997 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319093 IP 128.186.6.14.80 > 172.16.2.1.45242: . 69115:70407(1292) ack 3458 win 49248
15:08:01.319104 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319222 IP 128.186.6.14.80 > 172.16.2.1.45242: . 70407:71787(1380) ack 3458 win 49248
15:08:01.319232 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319338 IP 128.186.6.14.80 > 172.16.2.1.45242: . 71787:73167(1380) ack 3458 win 49248
15:08:01.319351 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319454 IP 128.186.6.14.80 > 172.16.2.1.45242: . 73167:74547(1380) ack 3458 win 49248
15:08:01.319465 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.319569 IP 128.186.6.14.80 > 172.16.2.1.45242: . 74547:75927(1380) ack 3458 win 49248
15:08:01.319581 IP 172.16.2.1.45242 > 128.186.6.14.80: R 1577678365:1577678365(0) win 0
15:08:01.324493 IP 128.186.6.14.80 > 172.16.2.1.45243: P 25243:25513(270) ack 3760 win 49248
15:08:01.325287 IP 128.186.6.14.80 > 172.16.2.1.45243: P 25513:26594(1081) ack 3760 win 49248
15:08:01.325587 IP 172.16.2.1.45243 > 128.186.6.14.80: P 3760:4160(400) ack 26594 win 8610 <nop,nop,timestamp 3136070522 173340265>
15:08:01.452627 IP 128.186.6.14.80 > 172.16.2.1.45244: S 3542691101:3542691101(0) ack 1580873047 win 49248 <nop,nop,timestamp 173340450 3136070515,mss 1380,nop,wscale 0,nop,nop,sackOK>
128.186.6.14.80 - это сервер, а 172.16.2.1.4524 (2/3/4) - это клиент. Порт 45243 принадлежит второму соединению, 45242 - это первое, которое закрывается RST, а 45244 - третье, которое запускается сразу после того, как клиент отправляет начальное RST для первого.
Есть ли способ узнать, что вызвало этот RST из журналов? Возможно, конкретное поведение HTTP? Два других соединения закрылись нормально с помощью рукопожатий FIN.