OkHttp — was es ist, Funktionen und Architektur des HTTP-Clients

Was ist OkHttp?

OkHttp ist ein effizienter HTTP-Client für Java, Android und Kotlin, entwickelt von Square. Die Bibliothek bietet eine Low-Level-API zum Ausführen von HTTP-Anfragen mit Unterstützung für HTTP/2, SPDY, WebSocket und automatische Verbindungswiederherstellung bei Netzwerkausfällen.

OkHttp entstand 2013 als Antwort auf die Notwendigkeit eines zuverlässigen HTTP-Clients, der die Probleme von HttpURLConnection lösen würde — fehlender Verbindungspool, schwache HTTP/2-Unterstützung und umständliche API. Bis 2025 wird OkHttp auf Systemebene der Android API verwendet: OkHttp ist seit Android 4.4 (API 19) in die HttpURLConnection-Implementierung eingebettet.

Laut Google I/O 2024 verarbeitet OkHttp über 70% aller HTTP-Anfragen im Android-Ökosystem. Dies ist möglich, weil OkHttp als Transportschicht für Retrofit, Apollo GraphQL, Firebase und viele andere Bibliotheken dient. Entwickler erhalten die OkHttp-Funktionalität automatisch, ohne es explizit hinzufügen zu müssen.

Wie OkHttp funktioniert

OkHttp-Architektur basiert auf einer Interceptor-Kette. Jede Anfrage durchläuft eine Sequenz von Interceptors, die die Request oder Response modifizieren oder die Ausführung unterbrechen können. Diese Architektur ähnelt dem Chain-of-Responsibility-Muster und ermöglicht flexible Erweiterbarkeit.

Wenn eine Anwendung eine Anfrage sendet, führt OkHttp die folgenden Schritte aus: DNS auflösen, eine Verbindung aus dem Pool auswählen (oder eine neue erstellen), TLS-Handshake öffnen (falls HTTPS), HTTP-Anfrage senden, Antwort empfangen und an die Anwendung zurückgeben. RealCall ist die interne Klasse, die den gesamten Lebenszyklus einer Anfrage von der Erstellung bis zum Abschluss verwaltet.

OkHttp behandelt automatisch Weiterleitungen (302, 301), wiederholt Anfragen bei Netzwerkausfällen, folgt dem Keep-Alive-Protokoll und unterstützt transparente Gzip-Komprimierung. Der Entwickler muss keinen Code für diese Operationen schreiben — OkHttp erledigt sie automatisch basierend auf den Server-Headern.

HTTP/2-Unterstützung und Multiplexing

HTTP/2 ermöglicht das gleichzeitige Senden mehrerer Anfragen über eine einzige TCP-Verbindung ohne Head-of-Line-Blocking (charakteristisch für HTTP/1.1). OkHttp verwendet automatisch HTTP/2, wenn der Server dies unterstützt, und wechselt bei Bedarf transparent zu HTTP/1.1.

HTTP/2-Multiplexing ist besonders wichtig für mobile Anwendungen, bei denen die Latenz beim Verbindungsaufbau (TCP + TLS) 100–300 ms betragen kann. Statt 10 sequenziellen Verbindungen verwendet OkHttp eine einzige und reduziert die Gesamtlatenz um 40–60% auf typischen Android-Geräten mit instabilen Verbindungen.

OkHttp Interceptors: Interceptor und NetworkInterceptor

Interceptor ist ein Interface mit einer einzigen Methode intercept(Chain), die eine Request erhält, Aktionen ausführt und eine Response zurückgibt. Es gibt zwei Arten von Interceptors: Application-Interceptors (hinzugefügt über addInterceptor) und Network-Interceptors (addNetworkInterceptor).

Application-Interceptors werden ausgelöst, bevor die HTTP-Anfrage gebildet wird — sie sehen die originale Request und die finale Response nach allen Transformationen. Network-Interceptors werden auf Netzwerkebene ausgelöst: Sie sehen die Anfrage nach Gzip-Komprimierung, Hinzufügen des Content-Length-Headers, Weiterleitungen und Wiederholungen. Network-Interceptors werden nicht aufgerufen, wenn die Antwort aus dem Cache geliefert wird.

Praktische Anwendung von Interceptors

In der Praxis lösen OkHttp-Interceptors drei Hauptaufgaben: Authentifizierung (Hinzufügen des Authorization-Headers), Protokollierung (HttpLoggingInterceptor zum Debuggen) und Wiederholung (automatische Wiederholung von Anfragen bei Netzwerkausfällen). Durch die Kombination mehrerer Interceptors kann eine vollständige Anfrageverarbeitungspipeline ohne Code-Duplizierung in jedem HTTP-Aufruf der Anwendung aufgebaut werden.

Die Reihenfolge des Hinzufügens von Interceptors ist wichtig: Der zuerst hinzugefügte Interceptor wird beim Eintritt als erster und beim Austritt als letzter ausgeführt. Für NetworkInterceptor wird die Reihenfolge vom Netzwerk-Stack bestimmt. Empfohlene Reihenfolge: AuthInterceptor (fügt Token hinzu), LoggingInterceptor (protokolliert die Anfrage), RetryInterceptor (wiederholt bei Fehlern).

Protokollierung über HttpLoggingInterceptor

Zum Debuggen von Netzwerkanfragen wird HttpLoggingInterceptor verwendet — ein fertiger Interceptor von Square. Er protokolliert die Methode, URL, Header und den Anfrage-/Antwortkörper. Protokollierungsstufen: BASIC (Methode + URL + Code), HEADERS (mit Headern) und BODY (vollständige Anfrage und Antwort). BODY ist während der Entwicklung nützlich, wird aber aus Sicherheits- und Leistungsgründen in der Produktion deaktiviert.

