腾讯云CLB 在哪里设置请求头大小

点击联系发帖人 时间：2022-07-13 01:15

腾讯会议小程序二维码怎么生成

公司一直在推动业务上云，同时越来越多的项目也要开始出海，对云的依赖会越来越多。但是云并不像它宣传的那么简单易用，尤其是云上网络，是大家理解云的一大阻碍。本文比较全面地梳理了云上网络的各种概念以及简要的原理，希望能够帮助大家建立一个知识索引，以备不时之需。由于本人不是云的专家，因此文章中有不对的地方也欢迎指正。

VPC 全称 Virtual Private Cloud，翻译成私有网络其实不太准确，但是它确实就是对网络资源的一种抽象。我身边的很多同事对 VPC 都很疑惑，每次一说到 VPC 感觉都有点儿晕，不知道为什么会有这个东西：你给我个云服务器不就行了，怎么还得有个什么 VPC 和子网，这到底是啥，好麻烦啊？

其实要理解 VPC，可以类比操作系统的虚拟内存。操作系统提供虚拟内存的抽象，让每个进程都像在独占地使用整个系统的内存，不用担心和其它进程内存地址冲突等等。而 VPC 也是提供类似的抽象，由于公有云上有非常多的企业，每个企业都有自己的网络规划需求，因此公有云需要提供一个类似于虚拟内存的抽象，让云上的某个客户像是在独占地使用整个网络，不用担心 IP 地址被别人占用了。有了 VPC 这层抽象，云上的客户几乎可以随意地规划网络，举例来说，你想让你的某台服务器或者数据库的地址是 )

作为用户来说，我们可以简单地把云联网看做一个巨大的路由器，不同的网络只要能够接入腾讯云的网络，就能加入云联网这个大路由器。而这个大路由器根据各种自动学习算法，来适应我们的网络拓扑，从而实现不同网络之间的互联互通。

由于云联网的便捷以及更好的性能，它将是构建混合云的基石，从而取代难以维护的对等连接。

我们前面讲了企业自己的 IDC 如果要和腾讯云的 VPC 互通，可以通过 VPN 网关来实现。但 VPN 网关是通过公网来建立通信连接的，即使使用了 IPSec 等加密技术，那也直解决了通信安全的问题，但网络质量依然会很不稳定。这时，对于有需求的大型企业来说，拉一根专线接入到腾讯云就很有必要了。一旦 IDC 通过专线接入了腾讯云的网络，那么后续的各种互联互通就变得非常容易了。

比如，如下图所示，可以通过配置专线网络实现和不同 VPC 的互通：

当然更简单的办法是专线接入腾讯云网络之后，直接和云联网打通，从而实现任意网络的互联：

前面讲的对等连接 VPN 网关云联网专线等等，都是想要屏蔽不同网络的差异，让用户的网络请求就像在同一个网络中一样。但是有些时候出于安全等各方面考虑，不同 VPC 之间，我只想让你访问我的某个服务，不想开放整个网络。此时，我可以把服务暴露到公网，你通过公网域名来访问，这没问题。假如两个 VPC 都在腾讯云上，如果走公网，数据包去公网绕一大圈不说，还会浪费宝贵的公网带宽。

此时私有连接就派上用场了。私有连接其实就是 VPC2 开放一个 IP+端口给 VPC1 调用，这样请求就可以在腾讯云内网中完成，效率更高也更安全更省成本。

如图所示，用户需要把 VPC2 中的服务提供给 VPC1 调用，那么就需要在 VPC2 中创建一个私有连接的终端节点服务，这个服务其实就是把负载均衡 CLB 对外暴露。同时调用方 VPC1 可以创建一个终端节点，连接 VPC2 的终端节点服务。配置好之后，VPC1 的终端节点其实就是一个 VIP，VPC1 中向这个 VIP 发送请求，就会被转发到 VPC2 的终端节点服务所对应的 CLB，从而实现不同 VPC 中服务间的 内网调用

前面讲的所有内容，都是在解决不同 VPC 和 IDC 之间网络层面互通的问题。利用上述的服务，我们可以构建出符合企业不同需求的混合云网络。然而网络构建也只是万里长征第一步，接下来还需要从应用层考虑，怎么保证服务的高可用，怎么加速用户的网络访问速度提高用户体验等等。

