Sunucu tarafı programlama dillerine nasıl erişildiğinin açıklanması

Anladığım kadarıyla herhangi bir genel amaçlı programlama dili bir web sitesinin sunucu tarafında geliştirilmesi için kullanılabiliyor.

Bir sunucunun, sunucuyu ve programlama dilini birlikte çalışması için CGI gibi bir arayüze ihtiyacı olduğunu düşünmekte haklı mıyım? Öyleyse neden bazı programlama dilleri (php gibi) diğerlerinden daha popüler?

Webin ilk günlerinde, CGI gerçekten dinamik içeriğe sahip tek (pratik) yoldu (dosya adlarını söyleyebiliyordunuz - ve bunlar cgi'den önceki günlerde kullanılıyordu, ancak bu hiç pratik değildi).

CGI, sürecin ortamına çatallanmış ve daha sonra yürütülen (ve muhtemelen bazı stdinlerde) ortamına yapıştırarak çalışır ve sonra stdout'tan çıkanları alır ve talep eden kişiye geri verir.

Bu, uygulama dilinin ne olduğu hakkında bir şey umursamıyor. Aslında, ilk CGI'larımı gün içinde C veya C ++ dilinde yazdım. Biraz acı vericiydi. Daha sonra 90'ların başında biraz perl öğrendim ve bu daha az acı vericiydi.

Bu bir noktaya kadar çalışıyor. Sorun ölçek. Her CGI talebi, bir çatal ve bir işlemin gerçekleştirilmesidir. Binlerce istek, binlerce işlem anlamına gelir. Bu gerçekten iyi çalışmıyor.

Bunun çözümü, çatal ağzı ve yürütmeyi, ya web sunucusunun kendi içindeki bir ipliğe hareket ettirerek ya da isteği, istifleme ve yürütmeye gerek kalmadan isteği işleyen başka bir işleme göndererek çıkarmaktır. mod_perl bunu yapmak için böyle bir araçtır (perl'i apache'ye taşıyan bir eklenti). Php (90'lı yılların sonlarında) bunu, dili çatallanmış ve aşılmış bir şey yerine, web sunucusunda bir eklenti olarak uygulamakla da yaptı. Perl'e benzeyen (bu, baskın web programlama dili idi) ve perl cgis'den daha iyi bir performans sergiledi. 90'lı yılların ortalarında bu zaman diliminde hala biraz ivme var - daha kurumsal sınıftaki uygulama sunucuları arkalarında daha resmi dilleri tutmaya başlamadan önce. Kazarsan,

Bu, bizi iç iş parçacıklarının doğduğu uygulama sunucularına (veya diğer yaklaşımlara - bu her şey için geçerli değil) tüm yeni süreçlerden ziyade istekleri yerine getirme - ölçeklemeye yardımcı olabilir. Harici bir süreç olarak bu, FastCGI ile görülebilir ve daha sonra diğer uygulama sunucuları ile yaygınlaştı. Bununla, uygulama sunucusu ve web sunucusu arasındaki çizginin biraz bulanıklaştığını - birçok uygulama sunucusunun, geleneksel web sunucularının olduğu gibi statik dosya GÇ'lerini işlemek için optimize edilmemiş olmasına rağmen, web sunucuları olarak iki katına çıkabileceğini unutmayın.

Genel uygulama sunucusu da yerine çözümüne yolunu açmıştır jenerik uygulama sunucusu, uygulamayı kendisi ya gömülü web sunucusunu çalıştıran veya başka tüm dağıtım olmak var. Bu gibi durumlarda, bir web uygulaması bir uygulama sunucusuna dağıtılmaz - yalnızca kendisi çalışmakta ve istekleri yerine getirmektedir. Yine, bu modelin amacı, uygulamanın yeni örneklerini başlatmanın ağır bedelinden kaçınmak ve bunun yerine uygulama içindeki talepleri daha hafif ağırlıktaki ipliklerle veya benzer yaklaşımlarla ele almaktır.

İşte bir şey var - tüm çözümler bir şekilde, şekil ya da biçimde eksik. CGI, kolay iken ölçeğinde ciddi problemler yaşıyor. Web sunucularındaki eklentiler web sunucusuna bağlanır (apache vs nginx vs IIS vs ...) ve dilin ortak işlevlerini kaybeder. Microsoft'un tanıtmak istediği teknolojilerden biri var. Ve eğer bir dil biliyorsanız, yığının farklı kısımlarında farklı dillere sahip olmak yerine, programlamayı sürdürmek istemez misiniz (istemcide javascript ve Node.js)?

Ve böylece bugün var. Bazı insanlar bir Java yığında çalışırlar (scala ve clojure nadir değildir). C # yığınındaki diğerleri. Bir JavaScript yığınındaki diğerleri. Dışarıda epeyce php yığını var. Bir sürü piton. Orada hala bazı perl yığınları bulabilirsiniz (ve eğer düşük hacimli sitelere bakarsanız, yine de CGI'ları bulacaksınız). Bulut bilgi işlem ile Google, Google’ı uygun bir sunucu tarafı web dili olarak da tanıtmıştır.

Her birinin avantajları, dezavantajları, çerçeveleri ve sunucuları vardır. Bu ebb'lerin nispi popülaritesi ve etraflarındaki teknolojiler değiştikçe akmaktadır. Farklı şeyler iyi yapıyorlar.

Evet, herhangi bir genel programlama dili, bir web sitesinin sunucu tarafındaki kısmını yazmaya hizmet edebilir.

Ancak, bir programlama dilinin nitelikleri, bu konuda diğer şeylerde olduğu gibi, genellikle popülerliğine katkıda bulunan birçok faktörden yalnızca biridir.

Örneğin, PHP'nin web siteleri için popüler olduğunu düşünüyorum çünkü:

• Statik bir web sitesinden bir PHP dinamik web sitesine yükseltmek son derece kolaydır - HTML dosyanızın dosya uzantısını değiştirin, <?phpetiketi en başa yerleştirin ve PHP'nin yüklü olması şartıyla dinamik bir web siteniz var! İş akışının geri kalanı, tamamen statik bir web sitesiyle aynıdır;
• Bu dağıtım kolaylığı nedeniyle, dinamik web siteleri önermek isteyen web sunucuları PHP'yi seçti, bu da onu en hızlı şekilde dağıtılan sunucu tarafı platformu haline getirdi;
• Doğru zamanda o pazara girdi;

PHP bir kez yaygın bir şekilde konuşlandırıldığında, konuşlandırmanın genişliğinden yararlanmak için PHP'de daha ciddi web uygulamaları yazmak ilginç hale geldi.

Daha genel bir şekilde söylemek gerekirse: Dilin kabul edilmesi genellikle bu soruların cevaplarıyla ilgilidir:

• Yapmak istediğim şeyi yapmak ne kadar kolay?
• Yapmak istediğim şeyin dili ne kadar yaygın olarak destekleniyor?

Bir sunucunun, sunucuyu ve programlama dilini birlikte çalışması için CGI gibi bir arayüze ihtiyacı olduğunu düşünmekte haklı mıyım?

Neredeyse. HTTP isteklerine yanıt verebilmesi için bir tür yazılıma sahip bir web sunucusuna ihtiyacınız var.

Statik bir sayfanın nasıl sunulduğunu düşünün. Sunucu HTTP isteğini alır, istenen belgeyi HTTP sunucusunun yapılandırmasına bağlı olarak dosya sisteminden bulur ve statik sayfayı döndürür.

CGI bu kavramı, çalıştırılabilir veya komut dosyalarının depolanabileceği dosya sisteminde bir cgi-bin klasörü belirlemenizi sağlayarak genişletir. CGI üzerinden bir programa eriştiğinizde, HTTP sunucusu işlemi veya komut dosyasını çalıştırır ve standart çıktıyı yalnızca statik belgeyi sunmak yerine geri istemciye iletir.

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

Eski CGI yapısı, büyük miktarda istek üzerinde iyi ölçeklenemez. Web için farklı programlama dilleri ve çerçeveleri farklı nedenlerden dolayı mevcuttur ve her biri farklı şeyler yapar. PHP, CGI'ya başvurmadan dinamik sayfalar sunmak için ilk kolay ve ucuz çözümlerden biri olduğu ve yaygın barındırma desteğine sahip olduğu için tarihsel nedenlerle olduğu kadar popüler. ASP, Microsoft çevreleri arasında popülerdi çünkü VB geliştiricilerinin becerilerini web'e kaydırmasına izin verdi. ASP.NET (Web Formları), çoğu VB kodlayıcısı olan Windows Forms geliştiricilerin web'e geçiş yapmasını çok kolaylaştırdı.

Bir tarayıcı bir HTTP isteği yaptığında, şöyle görünür:

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

… Sunucunun buna benzeyen bir yanıt göndermesi gerekir:

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>

Bir TCP soketindeki istekleri dinleyen, sunucuda çalışan herhangi bir kod, isteği okur ve uygun yanıtla yanıtlar yeterli olacaktır. Aptalca bir yol, yalnızca bir kabuk betiği kullanarak TCP bağlantı noktası 80'e bağlanan herkese karşı verilen yanıtı dağıtmaktır:

$ 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

Tabii ki, bu teknik ancak ancak HTTP protokolüne uygun görünmektedir .

Bu hazır yanıttan bir adım daha http.serverPython 3'deki kütüphaneyi kullanan bu basit Python programı var .

#!/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 sunucusu herhangi bir dilde yazılabilir; bu sadece bir örnek. Açıkçası, bu örnek çok basit. Yükü kodlanmış - program isteğin içeriğini tamamen göz ardı ediyor - URL, sorgu dizesi, Kabul Dilini, vb., İsteği temel alarak anlamlı yanıtlar üretmek için kod ekleyebilirsiniz, ancak daha sonra kod çok kompleksi. Ayrıca, programcılar bir HTTP isteğinin nasıl ele alınacağı hakkında endişelenmenize gerek kalmadan web uygulamasını yazmaya odaklanırlar.

Daha uygun bir çözüm, Apache HTTPD , IIS veya nginx gibi bir web sunucusu kullanmak olacaktır . Bir web sunucusu sadece ilgili TCP soketlerini dinleyen, çoklu istekleri (muhtemelen aynı anda) kabul eden ve istek URL'sine, başlıklarına ve diğer kurallara dayanarak nasıl cevap verileceğine karar veren bir programdır. İdeal olarak, SSL, erişim kontrolü ve kaynak sınırları gibi ayrıntıların çoğu kod yerine yapılandırma yoluyla halledilir. Çoğu zaman, web sunucusu, dosya sistemindeki dosyalardan yalnızca içerikten oluşan bir yanıt oluşturacaktır.

Bununla birlikte, dinamik içerik için web sunucusu, yanıtı oluşturmak üzere bir kod yürütecek şekilde yapılandırılabilir. Bunu yapmak için bir mekanizma CGI ile - sunucu isteği temel alarak bazı ortam değişkenleri belirler, bir program yürütür ve çıktısını TCP soketine kopyalar. Biraz daha karmaşık bir çözüm, başka bir programlama dilinde kod çağırmak için web sunucusuna destek ekleyen bir modüle sahip olmak olacaktır (örn . Apache için mod_php ). Diğer bir seçenek de web sunucusunu web uygulaması ile aynı dilde yazmaktır; bu durumda istek gönderimi sadece bir işlev çağrısıdır. Bu, node.js ve Apache Tomcat gibi Java sunucu uygulaması motorları için geçerlidir .

Teknolojinin seçimi gerçekten size bağlıdır ve kullanmayı tercih ettiğiniz programlama diline, kullanabileceğiniz barındırma ortamına, performans gereksinimlerine, popüler düşüncelere ve geçici sorunlara bağlıdır. Örneğin, CGI son zamanlarda tercih edilmedi, çünkü harici programları başlatma ihtiyacı ölçeklenebilirliği sınırlıyor.

Bir web sunucusu, herhangi bir programlama dilinde yazılmış, standartlara / uygulama seviyesindeki protokollere (HTTP, vb.) Bağlı kalarak soket (ler) üzerinden "web trafiğini" işleyen bir programdır. Çoğu programlama dili bir yuva oluşturmanızı sağlar.

Bir sunucunun, sunucuyu ve programlama dilini birlikte çalışması için CGI gibi bir arayüze ihtiyacı olduğunu düşünmekte haklı mıyım?

Özel bir sunucu programına ve uygulama programınıza sahip olmanıza gerek yoktur - bunlar aynı olabilir (performansla ilgili sorunları göz ardı ederek).

Bazı kullanabilirsiniz HTTP sunucusu kütüphane, örneğin libonion , hatta C kodlu Programda (veya C ++, ayrıca bkz Wt ). Ayrıca bazı HTTP istemci kütüphaneleri de var (örneğin libcurl )

Diğer HTTP kütüphanelerini kullanabilirsiniz, örneğin OCaml için ocsigen & ocamlnet .

Opa , HOP , Kaya , vb. Gibi (PHP dışında) Web'e özgü birçok dil vardır ... (hem HOP hem de Opa, sunucu ve tarayıcı tarafı hesaplamalarını kolayca karıştırabilir, ancak bunu acı verici ve manuel olarak yapmanız gerekir. PHP, açık bir şekilde AJAX tekniklerini kullanarak ve tarayıcı için bazı Javascript'leri elle kodlarken, HOP, Opa, Ocsigen, bu Javascript'i üretebilir).

Ayrıca kullanabilirsiniz FASTCGI bazı web sunucusuna bazı dinamik hizmeti eklemek için teknolojiyi ... FASTCGI iyi düz eski daha CGI bir FASTCGI uygulama aynı süreçte sayıda HTTP isteğine yanıt verebilir ederken, her gelen HTTP isteği için yeni bir süreç başlar. BTW, PHP bir FASTCGI uygulaması olarak çalışmak üzere yapılandırılabilir.

C.Queinnec, web taraması ve sürdürmelerin anlamlı bir şekilde ilişkili olduğunu gözlemledi .

PS. PHP'yi sevmiyorum ve popülaritesinin tarihsel ve sosyal sebepleri olduğuna inanıyorum (çoğunlukla teknik olanlar değil). Gerçekten de, AJAX yaygın olarak kullanılmadan önce PHP oldukça yaygındı ve HOP veya Opa'dan (veya Ocsigen'den) daha eskiydi.