เหตุใด UDP ที่ไม่น่าเชื่อถือ (ใช้งานที่ชั้นแอปพลิเคชัน) แทน TCP

TCP มอบความเชื่อถือได้ที่ transport layer ในขณะที่ UDP ไม่มี ดังนั้น UDP จึงรวดเร็ว แต่โปรโตคอลที่ชั้นแอปพลิเคชันสามารถใช้กลไกที่เชื่อถือได้ในขณะที่ใช้ UDP

ในแง่นี้เหตุใด UDP ที่ไม่มีความน่าเชื่อถือ (นำไปใช้กับ Application layer) แทน TCP ในกรณีที่ UDP เร็วกว่า TCP ในขณะที่เราต้องการความน่าเชื่อถือ

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

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

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

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

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

UDP ที่มีความน่าเชื่อถือสามารถใช้แทน TCP ได้ เรามีตัวอย่างของมัน: มันเรียกว่าQUIC

จากวิกิพีเดีย:

ในบรรดาแอปพลิเคชันอื่น QUIC ปรับปรุงประสิทธิภาพของเว็บแอปพลิเคชันที่เน้นการเชื่อมต่อที่ใช้ TCP ในปัจจุบัน ทำได้โดยสร้างการเชื่อมต่อแบบมัลติเพล็กซ์ระหว่างจุดปลายสองจุดเหนือ User Datagram Protocol (UDP)

ข้อดีของการใช้ UDP กับการสร้างโปรโตคอลการขนส่งเลเยอร์ใหม่คือเราเตอร์และอุปกรณ์เครือข่ายอื่น ๆ เข้าใจแล้ว

คุณสามารถใช้ UDP เพื่อใช้งานฟังก์ชั่น TCP ที่ชั้นแอพพลิเคชัน (ความน่าเชื่อถือความสามารถในการปรับตัว) คุณสามารถใช้ TCP ได้ตั้งแต่แรกยกเว้นว่าบางสิ่งที่แอปพลิเคชันของคุณต้องการไม่สามารถใช้กับ TCP ได้ หากคุณใช้ฟังก์ชั่นเหล่านั้นด้วยตัวคุณเองคุณอาจจะปิดท้ายได้แย่กว่า TCP ค่าใช้จ่ายที่เพิ่มจะลดประสิทธิภาพโดยรวมเช่นกัน

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

อย่างไรก็ตามโปรโตคอลด้านบนเลเยอร์การขนส่งไม่ได้อยู่ที่นี่

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

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

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

ดังนั้นความแตกต่างโดยรวมก็คือ TCP นั้นเป็นการนำไปใช้ในวัตถุประสงค์ทั่วไปที่ดีมาก แต่มีวัตถุประสงค์เฉพาะที่ UDP สามารถทำเช่นนั้นได้ TCP นั้นทำงานได้ไม่ดีหรือไม่ได้เลย - ตัวอย่างเช่น:

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

แต่โดยทั่วไปแล้วมันไม่คุ้มค่า TCP เป็นสิ่งที่ดีที่สุดดังนั้นทำไมต้องไปทำงานพิเศษทั้งหมดและเพิ่มโอกาส (ใหญ่) ในการเพิ่มข้อบกพร่องและข้อบกพร่องด้านความปลอดภัย

UDP นั้นไม่เร็วเพราะเป็น UDP TCP ไม่ช้าเพราะเป็น TCP

โปรโตคอลทั้งสองได้รับการออกแบบพร้อมกับการรับประกันที่แน่นอนและ TCP แบบดิบมีการรับประกันมากกว่า UDP แบบดิบ

และกฎของหัวแม่มือคือราคาสำหรับการค้ำประกันเป็นผลการดำเนินงาน

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

คุณสามารถเล่นกับการรับประกันเหล่านั้นเช่นกัน ปรับเปลี่ยนเล็กน้อยนี้ปรับเปลี่ยนเล็กน้อย และจากนั้นคุณจะจบลงด้วยโปรโตคอลเหมือนQUICซึ่งเป็นมากกว่า UDP และมันก็เป็นมากคล้ายกับ TCP + TLS ในหลายกรณีมันเร็วกว่า TCP (ถึงแม้ว่าจะมีความล่าช้าในบทความนี้สูงถึง 5% และบัฟเฟอร์สูงถึง 15% ซึ่ง IMO ไม่ใช่เรื่องใหญ่) แต่ในบางสถานการณ์ (เช่นเครือข่ายที่เชื่อถือได้หรือไม่จำเป็นต้องเข้ารหัส) ช้ากว่า (ดูคำอธิบายที่นี่ )

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

ความคิดของคุณจะดีในห้วงอวกาศ

คำตอบที่ถูกต้องคือ "มันขึ้นอยู่กับ" และ "เพราะนั่นจะทำให้เครือข่ายเสียหายโดยรวม" TCP / IP เป็นเครือข่ายที่ดีมากและปรับโดยอัตโนมัติเป็นความเร็วที่เหมาะสม แต่ไม่ได้สร้างแพ็กเก็ตคืน ICMP จำนวนมาก

เมื่อเราเตอร์ที่มี RAM ไม่เพียงพอก็จะได้รับแพ็คเก็ตทุกชนิด - พูดจากสึนามิ, Bittorrent หรือ FDT - มันลดลงและส่งกลับไปยังผู้ส่งแพ็คเก็ต dis-accept ที่ล้มเหลวเล็กน้อย ตอนนี้เซิร์ฟเวอร์ UDP ของคุณต้องติดตามและส่งชิ้นส่วนนั้นอีกครั้งด้วยตนเอง ISP ของเราเตอร์บางตัวมีรูปแบบของ Bittorrent มากมายที่ทำให้เกิดสึนามิ

