Апач это: что это такое и как работает

apache | Community Creatio

С чего начинается интернет. Конечно же Apache, наверное это единственный «живой» веб-сервер, который появился на заре развития интернета, и который продолжает жить и здравствовать. Ну, собственно, это была полемика, а мы перейдем к практике.

Итак, обзаводимся инструментами

1. Собственно, сам сервер Apache. Идем на сайт http://httpd.apache.org/download.cgi. Поддерживаемые версии на сегодня это 2.0.X и 2.2.X (да-да, 2.2 ветка уже тоже поддерживается). Внимание!!!: хотим SSL? Конечно. И не забываем, что нам надо взять соответствующий установочный пакет «Win32 Binary including OpenSSL 0.9.8m (MSI Installer)».
2. Ваш любимый блокнот, где придется немного подредактировать конфигурационные файлы Apache.
3. Хотим SSL? Конечно же, безопасность превыше всего. Тогда идем на http://www.slproweb.com/products/Win32OpenSSL.html (официальный сайт библиотек OpenSSL для Windows). И скачиваем оттуда версию «Win32 OpenSSL v1. 0.0a Light» (для тех, кто в 64-битном танке, там есть версия «Win64 OpenSSL v1.0.0a Light»). И не в коем случае не берите полную версию — она абсолютно не нужна.
   Да, чуть не забыл. Вы абсолютно не должны смущаться, по поводу разных версий OpenSSL в установочном пакете Apache и в поставке Win32 OpenSSL Light.
4. Ну и естественно, нужен пациент. То есть Terrasoft версии 3.3.2, веб-сервисы которого мы и будем подключать к Apache 2.X.X.

Краткое отступление. Когда писалась данная заметка, я тестировал все нижеописанное в следующей конфигурации: Windows Server 2008 32-bit, Apache 2.2.15 32-bit with SSL, IIS 7.0 (по умолчанию, я установил все расширения), Terrasoft XRM 3.3.2.107. Соответственно, все мои изыскания были проведены для данных версий. Но, скажу честно и откровенно, должны заработать и в других комбинациях.

Установка Apache.

Все до ужаса просто. Кликаем всегда далее и вот у нас стоит Apache, и он даже запустился. Так, только прежде чем ставить Apache, давайте посмотрим вокруг себя и попытаемся найти того, кто (или что) нам обязательно будет мешать. Вот некоторые кандидаты, замеченные Вашим покорным слугой.

Кандидат №1 — это конечно же уже установленный и запущенный Apache (другой версии). Если он Вам нужен — Вы и так уже знаете как его ставить, а если не нужен — удаляйте , удаляйте — мы же все равно ставим новый.

Кандидат №2 — это IIS. А-я-я-й. Мы же Apache ставим — зачем нам IIS. Поэтому необходимо удалить IIS с компьютера, чтобы он Вам не мешал и «не портил всю картину».
Как его удалять — ну это уже задание на дом — для изучения всяких-таких руководств от Microsoft.

Кандидат №3 — Skype. Ага, а что ему делать на сервере? Ну если он все-таки там нашелся, необходимо в его настройках отключить использование 80 и 443 портов (а он, редиска, использует их по умолчанию — зачем, это уже другая песня).

Итак, смотрим на скриншоты и вперед. В основном, установка идет со значениями по умолчанию.
Шаг №1

Шаг №2

Шаг №3

Шаг №4. Обратите внимание на значение в поле ServerName. Если Вы не будете использовать виртуальный хостинг, то здесь должно быть прописан полный адрес вашего сервера.
Также, по умолчанию, ставим Apache как службу системы с автоматическим запуском и прослушиванием порта 80.

Шаг №5

Шаг №6

Шаг №7

Проверить работоспособность можно, если перейти по адресу http://127.0.0.1/ или по адресу http://<имя_Вашего_сервера>/. Если Вы увидите след. картинку, то можно считать, что Apache установлен, запущен и работает нормально.

Установка Terrasoft XRM

Здесь я даже останавливаться не буду. Это итак разложено по полочкам в «Руководстве администратора». Единственный момент (а оказывается многие забывают) — это надо настроить путь к папке Settings в файле RunSettings.xml
К примеру, после установки Terrasoft XRM со значениями по умолчанию, путь к папке Settings будет C:\Program Files\Terrasoft\Settings\.

После этого, необходимо запустить TSClient.exe и настроить подключение к конфигурации.

Настройка Web-сервисов под Apache

Итак, Apache есть, Terrasoft XRM установлен. Самое время подключить web-сервисы. Открываем в любимом редакторе файл httpd.conf, который находиться в папке conf корневой папки установки Apache (если ставили по умолчанию, то это будет C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.conf) и в конец файла добавляем следующие строки (для Apache 2.2.x)

LoadModule tsapache_module \
     «С:\Program Files\Terrasoft\Bin\TSWebServicesServerLibraryApache22.dll»
/TSWebServices>
        SetHandler TSWebServicesServerLibraryApache22-handler
>

Для Apache 2.0.x, строки будут следующие

LoadModule tsapache_module \
     «С:\Program Files\Terrasoft\Bin\TSWebServicesServerLibraryApache20.dll»
/TSWebServices>
        SetHandler TSWebServicesServerLibraryApache20-handler
>

Название виртуальной директории (в данном примере TSWebServices) Вы можете придумать самостоятельно так, как Вам нравится.

Чтобы изменения вступили в силу, необходимо произвести перезапуск Apache сервера. Если по быстрому, то в трее у Вас должен быть значок Apache Monitor , кликнув по которому откроется окно программы, в котором можно сделать перезапуск (остановку/запуск) сервера Apache. Если перезапуск прошел успешно, значит модуль веб-сервисов загрузился успешно. Можно проверить работоспособность, если перейти по адресу http://127.0.0.1/TSWebServices/ (где вместо 127.0.0.1 может быть записан полный адрес сервера, а TSWebServices — это название виртуальной папки, которое Вы указали в httpd.conf). Вы должны увидеть следующую картинку

Увидели — вуаля. Web-сервисы под Apache запущенны и работают. Далее необходимо настроить клиент Terrasoft, но останавливаться на этом не буду, так как в руководстве данный материал полностью раскрыт и освещен.

Настройка SSL.

Вот собственно мы и добрались до самого главного. То есть до безучастности. Конечно, многие могут возразить, зачем, мол, веб-сервисы да еще и через SSL — не проще ли поднять VPN или заходить на удаленный рабочий стол.
Да, неверное многие так и делают, но дискуссии на тему что лучше мы оставим другим, а сейчас просто займемся настройкой SSL под Apache.

