Socket: Netzwerk-Endpunkte einfach erklärt

Stell dir zwei Programme vor, die Nachrichten austauschen sollen. Sie greifen nicht selbst auf Netzwerkkarte, Übertragungswege und sämtliche Protokolldetails zu. Stattdessen fordern sie beim Betriebssystem jeweils einen Socket an.

Bei einer Netzwerkübertragung gibt die Anwendung ihre Daten am Socket ab. Das Betriebssystem verarbeitet sie in den darunterliegenden Protokollschichten. Auf dem Zielrechner läuft der Weg in umgekehrter Richtung, bis die Daten über den dortigen Socket die empfangende Anwendung erreichen.

Für die beiden Programme kann es dadurch so wirken, als seien ihre Sockets direkt miteinander verbunden. Tatsächlich liegen mehrere Kommunikationsschichten und möglicherweise viele Netzwerkgeräte dazwischen.

Auf einem Rechner laufen meist viele Prozesse gleichzeitig. Deshalb genügt es nicht, nur den Zielrechner zu bestimmen. Die Daten müssen auch beim richtigen Kommunikationsendpunkt ankommen.

Eine typische Internet-Socket-Adresse besteht deshalb aus zwei Teilen:

• IP-Adresse: Welcher Rechner beziehungsweise welche Schnittstelle?
• Port: Welcher Kommunikationsendpunkt auf diesem Rechner?

Beispielsweise bezeichnet 192.168.0.1:5000 die IP-Adresse 192.168.0.1 und den Port 5000. Ein Client muss diese Serveradresse kennen. Seinen eigenen lokalen Port wählt das Betriebssystem häufig automatisch aus.

TCP-Ports und UDP-Ports bilden getrennte Namensräume. TCP-Port 5000 ist daher nicht derselbe Endpunkt wie UDP-Port 5000.

Sockets können unterschiedliche Kommunikationsarten verwenden. Besonders wichtig sind Stream-Sockets mit TCP und Datagramm-Sockets mit UDP.

TCP als geordneter Datenstrom

Ein TCP-Socket überträgt einen zuverlässigen, geordneten Byte-Datenstrom. Vor dem Datenaustausch wird eine Verbindung aufgebaut. TCP erkennt Übertragungsfehler und sorgt dafür, dass fehlende Daten erneut übertragen und in der richtigen Reihenfolge bereitgestellt werden.

Ein Byte-Datenstrom besitzt jedoch keine eingebauten Nachrichtengrenzen. Ein Aufruf wie recv(1024) bedeutet nur: Empfange bis zu 1024 Byte. Er garantiert nicht, dass genau eine vollständige Nachricht oder alle zuvor gesendeten Daten zurückgegeben werden. Die Anwendung braucht deshalb eine eigene Regel für Nachrichtengrenzen, etwa eine bekannte Länge oder ein eindeutiges Trennzeichen.

UDP als einzelne Datagramme

Ein UDP-Socket überträgt einzelne Datagramme, also abgegrenzte Nachrichten. Vorher ist kein TCP-artiger Verbindungsaufbau nötig. UDP garantiert jedoch weder Zustellung noch Reihenfolge. Datagramme können verloren gehen, doppelt eintreffen oder in anderer Reihenfolge ankommen.

Beim Client-Server-Modell übernimmt der Server eine bekannte Adresse und wartet. Der Client beginnt den Verbindungsaufbau.

Ablauf auf der Serverseite

1. socket() erzeugt einen Stream-Socket.
2. bind() bindet ihn an eine lokale IP-Adresse und einen Port.
3. listen() versetzt ihn in den Listening-Modus.
4. accept() wartet auf einen Verbindungsversuch und liefert einen neuen Connected-Socket für diesen Client.
5. Über den Connected-Socket werden Daten empfangen und gesendet.
6. close() gibt den Kommunikations-Socket wieder frei.

Der ursprüngliche Listening-Socket bleibt für weitere Verbindungsversuche zuständig. Der von accept() gelieferte Socket dient dagegen der Kommunikation mit einem bestimmten Client. So kann ein Server mehrere Verbindungen unterscheiden und – mit zusätzlichen Threads, Prozessen oder asynchroner Verarbeitung – gleichzeitig bearbeiten.

Ablauf auf der Clientseite

1. socket() erzeugt einen Stream-Socket.
2. connect() erhält die IP-Adresse und den Port des Servers und startet den Verbindungsaufbau.
3. Der Client sendet und empfängt Daten.
4. close() schließt den Socket und gibt Ressourcen frei.

Kurze Lehrbeispiele zeigen oft nur den Grundablauf. Für echte Anwendungen fehlen dann noch wichtige Regeln.

• Teilweiser Empfang: recv() kann weniger Daten liefern als erwartet. Die Anwendung muss weiter lesen und Nachrichtengrenzen selbst erkennen.
• Teilweises Senden: Auch beim Senden muss die Anwendung sicherstellen, dass alle vorgesehenen Bytes verarbeitet wurden. Hilfsfunktionen wie sendall() können dies vereinfachen.
• Leere Empfangsdaten: Bei TCP zeigt ein Empfang von null Byte an, dass die Gegenseite ihren Sendekanal geschlossen hat.
• Blockieren: accept() und recv() können warten. Timeouts oder eine geeignete Nebenläufigkeit verhindern, dass das ganze Programm unbegrenzt feststeckt.
• Ressourcen: Sockets müssen auch nach Fehlern geschlossen werden, damit Betriebssystemressourcen freikommen.
• Sicherheit: Ein normaler TCP-Socket verschlüsselt Daten nicht automatisch. Vertrauliche Netzwerkkommunikation benötigt zusätzliche Schutzmechanismen wie TLS und eine passende Authentifizierung.

Lokale Prozesse können statt einer Internetadresse auch einen Unix Domain Socket verwenden. Er wird durch einen Dateipfad wie /var/run/example.sock adressiert und vermeidet Teile des Netzwerk-Overheads. Diese Socket-Art ist vor allem auf Unix-artigen Systemen verbreitet.

Wenn du Socket, IP-Adresse, Port, Transportart und Socket-Rolle auseinanderhalten kannst, kannst du den Weg einer Nachricht erklären und viele typische Fehler in einfachen Client-Server-Programmen gezielt diagnostizieren.