โปรโตคอลคลื่นยักษ์สึนามิใช้ UDP พร้อมช่องสัญญาณควบคุมใน TCP http://tsunami-udp.sourceforge.net/ฉันพบการศึกษาที่แสดงว่าช้ากว่าสิ่งที่เรียกว่า FDT

โปรโตคอล Fast Data Transfer (FDT) ที่เป็นตำนานจาก CERN สามารถทำให้เครือข่ายทุกเครือข่ายสามารถใช้สตรีม TCP หลายตัว อาจจะเร็วกว่าเพราะมันทำให้การส่งสัญญาณน้อยลงซึ่งสึนามิซึ่งทำให้เครือข่ายท่วมท้นด้วย UDP มากบางตัวก็ไม่ได้ทำให้ข้ามไปเลย

UDP ใช้งานโดยแอพพลิเคชั่นที่ไม่น่าเชื่อถือ: สตรีมมิ่งเสียง, อินพุตเกม / การอัพเดท IO, "ping" เป็นจริงของ ICMP แต่ไม่รับประกัน Bittorrent, mosh ssh ตอบสนองอย่างน่าตกใจ, โทรศัพท์ VOIP, มัลติคาสต์, DNS ถูกส่งผ่าน UDP AFAIK สิ่งใดก็ตามที่ไม่คำนึงถึงแพ็กเก็ตที่หายไปอย่างผิดปกติและสามารถ "catchup" ได้ทันที

TCP / IP เป็นสิ่งประดิษฐ์นักฆ่าที่อนุญาตให้แอป devs ดังนั้นเพียงแค่ตั้งค่าและลืม ซ็อกเก็ตเป็นคู่ของที่อยู่ IP และพอร์ตและถูกออกแบบมาเพื่อให้สามารถติดตั้งและใช้งานได้นานหลายชั่วโมงหลายวันหรือหลายสัปดาห์โดยไม่ต้องเชื่อมต่อใหม่ อีเมลเว็บ IRC และแอพนักฆ่าทั้งหมดใช้ TCP แต่คุณสามารถหยุดการดาวน์โหลดที่แปลกไปอย่างกระทันหันได้เร็วขึ้น ... และในห้วงอวกาศการเชื่อมต่ออาจหมดเวลาไปกับการถ่ายโอนรูปแบบสึนามิที่ดีที่สุดสำหรับการถ่ายโอนไฟล์ระหว่างดวงดาว - คุณอาจอยู่ที่นั่น !!

หลักฐานอยู่ในข้อสังเกตสุดท้ายของสารสกัดการศึกษาทางวิทยาศาสตร์ซึ่งกล่าวถึงสิ่งที่เพิ่มขึ้นในระยะทางที่ฉันกำลังจะเกี่ยวกับ re: ห้วงอวกาศจาก: https://uscholar.univie.ac.at/get/o:300623.pdf

ประสิทธิภาพของ FDT และ GridFTP ที่มี TCP จะสูงกว่าสึนามิและ UDT โดยไม่มีความแออัด อัตราการส่งผ่าน FDT สูงสุดคือ 2.34 Gb / s ด้วย 1 ms RTT แต่จะลดลงอย่างรวดเร็วหลังจาก 100 ms เมื่อเทียบกับ GridFTP ซึ่งทำงานได้ดีกว่า FDT เมื่อลิงก์ RTT ยาวกว่า 100 ms สิ่งที่น่าสนใจคือปริมาณงานของสึนามิไม่ลดลงเมื่อเพิ่ม RTT ขึ้นแสดงว่ามีการควบคุมความแออัดที่มีประสิทธิภาพมากที่สุดเมื่อเพิ่ม RTT

จากนั้นอีกครั้ง ... มีโปรโตคอลอวกาศที่เหมือนกับอีเมลซึ่งจะดีกว่าสำหรับพื้นที่ แอพต้องไม่คำนึงถึงค่าการหมดเวลาเช่นตลอดไป

TCP! = UDP + ความน่าเชื่อถือ

TCP ไม่ได้เป็นเพียง UDP ที่เพิ่มความเชื่อถือได้ TCP มีคุณสมบัติมากกว่าความน่าเชื่อถือ คุณสามารถอ่านเกี่ยวกับพวกเขาใน RFC จำนวนมาก

คุณลักษณะใด ๆ เหล่านี้ "สามารถ" ถูกนำไปใช้งานที่ชั้นแอปพลิเคชัน ในที่สุดก็จะกลายเป็นจุดที่คุณเริ่มต้นการคิดค้นใหม่ล้อ

หากต้องการตั้งชื่อคุณสมบัติบางอย่างของ TCP มี ...

• การสร้างและการยกเลิกการเชื่อมต่อ: ดำเนินการจับมือและการปิดการเชื่อมต่อ

• การควบคุมการไหล: ช่วยให้มั่นใจได้ว่าผู้ส่งและผู้รับส่งสัญญาณในอัตราที่ทั้งคู่สามารถจัดการกับอัตราข้อมูลได้

• การควบคุมความแออัดแบบ end to end: อนุญาตให้โหนด end สามารถเค้นปริมาณงานตามการสูญเสีย อ่านเกี่ยวกับการเริ่มช้าการหลีกเลี่ยงความแออัดและการฟื้นตัวอย่างรวดเร็ว

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