首页 > 代码库 > 《TCP/IP具体解释》读书笔记（20章）－TCP的成块数据流
《TCP/IP具体解释》读书笔记（20章）－TCP的成块数据流
眼下建立在TCP协议上的网络协议特别多，有telnet。ssh，有ftp。有http等等。这些协议又能够依据数据吞吐量来大致分成两大类：(1)交互数据类型，比如telnet，ssh。这样的类型的协议在大多数情况下仅仅是做小流量的数据交换，比方说按一下键盘，回显一些文字等等。(2)数据成块类型。比如ftp。这样的类型的协议要求TCP能尽量的运载数据，把数据的吞吐量做到最大。并尽可能的提高效率。
针对这两种情况，TCP给出了两种不同的策略来进行传输数据。
本章介绍TCP所使用的被称为窗体协议的还有一种形式的流量控制方法。
该协议同意发送方在停止并等待确认前能够连续发送多个分组。由于发送方不必每发一个分组就停下来等待确认，因此该协议能够加速数据的传输。
1.隔一个报文段确认策略
TCP处理一个接收的报文将产生一个经受时延的确定，此ACK并不马上返回。这时分两种情况（隔一个报文或者定时器溢出）：
(1)TCP处理下一个报文。然后返回一个ACK确定2个报文段(能够想象成捎带ACK)。
(2)定时器溢出，返回ACK。假设溢出时。TCP接收缓冲区中还有数据没有被应用层读取完，那么返回报文段的窗体值将为初始窗体值减去缓冲区中的值。
2.滑动窗体协议
窗体移动:(1)窗体左边沿向右边沿靠近为窗体合拢。
(2)窗体右边沿向右边移动为窗体张开。
(3)窗体右边沿向左边移动为窗体收缩。RFC强烈建议不要使用这样的方式
假设左边沿到达右边沿。则称其为一个0窗体，此时发送方不能够发送不论什么数据。
来自接收方的一个报文段确认数据并把窗体向右边滑动。这是由于窗体的大小是相对于确认序号的。
窗体大小由进程控制。插口API同意进程设置发送和接收缓存的大小。接收缓存的大小是该连接上所能够通告的最大窗体大小。发挥TCP传输性能。TCP就是用这个窗体。慢慢的从数据的左边移动到右边，把处于窗体范围内的数据发送出去（但不用发送所有，仅仅是处于窗体内的数据能够发送。
）。
这就是窗体的意义。图20-6解释了这一点。窗体的大小是能够通过socket来制定的，4096并非最理想的窗体大小，而16384则能够使吞吐量大大的添加。
滑动窗体是用来加速传输数据。
TCP要保证“可靠”。就须要对一个数据包进行ack确认表示接收端收到（窗体张开）。有了滑动窗体，接收端就能够等收到很多包后仅仅发一个ack包。确认之前已经收到过的多个数据包。
有了滑动窗体，发送端在发送完一个数据包后不用等待它的ack，在滑动窗体大小内能够继续发送其他数据包（窗体合拢）。
发送的数据TCP包都有一个序号。
它是这么计算的：最初发送SYN时，有一个初始序号，依据RFC的定义。各个操作系统的实现都是与系统时间相关的。之后，序号的值会不断的添加，比方原来的序号是100，假设这个TCP包的数据有10个字节，那么下次的TCP包序号会变成110。
滑动窗体用于加速传输，比方发了一个seq=100的包，理应收到这个包的确认ack=101后再继续发下一个包。但有了滑动窗体。仅仅要新包的seq与没有得到确认的最小seq之差小于滑动窗体大小。就能够继续发。
由于窗体的左边沿受还有一端发送的确认序号的控制，因此不可能向左边沿移动。假设接收到一个指示窗体左边沿向左移动的ACK，则它被觉得是一个反复的ACK，并被丢弃。
下图展示了发送窗体与接收窗体滑动：
下图展示滑动窗体占满。窗体不能向右滑动。临时不能发送数据包。
3.PUSH标志
发送方使用该标志通知接收方将所收到的数据所有提交给接收进程。这里的数据包含与PUSH一起传送的数据以及接收方TCP已经为接收进程收到的其他数据。
(1)发送方将发送缓冲区的数据马上发送给接收方。
(2)接收方将接收缓冲区的数据马上提交给接收进程。
假设待发送数据会清空发送缓冲区，该包将自己主动设置PUSH标志。
4.慢启动(拥塞窗体)
假设发送方和接收方之间存在多个路由器和速率较慢的链路时，一些中间的路由器必须缓存分组，并有可能耗尽存储器的空间，这样的连接方式会严重减少了TCP连接的吞吐量。
拥塞窗体（cwnd）原理：
1）发送方開始发送一个报文。然后等待ACK。
2）当收到该ACK时。拥塞窗体从1添加到2，即能够发送2个报文段。
2）发送方再发送2个报文段，然后等待ACK，当收到这两个报文段的ACK时。拥塞窗体就添加为4。
这是一种指数添加的关系。
如此循环.....
在某些点上可能达到了互联网的容量。于是中间路由器開始丢弃分组，这就通知发送方它的拥塞窗体开得过大。
慢启动算法用于保证新分组进入网络的速率与还有一端返回确定的速率相等。
拥塞窗体是发送使用的流量控制。通告窗体是接收方使用的流量控制。
5.紧急方式
TCP提供了“紧急方式”，它使一端告诉还有一端有些具有某种方式的“紧急数据”已经放置在普通的数据流中。还有一端被通知这个紧急数据已被放置在普通数据流中，由接收方决定怎样处理。
能够设置TCP首部中的两个字段来发出这样的从一端到还有一端的紧急数据已经被放置在数据流中的通知。URG比特被置为1，而且一个16bit的紧急指针放置为一个正的偏移量，该偏移量必须与TCP首部中的序号字段相加，以便得出紧急数据的最后一个字节的序号。
紧急方式最常见的样例是Telnet和Rlogin，从server到client使用紧急方式是由于在这个方向上的数据流非常可能要被客户的TCP停止（即，client通告了一个大小为0的窗体）可是假设server进程进入紧急方式，虽然它不能够发送不论什么数据，serverTCP也会马上发送紧急指针和URG标志。当客户TCP接收到这个通知时就会通知客户进程，于是客户能够从server读取其输入、打开窗体并使数据流动。
作者原创。转载请标明原处：http://blog.csdn.net/xifeijian/article/details/44260995
《TCP/IP具体解释》读书笔记（20章）－TCP的成块数据流