Боб Б. частенько становился свидетелем того, как падал сайт его компании. Никто даже отдаленно не представлял, почему это случалось, но зато каждый твердо знал, что надо делать. Просто перезапустить IIS вместе с SQL, и, вуаля, всего через минуту сервер снова был готов к труду и обороне.

Как и в случае старой и своенравной машины в компании беспокоились, что вмешательство в приложение только усугубит проблему. Но спустя несколько месяцев после нескольких жалоб от клиентов Бобу было дозволено выяснить, в чем дело, а без разрешения он соваться в приложение не хотел.

В ожидании краха
Первой проблемой, с которой пришлось бороться Бобу, стал самодельный модуль журналирования. Как только падало само приложение, модуль немедленно отправлялся вслед за ним, заставляя Боба довольствоваться журналом полным сообщений «произошла ошибка во время протоколирования ошибки». Через несколько недель и пару падений сервера Боб поправил журнальный код и установил его на рабочую систему.

Следующее падение сервера не заставило себя долго ждать. Боб с головой погрузился в журналы работы и увидел зловещую ошибку «Серверу не хватает памяти» о которой сообщал SQL сервер. Тщательное гугление выявило, что проблема должна разрешиться с установкой сервис пака. Поэтому пробив несколько твердых лбов разных начальников выпрашивая разрешение на обновление SQL сервера, Боб установил-таки сервис пак. Теперь оставалось только дождаться, когда себя проявит истинная проблема.

Несколько мучительных недель ожидания прошли без единого сбоя, и Боб уже было решил, что глюк вылечился сервис паком. Но сервер снова завалился с тем же сообщением что и раньше «Серверу не хватает памяти». Боб начал тщательно разбираться в причинах и выяснил, что серверу действительно не хватало памяти. Впрочем, на этот раз все оказалось яснее, на сервере было открыто около 2000000 активных сессий.

Для небольшого коммерческого веб сайта, на который заходило в среднем не более тысячи посетителей, 2 миллиона сессий выходили за все разумные рамки. Боб заподозрил, что сервер DoS-ят, но быстро отбросил эту версию. Никто бы просто не стал напрягаться, чтобы валить их сайт.

Хождение кругами
Боб начал просматривать журнальные записи IIS сделанные примерно во время отказа, но так и не нашел ничего интересного. Журнал выглядел вполне естественно. Поломав с полчаса глаза вглядываясь в записи журнала, Боб, наконец, зажал PageDown и погрузился в размышления. И тут он заметил множество запросов с одного и того же IP адреса. Отыскав заголовки запросов, он обнаружил, что IP адрес принадлежал пользователю AOL, который заходил на их сайт откуда-то из Огайо.

66.77.93.50 - [08:34:29] "GET /access?action= _
   _ forward&uri=%2Ferror.aspx HTTP/1.1" 302 - "-" "-" "-" 

66.77.93.50 - [08:34:29] "GET /error.aspx _
   _ HTTP/1.1" 302 - "-" "-" "-"

Кусочки головоломки начали соединяться воедино. Какой-то веб сёрфер из Огайо попадал в бесконечный цикл перенаправлений, который при каждой итерации создавал новую сессию. Видимо пользователь AOL был достаточно терпелив, чтобы наслаждаться этим действом почти 11 часов.

Отключив в своем браузере куки и набрав специально сформированный URL, Боб убедился в том, что он тоже может попасть в бесконечный цикл перенаправлений. Однако причина возникновения цикла все еще оставалась тайной.

Боб перемалывал журнал, пока не обнаружил первую запись от этого пользователя:

66.77.93.50 - [08:34:29] _
   _ "GET /favicon.ico HTTP/1.1" 302 - "-" "-" "-"

Она относилась к иконке избранного, маленькой иконке, которая появляется рядом с адресом страницы. Что было еще более странным, это был первый и единственный запрос из Огайо, не считая перенаправлений.

В конце концов, Боб выяснил, что именно приводило к сбою: один из посетителей добавил их сайт в избранное, пользуясь старой версией AOL. Он не пытался зайти на сайт, равно как и ждать 11 часов пока загрузится затребованная им страница. Просто он или она оставили браузер AOL открытым, он в свою очередь периодически пытался обновить иконки для занесенных в избранное сайтов, учтиво следуя бесконечным перенаправлениям.

Боб быстро добавил в корневой каталог favicon.ico и излечил синдром бесконечных переходов. Падения сервера исчезли навсегда и больше никогда не повторялись. Однако забавно, что какое-то время веб сайт компании был во власти сетевых привычек некоей семьи из Огайо.

Оригинал:http://thedailywtf.com/Articles/The-Most-Favoritest-Icon.aspx
Перевод:Евгений Виговский