การเชื่อมต่อ TCP Half Open Open และการเชื่อมต่อ TCP ครึ่งปิดคืออะไร

ฉันพยายามที่จะเข้าใจความแตกต่างระหว่างการเชื่อมต่อ TCP Half Open และการเชื่อมต่อปิด TCP ครึ่งใครสามารถบอกได้ว่าพวกเขาคืออะไร?

โพสต์นี้จะขยายการเชื่อมต่อปิดครึ่ง สำหรับการเชื่อมต่อที่เปิดครึ่งดูคำอธิบายที่ถูกต้องของ KContreau

การเชื่อมต่อแบบปิดครึ่งคืออะไร หรือ: ไม่ใช่ข้อผิดพลาด - เป็นคุณสมบัติ!

การเชื่อมต่อ TCP ทุกครั้งประกอบด้วยการเชื่อมต่อครึ่งหนึ่งสองครั้งซึ่งปิดอย่างเป็นอิสระจากกัน ดังนั้นหากปลายด้านหนึ่งส่ง FIN ส่วนปลายอีกด้านนั้นว่างที่ ACK นั้น FIN (แทนที่จะเป็น FIN + ACK-ing) ซึ่งส่งสัญญาณปลาย FIN-send ที่ยังคงมีข้อมูลที่จะส่ง ดังนั้นทั้งสองจบลงในสถานะการถ่ายโอนข้อมูลที่มั่นคงนอกเหนือจาก ESTABLISHED - คือ FIN_WAIT_2 (สำหรับปลายทางที่ได้รับ) และ CLOSE_WAIT (สำหรับปลายทางที่ส่ง) การเชื่อมต่อดังกล่าวถูกปิดลงครึ่งหนึ่งและ TCP ได้รับการออกแบบมาเพื่อรองรับสถานการณ์เหล่านั้นดังนั้นการเชื่อมต่อที่ปิดครึ่งหนึ่งจึงเป็นคุณสมบัติ TCP

ประวัติความเป็นมาของการเชื่อมต่อครึ่งปิด

ในขณะที่ RFC 793 อธิบายกลไกดิบโดยไม่พูดถึงคำว่า "ปิดครึ่ง" RFC 1122 จะอธิบายรายละเอียดในหัวข้อ 4.2.2.13 คุณอาจสงสัยว่าใครต้องการคุณสมบัตินี้ นักออกแบบของ TCP ยังใช้ TCP / IP สำหรับระบบ Unix และเช่นเดียวกับผู้ใช้ Unix ทุกคนชอบการเปลี่ยนเส้นทาง I / O ตามที่ W. Stevens (ภาพประกอบ TCP / IP ส่วนที่ 18.5) ความปรารถนาที่จะ I / O-redirect TCP stream เป็นแรงจูงใจที่จะแนะนำคุณสมบัติดังกล่าว อนุญาตให้ FIN ack รับบทบาทหรือแปลเป็น EOF ดังนั้นจึงเป็นคุณสมบัติที่ช่วยให้คุณสามารถสร้างการโต้ตอบ / การตอบสนองสไตล์การตอบสนองแบบไม่เจาะจงบนชั้นแอปพลิเคชันโดยที่สัญญาณ FIN "จบการร้องขอ"

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

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

อย่างไรก็ตามเกี่ยวกับส่วนอื่น ๆ ... "ปัญหา": ใช้การจับมือ 3 ทางเพื่อเปิดการเชื่อมต่อ TCP และการจับมือแบบ 4 ทิศทางเพื่อปิด

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

ระบบปฏิบัติการพยายามต่อสู้กับการโจมตีแบบ DDoS แบบครึ่งๆโดย จำกัด จำนวนการเชื่อมต่อแบบครึ่งทางเปิด / ปิดที่สามารถปรากฏในระบบปฏิบัติการตามเวลาที่กำหนดและแนะนำความยาวสูงสุดของเวลาที่การเชื่อมต่อสามารถอยู่ใน สถานะครึ่งเปิด / ปิด ครั้งล่าสุดที่ฉันตรวจสอบเป็นการส่วนตัวอย่างไรก็ตามเวลาบน Windows ค่อนข้างสูง (2 วันถ้าฉันจำได้)

เงื่อนไขนี้ยิ่งทำให้รุนแรงขึ้นด้วยลักษณะที่เป็นทางเลือกของ TCP keep-alives ซึ่งหากดำเนินการอย่างเต็มรูปแบบนั้นมีจุดประสงค์เพื่อแก้ปัญหาระดับโปรโตคอล (เมื่อเทียบกับระดับแอปพลิเคชัน) เพื่อตรวจหาการเชื่อมต่อที่ตาย / ซอมบี้ แต่เมื่อมีการออกแบบ TCP แบนด์วิดท์ก็มีค่ามากกว่าตอนนี้และมีความกังวลว่าตัวจับเวลาแบบเก็บรักษาไว้สำหรับ TCP จะเป็น "ช่างพูด" ดังนั้น Keep-alives จึงเป็นทางเลือกไม่ได้ใช้โดยทั่วไปและไม่รับประกันว่าจะถูกส่งโดยเราเตอร์ตาม RFC1122 ดังนั้น ... แม้ว่าคุณจะเปิดใช้งาน Keep-alives ที่เลเยอร์ TCP ในความพยายามที่จะตรวจจับ / จัดการสถานการณ์คุณอาจพบว่าเมื่อปริมาณการใช้งานของคุณเดินทางไปทั่วโลกเราเตอร์บางตัวก็ทิ้งแพ็กเก็ต Keep-alive ... อาจเป็นอีกสถานการณ์ที่หาได้ยากในการทดสอบ

