Gnutella: โปรโตคอลที่อยู่รอดยาวนานกว่าโลกที่สร้างมันขึ้นมา

 (rickcarlino.com)
1 คะแนน โดย GN⁺ 10 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Gnutella เป็นโปรโตคอลแชร์ไฟล์ที่แทบถูกลืมไปแล้ว แต่เคยเป็นตัวอย่างจริงของเทคโนโลยีกระจายศูนย์ที่ผู้ใช้หลายล้านคนใช้งานโดยไม่ได้ตั้งใจจะเรียนรู้เรื่องระบบกระจายศูนย์ เพียงเพื่อแก้ปัญหาการดาวน์โหลด MP3
  • ในช่วงปี 2000–2001 อัตราการเข้าถึงอินเทอร์เน็ตของสหรัฐฯ แตะ 50%, เครื่องเล่น MP3 มีราคาถูกลง, การสตรีมยังมีข้อจำกัด และวัฒนธรรมการจัดการไฟล์ด้วยตนเองช่วยผลักดันการยอมรับ
  • โครงสร้างแบบไร้เซิร์ฟเวอร์และการไม่มี จุดล้มเหลวเพียงจุดเดียว ทำให้หลังจาก AOL ยกเลิกโครงการแล้วก็ยากจะย้อนกลับได้ และแม้จะพยายามสกัดกั้นมาหลายปีก็ยังทำงานต่อไป
  • โครงสร้างพื้นฐานคือการรวมการรับส่งไฟล์ผ่าน HTTP กับ TCP gossip protocol โดยมี PING/PONG, QUERY/QUERYHIT และ PUSH รับหน้าที่ค้นหา ตอบกลับ และหลบเลี่ยงไฟร์วอลล์
  • เหตุที่มันหายไปจากกระแสหลักไม่ใช่เพราะล้มเหลวทางเทคนิคในทันที แต่เพราะ สภาพแวดล้อมของผู้ใช้ ในยุคนั้นหายไปแล้ว ขณะที่เครือข่ายยังคงมีชีวิตต่อในขนาดที่เล็กลง

เหตุผลที่ Gnutella อยู่รอดได้นาน

  • Gnutella เป็นโปรโตคอลแชร์ไฟล์ที่หลายคนลืมไปแล้ว แต่เป็นกรณีตัวอย่างที่ผู้ใช้ทั่วไปหลายล้านคนใช้เพื่อแก้ปัญหาจริง โดยไม่ได้พยายามทำความเข้าใจเทคโนโลยีกระจายศูนย์
  • ผู้ใช้เข้าร่วมเครือข่าย Gnutella ไม่ใช่เพราะแรงจูงใจอย่างมูลค่าโทเคนที่เพิ่มขึ้น แต่เพราะต้องการ ดาวน์โหลด MP3 และเครือข่ายก็เติบโตอย่างรวดเร็ว ก่อนจะทรงตัวอยู่เกือบ 10 ปี แล้วค่อยลดลงแต่ยังคงมีผู้ใช้อยู่ต่อเนื่องเป็นหางยาว
  • Gnutella เป็นเทคโนโลยีเบื้องหลังที่ซ่อนอยู่ใต้โปรเจ็กต์ที่เด่นกว่าอย่าง LimeWire และด้วยโมเดล สวนปิด ของแพลตฟอร์มยุคใหม่ จึงมีผู้ใช้อินเทอร์เน็ตจำนวนมากที่แทบไม่คุ้นเคยกับระบบไฟล์อีกต่อไป
  • โปรเจ็กต์ Gnutella เริ่มต้นจากเดโมภายในที่ AOL ยกเลิก แต่หลุดออกสู่สาธารณะ และเพราะการออกแบบแบบกระจายศูนย์ไร้เซิร์ฟเวอร์ ทำให้เมื่อถูกปล่อยออกมาแล้วก็ยากจะดึงกลับ
  • Gnutella ยังคงทำงานอยู่หลายปีแม้มีความพยายามจะหยุดมัน และยังสามารถหาไฟล์ต้นฉบับ Gnutella.exe ได้จาก archive.org
  • เหตุผลที่ยากจะมองว่าเป็นโปรโตคอลที่ล้มเหลวมีชัดเจน
    • มันขยายตัวไปถึงระดับผู้ใช้พร้อมกันหลายล้านคน และรุ่งเรืองในฐานะกรณีใช้งานกระแสหลักอยู่ราว 10 ปี
    • สาเหตุที่หายไปจากกระแสหลักไม่ใช่ความล้มเหลวฉับพลันของตัวโปรโตคอลเอง แต่เป็นเพราะ สภาพแวดล้อมของผู้ใช้ ที่ Gnutella ถือกำเนิดขึ้นได้หายไปแล้ว
    • แม้วันนี้มันก็ยังทำงานต่อไปในขนาดที่เล็กลง

