应用程序调用send后，用这些接口并不意味着数据被真正发送到网络上，其实，这些数据只是从应用程序中被拷贝到了系统内核的套接字缓冲区中，或者说是发送缓冲区中 ，至于这些数据是什么时候被发送出去的，对应用程序来说，是无法预知的。对这件事情真正负责的，是运行于操作系统内核的 TCP 协议栈实现模块，决定什么时候发送出去， 还要取决于3个窗口——发送窗口、接收窗口、拥塞窗口
以客户端向服务器端发送消息为例，在某一个时刻可能由于服务器端处理消息的能力变弱，接收窗口变小，当接收窗口变小，则同时调整发送窗口大小， 不然客户端不管不顾地把数据包都传发送过来。如果都发送过来，服务器端来不及处理，必然会丢弃；而丢弃反过来使得客户端又重传，发送更多的数据包，最后导致网络崩溃
使用发送窗口、接收窗口使得TCP的可靠机制得到更强的保证，发送窗口、接收窗口是点与点之间的调整，是针对一个特定的连接
上述的发送窗口、接收窗口是针对一个特定的连接，那么服务器端程序有可能维护着成千上万个连接，那么就导致所有的连接发送的数据要在有限的带宽上传输，那么就有可能产生拥塞，对拥塞控制是通过拥塞窗口来完成的
在 TCP 协议中，拥塞控制是通过拥塞窗口来完成的，拥塞窗口的大小会随着网络状况实时调整
对拥塞的控制有两个算法：
慢启动
慢启动通过一定的规则，慢慢地将网络发送数据的速率增加到一个阈值。超过这个阈值之后，慢启动就结束了
拥塞避免
TCP 会不断地探测网络状况，并随之不断调整拥塞窗口的大小
所以一个消息能不能发送出去，至少取决于两个因素，一个是当前的发送窗口大小，另一个是拥塞窗口大小，而 TCP 协议中总是取两者中最小值作为判断依据
例如当前发送的字节为 200，发送窗口的大小是 300，拥塞窗口的大小是 100，那么取 300 和 100 中的最小值，就是 100，当前发送的字节数显然是大于拥塞窗口的，结果就是不能发送出去
发送窗口反应了作为单个TCP 连接、点对点之间的流量控制模型，它是需要和接收端一起共同协调来调整大小的
拥塞窗口则是反应了作为多个 TCP 连接共享带宽的拥塞控制模型，它是发送端独立地根据网络状况来动态调整的