TCP/IP 11成块数据流和交互数据流
现阶段使用TCP/IP的协议很多，这些协议又可以根据数据吞吐量来大致分成两大类：(1)交互数据类型，例如telnet，ssh。(2)数据成块类型，例如ftp，这种类型的协议要求TCP能尽量的运载数据，把数据的吞吐量做到最大，并尽可能的提高效率。针对不同的吞吐量，TCP给出了两种不同的策略来进行数据传输。
1、交互数据流
交互数据流常见的比如说按一下键盘，回显一下数据。这个过程中包括 发送按键的数据->接收服务端的ACK->服务端给出回显的数据->发送回显数据的ACK。
目前TCP给出的策略有两种：
一种是捎带ACK：这个策略是说，当主机收到远程主机的TCP数据报之后，通常不马上发送ACK数据报，而是等上一个短暂的时间，如果这段时间里面主机还有发送到远程主机的TCP数据报，那么就把这个ACK数据报“捎带”着发送出去，把本来两个TCP数据报整合成一个发送。一般的，这个时间是200ms。可以明显地看到这个策略可以把TCP数据报的利用率提高很多。
第二种是Nagle算法：这个算法的原理就是当主机处于等待ACK的状态时，发送缓冲区里面只能有一个TCP数据包，而且这个数据报会不断的收集后续的数据包，当收到ACK的时候，就把这个数据包一下子发出去。这样子确实可以降低网络负担，但是这种方法延迟可能会很高，因为每次都要等待ACK才发送。不过有发法可以关掉这个特性。
2、成块数据流
成块的数据流比较常见的就是FTP协议了，这种传输文件的，会很在意吞吐量而对于延迟来说，不敏感。
TCP中使用16bit的窗口大小来解决这个问题
1）一个ACK确认多个数据报
通常情况下，一个发送端发送一个数据报。接受端需要回复一个ACK，但是实际上发送端将会连续发送数据尽量填满接受方的缓冲区，而接受方对这些数据只要发送一个ACK报文来回应就可以了，这就是ACK的累积特性，这个特性大大减少了发送端和接收端的负担。想一下TCP的应答ACK就是下个期望的接受到的报文标号。
2）滑动窗口
接收方和发送方在发送数据之前会先协定一个滑动窗口，比如说窗口大小是2k，发送方维护这个窗口，也就是说发送的数据最大会在2k，指导接收到接受方的ACK。才会继续发送。也是就是说这里的数据已经确认到达了，才会继续发送。
3）数据拥塞
上面的策略用于局域网内传输还可以，但是用在广域网中就可能会出现问题，最大的问题就是当传输时出现了瓶颈（比如说一定要经过一个slip低速链路）所产生的大量数据堵塞问题（拥塞），为了解决这个问题，TCP发送方需要确认连接双方的线路的数据最大吞吐量是多少。这，就是所谓的拥塞窗口。
拥塞窗口的原理很简单，TCP发送方首先发送一个数据报，然后等待对方的回应，得到回应后就把这个窗口的大小加倍，然后连续发送两个数据报，等到对方回应以后，再把这个窗口加倍（先是2的指数倍，到一定程度后就变成现行增长，这就是所谓的慢启动），发送更多的数据报，直到出现超时错误，这样，发送端就了解到了通信双方的线路承载能力，也就确定了拥塞窗口的大小，发送方就用这个拥塞窗口的大小发送数据。要观察这个现象是非常容易的，我们一般在下载数据的时候，速度都是慢慢“冲起来的