Нет ответа от сервера linux

Проверка кода ответа сервера и http заголовков

Когда мы открываем любую веб-страницу нужного нам сайта вместе с HTML кодом страницы сервер передает код статуса запроса и http заголовки. По коду статуса программы могут быстро определить все ли прошло успешно или, например, такой страницы нет на сервере. Заголовки содержат информацию для браузера, которая указывает как нужно обрабатывать страницу и что с ней делать.

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

Что такое код ответа сервера?

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

• 100 — сервер принял первую часть запроса, можно подрожать передачу;
• 101 — нужно изменить протокол работы на более подходящий;
• 102 — на обработку запроса уйдет много времени, используется чтобы браузер не разрывал соединение раньше времени;

2хх — операция успешна:

• 200 — запрос выполнен успешно, отправляется для большинства запрашиваемых страниц;
• 201 — после выполнения запроса был создан ресурс;
• 202 — запрос принят, но еще не обработан;
• 203 — запрос выполнен успешно, но информация для ответа взята из прокси;
• 204 — запрос обработан, но контента для отображения нет;
• 205 — попросить пользователя ввести необходимые данные;
• 206 — запрос обработан, но передана только часть контента;

• 300 — есть несколько страниц для этого запроса, например, на нескольких языках;
• 301 — страница навсегда перемещена по новому адресу;
• 302 — документ был временно перемещен;
• 303 — документ необходимо загрузить по указанному адресу с помощью протокола GET;
• 304 — документ не изменился с последнего запроса;
• 305 — нужно использовать прокси;
• 307 — ресурс временно перемещен на новый адрес.

4хх — ошибка в запросе:

• 400 — неверный запрос;
• 401 — необходимо аутентифицироваться;
• 403 — запрос принят, но у вас нет доступа;
• 404 — страница не найдена на сервере;
• 405 — используемый метод нельзя применять на сервере;
• 408 — время ожидания передачи запроса истекло;
• 410 — ресурс полностью удален;
• 411 — нужно указать длину запроса;
• 413 — запрос слишком длинный;
• 414 — URI запроса слишком длинная.

5хх — ошибка сервера:

• 500 — внутренняя ошибка сервера;
• 501 — нужная функция не поддерживается;
• 502 — прокси не может соединиться со шлюзом;
• 503 — сервер не может обрабатывать запросы по техническим причинам;
• 504 — прокси не дождался ответа от сервера;
• 505 — версия протокола HTTP не поддерживается.

Что такое http заголовки?

С помощью http заголовков клиент и сервер обмениваются информацией и командами между собой. Они используются для согласования метода, протокола, кодировки, языка и многих других параметров работы. Рассмотрим основные заголовки, которые будет отправлять сервер:

• Server — имя и версия веб-сервера;
• Date — дата осуществления запроса;
• Content-Type — MIME тип передаваемых данных, например, text/html, тут же задается кодировка;
• Connection — тип соединения, может быть closed — уже закрыто, или keep-alive — открыто для передачи данных;
• Vary — указывает при каких заголовках веб-сервер будет возвращать разные старины для одного URI;
• Set-Cookie — сохранить Cookie информацию для страницы;
• Expires — можно хранить страницу или ресурс в кэше до определенной даты;
• Cache-Control — настройка времени кэширования страницы браузером, а также разрешения на кэширования;
• ETag — содержит контрольную сумму для страницы, применимо для проверки кэша;
• Last-Modified — дата, когда страница последний раз была изменена;

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

Проверка кода ответа сервера с помощью cURL

Чтобы увидеть только код ответа страницы достаточно выполнить такую команду:

Или, если хотите, чтобы ответ выглядел более естественно:

Страницы вернули 200, все в порядке. Но отправляет ли сервер редирект для нужных нам страниц? Если ваш сайт работает на https, то все запросы http должны перекидываться на https, также для любого сайта, все запросы на www домен должны перенаправляться на основной, или наоборот. Запросы на ip сайта тоже в идеале должны отправляться на основной домен. Проверка http ответа:

Все работает так, как нужно. Но смотреть код ответа сервера вряд ли понадобиться, намного интереснее проверка http статусов.

Проверка http заголовков с помощью Curl

Для проверки заголовков мы тоже можем использовать утилиту curl. Чтобы вывести заголовки страницы запустите ее с опцией -I:

Здесь отображается код ответа сервера, а также принятые http заголовки. Из них мы можем сделать такие выводы:

• Страница сгенерирована в nginx 1.10.2;
• Это обычная html страница (text/html);
• Размер страницы 102452 байт или 100 кб;
• Страница последний раз изменялась 18:13:12 (last_modified) это очень важный параметр для поисковых систем;
• Сервер будет выдавать разные версии страниц при изменении поля Accept-Encoding (Vary);
• Страница может храниться в любом кэше (public) на протяжении часа (expires);

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

