กลับไปยังบล็อก Webship

วิศวกรรม Webship

Webship: เว็บเซิร์ฟเวอร์ที่สอดคล้องกับ RFC มากที่สุดในโลก

Webship แปลงข้อกำหนด RFC ให้เป็นพฤติกรรมชัดเจนใน HTTP/1.1, HTTP/2, HTTP/3, QUIC, TLS, การแคช, การรีเวิร์สพร็อกซี, WebTransport, ACME และเมธอด QUERY ใหม่ สำรวจแผนที่มาตรฐาน RFC ทั้ง 52 ฉบับครบถ้วน

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

Webship 1.3.1 ถูกสร้างขึ้นโดยมีหลักการเพียงข้อเดียว: ความเร็วมีค่าเฉพาะเมื่อไบต์ยังคงความหมายของมัน

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

ความเข้ากันได้คือพฤติกรรม ไม่ใช่เครื่องหมาย

Webship ใช้มาตรฐานในสถานที่ที่เซิร์ฟเวอร์การผลิตมักจะเกิดความกำกวมบ่อยที่สุด:

  • การจัดกรอบ HTTP/1.1 ปฏิเสธความยาวที่ขัดแย้ง รหัสการถ่ายโอนที่ไม่ถูกต้อง เป้าหมายคำขอที่ใหญ่เกินไป ชิ้นส่วนที่บิดเบือน และรูปแบบการลักลอบคำขอ
  • HTTP/2 และ HTTP/3 ปฏิเสธฟิลด์การเชื่อมต่อที่ถูกห้าม ตรวจสอบความถูกต้องของ pseudo-fields จำกัดส่วนฟิลด์ที่บีบอัด และแยกความผิดพลาดของสตรีมออกจากความผิดพลาดของการเชื่อมต่อ
  • ไฟล์แบบคงที่รักษาความหมายของ HEAD ตัวตรวจสอบ เงื่อนไขลำดับช่วงไบต์ การเปลี่ยนเส้นทาง และประเภทของเนื้อหา
  • พร็อกซีแบบย้อนกลับรักษาการจัดกรอบ การยกเลิก ท้ายข้อความ การอัปเกรด การลองใหม่อย่างปลอดภัย และการส่งต่อเอกลักษณ์ ในขณะที่ลบฟิลด์แบบ hop-by-hop ออก
  • แคชคำนวณอายุ ความสดใหม่ การตรวจสอบใหม่ Vary การทำให้ไม่ถูกต้อง และกฎการใช้งานแบบเก่า แทนที่จะมองว่าการแคชเป็นเพียงทางลัดแบบกุญแจ-ค่า
  • TLS, QUIC, ACME, ข้อมูลเริ่มต้น และ WebTransport ใช้สถานะที่จำกัดและนโยบายความล้มเหลวที่ชัดเจน

กฎเดียวกันนี้ใช้กับเส้นทางด่วน Webship ไม่ได้กำหนดเส้นทางที่ “ถูกต้อง” หนึ่งเส้นทางและเส้นทางมาตรฐานที่แตกต่างออกไป

