सर्वर-साइड प्रोग्रामिंग भाषाओं तक कैसे पहुंचा जाता है, इसका स्पष्टीकरण

45

यह मेरी समझ है कि किसी भी सामान्य-प्रयोजन प्रोग्रामिंग भाषा का उपयोग किसी वेबसाइट के सर्वर-साइड विकास के लिए किया जा सकता है।

क्या मैं यह सोचने में सही हूं कि सर्वर को बनाने के लिए किसी तरह के इंटरफेस की जरूरत है जैसे सीजीआई और प्रोग्रामिंग भाषा एक साथ काम करते हैं? यदि ऐसा है तो कुछ प्रोग्रामिंग लैंग्वेज (जैसे php) दूसरों की तुलना में अधिक लोकप्रिय क्यों हैं?

programming-languages web-development web

— क्रिस डांस
स्रोत

2

यह वास्तव में किसी अन्य प्रोग्रामिंग कार्य के लिए समान कारण है। लोग नई प्रोग्रामिंग भाषाओं का आविष्कार करते हैं क्योंकि वे मौजूदा लोगों के बारे में कुछ नापसंद करते हैं। और अन्य लोग पुराने का उपयोग करते रहते हैं क्योंकि वे समान चीजों को नापसंद नहीं करते हैं - या कम से कम स्विच करने के लिए पर्याप्त नहीं है।

— किलन फ़ॉथ

तो क्या मैं कुछ भाषाओं को कहने में सही रहूंगा, जैसे कि php, वेब विकास को ध्यान में रखकर तैयार की गई हैं और इस प्रकार आम अनुप्रयोगों के लिए एक आसान (और इसलिए अधिक लोकप्रिय) विकल्प है?

— क्रिस डांस

29

PHP वह है जिसे मैं "उथली" भाषा कहूंगा। मूल संरचना को समझना आसान है, और इसमें सैकड़ों छोटे कार्य हैं जो कुछ उपयोगी हैं। इसलिए यह नए लोगों से अपील करता है। C # जैसी भाषा के साथ तुलना करें, जहां आपको विरासत, वस्तु अभिविन्यास, प्रकार की सुरक्षा और उसमें उत्पादक होने के लिए अपेक्षाकृत जटिल पुस्तकालय जैसी चीजें सीखनी हैं।

— रॉबर्ट हार्वे

4

यदि ऐसा कोई इंटरफ़ेस नहीं है, तो आप अभी भी भाषा में सर्वर लिख सकते हैं।

— user253751

75

वेब के शुरुआती दिनों में, CGI वास्तव में डायनेमिक कंटेंट रखने का एकमात्र (व्यावहारिक) तरीका था (आप फ़ाइलों के नाम पाइप कर सकते थे - और जिनका उपयोग cgi से पहले के दिनों में किया गया था, लेकिन यह व्यावहारिक नहीं था)।

CGI उस प्रक्रिया के वातावरण में सूचनाओं का एक गुच्छा चिपका कर काम करता है जो तब फोर्क किया जाता है और फिर निष्पादित किया जाता है (और संभवतः स्टडिन में कुछ) और फिर स्टैडआउट से बाहर आता है और अनुरोधकर्ता को वापस थूक देता है।

यह कार्यान्वयन भाषा क्या है, इसके बारे में एक सा परवाह नहीं करता है। वास्तव में, मैंने सी या सी ++ में अपने शुरुआती सीजीआई को दिन में वापस लिखा। यह एक तरह से दर्दनाक था। मैंने बाद में 90 के दशक की शुरुआत में कुछ पर्ल सीखा और यह बहुत कम दर्दनाक था।

यह काम करता है, एक बिंदु तक। समस्या पैमाना है। प्रत्येक CGI अनुरोध एक प्रक्रिया का एक कांटा और निष्पादन है। हजारों अनुरोधों का अर्थ है हजारों प्रक्रियाएं। यह वास्तव में अच्छी तरह से काम नहीं करता है।

