โปรโตคอลควบคุมการส่งข้อมูล (TCP) ใช้ อัลกอริทึม ควบคุมความแออัด หลายแบบ ซึ่งรวมถึงแง่มุมต่างๆ ของ รูปแบบ การเพิ่มแบบบวก/การลดแบบคูณ (AIMD) พร้อมกับรูปแบบอื่นๆ เช่นการเริ่มต้นช้า^{[ 1 ]}และหน้าต่างความแออัด (CWND) เพื่อหลีกเลี่ยงความแออัด

อัลกอริทึมการหลีกเลี่ยงความแออัดของ TCPเป็นพื้นฐานหลักสำหรับการควบคุมความแออัดในอินเทอร์เน็ต^{[ 2 ] [ 3 ] [ 4 ]}ตามหลักการ end-to-endการควบคุมความแออัดส่วนใหญ่เป็นหน้าที่ของโฮสต์อินเทอร์เน็ตไม่ใช่เครือข่ายเอง มีอัลกอริทึมหลายรูปแบบและเวอร์ชันที่นำไปใช้ในสแต็กโปรโตคอลของระบบปฏิบัติการของคอมพิวเตอร์ที่เชื่อมต่อกับ อินเทอร์เน็ต

เพื่อหลีกเลี่ยงปัญหาการล่มสลายของเครือข่าย (congestive collapse ) TCP ใช้กลยุทธ์การควบคุมความแออัดแบบหลายแง่มุม สำหรับแต่ละการเชื่อมต่อ TCP จะรักษาค่า CWND (Congestion Weighted Number) ไว้ เพื่อจำกัดจำนวนแพ็กเก็ตที่ยังไม่ได้รับการยืนยันทั้งหมดที่อาจอยู่ในระหว่างการส่งจากต้นทางถึงปลายทาง ซึ่งคล้ายคลึงกับ การใช้ Sliding Window (หน้าต่างเลื่อน)ของ TCP ในการควบคุมการไหลของข้อมูล

อั ลกอริ ทึมการเพิ่มแบบบวก/การลดแบบคูณ (AIMD) เป็นอัลกอริทึมควบคุมแบบวงปิด AIMD ผสมผสานการเติบโตเชิงเส้นของหน้าต่างความแออัดเข้ากับการลดลงแบบเลขชี้กำลังเมื่อเกิดความแออัด การไหลหลายรายการที่ใช้การควบคุมความแออัดของ AIMD จะบรรจบกันในที่สุดเพื่อใช้ปริมาณที่เท่ากันของลิงก์ที่มีการแย่งชิงกัน^{[ 5 ]}

นี่คืออัลกอริธึมที่อธิบายไว้ในRFC  5681สำหรับสถานะการหลีกเลี่ยงความแออัด^{[ 6 ]}

ในโปรโตคอล TCP หน้าต่างควบคุมการแออัด (CWND) เป็นหนึ่งในปัจจัยที่กำหนดจำนวนไบต์ที่สามารถส่งออกได้ในแต่ละครั้ง หน้าต่างควบคุมการแออัดนี้ถูกดูแลโดยผู้ส่ง และเป็นวิธีการป้องกันไม่ให้ลิงก์ระหว่างผู้ส่งและผู้รับมีปริมาณการรับส่งข้อมูลมากเกินไปจนรับไม่ไหว ซึ่งไม่ควรสับสนกับหน้าต่างเลื่อน (Sliding Window) ที่ผู้ส่งดูแล ซึ่งมีไว้เพื่อป้องกันไม่ให้ผู้รับรับข้อมูลมากเกินไป การคำนวณหน้าต่างควบคุมการแออัดนั้นทำโดยการประมาณปริมาณการแออัดบนลิงก์

เมื่อมีการตั้งค่าการเชื่อมต่อ ค่าหน้าต่างควบคุมการแออัด (congestion window) ซึ่งเป็นค่าที่แต่ละโฮสต์กำหนดขึ้นอย่างอิสระ จะถูกตั้งค่าเป็นค่าทวีคูณเล็กๆ ของขนาดส่วนข้อมูลสูงสุด ( MSS ) ที่อนุญาตในการเชื่อมต่อดังกล่าว การเปลี่ยนแปลงเพิ่มเติมในหน้าต่างควบคุมการแออัดจะถูกกำหนดโดย วิธีการ เพิ่มแบบบวก/ลดแบบคูณ (AIMD) ซึ่งหมายความว่า หากได้รับส่วนข้อมูลทั้งหมดและมีการยืนยันการรับส่งถึงผู้ส่งตรงเวลา ค่าคงที่บางค่าจะถูกเพิ่มเข้าไปในขนาดหน้าต่าง โดยจะใช้ขั้นตอนวิธีที่แตกต่างกัน

ผู้ดูแลระบบอาจปรับขีดจำกัดขนาดหน้าต่างสูงสุด หรือปรับค่าคงที่ที่เพิ่มเข้ามาในระหว่างการเพิ่มค่าแบบต่อเนื่อง ซึ่งเป็นส่วนหนึ่งของ การปรับ แต่ง TCP

การไหลของข้อมูลผ่านการเชื่อมต่อ TCP ยังถูกควบคุมโดยการใช้หน้าต่างรับข้อมูลที่ผู้รับประกาศไว้ ผู้ส่งสามารถส่งข้อมูลได้น้อยกว่าหน้าต่างควบคุมความแออัดของตนเองและหน้าต่างรับข้อมูล

Slow start ซึ่งกำหนดโดยRFC 5681 [ ^{7 ]}เป็นส่วนหนึ่งของ กลยุทธ์ การควบคุมความแออัดที่ TCP ใช้ร่วมกับอัลกอริธึม^อื่น ๆ เพื่อหลีกเลี่ยงการส่งข้อมูลมากกว่าที่เครือข่ายสามารถส่งต่อได้ กล่าวคือ เพื่อหลีกเลี่ยงการทำให้เกิดความแออัดของเครือข่าย  

การเริ่มต้นแบบช้าๆ เริ่มต้นด้วยขนาดหน้าต่างความแออัด (CWND) ที่ 1, 2, 4 หรือ 10 MSS ^{[ 8 ] [ 3 ] : 1} ค่าสำหรับขนาดหน้าต่างความแออัดสามารถเพิ่มขึ้นได้ 1 MSS ในแต่ละการยืนยัน (ACK) ที่ได้รับ ซึ่ง ^จะทำให้ขนาดหน้าต่างเพิ่มขึ้นเป็นสองเท่าในแต่ละRTT [ ^{a ]}

