Uso nel mondo reale di TCP_DEFER_ACCEPT?

Stavo esaminando il manuale httpd di Apache online e mi sono imbattuto in una direttiva per abilitare questo. Trovato una descrizione nella pagina man per 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.

Quindi ho trovato questo articolo, ma non sono ancora chiaro per quale tipo di carichi di lavoro sarebbe utile. Suppongo che se httpdha un'opzione specifica per questo, deve avere una certa rilevanza per i server Web. Suppongo anche che sia un'opzione e non solo httpdle connessioni di rete, che ci sono casi d'uso in cui lo si desidera e altri in cui non lo si desidera.

Anche dopo aver letto l'articolo, non sono chiaro quale sarebbe il vantaggio di aspettare il completamento della stretta di mano a tre vie. Sembrerebbe vantaggioso assicurarsi che non sarà necessario scambiare l' httpdistanza pertinente facendo ciò mentre l'handshake è ancora in corso invece di causare potenzialmente quel ritardo dopo che si è formata una connessione.

Per l'articolo, mi sembra anche che, indipendentemente dallo TCP_DEFER_ACCEPTstato di un socket, avrai ancora bisogno di quattro pacchetti (stretta di mano e dati in ciascun caso). Non so come ottengano il conteggio fino a tre, né come ciò fornisca un miglioramento significativo.

Quindi la mia domanda è fondamentalmente: è solo una vecchia opzione obsoleta o esiste un caso d'uso reale per questa opzione?

(per riassumere i miei commenti sul PO)

L'handshake a tre vie a cui si riferiscono fa parte dell'istituzione della connessione TCP, l'opzione in questione non si riferisce specificamente a questo. Si noti inoltre che lo scambio di dati non fa parte dell'handshake a tre vie, questo crea semplicemente la connessione TCP nello stato aperto / stabilito.

Per quanto riguarda l'esistenza di questa opzione, questo non è il comportamento tradizionale di un socket, normalmente il thread del gestore socket viene svegliato quando viene accettata la connessione (che è ancora dopo il completamento dell'handshake a tre vie), e per alcuni protocolli l'attività inizia qui ( ad es. un server SMTP invia una linea di saluto 220), ma per HTTP il primo messaggio nella conversazione è il browser Web che invia la sua linea GET / POST / etc, e fino a quando ciò accade il server HTTP non ha alcun interesse per la connessione (diverso dai tempi ), quindi riattivare il processo HTTP quando il socket accetta è un'attività dispendiosa poiché il processo si riaddormenterà immediatamente in attesa dei dati necessari.

Sebbene vi sia certamente argomento secondo cui il risveglio dei processi inattivi può renderli "pronti" per ulteriori elaborazioni (ricordo in particolare di aver svegliato i terminali di accesso su macchine molto vecchie e di averli collegati da swap), ma puoi anche sostenere che qualsiasi macchina che ha scambiato detto processo sta già facendo richieste sulle sue risorse e fare ulteriori richieste non necessarie potrebbe ridurre complessivamente le prestazioni del sistema - anche se le prestazioni apparenti del singolo thread migliorano (cosa che potrebbe anche non fare, una macchina estremamente occupata avrebbe colli di bottiglia sul disco IO che rallenta altre cose se ti sei scambiato, e se è così occupato, il sonno immediato potrebbe scambiarlo immediatamente. Sembra una scommessa, e alla fine la scommessa "avida" non paga necessariamente su una macchina occupata,

Il mio consiglio generale riguardo a quel livello di ottimizzazione delle prestazioni sarebbe di non prendere decisioni programmatiche su ciò che è meglio comunque, ma di consentire all'amministratore di sistema e al sistema operativo di lavorare insieme per affrontare i problemi di gestione delle risorse - questo è il loro lavoro e sono molto più adatto a comprendere i carichi di lavoro dell'intero sistema e oltre. Fornisci opzioni e opzioni di configurazione.

Per rispondere in modo specifico alla domanda, l'opzione è vantaggiosa su tutte le configurazioni, non al livello che probabilmente noteresti, tranne che sotto un carico estremo di traffico HTTP, ma è teoricamente il modo "giusto" per farlo. È un'opzione perché non tutte le versioni Unix (nemmeno tutte Linux) hanno questa capacità, e quindi per la portabilità può essere configurata per non essere inclusa.

Non sono chiaro quale sarebbe il vantaggio di attendere il completamento della stretta di mano a tre vie.

Le strette di mano a tre vie sono un protocollo comune nella telefonia vocale:

1. Server : "Buon pomeriggio, Epiphyte Corp."
2. Caller : "Ciao, sono Randy."
3. Server : "Sì, come posso aiutarti?"
4. Chiamante : il corpo della chiamata inizia a richiedere uno scherzo

Sono importanti in TCP per garantire che il canale sia stabilito. Se il client ha iniziato a inviare il corpo della chiamata prima di ascoltare (3) è possibile che il server non ascolti o non sia pronto. L'udito (3) non garantisce che il Server non abbia subito subito la combustione spontanea dopo la trasmissione, ma aumenta la sicurezza che il Server è pronto a ricevere.

Come notato in Wikipedia sull'handshaking :

1. Alice [Server] risponde con un messaggio di riconoscimento con il numero di riconoscimento y + 1, che Bob [Client] riceve e al quale non ha bisogno di rispondere .

Quindi, se si è disposti a rinunciare a un po 'più di certezza sul fatto che il server sia pronto, Server può saltare il passaggio (3) e il client supporrà semplicemente che il server fosse pronto. Ciò trasforma lo scambio di protocollo sopra in:

1. Server : "Buon pomeriggio, Epiphyte Corp."
2. Caller : "Ciao, sono Randy."
3. Caller : "Conosci qualche battuta su Imelda Marcos?"