负载均衡是我们接触得最多的产品，基本上所有业务服务都会需要使用 CLB。CLB 其实就是把对某个服务的请求转发到该服务对应的多个 CVM 上，通过各种算法来保证请求尽可能均匀地分布减少单台 CVM 的压力，同时 CLB 会感知 CVM 的健康状态，把不健康的实例从转发目标中摘除，从而减少不必要的请求失败。通过 CLB 还可以避免暴露内部 CVM

CLB 和我们熟知的 Nginx 职责基本上一样的，最早的 CLB 只是工作在 4 层网络（现在腾讯云的 CLB 也支持配置 7 层转发，相当于和 Nginx 进行了产品融合），而 Nginx 主要工作在 7 层网络。如果你仔细回想，可能会发现 4 层的 CLB 和 DNAT 网关似乎也类似，它们都是公网用户访问网关的公网 IP，再由网关根据配置转发到内网。不过 DNAT 主要是 1 对 1 的地址翻译，它的转发是确定的唯一的，用户对某个 ip+port 的请求，一定会翻译成另一个确定的 ip+port。而 CLB 会把对一个 ip+port 的请求转发到一系列 ip+port 中的任意一个。假如 CLB 转发的 CVM 实例就只有一台的话，那 CLB 其实就和 DNAT

那假如一个依赖于 Nginx 的业务系统要上云，还需要 4 层 CLB 吗？这个问题的答案其实不难得出，你可以先自己想一下。

首先，业务的 Nginx 是单点吗？如果有多个 Nginx 的实例，那么用户流量是怎么到达的呢？一种方式是通过 DNS 服务，把域名映射到多个 Nginx 实例的 IP，但这又要求每个 Nginx 都有公网 IP 才行，这会增加成本。同时，用户如果直接通过 DNS 查找 Nginx 实例，很难以做到动态的负载均衡，因为 DNS 的负载均衡一般都是通过配置权重来实现的。你可以把所有 IP 的权重都调成一样来实现负载均衡，但假如某台 Nginx 实例突然故障了，DNS 依然会把固定比例的流量指向该故障实例。

而引入 CLB 的话，DNS 处只需要暴露一个 CLB 的公网 IP，CLB 先进行 4 层的负载均衡，把流量转发到不同 Nginx，Nginx 再进行 7 层转发。如果 Nginx 出问题，CLB 可以自动摘除。如果 Nginx 扩容了新实例，去 CLB 上添加的生效时间也比配置 DNS 快得多。

当然，由于腾讯云上的 CLB 现在同时支持 4 层和 7 层转发，因此如果没有依赖于 Nginx 的特殊能力的话，其实可以只用 CLB 就可以了。

至此，我们已经覆盖了 VPC 内部，VPC 之间，VPC 和 IDC 之间，IDC 和 IDC 之间的各种网络接入的概念和技术，也知道了它们到底是要解决哪些问题，你可以根据需要自行深入去了解相关内容。

我们前面覆盖的内容，其实从某种意义上来说都属于是“内网”。接下来要讲讲另一个很重要的概念，就是接入网络。也就是用户怎么连接到我们的内网。

用户不可能记住我们的公网 IP，我们需要提供更容易记忆的域名，来支持用户访问我们的服务。所以第一步，你需要先去购买一个域名，然后配置这个域名解析到你的公网 IP，然后等待域名解析生效。

用户通过域名访问网站时，就会经历一个递归地域名查找流程，最终找到域名对应的 IP，然后再通过那个 IP 访问网站。这里的递归查询在没有缓存的情况下（比如用户第一次访问）会进行很多次，从而使得首次访问速度很慢，极大的影响用户体验。好不容易花钱买量买过来的用户，打开你的运营页面竟然白屏一直加载，然后关掉了，这不是亏惨了。

所以 DNSPod 就登场了，它其实解决的核心问题就是 DNS 解析的加速。域名商只关心你的域名是否可以正确解析，而 DNSPod 关心的是你的域名解析速度快不快。DNSPod 通过自己的 DNS 解析集群，能够极大的提高解析速度。

