计划和实现 Azure 应用程序网关

  • 10 分钟

Azure 应用程序网关是一种 Web 流量（OSI 第 7 层）负载均衡器，可用于管理 Web 应用程序的流量。 传统负载均衡器在传输层（OSI 层 4 - TCP 和 UDP）进行操作，并基于源 IP 地址和端口将流量路由到目标 IP 地址和端口。

应用程序网关可以根据 HTTP 请求的其他属性（例如 URI 路径或主机头）进行路由决策。 例如，可以基于传入 URL 路由流量。 因此，如果 /images 在传入的 URL 中，则你可以将流量路由到为映像配置的一组特定服务器（称为池）中。 如果 /video 在 URL 中，则会将流量路由到为视频优化的另一个池。

显示 Azure 应用程序网关示例的关系图。

这种类型的路由称为应用程序层（OSI 层 7）负载均衡。 Azure 应用程序网关可以执行基于 URL 的路由等操作。

应用程序网关组件

应用程序网关充当客户端的单一联络点。 它在包括 Azure VM、虚拟机规模集、Azure 应用服务和本地/外部服务器的多个后端池之间分配传入的应用程序流量。

显示 Azure 应用程序网关组件的关系图。

基础结构

应用程序网关基础结构包括虚拟网络、子网、网络安全组和用户定义路由。

前端 IP 地址

可将应用程序网关配置为使用公共 IP 地址和/或专用 IP 地址。 托管需要由客户端在 Internet 中通过面向 Internet 的虚拟 IP (VIP) 访问的后端时，必须使用公共 IP。

不向 Internet 公开的内部终结点不需要公共 IP 地址。 专用前端配置适合用于不向 Internet 公开的内部业务线应用程序。 对于位于不向 Internet 公开的安全边界内的多层级应用程序中的服务和层级，它也很有用，但需要启用轮循机制负载分配、会话粘性或 TLS 终止。

仅支持一个公共 IP 地址和一个专用 IP 地址。 在创建应用程序网关时选择前端 IP。

注意

应用程序网关前端支持双堆栈 IP 地址（公共预览版）。 最多可以创建四个前端 IP。 两个 IPv4 地址（公共和专用）和两个 IPv6 地址（公共和专用）。

  • 对于公共 IP 地址，可以在应用程序网关所在的位置创建新的公共 IP 地址或使用现有的公共 IP。 有关详细信息，请参阅静态与动态公共 IP 地址。
  • 对于专用 IP 地址，可以在创建应用程序网关的子网中指定一个专用 IP 地址。 对于应用程序网关 v2 SKU 部署，必须在向网关添加专用 IP 地址时定义静态 IP 地址。 对于应用程序网关 v1 SKU 部署，如果未指定 IP 地址，则会自动从子网中选择可用的 IP 地址。 以后无法更改选定的 IP 地址类型（静态或动态）。

某个前端 IP 地址将关联到检查前端 IP 上的传入请求的侦听器。

可以创建具有相同端口号的专用和公共侦听器。 但是，请注意与应用程序网关子网关联的任何网络安全组 (NSG)。 根据 NSG 的配置，可能需要将目标 IP 地址作为应用程序网关的公共和专用前端 IP 的允许入站规则。 在使用同一端口时，应用程序网关会将入站流的“目标”更改为网关的前端 IP。

入站规则：

  • 源：根据要求
  • 目标：应用程序网关的公共和专用前端 IP。
  • 目标端口：根据配置的侦听器
  • 协议：TCP

出站规则：无特定要求

侦听器

侦听器是一个逻辑实体，它可以使用端口、协议、主机和 IP 地址检查传入的连接请求。 配置侦听器时，必须输入与网关上传入请求中的对应值相匹配的值。

使用 Azure 门户创建应用程序网关时，还可以通过选择侦听器的协议和端口来创建默认的侦听器。 可以选择是否要在侦听器上启用 HTTP2 支持。 创建应用程序网关后，可以编辑该默认侦听器的设置 (appGatewayHttpListener) 或创建新的侦听器。

侦听器类型

侦听器是检查传入连接请求的逻辑实体。 如果与请求关联的协议、端口、主机名和 IP 地址匹配与侦听器配置关联的相同元素，侦听器将接受该请求。

在使用应用程序网关之前，必须至少添加一个侦听器。 可将多个侦听器附加到一个应用程序网关，这些侦听器可用于同一个协议。

