Ich habe einige Fragen bezüglich derfolgende Erklärung der Ports fand ich.
Die Anwendungsschicht kommuniziert mit der Transportschicht über einen Port. Ports sind nummeriert und Standardanwendungen verwenden immer denselben Port.
Durch die Verwendung einer Portnummer erkennt das Transportprotokoll (normalerweise TCP), welche Art von Inhalt das Paket enthält, und weiß so auf der Empfangsseite, an welches Anwendungsprotokoll die empfangenen Daten übermittelt werden sollen.
Warum sollte eine Portnummer jemals verwendet werden, um festzustellen, welche Art von Anwendungsdatenprotokoll darin enthalten ist, wenn es keine absolute Garantie dafür gibt?
Meines Wissens gibt es keine Einschränkungen, welche Art von Anwendungsdaten Sie über einen Port senden (es ist nur ein Vorschlag). Und sind die Protokolldaten zu diesem Zweck nicht bereits irgendwo im Paket enthalten?
Und was passiert mit den Daten, wenn Sie HTTP oder ein anderes Protokoll an ein Ziel von Port 25 senden (das SMTP erwartet)?
Drittens: Was passiert mit den Daten, wenn Sie sie an einen Port senden, der an kein Programm gebunden ist und daher nicht abgehört wird?
**Und wenn ein Port nur an ein einziges Programm gebunden werden kann, wie können dann mehrere Programme gleichzeitig auf meinem Computer ausgeführt werden, die von eingehenden HTTP-Daten abhängen?****
Dank im Voraus!
Antwort1
Warum sollte eine Portnummer jemals verwendet werden, um festzustellen, welche Art von Anwendungsdatenprotokoll darin enthalten ist, wenn es keine absolute Garantie dafür gibt?
Denn Raten ist eine furchtbare Vorgehensweise und man kann zum Beispiel niemanden mit böser Absicht davon abhalten, das Falsche zu senden. Es hilft also, wenn alle fair spielen und es macht nichts schlimmer.
Meines Wissens nach gibt es keine Einschränkungen hinsichtlich der Art der Anwendungsdaten, die Sie über einen Port senden (es handelt sich lediglich um einen Vorschlag).
Richtig. Tatsächlich handelt es sich nicht einmal um einen Vorschlag, sondern nur um eine Vereinbarung, die viele Leute teilen.
Und sind die Protokolldaten zu diesem Zweck nicht bereits irgendwo im Paket enthalten?
Nein. Zumindest nicht auf der Ebene, die der Port normalerweise anzeigt: Sie wissen, welche Art von IP-Protokoll höherer Ebene gesendet wird (z. B. TCP, UDP), aber nicht, was dessen Inhalt ist (z. B. HTTP, SMTP).
Und was passiert mit den Daten, wenn Sie HTTP oder ein anderes Protokoll an ein Ziel von Port 25 senden (das SMTP erwartet)?
TCP übergibt die Daten einfach an die Anwendungsschicht, die damit machen kann, was sie will. Meistens treten dabei nur Fehler auf. Manchmal treten aber auch Sicherheitslücken auf, die ausgenutzt werden können.
Gelegentlich kommt es bei fehlerhaften Clients zu einem angenehmen Verhalten, beispielsweise zu HTTP-Fehlern im Klartext, die einige HTTPS-Server ausgeben, wenn Sie für den Port kein SSL verwenden.
Drittens: Was passiert mit den Daten, wenn Sie sie an einen Port senden, der an kein Programm gebunden ist und daher nicht abgehört wird?
Sie erhalten eine ICMP-Fehlermeldung vom empfangenden System. Technisch gesehen könnte der Empfänger tun, was er will, aber in der Praxis passiert genau das.
Und schließlich: Wenn ein Port nur an ein einziges Programm gebunden werden kann, wie können dann mehrere Programme, die von eingehenden HTTP-Daten abhängen, gleichzeitig auf meinem Computer ausgeführt werden?
Wenn Ihr Browser eine HTTP-Verbindung zu einem Remote-Server herstellt, verwendet er einen zufälligen lokalen Port und kommuniziert mit dem bekannten Port (80 oder 443) auf dem Remote-Server. In diesem Fall ist der Port für jede einzelne ausgehende Verbindung eindeutig. (Technisch gesehen muss dies jedoch nicht so sein, wie im Serverfall.)
Auf der Serverseite kann beim Abhören nur ein Prozess neue Verbindungen auf einem Port annehmen (in Unix-/BSD-Sockets), er kann aber die hergestellte Verbindung an andere zu bedienende Prozesse weitergeben. Da der Satz eindeutig ist, kann der Verkehr an die richtige Verbindung weitergeleitet werden.