HTTP-Downlink-Header

Typ

Der Downlink-Header ist ein HTTP-Request-Header und Client Hint, mit dem der Client die effektive Downlink-Geschwindigkeit seiner Netzwerkverbindung in Megabit pro Sekunde an den Server übermittelt.

Syntax

Der Header enthält einen numerischen Wert, der die geschätzte Downlink-Geschwindigkeit angibt.

http 
Downlink: 10.0
Downlink: 1.5

Direktiven

Der Downlink-Header verwendet einen gerundeten Geschwindigkeitswert:

speed-value
Effektive Downlink-Geschwindigkeit in Megabit pro Sekunde (Mbps). Gerundet auf 0.025 Mbps, um Fingerprinting zu erschweren.
effective-bandwidth
Basiert auf tatsächlichen Netzwerk-Performance-Messungen, nicht auf theoretischer Verbindungsgeschwindigkeit. Reflektiert reale Bedingungen.
opt-in-required
Der Header wird nur gesendet, wenn der Server zuvor per Accept-CH: Downlink das Opt-in angefordert hat.

Beispiele

API passt Response-Größe an Bandbreite an

Ein Client mit langsamer Verbindung fragt Produktbilder an:

http 
GET /api/v1/products/12345/images HTTP/1.1
Host: cdn.example.com
Downlink: 1.5
ECT: 3g
Accept: image/webp,image/jpeg

Die API liefert kleinere, optimierte Bilder:

http 
HTTP/1.1 200 OK
Vary: Downlink, ECT
Content-Type: application/json

{
  "images": [
    {
      "url": "https://cdn.example.com/product-small.webp",
      "size": "640x480",
      "quality": "medium",
      "bytes": 45000
    }
  ]
}

Client mit schneller Verbindung erhält hochauflösende Bilder:

http 
GET /api/v1/products/12345/images HTTP/1.1
Host: cdn.example.com
Downlink: 10.0
ECT: 4g
Accept: image/webp,image/jpeg
http 
HTTP/1.1 200 OK
Vary: Downlink, ECT
Content-Type: application/json

{
  "images": [
    {
      "url": "https://cdn.example.com/product-large.webp",
      "size": "1920x1440",
      "quality": "high",
      "bytes": 250000
    }
  ]
}

Video-Streaming-API wählt Bitrate basierend auf Downlink

Eine Streaming-API liefert adaptive Bitrate-Manifeste:

http 
GET /api/v1/videos/abc123/manifest.m3u8 HTTP/1.1
Host: video.example.com
Downlink: 5.0

Der Server generiert Manifest mit passenden Qualitätsstufen:

http 
HTTP/1.1 200 OK
Vary: Downlink
Content-Type: application/vnd.apple.mpegurl

#EXTM3U
#EXT-X-STREAM-INF:BANDWIDTH=2000000,RESOLUTION=1280x720
stream-720p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=5000000,RESOLUTION=1920x1080
stream-1080p.m3u8

API verzögert Non-Essential-Ressourcen bei niedriger Bandbreite

Eine Dashboard-API priorisiert kritische Daten:

http 
GET /api/v1/dashboard HTTP/1.1
Host: app.example.com
Downlink: 0.5
ECT: 2g

Der Server liefert nur essenzielle Daten:

http 
HTTP/1.1 200 OK
Vary: Downlink
Content-Type: application/json

{
  "critical_data": {
    "account_balance": 1234.56,
    "alerts": ["Payment due"]
  },
  "deferred_resources": [
    "/api/v1/dashboard/charts",
    "/api/v1/dashboard/analytics"
  ],
  "message": "Additional data available on demand"
}

Downlink-Adaptive-Content-Flow

Der Ablauf der bandbreiten-adaptiven Content Delivery in APIs.

plantuml 
@startuml
actor "Slow Connection\nClient (1.5 Mbps)" as SlowClient
actor "Fast Connection\nClient (10 Mbps)" as FastClient
participant "API Gateway" as Gateway
participant "Content Service" as Content

SlowClient -> Gateway: GET /api/v1/media\nDownlink: 1.5\nECT: 3g
Gateway -> Content: Request optimized\nfor low bandwidth
Content -> Content: Select low-quality\nassets, compress aggressively
Content --> Gateway: Lightweight payload\n(50KB images, 480p video)
Gateway --> SlowClient: 200 OK\nVary: Downlink\n[optimized response]

FastClient -> Gateway: GET /api/v1/media\nDownlink: 10.0\nECT: 4g
Gateway -> Content: Request full\nquality assets
Content -> Content: Select high-quality\nassets, prefetch enabled
Content --> Gateway: Rich payload\n(300KB images, 1080p video)
Gateway --> FastClient: 200 OK\nVary: Downlink\n[full response]

note right
Both clients get optimal
experience for their actual
network conditions
end note
@enduml

Vorteile für die Systemarchitektur

  • Optimiert API-Responses für tatsächliche Netzwerkbedingungen statt theoretischer Verbindungstypen
  • Reduziert Timeouts und abgebrochene Downloads bei langsamen Verbindungen
  • Verbessert perceived Performance durch schnellere Initial-Loads
  • Kombinierbar mit ECT-Header für präzise Netzwerk-Charakterisierung
  • Ermöglicht serverbasierte Adaptive Bitrate Streaming ohne Client-seitige Logik

Spezifikation

Der Downlink-Header ist im Network Information API Draft definiert.

Weitere Spezifikationen

ECT Header, RTT Header