前言
建立在TCP协议上的应用层协议有非常多，如FTP、HTTP、Telnet等，这些协议依据数据传输的多少能够分为两类：交互数据类型和成块数据类型。
交互数据类型，如：Telnet，这类协议一般仅仅做小流量的数据交换。比方每按下一个键，要回显一些字符。
成块数据类型。如：FTP，这类协议须要传输的数据比較多。一般传输的数据量比較大。
针对这两种不同的情况，TCP採用不同的策略进行数据传输。
交互数据流
针对交互性要求比較高的应用，比方Rlogin远程登录中，须要回显client输入的字符，每发送一个字节到服务端。并回显到client的步骤例如以下：
1、client产生一个41bit长的报文（20字节的IP首部。20字节的TCP首部，1字节的数据）。发送到服务端；
2、服务端发送过来一个40bit的确认报文。
3、服务端发送回显的字符。报文长为41bit；
4、client发送确认报文。报文长为40bit。
假设在局域网中，通常不会有什么麻烦，由于局域网一般不会出现拥塞，但在广域网中。这些小分组则会添加网络拥塞出现的可能。为了提高这类数据的发送效率和降低网络负担，TCP採用了两种策略：捎带ACK和Nagle算法。
捎带ACK
捎带ACK的意思是，当接收端接收到TCP报文段后，并不马上发送ACK报文，而是等上一段时间，假设这段时间里该主机有数据要发送到远程主机，就将该数据捎带上ACK一起发送过去，非常明显。这样能够降低传输开销。为了防止产生超时重传。绝大多数情况下。这个等待时间为200ms，超过了200ms，假设没有数据要一起发送。就直接发送ACK报文。
捎带ACK的策略一般也仅仅有在交互性比較高的应用中才会使用，对于成块数据流，一般大多数应用程序不会同一时候在两个方向上发送数据。
Nagle算法
该算法的重点是要求在TCP连接上组多仅仅能有一个未被确认的数据报在传输。
算法的大致思路例如以下：应用程序把要发送的数据逐个字节地从到TCP的发送缓存，发送方把线面的一部分数据先发送出去。并把后面到达的字节继续缓存起来，当发送方收到前面字节的确认后，再把发送缓冲中的全部数据组装成一个报文段发送出去。同一时候继续对随后到来的数据进行缓存。仅仅有收到前一个报文段的确认后才干继续发送下一个报文段。另外。Nagle算法还规定，当发送缓存中的数据已达到发送窗体大小的一半或已达到报文段的MSS值时，就马上发送一个报文段。
当数据到达较快而网络速率较慢时，用这样的方法可明显地降低所用的网络带宽。非常明显。该算法也是专门为交互性高的应用而设计的，对于成块数据流。假设每收到一次确认才干发送下一个报文段。那么传输速率就会非常低。
成块数据流
对于一些数据吞吐量要求较高的应用，总是希望每次发送尽可能多的数据到主机。对于这类应用，TCP使用滑动窗体协议，该协议同意发送方在停止发送前和等待确认前能够连续发送多个分组，因此能够加速数据的传输。
滑动窗体
滑动窗体的滑动是以字节为单位的。发送方A和接收方B在TCP三次握手的前两次握手时协商好了发送窗体和接受窗体的大小，发送方A依据B发送来的确认连接报文中标明的窗体的大小。来确定收到确认前的最大发送数据量。假设A接收到的B发来的确认报文中标明的窗体大小为0。则停止发送数据。直到收到不为0的确认报文，再继续发送。发送窗体表示在没有收到B的确认的情况下，A能够连续把窗体内的数据都发送出去，凡是已发送过的数据，在没有收到确认前都要临时保留。以便超时重传时使用。
须要注意的一点是：使用TCP滑动窗体协议时，接收方不必确认每个收到的分组。在TCP中。ACK确认是累积的，能够在接收到几个序号连续的报文段后仅仅发送一个ACK确认报文，但累积等待的时间最长不能超过0.5秒，以防止发送端超时重传。
另外，要注意滑动窗体的三种变化：
1、窗体合拢。窗体左边沿向右边沿靠近。这样的情况发生在数据被发送后收到确认时；
2、窗体张开。窗体右边沿向右移动，说明同意发送很多其它的数据。这样的情况发生在还有一端的接收进程从TCP接收缓存中读取了已经确认的数据时。
3、窗体收缩。
窗体右边沿向左移动，一般非常少发生，RFC也强烈不建议这么做，由于非常可能会产生一些错误。比方一些数据已经发送出去了，又要收缩窗体，不让发送这些数据。
另外，窗体的左边沿是肯定不可能左移的，假设接收到一个指示窗体左边沿向左移动的ACK，则它被觉得是一个反复ACK。并被丢弃。
总结下面几点：
1、发送方不必发送一个全窗体大小的数据，一次发送一部分就可以。
2、窗体的大小能够减小。可是窗体的右边沿却不能向左移动。
3、接收方在发送一个ACK前不必等待窗体被填满。
4、窗体的大小是相对于确认序号的。收到确认后的窗体的左边沿从确认序号開始。
发送接收缓冲区
本部分主要明白一下几点：
1、缓冲空间和序号空间都是有限的，而且都是循环使用的。
2、窗体大小一定不大于收发缓冲区的大小
3、发送缓冲区用来暂存发送方准备发送的TCP报文段和已发送但尚未收到确认的数据。
4、接收缓冲区用来暂按序到达但尚未被上层应用程序读取的数据合未按序到达的数据。
版权声明：本文博客原创文章，博客，未经同意，不得转载。