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

以下转自：http://blog.csdn.net/ma_yan368/archive/2009/01/12/3761657.aspx

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

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

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

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

其中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

http://e-docs.bea.com/tuxedo/tux80/atmi/adwsc4.htm）
上图很清晰的说明了连接的过程。

这里还需要理解是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的一句话就是我们更重要的是要去理解为什么协议要这样实现。