3. Limitations of the "max_fragment_length" Extension
3. Limitations of the "max_fragment_length" Extension
L'extension max_fragment_length présente plusieurs limitations qui la rendent inadaptée à l'usage.
Un client qui n'a aucune contrainte l'empêchant d'accepter un grand enregistrement ne peut utiliser max_fragment_length sans risquer une réduction de la taille des enregistrements. La valeur maximale permise par l'extension est 2^12, bien inférieure à la taille maximale d'enregistrement 2^14 permise par le protocole.
Pour les transferts de données importants, de petites tailles d'enregistrement peuvent affecter sensiblement les performances. Chaque enregistrement entraîne des coûts supplémentaires, tant en octets supplémentaires pour les en-têtes qu'en expansion due au chiffrement. Le traitement d'un plus grand nombre d'enregistrements ajoute également des surcoûts de calcul qui peuvent être amortis plus efficacement pour des tailles d'enregistrement plus grandes. Par conséquent, les clients capables de recevoir de grands enregistrements peuvent hésiter à risquer une baisse de performance en proposant l'extension, surtout si celle-ci est rarement nécessaire.
Ce ne serait pas un problème si un point de code était disponible ou pouvait être ajouté pour des fragments de 2^14 octets. Toutefois, la RFC 6066 exige que les serveurs interrompent la poignée de main avec une alerte illegal_parameter s'ils reçoivent l'extension avec une valeur qu'ils ne comprennent pas. Il devient ainsi impossible d'ajouter de nouvelles valeurs à l'extension sans risquer des échecs de connexion.
Un serveur qui négocie max_fragment_length doit renvoyer la valeur choisie par le client. Le serveur ne peut pas demander une limite inférieure à celle offerte par le client. C'est un problème majeur si le serveur est plus contraint que les clients qu'il dessert.
L'extension max_fragment_length convient également mal aux cas où les capacités du client et du serveur sont asymétriques. Les contraintes sur la taille des enregistrements concernent souvent le récepteur.
En comparaison, une mise en œuvre peut être capable d'envoyer des données de manière incrémentielle. Le chiffrement n'a pas la même exigence d'atomicité. Certains chiffrements peuvent être chiffrés et envoyés progressivement. Ainsi, une extrémité peut accepter d'envoyer des enregistrements plus grands que la limite qu'elle annonce pour les enregistrements qu'elle reçoit.
Si ces freins suffisent à décourager les clients de déployer l'extension max_fragment_length, les serveurs contraints ne peuvent pas limiter la taille des enregistrements.