域名到 IP 的解析还只是第一步，接下来连接到这个 IP 也是有一些问题的。比如，不同运营商之间的网络访问是比较慢的，假如用户是电信的网，但是域名解析后拿到了联通的 IP，那么访问速度依然很慢。要解决这个问题，就需要 DNS 服务器能够根据用户的 IP 属于哪个运营商来返回对应的 IP 地址（如果有的话）。而 DNSPod 的智能线路解析就是干这个工作的。

所以 DNSPod 不仅可以减少 DNS 查找时的查询次数，还可以根据用户网络尽可能返回相同运营商的 IP，从而提高用户的访问速度。

用户访问速度要快除了加速 DNS 解析，还有个很重要的就是就近接入。就近接入细分又有两种：

POP 接入点离用户近

目标服务器离用户近的场景，有个我们都非常熟悉的产品——CDN（Content Delivery Network）。如果问 CDN 的大致原理，相信大家都知道，就是把内容缓存到很多个边缘节点服务器上，用户访问 CDN 资源时，从离他最近的节点取数据，而不需要去源站（VPC 内）取数据，能够大大缩短响应时间。

而 POP 接入点离用户近，是为了优化网络质量。之前我们也提过，公网的网络质量是很不稳定的，所以如果有可能，要尽量减少数据包在公网的传输距离，而应该让数据包尽可能多的在云厂商自己的骨干网中传输。POP 点就是分布在世界各地的接入点，用户的请求只要到了 POP 点，之后就可以走云厂商自己的骨干网了。

但是你有没有想过，不论是 CDN 还是 POP 点，用户怎么知道哪个节点离他最近呢，或者说，是谁帮用户选择最近的节点？——这就要用到 Anycast 技术了。

Anycast 简单来说就是多个不同的服务器共享同一个 IP 地址，利用 BGP 最优寻路算法，把请求路由到离用户最近的服务器。当这些服务器是 POP 点时，那么就相当于用户请求在公网上用最短的距离就接入了云厂商的骨干网，从而提高的后续的传输速率，达到加速的目的。

如上图所示，离真正游戏服务器部署地区越远的用户，请求在公网上传输的距离也越长，延时也就越高。云厂商在全球各地部署了相当多的 POP 点，这些 POP 点都通过专线和云厂商的骨干网连接。因此通过 Anycast 加速网络，虽然不能减少物理距离带来的时延，但是可以尽可能减少公网传输带来的时延，让请求绝大多数时候在云厂商骨干网里传输，从而提高传输速度。

Anycast 背后更深入的原理，则需要比较多的计算机网络知识和概念，如果不是相关从业人员，只是使用方的话，没有太大必要去深入细节。想要了解更多关于 Anycast 的技术，可以参考 KM 上这篇文章：草堂答疑系列微视频之腾讯云 BGP Anycast 技术简介 - 运营识堂课后分享沙龙 - KM 平台 (woa.com) 。

和 Anycast 加速还有个类似的产品，叫做 GAAP。虽然是不同的产品，但是它们的加速原理都是一致的，就是把请求尽量多地放到云的骨干网络中传输而不是公网。

可能你也发现了，其实绝大多数的网络加速方案，原理都是让网络包尽量走内网，减少走公网。而 GAAP 其实就可以理解为：把腾讯云的骨干网传输能力对外售卖。它和 AIA 的一个很大不同是，AIA 接入骨干网之后，后续访问的只能是腾讯云中的资源。而 GAAP 是售卖腾讯云骨干网的传输能力，用户的网络包有一段在加速通道中传输，加速通道尽头又会把请求通过公网发送到请求的目的地。

举个例子，比如游戏服务器部署在新加坡，但是我希望加拿大的用户也能比较快的访问。此时，我可以通过 GAAP 创建一条加速通道，这条通道的起点在腾讯云加拿大（假如有），实际的形式其实就是一个 IP。而通道的另一端是新加坡，通道内部都是走的腾讯云的骨干网。通道的尽头你可以想象成是一个 SNAT 网关，负责把流量从内网重新发到公网上。由于请求都已经到新加坡了，那么即使走公网，也很快就到达新加坡的服务器了。

