По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
На сегодняшний день двумя наиболее популярными веб-серверами с открытым исходным кодом для работы в Интернете являются HTTP-сервер Apache и Nginx. Более 50% веб-сайтов в мире работают на этих двух веб-серверах. В течение почти двух десятилетий веб-сервер Apache обслуживал около 60 процентов веб-сайтов в мире, пока не появился его конкурент Nginx (произносится как «engine-x»). В связи с резким ростом объемов трафика данных и количества пользователей всемирной паутины, Nginx был введен для преодоления ограничений производительности веб-серверов Apache. Nginx, разработанный для обеспечения более высокого уровня параллелизма, может быть развернут в качестве автономного веб-сервера и в качестве внешнего прокси-сервера для Apache и других веб-серверов. Прочитать про установку и настойку этих серверов можно в этой статье Кстати! Еще у нас есть статья по сравнению Apache против IIS. Welcome 🤓 Краткий обзор Apache Apache был разработан для доставки веб-контента, доступ к которому осуществляется через Интернет. Он известен тем, что играл ключевую роль в начальном росте интернета. Apache - это программное обеспечение с открытым исходным кодом, разработанное и поддерживаемое открытым сообществом разработчиков и работающее в самых разных операционных системах. Архитектура включает в себя ядро Apache и модули. Основной компонент предоставляет базовую серверную функцию, поэтому он принимает соединения и управляет параллелизмом. Различные модули соответствуют различным функциям, которые выполняются по каждому запросу. Конкретное развертывание Apache может быть сконфигурировано для включения различных модулей, таких как функции безопасности, управление динамическим контентом или для базовой обработки HTTP-запросов. Модель «один сервер делает все» стала ключом к раннему успеху Apache. Однако по мере увеличения уровня трафика и увеличения количества веб-страниц и ограничения производительности настройка Apache на работу с реальным трафиком усложнялась. Краткий обзор Nginx Nginx был разработан специально для устранения ограничений производительности веб-серверов Apache. Производительность и масштабируемость Nginx обусловлены архитектурой, управляемой событиями. Он значительно отличается от подхода Apache. В Nginx каждый рабочий процесс может одновременно обрабатывать тысячи HTTP-соединений. Следовательно, Nginx - это легковесная, масштабируемая и высокопроизводительная реализация. Эта архитектура делает обработку больших и флуктуирующих нагрузок на данные гораздо более предсказуемой с точки зрения использования ОЗУ, использования ЦП и задержки. Nginx также имеет богатый набор функций и может выполнять различные роли сервера: Обратный прокси-сервер для протоколов HTTP, HTTPS, SMTP, POP3 и IMAP Балансировщик нагрузки и HTTP-кеш Интерфейсный прокси для Apache и других веб-серверов, сочетающий гибкость Apache с хорошей производительностью статического контента Nginx Apache против Nginx: сравнение их богатых наборов функций Простота Разрабатывать и обновлять приложения на Apache очень просто. Модель «одно соединение на процесс» позволяет очень легко вставлять модули в любой точке логики веб-обслуживания. Разработчики могут добавлять код таким образом, что в случае сбоев будет затронут только рабочий процесс, выполняющий код. Обработка всех других соединений будет продолжаться без помех. Nginx, с другой стороны, имеет сложную архитектуру, поэтому разработка модулей не легка. Разработчики модулей Nginx должны быть очень осторожны, чтобы создавать эффективный и точный код, без сбоев, и соответствующим образом взаимодействовать со сложным ядром, управляемым событиями, чтобы избежать блокирования операций. Производительность Производительность измеряется тем, как сервер доставляет большие объемы контента в браузер клиента, и это важный фактор. Контент может быть статическим или динамическим. Давайте посмотрим статистику по этому вопросу. Статический контент Nginx работает в 2,5 раза быстрее, чем Apache, согласно тесту производительности, выполняемому до 1000 одновременных подключений. Другой тест с 512 одновременными подключениями показал, что Nginx примерно в два раза быстрее и потребляет меньше памяти. Несомненно, Nginx имеет преимущество перед Apache со статическим контентом. Поэтому, если вам нужно обслуживать одновременный статический контент, Nginx является предпочтительным выбором. Динамический контент Результаты тестов Speedemy показали, что для динамического контента производительность серверов Apache и Nginx была одинаковой. Вероятная причина этого заключается в том, что почти все время обработки запросов расходуется в среде выполнения PHP, а не в основной части веб-сервера. Среда выполнения PHP довольно похожа для обоих веб-серверов. Apache также может обрабатывать динамический контент, встраивая процессор языка, подобного PHP, в каждый из его рабочих экземпляров. Это позволяет ему выполнять динамический контент на самом веб-сервере, не полагаясь на внешние компоненты. Эти динамические процессоры могут быть включены с помощью динамически загружаемых модулей. Nginx не имеет возможности обрабатывать динамический контент изначально. Чтобы обрабатывать PHP и другие запросы на динамический контент, Nginx должен перейти на внешний процессор для выполнения и дождаться отправки визуализированного контента. Однако этот метод также имеет некоторые преимущества. Поскольку динамический интерпретатор не встроен в рабочий процесс, его издержки будут присутствовать только для динамического содержимого. Поддержка ОС Apache работает во всех операционных системах, таких как UNIX, Linux или BSD, и полностью поддерживает Microsoft Windows. Nginx также работает на нескольких современных Unix-подобных системах и поддерживает Windows, но его производительность в Windows не так стабильна, как на платформах UNIX. Безопасность И Apache, и Nginx являются безопасными веб-серверами. Apache Security Team существует, чтобы предоставить помощь и советы проектам Apache по вопросам безопасности и координировать обработку уязвимостей безопасности. Важно правильно настроить серверы и знать, что делает каждый параметр в настройках. Гибкость Веб-серверы могут быть настроены путем добавления модулей. Apache долго загружал динамические модули, поэтому все модули Apache поддерживают это. Nginx Plus (Nginx Plus - это программный балансировщик нагрузки, веб-сервер и кэш контента, построенный на основе открытого исходного кода Nginx) также использует модульную архитектуру. Новые функции и возможности могут быть добавлены с программными модулями, которые могут быть подключены к работающему экземпляру Nginx Plus по требованию. Динамические модули добавляют в Nginx Plus такие функции, как геолокация пользователей по IP-адресу, изменение размеров изображений и встраивание сценариев Lua в модель обработки событий Nginx Plus. Модули создаются как Nginx, Inc., так и сторонними разработчиками. Большинство необходимых функциональных возможностей основного модуля (например, прокси, кэширование, распределение нагрузки) поддерживаются обоими веб-серверами. Поддержка и документация Важным моментом, который следует учитывать, является доступная справка и поддержка веб-серверов среди прочего программного обеспечения. Поскольку Apache был популярен так долго, поддержка сервера довольно распространена повсеместно. Для главного сервера и для основанных на задачах сценариев, связанных с подключением Apache к другому программному обеспечению, имеется большая библиотека документации первого и стороннего производителя. Наряду с документацией многие инструменты и веб-проекты содержат инструменты для начальной загрузки в среде Apache. Это может быть включено в сами проекты или в пакеты, поддерживаемые отделом упаковки вашего дистрибутива. Apache, как правило, получает большую поддержку от сторонних проектов просто из-за своей доли рынка и продолжительности времени, в течение которого он был доступен. В прошлом для Nginx было трудно найти исчерпывающую англоязычную документацию из-за того, что большая часть ранней разработки и документации была на русском языке. Однако на сегодняшний день документация заполнена, и на сайте Nginx имеется множество ресурсов для администрирования и доступной документации от третьих лиц. Ngnix против Apache: Сравнение лицом к лицу Подводя итог, вот табличное представление наборов функций: ОсобенностьApacheNginxПростотаЛегко разрабатывать и внедрять инновации благодаря своей модели «одно соединение на процесс»Сложный в разработке, поскольку он имеет сложную архитектуру для одновременной обработки нескольких соединений.Производительность - Статический контентМедленно в отображении статического контентаВ 2,5 раза быстрее чем Apache и потребляет меньше памятиПроизводительность - Динамический контентОтличная производительность для динамического контентаОтличная производительность для динамического контентаПоддержка операционной системыПоддерживает все ОС - Unix, как и WindowsПоддерживает все ОС - как Unix, так и Windows, однако производительность в Windows сравнительно менее стабильна.БезопасностьЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныЭто безопасный веб-сервер. Понимание и настройка функций безопасности важныГибкостьМожно настроить, добавив модули. Apache имел динамическую загрузку модулей дольше всего.Nginx версии 1.11.5 и Nginx Plus Release R11 представили совместимость для динамических модулей.Поддержка и документацияОтличная поддержка и документация доступны, как это было на рынке в течение очень долгого времени.Несмотря на слабое начало поддержки и документации для Nginx, он быстро рос, поэтому теперь у него есть отличная поддержка ресурсов и доступная документация. Nginx и Apache - Совместная работа Для многих приложений Nginx и Apache хорошо дополняют друг друга. Очень распространенным начальным шаблоном является развертывание программного обеспечения Nginx с открытым исходным кодом в качестве прокси-сервера (или Nginx Plus в качестве платформы доставки приложений) перед веб-приложением на основе Apache. Nginx выполняет тяжелую работу, связанную с HTTP - обслуживает статические файлы, кэширует содержимое и разряжает медленные HTTP-соединения - так что сервер Apache может выполнять код приложения в безопасной и защищенной среде. Итак, что выберите? Apache или Nginx? Как видно, Apache и Nginx являются мощными, гибкими и способными. Последние версии обоих серверов являются конкурентоспособными во всех областях. Решение о том, какой сервер лучше для вас, во многом зависит от оценки ваших конкретных требований и выбора наилучшего варианта.
img
Много раз в день вы посещаете веб-сайты, на которых вас просят войти под своим именем пользователя, адресом электронной почты и паролем. Банковские сайты, сайты социальных сетей, почтовые службы, сайты электронной коммерции и новостные сайты - это всего лишь несколько типов сайтов, использующих этот механизм. Каждый раз, когда вы входите на один из этих сайтов, вы, по сути, говорите: «Да, я доверяю этому сайту, поэтому я хочу поделиться с ним своей личной информацией». Эти данные могут включать ваше имя, пол, физический адрес, адрес электронной почты, а иногда даже информацию о кредитной карте. Но откуда вы знаете, что можете доверять определенному веб-сайту? Иными словами, что делает веб-сайт для защиты вашей транзакции, чтобы вы могли доверять ей? Эта статья направлена на демистификацию механизмов, которые делают сайт безопасным. Мы начнем с обсуждения веб-протоколов HTTP и HTTPS и концепции безопасности транспортного уровня (TLS - Transport Layer Security), которая является одним из криптографических протоколов. Затем мы объясним центры сертификации (CA - Certificate Authorities) и самозаверяющие сертификаты и как они могут помочь защитить веб-сайт. Наконец, я представлю некоторые инструменты с открытым исходным кодом, которые вы можете использовать для создания и управления сертификатами. Защита маршрутов через HTTPS Самый простой способ понять защищенный веб-сайт - это увидеть его в действии. К счастью, сегодня найти защищенный веб-сайт гораздо проще, чем незащищенный веб-сайт в Интернете. Но, поскольку вы уже находитесь на сайте wiki.merionet.ru, будем использовать его в качестве примера. Независимо от того, какой браузер вы используете, вы должны увидеть значок, который выглядит как замок рядом с адресной строкой. Нажмите на значок замка, и вы должны увидеть что-то похожее на это. По умолчанию веб-сайт не является безопасным, если он использует протокол HTTP. Добавление сертификата, настроенного через хост сайта, может преобразовать сайт из незащищенного сайта HTTP в защищенный сайт HTTPS. Значок замка обычно указывает, что сайт защищен через HTTPS. Нажмите на сертификат, чтобы увидеть CA сайта. В зависимости от вашего браузера вам может понадобиться скачать сертификат, чтобы увидеть его. Здесь вы можете узнать кое-что о сертификате, кем, кому и когда был выдан. Эта информация о сертификате позволяет конечному пользователю проверить, что сайт безопасен для посещения. ВНИМАНИЕ: Если вы не видите знак сертификата на веб-сайте или если вы видите знак, указывающий на то, что веб-сайт не защищен, пожалуйста, не входите в систему и не выполняйте действия, требующие ваших личных данных. Это довольно опасно! Если вы видите предупреждающий знак, который редко встречается на большинстве общедоступных веб-сайтов, это обычно означает, что срок действия сертификата истек или используется самозаверяющий сертификат вместо сертификата, выпущенного через доверенный CA. Интернет-протоколы с TLS и SSL TLS - это текущее поколение старого протокола Secure Socket Layer (SSL). Лучший способ понять его место - посмотреть на модель OSI. Есть шесть уровней, которые составляют Интернет, каким мы его знаем сегодня: физический, данные, сеть, транспорт, безопасность и приложения. Физический уровень является базовой основой, и он наиболее близок к реальному оборудованию. Прикладной уровень является наиболее абстрактным и ближайшим к конечному пользователю. Уровень безопасности можно рассматривать как часть уровня приложений, а TLS и SSL, которые являются криптографическими протоколами, разработанными для обеспечения безопасности связи по компьютерной сети, находятся на уровне безопасности. Основным вариантом использования TLS является шифрование связи между веб-приложениями и серверами, такими как веб-браузеры, загружающие веб-сайт. Протокол TLS также можно использовать для шифрования других сообщений, таких как электронная почта, обмен сообщениями и передача голоса по IP (VOIP). Центры сертификации и самозаверяющие сертификаты Центр Сертификации (CA) - это доверенная организация, которая может выдавать цифровой сертификат. TLS и SSL могут сделать соединение безопасным, но для механизма шифрования необходим способ его проверки - это сертификат SSL/TLS. TLS использует механизм, называемый асимметричным шифрованием, который представляет собой пару ключей безопасности, называемых закрытым ключом (private key) и открытым ключом (public key). Важно знать, что центры сертификации, такие как GlobalSign, DigiCert и GoDaddy являются внешними доверенными поставщиками, которые выпускают сертификаты, которые используются для проверки сертификата TLS/SSL, используемого веб-сайтом. Этот сертификат импортируется на хост-сервер для защиты сайта. Прежде чем какой-либо крупный веб-браузер, такой как Chrome, Firefox, Safari или Internet Explorer, подключится к вашему серверу по протоколу HTTPS, он уже имеет в своем распоряжении набор сертификатов, которые можно использовать для проверки цифровой подписи, найденной в сертификате вашего сервера. Эти цифровые сертификаты веб-браузера называются сертификатами CA. Если с сертификатом на сервере все ок, то мы попадаем на сайт, а если нет, то браузер покажет нам предупреждение. Закрытые ключи, используемые для подписи сертификатов сервера, уже имеют соответствующие пары открытых ключей в веб-браузерах пользователей. Однако CA может быть слишком дорогим или сложным, когда вы просто пытаетесь протестировать веб-сайт или услугу в разработке. У вас должен быть доверенный ЦС для производственных целей, но разработчикам и администраторам веб-сайтов необходим более простой способ тестирования веб-сайтов, прежде чем они будут развернуты в рабочей среде - именно здесь приходят самозаверяющие сертификаты. Самозаверяющий сертификат - это сертификат TLS/SSL, подписанный лицом, которое его создает, а не доверенным центром сертификации. Создать самозаверяющий сертификат на компьютере очень просто, и он может позволить вам протестировать защищенный веб-сайт, не покупая дорогой сертификат, подписанный СА, сразу. Хотя самозаверяющий сертификат определенно рискованно использовать в производственной среде, он является простым и гибким вариантом для разработки и тестирования на подготовительных этапах. Инструменты с открытым исходным кодом для генерации сертификатов Для управления сертификатами TLS/SSL доступно несколько инструментов с открытым исходным кодом. Наиболее известным из них является OpenSSL, который включен во многие дистрибутивы Linux и в macOS. Тем не менее, другие инструменты с открытым исходным кодом также доступны. OpenSSL - Самый известный инструмент с открытым исходным кодом для реализации библиотек TLS и шифрования Apache EasyRSA - Утилита командной строки для создания и управления PKI CA CFSSL - PKI/TLS "Швейцарский нож" от Cloudflare Lemur - Инструмент создания TLS от Netflix
img
Сериализация – это процесс, в котором одна служба берет структуру данных, такую как словарь в Python, упаковывает ее и передает другой службе для чтения. Это максимально простое определение. Представьте, что мне нужно отправить кому-то сообщение. Итак, я записываю текст на уже собранный пазл. Далее я разбираю части пазла, добавляю несколько инструкций о том, как его собрать, и отправляю его. Затем получатель сообщения, получив кусочки головоломки, собирает их вместе. И теперь у него есть мое сообщение. Техническое определение этого понятия немного интереснее. А именно, сериализация – это процесс преобразования объекта данных в поток байтов и сохранения состояния объекта для хранения на диске или передачи по сети. Это сокращает необходимый размер хранилища и упрощает передачу информации по сети. Маршалинг и сериализация – в чем разница? Здесь на ум может прийти понятие маршалинга (Marshalling). Маршалинг – это процесс преобразования представления объекта в памяти в форму, подходящую для передачи. Хотя маршалинг и сериализация в общих чертах похожи, между ними все-таки есть принципиальная разница. Например, при создании программы в Golang для считывания JSON данных в структуру данных Golang вы можете использовать маршалинг для преобразования пары «ключ-значение» JSON в пару «ключ-значение» Golang. Разница в том, что маршалинг используется для преобразования данных. А сериализация, напротив, отправляет или сохраняет данные в потоке байтов и повторно собирает их в исходную форму. Оба процесса вроде бы выполняют процесс сериализации, но с разными намерениями. Вы можете увидеть структуру, которую я создал для взаимодействия с данными Twitter, ниже, как пример процесса маршалинга в действии. В Golang вы можете вставлять подсказки, называемые тегами, легко преобразовывая этот объект в данные JSON с помощью встроенной службы маршалинга Golang. Что такое Endianness? Я также хотел бы немного затронуть тему порядка следования байтов. Endianness – это термин, который используется для описания порядка байтов в памяти. Представьте, что память – это блок, в котором хранятся биты данных. Чтобы сериализация работала, поток байтов должен передавать типы данных независимо от изменения порядка следования байтов из одной системы в другую. Здесь вы можете увидеть большие различия и не очень. Очень важно, чтобы порядок следования байтов из одной системы в другую совпадал или каким-либо образом преобразовывался, поскольку не все системы упорядочивают свои биты одинаково. Little endian (от младшего к старшему) и big endian (от старшего к младшему) Варианты использования сериализации Наш вариант использования в полной мере использует все функции сериализации. Мы планируем получить некоторую информацию от сканируемого оборудования, упаковать эту информацию в поток байтов и отправить ее по сети в другую службу, которая восстановит данные. Процесс обратной сериализации и восстановления данных в исходную форму называется десериализацией. Есть и другие варианты использования сериализации. Например, REST API или протоколы обмена сообщениями, такие как AMQP, могут использовать сериализацию для сжатия и отправки данных. AMQP – это протокол обмена сообщениями, в котором вы отправляете сообщение брокеру AMQP, а служба-получатель «прослушивает» этого брокера в поисках сообщения. Серверные специалисты должны быть хорошо с этим знакомы, так как это часто используется для отправки данных туда и обратно в распределенных системах. Многие языки программирования включают возможность легкого развертывания некоторой сериализации. Так что это языково-независимая тема. Пример сериализации Приведем краткий пример. Код, приведенный ниже, использует библиотеку kombu для отправки сообщений через AMQP. Мы используем ее для отправки сообщений из одного программного пакета в другой по сети. Данный код предназначен для службы, отправляющей сообщение брокеру AMQP: Обратите внимание на метод publish. Мы передаем метод сериализации в качестве аргумента, чтобы библиотека понимала, как сериализовать данные, которые мы передаем. Сообщение с данными преобразуется в поток байтов, который, если на него посмотреть, выглядит просто как длинная строка букв и цифр. И мы отправляем сообщение. Соответствующая служба будет использовать тот же метод сериализации для восстановления данных в их исходное состояние. Это важная функция, поскольку мы создаем набор инструментов, которые должны иметь возможность отправлять сообщения друг другу, чтобы все работало. Форматы данных сериализации В основном я использую JSON для сериализации, когда этого требует задача. Но тем не менее, вы можете использовать и другие варианты. У JSON много издержек, но для меня он идеален, потому что он читабелен. Вы также можете использовать Protobuf, YAML или XML. Это лишь некоторые из возможных. Заключение Сериализация становится необходимостью, когда вы строите свои каналы связи. Полезно знать о таком понятии, чтобы чувствовать себя уверенно при подходе к любому инструменту, который вы используете, с соответствующими базовыми знаниями.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59