LVS基本原理和日志打印：incomplete startup packet

LVS(Linux Virtual Server)作为中国最早出现的自由软件项目之一，在Linux内核中实现了基于IP的四层数据请求负载均衡调度方案。相比Nginx等七层负载均衡方案，LVS处理流程更少，效率更高，更适合大型企业集群使用，目前LVS已经成为Linux官方标准内核模块的一部分。

LVS工作过程如下所示，客户端连接LVS，发送请求，LVS通过下发请求给不同的服务器，实现负载均衡。

LVS又称LVS Director，因此根据上图实例不同，在LVS中，包含以下术语：CIP（Client IP）、DIP（Director IP）、RIP（Real Server IP）。

根据内部的实现原理，LVS包含多种模式：NAT模式、DR模式、TUN模式。

1. NAT模式通过通过修改客户端入站目的地址为RIP将数据包传输至服务器，出站时LVS Director修改数据包地址为CIP将数据包传输至客户端。
2. DR模式通过修改入站数据包的目的MAC地址，将数据包传输至服务器，出站时不经过LVS，数据包由服务器直接返回给客户端。
3. TUN模式即隧道模式，指不修改数据包内容，而是为数据包封装包头（IP头）的方式转发数据，出入站路径和DR模式相同。

修改数据包的方法，主要是基于内核netfilter框架和iptables机制实现的。netfilter框架可以理解为内核处理数据包时，在IP层预留的几个数据快照点，如下图绿色节点所示。每一个快照点对应数据包在IP层的一个处理阶段，在数据包经过这些点时，可以通过注册HOOK函数对数据包进行操作。也可以通过iptables工具对数据包的行为进行自定义（丢弃、继续传输等）。

数据一定是经由上层传输的，例如通过http、TCP、UDP协议等下发至下层，TCP协议需要建立连接，netfitler实现TCP建连时有两种场景和方案：

1. 实现客户端到服务器的透明传输（包含建连），通俗点讲，就是客户端的目的IP地址实际上还是RIP，但是LVS可以代替服务器做应答，并转发数据给服务器，该场景下TCP建连可以视作客户端直接到服务器的一次三次握手。这种场景显然不能达到负载均衡的目的，而是较为适合长时延端到端传输。
2. 实现客户端请求向不同服务器转发，建连需要经历两个阶段：一是客户端和LVS建连、LVS再和服务器建连，可以理解为两个三次握手。显然这种场景可以实现LVS的负载均衡目的，但是建连过程变的复杂。

为解决建连复杂问题，目前LVS在客户端连接请求发起之前，就和服务器建立很多空连接（仅三次握手），对于数据库集群服务器，此时无法收到startuppackets报文，就会不断打印日志：

[BACKEND] WARNING:  could not receive data from client, remote nodename linux*****, detail:none.

[BACKEND] LOG:  incomplete startup packet

上述日志中，incomplete startup packet表明现象，could not receive data from client表明该现象的具体原因为没有收到数据。从PG官方论坛的讨论中，该日志是无害的。如果我们理解LVS和Gaussdb相关原理，就可以避免疑惑，少走弯路。