技术志 | Tony Bai

十二月 6, 2007

我不是计算机科班出身。记得大学的时候旁听计算机系的网络课，当时计算机系使用教材是"计算机网络–自顶向下方法与Internet特色"的影印版，这本教材与众不同的一个地方就是作者JAMES F.KUROSE和KEITH W.ROSS采用了'自顶向下'的编排思路，先从应用层开始，最后讲到物理层。而且这本书在语言上形象生动，通俗易懂。只怪我当初没有一心一意听讲，到现在存在我的脑子中的基本概念居多，深刻理解甚少。以致于工作后遇到此类的问题，只能恶补。这不，在12月1日凌晨全国统一短信类服务接入代码的调整工作中，我就遇到了此类问题，不得不再次抱起W.Richard Stevens的'TCP详解卷一'啃了啃，回顾一下TCP协议那些事儿。

做应用层网络程序开发的，手头上都有一把利器：抓包工具，更专业的名词就是协议分析工具，常用的且功能强大的协议分析工具有：TCPDUMP(Windows平台上的叫Windump)、Ethereal等。工作中常常会遇到因应用层程序在协议字段发送和接收解析上不一致而出现'纠纷'问题，这时我们一般采用的在TCP层用协议分析工具抓取该层原始数据包作为'对峙'的证据；还有的就是在客户端与服务器端链接问题上的一些现象也需要到TCP层去分析原因，这就需要对TCP层的基本工作原理有一个清晰的认识。

首先我们要明确：TCP头部中设置的一系列域都是为了能达到分割、重传、查重、重组、流控、全双工的协议功能而设置的，这里比较重要的字段就是序列号和确认号。由于要达到重传、查重、重组、全双工这些目的，TCP层需要通过序列号和确认号来保证。序列号用来标识发送端传送数据包的顺序，并且指导接收端对多数据包进行顺序重组；发送端传送一个数据包后，它会把这个数据包放入重发队列中，同时启动计时器，如果收到了关于这个包的确认信息，便将此数据包从队列中删除；如果在计时器超时的时候仍然没有收到确认信息，则需要重新发送该数据包。

TCP层以"三次握手"建立链接而"闻名于世"，三次握手的目的：建立链接，为后续的数据流传输奠基，因为TCP是双工的，因此在握手过程需告知彼此数据包发送的起始序列号。

Client –> 置SYN标志序列号 = J，确认号 = 0 —-> Server
Client <– 置SYN标志置ACK标志序列号 = K, 确认号 = J + 1 <– Server
Clinet –> 置ACK标志序列号 = J + 1，确认号 = K + 1 –> Server

链接建立后，接下来Client端发送的数据包将从J + 1开始，Server端发送的数据包将从K + 1开始，这里要说明的是：建立链接时，Client端宣称自己的初始序列号是J，Server端宣称自己的初始序列号是K，但是建立连接后的数据包却各自中初始序列号+1开始，这是因为SYN请求本身需要占用一个序列号。

在数据传输阶段，按照常理应用层数据的传输是这样的：(我们假定建立连接阶段Client端最后的确认包中序列号 = 55555, 确认号 = 22222)
Client –> 置PSH标志，置ACK标志序列号 = 55555, 确认号 = 22222，数据包长度 = 11 —> Server
Client <– 置ACK标志，序列号 = 22222, 确认号 = 55566 (=55555 + 11)，数据包长度 = 0 <— Server
Client <– 置PSH标志，置ACK标志序列号 = 22223, 确认号 = 55566，数据包长度 = 22 <— Server
Client –> 置ACK标志，序列号 = 55566, 确认号 = 22244(=22222+22)，数据包长度 = 0 —> Server

注：PSH标志指示接收端应尽快将数据提交给应用层。从我协议分析的经历来看，在数据传输阶段，几乎所有数据包的发送都置了PSH位；而ACK标志位在数据传输阶段也是一直是置位的。

但是实际我们在分析过程看到的却都是如下这样的：
Client –> 置PSH标志，置ACK标志序列号 = 55555, 确认号 = 22222，数据包长度 = 11 —> Server
Client <– 置PSH标志，置ACK标志序列号 = 22222, 确认号 = 55566 (=55555 + 11)，数据包长度 = 22 <— Server
Client –> 置PSH标志，置ACK标志序列号 = 55566, 确认号 = 22244 (=22222 + 22)，数据包长度 = 33 —> Server
Client <– 置PSH标志，置ACK标志序列号 = 22244, 确认号 = 55599 (=55566 + 33)，数据包长度 = 44 <— Server

也就是说：数据接收端将上一个应答和自己待发送的应用层数据组合在一起发送了。TCP的传输原则是尽量减少小分组传输的数量，所以一般默认都开启"带时延的ACK"。一般实现中，时延在200ms。Nagle算法多用来实现"带时延的ACK"，它要求一个TCP连接上最多只能有一个未被确认的小分组。在该分组的确认到达之前不能发送其他小分组。也就是说：发送端在发送一个分组后，需等待这个分组的ACK确认后，才可以进行下一个分组的发送。这样一来网络的传输效率被大大降低了。对于大数据块的传输来说，这样很多时候是难以忍受的。另一种拥塞控制策略被引入，那就是TCP的滑动窗口协议，滑动窗口协议是分组发送和分组确认不再同步，发送端可以连续发送n个分组，接收端同样也可以用一个确认包来一起确认这n个分组，通常n = 2。各种OS的TCP协议栈在实现上都是综合了Nagle算法和滑动窗口协议的，TCP层对应用层数据分组大小进行多次判断(一般分组大小都是和MSS做比较的)，以在Nagle和滑动窗口协议之间抉择到底选择哪一种控制方式进行发送。"The Linux Network Architecture: Design and Implementation of Network Protocols in the Linux Kernel"一书介绍了Linux在TCP层上的设计和实现，当然最直观的还是去分析Linux源代码了。