OkHttp-Codebeispiele in Kotlin

Betrachten wir eine einfache GET-Anfrage mit OkHttp. Zunächst wird ein OkHttpClient erstellt — ein schweres Objekt, das einmal erstellt und wiederverwendet wird. Dann wird eine Request mit einer URL erstellt, und die Anfrage wird synchron über execute oder asynchron über enqueue ausgeführt.

val client = OkHttpClient.Builder()
    .connectTimeout(15, TimeUnit.SECONDS)
    .readTimeout(15, TimeUnit.SECONDS)
    .build()

val request = Request.Builder()
    .url("https://api.github.com/users/octocat")
    .header("Accept", "application/vnd.github.v3+json")
    .build()

val response = client.newCall(request).execute()
println(response.body()?.string())

Für die asynchrone Ausführung wird die Methode enqueue verwendet, die einen Callback akzeptiert. OkHttp führt die Anfrage in einem Hintergrundthread aus und gibt das Ergebnis im Callback im selben Thread zurück. Zum Wechseln zum Android-Hauptthread verwenden Sie Handler oder Koroutinen.

client.newCall(request).enqueue(object : Callback {
    override fun onFailure(
        call: Call, e: IOException
    ) {
        println("Anforderung fehlgeschlagen: ${e.message}")
    }

    override fun onResponse(
        call: Call, response: Response
    ) {
        println(response.body()?.string())
    }
})

Hinzufügen eines Interceptors für die Authentifizierung

Ein benutzerdefinierter Interceptor fügt jeder Anfrage ein Bearer-Token hinzu. Der Interceptor prüft das Vorhandensein des Authorization-Headers und fügt, falls das Token noch nicht gesetzt ist, es aus dem Speicher hinzu. Bei einer 401-Antwort kann der Interceptor das Token über den Authenticator aktualisieren.

class AuthInterceptor(
    private val tokenProvider: () -> String?
) : Interceptor {
    override fun intercept(chain: Interceptor.Chain): Response {
        val originalRequest = chain.request()
        val token = tokenProvider.invoke()
        val request = originalRequest.newBuilder()
            .header("Authorization", "Bearer $token")
            .build()
        return chain.proceed(request)
    }
}

Verbindungspool und Caching in OkHttp

Verbindungspool (ConnectionPool) ist eine wichtige OkHttp-Optimierung, die die Wiederverwendung von TCP-Verbindungen für mehrere Anfragen ermöglicht. Anstatt für jede Anfrage einen neuen Socket zu erstellen, speichert OkHttp standardmäßig bis zu 5 inaktive Verbindungen für 5 Minuten, wodurch die Latenz für wiederholte Anfragen an denselben Host um 30–70% reduziert wird.

Das Antwort-Caching wird über die Klasse Cache implementiert. Zum Aktivieren des Caches genügt es, das Verzeichnis und die maximale Größe in OkHttpClient.Builder anzugeben. OkHttp speichert GET-Antworten automatisch gemäß den Cache-Control-, Expires- und ETag-Headern zwischen und gibt zwischengespeicherte Daten ohne Netzwerkanfrage zurück, wenn sie nicht veraltet sind.

val cacheDir = File(context.cacheDir, "http-cache")
val cache = Cache(cacheDir, 10L * 1024 * 1024)

val client = OkHttpClient.Builder()
    .cache(cache)
    .connectionPool(ConnectionPool(5, 5, TimeUnit.MINUTES))
    .build()

Die richtige Konfiguration von Pool und Cache ist besonders wichtig für Anwendungen mit häufigen Anfragen — Nachrichtenfeeds, Chats, Datenaktualisierungen. Ohne Pool erfordert jede TCP-Verbindung einen Drei-Wege-Handshake (SYN, SYN-ACK, ACK) und möglicherweise einen TLS-Handshake (2–3 Round Trips), was 100–500 ms zu jeder Anfrage hinzufügt.

OkHttp unterstützt auch WebSocket über die Klasse RealWebSocket. Eine WebSocket-Verbindung wird durch einen HTTP-Handshake (101 Switching Protocols) hergestellt und wechselt dann zu einem bidirektionalen Protokoll. OkHttp sendet automatisch Ping-Frames, um die Verbindung aktiv zu halten, und verbindet sich bei Unterbrechung neu. Der WebSocket von OkHttp ist mit Standard-Endpunkten wie wss://echo.websocket.org kompatibel.

Häufige Fehler bei der Arbeit mit OkHttp

OkHttpClient für jede Anfrage erstellen ist der häufigste Fehler. OkHttpClient enthält einen Verbindungspool, Cache und Thread-Pool. Das Erstellen einer neuen Instanz für jede Anfrage verschwendet nicht nur Speicher, sondern nimmt auch den Vorteil der Verbindungswiederverwendung. OkHttpClient sollte ein Singleton über einen DI-Container sein.

Ignorieren des Schließens von Response.body() führt zu Ressourcenlecks. ResponseBody enthält einen InputStream, der nach dem Lesen geschlossen werden muss. Bei Verwendung von body().string() oder body().bytes() schließt OkHttp den Stream automatisch, aber beim Lesen von body().byteStream() oder body().charStream() ist ein expliziter close()-Aufruf in einem finally-Block erforderlich.

Fehlende Timeout-Behandlung ist ein weiteres Problem. Standardmäßig hat OkHttp einen connectTimeout von 10 Sekunden, readTimeout von 10 Sekunden und writeTimeout von 10 Sekunden. Für mobile Anwendungen mit instabilen Verbindungen wird empfohlen, connectTimeout auf 15–30 Sekunden und readTimeout auf 15–30 Sekunden zu setzen, andernfalls wartet der Benutzer bei schlechtem Signal zu lange.