เงื่อนไขทางประวัติศาสตร์ที่ทำให้เกิดการยอมรับ

  • ราวปี 2000–2001 อัตราการเข้าถึงอินเทอร์เน็ต ของผู้บริโภคในสหรัฐฯ แตะ 50% และอินเทอร์เน็ตกำลังเปลี่ยนจากเครื่องมือของคนเฉพาะกลุ่มไปเป็นโครงสร้างพื้นฐานในชีวิตประจำวัน
  • มีหลายปัจจัยที่ทำให้การแชร์ไฟล์เพลงกลายเป็นเรื่องแพร่หลายพร้อมกัน
    • อุตสาหกรรมเพลงปรับตัวไม่ทันต่อความต้องการของผู้บริโภคที่เปลี่ยนไป
    • เครื่องเล่น MP3 และสตอเรจแบบโซลิดสเตตมีราคาถูกลงและแพร่หลายมากขึ้น
    • บนอินเทอร์เน็ตแบบ dial-up ความเร็วต่ำ การสตรีมเพลงยังไม่ใช่เรื่องที่ใช้งานได้จริง
    • การจัดการพื้นที่ดิสก์, ไดเรกทอรี, แบ็กอัป และไฟล์ดาวน์โหลดด้วยตัวเอง ยังเป็นสิ่งที่ผู้ใช้คอมพิวเตอร์ทั่วไปในยุคนั้นยอมรับได้
  • เงื่อนไขเหล่านี้ก่อให้เกิดยุคทองของการแชร์ไฟล์ที่ยืนยาวมาจนถึงต้นทศวรรษ 2010 และ LimeWire ก็กลายเป็นชื่อที่แทนประสบการณ์ในยุคนั้น
  • Gnutella ไม่มี จุดล้มเหลวเพียงจุดเดียว จึงกำจัดได้ยาก และแม้โปรโตคอลพื้นฐานจะเรียบง่าย แต่ก็ขยายต่อได้ง่ายด้วยส่วนขยายทางเลือกที่รวมอยู่ในสเปก

ลักษณะพื้นฐานของโปรโตคอล

  • สำหรับผู้ใช้ส่วนใหญ่ Gnutella คือเครื่องมือรับส่งไฟล์ แต่ในแก่นแท้มันใกล้เคียงกับ เสิร์ชเอนจิน P2P สำหรับค้นหา blob มากกว่า
  • ตามหลักการแล้ว มันอาจใช้ทำ DNS แบบง่าย, ตารางค้นหาเมทาดาทาแบบคีย์/ค่าในระดับโลก, หรือบริการจับคู่ลีกของ Unreal Tournament ได้ แต่ในประวัติศาสตร์จริง ผู้คนจดจำมันในฐานะระบบดาวน์โหลดไฟล์ที่ตรงกับคำค้น โดยเฉพาะการดาวน์โหลด MP3
  • ร่างสเปก Gnutella 0.6 ระบุว่ารีซอร์สที่แชร์กันอาจเป็นอะไรก็ได้ เช่น การแมปไปยังรีซอร์สอื่น, คีย์เข้ารหัส, ไฟล์ทุกชนิด, หรือเมทาดาทาของรีซอร์สที่อ้างอิงด้วยคีย์ได้
  • ลำดับการใช้งานทั่วไปมีดังนี้
    • เปิดใช้งาน ไคลเอนต์ Gnutella เช่น LimeWire, BearShare หรือ GTK-Gnutella
    • ไคลเอนต์เชื่อมต่อไปยัง peer จำนวนหนึ่งที่ใดก็ได้บนอินเทอร์เน็ต
    • ผู้ใช้ป้อนคำค้นอย่าง LinkinPark.mp3.exe
    • คำค้นจะกระจายจาก peer หนึ่งไปยังอีก peer หนึ่งออกไปทั่วเครือข่าย
    • ผลลัพธ์จากคอมพิวเตอร์แบบสุ่มทั่วโลกจะค่อย ๆ ตอบกลับมา
    • ผู้ใช้ดูชื่อไฟล์เพื่อเดาว่าเป็นของปลอมหรือไม่ เปรียบเทียบความเร็วการเชื่อมต่อ และหวังว่าจะไม่มีไวรัส
    • เมื่อเลือกไฟล์แล้ว ไคลเอนต์จะดาวน์โหลดชิ้นส่วนของไฟล์ผ่าน HTTP โดยตรงจากคอมพิวเตอร์ของผู้ใช้อื่น
  • ผู้ใช้อาจได้ไฟล์ผิด, บังเอิญค้นพบคอนเทนต์ใหม่, หรือได้รับมัลแวร์ และพฤติกรรมแบบ เก็บหาไปเรื่อยอย่างสำรวจ นี้ก็หายไปพร้อมกับการมาถึงของระบบแนะนำ
  • โดยทั่วไปไคลเอนต์จะมีฟังก์ชันหลักอยู่สี่อย่าง
    • ตัวจัดการคำค้น: จัดการการค้นหาที่ค่อย ๆ กระจายผ่าน peer หลายพันราย
    • ตัวจัดการไฟล์: ระบุไดเรกทอรีหรือพาธที่จะแชร์ และตำแหน่งเก็บไฟล์ที่ดาวน์โหลด
    • ตัวจัดการการรับส่ง: จัดการการโอนถ่ายไฟล์แบบสองทิศทาง การ resume การแบ่งส่วน และการควบคุมการรับส่ง
    • ฟีเจอร์เสริม: อาจมี IRC chat, กระดานข้อความ, ตัวเฝ้าดูคำค้น และการสำรวจโฮสต์เฉพาะ แต่หลายอย่างไม่ได้เป็นส่วนหนึ่งของตัวโปรโตคอลโดยตรง
  • ในระบบนิเวศของ Gnutella มีผู้นำตลาดอย่าง LimeWire แต่ก็มีไคลเอนต์หลายตัวอยู่ร่วมกัน และนักพัฒนาอิสระก็สามารถเขียนไคลเอนต์ใหม่จากศูนย์ได้
  • ระหว่างการพัฒนา Gnutella Bun Client พบว่ามีหลายอย่างที่ไม่อยู่ในสเปก, ฟีเจอร์ที่ไม่มีเอกสาร, และความสามารถที่กระจัดกระจายอยู่ในสเปกเสริมต่าง ๆ แสดงให้เห็นว่าโปรโตคอลวิวัฒน์แบบอินทรีย์