การทำงานเชิงความหมายของ HTTP, การจัดกรอบข้อมูล, การเก็บแคช, และการใช้พร็อกซี่

  • RFC 3986 — ตัวระบุทรัพยากรแบบสากล (URI): ไวยากรณ์ทั่วไป. Webship ทำการปรับมาตรฐานการอ้างอิงที่อยู่ Location และ Content-Location แบบสัมพัทธ์ รวมถึงส่วนที่เป็น dot segments ก่อนตัดสินใจยกเลิกแคช.
  • RFC 6455 — โปรโตคอล WebSocket. การอัปเกรดแบบรีเวิร์สพร็อกซีจะตรวจสอบคีย์ WebSocket ค่าการยอมรับ ซับโพรโทคอล ส่วนขยาย และการเปลี่ยนผ่านท่อ.
  • RFC 6585 — รหัสสถานะ HTTP เพิ่มเติม. ฟิลด์คำขอที่มีขนาดเกินกำหนดจะใช้รหัสตอบสนอง 431 ที่กำหนดไว้ในกรณีที่ยังสามารถตอบสนอง HTTP ได้
  • RFC 6797 — HTTP Strict Transport Security. Strict-Transport-Security จะถูกส่งออกเฉพาะผ่านการขนส่งที่ปลอดภัยและจะไม่รั่วไหลจากรายการแคชที่เป็นกลางต่อการขนส่งไปยัง HTTP แบบข้อความชัดเจน
  • RFC 7235 — การตรวจสอบสิทธิ์ HTTP/1.1. โทเค็นของแผนการตรวจสอบสิทธิ์จะถูกวิเคราะห์แบบไม่คำนึงถึงตัวพิมพ์ ซึ่งรวมถึงพื้นผิวการควบคุม MCP ที่ได้รับการป้องกันด้วย ขณะนี้ความหมายทั่วไปของ HTTP อยู่ใน RFC 9110
  • RFC 7239 — ส่วนขยาย HTTP แบบ Forwarded. ผู้ปฏิบัติการสามารถเลือกใช้ฟิลด์ Forwarded ตามมาตรฐาน, ฟิลด์ X-Forwarded แบบเก่า, ทั้งสองแบบ หรือไม่ใช้ก็ได้; ฟิลด์ระบุตัวตนที่ไม่เชื่อถือได้จากการรับเข้าจะถูกลบออกก่อน
  • RFC 7540 — HTTP/2. สิ่งนี้ถูกเก็บไว้เพื่อเป็นสายความเข้ากันได้กับ HTTP/2; สัญญา HTTP/2 ที่ใช้งานอยู่คือภาคต่อของมัน, RFC 9113.
  • RFC 7541 — HPACK: การบีบอัด Header สำหรับ HTTP/2. HTTP/2 stack ของ Webship ควบคุมสถานะตัวถอดรหัสและตารางตัวเข้ารหัสในขณะที่ยังคงรูปแบบสาย HPACK และการเข้ารหัส Huffman ไว้
  • RFC 7838 — บริการทางเลือกของ HTTP. Alt-Svc โฆษณาจุดเชื่อมต่อ HTTP/3 โดยไม่เปลี่ยนต้นกำเนิดที่แสดงโดย URL
  • RFC 8441 — การบูตสแตรป WebSockets ด้วย HTTP/2. Webship รองรับฐานรากการเจรจาขยาย-CONNECT สำหรับ downstream ซึ่งไม่ได้แสร้งทำว่า upstream HTTP/1.1 จะใช้งาน HTTP/2 extended CONNECT; การรวมกันของ upstream ที่ไม่รองรับจะล้มเหลวอย่างชัดเจน
  • RFC 8470 — การใช้ Early Data ใน HTTP. คำขอเริ่มต้นที่ Webship จะไม่ประมวลผล จะได้รับ 425 Too Early แทนการถูกจัดการโดยสมมติการเล่นซ้ำที่ไม่ปลอดภัย
  • RFC 8941 — ค่าฟิลด์โครงสร้างสำหรับ HTTP. ค่าความสำคัญของ HTTP ใช้การวิเคราะห์พจนานุกรมฟิลด์โครงสร้าง; ฟิลด์เสริมที่ไม่ถูกต้องจะถูกละเว้นทั้งหมด
  • RFC 9110 — ความหมายของ HTTP. เมธอด รหัสสถานะ ฟิลด์ ตัวตรวจสอบ เงื่อนไขเบื้องต้น การเปลี่ยนเส้นทาง ข้อมูลเมตาของเนื้อหา HEAD, CONNECT, OPTIONS และความหมายของช่วงแชร์สัญญาปัจจุบันเดียวกันข้ามเวอร์ชันโปรโตคอล
  • RFC 9111 — การแคช HTTP. Webship ใช้อายุที่แก้ไขแล้ว ความสดชัดเจนโดยชัดแจ้ง Vary, only-if-cached, must-revalidate, proxy-revalidate, การใช้ข้อมูลเก่าอย่างปลอดภัย และการทำให้ URI ที่มีผลและที่เกี่ยวข้องไม่ถูกต้อง
  • RFC 9112 — HTTP/1.1. กฎของ request-line, field, body-length, transfer-coding, chunk, trailer, persistence, และ close-delimited จะถูกบังคับใช้ก่อนการส่งต่อไปยังแอปพลิเคชัน
  • RFC 9113 — HTTP/2. ฟิลด์จำลอง order, authority, ฟิลด์การเชื่อมต่อที่ห้าม, ข้อจำกัดของ TE, วงจรชีวิตของสตรีม, การควบคุมการไหล, GOAWAY, และขอบเขตข้อผิดพลาด ถูกจัดการโดยเส้นทาง H2 ที่เป็นเจ้าของโดย Webship.
  • RFC 9114 — HTTP/3. Webship เป็นเจ้าของเส้นทางข้อผิดพลาด request, control-stream, SETTINGS, critical-stream, cancellation และ stream-versus-connection ที่ใช้โดยเซิร์ฟเวอร์ HTTP/3 ของมัน
  • RFC 9204 — QPACK: การบีบอัดฟิลด์สำหรับ HTTP/3. ความจุของตารางไดนามิกถูกจำกัดโดยขีดจำกัดที่ประกาศไว้ สตรีมคำสั่งยังคงสามารถวิเคราะห์ได้แม้ที่ความจุศูนย์ และสถานะที่ไม่ถูกต้องจะกลายเป็นข้อผิดพลาด QPACK ที่จำเป็น
  • RFC 9218 — โครงสร้างการจัดลำดับความสำคัญที่สามารถขยายได้สำหรับ HTTP. ความเร่งด่วนและการส่งมอบแบบเพิ่มขึ้นเป็นแนวทางในการจัดตาราง HTTP/3 ในขณะที่พารามิเตอร์ลำดับความสำคัญที่ไม่ทราบยังคงสามารถขยายได้
  • RFC 9220 — การเริ่มต้นใช้งาน WebSockets ด้วย HTTP/3. Webship ใช้พื้นฐาน SETTINGS ของ HTTP/3 extended-CONNECT ที่โปรโตคอลท่อลอดสมัยใหม่ใช้; แต่ไม่ได้หมายความว่าทุกโปรโตคอล CONNECT ที่เป็นไปได้จะได้รับการยอมรับ
  • RFC 9297 — HTTP Datagrams and the Capsule Protocol. เซสชัน WebTransport ใช้การถอดรหัสแคปซูลแบบจำกัดและการเชื่อมโยง HTTP Datagram โดยแคปซูลที่ไม่ทราบจะถูกจัดการเป็นจุดขยายแทนที่จะเป็นความล้มเหลวของตัวแยกวิเคราะห์
  • RFC 9421 — ลายเซ็นข้อความ HTTP. การระบุที่มาของการตอบสนอง Ed25519 เป็นทางเลือกสามารถครอบคลุมการเปิดตัว Webship และตัวตนการกำหนดค่าได้โดยไม่ต้องแทนที่ TLS หรือการยืนยันตัวตนของแอปพลิเคชัน
  • RFC 10008 — วิธีการ HTTP QUERY. Webship ถือว่า QUERY ปลอดภัยและทำซ้ำได้ รักษาตัวเนื้อหาของมันระหว่างการผ่านพร็อกซี รวมทั้งรวมข้อมูลเมตาเกี่ยวกับเนื้อหาและการแทนค่าในเอกลักษณ์ของแคช ห้ามใช้การประเมินความสดด้วยวิธีเชิงอัตวิสัย รองรับพฤติกรรมตามเงื่อนไขและช่วงข้อมูล และไม่เคยทำให้แคชหมดอายุเพียงเพราะใช้ QUERY