इसका समाधान वेब सर्वर में स्वयं को थ्रेड में ले जाकर फोर्किंग और एग्जीक्यूटिव को हटाना है, या किसी अन्य प्रक्रिया के लिए अनुरोध को भेजना है जो कांटा और निष्पादन की आवश्यकता के बिना अनुरोध को संभालता है। mod_perl ऐसा करने के लिए एक ऐसा उपकरण है (एक प्लग अपाचे में चल रहा है)। Php (90 के दशक के उत्तरार्ध) ने भी वेब सर्वर में एक प्लगइन के रूप में भाषा को लागू करने के साथ ऐसा किया था, जो कि कुछ के बजाय फोर्क और अधिक था। यह काफी लोकप्रिय हो गया क्योंकि यह पर्ल-लाइक था (जो शुरुआती प्रमुख वेब प्रोग्रामिंग भाषा थी) और पेरल cgis को बेहतर बना सकता था। 90 के दशक के मध्य की इस अवधि से अभी भी काफी गति है - इससे पहले कि अधिक एंटरप्राइज़-ग्रेड एप्लिकेशन सर्वर ने उनके पीछे और अधिक औपचारिक भाषाओं के साथ पकड़ बनाना शुरू किया। यदि आप चारों ओर खुदाई करते हैं,

यह हमें उन एप्लिकेशन सर्वरों में लाता है जहां आंतरिक थ्रेड्स को पूरी नई प्रक्रियाओं के बजाय अनुरोधों को संभालने के लिए (या अन्य दृष्टिकोण - यह सब कुछ के लिए मामला नहीं है) - जो पैमाने के साथ मदद कर सकता है। बाहरी प्रक्रिया के रूप में यह FastCGI के साथ देखा जा सकता है और फिर बाद में अन्य एप्लिकेशन सर्वरों के साथ प्रचलित हो गया। ध्यान दें कि इसके साथ एप्लिकेशन सर्वर और वेब सर्वर के बीच की रेखा थोड़ी धुंधली हो गई थी - कई एप्लिकेशन सर्वर वेब सर्वर के रूप में दोगुना हो सकते हैं, हालांकि पारंपरिक वेब सर्वर जिस तरह से हैं, स्थिर फ़ाइल IO को संभालने के लिए अनुकूलित नहीं थे।

जेनेरिक एप्लिकेशन सर्वर ने उन समाधानों का मार्ग भी प्रशस्त किया है, जहां जेनेरिक एप्लिकेशन सर्वर के बजाय , आपके पास एप्लिकेशन स्वयं या तो एक एम्बेडेड वेब सर्वर चला रहा है या अन्यथा संपूर्ण तैनाती हो रही है। ऐसी स्थितियों में कोई एक एप्लिकेशन सर्वर पर वेब एप्लिकेशन को तैनात नहीं करता है - यह केवल स्वयं चल रहा है और अनुरोधों को संभाल रहा है। फिर से, इस मॉडल का लक्ष्य आवेदन के नए उदाहरणों को लॉन्च करने की भारी कीमत से बचना है और इसके बजाय बहुत हल्के वजन के धागे या इसी तरह के दृष्टिकोण के साथ आवेदन के अंदर अनुरोधों को संभालना है।

हालांकि यहाँ बात है - सभी समाधान किसी न किसी तरह, आकार, या रूप में कमी हैं। सीजीआई, जबकि आसान में पैमाने के साथ गंभीर समस्याएं हैं। वेब सर्वर में प्लगइन्स स्वयं वेब सर्वर (अपाचे बनाम नग्नेक्स बनाम आईआईएस बनाम ...) में बंध जाते हैं और भाषा की सामान्य कार्यक्षमता खो देते हैं। Microsoft के पास अपनी खुद की तकनीकों की परेड है जिसे वह बढ़ावा देना चाहता है। और अगर आप एक भाषा जानते हैं, तो क्या आप स्टैक के विभिन्न हिस्सों (क्लाइंट और Node.js में जावास्क्रिप्ट) के बजाय अलग-अलग भाषाओं में प्रोग्रामिंग नहीं रखेंगे?

