In der Informatik bezeichnet Client-Server ein verbreitetes Software-Architekturmodell, das aus zwei grundsätzlichen Teilen besteht: Client-Systemen und Server-Systemen. Beide kommunizieren entweder über ein Computernetzwerk oder — seltener — lokal auf demselben Computer. Eine Client‑Server‑Anwendung ist damit ein verteiltes System, das sowohl aus Client‑ als auch aus Server‑Software besteht. Typisch ist das Anfrage‑Antwort‑Prinzip: Der Client‑Prozess initiiert eine Verbindung und sendet eine Anfrage, während der Server‑Prozess auf solche Anfragen wartet, sie verarbeitet und eine Antwort zurückliefert.

Wenn sowohl der Client- als auch der Server‑Prozess auf demselben Computer laufen, spricht man von einer Einzelplatzeinrichtung (lokale Client‑Server‑Konstellation). In der Praxis existieren jedoch oft viele Clients, die mit einem oder mehreren Servern über ein Netzwerk verbunden sind.

Funktionsweise und typische Komponenten

Die grundlegende Interaktion läuft meist nach dem Muster „Request — Process — Response“ ab. Wichtige Punkte sind:

  • Der Client stellt eine Dienstanforderung (z. B. Daten abfragen, Datei hochladen).
  • Der Server empfängt die Anfrage, prüft Berechtigungen, verarbeitet die Anfrage (z. B. Datenbankabfrage, Geschäftslogik) und sendet eine Antwort zurück.
  • Zwischen Client und Server werden standardisierte Kommunikationsprotokolle verwendet, z. B. HTTP(s) für Web‑Anwendungen, SMTP für E‑Mail, FTP für Dateitransfer oder eigene Protokolle über TCP/UDP.

In modernen Systemen gibt es oft zusätzliche Komponenten wie Load Balancer, Firewalls, Caching‑Server, Datenbank‑Server und API‑Gateways. Das klassische zweistufige Modell (Client und Server) kann erweitert werden zu mehrschichtigen (n‑Tier) Architekturen, etwa mit einer separaten Anwendungsschicht und einer Datenbankschicht.

Architekturvarianten

  • Zweistufig (Client‑Server): Nur Clients und Server — einfach und direkt.
  • Mehrschichtig (n‑Tier): Trennung von Präsentation, Anwendungslogik und Datenhaltung; verbessert Skalierbarkeit und Wartbarkeit.
  • Thin Client vs. Fat Client: Beim Thin Client liegt die meiste Logik auf dem Server (z. B. Web‑Apps). Beim Fat Client läuft mehr Logik lokal im Client (z. B. Desktop‑Anwendungen mit Serverdaten).
  • Stateless vs. Stateful: Manche Server sind zustandslos (jeder Request ist unabhängig), andere halten Sitzungszustand (Session‑Management).

Client‑Server vs. Peer‑to‑Peer (P2P)

Eine verwandte Architektur ist Peer‑to‑Peer, bei der jeder Host oder jede Anwendungsinstanz gleichzeitig als Client und Server fungieren kann. Im Gegensatz zum zentralisierten Client‑Server‑Modell gibt es keine dedizierten zentralen Server; die Teilnehmer teilen gleichberechtigt Aufgaben und Ressourcen. Peer‑to‑Peer‑Architekturen werden oft mit dem Akronym P2P abgekürzt.

Wesentliche Unterschiede:

  • Zentralisierung: Client‑Server hat zentrale Server; P2P ist dezentral.
  • Skalierung: P2P kann in bestimmten Szenarien besser skaliert werden, weil Last verteilt wird; Client‑Server skaliert meist durch horizontale/vertikale Erweiterung und Lastverteilung.
  • Verfügbarkeit: P2P ist weniger anfällig für einen einzelnen Ausfallpunkt, Client‑Server benötigt redundante Server und Failover‑Mechanismen.
  • Kontrolle und Sicherheit: Bei Client‑Server sind Kontrolle, Authentifizierung und Richtlinien zentralisierbar; P2P stellt hier oft höhere Anforderungen an Vertrauens‑ und Schutzmechanismen.

Modellierung und Standardisierung

Die Client‑Server‑Beziehung beschreibt, wie ein Client eine Dienstanforderung an den Server stellt und wie der Server diese annimmt, verarbeitet und die angeforderten Informationen zurücksendet. Die Interaktion zwischen Client und Server wird oft mit Hilfe von Sequenzdiagrammen beschrieben. Sequenzdiagramme sind in der Unified Modeling Language standardisiert und helfen dabei, zeitliche Abläufe und Nachrichtenflüsse grafisch darzustellen.

Vor‑ und Nachteile

  • Vorteile: zentrale Verwaltung, einfache Zugriffskontrolle, klare Trennung von Aufgaben, oft gute Performance bei richtiger Skalierung, etablierte Protokolle und Werkzeuge.
  • Nachteile: Zentraler Ausfallpunkt ohne Redundanz, höhere Infrastrukturkosten bei hoher Last, mögliche Engpässe bei Bandbreite und Serverkapazität.

Einsatzbereiche und Beispiele

Die Client‑Server‑Architektur ist ein Grundmodell des Network Computing und bildet die Basis vieler heutiger Anwendungen. Typische Beispiele sind:

  • E‑Mail‑Systeme (SMTP/IMAP/POP)
  • Web‑Zugriff: Ein Web‑Browser ist ein Client, der Informationen von Web‑Servern anfordert.
  • Datenbankzugriff: Clients stellen Abfragen an Datenbankserver.
  • Enterprise‑Anwendungen, Mobile Backends, API‑Server für Web‑ und Mobile‑Apps.

Sicherheit, Skalierbarkeit und Performance

Sicherheit wird in Client‑Server‑Systemen zentralisiert umgesetzt: Authentifizierung, Autorisierung, Verschlüsselung (z. B. TLS) und Logging laufen meist serverseitig. Zur Skalierung werden Maßnahmen wie Caching, Load Balancing, Replikation von Servern und horizontale Skalierung verwendet. Für hohe Performance ist das richtige Zusammenspiel von Netzwerk‑, Server‑ und Datenbank‑Tuning entscheidend.

Sowohl Client‑Server als auch P2P‑Architekturen sind heute weit verbreitet. Die Auswahl hängt von Anforderungen an Kontrolle, Verfügbarkeit, Skalierung und Sicherheit ab.