อัตราการส่งข้อมูลจะเพิ่มขึ้นตามอัลกอริทึมการเริ่มต้นช้า จนกว่าจะตรวจพบการสูญหายของแพ็กเก็ต หน้าต่างที่ผู้รับประกาศ (rwnd) กลายเป็นปัจจัยจำกัด หรือถึง เกณฑ์การเริ่มต้นช้า (ssthresh)ซึ่งใช้ในการพิจารณาว่าจะใช้อัลกอริทึมการเริ่มต้นช้าหรืออัลกอริทึมการหลีกเลี่ยงความแออัด โดยค่าที่ตั้งไว้จะจำกัดการเริ่มต้นช้า

หากค่า CWND ถึงssthresh TCP จะเปลี่ยนไปใช้ขั้นตอนวิธีหลีกเลี่ยงความแออัด ค่า CWND ควรเพิ่มขึ้นสูงสุด 1 MSS สำหรับแต่ละ RTT สูตรทั่วไปคือแต่ละ ACK ใหม่จะเพิ่มค่า CWND ขึ้นตามค่า MSS * MSS / CWNDซึ่งจะเพิ่มขึ้นเกือบเป็นเส้นตรงและให้ค่าประมาณที่ยอมรับได้

หากเกิดการสูญเสียข้อมูล TCP จะสันนิษฐานว่าเกิดจากความแออัดของเครือข่ายและจะดำเนินการลดภาระที่ส่งไปยังเครือข่าย มาตรการเหล่านี้ขึ้นอยู่กับอัลกอริทึมการหลีกเลี่ยงความแออัดของ TCP ที่ใช้

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

TCP Tahoe

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

TCP Reno

มี การส่งซ้ำอย่างรวดเร็วโดยครึ่งหนึ่งของค่า CWND ปัจจุบันจะถูกบันทึกเป็นssthreshและใช้เป็นค่าใหม่สำหรับ CWND จึงข้ามขั้นตอน slow start และไปที่อัลกอริธึมการหลีกเลี่ยงความแออัดโดยตรง อัลกอริธึมโดยรวมในที่นี้เรียกว่าฟื้นตัวเร็ว

การเริ่มต้นแบบช้า (Slow start) ตั้งอยู่บนสมมติฐานที่ว่าส่วนของข้อมูลที่ไม่ได้รับการยืนยันนั้นเกิดจากความแออัดของเครือข่าย แม้ว่านี่จะเป็นสมมติฐานที่ยอมรับได้สำหรับเครือข่ายจำนวนมาก แต่ส่วนของข้อมูลอาจสูญหายไปเนื่องจากสาเหตุอื่น ๆ เช่น คุณภาพการส่งสัญญาณ ในชั้นดาต้าลิงก์ ที่ไม่ดี ดังนั้น การเริ่มต้นแบบช้าจึงอาจทำงานได้ไม่ดีในสถานการณ์ที่มีการรับสัญญาณไม่ดี เช่นเครือข่ายไร้สาย

โปรโตคอลการเริ่มต้นช้ายังทำงานได้ไม่ดีสำหรับการเชื่อมต่อที่มีอายุสั้นเว็บเบราว์เซอร์ รุ่นเก่า จะสร้างการเชื่อมต่อที่มีอายุสั้นติดต่อกันหลายครั้งไปยังเว็บเซิร์ฟเวอร์ และจะเปิดและปิดการเชื่อมต่อสำหรับแต่ละไฟล์ที่ร้องขอ ซึ่งทำให้การเชื่อมต่อส่วนใหญ่อยู่ในโหมดการเริ่มต้นช้า ส่งผลให้เวลาตอบสนองช้าลง เพื่อหลีกเลี่ยงปัญหานี้ เบราว์เซอร์สมัยใหม่จะเปิดการเชื่อมต่อหลายรายการพร้อมกัน หรือใช้การเชื่อมต่อเดียวซ้ำ สำหรับไฟล์ทั้งหมดที่ร้องขอจากเว็บเซิร์ฟเวอร์เฉพาะ อย่างไรก็ตาม การเชื่อมต่อไม่สามารถนำมาใช้ซ้ำได้สำหรับเซิร์ฟเวอร์บุคคล ที่ สามหลายแห่งที่เว็บไซต์ใช้เพื่อดำเนิน การ โฆษณาบนเว็บคุณสมบัติการแชร์ของบริการเครือข่ายสังคม [ ^{9 ]}และสคริปต์ตัวนับของการวิเคราะห์^เว็บ

การส่งซ้ำอย่างรวดเร็ว (Fast retransmit)เป็นการปรับปรุงของTCPที่ช่วยลดเวลาที่ผู้ส่งต้องรอ ก่อนที่จะส่งส่วนข้อมูลที่สูญหายซ้ำอีกครั้ง โดยปกติแล้ว ผู้ส่ง TCP จะใช้ตัวจับเวลาแบบง่ายๆ เพื่อตรวจสอบส่วนข้อมูลที่สูญหาย หากไม่ได้รับการยืนยันการรับส่งข้อมูลสำหรับส่วนข้อมูลใดส่วนหนึ่งภายในเวลาที่กำหนด (ซึ่งเป็นฟังก์ชันของเวลาหน่วงในการรับส่งข้อมูลโดย ประมาณ ) ผู้ส่งจะถือว่าส่วนข้อมูลนั้นสูญหายในเครือข่ายและจะส่งส่วนข้อมูลนั้นซ้ำอีกครั้ง

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

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

ชื่อ Reno และ Tahoe เป็นชื่อของ ระบบปฏิบัติการ BSD UNIXและถูกใช้เพื่ออ้างถึงอัลกอริทึมควบคุมความแออัด (CCA) อย่างน้อยก็ในเอกสารปี 1996 โดย Kevin Fall และ Sally Floyd ^{[ 10 ]}

ต่อไปนี้เป็นการจัดประเภทที่เป็นไปได้ตามคุณสมบัติดังต่อไปนี้:

