Anche se HTTP può utilizzare più protocolli di trasporto, di fatto la maggior parte delle sue implementazioni esistenti utilizzano TCP. Tuttavia quest'ultimo non è ottimizzato per connessioni di breve durata e con un piccolo scambio di dati, situazione abbastanza frequente in HTTP.

Inoltre TCP richiede un three-way handshake per stabilire la connessione e altri quattro pacchetti per chiuderla. Pertanto se un tipico messaggio HTTP è formato da 10 pacchetti, si avrà un totale di 17 pacchetti scambiati, di cui 7 sono di overhead, circa il 41%.

Inoltre, i trasferimenti web non superano mai la fase slow-start di TCP, prima che la dimensione della finestra sia incrementata significativamente; difatti la connessione viene chiusa prima che ciò possa avvenire evitando così di sfruttare tutta la banda a disposizione.

Se consideriamo poi che un documento HTML è per lo più un contenitore di altri documenti identificati da URI, fare il download di un contenitore richiede numerose transazioni HTTP e di conseguenza numerose connessioni TCP, senza contare poi che prima che il documento completo possa essere visualizzato, bisogna attendere la conclusione di tutte le connessioni.

Un modo per ridurre la latenza è quello di aprire più connessioni HTTP parallele. Questo metodo venne introdotto da Netscape, che instaurava più connessioni per il download parallelo di più risorse. Un altro modo per risolvere il problema consiste nell'osservare che la connessione TCP, una volta stabilita, può restare aperta per più di un solo scambio di richiesta di risposta. Questa osservazione introduce il concetto di connessioni persistenti di HTTP 1.1.

L'idea alla base delle connessioni persistenti è quella di ridurre il numero di connessioni TCP gestite riducendo drasticamente la latenza percepita dall'utente, in quanto le connessioni successive non devono chiudere la connessione precedente e ripetere la fase slow-start di TCP.

• Pubblicazioni correlate:
• 24-02-2010 HTTP 1.1: le ragioni della sua introduzione
• 01-03-2010 HTTP 1.1: il meccanismo dell'hop by hop
• 03-03-2010 HTTP 1.1: il meccanismo del transfer coding
• 07-04-2010 HTTP 1.1: modifiche nella specifica dei metodi
• 12-04-2010 HTTP 1.1: modifiche nella specifica degli header (1/5)
• 14-04-2010 HTTP 1.1: modifiche nella specifica degli header (2/5)
• 19-04-2010 HTTP 1.1: modifiche nella specifica degli header (3/5)
• 21-04-2010 HTTP 1.1: modifiche nella definizione degli header (4/5)
• 26-04-2010 HTTP 1.1: modifiche nella definizione degli header (5/5)
• 05-05-2010 HTTP 1.1: modifiche nella specifica dei messaggi di risposta (1/4)
• 19-05-2010 HTTP 1.1: modifiche nella specifica dei messaggi di risposta (2/4)
• 26-05-2010 HTTP 1.1: modifiche nella specifica dei messaggi di risposta (3/4)
• 31-05-2010 HTTP 1.1: modifiche nella specifica dei messaggi di risposta (4/4)
• 07-06-2010 HTTP 1.1: gli obiettivi del caching
• 10-06-2010 HTTP 1.1: l'header Cache-Control
• 05-07-2010 HTTP 1.1: le direttive di Cache-Control per le richieste (1/2)
• 26-07-2010 HTTP 1.1: le direttive di Cache-Control per le richieste (2/2)
• 06-09-2010 HTTP 1.1: le direttive di Cache-Control per le risposte (1/2)
• 08-09-2010 HTTP 1.1: le direttive di Cache-Control per le risposte (2/2)
• 10-11-2010 HTTP 1.1: gli header ETag e Vary
• 29-12-2010 HTTP 1.1: ottimizzazione della banda (1/3)
• 05-01-2011 HTTP 1.1: ottimizzazione della banda (2/3)
• 12-01-2011 HTTP 1.1: ottimizzazione della banda (3/3)
• 02-02-2011 HTTP 1.1: gestione delle connessioni (2/2)
• 07-02-2011 HTTP 1.1: frammentazione dei messaggi
• 14-02-2011 HTTP 1.1: meccanismi per l'interoperabilità (1/2)
• 21-02-2011 HTTP 1.1: meccanismi per l'interoperabilità (2/2)
• 28-02-2011 HTTP 1.1: negoziazione del contenuto
• 16-03-2011 HTTP 1.1: gestione dell'autenticazione e dell'integrità dei messaggi
• 30-03-2011 HTTP 1.1: definizione del ruolo dei proxy (1/2)
• 04-04-2011 HTTP 1.1: definizione del ruolo dei proxy (2/2)
• 13-04-2011 HTTP 1.1: altre variazioni rispetto ad HTTP 1.0 (1/2)
• 18-04-2011 HTTP 1.1: altre variazioni rispetto ad HTTP 1.0 (2/2)