Common Gateway Interface ( CGI ) เทคโนโลยีเว็บจากยุค 1990 ที่ถูกทิ้งไปเนื่องจากความช้า กำลังได้รับความสนใจอีกครั้งจากนักพัฒนา การทดสอบล่าสุดแสดงให้เห็นว่า CGI สามารถรองรับโหลดที่น่าประทับใจบนฮาร์ดแวร์สมัยใหม่ ท้าทายความเชื่อที่ฝังรากลึกเกี่ยวกับข้อจำกัดของมัน
การทดลองของ Jake Gold แสดงให้เห็นว่าโปรแกรม CGI ที่เขียนด้วย Go ที่ทำงานบนโปรเซสเซอร์ AMD 3700X 16 เธรด สามารถให้บริการได้มากกว่า 2,400 คำขอต่อวินาที ซึ่งแปลเป็นมากกว่า 200 ล้านคำขอต่อวัน ระดับประสิทธิภาพนี้ทำให้ CGI กลับมาแข่งขันได้สำหรับแอปพลิเคชันเว็บจริงจัง ซึ่งดูเหมือนเป็นไปไม่ได้เมื่อไม่กี่ปีที่ผ่านมา
ตัวชี้วัดประสิทธิภาพ:
- คำขอต่อวินาที: 2,400+ ครั้ง
- ความจุคำขอรายวัน: 200+ ล้านครั้ง
- ฮาร์ดแวร์ทดสอบ: โปรเซสเซอร์ AMD 3700X แบบ 16 เธรด
- การใช้งาน: โปรแกรม CGI ที่พัฒนาด้วย Go + SQLite
ปัญหาเดิมและเหตุผลที่มันคงอยู่
CGI ทำงานโดยการสร้างโปรเซสใหม่สำหรับทุกคำขอเว็บ - เริ่มโปรแกรม รันมัน แล้วปิดมันลงอย่างสมบูรณ์ ในช่วงปลายยุค 1990 แนวทางนี้ช้าอย่างเจ็บปวด ทำให้นักพัฒนาสร้างทางเลือกอื่นเช่น mod_php ของ PHP และ FastCGI เพื่อให้โค้ดทำงานอยู่ในหน่วยความจำระหว่างคำขอ
การอพิพากษ์ในชุมชนเผยให้เห็นว่าบทเรียนนี้ฝังลึกในความคิดของนักพัฒนาอย่างไร โปรแกรมเมอร์หลายคนใช้เวลาหลายทศวรรษหลีกเลี่ยงรูปแบบ process-per-request เชื่อว่ามันมีข้อบกพร่องพื้นฐาน อย่างไรก็ตาม ความเชื่อนี้อิงจากข้อจำกัดของคอมพิวเตอร์ในยุค 1990 มากกว่าปัญหาที่แท้จริงของแนวทางนั้นเอง
บริบททางประวัติศาสตร์:
- ปัญหาเดิม: ค่าใช้จ่ายในการสร้างกระบวนการบนฮาร์ดแวร์ยุค 1990
- ภาษาโปรแกรมเก่า: Perl , Python , Java (เวลาเริ่มต้นช้า)
- ภาษาโปรแกรมสมัยใหม่: Go , Rust (เวลาเริ่มต้นเร็ว)
- ปัญหาด้านความปลอดภัย: ช่องโหว่ Shellshock (2014), ข้อกังวลเรื่องการตรวจสอบข้อมูลนำเข้า
ข้อได้เปรียบสมัยใหม่เกิดขึ้น
ภูมิทัศน์คอมพิวเตอร์ในปัจจุบันเปลี่ยนแปลงไปอย่างมาก เซิร์ฟเวอร์ในปัจจุบันมักมี CPU เธรดหลายร้อยตัว และแม้แต่เวอร์ชวลแมชชีนขนาดเล็กก็มี 16 คอร์ ที่สำคัญกว่านั้น ภาษาเช่น Go และ Rust สตาร์ทอัปเร็วกว่าสคริปต์ Perl, Python และ Java ที่ครองการพัฒนาเว็บยุคแรกมาก
โมเดล process-per-request จริงๆ แล้วมีข้อได้เปรียบที่น่าสนใจในสภาพแวดล้อมสมัยใหม่ แต่ละคำขอทำงานแยกกันอย่างสมบูรณ์ ขจัดความเสี่ยงด้านความปลอดภัยที่มาจากการแชร์สถานะระหว่างคำขอ การแยกนี้ยังทำให้โปรแกรม CGI เก่งในการใช้ประโยชน์จาก CPU หลายคอร์พร้อมกัน
ที่สำคัญที่สุด โปรแกรม CGI เนื่องจากทำงานเป็นโปรเซสแยก จึงเก่งมากในการใช้ประโยชน์จาก CPU หลายตัว!
การอภิปรายเรื่องความปลอดภัยและประสิทธิภาพ
ความสนใจใหม่ใน CGI ได้จุดประกายการอภิปรายเกี่ยวกับผลกระทบด้านความปลอดภัย นักวิจารณ์ชี้ไปที่ประวัติช่องโหว่ความปลอดภัยของ CGI รวมถึงความอ่อนไหวต่อบั๊ก Shellshock ในปี 2014 อย่างไรก็ตาม ผู้สนับสนุนโต้แย้งว่าปัญหาเหล่านี้เกิดจากการตรวจสอบข้อมูลนำเข้าที่ไม่ดีมากกว่าข้อบกพร่องพื้นฐานในโปรโตคอล CGI เอง
การเปรียบเทียบประสิทธิภาพก็สร้างการอภิปรายเช่นกัน ในขณะที่โปรแกรม Go ที่ใช้แนวทางดั้งเดิมสามารถเกิน 10,000 คำขอต่อวินาทีได้อย่างง่ายดาย แต่แอปพลิเคชันทุกตัวไม่จำเป็นต้องมีประสิทธิภาพสูงขนาดนั้น ความเรียบง่ายและประโยชน์จากการแยกของ CGI อาจมีน้ำหนักมากกว่าความเร็วดิบสำหรับกรณีการใช้งานหลายอย่าง
CGI เทียบกับทางเลือกสมัยใหม่:
- ข้อได้เปรียบของ CGI: การแยกกระบวนการอย่างสมบูรณ์ การใช้งาน multi-core ได้อย่างยอดเยี่ยม
- แนวทางแบบดั้งเดิม: สามารถจัดการคำขอได้มากกว่า 10,000 ครั้งต่อวินาทีด้วย Go
- การแลกเปลี่ยน: ความปลอดภัยและความเรียบง่าย เทียบกับประสิทธิภาพสูงสุด
- กรณีการใช้งาน: การสร้างต้นแบบอย่างรวดเร็ว แอปพลิเคชันแบบ polyglot ส่วนขยายสำหรับลูกค้า
การประยุกต์ใช้จริงในปัจจุบัน
การฟื้นคืนของ CGI ไม่ใช่แค่ความอยากรู้ทางวิชาการ นักพัฒนากำลังค้นหาการประยุกต์ใช้จริง โดยเฉพาะสำหรับการสร้างต้นแบบอย่างรวดเร็วและการสร้างแอปพลิเคชันเว็บ polyglot ที่ภาษาโปรแกรมต่างๆ จัดการเส้นทาง URL ต่างๆ แนวทางนี้ยังทำงานได้ดีสำหรับการอนุญาตให้ลูกค้าขยายซอฟต์แวร์ด้วยโค้ดกำหนดเองโดยไม่ต้องใช้เฟรมเวิร์กการรวมที่ซับซ้อน
เว็บเซิร์ฟเวอร์สมัยใหม่เช่น h2o กำลังยอมรับแนวโน้มนี้ โดยเสนอไฟล์กำหนดค่าที่สะอาดซึ่งทำให้การปรับใช้ CGI ตรงไปตรงมา นักพัฒนาบางคนแม้แต่มอง CGI เป็นรากฐานที่ดีกว่าสำหรับ serverless computing มากกว่าฟังก์ชัน lambda ที่เป็นกรรมสิทธิ์ เนื่องจากมันอิงจากมาตรฐานเปิดมากกว่าการใช้งานที่เฉพาะเจาะจงกับผู้ขาย
การกลับมาของ CGI แสดงตัวอย่างที่น่าสนใจของการที่เทคโนโลยีที่เปลี่ยนแปลงสามารถฟื้นฟูแนวทางที่ดูเหมือนล้าสมัย ในขณะที่มันอาจไม่แทนที่เว็บเฟรมเวิร์กสมัยใหม่ทั้งหมด ความเรียบง่ายและคุณสมบัติการแยกของ CGI ทำให้คุ้มค่าที่จะพิจารณาใหม่สำหรับแอปพลิเคชันเฉพาะ
Reference: Serving 200 million requests per day with a cgi-bin