1. ประเภทและปริมาณของข้อเสนอแนะที่ได้รับจากเครือข่าย
2. ความสามารถในการปรับใช้แบบค่อยเป็นค่อยไปบนอินเทอร์เน็ตในปัจจุบัน
3. ด้านประสิทธิภาพที่มุ่งหวังจะปรับปรุง ได้แก่ เครือ ข่ายที่มีแบนด์วิดท์และเวลาหน่วง สูง (B); ลิงก์ที่มีการสูญเสียข้อมูล (L); ความเป็นธรรม (F); ข้อได้เปรียบสำหรับข้อมูลระยะสั้น (S); ลิงก์อัตราแปรผัน (V); ความเร็วในการบรรจบกัน (C)
4. เกณฑ์ความยุติธรรมที่ใช้

กลไกการหลีกเลี่ยงการจราจรติดขัดที่เป็นที่รู้จักกันดีบางส่วนถูกจัดประเภทตามแผนผังนี้ดังต่อไปนี้:

อัลกอริทึม TCP Tahoe และ Reno ได้รับการตั้งชื่อย้อนหลังตามเวอร์ชันหรือรุ่นของ ระบบปฏิบัติการ 4.3BSDที่แต่ละอัลกอริทึมปรากฏครั้งแรก (ซึ่งตั้งชื่อตามทะเลสาบ TahoeและเมืองReno ในรัฐเนวาดา ที่อยู่ใกล้เคียง ) อัลกอริทึม Tahoe ปรากฏครั้งแรกใน 4.3BSD-Tahoe (ซึ่งสร้างขึ้นเพื่อรองรับมินิคอมพิวเตอร์ CCI Power 6/32 "Tahoe" ) และต่อมาได้เปิดให้ผู้ได้รับอนุญาตที่ไม่ใช่ AT&T สามารถใช้งานได้ในฐานะส่วนหนึ่งของ 4.3BSD Networking Release 1 ซึ่งทำให้มีการเผยแพร่และใช้งานอย่างกว้างขวาง มีการปรับปรุงใน 4.3BSD-Reno และต่อมาได้เผยแพร่สู่สาธารณะในชื่อ Networking Release 2 และต่อมาคือ 4.4BSD-Lite

แม้ว่าทั้ง Tahoe และ Reno จะถือว่าการหมดเวลาการส่งซ้ำ (RTO) และ ACK ซ้ำเป็นเหตุการณ์การสูญหายของแพ็กเก็ต แต่พฤติกรรมของ Tahoe และ Reno แตกต่างกันหลักๆ ในวิธีการตอบสนองต่อ ACK ซ้ำ:

• Tahoe: หากได้รับ ACK ซ้ำกัน 3 รายการ (เช่น ACK 4 รายการที่ยืนยันแพ็กเก็ตเดียวกัน ซึ่งไม่ได้แนบมากับข้อมูลและไม่เปลี่ยนแปลงหน้าต่างที่ผู้รับประกาศ) Tahoe จะทำการส่งซ้ำอย่างรวดเร็ว ตั้งค่าเกณฑ์การเริ่มต้นช้าเป็นครึ่งหนึ่งของหน้าต่างความแออัดปัจจุบัน ลดหน้าต่างความแออัดเป็น 1 MSS และรีเซ็ตเป็นสถานะการเริ่มต้นช้า^{[ 17 ]}
• Reno: หากได้รับ ACK ซ้ำกัน 3 รายการ Reno จะทำการส่งซ้ำอย่างรวดเร็วและข้ามขั้นตอนการเริ่มต้นช้าโดยการลดหน้าต่างความแออัดลงครึ่งหนึ่ง (แทนที่จะตั้งค่าเป็น 1 MSS เหมือน Tahoe) ตั้งค่า ssthresh ให้เท่ากับหน้าต่างความแออัดใหม่ และเข้าสู่ขั้นตอนที่เรียกว่า การกู้คืน อย่างรวดเร็ว^{[ 18 ]}

ทั้งในเมืองทาโฮและรีโน หากการตอบรับ (ACK) หมดเวลา (RTO timeout) จะใช้การเริ่มต้นแบบช้า (slow start) และทั้งสองอัลกอริทึมจะลดหน้าต่างการแออัด (congestion window) เหลือ 1 MSS

TCP New Reno ซึ่งกำหนดโดยRFC 6582 (ซึ่งแทนที่คำจำกัดความก่อนหน้านี้ในRFC 3782และRFC 2582 ) ช่วยปรับปรุงการส่งซ้ำในระหว่างขั้นตอนการกู้คืนอย่างรวดเร็วของ TCP Reno    

ในระหว่างการกู้คืนอย่างรวดเร็ว เพื่อให้หน้าต่างส่งข้อมูลเต็มอยู่เสมอ สำหรับทุกๆ ACK ที่ซ้ำกันที่ส่งกลับมา จะมีการส่งแพ็กเก็ตใหม่ที่ยังไม่ได้ส่งจากส่วนท้ายของหน้าต่างการแออัด

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

หลังจากส่งข้อมูลซ้ำ ข้อมูลที่ได้รับการยืนยันใหม่จะมีสองกรณี:

• การรับทราบอย่างสมบูรณ์: ACK จะรับทราบเซ็กเมนต์ระดับกลางทั้งหมดที่ส่งมา ssthresh ไม่สามารถเปลี่ยนแปลงได้ และ cwnd สามารถตั้งค่าเป็น ssthresh ได้
• การยืนยันการรับข้อมูลบางส่วน: การยืนยันการรับข้อมูล (ACK) ไม่ได้หมายความว่าจะยืนยันการรับข้อมูลทั้งหมด ซึ่งอาจส่งผลให้เกิดการสูญหายอีกครั้ง หากได้รับอนุญาต ให้ส่งส่วนแรกที่ยังไม่ได้รับการยืนยันซ้ำอีกครั้ง

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

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

New Reno ทำงานได้ดีเท่ากับ SACK ในอัตราข้อผิดพลาดแพ็กเก็ตต่ำ และมีประสิทธิภาพเหนือกว่า Reno อย่างมากในอัตราข้อผิดพลาดสูง^{[ 19 ]}

