Client-Timeout

Wenn ein Programm Daten über das Internet holt, wartet es auf eine Antwort. Das anfragende Programm nennt man Client, zum Beispiel eine App auf dem Handy oder ein Browser. Der antwortende Computer auf der Gegenseite ist der Server. Ein Client-Timeout ist die Frist, die sich der Client selbst setzt: Kommt bis dahin keine Antwort, bricht er das Warten ab und meldet einen Fehler. Typisch sind 30 oder 60 Sekunden, manchmal aber auch nur 5. Ohne solche Fristen könnte ein Programm endlos hängen, weil es auf eine Antwort wartet, die nie kommt.

Warum abgebrochene Anfragen trotzdem Geld kosten

Ein Timeout schützt zuerst den Nutzer. Eine App, die nach einer halben Minute „Verbindung fehlgeschlagen“ sagt, ist besser als eine, die für immer einen Ladebalken zeigt. Der Nutzer kann es erneut versuchen oder etwas anderes tun. Ohne Timeout blockieren außerdem Ressourcen im Client: offene Verbindungen, belegter Speicher, wartende Prozesse.

Bei KI-Diensten hat der Abbruch aber eine unangenehme Nebenwirkung. Der Server bemerkt oft nicht sofort, dass niemand mehr zuhört. Er rechnet die Antwort fertig, obwohl sie ins Leere geht. Die Rechenzeit auf teuren Grafikkarten ist also verbraucht, das Ergebnis aber wertlos. Bei vielen Nutzern gleichzeitig entsteht daraus ein spürbarer Kostenposten.

Noch heikler ist ein Timeout bei Anfragen, die etwas verändern. Wenn eine Bezahlung oder eine Bestellung abgebrochen wird, weiß der Client nicht, ob sie durchging. Der Server hat sie vielleicht längst ausgeführt. Ein erneuter Versuch kann dann zu einer doppelten Buchung führen. Gut gebaute Systeme verhindern das, indem jede Anfrage eine eindeutige Kennung mitbringt und mehrfach gesendet trotzdem nur einmal wirkt.

Wer die Uhr stellt und wo sie tickt

Die Uhr läuft im Client, nicht im Netz und nicht im Server. Sobald die Anfrage rausgeht, startet ein Zähler. Erreicht er die eingestellte Grenze, wirft das Programm einen Fehler und schließt die Verbindung. Man kann sich das wie eine Eieruhr in der Küche vorstellen: Sie klingelt unabhängig davon, ob der Kuchen fertig ist.

In der Praxis gibt es mehrere solche Uhren hintereinander. Eine für den Verbindungsaufbau, eine für das Warten auf die erste Antwortzeile, eine für die gesamte Übertragung. Bei Chat-Systemen ist die letzte besonders wichtig. Solche Systeme antworten meist im Streaming, also Wort für Wort statt am Ende alles auf einmal. Ein knappes Gesamt-Timeout schneidet dann lange Antworten mitten im Satz ab.

Wichtig ist die Abgrenzung zum Server-Timeout. Dort setzt der Server selbst eine Grenze und beendet eine zu lange Anfrage von seiner Seite. Wer beide Fristen unabgestimmt einstellt, bekommt schwer erklärbare Fehler. Als Faustregel sollte die Frist des Clients etwas länger sein als die des Servers, damit der Server sauber melden kann, dass er aufgibt.

Vom Ladebalken bis zur Fehlermeldung in der API

Im Alltag zeigt sich ein Client-Timeout als kurze, nüchterne Fehlermeldung. „Zeitüberschreitung der Anfrage“, „Der Vorgang wurde abgebrochen“ oder ein Ladekreis, der irgendwann verschwindet. In schlechtem Handynetz passiert das häufig, weil Antworten dort länger brauchen als der Client erlaubt.

Wer selbst programmiert, stellt diese Grenzen ausdrücklich ein. Programmierschnittstellen großer KI-Anbieter — also die technischen Zugänge, über die andere Programme das Modell nutzen — dokumentieren dafür eigene Empfehlungen. Für aufwendige Anfragen an sogenannte Reasoning-Modelle, die vor der Antwort längere Rechenschritte durchlaufen, werden mehrere Minuten empfohlen. Wer den Standardwert der Programmbibliothek stehen lässt, sieht dann reihenweise Abbrüche.

Ein verbreiteter Irrtum lautet: Ein Timeout heißt, der Server sei ausgefallen. Das stimmt selten. Meist war er nur überlastet oder die Antwort war einfach lang. Deshalb wiederholen viele Systeme die Anfrage automatisch, aber mit steigenden Pausen. Dieses Verfahren heißt Backoff und verhindert, dass tausende Clients gleichzeitig nachbohren und den ohnehin langsamen Server endgültig lahmlegen.