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 扩展, 则受限服务器将无法限制记录大小.