HTTP ECT Header

Typ

Der ECT-Header ist ein HTTP-Request-Header und Client Hint, mit dem der Client den effektiven Verbindungstyp seiner Netzwerkverbindung basierend auf gemessener Performance an den Server übermittelt.

Syntax

Der Header enthält einen Verbindungstyp-String, der die Netzwerkklasse repräsentiert.

http 
ECT: 4g
ECT: 3g

Direktiven

Der ECT-Header verwendet standardisierte Verbindungstyp-Werte:

slow-2g
Sehr langsame Verbindung mit hoher Latenz. Round-Trip-Time über 2000ms, Downlink unter 50 Kbps. Extreme Optimierung erforderlich.
2g
Langsame Verbindung mit hoher Latenz. RTT 1400-2000ms, Downlink 50-70 Kbps. Aggressive Content-Reduktion empfohlen.
3g
Moderate Verbindung mit mittlerer Latenz. RTT 270-1400ms, Downlink 70-700 Kbps. Balancierte Optimierung zwischen Qualität und Größe.
4g
Schnelle Verbindung mit niedriger Latenz. RTT unter 270ms, Downlink über 700 Kbps. Volle Qualität und Prefetching möglich.

Beispiele

API liefert unterschiedliche Payloads basierend auf ECT

Ein Client mit 3G-Verbindung fragt Dashboard-Daten an:

http 
GET /api/v1/dashboard HTTP/1.1
Host: app.example.com
ECT: 3g
Downlink: 2.0
Accept: application/json

Die API liefert optimierte, reduzierte Daten:

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

{
  "metrics": {
    "sales_today": 12450.00,
    "orders_count": 87
  },
  "chart_data": "summary_only",
  "deferred_widgets": [
    "/api/v1/dashboard/detailed-analytics",
    "/api/v1/dashboard/historical-charts"
  ]
}

Client mit 4G-Verbindung erhält vollständige Daten:

http 
GET /api/v1/dashboard HTTP/1.1
Host: app.example.com
ECT: 4g
Downlink: 10.0
Accept: application/json
http 
HTTP/1.1 200 OK
Vary: ECT, Downlink
Content-Type: application/json

{
  "metrics": {...},
  "chart_data": {
    "hourly_sales": [...],
    "top_products": [...],
    "conversion_funnel": [...]
  },
  "prefetch": [
    "/api/v1/reports/monthly",
    "/api/v1/analytics/realtime"
  ]
}

Video-API wählt Initial-Bitrate basierend auf ECT

Eine Streaming-API optimiert den initialen Video-Stream:

http 
GET /api/v1/videos/live/stream.m3u8 HTTP/1.1
Host: video.example.com
ECT: 2g

Der Server startet mit niedriger Bitrate:

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

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=500000,RESOLUTION=480x270
stream-240p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1000000,RESOLUTION=640x360
stream-360p.m3u8

API deaktiviert Prefetching bei slow-2g

Eine Content-API vermeidet unnötige Requests bei sehr langsamer Verbindung:

http 
GET /api/v1/articles/12345 HTTP/1.1
Host: news.example.com
ECT: slow-2g

Der Server liefert nur essenzielle Inhalte ohne Prefetch-Hints:

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

{
  "article": {
    "title": "Breaking News",
    "content": "Text-only version...",
    "images": [],
    "related_articles": []
  },
  "prefetch_disabled": true,
  "message": "Limited content for slow connection"
}

ECT-Based-Adaptive-API-Flow

Der Ablauf der netzwerktyp-adaptiven Content Delivery in APIs.

plantuml 
@startuml
actor "2G Client" as Client2G
actor "4G Client" as Client4G
participant "API Gateway" as Gateway
participant "Content Optimizer" as Optimizer

Client2G -> Gateway: GET /api/v1/content\nECT: 2g\nDownlink: 0.5
Gateway -> Optimizer: Classify connection:\nHigh latency, low bandwidth
Optimizer -> Optimizer: Apply aggressive\noptimization profile
Optimizer --> Gateway: Minimal payload\n(text only, no images)
Gateway --> Client2G: 200 OK\nVary: ECT\n[20KB response, no prefetch]

Client4G -> Gateway: GET /api/v1/content\nECT: 4g\nDownlink: 8.0
Gateway -> Optimizer: Classify connection:\nLow latency, high bandwidth
Optimizer -> Optimizer: Apply full-quality\nprofile with prefetch
Optimizer --> Gateway: Rich payload\n(images, videos, prefetch hints)
Gateway --> Client4G: 200 OK\nVary: ECT\n[200KB response + prefetch]

note right
ECT provides coarse-grained
network classification for
quick optimization decisions
end note
@enduml

Vorteile für die Systemarchitektur

  • Ermöglicht schnelle Optimierungsentscheidungen durch grobe Netzwerkklassifizierung
  • Kombiniert Latenz und Bandbreite in einem einzigen, leicht verständlichen Wert
  • Basiert auf gemessener Performance, nicht auf nominellem Verbindungstyp
  • Reduziert Timeouts und Frustrationen bei langsamen Verbindungen
  • Kombinierbar mit Downlink-Header für präzise Bandbreiten-Charakterisierung

Spezifikation

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

Weitere Spezifikationen

Downlink Header, Save-Data Header