Краткая версия: одна машина с Windows Server 2012 в моей сети получает постоянные, но прерывистые TCP RST при подключении к определенным веб-сайтам. Не знаю, откуда они. Ознакомьтесь с моим анализом и вопросами в журнале wirehark.
Длинная версия:
Мы запускаем кеширующий веб-прокси на одном из наших серверов для обслуживания небольшого офиса. Сотрудник сообщил, что при подключении к определенным сайтам он получал множество ошибок типа «Сброс подключения» или «Невозможно отобразить страницу», но это обновление обычно исправляет.
Я проверил поведение браузера, а затем напрямую, попробовав браузер без прокси на самом сервере. Но пинги и трассировки к проблемным сайтам не показывают никаких проблем, похоже, проблемы ограничиваются TCP-соединениями.
Затем я создал сценарий для тестирования затронутых сайтов, отправив им HTTP-запросы HEAD напрямую через cURL и проверив, как часто они работают. Типичный тест выглядит так: (это без проксирования, выполняется непосредственно на плохом сервере)
C:\sdk\Apache24\htdocs>php rhTest.php
Sending HTTP HEAD requests to "http://www.washingtonpost.com/":
20:21:42: Length: 0 Response Code: NULL (0%)
20:22:02: Length: 0 Response Code: NULL (0%)
20:22:22: Length: 0 Response Code: NULL (0%)
20:22:42: Length: 0 Response Code: NULL (0%)
20:23:02: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (20%)
20:23:22: Length: 3174 Response Code: HTTP/1.1 302 Moved Temporarily (33.33%)
20:23:43: Length: 0 Response Code: NULL (28.57%)
20:24:03: Length: 3171 Response Code: HTTP/1.1 302 Moved Temporarily (37.5%)
20:24:23: Length: 3173 Response Code: HTTP/1.1 302 Moved Temporarily (44.44%)
20:24:43: Length: 3172 Response Code: HTTP/1.1 302 Moved Temporarily (50%)
20:25:03: Length: 0 Response Code: NULL (45.45%)
В долгосрочной перспективе только около 60% запросов являются успешными, остальные ничего не возвращают, с кодом ошибки curl: «ошибка cURL (56): сбой при получении данных от однорангового узла». Плохое поведение соответствует веб-сайтам, которые я test (ни один сайт никогда не «становился лучше»), и он довольно постоянный, я занимаюсь устранением неполадок уже неделю, и коллеги сообщают, что проблема существует уже несколько месяцев.
Я протестировал сценарий запроса HEAD на других машинах в нашей сети: никаких проблем, все подключения проходят ко всем сайтам в моем тестовом списке. Затем я настраиваю прокси на своем личном рабочем столе, и когда я запускаю запросы HEAD от проблемного сервера, все соединения проходят. Итак, какая бы проблема ни была, она очень специфична для этого сервера.
Затем я попытался выделить, какие веб-сайты демонстрируют поведение сброса соединения:
Этот угол не превратился во что-то действительно полезное, поэтому затем я установил wirehark, чтобы посмотреть, что происходит, когда запрос не удался. Неудачные запросы HEAD выглядят так: (большой снимок экрана здесь: http://imgur.com/TNfRUtX )
127 48.709776000 192.168.1.142 192.33.31.56 TCP 66 52667 > http [SYN, ECN, CWR] Seq=0 Win=8192 Len=0 MSS=8960 WS=256 SACK_PERM=1
128 48.728207000 192.33.31.56 192.168.1.142 TCP 66 http > 52667 [SYN, ACK, ECN] Seq=0 Ack=1 Win=42340 Len=0 MSS=1460 SACK_PERM=1 WS=128
129 48.728255000 192.168.1.142 192.33.31.56 TCP 54 52667 > http [ACK] Seq=1 Ack=1 Win=65536 Len=0
130 48.739371000 192.168.1.142 192.33.31.56 HTTP 234 HEAD / HTTP/1.1
131 48.740917000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [RST] Seq=1 Win=0 Len=0
132 48.757766000 192.33.31.56 192.168.1.142 TCP 60 http > 52667 [ACK] Seq=1 Ack=181 Win=42240 Len=0
133 48.770314000 192.33.31.56 192.168.1.142 TCP 951 [TCP segment of a reassembled PDU]
134 48.807831000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
135 48.859592000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
138 49.400675000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
139 50.121655000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
141 51.564009000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
143 54.452561000 192.33.31.56 192.168.1.142 TCP 951 [TCP Retransmission] http > 52667 [PSH, ACK] Seq=1 Ack=181 Win=42240 Len=897
Я читаю это (поправьте меня, если я ошибаюсь, это не совсем моя область):
Итак, если веб-сервер отправил действительный RST, почему он продолжает попытки выполнить запрос? И если веб-сервер не генерировал RST, что, черт возьми, сделал?
То, что я пробовал, но безрезультатно:
Я кое-что подозреваю на сервере генерирует пакеты RST, но хоть убей, я не могу его найти. Мне кажется, если бы я знал: почему это только этот сервер? ИЛИ почему только некоторые сайты? это бы очень помогло. Хотя мне все еще любопытно, я все больше склоняюсь к ядерной бомбардировке с орбиты и начинать заново.
Идеи / предложения?
-Спасибо
В захвате вашего пакета было что-то необычное: в исходящем пакете SYN были установлены биты ECN.
Явное уведомление о перегрузке является расширением протокола IP, которое позволяет хостам быстрее реагировать на перегрузку сети. Впервые он был представлен в Интернете 15 лет назад, но серьезные проблемы отметил, когда он был впервые развернут. Самым серьезным из них было то, что многие брандмауэры либо отбрасывать пакеты, либо возвращать RST при получении пакета SYN с установленными битами ECN.
В результате большинство операционных систем отключили ECN по умолчанию, по крайней мере, для исходящих соединений. В результате я подозреваю, что многие сайты (и поставщики брандмауэров!) Просто никогда не исправили свои брандмауэры.
До выпуска Windows Server 2012. Microsoft включен ECN по умолчанию начиная с этой версии операционной системы.
К сожалению, в последнее время никто не проводил сколько-нибудь значительного тестирования реакции интернет-сайтов на ECN, поэтому трудно оценить, сохранились ли проблемы, наблюдавшиеся в начале 2000-х годов, но я сильно подозреваю, что они есть, и что ваш трафик, по крайней мере, некоторое время, проходя через такое оборудование.
После включения ECN на моем рабочем столе и последующего запуска Wireshark прошло всего несколько секунд, прежде чем я поймал пример хоста, с которого я получил RST для пакета с установленными SYN и ECN, хотя большинство хостов, похоже, работают нормально. Может, я сам поищу интернет ...
Вы можете попробовать отключить ECN на своем сервере, чтобы увидеть, исчезнет ли проблема. Это также лишит вас возможности использовать DCTCP, но в небольшом офисе маловероятно, что вы это сделаете или у вас возникнет такая необходимость.
netsh int tcp set global ecncapability=disabled