che cos'è TCP Half Open Connection e TCP half closed connection

Sto cercando di capire qual è la differenza tra TCP Half Open Connection e TCP Half closed connection qualcuno può dire esattamente cosa sono?

Questo post si espande su connessioni semichiuse. Per le connessioni semiaperte vedi la descrizione corretta di KContreau.

Cosa sono le connessioni chiuse a metà? Oppure: non è un bug, è una caratteristica!

Ogni connessione TCP è composta da due mezze connessioni che sono chiuse indipendentemente l'una dall'altra. Quindi, se un'estremità invia un FIN, allora l'altra estremità è libera solo per ACK quel FIN (invece di FIN + ACK-ing), che segnala alla fine che invia FIN che ha ancora dei dati da inviare. Quindi entrambe le estremità finiscono in uno stato di trasferimento dati stabile diverso da ESTABLISHED, ovvero FIN_WAIT_2 (per la parte ricevente) e CLOSE_WAIT (per la parte mittente). Si dice che una connessione del genere sia semichiusa e TCP sia effettivamente progettato per supportare quegli scenari, quindi le connessioni semichiuse sono una funzionalità TCP.

La storia della connessione mezza chiusa

Mentre RFC 793 descrive solo il meccanismo grezzo senza nemmeno menzionare il termine "semichiuso", RFC 1122 approfondisce la questione nella sezione 4.2.2.13. Potresti chiederti chi diavolo ha bisogno di quella funzione. I progettisti di TCP hanno inoltre implementato TCP / IP per il sistema Unix e, come ogni utente Unix, hanno adorato il reindirizzamento I / O. Secondo W. Stevens (TCP / IP illustrato, Sezione 18.5), il desiderio di reindirizzare gli stream TCP era la motivazione per introdurre la funzione. Consente a FIN ack di assumere il ruolo o essere tradotto come EOF. Quindi è fondamentalmente una funzione che ti consente di creare casualmente un'interazione improvvisata stile richiesta / risposta sul livello dell'applicazione, dove FIN indica "fine della richiesta".

Quando TCP stabilisce una connessione, viene considerato garantito poiché si verifica una stretta di mano:

1. Il computer di avvio invia la richiesta di connessione, inviando un SYN
2. Il computer che risponde risponde alla richiesta, rispondendo con un SYN-ACK
3. Il computer di avvio invia un riconoscimento, rispondendo con un ACK

A quel punto viene stabilita la connessione e i dati iniziano a fluire. Al contrario, un pacchetto UDP non è garantito e viene semplicemente inviato nella speranza che ci arrivi.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment

Ufficialmente, secondo le RFC, una connessione TCP semiaperta si verifica quando un lato della connessione stabilita si è arrestato in modo anomalo e non ha inviato notifica del termine della connessione. Questo non è l'uso comune oggi.

Ufficiosamente, se può fare riferimento a una connessione embrionale, che è una connessione in corso di creazione.

http://en.wikipedia.org/wiki/Embryonic_connection

Semichiuso è l'opposto di quella definizione non ufficiale. È uno stato da qualche parte nel mezzo in cui i computer stanno abbattendo la connessione stabilita.

Gli altri ragazzi hanno fatto un lavoro abbastanza decente di descrivere ciò che connessioni semiaperte e mezzo chiuso in realtà sono , ma l'idea di connessioni half-open è spesso cercato nel contesto di una loro di essere un problema.

Ci sono argomenti su Internet su ciò che la terminologia "semiaperta" o "semichiusa" dovrebbe rappresentare, ma per quanto mi riguarda, la terminologia è solo semantica. Alcuni sostengono che le connessioni "semiaperte" sono un "problema", mentre "semichiuse" sono una funzionalità di progettazione che consente di chiudere il flusso di invio chiudendo il flusso di invio prima che il download del file termini in uno stato semichiuso ( come descritto dagli altri utenti).

Tuttavia, per quanto riguarda l'altro ... il "problema": ci vuole una stretta di mano a 3 vie per aprire una connessione TCP e una stretta di mano a 4 vie per chiuderla.

TCP ha una vulnerabilità in quanto il pacchetto FIN finale inviato a un client può essere potenzialmente eliminato da router / reti con conseguente connessione semiaperta quando l'intenzione effettiva era quella di chiudere completamente la connessione. Questo e altri approcci simili sono stati i tipi più diffusi di attacchi Denial of Service in quanto non richiedono molta larghezza di banda, ma potenzialmente maniglie, socket e thread preziosi a seconda dell'implementazione del server, ma possono anche accadere nel mondo reale con frequenza crescente grazie ai nostri scadenti gestori wireless.

I sistemi operativi hanno tentato di contrastare gli attacchi DDoS semiaperti limitando il numero di connessioni semiaperte / chiuse che possono essere presenti nel sistema operativo in un determinato momento e introducendo un periodo di tempo massimo in cui le connessioni possono rimanere in un stato semiaperto / chiuso. L'ultima volta che ho verificato, personalmente, tuttavia, il limite di tempo su Windows era piuttosto alto (2 giorni, se ricordo).

Questa condizione è ulteriormente aggravata dalla natura facoltativa dei keep-alive TCP, che se completamente implementati erano intesi come una soluzione a livello di protocollo (anziché a livello di applicazione) per rilevare connessioni dead / zombie. Ma, quando fu progettato TCP, la larghezza di banda era considerevolmente più preziosa di quanto non lo sia ora, e c'erano timori che i timer mandadory keep-alive per TCP sarebbero troppo "chiacchieroni". Pertanto i keep-alive sono opzionali, non generalmente utilizzati e non sono garantiti per essere trasmessi dai router secondo RFC1122. Quindi ... anche se attivi keep-alive a livello TCP nel tentativo di rilevare / gestire lo scenario, potresti scoprire che mentre il tuo traffico viaggia in tutto il mondo, alcuni router rilasciano i pacchetti keep-alive ... creando potenzialmente UN ALTRO scenario raro da testare.

Le connessioni semiaperte rappresentano una sfida ingegneristica per i programmatori che scrivono server basati su TCP, in particolare perché possono apparire involontariamente in modo casuale, durante i periodi di carico elevato ... e in genere sui server di produzione ... e possono essere difficile da notare nelle fasi di test Alpha / Beta. Nella mia esperienza, ho scoperto che si verificano forse in 1 su 40.000 connessioni su server che gestiscono 2,5 milioni di connessioni / giorno, ma quei numeri varieranno a seconda delle condizioni del traffico e delle condizioni del traffico di ogni tratto di Internet tra il server e il client .

Come ingegnere, può essere difficile rintracciare i problemi che si verificano raramente e solo su server distribuiti in tempo reale, quindi è importante provare a simulare questo raro stato di connessione quando si scrive il codice del server TCP per analizzare come reagirà il server quando di fronte a questa situazione. Se il tuo server TCP utilizza un numero statico di thread di lavoro, ad esempio, potresti trovarli tutti consumati dalle connessioni zombie durante la distribuzione in produzione, ad esempio. Se le connessioni richiedono molta memoria di lavoro, il risultato finale potrebbe apparire simile a una perdita di memoria. ecc ecc.

Senza una soluzione keep-alive praticabile al 100% TCP lascia al livello utente la determinazione della modalità di gestione delle connessioni semiaperte / chiuse, pertanto il codice deve disporre di un piano / meccanismo per rilevare, timeout e clean- risorse quando si verifica questa condizione ... ovvero ... supponendo che questo sia un protocollo inventato e non uno dei tanti (cattivi) standard aperti che i programmatori utilizzano in genere. Ovviamente mi riferisco a protocolli come HTTP, che funzionano esclusivamente su TCP. Questi protocolli sono estremamente sopravvalutati secondo l'opinione di questo programmatore.

Riconoscendo i punti deboli di TCP e la sua sfortunata popolarità per la trasmissione del traffico HTTP / Web, le aziende intelligenti hanno cercato di cercare un sostituto. Ad esempio, Google ha sperimentato un protocollo chiamato QUIC, che trasmette HTTP su UDP. C'è anche un protocollo aperto chiamato TSCP. Nessuno di questi protocolli ha comunque visto un'ampia adozione.

Di norma, costruisco tutti i miei server per parlare esclusivamente sul mio protocollo basato su UDP. UDP è più complicato di quanto si possa pensare, tuttavia, e mi sembra di modificarlo sempre per renderlo più veloce, più intelligente, a bassa latenza, a congestione inferiore ... ma almeno non devo più fare i conti con connessioni aperte a metà; )

Migliore spiegazione della terminazione della connessione TCP

Nel processo di handshake a 3 vie TCP abbiamo studiato come stabilire la connessione tra client e server in TCP (Transmission Control Protocol) utilizzando segmenti di bit SYN. In questo articolo studieremo il modo in cui TCP chiude la connessione tra client e server. Qui dovremo anche inviare segmenti di bit al server il cui bit FIN è impostato su 1.

11

Come funziona il meccanismo in TCP:

Step 1 (FIN From Client) – Suppose that the client application decides it wants to close the connection. (Note that the server could also choose to close the connection). This causes the client send a TCP segment with the FIN bit set to 1 to server and to enter the FIN_WAIT_1 state. While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment (ACK).
Step 2 (ACK From Server) – When Server received FIN bit segment from Sender (Client), Server Immediately send acknowledgement (ACK) segment to the Sender (Client).
Step 3 (Client waiting) – While in the FIN_WAIT_1 state, the client waits for a TCP segment from the server with an acknowledgment. When it receives this segment, the client enters the FIN_WAIT_2 state. While in the FIN_WAIT_2 state, the client waits for another segment from the server with the FIN bit set to 1.
Step 4 (FIN from Server) – Server sends FIN bit segment to the Sender(Client) after some time when Server send the ACK segment (because of some closing process in the Server).
Step 5 (ACK from Client) – When Client receive FIN bit segment from the Server, the client acknowledges the server’s segment and enters the TIME_WAIT state. The TIME_WAIT state lets the client resend the final acknowledgment in case the ACK is lost.The time spent by client in the TIME_WAIT state is depend on their implementation, but their typical values are 30 seconds, 1 minute, and 2 minutes. After the wait, the connection formally closes and all resources on the client side (including port numbers and buffer data) are released.

altro su: https://www.geeksforgeeks.org/tcp-connection-termination/

La connessione semi chiusa è un processo che viene stabilito quando un'estremità del server e il Cliente intendono terminare la connessione. TCP è un processo orientato alla connessione, quindi ogni socket viene aperto per una particolare applicazione. In TCP non esiste alcuna pressione per la chiusura dell'applicazione. Pertanto, il processo orientato alla connessione prolunga la terminazione con segnali di attesa. questo si chiama mezzo chiuso in TCP (connessione)