और इसलिए, आपको आज मिल गया है। कुछ लोग जावा स्टैक में काम करते हैं (स्केला और क्लोजर असामान्य नहीं होते हैं)। C # स्टैक में अन्य। जावास्क्रिप्ट स्टैक में अन्य। वहाँ php ढेर का एक बहुत कुछ है वहाँ। बहुत सारे अजगर। आप अभी भी वहाँ कुछ पर्ल स्टैक पा सकते हैं (और यदि आप कुछ कम वॉल्यूम साइटों को देखते हैं, तो आप अभी भी सीजीआई पाएंगे)। क्लाउड कंप्यूटिंग के साथ, Google ने गो को एक व्यवहार्य सर्वर साइड वेब भाषा के रूप में भी बढ़ावा दिया है।

प्रत्येक के अपने फायदे, नुकसान, इसकी रूपरेखा और इसके सर्वर हैं। इन एब्स की सापेक्ष लोकप्रियता और उनके आसपास की तकनीकों के रूप में बदल जाती है। वे अलग-अलग काम अच्छे से करते हैं।

यही वह है जिसकी तलाश में मैं हूं। एक व्यापक और अप्रतिहत उत्तर। धन्यवाद!

— क्रिस डांस

1

"समाधान वेब सर्वर में कांटा और निष्पादन चक्र को स्थानांतरित करना है।" जरूरी नहीं: FastCGI, रिवर्स प्रॉक्सिंग, लक्ष्य भाषा की परवाह किए बिना या वेब सर्वर कार्यान्वयन के लिए एप्लिकेशन सर्वर से कनेक्ट करने के लिए प्रसिद्ध समाधान हैं, जो अपना काम करने के लिए एक अच्छी तरह से निर्दिष्ट क्रॉस-प्रोसेस संचार प्रोटोकॉल का उपयोग करते हैं।

— झोमिनल

1

@jhominal "प्रत्येक अनुरोध के लिए एक नई प्रक्रिया बनाने के बजाय, FastCGI अनुरोधों की एक श्रृंखला को संभालने के लिए लगातार प्रक्रियाओं का उपयोग करता है। ये प्रक्रियाएं FastCGI सर्वर के स्वामित्व में हैं, न कि वेब सर्वर की।" ( स्रोत ) - यह इसका दिल है, यह वही है जो एक एप्लिकेशन सर्वर करता है। एक निरंतर प्रक्रिया जो कांटा और निष्पादन किए बिना अनुरोधों को संभालती है।

@MichaelT: आप "वेब सर्वर" और "एप्लिकेशन सर्वर" का उपयोग कर रहे हैं जैसे कि शब्द विनिमेय थे - और, अपने जवाब में, आप "वेब सर्वर" का उपयोग ज्यादातर एपाचे, नग्नेक्स - यानी जेनेरिक वेब सॉफ्टवेयर के लिए करते हैं। केवल (उनके मूल में) सीमित प्रोग्रामेबिलिटी है।

— झोमिनल

1

मुझे नहीं लगता है कि यह (अब तक बहुत सामान्य) प्रैक्टिस करने के लिए पर्याप्त है कि प्रत्येक एप्लिकेशन का अपना वेबसर्वर हो, सबसे अधिक संभावना एक या एक से अधिक HTTP प्रॉक्सी के द्वारा।

— हॉब्स

19

हां, कोई भी सामान्य प्रोग्रामिंग भाषा एक वेब साइट के सर्वर-साइड भाग को लिखने के लिए सेवा दे सकती है।

हालांकि, एक प्रोग्रामिंग भाषा के गुण, इस विषय में अन्य चीजों की तरह, आमतौर पर केवल कई कारकों में से एक है जो इसकी लोकप्रियता में योगदान करते हैं।

उदाहरण के लिए, मुझे लगता है कि PHP वेबसाइटों के लिए लोकप्रिय हो गया क्योंकि

स्थैतिक वेबसाइट से PHP डायनामिक वेबसाइट पर अपग्रेड करना बेहद आसान है - बस अपनी HTML फ़ाइल के फ़ाइल एक्सटेंशन को बदलें, <?phpटैग को शुरुआत में रखें, और, बशर्ते PHP इंस्टॉल हो, आपके पास एक डायनामिक वेब साइट हो! बाकी वर्कफ़्लो बिल्कुल वैसा ही है जैसा स्थैतिक वेबसाइट के लिए;
तैनाती में आसानी के कारण, गतिशील वेब साइटों को प्रस्तावित करने के लिए देख रहे वेब होस्ट्स ने PHP को चुना, जिससे यह बहुत जल्दी से सबसे व्यापक रूप से तैनात सर्वर-साइड प्लेटफ़ॉर्म पर पहुंच गया;
यह सही समय पर उस बाजार में आ गया;

और एक बार जब PHP को व्यापक रूप से तैनात किया गया था, तो तैनाती की उस व्यापकता से लाभ उठाने के लिए PHP में अधिक गंभीर वेब एप्लिकेशन लिखना दिलचस्प हो गया।

इसे अधिक सामान्य तरीके से कहने के लिए: भाषा अपनाने को अक्सर इन सवालों के जवाबों के बारे में बताया जाता है:

यह करना कितना आसान है कि मैं क्या करना चाहता हूं?
मैं जो करना चाहता हूं, उसके लिए भाषा का कितना व्यापक समर्थन है?

— jhominal
स्रोत

7

क्या मैं यह सोचने में सही हूं कि सर्वर को बनाने के लिए किसी तरह के इंटरफेस की जरूरत है जैसे सीजीआई और प्रोग्रामिंग भाषा एक साथ काम करते हैं?

लगभग। आपको एक वेब सर्वर की जरूरत है जिसमें किसी तरह का सॉफ्टवेयर हो ताकि वह HTTP रिक्वेस्ट पर भी प्रतिक्रिया दे सके।

एक स्थैतिक पृष्ठ कैसे परोसा जाता है, इसके बारे में सोचें। सर्वर HTTP अनुरोध को पुनः प्राप्त करता है, HTTP सर्वर के विन्यास के आधार पर फाइलसिस्टम से अनुरोधित दस्तावेज़ को पाता है और स्थैतिक पृष्ठ को लौटाता है।

CGI इस अवधारणा का विस्तार आपको फाइल सिस्टम पर एक cgi-bin फ़ोल्डर को निर्दिष्ट करने की अनुमति देकर करता है, जहां निष्पादनयोग्य या स्क्रिप्ट संग्रहीत की जा सकती हैं। जब आप CGI के माध्यम से किसी प्रोग्राम को एक्सेस करते हैं, तो HTTP सर्वर प्रक्रिया या स्क्रिप्ट को चलाता है और मानक आउटपुट को क्लाइंट को केवल स्थैतिक दस्तावेज की सेवा देने के बजाय वापस भेज देता है।

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

पुराने सीजीआई ढांचे में बड़ी मात्रा में अनुरोध नहीं हैं। वेब के लिए अलग-अलग प्रोग्रामिंग लैंग्वेज और फ्रेमवर्क अलग-अलग कारणों से मौजूद हैं, और हर एक अलग-अलग चीजों को अच्छी तरह से करता है। PHP ऐतिहासिक कारणों से उतना ही लोकप्रिय है, जितना कि सीजीआई का सहारा लिए बिना डायनेमिक पेजों को परोसने के पहले आसान और सस्ते समाधानों में से एक था, जिसमें व्यापक रूप से होस्टिंग का समर्थन था। एएसपी माइक्रोसॉफ्ट सर्किल के बीच लोकप्रिय था क्योंकि इसने वीबी डेवलपर्स को अपने कौशल को वेब पर स्थानांतरित करने की अनुमति दी थी। ASP.NET (वेब फॉर्म) ने विंडोज फॉर्म डेवलपर्स के लिए बहुत आसान बना दिया, जिनमें से कई वीबी कोडर थे, जो वेब पर स्विच करने के लिए थे।

