Eben. Wir reden auch hier nicht vom Clientseitigen Port, der frei gewählt ist (wenn nicht genutzt). Hast du schonmal gesehen dass man Multithreading mit neuen connections visualisiert? Ich jedenfalls nicht. Zudem wäre des extrem ressourcen verbrauchend wenn pro connection auf port 80 eine neue socket geöffnet wird um dann auf 80 zu closen
habe da wohl eine große Sache losgetreten…
Mein Dank geht an Bizarrus, der mich auf den richtigen Weg gebracht hat… und bitte, zankt nicht…
Danke für die Korrektur, da lag ich wohl tatsächlich falsch. Muss ich mich beim Lehrer von damals mal beschweren 
Bin aber auch selbst schuld, wenn ich das gesagte nicht selbst überprüfe, was ich sonst eigentlich tue, weil ich selten irgendwelchen Aussagen vertraue. Habe ich jetzt aber überprüft (mit Wireshark) und es stimmt, die Kommunikation findet serverseitig tatsächlich weiterhin über den Port 80 statt. Der Rest stimmt aber, habe ich ebenfalls überprüft …
So habe ich dich aber verstanden, als du das hier geschrieben hast.
Klingt für mich so ziemlich nach Clientseite und dafür ist der Port 80, wie schon gesagt, irrelevant. Zudem ist auch der eingehende Port nie gesperrt, man wird nur keine Verbindung aufbauen können, wenn kein Dienst drauf lauscht. Dass die Firewall im DSL-Router standardmäßig da nix durchlässt, hat mit dem Clientrechner selbst ja nichts zu tun. Das ist eine externe Station und damit hat der Client direkt nichts zu tun. Du könntest deinen Rechner ja auch direkt an die Internetleitung klemmen, dann wäre überhaupt alles offen. Aber wenn du das meintest, dann sag ich mal „Sorry, du hast recht“. Aber für mich ist das eher ein „Wir hauen mal einfach alles in einen Topf und rühren alles um“.
pro connection auf port 80 eine neue socket geöffnet
Das hier ist übrigens in der Tat der Fall, denn es muss in jedem Fall für eine neue Verbindung ein neuer Socket bereitgestellt werden. Ein Socket ist nicht, wie viele sich das versuchen vorzustellen, eine Art Tunnel oder sowas. Ein Socket ist das hier: „IP:Port“ also z.B. 123.123.123.123:1337. Sobald von diesem Socket aus ein Verbindungsaufbau mit einem Server versucht wird, hat der Server es mit einem neuen Socket zu tun muss dafür entsprechend eine Verbindung öffnen. Das alles ist heute durch die heutigen Sprachen und durch das OS sehr schön weggekapselt, so dass man dann Klassen wie Socket hat, mit denen man solche Verbindungen sehr leicht und schnell aufbauen kann. Selbst wenn man sich sowas als eine Art Tunnel vorstellen will, so hat man für jeden Client, der eine Verbindung aufbaut, eben einen eigenen Tunnel und nicht einen für alle. Das ginge ja auch gar nicht, da jeder Client einen anderen Endpunkt darstellt. Wie soll man das mit der selben Verbindung regeln?
habe da wohl eine große Sache losgetreten…
Mein Dank geht an Bizarrus, der mich auf den richtigen Weg gebracht hat… und bitte, zankt nicht…
Ach wer zankt denn hier Ist doch alles gut, nur eine nette Diskussion und am Abend geht man wieder nen Bier trinken. So ist das eben
Muss ich mich beim Lehrer von damals mal beschweren Bin aber auch selbst schuld
Kann es sein, dass Ihr damals über FTP-Connections gesprochen habt? Da ist es nämlich so, dass ein zweiter Kanal aufgemacht wird.
Ne, es ging dabei um den allgemeinen Ablauf bei einem Verbindungsaufbau und die Bedeutung von Ports, da diese ja für jegliche Netzwerkkommunikation benötigt werden und nicht nur um Dienste anzubieten. Um ein spezielles Protokoll hat es sich dabei nicht gehandelt, kann mich jedenfalls nicht dran erinnern. Es ging dabei nicht um eine zweite Verbindung, sondern er hat es wirklich so erklärt, dass der Server die Verbindung über einen anderen Port fortführt, um den Dienst-Port wieder freizugeben bzw. wieder drauf lauschen zu können. Hat jetzt auch nix Multi-Threading zu tun oder so.