GAAP 相比于 AIA 的优势就是，它可以不限定要加速的源服务器所在的网络。比如，假设游戏服务器部署在新加坡自建的 IDC 机房或者在 AWS 新加坡 VPC 中，那么依然可以通过 GAAP 加速。而考虑到海外业务很多时候由于政策问题需要使用当地的云服务商，那么 GAAP 可能是比 AIA 更合适的加速方案。

本文简要地分享了腾讯云上各种网络的概念，从最基础的 VPC 和子网，到各种网络互通方案，比如对等连接，云联网。同时为了支持 IDC 和腾讯云网络的互通，还有基于公网的 VPN 方案以及专线方案。而腾讯云内部，不同 VPC 之间还可以通过私有连接来实现服务级别的相互访问，而不是网络地址空间的全部打通。

除了云上的内部网络，我们还关注用户怎么接入。这里首先就是 DNSPod，能够加速 DNS 的查询速度以及返回更适合用户网络的 IP 地址。而如果部署的服务器离用户很远，那么可以更多地利用腾讯云的骨干网来传输数据减少时延，这方面有 Anycast 和 GAAP 两种方案。Anycast 更简单，但是限制是访问的资源必须在腾讯云上，而 GAAP 基本上就属于对外售卖传输通道，访问的目标资源可以在任意的地方。

希望通过本文能够帮大家梳理一下上云需要涉及到的网络知识，遇到项目出海或者上云时，能够更从容地选择方案，也能更快地理由其它公有云提供的类似服务，进行择优选用。

}

传统的LVS负载均衡是一种集群( Cluster )技术，采用IP负载均衡技术和基于内容请求分发技术。LVS 有三种工作模式 DR 模式、NAT 模式及 TUNNEL 模式，三种模式分别都有各自的局限性。这样就催生了 CLB 概念。套用官网介绍：负载均衡（ Cloud Load Balancer ）是对多台云服务器进行流量分发的服务。负载均衡可以通过流量分发扩展应用系统对外的服务能力，通过消除单点故障提升应用系统的可用性。

这里首先需要了解下腾讯云相关的一些概念，有助于后续了解 CLB 业务。

腾讯云提供的一种网络负载均衡服务（ CLB ），可以结合 CVM 虚拟机为用户提供基于 TCP/UDP/HTTP/HTTPS 协议类型的负载均衡服务。

接受负载均衡分发请求的一组云服务器实例，负载均衡服务将访问请求按照用户设定的规则/权重转发到这一组后端 CVM 上进行应用处理。

腾讯云负载均衡分配给每个负载均衡实例的虚拟地址。客户端可以通过 vip+port 进行4层负载分发。也可以按照vip+vport+url进行7层负载分发。

目前存在两种监听器。传统公网固定IP类型的监听器包括监听端口，后端服务器端口、负载均衡策略、健康检查阀值配置和轮训方式等，每个监听器对应后端的一个应用服务。新版的应用型监听器只有监听端口属性（https 还有证书信息）。但是监听器下又可以创建域名和规则，规则中可以设置健康检查阀值、负载均衡策略、转发路径等信息。同时监听器维度存在几个概念需要了解下，主要如下：

vport：提供给客户端访问的端口

pport：LB 后端服务器需要启动的端口

轮询方式：目前只有权重轮询 /ip_hash/ 最小连接数三种轮询方式

会话保持：保证同一客户端多次请求在一定的时间内落地到后端同一台服务器上

snat：lb 是否支持后端服务器可以看到客户端的真实 ip，否则 RS 看到是 vip （ snat 不支持获取客户端 ip ）

健康检查：针对 lb 后端服务器端口存活状态进行检测，及时剔除异常端口的机器，保证服务稳定正常

公网 LB 支持 https 协议监听器，创建监听器过程中需要上传服务器和客户端证书。

内网 lb 主要提供给同 appid 下的子机之间进行负载均衡请求， lb 绑定的子机必须是 appid 下的子机，客户端请求子机也必须是 appid 下的子机。

