RFC ส่วนนี้เกี่ยวกับการส่งผ่านความรับผิดชอบไปยังระบบปฏิบัติการหรืออะไรก็ตามที่เป็นขั้นตอนต่อไปของกระบวนการ มันเกี่ยวข้องกับการแยกชั้น
การตอบรับโดย TCP ไม่รับประกันว่าข้อมูลจะถูกส่งไปยังผู้ใช้ปลายทาง แต่เพียงว่าการรับ TCP นั้นมีความรับผิดชอบในการทำเช่นนั้น
ฉันคิดเสมอเกี่ยวกับวิธีนี้:
- ระบบปฏิบัติการอาจล้มเหลวระหว่างการส่ง ACK และข้อมูลที่มาถึงกระบวนการไคลเอนต์ ("ไคลเอนต์" ที่นี่หมายถึงไคลเอนต์ของระบบปฏิบัติการไม่ใช่ "ไคลเอนต์เครือข่าย")
- กระบวนการไคลเอนต์อาจเป็นบั๊กหรือผิดพลาดหรือช้ากว่าที่คาดไว้มากในการจัดการกับข้อมูลที่เข้ามาหรืออ่านได้ในสถานการณ์ที่ไม่ชัดเจน
- หากไคลเอนต์กำลังส่งข้อมูลเป็นต้นไปอาจเป็นไฟล์ดิสก์ไฟล์อาจยังไม่ได้เขียนหรือล้างข้อมูล
- ถ้าไคลเอนต์กำลังส่งข้อมูลเป็นต้นไปโดย TCP, TCP ด้านไกลอาจไม่ได้ส่งข้อมูลรับ ACK หรือกระบวนการไกลใช้ข้อมูลสำเร็จ
ทั้งหมดที่กล่าวมาก็คือนี่เป็นการตอบรับเลเยอร์ 3 ("ฉันได้ยินไบต์ของคุณ") ไม่ใช่การตอบรับเลเยอร์ที่สูงขึ้น ลองพิจารณาตัวอย่างเช่นความแตกต่างระหว่าง TCP ACK, SMTP 250 OKหลังจากเกตเวย์จดหมายของ hop ถัดไปยอมรับข้อความ, ข้อความการรับข้อความ (เช่นต่อRFC 3798 ), พิกเซลการติดตามที่เปิดข้อความ, บันทึกขอบคุณจาก PA และตอบว่า "ใช่ฉันจะทำ"
อีกตัวอย่างที่ชัดเจนคือเครื่องพิมพ์:
- มันจะต้อง ACK ข้อมูลก่อนที่มันจะรู้ว่าจุดสิ้นสุดของมันประกอบด้วย (อาจเป็นไฟล์ Postscript เริ่มต้นด้วยห้องสมุดรวมกว่าหน้าต่างส่ง TCP)
- มันอาจมีการสอบถามสถานะ ("คุณมีกระดาษหรือไม่" ซึ่งมันสามารถดำเนินการได้อย่างชัดเจน)
- มันอาจมีคำสั่งพิมพ์ ("โปรดพิมพ์สิ่งนี้" ซึ่งมันอาจล้มเหลวถ้ากระดาษหมด)
ฉันขอแนะนำว่าหากผู้ใช้เห็นและส่ง ACKs แต่ยังคงประสบปัญหาการเชื่อมต่อเป็นลำดับความสำคัญมีความแออัดปัญหา OS หรือแอปพลิเคชันมากกว่าสิ่งที่เกี่ยวข้องกับเครือข่ายอย่างเคร่งครัด
หากต้องการวินิจฉัยฉันขอแนะนำให้ค้นหาการส่งสัญญาณซ้ำมากกว่า ACK โดยเฉพาะ