คำอธิบายวิธีการเข้าถึงภาษาการเขียนโปรแกรมฝั่งเซิร์ฟเวอร์


45

ฉันเข้าใจว่าภาษาการเขียนโปรแกรมวัตถุประสงค์ทั่วไปสามารถใช้สำหรับการพัฒนาเว็บไซต์ฝั่งเซิร์ฟเวอร์

ฉันคิดถูกแล้วว่าเซิร์ฟเวอร์ต้องการอินเทอร์เฟซบางอย่างเช่น CGI เพื่อให้เซิร์ฟเวอร์และภาษาโปรแกรมทำงานร่วมกันได้หรือไม่? ถ้าเป็นเช่นนั้นแล้วทำไมบางภาษาโปรแกรม (เช่น php) จึงเป็นที่นิยมมากกว่าภาษาอื่น ๆ ?


2
เป็นเหตุผลเดียวกันกับงานเขียนโปรแกรมอื่น ๆ ผู้คนคิดค้นภาษาการเขียนโปรแกรมใหม่เพราะพวกเขาไม่ชอบสิ่งที่มีอยู่ และบางคนก็ใช้ของเก่าต่อไปเพราะพวกเขาไม่ชอบสิ่งเดียวกัน - หรืออย่างน้อยก็ไม่พอที่จะเปลี่ยน
Kilian Foth

ดังนั้นฉันจะพูดถูกต้องว่าบางภาษาเช่น php ได้รับการออกแบบโดยคำนึงถึงการพัฒนาเว็บและเป็นตัวเลือกที่ง่ายกว่า
Chris Dance

29
PHP เป็นสิ่งที่ฉันจะเรียกภาษา "ตื้น" โครงสร้างพื้นฐานเข้าใจง่ายและมีฟังก์ชั่นเล็ก ๆ น้อย ๆ นับร้อยที่ทำสิ่งที่มีประโยชน์ มันจึงดึงดูดผู้มาใหม่ เปรียบเทียบกับภาษาเช่น C # ที่คุณต้องเรียนรู้สิ่งต่าง ๆ เช่นการสืบทอดการวางแนววัตถุความปลอดภัยประเภทและไลบรารีที่ค่อนข้างซับซ้อนเพื่อให้เกิดประโยชน์
Robert Harvey

4
ถ้าไม่มีอินเตอร์เฟซที่ดังกล่าวแล้วคุณยังสามารถเขียนเซิร์ฟเวอร์ในภาษา
253751

คำตอบ:


75

ในวันแรก ๆ ของเว็บ CGI เป็นวิธีเดียว (ในทางปฏิบัติ) ที่จะมีเนื้อหาแบบไดนามิก (คุณสามารถตั้งชื่อไฟล์ท่อ - และสิ่งเหล่านั้นถูกใช้ในหลายวันก่อน cgi แต่ก็ไม่ได้ใช้งานได้จริง)

CGI ทำงานโดยการรวมกลุ่มของข้อมูลในสภาพแวดล้อมของกระบวนการที่ถูกแยกแล้วประมวลผล (และอาจเป็นแบบ stdin) จากนั้นนำสิ่งที่ออกมาจาก stdout และถ่มน้ำลายที่ผู้ร้องขอ

สิ่งนี้ไม่สนใจสักนิดเกี่ยวกับภาษาที่ใช้งาน อันที่จริงฉันเขียน CGI ตอนแรกของฉันย้อนกลับไปในวันที่ C หรือ C ++ มันช่างเจ็บปวดเหลือเกิน ต่อมาฉันเรียนรู้ Perl ในช่วงต้นทศวรรษ 90 และนั่นก็เจ็บปวดน้อยกว่ามาก

ใช้งานได้จนถึงจุดหนึ่ง ปัญหาคือขนาด คำขอ CGI แต่ละรายการเป็นทางแยกและดำเนินการของกระบวนการ คำขอนับพันหมายถึงกระบวนการหลายพันรายการ ว่ามันไม่ได้ผลดี

