ใช้งานจริงของ TCP_DEFER_ACCEPT หรือไม่

ฉันอ่านคู่มือ httpd ของ Apache ออนไลน์และพบกับคำสั่งสำหรับการเปิดใช้งานนี้ พบคำอธิบายในหน้าคนสำหรับtcp:

   TCP_DEFER_ACCEPT (since Linux 2.4)
          Allow a listener to be awakened only when data arrives on the
          socket.  Takes an integer value (seconds), this can bound the
          maximum number of attempts TCP will make to complete the
          connection.  This option should not be used in code intended
          to be portable.

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

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

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

ดังนั้นคำถามของฉันก็คือ: นี่เป็นเพียงตัวเลือกที่ล้าสมัยหรือมีกรณีการใช้งานจริงสำหรับตัวเลือกนี้หรือไม่?

(เพื่อสรุปความคิดเห็นของฉันเกี่ยวกับ OP)

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

เกี่ยวกับการดำรงอยู่ของตัวเลือกนี้นี่ไม่ใช่พฤติกรรมดั้งเดิมของซ็อกเก็ตโดยปกติเธรดของตัวจัดการซ็อกเก็ตจะตื่นขึ้นเมื่อการเชื่อมต่อได้รับการยอมรับ (ซึ่งยังคงอยู่หลังจากการจับมือทั้งสามทางเสร็จสมบูรณ์) เช่นเซิร์ฟเวอร์ SMTP ส่งข้อความทักทาย 220 บรรทัด แต่สำหรับ HTTP ข้อความแรกในการสนทนาคือเว็บเบราว์เซอร์ส่งบรรทัด GET / POST / etc และจนกระทั่งเกิดเหตุการณ์นี้เซิร์ฟเวอร์ HTTP จะไม่สนใจการเชื่อมต่อ (นอกเหนือจากเวลา) ออก) ดังนั้นการปลุกกระบวนการ HTTP เมื่อซ็อกเก็ตยอมรับเสร็จสมบูรณ์เป็นกิจกรรมที่สิ้นเปลืองเนื่องจากกระบวนการจะเผลอหลับอีกครั้งโดยทันทีเพื่อรอข้อมูลที่จำเป็น

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

คำแนะนำทั่วไปของฉันเกี่ยวกับการปรับแต่งระดับนั้นจะไม่ทำการตัดสินใจเชิงโปรแกรมเกี่ยวกับสิ่งที่ดีที่สุดอยู่แล้ว แต่เพื่ออนุญาตให้ผู้ดูแลระบบและระบบปฏิบัติการทำงานร่วมกันเพื่อจัดการกับปัญหาการจัดการทรัพยากร - นั่นคืองานของพวกเขา เหมาะสำหรับการทำความเข้าใจปริมาณงานของทั้งระบบและอื่น ๆ ให้ตัวเลือกและตัวเลือกการกำหนดค่า

ในการตอบคำถามโดยเฉพาะตัวเลือกนี้มีประโยชน์สำหรับการกำหนดค่าทั้งหมดไม่ใช่ระดับที่คุณอาจสังเกตเห็นยกเว้นภายใต้ปริมาณการรับส่งข้อมูล HTTP จำนวนมาก แต่เป็นวิธีที่ "ถูกต้อง" ในทางทฤษฎี มันเป็นตัวเลือกเพราะไม่ใช่ทุก Unix (ไม่ใช่แม้แต่ลีนุกซ์ทุกตัว) รสชาติมีความสามารถนั้นและเพื่อความสะดวกในการพกพาสามารถกำหนดค่าไม่ให้เอียง

ฉันไม่ชัดเจนว่าประโยชน์ที่จะรอให้การจับมือทั้งสามทางเสร็จสมบูรณ์จะเป็นอย่างไร

Handshakes สามทางเป็นโปรโตคอลทั่วไปในระบบโทรศัพท์:

1. เซิร์ฟเวอร์ : "สวัสดีตอนเย็น, Epiphyte Corp. "
2. ผู้โทร : "สวัสดีนี่คือแรนดี้"
3. เซิร์ฟเวอร์ : "ใช่ฉันจะช่วยคุณได้อย่างไร"
4. ผู้โทร : ร่างกายของการโทรเริ่มร้องขอเรื่องตลก

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

ตามที่ระบุไว้ในWikipedia เกี่ยวกับการจับมือกัน :

1. อลิซ [เซิร์ฟเวอร์] ตอบกลับพร้อมข้อความตอบรับพร้อมหมายเลขตอบรับ y + 1 ซึ่ง Bob [ลูกค้า] ได้รับและตอบกลับโดยไม่จำเป็นต้องตอบกลับ

ดังนั้นหากคุณยินดีที่จะละทิ้งความมั่นใจเพิ่มเล็กน้อยที่เซิร์ฟเวอร์พร้อมเซิร์ฟเวอร์สามารถข้ามขั้นตอน (3) และไคลเอนต์จะสันนิษฐานว่าเซิร์ฟเวอร์พร้อมแล้ว สิ่งนี้จะเปลี่ยนการแลกเปลี่ยนโปรโตคอลด้านบนเป็น:

1. เซิร์ฟเวอร์ : "สวัสดีตอนเย็น, Epiphyte Corp. "
2. ผู้โทร : "สวัสดีนี่คือแรนดี้"
3. ผู้โทร : "คุณรู้จักเรื่องตลกเกี่ยวกับ Imelda Marcos บ้างไหม"