การผสานกันของ HTTP และ gossip protocol

  • การรัน HTTP server บนคอมพิวเตอร์ส่วนตัวแล้วบอก IP address ให้คนอื่นดูเหมือนจะพอสำหรับการแชร์ไฟล์ แต่ทุกวันนี้การเปิดเผยพอร์ต TCP ขาเข้าทำได้ยากเพราะ NAT, ไฟร์วอลล์ และนโยบายของ ISP ตามบ้าน
  • เมื่อ 20 ปีก่อน การรัน HTTP server ขนาดเล็กบนเครื่องโลคัลและเปิดให้เข้าถึงผ่าน public IP เป็นสิ่งที่ทำได้บ่อยกว่าปัจจุบันมาก
  • Gnutella ใช้ประโยชน์จากสภาพแวดล้อมนั้น โดยให้ผู้เข้าร่วมแต่ละคนโฮสต์ไฟล์ได้ภายใน mesh ของ peer ที่คอย gossip กัน
  • ขั้นตอนการรับส่งตอนดาวน์โหลดไฟล์ด้วย LimeWire คล้ายกับการรับไฟล์ผ่าน curl หรือ wget
  • แต่การมีแค่ HTTP server อย่างเดียวก็ยังไม่ทำให้กลายเป็นเครือข่ายแชร์ไฟล์ P2P
    • แม้ในเวลานั้น ISP ก็มักไม่ได้ให้ static IP ที่คงที่เสมอไป
    • IP address ที่แชร์วันนี้อาจเปลี่ยนไปในวันพรุ่งนี้
    • URL แบบสุ่มอย่าง http://74.6.231.21:4000 มีแนวโน้มสูงว่าจะไม่ถูกจัดทำดัชนีโดยเสิร์ชเอนจิน และถ้าปิดฝาโน้ตบุ๊กก็ออฟไลน์ทันที
  • ไคลเอนต์ Gnutella จะรัน TCP-based gossip protocol ควบคู่ไปกับ HTTP server
    • ประกาศการมีอยู่ของตัวเองภายใน mesh ของ peer ที่ให้บริการไดเรกทอรีแชร์ผ่าน HTTP แก่ผู้เข้าร่วม Gnutella คนอื่น
    • ข้อมูลอย่างที่อยู่ peer, แบนด์วิดท์, latency และคำค้นหาจะเคลื่อนที่ผ่าน mesh นี้
    • มีเครื่องมือไว้รับมือกับไฟร์วอลล์ด้วย แต่การแก้ปัญหา NAT แบบสมัยใหม่จำเป็นต้องอาศัยส่วนขยายที่เพิ่มเข้ามาในภายหลัง
  • บทบาทพื้นฐานของโหนด Gnutella มีสามอย่าง
    • ส่งไฟล์ให้ผู้ต้องการผ่าน HTTP server ในเครื่อง
    • ค้นหาและประกาศไฟล์ที่มีอยู่ผ่านข้อความ gossip
    • ในบางกรณี ใช้เทคนิคหลบเลี่ยงไฟร์วอลล์
  • Gnutella ไม่มีจุดเข้าใช้งานส่วนกลางหรือทะเบียนผู้ใช้แบบศูนย์กลาง ดังนั้นเมื่อเข้ามาอยู่ใน mesh แล้ว ก็จะเริ่มค้นพบ peer ใหม่, คำค้นขาเข้า และทราฟฟิกเครือข่ายอื่น ๆ

