le mie informazioni di contatto
Posta[email protected]
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
Il protocollo TCP ha le caratteristiche di connessione, trasmissione affidabile, orientato al flusso di byte, full-duplex, ecc. La trasmissione affidabile ne è la parte principale.
Figura 1
La figura sopra è la struttura dell'intestazione TCP.
(1) La porta di origine e la porta di destinazione non hanno bisogno di essere introdotte troppo. Sono i programmi utilizzati per indicare l'estremità di invio e quella di ricezione.
(2) Il numero di sequenza e il numero di sequenza di conferma vengono utilizzati per il meccanismo di risposta di conferma in TCP introdotto successivamente.
(3) I 4 bit nella parte di offset dei dati vengono effettivamente utilizzati per indicare la lunghezza dell'intestazione TCP qui. A causa dei 4 bit, il numero massimo rappresentato è 15, ma poiché l'unità è di 4 byte, la lunghezza massima del file. L'intestazione TCP è di 60 byte.
(4) Sappiamo tutti che la lunghezza massima dei pacchetti di dati UDP è 64kb, che è molto limitata, quindi per evitare questa situazione, nell'intestazione TCP vengono forniti 6 bit riservati, che possono essere utilizzati se la funzione TCP viene espansa successivamente. Rappresentato utilizzando bit riservati.
(5) L'identificatore inglese a 6 byte è correlato al meccanismo TCP introdotto successivamente e non verrà introdotto qui.
(6) La checksum ha la stessa funzione della checksum in UDP e viene utilizzata anche per verificare se i dati sono cambiati durante il processo di trasmissione.
(7) La finestra verrà discussa più avanti quando verrà introdotto il meccanismo.
(8) Il puntatore di emergenza verrà introdotto più avanti.
(9) Tra gli optional sono presenti alcuni optional/opzionali.
Il protocollo TCP deve risolvere un problema molto importante: la trasmissione affidabile. La cosiddetta trasmissione affidabile non significa che il mittente possa inviare i dati al destinatario al 100%, ma farà del suo meglio per far sapere al mittente se il destinatario lo sa.
figura 2
Come mostrato nella Figura 2, ogni volta che invii un messaggio alla dea, la dea ti invierà un messaggio. Questa è la risposta. Questo è anche il caso in TCP. Il client invia un pacchetto di dati e il server lo farà restituire un pacchetto di dati di risposta In questo momento, i dati di risposta Il flag ACK del pacchetto nella Figura 1 sarà impostato su 1.
immagine 3
Come mostrato nella Figura 3, quando inviamo più messaggi alla dea, poiché la dea risponde ai messaggi a velocità diverse, è facile per noi confonderci. Penseremo che la dea accetti di essere la mia ragazza la dea dice di perdersi. Questa è Internet Il problema dell'ultimo arrivato, primo servito esiste oggettivamente in Cina. Ovviamente inviando più pacchetti di dati al client e rispondendo il client a pacchetti di dati a risposta multipla, dobbiamo anche distinguere quale risposta corrisponde a quale pacchetto di dati è stato inviato. Questo problema può essere risolto utilizzando il numero di sequenza e il numero di sequenza di conferma nella Figura 1 .
Ogni pacchetto di dati inviato ha un numero di sequenza, ma non esiste un numero di sequenza di conferma oppure il campo del numero di sequenza di conferma non è valido. L'ACK del pacchetto di dati che risponde è 1. In questo momento, il campo del numero di sequenza di conferma è valido. e il numero di sequenza e risposta del pacchetto di dati inviato I numeri di sequenza di conferma dei pacchetti di dati sono corrispondenti, in modo che sia possibile distinguere chi ha risposto a chi e il problema dell'ultimo arrivato, primo servito nella rete può essere risolto sopra .
Il numero di sequenza del pacchetto dati TCP effettivo è numerato in base ai byte A ogni byte verrà assegnato un numero di sequenza. Il valore del numero di sequenza nell'intestazione TCP è il numero del primo byte nel payload, ad esempio il numero del primo byte nella parte del payload. Un numero di byte è 1 e la lunghezza del payload è 1000 byte, quindi il numero di sequenza di riconoscimento nell'intestazione del pacchetto di dati di risposta è 1001. Questo perché il numero di sequenza di riconoscimento del il pacchetto di dati di risposta corrispondente al pacchetto di dati è impostato su Il numero dell'ultimo byte del payload viene aumentato di 1. In effetti, questo è più facile da capire Restituire 1001 significa che il payload di 1000 byte inviato è stato ricevuto e il vengono richiesti i dati dopo il 1001, come mostrato nella Figura 4.
Figura 4
Per i successivi pacchetti di dati inviati, il numero di sequenza viene incrementato, ma una cosa da notare è che, sebbene venga incrementato, il numero di sequenza non inizia da 0 o 1.
Una trasmissione affidabile può essere ottenuta principalmente facendo affidamento sul meccanismo della "risposta di conferma". Può dire al mittente attraverso il messaggio di risposta se tutto sta andando bene e se si verifica una perdita di pacchetti. Cosa fare se si verifica una perdita di pacchetti (i dati vengono persi durante il processo di trasmissione e non possono raggiungere l'estremità opposta, un evento casuale oggettivo)?
La ritrasmissione del timeout viene utilizzata per gestire i problemi di perdita di pacchetti nella rete.
In questo caso le situazioni sono principalmente due:
(1) I pacchetti di dati trasmessi vengono persi
A questo punto, B non invierà un pacchetto di risposta se non riceve il pacchetto di dati di A. Quando l'evento che A attende supera una determinata soglia, determinerà che si è verificato un problema di perdita di pacchetto e ritrasmetterà il pacchetto di dati.
(2) Il pacchetto di dati di risposta è andato perso
Quando A non riceve il pacchetto di dati di risposta, ritrasmette comunque un pacchetto di dati, ma in questo momento B ha ricevuto un pacchetto di dati. Con la ritrasmissione del pacchetto di dati, riceverà due pacchetti di dati identici. Questo non è scientifico , soprattutto per questioni come i trasferimenti, in cui si verificheranno trasferimenti ripetuti.
Per i problemi di cui sopra, il ricevitore TCP deduplicherà i dati ricevuti in base al numero di sequenza. Il livello TCP non si preoccupa del problema della duplicazione. La chiave è che il livello applicazione non può leggere i dati duplicati, non importa quante volte vengono ritrasmessi, è necessario garantire che solo una copia dei dati venga letta dal livello applicazione.
Nel kernel del sistema operativo ricevente c'è una struttura dati: il buffer di ricezione. Questa struttura dati è simile alla coda di blocco prioritario. Quando B riceve il pacchetto di dati e passa attraverso gli strati fino allo strato di trasporto, ci sarà un coda di blocco per inserire i dati e la coda determinerà se i dati esistono in base al numero di sequenza del pacchetto di dati. Se esiste (esistenza significa che lo stesso pacchetto di dati è stato ricevuto ed è stato letto una volta dal livello dell'applicazione), verrà scartato direttamente. Un altro punto del buffer di ricezione è che può risolvere il problema dell'ultimo arrivato, primo servito nella rete. I dati inviati verranno ordinati in base al numero di sequenza e quindi consumati dal programma del livello applicativo in ordine.
Come mostrato nella figura sopra, i dati che arrivano nel buffer di ricezione verranno ordinati in base al numero di sequenza. Questo non solo risolve il problema dell'ultimo inviato, del primo arrivato, ma risolve anche il problema della ricezione di pacchetti di dati duplicati questa volta, se il pacchetto di dati ritrasmesso viene ricevuto con il numero di sequenza 500, verrà scartato direttamente, perché il numero di sequenza minimo del buffer di ricezione è 1000, il che significa che 500 è già stato letto dal programma applicativo.
La perdita di pacchetti in sé è un evento poco probabile. Quando il numero di pacchetti persi aumenta, la rete diventerà un grosso problema. All'aumentare del numero di ritrasmissioni, l'intervallo di tempo tra le ritrasmissioni continua ad allungarsi, poiché un numero maggiore di ritrasmissioni indica che c'è un problema con la rete e ritrasmissioni frequenti consumeranno risorse. Quando il numero di ritrasmissioni raggiunge una soglia, verrà inviato un messaggio di ripristino con il bit del flag RST impostato su 1 per cancellare lo stato intermedio di entrambe le estremità. Se il messaggio di ripristino non riceve risposta, la connessione su entrambe le estremità verrà eliminata.
La ritrasmissione del timeout è un supplemento alla risposta di riconoscimento.
Figura 5
Stabilire una connessione significa che entrambe le parti comunicanti salvano le informazioni dell'altra estremità. Il completamento specifico richiede tre interazioni di rete, come mostrato nella Figura 5.
La prima volta dell'handshake a tre vie deve essere avviata dal cliente. Chi avvia l'handshake a tre vie è il cliente. Il processo specifico è mostrato nella Figura 5. Innanzitutto, il client invia un pacchetto SYN, ovvero il flag SYN nell'intestazione è impostato su 1. Quindi il server restituisce un pacchetto di risposta. I flag ACK e SYN del pacchetto di risposta lo sono entrambi impostati a 1, perché ACK e SYN I pacchetti di dati con bit di flag vengono inviati dal kernel del sistema operativo contemporaneamente, quindi possono essere inviati insieme per migliorare le prestazioni. Infine, il client invia un pacchetto di risposta al server e l'handshake a tre vie viene completato. I pacchetti di dati trasmessi durante questo processo non contengono dati aziendali.
Il significato della stretta di mano a tre:
(1) Lanciare pietre per chiedere indicazioni
Confermare se il collegamento di comunicazione è regolare
(2) Negoziare alcuni parametri importanti
Ad esempio, il numero di sequenza del pacchetto di dati trasmesso
(3) Confermare le capacità di ricezione e invio di entrambe le parti
Perché tre strette di mano? Quattro o due strette di mano vanno bene?
Sebbene l'handshake a quattro vie non influisca sulle normali funzioni, ridurrà le prestazioni. L'handshake a due vie non può confermare completamente le capacità di ricezione e invio del server.
Inoltre, qui sono coinvolti altri due stati importanti. Il primo è lo stato di ascolto, il che significa che il server ha collegato la porta in questo momento e sta aspettando che il client invii un pacchetto SYN facile da capire e significa che l'handshake a tre vie è completato Lo stato dopo aver stabilito la connessione.
A differenza dell'handshake a tre vie, che può essere avviato solo prima dal client, sia il server che il client possono avviare l'handshake a quattro vie.
Figura 6
Il processo specifico di sventolare quattro volte è mostrato nella Figura 6. Quando il metodo socket.close() viene chiamato nel codice client o quando il processo termina, un messaggio di fine FIN verrà inviato al server. Il server invierà immediatamente un ACK, ma dovrà attendere fino al codice del server. Solo dopo aver chiamato il codice come socket.close() il messaggio finale FIN può essere inviato al client. Successivamente, il client invia un messaggio ACK al server e il processo si completa sventolando quattro volte.
L'ACK e il FIN al centro qui non possono essere combinati, perché l'ACK viene inviato dal kernel del sistema, quindi verrà inviato immediatamente quando il server riceve il messaggio FIN, ma il messaggio FIN dovrà attendere fino al codice lato server esegue il socket. Può essere inviato dopo close() e c'è una differenza di tempo tra i due. Ma c'è un modo per combinare i due. In circostanze particolari, l'ACK può essere inviato in ritardo, in modo da poter essere inviato insieme al FIN.
Inoltre, ci sono due stati coinvolti nei quattro processi di waving. Il primo è lo stato close_wait. Questo stato è lo stato in cui si trova il destinatario dopo aver ricevuto il messaggio FIN del mittente. L'altro stato è time_wait. Questo stato è quando si invia lo stato A che la parte deve attendere dopo aver ricevuto il FIN inviato dal destinatario e quindi aver inviato un ACK al destinatario. La connessione non può essere interrotta immediatamente perché è necessario evitare che l'ultimo ACK inviato dal mittente al destinatario venga perso e. il ricevitore ritrasmette il FIN Per garantire che il mittente possa ancora ricevere questo FIN, il tempo in questo stato è solitamente 2MSI (MSI: il tempo massimo per la trasmissione dei dati su entrambe le estremità), che solitamente è 2 minuti.
Se sul ricevitore viene trovato un numero elevato di close_wait, significa che il metodo close() è stato dimenticato. Se sul server viene trovato un numero elevato di time_wait, significa che il server ha attivato un numero elevato di disconnessioni TCP attive. operazioni.
TCP deve garantire una trasmissione affidabile, ma allo stesso tempo vuole anche completare la trasmissione dei dati nel modo più efficiente possibile. La finestra scorrevole è un meccanismo per migliorare l'efficienza. In realtà questo è un modo per compensare, perché per garantire l'affidabilità, TCP sacrifica molte prestazioni. Non importa come si fa scorrere la finestra, la velocità di trasmissione dei dati non può essere più veloce di UDP.
Figura 7
Come mostrato nella Figura 7, questo è il processo di trasmissione dei dati, ma il processo di invio di un pacchetto di dati e di ricezione di un pacchetto di dati di risposta è ancora relativamente lento.
Figura 8
Come mostrato nella Figura 8, ciò avviene dopo l'introduzione del meccanismo della finestra scorrevole. Invece di inviare un pacchetto di dati ma più pacchetti di dati alla volta, il tempo di attesa dei pacchetti di dati di risposta restituiti si sovrappone. Senza attendere l'ACK, la quantità di dati inviati in batch corrisponde alla dimensione della finestra.
Figura 9
Il processo di scorrimento della finestra è mostrato nella Figura 9. Supponiamo che la dimensione della finestra sia di 4 gruppi. Quando un gruppo riceve un ACK, verranno inviati nuovi dati per integrarlo, il che equivale a un processo di scorrimento. Se il mittente riceve l'ACK 3001 significa che sono stati ricevuti i dati da 1001 a 3001, quindi la finestra può spostarsi di due spazi a destra.
Cosa fare se si verifica una perdita di pacchetti nella finestra scorrevole? Esistono due situazioni:
(1) Il pacchetto di dati inviato è andato perso
Se un certo gruppo di datagrammi inviati viene perso, anche se si inviano molti gruppi di dati al destinatario in batch, il numero di sequenza di conferma dell'ACK ricevuto è ancora quello del gruppo perduto finché il mittente non ritrasmette il datagramma. Ad esempio, i datagrammi 1001~2000 nell'immagine sopra vengono persi Anche se successivamente vengono trasmessi più set di dati, l'ACK di 1001 verrà restituito finché il mittente non ritrasmette e il destinatario lo riceve, quindi risponde con l'ACK di 7001. .
(2) La risposta ACK viene persa
Se l'ACK di risposta viene perso, non devi preoccuparti, perché puoi semplicemente attendere fino a quando non viene restituito l'ACK di altri gruppi di dati. Ad esempio, se l'ACK di 1001 nell'immagine sopra viene perso non ha importanza. Il mittente del successivo ACK del 2001 lo ha ricevuto. I dati precedenti sono stati ricevuti, e lo stesso vale se l'ACK dei dati successivi viene perso.
L'elaborazione sopra menzionata della perdita di pacchetti è ancora molto efficiente. Se il pacchetto di dati viene perso, basta colmare il vuoto e ritrasmettere i dati. Se l'ACK viene perso, basta ignorarlo. Tale operazione è chiamata ritrasmissione veloce.
La ritrasmissione del timeout e la ritrasmissione rapida sono strategie diverse adottate in ambienti diversi. Se il TCP trasmette pochi e poco frequenti dati, verrà attivata la ritrasmissione del timeout. Se il TCP deve trasmettere una grande quantità di dati in un breve periodo di tempo, la finestra scorrevole lo farà essere attivato. Ritrasmissione veloce, la ritrasmissione veloce è equivalente alla variante della ritrasmissione timeout sotto la finestra scorrevole.
Come accennato in precedenza a proposito della finestra scorrevole, la dimensione della finestra è variabile. È possibile controllare la velocità di invio del mittente modificando la dimensione della finestra, maggiore è la quantità di dati inviati per unità di tempo e maggiore è l'efficienza. Più piccola è la finestra, più dati vengono inviati per unità di tempo. Meno dati ci sono, meno efficiente è. Normalmente, ovviamente, speriamo che l'efficienza sia la più elevata possibile, ma il prerequisito per un'elevata efficienza è garantire l'affidabilità. Se il mittente invia troppo velocemente e il destinatario non può gestirlo, potrebbe verificarsi una perdita di pacchetti è Il destinatario comunica al mittente che la velocità di invio è troppo elevata. Si tratta di "controllo del flusso".
Come mostrato nella figura sopra, come menzionato prima, nel kernel è presente un buffer di ricezione della struttura dati e il ricevitore restituirà la dimensione dello spazio libero nel buffer di ricezione come dimensione della finestra. L'intestazione TCP precedente ha un campo di dimensione della finestra a 16 bit che utilizza ACK per salvare e restituire queste informazioni. Il campo di dimensione della finestra avrà effetto solo in ACK.
Come mostrato nella figura sopra, ACK restituirà la dimensione della finestra per raggiungere lo scopo del controllo del flusso. Quando la dimensione della finestra ritorna a 0, il mittente invierà periodicamente messaggi sonda che non contengono dati aziendali per attivare ACK per conoscere i dati. stato del buffer. C'è spazio libero.
Il controllo della congestione è molto simile al controllo del flusso, entrambi i meccanismi sono abbinati a finestre scorrevoli.
Come mostrato nella figura sopra, i collegamenti nella rete sono molto complessi e qualsiasi nodo sul collegamento può limitare la velocità del mittente. L'idea del controllo della congestione è trattarla nel suo insieme, non importa quanto complessa sia la struttura intermedia, e quindi trovare la dimensione della finestra più appropriata attraverso gli esperimenti.
La figura sopra è un processo di controllo della congestione. Provalo innanzitutto con una dimensione della finestra relativamente piccola (avvio lento), perché non conosci la situazione di congestione della rete. Successivamente, la dimensione della finestra aumenterà in modo esponenziale e quando raggiungerà una certa soglia, inizierà a crescere in modo lineare, quindi quando la finestra cresce fino a un certo punto, si verifica una perdita di pacchetti. A questo punto, la finestra viene immediatamente ridotta. Esistono due modi per ridurre le dimensioni:
(1) Riduci direttamente fino in fondo, torna all'inizio dell'avvio lento, quindi ripeti il processo precedente (già abbandonato)
(2) Ridurre della metà e poi crescere linearmente (il metodo effettivamente utilizzato)
Il controllo della congestione consiste nell'utilizzare esperimenti per trovare una dimensione della finestra adatta. Se c'è molta perdita di pacchetti, ridurre la dimensione della finestra. Se non c'è perdita di pacchetti, aumentare la dimensione della finestra.
La risposta ritardata, come suggerisce il nome, significa attendere un po' prima di restituire un ACK. Ciò in realtà comporta anche un problema di dimensione della finestra, poiché la risposta ritardata di ACK darà al ricevente più tempo per consumare i dati nel buffer di ricezione, aumentandolo così. la dimensione del buffer libero, la dimensione della finestra restituita da ACK aumenta e il mittente può inviare più dati in batch.
Esistono due metodi di risposta ritardata:
(1) Specificare il ritardo in base a un determinato tempo
(2) In base alla quantità di dati ricevuti
Le due strategie precedenti vengono utilizzate in combinazione.
Le risposte piggyback in realtà sono apparse prima, come meccanismo utilizzato per migliorare l’efficienza della trasmissione. Questo è il caso in cui ACK e SYN vengono restituiti utilizzando lo stesso pacchetto di dati nell'handshake a tre vie. Esiste anche una situazione simile a quella di Four Waves. Poiché ACK e FIN vengono inviati in momenti diversi, non è possibile inviare risposte piggyback. Tuttavia, con la risposta ritardata, ACK non deve essere inviato così rapidamente al mittente possono essere combinati con le due FIN. Le trasmissioni secondarie vengono combinate in un'unica trasmissione collegandosi alle risposte.
L'orientamento al flusso di byte è un meccanismo di TCP. Un problema a cui prestare attenzione è il problema del blocco dei pacchetti. Questo problema è causato dall'incapacità di distinguere i confini tra i diversi pacchetti di dati del livello applicazione flusso di byte, il server può leggere più byte può anche leggere un byte, il che può facilmente causare questo problema.
Esistono due soluzioni al problema del sacchetto appiccicoso di cui sopra:
(1) Utilizzare separatori
È possibile utilizzare qualsiasi simbolo purché non esista nel pacchetto di richiesta
(2) Concordare la lunghezza del pacchetto dati
Nella maggior parte dei casi, però, i programmatori Java non utilizzano direttamente il protocollo TCP, bensì protocolli già pronti come http oppure implementano la comunicazione di rete sulla base di strumenti come protobuffer o dubbo. Questi metodi hanno risolto internamente il problema degli sticky packet. Perduto.
(1) Ad entrambe le estremità della comunicazione, il processo ad un'estremità si è bloccato.
Il sistema operativo completa quattro onde e agita il PCB.
(2) Un determinato host viene arrestato (processo normale)
La prima possibilità è che il sistema operativo abbia completato quattro ondate. La seconda possibilità è che il ricevente non abbia risposta ACK dopo aver inviato il FIN. Ritrasmette più volte e poi cancella unilateralmente la connessione che si spegne, poiché sono tutti spenti. Le informazioni archiviate (memoria) sono naturalmente scomparse.
(3) L'alimentatore di un determinato host è spento.
Quando l'host spento è un server, il pacchetto di dati inviato dal client verrà ritrasmesso senza ACK. Se non viene ottenuto alcun risultato dopo più ritrasmissioni, la connessione verrà eliminata.
Quando l'host spento è un client e il server non riceve un pacchetto di dati per un lungo periodo, invierà periodicamente un pacchetto heartbeat senza carico utile, solo per attivare un ACK. Se il client è normale, restituirà un ACK, altrimenti non lo riceverà. Se dopo essere stati inviati più volte di seguito non viene ricevuta alcuna risposta dal client ma non c'è risposta, si può considerare che il client è inattivo e le informazioni di connessione vengono cancellate.
Inoltre, sebbene TCP implementi i pacchetti heartbeat, il ciclo è lungo e spesso richiede alcuni minuti per scoprire che il client è inattivo tramite questo pacchetto heartbeat. Nello sviluppo effettivo, verranno implementati i pacchetti heartbeat a livello di applicazione, con frequenza più elevata e periodo più breve (livello di secondo livello/millisecondo vengono inviati A->B invia un ping e B->A risponde con un pong). Una volta che il dispositivo si blocca, è possibile individuare rapidamente il problema.
(4) Il cavo di rete è scollegato
Essenzialmente, è il terzo caso. Se il mittente non riceve l'ACK, scadrà e ritrasmetterà, quindi invierà RST e quindi eliminerà la connessione unilateralmente. Se il destinatario non riceve il pacchetto di dati, invierà un pacchetto heartbeat Se non riceve l'ACK, invierà semplicemente un pacchetto heartbeat con le informazioni di eliminazione.
Ci sono due bit di flag nella struttura dell'intestazione TCP che non sono menzionati, vale a dire PSH e URG che sollecita l'altra parte a restituire una risposta il prima possibile. L'URG è associato al campo del puntatore di emergenza dell'intestazione del pacchetto TCP e utilizzato insieme per controllare la trasmissione dei dati fuori banda TCP.
La trasmissione dati fuori banda significa che oltre ai dati aziendali, ci sono alcuni pacchetti dati speciali utilizzati per controllare il meccanismo di funzionamento del TCP stesso.
Si dedica alla ricerca tecnologica da più di 30 anni ed è esperto in vari linguaggi come Java, Linux, Javascript, php, css, ecc. Ha dato numerosi contributi nel campo dell'open source stazione di documentazione per gli sviluppatori per condividere alcuni problemi nello sviluppo della tecnologia per riferimento futuro
Posta[email protected]