การเชื่อมต่อแบบ Half-Open ก่อให้เกิดความท้าทายด้านวิศวกรรมเล็กน้อยสำหรับนักเขียนโค๊ดที่เขียนเซิร์ฟเวอร์ที่ใช้ TCP โดยเฉพาะอย่างยิ่งเพราะพวกเขาสามารถปรากฏแบบสุ่มโดยไม่ได้ตั้งใจในช่วงเวลาที่มีโหลดสูง ... และโดยทั่วไปบนเซิร์ฟเวอร์ที่ใช้งาน ... สังเกตเห็นได้ยากในขั้นตอนการทดสอบอัลฟ่า / เบต้า จากประสบการณ์ของฉันฉันพบว่าพวกเขาอาจเกิด 1 ใน 40,000 การเชื่อมต่อบนเซิร์ฟเวอร์ที่จัดการการเชื่อมต่อ 2.5million / วัน แต่ตัวเลขเหล่านั้นจะแตกต่างกันไปขึ้นอยู่กับสภาพการจราจรของคุณและสภาพการจราจรของอินเทอร์เน็ตทุกขาระหว่างเซิร์ฟเวอร์ของคุณและไคลเอนต์ .

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

หากไม่มีโซลูชัน Keep-alive ที่ใช้งานได้ 100% จะปล่อยให้มันขึ้นอยู่กับเลเยอร์ผู้ใช้เพื่อกำหนดวิธีจัดการการเชื่อมต่อแบบครึ่งทางเปิด / ปิดดังนั้นรหัสของคุณจะต้องมีแผน / กลไกในการตรวจจับการหมดเวลาและ ตั้งค่าทรัพยากรเมื่อเงื่อนไขนี้เกิดขึ้น ... นั่นคือ ... สมมติว่านี่เป็นโปรโตคอลที่คุณคิดค้นขึ้นและไม่ใช่หนึ่งในมาตรฐานเปิด (เลว) มากมายที่โปรแกรมเมอร์มักจะใช้ แน่นอนฉันหมายถึงโปรโตคอลเช่น HTTP ซึ่งทำงานเฉพาะผ่าน TCP โปรโตคอลเหล่านี้ overrated อย่างมากในความเห็นของโปรแกรมเมอร์นี้

เมื่อตระหนักถึงจุดอ่อนของ TCP และความนิยมที่โชคร้ายในการส่งทราฟฟิก HTTP / Web บริษัท สมาร์ทจึงพยายามหาทางทดแทน ตัวอย่างเช่น Google ทดลองกับโปรโตคอลที่เรียกว่า QUIC ซึ่งส่ง HTTP ผ่าน UDP นอกจากนี้ยังมีโปรโตคอลเปิดที่เรียกว่า TSCP ไม่มีโพรโทคอลเหล่านั้นที่เห็นการยอมรับอย่างกว้างขวาง

ตามกฎแล้วฉันสร้างเซิร์ฟเวอร์ของตัวเองทั้งหมดเพื่อพูดคุยเฉพาะในโปรโตคอลที่ใช้ UDP ของฉันเอง UDP นั้นยากกว่าที่คุณคิดและฉันก็รู้สึกว่าฉันกำลังปรับมันให้เร็วขึ้นฉลาดขึ้นลดความแออัดลดความแออัด ... แต่อย่างน้อยฉันก็ไม่ต้องจัดการกับการเชื่อมต่อแบบเปิดครึ่ง )

เมื่อ TCP สร้างการเชื่อมต่อจะถือว่ามีการรับประกันเนื่องจากมีการจับมือกันเกิดขึ้น:

1. คอมพิวเตอร์ที่เริ่มต้นส่งการร้องขอการเชื่อมต่อส่ง SYN
2. คอมพิวเตอร์ที่ตอบสนองจะได้รับคำขอโดยตอบกลับด้วย SYN-ACK
3. คอมพิวเตอร์ที่เริ่มต้นส่งการตอบรับตอบกลับด้วย ACK

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

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

ตามอย่างเป็นทางการตาม RFC ของการเชื่อมต่อ TCP ครึ่งเปิดคือเมื่อด้านหนึ่งของการเชื่อมต่อที่จัดตั้งขึ้นได้ล้มเหลวและไม่ได้ส่งการแจ้งเตือนว่าการเชื่อมต่อจะสิ้นสุดลง นี่ไม่ใช่การใช้งานทั่วไปวันนี้

อย่างไม่เป็นทางการหากสามารถอ้างถึงการเชื่อมต่อของตัวอ่อนซึ่งเป็นการเชื่อมต่อในกระบวนการของการจัดตั้ง

http://en.wikipedia.org/wiki/Embryonic_connection

ครึ่งปิดเป็นสิ่งที่ตรงกันข้ามกับคำนิยามที่ไม่เป็นทางการ เป็นรัฐที่อยู่ตรงกลางที่คอมพิวเตอร์ขาดการเชื่อมต่อที่สร้างไว้แล้ว

การอธิบายที่ดีที่สุดของการยกเลิกการเชื่อมต่อ TCP

ในกระบวนการจับมือ 3-TCP เราศึกษาว่าการเชื่อมต่อสร้างขึ้นระหว่างไคลเอนต์และเซิร์ฟเวอร์ใน Transmission Control Protocol (TCP) โดยใช้เซ็กเมนต์บิตซิง ในบทความนี้เราจะศึกษาเกี่ยวกับวิธีการปิดการเชื่อมต่อ TCP ระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ ที่นี่เราจะต้องส่งบิตเซกเมนต์ไปยังเซิร์ฟเวอร์ซึ่ง FIN บิตถูกตั้งค่าเป็น 1

11

กลไกทำงานอย่างไรใน TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

เพิ่มเติมเกี่ยวกับ: https://www.geeksforgeeks.org/tcp-connection-termination/

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