การบูตสแตรป

  • การบูตสแตรป คือกระบวนการหา peer เริ่มต้นสักสองสามรายเพื่อเข้าไปใน mesh P2P ที่ไม่มีทั้งคำเชิญและไม่มีประตูหน้า
  • เครือข่าย Gnutella ทั่วโลกคือการผสมกันของ IP address ของผู้เข้าร่วม และเพียงแค่เชื่อมต่อกับ peer ที่เชื่อถือได้สักรายหนึ่งที่ยังต่ออยู่กับเครือข่ายหลัก ก็จะเริ่มมองเห็นทราฟฟิกของเครือข่ายที่ครอบคลุมผู้ใช้จำนวนมากได้
  • เมื่อเวลาผ่านไป จะค้นพบ peer เพิ่มขึ้นจากข้อความ PONG และรายชื่อ peer จะถูกบันทึกลงดิสก์เพื่อใช้เชื่อมต่อใหม่ในภายหลัง
  • เนื่องจาก IP address เปลี่ยนหรือมีบางเครื่องออฟไลน์ รายชื่อ peer ที่บันทึกไว้จะค่อย ๆ ใช้ไม่ได้บางส่วน และไคลเอนต์ก็จะลองไล่ไปตามรายการจนกว่าจะเจอ peer ที่ใช้ได้
  • สำหรับการเข้าร่วมเครือข่ายครั้งแรก หรือกลับมาใช้งานหลังจากหายไปนาน รายชื่อที่บันทึกไว้อาจไม่เพียงพอ จึงจำเป็นต้องมีการบูตสแตรป
  • วิธีที่ใช้กันมากที่สุดคือ Gnutella Web Cache (GWebCache)
    • เป็นกลุ่มของเว็บเซิร์ฟเวอร์อิสระที่อาสาสมัครดูแล มักอยู่ในรูปเว็บแอปเล็ก ๆ ที่เขียนด้วย CGI หรือ PHP
    • บันทึก IP address ของผู้เข้าร่วม Gnutella ที่สมัครใจส่งข้อมูลเข้ามา
    • บันทึก IP หรือโดเมนของเซิร์ฟเวอร์ GWebCache อื่น ๆ ไว้เผื่อเซิร์ฟเวอร์ปัจจุบันล่ม
    • ให้รายการเซิร์ฟเวอร์ GWebCache สำรอง
    • ให้รายการ IP address ของผู้เข้าร่วมเครือข่าย Gnutella ที่รู้จักอยู่ในขณะนั้น
  • ไคลเอนต์ Gnutella บางตัวจะเชื่อมต่อไปยัง cache server โดยอัตโนมัติ ขณะที่บางตัวต้องคัดลอก IP ไปใส่ในไฟล์ตั้งค่าหรือเมนูตั้งค่าด้วยตนเอง
  • เมื่อเชื่อมต่อกับ peer เริ่มต้นแล้ว ก็จะเริ่มเก็บ peer เพิ่มได้ทางอ้อมจากข้อความภายในเครือข่าย ทำให้การพึ่งพา cache ลดลง
  • GWebCache ไม่ใช่ คอขวดส่วนกลาง
    • มีเซิร์ฟเวอร์ GWebCache หลายตัวที่ไม่เกี่ยวข้องกัน
    • มีหลายวิธีในการบูตสแตรปไคลเอนต์โดยไม่ใช้ GWebCache
    • ต่อให้ไม่มี GWebCache, Gnutella ก็ยังอยู่รอดได้ในรูปแบบที่ใช้งานลำบากขึ้น
  • ตัวอย่างการขอรายการบูตสแตรปมีดังนี้
    • เติม ?get=1&client=TEST&version=1 ต่อท้าย URL เพื่อดึงรายการได้ แต่ถ้าขอบ่อยเกินไปจะถูกจำกัดความเร็วอย่างรวดเร็ว
http://cache.jayl.de/g2/gwc.php
http://gweb.4octets.co.uk/skulls.php
http://midian.jayl.de/g2/bazooka.php
http://p2p.findclan.net/skulls.php
http://skulls.gwc.dyslexicfish.net/skulls.php
  • ตัวอย่างผลลัพธ์มีดังนี้
H|106.107.193.27:23459|88579
H|182.233.59.26:23464|88581
U|http://bj.ddns.net/skulls/skulls.php|208999
U|http://scissors.gwc.dyslexicfish.net:3709/|341201
  • รายการที่ขึ้นต้นด้วย H คือ peer และรายการที่ขึ้นต้นด้วย U คือ cache server สำรองที่อาจใช้ภายหลังได้

