Проще говоря, он умеет только HTTP/1.0 при общении с бакендом.
Неа, совсем никак. Ну не умеет он.
Может оно и так. Но я бы не утверждал сгоряча, что "нафиг оно не нада". Апачевский прокси умеет все это - HTTP/1.1 требует, чтобы умело. Наверное, в определенных условиях это будет существенно. Например, если тазики с бакендом и прокси - существенно разнесены в сети.
ТС, а сколько memory_limit стоит для PHP?
а почему mod_rewrite на апаче не поможет?
Ну, "как у ТС" - там все совсем просто. Пишем скриптом файл прямо в формате iptables-save/restore. Или просто - строчка awk переделает его исходный *.txt в то что нужно.
Но в общем, эта штука расчитана больше на ручную работу с правилами. Сдампил, поломал, залил, поимел проблему с доступом - откатили изменение.
Почему? Когда работают - особого эффекта от цепочек по сравнению с "плоскими" правилами - особо не заметно. Когда не работают - каши не просят. Имеем в любом случае профит в виде человеческого управления правилами.
Подгружается оно давно уже автоматом. Это откуда-то из "времен очаковских... aka ядро 2.4.x".
Еще полезно создавать отдельную цепочку логически объединенных правил
iptables -N ban-jul-12iptables -P ban-jul-12 ACCEPTiptables -I ban-jul-12 -m ... -j DROP
А дальше можно подключить все это дело в INPUT и открутить обратно одной командой, типа
iptables -I INPUT 123 ban-jul-12
PS: Полезно также помнить про man iptables-apply и LOG можно сразу заменять на DROP без особых опасений ;)
Дак может Вы просто попали под раздачу бана?
Вы хоть запихните себя в whitelist для приличия, тем более ежели баните сразу по пол-интернета :D
Не, не кривые. Просто не расчитанные на произвольный тип нагрузки, а телепатический модуль в nginx еще не встроили 🚬
веб-адрес (URL) "тормозящего" скрипта.
Если, как объяснено выше, натравить ab на URL, который отрабатывает быстро - получите 502 (баклог закончится в конце-концов). А вот если на медленно работающий URL - получите как раз 504 (сработают таймауты nginx). Попробуйте :)
Думаю, здесь дело в инерции. Необходимо обучить пользователей пользоваться соответствующими клиентами (например, под WebDAV)... А альтернативы есть FTP и для заливки файлов, и для раздачи...
Я например, делал видеохостинг с простой загрузкой файлов по HTTP (nginx модуль upload, etc). FTP там нафиг оказался не нужен.
Не в тех попугаях меряете. Надо - в процентном соотношении с другими проблемами клиентов.
Если бы Вы поработали немного в крупном хостинг-провайдере - мгновенно бы услышали о целой куче проблем, связанных с FTP. И в первую очередь - именно связанные с сетевыми экранами. Но не заканчивая этим. Далеко не все прозрачно с не-ascii кодировками для имен файлов обстоит. И т.п.
Собственно, "для заливки" есть WebDAV (расширение HTTP).
