ข้ามไปที่เนื้อหาหลัก

เพียร์ทูเพียร์ในเบราว์เซอร์

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

หน้านี้อธิบายว่าสิ่งนั้นหมายถึงอะไรจริง ๆ ใช้ทรานสปอร์ตใดบ้าง ยังทำอะไรไม่ได้ และเหตุใดการเผยแพร่จากแท็บ จึงเพิ่งเริ่มทำงานได้ในปี 2026

สำหรับการออกแบบเครือข่ายในภาพรวม ดู โปรโตคอลแบบเพียร์ทูเพียร์

สิ่งที่รันอยู่ในแท็บ​

เมื่อ P2P ในเบราว์เซอร์ทำงานอยู่ หน้าเว็บจะถือโหนด libp2p ของจริงเอาไว้:

  • มันเชื่อมต่อ (dial) ไปยังเพียร์อื่นผ่าน WebSockets ที่ปลอดภัย
  • มันดึงและตรวจสอบเนื้อหาของชุมชนจากเพียร์เหล่านั้น ไม่ใช่จากเกตเวย์ IPFS
  • มันเข้าร่วม gossipsub การเผยแพร่โพสต์จึงไม่ต้องพึ่งผู้ให้บริการ pubsub ที่มีผู้โฮสต์ไว้
  • มันใช้สแตกไคลเอ็นต์โปรโตคอลชุดเดียวกัน (pkc-js) กับแอป Bitsocial ตัวอื่นทุกตัว

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

โหนดในเบราว์เซอร์เชื่อมต่ออย่างไร​

pkc-js เชื่อมต่อกับเพียร์ผ่าน WebSockets ที่ปลอดภัย ส่วนการ dial ด้วย WebRTC และ WebTransport ถูกปฏิเสธโดยค่าเริ่มต้นผ่าน connection gater เพราะในเบราว์เซอร์ทั้งสองอย่างเพิ่มเส้นทางการสร้างการเชื่อมต่อ ที่ยาวและมักล้มเหลว ทั้งการเจรจา STUN/ICE และการหมุนเวียน certhash ซึ่งทำให้หน้าเว็บโหลดช้าลง ขณะที่ WebSocket ให้ทรานสปอร์ตที่ตรงไปตรงมาและเชื่อถือได้ ผู้เรียกใช้ที่ต้องการ WebRTC หรือ WebTransport เป็นการเฉพาะสามารถแทนที่ gater ได้ผ่าน libp2pJsClientsOptions[].libp2pOptions.connectionGater

ผลในทางปฏิบัติคือเพียร์ในเบราว์เซอร์จะเชื่อมต่อกับโหนดที่เปิดปลายทาง WSS ไว้ ซึ่งหมายความว่าโหนดเหล่านั้น ต้องมีโดเมนและใบรับรองที่ลงนามโดย CA ส่วนเพียร์ที่อยู่หลังการเชื่อมต่ออินเทอร์เน็ตบ้านซึ่งไม่มีสิ่งเหล่านี้ จะถูกเข้าถึงทางอ้อมแทนการถูก dial จากแท็บโดยตรง

เหตุใดการเผยแพร่จากเบราว์เซอร์จึงเพิ่งเริ่มทำงานได้ในปี 2026​

เพียร์ทูเพียร์ในเบราว์เซอร์ไม่ใช่แนวคิดใหม่ สิ่งที่เปลี่ยนไปในปี 2026 คือ โพสต์ ของโหนดในเบราว์เซอร์ ไปถึงเครือข่ายส่วนที่เหลือได้แล้ว

สเปก pubsub ของ libp2p กำหนดให้ seqno ของข้อความเป็นจำนวนเต็ม 64 บิตแบบ big-endian ที่เพิ่มขึ้นเชิงเส้น แต่ js-libp2p-gossipsub กลับสร้างไบต์สุ่ม 8 ไบต์แทน ขณะที่ go-libp2p-pubsub และ rust-libp2p ต่างใช้ตัวนับ Kubo 0.40+ เปิดใช้ BasicSeqnoValidator เป็นค่าเริ่มต้น ซึ่งจะปฏิเสธข้อความ ทุกข้อความที่มี seqno ไม่มากกว่าค่าสูงสุดที่เคยเห็นจากเพียร์นั้น

ผลก็คือข้อความส่วนใหญ่ที่เผยแพร่โดยโหนด JavaScript รวมถึงโหนดในเบราว์เซอร์ ถูกเพียร์ที่รัน Kubo ทิ้งไปอย่างเงียบ ๆ ชุดทดสอบที่จำลองปัญหานี้วัดได้ว่ามีข้อความมาถึงเพียง 2 ถึง 8 จาก 30 ข้อความ

ปัญหานี้ถูกวินิจฉัยไว้ใน js-libp2p-gossipsub#545 และแก้ไขแล้วใน @libp2p/gossipsub 15.0.21 เมื่อเดือนพฤษภาคม 2026 ก่อนที่การแก้ไขนั้นจะออกมา โหนดในเบราว์เซอร์ เชื่อมต่อและอ่านได้ แต่โพสต์ของมันมักหายไประหว่างทางไปยังเพียร์ที่เขียนด้วย Go ปัจจุบัน pkc-js มาพร้อม @libp2p/gossipsub 16.0.4 ซึ่งใหม่กว่าการแก้ไขดังกล่าว

สิ่งที่โหนดในเบราว์เซอร์ยังทำไม่ได้​

โหนดในเบราว์เซอร์เป็นเพียร์ของจริง ไม่ใช่เซิร์ฟเวอร์ จึงมีข้อจำกัดต่างจากโหนดเดสก์ท็อปหรือโหนดที่เปิดตลอดเวลา:

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

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

เราเตอร์ HTTP ไม่ใช่เกตเวย์​

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

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

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

ทุกวันนี้สิ่งนี้ทำงานอยู่ที่ไหนบ้าง​

  • 5chan ทำงานแบบ P2P ในเบราว์เซอร์ล้วน ๆ โดยค่าเริ่มต้นในเว็บแอปที่ 5chan.app

การถอยไปใช้เกตเวย์​

การเข้าถึงผ่านเกตเวย์ยังคงมีอยู่ในฐานะเส้นทางสำรองเพื่อความเข้ากันได้ สำหรับเบราว์เซอร์หรือเครือข่าย ที่เข้าร่วมโดยตรงไม่ได้ ดู การถอยไปใช้เกตเวย์ สถาปัตยกรรมเป้าหมายคือ P2P ในเบราว์เซอร์มาก่อน โดยมีเกตเวย์เป็นทางเลือกสำรอง ไม่ใช่คอขวดโดยค่าเริ่มต้น