Mehrere Programme, nur ein Port?
-
Hi!
Wie kann es eigentlich sein, dass mehrere Programme den gleichen Port nutzen, und trotzdem funktionieren?
zB. wenn ich in paar verschiedenen Browsern gleichzeitig surfe.
Oder einmal hatte ich ein Serverprogramm, welches auf Port 80 lief. Trotzdem funktionierte es zusammen mit dem Browser.Der Port ist doch die einzige eindeutige Identifikation, wo ein Datenpaket denn nun hin muss.
-
Fräge! schrieb:
Hi!
Wie kann es eigentlich sein, dass mehrere Programme den gleichen Port nutzen, und trotzdem funktionieren?
zB. wenn ich in paar verschiedenen Browsern gleichzeitig surfe.
Oder einmal hatte ich ein Serverprogramm, welches auf Port 80 lief. Trotzdem funktionierte es zusammen mit dem Browser.Der Port ist doch die einzige eindeutige Identifikation, wo ein Datenpaket denn nun hin muss.
netstat -a
TCP kirk:4711 www.c-plusplus.net:http HERGESTELLT TCP kirk:4712 www.c-plusplus.net:http HERGESTELLT
Beim http-Server ist es Port 80. Bei mir ist es Port 4711. Eindeutig ist die Connection, die aus zwei Endpunkten besteht, wobei jeder Endpunkt Adresse und Port hat.
-
-
Ein Browser öffnet Port 80 nicht auf localhost.
Er baut eine Verbindung auf Port 80 auf Fremdrechner auf. Auf dem Fremdrechner läuft ein Programm welches Port 80 offen hat.
Es kann nur ein Programm Port 80 offen haben und das ist eben da der Webserver.
Beide Kommunizieren dann auch nicht über Port 80 sondern verhandeln Gegenseitig die Ports aus damit Port 80 wieder frei wird.
-
zwutz schrieb:
Hat gar nichts mit der Frage zu tun.
-
Unix-Tom schrieb:
Beide Kommunizieren dann auch nicht über Port 80 sondern verhandeln Gegenseitig die Ports aus damit Port 80 wieder frei wird.
Hä??? Das klingt wie, sie quasseln ein wenig rum, entscheiden sich, statt Port 80 vielleicht mal lieber Port 5093 zu nehmen und reden dann dort weiter.
Wäre es nicht total schlau, daß der Client seinen Source-Port (irgend einen Port >=1024, der noch nicht für eine Connection mit der Zieladresse verwendet wurde) beim ersten Paket, nennen wir es mal SYN, einfach mitschickt?Die Ausgabe von netstat
TCP kirk:4711 www.c-plusplus.net:http HERGESTELLT
ist zu lesen als
TCP 192.168.0.1:4711 87.106.19.147:80 HERGESTELLT
Die Verbindung besteht aus diesen 4 Zahlen, zwei Adressen und zwei Ports.
Mit weiteren lokalen Ports kann ich weitere Verbindungen nach 87.106.19.147:80 aufmachen.
-
volkard schrieb:
Unix-Tom schrieb:
Beide Kommunizieren dann auch nicht über Port 80 sondern verhandeln Gegenseitig die Ports aus damit Port 80 wieder frei wird.
Hä??? Das klingt wie, sie quasseln ein wenig rum, entscheiden sich, statt Port 80 vielleicht mal lieber Port 5093 zu nehmen und reden dann dort weiter.
Vor ein oder zwei Jahren gab schon mal diese Diskussion. Damals hatte es Unix-Tom auch nicht verstanden.
-
volkard schrieb:
Wäre es nicht total schlau, daß der Client seinen Source-Port (irgend einen Port >=1024, der noch nicht für eine Connection mit der Zieladresse verwendet wurde) beim ersten Paket, nennen wir es mal SYN, einfach mitschickt?
Wäre klug, nur macht es TCP und UDP bei jedem Paket. Aber deine Erklärung stimmt natürlich
Grüssli
-
Unix-Tom schrieb:
Es kann nur ein Programm Port 80 offen haben und das ist eben da der Webserver.
fuer ip addressen gilt hier das gleiche wie fuer ports. es ist nicht verboten mehrere addressen auf einem rechner laufen zu haben.
tcp/ip handelt da im uebrigen ueberhaupt nichts aus. das ist hoeheren layer vorbehalten.
gruesse, mm
-
mezzo mix schrieb:
tcp/ip handelt da im uebrigen ueberhaupt nichts aus. das ist hoeheren layer vorbehalten.
TCP handelt einiges aus, MSS, Startwerte der SEQ/ACK-Nummern, usw.
Sobald es um TCP/IP geht, kommen die Halbwissenden aus ihren Löchern.
Seid lieber still.
-
Hacker 2.0 schrieb:
mezzo mix schrieb:
tcp/ip handelt da im uebrigen ueberhaupt nichts aus. das ist hoeheren layer vorbehalten.
TCP handelt einiges aus, MSS, Startwerte der SEQ/ACK-Nummern, usw.
Sobald es um TCP/IP geht, kommen die Halbwissenden aus ihren Löchern.
Seid lieber still.ich bezog mich auf auf ports, flachzange. darum ging's hier.
-
mezzo mix schrieb:
Hacker 2.0 schrieb:
mezzo mix schrieb:
tcp/ip handelt da im uebrigen ueberhaupt nichts aus. das ist hoeheren layer vorbehalten.
TCP handelt einiges aus, MSS, Startwerte der SEQ/ACK-Nummern, usw.
Sobald es um TCP/IP geht, kommen die Halbwissenden aus ihren Löchern.
Seid lieber still.ich bezog mich auf auf ports, flachzange. darum ging's hier.
Ports gehören aber zum Transportation-Layer und werden in TCP und UDP implementiert. Worauf willst du bitte hinaus?
Grüssli
-
Dravere schrieb:
mezzo mix schrieb:
Hacker 2.0 schrieb:
mezzo mix schrieb:
tcp/ip handelt da im uebrigen ueberhaupt nichts aus. das ist hoeheren layer vorbehalten.
TCP handelt einiges aus, MSS, Startwerte der SEQ/ACK-Nummern, usw.
Sobald es um TCP/IP geht, kommen die Halbwissenden aus ihren Löchern.
Seid lieber still.ich bezog mich auf auf ports, flachzange. darum ging's hier.
Ports gehören aber zum Transportation-Layer und werden in TCP und UDP implementiert. Worauf willst du bitte hinaus?
Grüssli
das tcp keine ports aushandelt. wenn du einen brief wegschickst, solltest du die addresse auch vorher kennen, ansonsten wird das nichts. du kannst dann im brief schreiben, dass du jetzt umziehst, das ist dein applikations layer. alles klar?
gruesse, mm
-
mezzo mix schrieb:
das tcp keine ports aushandelt. wenn du einen brief wegschickst, solltest du die addresse auch vorher kennen, ansonsten wird das nichts. du kannst dann im brief schreiben, dass du jetzt umziehst, das ist dein applikations layer. alles klar?
Das keine Ports ausgehandelt werden, wurde schon lange gesagt. Dass du den Zielport kennen musst, ist natürlich klar. Aber der Port, welcher auf deiner Seite als Ausgang verwendet wird, wird von TCP, bzw. UDP, definiert. Und TCP, bzw. UDP, ist für die Übermittlung von diesen Ports zuständig.
Grüssli
-
Dravere schrieb:
Das keine Ports ausgehandelt werden, wurde schon lange gesagt. Dass du den Zielport kennen musst, ist natürlich klar. Aber der Port, welcher auf deiner Seite als Ausgang verwendet wird, wird von TCP, bzw. UDP, definiert. Und TCP, bzw. UDP, ist für die Übermittlung von diesen Ports zuständig.
Grüssli
jetzt die korinthenkackerei wieder los.
ich schrieb:
mezzo mix schrieb:
tcp/ip handelt da im uebrigen ueberhaupt nichts aus. das ist hoeheren layer vorbehalten.
damit will ich sagen, wenn man ports ändern will, dann durch höhere layer.
Dravere schrieb:
Aber der Port, welcher auf deiner Seite als Ausgang verwendet wird, wird von TCP, bzw. UDP, definiert. Und TCP, bzw. UDP, ist für die Übermittlung von diesen Ports zuständig.
Grüssli
kein stück wird er durch tcp oder udp "definert", was immer du damit meinst.
um bei meinem beispiel zu bleiben, sagst du: die address wird durch die addresse definiert. falsch, ich, der absender, schreib die addresse drauf. (mr. so called application layer)tcp und udp sind mit sicherheit nicht fuer die uebermittlung dieser ports zustaendig, sondern, zurück zu meinem beispiel, der postbote. (das ist dann mr. IP)
durch nachdenken kann man da auch selber drauf kommen...
des weiteren faellt mir da noch ein:
Hacker 2.0 schrieb:
Sobald es um TCP/IP geht, kommen die Halbwissenden aus ihren Löchern.
ich erweitere das mal auf netze im allgemeinen.
gruesse, mm
-
mezzo mix schrieb:
tcp und udp sind mit sicherheit nicht fuer die uebermittlung dieser ports zustaendig, sondern, zurück zu meinem beispiel, der postbote. (das ist dann mr. IP)
Portnummern stecken in den UDP- und TCP-Headern, nicht im IP-Header.
Ich sagte Dir bereits, daß Du besser ruhig sein solltest.
-
mezzo mix schrieb:
kein stück wird er durch tcp oder udp "definert", was immer du damit meinst.
um bei meinem beispiel zu bleiben, sagst du: die address wird durch die addresse definiert. falsch, ich, der absender, schreib die addresse drauf. (mr. so called application layer)Könntest du bitte lesen, was ich geschrieben habe? Die Zieladresse und der Zielport setzt du fest. Aber es gibt auch noch einen Ausgangsport (Source-Port) und dieser setzt der Transportation-Layer fest.
mezzo mix schrieb:
tcp und udp sind mit sicherheit nicht fuer die uebermittlung dieser ports zustaendig, sondern, zurück zu meinem beispiel, der postbote. (das ist dann mr. IP)
Liest mal die RFCs zu TCP und UDP. Bzw. geht mal auf Wikipedia. Die Ports werden im Header von TCP, bzw. UDP, gespeichert. IP hat nur die Ausgangs- und Zieladdresse, speichert aber nichts über die Ports ab.
mezzo mix schrieb:
durch nachdenken kann man da auch selber drauf kommen...
Und solchen Unsinn solltest du gleich lassen. Ich habe dich in keiner Weise angegriffen, wieso machst es also du?
Grüssli
-
Hacker 2.0 schrieb:
mezzo mix schrieb:
tcp und udp sind mit sicherheit nicht fuer die uebermittlung dieser ports zustaendig, sondern, zurück zu meinem beispiel, der postbote. (das ist dann mr. IP)
Portnummern stecken in den UDP- und TCP-Headern, nicht im IP-Header.
Ich sagte Dir bereits, daß Du besser ruhig sein solltest.die uebermittlung der ports wird durch IP durchgefuehrt. kein router interessiert sich fuer deine ports. das gilt fuer dich, als auch fuer Dravere.
-
Dravere schrieb:
mezzo mix schrieb:
durch nachdenken kann man da auch selber drauf kommen...
Und solchen Unsinn solltest du gleich lassen. Ich habe dich in keiner Weise angegriffen, wieso machst es also du?
es ist unhoeflich von dir hier dein halbwissen zu verbreiten und dann auch noch stumpf auf der richtigkeit zu beharren. da werd ich halt schon mal ein bisschen ungehalten. entschuldigung dafuer.
gruesse, mm
ps: dein absenderport-argument nehme ich gerne spaeter auseinander.
-
mezzo mix schrieb:
Hacker 2.0 schrieb:
mezzo mix schrieb:
tcp und udp sind mit sicherheit nicht fuer die uebermittlung dieser ports zustaendig, sondern, zurück zu meinem beispiel, der postbote. (das ist dann mr. IP)
Portnummern stecken in den UDP- und TCP-Headern, nicht im IP-Header.
Ich sagte Dir bereits, daß Du besser ruhig sein solltest.die uebermittlung der ports wird durch IP durchgefuehrt. kein router interessiert sich fuer deine ports. das gilt fuer dich, als auch fuer Dravere.
Wenn du so argumentierst, kannst du gleich sagen, dass der Physical-Layer die Daten transportierst. Es geht doch darum, welches Packet für den Transport zuständig ist und das ist nunmal TCP/UDP. Und TCP/UDP ist auch dafür zuständig den Ausgangsport festzulegen. Wie du selber sagst, interessiert es IP einen feuchten Dreck, was weiter oben transportiert wird.
Grüssli