Skip to content

Instantly share code, notes, and snippets.

@summerwind
Created April 11, 2014 14:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save summerwind/10474007 to your computer and use it in GitHub Desktop.
Save summerwind/10474007 to your computer and use it in GitHub Desktop.
HTTP/2 Issue #362

BLOCKED frame should be added #362

背景

  • フロー制御の実装におけるバグを見つけることは非常に難しい
    • なぜクライアントやサーバーはデータの送信をやめたのか
    • いったい何が起きているのか
  • ストリームの同時並列数の制限にあった場合も何がおきているのか分かりにくい
  • このように処理がブロックされた場合は、明示的な通知が欲しい

対応案

  • BLOCKED フレームを導入する
    • ブロック状態になった場合は BLOCKED フレームを送信して、何が起きているかを通知する
  • データの伝え方案
    • 案1: 8ビットのペイロードを用意し、そこに値を入れる
    • 案2: フレームヘッダーのフラグで通知する

意見

  • ウインドウサイズなどは推測できるのでは? (Mike Belshe)
  • 同時並列数の制限はあまり有益ではない (Mike Belshe)
  • フレームとしては過剰じゃない? (Mike Belshe)
  • おそらく適切に生成することが難しい (Martin)
  • このフレームの価値は理解できるが、プロトコルにではなく専用のツールのようなものを作ったほうがいい (Martin)
  • この段階で新しいフレームを入れるのには懐疑的 (Patrick McManus)
  • DoS攻撃を防ぐ方法を考える必要もある (Patrick McManus)

意見への反応

  • バギーな実装や、一方のTCPの状態がわからない場合の問題に解決するのに役に立つ
  • 変化するネットワークの状況にあわせてセッションやストリームのフロー制御を動的にチューニングするのにも有用
  • 問題が起きた時に情報を取得できなければ意味がないので、別のツールを構築するのは非現実的

提案されている仕様

6.x BLOCKED

The BLOCKED frame (type=0xPLACEHOLDER) conveys flow control and data
availability status useful in tuning and debugging flow control.

The BLOCKED frame contains no payload and does not define any flags.
Semantically the BLOCKED frame is used to indicate to a remote endpoint
that data subject to flow control was available to be sent, and that the
underlying transport was ready to send said data, but was prohibited from
sending said data due to either stream-level or connection-level flow
control windows being nonpositive. The specific flow control window
prohibiting the sending of said data is indicated in the stream id of the
BLOCKED frame. In the stream-level flow control blockage case, the frame's
stream identifier indicates the affected stream; otherwise the value "0"
indicates connection-level flow control blockage.

Endpoints MUST NOT send a successive BLOCKED frame on a given stream id
(including "0") unless the associated flow control window became positive
since the last time that a BLOCKED frame for that flow control window was
sent. This can happen only as a result of receiving a WINDOW_UPDATE frame
or appropriate SETTINGS frame increasing said flow control window. (TODO:
Add reference to appropriate sections of flow control spec?) (TODO: Add
GOAWAY-ENHANCE_YOUR_CALM usage here as appropriate behavior in this case?)

BLOCKED can be sent by a peer that has sent a frame bearing the END_STREAM
flag. This means that a receiver could receive a BLOCKED frame on a "half
closed (remote)" or "closed" stream. A receiver MUST NOT treat this as an
error, see Section 5.1.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment