Un host crea un thread separato per ogni richiesta TCP SYN? Oppure dipende dall'implementazione del socket per l'host?
Ad eccezione degli stack di rete dello spazio utente, il sistema operativo gestisce completamente l'handshake TCP completo nel kernel e notifica l'applicazione solo dopo aver stabilito completamente la connessione. La parte del kernel è gestita in un modo leggero, cioè di solito non ci sono thread del kernel coinvolti. Cosa succede nello spazio utente dopo che la connessione è stata stabilita dipende dall'applicazione. Alcune applicazioni creano un nuovo thread o un nuovo processo per ogni nuova connessione mentre altri lo gestiscono all'interno dello stesso thread e processo.
Il modo in cui uno stack di rete gestisce più connessioni è assolutamente specifico del sistema operativo. In effetti, è anche specifico per l'hardware di rete, in quanto le schede di rete migliori possono gestire molto il TCP stesso.
Non si può quindi, di solito, assumere che uno stack di rete sia intrinsecamente multithreading o meno - da un punto di vista logico di flusso puro, una scheda di rete ottiene ed elabora un pacchetto Ethernet dopo l'altro, e quindi, è sempre possibile elaborare loro sequenzialmente nel software.
Tuttavia, potrebbe essere vantaggi (principalmente: essere in grado di suddividere il carico di lavoro tra i core della CPU) per far sì che il sistema operativo gestisca il networking in un modo multithread. Nota che questa discussione probabilmente non ha la forma di thread di user-land come probabilmente li conosci, ma di attività del sistema operativo; ma non vi è alcuna garanzia che la gestione TCP per le connessioni esistenti non venga eseguita nello spazio utente nel contesto del processo che sta utilizzando un socket. È una decisione di progettazione del sistema operativo.
D'altra parte, ci sono buone ragioni per non networking multithread, specialmente in situazioni di basso carico o quando c'è un solo ricevitore o mittente dominante di pacchetti nello spazio utente (principalmente: la sincronizzazione è difficile , e quindi, spesso più costoso di un semplice parsing di un'intestazione TCP, e si perderebbe effettivamente più di quanto si vince quando si decide quale core della CPU dovrebbe gestire un pacchetto dopo che un core lo ha già toccato). Anche in questo caso, spesso viene risolto in modo molto adattivo dai sistemi operativi o dalle schede di rete di fascia alta, anche nell'hardware che può essere detto di trasferire il contenuto dei pacchetti in aree di memoria diverse e quindi consentire a determinati tipi di traffico di essere "appiccicosi" a un core specifico.
Poiché questa è la sicurezza delle informazioni SE e hai implicato l'argomento di DDOS: tutto è altamente adattivo. Ma si può presumere che il controllo dello stato nei moderni sistemi operativi possa essere fatto praticamente prima che arrivi il successivo interrupt della scheda di rete, e quindi, la gestione / generazione di pacchetti SYN-ACK può essere effettuata normalmente ad es. un ciclo di eventi principale o in attività di lavoro.
SYN flooding era un metodo efficace circa 20 anni fa. Semplicemente non so se è ancora così: le macchine moderne non si preoccupano solo quando la tabella delle connessioni che devono gestire in uno stato SYN-ma-non-ancora-ACK colpisce diverse centinaia di kilobyte (gaaasp!). Certo, cercare le poche% di% di richieste di clienti legittimi potrebbe richiedere centinaia di nanosecondi o anche diversi microsecondi in un formato di memorizzazione dei dati efficiente a metà per gli scenari di attacco in cui l'attaccante non ha ottenuto una corsia da 10 Gbit / s sul server ... La mia impressione è che un laptop mediocre in questi giorni sia in grado di fare firewalling (almeno con il conntrack predefinito di Linux), di gestire NAT e TCP alla massima velocità di 1 Gbit / s senza sovraccaricare il sudore. Saturare queste funzionalità con le voci su una tabella noiosa di connessioni semiaperte sarà piuttosto difficile.