Port und Socket
Um von einem Programm aus auf eine Netzwerk-Ressource zuzugreifen, hat man das Konzept des Sockets erfunden. Ein Socket verhält sich aus der Sicht des Programmierers fast wie eine Datei. Er kann sie öffnen, etwas hineinschreiben, etwas herauslesen und sie wieder schließen. Intern verbindet das Betriebssystem den Socket mit dem Netzwerk.Will das Programm Firefox auf dem Server-Host das Programm Apache erwischen, muss es neben der IP-Adresse noch eine weitere Kennung geben, denn der Firefox möchte weder mit einem anderen Firefox, noch mit dem Thunderbird oder dem Mail-Server des Hosts Kontakt aufnehmen.
Zur Unterscheidung bekommen die Sockets eine für den Host eindeutige Nummer. Diese Nummer nennt man den Port. Ein Client kann irgendeine Nummer verwenden. Will man aber einen bestimmten Server erwischen, ist es gut, wenn er eine festgelegte Nummer hat. Beispielsweise binden sich Web-Server an den Port 80, wenn sie unverschlüsselte Webseiten anzubieten haben. Diese Konvention kennt jeder Browser und ruft darum den Port 80.
Einen solchen festgelegten Port nennt man einen "well-known-port". Eine Liste der wichtigsten findet man in der Datei /etc/services (unter UNIX/Linux).
Der Client wird sich dagegen irgendeinen Port geben lassen und bekommt dann einen Port aus dem höheren Bereich (1024 oder höher).
Manchmal können Sie den Port in einer URL sehen. Wenn ein Server angesprochen wird, der nicht über seinen well known port anzusprechen ist, dann wird im Web der Port durch einen Doppelpunkt abgetrennt an die Zieladresse gehängt.
Client und Server
Als Client wird der Prozess bezeichnet, der eine Anfrage startet. Ein Server wartet auf Anfragen von Clients, bearbeitet diese Anfragen und sendet die Ergebnisse an den Client zurück.
- Der Server macht sich bereit für Anfragen. Dazu muss er ständig verfügbar sein. Er holt sich einen Socket und bindet ihn an den well known port, für den er zuständig sein will. Dann liest er diesen Socket aus. Solange keine Anfrage vorliegt, wird er vom Betriebssystem schlafen gelegt, bis ihn eine Anfrage weckt.
- Der Client startet die Anfrage. Dazu fordert er einen Socket mit einem beliebigen Port an.
- Der Client bestückt seinen Socket mit der Zieladresse und dem bekannten Port und bittet um eine Verbindung (connect).
- Der Server wacht auf. Er stellt fest, dass da jemand an seinem Port ankommt. Er merkt sich den Port des Clients, um über diesen später seine Antwort zu senden.
- Bei den meisten Servern wird das Programm einen Parallelprozess eröffnen, damit während der Bearbeitung dieser Anfrage auch andere Clients seinen Dienst benutzen können.
- Der Client beginnt nun, seine Anfrage über den Socket zu senden. Anschließend liest er auf dem Socket, weil er hofft, eine Antwort zu bekommen. So wird er schlafen gelegt.
- Der Server hat nun die Anfrage des Clients aus dem Socket ausgelesen und beginnt mit der Bearbeitung. Beispielsweise holt er die Webseite, die der Client lesen will. Er sendet sie über seinen Socket an den Client-Port, den er sich zuvor gemerkt hat. Anschließend gibt es nichts für ihn zu tun und er wartet auf den nächsten Auftrag.
- Der Client wird durch die Antwort des Servers geweckt. Er liest seinen Socket aus und verarbeitet die Antwort, in der er beispielsweise die Webseite darstellt.
- Da er keine weiteren Anfragen an den Server hat, schließt er den Socket wieder und gibt damit seinen Port wieder frei.
Transmission Control Protocol (TCP) ordnet Pakete
Die Daten, die der Client an den Server sendet oder von ihm bekommt, wurden zum Transport in Pakete verpackt. Als Programmierer werden sie erwarten, dass die Pakete vollständig und in der richtigen Reihenfolge ankommen. Das ist aber bei den wilden Dingen, die im Internet passieren, nicht unbedingt gewährleistet.Damit die Programme dennoch einfach so arbeiten können, als würden sie es mit Dateien zu tun haben, muss das Netzwerk für eine klare Reihenfolge sorgen. Das erledigt das Transmission Control Protocol (TCP). Geht irgend ein Paket verloren, fragt es nach und bittet gegebenenfalls um Nachlieferung. Dann sortiert es die Pakete noch mundgerecht. Das geschieht alles im Hintergrund, so dass sich das Programm darum nicht kümmern muss.
Das mag alles seine Zeit dauern und das Netzwerk mit zusätzlichen Paketen belasten, aber in den meisten Fällen ist es sinnvoll, dass sich der Experte - die Netzwerkschicht - darum kümmert, anstatt dass das Programm all dies regelt.
Das TCP-Paket
32 Bits | |
---|---|
Quell-Port | Ziel-Port |
Sequenznummer | |
Acknowledgement-Nummer | |
Länge, Flags | Empfangsfenster |
Prüfsumme | Urgent Data Pointer |
Optionen | |
Payload |
- Quell-Port und Ziel-Port: Die IP-Adressen stehen bereits im IP-Paket, das das TCP-Paket transportiert.
- Sequenznummer: Gibt die Nummer des Bytes im Datenstrom an, bei dem dieses Paket beginnt.
- Acknowledgement-Nummer: Enthält die die nächste Sequenznummer, die der Absender der Bestätigung erwartet. Dies ist also die Sequenznummer plus 1 des letzten erfolgreich empfangenen Datenbytes. Dieses Feld ist nur gültig, wenn das ACK-Flag eingeschaltet ist. Sobald eine Verbindung hergestellt ist, ist das ACK-Flag immer eingeschaltet.
- Länge: Die Länge des Headers, kann wegen des Optionsfeldes variieren.
- Flags:
- URG: Das Segement enthält urgent data (dringende Daten).
- ACK: Zeigt, dass die Acknowledgment-Nummer gilt. Der Empfänger möge bitte darauf achten.
- PSH: Der Sender verwendete die Push-Operation.
- RST: Der Empfänger ist verwirrt und wünscht den Abbruch der Beziehungen.
- SYN: Verbindungsaufbau
- FIN: Verbindungsabbau
- Empfangsfenster: Hier kann der Client eintragen, wie viele Bytes er maximal empfangen will.
- Prüfsumme
- Urgent Data Pointer
- Optionen: Enthält die maximum segment size (MSS)
- Payload: Die Daten, wegen derer man sich den ganzen Stress macht
TCP-Verbindungs-Handshake
Da die TCP-Verbindung verlässliche Daten überträgt, gibt es einen Handshake.- Client sendet: SYN seq=x (x ist zufällig gewählt)
- Server antwortet: SYN-ACK ack=x+1 seq=y (y ist zufällig gewählt)
- Client sendet: ACK ack=y+1 seq=x+1, gefolgt von den Daten.
- Client oder Server sendet: fin seq=x (x ist zufällig gewählt)
- Gegenüber antwortet: ack=x+1 und dann fin=y (y ist zufällig gewählt)
- Client oder Server sendet: ack=y+1
User Datagram Protocol (UDP) fire and forget
In manchen Fällen ist Geschwindigkeit wichtiger als Zuverlässigkeit. So ist beim Streamen von Audio-Signalen der Verlust von einem Paket in den meisten Fällen gar nicht zu hören. Wenn aber die verlorenen Pakete nachgeordert werden, wird es zu einem hörbaren Zeitverlust kommen.Will der Programmierer eine solche Verbindung haben, gibt er bei Anforderung seines Sockets als Protokoll UDP an. Logischerweise wird dieser Socket nur mit einem UDP-Port auf Serverseite verbunden.
Dieses Verfahren ist sehr schnell und eignet sich besonders für Multimedia-Streams und VoIP.
Das UDP-Paket
32 Bits | |
---|---|
Quell-Port | Ziel-Port |
Länge | Prüfsumme |
Payload |
Das Paket wird als Data in ein IP-Paket gelegt.