5.7.2 TCP的传输效率

应用进程把数据传送到TCP的发送缓存后，剩下的发送任务 就由TCP来控制。

TCP有3种机制来控制TCP报文段的发送时机： 1、TCP维持 一个变量 ，等于 最大报文段长度MSS 。只要缓存中的数据达到MSS字节，就组装成一个TCP报文段发送出去。 2、由 发送方的应用进程 指明要求发送报文段，即TCP支持的 推送（PUSH）操作 。 3、发送方的一个 计时器期限 到了，这时就把 当前已有的缓存数据 装入报文段（长度不能超过MSS）发送出去。

如何控制TCP发送报文段的时机仍然是一个较为复杂的问题。如： 一个用户使用一条TELNET连接（运输层为TCP）。 若用户只发一个字符，加上20字节的首部得到21字节长的TCP报文段。再加上20字节的IP首部形成41字节长的IP数据报。 接收方TCP收到后立即发回确认，构成的数据报是40字节长（假定无数据发送）。 如此线路上需传送总长度为81个字节，2个报文段。只有1个数据字节，效率很低。 若发送方再发送一个只含一个字节数据的报文段，41字节发出去，40字节确认回来 如此线路上需传送总长度为162个字节，4个报文段。只有2个数据字节，效率很低。 因此最好适当推迟发回确认报文，并尽量使用捎带确认的方法。

TCP的实现中广泛使用Nagle算法： 给发送端的TCP使用的。 若发送应用进程把要发送的数据逐个字节地送到TCP的发送缓存，则发送方就把 第1个数据字节 先发送出去，把 后面到达的数据字节 都缓存起来。 当发送方收到对 第1个数据字符 的确认后，再把 发送缓存中的所有数据 组装成1个报文段发送出去，同时继续对随后到达的数据进行缓存。 只有在收到 对前一个报文段的确认 或者 数据已经积累到可以组装成一个最大的报文段 后才继续发送下一个报文段。重复这一步。 当数据到达较快而网络速率较慢时，用这样的方法可以减少所使用的网络带宽。（因为是收到前一个确认后再发送而不是用自己的定时器计时） Nagle既考虑了应用进程产生数据的速率，也考虑了网络传输数据的速率。

糊涂窗口综合征 TCP的接收方的缓存已满，而接收应用进程每次只从接收缓存中读取1个字节（如此接收缓存空间仅腾出1个字节），然后向发送方发回确认，设置窗口为1字节。 接着发送方又发来1个字节的数据（对应的IP数据报为41字节长）。接收方应用进程接收并发回确认，仍然将窗口设置为1字节长。 如此一字节一字节地通信，网络效率很低。

糊涂窗口综合征产生的条件是：当发送方应用进程产生数据很慢，或者接收方应用进程读取数据很慢，或者二者都有。 此时发送方和接收方都有可能产生糊涂窗口综合征。使得发送或接收的报文段很小。 如发送端为产生数据很慢的应用进程服务。应用进程一次只产生一个字节进入到TCP的发送缓存。TCP发送的报文段只包含一个字节的数据，意味着一个41字节的数据报（20字节的TCP首部和20字节的IP首部）才传送1字节的数据。数据的传送效率是 1 / 41

解决糊涂窗口综合征的方法 1、让接收方等待一段时间，使得接收方接收缓存已有足够空间容纳一个最长的报文段，或者等到接收缓存已有一般空闲的空间。再发回确认报文。 2、发送方也不要发送太小的报文段，而是把数据累积成足够大的报文段（如达到接收方缓存空间的一般大小）再发送。 以上两种方法可配合使用。