3. Limitations of the "max_fragment_length" Extension (Limitazioni dell'estensione 'max_fragment_length')
3. Limitations of the "max_fragment_length" Extension (Limitazioni dell'estensione «max_fragment_length»)
L'estensione max_fragment_length presenta diverse limitazioni che ne rendono inadatto l'uso.
Un client che non ha vincoli che impediscono di accettare un record grande non può usare max_fragment_length senza rischiare una riduzione della dimensione dei record. Il valore massimo consentito dall'estensione è 2^12, molto inferiore alla dimensione massima di record 2^14 consentita dal protocollo.
Per trasferimenti di dati di grandi dimensioni, piccole dimensioni di record possono influire sensibilmente sulle prestazioni. Ogni record comporta costi aggiuntivi, sia in ottetti aggiuntivi per le intestazioni dei record sia per l'espansione dovuta alla crittografia. Elaborare più record aggiunge anche oneri computazionali che possono essere ammortizzati più efficacemente con dimensioni di record maggiori. Di conseguenza, i client in grado di ricevere record grandi potrebbero essere restii a rischiare una riduzione delle prestazioni offrendo l'estensione, soprattutto se l'estensione è raramente necessaria.
Questo non sarebbe un problema se fosse disponibile o potesse essere aggiunto un codepoint per frammenti di 2^14 ottetti. Tuttavia, RFC 6066 richiede che i server interrompano l'handshake con un avviso illegal_parameter se ricevono l'estensione con un valore che non comprendono. Ciò rende impossibile aggiungere nuovi valori all'estensione senza il rischio di tentativi di connessione falliti.
Un server che negozia max_fragment_length è tenuto a rispecchiare il valore scelto dal client. Il server non può richiedere un limite inferiore a quello offerto dal client. Questo è un problema significativo se un server è più vincolato dei client che serve.
L'estensione max_fragment_length è anche poco adatta ai casi in cui le capacità di client e server sono asimmetriche. I vincoli sulla dimensione dei record sono spesso vincoli del ricevente.
In confronto, un'implementazione potrebbe essere in grado di inviare dati in modo incrementale. La crittografia non ha lo stesso requisito di atomicità. Alcuni cifrari possono essere crittografati e inviati in modo progressivo. Così, un endpoint potrebbe essere disposto a inviare record più grandi del limite che annuncia per i record che riceve.
Se questi disincentivi sono sufficienti a scoraggiare i client dal distribuire l'estensione max_fragment_length, i server vincolati non possono limitare le dimensioni dei record.