Das Client-Server-Modell
Das Client-Server-Modell
Im Client-Server-Modell gibt es eine klare Rollenverteilung: Ein zentraler Server stellt Dienste bereit, mehrere Clients nehmen diese in Anspruch. Der Server laeuft in der Regel dauerhaft und wartet auf Anfragen.
| Merkmal | Beschreibung |
|---|---|
| Zentrale Steuerung | Der Server verwaltet Daten, Benutzerkonten und Zugriffsrechte zentral |
| Request-Response | Clients senden Anfragen, der Server verarbeitet sie und liefert Antworten |
| Skalierbarkeit | Neue Clients koennen ohne Aenderung am Server hinzugefuegt werden |
| Verfuegbarkeit | Faellt der Server aus, steht der gesamte Dienst still (Single Point of Failure) |
| Beispiele | Webserver (Apache, Nginx), E-Mail (Exchange), Datenbank (MySQL), Active Directory |
Ein Client-Server-Netzwerk funktioniert wie ein Restaurant: Die Kueche (Server) bereitet Gerichte zu, und die Gaeste (Clients) bestellen ueber den Kellner. Jeder Gast bekommt sein bestelltes Gericht - aber wenn die Kueche schliesst, gibt es fuer niemanden mehr Essen.
Client-Server im Alltag
Das Client-Server-Modell begegnet uns taeglich - oft ohne dass wir es bewusst wahrnehmen. Nahezu jede Internetanwendung basiert auf diesem Prinzip.
Das Schema ist immer gleich: Ein Programm (Client) stellt eine Anfrage an einen Dienst (Server) ueber ein definiertes Protokoll. Wer das Muster einmal verstanden hat, kann jede Client-Server-Anwendung einordnen.
Das Peer-to-Peer-Modell (P2P)
Im Peer-to-Peer-Modell sind alle Teilnehmer gleichberechtigt. Jeder Rechner kann gleichzeitig Client und Server sein - es gibt keine zentrale Instanz, die den Verkehr steuert.
| Merkmal | Beschreibung |
|---|---|
| Gleichberechtigung | Kein zentraler Server - jeder Knoten ist Client und Server zugleich |
| Ausfallsicherheit | Faellt ein Peer aus, funktioniert das restliche Netz weiter |
| Ressourcenteilung | Bandbreite, Speicher und Rechenleistung werden gemeinsam genutzt |
| Verwaltung | Schwer zentral zu administrieren - jeder Peer verwaltet sich selbst |
| Beispiele | BitTorrent, Bitcoin/Blockchain, AirDrop, LAN-Spiele, IPFS |
P2P ist wie eine Lerngruppe ohne Lehrer: Jeder bringt eigenes Wissen mit und teilt es direkt mit den anderen. Niemand hat die Aufsicht oder die alleinige Wahrheit. Wenn jemand fehlt, macht die Gruppe einfach weiter - es fehlt nur ein Stueck Wissen.
Vergleich: Client-Server vs. Peer-to-Peer
Beide Modelle haben klare Staerken und Schwaechen. Die Wahl haengt vom Einsatzzweck, der Netzwerkgroesse und den Sicherheitsanforderungen ab.
| Kriterium | Client-Server | Peer-to-Peer |
|---|---|---|
| Struktur | Hierarchisch (Server oben, Clients unten) | Flach (alle gleichberechtigt) |
| Verwaltung | Zentral, professionell administrierbar | Dezentral, jeder Peer eigenverantwortlich |
| Kosten | Hoehere Anfangsinvestition (Hardware, Lizenzen) | Geringere Einstiegskosten |
| Skalierung | Gut skalierbar durch Server-Upgrades/Cluster | Skaliert durch neue Peers, wird aber komplexer |
| Ausfallrisiko | Single Point of Failure (Server) | Kein einzelner Ausfallpunkt |
| Datensicherheit | Zentrale Backups und Rechteverwaltung | Jeder Peer muss selbst Backups erstellen |
| Performance | Abhaengig von Server-Leistung | Steigt mit Anzahl der Peers (mehr Quellen) |
| Typische Groesse | Mittel bis gross (ab ca. 10 Geraete) | Klein (bis ca. 10 Geraete) oder spezialisiert |
P2P ist wie eine Lerngruppe ohne Lehrer: Jeder bringt eigenes Wissen mit und teilt es direkt mit den anderen. Niemand hat die Aufsicht oder die alleinige Wahrheit. Wenn jemand fehlt, macht die Gruppe einfach weiter - es fehlt nur ein Stueck Wissen.
IT-Sicherheit: Schwachstellen Client-Server
Die zentrale Architektur des Client-Server-Modells erzeugt spezifische Angriffsvektoren. Der Server ist das primaere Ziel - wer ihn kompromittiert, hat potenziell Zugriff auf alle Daten und Dienste.
| Schwachstelle | Beschreibung | Gegenmassnahme |
|---|---|---|
| Single Point of Failure | Server-Ausfall legt den gesamten Dienst lahm | Redundanz, Failover-Cluster, Load Balancing |
| DDoS-Angriff | Massenanfragen ueberlasten den Server | Rate Limiting, CDN, Anti-DDoS-Diensteh |
| SQL-Injection | Schadcode in Eingabefeldern manipuliert die Datenbank | Prepared Statements, Input-Validierung |
| Privilegien-Eskalation | Angreifer erlangt erhoehte Rechte auf dem Server | Least-Privilege-Prinzip, regelmaessige Patches |
| Man-in-the-Middle | Abfangen der Client-Server-Kommunikation | TLS/HTTPS, Zertifikats-Pinning |
| Fehlkonfiguration | Offene Ports, Standard-Passwoerter, fehlende Updates | Hardening-Checklisten, Vulnerability-Scans |
Bei einer SQL-Injection schleust ein Angreifer SQL-Befehle ueber Eingabefelder ein. Statt eines Benutzernamens wird z.B. ' OR 1gleich1 -- eingegeben. Ist die Anwendung verwundbar, wird die gesamte Datenbank ausgelesen. Gegenmittel: Prepared Statements trennen SQL-Logik strikt von Nutzereingaben.
