集群的可扩展性及其分布式体系结构之十

核心提示： Step7：负载均衡器选择完实际的服务节点，以客户端的"身份"向服务节点发起SYN连接请求，集群的可扩展性及其分布式体系结构之十(6)，特别一提的是，该请求使用了客户端原先发起的请求初始序列号CSEQ，序列转换的偏移量，因此，这么做的目的是为了后面进行TCP粘合所必须的

Step7：负载均衡器选择完实际的服务节点，以客户端的"身份"向服务节点发起SYN连接请求，特别一提的是，该请求使用了客户端原先发起的请求初始序列号CSEQ。这么做的目的是为了后面进行TCP粘合所必须的TCP Header数据转换时，尽可能减少均衡器的CPU计算量，也方便管理被粘合的两个连接。

Step8：SYN（CSEQ）由服务端监听口到达服务节点，从整个会话过程来看，客户端Step1所发出的SYN（CSEQ）被延迟地发送到了最终目的地！

Step9：服务端接受SYN(CSEQ)，送回应答数据包ACK(CSEQ)＋1），同时发起SYN(SSEQ)以完成TCP的握手例程。

Step10：值得注意的一个步骤，服务节点的SYN(SSEQ)报文序列被重新映射为SYN（DSEQ），和step3的报文序列相同。这样，从负载均衡器的角度来讲，他正确的获得了一个应答报文，并且这个被转换过序列的应答报文可以直接和客户端的报文序列映射在一起了。而ACK（CSEQ＋1）应答报文被送回核心模块。

到这里为止，我们可以发现，服务端监听口对于均衡器而言，作为虚拟的服务端而存在，通过该端口的报文序列都是转换过后的序列，能够直接和客户端监听口的序列对应。同理，客户端监听口也承担了相似的角色。

Step11：均衡器确认了ACK（CSEQ＋1）报文后，完成和服务节点的三次握手。发出应答报文ACK（DSEQ＋1）（注意：均衡器在这里使用的是客户端序列，把自己当做客户端，把服务端监听口当做服务器）。同时发出请求数据Data（CSEQ＋1）。

到这一步，均衡器完成了对Step5的TCP请求延迟处理。客户端的请求数据终于被发送给了服务节点（通过服务端监听口）。

Step12：经过服务端监听口的报文，需要被适当的修改序列：即DSEQ序列－>SSEQ序列。这样的转换是固定偏移的，也就是第一次SYN被接收之后，二者序列之差可以作为整个通信过程中，序列转换的偏移量。因此，从端口送回到服务节点的报文是：Data（CSEQ＋1）以及ACK（SSEQ＋1）。