8. Connections (Connessioni)

8.1 Persistent Connections (Connessioni Persistenti)

8.1.1 Purpose (Scopo)

Prima delle connessioni persistenti, era necessario stabilire una connessione TCP separata per recuperare ogni URL, il che aumentava il carico sui server HTTP e causava congestione su Internet. L'uso di immagini inline e altri dati associati richiede tipicamente che un client effettui più richieste allo stesso server in un breve periodo di tempo. I risultati delle analisi di questi problemi di prestazioni e delle implementazioni di prototipi sono disponibili [26] [30]. L'esperienza di implementazione e le misurazioni delle implementazioni HTTP/1.1 (RFC 2068) reali mostrano buoni risultati [39]. Sono state esplorate anche alternative come T/TCP [27].

Le connessioni HTTP persistenti presentano molti vantaggi:

• Aprendo e chiudendo meno connessioni TCP, si risparmia tempo CPU nei router e negli host (client, server, proxy, gateway, tunnel o cache), e si risparmia memoria utilizzata per i blocchi di controllo del protocollo TCP negli host.

• Le richieste e le risposte HTTP possono essere messe in pipeline (pipelining) su una connessione. Il pipelining consente a un client di effettuare più richieste senza attendere ogni risposta, permettendo un uso più efficiente di una singola connessione TCP e un tempo trascorso notevolmente ridotto.

• La congestione della rete è ridotta diminuendo il numero di pacchetti causati dalle aperture TCP e consentendo a TCP di avere tempo sufficiente per determinare lo stato di congestione della rete.

• La latenza delle richieste successive è ridotta poiché non è necessario spendere tempo sulla stretta di mano di apertura della connessione TCP.

• HTTP può evolversi in modo più elegante poiché gli errori possono essere segnalati senza la penalità di chiudere la connessione TCP. I client che utilizzano versioni future di HTTP potrebbero tentare in modo ottimistico nuove funzionalità, ma se comunicano con un server più vecchio, riprovare con la vecchia semantica dopo aver segnalato un errore.

Le implementazioni HTTP dovrebbero (SHOULD) implementare connessioni persistenti.

8.1.2 Overall Operation (Operazione Complessiva)

Una differenza significativa tra HTTP/1.1 e le versioni precedenti di HTTP è che le connessioni persistenti sono il comportamento predefinito di qualsiasi connessione HTTP. Cioè, a meno che non sia diversamente indicato, il client dovrebbe (SHOULD) presumere che il server manterrà una connessione persistente, anche dopo una risposta di errore dal server.

Le connessioni persistenti forniscono un meccanismo per le applicazioni HTTP/1.0 e HTTP/1.1 per segnalare la chiusura della connessione. Questo segnale è fornito tramite il campo di intestazione Connection (sezione 14.10). Una volta che un'opzione di connessione "close" è stata inviata o ricevuta, quella connessione non deve (MUST NOT) essere considerata "persistente".

Le applicazioni HTTP/1.1 non devono (MUST NOT) stabilire connessioni persistenti con client HTTP/1.0.

8.1.3 Proxy Servers (Server Proxy)

È particolarmente importante che i proxy implementino correttamente le proprietà del campo di intestazione Connection, come descritto nella sezione 14.10.

I server proxy devono (MUST) segnalare separatamente le connessioni persistenti ai client e ai server upstream. Ogni connessione persistente si applica solo a un singolo collegamento di trasporto.

8.1.4 Practical Considerations (Considerazioni Pratiche)

I server hanno tipicamente un valore di timeout oltre il quale non manterranno più una connessione inattiva. I server proxy possono rendere questo valore di timeout più alto poiché i client potrebbero aver già stabilito connessioni sulle connessioni esistenti. L'uso di connessioni persistenti non richiede che i server mantengano le connessioni indefinitamente. In effetti, i server possono (MAY) chiudere una connessione in qualsiasi momento, ma dovrebbero (SHOULD) farlo in modo elegante.

I client, i server e i proxy devono (MUST) essere in grado di recuperare da eventi di chiusura asincroni. Il software client dovrebbe (SHOULD) riaprire la connessione di trasporto e ritrasmettere la sequenza di richieste abortita senza interazione dell'utente, purché la sequenza di richieste sia idempotente (vedere sezione 9.1.2). I metodi o le sequenze non idempotenti non devono (MUST NOT) essere automaticamente ritentati, sebbene l'user agent possa (MAY) offrire all'utente un mezzo per ritentare manualmente le richieste.

I server dovrebbero (SHOULD) sempre rispondere ad almeno una richiesta prima di chiudere una connessione. I server non dovrebbero (SHOULD NOT) chiudere una connessione nel mezzo della trasmissione di una risposta, a meno che non sia sospettato un guasto di rete o del client.