วิธีแก้ปัญหาคือลบฟอร์กกิ้งและเอ็กซีคิวต์โดยย้ายมันไปที่เธรดในเว็บเซิร์ฟเวอร์เองหรือส่งการร้องขอไปยังกระบวนการอื่นที่จัดการการร้องขอโดยไม่ต้องแยกและ exec mod_perl เป็นเครื่องมือหนึ่งในการทำเช่นนี้ (ปลั๊กอินย้าย Perl เข้าไปใน Apache) Php (ปลาย 90s) ทำสิ่งนี้ด้วยการใช้ภาษาเป็นปลั๊กอินในเว็บเซิร์ฟเวอร์เองแทนที่จะเป็นสิ่งที่แยกและเกิน สิ่งนี้ได้รับความนิยมอย่างมากเนื่องจากเป็นภาษา Perl (ซึ่งเป็นภาษาการเขียนโปรแกรมเว็บที่โดดเด่นในช่วงต้น) และอาจมีประสิทธิภาพเหนือกว่า cgis ยังคงมีแรงผลักดันเล็กน้อยจากช่วงเวลานี้ในช่วงกลางทศวรรษที่ 90 ก่อนที่แอพพลิเคชั่นเซิร์ฟเวอร์ระดับองค์กรจะเริ่มมีภาษาที่เป็นทางการอยู่เบื้องหลัง ถ้าคุณขุดไปรอบ ๆ

สิ่งนี้นำเราไปสู่แอปพลิเคชันเซิร์ฟเวอร์ที่มีเธรดภายในเกิดขึ้น (หรือวิธีการอื่น ๆ - นี่ไม่ใช่กรณีสำหรับทุกสิ่ง) ในการจัดการคำขอมากกว่ากระบวนการใหม่ทั้งหมด - ซึ่งสามารถช่วยในการปรับขนาด ในฐานะที่เป็นกระบวนการภายนอกสิ่งนี้สามารถมองเห็นได้ด้วย FastCGI และต่อมากลายเป็นที่แพร่หลายกับแอพพลิเคชันเซิร์ฟเวอร์อื่น ๆ โปรดทราบว่าด้วยสิ่งนี้เส้นแบ่งระหว่างแอ็พพลิเคชันเซิร์ฟเวอร์และเว็บเซิร์ฟเวอร์มีความพร่ามัว - แอ็พพลิเคชันเซิร์ฟเวอร์จำนวนมากสามารถเพิ่มเป็นสองเท่าเป็นเว็บเซิร์ฟเวอร์แม้ว่าจะไม่ได้รับการปรับให้เหมาะสมสำหรับการจัดการไฟล์ IO แบบคงที่

แอ็พพลิเคชันเซิร์ฟเวอร์ทั่วไปได้ปูทางไปสู่การแก้ปัญหาซึ่งแทนที่จะเป็นแอพพลิเคชั่นเซิร์ฟเวอร์ทั่วไปคุณมีแอปพลิเคชั่นที่ใช้งานเว็บเซิร์ฟเวอร์ในตัวหรือทำการปรับใช้ทั้งหมด ในสถานการณ์เช่นนี้เราไม่ได้ปรับใช้เว็บแอปพลิเคชั่นบนเซิร์ฟเวอร์แอปพลิเคชัน - มันเป็นเพียงการเรียกใช้และจัดการคำขอ อีกครั้งเป้าหมายของรุ่นนี้คือการหลีกเลี่ยงราคาจำนวนมากในการเปิดตัวอินสแตนซ์ใหม่ของแอปพลิเคชันและจัดการการร้องขอภายในแอปพลิเคชันด้วยเธรดน้ำหนักที่เบากว่าหรือแนวทางที่คล้ายกันแทน

นี่คือสิ่งที่ - การแก้ปัญหาทั้งหมดจะขาดในบางวิธีรูปร่างหรือรูปแบบ CGI ในขณะที่ง่ายมีปัญหาร้ายแรงเกี่ยวกับขนาด ปลั๊กอินในเว็บเซิร์ฟเวอร์จะผูกเข้ากับเว็บเซิร์ฟเวอร์เอง (apache vs nginx vs IIS vs ... ) และสูญเสียฟังก์ชันการทำงานทั่วไปของภาษา Microsoft มีขบวนพาเหรดของเทคโนโลยีที่ต้องการส่งเสริม และถ้าคุณรู้ภาษาเดียวคุณจะไม่เขียนโปรแกรมต่อไปแทนที่จะมีภาษาต่าง ๆ ในส่วนต่าง ๆ ของสแต็ก (จาวาสคริปต์ในไคลเอนต์และ Node.js)?