Но сначала немного теории. Итак, для того чтобы обзавестись защищенным каналом, необходимо наличие сертификатов. А здесь начинаются сплошные непонятные слова и действия. (Да, можно и бубен прикупить, с надписями SSL). Но мы сейчас быстро разложим все по полочкам.

Собственно, сертификат — это заверенный удостоверяющим центром электронный (или печатный, что очень редко) документ, подтверждающий принадлежность владельцу открытого ключа или каких-либо атрибутов. А теперь, чтобы не надо было ломать мозги, представим себе, что сертификат — это какой либо документ (например копия Вашего паспорта) содержащий Ваши данные и это все заверено государственным нотариусом. Ведь ни у кого не будет сомнений, что это копия действительно Вашего паспорта, а не дяди Васи со стороны. То есть, удостоверяющий центр — это такая организация, которой все доверяют. Довольно известные компании Thawte, VeriSign очень давно работают в этом сегменте, что позволяет им довольно интенсивно влиять на многие аспекты сертификации в целом.

Для нас же с Вами, сертификат — это некий файл в формате X.509 (может быть текстовым, а может и не быть :-)) который содержит информацию про Вас, и информацию про того, кто сертификат «заверил». Понятие «заверил» не зря взято в кавычки — это значит что в Вашем сертификате стоит электронная цифровая подпись той компании, которая подтвердила правдивость Ваших данных. Собственно, как мокрая печать нотариуса на документах.

Также существуют корневые сертификаты (CA). Корневой сертификат — это сертификат, который заверен сам собой. Напрашивается вопрос — зачем сертификат который заверен своей же организацией. А вот ответ на самом деле очень простой. Если каждый сертификат должен быть кем-то заверен (далее по тексу буду использовать выражение «подписан», так как в мире сертификатов оно больее полно раскрывает смысл), то где-то должно быть начало этой цепочки. Так вот, начало этой цепочки — это и есть корневой сертификат.

Кроме всего этого, существуют публичные списки корневых сертификатов. Это списки тех сертификатов, которые либо включены в операционную систему либо встроенны в приложение (например, браузер Mozilla Firefox). Используя эти публичные сертификаты (CA) приложение может проверить «на действительность и правильность» любой сертификат. В случае с браузерами — мы видим «позеленевшую» адресную строку, когда заходим на любой сайт HTTPS.

Итак, было немного теории, теперь перейдем к практике.

Для начала подготовим инструменты — это минимальный набор файлов: openssl.exe, libeay32.dll, ssleay32.dll и главное — openssl.cfg. Можно забрать архивом прикрепленных файлах. Распаковываем. Конечно, туда, куда Вам больше нравится.

Теперь вкратце о том, что необходимо сделать. Так как мы будем генерировать (создавать) все сами — (денег нет, не дают, нет необходимости покупать у гигантов CA) — то нам необходимо будет сгенерировать два сертификата. Первый — это RootCA — то есть наш корневой сертификат, который мы сами же и подпишем. Второй — это сертификат сервера, на котором будут работать вебсервер.

Чтобы долго не расписывать что, как и почем, в архиве есть файл gen.cmd (для любознательных — можете заглянуть внутрь). Запускаем и идем по шагам.

Итак, какие данные у вас спросит скрипт.

Код страны — двухбуквенное обозначение, вводить необходимо в верхнем регистре.

Название компании. Обязательно латиницей. На данный момент пробелы в названии не поддерживаются (хотя для любопытных — можете попробовать).

Название сервера — это должно быть полное FQDN имя домена, для которого будет сгенерирован сертификат. Обычно — это полное название компютера, на котором установлен Apache2 (или IIS). Если это не так — ну тогда Вам прямая дорога к вашему системному администратору (если это не Вы) — он должен быть в курсе.

Введенные данные будут записаны в файл info.txt.

Пароли — первый для приватного ключа от CA, второй — для приватного ключа сервера. Минимум — 4 символа. (Сохранены будут с файлах с расширением .pwd)

После этого будут сгенерированны ключи и сертификаты. При создании экспортных версий (для MS) — будут запрошены пароли экспорта — эти пароли будут запрошены при импорте сертификатов в MS.

Да, если у Вас что-то пошло не так, там есть простенький файл clean.cmd — который удалит все сгенерированные и промежуточные данные. (Внимание, приватные ключи тоже будут удалены).

Продолжение следует…

Что такое апач?

Что такое веб-сервер?

Зачем использовать веб-сервер Apache?

Преимущества Apache

Недостатки Apache

Вывод

Веб-сервер Apache – один из самых популярных серверов HTTP, который поддерживает PHP и Perl. Это популярное программное обеспечение разработано и поддерживается Apache Software в США. Многие серверы по всему миру управляются веб-сервером Apache. Причина этого – скорость и безопасность, которые обеспечивает эта компания.

Апачи – это название индейского племени. Это племя было известно своей храбростью и умением вести войну. Это имя было выбрано в 1995 году для первой версии этого веб-сервера. В этой статье мы должны объяснить, что такое apache и почему он используется?

Причина этого – скорость и безопасность, которые обеспечивает эта компания. Апачи – это название индейского племени. Это племя было известно своей храбростью и умением вести войну. Это имя было выбрано в 1995 году для первой версии этого веб-сервера. В этой статье мы должны объяснить, что такое apache и почему он используется?

В 1996 году Apache был хорошо известен во всем мире и быстро стал популярным. Благодаря функции открытого исходного кода он поддерживает многие современные технологии, такие как SSL и CGL. Apache поддерживает Linux, Windows и т.д.

Кроме того, вы можете использовать макросы и дополнения для улучшения, разработки и настройки этого программного обеспечения. Они дали Apache прозвище «LAMP» за поддержку 4 наиболее часто используемых систем Linux, Apache, MySQL и PHP / Perl.

Можно с уверенностью сказать, что Apache поддерживает все системы, используемые в современном мире. Согласно статистике Netcraft.com, около 60% веб-сайтов во всем мире используют Apache.

В нашей предыдущей статье мы обсуждали, как установить WordPress на localhost.

Что такое веб-сервер?

Веб-сервер – это система / программное обеспечение, которое отвечает на запросы браузеров. Он получает запросы, а затем отправляет пользователям желаемую запрошенную страницу. Веб-сервер – это программное обеспечение, которое использует протокол HTTP для отправки файлов с физического сервера в браузер пользователя, и без него пользователь не может открывать никакие страницы. Проще говоря, веб-сервер называется программой, которая открывает запрошенные веб-страницы.

