【CS.CN】深入解析HTTP中的Expect: 100-continue头：性能优化的利器还是鸡肋？

目录

• 0 序言
  • 0.1 由来
  • 0.2 使用场景
  • 0.3 现在还需要吗？
• 1 Expect: 100-continue的机制
• 2 语法 && 通过重新设置空的Expect头优化性能
• 3 实例分析：长连接中的Expect问题解决
• 4 总结

0 序言

0.1 由来

Expect: 100-continue头部字段最早在HTTP/1.1规范中引入。其主要目的是在客户端发送大请求主体（如文件上传）之前，确保服务器能够处理该请求，从而避免不必要的数据传输。

可以将Expect: 100-continue机制比作一个礼貌的问询：

1. 情景设定：
   • 想象你要向朋友送一个大礼物（比如一个大箱子）。
   • 你不确定朋友是否有地方存放这个大箱子。
2. 正常流程：
   • 你打电话（建立TCP连接），告诉朋友你有一个大箱子（发送请求头）。
   • 朋友确认他们有地方放这个大箱子（服务器响应100 Continue）。
   • 你再送过去（发送请求主体）。
3. 使用Expect: 100-continue：
   • 你先打电话（建立TCP连接），告诉朋友你有一个大箱子，但等朋友确认他们有地方放这个大箱子后你才送过去（发送Expect: 100-continue头并等待100 Continue响应）。
   • 如果朋友说没有地方（返回错误状态），你就不送了（节省了不必要的传输）。

0.2 使用场景

• 大数据上传：当客户端需要上传大文件或大数据时，使用Expect: 100-continue可以确保服务器能够接受这些数据，从而避免在服务器不能处理请求的情况下浪费带宽。
• 带宽受限的环境：在带宽较低或受限的网络环境中，通过此机制可以减少不必要的数据传输，提高效率。
  • 节省带宽：避免在服务器不能处理请求的情况下发送大量数据，节省网络带宽。
  • 提高效率：在服务器无法处理请求时，客户端能尽早得知，避免等待无效的传输过程。

0.3 现在还需要吗？

虽然Expect: 100-continue在某些情况下依然有用，但现代网络环境和服务器架构的进步使其重要性有所降低：

• 快速网络：现代网络速度提高，使得发送请求头和等待100 Continue响应的时间成本变得相对较高。
• 高效服务器：现代服务器处理能力提升，通常可以快速判断并响应请求，无需客户端等待确认。
• 其他优化手段：现在有更多的优化手段和更好的网络协议（如HTTP/2, HTTP/3）可以提升传输效率。

是否需要使用Expect: 100-continue取决于具体的应用场景：

• 需要：在高带宽消耗的应用场景中，尤其是大数据上传或受限带宽环境中，依然可以使用。
• 不需要：在一般的Web请求或快速网络环境中，去掉Expect: 100-continue头可以减少等待时间，优化性能。

1 Expect: 100-continue的机制

Expect 是一个请求消息头，包含一个期望条件，表示服务器只有在满足此期望条件的情况下才能妥善地处理请求。

规范中只规定了一个期望条件，即 Expect: 100-continue, 对此服务器可以做出如下回应：

• 100 如果消息头中的期望条件可以得到满足，使得请求可以顺利进行的话，
• 417 (Expectation Failed) 如果服务器不能满足期望条件的话；也可以是其他任意表示客户端错误的状态码（4xx）。

例如，如果请求中 Content-Length 的值太大的话，可能会遭到服务器的拒绝。常见的浏览器不会发送 Expect 消息头，但是其他类型的客户端如 cURL 默认会这么做。