— ravibhagw
स्रोत

3

जब कोई ब्राउज़र 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>

सर्वर पर चलने वाला कोई भी कोड जो टीसीपी सॉकेट पर अनुरोधों को सुनता है, अनुरोध को पढ़ता है, और उचित प्रतिक्रिया के साथ उत्तर पर्याप्त होगा। एक गूंगा तरीका सिर्फ शेल स्क्रिप्ट का उपयोग करके टीसीपी पोर्ट 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 प्रोटोकॉल का पालन करने के लिए मुश्किल से दिखाई देती है ।

उस डिब्बाबंद प्रतिक्रिया से एक कदम यह सरल पायथन कार्यक्रम है, जो http.serverपायथन 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, क्वेरी स्ट्रिंग, स्वीकार-भाषा हेडर, आदि। आप अनुरोध के आधार पर सार्थक प्रतिक्रियाओं को उत्पन्न करने के लिए कोड जोड़ सकते हैं, लेकिन तब कोड बहुत मिल जाएगा जटिल। इसके अलावा, प्रोग्रामर वेब एप्लिकेशन लिखने पर ध्यान केंद्रित करेंगे, ताकि HTTP अनुरोध को संभालने के तरीके के बारे में चिंता न हो।

वेब सर्वर का उपयोग करने के लिए एक अधिक उपयुक्त समाधान होगा, जैसे कि अपाचे एचटीडी , आईआईएस , या नेग्नेक्स । एक वेब सर्वर सिर्फ एक प्रोग्राम है जो संबंधित टीसीपी सॉकेट्स पर सुनता है, कई अनुरोधों (संभवतः एक साथ) को स्वीकार करता है, और यह अनुरोध करता है कि अनुरोध URL, हेडर और अन्य नियमों के आधार पर प्रतिक्रिया कैसे उत्पन्न की जाए। आदर्श रूप से, कई विवरण, जैसे कि एसएसएल, एक्सेस कंट्रोल, और संसाधन सीमाओं को कोड के बजाय कॉन्फ़िगरेशन के माध्यम से ध्यान रखा जाता है। ज्यादातर समय, वेब सर्वर एक प्रतिक्रिया तैयार करेगा जिसमें फाइलसिस्टम की फाइलों से सामग्री होती है।

गतिशील सामग्री के लिए, हालांकि, प्रतिक्रिया उत्पन्न करने के लिए वेब सर्वर को कुछ कोड निष्पादित करने के लिए कॉन्फ़िगर किया जा सकता है। सीजीआई के साथ ऐसा करने के लिए एक तंत्र - सर्वर अनुरोध के आधार पर कुछ पर्यावरण चर निर्धारित करता है, एक प्रोग्राम निष्पादित करता है, और इसके आउटपुट को टीसीपी सॉकेट में कॉपी करता है। एक और अधिक परिष्कृत समाधान के लिए एक मॉड्यूल होगा जो किसी अन्य प्रोग्रामिंग भाषा (जैसे अपाचे के लिए mod_php ) में कॉलिंग कोड के लिए वेब सर्वर को समर्थन जोड़ता है । फिर भी एक अन्य विकल्प वेब सर्वर को वेब एप्लिकेशन के रूप में उसी भाषा में लिखना है, जिस स्थिति में अनुरोध प्रेषण केवल एक फ़ंक्शन कॉल है। यह Apache Tomcat जैसे node.js और Java सर्वलेट इंजन के मामले में है ।

