ฉันต้องการหลายช่องสัญญาณระหว่างสองโฮสต์ มีข้อดีหลายประการในการสร้างการเชื่อมต่อ TCP เดียวเท่านั้น แต่ฉันสงสัยว่าการมัลติเพล็กซ์อาจทำให้เกิดปัญหาที่หลีกเลี่ยงไม่ได้ มันจะเป็นอันตรายต่อประสิทธิภาพการทำงานหรือเพิ่มความล่าช้าอย่างมีนัยสำคัญหรือไม่ แล้วการใช้งานหน่วยความจำและการใช้ CPU ล่ะ มีข้อเสนอแนะหรือคำเตือนใด ๆ ที่คุณต้องการให้?
คำตอบ:
TLDR:ข้อเสียเปรียบหลักที่คุณอาจสังเกตเห็นเมื่อมัลติเพล็กซ์หลายช่องทางด้านบนของ TCP (ถ้าคุณทำถูก) คือเวลาแฝงที่เพิ่มขึ้นเนื่องจากการบล็อกส่วนหัวระหว่างแชแนล
ผลที่ตามมา:ถ้าคุณไม่แคร์เรื่องความล่าช้าคุณก็น่าจะสบายดี
บนมืออื่น ๆโดยใช้การเชื่อมต่อ TCP เดียว“หมายถึงการแข่งขันน้อยกับกระแสอื่น ๆ และการเชื่อมต่ออีกต่อไปอาศัยอยู่ซึ่งในการเปิดนำไปสู่การใช้ประโยชน์ในการที่ดีขึ้นของความจุเครือข่ายพร้อมใช้งาน”
หากคุณทวีคูณหลายแชนเนลที่ด้านบนของสตรีม TCP เดียวกันแชนเนลอาจประสบปัญหาการบล็อกส่วนหัว :
การบล็อก Head-of-line (HOL) สามารถเกิดขึ้นได้เมื่อโปรโตคอลการขนส่งเสนอบริการที่ได้รับคำสั่งหรือบริการบางส่วน: หากเซ็กเมนต์หายไปข้อความที่ตามมาจะต้องรอการส่งสัญญาณใหม่ที่สำเร็จในคิวผู้รับและทำให้ล่าช้า
เมื่อคุณทวีคูณหลายสตรีมที่ด้านบนของ TCP คุณจะได้รับ HOL ระหว่างแชนเนล
หากแชนเนล A เติมบัฟเฟอร์การส่ง TCP คุณจะต้องรอก่อนที่จะได้รับข้อมูลทั้งหมดนี้ก่อนที่ข้อมูลใหม่ของแชนเนล B จะสามารถส่งไปยังเลเยอร์แอปพลิเคชันระยะไกลได้อย่างมีประสิทธิภาพ
ดู"มัลติเพล็กซ์บน TCP"สำหรับรายละเอียดเพิ่มเติมเกี่ยวกับมัลติเพล็กซิ่งแชนเนลที่ด้านบนของ TCP และการอภิปรายเกี่ยวกับแฮ็คข่าว
ตัวอย่างทั่วไปของสิ่งนี้คือ SSH SSH สามารถ multiplex หลายช่องทาง (ดูControlMaster, ControlPathและControlPersistใน OpenSSH) การใช้สิ่งนี้จะช่วยลดค่าใช้จ่ายในการเริ่มต้นเซสชัน SSH ใหม่ (latency เริ่มต้น) แต่การถ่ายโอนอย่างหนักในช่องสัญญาณหนึ่งมักจะเพิ่มเวลาแฝง / การโต้ตอบของอีกช่องทางหนึ่ง (ซึ่งจะไม่เกิดขึ้นหากคุณใช้กระแส TCP หลายรายการ): เซสชันและเริ่มทริกเกอร์การถ่ายโอนไฟล์จำนวนมากผ่านช่องทางเดียวกันเซสชันของคุณจะเริ่มมีการโต้ตอบน้อยลง
HTTP / 2 ใช้การร้องขอ / ตอบกลับแบบมัลติเพล็กซ์เพื่อแก้ไขการบล็อก HOL คุณสมบัตินี้มีการโฆษณาในหลายบทความและบทความเกี่ยวกับ HTTP / 2 HTTP / 2 RFCเรียกร้อง:
HTTP / 1.1 เพิ่ม pipelining คำขอ แต่นี่เป็นเพียงส่วนหนึ่งของการร้องขอพร้อมกันและยังคงทนทุกข์ทรมานจากการบล็อกส่วนหัวของบรรทัด
[ ... ]
โปรโตคอลผลลัพธ์นั้นเป็นมิตรกับเครือข่ายมากกว่าเนื่องจากสามารถใช้การเชื่อมต่อ TCP น้อยลงเมื่อเปรียบเทียบกับ HTTP / 1.x นี่หมายถึงการแข่งขันที่น้อยลงกับกระแสอื่น ๆ และการเชื่อมต่อที่ยาวนานขึ้นซึ่งจะนำไปสู่การใช้ประโยชน์จากความจุเครือข่ายที่ดี
อย่างไรก็ตามสิ่งที่ไม่ได้กล่าวถึงคือการปิดกั้น HOL ไม่ได้รับการแก้ไขทั้งหมด HTTP / 2 ผ่าน TCP ยังคงได้รับความทุกข์ ) จากTCP บล็อกระดับ
สิ่งนี้ถูกกล่าวถึงใน บทความ LWNเกี่ยวกับ QUIC:
HTTP / 2 ถูกออกแบบมาเพื่อแก้ไขปัญหานี้โดยใช้หลายรายการ "กระแส" ที่สร้างขึ้นในการเชื่อมต่อเดียว [... ] มันสร้างปัญหาใหม่: การสูญเสียแพ็คเก็ตเดียวจะหยุดการส่งกระแสข้อมูลทั้งหมดในครั้งเดียวการสร้างปัญหาความล่าช้าใหม่ ตัวแปรนี้ในปัญหาการบล็อคส่วนหัวของบรรทัดถูกสร้างขึ้นใน TCP เองและไม่สามารถแก้ไขได้ด้วยการปรับแต่งเพิ่มเติมที่ระดับ HTTP
นั่นเป็นหนึ่งในคุณสมบัติที่แตกต่างของ SCTP (การทำหลายสตรีม) คุณสามารถมีสตรีมอิสระหลายรายการในการเชื่อมโยง SCTP เดียวกันและแต่ละสตรีมไม่ได้บล็อกสตรีมอื่น
ดูSSH ผ่าน SCTP - การเพิ่มประสิทธิภาพโปรโตคอลหลายแชนเนลโดยปรับเป็น SCTPสำหรับผลของการใช้ SCTP เพื่อหลีกเลี่ยงการปิดกั้น HOL ข้ามแชนเนลใน SSH:
SCTP จะรักษาลำดับของข้อความภายในสตรีมเดียวเพื่อลดผลกระทบที่รู้จักกันในชื่อการบล็อกส่วนหัว หากข้อความสูญหายข้อความที่ตามมาจะต้องล่าช้าจนกว่าข้อความที่หายไปจะถูกส่งใหม่เพื่อรักษาลำดับ เนื่องจากมีเพียงข้อความของสตรีมเดียวกันที่ต้องล่าช้าจำนวนข้อความที่ได้รับผลกระทบหลังจากการสูญเสียจะลดลง
[ ... ]
ด้วยการทำแผนที่ช่องทางของ SSH ไปยังสตรีมของ SCTP ประโยชน์ของการสตรีมมิ่งแบบหลายช่องทางนั้นมีให้สำหรับ SSH ซึ่งเป็นการลดการบล็อกส่วนหัวของบรรทัด
SCTP นั้นไม่จำเป็นต้องปรับใช้ง่าย (เนื่องจากความพร้อมใช้งานของระบบปฏิบัติการ, การโต้ตอบระหว่างกลางและอื่น ๆ ) ความเป็นไปได้ที่จะใช้มันมากกว่า UDP ใน userspace
อีกตัวอย่างหนึ่งคือโปรโตคอลQUIC รุ่นทดลองที่ใช้สำหรับมัลติเพล็กซิ่ง HTTP ผ่าน UDP (เนื่องจากมัลติเพล็กซ์สตรีมที่ด้านบนของ TCP เนื่องจาก HTTP / 2 ไม่รองรับการบล็อก HOL ):
QUIC เป็นการขนส่งใหม่ซึ่งช่วยลดความหน่วงแฝงเมื่อเปรียบเทียบกับ TCP บนพื้นผิว QUIC คล้ายกับ TCP + TLS + HTTP / 2 ที่ใช้งานบน UDP
[ ... ]
มัลติเพล็กซ์โดยไม่มีการบล็อคหัวบรรทัด
โปรโตคอล QUIC ของ Google: การย้ายเว็บจาก TCP ไปยัง UDPนำเสนอภาพรวมที่ดีของการบล็อก QUIC และ HOL เมื่อทำการมัลติเพล็กซิ่งแชนเนลที่ด้านบนของ TCP
งานนำเสนอล่าสุดอ้างว่าHTTP ผ่าน QUICปรับปรุงเวลาแฝง แต่การปรับปรุงการปิดกั้น HOL เป็น "ประโยชน์น้อยกว่า":
0-RTT มากกว่า 50% ของการปรับปรุงเวลาแฝง
[ ... ]
การส่งสัญญาณที่หมดเวลาน้อยลงตามการปรับปรุงเวลาแฝงท้าย […]
ผลประโยชน์อื่น ๆ ที่น้อยลงเช่นการบล็อกส่วนหัวของบรรทัด
โปรดทราบว่าในขณะที่ QUIC ได้รับการอธิบายว่า“ คล้ายกับ TCP + TLS + HTTP / 2 ที่ใช้กับ UDP” ในความเป็นจริงเป็นการขนส่งทั่วไปที่สามารถใช้งานได้อย่างอิสระจาก HTTP / 2 และอาจเหมาะกับความต้องการของคุณ
หมายเหตุ: HTTP / QUIC si ไปได้มาตรฐานเป็นHTTP / 3
ฉันว่าคุณต้องอ่านคำแนะนำ ZeroMQรูปแบบที่มันให้ไว้กับเหตุผลและข้อเสียคือการอ่านที่จำเป็น
แต่ไม่เช่นนั้นจะไม่มีปัญหาในการยกเลิกการเชื่อมต่อช่องเครือข่ายจากการส่งข้อมูลแอปพลิเคชันของคุณ คุณจะต้องทำการ muxing และ demuxing ของ data packets ที่ส่งมา (และฉันอยากจะแนะนำสถาปัตยกรรมที่อิงกับ packet ที่นี่ไม่ใช่การสตรีมข้อมูลในการไหลต่อเนื่อง) และการบัฟเฟอร์ของพวกมันที่ปลายแต่ละด้าน
ควรมีผลกระทบเพียงเล็กน้อยมิฉะนั้นคุณอาจต้องการหน่วยความจำเพิ่มขึ้น - เพียงเล็กน้อย - เพื่อบัฟเฟอร์ข้อมูลและ CPU เพิ่มขึ้นเล็กน้อยเมื่อคุณจัดการรหัสเพิ่มเติมเพื่อล็อคและแยกแพ็คเก็ต แต่ไม่มีอะไรสำคัญ (ยกเว้นว่าคุณกำลังเขียนสิ่งที่ผู้เชี่ยวชาญที่ต้องการปริมาณงานและประสิทธิภาพเป็นสิ่งสำคัญ)
ใช่ฉันได้สร้างระบบฐานข้อมูลลูกค้า - เซิร์ฟเวอร์โดยใช้หลักการนี้อย่างแม่นยำ
ช่องสัญญาณมัลติเพล็กซ์บนการเชื่อมต่อ TCP หนึ่งครั้งแต่ละแพ็กเก็ตส่งข้อมูลซึ่งจะแบ่งออกเป็นผู้รับตามลำดับที่ปลายอีกด้านหนึ่ง
Hogging ของการเชื่อมต่อโดยหนึ่งช่องสัญญาณ garrulous ทำโดยผู้ส่งการเชื่อมต่อ TCP ทำการเลือก round-robin ซึ่ง packet ที่จะส่งจากช่องสัญญาณที่มีข้อมูลพร้อมที่จะส่ง
เพื่อจัดการกรณีของช่องสัญญาณหนึ่งที่ตัดสินใจส่งแพ็กเก็ต 1GB และล็อคทุกคนออกไปผู้ส่งสามารถเลือกที่จะแบ่งแพ็คเก็ตเป็นชิ้น ๆ และส่งชิ้นเดียวก่อนที่จะเปิดช่องอีกช่องหนึ่ง ในตอนท้ายที่ได้รับการประกอบชิ้นส่วนอีกครั้งลงในแพ็คเก็ตจะทำก่อนผู้รับเห็นแพ็คเก็ต