公网 lb 开发商可以将自己的服务搭建在 lb 绑定的后端服务器上，然后提供给自己的用户使用进行访问。公网 lb 对绑定后端子机有一个要求：子机必须要有流量。

基础网络与私有网络之分

基础网络包含 vpc0 和实体网络子机，这里要求 lb 绑定的后端服务器必须是基础网络子机。当基础网络与 vpc 互通之后，基础网络子机也可以访问私有网络的 LB 服务。

私有网络即所有的 vpc>0 子机，这里同时要求 lb 绑定的后端服务器必须是私有网络子机。

物理网络与 VPC 网络之分

物理网络：这种网络架构是腾讯云最早使用的框架，有非常大的局限性，如下描述：A 受物理网络路由限制，子机不能跨机架迁移；B 子机 ip 固定，用户不可自定义；C 用户的子机 IP 无规律，不能划分网段，不方便管理。

VPC 网络：为了解决实体网络的限制，应运而生出来了私有网络。VPC 网络可以让虚拟机保持 IP 、 MAC 不变进行跨机架迁移。用户自定义网络，选择 IP 地址范围、管理子网、路由表和网关。支持 IPSec VPN 、 SSLVPN 、专线接入，满足 VPC 网络与客户本地数据中心部署混合云需求。

综上所述，所以目前公网 LB 同样也区分基础网络与私有网络类型。但是底层负载能力实现原理基本保持一致。

目前腾讯云内网 LB 只支持4层负载，不支持7层负载。公网 LB 同时支持7层和4层负载。下面介绍关于7层与4层的区别见下图。

4层 LB 主要是通过报文中的目的地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。负载能力实现主要基于数据包的传输层信息（ ip + port ）进行负载转发。

7层 LB 也成为“内容交换”，主要通过报文中真正有意义的应用层内容（证书，cookies，http头部信息），会在负载均衡设备上进行证书校验，三次握手等操作，再加上负载均衡设备设置的服务器选择方式，决定最终的内服务器。负载能力实现主要基于应数据包应用层信息（ domain+port+url 等）进行负载转发。

首先看下图，简单可以看到公网 LB 的实现主要是由 TGW （ tencent gateway ）实现。 TGW 集群承载腾讯流量入口，有着强大的负载均衡能力，当然也有其他重要能力（例如：ip 漂移，容灾等）。

大多数用户使用传统的 LB 主要具有三种使用场景：流量分发；横向扩展；业务分离。腾讯云目前提供两种类型的 LB：经典型和应用型。

腾讯云目前提供的经典型 LB （公网有日租）基本可以满足大部分用户的使用场景，但是有一定的局限性。主要局限性表现如下：

分配一个域名（带有腾讯云后缀的域名）
子机绑定在 LB 维度

这样就存在多个问题：域名含有腾讯云后缀，用户不可自定义；每个 LB-vip 对应一个域名，对 vip 造成大量浪费；7层访问只能细化到域名维度，不能在 url 维度进行细化。这样就应运而生了应用型 LB。

针对比较高端的用户使用场景比较复杂，腾讯云推出应用型 LB 可以在单个 LB 上实现业务分离，真正基于应用层内容进行负载均衡。如下图所示。这种类型的 LB 就完全弥补了传统LB的缺陷。主要优点整理如下：

不会分配固有域名，LB 下可以创建多个监听器
每个监听器下可以创建多个域名
每个域名下可以创建多个规则
子机绑定在规则维度，并且可以绑定一台子机上的多个端口

这样做的好处比较多：真正发挥 http 七层转发的优势，CLB 开始了解业务；有利于IP收敛，整个网站对外可以只使用一个公网IP；节省二级域名，减少DNS解析次数，有效提高用户访问速度；自定义转发规则，会话保持和健康检查的颗粒度可以细致到转发组级别。

公网 LB 流程中 TGW（ STGW ）中 ld 集群上需要区分vpc网络和物理网络。vpc网络采用gre隧道封装技术实现TGW和虚拟机之间进行通讯，物理网络采用IP隧道封装技术实现TGW和虚拟机之间进行通讯。7层和4层负载均衡实现分别是在不同的ld集群上进行，当然实现技术也是不一致的。如果不清楚gre和ip隧道区别，请看下图。

