fragen zu einem request an einen proxyserver

[Roboman93]

ich habe mir gedacht, dass es sicher möglich ist, einen einfachsten proxyserver zu programmieren.
dazu meine fragen:
kennt jemand eine Seite, in der steht, wie eine Kommunikation zwischen einem Client und dem proxyserver abgewickelt wird?

und zweitens: wie kann ich einzelne pcs, die hinter einem router sitzen und den gleichen browser haben, unterscheiden?

mfg roboman

[thewulf00]

Such das Protokoll auf einer RFC-Seite, dann siehste den genauen Ablauf.

Die einzelnen PCs unterscheidest Du anhand der IP-Nummer. Jedes Paket hat eine, die das Betriebssystem aufsteigend zählend vergibt. Ergo: Unterschiedlich Betriebssysteme, unterschiedliche IP-Nummernfolgen.

[vohopri]

Hi Roboman,

wenn die Clients hinter dem selben Router sitzen, kann der proxy nicht die IPs unterscheiden, aber er kann die remote ports unterscheiden. Der server Teil des Proxy ist zuerst listening. Wenn die Clients via Router ihn ansprechen, verwendet der Router für die Verbindung zum Proxy unterschiedliche Ports (ports des Routers sind gemeint) auf der Ausgangsseite. Der Proxy richtet dann für jedes remote Port des Routers, von dem er angesprochen wird, eine Connection ein, und spricht dann seinerseits über ein bestimmtes Ausgangs Port den Eigentlichen Server an. Die Zuordnung der Eingangs Connection des proxy zum Ausgangsport des proxy ist fix, solange diese Verbindung besteht. Anhand dieser Zuordnung kann dann die Antwort, die der proxy vom eigentlichen server bekommt an die richtige Connection zurück weiterleiten.

Eigentlich verwenden alle 3 das selbe System: der eigentliche Server, der proxy und der Router. Antworten werden immer an eine bestimmte IP:Portnummer gerichtet. Die Kombination IP:Portnummer wird auch Socket genannt, also deutsch Steckdose, DAS ist die eindeutige Verbindungskennzeichnung.

Sicher kann man einen proxy programmieren. Das ist eine haarige Sache, aber seehr interessant. Welche Sprache verwendest du? Ich verwende da Delphi.

grüsse,
Hannes

[thewulf00]

@Vohopri:
Das Problem mit den Ports ist aber, dass für jede Verbindung ein neuer Port genommen wird, d.h. je ein Port für:
- den ersten Aufruf, auf den i.d.R. ein redirect folgt,
- den zweiten Aufruf, nur HTML,
- eventuelle Header-Dateien (CSS, JavaScript) (pro Datei ein neuer Port),
- jedes Bild,
- dynamischen Content nach Laden der Seite (Flash, JavaScripte, Ajax),
...

[vohopri]

Hallo Wulf,

das ist eigentlich kein Problem, sondern das ist einfach so. Muss aber nicht immer so sein, die Connection kann auch am Leben gehalten werden und für die nächste Datei wieder verwendet werden. Da kann die Situation auch recht einfach gestalten, wenn man einen selbst geschriebenen Cient verwendet.

Aber du hast natürlich recht, es macht das Programmieren eines Proxy aufwändig, wenn er universell einsetzbar sein soll.

Grundsätzlich gibt es für die Anfrage und das Übertragen eines Webdokuments durch einen Browser über einen proxi in diesem Proxy dann mehrere eingehende connections. Auch spricht der Proxy den Server über mehrere ausgehende Ports an. Und wie oben beschrieben: Für jedes ausgehende Port, muss sich der proxy gemerkt haben, zu welcher eingehenden Connection dessen Antwort Information gehört. Durch die IP:Portnummer Kombination sind die Connections ja eindeutig identifizierbar.

Ich würde auch nicht behaupten, dass es eine einfache Sache ist. Lustig wirds dann, wenn Verbindungen auf der einen Seite abgebrochen werden, oder in einen Timeout laufen, und auf der anderen Seite noch Information kommt. Man muss sich da halt um einiges kümmern.

Welcher Inhalt - zB. Html oder Gif - auf einer Connection angefragt ist, interessiert den Proxy im Allgemeinen nicht. Er reicht nur Anfragen und Antworten durch. Wie das Gif in das Html gehört weiss ohnehin der Client.

grüsse,
Hannes

[Roboman93]

ok,danke für die antworten. ich werde das mit den ports mal ausprobieren.

mfg roboman

[Lurchi]

Hallo roboman,

für welchen zweck willst du einen Proxy bauen?

Die Kommunikation zwischen einem Client und einem Proxy ist stinknormale Socketkommunikation zwischen zwei Programmen. Lediglich der Proxy macht dann noch etwas mehr mit den Daten...
Was im Falle von HTTP und HTTPS der Proxy können muss ist in RFC1945 und RFC2616 beschrieben. Aber das ist Anwendungslogig.

Einen einfachen Port Forwarder (nichts anderes ist ein Proxy im Grunde...) kann man sich auch mit Putty bauen (unter Linux gibt es da auch noch andere Lösungen).

Zum identifizieren von Clients:
Willst du herausfinden, welcher Client gerade mit dem Ziel redet oder willst du eine Identifikation verhindern?

[Client]---
           +-----[Router]-----[Ziel]
[Client]---

Clients hinter einem nicht maskierden Router können anhand ihrer eigenen IP Adresse ermittelt werden, da diese vom Router einfach weitergeleitet werden.

Clients hinter einem maskierden Router [aka NAT oder Masquerading] kann man in der Regel nicht identifizieren. Es sei den man analysiert den Inhalt des Datenstroms und findet Spuren des orginal Rechners.
Der Router speichert hierzu sich eine Session bestehend aus Quell-IP, Quell-Port, Ziel-IP und Ziel-Port und ersetzt die Quell-Adresse und Port direkt im Header des IP Pakets durch seine eigenen Adress-Daten und sendet diese dann an das Ziel. Dieses sendet dann die Daten an den Router zurück, der jetzt einfach wieder seine IP Adresse durch die des CLients austauscht und die Daten dann einfach an den Client weiterschickt.

Wer gerade mit wem auf welchem Port spricht kann man sehr schön unter Windows mit "netstat -a" unter Linux mit mit "netstat -l" anschauen.

Mit WireShark oder tcpdump kann man sich den gesamten TCP/IP Dialog auf Paketebene sehr übersichtlich anschauen. Das ist auf Routern und Proxyservern sehr Aufschlußreich (wenn nicht gerade viel los ist).