ดังนั้นคุณมีวันนี้ บางคนทำงานในสแต็ก Java (ที่มี scala และ clojure กลายเป็นเรื่องผิดปกติ) อื่น ๆ ใน C # สแต็ค อื่น ๆ ในสแต็ก JavaScript php มีจำนวนค่อนข้างน้อย หลามจำนวนมาก คุณยังคงสามารถพบ Perl ได้ที่นั่น (และหากคุณดูไซต์ที่มีปริมาณน้อยคุณจะยังพบ CGIs อยู่) ด้วยการประมวลผลแบบคลาวด์ Google ได้ส่งเสริม Go เป็นภาษาเว็บฝั่งเซิร์ฟเวอร์ที่ทำงานได้

แต่ละคนมีข้อดีข้อเสียกรอบและเซิร์ฟเวอร์ของมัน ความนิยมที่สัมพันธ์กันของการลดลงและการไหลเหล่านี้เป็นเทคโนโลยีรอบตัวพวกเขาเปลี่ยนแปลง พวกเขาทำสิ่งต่าง ๆ ได้ดี


นี่คือสิ่งที่ฉันกำลังมองหา คำตอบที่ครอบคลุมและไม่มีคำตอบ ขอขอบคุณ!
Chris Dance

1
"ทางออกคือการย้ายทางแยกและวนรอบ exec ลงในเว็บเซิร์ฟเวอร์เอง" ไม่จำเป็นต้อง: FastCGI, reverse proxying เป็นโซลูชันที่รู้จักกันดีในการเชื่อมต่อกับเซิร์ฟเวอร์แอปพลิเคชันโดยไม่ต้องสนใจภาษาเป้าหมายหรือการใช้งานเว็บเซิร์ฟเวอร์ที่ใช้โปรโตคอลการสื่อสารข้ามกระบวนการที่ระบุไว้อย่างดีเพื่อทำงานของพวกเขา
jhominal

1
@jhominal "แทนที่จะสร้างกระบวนการใหม่สำหรับแต่ละคำขอ FastCGI ใช้กระบวนการถาวรเพื่อจัดการชุดของคำขอกระบวนการเหล่านี้เป็นของเซิร์ฟเวอร์ FastCGI ไม่ใช่เว็บเซิร์ฟเวอร์" ( แหล่งที่มา ) - มันคือหัวใจนี่คือสิ่งที่แอปพลิเคชันเซิร์ฟเวอร์ทำ กระบวนการถาวรที่จัดการการร้องขอโดยไม่ต้องทำ fork และ exec

@MichaelT: คุณกำลังใช้ "เว็บเซิร์ฟเวอร์" และ "แอปพลิเคชันเซิร์ฟเวอร์" ราวกับว่าข้อกำหนดนั้นใช้แทนกันได้และในคำตอบของคุณคุณใช้ "เว็บเซิร์ฟเวอร์" ส่วนใหญ่เพื่ออ้างถึง apache, nginx - นั่นคือซอฟต์แวร์เว็บเซิร์ฟเวอร์ทั่วไปที่ มีเพียงความสามารถในการโปรแกรมแบบ จำกัด (ที่แกนกลาง)
jhominal

1
ฉันไม่คิดว่ามันจะดีพอที่จะกล่าวถึงการฝึกฝน (โดยทั่วไปแล้ว) ว่าการให้แต่ละแอปพลิเคชั่นเป็นเว็บเซิร์ฟเวอร์ของตัวเองโดยส่วนใหญ่มักจะมีผู้รับมอบฉันทะ HTTP หนึ่งรายการขึ้นไป
ฮอบส์

19

ใช่ภาษาการเขียนโปรแกรมทั่วไปสามารถให้บริการในการเขียนส่วนฝั่งเซิร์ฟเวอร์ของเว็บไซต์

อย่างไรก็ตามคุณภาพของภาษาการเขียนโปรแกรมในเรื่องนี้เช่นเดียวกับสิ่งอื่น ๆ มักจะเป็นเพียงหนึ่งในหลาย ๆ ปัจจัยที่มีส่วนทำให้ความนิยมของมัน