根据小编本人理解，gre 技术主要应用场景在于该数据包的目的地址不是 gre 里面封装的 ip 信息，但是数据包到达目的端之后需要 gre 的封装信息进行进一步操作（qcloud 目前当数据包到达母机之后，母机根据 gre 信息决定下一步路由）；IP 隧道主要应用场景在于该数据包的目的地址就是即将要封装的 ip 信息，可以理解为将新的 ip 把原来的数据包进行再一次封装，这样数据包才能根据封装的目的ip进行路由。

先对4层 VPC 网络负载均衡整体的架构做简单介绍。用户在 qcloud 控制台或者调用 api 操作之后，操作流最终会下发到 TGW 提供的 oss 组件模块，该 oss 模块主要负责提供接口（比分配 vip ，创建监听器，创建域名和规则等）供 qcloud 调用，ld 上存在组件将接口请求中的相关规则下发到集群内每个 ld 设备内核中，ld 上负载均衡转发功能主要由相关内核模块实现。

ld 上存在 gre 设备对数据包进行 gre 封装，将( vpcid,vmip )带入数据包，这样数据包就会将带有 gre 头的数据包发送给子机所在的母机。
vpc 母机上存在 gre 设备对数据包进行解封装，根据 vpcid 和 vmip 即可将请求发送给相应虚拟网桥下的对应子机。

首先在经过虚拟网桥之后 gre 设备需要对数据包进行 gre 封装，此时的目的 ip 为 tsvip ，源 ip 为 hostip。
则数据包可以正常返回给客户端。这样既可完成一次负载均衡数据交互。

整体流程上和 vpc 基本一样，只是在 TGW 和 cvm 之间通讯时通过 ip 隧道的方式进行的，TGW 的 ld 集群中存在内核模块对数据包进行 ip 隧道封装和解封装（如下图）。

7层LB目前使用的底层架构是 STGW （ TGW 的升级版），这里简单说一下 STGW 的强大之处。

内容路由（根据 url ， header 等字段深度匹配，精确、正则、前缀匹配）
负载均衡策略（加权轮询，ip_hash，最小连接数，一致性 hash）

7层针对 CLB 来讲主要是提供 http 和 https 服务， https 有三大功能：身份认证---防冒充；数据加密---防窃听；数据一致性---防篡改，防抵赖。目前 STGW 针对 https 性能做了很大提升，目前已经具有以下特点。

统一的证书管理及证书远程加载服务

其实和四层的区别主要是中间多了一层l7-ld，如下图所示为 vpc 公网 LB 数据流程图，这一层主要是做 nginx 反向代理和7层负载功能的。本应该 ld 和实体网络 vm 之间是可以通过普通的 ip 包进行数据交互的，但是 vpc 子机的话，存在私有网络和自定义 ip，ld 就没法和 vm 之间进行直接通讯了，目的 ip 为 vpc 子机的话，数据包是没法路由的。为了解决上面的问题，TGW 在l7-ld上安装了内核模块，该内核用来模拟 TGW 封装 gre 包，然后将 gre 后的数据包和 vpc 子机进行交互就没有任何问题了。qcloud 为腾讯云业务层，oss 模块接收到请求之后将规则下发到l7-nginx 的配置文件中，l7-nginx 通过反向代理功能和 nginx 本身负载均衡功能会进行

l7-nginx 提供的反向代理和负载均衡能力，这个是7层负载均衡的核心功能。上面谈到l7-agent 会下发业务侧的规则到l7-nginx 上，其实就是下发一个 nginx 的配置文件到l7-nginx 上，如下图所示。可以看到这个配置文件里面域名就是用户在控制台配置的域名，还有vip、vport信息、子机，权重等信息都存在这个配置文件中。

Upstream 为 nginx 负载均衡的主要模块。它提供了一个简单的方法实现在轮训和客户端 ip 之间的后端服务器负载均衡，并且可以对后端服务器进行健康检查。upstream 并不处理请求，而是通过请求后端服务器得到用户的请求内容。在转发给后端时，默认是轮询，也可以是 ip_hash。

