TCP性能提高措施

1、滑动窗口
在确认应答机制中，接收方每接收到一个数据段，都要给发送方发送一个ACK应答报文，发送方在接收到应答报文后才继续发送下一个报文段，这样可保证数据传送的可靠性。但是这样做性能较差，尤其在数据往返时间较长的时候。
TCP中引入了滑动窗口机制，只要数据处于这个滑动窗口中，就可以在上一个数据段未收到确认时依然将后面的数据发送出去。这样就可以一次发送多条数据，就大大的提高了性能（其实是将多个段的等待确认时间重叠在了一起）。
采用滑动窗口方式发送数据的过程如下：

滑动窗口大小：指无需等待确认应答而可以继续发送发送数据的最大值。上图中的滑动窗口大小为4000个byte（即四个数据段）。
发送前四个段时无需等待任何ACK报文，直接连续发送；收到第一个ACK后，窗口向后移动一个段，发送第五个段，之后以此类推；操作系统为了维护这个滑动窗口，需要开辟一个发送缓冲区，其关系如下：

只有确认过的数据才能从缓冲区删掉。发送窗口工作过程：

当然也存在着接收窗口与接收缓存：

连接双方的接收窗口与发送窗口越大，则网络吞吐量越高。
2、快重传
无论何种情况都可能会产生丢包问题，那么这里没有经过确认就批量发送报文段如果发生丢包问题该如何解决呢？这里分两种情况讨论
a、在数据发送过程中产生丢包问题
这种情况下报文段没有成功传送到接收方，而因为有滑动窗口机制，所以发送方会继续发送后续报文段。但是接收方每次收到报文都只会对其收到的最后一个“有序”报文段进行确认，这样发送方就会不断地发送被丢失报文段后面的数据段，接收方不断发送对到达的“有序”报文段的最后一个报文段的确认报文，当发送方收到3个同样的确认应答时就进行重发。其过程如下：

b、应答报文丢失
接收方发送出的ACK报文也可能会在中途丢失，这样发送方就可能收不到前面发送的数据的确认报文，但是如果收到了后续报文段的ACK也会认为前面的报文段已经被接收方收到，这样就进行了确认。其过程为：

这种机制就叫做“高速重发控制”（也叫快重传）。

3、延迟应答
我们都知道，窗口越大，网络吞吐量就越大，传输效率越大，在保证网络不拥塞的情况下应尽量提高传输效率。
接收方在收到数据后，会对发送方发出应答报文ACK，现在假想这种情况：
假设接收缓冲区为1M，一次收到了500K数据；如果立即应答，那么返回的窗口就是500K。但实际上接收方处理接收窗口中数据的速度会很快，10ms内就可以把500K数据从缓冲区取出。这种情况下，很可能接收方还没有接收到下一个报文段缓冲区就又增大了，所以即使下一个报文段大于500K，接收缓冲区也能成功接收。如果接收方接收到第一个报文段后不立即返回，而是等待一会儿（比如再等200ms）再应答，那么返回的窗口大小就有1M。
这就是延迟应答。延迟应答的”延迟“限制：
数量限制：每隔N个包就应答一次。
时间限制：超过最大延迟时间就应答一次。
具体的数量和超时时间，依操作系统不同也有差异，一般N取2，超时时间取200ms。其过程如下：

延迟确认应答是能够提高网络利用率从而降低计算机处理负荷的一种较优的处理机制。

4、捎带应答
有时客户端与服务器之间的交互在应用层也是“一发一收”的，即接收方没收到报文段后，随机也给发送方发送数据。这种情况下就可以使用“捎带应答”机制，接收方的确认报文可以搭“顺风车”到发送方。实例如下：

注意：接收数据以后如果即可返回确认应答，就无法实现捎带应答。也就是说如果没有启动延迟应答就无法实现捎带应答。