Веб-сервер может отображать компонент пути полученного URL-адреса. Он либо отобразит его на статический, либо на динамический URL, а затем отобразит результаты пользователю. Если по какой-либо причине веб-сервер не отвечает, в вашем браузере отобразится ошибка.

Зачем использовать веб-сервер Apache?

В настоящее время существует множество веб-серверов, которыми пользуются пользователи по всему миру. Самые популярные из них – Apache, IIS, LiteSpeed, LightTPD и Nginx. Apache является самым популярным по нескольким простым причинам:

1. Apache бесплатен как для личного, так и для коммерческого использования.
2. Это программное обеспечение заслуживает доверия и предлагает отличную безопасность. Кроме того, Apache имеет открытый исходный код и позволяет пользователям просматривать коды и изменять их в соответствии со своими потребностями.
3. Веб-серверы Apache могут использоваться для любых веб-сайтов (от веб-сайтов с несколькими страницами до веб-сайтов с тысячами страниц).
4. Чаще всего Apache используется .htaccess, который используют многие эксперты по Linux. Программисты могут редактировать .htaccess, чтобы добавлять свои собственные функции.

Преимущества Apache

Как упоминалось выше, Apache используется уже 25 лет, и его популярность продолжает расти, и другие веб-серверы не могут конкурировать с ним. У веб-сервера Apache много преимуществ. Мы упомянем некоторые ниже:

• Поскольку это открытый исходный код, вам необходимо разрешение на просмотр кодов.
• Вы можете редактировать код.
• Вы можете добавлять в него макросы и дополнения. Эта функция сделала Apache популярным в сообществе программистов.
• Веб-сервер Apache заслуживает доверия.
• Вы можете сохранить любые внесенные изменения, не перезагружая его.
• Apache поддерживает две известные в мире операционные системы: Linux и Windows.
• Обновляется регулярно.
• Легко установить.
• Гибкий.
• Вы можете разместить несколько веб-сайтов одновременно.
• Простая конструкция.
• Поддерживает многие CMS, такие как WordPress и Joomla.
• Рекомендуется новичкам.
• Документы и руководства Apache регулярно обновляются.
• Apache не имеет статических или динамических проблем и может управлять тысячами веб-сайтов.
• Apache – самый старый веб-сервер в мире, и его сообщество активно поддерживает.
• Высокоскоростной

Недостатки Apache

У Apache может быть много преимуществ, но есть и недостатки. Важные недостатки:

• Как упоминалось выше, Apache – это открытый исходный код. Таким образом, неправильное изменение кодов может вызвать серьезные проблемы с безопасностью.
• Когда мы создаем новые протоколы в Apache, в коде могут появиться ошибки, и для их устранения вам придется нанять отладчик.
• Этот веб-сервер нуждается в постоянных обновлениях.
• На сайтах с большим количеством посетителей могут возникать проблемы.
• Веб-сервер Apache основан на процессах. Это означает, что соединения требуют отдельных потоков, что может быть дорогостоящим.

Вывод

В исследовании, проведенном в 2014 году, статистика наиболее часто используемых и популярных веб-серверов выглядит следующим образом:

1. Apache: 60,6%
2. NGINX: 20,6%
3. США: 13,9%
4. LiteSpeed: 2,0%

Хотя эти цифры могли измениться за 5 лет, существует твердое мнение, что благодаря преимуществам Apache, он по-прежнему является наиболее часто используемым веб-сервером.

Apache позволяет размещать веб-сайты, не беспокоясь о рисках безопасности. Этот веб-сервер подходит для веб-сайтов малого и среднего размера. Apache имеет хорошие отношения между различными CMS, такими как Joomla, Drupal, Weebly и WordPress, поэтому многие пользователи WordPress полагаются на Apache.

Источник записи: https://betterstudio.com

Apache vs Nginx — База знаний cPanel хостинг

Apache и Nginx — 2 самых широко распространенных веб-сервера с открытым исходным кодом в мире. Вместе они обслуживают более 50% трафика во всем интернете. Оба решения способны работать с разнообразными рабочими нагрузками и взаимодействовать с другими приложениями для реализации полного веб-стека.

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

Общий обзор

Прежде чем погрузиться в различия между Apache и Nginx давайте бегло взглянем на предысторию каждого из этих проектов.

Apache

Apache HTTP Server был разработан Робертом Маккулом в 1995 году, а с 1999 года разрабатывается под управлением Apache Software Foundation — фонда развития программного обеспечения Apache. Так как HTTP сервер это первый и самый популярный проект фонда его обычно называют просто Apache.

Веб-север Apache был самым популярным веб-сервером в интернете с 1996 года. Благодаря его популярности у Apache сильная документация и интеграция со сторонним софтом.

Администраторы часто выбирают Apache из-за его гибкости, мощности и широкой распространенности. Он может быть расширен с помощью системы динамически загружаемых модулей и исполнять программы на большом количестве интерпретируемых языков программирования без использования внешнего программного обеспечения.

Nginx

В 2002 году Игорь Сысоев начал работу над Nginx для того чтобы решить проблему C10K — требование к ПО работать с 10 тысячами одновременных соединений.

Первый публичный релиз был выпущен в 2004 году, поставленная цель была достигнута благодаря асинхронной event-driven архитектуре.

Nginx начал набирать популярность с момента релиза благодаря своей легковесности (light-weight resource utilization) и возможности легко масштабироваться на минимальном железе. Nginx превосходен при отдаче статического контента и спроектирован так, чтобы передавать динамические запросы другому ПО предназначенному для их обработки.

Администраторы часто выбирают Nginx из-за его эффективного потребления ресурсов и отзывчивости под нагрузкой, а также из-за возможности использовать его и как веб-сервер, и как прокси.

Архитектура обработки соединений

Одно из самых существенных отличий между Apache и Nginx состоит в том как они обрабатывают соединения и отвечают на различные виды трафика.

Apache предоставляет несколько модулей мультипроцессинга (multi-processing modules, MPM), которые отвечают за то как запрос клиента будет обработан. Это позволет администраторам определять политику обработки соединений. Ниже представлен список MPM-модулей Apache:

