Objaśnienie dostępu do języków programowania po stronie serwera

Rozumiem, że do tworzenia strony internetowej po stronie serwera można użyć dowolnego języka programowania ogólnego.

Czy mam rację, myśląc, że serwer potrzebuje tylko interfejsu, takiego jak CGI, aby serwer i język programowania działały razem? Jeśli tak, to dlaczego niektóre języki programowania (takie jak php) są bardziej popularne niż inne?

We wczesnych dniach Internetu CGI był rzeczywiście jedynym (praktycznym) sposobem na posiadanie dynamicznej zawartości (można było nazwać potoki plików - i były one używane kilka dni przed cgi, ale to wcale nie było praktyczne).

CGI polega na umieszczeniu szeregu informacji w środowisku procesu, który jest rozwidlany, a następnie wykonywany (i ewentualnie w stdin), a następnie bierze to, co wychodzi ze standardowego wyjścia i wyrzuca je z powrotem do requestera.

Nie obchodzi mnie to, jaki jest język implementacji. Rzeczywiście, napisałem moje wczesne CGI w ciągu dnia w C lub C ++. To było trochę bolesne. Później nauczyłem się trochę perla na początku lat 90. i było to o wiele mniej bolesne.

To działa do pewnego momentu. Problemem jest skala. Każde żądanie CGI jest rozwidleniem i wykonaniem procesu. Tysiące żądań to tysiące procesów. To naprawdę nie działa dobrze.

Rozwiązaniem tego problemu jest usunięcie rozwidlenia i wykonania poprzez przeniesienie go do wątku na samym serwerze internetowym lub wysłanie żądania do innego procesu, który obsługuje żądanie bez potrzeby rozwidlania i wykonywania. mod_perl jest jednym z takich narzędzi (wtyczka przenosi perla do apache). Php (koniec lat 90.) również to zrobił, implementując język jako wtyczkę w samym serwerze internetowym, a nie coś, co zostało rozwidlone i przekroczyło. Stało się to dość popularne, ponieważ było podobne do Perla (który był wczesnym dominującym językiem programowania w Internecie) i mogło przewyższyć perl cgis. W połowie lat 90. XX wieku nadal panuje spory impet - zanim serwery aplikacji klasy korporacyjnej zaczną się zajmować, a za nimi stoją bardziej sformalizowane języki. Jeśli przekopiesz się,

To prowadzi nas do serwerów aplikacji, w których odradzają się wątki wewnętrzne (lub inne podejścia - nie jest tak w przypadku wszystkiego) do obsługi żądań, a nie całych nowych procesów - które mogą pomóc w skalowaniu. Jako proces zewnętrzny można to zaobserwować za pomocą FastCGI, a następnie stało się powszechne na innych serwerach aplikacji. Zauważ, że dzięki temu granica między serwerem aplikacji a serwerem WWW stała się nieco rozmyta - wiele serwerów aplikacji mogło pełnić rolę serwerów WWW, choć nie zostały zoptymalizowane do obsługi statycznego We / Wy pliku w sposób, w jaki są tradycyjne serwery WWW.

Ogólny serwer aplikacji utorował również drogę do rozwiązań, w których zamiast zwykłego serwera aplikacji masz samą aplikację z wbudowanym serwerem internetowym lub całe wdrożenie. W takich sytuacjach nie wdraża się aplikacji internetowej na serwerze aplikacji - po prostu działa ona sama i obsługuje żądania. Ponownie, celem tego modelu jest uniknięcie wysokich kosztów uruchamiania nowych instancji aplikacji i zamiast tego obsługa żądań w aplikacji za pomocą wątków o mniejszej wadze lub podobnych podejść.

Ale o to chodzi - wszystkie rozwiązania są w jakiś sposób niedoskonałe, mają kształt lub formę. CGI, podczas gdy easy ma poważne problemy ze skalą. Wtyczki na serwerach sieciowych zostają powiązane z samym serwerem WWW (Apache vs Nginx vs IIS vs ...) i tracą wspólną funkcjonalność języka. Microsoft ma własną paradę technologii, którą chciałby promować. A jeśli znasz jeden język, czy nie wolałbyś nadal programować w nim, zamiast mieć różne języki w różnych częściach stosu (javascript w kliencie i Node.js)?

