TCP/IP详解-交互数据流和成块数据流

TCP传输的数据分为成块数据和交互数据。按字节算，成块数据约占90%

1 交互式输入
交互式数据报文所含数据量少

其中数据字节的确认和数据字节的回显可以合并为一个报文

tcpdump输出：

2 经受时延的确认

通常TCP在接收到数据时并不立即发送ACK；相反，它推迟发送，以便将ACK和需要沿该方向发送的数据一起发送，绝大多数实现采用的时延为200ms

观察到每次发送ACK的实际时间之差为200ms的整数倍，TCP采用200ms的定时器。
由于将要确认的数据是随机到达（如时刻16.4,47.3等），TCP在200ms定时器的下一次溢出发送ACK

3 Nagle算法
上一节中，传输41字节分组：20字节的ip首部，20字节的TCP首部和1字节的数据。在广域网上，这些小分组会增加拥塞的可能

Nagle算法要求一个TCP连接上最多只能有一个未被确认的未完成的小分组，该分组的确认到达之前不能发生其他的小分组。该算法优点：自适应的，确认达到得越快，数据发送也就越快

报文段12是经受时延的ACK，但该ACK不包含任何数据。当时服务器一定非常忙，无法在定时器溢出前及时处理收到的字符

报文段14的确认序号是54，是报文段12中确认的应答。但在发送报文段14之前，接收了报文段13，报文段15是报文段13中确认的应答

当小消息必须无延时地发送（如鼠标移动）的情况下，需要关闭Nagle算法

例子：
打开Nagle算法：

关闭Nagle算法：

报文段4带有来自服务器的第5个字节以及确认序号为4的ACK。然而客户不希望接收第5个字节，因此发送确认序号为2而不是6的响应（没有被延迟）

报文段5期望的下一个字节是第2个字节（每当TCP接收到一个超出期望序号的失序数据时，它总是发送一个确认序号为期望序号的确认），因为丢失分组中的第2,3,4字节，表明服务器已经接收到报文段2

重传的报文段6中包含丢失的报文中的数据和报文段4，这被称为重新分组化

4 正常数据流

报文段7的ACK的序号之所以是2049而不是3073是由以下原因造成的：当一个分组到达时，它首先被设备中断例程进行处理，然后放置到I P的输入队列中。三个报文段4、5和6依次到达并按接收顺序放到I P的输入队列。IP将按同样顺序将它们交给TCP。当TCP处理报文段4时，该连接被标记为产生一个经受时延的确认。TCP处理下一报文段（5），由于T C P现在有两个未完成的报文段需要确认，因此产生一个序号为2048的ACK（报文段7），并清除该连接产生经受时延的确认标志。TCP处理下一个报文段（ 6），而连接又被标志为产生一个经受时延的确认。在报文段9到来之前，由于时延定时器溢出，因此产生一个序号为3073的ACK（报文段8）。报文段8中的窗口大小为3072，表明在TCP的接收缓存中还有1024个字节的数据等待被应用程序读取。

隔一个报文确认策略：报文段11,12和13到达并被放入IP的接收队列，当报文段11被处理，连接被标记为产生一个经受时延的确认。当报文段12被处理，他们的ACK被产生且连接的经受时延的确认标志被清除。报文段13使得连接再次被标记为产生经受时延，但在延时定时器溢出之前，报文段15被处理完，因此确认立刻发出

另一种时间序列：

另一种时间序列（快的发送方和慢的接收方）:

5 滑动窗口

不支持窗口右边沿向左移动以及左边沿向左移动
当左边沿达到右边沿，则称为零窗口

1)发送方不必发送一个全窗口大小的数据
2)来自接收方的一个报文段确认数据并把窗口向右滑动
3)窗口大小可以减小，但右边沿不能向左移动
4)接收方在发送一个ACK前不必等待窗口被填满

6 窗口大小

7 PUSH标志
发送方使用PUSH标志通知接收方将所收到的数据全部提交给接收进程，这里的数据包括与PUSH一起传送的数据以及接收方TCP已经为接收进程收到的其他数据

7 慢启动
发送方一开始便向网络发送多个报文段，直至达到接收方通告的窗口大小为止。这种方式在局域网可以，但在广域网会出现很多问题

慢启动为发送方的TCP增加另一个窗口：拥塞窗口，记为cwnd

拥塞窗口初始化为1一个报文段，每接收到一个ACK，拥塞窗口就增加一个报文段。发送方取拥塞窗口和通告窗口中的最小值为发送上限。

拥塞窗口是发送方使用的流量控制，通告窗口是接收方使用的流量控制

8 成块数据吞吐量

时间31及其后续时间，发送方和接收方之间的管道被填满，此时无论拥塞窗口和通告窗口是多少，都不能容纳更多的数据

大管道向小管道发送报文情况：

9 紧急方式
紧急方式告诉另一端有某种方式的”紧急数据”已经放置在普通的数据流中，由另一端决定如何处理

URG比特置为1,16bit的紧急指针被置为一个正的偏移地址。偏移量与TCP首部中的序号相加，得出紧急数据的最后一个字节的序号

TCP必须通知接收进程，何时已接收到一个紧急数据指针以及何时某个紧急数据指针还不
在此连接上，或者紧急指针是否在数据流中向前移动。接着接收进程可以读取数据流，并必须能够被告知何时碰到了紧急数据指针。只要从接收方当前读取位置到紧急数据指针之间有数据存在，就认为应用程序处于“紧急方式”。在紧急指针通过之后，应用程序便转回到正常方式。

Telnet和Rlogin从服务器到客户使用紧急方式是因为在这个方向上的数据流很可能要被客户的TCP停止（也即，它通告了一个大小为0的窗口）。但是如果服务器进程进入了紧急方式，尽管它不能够发送任何数据，服务器TCP也会立即发送紧急指针和URG标志。当客户T C P接收到这个通知时就会通知客户进程，于是客户可以从服务器读取其输入、打开窗口并使数据流动。

例子:

第一个ACK在应用进程写1个字节并进入紧急方式时被发送

第二个和第三个ACK在应用进程写最后两个1024字节数据时发送

第四个ACK在应用进程关闭其TCP连接时被发送，发送应用程序在启动几毫秒后终止在
接收方应用进程已经发出其第一个写操作之前。TCP将所有的数据进行排队，并在可能时发送出去

第五个ACK很可能是接收第四个ACK是产生的

TCP对应用进程写的数据进行重新分组化。当进入紧急方式时待输出的1个字节与缓存中的后面1023个字节一同发送