EMZETT.Client
Kurz: Ein Gerät oder Programm, das Dienste oder Daten von einem Server anfordert — das Gegenstück zum Server im Client-Server-Modell.
Genauer: Beispiele: ein Browser, der eine Webseite von einem Webserver lädt, oder ein E-Mail-Programm, das Nachrichten von einem Mailserver abruft. Ein Gerät kann je nach Kontext gleichzeitig Client und Server sein (z. B. bei Peer-to-Peer-Systemen).
Im Detail
Die Rollenverteilung im Client-Server-Modell
Das Client-Server-Modell beschreibt eine grundlegende Rollenverteilung, nicht zwingend physisch getrennte Hardware: Der Client initiiert eine Anfrage (Request), der Server wartet passiv auf solche Anfragen und antwortet (Response) — diese Asymmetrie ist der Kern des Modells, unabhängig davon, ob Client und Server im selben Raum stehen oder Kontinente auseinanderliegen und über das Internet kommunizieren. Ein Browser ist dabei nur ein Beispiel unter vielen: Auch eine mobile App, die Daten von einer REST-API abruft, ein Mailclient, der Nachrichten von einem Mailserver holt, oder ein Spiel, das den Spielstand mit einem Spiele-Server synchronisiert, folgt demselben Grundmuster.
Dicke vs. dünne Clients
Eine wichtige Unterscheidung ist die zwischen “dicken” Clients (Fat/Thick Client — viel Logik und Verarbeitung läuft lokal auf dem Client, der Server liefert hauptsächlich Rohdaten, z. B. bei klassischer Desktop-Software) und “dünnen” Clients (Thin Client — fast die gesamte Logik läuft serverseitig, der Client zeigt nur noch das Ergebnis an, z. B. bei einer einfachen serverseitig gerenderten Webseite). Moderne Web-Anwendungen bewegen sich oft irgendwo dazwischen, da viel Logik inzwischen direkt im Browser per JavaScript läuft.
Wann jemand gleichzeitig Client und Server ist
Wichtig ist die Unterscheidung zur Rolle “Peer” in Peer-to-Peer-Netzwerken (z. B. bei manchen Filesharing-Protokollen), wo jeder Teilnehmer gleichzeitig als Client UND Server agiert — es gibt keine feste Hierarchie, jeder kann Anfragen sowohl senden als auch beantworten. Auch innerhalb einer typischen Web-Architektur ist die Rollenverteilung oft mehrstufig: Ein Webserver ist aus Sicht des Browsers ein Server, tritt aber selbst wieder als Client auf, wenn er Daten bei einer Datenbank oder einem anderen Backend-Dienst anfragt — dieselbe Maschine kann also je nach Blickrichtung gleichzeitig beide Rollen einnehmen.
Client-seitige Hardware
Als “Client” wird umgangssprachlich auch das physische Endgerät selbst bezeichnet, an dem ein Nutzer arbeitet — vom Desktop-PC über Laptops bis zu Smartphones und Tablets. Diese Geräte müssen typischerweise deutlich weniger leistungsfähig sein als der zugehörige Server, da sie meist nur einen einzigen Nutzer gleichzeitig bedienen, während ein Server oft tausende Clients parallel versorgt.
Client-seitige vs. server-seitige Validierung
Ein wichtiges Sicherheitsprinzip: Client-seitige Logik (z. B. Eingabeprüfungen in einem Formular) dient primär dem Nutzungskomfort — schnelle Rückmeldung ohne Server-Roundtrip —, darf aber niemals die einzige Kontrolle sein, da der Client grundsätzlich als nicht vertrauenswürdig gilt. Jeder Client lässt sich manipulieren (z. B. über Entwicklertools im Browser oder eine abgeänderte App), weshalb sicherheitskritische Prüfungen (Berechtigung, Preise, Mengenbegrenzungen) immer zusätzlich serverseitig erzwungen werden müssen — eine reine Client-seitige Prüfung ist bestenfalls Komfort, nie ein echter Schutzmechanismus.
Client-Anwendungstypen
Neben dem klassischen Web-Client gibt es native Clients (eigenständige Apps für ein bestimmtes Betriebssystem, z. B. eine Desktop- oder Smartphone-App) und hybride Ansätze (Web-Technologien in einer nativ verpackten App, z. B. über Electron oder Cordova). Native Clients bieten meist bessere Performance und tieferen Zugriff auf Systemfunktionen (Kamera, Benachrichtigungen, Dateisystem), erfordern aber getrennte Entwicklung pro Plattform, während Web-Clients plattformübergreifend über einen einzigen Code funktionieren, dafür aber vom Funktionsumfang des Browsers begrenzt bleiben.