Як працює web сервер на комп'ютері. Що таке веб-сервер. Forbidden - вам сюди не можна

Для чого потрібен сервер і коли варто купувати його для свого бізнесу?

Для початку уточнимо, що сервер - це обладнання, яке використовує серверне програмне забезпечення. Він оптимізований для роботи з іншими комп'ютерами (клієнтами). Клієнтами сервера можуть бути комп'ютери, телефони, факси, принтери і всі інші пристрої, які підключаються до інтернету. Чим більше інформації Ви плануєте зберігати на серверному обладнанні, тим потужнішим має бути сервер. Для яких цілей орендують сервер? Детальніше в матеріалі на блозі ГіперХост.

Компанії використовують сервера для загального доступу всіх співробітників до певної інформації і для загального користування доступними ресурсами. Для того, щоб сервер добре працював, наймають системного адміністратора. Він налаштовує обладнання для роботи, робить резервне копіювання, усуває виниклі неполадки. Коректна робота сервера безпосередньо залежить від якісної і професійної роботи сіс.адміна. Зверніть увагу, що для всіх користувачів послуг компанії надається безкоштовна технічна підтримка, незалежно від тарифу.

Але все ж багато хто вважає, що мати власний сервер не обов'язково, можна скористатися звичайним комп'ютером. Але хочемо вас попередити, що це дуже недалекоглядне рішення. Комп'ютер не зможе виконувати безліч завдань, які виконує сервер. Перш за все, сервер це не тільки зберігання інформації, але і виконання великої кількості одночасних запитів, з якими звичайний ПК не впорається і в критичний момент просто втратить всю необхідну інформацію.

Якщо Ваш бізнес працює на перспективне майбутнє, слід задуматися про вибір сервера.

Для початку розберемося, які є види серверів в залежності від виконуваних функцій.

Поштовий сервер бере безпосередню участь в ухваленні та відправленні електронної пошти. Ви відправляєте лист на електронну адресу, але воно спочатку потрапляє на поштовий сервер, де відбувається його обробка. Індексується адресу одержувача і лист відправляється. У цьому процесі бере участь кілька поштових серверів, які обмінюються необхідною інформацією. Про популярних поштових серверах Exim, Postfix, Sendmail можна прочитати в статті.

файловий сервер зберігає всі файли мережі, до яких відбувається доступ з інших комп'ютерів. Для обміну файлами використовується протокол FTP, за допомогою якого користувач може завантажувати всі файли в мережі (картинки, відео, аудіо). Файловим сервером можна вважати будь-який комп'ютер, який має багато дискового простору для зберігання інформації.

Веб-сервер - сервер підключений до Інтернету і приймає запити користувачів по протоколу HTTP. Всі сайти, який є в мережі, розташовані на веб-серверах. Такий вид сервера - безпосередній провідник між сайтом і клієнтами. Веб-сервер отримує запит, далі обробляє його і видає результат (файловий або гіпертекстовий). За своєю суттю веб-хостинг і веб-сервер поняття ідентичні. Веб сервер Nginx і apache - що це і як працює дана зв'язка? Відповідь на це питання.

Сервера баз даних. У більшості всі програми використовують бази даних. Даний вид серверів забезпечують доступ до даних за допомогою системи клієнт-сервер. Найпопулярнішими серверами баз даних є SQL SERVER (Microsoft), SQL BASE SERVER, Oracle SERVER (Oracle Corporation), IBM DB2, Informix. Вони працюють на платформі різних ОС, таких як MSDOS, OS / 2, Xenix, Unix.

Проксі-сервер - можна сказати, що це той же веб-сервер, але він здійснює запити в мережі замість відвідувача. Це по суті комплекс програм. Ви підключаєтеся до проксі-сервера, даєте йому запит, а він шукає інформацію замість Вас, в деяких випадках змінюючи її. Робота з проксі-сервером дозволяє захистити комп'ютер клієнта від шкідливих програм, бути анонімним в мережі, обмежити доступ до певних ресурсів або навпаки обійти заборони. проста установка проксі сервера на свій VPS за 1 хвилину, докладніше.

Ігровий сервер забезпечує зв'язок між клієнтами в мережі. Клієнти взаємодіють в грі і спілкуються між собою. Даний сервер отримує інформацію, обробляє запити, оновлює систему і розсилає результати всім учасникам гри. В основному, ігрові сервера розміщують у себе хостинг-компанії.

У наш час дуже важко уявити роботу підприємства без використання серверів. У цьому трудомісткий процес беруть участь сервера всіх типів.

Причини, за якими можна визначити, чи потрібно для вашої фірми?

• Ви бажаєте систематизувати і централізувати всю інформацію, яка знаходиться у вашій компанії.
• Багатьом співробітникам необхідно підключатися до мережі, незалежно від місця їх знаходження.
• Вам необхідно багато місця для зберігання інформації.
• Ви плануєте запустити програмне забезпечення, яке допоможе розвитку вашого бізнесу.
• Ваша компанія розвивається і росте, кількість співробітників постійно збільшується.
• Ваш бізнес не дуже великий, але Ви хочете виглядати як справжній професіонал.

Від правильності вибору сервера залежить успішна робота компанії, адже сервера допомагають організувати безперебійне функціонування підприємства, і пов'язують окремі підрозділи, наприклад, ті, які знаходяться в різних містах.

фахівці компанії HyperHost із задоволенням підберуть найбільш оптимальний фізичний або, за всіма параметрами, сервер і забезпечать стабільність Ваших проектів. Порівняння також допоможе зробити вам правильний вибір і правильно підібрати послугу в залежності від поставленої мети.

Необхідно вибрати операційну систему для роботи сервера? Дана допоможе вам зробити правильний вибір і оцінити всі можливості кожної ОС. Про панелях управління для серверів з Linux.

42788 раз (а) 18 Сьогодні переглянуто раз (а)