I client che desiderano inviare una connessione persistente possono (MAY) "mettere in pipeline" le loro richieste (cioè inviare più richieste senza attendere l'arrivo di ogni risposta). I server devono (MUST) inviare le loro risposte nell'ordine in cui sono state ricevute le richieste corrispondenti.

8.2 Message Transmission Requirements (Requisiti di Trasmissione dei Messaggi)

8.2.1 Persistent Connections and Flow Control (Connessioni Persistenti e Controllo del Flusso)

I server HTTP/1.1 dovrebbero (SHOULD) mantenere connessioni persistenti per se stessi, quando possibile. Tuttavia, se mantengono connessioni persistenti, allora per una determinata connessione TCP, dovrebbero (SHOULD) utilizzare quella connessione per almeno una sequenza richiesta-risposta.

8.2.2 Monitoring Connections for Error Status Messages (Monitoraggio delle Connessioni per Messaggi di Stato di Errore)

Un client HTTP/1.1 (o superiore) che invia una richiesta (in particolare una richiesta critica per l'autenticazione o con un metodo non sicuro) deve (MUST) reinviare la richiesta se la connessione di trasporto viene chiusa o reimpostata prima che il client abbia completato l'invio del messaggio di richiesta.

8.2.3 Use of the 100 (Continue) Status (Uso dello Stato 100 (Continue))

Lo scopo dello stato 100 (Continue) (vedere sezione 10.1.1) è consentire a un client che invia un corpo di messaggio di richiesta di determinare se il server di origine è disposto ad accettare la richiesta (basata sulle intestazioni di richiesta) prima che il client invii il corpo della richiesta. In alcuni casi, può essere inappropriato o inefficiente per un client inviare un corpo se il server rifiuterà il messaggio senza leggere il corpo.

Requisiti per un client HTTP/1.1 (o superiore) contenente un corpo di messaggio di richiesta:

• Se il client attenderà una risposta 100 (Continue) per un periodo di tempo ragionevole, il client deve (MUST) inviare un campo di intestazione Expect (sezione 14.20) contenente il valore di aspettativa "100-continue".

• Il client non deve (MUST NOT) inviare un campo di intestazione Expect con il valore di aspettativa "100-continue" a un server HTTP/1.0 (o precedente).

• Un client che invia un'aspettativa 100 (Continue) ma non riceve uno stato 100 (Continue) dovrebbe (SHOULD) attendere per un periodo indeterminato; il client può (MAY) quindi scadere e inviare la richiesta (con il suo corpo di messaggio) o chiudere la connessione.

Requisiti per un server di origine HTTP/1.1 (o superiore) che riceve una richiesta da un client HTTP/1.1 (o superiore):

• Dopo aver ricevuto una richiesta contenente un campo di intestazione Expect con il valore di aspettativa "100-continue", il server di origine deve (MUST) rispondere con uno stato 100 (Continue) se intende leggere ed elaborare il corpo del messaggio di richiesta, o rispondere con un codice di stato finale. Il server di origine non deve (MUST NOT) attendere il corpo della richiesta prima di inviare la risposta 100 (Continue). Se risponde con un codice di stato finale, può (MAY) chiudere la connessione di trasporto o può (MAY) continuare a leggere e scartare il resto della richiesta. Non deve (MUST NOT) eseguire il metodo della richiesta (se intende rifiutare la richiesta).

• Il server di origine dovrebbe (SHOULD) rispondere con 100 (Continue) immediatamente dopo aver ricevuto le intestazioni di richiesta da un client HTTP/1.1 (o superiore), a meno che la richiesta non contenga un campo di intestazione Expect con un valore di aspettativa che non comprende "100-continue".

8.2.4 Client Behavior if Server Prematurely Closes Connection (Comportamento del Client se il Server Chiude Prematuramente la Connessione)

Se un client HTTP/1.1 invia una richiesta HTTP prima di ricevere una risposta e riceve una risposta che indica che il server non desidera ricevere ulteriori richieste su quella connessione, il client dovrebbe (SHOULD) reinviare la richiesta, a condizione che possa determinare che tutte le richieste nella sequenza sono idempotenti (vedere sezione 9.1.2).

I metodi o le sequenze non idempotenti non devono (MUST NOT) essere automaticamente ritrasmessi, ma l'user agent può (MAY) offrire all'utente un mezzo per ritentare manualmente questa sequenza. Prima di ritrasmettere automaticamente le richieste, se la sequenza di richieste precedente non poteva essere completata interamente, il client dovrebbe (SHOULD) confermare eventuali differenze tra il suo stato attuale e lo stato previsto.

---