你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
在 Azure Front Door 中监视指标和日志
Azure Front Door 提供了多种功能来帮助监视应用程序、跟踪请求和调试 Front Door 配置。
日志和指标由 Azure Monitor 存储和管理。
报告提供有关流量如何流经 Azure Front Door、Web 应用程序防火墙 (WAF) 以及应用程序的见解。
指标
在 Azure Front Door 中,每隔 60 秒衡量并发送一次指标。 Azure Monitor 可能需要多达 3 分钟来处理这些指标,在处理完成之前,这些指标可能不会显示。 指标还可以显示在图表或网格中,可通过 Azure 门户、Azure PowerShell、Azure CLI 和 Azure Monitor API 进行访问。 有关详细信息,请参阅 Azure Monitor 指标。
下表中列出的指标将免费记录和存储有限的一段时间。 若支付额外费用,则可以存储更长时间。
指标 | 说明 | 维度 | 建议的聚合 |
---|---|---|---|
字节命中率 | 从 Azure Front Door 缓存提供的流量百分比,根据总出口流量计算。 如果大多数流量转发到原点而不是从缓存提供,则字节命中率较低。 字节命中率 =(从边缘的流出量 - 从源点的流出量)/从边缘的流出量。 从字节命中率计算中排除的方案:
|
终结点 | 平均值、最小值 |
源运行状况百分比 | 从 Azure Front Door 发送到原点的运行状况探测中的成功百分比。 | 源点、源点组 | Avg |
源延迟 | Azure Front Door 计算从向源发送请求到从源接收最后一个响应字节的时间。 | 终结点、源点 | 平均值、最大值 |
源请求计数 | 从 Azure Front Door 发送到原点的请求数。 | 终结点、原点、HTTP 状态、HTTP 状态组 | Avg、Sum |
4XX 百分比 | 响应状态代码为 4XX 的所有客户端请求所占的百分比。 | 终结点、客户端所在国家/地区、客户端所在区域 | 平均值、最大值 |
5XX 百分比 | 响应状态代码为 5XX 的所有客户端请求所在的百分比。 | 终结点、客户端所在国家/地区、客户端所在区域 | 平均值、最大值 |
请求计数 | 通过 Azure Front Door 提供的客户端请求数,包括完全从缓存提供的请求。 | 终结点、客户端所在国家/地区、客户端所在区域、HTTP 状态、HTTP 状态组 | Avg、Sum |
请求大小 | 以请求形式从客户端发送到 Azure Front Door 的字节数。 | 终结点、客户端所在国家/地区、客户端所在区域、HTTP 状态、HTTP 状态组 | 平均值、最大值 |
响应大小 | 以响应的形式从 Front Door 发送到客户端的字节数。 | 终结点、客户端所在国家/地区、客户端所在区域、HTTP 状态、HTTP 状态组 | 平均值、最大值 |
总延迟 | Azure Front Door 接收客户端请求,并将最后一个响应字节发送到客户端。 这是花费的总时间。 | 终结点、客户端所在国家/地区、客户端所在区域、HTTP 状态、HTTP 状态组 | 平均值、最大值 |
Web 应用程序防火墙请求计数 | Azure Front Door Web 应用程序防火墙处理的请求数。 | 操作、策略名称、规则名称 | Avg、Sum |
注意
如果对原点的请求超时,则“Http 状态”维度的值为 0。
日志
日志会跟踪通过 Azure Front Door 传递的所有请求。 处理和存储日志可能需要几分钟时间。
有多个 Front Door 日志,可用于不同的目的:
- 访问日志可用于识别慢速请求、确定错误率,以及了解 Front Door 的缓存行为如何适用于你的解决方案。
- Web 应用程序防火墙 (WAF) 日志可用于检测潜在攻击,以及可能指示 WAF 阻止的合法请求的误报检测。 有关 WAF 日志的详细信息,请参阅 Azure Web 应用程序防火墙监视和日志记录。
- 运行状况探测日志可用于识别不正常或未响应来自 Front Door 某些地理分散式 PoP 的请求的原点。
- 活动日志提供对 Azure 资源执行的操作的可见性,例如对 Azure Front Door 配置文件的配置更改。
访问日志和 Web 日志包括跟踪引用,它也使用 X-Azure-Ref
标头在对原点和客户端响应的请求中传播。 你可以使用跟踪引用来端到端了解应用程序请求处理。
默认未启用访问日志、运行状况探测日志和 WAF 日志。 若要启用和存储诊断日志,请参阅配置 Azure Front Door 日志。 默认情况下会收集活动日志条目,可在 Azure 门户中查看这些条目。
访问日志
有关每个请求的信息将记录到访问日志中。 每个访问日志条目都包含下表中列出的信息。
属性 | 说明 |
---|---|
TrackingReference | 这是唯一的引用字符串,用于识别 Azure Front Door 处理的请求。 跟踪引用是使用 X-Azure-Ref 标头发送到客户端和原点的。 在访问或 WAF 日志中搜索特定请求时,请使用跟踪引用。 |
时间 | Azure Front Door 边缘将请求的内容传送到客户端的日期和时间 (UTC)。 |
HttpMethod | 请求使用的 HTTP 方法:DELETE、GET、HEAD、OPTIONS、PATCH、POST 或 PUT。 |
HttpVersion | 客户端在请求中指定的 HTTP 版本。 |
RequestUri | 已收到请求的 URI。 此字段包含完整方案、端口、域、路径和查询字符串。 |
HostName | 来自客户端的请求中的主机名。 如果启用自定义域并且具有通配符域 (*.contoso.com ),则 HostName 日志字段的值为 subdomain-from-client-request.contoso.com 。 如果使用 Azure Front Door 域 (contoso-123.z01.azurefd.net ),则 HostName 日志字段的值为 contoso-123.z01.azurefd.net 。 |
RequestBytes | HTTP 请求消息的大小(以字节为单位),包括请求标头和请求正文。 |
ResponseBytes | HTTP 响应消息的大小(以字节为单位)。 |
UserAgent | 客户端使用的用户代理。 通常,用户代理会识别浏览器类型。 |
ClientIp | 发出原始请求的客户端的 IP 地址。 如果请求中有 X-Forwarded-For 标头,则将从标头中获取客户端 IP 地址。 |
SocketIp | 与 Azure Front Door 边缘建立直接连接的 IP 地址。 如果客户端使用 HTTP 代理或负载均衡器发送了请求,则 SocketIp 的值是该代理或负载均衡器的 IP 地址。 |
timeTaken | 从 Azure Front Door 边缘收到客户端请求到 Azure Front Door 向客户端发送响应的最后一个字节所经历的时长(以秒为单位)。 此字段不考虑网络延迟和 TCP 缓冲。 |
RequestProtocol | 客户端在请求中指定的协议。 可能的值包括:HTTP、HTTPS。 |
SecurityProtocol | 请求使用的 TLS/SSL 协议版本,如果请求未使用加密,则为 null。 可能的值包括:SSLv3、TLSv1、TLSv1.1、TLSv1.2。 |
SecurityCipher | 当请求协议的值为 HTTPS 时,此字段指示客户端和 Azure Front Door 协商的 TLS/SSL 密码。 |
终结点 | Azure Front Door 终结点的域名,例如 contoso-123.z01.azurefd.net 。 |
HttpStatusCode | 从 Azure Front Door 返回的 HTTP 状态代码。 如果对原点的请求超时,则 HttpStatusCode 字段的值为 0。 如果客户端关闭了连接,则 HttpStatusCode 字段的值为 499。 |
Pop | 响应用户请求的 Azure Front Door 边缘接入点 (PoP)。 |
缓存状态 | Azure Front Door 缓存如何处理请求。 可能的值为:
|
MatchedRulesSetName | 已处理的规则引擎规则的名称。 |
RouteName | 请求匹配的路由的名称。 |
ClientPort | 发出请求的客户端的 IP 端口。 |
Referrer | 发起请求的站点的 URL。 |
TimetoFirstByte | 从 Azure Front Door 边缘收到请求到将第一个字节发送给客户端所经历的时长,以秒为单位,由 Azure Front Door 衡量。 此属性不测量客户端数据。 |
ErrorInfo | 如果在处理请求期间发生错误,则此字段会提供有关错误的详细信息。 可能的值为:
|
OriginURL | 发送请求的源的完整 URL。 URL 由方案、主机头、端口、路径和查询字符串构成。 URL 重写:如果请求 URL 由规则引擎重写,则路径是指重写的路径。 在边缘 PoP 上缓存:如果请求是从 Azure Front Door 缓存提供的,则源为 N/A。 大请求:如果请求的内容很大,并且有多个分块请求返回到源,则此字段将对应于向源发出的第一个请求。 有关详细信息,请参阅对象区块。 |
OriginIP | 为请求提供服务的源的 IP 地址。 在边缘 PoP 上缓存:如果请求是从 Azure Front Door 缓存提供的,则源为 N/A。 大请求:如果请求的内容很大,并且有多个分块请求返回到源,则此字段将对应于向源发出的第一个请求。 有关详细信息,请参阅对象区块。 |
OriginName | 源的完整主机名(DNS 名称)。 在边缘 PoP 上缓存:如果请求是从 Azure Front Door 缓存提供的,则源为 N/A。 大请求:如果请求的内容很大,并且有多个分块请求返回到源,则此字段将对应于向源发出的第一个请求。 有关详细信息,请参阅对象区块。 |
Result | SSLMismatchedSNI 是一个状态代码,表示请求成功,但 SNI 和主机标头之间存在不匹配警告。 此状态代码意味着域前置,这是一种违反 Azure Front Door 条款的技术。 2024 年 1 月 22 日之后,通过 SSLMismatchedSNI 提出的请求将被拒绝。 |
Sni | 此字段指定在 TLS/SSL 握手期间发送的服务器名称指示 (SNI)。 如果存在 SSLMismatchedSNI 状态代码,则它可用于标识确切的 SNI 值。 此外,可以将其与 requestUri 字段中的主机值进行比较,以检测并解决不匹配问题。 |
运行状况探测日志
Azure Front Door 会记录每个失败的运行状况探测请求。 这些日志可帮助你诊断源问题。 你可以使用日志提供的信息来调查失败原因,然后将源恢复为正常状态。
此日志可发挥作用的部分场景包括:
- 你发现 Azure Front Door 流量只是发送到了一部分源。 例如,你可能注意到,四个源中只有三个接收流量。 你想知道源是否正在接收和响应运行状况探测,以便知道源是否正常。
- 你注意到源运行状况百分比指标低于预期。 你想知道哪些源记录为不正常,以及运行状况探测失败的原因。
每个运行状况探测日志项目采用以下架构:
属性 | 说明 |
---|---|
HealthProbeId | 用于标识运行状况探测请求的唯一 ID。 |
时间 | 发送运行状况探测的日期和时间 (UTC)。 |
HttpMethod | 运行状况探测请求使用的 HTTP 方法。 值包括 GET 和 HEAD,具体取决于运行状况探测的配置。 |
结果 | 运行状况探测的状态。 值是 success 或探测收到的错误的说明。 |
HttpStatusCode | 源返回的 HTTP 状态代码。 |
ProbeURL | 探测请求发送到的完整目标 URL。 URL 由方案、主机头、路径和查询字符串组成。 |
OriginName | 运行状况探测发送到的源的名称。 如果源配置为使用 FDQN,则此字段可帮助你查找相关的源。 |
POP | 发送探测请求的边缘 PoP。 |
原始 IP | 运行状况探测发送到的源的 IP 地址。 |
TotalLatency | 从 Azure Front Door 边缘将运行状况探测请求发送给原点到原点向 Azure Front Door 发送最后一个响应所经历的时间。 |
ConnectionLatency | 设置 TCP 连接以将 HTTP 探测请求发送到源所用的时间。 |
DNSResolution Latency | DNS 解析所用的时间。 仅当源配置为 FDQN 而不是 IP 地址时,此字段才具有值。 如果源配置为使用 IP 地址,则值为 N/A。 |
以下示例 JSON 片段显示了失败的运行状况探测请求的运行状况探测日志项目。
{
"records": [
{
"time": "2021-02-02T07:15:37.3640748Z",
"resourceId": "/SUBSCRIPTIONS/mySubscriptionID/RESOURCEGROUPS/myResourceGroup/PROVIDERS/MICROSOFT.CDN/PROFILES/MyProfile",
"category": "FrontDoorHealthProbeLog",
"operationName": "Microsoft.Cdn/Profiles/FrontDoorHealthProbeLog/Write",
"properties": {
"healthProbeId": "9642AEA07BA64675A0A7AD214ACF746E",
"POP": "MAA",
"httpVerb": "HEAD",
"result": "OriginError",
"httpStatusCode": "400",
"probeURL": "http://www.example.com:80/",
"originName": "www.example.com",
"originIP": "PublicI:Port",
"totalLatencyMilliseconds": "141",
"connectionLatencyMilliseconds": "68",
"DNSLatencyMicroseconds": "1814"
}
}
]
}
Web 应用程序防火墙日志
有关 Front Door Web 应用程序防火墙 (WAF) 日志的详细信息,请参阅 Azure Web 应用程序防火墙监视和日志记录。
活动日志
活动日志提供有关 Azure Front Door 资源管理操作的信息。 日志包括有关对 Azure Front Door 资源执行的每个写入操作的详细信息,包括操作发生时间、执行操作的人员以及具体操作。
注意
活动日志不包括读取操作。 它们也可能不包括你使用 Azure 门户或经典管理 API 执行的所有操作。
有关详细信息,请参阅查看活动日志。
后续步骤
若要启用和存储诊断日志,请参阅配置 Azure Front Door 日志。
重要
Azure Front Door(经典版)将于 2027 年 3 月 31 日停用。 为了避免任何服务中断,请务必在 2027 年 3 月之前将 Azure Front Door(经典版)配置文件迁移到 Azure Front Door 标准层或高级层。 有关详细信息,请参阅 Azure Front Door(经典版)停用。
使用 Azure Front Door(经典)时,可以通过以下方式监视资源:
- 指标 Azure Front Door 目前有八个指标来查看性能计数器。
- 日志。 通过活动和诊断日志,可出于监视目的从资源保存或使用性能、访问及其他数据。
指标
指标是某些 Azure 资源的一项功能,可让你能够查看门户中的性能计数器。 以下是可用的 Front Door 指标:
指标 | 指标显示名称 | 计价单位 | 维度 | 说明 |
---|---|---|---|---|
RequestCount | 请求计数 | 计数 | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
Front Door 服务的客户端请求数。 |
RequestSize | 请求大小 | 字节 | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
以请求的形式从客户端发送到 Front Door 的字节数。 |
ResponseSize | 响应大小 | 字节 | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
以响应的形式从 Front Door 发送到客户端的字节数。 |
TotalLatency | 总延迟 | 毫秒 | HttpStatus HttpStatusGroup ClientRegion ClientCountry |
从 Front Door 接收到客户端请求到最后一个响应字节从 AFD 发送到客户端的总时间。 |
BackendRequestCount | 后端请求计数 | 计数 | HttpStatus HttpStatusGroup Backend |
从 Front Door 发送到后端的请求数。 |
BackendRequestLatency | 后端请求延迟 | 毫秒 | 后端 | 自 Front Door 向后端发送请求起,直至 Front Door 接收到来自后端的最后一个响应字节为止,所计算的时间。 |
BackendHealthPercentage | 后端运行状况百分比 | 百分比 | Backend BackendPool |
从 Front Door 到后端,成功运行状况探测的百分比。 |
WebApplicationFirewallRequestCount | Web 应用程序防火墙请求计数 | 计数 | PolicyName RuleName Action |
Front Door 的应用层安全性所处理的客户端请求数。 |
活动日志
活动日志提供有关对 Azure Front Door(经典)配置文件执行的操作的信息。 它们还确定对 Azure Front Door(经典)配置文件执行的任何写入操作(put、post 或 delete)的内容、操作者和时间。
注意
如果对源的请求超时,则 HttpStatusCode 的值将设置为“0”。
可以在 Azure Monitor 中访问 Front Door 中的活动日志或 Azure 资源的所有日志。 要查看活动日志,请执行以下操作:
选择你的 Front Door 实例。
选择“活动日志”。
选择一个筛选范围,然后选择“应用”。
注意
活动日志不包括任何 GET 操作或使用 Azure 门户或原始管理 API 执行的操作。
诊断日志
诊断日志提供了大量有关操作和错误的信息,这些信息对于审核和故障排除非常重要。 诊断日志不同于活动日志。
活动日志让你能够了解对 Azure 资源执行的操作。 诊断日志提供资源已完成的操作的深入信息。 有关详细信息,请参阅 Azure Monitor 诊断日志。
若要为 Azure Front Door(经典)配置诊断日志,请执行以下操作:
选择你的 Azure Front Door(经典)配置文件。
选择“诊断设置”。
选择“启用诊断”。 将诊断日志与指标一起存档到存储帐户,将其流式传输到事件中心,或者将其发送到 Azure Monitor 日志。
Front Door 目前提供诊断日志。 诊断日志提供单独的 API 请求,其中每个条目具有以下架构:
属性 | 说明 |
---|---|
BackendHostname | 如果请求被转发到后端,则此字段表示后端的主机名。 如果在为传递规则启用缓存时,请求将被重定向或转发到区域缓存,则此字段为空。 |
CacheStatus | 对于缓存方案,此字段定义在 POP 处的缓存命中/未命中情况 |
ClientIp | 发出请求的客户端的 IP 地址。 如果请求中包含 X-Forwarded-For 头,则从同一个头中获取客户端 IP。 |
ClientPort | 发出请求的客户端的 IP 端口。 |
HttpMethod | 请求使用的 HTTP 方法。 |
HttpStatusCode | 从代理返回的 HTTP 状态代码。 如果对源的请求超时,则 HttpStatusCode 的值将设置为“0”。 |
HttpStatusDetails | 请求的结果状态。 此字符串值的含义可以在状态引用表中找到。 |
HttpVersion | 请求或连接的类型。 |
POP | 请求着陆的边缘的短名称。 |
RequestBytes | HTTP 请求消息的大小(以字节为单位),包括请求标头和请求正文。 |
RequestUri | 已收到请求的 URI。 |
ResponseBytes | 后端服务器作为响应发送的字节数。 |
RoutingRuleName | 请求匹配的传递规则的名称。 |
RulesEngineMatchNames | 请求匹配的规则的名称。 |
SecurityProtocol | 请求所使用的 TLS/SSL 协议版本,如果没有加密,则为 null。 |
SentToOriginShield (已弃用)* 请参阅以下部分中的弃用说明。 |
如果为 true,则表示请求是从源防护缓存(而不是边缘 pop)响应的。 源防护是用于提高缓存命中率的父缓存。 |
isReceivedFromClient | 如果为 true,则表示请求来自客户端。 如果为 false,则请求在边缘(子 POP)未命中,并从源盾牌(父 POP)进行响应。 |
TimeTaken | 从请求的第一个字节传入 Front Door 到响应的最后一个字节传出 Front Door 的时间长度(以秒为单位)。 |
TrackingReference | 标识由 Front Door 提供的请求的唯一引用字符串,该请求还会以 X-Azure-Ref 标头的形式发送到客户端。 是搜索特定请求访问日志中的详细信息必需的。 |
UserAgent | 客户端使用的浏览器类型。 |
ErrorInfo | 此字段包含特定类型的错误,以便进一步进行故障排除。 可能的值包括: NoError:表示未发现任何错误。 CertificateError :常规 SSL 证书错误 。CertificateNameCheckFailed:SSL 证书中的主机名无效或不匹配。 ClientDisconnected:客户端网络连接问题导致请求失败。 UnspecifiedClientError:常规客户端错误。 InvalidRequest:请求无效。 此错误的可能原因是标头、正文和 URL 格式不正确。 DNSFailure:DNS 故障。 DNSNameNotResolved:无法解析服务器名称或地址。 OriginConnectionAborted:与源的连接突然断开。 OriginConnectionError:常规源连接错误。 OriginConnectionRefused:无法与源建立连接。 OriginError:常规源错误。 OriginInvalidResponse:源返回的响应无效或无法识别。 OriginTimeout:超过了源请求的超时期限。 ResponseHeaderTooBig:源返回的响应头过大。 RestrictedIP:由于 IP 受限而阻止了请求。 SSLHandshakeError:由于 SSL 握手失败,无法与源建立连接。 UnspecifiedError:发生了与表中任何错误都不相符的错误。 SSLMismatchedSNI:请求无效,因为 HTTP 消息标头与 SSL/TLS 连接设置期间 TLS SNI 扩展中显示的值不符。 |
结果 | SSLMismatchedSNI 是一个状态代码,表示请求成功,但 SNI 和主机标头之间存在不匹配警告。 此状态代码意味着域前置,这是一种违反 Azure Front Door 条款的技术。 2024 年 1 月 22 日之后,通过 SSLMismatchedSNI 提出的请求将被拒绝。 |
Sni | 此字段指定在 TLS/SSL 握手期间发送的服务器名称指示 (SNI)。 如果存在 SSLMismatchedSNI 状态代码,则它可用于标识确切的 SNI 值。 此外,可以将其与 requestUri 字段中的主机值进行比较,以检测并解决不匹配问题。 |
发送到源盾牌弃用
原始日志属性 isSentToOriginShield 已弃用,并已替换为新的字段 isReceivedFromClient。 如果正在使用弃用的字段,请改为使用新字段。
原始日志包括从 CDN 边缘(子 POP)和源盾牌生成的日志。 源盾牌是指位于全球各地的战略性父节点。 这些节点与源服务器通信,可减少源上的流量负载。
对于传至源盾牌的每个请求,都有两个日志项目:
- 一个传至边缘节点
- 一个传至源盾牌。
要区分边缘节点与源盾牌的流出或响应,可以使用字段 isReceivedFromClient 来获取正确数据。
如果值为 false,则表示该请求是从源盾牌到边缘节点的响应。 这种方法用来比较原始日志与账单数据非常有效。 从源盾牌向边缘节点流出不会产生费用。 从边缘节点向客户端流出却会产生费用。
Kusto 查询示例,不包括在 Log Analytics 的源盾牌上生成的日志。
AzureDiagnostics | where Category == "FrontdoorAccessLog" and isReceivedFromClient_b == true
注意
对于各种路由配置和流量行为,某些字段(如 backendHostname、cacheStatus、isReceivedFromClient 和 POP 字段)可能会用不同的值来响应。 下表说明了这些字段在各种情况下将具有的不同值:
方案 | 日志项计数 | POP | BackendHostname | isReceivedFromClient | CacheStatus |
---|---|---|---|---|---|
未启用缓存的传递规则 | 1 | 边缘 POP 代码 | 请求被转发到的后端 | True | CONFIG_NOCACHE |
启用缓存的传递规则。 缓存命中边缘 POP | 1 | 边缘 POP 代码 | 空 | True | HIT |
启用缓存的传递规则。 缓存未命中边缘 POP,但命中父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 父缓存 POP 主机名 2. 空 |
1. True 2. False |
1. MISS 2. HIT |
启用缓存的传递规则。 缓存未命中边缘 POP,但部分缓存命中父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 父缓存 POP 主机名 2. 帮助填充缓存的后端 |
1. True 2. False |
1. MISS 2. PARTIAL_HIT |
启用缓存的传递规则。 缓存部分命中边缘 POP,但命中父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. True 2. False |
1. PARTIAL_HIT 2. HIT |
启用缓存的传递规则。 缓存未命中边缘和父缓存 POP | 2 | 1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. 边缘 POP 代码 2. 父缓存 POP 代码 |
1. True 2. False |
1. MISS 2. MISS |
处理请求时出错 | 空值 |
注意
对于缓存方案,如果从 Azure Front Door 边缘或源盾牌缓存提供请求的部分字节,同时从大型对象的源提供部分字节,则缓存状态的值将为 partial_hit。
Azure Front Door 使用一种被称作对象区块的技术。 请求大型文件时,Azure Front Door 会从源检索文件的较小部分。 在 Azure Front Door POP 服务器收到请求的文件的完整范围或字节范围后,Azure Front Door 边缘服务器会以 8 MB 的区块从源请求文件。
区块到达 Azure Front Door 边缘后,会将区块缓存并立即提供给用户。 然后,Azure Front Door 会并行预提取下一个区块。 此预提取可确保内容先于用户一个区块,这可以减少延迟。 此过程将继续,直到整个文件下载完成(如果已请求),所有字节范围都可用(如果已请求),或客户端关闭连接。 有关字节范围请求的详细信息,请参阅 RFC 7233。 Azure Front Door 会在收到区块后进行缓存。 无需在 Front Door 缓存上缓存整个文件。 随后从 Azure Front Door 缓存中请求文件或字节范围的请求。 如果未在 Azure Front Door 上缓存所有区块,将使用预提取从源请求区块。 此优化取决于源服务器能否支持字节范围请求。 如果源服务器不支持字节范围请求,则此优化不会生效。