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

ประสิทธิภาพการสตรีมไม่ได้เป็นเรื่องที่เกี่ยวข้องกับเครื่องเล่นวิดีโอเพียงอย่างเดียว ซอฟต์แวร์ อาร์ติแฟกต์ น้ำหนักโมเดล การสำรองข้อมูล ไลบรารีเสียง และการส่งออก API ขนาดใหญ่ทั้งหมดขึ้นอยู่กับพื้นฐานเดียวกัน: ย้ายไบต์อย่างรวดเร็ว รักษาข้อมูลต้นฉบับให้ถูกต้อง เคารพแรงดันกลับ และหยุดอย่างเรียบร้อยเมื่อไคลเอนต์ตัดการเชื่อมต่อ

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

วัดความสามารถในการสตรีม 100 เมกะไบต์

Webship 1.3.1 ความจุ Debian ทำการวัดอัตราการถ่ายโอนข้อมูลเฉลี่ยโดยใช้ payload ขนาดคงที่ 100 MB การทดสอบแต่ละตัวอย่างที่ยอมรับต้องใช้ร่างกายการตอบสนองขนาด 99,943,778 ไบต์พอดี และไม่มีข้อผิดพลาดใด ๆ ของไคลเอนต์ โปรโตคอล ตัวแทน หน้าเพจหลัก, และ HTTP/3 การสูญเสียแพ็กเก็ต

| โหมด Webship | TLS HTTP/1.1 | TLS HTTP/2 | TLS HTTP/3 | | --- | ---: | ---: | ---: | | การส่งไฟล์โดยตรง | 4,194.8 MiB/s | 3,574.3 MiB/s | 2,096.9 MiB/s | | รีเวิร์สพร็อกซีพร้อมการยุติ TLS | 3,585.7 MiB/s | 3,355.0 MiB/s | 1,938.6 MiB/s | | รีเวิร์สพร็อกซีพร้อมการส่งต่อ TLS | 2,783.2 MiB/s | 2,135.0 MiB/s | 1,748.5 MiB/s |

ในการเปรียบเทียบที่บันทึกไว้ Webship ทำผลลัพธ์ตรงกลางที่สูงที่สุดแบบตรงและผ่าน TLS สำหรับโปรโตคอลที่วัดทั้งหมด เมทริกซ์สมบูรณ์รวมถึง Nginx, Lighttpd, Caddy, HAProxy, Envoy, Pingora และ Bun ใน [หน้ามาตรฐานการทดสอบ](/benchmarks)

ตัวเลขเหล่านี้วัดความสามารถบนโฮสต์มาตรฐาน มันไม่ใช่คำสัญญาสำหรับเส้นทางอินเทอร์เน็ตใด ๆ ความหน่วงของการจัดเก็บ ขนาดแบนด์วิดท์ของเครือข่าย เวลาเดินทางไป-กลับ การสูญเสียแพ็กเก็ต นโยบาย TLS การทำงานพร้อมกัน และพฤติกรรมต้นทาง ยังคงเป็นตัวกำหนดความเร็วในการส่งจริง

หนึ่งไบนารี สามกลยุทธ์การขนส่ง

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

HTTP/1.1: การเปลี่ยนภาพรอบไฟล์น้อยลง

บน Linux, Webship จะเก็บหัวการตอบสนองและข้อมูลไฟล์ภายในช่วง TCP cork ที่ดีที่สุดเท่าที่ทำได้ เมื่อการตอบสนอง TLS ขนาดใหญ่มีคุณสมบัติสำหรับเส้นทางแบบกลุ่ม การส่งไฟล์โดยตรงสามารถย้ายจากบันทึก Rustls ไปยัง TLS เคอร์เนลแบบทางเดียวที่มีการตรวจสอบ และใช้ sendfile โดยไม่ต้องคัดลอกข้อมูลไฟล์ผ่านบัฟเฟอร์ของแอปพลิเคชัน

การเชื่อมต่อยังคงเริ่มต้นใน userspace TLS การตอบสนองขนาดเล็กยังคงอยู่ที่นั่น Webship จะร้องขอการเปลี่ยนไปใช้ kTLS ก็ต่อเมื่อมีเนื้อหาการตอบสนองอย่างน้อย 1 MiB พิสูจน์ว่าการเชื่อมต่อกำลังรับส่งข้อมูลจำนวนมาก

HTTP/2: การจัดกลุ่มโดยไม่ทำลายการควบคุมการไหล

