update.コメントを受けて一部修正しました。他、データの加算が間違っていたので修正。フロー制御HTTP2にはストリームで受信できるデータ量をコントロールするフロー制御という仕組みがあります。フロー制御では二つのことを決めています。(INITIAL_WINDOW_SIZE)(デフォルト65535)⚫️一つのストリームで受信できるデータ量(デフォルト65535)これは最初に交換するSETTINGフレームでクライアントとサーバーが取り決めます。その後に一つのストリームでデータを受信するたびに減っていきます。0になったらデータを受信することはできないので、WINDOW_UPDATEフレームで任意のバイト数を加算させます。0Kこのままではコネクション全体が0なのでストリームID1に余裕があっても受信できない。200Kこれで再び受信可能になる。70200Kコネクション全体を初期値より増やすことが可能つまり、受信時は両方減り、加算時は指定したものだけ加算します。youtubeでテストyoutbeでテストしてみたところ、データ受信量が多くて良いサンプルが採れました。nghttp2を使用してフロー制御の簡単な例を見てみました。h2-14NPNによりHTTP2ドラフト14が採用されました。続いてSETTINGフレームの交換が行われます。[SETTINGS_INITIAL_WINDOW_SIZE(0x04):65535]最初のやりとりの概要youtubeサーバーは自身が受け取るストリームの初期ウィンドウサイズが65535。自身が受け取る1回のフレームの最大サイズ(SETTINGS_MAX_FRAME_SIZE)が16384。そのすぐ後でWINDOW_UPDATEでコネクション全体のウィンドウサイズに983041を加算してアップデートしている。クライアントはストリームの初期ウィンドウサイズを65535に設定。headerここまでがACKの送受信、リクエストヘッダの送信とレスポンスヘッダの受信です。/」に対するbodyデータを受信しています。6553565535消費したので、クライアントのコネクション全体とストリームID1の初期ストリームウィンドウサイズが0になりました。(window_size_increment=33738)クライアント側からWINDOW_UPDATEフレームを送信して、ストリームID1とストリームID0(コネクション全体)のウィンドウサイズを加算させています。66689」なので、今のウィンドウサイズは66689になります。この時に送信できるサイズは「2^31」(2147483648)なので、nghttp2がなぜ2回に小分けにして送信しているのかは今のところ謎です。32951以下同じ流れ。opaque_data(0)=[])最終的にウィンドウサイズは65000程度を保つようになっているようです。受信ウィンドウの最大サイズは「2^31」(2147483648)で、WINDOW_UPDATEで加算させることができる最大サイズも「2^31」(2147483648)です。このような巨大な数字は今のところは見たことがないです。負の値を保持して待機する必要がある。フレームの受信時に、使用可能なフロー制御ウインドウを-44KBに再計算します。フレームが>ウインドウを正の値に戻すまで、負の値のフロー制御ウインドウを保持します。ウインドウが正の値に戻った後に、クライアントは送信を再開します。upLoginユーザーは見つかりませんでした。