Мы можем видеть, что картинка будет храниться в кэше намного дольше (max-age) чем html страница.

Осталось проверить работают ли такие заголовки, как If-Modified-Since и If-None-Match. Первый позволяет выполнять проверку актуальности кэша по дате модификации, второй — по контрольной сумме поля ETag. Кэш очень важен, чтобы снизить нагрузку на ваш сервер. Если страница не изменилась, то сервер лишь сообщает что она не изменилась, отправляя код ответа 304, вместо передачи полного файла.

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

Проверка If-Modified-Since

Сначала запрашиваем нашу страницу для просмотра заголовков http, а затем копируем поле Last-Modified:

Теперь запрашиваем ее еще раз, но уже с заголовком If-Modified-Since: и ваша дата:

В ответ вы должны получить не саму страницу, а только заголовок HTTP/1.1 304 Not Modified. Если так, значит проверка кода ответа сервера пройдена и все работает верно.

Проверка If-None-Match

Заголовок If-None-Match работает похожим образом, только здесь используется значение контрольной суммы кэша из поля ETag. Опять запросим нашу страницу и скопируем сумму:

Затем отправим полученную сумму с заголовком:

И снова мы должны получить ответ 304, страница не изменена.

Проверка сжатия

Сжатие позволяет уменьшить размер передаваемых данных, но в то же время создает дополнительную нагрузку на сервер. Чтобы проверить поддерживает ли сервер сжатие gzip нужно отправить в запросе заголовок Accept-Encoding с параметром gzip:

В ответе мы увидим поле Content-Encoding: gzip. Это будет означать, что сжатие используется.

Выводы

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

Источник

Попович Алексей персональный сайт разработчика

Основные направления моей деятельности

На битриксе можно реализовать что угодно. Как говорил один клиент — реализовать можно все, лишь бы было кому это оплатить 🙂

Созданием сайтов я занимаюсь с 2009-го года, а вообще основами алгоритмов и программированием занимаюсь еще со школьных лет, т.е. примерно с 2000-го года. За всю свою практику в создании приложений (а веб-решение — это также приложение, активно или пассивно взаимодействующее с пользователем) понял главное — нельзя охватить все, иначе не будешь знать ничего.

К основным направлениям моей деятельности относятся:

• Проектирование веб-решений разного уровня сложности (предпочитаю работать над неординарными проектами, позволяющими поломать голову над реализацией задачи);
• Создание предпроектного описания задачи (ТЗ) для создания сайта на базе продуктов 1С-Битрикс;
• Сопровождение и доработки действующих проектов на базе продуктов 1С-Битрикс;
• Создание сайтов с нуля с использованием готовых решений. Выбираем наиболее подходящее вам из готовых решений на Marketplace, устанавливаем его и потом уже его допиливаем;
• Перенос сайтов с любой другой CMS под управление 1С-Битрикс Управление сайтом;
• Анализ сайтов-конкурентов;
• Курирование работы сводной команды разработчиков над вашим веб-решением на базе 1С-Битрикс — могу выступать в роли Менеджера проекта с постановкой задач всем участникам проекта, оценкой качества выполненной работы, решением вопросов, возникающих в ходе работы над проектом;
• Настройка интеграции сайтов на базе 1С-Битрикс с любой другой системой через API систем или через обмен файлами с другой системой;
• Получение информации с публичных страниц сторонних сайтов, путем прямого парсинга данных;
• Доработка сайтов под требования сео-специалистов;
• Перенос сайтов с разделяемых хостингов на VPS;

Отзывы о работе веб-мастера

Александра

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

Максим

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

Александр

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

Источник

Как проверить подключение к Интернету в терминале Linux

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

Метод 1: команда PING

Лучший способ — проверить доступность Интернета с помощью команды PING.

Команда PING используется для отправки и получения пакетов от внешнего / удаленного сервера и на него.

В качестве примера мы попытаемся отправить три интернет-пакета на сервер Google и проверить подключение к Интернету, сможем ли мы получать интернет-пакеты с сервера Google.

В выводе вы также можете увидеть, что три пакета переданы и получены. Опять же, это потому, что пинг на сервер Google прошел успешно.

Метод 2: команда CURL

Другой способ проверить подключение к Интернету — использовать команду CURL.

Команда CURL используется для загрузки, выгрузки или передачи данных по сети с сервера или на сервер. Он поддерживает различные протоколы, и мы можем использовать его для проверки подключения к Интернету, подключившись к linuxhint.com и получив заголовки. Если заголовки получены успешно, это означает, что Интернет работает; в противном случае возникнет проблема.

Если вы получаете статус 200 OK и заголовки веб-сайта, подключение к Интернету работает нормально.

Источник