I tak masz dzisiaj. Niektóre osoby pracują na stosie Java (scala i clojure nie są rzadkie). Inne w stosie C #. Inne w stosie JavaScript. Istnieje całkiem sporo stosów php. Dużo pytona. Nadal możesz znaleźć stosy Perla (a jeśli spojrzysz na kilka stron o niskim wolumenie, nadal znajdziesz CGI). Dzięki przetwarzaniu w chmurze Google promuje Go również jako realny język internetowy po stronie serwera.

Każda ma swoje zalety, wady, swoje struktury i serwery. Względna popularność tych odpływów i przepływów wraz ze zmianami technologii wokół nich. Robią różne rzeczy dobrze.

Tak, dowolny ogólny język programowania może służyć do pisania części witryny po stronie serwera.

Jednak cechy języka programowania, zarówno w tym temacie, jak i innych, są zwykle tylko jednym z wielu czynników wpływających na jego popularność.

Na przykład uważam, że PHP stał się popularny na stronach internetowych, ponieważ:

• Przejście ze strony statycznej na dynamiczną stronę PHP jest niezwykle łatwe - wystarczy zastąpić rozszerzenie pliku HTML, umieścić <?phpznacznik na początku, a jeśli PHP jest zainstalowane, masz dynamiczną stronę internetową! Reszta przepływu pracy jest dokładnie taka sama, jak w przypadku statycznej witryny internetowej;
• Ze względu na łatwość wdrażania hosty internetowe, które chciały zaproponować dynamiczne strony internetowe, wybrały PHP, dzięki czemu dość szybko stała się najczęściej wdrażaną platformą po stronie serwera;
• Weszło na ten rynek we właściwym czasie;

A kiedy PHP zostało szeroko wdrożone, interesujące stało się pisanie poważniejszych aplikacji internetowych w PHP, aby skorzystać z tak szerokiego wdrożenia.

Mówiąc bardziej ogólnie: adopcja języka często dotyczy odpowiedzi na następujące pytania:

• Jak łatwo jest robić to, co chcę?
• Jak szeroko wspierany jest język tego, co chcę robić?

Czy mam rację, myśląc, że serwer potrzebuje tylko interfejsu, takiego jak CGI, aby serwer i język programowania działały razem?

Prawie. Potrzebujesz serwera WWW, który ma oprogramowanie, które pozwala mu również odpowiadać na żądania HTTP.

Pomyśl o tym, jak wyświetlana jest strona statyczna. Serwer pobiera żądanie HTTP, znajduje żądany dokument z systemu plików na podstawie konfiguracji serwera HTTP i zwraca stronę statyczną.

CGI rozszerza tę koncepcję, umożliwiając wyznaczenie folderu cgi-bin w systemie plików, w którym można przechowywać pliki wykonywalne lub skrypty. Gdy uzyskujesz dostęp do programu za pomocą CGI, serwer HTTP uruchamia proces lub skrypt i przekazuje standardowe dane wyjściowe z powrotem do klienta, a nie tylko podaje statyczny dokument.

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

Stara struktura CGI nie skaluje się dobrze w przypadku dużej liczby żądań. Różne języki programowania i frameworki dla sieci istnieją z różnych powodów i każdy z nich robi dobrze różne rzeczy. PHP jest tak popularny jak z powodów historycznych, ponieważ był jednym z pierwszych łatwych i tanich rozwiązań do obsługi dynamicznych stron bez uciekania się do CGI i miał szerokie wsparcie hostingu. ASP była popularna wśród kręgów Microsoft, ponieważ pozwalała programistom VB przenieść swoje umiejętności do sieci. ASP.NET (Web Forms) bardzo ułatwił programistom Windows Forms, z których wielu było programistami VB, przejście do sieci.

Gdy przeglądarka wysyła żądanie HTTP, wygląda to tak:

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

… Na który serwer powinien wysłać odpowiedź, która wygląda następująco:

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>

Wystarczy dowolny kod działający na serwerze, który nasłuchuje żądań na gnieździe TCP, odczyta żądanie i odpowie z odpowiednią odpowiedzią. Jednym głupim sposobem jest po prostu wyrzucenie konserwowanej odpowiedzi każdemu, kto łączy się z portem TCP 80, za pomocą skryptu powłoki:

$ 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

Oczywiście ta technika wydaje się ledwo zgodna z protokołem HTTP .

Krokiem naprzód w stosunku do tej konserwowanej odpowiedzi jest ten prosty program w języku Python, który korzysta z http.serverbiblioteki w języku 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()

