3. Limitations of the "max_fragment_length" Extension ("max_fragment_length" 拡張の限界)

3. Limitations of the "max_fragment_length" Extension ("max_fragment_length" 拡張の限界)

max_fragment_length 拡張には, 利用に適さないほどのいくつかの限界がある.

大きなレコードを受け入れる妨げとなる制約のないクライアントは, レコードサイズが縮小されるリスクを負わずに max_fragment_length を使えない. この拡張が許す最大値は 2^12 であり, プロトコルが許す最大レコードサイズ 2^14 よりはるかに小さい.

大きなデータ転送では, 小さいレコードサイズが性能に実質的な影響を与える. すべてのレコードに追加コストがかかり, レコードヘッダの追加オクテットと暗号化による拡張の両方が発生する. より多くのレコードを処理することは計算オーバーヘッドも増やし, より大きなレコードサイズの方が効果的に償却できる. したがって, 大きなレコードを受信できるクライアントは, 特にその拡張がめったに必要とされない場合, 拡張を提示して性能を下げるリスクを負いたがらないことがある.

2^14 オクテットのフラグメント用の codepoint が利用可能であるか追加できれば, これは問題にならない. しかし, RFC 6066 では, サーバーは理解できない値を伴う拡張を受け取った場合, illegal_parameter アラートでハンドシェイクを中止しなければならない. これにより, 接続試行の失敗のリスクなしに拡張に新しい値を追加することは不可能である.

max_fragment_length を交渉するサーバーは, クライアントが選択した値をエコーしなければならない. サーバーはクライアントが提示した上限より低い上限を要求できない. サーバーがサービスするクライアントより制約が強い場合, これは重大な問題である.

max_fragment_length 拡張は, クライアントとサーバーの能力が非対称な場合にも不向きである. レコードサイズの制約はしばしば受信側の制約である.

対照的に, 実装はデータを増分的に送信できる場合がある. 暗号化には同じ原子性要件はない. 一部の暗号は進行的に暗号化して送信できる. したがって, エンドポイントは, 受信するレコードについて通告する上限より大きいレコードを送信してもよい場合がある.

これらの抑止要因がクライアントによる max_fragment_length 拡張の展開を思いとどまらせるのに十分なら, 制約の強いサーバーはレコードサイズを制限できない.