Меня раздражает следующий сценарий:
Я управляю MVC приложение на Веб-сервер IIS 10. При вызове URI требуется около 10 секунд, пока приложение не начнет вызываться (время IDLE). Не имея реального объяснения простоя, я начал копать глубже, используя WireShark и наткнуться на следующее явление:
Первоначальное установление связи TCP не завершено (отсутствует ACK)
- Клиент -> Сервер (SYN)
- Сервер -> Клиент (SYN, ACK)
- Клиент -> Сервер (ACK никогда не достигает сервера)
Примечание: Топология описана ниже. Клиент перенаправляется на Server2 после первого запроса. Клиент -> Шлюз -> Маршрутизатор -> Сервер1 -> Сервер2
Я использовал wirehark как на стороне клиента, так и на стороне сервера. Сервер повторно отправляет кортеж SYN, ACK два раза, примерно через 10 секунд простоя, соединение, тем не менее, устанавливается. Если посмотреть на соответствующий RFC, это нормально (ACK отправляется клиентом косвенно при отправке данных). ACK никогда не достигает маршрутизатора, так где же он может быть потерян? И почему КАЖДЫЙ раз теряется? Может это какой-нибудь роутер (Микротик) настройка, например Нет-ACK? Отсутствует ACK причина задержки IDLE 10 секунд?
РЕДАКТИРОВАТЬ:
Я редактировал топологию выше. Вы найдете следы wirehark ниже:
Из-за процесса анонимизации в TraceWrangler IP-адреса меняются от трассировки к трассировке следующим образом:
Client IP: 192.168.248.249 <=> 172.23.147.181 <=> 192.168.201.209 <=> 10.206.108.221
Router IP: 10.194.30.227 <=> 172.17.84.111
Server1 IP: 172.31.124.208 <=> 10.100.24.4
Server2 IP: 172.20.78.56 <=> 192.168.204.149
Вы можете использовать следующие фильтры, чтобы получить четкое представление о начальном рукопожатии:
Filter Client: (((ip.dst ==192.168.248.249) && (ip.src ==10.194.30.227)) || ((ip.dst ==10.194.30.227) && (ip.src ==192.168.248.249))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)
Filter Router: (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)
Filter Server1: (((ip.dst ==172.31.124.208) && (ip.src ==192.168.201.209)) || ((ip.dst ==192.168.201.209) && (ip.src ==172.31.124.208)) || ((ip.dst ==172.31.124.208) && (ip.src ==172.20.78.56)) || ((ip.dst ==172.20.78.56) && (ip.src ==172.31.124.208))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)
Filter Server2: (((ip.dst ==10.100.24.4) && (ip.src ==10.206.108.221)) || ((ip.dst ==10.206.108.221) && (ip.src ==10.100.24.4)) || ((ip.dst ==10.100.24.4) && (ip.src ==192.168.204.149)) || ((ip.dst ==192.168.204.149) &&(ip.src ==10.100.24.4))) && (tcp.flags.syn==1 ) || (tcp.flags == 0x0010 && tcp.seq==1 && tcp.ack==1)
Вы не поверите, но проблема тем временем решена, я не очень понимаю, почему следующее изменение в RouterOS гарантирует, что ACK больше не теряется, а приложение загружается в спешке, но я действительно рад: в списках RouterOS Route IP-адрес шлюза был введен как IP-адрес вместо имени интерфейса / имени DNS.
У вас есть какое-нибудь объяснение этой проблемы? Перевод / поиск занимает столько секунд, а ACK тем временем игнорируется? У меня всегда было ощущение, что это проблема в RouterOS, но я понятия не имел, как ее отследить. Какое счастливое совпадение, что наш администратор играл со столами маршрутизатора и попросил меня снова проверить время загрузки. Неужели это единственное изменение? Я смог подтвердить в wirehark, что ACK больше не теряется.
РЕДАКТИРОВАТЬ:
Я экспортировал настройки IP-маршрута ниже, чтобы увидеть различия в маршруте:
Шлюз явно не определен в списке адресов, только маршрутизатор:
Итак, что происходит технически, и откуда берутся задержка и отсутствие ACK?