จนกระทั่งช่วงกลางทศวรรษ 1990 การหมดเวลาที่กำหนดไว้ทั้งหมดและความล่าช้าในการรับส่งข้อมูลแบบรอบทิศทางที่วัดได้ของ TCP นั้นขึ้นอยู่กับแพ็กเก็ตที่ส่งล่าสุดในบัฟเฟอร์การส่งเท่านั้นนักวิจัยจากมหาวิทยาลัยแอริโซนาLarry PetersonและLawrence Brakmoได้แนะนำ TCP Vegas ซึ่งมีการตั้งค่าการหมดเวลาและวัดความล่าช้าในการรับส่งข้อมูลแบบรอบทิศทางสำหรับทุกแพ็กเก็ตในบัฟเฟอร์การส่ง นอกจากนี้ TCP Vegas ยังใช้การเพิ่มแบบบวกในหน้าต่างความแออัด ในการศึกษาเปรียบเทียบ TCP CCA ต่างๆ ในปี 2012 พบว่า TCP Vegas มีความราบรื่นที่สุด รองลงมาคือ TCP CUBIC ^{[ 20 ]}

TCP Vegas ไม่ได้ถูกใช้งานอย่างแพร่หลายนอกห้องปฏิบัติการของ Peterson แต่ถูกเลือกให้เป็นวิธีการควบคุมความแออัดเริ่มต้นสำหรับเฟิร์มแวร์DD-WRT v24 SP2 ^{[ 21 ]}

TCP Hybla ^{[ 22 ] [ 23 ]}มีเป้าหมายเพื่อขจัดบทลงโทษสำหรับการเชื่อมต่อ TCP ที่ใช้ลิงก์วิทยุภาคพื้นดินหรือดาวเทียมที่มีความหน่วงสูง การปรับปรุง Hybla ขึ้นอยู่กับการประเมินเชิงวิเคราะห์ของพลวัตของหน้าต่างความแออัด^{[ 24 ]}

Binary Increase Congestion control (BIC) เป็นการใช้งาน TCP ที่มี CCA ที่ได้รับการปรับให้เหมาะสมสำหรับเครือข่ายความเร็วสูงที่มีความหน่วงสูง ซึ่งรู้จักกันในชื่อเครือข่ายยาวและหนา (LFN) ^{[ 25 ]} BIC ถูกใช้เป็นค่าเริ่มต้นในเคอร์เนล Linux เวอร์ชัน 2.6.8 ถึง 2.6.18

CUBIC เป็นรูปแบบที่ลดความรุนแรงและเป็นระบบมากกว่า BIC โดยที่หน้าต่างจะเป็นฟังก์ชันกำลังสามของเวลาตั้งแต่เหตุการณ์ความแออัดครั้งล่าสุด โดยจุดเปลี่ยนผันจะอยู่ที่หน้าต่างก่อนเกิดเหตุการณ์นั้น CUBIC ถูกใช้เป็นค่าเริ่มต้นในเคอร์เนล Linuxตั้งแต่เวอร์ชัน 2.6.19 เป็นต้นไป

Agile-SD เป็น CCA ที่ใช้ Linux ซึ่งออกแบบมาสำหรับเคอร์เนล Linux จริง เป็นอัลกอริธึมฝั่งผู้รับที่ใช้แนวทางตามการสูญเสียโดยใช้กลไกใหม่ที่เรียกว่าปัจจัยความคล่องตัว (AF) เพื่อเพิ่มการใช้แบนด์วิดท์บนเครือข่ายความเร็วสูงและระยะสั้น (เครือข่ายที่มีผลิตภัณฑ์แบนด์วิดท์-ความล่าช้าต่ำ) เช่น เครือข่ายบริเวณท้องถิ่นหรือเครือข่ายใยแก้วนำแสง โดยเฉพาะอย่างยิ่งเมื่อขนาดบัฟเฟอร์ที่ใช้มีขนาดเล็ก^{[ 26 ]}ได้รับการประเมินโดยการเปรียบเทียบประสิทธิภาพกับ Compound TCP (CCA เริ่มต้นใน MS Windows) และ CUBIC (ค่าเริ่มต้นของ Linux) โดยใช้โปรแกรมจำลอง NS-2 พบว่าช่วยปรับปรุงประสิทธิภาพโดยรวมได้ถึง 55% ในแง่ของปริมาณงานเฉลี่ย

Westwood+ เป็นการปรับปรุง TCP Reno ที่ส่งจากฝั่งผู้ส่งเท่านั้น ซึ่งช่วยเพิ่มประสิทธิภาพการควบคุมการแออัดของ TCP ทั้งในเครือข่ายแบบมีสายและไร้สาย TCP Westwood+ ใช้ การประมาณ แบนด์วิดท์ แบบ end-to-end เพื่อกำหนดขนาดหน้าต่างการแออัดและเกณฑ์ slow-start หลังจากเกิดการแออัด กล่าวคือ หลังจากได้รับ ACK ซ้ำกันสามครั้งหรือหมดเวลา แบนด์วิดท์จะถูกประมาณโดยการหาค่าเฉลี่ยของอัตราการส่งแพ็กเก็ต ACK กลับมา แตกต่างจาก TCP Reno ที่ลดขนาดหน้าต่างการแออัดลงครึ่งหนึ่งโดยไม่พิจารณาอะไรเลยหลังจากได้รับ ACK ซ้ำกันสามครั้ง TCP Westwood+ จะกำหนดเกณฑ์ slow-start และหน้าต่างการแออัดแบบปรับเปลี่ยนได้ โดยคำนึงถึงการประมาณแบนด์วิดท์ที่มีอยู่ ณ เวลาที่เกิดการแออัด เมื่อเทียบกับ Reno และ New Reno แล้ว Westwood+ ช่วยเพิ่มปริมาณงานบนลิงก์ไร้สายได้อย่างมาก และปรับปรุงความเป็นธรรมในเครือข่ายแบบมีสาย

Compound TCP เป็นการ ใช้งาน TCP ของ Microsoftที่รักษาหน้าต่างควบคุมการแออัดสองแบบที่แตกต่างกันพร้อมกัน โดยมีเป้าหมายเพื่อให้ได้ประสิทธิภาพที่ดีบน LFNs โดยไม่กระทบต่อความเป็นธรรมมีการใช้งานอย่างแพร่หลายใน Windows เวอร์ชันต่างๆ ตั้งแต่ Microsoft Windows VistaและWindows Server 2008และได้รับการพอร์ตไปยัง Windows เวอร์ชันเก่ากว่า รวมถึงLinuxด้วย

