网络编程学习10TCP动态数据传输由前面所学的知识可知，在调用write或send等发送数据的接口后，并不意

发送窗口和接收窗口分别属于TCP连接的双方，一个作为生产者，一个作为消费者，它们之间需要达到一致协同的生产-消费速率。流量控制只考虑单个连接的数据传递。

由于TCP数据包需要经过网卡、交换机、核心路由器等一系列的网络设备，并且网络设备本身的能力也是有限的，当多个连接的数据包同时在网络上传送时，势必会发生带宽争抢、数据丢失等情况，所以，TCP就必须考虑在多个连接共享的有限带宽上，兼顾效率和公平性的控制，这就是拥塞控制。

拥塞控制是通过拥塞窗口来完成的，拥塞窗口的大小会随着网络状况实时调整。

综上，在任何一个时刻，TCP发送缓冲区的数据能否真正发送出去，至少取决于两个因素，一个是当前的发送窗口的大小，一个是当前的拥塞窗口的大小，并且TCP协议中总是取两者的最小值为判断依据。

发送窗口是作为单TCP连接、点对点之间的流量控制模型，需要和接收端一起共同协调来调整大小。拥塞窗口则是反应了作为多个TCP连接共享带宽的拥塞控制模型，它是发送端独立地根据网络状况来动态调整的。

糊涂窗口综合症是指当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小；极端情况下，有效载荷可能只有1个字节；传输开销有40字节(20字节的IP头+20字节的TCP头)这种现象。

如果发送端为产生数据很慢的应用程序服务(典型的有telnet应用)，例如，一次产生一个字节。这个应用程序一次将一个字节的数据写入发送端的TCP的缓存。如果发送端的TCP没有特定的指令，它就产生只包括一个字节数据的报文段。结果有很多41字节的IP数据报就在互连网中传来传去。

Nagle算法：其本质是限制大批量的小数据包同时发送，为此，它提出，在任何一个时刻，未被确认的小数据包不能超过一个。这里的小数据包，指的是长度小于最大报文段长度MSS的TCP分组。这样的话，发送端就可以把接下来连续的几个小数据包存储起来，等待接收到前一个小数据包的ACK分组之后（或者累积到一个最大报文段），再将数据一次性发送出去。

如果TCP接收方的缓存已满，而交互式的应用进程一次只从接收缓存中读取1字节（这样就使接收缓存空间仅腾出1个字节），然后向发送方发送确认，并把窗口设置为1个字节，这样的话，发送方就只能发来一个字节的数据（但是，发送方发送的IP数据报是41字节长）。接收方发回确认，仍然将窗口设置为1个字节，这样进行下去，会使网络的效率很低。

Clark解决方法：只要有数据到达就发送确认，但宣布的窗口大小为零，直到缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了。

延迟确认：当一个报文段到达时并不立即发送确认。接收端在确认收到的报文段之前一直等待，直到缓存有足够的空间为止。

场景：接收端对每个接收到的TCP分组进行确认，也就是发送ACK报文，但是ACK报文本身是不带数据的分段，如果一直这样发送大量的ACK报文，就会消耗大量的带宽。之所以会这样，是因为TCP报文、IP报文固有的消息头是不可或缺的。

上述问题可以通过时延ACK解决，时延ACK在收到数据后并不马上回复，而是累计需要发送的ACK报文，等到有数据需要发送给对端时，将累计的ACK捎带一并发送出去。当然，时延ACK机制并不能无限延时，否则会让发送端认为发送没有成功，导致重传。

这样的话，Nagle算法和延时确认组合在一起，增大了处理时延，实际上，两个优化彼此在阻止对方。

所以，对于时延敏感的应用，Nagle算法并不适用，此时可以通过修改套接字来关闭Nagle算法。

iovec结构体的定义如下：

structiovec{void*iov_base;/*内存起始地址*/size_tiov_len;/*这块内存的长度*/};由上可见，iovec结构体封装了一块内存的起始位置和长度。一般都会定义一个存放iovec类型的数组，数组中的每一个元素代表一块分散的内存。

readv函数将数据从文件描述符读到分散的内存块中，即分散读；writev函数则将多块分散的内存数据一并写入文件描述符中，即集中写，它们的函数定义如下：

readv和writev在成功时返回读出/写入fd的字节数，失败返回-1并设置errno。它们相当于简化版的recvmsg和sendmsg函数。