当 Nginx 在检测到后端服务器故障后，nginx 依然会把请求转向该服务器，当 nginx 发现 timeout 或者 refused 后，会把改请求会分发到 upstream 的其它节点，直到获得正常数据后，nginx 才会把数据返回给用户，上面配置文件中 max_fails 和 fail_timeout 字段就是和健康检查相关的。

7层物理网络负载均衡实现方式和 vpc 网络唯一的不同就是数据包封装技术不同，因为物理网络不需要进行gre封装，直接IP隧道即可实现和子机通讯（如下图）。其他就没有必要再详细说了，和 vpc 基本保持一致。

目前腾讯云应用型 LB 支持请求重定向，域名端口 + 规则维度进行重定向。给用户直接的感受就是当你使用 url-a 在浏览器上进行访问时，请求会被自动重定向到 url-b 。这里底层的实现也是基于 nginx 的 rewrite 操作进行处理。当用户设置了重定向操作之后，会在 nginx 下发如下配置

在 Cookie 插入模式下，CLB 将负责插入 cookie ，后端服务器无需作出任何修改。当客户进行第一次请求时，客户 HTTP 请求（不带 cookie ）进入 CLB， CLB 根据负载平衡算法策略选择后端一台服务器，并将请求发送至该服务器，后端服务器进行 HTTP 回复（不带 cookie ）被发回 CLB ，然后 CLB 插入 cookie ，将 HTTP 回复（带 cookie ）返回到客户端。当客户请求再次发生时，客户 HTTP 请求（带有上次 CLB 插入的 cookie ）进入 CLB ，然后 CLB 读出 cookie 里的会话保持数值，将 HTTP 请求（带有与上面同样的 cookie ）发到指定的服务器，然后后端服务器进行请求回复，由于服务器并不写入 cookie ， HTTP 回复将不带有 cookie ，恢复流量再次经过进入 CLB 时，CLB 再次写入更新后的会话保持 cookie 。

实践一下看看，可以看到第一次访问时返回给客户端的 cookies 值

表示负载均衡系统会根据用户自定义cookie名称来分配和管理对客户端进行的cookie植入操作，便于用户识别和区分自定义的cookie名称，从而有选择的针对后端应用服务器上的不同应用设定会话保持规则，用户在进行配置时需要指定相应的cookie名称。目前腾讯云不支持这种类型（阿里云支持）。

服务器如何分辨请求类型

服务器如何获取来访者真实 IP

针对 7 层（ HTTP 协议）服务，负载均衡通过 Http Header:X-Real-IP 获取来访者真实 IP ，该功能已经默认开启，无需配置，也不能修改。针对 4层（ TCP 协议）服务可以直接获取，无需额外配置。

目前默认是 GET 方式进行请求，后续会改为默认使用 HEAD ，可选 GET 的请求方式。修改后的健康检查使用HTTP/1.1协议增加了 host 字段（ host 字段可配置）。 HEAD 和 GET 请求方式的区别如下：

HEAD：只请求页面的首部。
GET：请求指定的页面信息，并返回实体主体。

其中，默认使用 HEAD 方法请求的话，服务器返回的只是响应标题，可以有效降低后端开销，提高请求效率。但在某些业务场景下依然需要选取 GET 方式请求，例如在较为苛刻的健康检查时，需要通过判断 body 中某些字段来获取版本号等，此时 HEAD 请求返回的数据不足，需要通过 GET 来实现。

HTTP1.0：浏览器接收到头部信息后，接受完 Content-Length 中定义的长度字节后开始解析页面，但如果服务端有部分数据延迟发送吗，则会出现浏览器白屏，造成比较糟糕的用户体验。HTTP/1.1中引入了 Chunked transfer-coding 来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。该功能，主流的浏览器，以及 apache 、 nginx 等 web 服务器是默认支持的，无需配置。