Сервер - це якась програма, апарат або програмно-апаратний комплекс, який реалізує якісь сервіси. У свою чергу сервіс - це служба, яка виконує якісь дії, запитувані клієнтом. Давайте розглянемо уважніше, як працює сервер.

Складові клієнт-серверної схеми

Подивимося, з чого складається сам сервер і без яких зовнішніх компонент він не може обходитися. По-перше, сервер втрачає свій сенс за відсутності клієнтів. Принцип роботи сервера - реалізовувати потреби клієнтів. Клієнт формує вимоги до сервера і бере на себе деяку частку його роботи. Тому частіше говорять не просто про сервер, а про систему клієнти-сервер. Клієнт складає запити до сервера, за допомогою яких виявляють свою волю. Тому наступним, другим компонентом системи буде той формальний мову, на якому ці запити складаються. Цих мов велика кількість і вибір того чи іншого напряму залежить від сервера. Запити до сервера повинні якось доставлятися. Третій елемент - канал зв'язку клієнта і сервера, по якому передаються дані. Це найчастіше або локальна мережа, або Інтернет, або локальні зв'язку однієї машини. Прийшовши запит сервер повинен якось прийняти і розпізнати. Приймаючий пристрій - так званий зовнішній інтерфейс, являє собою кілька портів, які сервер безперервно (або не безупинно) слухає. Прийняті запити відправляються в програмну частину сервера, де й обробляються відповідно до того, як сервер запрограмований. І в залежності від прийнятого запиту, запускається той чи інший сервіс з тими чи іншими початковими даними. Сервіси і будуть останньою складовою системи. Після закінчення роботи сервісу результат виконання надсилається клієнту по тому ж каналу зв'язку. Або, якщо сервіс інтерактивний, то і в процесі його роботи буде інтенсивний обмін даними по каналу «клієнт-сервер».

Для чого потрібен сервер

Зараз основне призначення клієнт-серверних систем - перемістити навантаження з машин-клієнтів на машину сервер. Саме тому обчислювальна потужність звичайного сервера на пару порядків вище, ніж она у звичайного домашнього комп'ютера. Але іноді така організація роботи системи віддає всю навантаження на клієнти, а сервер служить для організації їх роботи та взаємодії. Або строго навпаки, сервер виконує всі обчислення, а клієнти служать лише для видачі інформації користувачеві. Як видно, способів використовувати клієнт-серверну модель маса.

Плюси і мінуси моделі

Плюси очевидні - сам принцип роботи сервера забезпечує зручність роботи з системою, простоту управління нею, правильний розподіл навантаження на машини. А мінусом є мова запитів і пов'язані з ним компоненти. Якщо користувач випадково або навмисно відсилає на сервер невірно сформульований запит, то якщо така помилка не була передбачена програмістом, система дасть збій. Обізнані люди складають свідомо невірні запити так, щоб система, покликана видавати клієнту прогноз погоди, вивела зловмисникові, наприклад, дані кредитних карт всіх користувачів (якщо, звичайно, за дані карт і за прогноз погоди відповідає один і той же сервер). І щасливий зловмисник спочатку йде і перераховує собі всі гроші всіх користувачів сервісу, а потім довго і вдумливо тікає від управління «К», що розслідує цей злочин.

Безпека

Клієнт-серверна модель організації роботи системи - дуже зручна в програмуванні, управлінні і роботі річ. Але щоб такий системою можна було користуватися, кожна компонента працюючої схеми повинна бути захищена як від зловмисників, так і від користувачів, які не знають, як працює сервер, але жмущих все кнопочки, до яких зможуть дотягнутися в довільній послідовності. Щоб в системі можна було зберігати, передавати і обробляти важливі дані, наприклад, відомості про платіжні картки, система інформаційної безпеки сервера має задовольняти певним законом вимогам.

Будь-яке обладнання, в тому числі і серверне, іноді починає працювати непередбачувано. Абсолютно не важливо - нове чи це обладнання, або ж воно вже кілька років працює з повним навантаженням.

Випадків збою і некоректної роботи виникає безліч і діагностика проблеми часто перетворюється в захоплюючу головоломку.

Нижче ми розповімо про деякі цікаві і нетривіальних випадках.

виявлення неполадок

Реєстрація проблеми найчастіше відбувається після звернення клієнтів в службу технічної підтримки за допомогою тікет-системи.

У разі звернення клієнта, який орендує у нас виділені сервери фіксованою конфігурації, ми проводимо діагностику, щоб з'ясувати, що проблема не носить програмний характер.

Проблеми програмного характеру клієнти зазвичай вирішують власними силами, проте, ми в будь-якому випадку ми намагаємось запропонувати допомогу наших системних адміністраторів.