TCP Proportional Rate Reduction (PRR) ^{[ 27 ]}เป็นอัลกอริทึมที่ออกแบบมาเพื่อปรับปรุงความแม่นยำของข้อมูลที่ส่งระหว่างการกู้คืน อัลกอริทึมนี้รับประกันว่าขนาดหน้าต่างหลังการกู้คืนจะใกล้เคียงกับเกณฑ์การเริ่มต้นช้ามากที่สุด ในการทดสอบที่ดำเนินการโดยGoogleพบว่า PRR ส่งผลให้ความหน่วงเฉลี่ยลดลง 3–10% และเวลาหมดเวลาในการกู้คืนลดลง 5% ^{[ 28 ]} PRR มีให้ใช้งานในเคอร์เนล Linuxตั้งแต่เวอร์ชัน 3.2 ^{[ 29 ]}

แบนด์วิดท์คอขวดและเวลาการแพร่กระจายแบบไปกลับ (BBR) เป็น CCA ที่พัฒนาขึ้นที่ Google ในปี 2016 ^{[ 30 ]}ในขณะที่ CCA ส่วนใหญ่เป็นแบบอิงการสูญเสีย กล่าวคือ อาศัยการสูญเสียแพ็กเก็ตเพื่อตรวจจับความแออัดและอัตราการส่งที่ต่ำลง แต่ BBR เช่นเดียวกับTCP Vegasเป็นแบบอิงโมเดล อัลกอริทึมนี้ใช้แบนด์วิดท์สูงสุดและเวลาไปกลับที่เครือข่ายส่งแพ็กเก็ตข้อมูลขาออกชุดล่าสุดเพื่อสร้างโมเดลของเครือข่าย การยืนยันการส่งแพ็กเก็ตแบบสะสมหรือแบบเลือกแต่ละครั้งจะสร้างตัวอย่างอัตราที่บันทึกปริมาณข้อมูลที่ส่งในช่วงเวลาระหว่างการส่งแพ็กเก็ตข้อมูลและการยืนยันแพ็กเก็ตนั้น^{[ 31 ]}

เมื่อนำไปใช้ที่YouTube BBRv1 ให้ผลลัพธ์อัตราการรับส่งข้อมูลเครือข่ายที่สูงขึ้นโดยเฉลี่ย 4% และสูงถึง 14% ในบางประเทศ^{[ 32 ]} BBR มีให้บริการสำหรับ Linux TCP ตั้งแต่ Linux 4.9 ^{[ 33 ]}นอกจากนี้ยังมีให้บริการสำหรับQUIC ด้วย^{[ 34 ]}

ความเป็นธรรมของ BBR เวอร์ชัน 1 (BBRv1) ต่อสตรีมที่ไม่ใช่ BBR เป็นที่ถกเถียงกัน ในขณะที่การนำเสนอของ Google แสดงให้เห็นว่า BBRv1 สามารถทำงานร่วมกับ CUBIC ได้ดี^{[ 30 ]}นักวิจัยเช่น Geoff Huston และ Hock, Bless และ Zitterbart พบว่ามันไม่เป็นธรรมต่อสตรีมอื่นๆ และไม่สามารถปรับขนาดได้^{[ 35 ]} Hock และคณะยังพบ "ปัญหาร้ายแรงบางประการ เช่น ความล่าช้าในการเข้าคิวที่เพิ่มขึ้น ความไม่เป็นธรรม และการสูญเสียแพ็กเก็ตจำนวนมาก" ในการใช้งาน BBR ของ Linux 4.9 ^{[ 36 ]} Soheil Abbasloo และคณะ (ผู้เขียน C2TCP) แสดงให้เห็นว่า BBRv1 ทำงานได้ไม่ดีในสภาพแวดล้อมแบบไดนามิก เช่น เครือข่ายเซลลูลาร์^{[ 11 ] [ 12 ]}พวกเขายังแสดงให้เห็นว่า BBR มีปัญหาเรื่องความไม่เป็นธรรม ตัวอย่างเช่น เมื่อ โฟลว์ CUBIC (ซึ่งเป็นการ ใช้งาน TCP เริ่มต้น ใน Linux, Android และ MacOS) อยู่ร่วมกับโฟลว์ BBR ในเครือข่าย โฟลว์ BBR สามารถครอบงำโฟลว์ CUBIC และได้รับแบนด์วิดท์ลิงก์ทั้งหมดจากโฟลว์นั้น (ดูรูปที่ 18 ใน^{[ 11 ]} )

เวอร์ชัน 2 พยายามจัดการกับปัญหาความไม่เป็นธรรมเมื่อทำงานร่วมกับการจัดการความแออัดตามการสูญเสีย เช่น CUBIC ^{[ 37 ]}ใน BBRv2 โมเดลที่ใช้โดย BBRv1 ได้รับการปรับปรุงเพื่อรวมข้อมูลเกี่ยวกับการสูญเสียแพ็กเก็ตและข้อมูลจากการแจ้งเตือนความแออัดแบบชัดเจน (ECN) ^{[ 38 ]}แม้ว่า BBRv2 อาจมีปริมาณงานต่ำกว่า BBRv1 ในบางครั้ง แต่โดยทั่วไปถือว่ามีปริมาณงาน ที่ดี กว่าWindows 11 เวอร์ชัน 24H2และWindows Server 2025รองรับ BBRv2 แต่อาจไม่ได้เปิดใช้งานโดยค่าเริ่มต้น

เวอร์ชัน 3 (BBRv3) แก้ไขข้อบกพร่องสองประการใน BBRv2 (การสิ้นสุดการตรวจสอบแบนด์วิดท์ก่อนกำหนด การบรรจบกันของแบนด์วิดท์) และทำการปรับแต่งประสิทธิภาพบางส่วน นอกจากนี้ยังมีเวอร์ชันที่เรียกว่า BBR.Swift ซึ่งปรับให้เหมาะสมสำหรับลิงก์ภายในศูนย์ข้อมูล โดยใช้ network_RTT (ไม่รวมความล่าช้าของตัวรับ) เป็นสัญญาณควบคุมความแออัดหลัก^{[ 38 ]}