HTTP/2 การมัลติเพล็กซิ่งทำให้การบัฟเฟอร์ที่ควบคุมไม่ได้มีค่าใช้จ่ายสูง Webship จัดกลุ่มการเขียนในขณะที่ยังคงจำกัดการควบคุมการไหลของสตรีมและการเชื่อมต่อ สำหรับการสตรีมที่มีความพร้อมกันสูง บัฟเฟอร์เขียน TLS ขนาด 128 KiB สามารถเก็บเฟรม DATA ขนาด 64 KiB สองเฟรมได้ ในขณะที่งบประมาณการส่งของการเชื่อมต่อยังคงชัดเจนและจำกัด

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

HTTP/3: การปรับความเร็ว QUIC แทน kTLS

HTTP/3 ไม่เคยใช้เส้นทาง TCP kTLS Webship ใช้การจัดระยะเวลา QUIC ที่รับรู้ขนส่ง การแบ่งแพ็กเก็ตเดต้าแกรมแบบจำกัด DPLPMTUD และการสร้างไมโครบรรจุแบบขับเคลื่อนด้วยตัวจับเวลาต่อรีแอคเตอร์ HTTP/3 ขนาดใหญ่และเซสชัน WebTransport ที่ได้รับการยอมรับสามารถเลือก BBR ได้โดยไม่เปลี่ยนนโยบาย CUBIC ที่ใช้โดยทราฟิกปกติ

การทดสอบคุณสมบัติความเสถียร HTTP/3 แบบมุ่งเน้นใช้ตัวอย่างที่ได้รับการยอมรับจำนวนเจ็ดตัวอย่าง การสตรีมที่สิ้นสุดด้วย TLS ให้ค่ามัธยฐาน 1,938.6 MiB/s โดยมีสัมประสิทธิ์ความแปรปรวน 2.12% การส่งผ่าน TLS ให้ 1,748.5 MiB/s โดยมีสัมประสิทธิ์ความแปรปรวน 1.65% ทั้งสองชุดไม่มีข้อผิดพลาดด้านความสมบูรณ์ของข้อมูล, ไคลเอนต์, โปรโตคอล และการสูญเสียแพ็กเก็ต

การส่งตรงหรือพร็อกซี่ย้อนกลับ?

ใช้การส่งมอบโดยตรงเมื่อ Webship เป็นเจ้าของโครงสร้างไฟล์ที่ปรับใช้ มันจะลบการกระโดดต้นทางและเปิดใช้งานเส้นทางไฟล์สแตติกที่มีประสิทธิภาพที่สุด

ไซต์มัลติโปรโตคอลที่เรียบง่ายมีลักษณะดังนี้:

listen = "0.0.0.0:443"
workers = 8
root = "/srv/media"

[[sites]]
domain = "media.example.com"
root = "/srv/media"

[sites.protocols]
h1 = true
h2 = true
h3 = true

[sites.tls]
cert = "/etc/webship/media-cert.pem"
key = "/etc/webship/media-key.pem"

ใช้การสิ้นสุด TLS แบบรีเวิร์สพร็อกซีเมื่อ Webship ต้องกำหนดเส้นทางตามเส้นทาง, ใช้การตรวจสอบ WAF หรือ API Shield, บังคับใช้ขีดจำกัดของเนื้อหา, เพิ่มหัวข้อการส่งต่อ, หรือสังเกตฟิลด์ HTTP:

[reverse_proxy]
enabled = true
tls_termination = true

[reverse_proxy.protocols]
h1 = true
h2 = true
h3 = true

[reverse_proxy.tls]
cert = "/etc/webship/proxy-cert.pem"
key = "/etc/webship/proxy-key.pem"

[[reverse_proxy.routes]]
domain = "media.example.com"
path_prefix = "/"
upstreams = ["10.0.0.20:8080"]

ตั้งค่า tls_termination = false เมื่อแหล่งต้นทางต้องเก็บแอปพลิเคชันแบบข้อความธรรมดาและกุญแจเซสชันที่ใช้งานอยู่ การส่งผ่านไม่สามารถตรวจสอบฟิลด์ HTTP ที่เข้ารหัสได้ ดังนั้นการส่งผ่าน TCP จะกำหนดเส้นทางโดย ClientHello SNI ในขณะที่การส่งผ่าน HTTP/3 ต้องการต้นทาง UDP ร่วมหนึ่งแห่ง

ปรับจูนการสตรีมแบบกลุ่มอย่างชัดเจน

สำหรับการสตรีม TLS HTTP/2 ที่มีการใช้งานพร้อมกันสูง, Webship บันทึกการตั้งค่าที่เชื่อมโยงกับกระบวนการเหล่านี้:

[runtime.settings]
h2_tls_write_buffer_bytes = "131072"
proxy_h2_tls_max_send_buffer_bytes = "131072"
proxy_h2_tls_connection_send_buffer_bytes = "33554432"

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