• mpm_prefork — этот модуль создает по одному процессу с одним потоком на каждый запрос. Каждый процесс может обрабатывать только одно соединение в один момент времени. Пока число запросов меньше числа процессов этот MPM работает очень быстро. Однако производительность быстро падает когда число запросов начинает превосходить число процессов, поэтому в большинстве случаев это не самый лучший выбор. Каждый процесс потребляет значительный объем RAM, поэтому этот MPM сложно поддается масштабированию. Но он может быть использован вместе с компонентами, которые не созданы для работы в многопоточной среде. Например, PHP не является потокобезопасным, поэтому этот MPM рекомендуется использовать как безопасный метод работы с mod_php.
• mpm_worker — этот модуль создает процессы, каждый из которых может управлять несколькими потоками. Каждый поток может обрабтывать одно соединение. Потоки значительно более эффективны чем процессы, что означает что mpm_worker масштабируется значительно лучше чем mpm_prefork. Так как потоков больше чем процессов это означает, что новое соединение может быть сразу обработано свободным потоком, а не ждать пока освободится процесс.
• mpm_event — этот модуль похож на mpm_worker, но оптимизрован под работу с keep-alive соединениями. Когда используется mpm_worker соединение будет удерживать поток вне зависимости от того активное это соединение или keep-alive. Mpm_event выделяет отдельные потоки для keep-alive соединений и отдельные потоки для активных соединений. Это позволяет модулю не погрязнуть в keep-alive соединениях, что необходимо для быстрой работы. Этот модуль был отмечен как стабильный в Apache версии 2.4.

Как вы можете видеть Apache предлагает гибкие возможности для выбора различных алгоритмов обработки соединений и запросов.

Nginx

Nginx появился на сцене позднее Apache, по этой причине, его разработчик был лучше осведомлен о проблемах конкурентности, с которыми сталкиваются сайты при масштабировании. Благодаря этим знаниям Nginx изначально был спроектирован на базе асинхронных неблокирующих event-driven алгоритмов.

Nginx создает процессы-воркеры каждый из которых может обслуживать тысячи соединений. Воркеры достигают такого результата благодаря механизму основанному на быстром цикле, в котором проверяются и обрабатываются события. Отделение основной работы от обработки соединений позволяет каждому воркеру заниматься своей работой и отвлекаться на обработку соединений только тогда когда произошло новое событие.

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

Этот подход к обработке соединений позволяет Nginx’у невероятно масштабироваться при ограниченных ресурсах. Поскольку сервер однопоточный и он не создает процессы под каждое соединение, использование памяти и CPU относительно равномерно, даже при высоких нагрузках.

Статический и динамический контент

Если рассматривать жизненные примеры, то основные различия между Apache и Nginx в том как они обрабатывают запросы к статическому и динамическому контенту.

Apache

Apache может раздавать статический контент используя стандартные file-based методы. Производительность таких операций зависит от выбранного MPM.

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

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

Nginx

Nginx не имеет возможности самостоятельно обрабатывать запросы к динамическому контенту. Для обработки запросов к PHP или другому динамическому контенту Nginx должен передать запрос внешнему процессору для исполнения, подождать пока ответ будет сгенерирован и получить его. Затем результат может быть отправлен клиенту.

Для администраторов это означает, что нужно настроить взаимодействие Nginx с таким процессором используя один из протоколов, который известен Nginx’у (http, FastCGI, SCGI, uWSGI, memcache). Это может немного усложнить процесс настройки, в особенности когда вы будете пытаться предугадать какое число соединений разрешить, так как будет использоваться дополнительное соединение с процессором на каждый пользовательский запрос.

Однако, этот метод имеет и свои преимущества. Так как интерпретатор не встроен в каждого воркера, то оверхед, связанный с этим, будет иметь место только при запросах к динамическому контенту. Статический контент будет возвращен клиенту простым способом и запросы к интерпретатору будут выполняться только тогда когда они нужны. Apache тоже может работать в такой манере, но тогда это лишит его всех преимуществ описанных в предыдущем разделе.

Распределенная конфигурация против централизованной

Для администраторов одним из очевидных отличий этих двух веб-серверов является наличие у Apache возможности задавать конфигурацию на уровне директории.

Apache

Apache имеет опцию, которая позволяет включить конфигурирование на уровне директорий. Если эта опция включена, то Apache будет искать конфигурационные директивы в директориях с контентом в специальных скрытых файлах, которые называются .htaccess.

Так как такие конфигурационные файлы находятся в директриях с контентом, Apache вынужден при обработке каждого запроса проверять не содержит ли каждый компонент запрашиваемого пути файл .htaccess и исполнять директивы в найденных файлах. Это позволяет децентрализовать конфигурирование веб-сервера, что позволяет реализовать на уровне директорий модификацию URL’ов (URL rewrite), ограничения доступа, авторизацию и аутентификацию и даже политики кеширования.

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

Это дает простой способ таким приложениям как системы управления контентом (CMS) конфигурировать собственное окружение не имея доступа к конфигурационному файлу веб-сервера. Это также может быть использовано шаред хостингами, чтобы сохранить контроль над основным конфигурационным файлом и дать клиентам контроль над конфигурацией определенных директорий.

Nginx

Nginx не интерпретирует файлы .htaccess и не предоставляет механизм конфигурирования на уровне директорий за пределами основного конфигурационного файла. Этот подход может показаться менее гибким чем в случае с Apache, но он имеет свои преимущства.

Основное преимущество перед использованием . htaccess — это улучшенная производительность. Типичная установка Apache позволяет использовать файлы .htaccess в любой директории, поэтому веб-сервер при каждом запросе вынужден проверять наличие этого файла во всех родительских директориях запрошенного файла. Если найден один или более таких файлов, то все они должны быть прочитаны и интерпретированы.

Так как Nginx не позволяет переопределять конфиги на уровне директорий, он может обрабатывать запросы быстрее, ведь ему достаточно сделать один directory lookup и прочитать один конфигурационный файл на каждый запрос (предполагается, что файл найден там где он должен быть по соглашению).

Второе преимущество связано с безопасностью. Распределенная конфигурация на уровне директорий в Apache возлагает ответственность за безопасность на обычных пользователей, которые вряд ли способны решить эту задачу качественно. То что администратор контролирует весь сервер предотвращает ошибки безопасности, которые могут возникнуть если дать пользователям доступ к конфигурации.

Имейте ввиду, что вы можете отключить поддержку .htaccess в Apache, если сказанное выше произвело на вас впечатление.

Интерпретация базирующаяся на файлах и URI

То как веб-сервер интерпретирует запрос и сопоставляет его с ресурсом в системе это еще одна отличительная особенность в этих двух серверах.

Apache

Apache имеет возможность интерпретировать запрос как физический ресурс в файловой системе или как URI, который требует дополнительной обработки. Первый тип запросов использует конфигурационные блоки или , второй — блоки .

