libjingle源码解析(4)-【PseudoTcp】建立UDP之上的TCP(2)：对交互数据流的处理

对交互数据流的处理

TCP包含两类数据流，交互数据流和成块数据流。交互数据流的特点是每个报文数据字节数比较小，大部分是10字节一下，而成块数据流的特点是大部分报文是满长度的，一般能达到MSS。

本文先介绍一些TCP和PTCP对交互数据流的处理。

交互式输入

    Rlogin是典型的交互数据流应用，每一按键都会产生数据分组，使客户端传输一个报文，接连总共产生4个报文：

    a.C传输交互按键数据

    b.S确认C的数据

    c.S回显C的按键

    d.C确认S的回显

    上面的报文b,c可能会同时包含在一个报文段。而对于TCP报文-有40个字节的头部的协议报文来说每次只传输一个字节是个极大的浪费，此外Rlogin这类应用会在短时间内按N个字符，按如上的方式，至少要传输3*N个报文。

经受时延的确认

    经受时延的确认考虑了时间有关的细微之处，对于交互类应用，短时间内会产生多个报文。对于TCP，当接收数据时，并不立即发送确认，而先缓存，延迟发送，以便在短时间如果有该方向的数据需要发送，则一同发送，这样能减少ACK报文的个数，提高报文的利用率。TCP通常等待200ms后发送ACK。

    对于PTCP来说，也支持延时确认，默认延时时长为100ms，可以通过选项OPT_ACKDELAY更改延时时间。不另外，如果出现连续两个不含数据的ACK需要发送，则不会等到100ms，直接会发送ACK报文。PTCP发送ACK的时机如下：

    A. 和SEND数据一起发送

    B. 等到超时（100ms后没有数据时）时发送

    C. 出错时发送（如发现对方传来的数据和预期的不一致，或者ACK被丢失）

    虽然PTCP是等到100ms后发送ACK，但没有提供任何定时器，只提供了下次需要被提醒的时间（通过方法GetNextClock)，然后由业务层来实现定时器并通知到时（通过方法NotifyClock）。这样，业务层就会有灵活的方式设置定时器，比如通过消息循环，等待事件，完成端口等等。

Nagle算法

    Nagle算法是为了避免在广域网上出现大量的TCP小分组报文段。该算法要求一个TCP连接上最多只有一个未被确认的小分组。当已经发送的一个分组没有被确认前，该算法积累所有需要发送的数据，等到未被确认的分组确认了，一同发送，这样在短时间内出现的小分组合并成一个报文发送，提高了报文的利用率。这个算法是自适应的，得到确认越快，则发送频率越高。伪代码如下：

    if there is new data to send

      if the window size >= MSS and available data is >= MSS

        send complete MSS segment now

      else

        if there is unconfirmed data still in the pipe

          enqueue data in the buffer until an acknowledge is received

        else

          send data immediately

        end if

      end if

    end if

    PTCP也支持Nagle算法，可以通过选项OPT_NODELAY开启或者关闭。Nagle算法的实现比较简单，当尝试发送数据时，发现如果有未确认的数据且等待发送的数据长度小于MSS，则延迟发送，如下：

窗口大小通告

    TCP和PTCP都通过头部的window字段通告接收缓冲区的可用窗口大小。当客户端收到服务器的数据，并有等待发送的数据时（开启Nagle算法时会经常出现此情况），通告给服务器的窗口大小总是小于接收缓冲区的大小，是因为，应用层还没有拿取刚从服务获取的数据之前，就会尝试发送被缓冲的数据。

    PTCP的实现如下：

    当PTCP接收对方发送的数据时会调用NofifyPacket->parse->process，在Process先调用attemptSend发送缓冲的数据，然后通知应用层有可读数据。