Якщо стає ясно, що проблема апаратна (наприклад, сервер не бачить частину оперативної пам'яті), то на цей випадок у нас завжди є в резерві аналогічна серверна платформа.

У разі виявлення апаратної проблеми ми переносимо диски зі збійного сервера на резервний і, після невеликої перенастроювання мережевого обладнання, виконується запуск сервера в роботу. Таким чином дані не втрачаються, а час простою не перевищує 20 хвилин з моменту звернення.

Приклади неполадок і способи їх усунення

Збій в роботі мережі на сервері

Існує ймовірність, що після перенесення дисків з збійного сервера на резервний перестане працювати мережа на сервері. Це зазвичай відбувається в разі використання операційних систем сімейства Linux, наприклад Debian або Ubuntu.

Справа в тому, що при першій установці операційної системи, MAC-адреси мережевих карт записуються в спеціальний файл, розташований за адресою: /etc/udev/rules.d/70-persistent-net.rules.

При старті операційної системи цей файл зіставляє імена інтерфейсів MAC-адресами. При заміні сервера на резервний, MAC-адреси мережевих інтерфейсів вже не збігаються, що і призводить до непрацездатності мережі на сервері.

Для вирішення проблеми необхідно видалити вказаний файл і перезапустити мережевий сервіс, або перезавантажити сервер.

Операційна система, не знайшовши цього файлу, автоматично згенерує аналогічний і порівняє інтерфейси вже з новими MAC-адресами мережевих карт.

Перенастроювання IP-адрес після цього не потрібно, мережа відразу почне працювати.

Плаваюча проблема з зависаннями

Одного разу до нас на діагностику надійшов сервер з проблемою випадкових зависань в процесі роботи. Перевірили логи BIOS і IPMI - порожньо, ніяких помилок. Поставили на стрес-тестування, навантаживши все ядра процесора на 100%, з одночасним контролем температури - завис намертво через 30 хвилин роботи.

При цьому процесор працював штатно, значення температури не перевищували стандартних при навантаженні, все кулери були справні. Стало ясно, що справа не в перегрів.

Далі слід було виключити ймовірні збої модулів оперативної пам'яті, тому поставили сервер на тест пам'яті за допомогою досить популярного Memtest86 +. Хвилин через 20 сервер очікувано завис, видавши помилки по одному з модулів оперативної пам'яті.

Замінивши модуль на новий, ми поставили сервер на тест повторно, однак нас чекало фіаско - сервер знову завис, видавши помилки вже по іншому модулю ОЗУ. Замінили і його. Ще один тест - ще раз завис, знову видавши помилки по оперативної пам'яті. Уважний огляд слотів ОЗУ не виявив ніяких дефектів.

Залишався один можливий винуватець проблеми - центральний процесор. Справа в тому, що контролер оперативної пам'яті розташований саме всередині процесора і саме він міг давати збій.

Знявши процесор, виявили катастрофу - один пін сокета був зламаний у верхній частині, обламані кінчик Піна буквально прикипів до контактної майданчику процесора. У підсумку, коли на сервері не було навантаження, все працювало адекватно, але при збільшенні температури процесора контакт порушувався, тим самим припиняючи нормальну роботу контролера оперативної пам'яті, що і викликало зависання.

Остаточно проблема вирішилася заміною материнської плати, оскільки відновити зламався пін сокета нам, на жаль, не під силу, і це вже завдання для сервісного центру.

Уявне зависання сервера при установці ОС

Досить кумедні випадки виникають, коли виробники обладнання починають міняти архітектуру апаратної частини, відмовляючись від підтримки старих технологій на користь нових.

До нас звернувся користувач зі скаргою на зависання сервера при спробі установки операційної системи Windows Server 2008 R2. Після успішного запуску інсталятора, сервер припиняв реагувати на мишу і клавіатуру в KVM-консолі. Для локалізації проблеми підключили до сервера фізичну миша і клавіатуру - все те ж саме, інсталятор запускається і перестає реагувати на пристрої введення.

На той момент цей сервер у нас був одним з перших на базі материнської плати X11SSL-f виробництва Supermicro. В налаштуваннях BIOS був один цікавий пункт Windows 7 install, виставлений в Disable. Оскільки Windows 7, 2008 і 2008 R2 розгортаються на одному і тому ж інсталятор, виставили цей параметр в Enable і чудесним чином миша і клавіатура нарешті запрацювали. Але це було лише тільки початок епопеї з установкою операційної системи.

На момент вибору диска для установки жодного диска з'являлося, більш того, видавалася помилка необхідності установки додаткових драйверів. Операційна система встановлювалася з USB-флешки і швидкий пошук в інтернеті показав, що такий ефект виникає, якщо програма установки не може знайти драйвера для контролера USB 3.0.

Вікіпедія повідомила, що проблема вирішується відключенням в BIOS підтримки USB 3.0 (XHCI-контролера). Коли ми відкрили документацію до материнської плати, нас чекав сюрприз - розробники вирішили повністю відмовитися від контролера EHCI (Enhanced Host Controller Interface) на користь XHCI (eXtensible Host Controller Interface). Іншими словами, всі порти USB на цій материнській платі є портами USB 3.0. І якщо відключити контролер XHCI, то ми цим самим відключимо і пристрої введення, унеможлививши роботу з сервером і відповідно установку операційної системи.

Оскільки серверні платформи були обладнані приводами для читання CD / DVD дисків, єдиним вирішенням проблеми стало інтегрування драйверів безпосередньо в дистрибутив операційної системи. Тільки інтегрувавши драйвера контролера USB 3.0 і пересобран інсталяційний образ, ми змогли встановити Windows Server 2008 R2 на цей сервер, а цей випадок увійшов в нашу базу знань, щоб інженери не витрачали зайвий час на безплідні спроби.

Ще цікавіша бувають випадки, коли клієнти привозять нам обладнання на розміщення, а воно веде себе не так, як очікується. Саме так і сталося з дисковою полицею лінійки Dell PowerVault.

Пристрій являє собою систему зберігання даних c двома дисковими контролерами і мережевими інтерфейсами для роботи по протоколу iSCSI. Крім цих інтерфейсів присутній MGMT-порт для віддаленого управління.

Серед наших послуг для розміщеного обладнання якраз є спеціальна послуга «Додатковий порт 10 Мбіт / с», яку замовляють у разі потреби підключення засобів віддаленого управління сервером. Ці кошти мають різні назви:

• «ILO» у Hewlett-Packard;
• «IDrac» у Dell;
• IPMI у Supermicro.

Функціонал у них приблизно однаковий - моніторинг стану сервера і доступ до віддаленої консолі. Відповідно велика швидкість каналу їм не потрібно - 10 Мбіт / с цілком достатньо для комфортної роботи. Саме ця послуга і була замовлена \u200b\u200bклієнтом. Ми проклали відповідну мідну кроссіровкі, і налаштували порт нашого мережевого обладнання.

Для обмеження швидкості порт просто налаштовується як 10BASE-T і включається в роботу, маючи максимальну швидкість в 10 Мбіт / с. Після того, як все було готово - ми підключили MGMT-порт дискової полки, але клієнт майже відразу повідомив, що у нього нічого не працює.

Перевіривши стан порту комутатора, ми виявили неприємну напис «Physical link is down». Такий напис говорить, що є проблеми з фізичним з'єднанням між комутатором і підключеним до нього клієнтським обладнанням.

Погано обтиснутий коннектор, зламаний роз'єм, перебиті жили в кабелі - ось невеликий перелік проблем, які призводять саме до відсутності линка. Зрозуміло, наші інженери одразу взяли тестер кручений пари і перевірили з'єднання. Всі жили ідеально продзвонювати, обидва кінці кабелю були обтиснуті ідеально. До того ж, включивши в цей кабель тестовий ноутбук, ми отримали як і належить з'єднання зі швидкістю 10 Мбіт / с. Стало ясно, що проблема на стороні обладнання клієнта.

Оскільки ми завжди намагаємося допомогти нашим клієнтам у вирішенні проблем, вирішили розібратися, що саме викликає відсутність линка. Уважно вивчили роз'єм порту MGMT - все в порядку.

Знайшли на сайті виробника оригінальну інструкцію по експлуатації, щоб уточнити - чи можливо з боку програмного забезпечення «погасити» даний порт. Однак такої можливості не передбачалося - порт в будь-якому випадку піднімався автоматично. Незважаючи на те, що подібне обладнання повинно завжди підтримувати Auto-MDI (X) - іншими словами правильно визначати який кабель включений: звичайний або кросовер, ми експерименту заради обжав кросовер і включили в той же порт комутатора. Пробували примусово виставляти параметр дуплексу на порту комутатора. Ефект був нульовий - линка не було і ідеї вже закінчувалися.

Тут хтось з інженерів висловив абсолютно суперечить здоровому глузду припущення, що обладнання не підтримує 10BASE-T і буде працювати тільки на 100BASE-TX або навіть на 1000BASE-X. Зазвичай будь-який порт, навіть на самому дешевому пристрої сумісний з 10BASE-T і спочатку припущення інженера мілини як "фантастику", але від безвиході вирішили спробувати переключити порт в 100BASE-TX.

Нашому здивуванню не було меж, лінк миттєво піднявся. Чим саме обумовлено відсутність підтримки 10BASE-T на порту MGMT залишається загадкою. Такий випадок - дуже велика рідкість, але має місце бути.

Клієнт був здивований не менше нашого і дуже дякував за вирішення проблеми. Відповідно до нього так і залишили порт в 100BASE-TX, обмеживши швидкість на порту безпосередньо за допомогою вбудованого механізму обмеження швидкості.

Відмова турбін охолодження

Якось раз до нас приїхав клієнт, попросив зняти сервер і винести його в сервісну зону. Інженери все зробили і залишили його наодинці з обладнанням. Минула година, друга, третя - клієнт весь час запускав / зупиняв сервер і ми поцікавилися, в чому ж полягає проблема.

Виявляється, що у сервера виробництва Hewlett-Packard відмовило дві турбіни охолодження з шести. Сервер при цьому включається, видає помилку по охолодженню і відразу вимикається. При цьому на сервері розташовується гипервизор з критичними сервісами. Для відновлення штатної роботи сервісів потрібно виконати термінову міграцію віртуальних машин на іншу фізичну ноду.

Вирішили клієнту допомогти наступним чином. Зазвичай сервер розуміє, що з вентилятором охолодження все добре, просто зчитуючи кількість обертів. При цьому, зрозуміло, інженери Hewlett-Packard зробили все, щоб не можна було замінити оригінальну турбинку аналогом - нестандартний коннектор, нестандартна терморегулятори.

Оригінал такої деталі коштує близько $ 100 і її не можна просто так піти і купити - треба замовляти з-за кордону. Благо в інтернеті виявили схему з оригінальною терморегулятори і з'ясували, що один з пинов якраз відповідає за зчитування кількості оборотів двигуна в секунду.

Подальше було справою техніки - взяли пару проводів для прототипування (волею випадку опинилися під рукою - деякі наші інженери захоплюються Arduino) і просто з'єднали Піни від сусідніх робочих турбінок з коннекторами вийшли з ладу. Сервер запустився і клієнту нарешті вдалося виконати міграцію віртуальних машин і запустити сервіси в роботу.

Зрозуміло, що все це було виконано виключно під відповідальність клієнта, проте в підсумку такий нестандартний хід дозволив скоротити простої до мінімуму.

А де ж диски?

У деяких випадках причина проблеми часом настільки нетривіальна, що на її пошук йде дуже багато часу. Так і вийшло, коли один з наших клієнтів поскаржився на випадковий відвал дисків і зависання сервера. Апаратна платформа - Supermicro в корпусі 847 (форм-фактора 4U) з кошиками для підключення 36-ти дисків. У сервері було встановлено три однакових RAID-контролера Adaptec, до кожного підключено по 12 дисків. У момент виникнення проблеми, сервер переставав бачити випадкове кількість дисків і зависав. Сервер вивели з продакшн і приступили до діагностики.

Перше, що вдалося з'ясувати - диски відвалювалися тільки на одному контролері. При цьому «випали диски» зникали зі списку в рідній утиліті управління Adaptec і заново там з'являлися тільки при повному відключенні живлення сервера і наступному підключенні. Перше, що спало на думку - програмне забезпечення контролера. На всіх трьох контролерів стояли трохи різні прошивки, тому було вирішено на всіх контролерах встановити одну версію прошивки. Виконали, поганяли сервер в режимах максимального навантаження - все працює як годиться. Помітивши проблему як вирішену, сервер віддали клієнтові назад в продакшн.

Через два тижні знову звернення з тією ж проблемою. Було вирішено замінити контролер на аналогічний. Виконали, прошили, підключили, поставили на тести. Проблема залишилася - через пару днів випали всі диски вже на новому контролері і сервер благополучно завис.

Переустановили контролер в інший слот, замінили бекплейн і SATA-кабелі від контролера до бекплейна. Тиждень тестів і знову диски випали - сервер знову завис. Звернення на підтримку Adaptec результатів не принесло - вони перевірили всі три контролера і проблем не виявили. Замінили материнську плату, пересобран платформу мало не з нуля. Все, що викликало найменші сумніви замінили на нове. І проблема знову проявилася. Містика та й годі.

Проблему вдалося вирішити випадково, коли стали перевіряти окремо кожен диск. При певному навантаженні один з дисків починав стукати головами і давав коротке замикання на порт SATA, при цьому будь-яка аварійна індикація відсутня. Контролер при цьому переставав бачити частину дисків і знову починав їх впізнавати тільки при перепідключенні по харчуванню. Ось так один єдиний зіпсований диск виводив з ладу всю серверну платформу.

висновок

Звичайно, це лише мала частина цікавих ситуацій, які були вирішені нашими інженерами. Деякі проблеми «відловити» досить непросто, особливо коли в логах немає ніяких натяків на що стався збій. Зате будь-які подібні ситуації стимулюють інженерів детально розбиратися в пристрої серверного обладнання і знаходити найрізноманітніші рішення проблем.

Ось такі кумедні випадки були в нашій практиці.
А з якими стикалися ви? Ласкаво просимо в коментарі.

Що таке веб-сервер? З точки зору обивателя - це якийсь чорний ящик, який обробляє запити браузера і видає у відповідь веб-сторінки. Технічний фахівець засипле вас масою малозрозумілих термінів. В результаті початківцям адміністраторам веб-серверів буває деколи важко розібратися у всьому різноманітті термінів і технологій. Дійсно, область веб-розробки динамічно розвивається, але в основі багатьох сучасних рішень лежать базові технології та принципи, про які ми сьогодні і поговоримо.

Якщо не знаєш з чого почати, то починати треба спочатку. Щоб не заплутатися у всьому різноманітті сучасних веб-технологій потрібно звернутися до історії, щоб зрозуміти, з чого починався сучасний інтернет і як розвивалися і удосконалювалися технології.

HTTP-сервер

На зорі розвитку інтернету сайти представляли собою просте сховище спеціальним чином розмічених документів і деяких пов'язаних з ними даних: файлів, зображень і т.п. Для того, щоб документи могли посилатися один на одного і пов'язані дані був запропонований спеціальний мову гіпертекстової розмітки HTML, а для доступу до таких документів за допомогою мережі інтернет протокол HTTP. І мова, і протокол, розвиваючись і вдосконалюючись, дожили до наших днів без істотних змін. І тільки почав приходити на зміну прийнятого в 1999 році протоколу HTTP / 1.1 протокол HTTP / 2 несе кардинальні зміни з урахуванням вимог сучасної мережі.

Протокол HTTP реалізовано по клієнт-серверної технології і працює за принципом запит-відповідь без збереження стану. Метою запиту служить якийсь ресурс, який визначається єдиним ідентифікатором ресурсу - URI (Uniform Resource Identifier), HTTP використовує одну з різновидів URI - URL (Uniform Resource Locator) - універсальний покажчик ресурсу, Який крім відомостей про ресурс визначає також його фізичне місце розташування.

Завдання HTTP-сервера обробити запит клієнта і або видати йому необхідний ресурс, або повідомити про неможливість це зробити. Розглянемо наступну схему:

Користувач за допомогою HTTP-клієнта, найчастіше це браузер, запитує у HTTP-сервера якийсь URL, сервер перевіряє і віддає відповідний цьому URL-файл, зазвичай це HTML-сторінка. Отриманий документ може містити посилання на відповідні ресурси, наприклад, зображення. Якщо їх потрібно відображати на сторінці, то клієнт послідовно запитує їх у сервера, крім зображень також можуть бути запитані таблиці стилів, скрипти, що виконуються на стороні клієнта і т.д. Отримавши всі необхідні ресурси браузер обробить їх згідно коду HTML-документа і видасть користувачеві готову сторінку.

Як вже багато хто здогадався, під ім'ям HTTP-сервера в даній схемі знаходиться сутність, яка більш відома сьогодні під назвою веб-сервер. Основна мета і завдання веб-сервера - обробка HTTP-запитів і повернення користувачеві їх результатів. Веб-сервер не вміє самостійно генерувати контент і працює тільки зі статичним вмістом. Це актуально і для сучасних веб-серверів, незважаючи на все багатство їх можливостей.

Довгий час одного веб-сервера було досить для реалізації повноцінного сайту. Але в міру зростання мережі інтернет можливостей статичного HTML стало гостро бракувати. Простий приклад: кожна статична сторінка самодостатня і повинна містити посилання на всі пов'язані з нею ресурси, при додаванні нових сторінок посилання на них потрібно додати на вже існуючі сторінки, інакше користувач ніколи не зможе потрапити на них.

Сайти того часу взагалі мало походили на сучасні, наприклад, нижче показаний вид одного з піонерів російськомовного інтернету, сайт компанії Rambler:

А перехід уздовж будь-яких посилань взагалі може привести сучасного користувача в подив, повернутися назад з такою сторінки не представляється можливим, крім як через натискання однойменної кнопки в браузері.

Спроба створити щось більш-менш схоже на сучасний сайт дуже скоро перетворювалася в наростаючий обсяг робіт по внесенню змін у вже існуючі сторінки. Адже якщо ми щось поміняли в загальній частині сайту, наприклад, логотип в шапці, то нам потрібно внести цю зміну на всі існуючі сторінки. А якщо ми змінили шлях до однієї зі сторінок або видалили її, то нам треба буде знайти всі посилання на неї і змінити або видалити їх.

Тому наступним кроком у розвитку веб-серверів стала підтримка технології включення на стороні сервера - SSI (Server Side Includes). Вона дозволяла включати в код сторінки вміст інших файлів, що давало можливість винести повторювані елементи, такі як шапка, підвал, меню і т.п. в окремі файли і просто підключати при остаточному складанні сторінки.

Тепер, щоб змінити логотип або пункт меню зміни треба буде внести лише в один файл, замість редагування всіх існуючих сторінок. Крім того, SSI дозволяв виводити на сторінки деякий динамічний вміст, наприклад, актуальну дату і виконувати нескладні умови і працювати зі змінними. Це був значний крок вперед, полегшував працю вебмайстрів і підвищує зручність користувачів. Однак реалізувати по-справжньому динамічний сайт дані технології все ще не дозволяли.

Варто відзначити, що SSI активно застосовується і сьогодні, там, де в код сторінки потрібно вставити якийсь статичний контент, перш за все завдяки простоті і невибагливість до ресурсів.

CGI

Наступним кроком у розвитку веб-технології стала поява спеціальних програм (скриптів) виконують обробку запиту користувачів на стороні сервера. Найчастіше вони пишуться на скриптових мовах, спочатку це був Perl, сьогодні пальму лідерства утримує PHP. Поступово виник цілий клас програм - системи управління контентом - CMS (Content management system), Які представляють повноцінні веб-додатки здатні забезпечити динамічну обробку запитів користувача.

Тепер важливий момент: веб-сервера не вміли і не вміють виконувати скрипти, їх завдання - віддача статичного вмісту. Тут на сцену виходить нова сутність - сервер додатків, який представляє собою інтерпретатор скриптових мов і за допомогою якого працюють написані на них веб-додатки. Для зберігання даних зазвичай використовуються СУБД, що обумовлено необхідністю доступу до великої кількості взаємозалежної інформації.

Однак сервер додатків не вміє працювати з протоколом HTTP і обробляти запити користувачів, так як це завдання веб-сервера. Щоб забезпечити їх взаємодію був розроблений загальний інтерфейс шлюзу - CGI (Common Gateway Interface).

Слід чітко розуміти, CGI - це не програма і не протокол, це саме інтерфейс, тобто сукупність способів взаємодії між додатками. Також не слід плутати термін CGI з поняттям CGI-додатки або CGI-скрипта, якими позначають програму (скрипт) підтримуючу роботу через інтерфейс CGI.

Для передачі даних використовуються стандартні потоки введення-виведення, від веб-сервера до СGI-додатком дані передаються через stdin, Приймаються назад через stdout, Для передачі повідомлень про помилки використовується stderr.

Розглянемо процес роботи такої системи докладніше. Отримавши запит від браузера користувача веб-сервер визначає, що запитано динамічний вміст і формує спеціальний запит, якій через інтерфейс CGI направляє веб-додатком. При його отриманні під час запуску програми і виконує запит, результатом якого є HTML-код динамічно сформованої сторінки, який передається назад веб-сервера, після чого додаток завершує свою роботу.

Ще одна важлива відмінність динамічного сайту - його сторінки фізично не існують в тому вигляді, який віддається користувачеві. Фактично є веб-додаток, тобто набір скриптів та шаблонів, і база даних, яка зберігає матеріали сайту і службову інформацію, окремо розташовується статичну вміст: картинки, java-скрипти, файли.

Отримавши запит веб-додаток отримує дані з БД і заповнює ними вказаний в запиті шаблон. Результат віддається веб-сервера, який доповнює сформовану таким чином сторінку статичним вмістом (зображення, скрипти, стилі) і віддає її браузеру користувача. Сама сторінка при цьому ніде не зберігається, хіба що в кеші, і при отриманні нового запиту відбудеться повторна генерація сторінки.

До переваг CGI можна віднести мовну і архітектурну незалежність: CGI-додаток може бути написано на будь-якій мові і однаково добре працювати з будь-яким веб-сервером. З огляду на простоту і відкритість стандарту це призвело до бурхливого розвитку веб-додатків.

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

На поточний момент CGI практично не застосовується, так як йому на зміну прийшли більш досконалі технології.

FastCGI

Як випливає з назви, основною метою розробки даної технології було підвищення продуктивності CGI. Будучи її подальшим розвитком FastCGI є клієнт-серверний протокол для взаємодії веб-сервера і сервера додатків, що забезпечує високу продуктивність і безпеку.

FastCGI усуває основну проблему CGI - повторний запуск процесу веб-додатки на кожен запит, FastCGI процеси запущені постійно, що дозволяє істотно економити час і ресурси. Для передачі даних замість стандартних потоків використовуються UNIX-сокети або TCP / IP, Що дозволяє розміщувати веб-сервер і сервера додатків на різних хостах, таким чином забезпечуючи масштабування і / або високу доступність системи.

Також ми можемо запустити на одному комп'ютері кілька FastCGI процесів, які можуть обробляти запити паралельно, або мати різні настройки або версії скриптового мови. Наприклад, можна одночасно мати кілька версій PHP для різних сайтів, направляючи їх запити різних FastCGI процесам.

Для управління FastCGI процесами і розподілом навантаження служать менеджери процесів, вони можуть бути як частиною веб-сервера, так і окремими додатками. Популярні веб-сервера Apache і Lighttpd мають вбудовані менеджери FastCGI процесів, в той час як Nginx вимагає для своєї роботи c FastCGI зовнішній менеджер.

PHP-FPM і spawn-fcgi

Із зовнішніх менеджерів для FastCGI процесів застосовуються PHP-FPM і spawn-fcgi. PHP-FPM спочатку був набором патчів до PHP від \u200b\u200bАндрія Нігматуліна, вирішував ряд питань управління FastCGI процесами, починаючи з версії 5.3 є частиною проекту і входить в поставку PHP. PHP-FPM вміє динамічно управляти кількістю процесів PHP в залежності від навантаження, перезавантажувати пули без втрати запитів, аварійний перезапуск збійних процесів і являє собою досить просунутий менеджер.

Spawn-fcgi є частиною проекту Lighttpd, але до складу однойменного веб-сервера не входить, за замовчуванням Lighttpd використовує власний, більш простий, менеджер процесів. Розробники рекомендують використовувати його в випадках, коли вам потрібно управляти FastCGI процесами розташованими на іншому хості, або потрібні додаткові параметри безпеки.

Зовнішні менеджери дозволяють ізолювати кожен FastCGI процес в своєму chroot (зміна кореневого каталогу програми без можливості доступу за його межі), відмінному як від chroot інших процесів, так і від chroot веб-сервера. І, як ми вже говорили, дозволяють працювати з FastCGI додатками розташованими на інших серверах через TCP / IP, в разі локального доступу слід вибирати доступ через UNIX-сокет, як швидкий тип з'єднання.

Якщо знову подивитися на схему, то ми побачимо, що у нас з'явився новий елемент - менеджер процесів, який є посередником між веб-сервером і серверами додатків. Це дещо ускладнює схему, так як налаштовувати і супроводжувати доводиться більшу кількість служб, але в той же час відкриває ширші можливості, дозволяючи налаштувати кожен елемент сервера чітко під свої завдання.

На практиці, вибираючи між вбудованим менеджером і зовнішнім розсудливо оцініть ситуацію і вибирайте саме той інструмент, який найбільш підходить до ваших потреб. Наприклад, створюючи простий сервер для декількох сайтів на типових двигунах застосування зовнішнього менеджера буде явно зайвим. Хоча ніхто не нав'язує вам своєї точки зору. Linux тим і хороший, що кожен може, як з конструктора, зібрати саме те, що йому треба.

SCGI, PCGI, PSGI, WSGI та інші

Занурюючись в тему веб-розробки, ви неодмінно будете зустрічатися зі згадуванням різних CGI-технологій, найбільш популярні з яких ми перерахували в заголовку. Від такого різноманіття можна і розгубитися, але якщо ви уважно прочитали початок нашої статті, то знаєте, як працює CGI і FastCGI, а, отже, розібратися з будь-якої з цих технологій не складе для вас праці.

Незважаючи на відмінності в реалізаціях того чи іншого рішення базові принципи залишаються загальними. Всі ці технології надають інтерфейс шлюзу ( Gateway Interface) Для взаємодії веб-сервера з сервером додатків. Шлюзи дозволяють розв'язати між собою середовища веб-сервера і веб-додатки, дозволяючи використовувати будь-які поєднання без оглядки на можливу несумісність. Простіше кажучи, неважливо, чи підтримує ваш веб-сервер конкретну технологію або скриптова мова, головне, щоб він вмів працювати з потрібним типом шлюзу.

І якщо вже ми перерахували в заголовку цілу пачку абревіатур, то пройдемо по ним більш докладно.

SCGI (Simple Common Gateway Interface) - простий спільний інтерфейс шлюзу - розроблений як альтернатива CGI і багато в чому аналогічний FastCGI, але більш простий в реалізації. Все, про що ми розповідали стосовно FastGCI справедливо і для SCGI.

PCGI (Perl Common Gateway Interface) - бібліотека Perl для роботи з інтерфейсом CGI, довгий час була основним варіантом роботи з Perl-додатками через CGI, відрізняється хорошою продуктивністю (наскільки це може бути застосовано до CGI) при скромних потреби у ресурсах і непоганий захисту від перевантаження.

PSGI (Perl Web Server Gateway Interface) - технологія взаємодії веб-сервера і сервера додатків для Perl. Якщо PCGI являє собою інструмент для роботи з класичним CGI інтерфейсом, то PSGI більш нагадує FastCGI. PSGI-сервер являє середу для виконання Perl-додатків яка постійно запущена в якості служби і може взаємодіяти з веб-сервером через TCP / IP або UNIХ-сокети і надає Perl-додатків ті ж переваги, що і FastCGI.

WSGI (Web Server Gateway Interface) - ще один специфічний інтерфейс шлюзу, призначений для взаємодії веб-сервера з сервером додатків для програм, написаних на мові Phyton.

Як неважко помітити, всі перераховані нами технології є в тій чи іншій мірі аналогами CGI / FastCGI, але для специфічних областей застосування. Наведених нами даних буде цілком достатньо для загального розуміння принципу і механізмів їх роботи, а більш глибоке їх вивчення має сенс тільки при серйозній роботі з зазначеними технологіями та мовами.

Сервер додатків як модуль Apache

Якщо раніше ми говорили про якийсь абстрактний веб-сервері, то тепер мова піде про конкретному рішенні і справа тут не в наших перевагах. Серед веб-серверів Apache займає особливе місце, в більшості випадків, коли говорять про веб-сервері на платформі Linux, та й про веб-сервері взагалі, то матися на увазі буде саме Apache.

Можна сказати, що це свого роду веб-сервер "за замовчуванням". Візьміть будь-який масовий хостинг - там виявиться Apache, візьміть будь-який веб-додаток - настройки за замовчуванням виконані під Apache.

Так, з технологічної точки зору Apache не є вінцем технологій, але саме він представляє золоту середину, простий, зрозумілий, гнучкий в настройках, універсальний. Якщо ви робите перші кроки в Сайтобудування - то Apache ваш вибір.

Тут нас можуть дорікнути, що Apache вже давно неактуальне, все "реальні пацани" вже поставили Nginx і т.д. і т.п., тому пояснимо даний момент більш докладно. Всі популярні CMS з коробки сконфігуровані для використання спільно з Apache, це дозволяє зосередити всю увагу на роботу саме з веб-додатком, виключивши з можливого джерела проблем веб-сервер.

Всі популярні серед новачків форуми теж мають на увазі в якості веб-сервера Apache і більшість рад і рекомендацій будуть ставитися саме до нього. У той же час альтернативні веб-сервера як правило вимагають більш тонкої і ретельної настройки, як з боку веб-сервера, так і з боку веб-додатки. При цьому користувачі цих продуктів зазвичай набагато більш досвідчені і типові проблеми новачків в їх середовищі не обговорюються. В результаті може скластися ситуація, коли нічого не працює і запитати нема в кого. З Apache такого гарантовано не станеться.

Власне, що такого зробили розробники Apache, що дозволило їх дітищу зайняти особливе місце? Відповідь досить проста: вони пішли своїм шляхом. У той час як CGI пропонував абстрагуватися від конкретних рішень, зосередившись на універсальному шлюзі, в Apache вчинили по-іншому - максимально інтегрували веб-сервер і сервер додатків.

Дійсно, якщо запустити сервер додатків як модуль веб-сервера в загальному адресному просторі, то ми отримаємо набагато простішу схему:

Які переваги це дає? Чим простіше схема і менше в ній елементів, тим простіше і дешевше супроводжувати її і обслуговувати, тим менше в ній точок відмови. Якщо для одиничного сервера це може бути не так важливо, то в рамках хостингу це дуже важливий чинник.

Друга перевага - продуктивність. Знову засмутимо шанувальників Nginx, завдяки роботі в єдиному адресному просторі, по продуктивності сервера додатків Apache + mod_php завжди буде на 10-20% швидше будь-якого іншого веб-сервера + FastCGI (або інше CGI рішення). Але також слід пам'ятати, що швидкість роботи сайту обумовлена \u200b\u200bне тільки продуктивністю сервера додатків, але і рядом інших умов, в яких альтернативні веб-сервера можуть показувати значно кращий результат.

Але є ще одне, досить серйозна перевага, це можливість настройки сервера додатків на рівні окремого сайту або користувача. Давайте повернемося трохи назад: в FastCGI / CGI схемах сервер додатків - це окрема служба, зі своїми, окремими, настройками, яка навіть може працювати від імені іншого користувача або на іншому хості. З точки зору адміністратора одиночного сервера або якого-небудь великого проекту - це відмінно, але для користувачів і адміністраторів хостингу - не дуже.

Розвиток інтернету привело до того, що кількість можливих веб-додатків (CMS, скриптів, фреймворків і т.п.) стало дуже велике, а низький поріг входження привернув до сайтобудування велика кількість людей без спеціальних технічних знань. У той же час різні веб-додатки могли вимагати різної настройки сервера додатків. Як бути? Кожен раз звертатися в підтримку?

Рішення знайшлося досить просто. Так як сервер-додатків тепер частина веб-сервера, то можна доручити останньому управляти його настройками. Традиційно для управління настройками Apache крім конфігураційних файлів застосовувалися файли httaccess, які дозволяли користувачам писати туди свої директиви і застосовувати їх до тієї директорії, де розташований даний файл і нижче, якщо там настройки не перекриваються своїм файлом httaccess. У режимі mod_php дані файли дозволяють також змінювати багато опції PHP для окремого сайту або директорії.

Для прийняття змін не потрібно перезапуск веб-сервера і в разі помилки перестане працювати тільки цей сайт (або його частина). Крім того, внести зміни в простий текстовий файл і покласти його в папку на сайті під силу навіть непідготовленим користувачам і безпечно для сервера в цілому.

Поєднання всіх цих переваг і забезпечило Apache настільки широке застосування і статус універсального веб-сервера. Інші рішення можуть бути швидше, економічніше, краще, але вони завжди вимагають настройки під завдання, тому застосовуються в основному в цільових проектах, в масовому сегменті безальтернативно домінує Apache.

Поговоривши про достоїнства, перейдемо до недоліків. Деякі з них просто є зворотною стороною медалі. Той факт, що сервер додатків є частиною веб-сервера дає плюси в продуктивності і простоті настройки, але в той же час обмежує нас як з точки зору безпеки - сервер додатків завжди працює від імені веб-сервера, так і в гнучкості системи, ми не можемо рознести веб-сервер і сервер додатків на різні хости, не можемо використовувати сервера з різними версіями скриптового мови або різними настройками.

Другий мінус - більш високе споживання ресурсів. У схемі з CGI сервер додатків генерує сторінку і віддає її веб-сервера, звільняючи ресурси, зв'язка Apache + mod_php тримає ресурси сервера додатків зайнятими до тих пір, поки веб-сервер не віддасть вміст сторінки клієнту. Якщо клієнт повільний, то ресурси будуть зайняті на весь час його обслуговування. Саме тому перед Apache часто ставлять Nginx, який грає роль швидкого клієнта, це дозволяє Apache швидко віддати сторінку і звільнити ресурси, переклавши взаємодія з клієнтом на більш економічний Nginx.

висновок

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

Якщо щодня використовується комп'ютер, який підключений до мережі, якщо на мобільному гаджеті теж підключений Інтернет, то кожен користувач час від часу стикається зі словом - «сервер». Причому це слово може зустрічатися в різних поєднаннях, і не кожен користувач розуміє, про що йде мова. Що ж ховається до словом «сервер», та й навіщо він користувачам потрібен?

Під поняттям «сервер» може ховатися апаратний пристрій і програмне забезпечення для нього (апаратний і віртуальний). Апаратний сервер - це окремий комп'ютер. Він потрібен для забезпечення роботи інших ПК та офісної техніки. Віртуальний сервер - це ПЗ. При цьому конкретний сервер об'єднує ці два види.

Найперше слід пам'ятати, що в його завдання входить обслуговування мережі і користувачів, а не управління мережею. Користувачі самі ставлять завдання серверу, а він швидко їх вирішує. Чим якісніше сервер, наприклад, такий як сервери HP, тим якісніше він виконує свої обов'язки.

Роботу великих компаній, на яких встановлено багато електронного устаткування, уже важко уявити без об'єднання всі цих пристроїв в одну мережу. Сервер на підприємстві дозволяє віддаленого управляти офісною технікою та дозволяє взаємодіяти ПК між собою.

Поломка сервера або збій в його роботі може закінчитися катастрофою

На підприємствах сервери дозволяють оптимізувати роботу всіх відділів. Але і в повсякденному житті ми часто стикається з роботою серверів. Зокрема, операціоністи в касах і банках за допомогою сервера роздруковують документи і здійснюють проплати. Сервер підтримує роботу всіх поштовиків, соцмереж і менеджерів спілкування.

Сервер забезпечує вихід в Мережу. Всі сайти зберігаються на серверах. Це забезпечує віртуальний хостинг. Таку послугу надають хостингові компанії.