प्रौद्योगिकी का विकल्प वास्तव में आप पर निर्भर है, और आप जिस प्रोग्रामिंग भाषा का उपयोग करना चाहते हैं, उस पर निर्भर करता है, होस्टिंग वातावरण जो आपके लिए उपलब्ध है, प्रदर्शन की आवश्यकताएं, लोकप्रिय राय, और गुजरने वाले सनक। उदाहरण के लिए, CGI हाल ही में इष्ट नहीं रहा है, क्योंकि बाहरी कार्यक्रमों को लॉन्च करने की आवश्यकता स्केलेबिलिटी को सीमित करती है।

— 200_success
स्रोत

1

एक वेब सर्वर किसी भी प्रोग्रामिंग भाषा में लिखा गया एक प्रोग्राम है जो मानकों / एप्लिकेशन स्तर प्रोटोकॉल (HTTP, आदि) का पालन करते हुए सॉकेट (ओं) पर "वेब ट्रैफिक" को संभालता है। अधिकांश प्रोग्रामिंग लैंग्वेज आपको सॉकेट बनाने की पेशकश करती हैं।

क्या मैं यह सोचने में सही हूं कि सर्वर को बनाने के लिए किसी तरह के इंटरफेस की जरूरत है जैसे सीजीआई और प्रोग्रामिंग भाषा एक साथ काम करते हैं?

समर्पित सर्वर प्रोग्राम और आपके एप्लिकेशन प्रोग्राम की आवश्यकता नहीं है - वे एक ही हो सकते हैं (किसी भी प्रदर्शन से संबंधित मुद्दों की उपेक्षा)।

— mucaho
स्रोत

0

आप कुछ HTTP सर्वर लाइब्रेरी का उपयोग कर सकते हैं , उदाहरण के लिए मानहानि , यहां तक कि आपके प्रोग्राम में सी (या सी ++, कोड भी देखें Wt )। कुछ HTTP क्लाइंट लाइब्रेरी (उदाहरण के लिए libcurl )

आप OCaml के लिए अन्य HTTP पुस्तकालयों, जैसे ocsigen और ocamlnet का उपयोग कर सकते हैं ।

कई वेब समर्पित भाषाएं हैं (PHP के बाहर), उदाहरण के लिए ओपा , एचओपी , काया , आदि ... (एचओपी और ओपा दोनों आसानी से सर्वर-साइड और ब्राउज़र-साइड संगणनाओं को मिला सकते हैं, लेकिन आपको यह दर्द और मैन्युअल रूप से करना होगा PHP, स्पष्ट रूप से AJAX तकनीकों का उपयोग कर रहा है और ब्राउज़र के लिए कुछ जावास्क्रिप्ट को कोड कर रहा है। इसके विपरीत, HOP, Opa, Ocsigen उस जावास्क्रिप्ट को उत्पन्न करने में सक्षम हैं)।

आप FASTCGI तकनीक का उपयोग कुछ वेब सर्वर में कुछ गतिशील सेवा को जोड़ने के लिए भी कर सकते हैं ... FASTCGI सादे पुराने CGI से बेहतर है जो हर आने वाले HTTP अनुरोध के लिए एक नई प्रक्रिया शुरू करता है, जबकि FASTCGI एप्लिकेशन एक ही प्रक्रिया में कई HTTP अनुरोधों की सेवा कर सकता है। BTW, PHP को FASTCGI एप्लिकेशन के रूप में काम करने के लिए कॉन्फ़िगर किया जा सकता है।

C.Queinnec ने पाया कि वेब ब्राउज़िंग और निरंतरता काफी संबंधित हैं।

पुनश्च। मुझे PHP पसंद नहीं है, और मुझे विश्वास है कि इसकी लोकप्रियता के ऐतिहासिक और सामाजिक कारण हैं (मुख्यतः तकनीकी वाले नहीं)। वास्तव में AJAX व्यापक रूप से उपयोग होने से पहले PHP का व्यापक रूप से उपयोग किया गया था, और HOP या Opa (या Ocsigen) से पुराना है।

— बेसाइल स्टारीनेवविच
स्रोत