ประเภทข้อความหลัก

  • Gnutella เป็น โปรโตคอลบน TCP และเมื่อเชื่อมต่อไปยัง peer ที่รับการเชื่อมต่อขาเข้าได้ จะมีการทำ handshake ก่อน
  • ไคลเอนต์จะส่ง GNUTELLA CONNECT/0.4 หรือ GNUTELLA CONNECT/0.6 และถ้าอีกฝ่ายตอบรับในเชิงบวก การเชื่อมต่อก็จะถูกตั้งขึ้นและเริ่มมีข้อความ Gnutella แบบไบนารีไหลผ่าน
  • ทุกข้อความไบนารีจะเริ่มต้นด้วย เฮดเดอร์ 23 ไบต์
    • เฮดเดอร์ประกอบด้วย message ID, payload type, TTL, hop count และ payload length
    • TTL คืออายุที่เหลือของข้อความ และ hop count คือระยะทางที่เดินทางมาแล้ว
    • TTL + Hops แสดงขอบเขตการเข้าถึงที่ข้อความถูกตั้งใจให้ไปถึงแต่แรก
  • ข้อความแกนหลักจริง ๆ มีห้าประเภท
    • PING: ใช้ค้นหา peer ที่ยังมีชีวิตอยู่, payload type 0x00
    • PONG: ตอบกลับ PING พร้อม IP address, พอร์ต และสถิติการแชร์, payload type 0x01
    • QUERY: คำขอค้นหาที่ผู้ใช้เริ่มเองหรือ peer ใกล้เคียงเป็นผู้เริ่ม, payload type 0x80
    • QUERYHIT: คำตอบเชิงบวกต่อ QUERY ซึ่งรวมเรกคอร์ดผลลัพธ์ไฟล์และข้อมูลการเชื่อมต่อสำหรับดาวน์โหลด, payload type 0x81
    • PUSH: วิธีอ้อมสำหรับผู้อัปโหลดที่อยู่หลังไฟร์วอลล์ โดยขอให้เจ้าของไฟล์เชื่อมต่อกลับไปยังฝั่งผู้ดาวน์โหลด, payload type 0x40
  • มีข้อความ BYE ด้วย แต่ไม่ถือว่าจำเป็นอย่างเคร่งครัด
  • ข้อความของโปรโตคอลรองรับ ฟิลด์ข้อมูลส่วนขยาย ทำให้ไคลเอนต์เพิ่มความสามารถใหม่ได้โดยไม่ทำลายทั้งเครือข่าย
  • GTK-Gnutella รองรับฟีเจอร์อย่าง TLS, IPv6 และ UDP ซึ่งไม่ได้อยู่ในโปรโตคอลแกนขนาดเล็กดั้งเดิม

ส่วนขยายของโปรโตคอล

  • อาจเป็นไปได้ที่จะสร้างไคลเอนต์ Gnutella ที่ใช้งานได้ด้วยการรองรับเพียงห้าประเภทข้อความ แต่สเปกนั้นมีอายุเกือบ 30 ปีแล้ว และระบบนิเวศก็ไม่เคยหยุดนิ่ง
  • Gnutella เปิดพื้นที่ให้ใส่แนวคิดใหม่ ๆ ลงไปในแพ็กเก็ตแบบเก่าได้
  • GGEP (Gnutella Generic Extension Protocol) ให้พื้นที่ทั่วไปสำหรับใส่ข้อมูลส่วนขยายลงในข้อความปกติ
  • HUGE (Hash/URN Gnutella Extensions) ทำให้ไคลเอนต์ระบุไฟล์ด้วยแฮช SHA ได้ แทนที่จะค้นหาแค่จากชื่อไฟล์
  • มีการกล่าวถึงการรองรับ XML extension payload เช่นกัน แต่สเปกพูดถึงมันในอดีตกาล และไม่พบในทราฟฟิกเครือข่ายสมัยใหม่
  • แม้การออกแบบดั้งเดิมจะเล็ก แต่ก็ยืดหยุ่นพอที่จะเติบโตต่อได้เรื่อย ๆ

วิธีทำงานของการค้นหาและการรับส่ง

  • ข้อความ PING/PONG ทำหน้าที่เหมือนการเต้นของชีพจรที่วิ่งไปมาระหว่างโหนด
    • PING ไม่มี payload ที่บังคับนอกจากเฮดเดอร์ 23 ไบต์มาตรฐาน แต่สามารถบรรจุข้อมูลส่วนขยาย GGEP แบบเลือกได้
    • PONG บรรจุพอร์ต, IPv4 address, จำนวนไฟล์ที่แชร์ และจำนวนกิโลไบต์ที่แชร์ของ servent ที่ตอบกลับ
    • โหนดจะสะสมข้อมูล IP/พอร์ตที่แนบมากับ PONG เพื่อเชื่อมต่อกับ mesh ได้ดีขึ้น และเก็บข้อมูลนี้ไว้ใช้ในเซสชันถัดไป
  • QUERY/QUERYHIT ทำงานคล้าย PING/PONG แต่ขนส่งทราฟฟิกการค้นหาแทนการประกาศตัวของ peer
    • QUERY บรรจุค่าความเร็วขั้นต่ำหรือฟิลด์แบนด์วิดท์สำหรับการรับส่ง ตามด้วยสตริงคำค้นที่ลงท้ายด้วย NUL
    • ตัวอย่าง: beethoven.mp3
    • ข้อความ QUERY จะกระจายออกจากผู้ส่งเหมือนน้ำท่วม และข้อความ QUERYHIT จะวิ่งกลับมาหาผู้ส่งหากมีผลลัพธ์
    • QUERYHIT มี IP address, พอร์ต, ความเร็ว และชุดผลลัพธ์ของผู้ตอบ
    • แต่ละผลลัพธ์มี file index, ขนาดไฟล์, ชื่อไฟล์ และเมทาดาทาหรือส่วนขยายแบบเลือกได้
    • file index จะถูกใช้ภายหลังเมื่อต้องร้องขอไฟล์ผ่าน HTTP
  • ด้วยธรรมชาติของ flood routing ใน Gnutella ผลลัพธ์จึงมาถึงช้า และบางครั้งใช้เวลาหลายนาทีกว่าจะครบ
  • วิศวกรของ LimeWire ได้คิดค้น dynamic query routing เพื่อแก้ปัญหานี้ให้ขยายระบบได้ดีขึ้น
    • ใช้ bloom filter และ topology เครือข่ายที่ชาญฉลาด
    • โครงสร้างขั้นสูงนี้ช่วยให้ขยายได้ถึงระดับผู้ใช้หลายล้านคนโดยไม่ติดปัญหาของ flood routing
    • ทุกวันนี้ไคลเอนต์กระแสหลักส่วนใหญ่ก็ยังใช้ระบบนี้