ตัวอย่างเช่นฉันคิดว่า PHP เป็นเว็บไซต์ยอดนิยมเพราะ:

  • มันง่ายมากที่จะอัพเกรดจากเว็บไซต์คงที่ไปเป็นเว็บไซต์ไดนามิก PHP เพียงแค่เปลี่ยนนามสกุลไฟล์ของไฟล์ HTML ของคุณวาง<?phpแท็กที่จุดเริ่มต้นและหากติดตั้ง PHP ไว้คุณมีเว็บไซต์ไดนามิก! ส่วนที่เหลือของเวิร์กโฟลว์นั้นเหมือนกับเว็บไซต์แบบคงที่
  • เนื่องจากความง่ายในการปรับใช้โฮสต์เว็บที่ต้องการเสนอเว็บไซต์แบบไดนามิกจึงเลือกใช้ PHP ทำให้มันเป็นแพลตฟอร์มฝั่งเซิร์ฟเวอร์ที่ปรับใช้อย่างกว้างขวางที่สุด
  • มันเข้าสู่ตลาดนั้นในเวลาที่เหมาะสม

และเมื่อมีการใช้งาน PHP อย่างกว้างขวางมันก็น่าสนใจที่จะเขียนเว็บแอพพลิเคชั่นที่จริงจังมากขึ้นใน PHP เพื่อรับประโยชน์จากความหลากหลายของการปรับใช้นั้น

ในการพูดด้วยวิธีทั่วไป: การใช้ภาษามักจะเกี่ยวกับคำตอบของคำถามเหล่านี้:

  • การทำสิ่งที่ฉันต้องการทำได้ง่ายเพียงใด?
  • ภาษาที่ฉันต้องการทำมีให้การสนับสนุนอย่างกว้างขวางเพียงใด?

7

ฉันคิดถูกแล้วว่าเซิร์ฟเวอร์ต้องการอินเทอร์เฟซบางอย่างเช่น 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 (เว็บฟอร์ม) ทำให้มันง่ายมากสำหรับนักพัฒนา Windows Forms ซึ่งส่วนใหญ่เป็น VB coders เพื่อสลับไปยังเว็บ


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>

รหัสใด ๆ ที่ทำงานบนเซิร์ฟเวอร์ที่รับฟังคำขอบนซ็อกเก็ต 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, สตริงเคียวรี, ส่วนหัวยอมรับภาษา, ฯลฯ คุณสามารถเพิ่มรหัสเพื่อสร้างการตอบสนองที่มีความหมายตามคำขอ แต่จากนั้นโค้ดจะได้รับมาก ซับซ้อน นอกจากนี้โปรแกรมเมอร์ต้องการเน้นที่การเขียนแอปพลิเคชันบนเว็บโดยไม่ต้องกังวลกับรายละเอียดของวิธีจัดการกับคำขอ HTTP

วิธีการแก้ปัญหาที่เหมาะสมมากขึ้นจะใช้เว็บเซิร์ฟเวอร์เช่นApache HTTPD , IISหรือNginx เว็บเซิร์ฟเวอร์เป็นเพียงโปรแกรมที่ฟังบนซ็อกเก็ต TCP ที่เกี่ยวข้องยอมรับการร้องขอหลายรายการ (อาจพร้อมกัน) และตัดสินใจว่าจะสร้างการตอบสนองอย่างไรตาม URL คำขอส่วนหัวและกฎอื่น ๆ จะเป็นการดีที่รายละเอียดจำนวนมากเช่น SSL, การควบคุมการเข้าถึงและการ จำกัด ทรัพยากรได้รับการดูแลผ่านการกำหนดค่ามากกว่ารหัส บ่อยครั้งที่เว็บเซิร์ฟเวอร์จะกำหนดคำตอบที่ประกอบด้วยเนื้อหาจากไฟล์ในระบบไฟล์

สำหรับเนื้อหาแบบไดนามิกเว็บเซิร์ฟเวอร์สามารถกำหนดค่าให้รันโค้ดบางอย่างเพื่อสร้างการตอบสนอง กลไกหนึ่งในการทำเช่นนั้นคือกับ CGI - เซิร์ฟเวอร์ตั้งค่าตัวแปรสภาพแวดล้อมบางอย่างตามคำขอดำเนินงานโปรแกรมและคัดลอกผลลัพธ์ไปยังซ็อกเก็ต TCP โซลูชันที่ซับซ้อนกว่านี้เล็กน้อยคือการมีโมดูลที่เพิ่มการสนับสนุนไปยังเว็บเซิร์ฟเวอร์สำหรับการเรียกรหัสในภาษาการเขียนโปรแกรมอื่น (เช่นmod_php สำหรับ Apache ) อีกทางเลือกหนึ่งคือการเขียนเว็บเซิร์ฟเวอร์ในภาษาเดียวกับเว็บแอปพลิเคชันซึ่งในกรณีนี้การจัดส่งคำขอเป็นเพียงการเรียกใช้ฟังก์ชัน นั่นคือกรณีที่มีNode.jsและเครื่องมือเซิร์ฟเล็ต Java เช่นApache Tomcat

