TCP/IP 11成块数据流和交互数据流

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的指数倍,到一定程度后就变成现行增长,这就是所谓的慢启动),发送更多的数据报,直到出现超时错误,这样,发送端就了解到了通信双方的线路承载能力,也就确定了拥塞窗口的大小,发送方就用这个拥塞窗口的大小发送数据。要观察这个现象是非常容易的,我们一般在下载数据的时候,速度都是慢慢“冲起来的


阅读更多
想对作者说点什么?

博主推荐

换一批

没有更多推荐了,返回首页