PUSH และไฟร์วอลล์

  • ข้อความ PUSH เป็นวิธีอ้อมที่ช่วยให้ HTTP server บางตัวหลุดข้อจำกัดของไฟร์วอลล์ได้ แต่ก็ไม่ได้แก้ได้ทุกกรณี
  • แทนที่ไคลเอนต์จะเชื่อมต่อไปยังเซิร์ฟเวอร์เหมือน HTTP ทั่วไป มันใกล้เคียงกับการขอให้เซิร์ฟเวอร์เชื่อมต่อกลับมายังฝั่งไคลเอนต์แทน
  • ข้อความ PUSH มี servent identifier และตัวระบุอื่น ๆ ที่จำเป็นเพื่อให้ผู้อัปโหลดหาผู้ดาวน์โหลดเจอ
  • เพราะไคลเอนต์เชื่อมต่อโดยตรงไม่ได้ จึงเป็นการร้องขอให้อีกฝ่ายเชื่อมต่อกลับมาแล้วส่งไฟล์ให้
  • รายละเอียดเพิ่มเติมดูได้ใน สเปก Gnutella
  • ไคลเอนต์สมัยใหม่ใช้เทคนิคเพิ่มเติมและส่วนขยาย UDP เพื่อจัดการปัญหานี้อย่างเป็นธรรมชาติมากขึ้น

ความหมายที่ยังหลงเหลืออยู่และแหล่งอ้างอิง

  • Gnutella ขยายไปถึงระดับผู้ใช้พร้อมกันหลายล้านคนได้ด้วยการออกแบบยุคแรกที่ดี, หลีกเลี่ยงการถูกปิดกั้นได้ และคงสถานะออนไลน์อยู่ได้หลายทศวรรษโดยแทบไม่ต้องพึ่งความช่วยเหลือจากภายนอก
  • ความจริงที่ว่าเครือข่ายซึ่งเป็นส่วนหนึ่งของวัฒนธรรม Y2K ยังไม่หายไป ทั้งที่ไม่ใช่เครือข่ายที่พังทันทีเมื่อมีทราฟฟิกจริง แสดงให้เห็นถึงความแข็งแรงของการออกแบบ
  • ข้อสรุปจึงใกล้เคียงกับว่าเหตุผลจริงที่ Gnutella เลือนหายไป ก็เพราะมันมีชีวิตอยู่นานกว่าโลกที่สร้างมันขึ้นมา
  • ตัวเครือข่ายเองมีอายุยืนยาวกว่าเว็บไซต์หลายแห่งที่เคยโฮสต์เอกสารเกี่ยวกับโปรโตคอลนี้เสียอีก

  • ลิงก์อ้างอิง

    • GTK-Gnutella GitHub - เป็นไคลเอนต์ที่ควรใช้หากอยากลองใช้ Gnutella จริง ๆ ในยุค 2020s โดยผู้ดูแลหลักเคยมีส่วนร่วมในการเขียนสเปก Gnutella 0.6 และยังคงทำงานอยู่
    • Gnutella Bun Client GitHub - อิมพลีเมนเทชันไคลเอนต์ Gnutella แบบงานอดิเรกที่เขียนด้วย TypeScript/Bun ใช้งานได้จริงและเข้ากันได้กับ GTK-Gnutella โดยรวม แม้จะยังไม่สมบูรณ์แบบ
    • Gnutella Terminology Glossary - ศัพท์เฉพาะที่อธิบายคำและแนวคิดที่เกี่ยวข้องกับ Gnutella เช่น QRP, GGEP และ GIV
    • Gnutella Forums - ฟอรัมเก่าสำหรับไคลเอนต์ Gnutella การแก้ปัญหา และการพูดคุยเรื่องเครือข่าย ซึ่ง ณ ปี 2026 ไม่ได้คึกคักมากนัก
    • Cap’n Bry’s Gnutella Site - เว็บไซต์แฟนเพจ Gnutella แบบเก่า
    • Annotated Gnutella Protocol Specification v0.4 - สเปกโปรโตคอล Gnutella 0.4 ฉบับดั้งเดิมและฉบับมีคำอธิบายประกอบ
    • Gnutella Protocol 0.6 Draft - ร่างสเปกโปรโตคอล Gnutella 0.6 ในภายหลัง
    • Query Routing Protocol Spec - สเปก QRP ซึ่งเป็นระบบ query routing ของ Gnutella ที่ช่วยลดการ flooding ที่สิ้นเปลือง โดยภาพประกอบได้หายไปแล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 10 시간 전
