美团：2020年新业务及其他板块收入273亿元，同比增长33.6%
06-18
1.引言随着云计算技术的快速发展，负载均衡作为云计算服务的重要组成部分，已经成为云计算服务的重要组成部分。为企业和个人提供云计算服务的重要组成部分。
用户实现Web应用高可用性、高性能、高扩展性的关键技术。腾讯云七层负载均衡（CLB）作为腾讯云提供的核心负载均衡服务之一，以其灵活、高效的特点受到了广大用户的青睐。
在Web应用的实际部署和运维中，我们经常会遇到各种重定向需求，比如从HTTP安全升级到HTTPS、通过不同路径分配资源、根据用户状态提供个性化服务等。为了满足这些需求，我们需要深入了解CLB的重定向机制并掌握相应的配置技巧。
同时，随着网络安全意识的不断提高，我们也需要关注CLB可能带来的安全风险，并采取有效措施进行防范。本文旨在全面介绍腾讯云七层CLB的重定向功能及其在实际应用中的各种场景。
我们将从基础知识开始，逐步深入到高级配置和优化策略，力争为读者提供系统、全面的CLB重定向指南。此外，我们还将结合具体案例和错误示例来分析CLB在实际应用中可能遇到的问题和解决方案，帮助读者更好地理解和应用CLB的重定向功能。
2. 重定向状态码的详细信息请参考HTTP/1.1标准（RFC）。状态代码表示永久重定向。
当资源永久移动到新 URL 时，服务器会返回状态代码。这意味着客户应该更新其书签和引用，因为将来再次访问时旧 URL 将不再有效。
搜索引擎还将更新其索引，用新 URL 替换旧 URL，这有助于 SEO 优化。临时重定向，当资源临时移动到新的URL时，服务器返回一个状态码。
此时，当客户端在将来的某个时刻再次访问旧的URL时，可能会找到原来的资源。因此，客户端不需要更新书签和引文，但搜索引擎可能不会立即更新其索引，这可能会对SEO造成一些影响。
状态码明确表明客户端应使用相同的请求方法（例如 GET、POST 等）重定向到新的 URL，而不是像 / 状态码那样将请求方法默认更改为 GET。这使得在处理 POST 请求等复杂请求时状态码更加清晰和安全。
注意，跳转，跳转后的协议是GET，跳转前的协议不能保留。例如，客户端发送 HTTP POST GET。
HTTP监听转发，默认使用80端口。创建成功后，HTTP:80地址会自动跳转到HTTPS:地址进行访问。
1、前提和限制前提是已经创建了80监听器和监听器，并且80对应HTTP和HTTPS，不支持其他指定端口。限制重定向配置包括协议/端口、域名和路径的配置。
为避免环回，请注意以下限制信息： 如果原访问路径与重定向访问路径一致，则不允许配置。如果原访问路径已经配置了重定向策略（包括原访问路径和重定向访问路径），则不允许再次配置。
如果配置的重定向访问路径是其他重定向策略的原始访问路径，则不允许配置。同时，要跳转的80监听不需要绑定任何RS，因为它实际上并不提供服务。
只需将 RS 绑定到监听器即可。 80监听器的HTTP请求到达LB七层网关STGW后，会跳转到监听器，由监听器对应路径下的RS提供服务： 2.示例及等效nginx配置控制台配置： 配置完成后可以看到自动重定向会将客户端携带的完整路径传递给重定向 定向 HTTPS： 强制 HTTP 为 HTTPS，类似 nginx 返回： 代码语言： nginx copy server { Listen 80; }服务器名称domain.com；返回 { 听 80;服务器名称domain.com；位置 / { 重写 ^( .*)$ 永久; }} 4. 手动重定向 这种类型的重定向比较灵活。
您可以手动指定哪个监听器URL跳转到哪个监听器URL。它还支持同一侦听器的不同 URL 规则。
之间跳转。例如从80监听的/跳转到80监听的/demo路径： 1、保留URL和不保留URL 1）保留URL还是以上面的自动重定向配置为例。
当勾选Keep URL时，客户端携带的URL路径将被附加到重定向的URL上：这个路径看起来很奇怪。理论上，访问/keepurl应该跳转到/demo/keepurl，对吧？因为80监听器写的是/demo路径而不是/demo/路径。
如果我们把80监听的/demo改为/demo/：重定向规则也跳转到/demo/：此时重定向保留了URL，符合我们的预期：与nginx配置类似：代码语言: nginx 复制服务器 { 监听 80;服务器名称domain.com；位置 / { 重写 ^(.*)$ 重定向; # 或 return }}2) 如果不保留 URL，以 80 监听器/跳转到 80 监听器/demo 监听器为例： 不保留 URL 时，会正常跳转到 /demo 路径，不带跳转前的URL：对应的nginx配置可以是：代码语言：nginx copy server {listen 80;服务器名称domain.com；位置 / { 重写 ^( .*)$ 重定向; # 或返回 }}2.不同监听器、不同域名之间的跳转，比如从80监听器的domain.com跳转到监听器的newdomain.com：这里有3个URL（/、/demo、/test）重定向到新域名。是否保留URL不再赘述。
请参考上述案例。下面是不保留URL的例子：类比nginx配置，效果相同： 代码语言： nginx copy server {listen 80;服务器名称domain.com；位置/{返回}位置/演示{返回}位置/测试{返回}}3.跳转到不同监听的同一个域名，比如从80监听的domain.com跳转到监听的domain.com，以保留的URL为例：是不是和之前的自动重定向类似？有相似之处，也有不同之处。
相似之处在于它们都可以从http重定向到https，但是手动重定向是可选的，并且不保留保留URL的能力。自动重定向将默认保留 URL，手动重定向的功能将被覆盖。
自动重定向或自动重定向的效果是手动重定向的子集。此重定向配置类似于等效的 nginx 配置： 代码语言： nginx copy server { Listen 80;服务器名称domain.com；返回 { 听 80;服务器名称domain.com；位置 / { 重写 ^(.*)$ 重定向; } }4.同一个监听器的不同域名跳转，比如将监听器的domain.com重定向到监听器的newdomain.com，并保留URL：类比nginx配置，效果相同： 代码语言： nginx copy server {listen ssl;服务器名称domain.com；位置/{返回}}5。
同一个监听跳转到同一个域名但不同的URL。例如将80监听的domain.com路径/跳转到/demo/，保留URL：同上 nginx配置效果： 代码语言： nginx copy server { Listen 80; }服务器名称domain.com； location / { return }} 五、默认域名和根URL带来的安全问题及解决方案 1、默认域名带来的安全问题 七层CLB有默认域名的概念。
当客户端携带的HTTP头中的HOST字段与监听器下的任何域名都不匹配时，最终会匹配该域名，并转发给该域名。比如80监听，默认域名为domain.com：此时我在客户端执行curl请求，请求为LB VIP，HOST默认使用VIP，不涉及任何域名：看RS抓包，STGW转发发送给RS时，携带的HOST也是VIP：STGW成功将请求透传到默认域名domain.com，RS根路径下。
这会带来一些安全问题。如果针对所有外网客户端，则外网客户端只需发起七层HT??TP检测即可。
LB收到请求后，将其转发给默认域名下的RS。 RS将接收并处理请求意味着所有来者都不会被拒绝。
在一些安全要求较高的业务场景中，这是我们不希望看到的。2、解决办法要么是在RS业务层拒绝此类非法请求，只允许特定域名访问，其他域名不允许；或代表LB应答此类非法请求，不将此类请求转发给RS处理，且不占用空间。
必要的 RS 性能。 1）RS业务层首先看第一种方案。
RS拒绝此类非法请求，只允许特定域名的HOST访问。 RS以nginx web业务为例： 代码语言： nginx copy server { Listen 80 default_server;服务器名称“”；返回;}服务器{听80;服务器名称domain.com； ...省略} 在第一个服务器模块中，我们监听80端口，server_name为空，在第二个服务器模块中，我们指定我们的正常业务域名。
通过这两种组合，当客户端携带的HOST不是domain.com时，服务器将变得无响应并关闭连接。在RS上测试：第一个红圈应该表明domain.com没有作为HOST携带，并且收到空响应，第二个红圈应该是正常响应。
此时LB在客户端进行测试：客户端收到STGW返回的状态码。为什么不是“服务器回复为空”？因为STGW将客户端的GET请求转发给RS后，RS并没有返回正常的数据。
STGW 将状态代码响应给客户端。 RS中的抓包现象如下：RS收到客户端的GET请求，且HOST为LB VIP，nginx判断HOST不是domain.com，然后匹配server_name为空的情况。
因此，没有响应任何数据，但请求FIN和ACK。也可以让nginx返回： 代码语言： nginx copy server { Listen 80 default_server;服务器名称“”；返回;}服务器{听80;服务器名称domain.com； ...省略} 此时客户端收到的是RS状态码，而不是STGW，但没必要浪费不必要的业务流量。
如果可以退货，则不予退货。如果能被LB挡住，就让LB挡住。
2）七层CLB层因此有第二种解决方案：在LB上应答此类非法请求。这样的请求不应该转发给RS进行处理，这会占用不必要的RS性能。
在80监听下新建域名规则。您可以根据需要编写域名。
你可以写LB的IP或者任何IP或域名，只要不是我们的业务域名即可，并且不绑定任何RS后端服务如下：我们将业务域名设置为newdomain.com，并且不是默认值。此时我们通过VIP访问LB 80监听：LB收到请求后匹配默认域名，但该域名下没有RS服务。
STGW应答状态码，返回内容长度为0。当HOST指定为newdomain.com时，就会匹配我们的业务域名。
RS 正常响应数据。其他非法域名则由STGW以状态码应答，并且不返回任何数据： 3.想象一下根URL引起的安全问题。
场景，客户端正在使用诸如 gobuster 之类的扫描仪，并且想要扫描服务器上存在的文件或资源。这时，如果LB监听有/路径，并且绑定了RS业务，那么每次客户端扫描时，LB都会转发给RS，RS最终返回一些敏感文件数据。
这时我们要做的就是避免使用/路径，而改用分层目录或者长目录，防止RS每次恶意扫描都响应数据，浪费不必要的业务资源，带来很大的数据安全风险。 4、解决方案1）当根路径没有与RS绑定，不能准确匹配其他路径时，作为保证，至少会匹配根路径。
当根路径没有与RS绑定时，STGW会代为应答： 2）删除根路径，成为根路径。当路径不存在时，客户端向服务器请求路径。
如果不匹配任何一项，STGW将代表应答： STGW应答OK以及应答所消耗的字节数： 可以清楚地看到消耗会比OK的要大。 ，而扫描软件最终判定OK状态码是正常的，因此OK响应行为甚至会迷惑客户端对恶意扫描结果的判断，所以推荐第一种方案。
6. 一些错误示例 1. 无限重定向循环/太多重定向。常见错误之一是无休止的重定向循环。
浏览器最终会报告重定向次数过多。我们看看为什么会报错。
首先我们做了一层HTTP到HTTPS的自动重定向：访问HTTP，最后跳转到监听器的rokasyangtest.com。这一层没有问题：监听器后面绑定的RS是HTTP服务，端口是80。
紧接着，listener/listener后面绑定的RS服务对应的服务端口也被重定向了： 代码语言：nginx copy server {listen 80;服务器名称 rokasyangtest.com；重写 ^(.*)$ 重定向；根/var/www/html； indexindex.htmlindex.htmindex.nginx-debian.html;}将http重定向到https，这就是问题所在。整个重定向过程如下： 解决方案很简单，要么将LB绑定的RS服务从HTTP 80修改为HTTPS，要么取消RS的HTTP重定向。
显然，后者更为合理。无需在 CLB --> RS 部分中使用 HTTPS。
此段已经是云上VPC的内网了。 Client -> LB 可以是 HTTPS，LB-->RS 需要另外一层 HTTPS。
会增加不必要的开销，整体访问时间也会增加。取消nginx的80监听器跳转：代码语言：nginx copy server {listen 80;服务器名称 rokasyangtest.com； #rewrite ^(.*)$ 重定向；根/var/www/html；索引index.html索引。
htm index.nginx-debian.html;} 访问https，最终正常得到业务响应。 2. 协议不匹配 1) 前端协议使用错误 使用HTTP 协议访问HTTPS 监听器： 正如预期，STGW 将返回错误。
使用HTTPS协议访问HTTP监听：SSL协议错误或版本错误。 2）后端协议使用错误。
后端协议使用HTTPS。 RS实际的业务是HTTP。
我们将后端协议改为https，但是绑定的RS服务和端口仍然是HTTP：首先健康检查会变成异常：在RS中抓包可以发现RS无法处理此类请求并返回Bad Request：这时候我们看看客户端返回的是什么：STGW应答的状态码，但是实际的RS并没有生成，STGW也没有得到RS的正常返回数据。 ，在这种情况下，将代表客户回答客户。
7.总结 至此，我们已经简单深入地讲解了七层CLB重定向的所有情况以及具有同等效果的Nginx配置。还涵盖了默认域名和根URL带来的安全风险和相应的解决方案，并对LB进行了分析。
一些错误示例，比如重定向太多、协议不匹配等。如果想进一步讨论CLB的性能优化和监控方面。
首先，为了提高CLB的性能，我们可以采取以下措施： 优化后端服务：保证后端服务能够快速响应请求，减少CLB的等待时间。资源合理配置：根据业务需求和流量特征，合理配置CLB计算和网络资源。
使用长连接：使用LB到RS的长连接，减少CLB与后端服务之间的连接建立和关闭次数，提高响应速度，减少连接开销。其次，为了更好的监控CLB的运行状况，我们可以使用腾讯云提供的监控工具，比如云监控、报警服务等。
通过实时监控CLB的各项指标，比如请求量、响应量等时间、错误率等，我们可以及时发现潜在的问题并采取相应的措施。另外，设置合理的报警规则可以帮助我们在出现异常情况时尽快得到通知，从而保证业务的稳定运行。
总之，腾讯云七层CLB是一种高效、灵活的负载均衡解决方案，可以满足各种复杂场景的需求。通过深入了解其重定向机制、安全风险和优化策略，我们可以更好地利用CLB为业务发展提供有力支持。
在未来的实践中，我们将持续关注CLB的发展，并分享更多其应用和优化的实践经验。
版权声明：本文内容由互联网用户自发贡献，本站不拥有所有权，不承担相关法律责任。如果发现本站有涉嫌抄袭的内容，欢迎发送邮件 举报，并提供相关证据，一经查实，本站将立刻删除涉嫌侵权内容。
标签：
相关文章
06-17
06-17
06-18
06-18
06-17
06-18
最新文章
【玩转GPU】ControlNet初学者生存指南
【实战】获取小程序中用户的城市信息（附源码）
包雪雪简单介绍Vue.js：开学
Go进阶：使用Gin框架简单实现服务端渲染
线程池介绍及实际案例分享
JMeter 注释 18 - JMeter 常用配置组件介绍
基于Sentry的大数据权限解决方案
【云+社区年度征文集】GPE监控介绍及使用