Cellular Controlled Delay TCP (C2TCP) ^{[ 11 ] [ 12 ]}เกิดขึ้นจากการขาดแนวทาง TCP แบบ end-to-end ที่ยืดหยุ่นซึ่งสามารถตอบสนอง ความต้องการ QoS ที่หลากหลายสำหรับแอปพลิเคชันต่างๆ โดยไม่จำเป็นต้องเปลี่ยนแปลงอุปกรณ์เครือข่าย C2TCP มี เป้าหมายเพื่อตอบสนองความต้องการ ความหน่วงต่ำมากและแบนด์วิดท์สูงของแอปพลิเคชันต่างๆ เช่นความเป็นจริงเสมือนการประชุมทางวิดีโอเกมออนไลน์ระบบสื่อสารยานยนต์ฯลฯ ในสภาพแวดล้อมที่มีพลวัตสูง เช่นเครือข่ายเซลลูลาร์LTE ในปัจจุบัน และ5G ในอนาคต C2TCP ทำงานเป็นส่วนเสริมบน TCP แบบ loss-based (เช่น Reno, NewReno, CUBIC , BIC , ...) โดยจำเป็นต้องติดตั้งเฉพาะฝั่งเซิร์ฟเวอร์เท่านั้น และทำให้ความล่าช้าเฉลี่ยของแพ็กเก็ตถูกจำกัดไว้ที่ความล่าช้าที่ต้องการซึ่งกำหนดโดยแอปพลิ เคชัน

นักวิจัยที่NYU ^{[ 39 ]}แสดงให้เห็นว่า C2TCP มีประสิทธิภาพเหนือกว่าในด้านความล่าช้าและการเปลี่ยนแปลงความล่าช้าของรูปแบบ TCP ที่ทันสมัยต่างๆ ตัวอย่างเช่น พวกเขาแสดงให้เห็นว่าเมื่อเปรียบเทียบกับ BBR, CUBIC และ Westwood โดยเฉลี่ยแล้ว C2TCP ลดความล่าช้าเฉลี่ยของแพ็กเก็ตลงประมาณ 250%, 900% และ 700% ตามลำดับในสภาพแวดล้อมเครือข่ายเซลลูลาร์ต่างๆ^{[ 11 ]}

Elastic-TCP ได้รับการเสนอในเดือนกุมภาพันธ์ 2019 เพื่อเพิ่มการใช้แบนด์วิดท์บนเครือข่ายที่มี BDP สูงเพื่อรองรับการประมวลผลแบบคลาวด์เป็น CCA ที่ใช้ Linux ซึ่งออกแบบมาสำหรับเคอร์เนล Linux เป็นอัลกอริทึมฝั่งผู้รับที่ใช้แนวทางตามการสูญเสีย-ความล่าช้าโดยใช้กลไกใหม่ที่เรียกว่าฟังก์ชันถ่วงน้ำหนักที่สัมพันธ์กับหน้าต่าง (WWF) มีความยืดหยุ่นสูงในการจัดการกับลักษณะเครือข่ายที่แตกต่างกันโดยไม่จำเป็นต้องปรับแต่งโดยมนุษย์ ได้รับการประเมินโดยการเปรียบเทียบประสิทธิภาพกับ Compound TCP (CCA เริ่มต้นใน MS Windows), CUBIC (ค่าเริ่มต้นสำหรับ Linux) และ TCP-BBR (ค่าเริ่มต้นของ Linux 4.9 ที่ Google ใช้) โดยใช้โปรแกรมจำลองและทดสอบ NS-2 Elastic-TCP ปรับปรุงประสิทธิภาพโดยรวมอย่างมีนัยสำคัญในแง่ของปริมาณงานเฉลี่ย อัตราการสูญเสีย และความล่าช้า^{[ 40 ]}

Soheil Abbasloo และคณะได้เสนอ NATCP (Network-Assisted TCP) ^{[ 13 ]}ซึ่งเป็นการออกแบบ TCP ที่เป็นที่ถกเถียงกัน โดยมุ่งเป้าไปที่ การประมวลผลแบบเอดจ์หลายการเข้าถึง (MEC) แนวคิดหลักของ NATCP คือ หากทราบลักษณะของเครือข่ายล่วงหน้า TCP จะได้รับการออกแบบที่แตกต่างออกไป ดังนั้น NATCP จึงใช้คุณสมบัติและลักษณะที่มีอยู่ในสถาปัตยกรรมเซลลูลาร์แบบ MEC ในปัจจุบันเพื่อผลักดันประสิทธิภาพของ TCP ให้ใกล้เคียงกับประสิทธิภาพสูงสุด NATCP ใช้การตอบรับนอกแบนด์จากเครือข่ายไปยังเซิร์ฟเวอร์ที่อยู่ใกล้เคียง การตอบรับจากเครือข่าย ซึ่งรวมถึงความจุของลิงก์การเข้าถึงเซลลูลาร์และ RTT ขั้นต่ำของเครือข่าย จะนำทางเซิร์ฟเวอร์เพื่อปรับอัตราการส่งของตน ดังที่ผลลัพธ์เบื้องต้นแสดงให้เห็น NATCP มีประสิทธิภาพเหนือกว่ารูปแบบ TCP ที่ทันสมัย^{​​[ 13 ] [ 41 ]}

• ฟาสต์ ท็อป
• TCP FAST ทั่วไป^{[ 42 ]}
• เอช-ทีซีพี
• ศูนย์ข้อมูล TCP
• TCP ความเร็วสูง
• HSTCP-LP ^{[ 43 ]}
• LEDBAT
• ทีพีซี-อิลลินอยส์
• TCP-LP ^{[ 43 ]}
• ถุง TCP
• TCP ที่ปรับขนาดได้
• TCP Veno ^{[ 44 ]}
• เวสต์วูด
• XCP ^{[ 45 ]}
• YeAH-TCP ^{[ 46 ]}
• TCP-FIT ^{[ 47 ]}
• การหลีกเลี่ยงการจราจรติดขัดด้วยช่วงเวลาที่เป็นปกติ (CANIT) ^{[ 48 ]}
• การควบคุมความแออัดของเครือข่ายประสาทเทียมแบบไม่เชิงเส้นโดยใช้อัลกอริธึมทางพันธุกรรมสำหรับเครือข่าย TCP/IP ^{[ 49 ]}
• ดี-ทีซีพี^{[ 50 ]}
• NexGen D-TCP ^{[ 51 ]}
• โคปา^{[ 52 ]}

