Пояснення способу доступу до мов програмування на стороні сервера

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

Я маю рацію, думаючи, що серверу просто потрібен якийсь інтерфейс, такий як CGI, щоб сервер і мова програмування працювали разом? Якщо так, то чому деякі мови програмування (наприклад, php) популярніші за інші?

У перші дні Інтернету CGI справді був єдиним (практичним) способом мати динамічний контент (ви можете робити іменовані файли файлів - і вони використовувалися за дні до cgi, але це зовсім не було практично).

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

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

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

Рішення цього полягає в тому, щоб видалити форкінг та exece, або перемістивши його в потік на самому веб-сервері, або переславши запит на інший процес, який обробляє запит, не потребуючи розщеплення та виконання. mod_perl - один з таких інструментів для цього (плагін, що рухається perl в apache). Php (кінець 90-х) також це робив, реалізуючи мову як плагін на самому веб-сервері, а не як роздрібнене і перевищуване. Це стало досить популярним, оскільки було схоже на перл (що було раннім домінуючим мовою веб-програмування) і може перевершити perl cgis. З цього періоду в середині 90-х ще є досить багато імпульсів - до того, як більш серверні сервери прикладних програм почали вживатися з більш формалізованими мовами позаду. Якщо копати,

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

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

Ось у чому річ - всі рішення певним чином, формою чи формою є дефіцитними. CGI, хоча easy має серйозні проблеми зі масштабом. Плагіни веб-серверів зв’язуються із самим веб-сервером (apache vs nginx vs IIS vs ...) і втрачають загальну функціональність мови. Microsoft має власний парад технологій, який хотів би просувати. І якщо ви знаєте одну мову, чи не хочете ви продовжувати програмування в ній, ніж мати різні мови в різних частинах стеку (javascript у клієнті та Node.js)?

І так, у вас сьогодні є. Деякі люди працюють у Java-стеці (коли масштаби і клоджури не стають рідкісними). Інші в стеку C #. Інші в стеку JavaScript. Там дуже багато php стеків. Багато пітона. Ви все ще можете знайти кілька стеків perl там (і якщо ви подивитеся на деякі сайти з невеликим обсягом, ви все одно знайдете CGI). За допомогою хмарних обчислень Google також просунув Go як життєздатну веб-мову, що працює на сервері.

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

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

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

Наприклад, я вважаю, що PHP став популярним для веб-сайтів, оскільки:

• Перейти зі статичного веб-сайту до динамічного веб-сайту PHP надзвичайно просто - просто замініть розширення файлу HTML-файлу, поставте <?phpтег на початку, і за умови встановлення PHP у вас є динамічний веб-сайт! Решта робочого процесу точно така ж, як і для статичного веб-сайту;
• Через таку простоту розгортання веб-хости, які хотіли запропонувати динамічні веб-сайти, обрали PHP, що зробило його досить швидко найбільш широко розгорненою платформою на сервері;
• Він потрапив на той ринок у потрібний час;

І після того, як PHP широко розгорнувся, стало цікаво писати більш серйозні веб-додатки в PHP, щоб скористатися такою широкістю розгортання.

Сказати це узагальнюючим способом: прийняття мови часто стосується відповідей на ці запитання:

• Наскільки легко робити те, що я хочу робити?
• Наскільки широко підтримується мова для того, що я хочу зробити?

Я маю рацію, думаючи, що серверу просто потрібен якийсь інтерфейс, такий як CGI, щоб сервер і мова програмування працювали разом?

Майже. Вам потрібен веб-сервер, який має якесь програмне забезпечення, яке також може відповідати на HTTP-запити.

Подумайте, як подається статична сторінка. Сервер отримує HTTP-запит, знаходить запитуваний документ із файлової системи на основі конфігурації сервера HTTP та повертає статичну сторінку.

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

 If so then why are some programming languages (such as php) more popular than others?

Стара структура CGI не набирає масштабів над великим обсягом запитів. Різні мови програмування та рамки для Інтернету існують з різних причин, і кожна з них робить добре різні речі. PHP настільки ж популярний, як і з історичних причин, оскільки був одним з перших простих і дешевих рішень для обслуговування динамічних сторінок, не вдаючись до CGI і мав широку підтримку хостингу. ASP був популярний серед кіл Microsoft, оскільки дозволив розробникам VB перенести свої навички в Інтернет. ASP.NET (Web Forms) дуже спростив розробників Windows Forms, багато з яких були кодерами VB, перейти на Інтернет.