ทางเลือกของเทคโนโลยีขึ้นอยู่กับคุณและขึ้นอยู่กับภาษาการเขียนโปรแกรมที่คุณต้องการใช้สภาพแวดล้อมการโฮสต์ที่พร้อมใช้งานสำหรับคุณข้อกำหนดด้านประสิทธิภาพความคิดเห็นยอดนิยม ตัวอย่างเช่น CGI ไม่ได้รับการสนับสนุนเมื่อเร็ว ๆ นี้เนื่องจากความต้องการที่จะเปิดตัวโปรแกรมภายนอก จำกัด ขีดความสามารถในการขยาย


1

เว็บเซิร์ฟเวอร์เป็นโปรแกรมที่เขียนด้วยภาษาการเขียนโปรแกรมใด ๆ ที่จัดการ "การรับส่งข้อมูลเว็บ" ผ่านซ็อกเก็ต (s) ที่ยึดตามโปรโตคอลระดับมาตรฐาน / แอปพลิเคชัน (HTTP และอื่น ๆ ) ภาษาโปรแกรมส่วนใหญ่จะให้คุณสร้างซ็อกเก็ต

ฉันคิดถูกแล้วว่าเซิร์ฟเวอร์ต้องการอินเทอร์เฟซบางอย่างเช่น CGI เพื่อให้เซิร์ฟเวอร์และภาษาโปรแกรมทำงานร่วมกันได้หรือไม่?

ไม่จำเป็นต้องมีโปรแกรมเซิร์ฟเวอร์เฉพาะและโปรแกรมแอปพลิเคชันของคุณ - พวกเขาสามารถเหมือนกัน (ไม่สนใจประเด็นที่เกี่ยวข้องกับประสิทธิภาพ)


0

คุณสามารถใช้ไลบรารีเซิร์ฟเวอร์HTTPบางไลบรารีเช่นlibonionแม้ในโปรแกรมของคุณใน C (หรือ C ++ โปรดดูWt ด้วย ) นอกจากนี้ยังมีห้องสมุดลูกค้า HTTP (เช่นlibcurl )

คุณสามารถใช้อื่น ๆ HTTP ห้องสมุดเช่นocsigen & ocamlnetสำหรับOCaml

มีหลายภาษาที่อุทิศให้กับเว็บ (นอก PHP) เช่นOpa , HOP , Kayaและอื่น ๆ (ทั้ง HOP & Opa สามารถผสมการคำนวณฝั่งเซิร์ฟเวอร์และเบราว์เซอร์ได้อย่างง่ายดาย แต่คุณต้องทำด้วยความเจ็บปวดและด้วยตนเอง PHP อย่างชัดเจนโดยใช้เทคนิคAJAXและใช้จาวาสคริปต์สำหรับเบราว์เซอร์ด้วยมือในทางกลับกัน HOP, Opa, Ocsigen สามารถสร้าง Javascript นั้นได้

คุณยังสามารถใช้เทคโนโลยีFASTCGIเพื่อเพิ่มบริการแบบไดนามิกให้กับบางเว็บเซิร์ฟเวอร์ ... FASTCGI นั้นดีกว่าCGI แบบเก่าธรรมดาซึ่งเริ่มกระบวนการใหม่สำหรับทุกคำขอ HTTP ขาเข้าในขณะที่แอปพลิเคชัน FASTCGI สามารถให้บริการคำขอ HTTP จำนวนมากในกระบวนการเดียวกัน BTW, PHP สามารถกำหนดค่าให้ทำงานเป็นแอปพลิเคชัน FASTCGI

C.Queinnec สังเกตว่าการท่องเว็บและการดำเนินการต่อเนื่องมีความสัมพันธ์กันอย่างมีนัยสำคัญ

PS ฉันไม่ชอบ PHP และฉันเชื่อว่าความนิยมนั้นมีเหตุผลทางประวัติศาสตร์และสังคม แน่นอน PHP นั้นแพร่หลายก่อน AJAX ใช้กันอย่างแพร่หลายและเก่ากว่า HOP หรือ Opa (หรือ Ocsigen)

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.