Так как Apache изначально был спроектирован как веб-сервер, он по умолчанию интерпретирует запросы как ресурсы в файловой системе. Он берет document root веб-сервера и дополняет его частью запроса, которая следует за именем хоста и номером порта, чтобы найти запрашиваемый файл. В общем случае, иерархия файловой системы представленная в вебе доступна как дерево документов.

Apache предоставляет ряд альтернатив на случай когда запрос не соответствует файлу в файловой системе. Использование блоков это метод работы с URI без отображения на файловую систему. Также возможно использовать регулярные выражения, которые позволяют задать более гибкие настройки для всей файловой системы.

Так как Apache может оперировать и c файловой системой, и с webspace, то он в основном опирается на методы работы с файловой системой. Это видно в некоторых решениях в дизайне архитектуры веб-сервера, например, в использовании файлов .htaccess для конфигурирования на уровне директорий. Документация к Apache не рекомендует использовать URI-блоки для ограничения доступа для запросов к файловой системе.

Nginx

Nginx создан, чтобы работать и в качестве веб-сервера, и в качестве прокси-сервера. По этой причине он работает в первую очередь с URI, транслируя их при необходимости в запросы к файловой системе.

Эта особенность прослеживается в том как для Nginx конструируются и интерпретируются конфигурационные файлы. В Nginx нет способа создать конфигурацию для заданной директории, вместо этого он парсит URI.
Например, основными конфигурационными блоками в Nginx являются и . В блоке определяется хост, который будет обслуживаться, блок отвечает за обработку части URI, которая идет после имени хоста и номера порта. Таким образом, запрос интерпретируется как URI, а не как путь в файловой системе.

В случае запросов к статическим файлам все запросы должны быть отображены (mapped) на путь в файловой системе. Сначала Nginx выбирает блоки server и location, которые будут использованы для обработки запроса и затем объединяет document root с URI, в соответствии с конфигурацией.

Эти подходы (интерпретация запроса как пути в файловой системе и как URI) могут показаться похожими, но тот факт что Nginx рассматривает запросы как URI, а не как пути в файловой системе позволяет ему легче справляться одновременно и с ролью веб-сервера, и с ролью прокси. Nginx конфигурируется так, чтобы отвечать на различные шаблоны запросов. Nginx не обращается к файловой системе до тех пор пока он не готов обслужить запрос, что объясняет почему он не реализует ничего похожего на файлы . htaccess.

Модули

И Apache, и Nginx могут быть расширены при помощи системы модулей, но способы реализации модульной системы принципиально отличаются.

Apache

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

Apache использует эту функциональность для решения широкого круга задач. Благодаря зрелости платформы существует огромное множество модулей, которые могут изменять ключевые особенности сервера, например модуль mod_php позволяет включать PHP-интерпретатор в кажого воркера.

Использование модулей не ограничивается лишь обработкой динамических запросов. Среди других возможностей модулей: изменение URL’ов (URL rewrite), аутентификация клиентов, защита сервера, логгирование, кеширование, сжатие, проксирование, ограничение частоты запросов, шифрование. Динамические модули могут значительно расширить функцональность ядра.

Nginx

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

Для многих пользователей по этой причине Nginx кажется менее гибким. Это особенно относится к пользователям, кто имеет мало опыта ручной сборки приложений и предпочитают использовать системы управления пакетами. Обычно разработчики дистрибутивов стремятся создать пакеты для всех часто используемых модулей, но если вам нужен какой-то нестандартный модуль вам придется собрать его из исходников самостоятельно.

Тем не менее, модули в Nginx очень полезны и востребованы, вы можете определить чего вы хотите от сервера и включить только те модули, что вам нужны. Некоторые пользователи считают такой подход более безопасным так как произвольные модули не могут быть подключены к серверу.

Модули Nginx реализуют те же возможности, что и модули Apache: проксирование, сжатие данных, ограничение частоты запросов, логгирование, модификация URL’ов, гео-локация, аутентификация, шифрование, потоковое вещание, почтовые функции.

Поддержка, совместимость, экосистема и документация

В процессе использования приложения важными являются экосистема созданная вокруг него и возможность получения поддержки.

Apache

Так как Apache пользуется популярностью такое длительное время с поддержкой у него нет проблем. Легко можно найти большое количество документации как от разработчиков Apache, так и от сторонних авторов. Эта документация покрывает все возможные сценарии использования Apache, включая взаимодействие с другими приложениями.

Существует много инструментов и веб-проектов идущих в комплекте со средствами запуска самих себя из под Apache. Это относится как к самим проектам, так и к системам управления пакетами.

В общем случае Apache будет иметь больше поддержки в сторонних проектах просто потому он доступен на рынке длительное время. Администраторы также обычно имеют больше опыта работы с Apache, так как большинство людей начинают работу с шаред-хостингов где Apache более популярен из-за поддержки файлов . htaccess.

Nginx

Nginx обычно используется там, где предъявляются повышенные требования к производительности и в некоторых областях он все еще является догоняющим.

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

Разработчики стороннего ПО также начинают поддерживать работу с Nginx и некоторые из них уже предлагают на выбор пользователя конфиги для работы или с Apache, или с Nginx. И даже без поддержки приложением работы с Nginx не составляет большого труда написать свой конфиг для интеграции приложения с Nginx.

Совместное использование Apache и Nginx

После того как вы ознакомились с плюсами и минусами Apache и Nginx у вас должно появиться представление того, какой из серверов больше подходит под ваши задачи. Однако, можно достигнуть лучших результатов используя оба сервера вместе.

Распространенной схемой использования является размещение Nginx перед Apache в качестве реверс-прокси. В такой конфигурации Nginx называют фронтендом, а Apache — бэкендом. При таком подходе Nginx будет обслуживать все входящие запросы клиентов и мы получим выигрыш из-за его возможности обрабатывать множество конкурентных запросов.

Nginx будет самостоятельно обслуживать статический контент, а для динамического контента, например для запросов к PHP-страницам, будет передавать запрос к Apache, который будет рендерить страницу, возвращать ее Nginx’у, а тот в свою очередь будет передавать ее пользователю.

Такая конфигурация очень популярна, Nginx используется в ней для сортировки запросов. Он обрабатывает сам те запросы которые может и передает Apache только запросы, которые не может обслужить сам, снижая таким образом нагрузку на Apache.

Эта конфигурация позволяет горизонтально масштабировать приложение: вы можете установить несколько бэкенд серверов за одним фронтендом и Nginx будет распределять нагрузку между ними, увеличивая тем самым отказоустойчивость приложения.

Заключение

