10. Server Scheduling (Pianificazione del server)

È generalmente vantaggioso per i server HTTP inviare tutte le risposte il prima possibile. Tuttavia, quando si servono più richieste su una singola connessione, può esserci competizione tra le richieste per risorse come la larghezza di banda della connessione. Questa sezione descrive considerazioni su come i server pianificano l'ordine di invio delle risposte in competizione quando esiste tale competizione.

La pianificazione del server è un processo di prioritizzazione basato su molti input; i segnali di priorità sono solo una forma di input. Fattori come la scelta dell'implementazione o l'ambiente di distribuzione giocano anch'essi un ruolo. Qualsiasi connessione può avere molte permutazioni dinamiche. Per queste ragioni, non è possibile descrivere un algoritmo di pianificazione universale. Questo documento fornisce alcune raccomandazioni di base, non esaustive, su come i server potrebbero agire sui parametri di priorità. Non descrive in dettaglio come i server combinano i segnali di priorità con altri fattori. Gli endpoint non possono dipendere da un trattamento particolare basato sui segnali di priorità. Esprimere la priorità è solo un suggerimento.

Si raccomanda (RECOMMENDED) che i server rispettino il parametro urgency (Sezione 4.1) dove possibile, inviando le risposte ad alta urgenza prima delle risposte a bassa urgenza.

Il parametro incremental indica come i client elaborano i byte di risposta in arrivo. Si raccomanda (RECOMMENDED) che i server rispettino il parametro incremental (Sezione 4.2) dove possibile.

Le risposte non incrementali della stessa urgenza dovrebbero (SHOULD) essere servite allocando larghezza di banda in ordine crescente per ID di flusso, che corrisponde all'ordine in cui i client hanno effettuato le richieste. Ciò garantisce che i client possano utilizzare l'ordine delle richieste per influenzare l'ordine delle risposte.

Le risposte incrementali della stessa urgenza dovrebbero (SHOULD) essere servite condividendo la larghezza di banda tra di esse. Il contenuto del messaggio delle risposte incrementali viene utilizzato man mano che viene ricevuto in parti o blocchi. I client potrebbero beneficiare maggiormente dalla ricezione di porzioni di tutte queste risorse piuttosto che dall'interezza di una singola risorsa. La dimensione della porzione di risorsa necessaria per migliorare le prestazioni varia. Alcuni tipi di risorse collocano elementi critici all'inizio; altre risorse possono utilizzare le informazioni in modo progressivo. Questo schema non specifica esplicitamente come i server dovrebbero utilizzare dimensione, tipo o qualsiasi altro input per decidere come dare priorità.

Potrebbero esserci scenari in cui i server devono pianificare più risposte incrementali e non incrementali allo stesso livello di urgenza. L'adesione rigorosa alle linee guida di pianificazione basate sull'urgenza e sull'ordine di generazione delle richieste potrebbe portare a risultati non ottimali per il client, poiché le risposte non incrementali precoci potrebbero bloccare il servizio di risposte incrementali emesse successivamente. Ecco esempi di tali sfide:

1. Allo stesso livello di urgenza, una richiesta non incrementale per una grande risorsa seguita da una richiesta incrementale per una piccola risorsa.

2. Allo stesso livello di urgenza, una richiesta incrementale di lunghezza incerta seguita da una grande risorsa non incrementale.

Si raccomanda (RECOMMENDED) che i server evitino tale fame dove possibile. Il mezzo per farlo è una decisione di implementazione. Ad esempio, i server potrebbero inviare preventivamente risposte di determinati tipi incrementali basati su altre informazioni come la dimensione del contenuto.

La pianificazione ottimale dei push del server è difficile, specialmente quando le risorse spinte competono con richieste concorrenti attive. Ci sono molti fattori che i server possono considerare durante la pianificazione, come il tipo o la dimensione della risorsa spinta, la priorità della richiesta che ha attivato il push, il numero di risposte concorrenti attive, la priorità di altre risposte concorrenti attive, ecc. Non ci sono linee guida generali sul modo migliore di applicare questi fattori. Server eccessivamente semplici potrebbero spingere a una priorità troppo alta e bloccare le richieste dei client o spingere a una priorità troppo bassa e ritardare le risposte, negando l'obiettivo previsto del push del server.

I segnali di priorità sono un fattore nella pianificazione del push del server. Il concetto di valori predefiniti dei parametri si applica in modo leggermente diverso, poiché non esiste un segnale client esplicito per la priorità iniziale. I server possono applicare segnali di priorità forniti nelle risposte di origine; vedere le linee guida di fusione fornite nella Sezione 8. In assenza di segnali di origine, l'applicazione di valori di parametri predefiniti potrebbe essere non ottimale. Qualunque cosa i server decidano su come pianificare le risposte spinte, possono segnalare la priorità attesa ai client includendo un campo Priority nel frame PUSH_PROMISE o HEADERS.

10.1. Intermediaries with Multiple Backend Connections (Intermediari con più connessioni backend)

Un intermediario che serve una connessione HTTP potrebbe distribuire le richieste su più connessioni backend. Quando applica rigorosamente le regole di ordinamento delle priorità, le richieste a priorità inferiore non possono progredire mentre le richieste con priorità superiore sono in corso. Questo blocco può propagarsi alle connessioni backend, che i peer potrebbero interpretare come stallo della connessione. Gli endpoint implementano comunemente protezione contro gli stalli, come la chiusura improvvisa delle connessioni dopo un certo periodo. Per ridurre la probabilità che ciò si verifichi, gli intermediari possono evitare di seguire rigorosamente l'ordinamento delle priorità e allocare invece una piccola quantità di larghezza di banda a tutte le richieste che inoltrano in modo che ognuna possa fare progressi nel tempo.

Allo stesso modo, i server dovrebbero (SHOULD) allocare una certa quantità di larghezza di banda ai flussi che agiscono come tunnel.

---