Увеличено количество таймаутов 408 запросов для нулевого значения на веб-сервере.

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

1) Очень низкий Apache TIMEOUT значение - ваш веб-сервер может завершить сеанс до того, как клиент даже получит возможность отправить запрос.

слишком много кодов ошибок 408 в журнале доступа

2) browser predictive optimization - вы можете легко протестировать это в разных браузерах. Просто делай tail -f /var/log/apache2/access.log, используя релевантные ключевые слова, которые приведут ваш сайт на первую страницу поиска, наведите указатель мыши на ссылку, указывающую на ваш сайт, проверьте, отображается ли предварительный просмотр сайта… все это, не нажимая на ссылку, которая открывает ваш сайт.

http://forum.linode.com/viewtopic.php?f=10&t=8048

3) denial of service attack - ддос греет типа slow loris может открыть слишком много подключений к серверу, не отправив ни единого прощания, связывающего все процессы Apache.

http://blog.spiderlabs.com/2011/07/advanced-topic-of-the-week-mitigating-slow-http-dos-attacks.html

Цитата из ссылки выше -

«Хитрость заключается в том, чтобы открыть соединение с сервером, но не отправить ни одного байта. Открытие соединения и ожидание почти не требует ресурсов со стороны злоумышленника, но постоянно заставляет один процесс Apache терпеливо ждать запроса. Apache будет ждать, пока время ожидания истекает, а затем закройте соединение. Начиная с Apache 1.3.31, время ожидания строки запроса регистрируется в журнале доступа (с кодом состояния 408). Сообщения о времени ожидания строки запроса появляются в журнале ошибок с информацией об уровне. Apache 2 не записывает такие сообщения в журнал ошибок, но предпринимаются попытки добавить те же функции, что и в ветви 1.x. "

Большинство ответов сервера кода 408, похоже, связаны с тайм-аутом клиента, а не с ожиданием. Я исключаю отказ в обслуживании в упомянутых случаях, моих серверах и упомянутых рецензиях, потому что количество совпадений невелико. Я пробовал, но не смог воспроизвести какие-либо ошибки 408 через предварительные просмотры в Safari, Chrome или Firefox под OS X. Я также не вижу их в большинстве месяцев на локальном (непубличном) сервере, чего я ожидал бы, если бы они были нормальным поведением браузера. Это могут быть браузеры, которые смотрят вперед, открывая соединения и никогда не используя их для запроса, но я не вижу такого поведения, достаточного для того, чтобы учесть количество 408 на этих общедоступных серверах. Хотя открытие соединения с пустым запросом действительно запускает соединение, имеет смысл заглянуть вперед, чтобы захватить ресурс или использовать ОПЦИИ (которые я также вижу только в редких ситуациях с перекрестными сайтами и пауками).

Я выполнил поиск хоста DNS в списке из 47 IP-адресов, получивших 408 ответов без идентифицированного ресурса, агента или размера запроса в журнале с малоиспользуемого общедоступного сервера. Я проигнорировал дополнительные 67 IP-адресов, которые различались только последним кортежем, и представил их первым в каждом наборе. Итак, это 47 различных клиентских сетей / интернет-провайдеров. Время ожидания Apache по умолчанию составляет 60 секунд. Из 47 произведенных машин 20 наименований. Из этих машин 10 (50%) находились в материковом Китае, 5 - в США (25% и все OH, OK и NH) и 5 ​​- между Бразилией, Великобританией, Италией и Тайванем (ROC). Я также подозреваю, что значительная часть из 27 IP-адресов, которые не привели к названию машины, также находятся в Китае, но не могут этого показать.

Из 67 IP-адресов, проигнорированных, поскольку их блок уже был представлен, 63 были пауками Baidu: baiduspider - *. Crawl.baidu.com (если это кажется чрезмерным, имейте в виду, что теперь он больше, чем Yahoo или Bing по количеству поисковых запросов в месяц - Второй только в Google).

Если бы они были вызваны поведением современного браузера, я бы ожидал, что в США их будет больше. Сервер, на который я вошел, находится в районе залива. Вместо этого я думаю, что это в первую очередь перегрузка сети, из-за которой установка соединений занимает слишком много времени и позволяет отправлять и получать полный запрос до того, как соединение будет разорвано или истечет время ожидания Apache. В частности, чрезмерная загруженность из-за роста спроса, неадекватной трансграничной пропускной способности и национальной инфраструктуры межсетевого экрана в Китае. Это также может быть преднамеренный сброс поддельного соединения, но для этого нет никаких оснований ожидать этого. Остальные - домашние пользователи с плохим подключением или неудачным оборудованием в другом месте.

Я думаю, что проблема в первую очередь связана с подключением на стороне клиента, но вы можете захотеть получить согласительную и не графическую страницу с ошибкой 408. Хотя, судя по размеру 0, указанному в журнале исходящего ответа, Apache не использует страницу с ошибкой.

В моем случае Apache был перегружен. Ответ был выключить KeepAlive и увеличьте MaxClients в apache.conf.

У меня возникла эта проблема, когда я изменил конфигурацию Apache для своего сервера FastCGI.

Увеличение -idle-timeout значение от 60 до 900 дало мне несколько бессонных ночей, поскольку я не мог отследить 408 ошибок до этого небольшого изменения.

Рад, что наконец исправил это, вернув это значение на 60.