Как вы можете видеть и Apache, и Nginx — это мощные, гибкие и функциональные инструменты. Для того чтобы выбрать сервер под ваши задачи необходимо определиться с требованиями к нему и провести тесты на всех возможных паттернах использования вашего приложения.

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

Источник: https://habr.com/ru/post/267721/

Apache vs Nginx

Boeing заявляет, что модернизированный Apache является основным боевым вертолетом армии, а не FARA

Рендеринг модернизированного концепта AH-64 компании Boeing в действии.

Предоставлено Boeing

Среди многих интригующих масштабных моделей, представленных на ежегодной конференции AUSA в Вашингтоне, округ Колумбия, на этой неделе был BoeingBA заводской макет модернизированного концепта AH-64. Армия специально не запрашивала новый вариант Apache, но Boeing уверен, что его AH-64 будет ударным вертолетом на десятилетия вперед.

Уверенность компании основана на сигналах, которые армия недавно отправила о структуре своего парка вертолетов, говорит Кэтлин Джоливетт, вице-президент программ ударных вертолетов компании Boeing. «Армия заявила, что Apache будет существовать много лет, в период с 2050 по 2060 год. Мы знаем, что Apache актуален сегодня. Мы просто пытаемся убедиться, что это актуально в будущем».

Не так давно бригадный генерал (теперь генерал-майор) Вальтер Рюген, директор многофункциональной армейской группы Future Vertical Lift (FVL), сказал мне, что предстоящий штурмовик-разведчик Future Attack Reconnaissance Aircraft (FARA) будет основным ударным вертолетом. , это самолет первого дня, «пинок в дверь», а не «Апач».

«FARA и ее экосистема на самом деле являются нашей вторгающейся силой на нижнем уровне воздушного пространства.» Эта сила сможет найти, исправить и устранить движущиеся угрозы», — сказал БГЕН Руген, — «Затем мы начнем дезинтеграцию и откроем коридор. И действительно, я не думаю, что Apache участвует в фазе проникновения. Я думаю, что FARA и экосистема FARA делают это».

Два года спустя возросла вероятность того, что армия будет получать меньшую долю будущих оборонных бюджетов, поскольку ВВС и флот пытаются рекапитализироваться для потенциального будущего конфликта на обширных просторах Индо-Тихоокеанского региона. Эта перспектива вполне может лежать в основе комментариев генерал-майора Рюгена, сделанных в первый день AUSA. В частности, он сказал, что служба работает над поиском дополнительных способов привлечь своих союзников к участию в программах FVL, включая FARA.

ЕЩЕ ОТ FORFORBES ADVISOR

Конкурсный прототип армейского ударно-разведывательного самолета будущего от Sikorsky был готов на 90% … [+] по состоянию на середину лета.

Courtesy Sikorsky

Недавние соглашения о проекте FVL с Великобританией и Нидерландами не только свидетельствуют о стремлении к функциональной совместимости и техническому сотрудничеству в отношении FARA и будущего штурмового самолета большой дальности (FLRAA), но и о желании разделить их расходы.

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

Армейские официальные лица почти ничего не сказали о сроках будущего приобретения FVL в AUSA, а Рюген лишь подтвердил, что решение по FLRAA ожидается в «относительно короткий» период времени. Конкретные сроки для FARA, которые замедлились из-за задержек с поставкой нового улучшенного турбинного двигателя (ITE, GE T901) конкурентам Bell и Sikorsky, не были указаны.

Но зрители FVL на шоу отметили, что нынешнее продолжающееся решение и неопределенность в отношении того, когда Пентагон получит бюджет на 2023 год, вызывают в отрасли предположения о том, что FARA может быть обоснована и пересмотрена позже в этом десятилетии. Демонстрируя свою новую концепцию модернизации Apache, Boeing, казалось, читал чайные листья FARA, несмотря на то, что в настоящее время нет заявленных требований армии к новой версии AH-64.

«Все, что мы хотим сказать, — продолжает Кэтлин Джоливетт, — это то, что, поскольку [Apache] будет работать в операционной среде FVL, ему придется сотрудничать с этими платформами, ему придется разговаривать с ними. ».

Джоливетт говорит, что не было ни официальных, ни неофициальных переговоров с армией о модернизации Apache, кроме самой последней версии 64E AH-64E, которая сейчас находится на вооружении. Скорее, говорит она, Boeing находится в «режиме прослушивания», прислушиваясь к общим комментариям армии по поводу модернизации.

Эти комментарии и ожидаемая доступность ITE составляют основу модернизированной концепции Apache. Дополнительная тяга от пары GE T901 могла позволить AH-64 нести большую полезную нагрузку, преимущество, которое было визуально признано включением в концепцию третьего пилона с коротким крылом для увеличения боекомплекта. Представитель Boeing заявил о возможности установки нового лазерного оружия, которое можно увидеть на дополнительном пилоне масштабной модели.

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

Принимая во внимание список пожеланий программы FVL, компания Boeing заявляет, что она также оценивает передовые системы миссии, датчики и слияние датчиков, чтобы снизить когнитивное напряжение и облегчить рабочую нагрузку пилота. Возможность интеграции этих, а также будущих высокоточных боеприпасов, лазеров или других средств воздушного базирования будет реализована за счет усовершенствованной цифровой магистрали, которая приближается к гибкости типа MOSA (модульная архитектура открытых систем).

По словам Джоливетт, компания уже вкладывает собственные инвестиции и ресурсы в концепцию Apache. Однако она говорит, что нет никаких сроков для интеграции всего вышеперечисленного в физический планер. «На самом деле у нас еще нет прототипа, поэтому сейчас это всего лишь концепция».

Спрос на последнюю версию 6 самолета Boeing AH-64E высок как со стороны армии США, так и со стороны международных … [+] клиентов.

Предоставлено Boeing

Сроки переоборудования существующих AH-64 в модернизированные самолеты, предусмотренные концепцией, могут оказаться непростой задачей, по словам Джоливетт, благодаря спросу, который в настоящее время наблюдается в Boeing на обновление AH-64D и более ранних AH-64E до последние спецификации версии 6 как от армии, так и от иностранных заказчиков.

В целом, международный спрос на Apache, собственные инвестиции Boeing в модернизированную концепцию и неизбежное финансовое давление, с которым сталкивается армия, позволяют предположить, что Apache не является дополнением к новой партии ударных вертолетов FARA.

На самом деле все наоборот.

Apache работает нормально Fix DirectAdmin

от Manu Menon | 29 августа 2022 г.

Давайте подробнее рассмотрим ошибку, apache работает нормально исправить DirectAdmin. В Bobcares наша служба поддержки управления сервером может дать вам подробный обзор ошибки и ее причин.

