Stavo esaminando il manuale httpd di Apache online e mi sono imbattuto in una direttiva per abilitarlo. Ho 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.
Poi ho trovato questo articolo ma non sono ancora chiaro per quale tipo di carichi di lavoro sarebbe utile. Presumo che se httpd ha un'opzione specifica per questo, deve avere una certa rilevanza per i server web. Presumo anche dal fatto che sia un'opzione e non solo come httpd fa connessioni di rete, che ci sono casi d'uso in cui lo desideri e altri in cui non lo vuoi.
Anche dopo aver letto l'articolo, non sono chiaro quale sarebbe il vantaggio di attendere il completamento della stretta di mano a tre vie. Sembrerebbe vantaggioso assicurarsi che non sia necessario sostituire il relativo httpd esempio facendo così mentre l'handshake è ancora in corso invece di causare potenzialmente quel ritardo dopo che si è formata una connessione.
Per quanto riguarda l'articolo, mi sembrerebbe anche che indipendentemente dal TCP_DEFER_ACCEPT stato di un socket, avrai comunque bisogno di quattro pacchetti (handshake e poi dati in ogni caso). Non so come riescano a portare il conto alla rovescia a tre, né come ciò fornisca un miglioramento significativo.
Quindi la mia domanda è fondamentalmente:questa è solo una vecchia opzione obsoleta o esiste un caso d'uso reale per questa opzione?
Risposta accettata:
(per riassumere i miei commenti sull'OP)
L'handshake a tre vie a cui si riferiscono fa parte della creazione 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 solo 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 del socket viene riattivato quando la connessione viene accettata (che è ancora dopo il completamento dell'handshake a tre vie), e per alcuni protocolli l'attività inizia qui ( ad esempio 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ò non accade il server HTTP non ha alcun interesse per la connessione (a parte il tempo it out), quindi riattivare il processo HTTP al completamento dell'accettazione del socket è un'attività dispendiosa poiché il processo si addormenterà immediatamente di nuovo in attesa dei dati necessari.
Sebbene vi sia certamente un argomento sul fatto che riattivare i processi inattivi possa renderli "pronti" per ulteriori elaborazioni (ricordo in particolare di aver svegliato i terminali di accesso su macchine molto vecchie e di averli inseriti dallo scambio), ma puoi anche sostenere che qualsiasi macchina che ha scambiato detto processo sta già richiedendo le 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 accadere, una macchina estremamente impegnata avrebbe colli di bottiglia sull'IO del disco che farebbero rallentare altre cose se hai effettuato lo scambio e, se è così occupato, il sonno immediato potrebbe riattivarlo). Sembra essere una scommessa, e alla fine la scommessa "avida" non paga necessariamente su una macchina occupata, e sicuramente causa lavoro extra non necessario su una macchina su cui è già stato scambiato il processo:il tuo approccio ottimizza per una macchina con un set di processi di memoria di grandi dimensioni che sono per lo più dormienti e lo scambio di una dormienza con un'altra non è un grosso problema, tuttavia una macchina con un ampio set di memoria di processi attivi soffrirà di I/O extra e qualsiasi macchina che non ha memoria limitata soffre, qualsiasi macchina legata alla CPU starà peggio.
Correlati:Linux – Perché rsync su Linux non conserva tutti i timestamp (ora di creazione)?Il mio consiglio generale in merito a quel livello di ottimizzazione delle prestazioni sarebbe di non prendere comunque decisioni programmatiche su ciò che è meglio, 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 scelte di configurazione.
Per rispondere in modo specifico alla domanda, l'opzione è vantaggiosa su tutte le configurazioni, non al livello che potresti mai notare se non sotto un carico estremo di traffico HTTP, ma in teoria è 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 configurato per non essere incline.