Використання TCP_DEFER_ACCEPT у реальному світі?

Я переглядав посібник Apache httpd в Інтернеті і натрапив на директиву, яка дозволяє це зробити. Знайдено опис на сторінці man для 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статусу сокета, вам все одно знадобляться чотири пакети (рукостискання, потім дані у кожному випадку). Я не знаю, як вони зменшують кількість до трьох, і як це забезпечує значне підвищення.

Отже, моє запитання в основному: це лише старий застарілий варіант, чи існує фактичний випадок використання для цього варіанту?

(підсумувати мої коментарі до ОП)

Тристороннє рукостискання, яке вони намагаються, є частиною встановлення з'єднання TCP, питання, про яке йдеться, конкретно не стосується цього. Також зауважте, що обмін даними не є частиною триходового рукостискання, це просто створює TCP-з'єднання у відкритому / встановленому стані.

Що стосується існування цієї опції, це не традиційна поведінка сокета, як правило, нитка обробника сокета пробуджується, коли з'єднання прийнято (це все-таки після завершення тривимірного рукостискання), і для деяких протоколів діяльність починається тут ( наприклад, сервер SMTP надсилає лінію привітання 220), але для HTTP першим повідомленням у бесіді є веб-браузер, який надсилає його рядок GET / POST / тощо, і поки це не стане, сервер HTTP не має інтересу до з'єднання (крім часу це), таким чином прокидання HTTP-процесу, коли прийняття сокета завершиться, є марною діяльністю, оскільки процес негайно засне знову, очікуючи необхідних даних.

Хоча, безумовно, є аргумент, що пробудження неробочих процесів може зробити їх "готовими" до подальшої обробки (я спеціально пам'ятаю, як прокидаються термінали для входу на дуже старих машинах і змушують їх замінятися від swap), але ви також можете стверджувати, що будь-яка машина, яка має замінив зазначений процес вже вимагає своїх ресурсів, а подальше подальше непотрібне запитання може загалом знизити продуктивність системи - навіть якщо очевидна продуктивність вашої індивідуальної нитки покращиться (що також не може, надзвичайно зайнята машина матиме вузькі місця на вході диска, який би сповільнюйте інші речі, якщо ви замінилися, і якщо це так зайнято, негайний сон може змінити його назад. Здається, це азартна гра, і в кінцевому підсумку «жадібна» гра не обов'язково окупається на зайнятій машині,

Моя загальна порада щодо такого рівня настройки продуктивності полягала б у тому, щоб не приймати програмних рішень про те, що все одно найкраще, а дозволити системному адміністратору та операційній системі спільно працювати над питаннями управління ресурсами - це їхня робота, і вони багато краще підходить для розуміння завантаженості всієї системи та поза нею. Надайте варіанти та параметри конфігурації.

Щоб конкретно відповісти на питання, цей варіант корисний для всіх конфігурацій, не до рівня, який ви коли-небудь могли б помітити, за винятком екстремального навантаження трафіку HTTP, але теоретично це "правильний" спосіб зробити це. Це варіант, оскільки не всі аромати Unix (навіть не всі Linux) мають таку можливість, і, таким чином, для портативності він може бути налаштований так, щоб він не включався.

Мені незрозуміло, якою перевагою буде очікування завершення тристороннього рукостискання.

Тристороння рукостискання - це звичайний протокол голосової телефонії:

1. Сервер : "Добрий день, корпорація Epiphyte".
2. Caller : "Привіт, це Ренді".
3. Сервер : "Так, як я можу вам допомогти?"
4. Caller : тіло виклику починається з проханням пожартувати

Вони важливі в TCP для забезпечення встановлення каналу. Якщо Клієнт почав надсилати телефонний дзвінок перед тим, як почути (3), є ймовірність, що Сервер не слухає або не готовий. Слух (3) не гарантує, що Сервер не зазнав негайного самозаймання після передачі, але це підвищує впевненість, що Сервер готовий приймати.

Як зазначається у Вікіпедії про рукостискання :

1. Аліса [Сервер] відповідає на повідомлення про підтвердження з номером підтвердження у + 1, яке отримує Боб [Клієнт] і на яке йому не потрібно відповідати .

Тож якщо ви готові відмовитись від певної впевненості, що сервер готовий, сервер може пропустити крок (3), і клієнт просто припустить, що сервер був готовий. Це перетворює протокол обміну вище в:

1. Сервер : "Добрий день, корпорація Epiphyte".
2. Caller : "Привіт, це Ренді".
3. Caller : "Чи знаєте ви якісь жарти щодо Імельди Маркос?"