Serwer HTTP może być napisany w dowolnym języku; to tylko przykład. Oczywiście ten przykład jest bardzo szczątkowy. Ładunek jest zakodowany na stałe - program całkowicie ignoruje treść żądania - adres URL, ciąg zapytania, nagłówek Accept-Language itp. Możesz dodać kod, aby wygenerować znaczące odpowiedzi na podstawie żądania, ale wtedy kod byłby bardzo złożony. Poza tym programiści wolą skupić się na pisaniu aplikacji internetowej, nie martwiąc się o szczegóły obsługi żądania HTTP.

Bardziej odpowiednim rozwiązaniem byłoby użycie serwera WWW, takiego jak Apache HTTPD , IIS lub nginx . Serwer WWW to tylko program, który nasłuchuje na odpowiednich gniazdach TCP, akceptuje wiele żądań (być może jednocześnie) i decyduje, jak wygenerować odpowiedź na podstawie adresu URL żądania, nagłówków i innych reguł. Idealnie, wiele szczegółów, takich jak SSL, kontrola dostępu i limity zasobów, są obsługiwane przez konfigurację, a nie kod. W większości przypadków serwer sieciowy sformułuje odpowiedź, która składa się tylko z zawartości plików w systemie plików.

Jednak w przypadku treści dynamicznych serwer WWW można skonfigurować tak, aby wykonywał pewien kod w celu wygenerowania odpowiedzi. Jednym z mechanizmów tego jest CGI - serwer ustawia niektóre zmienne środowiskowe na podstawie żądania, wykonuje program i kopiuje dane wyjściowe do gniazda TCP. Nieco bardziej wyrafinowanym rozwiązaniem byłoby posiadanie modułu, który dodaje obsługę serwera WWW do wywoływania kodu w innym języku programowania (np. Mod_php dla Apache ). Jeszcze inną opcją jest napisanie serwera WWW w tym samym języku co aplikacja internetowa, w którym to przypadku wysłanie żądania jest tylko wywołaniem funkcji. Tak jest w przypadku węzłów.js i silników serwletów Java, takich jak Apache Tomcat .

Wybór technologii zależy wyłącznie od Ciebie i zależy od preferowanego języka programowania, dostępnego środowiska hostingowego, wymagań dotyczących wydajności, popularnych opinii i pozytywnych trendów. Na przykład CGI nie było ostatnio preferowane, ponieważ potrzeba uruchamiania programów zewnętrznych ogranicza skalowalność.

Serwer WWW to program napisany w dowolnym języku programowania, który obsługuje „ruch internetowy” przez gniazda zgodne z normami / protokołami na poziomie aplikacji (HTTP itp.). Większość języków programowania oferuje utworzenie gniazda.

Czy mam rację, myśląc, że serwer potrzebuje tylko interfejsu, takiego jak CGI, aby serwer i język programowania działały razem?

Nie ma potrzeby posiadania dedykowanego programu serwera i aplikacji - mogą być takie same (bez względu na problemy związane z wydajnością).

Możesz użyć biblioteki bibliotek HTTP , np. Libonion , nawet w swoim programie napisanym w C (lub C ++, patrz także Wt ). Istnieje również biblioteka klientów HTTP (np. Libcurl )

Możesz używać innych bibliotek HTTP, np. Ocsigen i ocamlnet dla OCaml .

Istnieje kilka języków dedykowanych dla sieci (poza PHP), np. Opa , HOP , Kaya itp. (Zarówno HOP, jak i Opa mogą łatwo łączyć obliczenia po stronie serwera i przeglądarki, ale musisz to zrobić boleśnie i ręcznie w PHP, jawnie wykorzystując techniki AJAX i ręcznie kodując niektóre Javascript dla przeglądarki, natomiast HOP, Opa, Ocsigen są w stanie wygenerować ten Javascript.

Możesz także użyć technologii FASTCGI , aby dodać dynamiczną usługę do jakiegoś serwera WWW ... FASTCGI jest lepszy niż zwykły stary CGI, który uruchamia nowy proces dla każdego przychodzącego żądania HTTP, podczas gdy aplikacja FASTCGI może obsługiwać wiele żądań HTTP w tym samym procesie. BTW, PHP można skonfigurować do pracy jako aplikacja FASTCGI.

C.Queinnec zauważył, że przeglądanie stron internetowych i kontynuacja są ze sobą ściśle powiązane.

PS. Nie lubię PHP i wierzę, że jego popularność ma przyczyny historyczne i społeczne (nie głównie techniczne). Rzeczywiście PHP było szeroko rozpowszechnione, zanim AJAX stał się szeroko stosowany, i jest starsze niż HOP lub Opa (lub Ocsigen).