拆除TCP连接过程用一句话表述就是：你关你的发送通道，我关我的发送通道(因为TCP是全双工)。当一方关闭发送通道后，仍可接收另一方发送过来数据，这样的情况就成为"半关闭"。然而多数情况下，"半关闭"使用的很少，而且半关闭需要SOCKET AIP支持在SOCKET上的shutdown(而不是调用close)。

正常的关闭流程是源于Fin报文的:
Client –> Fin ACK –> Server
Client <– ACK <– Server
Client <– Fin ACK — Server
Client –> ACK –> Server
发送Fin分组的一端会先将发送缓冲中的报文按序发完之后，再发出Fin；所以说Fin又叫做：orderly release。

异常的关闭流程是源于Rst报文的。一个典型的例子就是当客户端所要链接的服务器端的端口并没有程序在listen，这时服务器端的TCP层会直接发送一个Rst报文，告诉客户端重置连接。Rst报文是无需确认的。客户端在收到Rst后会通知应用层对方异常结束链接(需通过SOCKET API的设置才能得知对方是异常关闭)。

也谈'万能'栈

十一月 27, 2007

1 条评论

在网上搜索"万能"二字的英文翻译，结果却无意中看到有人提到了如何设计"万能栈"。栈(stack)是比较基础(fundamental)的数据结构，实现起来一般都比较容易。但一般的栈(stack)的实现都是局限于某种特定类型的，比如一个存储32-bit整型的栈。如果对于同一份栈实现，要求可以存储多种数据类型的话，那就需要仔细想想了。而这样的栈实现也就被戏称"万能"栈。

这里对"万能"栈再做一个分类：同构数据"万能"栈和异构数据"万能"栈。简单解释一下：同构数据"万能"栈指得是这个栈可以存储多种类型数据，但是每次使用该栈时只使用其中一种类型数据；异构数据"万能"栈则说的是这个栈可以存储多种类型数据，而且使用时也是多种数据混合处理。

对于同构的"万能"栈，像C++、Java这样有模板支持的语言来说，是很好实现的。C++的标准库中就携带了一个通用的stack类，使用起来也很是方便：
stack<int> s;
for( int i=0; i < 10; i++ )
s.push(i);

但是对于使用C语言的人来说，栈是需要自己实现的。那么如何实现一个同构数据"万能"栈呢？我的想法是借用union的语法功能：
union general_unit {
        void *vp;
        void (*fp)(void);
        char *cp;
        long   l;
        double d;
   long long ll;
};

struct stack_item_t {
union general_unit item;
};
这样我在准备我的item的时候，就可以按需选取union中提供的相应类型的member。比如：
struct stack_item_t item;
item.item.l = 5;
push(&item);

这里其实也是有些别扭的，别扭在于谁来管理数据存储的问题。对于char, int, long, float, doule这样的语言本身提供的基本数据类型，大可存储在stack中。但是对于其他非基本数据类型的数据，我们只能将其指针放到栈中了，这时你就要保证push到栈中的地址在栈的活动期是有效的，像下面这样的肯定会出错：
typedef struct Foo {
//…
} Foo;

void foo(void) {
   Foo foo;
   //init…
   struct stack_item_t item;
   item.item.vp = (void*)&foo;
   push(&item);
}

int main(void) {
   struct stack_item_t item;
   item = pop();
   Foo *pfoo = (Foo*)item.vp;
   pfoo->xxx; //error;
}

如果上面的例子中存储的是函数指针的话，那么问题就不大了，因为函数地址在程序构建之后其地址就是全局可访问且始终不变的。

有了上面的基础，异构的"万能"栈实现也就容易了。异构栈要求：pop时候我也要知道pop出来的item的类型，那么只用union显然不能完成这个任务了，我们需要有一个字段来标识一下存储的类型是什么或者说标识使用了general_unit中的哪个成员，便于上层使用，方法如下：
union general_unit {
        void *vp;
        void (*fp)(void);
        char *cp;
        long   l;
        double d;
   long long ll;
};

struct general_item {
union general_unit unit;
int ut_type; //用于标识栈中数据的类型
};

struct stack_item_t {
struct general_item item;
};

这样在pop时我们需要如是做：
item = pop();
switch(item.item.ut_type) {
   case xx:
       //…
   case yy:
       //…
   //…
}
看起来还是比较麻烦的。

以上只是"万能"栈的一种想法而已，C语言博大精深，有很多诡秘的技巧是我所不知的，也许很多人还有更好的方法。

为什么要给万能二字加上引号呢？其实就是说明这个"万能"只是一个相对的概念，这个相对的"万能"带来的是数据存储管理的不一致以及接口的不易用。在平时使用时尽量避免使用这种所谓的"万能"栈，一般来说我们都会使用比较单一类型的栈实现，这样的栈简单、高效、易用且不易出错。