侦听器检测到来自客户端的传入请求后，应用程序网关将这些请求路由到规则中配置的后端池中的成员。

侦听器支持以下端口和协议。

端口

侦听器在某个端口上侦听客户端请求。 可以按照以下方式为 v1 和 v2 SKU 配置端口。

SKU 支持的端口范围 异常
V2 1 到 64999 22
V1 1 到 65502 3389

协议

应用程序网关支持四种协议：HTTP、HTTPS、HTTP/2 和 WebSocket：

注意

仅针对连接到应用程序网关侦听程序的客户端提供了 HTTP/2 协议支持。 与后端服务器池的通信始终通过 HTTP/1.1 进行。 默认情况下，HTTP/2 支持处于禁用状态。 可以选择启用该协议。

  • 在侦听器配置中指定 HTTP 或 HTTPS 协议。
  • 原生支持 WebSocket 和 HTTP/2 协议，默认已启用 WebSocket 支持。 用户无法通过配置设置来选择性地启用或禁用 WebSocket 支持。 对 HTTP 和 HTTPS 侦听器使用 WebSocket。

使用 HTTPS 侦听器进行 TLS 终止。 HTTPS 侦听器可将加密和解密工作卸载到应用程序网关，以避免加密和解密开销给 Web 服务器造成负担。

请求传递规则

使用 Azure 门户创建应用程序网关时，可创建一个默认规则 (rule1)。 此规则会将默认侦听器 (appGatewayHttpListener) 绑定到默认后端池 (appGatewayBackendPool) 和默认后端 HTTP 设置 (appGatewayBackendHttpSettings)。 创建网关后，可以编辑该默认规则的设置，或创建新的规则。

规则类型

