TCP/IP具体解释学习笔记--TCP数据流

1.TCP的交互数据流

(1)基本概念

所谓交互数据流，其对TCP而言，就是他们所产生的大多数的TCP报文段中所包括的数据不超过10个字节。比如聊天等telnet的软件的TCP数据流就属于TCP交互数据流

(2)经受时延的确认

TCP收到数据时并不会立即发送数据。相反它会推迟数据的发送，以便让ack和该方向要发送的数据一起发送（搭个便车。不然ack就得自己自己组成一个数据段发送，这样有可能造成网络发生拥塞）,可是假设此方向一直没数据发送，那么ack就得一直等下去？当然不会，系统会给其定一个最长等待时间，一般为200ms超过这个时间，那么这个ack就必须得发出去了

(3)Nagle算法

设想这么一种情况，发送端每次发一个字节，而且连续发了好多次。那么假设每一个字节都组成一个TCP数据段，一个41字节大小的数据段仅仅装有1个字节。对与网络来说这也太占用资源了。所以我们应该但不是必须得在发送端设计某种发送送规则，如今最经常使用的就是Nagle规则了，Nagle规则相对简单点，它的规则大致是这样的，在一个TCP连接所相应的线路中最多仅仅能有一个未被确认的数据段，在该数据端的ack没来之前则不能发送数据,发送端在ack到来之前将小的字符流。组在一起，等ack到来时，则数据段已集结成大接近满载的数据段。此时将数据段发送出去。则利用率就会大幅提升。该算法的优越性在于它的自适应性。确认到达的越快，数据发的就越快，到达的慢就发的慢，在局域网内因为跳数较少，所以传输数据速度就会非常快。可是数据报中的数据较少。而在广域网里。因为跳数多，ack过来的时间非常慢，所以数据发送的相对慢点，可是与之相应的是，数据报所携带的数据差点儿是满载的。

    注意点:我们能够在应用程序设置套接字，将其设为TCP_NODELAY就会关闭Nagle算法，从而将要发的数据高速的发出去，此做法一般适用于即使交互类的软件

2.成块数据流

(1)滑动窗体

如上图所看到的

1，2，3为已经确认的数据，所以窗体以滑过他们，当接收方确认数据后，这个窗体不时的向右移动，窗体俩个边沿的相对运动添加或降低了窗体的大小，我们使用三个术语来描写叙述窗体的左右移动

(1)称窗体左边沿向右边沿移动为窗体合拢，这样的现象发生在数据被发送和确认时。

(2)当窗体右边沿向右移动时将同意发送很多其它的数据。我们称之为窗体张开，这样的现象发生在还有一端的接收进程读取已经确认的数据TCP的接收缓冲区

(3)当右边沿向左移动时称之为窗体收缩

(2)窗体大小

窗体大小由接收方来提供。默认的窗体大小为4096字节，可是在文件传输中未必高效。測试表明当窗体为16000时效率最高。大约能提高40%

(3)PUSH标志

发送方使用PUSH标志通知接收方将所收到的数据所有提交给接收进程。这里的所有包括PUSH之前已经收到的数据

(4)慢启动

所谓的慢事实上是对流量控制的一种算法，该算法通过观察到新分组进入网络的速率应该与接收端返回确认的速率同样而进行工作的

慢启动为发送方的TCP添加了一个拥塞窗体。当连接两方建立连接时。拥塞窗体被初始化为1个报文段，每收到一个ACK。拥塞窗体就添加一个一个报文段，发送方会取拥塞窗体和接收窗体的最小值做为发送数据的最大上线。因为拥塞窗体刚開始为1，发送方刚開始等待ACK。当收到后拥塞窗体变为2，此时能够发送俩个数据了。当再次收到ACK后，拥塞窗体变为4，如此呈指数增长，当达到互联网容量。于是中间路由器開始丢弃分组，以此来告知发送方它的拥塞窗体开的太大了

(5)拥塞

当数据到达一个大管道并向一个较小的管道发送时便会产生拥塞。当多个输入流到达一个路由器，而路由器的输出流小于这些输入流的总和时也会发生拥塞