บนระบบ Linux ให้โหลดโมดูล kernel TLS และ BBR และอนุญาตให้บัญชีผู้ใช้บริการ Webship เลือก BBR Webship ล้มเหลวก่อนการผูกเมื่อความสามารถของ kernel ที่จำเป็นของมันไม่สามารถใช้งานได้ ดังนั้นการปรับใช้ไม่สามารถอ้างสิทธิ์เส้นทางที่ปรับปรุงประสิทธิภาพโดยไม่มีสัญญาณในขณะที่ทำงานโดยปราศจากมัน ระบบปฏิบัติการอื่นยังคงรักษา Rustls แบบพกพาและเส้นทางการควบคุมความแออัดที่มีเอกสารสำหรับแพลตฟอร์มของตน

WebTransport เป็นรูปแบบการสตรีมที่แตกต่าง

WebTransport รวมสตรีมที่เชื่อถือได้และดาตาแกรมที่ไม่น่าเชื่อถือเข้าด้วยกันในเซสชันที่ปลอดภัย ซึ่งไม่ใช้ TCP kTLS จุดสิ้นสุดวินิจฉัยแบบจำกัดของ Webship จะตรวจสอบแหล่งกำเนิดและบังคับใช้ข้อจำกัดของเซสชัน สตรีม แคปซูล ดาตาแกรม ไบต์ และเวลาไร้งาน

ในการทดสอบความจุ 1.3.1 การส่งตรง WebTransport ถึง 1,018.1 MiB/s สำหรับการสตรีมที่เชื่อถือได้ และ 1,038.9 MiB/s สำหรับดาตาแกรม การส่งผ่าน TLS ถึง 548.6 MiB/s และ 629.7 MiB/s ตามลำดับ ทั้งสองโหมดผ่านตัวอย่างทั้งห้าครั้งโดยไม่มีตัวอย่างใดถูกปฏิเสธ ดาตาแกรมสูญหายเป็นศูนย์ และไม่มีข้อผิดพลาดสำคัญของไคลเอนต์

แนะนำ HTTP/3 สำหรับลูกค้า WebTransport ใหม่ เส้นทาง HTTP/2 มีอยู่เพื่อความเข้ากันได้กับการตั้งค่าร่างหมดอายุรุ่นเก่า

สิ่งที่ต้องตรวจสอบก่อนการใช้งานจริง

1. ทดสอบขนาดสื่อหรือสิ่งประดิษฐ์ที่คุณจะให้บริการอย่างแท้จริง ไม่ใช่เพียงการตอบสนองสังเคราะห์ขนาดเล็ก
2. ตรวจสอบความยาวของการตอบสนองและสารสรุปเนื้อหาที่ฝั่งลูกค้า
3. การยกเลิกการออกกำลังกาย, คำขอช่วง, ผู้อ่านช้า, และพฤติกรรมการปิดครึ่งต้นกำเนิด
4. วัดอัตราการส่งข้อมูลอย่างต่อเนื่องพร้อมกับ CPU หน่วยความจำ ข้อผิดพลาดของซ็อกเก็ต การส่งซ้ำ และความหน่วงหาง
5. ตรวจสอบโหมดโดยตรง โหมดที่สิ้นสุดด้วย TLS และโหมดผ่านแยกกัน เนื่องจากมีขอบเขตด้านความปลอดภัยและการส่งเส้นทางที่แตกต่างกัน
6. เก็บการติดตั้งเครื่องมือให้อยู่ในสถานะปิดสำหรับการจราจรการผลิตปกติ จากนั้นเปิดการวินิจฉัยที่มีขอบเขตอย่างตั้งใจเมื่อทำการสอบสวน
7. ตรวจสอบ kTLS และ BBR ของ Linux ใหม่หลังจากมีการเปลี่ยนแปลง kernel, container, หรือ systemd sandbox

การสตรีมมีความเร็วเมื่อเส้นทางทั้งหมดทำงานร่วมกัน การออกแบบของ Webship ทำให้การปรับแต่งข้อมูลจำนวนมากเฉพาะโปรโตคอลในขณะเดียวกันยังคงรักษารูปแบบการทำงานหนึ่งแบบและมาตรฐานความถูกต้องหนึ่งมาตรฐาน

อ่านเอกสารฉบับสมบูรณ์ [Webship 1.3.1 documentation](/docs/1.3.1), ตรวจสอบ [วิธีการมาตรฐานและเมทริกซ์คู่แข่ง](/benchmarks), หรือดาวน์โหลดเวอร์ชันที่ลงนามจาก [Downloads](/downloads)