用TCP连接分析TUXEDO的WS模式

 

Abstract : 关于中间件，有一个很有名的定义是：平台 + 通信。这一点在 TUXEDO 上面得到了很好的体现，因为它提供了运行和开发的平台，以及多种的通信方式。在这多种通信方式中，使用最频繁的是 WS （ workstation ）方式。 WS 方式使用的是 TCP 连接，为了对 WS 方式有更多的了解，我们结合 TCP 连接的知识对这种方式进行了一个比较深入的分析。

名词说明 :

WSC: WorkStation Client               WSL: WorkStation Listener

WSH: WorkStation Handler            Server: 小写表示服务器端的服务处理进程

 

TCP 连接是一种 C/S 模式的，即 server 端公开自己的 IP 和端口号， client 通过这两个参数与之建立连接，客户端使用的端口一般是 OS 临时分配的。

TCP server 端一般有两种模式，一种是 iterative( 重复 ) 的，一种 concurrent （并发）的。前面一种是一个 server 的进程（应用层）来处理 client 的请求，处理完了之后继续接受请求来处理，当 server 正在处理的过程中，新来的请求得不到处理，只有等待。后面一种是请求到来的时候， server 进程通常会新开一个进程来处理这个请求，自己继续监听公开端口的连接请求。

在 TUXEO 这种事务处理系统中，会经常有大量的请求，故第一种模式肯定是不行的，第二种模式虽然可以达到同时处理不同请求的目的，但是由于每次要开新的进程，系统的开销很大，也会影响性能。实际中， TUXEDO 的 Workstation 方式采用了另一种方法来实现多请求的并发处理。下面我们进行详细的说明。

以下是 ubb 中关于 WSL 的配置参数：

WSL              SRVGRP=Group1 SRVID=200

                     CLOPT="-A -t -- -n //ip （ 服务器 IP ，在此隐去 ） :4050 -m 2 -M 10 -x 10"

其中 ip:4050 就是 TUXEDO 服务器的 WSL 的监听地址，只有一个 WSL 进程。 -m 参数指定的是启动时 WSH 的个数， -M 为最大个数（用户数大于 m*x 时系统会自动启动更多的 WSH ）， -x 为每个 WSH 可以多道处理请求的最大数目，可以理解为 WSH 的请求缓冲区可以存放十个请求。这样我们上面的配置在启动后可以处理同时 20 个并发请求，最大可以处理 100 个。

根据这个配置和相关参数的解释，我们就可以知道 TUXEDO 采用的处理模式了， TUXEDO 在上面 TCP 的第二种方式之上进行了改进。监听进程还是只有一个 (WSL) ，但是事先已经起了多个处理请求的进程 (WSH) ，每个 WSH 又可以处理多个请求，这样就保证了大量的请求能同时得到处理，也省去了临时开服务进程的开销。

为了很好的理解整个工作过程，我们首先来看一下 WSC 连上来的时候的一些步骤。

图 1 ： WSC 连接的工作示意图（摘自 TUXEDO 文档： ADCF04-WS ）

 

上图很清晰的说明了连接的过程。

这里还需要理解是 WSH 和 server 进程之间的关系。因为大家知道，真正处理 client 请求的是 server 进程，所有的业务处理，以及和数据库相关的操作都是在 server 进程中完成的，这也是我们 TUXEDO 应用开发主要做的部分。我的理解是 WSH 可以看成是 WSC 在本地的一个代理。 WSH 收到 WSC 的请求数据 , 放在缓冲区，然后发给 server 进程来处理，因为在同一台机器上，一般采用本地进程间通信的机制，效率比较高。 Server 处理完后将结果返回给 WSH ， WSH 再将结果返回给 WSC ，这个过程中 WSH 和 WSC 是保持着 TCP 连接的，而 server 进程并不直接和 WSC 打交道。

       以上的过程也可以参考下图：

 

图 2 ： WS 方式的连接步骤和相关模块说明图

 

需要解释的是 WSH 和 server 之间的粗线箭头。因为 WSH 和 server 直接是多对多的关系，每个 WSH 可以把请求发给多个 server ，每个 server 也可以接受多个 WSH 发来的请求。

还有一个问题就是 TCP 应用是和机器的物理端口绑定的，既然 WSL 和 WSH 都要和 WSC 进行 TCP 通信，而且很可能是同时的，那么就必须使用不同的端口。这个我们在后面会进行相关的说明。为了简便起见，我将 server 和 WSC 都实现在同一台机器上，因为是 WS 方式，同样会进行 TCP 连接，和两台机器之前的情况是一样的，但是数据流会采用回环（ loopback ）设备，但不影响我们对问题的说明。

结合上面的 WSL 设置，我们在 Windows 的任务管理器中看到一个 WSL 进程和两个 WSH 进程。

下面我们结合 TCP 的知识来说明 WS 方式中的连接动作。为便于数据的说明，这里给出一个 TCP 状态的变迁图。限于篇幅，这里不作解释，请大家参考相关的书籍。

 

图 3 ： TCP 状态变迁图

 

下面是在 Windows command 窗口用 netstat 看到的输出，并给出相关的解释说明。

 

图 4 ： netstat 输出 1 ，关于 WSC 和 WSL 连接

 

输出的前面两行是处在 TIME_WAIT 状态的连接，是之前试验留下的连接，要等到两个 MSL(Maximum Segment Lifetime) 的时间后结束。

