Test durchführen beüglich Port des Requesters

[Tom]

Hello,

bin durch Christoph S. Posting bezüglich register_globals und predefined variables gerade darauf gekommen...

'REMOTE_PORT'
Der Port, Über den der Rechner des Benutzers mit dem Webserver kommuniziert.

Wenn ich ein Post absende und klicke dann ganz schnell noch einmal auf den Submit-Button, zählen dann die Browser den Port i.d.R. hoch, oder wird derselbe nochmal benutzt?

Wie könnte ich das denn mal möglichst repräsentativ testen?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Hallo Tom,

Wenn ich ein Post absende und klicke dann ganz schnell noch einmal auf den Submit-Button, zählen dann die Browser den Port i.d.R. hoch, ...

Nein, wieso sollten sie?
Solange du mit HTTP arbeitest, wirst du (gewöhnlich) den Port 80 benutzen, der für dieses Protokoll vorgesehen ist. Wenn du den gleichen HTTP-Request zweimal abschickst (egal ob GET oder POST), dann wird er auch beide Male über Port 80 abgesetzt.

Wie könnte ich das denn mal möglichst repräsentativ testen?

Das brauchst du nicht; das HTTP-Protokoll bzw. die Default-Zuordnung von Portnummern zu den jeweiligen Protokollen sagt eigentlich schon alles.

So long,

Martin

[Tom]

Hello,

Nein, wieso sollten sie?
Solange du mit HTTP arbeitest, wirst du (gewöhnlich) den Port 80 benutzen, der für dieses Protokoll vorgesehen ist. Wenn du den gleichen HTTP-Request zweimal abschickst (egal ob GET oder POST), dann wird er auch beide Male über Port 80 abgesetzt.

Da hast Du was falsch verstanden. Nicht der Port der requested resource wird hochgezählt[1], sondern der des requesters.

Gibt es denn die Möglichkeit, dass unterschiedliche Requests einer IP (also welche, die unter unterschiedlicher Absender-Portnummer abgeschickt wurden) unterwegs zusammengefasst würden und uaf einen einzigen translated Port gelegt werden?

[1] dass da jemand auf "hochzählen" reagieren wird, war mir schon fast klar, zumindest habe
    ich damit gerechnet. Mir geht es darum: wann wird ein Request als abgeschlossen betrachtet?
    Wie kann ich da Grund reinbringen?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Henryk Plötz]

Moin,

Gibt es denn die Möglichkeit, dass unterschiedliche Requests einer IP (also welche, die unter unterschiedlicher Absender-Portnummer abgeschickt wurden) unterwegs zusammengefasst würden und uaf einen einzigen translated Port gelegt werden?

Nicht auf TCP-Ebene, aber wenn ein Proxy zwei Anfragen für den gleichen Server erhält (das ist HTTP, also spielen TCP-Verbindungen keine Rolle, also trifft die Überlegung zu, egal ob die vom gleichen Client vom gleichen Port, vom gleichen Client von einem anderen Port, oder sonstwoher kommen) darf er sie natürlich über die gleiche TCP-Verbindung abwickeln.

Wie kann ich da Grund reinbringen?

RFC 2616 lesen? Ggbf. noch 793 zum Verständnis dazu.

[Tom]

Hello,

Gibt es denn die Möglichkeit, dass unterschiedliche Requests einer IP (also welche, die unter unterschiedlicher Absender-Portnummer abgeschickt wurden) unterwegs zusammengefasst würden und uaf einen einzigen translated Port gelegt werden?

Nicht auf TCP-Ebene, aber wenn ein Proxy zwei Anfragen für den gleichen Server erhält (das ist HTTP, also spielen TCP-Verbindungen keine Rolle, also trifft die Überlegung zu, egal ob die vom gleichen Client vom gleichen Port, vom gleichen Client von einem anderen Port, oder sonstwoher kommen) darf er sie natürlich über die gleiche TCP-Verbindung abwickeln.

Klar. Dann füllt er mit seinem Request beim nächsten in der Kette also seinen Cache, und beantwortet die einzelnen Anforderungen an sich wieder getrennt. Dass zwei getrennte Aufforderungen aber genau glöeich sind und gleichzeitig eintreffen, ist sicher auch Zufall.

Hier wäre dann das Szenario möglich: Anfrage von zwei IPs und zwei Ports (zwei Hosts[1] im Netz), Anfrage von einer IP und zwei Portnummern (z.B. über einen Router), oder Anfrage von einer IP und einer Portnummer (dann wird schon weider ein Proxy im Spiel sein).

... immer ausgehend von der Überlegung, dass es sich um _zwei_ gleiche Anfragen handelt.

[1] Wobei 'Host' eben tatsächlich jedes aktive Gerät sein kann.

Wie kann ich da Grund reinbringen?

RFC 2616 lesen? Ggbf. noch 793 zum Verständnis dazu.

Das ist die passende Idee. Danke. Weitet sich eine kleine Hintergrundfrage also schon wieder in die Erkenntnis aus, dass ich gar nix nicht genau nicht weiß. Noch nicht, jedenfalls!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Hi,

mir scheint, ich hatte dich tatsächlich missverstanden - aber das liegt daran, dass du in der Fragestellung den Browser ins Spiel gebracht hast. Und der hat nun einmal überhaupt nichts damit zu tun, welcher Port für die _ausgehende_ Verbindung auf dem Client verwendet wird.

Gibt es denn die Möglichkeit, dass unterschiedliche Requests einer IP (also welche, die unter unterschiedlicher Absender-Portnummer abgeschickt wurden) unterwegs zusammengefasst würden und uaf einen einzigen translated Port gelegt werden?

Wie Henryk schon schrieb: Da gibt es anscheinend kein Schema - wir müssen die Auswahl der Portnummer hier wohl als "zufällig" betrachten.

Aber das bringt mich so langsam auf die Gegenfrage: Wozu?
Welchen Zweck verfolgst du mit deiner Überlegung?

Mir geht es darum: wann wird ein Request als abgeschlossen betrachtet?

IMHO dann, wenn alle Pakete der zugehörigen Response beim Client angekommen sind oder ein Timeout zuschlägt.
Trotzdem verstehe ich noch nicht, was du damit anfangen kannst und willst.

Schönen Tag noch,

Martin

[Tom]

Hello,

Gibt es denn die Möglichkeit, dass unterschiedliche Requests einer IP (also welche, die unter unterschiedlicher Absender-Portnummer abgeschickt wurden) unterwegs zusammengefasst würden und uaf einen einzigen translated Port gelegt werden?

Wie Henryk schon schrieb: Da gibt es anscheinend kein Schema - wir müssen die Auswahl der Portnummer hier wohl als "zufällig" betrachten.

Das ist auch nicht meine Frage. Dass die Auswahl einer Portnummer "chaotisch" erfolgen kann. weiß ich auch, habe ich auch nicht bezweifelt. Der Einfachheit halber wird sie aber i.d.R. hochgezählt, damit die Zeitdifferenz zwischen zwei Verwendungen derselben Port-Nummer möglichst maximal ist.

Aber das bringt mich so langsam auf die Gegenfrage: Wozu?
Welchen Zweck verfolgst du mit deiner Überlegung?

Zu wissen, was da noch ablaufen kann ;-)

Aus Deinen Antworten entnehme ich aber, dass Du weder weißt, was da genau abläuft, noch es jemals genauer untersucht hast. Lass mich also bitte _meinen_ Wissendurst ausleben.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Hi,

Aus Deinen Antworten entnehme ich aber, dass Du weder weißt, was da genau abläuft, noch es jemals genauer untersucht hast. Lass mich also bitte _meinen_ Wissendurst ausleben.

Sorry, wenn ich dir irgendwie auf den Schlips getreten bin! .-)
Ich wollte dich keineswegs von deinen weiteren Nachforschungen abhalten oder als Motivationsbremser dastehen. Eher im Gegenteil: Auch ich "leide" unter permanenter Neugier, und vielleicht hätte mich das, was du verfolgst, auch begeistern können. Und ich weiß, dass es noch viele Dinge zwischen 0 und 1 (oder zwischen Client und Server) gibt, die ich noch lernen möchte.
Wenn es natürlich nur um des Wissens willen ist - gut, das ist auch schon Grund genug, weiterzuforschen. :)

Viel Erfolg dabei,

Martin

[Henryk Plötz]

Moin,

'REMOTE_PORT'
Der Port, Über den der Rechner des Benutzers mit dem Webserver kommuniziert.

Wenn ich ein Post absende und klicke dann ganz schnell noch einmal auf den Submit-Button, zählen dann die Browser den Port i.d.R. hoch, oder wird derselbe nochmal benutzt?

Ein ganz klares "kommt drauf an". Der Client hat mit der Auswahl des Absendeports üblicherweise gar nichts zu tun, das macht der TCP/IP-Stack für ihn (und der muss auch nicht 'hochzählen', der kann das auch (pseudo)zufällig machen, IIRC sorgt zum Beispiel grsecurity dafür). Er könnte zwar sich einen bestimmten aussuchen, aber das macht hier ja überhaupt gar keinen Sinn. (+natürlich solche Krankheiten wie Port Adress Translation aka Masquerading)

Was der Client natürlich unter Umständen benutzt ist eine Keep-Alive-Verbindung zum Server, das ist dann aber weitgehend seine eigene Entscheidung. (Wenn der Server das zulässt und nicht mit Connection: Close antwortet, versteht sich.)

Im Übrigen ist der Client natürlich nicht immer nur ein Browser, sondern unter Umständen auch ein Proxy oder Gateway, das muß ggbf. beachtet werden.