发送方和接收方各自的处理速度不一样，如果发送方一味猛发，接收方的缓冲迟早会被填满，多出来的只能被丢掉。流控就是为了避免这种情况：接收方通过反馈告诉发送方，自己还能接多少。
这套反馈是加在传输层上的，与 IP 数据包本身不在同一个层次。报文只是载体，真正做决定的是这一层的窗口信息。理解了这一点，就不会把丢包和流控混为一谈。
- 接收方在 IP 层的应答里声明剩余缓冲空间
- 发送方据此调整在途未确认的数据量
- 缓冲将满时窗口收窄，自行降速
- 缓冲腾空后窗口恢复，速度随之回升
- 全过程不需要应用层介入
它和拥塞控制不是一回事
两者都表现为降速，成因却不同。流控看的是接收方还能不能接，属于端到端的协商；拥塞控制看的是路上堵不堵，由发送方根据丢包与时延做推断。前者有明确的反馈，后者只能靠推测。分开看，才能判断该扩接收端还是该换线路。
流控是对方接不下，拥塞是路上送不过去，两者的处理方向完全不同。把降速一律归到线路问题上，常常会漏掉接收端缓冲不足这一层。
代理链路带来的变化
走代理IP转发时，原本端到端的一次协商会被切成两段。本机与IP之间、IP与目标站之间各自有自己的一套窗口与节奏，两段的进度不一定同步。IP这一侧的缓冲如果偏小，就会成为整体速度的短板，而目标站那一侧看起来一切正常。代理IP链路里，两段协商中最窄的那一段决定了整体速度。
怎么判断卡在哪一段
看趋势比看单点有用。如果在途数据的量一直上不去，同时应答回来的窗口值很小，问题多半在接收侧；如果窗口一直很大却在途量上不去，才轮到怀疑线路。两种趋势对应两种处理，别混着改。
先确认窗口值，再讨论带宽，顺序反了容易把问题改到别的环节去。
调整时留意什么
缓冲区的大小、单次发送的量、以及确认的节奏，这三项相互牵连。只放大缓冲而不动节奏，效果有限；只加快节奏而不动缓冲，反而更容易触发丢弃。
窗口小是信号，不是病因。
把这些关系理清楚，遇到速度上不去的情况，就能按窗口、缓冲、线路的顺序逐项确认，不至于一上来就换代理IP。