ความคิดเห็นจาก Lobste.rs

  • จำได้ว่า Gnutella ทำให้ดาวน์โหลดไฟล์ตามคำค้นหาได้ง่ายมาก โดยมากก็คือ MP3 แต่ก็มี “อย่างอื่น” ด้วย
    ดีใจที่มันชวนให้นึกถึงวันเก่าๆ และก็เสียดายที่เว็บทุกวันนี้กลายเป็นสัตว์ประหลาดไปแล้ว
    ช่วงกลางทศวรรษ 2000 หอพักมหาวิทยาลัยเป็น เครือข่ายแบบแบนราบ และ iTunes ก็ได้รับความนิยมมาก โดยแชร์เพลงให้ใครก็ได้ในเครือข่าย
    แค่สัปดาห์เดียวก็เติม โน้ตบุ๊ก HP 64 บิต เครื่องใหม่ที่ซื้อจาก Circuit City ด้วยเพลงของ Evanescence และ Green Day จนรู้สึกว่า Columbia House CD Club ไม่จำเป็นอีกต่อไปแล้ว

    • ที่หอพักมีเครือข่ายแชร์ไฟล์อยู่ และฝ่าย IT ก็รู้กันอย่างไม่เป็นทางการหมด แต่ในทางการก็แกล้งทำเป็นไม่รู้
      หลายปีหลังเรียนจบ มีใครบางคนดันพูดเรื่องนี้ต่อหน้าคนผิด ฝ่าย IT เลย รับรู้อย่างเป็นทางการ และสุดท้ายก็ต้องปิดมันลง
    • หรือว่าเป็น Dtella? ยังจำได้ดีว่าครั้งหนึ่งเคยมีส่วนร่วมสั้นๆ กับทีมปล่อยของในเครือข่าย Dtella แบบไม่เป็นทางการและไม่ได้รับอนุมัติจาก IT ของมหาวิทยาลัย และนั่นก็เป็นโอกาสแรกที่ได้ทำงานใกล้ชิดกับสายเทคนิคพอสมควร
      มารู้ทีหลังว่าไม่ได้หมายถึง “เครือข่ายแบบแบนราบ” ของโหนดแชร์ไฟล์ที่สร้างทับบนเครือข่ายมหาวิทยาลัย แต่หมายถึงตัวเครือข่ายเองเป็นแบบแบนราบ
      ถึงอย่างนั้น ช่วงมหาวิทยาลัยก็เป็นช่วงเวลาที่สนุกกับเรื่องแบบนี้ได้จริงๆ

  • Soulseek ยังถือว่ายังมีชีวิตอยู่พอสมควรและใช้งานได้ดี

  • เรื่องที่ตลกที่สุดของ Gnutella คือ ไม่ได้เกี่ยวอะไรกับโครงการ GNU เลย แค่เอา GNU มาใส่ในชื่อเพราะมันดูเท่

  • มักสงสัยอยู่บ่อยๆ ว่าเทคโนโลยีหลักของ Gnutella จะนำกลับมาใช้กับการค้นพบคอนเทนต์แบบ small-web รุ่นใหม่ๆ หรืออะไรที่คล้าย Gemini ได้มากแค่ไหน
    คำว่า “ล้มเหลว” นั้นไม่ครบถ้วน เพราะโดยทั่วไปแล้วสิ่งต่างๆ ไม่ได้สำเร็จหรือล้มเหลวลอยๆ แต่จะสำเร็จหรือล้มเหลวเมื่อเทียบกับเป้าหมายบางอย่างเท่านั้น
    มีเหตุผลใหญ่ๆ สองข้อที่ทำให้ผู้ใช้ Gnutella ไม่เหลืออยู่แล้ว และทั้งสองข้อก็ถือเป็นความล้มเหลวได้
    อย่างแรกคือ Gnutella และซอฟต์แวร์หลายตัว ปกป้องความเป็นส่วนตัว ของผู้ใช้ได้ไม่เพียงพอ ทำให้ผู้ใช้เผชิญทั้งความเสี่ยงจริงและความเสี่ยงที่รับรู้
    อย่างที่สองคือ แม้จะยอดเยี่ยมมากในฐานะระบบแจกจ่ายไฟล์สื่อ แต่ก็ไม่สามารถให้สมดุลด้านคุณภาพและราคาที่ทำให้ผู้ใช้ส่วนใหญ่พอใจได้ มันให้การเข้าถึงแบบไม่จำกัดอย่างที่ผู้ใช้ต้องการ แต่รับประกันไม่ได้ว่าเป็นคอนเทนต์จริง ขณะที่ Spotify ให้ได้ทั้งสองอย่าง
    ในความหมายนั้น ผู้ใช้ Gnutella ยังมีอยู่ เพียงแต่ตอนนี้ไปใช้อย่างอื่นกันแล้ว

    • ถ้าใครอยากลองทำอะไรแนว Gemini + Gnutella ร่วมกัน ก็ติดต่อมาได้เลย เคยมีไอเดียคล้ายๆ กันอยู่
      เคยคิดเรื่องการทำคลังไฟล์ *.gmi และทำให้ค้นหาได้ผ่านส่วนขยายของ Gnutella รวมถึง ระบบ pointer ที่ให้คนเซ็นชื่อและเผยแพร่เอกสาร gemtext ได้
      ตัวไอเดียอาจไม่ใหม่ แต่การผสม Gemtext + การกระจายผ่าน Gnutella ดูใหม่อยู่: https://github.com/RickCarlino/gnutella-bun-client/…
      ข้อเขียนนี้เป็นผลจากการระดมความคิดร่วมกับ GPT-5.4 เลยเก็บฝังไว้เผื่ออนาคต และยังไม่ได้ตั้งใจจะแชร์ จึงควรอ่านอย่างระมัดระวัง
      อยากฟังว่ามีความคิดอะไรบ้างในพื้นที่ Gemini + Gnutella และผมหาเจอได้ง่ายบน Linkedin, Reddit, Fediverse ฯลฯ โดยมีข้อมูลติดต่ออยู่ในบล็อกด้วย

  • OnionShare ก็ค่อนข้างน่าสนใจเหมือนกัน: https://onionshare.org/
    มันอาจกลายเป็นส่วนหนึ่งของ DaRkWeB ก็ได้

    • สงสัยว่ามันมี search overlay ให้หรือเปล่า หรือมีแค่ความสามารถในการรับส่งข้อมูล
      ดูจากเอกสารแล้ว มันน่าจะใกล้เคียงกับเครื่องมือส่งไฟล์แบบเชื่อมต่อโดยตรงมากกว่า

  • ดูเหมือนว่าจะขาดอีกเหตุผลหนึ่งว่าทำไม Gnutella ถึงอยู่ได้นานภายใต้เงื่อนไขในยุคนั้น นั่นคือแทบไม่มีแรงจูงใจที่เป็นรูปธรรมให้ทำ สแปมการค้นหาแบบ P2P
    หลังจากนั้นสแปมการค้นหาแบบ P2P ก็เกิดขึ้นจริง

    • Gnutella มี ระดับความเชื่อใจ สูงกว่าระบบ P2P ในยุคหลังๆ จึงสอดสแปมได้ง่ายกว่า แต่ตอนนี้ผู้ใช้น่าจะเหลือเพียงหลักพัน แรงจูงใจเลยต่ำ
      ทุกวันนี้ IRC แทบไม่มีสแปมก็น่าจะด้วยเหตุผลคล้ายกัน
      น่าสนใจที่หลายส่วนของโปรโตคอลนี้เชื่อใจไคลเอนต์
      GUID ควรเป็นค่าสุ่ม แต่ผู้ใช้ควบคุมได้ ดังนั้นทุกคนอาจตั้ง GUID เป็น 0000 ทั้งหมดก็ได้ ถ้าจะสร้าง Gnutella ใหม่ในแบบสมัยใหม่ ก็คงใส่ระบบแลกเปลี่ยนคีย์ที่ซับซ้อนกับตัวตนบนคีย์ ED25519 เข้าไป
      ทั้งจำนวนไฟล์ที่ประกาศ แบนด์วิดท์ ฯลฯ ก็เป็นโครงสร้างที่เชื่อโดยปริยายว่าผู้ใช้พูดความจริง ถ้าเป็นโปรโตคอลที่ซับซ้อนกว่านี้ก็คงพยายามตรวจสอบคำกล่าวอ้างเหล่านี้จริงๆ
      ถ้าใส่การเซ็นคีย์หรือการจัดการชื่อเสียงเข้าไปมากๆ การติดตั้งอาจซับซ้อนเกินไป และความเรียบง่ายนี่เองอาจเป็นเหตุผลที่มันสำเร็จ Gnutella client นั้น สร้างได้จริง
      ผมคิดว่าโปรเจกต์ P2P สมัยใหม่จำนวนมากพลาดจุดนี้ แม้แต่โปรเจกต์ที่ชอบอย่าง Secure Scuttlebutt ก็เหมือนพยายามทำให้เกือบสมบูรณ์แบบโดยคำนึงถึงความล้มเหลวและกรณีการใช้งานผิดมากมาย สุดท้ายเลยกลายเป็นระบบนิเวศที่มีไคลเอนต์ที่ใช้งานได้จริงเพียงตัวเดียวซึ่งสร้างโดยคนเขียนสเปกเอง
      ตัวอย่างเดียวกันนี้ใช้กับ gemini:// ได้เช่นกัน แม้จะไม่ใช่ P2P แต่เป็นโปรโตคอลแบบ federated ถึงสเปกจะมีปัญหาและช่องโหว่มากมาย แต่สุดท้ายผู้คนก็ สร้างไคลเอนต์ที่ใช้งานได้จริง และแม้มีปัญหา ระบบนิเวศก็ค่อนข้างมี implementation ที่หลากหลาย

  • การที่ Gnutella โด่งดังขึ้นมาในช่วงนั้น ส่วนหนึ่งอย่างมากมาจากบทบาทของ Gene Kan และ Spencer Kimball ซึ่งเป็นสมาชิก Berkeley XCF
    ต่อมา Spencer ก็ทำงานวิศวกรรมที่ยอดเยี่ยมหลายอย่างที่ Google และตอนนี้เป็น CEO ของบริษัทฐานข้อมูล Cockroach Labs
    Gene ประสบความสำเร็จเร็วจากการขายบริษัทเสิร์ชให้ Sun แต่ก็น่าเศร้าที่เขาเสียชีวิตอย่างน่าอนาถตั้งแต่อายุยังน้อยในปี 2002