《企业运维之云上网络原理与实践》——第二章 负载均衡 CLB——负载均衡CLB（上）-产品和架构（3） https://developer.aliyun.com/article/1230705?groupCode=supportservice
3. 健康检查
健康检查是CLB集群对后端进行一个探测，多台ECS同时提供一个服务，通过健康检查可以追踪的故障服务，避免了后端ECS异常对总体服务的影响。
• 健康检查可以感知到后端ECS的可用性；
• 探测源均是承载业务的转发集群；
• 探测源IP段为100.64.0.0/10。
1) TCP监听
CLB向后端发起一个TCP三次握手，后端响应完成，以RST方式断开连接。
• 请求方式：TCP三次握手或HTTP GET；
• 判定成功逻辑：超时时间内收到了SYN_ACK；
• 判定失败逻辑：超时时间内未收到SYN_ACK；
• 关闭连接方式：发送RST数据包。
问题一：为什么选择RST方式而不是四次挥手断开连接？
因为健康检查是用CLB额外引入的逻辑，对后端ECS具有一定的负担，为了尽可能地减少健康检查的开销，采用了RST方式，只需要单向的一个包就可以立即断开，断开后两端的机器系统内核都不再去维护TCP五元组连接的管理。
问题二：使用RST可能带来哪些问题？
RST在TCP/IP定义里属于非正常的链接结束逻辑，在某些程序比如java程序会频繁提示“connection reset by peer”，只要确定探测源是100.64.0.0/10，就可以认为这是健康检查探测的逻辑，可以忽略该异常信息。
2) UDP监听
UDP是面向无连接的协议，一般用于如DNS、syslog协议场景，UDP监听的规则是发出报文，在规定时间内，收到差错报文回应表示失败，未收到报文表示成功（也可以设置为返回特定字符串来判定成功）。
• 请求方式：UDP报文；
• 判定成功逻辑：超时时间内没有收到ICMP端口不可达报文；
• 判定失败逻辑：超时时间内收到了ICMP端口不可达报文。
3) HTTP（S）监听
• 请求方式：HTTP GET方法或HEAD方法，可能包含Host头，默认使用HEAD方法（尽可能地降低健康检查给后端ECS带来的影响，HEAD方式只返回响应头部字节数，开销也比较小）；
• 判定成功逻辑：超时时间内收到了配置的预期状态码（如200）；
• 判定失败逻辑：除上述以外的情况（如收到了502状态码、收到了RST、建连失败等）。
4) 滞后性和探测频率
• 滞后性：如果机器出现故障时，CLB需要一定的时间才能感应到；
• 探测频率：探测频率会根据CLB转发机器数量而倍增，需要在灵敏性和业务可容忍的范围内，适当设定该频率。
《企业运维之云上网络原理与实践》——第二章 负载均衡 CLB——负载均衡CLB（上）-产品和架构（5） https://developer.aliyun.com/article/1230701?groupCode=supportservice