TCP New Renoเป็นอัลกอริทึมที่ใช้งานกันมากที่สุด การสนับสนุน SACK เป็นเรื่องปกติมากและเป็นส่วนขยายของ Reno/New Reno อัลกอริทึมอื่นๆ ส่วนใหญ่เป็นข้อเสนอที่แข่งขันกันซึ่งยังคงต้องได้รับการประเมิน เริ่มต้นด้วยเวอร์ชัน 2.6.8 เคอร์เนล Linux ได้เปลี่ยนการใช้งานเริ่มต้นจาก New Reno เป็นBICการใช้งานเริ่มต้นถูกเปลี่ยนอีกครั้งเป็น CUBIC ในเวอร์ชัน 2.6.19 FreeBSDตั้งแต่เวอร์ชัน 14.X เป็นต้นไปก็ใช้ CUBIC เป็นอัลกอริทึมเริ่มต้นเช่นกัน^{[ 53 ]}เวอร์ชันก่อนหน้าใช้ New Reno อย่างไรก็ตาม FreeBSD รองรับตัวเลือกอื่นๆ อีกหลายอย่าง^{[ 54 ]}

เมื่อผลคูณของแบนด์วิดท์และเวลาแฝงต่อการรับส่งข้อมูลเพิ่มขึ้น ไม่ว่าจะเป็นรูปแบบการจัดคิวแบบใดก็ตาม TCP จะไม่มีประสิทธิภาพและมีแนวโน้มที่จะเกิดความไม่เสถียร ประเด็นนี้มีความสำคัญมากขึ้นเรื่อยๆ เมื่ออินเทอร์เน็ตพัฒนาไปสู่การใช้ลิงก์ใยแก้วนำแสงที่มีแบนด์วิดท์สูงมาก

TCP Interactive (iTCP) ^{[ 55 ]}อนุญาตให้แอปพลิเคชันสมัครรับเหตุการณ์ TCP และตอบสนองตามนั้น ทำให้สามารถขยายฟังก์ชันต่างๆ ของ TCP จากภายนอกเลเยอร์ TCP ได้ กลไกการควบคุมความแออัดของ TCP ส่วนใหญ่ทำงานภายใน iTCP ยังช่วยให้แอปพลิเคชันขั้นสูงสามารถมีส่วนร่วมในการควบคุมความแออัดได้โดยตรง เช่น การควบคุมอัตราการสร้างแหล่งที่มา

Zeta-TCPตรวจจับความแออัดจากทั้งการวัดความหน่วงและอัตราการสูญเสีย เพื่อเพิ่มปริมาณงาน ให้สูงสุด Zeta-TCP จะใช้กลยุทธ์การหน่วงเวลาหน้าต่างความแออัดที่แตกต่างกันตามความน่าจะเป็นของความแออัด นอกจากนี้ยังมีการปรับปรุงอื่นๆ เพื่อตรวจจับการสูญเสียแพ็กเก็ตได้อย่างแม่นยำ หลีกเลี่ยงการหมดเวลาการส่งซ้ำ และเร่งและควบคุมปริมาณการรับส่งข้อมูลขาเข้า (ดาวน์โหลด) ^{[ 56 ]}

CCA อาจถูกจำแนกตามความตระหนักรู้ของเครือข่าย ซึ่งหมายถึงขอบเขตที่อัลกอริธึมเหล่านี้ตระหนักถึงสถานะของเครือข่าย โดยประกอบด้วยสามประเภทหลัก ได้แก่ กล่องดำ กล่องเทา และกล่องเขียว^{[ 57 ]}

อัลกอริทึมแบบกล่องดำนำเสนอวิธีการควบคุมความแออัดแบบไม่เปิดเผยข้อมูล โดยจะทำงานโดยอาศัยเพียงข้อมูลป้อนกลับแบบไบนารีที่ได้รับเมื่อเกิดความแออัด และไม่ถือว่ามีความรู้ใดๆ เกี่ยวกับสถานะของเครือข่ายที่มันจัดการอยู่

อัลกอริทึมแบบ Grey box ใช้การวัดตามเวลา เช่น การเปลี่ยนแปลงของ RTT และอัตราการมาถึงของแพ็กเก็ต เพื่อให้ได้มาซึ่งการวัดและการประมาณค่าแบนด์วิดท์ การแย่งชิงการไหลของข้อมูล และความรู้เกี่ยวกับสภาพเครือข่ายอื่นๆ

อัลกอริทึมแบบกล่องสีเขียวเสนอวิธีการควบคุมความแออัดแบบสองโหมด ซึ่งจะวัดส่วนแบ่งที่ยุติธรรมของแบนด์วิดท์ทั้งหมดที่ควรจัดสรรให้กับแต่ละโฟลว์ ณ จุดใดจุดหนึ่งระหว่างการทำงานของระบบ

• ความเร็วสูง-TCP ^{[ 58 ]}
• BIC TCP (Binary Increase Congestion Control Protocol) ใช้การเพิ่มอัตราการรับส่งข้อมูลของแหล่งที่มาแบบโค้งเว้าหลังจากเหตุการณ์ความแออัดแต่ละครั้ง จนกระทั่งหน้าต่างการรับส่งข้อมูลเท่ากับหน้าต่างก่อนเกิดเหตุการณ์ เพื่อเพิ่มระยะเวลาที่เครือข่ายถูกใช้งานอย่างเต็มประสิทธิภาพให้มากที่สุด หลังจากนั้นจึงทำการตรวจสอบอย่างเข้มข้น
• CUBIC TCP – เป็นรูปแบบที่พัฒนามาจาก BIC ซึ่งมีความรุนแรงน้อยกว่าและเป็นระบบมากกว่า โดยที่ขนาดของหน้าต่างจะเป็นฟังก์ชันกำลังสามของเวลาตั้งแต่เหตุการณ์ความแออัดครั้งล่าสุด โดยจุดเปลี่ยนจะอยู่ที่ขนาดของหน้าต่างก่อนเกิดเหตุการณ์นั้น
• AIMD-FC (การเพิ่มขึ้นแบบบวก การลดลงแบบคูณด้วยการบรรจบกันอย่างรวดเร็ว) ซึ่งเป็นการปรับปรุงของ AIMD ^{[ 59 ]}
• กลไกทวินาม
• โปรโตคอล SIMD
• ไกเอ็มดี

