TCP协议(上）中. 他讲述了其保证算法
包顺序发送(TCP头的第二行序号)缓存
包丢失会重传(第三行有确认序号.响应超时会重发)网络
拥塞控制
拥塞控制.对客户端：它要保证发送的频率,若是太快会撑死，太慢却没有物尽其用！对服务端：她得告诉对方本身的效率是多少(一次能处理多少个请求分别多少时间.若是超出本身的范畴直接不接收这就致使丢包)spa
咱们怎么知道服务端的极限呢，咱们能够看到TCP头的第四行-16位窗口大小.叫Advertised window。超过这个窗口大小服务端就作不来这时客户端就别再发送了.blog
客户端四种状态
1.已发送并已确认class
2.已发送但未确认效率
3.未发送待发送(可发送）sed
4.未发送不发送(不可发送)请求
这里窗口大小为二、3状态的合(即上图紫色部分的总和)程序
服务端三种状态
1.已确认.等待应用程序处理
2.已收到.但未确认
3.还没有收到
理想状况下,上述就能在网络中完整的传输.但现实每每是很骨感的。
好比客户端是连续发送的包.有的包丢了(压根没到服务端).
有的包服务端收到了并进行ACK但途中丢了(这时服务端又得重发).
再者网络状态不稳定的状况.也要适当的调整窗口大小
客户端发送的包若是没有回复就会超时重试.那超时时间如何取值呢.这时间必须大于往返时间RTT的值.不然会引发没必要要的重传.也不宜过长，这样访问就变慢了.
这时就要用到自适应重传算法：采样RTT的波动范围，计算并估计一个超时的时间。
流量控制问题
咱们在对于包的确认中，同时会携带一个窗口的大小.好比窗口大小为9.即确保二、3状态(已发送未确认、待发送)总和为9便可
当有一些极端状况，好比服务端发送一个确认包.却不读取缓存的包，这时窗口应设置为8.若是这样下去.窗口最后变为0了.客户端直接啥都不用作。这时客户端会定时发送探测数据包.看服务端是否调整了窗口的大小以便继续发包出去
拥塞控制问题
最后的拥塞控制，也是经过窗口的大小来控制的，
前面的滑动窗口rwnd是怕发送方把接收方缓存塞满，用拥塞窗口cwnd，是怕把网络塞满