ошибка: получение страницы apache. Apache работает нормально

Ошибка может возникать по одной из следующих причин:

Причина 1

В этом случае, если apache работает нормально, исправьте DirectAdmin; значение, которое домен разрешает *на вашем компьютере*, не соответствует значению, используемому apache. Перейдите на уровень администратора -> Показать всех пользователей, найдите домен и посмотрите, какой IP-адрес он настроен для использования.

Следующим шагом является определение IP-адреса, в который разрешается домен. Рекомендуется использовать внешний сервер, такой как dnsreport. com или другие бесплатные службы поиска, чтобы найти IP-адрес, в который разрешается имя. Эти два IP-адреса должны совпадать.

Обратите внимание: если мы недавно обновили IP-адреса доменов, возможно, нам придется подождать до 4 часов, пока новый IP-адрес будет передан нам. Таким образом, просмотр вышеуказанных страниц *нормальен* при смене IP-адресов. Уменьшите TTL перед изменением IP, чтобы сократить это время.

Причина 2

Виртуальный хост не указан в конфигурациях Apache. Есть несколько вещей, на которые стоит обратить внимание. Пользовательский файл httpd.conf находится в /usr/local/directadmin/data/users/username/httpd.conf и должен включаться в основной файл /etc/httpd/conf/httpd.conf одним из двух способов, в зависимости от конфигурация.

Для конфигурации на apache работает нормально fix DirectAdmin:

1. Если у нас есть custombuild (обычно Apache 2.2), мы должны увидеть следующую строку в /etc/httpd/conf/httpd. conf:

   Внизу , включите файл conf/extra/directadmin-vhosts.conf. Строка Include для пользователя httpd.conf должна появиться в файле /etc/httpd/conf/extra/directadmin-vhosts.conf, как и /usr/local/directadmin/data/users/username/httpd.conf. Если это не так, мы можем изменить все файлы конфигурации Apache с помощью:

   cd /usr/local/directadmin/custombuild
./build rewrite_confs

   Для этой конфигурации убедитесь, что мы соблюдаем следующие правила для нормального функционирования apache. conf/extra/directadmin-vhosts.conf
   в файле /usr/local/directadmin/conf/directadmin.conf.

2. То же самое, если мы используем customapache (обычно apache 1.3), но пользователь httpd.conf другой. В /etc/httpd/conf/httpd.conf включен файл /usr/local/directadmin/data/users/username/httpd.conf. Кроме того, apacheconf=/etc/httpd/conf/httpd.con должен присутствовать в /usr/local/directadmin/conf/directadmin.conf.

Устранение неполадок 1:

Мы можем использовать несколько вариантов устранения неполадок для ошибки. Apache работает нормально. Исправьте DirectAdmin некоторые из них, как показано ниже:

• . этот домен.
• После миграции с другого сервера убедитесь, что IP-адрес в файле httpd задан правильно. (IP-адрес старого сервера может все еще присутствовать).

  /usr/local/directadmin/data/users/ИМЯ ПОЛЬЗОВАТЕЛЯ/httpd.conf

• Убедитесь, что IP-адрес, назначенный домену, совпадает с IP-адресом, на который он ссылается. Если https не работает, я предполагаю, что у человека деактивирован SSL.
• Принудительно перезапустите Apache/nginx, используя следующий код:

  killall -9 httpd
service httpd start и проверьте, решает ли это проблему.

• Другой способ нормального функционирования Apache для исправления ошибки directadmin — проверить виртуальный хост. Если мы видим страницу «Добро пожаловать в apache», это означает, что виртуальный хост не загружен в файлы httpd.conf для этого IP-адреса. Возможно, пользовательский httpd. conf вообще не включен в основной httpd.conf, или IP-адрес, на который разрешается домен, не совпадает с IP-адресом, определенным в виртуальном хосте.

  Используя custombuild, мы можем легко восстановить его, введя код ниже.

  cd /usr/local/directadmin/custombuild
./build rewrite_confs

• Убедитесь, что IP-адрес в /etc/hosts соответствует домену/пользователю DirectAdmin для решения проблемы с apache работает нормально исправить ошибку directadmin.
• Если мы просто хотим разместить один веб-сайт на сервере с одним IP-адресом и хотим, чтобы сайт посещался с этого IP-адреса, мы можем сделать это следующим образом:

  Сначала измените файл: /etc/httpd/conf/extra/httpd-vhosts.conf :

  DocumentRoot /var/www/html

  Измените приведенный выше код на код, как показано ниже:

  DocumentRoot /home/user1 /domains/domain.com/public_html

  Переименуйте user1 и domain.com, указав настоящее имя пользователя и домен. Обратите внимание, менять их нужно только внутри разделов:

  VirtualHost 11.22.33.44:80
...
...
...
VirtualHost
VirtualHost 11.22.33.44:443
...
...
...
VirtualHost

  Где 11.22.33.44 — IP-адрес сервера. После этого запустите код:

  chattr +i /etc/httpd/conf/extra/httpd-vhosts.conf

  Наконец, перезапустите Apache.

Устранение неполадок 2:

• В случае использования «chattr +i» для любых файлов конфигурации. Пожалуйста, сделайте следующее вместо этого сейчас, чтобы управлять apache нормально, исправить DirectAdmin:

  chattr -i /etc/httpd/conf/extra/httpd-vhosts.conf mkdir -p /usr/local/directadmin/custombuild/custom/ap2/conf/extra cp -p /etc/httpd/conf/extra/ httpd-vhosts.conf /usr/local/directadmin/custombuild/custom/ap2/conf/extra/httpd-vhosts.conf

• Запустите приведенный ниже код:

  chattr -i /etc/httpd/conf/extra /httpd-vhosts. conf

  Внесите необходимые изменения и выполните команду:

  chattr +i /etc/httpd/conf/extra/httpd-vhosts.conf

[Нужна помощь с похожими вопросами? Мы здесь, чтобы помочь]. Группа поддержки управления сервером .

ПРЕДОТВРАТИТЕ СБОЙ СЕРВЕРА!

Никогда больше не теряйте клиентов из-за низкой скорости сервера! Позвольте нам помочь вам.

Наши специалисты по серверам будут контролировать и обслуживать ваш сервер 24/7, чтобы он оставался молниеносно быстрым и безопасным.

НАЧАТЬ

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

Поиск:

Похожие сообщения

Категории

Последние | Управление сервером

Советы по устранению неполадок для Apache | Acunetix

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

Проверьте конфигурацию HTTP-сервера Apache