• TCP Vegas – ประเมินความล่าช้าในการเข้าคิว และเพิ่มหรือลดขนาดหน้าต่างแบบเชิงเส้น เพื่อให้จำนวนแพ็กเก็ตต่อโฟลว์คงที่อยู่ในคิวของเครือข่าย Vegas ใช้หลักความยุติธรรมตามสัดส่วน
• FAST TCP – บรรลุสมดุลแบบเดียวกับ Vegas แต่ใช้การควบคุมแบบสัดส่วนแทนการเพิ่มขึ้นเชิงเส้น และจงใจลดระดับการขยายสัญญาณลงเมื่อแบนด์วิดท์เพิ่มขึ้นโดยมีเป้าหมายเพื่อให้มั่นใจถึงเสถียรภาพ
• TCP BBR – ประมาณการความล่าช้าในการเข้าคิว แต่ใช้การเพิ่มขึ้นแบบเลขชี้กำลัง โดยตั้งใจลดความเร็วลงเป็นระยะเพื่อความเป็นธรรมและลดความล่าช้า
• TCP-Westwood (TCPW) – การสูญเสียทำให้หน้าต่างถูกรีเซ็ตเป็นค่าประมาณของผู้ส่งเกี่ยวกับผลคูณของแบนด์วิดท์-ความล่าช้า (RTT ที่วัดได้น้อยที่สุดคูณด้วยอัตราการรับ ACK ที่สังเกตได้) ^{[ 60 ]}
• C2TCP ^{[ 12 ] [ 11 ]}
• TFRC ^{[ 61 ]}
• ทีพี-เรียล
• เสื้อเจอร์ซีย์ของทีพี

• กลไกแบบสองโหมด – กลไกการหลีกเลี่ยงและควบคุมความแออัดแบบสองโหมด
• วิธีการส่งสัญญาณที่เราเตอร์นำมาใช้
  • การตรวจจับล่วงหน้าแบบสุ่ม (Random Early Detectionหรือ RED) จะสุ่มทิ้งแพ็กเก็ตตามสัดส่วนของขนาดคิวในเราเตอร์ ส่งผลให้ปริมาณการรับส่งข้อมูลบางประเภทลดลงแบบทวีคูณ
  • การแจ้งเตือนความแออัดอย่างชัดเจน (ECN)
• การควบคุมความแออัดโดยใช้เครือข่ายช่วย
  • NATCP ^{[ 13 ]} – TCP ที่ได้รับการสนับสนุนจากเครือข่ายใช้การตอบรับที่ชัดเจนนอกแบนด์ซึ่งระบุ RTT ขั้นต่ำของเครือข่ายและความจุของลิงก์การเข้าถึงเซลลูลาร์
  • โปรโตคอลควบคุมความแออัดแบบโครงสร้างแปรผัน (VCP) ใช้บิต ECN สองบิตเพื่อส่งข้อมูลสถานะความแออัดของเครือข่ายกลับมาโดยตรง นอกจากนี้ยังมีอัลกอริทึมฝั่งโฮสต์ปลายทางรวมอยู่ด้วย

อัลกอริทึมต่อไปนี้จำเป็นต้องเพิ่มฟิลด์ที่กำหนดเองลงในโครงสร้างแพ็กเก็ต TCP:

• โปรโตคอลควบคุมที่ชัดเจน (XCP) – แพ็กเก็ต XCP จะมีส่วนหัวความแออัดพร้อมฟิลด์การตอบกลับ ซึ่งระบุการเพิ่มหรือลดของหน้าต่างความแออัดของผู้ส่ง เราเตอร์ XCP จะตั้งค่าการตอบกลับอย่างชัดเจนเพื่อประสิทธิภาพและความเป็นธรรม^{[ 62 ]}
• MaxNet – ใช้ฟิลด์ส่วนหัวเดียวซึ่งบรรจุระดับความแออัดสูงสุดของเราเตอร์ใดๆ บนเส้นทางของโฟลว์ อัตราจะถูกกำหนดตามฟังก์ชันของความแออัดสูงสุดนี้ ส่งผลให้เกิดความยุติธรรมแบบสูงสุด-ต่ำสุด^{[ 63 ]}
• JetMaxเช่นเดียวกับ MaxNet ตอบสนองต่อสัญญาณความแออัดสูงสุดเท่านั้น แต่ยังส่งข้อมูลส่วนอื่นๆ เพิ่มเติมอีกด้วย

• BIC ถูกใช้เป็นค่าเริ่มต้นในเคอร์เนล Linux เวอร์ชัน 2.6.8 ถึง 2.6.18 (สิงหาคม 2547 – กันยายน 2549) ^{[ 64 ]}
• CUBIC ถูกใช้เป็นค่าเริ่มต้นในเคอร์เนล Linux ตั้งแต่เวอร์ชัน 2.6.19 (พฤศจิกายน 2549) ^{[ 64 ]}
• PRR ถูกรวมเข้าไว้ในเคอร์เนล Linux เพื่อปรับปรุงการกู้คืนข้อมูลที่สูญหายตั้งแต่เวอร์ชัน 3.2 (มกราคม 2555) ^{[ 64 ]}
• BBRv1 ถูกรวมเข้าไว้ในเคอร์เนล Linux เพื่อเปิดใช้งานการควบคุมความแออัดตามแบบจำลองตั้งแต่เวอร์ชัน 4.9 (ธันวาคม 2016) ^{[ 64 ]}

• L4Sคือเวอร์ชันปรับปรุงของ ECN ที่ออกแบบมาเพื่อใช้งานกับเอนด์พอยต์ TCP
• การขนส่งพื้นหลังที่มีความล่าช้าน้อยเป็นพิเศษ (LEDBAT)
• ความแออัดของเครือข่าย § การบรรเทา
• โปรโตคอลควบคุมการส่งข้อมูล §§  การควบคุมความแออัดและการพัฒนา

• แนวทางการควบคุมความแออัดในเครือข่ายแพ็กเก็ต
• เอกสารวิจัยด้านการควบคุมการจราจรติดขัด
• ออลแมน, มาร์ค; แพ็กสัน, เวอร์น; สตีเวนส์, ดับเบิลยู. ริชาร์ด (เมษายน 1999). " การส่งซ้ำอย่างรวดเร็ว/การกู้คืนอย่างรวดเร็ว"การควบคุมความแออัดของ TCPคณะทำงานด้านวิศวกรรมอินเทอร์เน็ตมาตรา 3.2 doi : 10.17487/RFC2581 RFC 2581 สืบค้นเมื่อ1 พฤษภาคม 2010
• อัลกอริทึมการจัดการความแออัดและการหลีกเลี่ยงความแออัดของ TCP  – คู่มือ TCP/IP