第三个是当前 WSC 到 WSL 的连接，这里地址显示的主机名和端口号。由于 WSC 和 WSL 的连接建立时间极短，我们没能看到 WSC 和 WSL 连接的 ESTABLISHED 状态，看到的是进入 FIN_WAIT_2 状态（从 WSC 角度）和 CLOSE_WAIT 状态 ( 从 WSL 角度 ) 的连接。这个状态表明 WSC 发起了 active close, 发送了 FIN 并收到 ACK ，但是还没有收到 WSL 的 FIN 结束请求，连接处于 half-close 状态。 CLOSE_WAIT 表示 WSL 收到 WSC 的 FIN 请求，并发回 ACK ，与上面的 WSC 的 FIN_WAIT_2 状态正好对应。

在上图的第二个 netstat 输出中，我们就可以看到使用端口号 1544 的 WSC 连接进入到 TIME_WAIT 状态了，与前面两个连接一样。

 

 

图 5 ： netstat 输出 1 ，关于 WSC 和 WSH 连接

 

在上面的图 4 中，我们说明了 WSC 和 WSL 的连接。现在我们来看一下 WSC 和 WSH 的连接。由于调用的是 TOUPPER 服务，请求的处理时间极短，所以在图 4 中没有看到 WSC 和 WSH 的连接。为了观察到这个连接，特意在 tpinit 和 tpterm 之间加入了一个函数调用 sleep(10) ，让 WSC 睡眠 10s ，这样连接就被保持了，在这个过程中，我们用 netstat 看到了上面的输出。

大家知道在 TCP 连接中，一般 client 使用的端口号都是 OS 临时分配的，通常是顺序使用的。但是这里除了我们指定的 4050 端口（ WSL ）和单调增长的 15XX WSC 端口外，还有一个 3212 端口，这个就是 WSH 使用的端口。笔者经过多次反复的上述试验，发现在 ESTABLISHED 状态的连接中 SERVER 端的端口号都是 3212 和下图中的 3213 ，因而推测这就是我们的两个 WSH 分别使用的端口。

从上图，我们分析出的连接过程是， WSC 先和 WSL 建立连接，然后 WSC 从 WSL 处得到 WSH 的端口号，和 WSH 建立连接，来完成事务处理。由于 WSL 是唯一的，要被多个 WSC 使用，所以 WSC 和 WSL 的连接是非常短暂的。这与图 1 中的过程是吻合的，但是我们没有能看到 STEP2 中 WSL 和 WSH 通信的过程。

 

 

图 6 ： netstat 输出 1 ，关于 WSC 和 WSH 连接特性

 

       根据图 4 和图 5 ，我们详细分析了两个连接的过程。下面我们分析一下图 6 的输出。

WSC 通过端口 1548 和 WSL 建立连接后，很快进入 TIME_WAIT, 如图 6 的第一个 netstat 的第五行（只计 TCP 行）连接所示。第六行和第七行， WSC 用端口 1549 和 WSH （端口 3213 ）建立连接，由于上面提到的 sleep(10) 而处于 ESTABLISHED 状态。由于 WSC 和 WSL 的连接是要延时关闭的，结合前后输出我们可以确认上述 1549 端口是被 1548 端口的 WSC 使用的。这就是说 WSC 和 WSH 建立连接会采用一个新的端口，这是由于 TCP 的性质决定的。在很多的 TCP 实现中，处在 2MSL 等待状态的端口是不能马上被使用的，所以 WSC 必须使用一个新的端口 1549 来和 WSH 连接。

       下面我们来看看另一个有趣的地方。前面说到 WSC 和 WSL 的连接很快进入到 TIME_WAIT 的状态，那么 WSC 和 WSH 的连接是否也是这样的呢？从图 6 的第二个 netstat 结果中，我们发现不是这样的。因为 1549 和 3213 的连接“不见”了，而并没有进入其他 TCP 状态转换图中的状态。而这时 1548 的连接还处在 TIME_WAIT 状态中，表明还没有完成 Windows 版 TCP/IP 实现的 2MSL 时间。后面的使用 1550 端口的其它连接也已经建立了，唯独其中的 1549 连接完全的结束了。这就说明 WSC 和 WSH 的连接采用的是结束后立即终止的方法。这样做的好处是可以很快的释放端口，避免 client 的主机端口被耗尽，特别是在请求发起很多的时候。我们知道主机的端口号在 0 － 65535 之间，而且很多是被保留， WSC 无法使用的。

       经过上面的分析，相信大家对 TUXEDO 的 WS 方式的连接过程有了一个比较清晰的认识。 WS 方式是实际中使用最多的方式，对这种方式的理解有助于我们的应用开发和对相关系统状况的分析和故障的检查。以上假设大家有相关的 TUXEDO 开发经验，能完成 TOUPPER 的 WS 版的配置和实现即可，另外还要求对 TCP 协议有相关的了解。希望对大家学习 TUXEDO 或者网络知识有帮助。对以上的过程还可以进行更细致的分析，例如捕获相关的数据包，监听端口等。这里有一些是我自己的理解，也希望大家批评指正。

 

后记 ：

以上是最近在深入学习网络方面的知识，对 TCP/IP 有了更深的认识和了解之后，结合自己之前在 TUXEDO 方 面的工作和实践，并做了相关的试验而分析出的一些看法和理解。我觉得这是一个很好的方式：结合正在使用的软件来学习网络的原理，也参考这些原理来理解实际 的过程。而不仅仅是记得那些协议和规定，或者开发只知其然，不知其所以然的应用。协议和软件一样是在不断发展的，借用参考资料中 Larry Peterson 的一句话就是我们更重要的是要去理解为什么协议要这样实现。

 

 

参考资料 ：

1．  TUXEDO  e-docs 官方文档。

2．  TCP/IP Illustrated V1: The Protocols    W. Richard Stevens

3．  Computer Networks: A System Approach(2^nd ) Larry Peterson & Bruce Davie