Wykorzystanie TCP_DEFER_ACCEPT w świecie rzeczywistym?

Przeczytałem online instrukcję Apache httpd i natknąłem się na dyrektywę, aby to umożliwić. Znaleziono opis na stronie podręcznika dla 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.

Potem znalazłem ten artykuł, ale nadal nie jestem pewien, do jakiego rodzaju obciążeń byłoby to przydatne. Zakładam, że jeśli httpdma taką opcję, musi mieć pewne znaczenie dla serwerów sieciowych. Zakładam również, że jest to opcja, a nie tylko sposób httpdpołączeń sieciowych, że istnieją przypadki użycia, w których chcesz, i inne, w których nie.

Nawet po przeczytaniu artykułu nie jestem pewien, jaka byłaby korzyść z oczekiwania na zakończenie uzgadniania trójstronnego. Wydaje się korzystne, aby upewnić się, że nie trzeba będzie zamieniać odpowiedniej httpdinstancji, robiąc to, podczas gdy uścisk dłoni wciąż trwa, zamiast potencjalnie powodować to opóźnienie po utworzeniu połączenia.

W przypadku tego artykułu wydaje mi się również, że bez względu na TCP_DEFER_ACCEPTstatus gniazda nadal będziesz potrzebować czterech pakietów (uzgadnianie, a następnie dane w każdym przypadku). Nie wiem, jak sprowadzają odliczanie do trzech, ani jak zapewnia to znaczące ulepszenie.

Więc moje pytanie jest w zasadzie: czy to tylko stara przestarzała opcja, czy istnieje rzeczywisty przypadek użycia tej opcji?

(aby streścić moje komentarze na temat PO)

Trójstronny uścisk dłoni, do którego się odnoszą, jest częścią nawiązywania połączenia TCP, przedmiotowa opcja nie odnosi się konkretnie do tego. Należy również pamiętać, że wymiana danych nie jest częścią trójstronnego uzgadniania, to po prostu tworzy połączenie TCP w stanie otwartym / ustanowionym.

Jeśli chodzi o istnienie tej opcji, nie jest to tradycyjne zachowanie gniazda, zwykle wątek obsługi gniazda jest budzony, gdy połączenie zostanie zaakceptowane (co jest nadal po zakończeniu uzgadniania trójstronnego), a dla niektórych protokołów rozpoczyna się tutaj aktywność ( np. serwer SMTP wysyła 220 powitania), ale dla HTTP pierwszą wiadomością w rozmowie jest przeglądarka internetowa wysyłająca swoją linię GET / POST / etc, i dopóki to się nie stanie, serwer HTTP nie jest zainteresowany połączeniem (poza czasem to), a więc budzenie procesu HTTP po zakończeniu akceptacji gniazda jest marnotrawstwem, ponieważ proces natychmiast zasypia w oczekiwaniu na niezbędne dane.

Chociaż z pewnością istnieje argument, że przebudzenie bezczynnych procesów może uczynić je „gotowymi” do dalszego przetwarzania (szczególnie pamiętam budzenie terminali logowania na bardzo starych komputerach i ich ładowanie z wymiany), ale można również argumentować, że każda maszyna, która ma wymieniono proces, który już stwarza wymagania dotyczące swoich zasobów, a stawianie dalszych niepotrzebnych wymagań może ogólnie obniżyć wydajność systemu - nawet jeśli widoczna wydajność twojego wątku poprawi się (co również nie musi, bardzo zajęty komputer miałby wąskie gardła na IO dysku, co by spowolnij inne rzeczy, jeśli włączysz się, a jeśli jest tak zajęty, natychmiastowy sen może zamienić go z powrotem z powrotem). To wydaje się być hazardem, a ostatecznie „chciwy” hazard niekoniecznie się opłaca na ruchliwej maszynie,

Moja ogólna rada dotycząca tego poziomu dostrajania wydajności polega na tym, aby nie podejmować programowych decyzji co do tego, co jest najlepsze, ale pozwolić administratorowi systemu i systemowi operacyjnemu współpracować w celu rozwiązania problemów związanych z zarządzaniem zasobami - to jest ich praca i jest ich wiele lepiej dostosowane do zrozumienia obciążeń całego systemu i nie tylko. Podaj opcje i opcje konfiguracji.

Aby dokładnie odpowiedzieć na pytanie, opcja ta jest korzystna we wszystkich konfiguracjach, nie do poziomu, który prawdopodobnie byś zauważył, z wyjątkiem dużego obciążenia ruchem HTTP, ale teoretycznie jest to „właściwy” sposób na zrobienie tego. Jest to opcja, ponieważ nie wszystkie wersje uniksowe (nawet wszystkie Linux) mają taką możliwość, a zatem dla przenośności można ją skonfigurować tak, aby nie była dołączona.

Nie jestem pewien, jaka byłaby korzyść z oczekiwania na zakończenie uzgadniania trójstronnego.

Uzgadnianie trójdrożne jest powszechnym protokołem w telefonii głosowej:

1. Serwer : „Dzień dobry, Epiphyte Corp.”
2. Dzwoniący : „Cześć, to jest Randy”.
3. Serwer : „Tak, w czym mogę pomóc?”
4. Dzwoniący : część połączenia zaczyna prosić o dowcip

Są one ważne w TCP dla zapewnienia ustanowienia kanału. Jeśli klient rozpoczął wysyłanie wezwania przed wysłuchaniem (3), istnieje prawdopodobieństwo, że serwer nie słucha lub nie jest gotowy. Przesłuchanie (3) nie gwarantuje, że serwer nie doznał natychmiastowego samozapłonu po transmisji, ale zwiększa pewność, że serwer jest gotowy do odbioru.

Jak wspomniano w Wikipedii na temat uzgadniania :

1. Alice [Serwer] odpowiada komunikatem z potwierdzeniem o numerze y + 1, który Bob [Klient] otrzymuje i na który nie musi odpowiadać .

Jeśli więc zechcesz zrezygnować z dodatkowej pewności, że serwer jest gotowy, serwer może pominąć krok (3), a klient po prostu przyjmie, że serwer jest gotowy. To zmienia powyższą wymianę protokołów w:

1. Serwer : „Dzień dobry, Epiphyte Corp.”
2. Dzwoniący : „Cześć, to jest Randy”.
3. Dzwoniący : „Czy znasz jakieś dowcipy na temat Imelda Marcos?”