Коли браузер робить HTTP-запит, це виглядає приблизно так:

GET /search?q=cats HTTP/1.0
Host: www.google.com
Connection: close

… На який сервер повинен надіслати відповідь, яка виглядає приблизно так:

HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>

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

$ nc -l 8000 <<'RESPONSE'
HTTP/1.0 200 Success
Content-Type: text/html; charset=UTF-8
Content-Length: 1337

<!DOCTYPE html>
<html>
  <head><title>cats - Google Search</title>
  <body>
    <h1>About 415,000,000 results</h1>
    …
  </body>
</html>
RESPONSE

Звичайно, ця методика ледве відповідає протоколу HTTP .

Крок від цієї консервованої відповіді - це проста програма Python, яка використовує http.serverбібліотеку в Python 3.

#!/usr/bin/python3

import http.server

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        payload = '<!DOCTYPE html>... insert cats here ...'.encode('UTF-8')
        self.send_response(200)
        self.send_header('Content-Type', 'text/html; charset=UTF-8')
        self.send_header('Content-Length', len(payload))
        self.end_headers()
        self.wfile.write(payload)

http.server.HTTPServer(('', 80), Handler).serve_forever()

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

Більш підходящим рішенням буде використання веб-сервера, такого як Apache HTTPD , IIS або nginx . Веб-сервер - це лише програма, яка прослуховує відповідні сокети TCP, приймає кілька запитів (можливо, одночасно) і вирішує, як генерувати відповідь на основі URL-адреси запиту, заголовків та інших правил. В ідеалі багато деталей, таких як SSL, контроль доступу та обмеження ресурсів, забезпечуються за допомогою конфігурації, а не коду. Значну частину часу веб-сервер формулює відповідь, що складається лише з вмісту з файлів у файловій системі.

Однак для динамічного вмісту веб-сервер може бути налаштований на виконання деякого коду для створення відповіді. Один з механізмів для цього є з CGI - сервер встановлює деякі змінні середовища на основі запиту, виконує програму та копіює свій вихід у сокет TCP. Трохи складнішим рішенням буде мати модуль, який додає підтримку веб-серверу для виклику коду іншою мовою програмування (наприклад, mod_php для Apache ). Ще один варіант - написати веб-сервер тією ж мовою, що й веб-додаток, і в такому випадку відправка запиту - це лише виклик функції. Це стосується двигунів node.js та сервлетів Java, таких як Apache Tomcat .

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

Веб-сервер - це програма, написана будь-якою мовою програмування, яка обробляє "веб-трафік" через сокет (и), що дотримуються стандартів / протоколів рівня додатків (HTTP тощо). Більшість мов програмування пропонують вам створити сокет.

Я маю рацію, думаючи, що серверу просто потрібен якийсь інтерфейс, такий як CGI, щоб сервер і мова програмування працювали разом?

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

Ви можете використовувати деяку бібліотеку серверів HTTP , наприклад, libonion , навіть у програмі, кодованій на C (або C ++, див. Також Wt ). Також є деяка клієнтська бібліотека HTTP (наприклад, libcurl )

Ви можете використовувати інші бібліотеки HTTP, наприклад ocsigen & ocamlnet для OCaml .

Існує кілька виділених веб-мов (за межами PHP), наприклад, Opa , HOP , Kaya тощо ... (і HOP, і Opa можуть легко змішувати обчислення на стороні сервера та браузера, але це потрібно робити болісно і вручну в PHP, явно використовуючи методи AJAX і ручне кодування деяких Javascript для браузера. На відміну від цього HOP, Opa, Ocsigen здатні генерувати цей Javascript).

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

C.Queinnec зауважив, що перегляд веб-сайтів та їх продовження істотно пов'язані.

PS. Мені не подобається PHP, і я вважаю, що його популярність має історичні та соціальні причини (не в основному технічні). Дійсно, PHP був широко поширений задовго до того, як AJAX став широко використовуватися, і старший за HOP або Opa (або Ocsigen).