Проблемы с HTTP-сервером Apache также могут быть результатом неправильно настроенного файла конфигурации Apache httpd.conf . Просмотр всего файла конфигурации в поисках опечаток может оказаться трудоемкой задачей, но, к счастью, Apache предоставляет способ сканирования файла httpd.conf на наличие синтаксических ошибок. Это можно сделать с помощью инструмента configtest из программы apachectl . Для Apache в системах Unix вам нужно будет выполнить apachectl –configtest из командной строки, а для Apache в системах Windows вам необходимо сначала перейти в каталог Apache «bin» из командной строки, а затем выполнить httpd.exe –t .

Рисунок 1. HTTP-сервер Apache обнаружил синтаксическую ошибку в директиве ServerTokens. Похоже, что директива ServerTokens была написана с ошибкой из-за дополнительной буквы «t» в начале части «Tokens». Другие проблемы могут остаться после решения этой проблемы, поэтому рекомендуется повторно запустить 9Инструмент 0098 configtest после исправления проблемы и перезапуска Apache.

Используйте последнюю версию Apache HTTP Server

Старые версии Apache HTTP Server могут содержать ошибки, которые могут вызывать проблемы, с которыми вы сталкиваетесь. Кроме того, использование устаревшей версии Apache также может привести к уязвимостям в системе безопасности. Список уязвимостей и ошибок в предыдущих версиях Apache можно найти здесь, а последнюю версию Apache можно скачать здесь.

Журналы HTTP-сервера Apache

В первую очередь следует проанализировать журнал ошибок HTTP-сервера Apache, поскольку он предоставляет подробную информацию обо всех ошибках, которые произошли на вашем веб-сервере. По умолчанию ошибки регистрируются в файле error_log, расположенном в каталоге журналов внутри корневой установки Apache. Уровни ведения журнала также можно настроить в файле конфигурации Apache httpd.conf, чтобы указать, какие типы ошибок записываются. Информацию о восьми различных уровнях ведения журнала можно найти здесь. Настройка уровня журнала на более высокий может предоставить вам больше информации о проблеме, но также затруднит поиск того, что вам нужно. Помимо журналов ошибок, Apache также предоставляет журналы доступа, в которых записываются все запросы, обработанные сервером. Эти журналы также могут давать дополнительные пояснения о том, что могло вызвать проблему, а также могут дополнять информацию, содержащуюся в журналах ошибок.

Используйте модуль mod_log_forensic

Модуль mod_log_forensic используется для обеспечения криминалистической регистрации клиентских запросов. Это включает регистрацию запросов до и после их обработки, когда на одни и те же запросы ссылаются с одним и тем же идентификатором. Таким образом, любые проблемы, вызванные конкретными запросами, могут быть легко идентифицированы. Это может помочь проанализировать, какие запросы могут вызывать остановку или сбой вашего веб-сервера. Чтобы включить этот модуль, вам необходимо настроить следующие строки в файле конфигурации Apache httpd.conf:

LoadModule log_forensic_module modules/mod_log_forensic.so

LoadModule unique_id_module modules/mod_unique_id.so

ForensicLog logs/forensic_log

Also, the check_forensic Bash script can be used in combination with the mod_log_forensic module to list any неполные запросы, обнаруженные в журнале судебной экспертизы. Пример использования инструмента check_forensic приведен ниже:

check_forensic

Используйте модуль mod_whatkilledus

Когда дела идут очень плохо и происходит сбой сервера Apache, модуль mod_whatkilledus можно использовать для регистрации подробной технической информации о сбое вместе с исходным запросом клиента, вызвавшим его. Кроме того, если модуль mod_backtrace включен, будет включена обратная трассировка, показывающая точку сбоя, что полезно для аннотирования журналов ошибок обратными трассировками после выполнения определенных условий. Для систем Unix эти модули будут работать только в том случае, если --enable-exception-hook аргумент включен в сборке httpd . С другой стороны, для систем Windows нет особых требований. Инструкции по установке и настройке для mod_whatkilledus и mod_backtrace можно найти здесь.

Пример журнала сбоя в журналах mod_whatkilledus

Проверьте сторонние модули

Возможно, сторонние модули могут вызывать проблемы, с которыми вы сталкиваетесь при установке Apache HTTP Server. Поэтому вам следует отключить все сторонние модули и проверить, можно ли воспроизвести проблему. Если отключение этих модулей решило проблему, вы можете попытаться повторно включить каждый модуль один за другим, чтобы путем исключения определить, какой из модулей вызывал проблему.

Запустите Apache HTTP Server как отдельный процесс и используйте инструменты отладки

Типичная установка Apache HTTP Server выполняется с несколькими процессами. Однако для упрощения устранения неполадок лучше всего запускать Apache как единый процесс. Это можно сделать, используя опцию X при запуске Apache. В приведенном ниже примере Apache запускается в режиме одного процесса, при этом Apache не будет создавать новые дочерние процессы или отсоединяться от терминала.

$ httpd –X

После этого весь трафик и связь будут проходить через один процесс, что позволит использовать процедуры устранения неполадок в одном процессе, а не в нескольких процессах. Затем вы сможете запустить Apache httpd под отладчиком, получить обратную связь о сбое, а также заставить сервер выполнить дамп ядра. Официальные ресурсы для разработчиков Apache, найденные здесь, более подробно объясняют, как все это сделать для серверов Apache, работающих как в системах Windows, так и в системах Unix.

Проблемы с выполнением скриптов

Динамический контент обычно обслуживается через скрипты, которые выполняются HTTP-сервером Apache через модуль mod_cgi. Этот модуль включает в себя собственный механизм регистрации ошибок, возникающих при выполнении этих скриптов. После включения директивы ScriptLog mod_cgi будет записывать выходные данные любых сценариев, которые не выполнялись должным образом, включая код ответа сервера, полученный запрос и любой ответ, отправленный клиенту. Чтобы включить это, вам нужно изменить файл конфигурации httpd.conf и указать директиву ScriptLog и место, где будут сохраняться журналы, как указано ниже.

ScriptLog logs/cgi_log

Ресурсы сообщества Apache

Apache — это проект с открытым исходным кодом, пользующийся широкой поддержкой сообщества, поэтому существует ряд ресурсов, которые можно использовать для помощи в решении проблем Apache. Чаще всего проблемы уже были задокументированы на различных форумах или веб-сайтах, поэтому простой поиск в Google может привести к нескольким ответам или предложениям. Другие ресурсы, на которые вы можете ссылаться, включают:

• Официальная документация по HTTP-серверу Apache доступна здесь.