การขนส่งและการควบคุมความแออัดของ QUIC

TLS ใบรับรอง และการจัดการใบรับรองอัตโนมัติ

WebTransport: ชัดเจนเกี่ยวกับสิ่งที่ถูกมาตรฐาน

WebTransport บน HTTP/3 ไม่ถูกนับเป็น RFC ที่ห้าสิบสาม ตาม Webship 1.3.1 การแมปแบบสายของมันยังคงเป็น draft-ietf-webtrans-http3-16 Webship นำร่างนั้นไปใช้งานบน HTTP/3 ที่มาตรฐาน ขยาย CONNECT, QUIC DATAGRAM, HTTP Datagram และชั้น Capsule ที่กล่าวถึงข้างต้น นอกจากนี้ยังใช้งานส่วนขยาย RESET_STREAM_AT ที่เจรจาตกลงกัน ซึ่งจำเป็นเพื่อรักษาคำนำตัวระบุเซสชันที่เชื่อถือได้เมื่อสตรีม WebTransport ถูกรีเซ็ต

ความแตกต่างนั้นสำคัญ ความเข้ากันได้กับมาตรฐานไม่ได้ดีขึ้นเพียงแค่เรียกเอกสารร่างว่า RFC แต่จะดีขึ้นโดยการติดตามเอกสารร่างอย่างชัดเจน แยกมันออกจากเส้นทาง HTTP ปกติ ต่อรองทุกส่วนขยาย กำหนดขอบเขตทรัพยากรของแต่ละเซสชัน และทดสอบพฤติกรรมการยกเลิกและความล้มเหลว

