即时通讯开发之TCP 交互数据流成块数据流

Posted 2023-01-20 wecloud1314

目前建立在 TCP 协议上的网络协议特别多,有 telnet,ssh,有 ftp,有 http 等等。

 

这些协议又可以根据数据吞吐量来大致分成两大类:

    交互数据类型：例如 telnet,ssh,这种类型的协议在大多数情况下只是做小流量的数据交换,比如说按一下键盘,回显一些文 字等等。
    数据 成块类型：例如 ftp,这种类型的协议要求 TCP 能尽量的运载数据,把数据的吞吐量做到最大,并尽可能的提高效率。

针对这两种情况,TCP 给出了两种不同的策略来进行数据传输。

TCP 的交互数据流

对于交互性要求比较高的应用,TCP 给出两个策略来提高发送效率和减低网络负担:

    捎带 ACK。
    Nagle 算法(一次尽量多 的发数据)。

通常,在网络速度很快的情况下,比如用 lo 接口进行 telnet 通信,当按下字母键并要求回显的时候,客户端和服务器将经 历 发送按键数据->服务器发送按键数据的 ack -> 服务器端发送回显数据->客户端发送回显数据的 ACK 的过程,而其中的数据流量将 是40bit + 41bit+41bit+40bit = 162bit,如果在广域网里面,这种小分组的 TCP 流量将会造成很大的网络负担。即时通讯聊天软件app开发可以加蔚可云的v：weikeyun24咨询

 

捎带 ACK 的发送方式

这个策略是说,当主机收到远程主机的 TCP 数据报之后,通常不马上发送 ACK 数据报,而是等上一个短暂的时间,如果这段时 间里面主机还有发送到远程 主机的 TCP 数据报,那么就把这个 ACK 数据报“捎带”着发送出去,把本来两个 TCP 数据报整合成一个发 送。一般的,这个时间是200ms。可以明显地看 到这个策略可以把 TCP 数据报的利用率提高很多。

Nagle 算法

上过 bbs 的人应该都会有感受,就是在网络慢的时候发贴,有时键入一串字符串以后,经过一段时间,客户端“发疯”一样突然回 显出很多内容,就好像数据一下子传过来了一样,这就是 Nagle 算法的作用。

Nagle 算法是说,当主机 A 给主机 B 发送了一个 TCP 数据报并进入等待主机 B 的 ACK 数据报的状态时,TCP 的输出缓冲区里面 只能有一个 TCP 数 据报,并且,这个数据报不断地收集后来的数据,整合成一个大的数据报,等到 B 主机的 ACK 包一到,就把这些 数据“一股脑”的发送出去。虽然这样的描述有些 不准确,但还算形象和易于理解,我们同样可以体会到这个策略对于低减网络负担的 好处。

在编写插口程序的时候,可以通过 TCP_NODELAY 来关闭这个算法。并且,使用这个算法看情况的,比如基于 TCP 的 X 窗口协议,如果处理鼠标事件时还是用这个算法,那么“延迟”可就非常大了。

TCP 的成块数据流

对于 FTP 这样对于数据吞吐量有较高要求的要求,将总是希望每次尽量多的发送数据到对方主机,就算是有点“延迟”也无所谓。 TCP 也提供了一整套的策略来支持这样的需求。TCP 协议中有16个 bit 表示“窗口”的大小,这是这些策略的核心。

传输数据时 ACK 的问题

在解释滑动窗口前,需要看看 ACK 的应答策略,一般来说,发送端发送一个 TCP 数据报,那么接收端就应该发送一个 ACK 数 据报。但是事实上却不是这 样,发送端将会连续发送数据尽量填满接受方的缓冲区,而接受方对这些数据只要发送一个 ACK 报文来 回应就可以了,这就是 ACK 的累积特性,这个特性大大减 少了发送端和接收端的负担。

滑动窗口

滑动窗口本质上是描述接受方的 TCP 数据报缓冲区大小的数据,发送方根据这个数据来计算自己最多能发送多长的数据。如果发 送方收到接受方的窗口大小 为0的 TCP 数据报,那么发送方将停止发送数据,等到接受方发送窗口大小不为0的数据报的到来。书中的 P211和 P212很好的解释了这一点。

关于滑动窗口协议,书上还介绍了三个术语,分别是:

    窗口合拢: 当窗口从左边向右边靠近的时候,这种现象发生在数据被发送和确认的时候。
    窗口张开: 当窗口的右边沿向右边移动的时候,这种现象发生在接受端处理了数据以后。
    窗口收缩: 当窗口的右边沿向左边移动的时候,这种现象不常发生。

TCP 就是用这个窗口,慢慢的从数据的左边移动到右边,把处于窗口范围内的数据发送出去(但不用发送所有,只是处于窗口内的数据可以发送。)。这就 是窗口的意义。

数据拥塞

上面的策略用于局域网内传输还可以,但是用在广域网中就可能会出现问题,最大的问题就是当传输时出现了瓶颈(比如说一定 要经过一个 slip 低速链 路)所产生的大量数据堵塞问题(拥塞),为了解决这个问题,TCP 发送方需要确认连接双方的线路的数据最 大吞吐量是多少。这,就是所谓的拥塞窗口。

拥塞窗口的原理很简单,TCP 发送方首先发送一个数据报,然后等待对方的回应,得到回应后就把这个窗口的大小加倍,然后连 续发送两个数据报,等到对 方回应以后,再把这个窗口加倍(先是2的指数倍,到一定程度后就变成现行增长,这就是所谓的慢启动), 发送更多的数据报,直到出现超时错误,这样,发送端 就了解到了通信双方的线路承载能力,也就确定了拥塞窗口的大小,发送方就 用这个拥塞窗口的大小发送数据。要观察这个现象是非常容易的,我们一般在下载数据 的时候,速度都是慢慢“冲起来的”。