创建规则时，可以选择“基本”或“基于路径”。

  • 若要将关联的侦听器（例如 blog.contoso.com/*）上的所有请求转发到单个后端池，请选择“基本”。
  • 若要将来自特定 URL 路径的请求路由到特定的后端池，请选择“基于路径”。 路径模式仅应用到 URL 的路径，而不应用到该 URL 的查询参数。

关联的侦听器

将一个侦听器关联到该规则，以评估与该侦听器关联的请求路由规则，从而确定请求要路由到的后端池。

关联的后端池

将规则关联到包含后端目标的后端池，该池为侦听器收到的请求提供服务。

  • 如果使用基本规则，则只允许一个后端池。 关联的侦听器上的所有请求都将转发到该后端池。
  • 如果使用基于路径的规则，请添加对应于每个 URL 路径的多个后端池。 与输入的 URL 路径匹配的请求将转发到相应的后端池。 另请添加默认后端池。 与规则中的任何 URL 路径都不匹配的请求将转发到该池。

关联的后端 HTTP 设置

为每个规则添加后端 HTTP 设置。 系统使用此设置中指定的端口号、协议和其他信息，将请求从应用程序网关路由到后端目标。

如果使用基本规则，则只允许一个后端 HTTP 设置。 系统会使用此 HTTP 设置将关联的侦听器上的所有请求转发到相应的后端目标。

如果使用基于路径的规则，请添加对应于每个 URL 路径的多个后端 HTTP 设置。 系统使用对应于每个 URL 路径的 HTTP 设置，将与此设置中的 URL 路径匹配的请求转发到相应的后端目标。 另请添加默认 HTTP 设置。 系统会使用默认 HTTP 设置，将与此规则中的任何 URL 路径都不匹配的请求转发到默认后端池。

重定向设置

如果为基本规则配置了重定向，则关联的侦听器上的所有请求将重定向到目标。 此过程称为全局重定向。 如果为基于路径的规则配置了重定向，则只会重定向特定站点区域中的请求。 区域的示例包括 /cart/* 表示的购物车区域。 此过程称为基于路径的重定向。

侦听器

选择侦听器作为重定向目标可将来自网关上的一个侦听器的流量重定向到另一个侦听器。 想要启用 HTTP 到 HTTPS 的重定向时，必须指定此设置。 此设置将来自源侦听器（用于检查 HTTP 请求）的流量重定向到目标侦听器（用于检查传入的 HTTPS 请求）。 还可以选择在转发到重定向目标的请求中包含来自原始请求的查询字符串和路径。

显示重定向配置设置页面示例的屏幕截图。

外部站点

若要将与此类规则关联的侦听器上的流量重定向到外部站点，请选择外部站点。 可以选择在转发到重定向目标的请求中包含来自原始请求的查询字符串。 无法将原始请求中的路径转发到外部站点。

重写 HTTP 标头和 URL

通过使用重写规则，当请求和响应数据包通过应用程序网关在客户端和后端池之间移动时，你可以添加、删除或更新 HTTP(S) 请求和响应标头以及 URL 路径和查询字符串参数。

这些标头和 URL 参数可以设置为静态值，也可以设置为其他标头和服务器变量。 这有助于处理重要的用例，例如提取客户端 IP 地址、删除有关后端的敏感信息、添加更多安全性等。

HTTP 设置

应用程序网关使用此处指定的配置将流量路由到后端服务器。 创建 HTTP 设置后，必须将其关联到一个或多个请求路由规则。

Azure 应用程序网关使用网关托管 Cookie 来维护用户会话。 当用户将第一个请求发送到应用程序网关时，它会在响应中使用包含会话详细信息的哈希值来设置关联 Cookie，将具有关联 Cookie 的后续请求路由到同一后端服务器，以便保持粘性。

当要在同一台服务器上保存用户会话时，以及在服务器上以本地方式为用户会话保存会话状态时，可以使用此功能。 如果应用程序无法处理基于 Cookie 的相关性，则你无法使用此功能。 若要使用此功能，请确保客户端支持 Cookie。

注意

由于未设置 Secure 或 HttpOnly 标志，某些漏洞扫描可能会标记应用程序网关相关性 Cookie。 这些扫描没有考虑到 Cookie 中的数据是使用单向哈希生成的。 Cookie 不包含任何用户信息，仅用于路由。

连接清空

连接排出可帮助你在计划内服务更新期间正常移除后端池成员。 它适用于以下后端实例：

  • 显式从后端池中删除的后端实例，
  • 在横向缩减操作期间删除的后端实例，或者
  • 由运行状况探测报告为不正常的后端实例。

可以通过在“后端设置”中启用“连接排出”来将此设置应用于所有后端池成员。 它确保后端池中的所有取消注册实例不会收到任何新的请求/连接，同时保持现有连接，直到达到配置的超时值。 对于 WebSocket 连接，也是如此。

配置类型 值
后端设置中未启用连接排出时的默认值 30 秒
在后端设置中启用连接排出时用户定义的值 1 到 3600 秒

此情况的唯一例外是由于网关托管会话相关性而绑定到注销实例的请求，这些请求将继续被转发到注销实例。

协议

应用程序网关支持使用 HTTP 和 HTTPS 将请求路由到后端服务器。 如果选择了 HTTP 协议，则流量将以未加密的形式传送到后端服务器。 如果不能接受未加密的通信，请选择 HTTPS。

在侦听器中结合 HTTPS 使用此设置将有助于实现端到端的 TLS。 这样，就可以安全地将敏感数据以加密的形式传输到后端。 后端池中每个已启用端到端 TLS 的后端服务器都必须配置证书，以便能够进行安全的通信。

端口

此设置指定后端服务器要在哪个端口上侦听来自应用程序网关的流量。 可以配置 1 到 65535 的端口号。

受信任的根证书

如果选择 HTTPS 作为后端协议，则应用程序网关需要受信任的根证书来信任端到端 SSL 的后端池。 默认情况下，“使用已知 CA 证书”选项设置为“否”。 如果计划使用自签名证书或内部证书颁发机构签名的证书，则必须为应用程序网关提供后端池将使用的匹配公共证书。 此证书必须以 .CER 格式直接上传到应用程序网关。

如果计划在后端池中使用由受信任的公共证书颁发机构签名的证书，则可将“使用已知的 CA 证书”选项设置为“是”并跳过上传公共证书。

请求超时

此设置表示应用程序网关在接收后端服务器的响应时会等待多少秒。

替代后端路径

使用此设置可以配置可选的自定义转发路径，以便在将请求转发到后端时使用。 与“替代后端路径”字段中的自定义路径匹配的任意传入路径部分将复制到转发的路径。 下表描述了此功能的工作原理：

将 HTTP 设置附加到基本请求路由规则时：

原始请求 替代后端路径 请求被转发到后端
/home/ /override/ /override/home/
/home/secondhome/ /override/ /override/home/secondhome/

将 HTTP 设置附加到基于路径的请求路由规则时：

原始请求 路径规则 替代后端路径 请求被转发到后端
/pathrule/home/ /pathrule* /override/ /override/home/
/pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/
/home/ /pathrule* /override/ /override/home/
/home/secondhome/ /pathrule* /override/ /override/home/secondhome/
/pathrule/home/ /pathrule/home* /override/ /override/
/pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/
/pathrule/ /pathrule/ /override/ /override/

使用自定义探测

此设置用于将自定义探测与某个 HTTP 设置相关联。 只能将一个自定义探测关联到某个 HTTP 设置。 如果未显式关联自定义探测，则会使用默认探测来监视后端的运行状况。 我们建议创建自定义探测，以便更好地控制后端的运行状况监视。

注意

只有在将相应的 HTTP 设置显式关联到某个侦听器之后，自定义探测才会监视后端池的运行状况。

配置主机名

应用程序网关允许与后端建立的连接使用的主机名不同于客户端用来连接到应用程序网关的主机名。 虽然在某些情况下此配置可能很有用，但若要替代主机名以使客户端和应用程序网关之间的主机名不同于应用程序网关和后端目标之间的主机名，应谨慎为之。

在生产环境中，建议将客户端到应用程序网关之间使用的主机名保留为应用程序网关到后端目标之间使用的主机名。 这可以避免绝对 URL、重定向 URL 和主机绑定 Cookie 出现潜在问题。

在设置偏离此配置的应用程序网关之前，请查看此类配置的影响，这在体系结构中心内进行了更详细的讨论：保留反向代理与其后端 Web 应用程序之间的原始 HTTP 主机名。

HTTP 设置在两个方面影响着应用程序网关用于连接到后端的主机 HTTP 标头：

  • 从后端地址中选取主机名
  • 主机名替代

从后端地址中选取主机名

此功能将请求中的 host 标头动态设置为后端池的主机名。 主机名使用 IP 地址或 FQDN。

如果后端的域名不同于应用程序网关的 DNS 名称，并且后端必须使用特定的 host 标头才能解析为正确的终结点，则此功能会很有帮助。

例如，作为后端的多租户服务。 应用服务是一种多租户服务，使用具有单个 IP 地址的共享空间。 因此，只能通过自定义域设置中配置的主机名访问应用服务。

自定义域名默认为 example.azurewebsites.net。 若要通过未显式注册到应用服务中的主机名或者通过应用程序网关的 FQDN 使用应用程序网关访问应用服务，可以将原始请求中的主机名替代为应用服务的主机名。 为此，请启用“从后端地址中选取主机名”设置。

对于其现有自定义 DNS 名称映射到应用服务的自定义域，建议的配置是不启用“从后端地址中选取主机名”。

主机名替代

此功能可将应用程序网关上的传入请求中的 host 标头替换为指定的主机名。

例如，如果在“主机名”设置中指定了 www.contoso.com，则当请求被转发到后端服务器时，原始请求 *https://appgw.eastus.cloudapp.azure.com/path1 会更改为 *https://www.contoso.com/path1。

后端池

可将后端池指向 4 种类型的后端成员：特定的虚拟机、虚拟机规模集、IP 地址/FQDN 或应用服务。

创建后端池后，必须将其关联到一个或多个请求路由规则。 此外，必须为应用程序网关上的每个后端池配置运行状况探测。 满足请求路由规则条件时，应用程序网关会将流量转发到相应后端池中正常运行的服务器（是否正常由运行状况探测决定）。

运行状况探测

Azure 应用程序网关监视其后端池中所有服务器的运行状况，并自动停止向其认为运行不正常的任何服务器发送流量。 探测继续监视此类运行不正常的服务器，只要探测检测到流量正常，网关就会再次将流量路由到该服务器。

默认探测使用关联后端设置的端口号和其他预设配置。 可以使用自定义探测按照自己的方式来配置。

探测行为

源 IP 地址

探测的源 IP 地址取决于后端服务器类型：

  • 如果后端池中的服务器是公共终结点，则源地址是应用程序网关的前端公共 IP 地址。
  • 如果后端池中的服务器是专用终结点，则源 IP 地址来自应用程序网关子网的地址空间。

探测操作

在配置规则后，网关立即启动探测，方法是将规则与后端设置和后端池（当然还有侦听器）相关联。 下图显示网关独立探测所有后端池服务器。 开始到达的传入请求仅发送到运行正常的服务器。 默认情况下，后端服务器标记为运行不正常，直到收到成功的探测响应。

显示 Azure 应用程序网关运行状况探测操作示例的关系图。

所需的探测是根据后端服务器和后端设置的唯一组合确定的。 例如，假设网关有一个带有两个服务器和两个后端设置的后端池，这些服务器和后端设置具有不同的端口号。 当这些不同的后端设置使用各自的规则与同一后端池相关联时，网关会为每个服务器和后端设置的组合创建探测。 可以在后端运行状况页上查看此信息。

显示后端运行状况设置示例的屏幕截图。

此外，应用程序网关的所有实例探测相互独立的后端服务器。

注意

后端运行状况报告根据相应的探测的刷新间隔进行更新，不依赖于用户的请求。

默认的运行状况探测

如果未设置任何自定义探测配置，应用程序网关自动配置默认运行状况探测。 监视行为的工作方式是向在后端池中配置的 IP 地址或 FQDN 发出 HTTP GET 请求。 对于默认探测，如果后端 http 设置是针对 HTTPS 配置的，则探测会使用 HTTPS 测试后端服务器的运行状况。

例如：将应用程序网关配置为使用 A、B 和 C 后端服务器来接收端口 80 上的 HTTP 网络流量。 默认运行状况监视每隔 30 秒对三台服务器进行测试，以获取每个请求 30 秒超时的正常 HTTP 响应。 正常的 HTTP 响应具有 200 到 399 的状态代码。 在这种情况下，运行状况探测的 HTTP GET 请求类似于 http://127.0.0.1/。 另请参阅应用程序网关中的 HTTP 响应代码。

如果服务器 A 的默认探测检查失败，应用程序网关将停止将请求转发到此服务器。 默认探测仍继续每隔 30 秒检查服务器 A。 当服务器 A 成功响应默认运行状况探测发出的请求时，应用程序网关会开始再次将请求转发到此服务器。

默认的运行状况探测设置

探测属性 值 说明
探测 URL <协议>://127.0.0.1:<端口>/ 协议和端口继承自探测与之关联的后端 HTTP 设置
时间间隔 30 发送下一个运行状况探测前需要等待的时间（以秒为单位）。
超时 30 将探测标记为不正常前，应用程序网关等待探测响应的时间（以秒为单位）。 如果探测返回为正常，则相应的后端立即被标记为正常。
不正常阈值 3 控制在定期运行状况探测出现故障的情况下要发送的探测数。 在 v1 SKU 中，快速连续发送这些额外的运行状况探测，以快速确定后端的运行状况，并且无需等待探测时间间隔。 对于 v2 SKU，运行状况探测会等待一段时间间隔。 连续探测失败计数达到不正常阈值后，将后端服务器标记为故障。

默认探测只查看 <协议>://127.0.0.1:<端口> 来判断运行状况。 如果需要配置运行状况探测以使其转到自定义 URL 或修改任何其他设置，必须使用自定义探测。

自定义的运行状况探测

使用自定义探测可以更精细地控制运行状况监视。 使用自定义探测时，可以配置自定义主机名、URL 路径、探测间隔，以及在将后端池实例标记为不正常之前可接受的失败响应次数等。

自定义的运行状况探测设置

下表提供自定义运行状况探测的属性的定义。

探测属性 说明
名称 探测的名称。 此名称用于在后端 HTTP 设置中标识和引用探测。
协议 用于发送探测的协议。 这必须与它关联到的后端 HTTP 设置中定义的协议匹配
主机 发送探测时使用的主机名。 在 v1 SKU 中，此值仅用作探测请求的主机头。 在 v2 SKU 中，此值用作主机头和 SNI
路径 探测的相对路径。 有效路径以“/”开头
端口 如果已定义，它将用作目标端口。 否则，它会使用与其关联的 HTTP 设置相同的端口。 此属性仅在 v2 SKU 中可用
时间间隔 探测间隔（秒）。 此值是每两次连续探测之间的时间间隔
超时 探测超时（秒）。 如果在此超时期间内未收到有效响应，探测将被标记为失败
不正常阈值 探测重试计数。 连续探测失败计数达到不正常阈值后，将后端服务器标记为故障

探测匹配

默认情况下，状态代码为 200 到 399 的 HTTP(S) 响应被视为正常。 自定义运行状况探测额外支持两个匹配条件。 可根据需要使用条件匹配来修改构成正常响应的因素的默认解释。

下面是匹配条件：

  • HTTP 响应状态代码匹配 - 接受用户指定的 http 响应代码或响应代码范围的探测匹配条件。 支持逗号分隔的单个响应状态代码，或一系列状态代码。
  • HTTP 响应正文匹配 - 查找 HTTP 响应正文并匹配用户指定字符串的探测匹配条件。 该匹配操作只会在响应正文中确定是否存在用户指定的字符串，而不执行完整正则表达式匹配。 指定的匹配项不得超过 4090 个字符。

可以使用 New-AzApplicationGatewayProbeHealthResponseMatch cmdlet 指定匹配条件。

例如：

Azure PowerShell

$match = New-AzApplicationGatewayProbeHealthResponseMatch -StatusCode 200-399




$match = New-AzApplicationGatewayProbeHealthResponseMatch -Body "Healthy"

可以在 PowerShell 中使用 -Match 运算符将匹配条件附加到探测配置。

自定义探测用例

  • 如果后端服务器仅允许经过身份验证的用户访问，则应用程序网关探测将收到 403 响应代码而不是 200。 由于客户端（用户）必须针对实时流量自行进行身份验证，因此可以将探测流量配置为接受 403 作为预期响应。
  • 当后端服务器安装了通配符证书 (*.contoso.com) 来为不同的子域提供服务时，可以使用具有接受的特定主机名（SNI 必需）的自定义探测来建立成功的 TLS 探测，并将该服务器报告为运行正常。 将后端设置中的“替代主机名”设置为“否”时，不同的传入主机名（子域）将按原样传递到后端。

网络安全组 (NSG) 注意事项

公共预览版中可以通过 NSG 规则对应用程序网关子网进行精细控制。 此处提供了更多详细信息。

对于当前功能，存在一些限制：

对于应用程序网关 v1 SKU，必须允许 TCP 端口 65503-65534 上的传入 Internet 流量；对于 v2 SKU，必须允许 TCP 端口 65200-65535 上的传入 Internet 流量，并将目标子网设置为“任何”，将源设置为“GatewayManager”服务标记。 此端口范围是进行 Azure 基础结构通信所必需的。

此外，不能阻止出站 Internet 连接，并且必须允许来自 AzureLoadBalancer 标记的入站流量。

应用程序网关的工作原理

显示 Azure 应用程序网关工作原理示例的关系图。

应用程序网关如何接受请求

  1. 客户端将请求发送到应用程序网关之前，会使用域名系统 (DNS) 服务器解析应用程序网关的域名。 由于所有应用程序网关都位于 azure.com 域中，因此 DNS 条目受 Azure 的控制。
  2. Azure DNS 将 IP 地址返回到客户端，即应用程序网关的前端 IP 地址。
  3. 应用程序网关接受一个或多个侦听器上的传入流量。 侦听器是检查连接请求的逻辑实体。 侦听器上为客户端到应用程序网关的连接配置了前端 IP 地址、协议和端口号。
  4. 如果正在使用 Web 应用程序防火墙 (WAF)，则应用程序网关会根据 WAF 规则检查请求标头和正文（如果有）。 此操作确定请求是有效的请求还是安全威胁。 如果请求有效，则将请求路由到后端。 如果请求无效，并且 WAF 处于预防模式，则会将其作为安全威胁予以阻止。 如果 WAF 处于检测模式，则将评估并记录请求，但仍将其转发到后端服务器。

可以使用 Azure 应用程序网关作为内部应用程序负载均衡器或面向 Internet 的应用程序负载均衡器。 面向 Internet 的应用程序网关使用公共 IP 地址。 面向 Internet 的应用程序网关的 DNS 名称可公开解析为其公共 IP 地址。 因此，面向 Internet 的应用程序网关可以路由来自 Internet 的客户端请求。

内部应用程序网关仅使用专用 IP 地址。 如果使用的是自定义或专用 DNS 区域，则域名应在内部可解析为应用程序网关的专用 IP 地址。 因此，内部负载均衡器只能路由有权访问应用程序网关虚拟网络的客户端发出的请求。

应用程序网关如何路由请求

如果请求有效且未被 WAF 阻止，则应用程序网关将评估与侦听器关联的请求路由规则。 此操作确定要将请求路由到哪个后端池。

根据请求路由规则，应用程序网关确定是要将侦听器上的所有请求路由到特定的后端池、根据 URL 路径将请求路由到不同的后端池，还是将请求重定向到另一个端口或外部站点。

当应用程序网关选择后端池时，会将请求发送到该池中的正常后端服务器之一 (y.y.y.y)。 服务器的运行状况由运行状况探测决定。 如果后端池包含多个服务器，应用程序网关将使用轮循机制算法在正常运行的服务器之间路由请求。 这会对服务器上的请求进行负载均衡。

应用程序网关确定后端服务器之后，会根据 HTTP 设置来与后端服务器建立新的 TCP 会话。 HTTP 设置组件指定与后端服务器建立新会话所需的协议、端口和其他路由相关设置。

HTTP 设置中使用的端口和协议确定应用程序网关与后端服务器之间的流量是已加密（从而实现端到端 TLS）还是未加密。

注意

v1 SKU 规则按照在门户中列出的顺序进行处理。

将原始请求发送到后端服务器时，应用程序网关遵循 HTTP 设置中指定的任何自定义配置，这些配置与替代主机名、路径和协议相关。 此操作将保持基于 Cookie 的会话相关性、连接清空、从后端选择主机名的设置，等等。

如果后端池：

  • 是公共终结点，则应用程序网关会使用其前端公共 IP 来访问服务器。 如果没有前端公共 IP 地址，系统会分配一个公共 IP 地址来建立出站外部连接。
  • 包含可以在内部解析的 FQDN 或专用 IP 地址，则应用程序网关会使用其实例的专用 IP 地址将请求路由到后端服务器。
  • 包含外部终结点或者可以在外部解析的 FQDN，则应用程序网关会使用其前端的公共 IP 地址将请求路由到后端服务器。 如果子网包含服务终结点，则应用程序网关将通过其专用 IP 地址将请求路由到服务。 DNS 解析基于专用 DNS 区域或自定义 DNS 服务器（如果已配置），或者会使用 Azure 提供的默认 DNS。 如果没有前端公共 IP 地址，系统会分配一个公共 IP 地址来建立出站外部连接。

后端服务器 DNS 解析

当后端池的服务器配置了完全限定的域名 (FQDN) 时，应用程序网关会执行 DNS 查找以获取域名的 IP 地址。 IP 值存储在应用程序网关的缓存中，使其在处理传入请求时能够更快地到达目标。

应用程序网关会将此缓存信息保留相当于该 DNS 记录的 TTL（生存时间）的时间，并会在 TTL 过期后执行新的 DNS 查找。 如果网关检测到后续 DNS 查询的 IP 地址发生更改，它会开始将流量路由到此更新的目标。 如果出现 DNS 查找无法收到响应或记录不再存在等问题，网关会继续使用上一个已知良好的 IP 地址。 这可确保对数据路径的影响最小。

  • 将自定义 DNS 服务器与应用程序网关的虚拟网络结合使用时，必须确保所有服务器都相同并使用相同的 DNS 值做出一致的响应。
  • 使用专用终结点的专用 DNS 区域时，本地自定义 DNS 服务器的用户必须确保通过 Azure DNS 专用解析程序（推荐）或 DNS 转发器 VM 连接到 Azure DNS。

对请求的修改

应用程序网关先在所有请求中插入六个附加的标头，然后再将请求转发到后端。 这些标头是 x-forwarded-for、x-forwarded-port、x-forwarded-proto、x-original-host、x-original-url 和 x-appgw-trace-id。x-forwarded-for 标头的格式是逗号分隔的“IP:端口”列表。

x-forwarded-proto 的有效值为 HTTP 或 HTTPS。 x-forwarded-port 指定请求抵达应用程序网关时所在的端口。 x-original-host 标头包含随请求一起抵达的原始主机标头。 此标头在 Azure 网站集成中非常有用，其中，传入的主机标头在流量路由到后端之前会修改。 如果已启用会话相关性作为一个选项，则会添加网关管理的相关性 Cookie。

x-appgw-trace-id 是应用程序网关针对每个客户端请求生成的唯一 guid，在转发给后端池成员的请求中提供。 GUID 包含 32 个字母数字字符，其中不含短划线（例如：ac882cd65a2712a0fe1289ec2bb6aee7）。 此 GUID 可用于关联应用程序网关接收的请求，并通过诊断日志中的 transactionId 属性启动到后端池成员。

可配置应用程序网关，让它使用重写 HTTP 标头和 URL 修改标头，或使用路径替代设置修改 URI 路径。 但是，除非配置为这样做，否则所有传入的请求都会代理到后端。