Also ersten ist das TCP-Packet, oben TCP-Teil genannt in dem IP-Packet, oben IP-Teil genannt, verpackt und es folgt nicht dem TCP-Packet ein IP-Packet (ein TCP-Packet wirst du ohne das einpacken in ein IP-Packet auch schwer routen können
). Im TCP-Packet ist dann wiederum das HTTP-Packet verpackt und im HTTP-Packet der eigentliche Content (HTML-Sourcecode, und was man halt alles so über HTTP ziehen kann also eigentlich alles...). Soviel grob zur Packettechnischen Hirachie.
Wenn du nun einen HTTP-Proxy benutzt, Cachingfunktionen (das heisst der Proxy liefert nicht das eigentliche Original vom Server sondern zwischengespeicherte Daten, u. A. aus Performance Gründen) lass ich jetzt mal weg, zu mal er Definitionsmässig nicht zu einem HTTP-Proxy dazu gehören muss (aber meisst in einem Atemzug genannt wird...), geschieht folgendes:
Dein Client (der Netzwerk technische Teil in deinem Browser oder Downloadmanager z. B.) öffnet eine TCP Verbindung zu dem Proxy. Die TCP Packete werden per IP da hingeroutet übrigens (deshalb das Verpacken), steht die Verbindung sendet der Client weiter TCP-Packete in die er Stücke weise das HTTP-Packet reinbaut, das den Request enthält. Der Proxy nimmt diesen Request an und untersucht ihn. Anhand der Header-Daten des HTTP-Packetes des Requests kann er dann, sofern alles stimmt den eigentlichen "ursprünglichen" Server ermitteln und macht seinerseits die selbe Prozedur (TCP-Verbindung erstellen, Request senden, ) noch mal und verhält sich also wie ein Client zu dem eigentlichen Server. Wenn er die Antwort des Servers empfangen hat kappt der Server die TCP-Verbindung und der Proxy schickt die Response wieder zu deinem Browser und kappt anschliessend nun diese IP-Verbindung, er verhält sich deinem Browser gegenüber also wie ein Server (ist n kleiner Hacken drinne, die Request-Line muss bei ner Anfrage bei nem Proxy anders sein, weil der den kompletten URL braucht nicht nur den Pfad wie ein ursprünglicher Server und und es gibt u. U. andere Header-Direktive die gesetzt sein müssen oder nicht gesetzt sein dürfen / sollten, aber das sind Details...).
Also haben wir folgendes Schema:
Code:
uClient <--Netzwerkverbindung(uc-ps)--> pServer|pClient <--Netzwerkverbindung(pc-us)--> uServer
Es sind also zwei völlig verschiedene Netzwerkverbindungen die bei so einer Requestline zustande kommen und da die IP-Adresse in den IP-Packeten (man höre und staune...) notiert ist wird der ursprüngliche Client bei einer solchen Aktion nichts von der IP-Adresse des ursprünglichen Servers zu Gesicht bekommen (zumindest nicht in den IP-Headern an anderer stelle kann es vorkommen dazu gleich mehr...) und der ursrüngliche Server nicht die IP-Adresse des Servers, weil der Proxy alles bis auf das HTTP-Packet auspackt das interpretiert uns für seinen Request sogar ein neues kreieren muss, er muss also sein HTTP-Packet mit dem Request auch wieder einpacken und generier so völlig neue TCP- und dann IP-Packete, in denen er als seine Adresse als Source angibt (sonst würds auch wenig bringen weil die Antwort des Servers sonst irgendwo hingeht wo sie nicht erwartet wird und niemand wird sie je sehen (im Regelfall, Aussnahmen werden nicht bhandelt um die Uhrzeit... *g*). Und zum Client wird er natürlich auch als Source-Adresse seine angeben, der Proxy, weil sonst kommt von dem ja nichts an (TCP erfordert das mehrmalige hin und hersenden (aber nicht des gleichen!) von TCP-Packeten, auch wenn der eigenliche Content nur in eine Richtung transferiert wird um zu wissen von wem was kommt muss deshalb in den IP-Packeten die Absender Adresse vermerkt sein...). Auf IP Ebene wissen also der Client nur von dem Proxy und der Server auch nur von dem Proxy, der Proxy weiss von beiden...
Nu gibt es aber natürlich Möglichkeiten wie diese Unsichtbarkeit brechen kann (auf anderer Ebene nämlich). Erstens weiss der Client eh von dem Server, er gibt dem Proxy ja die Adresse, zwar meisst in Form von einem Hostnamen in einem URL, aber man könnte so auf der Clientseite natürlich auch die IP-Adresse des Servers bekommen...
Und der zweite Punkt liegt am Proxy. Zum einem können die Dinger können natürlich loggen was sie so treiben und einfach aufzeichen welche Requests von wem sie an wen geschickt haben und wer sie intiert hat (der Proxy kennt ja beide, auch IP-Adressmässig), so liesse sich im Nachhinein dursch studieren der Logdatei wieder auslesen wer wo "gesurft" ist. Andererseits kann der Proxy die HTTP-Packete ja gestalten wie er will (wenn er funktionier hällt er sich an Regeln, aber theorethisch kann er auch Rotz hin und her schicken...) und auch zusätliche Header Einträge in diese einfügen, wo bei dem X-Forwarded (X- hat sich so als Präfix eigebürgert, für nicht offizielle Header oder Format-Direktiven in Text basierten Protokollen, Forwarded sollte bei genug englisch Kenntnissen den Sinn erkennen lassen, es sei aber gesagt, das man auch theorethisch X-Weitergleitet oder X-Hier-Haste oder etwas in der Art verwenden könnte, es ist ja kein offiziell festgelegter Heade!) Header wären, in diesen kann der Proxy natürlich eintragen was er will, auch die IP Adresse der jeweiligen Ursrungs Instanzen, des Server, bzw des Clients. Die IP-Adresse ist dann also HTTP-Pakete verborgen. Diese spielt zwar für das Routing keine Rolle (könnte auch ne falsch drin stehen, wenn die richtige im IP-Header ist, dann kommt trotzdem alles ordnungsgemäss an...) kann also auch nicht von der IP Facility des Client bzw. des Servers geloggt werden, aber natürlich von dem Part der Software, die für HTTP zuständig ist. Und aus ist mit der Anonymität...
Übrigens @Damein, dieser Header dient sicher nicht dazu, das der eigentlich Server die Antwort dann direkt an den eigentlichen Client schickt. Das geht nicht (TCP mässig), ausser auf dem Clientrechner wartet ein Server auf die Antwort des eigentlichen Servers, was aber nicht Bestandteil von HTTP ist, oder der Server würde seine IP-Adresse spoofen (inkl. das Erraten der richtigen Sequenz...) und sich als der Proxy ausgeben (der dann am Ende mit ner halb offenen Verbindung in die Röhre guckt...), was auch nicht in HTTP vorgesehen ist...
Literatur:
http://www.ietf.org/rfc/rfc0791.txt (IP)
http://www.ietf.org/rfc/rfc0793.txt (TCP)
http://www.ietf.org/rfc/rfc1945.txt (HTTP/1.0)
http://www.ietf.org/rfc/rfc2616.txt (HTTP/1.1)
![[HaBo]](/styles/default/logoklein.png){kind=small}
