9.2 Web, Cloud Path & Application Probes

9.2 Web, Cloud Path & Application Probes

Quick Answer: ZDX relies on Active Synthetic Probes executed by Zscaler Client Connector at scheduled intervals. Web Probes dissect the application transaction into distinct timing phases: DNS Resolution, TCP Connect, SSL Handshake, Server Response Time (TTFB), and Total Download Time. Cloud Path Probes provide hop-by-hop network route tracing using adaptive TCP SYN / ICMP / UDP packets to pinpoint packet loss and latency across the local Wi-Fi, ISP transit, Zscaler Zero Trust Exchange, and SaaS edge. Page Fetch Probes simulate browser rendering, while Call Quality Probes capture audio/video Mean Opinion Scores (MOS), jitter, and packet loss.

---

1. Anatomy of a ZDX Web Probe

A Web Probe performs continuous synthetic HTTP/HTTPS transactions against a designated target URL (e.g., https://outlook.office365.com or an internal enterprise portal). Rather than simply checking whether the site is "up" or "down," the Web Probe breaks down the transaction into precise millisecond-level stages:

+-----------------------------------------------------------------------------+
|                     ZDX WEB PROBE TRANSACTION PHASES                        |
+-----------------------------------------------------------------------------+

 |<-------------------------- TOTAL FETCH TIME ----------------------------->|
 
 +--------------+--------------+---------------+---------------+-------------+
 | DNS Lookup   | TCP Connect  | SSL Handshake | Server Rsp    | Content     |
 | Time         | Time         | Time          | (TTFB)        | Download    |
 +--------------+--------------+---------------+---------------+-------------+
 | Resolves FQDN| TCP 3-Way    | TLS Client/   | Request Sent  | Payload     |
 | to IP via    | Handshake    | Server Hello, | -> First Byte | Streamed to |
 | Resolver     | (SYN-ACK)    | Cert & Cipher | Received      | Client      |
 +--------------+--------------+---------------+---------------+-------------+

Metric Breakdown & Diagnostic Value:

1. DNS Lookup Time:
   • Definition: The time taken to resolve the application's Fully Qualified Domain Name (FQDN) to an IP address.
   • Diagnostic Insight: High DNS lookup time (>50–100ms) indicates local DNS server misconfiguration, unoptimized DNS forwarders, or slow authoritative nameservers.
2. TCP Connect Time:
   • Definition: The duration required to complete the initial TCP 3-way handshake (SYN $\rightarrow$ SYN-ACK $\rightarrow$ ACK) between the client (or Zscaler Edge) and the destination server.
   • Diagnostic Insight: Spikes in TCP connect time indicate underlying network congestion, routing sub-optimality, or firewall state-table exhaustion along the transport path.
3. SSL/TLS Handshake Time:
   • Definition: The time required to negotiate cryptographic parameters, validate digital certificates, and establish a secure TLS session.
   • Diagnostic Insight: Elevated TLS handshake times point to cryptographic negotiation overhead, OCSP/CRL revocation check delays, or server-side SSL accelerator saturation.
4. Server Response Time / Time to First Byte (TTFB):
   • Definition: The time elapsed from when the client finishes sending the HTTP request (GET/POST) until the very first byte of HTTP response headers/data is received from the server.
   • Diagnostic Insight: TTFB is the premier indicator of application server health. If DNS, TCP, and SSL times are low, but TTFB is high (>500ms–2000ms), the delay is caused by server-side compute bottlenecks, database query stalls, or backend SaaS application overload—not the network.
5. Total Page Fetch / Download Time:
   • Definition: The complete time required to transfer the full payload of the requested web resource.
   • Diagnostic Insight: Large fetch times with low TTFB indicate bandwidth throttling, MTU fragmentation, or oversized web assets.
6. HTTP Response Codes:
   • ZDX tracks HTTP return codes (200 OK, 301/302 Redirect, 401 Unauthorized, 403 Forbidden, 404 Not Found, 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable). Repeated 5xx codes immediately degrade the ZDX application score to Poor.

---

2. Cloud Path Probes & Hop-by-Hop Underlay Diagnostics

While Web Probes assess Layer 7 application responsiveness, Cloud Path Probes analyze the Layer 3/4 network transport path connecting the user endpoint to the destination.

+-----------------------------------------------------------------------------+
|                        ZDX CLOUD PATH HOP ANALYSIS                          |
+-----------------------------------------------------------------------------+

  [Endpoint] ---> [Hop 1: GW] ---> [Hops 2-5: ISP] ---> [Hop 6: Zscaler PSE] 
    (ZCC)           (192.168.1.1)    (Transit Underlay)     (Zero Trust Edge)
      |                  |                 |                      |
    0.8ms              1.2ms             14.5ms                 16.1ms
    0% Loss            0% Loss           0% Loss                0% Loss
                                                                  |
                                                                  v
  [Target SaaS App] <--- [Hops 8-9: SaaS Edge] <--- [Hop 7: Internet Peering]
   (Salesforce)            (136.146.x.x)                  (Equinix IXP)
      |                          |                             |
    48.2ms                     46.8ms                        22.4ms
    0% Loss                   *8% LOSS* (SPIKE)              0% Loss

Adaptive Probing Protocols:

Cloud Path probes can be configured with specific transport protocols depending on network security constraints:

• TCP SYN Probing (Recommended & Default for Web Apps): Sends lightweight TCP SYN packets to the target port (e.g., TCP 443/80). Because TCP SYN traffic closely mimics real user application packets, firewalls and intermediate routers treat it identically to live production traffic.
• ICMP Echo Probing: Uses traditional ICMP Echo Request (ping) packets. While useful for general reachability, many enterprise firewalls and upstream Tier-1 ISPs deprioritize or drop ICMP traffic (ICMP rate-limiting), which can produce false packet loss readings.
• UDP Probing: Transmits UDP datagrams to high-numbered ports or specific application ports (e.g., DNS port 53 or WebRTC media ports). Essential for real-time collaboration path diagnostics.

Tunnel-Aware Path Discovery:

ZDX Cloud Path understands Zscaler traffic redirection architecture:

• Direct / Off-Tunnel: When traffic bypasses Zscaler (e.g., bypassed via PAC file or split-tunneling), Cloud Path maps the native Internet path directly to the SaaS provider.
• Z-Tunnel 1.0 / Z-Tunnel 2.0 (ZIA): Cloud Path delineates the hops from the client to the ZIA Public Service Edge, shows the processing transition within the Zscaler security fabric, and maps the egress path from Zscaler to the SaaS front door.
• Zscaler Private Access (ZPA): Cloud Path visualizes the micro-tunnel between the client and the ZPA Public/Private Service Edge, and extends visibility through the App Connector to the internal private server.

---

3. Page Fetch Probes for Complex Web Applications

Modern web applications (e.g., ServiceNow, Jira, Salesforce Lightning) are heavy single-page applications (SPAs) consisting of HTML wrappers that load dozens of asynchronous JavaScript bundles, CSS stylesheets, REST API calls, and image assets.

+-----------------------------------------------------------------------------+
|                        PAGE FETCH PROBE EXECUTION                           |
+-----------------------------------------------------------------------------+

  1. Fetch Initial Document (HTML Shell)
     [GET /index.html] ----------> Status: 200 OK (52ms)
  
  2. Parse DOM & Fetch Synthetic Asset Waterfall
     +-- [GET /app.bundle.js] ----> Status: 200 OK (84ms)
     +-- [GET /theme.css] --------> Status: 200 OK (38ms)
     +-- [GET /api/v1/auth] ------> Status: 200 OK (112ms)
     +-- [GET /logo.png] ---------> Status: 200 OK (22ms)
  
  3. Compute Aggregate Page Metrics
     * DOM Interactive Time
     * Page Load Complete Time
     * Total Transferred Payload Size (Bytes)

• Mechanics: While a standard Web Probe requests a single target URL or health endpoint, a Page Fetch Probe downloads the root HTML and fetches secondary page assets. This measures real browser-like load times, verifying that content delivery networks (CDNs) and asset caches are operating correctly.

---

4. Collaboration Call Quality Probes (Teams & Zoom)

Voice over IP (VoIP) and real-time video collaboration traffic have stringent performance requirements. TCP retransmissions are unusable for real-time audio; drops and jitter directly cause robotic audio, dropped syllables, and frozen video frames.

ZDX provides dedicated Collaboration Monitoring for Microsoft Teams and Zoom by combining active client-side UDP probes with direct API integration into Microsoft Teams Call Quality Dashboard (CQD) and Zoom Quality of Service Subscription (QSS) APIs:

+-----------------------------------------------------------------------------+
|                  COLLABORATION QUALITY METRIC HIERARCHY                     |
+-----------------------------------------------------------------------------+

  +-------------------------------------------------------------------------+
  |                MEAN OPINION SCORE (MOS) [Scale: 1.0 - 5.0]              |
  +-------------------------------------------------------------------------+
          |                             |                            |
          v                             v                            v
  +---------------+             +---------------+            +--------------+
  | NETWORK JITTER|             | PACKET LOSS   |            | ROUND-TRIP   |
  | (< 30 ms)     |             | (< 1.0%)      |            | DELAY (<150ms|
  +---------------+             +---------------+            +--------------+

---

5. Probe Frequency & Target Configuration Matrix

Administrators configure probes in the ZDX Admin Portal under Applications $\rightarrow$ Probe Configuration. Selecting the proper frequency balances diagnostic precision against endpoint compute and network bandwidth:

---

6. Exam Tips & High-Frequency Distinctions

[!IMPORTANT] Diagnostic Trap: High TTFB vs. High TCP Connect Time:

• If an exam question describes a scenario where DNS Time = 2ms, TCP Connect = 8ms, SSL Handshake = 12ms, but TTFB = 1800ms, the root cause is Server/Application Processing Stalls (e.g., overloaded database or backend compute), NOT network latency or ISP congestion.
• If TCP Connect = 250ms and Cloud Path shows 15% loss at Hop 3, the root cause is Network Transport Congestion.

[!TIP] TCP SYN vs. ICMP Probes: Always choose TCP SYN probes when monitoring web applications across strict enterprise security boundaries. Many enterprise firewalls and Tier-1 transit backbones drop ICMP packets by policy, generating false packet loss alerts in Cloud Path.