实现 web 集群后，肯定会首先考虑 session 同步问题，因为通过负载均衡后，同一个 IP 访问同一个页面会被分配到不同的服务器上，如果 session 不同步的话，一个登录用户，一会是登录状态，一会又不是登录状态。腾讯云目前实现了集群内 session 连接定期同步。这样在别的服务器接管故障机器的包时，能够正确找到 session ，保证提供正常服务。不同集群之间进行 session 同步，目前腾讯云尚不支持。

利用 cookie 同步 session ：session 是文件的形势存放在服务器端的，cookie 是文件的形势存在客户端的，怎么实现同步呢？方法很简单，就是把用户访问页面产生的 session 放到 cookie 里面，就是以 cookie 为中转站。你访问 web 服务器 A，产生了 session 把它放到 cookie 里面了，你访问被分配到 web 服务器 B，这个时候，web 服务器 B 先判断服务器有没有这个 session ，如果没有，在去看看客户端的 cookie 里面有没有这个 session，如果也没有，说明 session 真的不存，如果 cookie 里面有，就把 cookie 里面的 sessoin 同步到 web 服务器 B，这样就可以实现 session 的同步了。

集群容灾，简单来说就是一个集群中一台服务器倒掉不会影响整个集群的服务能力。CLB 采用 ospf 动态路由协议来实现集群的容灾，若一台机器倒掉，ospf 协议可以保证在10s 以内把机器从集群中剔除。CLB 一个集群放在两个接入交换机下，并且保证跨机架的容灾，这样保证在即便有单边的交换机出故障或者单边机架掉电时，本集群的服务不受影响。

腾讯云有非常厉害的大禹系统来保护业务，但是大禹系统的宙斯盾的检测时长是10s，那么在大禹系统生效之前，可能客户的 RS 已经被压垮。为了解决这10s内的问题，我们开发了 synproxy 的功能。目前腾讯云这边的具体实现是：CLB 在接收到客户端的三步握手请求时，代理三步握手，在数据包到来之前，不会打扰到 RS，一旦第一个包到来，CLB 将其缓存，此时再和 RS 进行三步握手，握手成功之后，将缓存的数据包发送给 RS，之后的流程就透传数据包了。这样保证 DDos 攻击不会到达 RS，而是由 CLB 来承担压力。CLB本身承载能力比较强，又是集群模式，同时又具备资源隔离的能力，所以一般情况下，很难在10s以内把 CLB 机器压垮。

本文主要讲述了腾讯云 CLB 的基本概念，业务架构以及公网 LB 技术实现，希望对于大家理解负载均衡技术架构有所帮助。

}

①购买一个负载均衡LB实例

②一级、二级域名都解析到VIP上

在nginx中只需要配置好伪静态和相关设置就ok了

1 前言腾讯云负载均衡(Cloud LoadBalancer),简称CLB, 负载均衡通过设置虚拟服务地址(VIP)将来自客户端的请求按照指定方式分发到其关联的多台后端云服务器,服务器将请求的响应返 ...
欢迎大家前往云+社区,获取更多腾讯海量技术实践干货哦~ 作者:李想腾讯人做产品一直是很贴近用户的需求的,腾讯云也不例外.负载均衡器作为公有云上的最基础的网络服务,几乎每家云厂商都会提供,虽然负载均衡 ...
一.相关文档 1.证书服务 2.简单路由-HTTP 协议变为 HTTPS 协议二.阿里云操作界面 1.云盾证书服务管理控制台(查询CA证书服务) 2.负载均衡管理控制台三.相关文档 1.Syman ...
Nfs同步文件夹配置问题描述 : javaweb应用部署到云服务器上时,当服务器配置了SLB负载均衡的时候,多台服务器就会造成文件上传下载获取不到文件的错误, 解决办法有:1.hdfs 2.搭建f ...

一.sql server 不能连接远程服务器,但可以连接本地的数据库我目前用的是sql server 2012 sp1,用着用着突然就不能连接远程服务器上的数据库了,崩溃了一天... 修复试了,卸载 ...
针对app线上修复技术,目前有好几种解决方案,开源界往往一个方案会有好几种实现.重复的实现会有造轮子之嫌,但分析解决方案在技术上的探索和衍变,这轮子还是值得去推动的关于Hot Fix技术 Hot F ...

}

久游无息网