ชุมชนนักพัฒนาถกเถียงเรื่องชื่อและความจำเป็นของโปรโตคอลการถ่ายโอนไฟล์ใหม่ ท่ามกลางการเปรียบเทียบกับ HTTP

BigGo Editorial Team
ชุมชนนักพัฒนาถกเถียงเรื่องชื่อและความจำเป็นของโปรโตคอลการถ่ายโอนไฟล์ใหม่ ท่ามกลางการเปรียบเทียบกับ HTTP

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

ความกังวลเรื่องชื่อที่ซ้ำซ้อน

คำวิจารณ์ที่เห็นได้ชัดที่สุดจากชุมชนมุ่งเน้นไปที่การเลือกชื่อของโปรโตคอล นักพัฒนาหลายคนชี้ให้เห็นว่า RTP นั้นถูกใช้เป็นคำย่อของ Real-time Transport Protocol อยู่แล้ว ซึ่งเป็นมาตรฐานที่ใช้กันอย่างแพร่หลายสำหรับการส่งเสียงและวิดีโอผ่านเครือข่าย IP ดังที่นักพัฒนาคนหนึ่งกล่าวว่า:

จากประสบการณ์การทำงานกับ RTP ผมสับสนมากว่าทำไมถึงเลือกใช้ชื่อนี้เป็นโปรโตคอลหลัก (โดยเฉพาะอย่างยิ่งเมื่อแอปพลิเคชันส่วนใหญ่ต้องใช้ RTCP ด้วย ดังนั้นอย่างดีที่สุดก็คงเป็นสองโปรโตคอลหลัก...) - pavlov

ผู้พัฒนาโปรโตคอลได้ยอมรับข้อผิดพลาดนี้ในส่วนแก้ไขเพิ่มเติม โดยระบุว่ากำลังร่างข้อเสนอใหม่เพื่อแก้ไขปัญหาเรื่องการตั้งชื่อ

ความเข้ากันได้กับ HTTP และความจำเป็น

นักพัฒนาหลายคนตั้งคำถามว่าจำเป็นต้องมีโปรโตคอลใหม่หรือไม่ เมื่อ HTTP มีความสามารถที่มีอยู่แล้ว ผู้แสดงความคิดเห็นหลายคนชี้ให้เห็นว่า HTTP/1.1 พร้อมคำขอแบบช่วง (range requests) ก็มีโซลูชันที่มีประสิทธิภาพสำหรับการถ่ายโอนไฟล์ขนาดใหญ่อยู่แล้ว ดังที่นักพัฒนาที่มีประสบการณ์คนหนึ่งชี้แจงว่า:

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

ข้อพิจารณาทางเทคนิค

ข้อกำหนดของโปรโตคอลได้รับการตรวจสอบทางเทคนิคจากชุมชน โดยเฉพาะในประเด็นต่อไปนี้:

  1. การเลือกใช้ Endianness - การใช้รูปแบบ little-endian ในข้อกำหนดก่อให้เกิดการถกเถียงเกี่ยวกับข้อตกลงเรื่องลำดับไบต์ในเครือข่าย
  2. การจัดการโทเค็น - ความกังวลเกี่ยวกับผลกระทบด้านความปลอดภัยของโทเค็นที่ไคลเอนต์เลือก
  3. ความสามารถในการขยายโปรโตคอล - คำถามเกี่ยวกับพื้นที่จำกัดสำหรับประเภทคำขอในอนาคตที่มีการจัดสรรเพียง 1 บิต

การอ้างประสิทธิภาพ

ในขณะที่โปรโตคอลนี้มีเป้าหมายที่จะปรับปรุงประสิทธิภาพของ BitTorrent ในการถ่ายโอนจากแหล่งเดียว สมาชิกในชุมชนได้ท้าทายแนวคิดนี้ โดยชี้ให้เห็นว่า BitTorrent สามารถทำความเร็วในการถ่ายโอนได้ดีเยี่ยมในสถานการณ์แหล่งเดียวเมื่อตั้งค่าอย่างเหมาะสม นักพัฒนาบางคนกล่าวว่าคุณสมบัติ web seed ของ BitTorrent สามารถให้ประสิทธิภาพที่เทียบเท่ากับ HTTP ได้

ทิศทางในอนาคต

การอภิปรายได้ชี้ให้เห็นถึงพื้นที่ที่ต้องปรับปรุงในโปรโตคอลการถ่ายโอนไฟล์โดยทั่วไป ได้แก่:

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

ผู้พัฒนาได้รับทราบข้อเสนอแนะและระบุว่ากำลังพัฒนาข้อเสนอฉบับแก้ไขเพื่อจัดการกับปัญหาที่ระบุ โดยเฉพาะอย่างยิ่งการชนกันของชื่อและความจำเป็นในการเพิ่มฟิลด์โปรโตคอล

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