HTTP/2 Flow Control 经验
感觉这个东西一般的开发者驾驭不了. 在驾驭不了的情况下需要知道它的限制.
1 建立 connection 设定对 stream 和 connection 的 window size (SETTINGS_INITIAL_WINDOW_SIZE).
初始值是 64 KB (减 1 字节). 一般为了方便起见用 (2^N) - 1 形式.
如果在对方发送数据后更改了的话 window 可能会变成负数, 这仅限于第一次交互时才可能发生.
2 WINDOW_UPDATE 起到类似 ACK 的作用, 收到多少数据就发回去允许对方加量.
但是**一般的实现**都是同等数量恢复, 而不像 TCP 那样会慢慢扩大窗口.
这就出现问题了, 如果窗口不变的话, 最大传输速度就和 latency 成反比了.
所以客户端应该设定一个较大的 window size, 但也不能过大 (感觉 N 等于 19 是一个不错的值).
其实正常情况下是不太需要调整 N 的,
但是考虑到某朝神奇的网络状况的话, 应该能想到 WINDOWS_UPDATE frame 可能会丢失,
这个 frame 丢失走 TCP 重传的话需要一定时间, 要保证对方在这个恢复时间内还能够维持发送,
这就是偶认为应当调整这个值的意义.
对于 nghttpx 的 proxy 模式 (-p) 来说, 推荐的参数就是 --backend-http2-window-bits=19 --backend-http2-connection-window-bits=19
1 建立 connection 设定对 stream 和 connection 的 window size (SETTINGS_INITIAL_WINDOW_SIZE).
初始值是 64 KB (减 1 字节). 一般为了方便起见用 (2^N) - 1 形式.
如果在对方发送数据后更改了的话 window 可能会变成负数, 这仅限于第一次交互时才可能发生.
2 WINDOW_UPDATE 起到类似 ACK 的作用, 收到多少数据就发回去允许对方加量.
但是**一般的实现**都是同等数量恢复, 而不像 TCP 那样会慢慢扩大窗口.
这就出现问题了, 如果窗口不变的话, 最大传输速度就和 latency 成反比了.
所以客户端应该设定一个较大的 window size, 但也不能过大 (感觉 N 等于 19 是一个不错的值).
其实正常情况下是不太需要调整 N 的,
但是考虑到某朝神奇的网络状况的话, 应该能想到 WINDOWS_UPDATE frame 可能会丢失,
这个 frame 丢失走 TCP 重传的话需要一定时间, 要保证对方在这个恢复时间内还能够维持发送,
这就是偶认为应当调整这个值的意义.
对于 nghttpx 的 proxy 模式 (-p) 来说, 推荐的参数就是 --backend-http2-window-bits=19 --backend-http2-connection-window-bits=19
