b"\n_START_ARTICLE_\nControllo della congestione in TCP\n_START_PARAGRAPH_\nIn telecomunicazioni e informatica il controllo della congestione in TCP \xc3\xa8 una funzionalit\xc3\xa0 di controllo di trasmissione da parte di TCP che permette di limitare la quantit\xc3\xa0 di dati trasmessi sotto forma di pacchetti e non ancora riscontrati dal mittente, adattando il flusso dati inviato all'eventuale stato di congestione della rete. Tale stato \xc3\xa8 desunto indirettamente a partire da informazioni ricavabili dallo stato della trasmissione dei pacchetti da parte di un terminale, evitando cos\xc3\xac congestione nella rete stessa.\n_START_SECTION_\nSlow start\n_START_PARAGRAPH_\nDurante la fase di partenza lenta (in inglese, slow start) la finestra di  congestione cwnd  viene impostato di default ad 1 (il che comporta una velocit\xc3\xa0 di invio iniziale di circa MSS/RTT) e il mittente TCP inizia trasmettendo il primo segmento dati, attendendo un riscontro. La cwnd aumenta di una quantit\xc3\xa0 pari al MSS per ciascun segmento che, dopo esser stato trasmesso, viene riscontrato (si riceve un ACK). Quindi ad ogni RTT la cwnd raddoppia di dimensioni (e conseguentemente ne raddoppia anche la velocit\xc3\xa0 trasmissiva)._NEWLINE_La fase di slow start viene mantenuta fintanto che non si incorre in un evento di congestione, come la perdita di un segmento dati, oppure quando la dimensione della finestra di congestione raggiunge o supera il valore della variabile ssthresh, evento che conduce alla fase di aumento additivo - diminuzione moltiplicativa (AIMD), o infine nel caso in cui vengono identificati tre segmenti riscontrati duplicati. In tal caso il mittente TCP pone cwnd ad 1 ed inizia di nuovo il processo di Slow Start. Inoltre pone il valore di sstresh a cwnd/2.   _NEWLINE_Successivamente si passa all'algoritmo di Congestion Avoidance (quando cwnd >= ssthresh) oppure Fast Recovery (quando vengono identificati tre segmenti riscontrati duplicati).\n_START_SECTION_\nTCP New Reno\n_START_PARAGRAPH_\nIl TCP Reno risolve in parte il problema di perdite non dovute a congestione solo quando le perdite non sono fortemente correlate tra loro, cio\xc3\xa8 quando si perde al massimo un pacchetto all'interno di ogni finestra. _NEWLINE_Questo comportamento \xc3\xa8 problematico nelle situazioni in cui si perdono interi burst di pacchetti (situazione frequente ad esempio nei collegamenti wireless).  Infatti, in questi casi TCP Reno potrebbe ridurre il valore della finestra di congestione pi\xc3\xb9 volte consecutivamente (ovvero tante volte quanti sono i pacchetti persi) causando un drastico peggioramento della velocit\xc3\xa0 di trasmissione della connessione TCP._NEWLINE_TCP New Reno cerca di aggirare il problema basandosi sul sistema degli ACK parziali. _NEWLINE_Vengono considerati ACK parziali gli ACK che riscontrano pacchetti intermedi, e non gli ultimi pacchetti che necessiterebbero riscontro, dopo che \xc3\xa8 stata gi\xc3\xa0 iniziata la fase di Fast Recovery in seguito all'arrivo di tre ack duplicati._NEWLINE_Quando uno di questi ack si presenta durante una fase di Fast Recovery (cio\xc3\xa8 in seguito alla ricezione di 3 ack duplicati), TCP New Reno si mantiene in tale fase continuando a reinviare i pacchetti via via richiesti finch\xc3\xa9 non viene riscontrato l'ultimo pacchetto inviato nella fase precedente all'ingresso in Fast Recovery.\n_START_SECTION_\nEquit\xc3\xa0\n_START_PARAGRAPH_\nL'equit\xc3\xa0 in una rete a commutazione di pacchetto misura in che modo la banda di una rete viene ripartita tra i flussi dati attivi. Nel caso di una rete composta da un unico collegamento a collo di bottiglia avente banda pari a R bps, condiviso da K connessioni TCP, la perfetta equit\xc3\xa0 corrisponde ad una ripartizione uniforme della banda R tra le K connessioni attive. In altre parole, la perfett\xc3\xa0 equit\xc3\xa0 viene raggiunta se ciascuna delle K connessioni TCP ottiene a regime una velocit\xc3\xa0 media di trasmissione dei dati pari a R/K. Nel caso del TCP, questa condizione pu\xc3\xb2 verificarsi solo quando le K connessioni presentano lo stesso RTT (Round Trip Time). Infatti, la velocit\xc3\xa0 media di trasmissione dei dati di una connessione TCP \xc3\xa8 inversamente proporzionale al suo RTT. Queste considerazioni sono valide in presenza di applicazioni persistenti, ovvero in grado di trasmettere senza interruzioni quantit\xc3\xa0 di dati teoricamente infinita."