ทำไมความกว้างนี้ถึงสำคัญในการผลิต

ข้อบกพร่องด้านมาตรฐานมักไม่เกิดขึ้นเพียงลำพัง การจัดการ HSTS ที่ไม่ถูกต้องสามารถข้ามขอบเขตของแคชได้ คำสั่ง QPACK ที่มีรูปแบบไม่ถูกต้องสามารถยุติคำขอที่ไม่เกี่ยวข้องได้ สมมติฐานข้อมูลล่วงหน้าอย่างไม่ปลอดภัยสามารถเล่นซ้ำการดำเนินการได้ คีย์แคช QUERY ที่ละเว้นร่างคำขอสามารถส่งกลับผลลัพธ์ของคำถามอื่นได้ ตัวกลางที่ลบ trailer หรือจัดการการยกเลิกไม่ถูกต้องสามารถเปลี่ยนโปรโตคอลแอปพลิเคชันโดยไม่แจ้งได้

สถาปัตยกรรมของ Webship จัดการเรื่องเหล่านี้เป็นความกังวลที่เชื่อมโยงกัน ขอบเขตของตัววิเคราะห์ (Parser limits), การตรวจสอบความปลอดภัย, การแคช, การทำ reverse proxy, สถานะการรับส่งข้อมูล, และการติดตั้งเครื่องมือร่วมกันโดยมีสัญญาอย่างชัดเจน ผลลัพธ์คือเซิร์ฟเวอร์หนึ่งที่สามารถสลับระหว่าง HTTP/1.1, HTTP/2, HTTP/3, การส่งมอบแบบสแตติก, การทำ reverse proxy, การสตรีม, และ WebTransport โดยไม่ต้องให้แต่ละโหมดมีคำนิยามของความถูกต้องที่แตกต่างกัน

ตรวจสอบข้ออ้าง

อย่าเชื่อคำชมเชยโดยไม่ตรวจสอบ อ่านเอกสาร [Webship 1.3.1](/docs/1.3.1) ตรวจสอบการตั้งค่าและขอบเขตของโปรโตคอล และทำซ้ำพฤติกรรมที่เผยแพร่ จากนั้น [ดาวน์โหลด Webship](/downloads) และทดสอบกรณีขอบเขตที่สำคัญต่อระบบของคุณ

วิศวกรรม Webship

สตรีมมิ่งกับ Webship: ความเร็วในการประมวลผลสูงโดยไม่แลกเปลี่ยนความถูกต้อง

เรียนรู้ว่า Webship ให้บริการและเป็นพร็อกซีไฟล์สื่อขนาดใหญ่ผ่าน HTTP/1.1, HTTP/2, และ HTTP/3 โดยใช้ kTLS แบบปรับตัว, การปรับจังหวะ BBR, บัฟเฟอร์จำกัด, และเกตความสมบูรณ์แบบไม่มีข้อผิดพลาดอย่างไร

อ่านบทความ

เว็บเซิร์ฟเวอร์ของคุณเป็นการตัดสินใจเกี่ยวกับต้นทุนโครงสร้างพื้นฐาน

Webship ผสานการส่งมอบ Rust ความเร็วสูง โปรโตคอลสมัยใหม่ การป้องกันในตัว การสังเกตการณ์ในพื้นที่ และการปฏิบัติการที่เน้น AI ไว้ในเวลารันไทม์เดียว—มอบเส้นทางที่น่าเชื่อถือให้กับทีมโครงสร้างพื้นฐานเพื่อลดจำนวนเซิร์ฟเวอร์และส่วนประกอบที่ปลายทาง

อ่านบทความ

Webship 1.3.1: ความสามารถของ HTTP/2 และรีเวิร์ส-พร็อกซีที่สูงขึ้น

Webship 1.3.1 เพิ่มความจุ h2c โดยตรงขึ้น 34.19%, เพิ่ม HTTP/2 TLS โดยตรงขึ้น 26.67%, และ reverse-proxy H1 ขึ้น 15.10% เมื่อเทียบกับ 1.2.0 ในขณะเดียวกันก็เสริมความเสถียรและความถูกต้องในการขนส่ง

อ่านบทความ