DE69919965T2

DE69919965T2 - Methode und Proxy Umleiteinrichtung zum transparenten Verweisen von Anfragen nach Web-Objekten auf Proxycaches

Info

Publication number: DE69919965T2
Application number: DE69919965T
Authority: DE
Inventors: Ariel Berkeley Heights Cohen; Sampath Bridgewater Rangarajan; Navjot Morristown Singh
Original assignee: Lucent Technologies Inc
Current assignee: Nokia of America Corp
Priority date: 1998-12-16
Filing date: 1999-12-07
Publication date: 2005-09-15
Anticipated expiration: 2019-12-08
Also published as: US6389462B1; DE69919965D1; EP1011244B1; EP1011244A2; EP1011244A3; CA2288488A1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft paketvermittelte Computernetzwerke und insbesondere ein Verfahren und eine Vorrichtung in einem solchen Netzwerk zum transparenten Abfangen von Klient-Web-Anforderungen und zum Umleiten dieser zu Proxy-Caches.
Proxy-Cache-Speicherung dient zur Zeit zum Verringern sowohl der Latenz des Objektabrufens als auch des Verkehrs auf dem Internet-Backbone. Wenn ein Proxy-Cache eine Kopie eines Objekts von einem Ursprungsserver gespeichert hat, die von einem Klient angefordert wurde, wird das angeforderte Objekt bekanntlich nicht von dem Ursprungsserver, sondern von dem Proxy-Cache aus geliefert. Dadurch wird es deshalb unnötig, die Anforderung über ein großflächiges Netzwerk, wie zum Beispiel das Internet, zu dem Ursprungsserver zu senden, in dem das Orginalobjekt gespeichert ist, und die antwortende Übertragung einer Kopie des angeforderten Objekts zurück über das Netzwerk zu dem anfordernden Klient durchzuführen.
Das Lenken einer Anforderung von einem Klient zu einem Proxy-Cache zur Bestimmung, ob eine angeforderte Kopie eines Objekts in dem Cache gespeichert ist, kann entweder transparent oder nichttransparent für den Klient erreicht werden. Die nichttransparente Umlenkung wird durch das Browser-Programm des Klient erreicht, das so konfiguriert ist, daß es alle Objektanforderungen zu einem gekennzeichneten Proxy-Cache an einer spezifizierten Adresse sendet. Im allgemeinen kann ein Browser so konfiguriert werden, daß er alle seine Klient-Anforderungen zu einem gekennzeichneten Proxy-Cache sendet, wenn der Klient mit einem lokalen Netzwerk (LAN) verbunden ist oder sich auf einem Intranet hinter einer Firewall befindet, wo sich ein diesem LAN oder Intranet zugeordneter Proxy-Cache befindet. Wenn Klients von einem großen Internet-Dienstanbieter (ISP) versorgt werden, ist es jedoch vom Standpunkt des ISPs aus gesehen nicht vorteilhaft, es seinen Teilnehmern zu erlauben, ihre Browser auf einen dem ISP zugeordneten spezifischen Proxy-Cache einzustellen. Ein großer ISP hat wahrscheinlich viele Proxy-Caches an mehreren Orten und wird somit wünschen, die Kontrolle darüber zu behalten, an welchen seiner mehreren bestimmten Proxy-Caches eine Klient-Anforderung gerichtet wird. Wenn ein Proxy-Cache, dessen Adresse statisch in dem Browser eines Klient gesetzt ist, funktionsunfähig wird, bleiben außerdem alle Klient-Anforderungen erfolglos.
Vom Standpunkt eines ISPs aus gesehen ist es deshalb in bezug auf Latenz und Minimierung von Verkehr auf und aus dem Netzwerk mehr wünschenswert, transparent eine Web-Anforderung eines Klient abzufangen und diese zu einem seiner funktionsfähigen Proxy-Caches zu senden, um zu bestimmen, ob dort eine Kopie des angeforderten Objekts gespeichert ist. Wenn es sich dann zeigt, daß eine Kopie des angeforderten Objekts in diesem Proxy-Cache gespeichert ist, wird eine Kopie des Objekts zu dem Klient gesendet, der sich nicht darüber bewußt ist, daß er ein Objekt von dem Proxy-Cache zugestellt bekommen hat, statt von dem Ursprungsserver, an den die Anforderung gerichtet war. Wenn der Proxy-Cache keine Kopie des angeforderten Objekts hält, dann wird eine separate Verbindung zwischen dem Proxy-Cache und dem Ursprungsserver hergestellt, um eine Kopie des Objekts zu erhalten, die, wenn sie an den Proxy zurückgegeben wird, über die zwischen dem Klient und dem Proxy hergestellte Verbindung zu dem Klient gesendet wird.
Wenn ein Klient eine URL des Objekts, von dem er eine Kopie anfordert, spezifiziert, wird ein DNS-Nachschlagen (Domain Name Server) durchgeführt, um aus der URL eine IP-Adresse des Ursprungsservers, der das angeforderte Objekt besitzt, zu bestimmen. Als Ergebnis dieses Nachschlagens wird dem Klient eine IP-Adresse von einem von möglicherweise mehreren im wesentlichen äquivalenten Servern zurückgegeben, die dieses Objekt enthalten.
Der Klient stellt dann unter Verwendung eines dreiseitigen Handshake-Mechanismus eine TCP-Verbindung mit diesem Server her. An jedem Ende wird eine solche Verbindung durch eine Portnummer und eine IP-Adresse bestimmt. Zuerst wird ein SYN-Paket von dem Klient zu diesem Ursprungsserver gesendet, wobei die Ziel-IP-Adresse, die in dem Paket spezifiziert ist, die durch DNS bestimmte IP-Adresse des Ursprungsservers ist, und die Zielportnummer für eine HTTP-Anforderung ist gewöhnlich Port 80. Die Quellen-IP-Adresse und die Portnummer des Pakets sind die IP-Adresse und die Portnummer, die dem Klient zugeordnet sind. Die Klient-IP-Adresse wird im allgemeinen durch einen ISP dem Klient zugewiesen und die Klient-Portnummer wird durch den Protokollstapel in dem Klient dynamisch zugewiesen. Der Ursprungsserver antwortet dem Klient dann mit einem ACK-SYN-Paket, in dem die Ziel-IP-Adresse und der Zielport die IP-Adresse und Portnummer des Klient sind und die Quellen-IP-Adresse und Portnummer des Pakets die IP-Adresse des Servers und die Portnummer des Servers sind, wobei letztere im allgemeinen Port 80 ist. Nach dem Empfang des ACK-SYN-Pakets sendet der Klient ein oder mehrere Pakete zu dem Ursprungsserver, wobei die Pakete eine GET-Anforderung enthalten. Die GET-Anforderung enthält eine vollständige URL, die diesem Server das spezifische Objekt in dem Ursprungsserverort identifiziert von dem der Klient eine Kopie möchte. Im Gegensatz zu einer absoluten URL, die sowohl Ortsinformationen (z.B. www.yahoo.com) als auch Objektinformationen (z.B. index.html) enthält, identifiziert eine vollständige URL nur das konkrete Objekt (z.B. index.html), das angefordert wird, da das Paket bzw. die Pakete, das bzw. die die GET-Anforderung enthalten, mittels der Zieladresse des Pakets bzw. der Pakete zu dem richtigen Ursprungsserverort gesendet wird bzw. werden.
Wenn ein Browser so konfiguriert ist, daß er nicht transparent alle Anforderungen zu einem Proxy sendet, wird durch den Browser eine GET-Anforderung formuliert, die die absolute URL des angeforderten Objekts enthält. Diese absolute URL wird dann von dem Proxy zur Herstellung einer separaten TCP-Verbindung mit dem Ursprungsserver verwendet, wenn der Proxy keine Kopie des angeforderten Objekts in seinem Cache aufweist. Der Proxy benötigt die absolute URL, da die Zieladresse der Pakete zu dem Proxy durch den Browser auf die IP-Adresse des Proxys gesetzt wird, anstelle der IP-Adresse des Ursprungsservers. Um zu bestimmen, ob er das Objekt in seinem Cache besitzt, und um eine Verbindung mit dem Ursprungsserver herzustellen, wenn dies nicht der Fall ist, benötigt der Proxy also die absolute URL des Ursprungsservers in der GET-Anforderung.
Wenn Anforderungen transparent zu einem Proxy-Cache gelenkt werden, ist dem Klient-Browser jedoch nicht bewußt, daß die Anforderung zu dem Proxy gelenkt wird und möglicherweise aus dem Cache erfüllt wird. Statt dessen muß der Browser des Klient „denken", daß er mit dem Ursprungsserver verbunden ist, an den sein SYN und das Paket bzw. die Pakete mit der GET-Anforderung adressiert sind. Eine solche Ursprungsserver-IP-Adresse wird durch den Browser durch ein DNS-Nachschlagen bestimmt. Außerdem müssen die Quellenadresse des ACK-SYN-Pakets und der Pakete mit dem angeforderten Objekt diese selbe Ursprungsserver-IP-Adresse sein, oder sie werden von dem Browser nicht als die Antwortpakete auf das SYN-Paket und die Anforderung des Objekts erkannt. Um Objektanforderungen transparent zu einem Proxy-Cache zu senden, muß ein Mechanismus entlang dem Paketübertragungsweg zum Abfangen eines anfänglichen von einem Browser gesendeten SYN-Pakets und zum Umlenken dieses zu dem Proxy-Cache, um eine TCP-Verbindung herzustellen, eingerichtet sein. Der Proxy-Cache muß sich dann beim Senden des ACK-SYN-Pakets zurück zu dem Klient als der Ursprungsserver ausgeben, indem er die IP-Adresse des Ursprungsservers und die Portnummer als die Quellenadresse dieses Pakets benutzt. Außerdem muß das nachfolgende Paket bzw. müssen die nachfolgenden Pakete mit einer GET-Anforderung zu dem Proxy-Cache umgelenkt und die Anforderung entweder von dem Cache oder über eine separate TCP-Verbindung von dem Proxy zu dem Ursprungsserver erfüllt werden. In jedem Fall muß die zu dem Klient zurückgesendete Quellenadresse von Paketen die IP-Adresse und Portnummer des Ursprungsservers sein, an den die von dem Klient gesendeten Pakete adressiert waren.
Damit einer Anforderung eines Objekts zugeordnete Pakete zu einem irgendwo in dem Netzwerk verbundenen Proxy-Cache umgelenkt werden können, „schaut" eine Vermittlung der Schicht 4 (L4) auf dem Paketweg auf die Portnummer einer Zieladresse eines SYN-Anforderungspakets. Da HTTP-Verbindungsanforderungen im allgemeinen an den Port 80 eines Ursprungssservers gerichtet sind, lenkt die L4-Vermittlung transparent alle Pakete mit einer Portnummer von 80 in der Zieladresse um. Das SYN-Paket wird somit zu einem gewählten Proxy-Cache gesendet. Damit der Proxy-Cache ordnungsgemäß dem Klient antworten kann, muß er, wie bereits erwähnt, die absolute URL des angeforderten Objekts kennen, und zu dem Klient zurückgegebene Pakete müssen sich als von dem Ursprungsserver kommend ausgeben. Im Gegensatz zu dem zuvor beschriebenen nichttransparenten Cache-Verfahren, bei dem der Browser eine GET-Anforderung mit der absoluten URL formuliert, muß für eine transparente Cache-Speicherung die absolute URL auf irgendeine Weise dem Proxy-Cache zugeführt werden, damit der Proxy bestimmen kann, ob er tatsächlich das angeforderte Objekt in seinem Cache besitzt, oder ob er eine separate TCP-Verbindung mit dem Ursprungsserver herstellen muß, um das Objekt anzufordern. Wenn ein oder mehrere Caches direkt mit der L4-Vermittlung verbunden sind, wählt die Vermittlung im Stand der Technik einen der Caches und leitet die Pakete transparent zu diesem Proxy weiter, ohne die Quellen- oder Zieladresse der Pakete zu modifizieren. Der in einem bereitwilligen TDP-Modus arbeitende Proxy nimmt alle ankommenden Pakete ungeachtet ihrer Zieladresse an. Der Proxy, der dann das SYN-Paket mit der Zieladresse des Ursprungsservers und der Quellenadresse des Klient empfängt, kann auf das SYN-Paket mit einem ACK-SYN-Paket antworten. Dieses ACK-SYN-Paket enthält die Adresse des Klient als Zieladresse und eine Quellenadresse, die sich für die Ursprungsserveradresse ausgibt. Dieses Paket wird durch die L4-Vermittlung über die TCP-Verbindung auf das Netzwerk zurück zum Klient transportiert. Das nachfolgende Paket bzw. die nachfolgenden Pakete mit der GET-Anforderung von dem Klient wird bzw. werden durch die L4-Vermittlung zu dem direkt verbundenen Proxy umgelenkt. Da das GET-Paket bzw. die GET-Pakete nur die vollständige URL enthalten, muß der Proxy die absolute URL formulieren, um zu bestimmen ob er das angeforderte Objekt in seinem Cache besitzt oder ob er eine separate TCP-Verbindung zu dem Ursprungsserver herstellen muß. Der Proxy bildet die absolute URL durch Voranstellen der vollständigen URL in der GET-Anforderung an die IP-Adresse des Ursprungsservers in der Zieladresse des Pakets. Der Proxy kann dann bestimmen, ob er das Objekt besitzt, und, wenn dies nicht der Fall ist, eine TCP-Verbindung zu dieser absoluten Adresse herstellen. Wenn dieser bestimmte Ursprungsserver an dieser IP-Adresse nicht funktionsfähig sein sollte, kann der Proxy der vollständigen URL in der GET-Anforderung als Alternative den logischen Namen des in dem HOST-Feld des Pakets bzw. der Pakete mit der GET-Anforderung angegebenen Orts voranstellen.
Wenn im Stand der Technik der Proxy-Cache nicht direkt mit der L4-Vermittlung verbunden ist, dann muß die L4-Vermittlung eine Netzwerkadressenübersetzung (NAT) und eine Portadressenübersetzung (PAT) an diesen an den Port 80 eines Ursprungsservers gerichteten Paketen durchführen. Wenn die L4-Vermittlung ein SYN-Paket zum Einleiten einer TCP-Verbindung von einem Klient zu einem Ursprungsserver empfängt, übersetzt sie genauer gesagt die Zieladresse des Pakets aus der IP-Adresse und Portnummer des Ursprungsservers in die IP-Adresse und Portnummer eines gewählten Proxy-Cache. Ferner übersetzt die Vermittlung die Quellenadresse des Pakets aus der IP-Adresse und Portnummer des Klient in ihre eigene IP-Adresse und eine Portnummer. Wenn der Proxy mit einem ACK-SYN-Paket antwortet, antwortet er deshalb der L4-Vermittlung, wo eine NAT die Ziel-IP-Adresse aus der IP-Adresse der L4-Vermittlung in die IP-Adresse des Klient übersetzt, und übersetzt die Quellen-IP-Adresse aus der IP-Adresse des Proxy in die IP-Adresse des Ursprungsservers. Außerdem übersetzt eine PAT die Portnummer in der Zieladresse aus der der L4-Vermittlung in die des Klient und übersetzt die Portnummer in der Quellenadresse aus der des Proxy in die des Ursprungsservers (gewöhnlich 80). Wenn der Klient ein ACK-Paket und dann das Paket bzw. die Pakete mit der GET-Anforderung zu dem Ursprungsserver sendet, führt die L4-Vermittlung wieder eine NAT durch, wobei die Ziel-IP-Adresse in die IP-Adresse des Proxy übersetzt wird. Wenn das Paket bzw. die Pakete mit der GET-Anforderung durch den Proxy empfangen wird bzw. werden, kennt er also nicht die IP-Adresse des Ursprungsservers wie bei der oben beschriebenen direkt verbundenen Proxyanordnung. Der Proxy muß deshalb den logischen Namen in dem HOST-Feld betrachten und ein DNS-Nachschlagen durchführen, um die IP-Adresse dieses Orts zu bestimmen. Der Proxy verwendet diese IP-Adresse in Kombination mit der vollständigen URL in der GET-Anforderung dann zur Bildung einer absoluten URL, aus der er bestimmt, ob er das angeforderte Objekt in seinem Cache besitzt. Wenn nicht, wird eine separate TCP-Verbindung von dem Proxy zu dieser absoluten URL hergestellt, um dieses Objekt abzurufen, das an den Proxy zurückgegeben wird. Gleichgültig, ob das Objekt in dem Proxy-Cache gefunden oder über die separate Verbindung von dem Ursprungsserver abgerufen wird, wird es zu der L4-Vermittlung zurück weitergeleitet, in der eine NAT und eine PAT durchgeführt werden, um die Zieladresse in die des Klient und um die Quellenadresse in den bestimmten Ursprungsserver, an den die Anforderung des Klient gerichtet war, zu übersetzen. Es ist zu beachten, daß die Quellenadresse des Ursprungsservers, die erhalten wird, wenn der Browser des Klient ein DNS-Nachschlagen unter Verwendung der absoluten URL des Ursprungsservers einleitet, möglicherweise nicht dieselbe IP-Adresse ist, die erhalten wird, wenn der Proxy ein DNS-Nachschlagen unter Verwendung der Kombination der Orts-URL in dem HOST-Feld und der vollständigen URL in der GET-Anforderung durchführt.
Die oben beschriebenen Techniken zur Durchführung einer transparenten Proxi-Cache-Speicherung haben mehrere Nachteile. Erstens ist die Verwendung eines HOST-Feldes zum Spezifizieren eines logischen Namens eines Ursprungsservers zur Zeit nicht in den derzeit verwendeten HTTP1.0-Standards enthalten. Folglich ist möglicherweise in dem Paket bzw. den Paketen, das bzw. die eine GET-Anforderung enthalten, kein HOST-Feld vorhanden. Wenn, wie oben beschrieben, die Informationen in dem HOST-Feld notwendig für die Bildung einer absoluten URL sind, um zu bestimmten, ob der Proxy-Cache das angeforderte Objekt besitzt, und um, wenn dies nicht der Fall ist, eine Verbindung zu einem Ursprungsserver von dem Proxy herzustellen, führt das Fehlen des HOST-Feldes zu einer unerfüllten Anforderung. Zweitens ist es bei den vorbekannten Techniken erforderlich, daß der Proxy-Cache die Funktion des Bildens einer absoluten URL aus den Informationen in dem HOST-Feld und in dem Paket bzw. den Paketen mit der GET-Anforderung durchführt. Standard-Proxy-Caches, die erwarten, daß der Browser des Klient die absolute URL produziert, können also nicht verwendet werden. Es ist eine Methologie für transparentes Proxy-Cache-Speichern erwünscht, die sowohl dem Klient als auch dem Proxy transparent ist, um eine Modifikation des Programms, das Proxy-Cache-Operationen steuert, zu vermeiden. An jeder beliebigen Stelle in dem Netzwerk könnten somit Standard-Proxy-Caches verwendet werden, ohne daß eine spezielle Implementierung notwendig ist.
Die oben beschriebenen vorbekannten Techniken haben sogar weitere Nachteile in bezug auf durch die HTTP1.1 Standards definierten persistenten Verbindungen. Gemäß diesen Standards ermöglicht es eine persistente Verbindung, einem Klient, mehrere GET-Anforderungen über dieselbe TCP-Verbindung zu senden, nachdem diese Verbindung zwischen zwei Endpunkten hergestellt wurde. Wenn ein vorbekannter transparenter Proxy-Cache auf der Verbindung zwischengeschaltet ist, kann ein Klient „denken", daß er eine persistente Verbindung mit dem durch das DNS-Nachschlagen bestimmten spezifischen Ursprungsserver hergestellt hat. In der Realität wird die Verbindung jedoch transparent durch die L4-Vermittlung zu einem Proxi-Cache umgelenkt. Als Reaktion auf ein DNS-Nachschlagen unter Verwendung des logischen Namens in dem ROST-Feld kann der Proxi-Cache zu einem äquivalenten Ursprungsserver an einer anderen IP-Adresse gelenkt werden. Während jede nachfolgende GET-Anforderung durch den Proxy von dem Klient in der dafür gehaltenen persistenten Verbindung des Klient empfangen wird, kann weiterhin jedes antwortende DNS-Nachschlagen auf den logischen Namen eine Verbindung zu sogar noch einer anderen IP-Adresse eines äquivalenten Ursprungsservers lenken. Folglich gehen die Vorteile einer transaktionsorientierten persistenten Verbindung, bei der ein Server über die gesamte Verbindung hinweg Zustandsinformationen aufrechterhalten kann, verloren. Es ist eine Methodologie wünschenswert, die Persistenz zu demselben Ursprungsserver, zu dem der Browser von Klients gelenkt wird, oder zu einem selben äquivalenten Ursprungsserver während der gesamten Dauer der persistenten Verbindung aufrechterhält.
Aus ARROWPOINT COMMUNICATIONS: „Content Smart Cache Switching" WHITE PAPER, [online], 16.11.1998 (1998-11-16), Seiten 1-12, XP002194928, abgerufen aus dem Internet: http://www.knowware.co.uk/ArrowPoint/pdf/Content_Smart_ Cache_Switching.pdf, ist eine Vermittlung bekannt, die Vermittlung auf höherer Ebene verwendet, um eine Anforderung auf der Basis der URL des angeforderten Inhalts zu einem Proxy-Cache to transferieren.
Kurze Darstellung der Erfindung
Ein Verfahren, ein Proxy-Umlenker, ein computerlesbares Medium und ein Computerprogrammprodukt gemäß der Erfindung werden in den unabhängigen Ansprüchen definiert. Bestimmte Formen werden in den abhängigen Ansprüchen definiert.
Die vorbekannten Techniken für transparentes Proxy-Cache-Speichern zugeordneten Probleme werden durch die vorliegende Erfindung beseitigt. Gemäß der vorliegenden Erfindung wird eine Vermittlungsentität, wie zum Beispiel die L4-Vermittlung (die im folgenden als Proxy-Umlenker bezeichnet wird), durch die die Pakete fließen, mit den Funktionalitäten auf der IP-Ebene ausgestattet, die notwendig sind, um die vollständige URL in jeder durch einen Klient gesendeten GET-Anforderung in eine entsprechende absolute URL zu transformieren. Genauer gesagt werden die IP-Adresse, die in dem Zielfeld in dem IP-Kopfteil des Pakets bzw. der Pakete von dem Klient mit der GET-Anforderung gefunden wird, als Präfix durch den Proxy-Umlenker zu der vollständigen URL in der GET-Anforderung hinzugefügt. Folglich wird die vollständige URL in der GET-Anforderung modifiziert, um eine absolute URL zu bilden, die, wenn sie von dem Proxy-Cache empfangen wird, direkt dazu verwendet wird, zu bestimmen, ob das angeforderte Objekt in den Cache gespeichert ist, und, wenn dies nicht der Fall ist, um eine separate TCP-Verbindung zu dem Ursprungsserver herzustellen. Die von dem Proxy empfangene GET-Anforderung ist also dem äquivalent, das er zu empfangen erwarten würde, wenn er im nichttransparenten Modus arbeiten würde. Wenn eine persistente Verbindung hergestellt wird, weist vorteilhafterweise jede nachfolgende GET-Anforderung denselben IP-Adressenpräfix auf, der durch das anfängliche DNS-Nachschlagen durch den Klient bestimmt wird.
Durch Modifizieren der GET-Anforderung in dem Proxyumlenker, sodaß sie die Zieladresse des Ursprungsservers enthält, wird die Anzahl von Byte auf der IP-Ebene in dem Paket, das die resultierende absolute Adresse enthält, um die Anzahl von Byte in dem Präfix vergrößert. In dem Kopfteil in jedem Paket befindet sich eine Sequenznummer (seq), die eine Angabe der Position der ersten Bytezahl in dem Nutzsignal liefert. Wenn die IP-Adresse einem Paket hinzugefügt wird, muß also die Sequenznummer jedes der nachfolgenden Pakete um den Zählwert der zusätzlichen Byte erhöht werden. Ferner muß eine Bestätigungssequenznummer (ack_seq) in dem Kopfteil an den von dem Proxy oder dem Ursprungsserver zurückgegebenen Paketen, die logisch dem Empfang des GET-Pakets bzw. der GET-Pakete in dem Ursprungsserver folgen, durch den Proxyumlenker erniedrigt werden, bevor sie zu dem Klient weitergeleitet werden, um zu vermeiden, den Klient in Bezug darauf, wie die Sequenzennummer des nächsten Byte, das er sendet, lauten soll, zu verwirren. Wenn die von dem Klient gesendete GET-Anforderung mehr als ein TCP-Segment umfaßt, dann werden weiterhin die zusätzlichen Byte in dem ersten der Segmente, die durch die zusätzlichen Byte, die der URL hinzugefügt werden, verursacht werden, in das zweite Segment verschoben, und die nun resultierenden zusätzlichen Byte in dem zweiten Segment werden in das dritte Segment verschoben usw., bis zum letzten der Segmente. Um die Notwendigkeit des Anforderns des Hinzufügens eines zusätzlichen Segments zu der GET-Anforderung, um die zusätzlichen Byte unterzubringen, zu verhindern, wird der die GET-Anforderung sendende Klient dazu getäuscht, Segmente zu senden, deren maximale Größe kleiner ist, als das, was tatsächlich von dem Proxy empfangen werden kann, wie durch ein Feld mit der maximalen Segmentgröße (MSS) in Paketen aus dem Proxy angegeben wird. Nach dem Empfang des ACK-SYN-Pakets von dem Proxy verringert der Proxyumlenker den aus dem Proxy empfangenen MSS-Parameter um den Betrag der Anzahl von Byte, die zu der GET-Anforderung hinzugefügt werden, bevor dieser Parameter zum Klient weitergeleitet wird. Wenn der Klient das nächste Mal eine GET-Anforderung sendet, wird also jedes Segment auf die reduzierte MSS begrenzt, wodurch sichergestellt wird, daß die Segmentgröße eines letzten Segments in einer GET-Anforderung, nachdem der IP-Adresse durch den Proxy-Umlenker ein Präfix vorangestellt wurde, um die absolute URL zu bilden (gleichgültig, ob die GET-Anforderung ein oder mehrere Segmente lang ist) kleiner oder gleich der tatsächlichen MSS ist, die der Proxy empfangen kann.
Kurze Beschreibung der Zeichnung
1 ist ein Blockschaltbild eines Netzwerks, das einen Proxyumlenker enthält, der Anforderungen transparent von einem Klient zu einem Proxy-Cache sendet, indem die Zieladresse von Paketen in einer Klientanforderung von der des Ursprungsservers in die eines Proxy und die Quellenadresse von der des Klient in die der Vermittlungsentität umgeändert wird, und der gemäß der vorliegenden Erfindung eine GET-Anforderung so modifiziert, daß sie die Zieladresse des Ursprungsservers enthält;
2 ist ein Blockschaltbild des Proxyumlenkers, der auf einem programmierbaren Netzwerkelement implementiert ist, das Pakete gemäß durch ein geladenes Programm bereitgestellten Anweisungen manipuliert; und
3, 4, 5 und 6 sind Flußdiagramme der Funktionsweise des Proxyumlenkers.
Ausführliche Beschreibung
Mit Bezug auf 1 sind mehrere Klients 101-1 – 101-N mit einem lokalen Netzwerk (LAN) 102, wie zum Beispiel einem Ethernet, verbunden. Das LAN 102, das seinerseits durch einen Router 103 mit einer Vermittlung der Ebene 4 (L4) 104 (Proxyumlenker) verbunden ist, das als Schnittstelle des LAN mit dem großflächigen Netzwerk (WAN) 105, wie zum Beispiel mit dem Internet, dient. Obwohl sie als zwei getrennte Elemente gezeigt sind, können die Funktionalitäten des Routers 103 und des Proxyumlenkers 104 in der Praxis in einer einzigen Einheit kombiniert werden. Alle Anforderungen von beliebigen der mit dem LAN 102 verbundenen Klient von Objekten, die in Servern gespeichert sind, die mit dem Internet 105 verbunden sind, durchqueren den Proxyumlenker 104 auf das Internet. Die Pakete, die solche Anforderungen umfassen, die die standardisierten Pakete enthalten, die eine TCP-Verbindung herstellen, werden zu einer IP-Zieladresse und Portnummer gelenkt, die in dem IP-Kopfteil jedes Pakets angegeben werden, das von einer Klient-Quellenadresse stammt, die eine Klient-IP-Adresse und -Portnummer enthält. Ähnlich werden Antworten auf solche Anforderungen von einem mit dem Internet 105 verbundenen Ursprungsserver über eine IP-Zieladresse gelenkt, die gleich der IP-Adresse und Portnummer des Klient ist, von dem die Anforderung stammte, und weisen als Quellenadresse die IP-Adresse und Portnummer des Servers auf. Alle solchen an beliebige der Klients 101-1 – 101-N von einem beliebigen mit dem Internet 105 verbundenen Server gerichteten Pakete werden durch den Proxyumlenker 104 geleitet.
Wenn beliebige der mit den LAN 102 verbundenen Klients, wie zum Beispiel Klient 101-1, durch einen Browser ein Objekt durch Spezifizieren einer logischen URL anfordert, wird auf einen lokal oder auf dem Internet 105 wie gezeigt verbundenen Domain-Namenserver (DNS) 106 zugegriffen, um auf der Basis dieses logischen Namens ein Datenbanknachschlagen durchzuführen. Eine zugeordnete IP-Adresse wird dann an den Browser zurückgegeben. Die an den Browser zurückgegebene IP-Adresse ist die IP-Adresse eines bestimmten Ursprungsservers, der das Objekt enthält, das durch die logische URL angefordert wurde. Da ein logischer Name tatsächlich mehreren im wesentlichen äquivalenten Ursprungsservern, wie zum Beispiel den Servern 107 und 109, zugeordnet sein kann, kann die von dem DNS 106 gewählte, an den Klient-Browser zurückgegebene bestimmte IP-Adresse im Reigenverfahren bestimmt werden. Wenn der DNS 106 einen Ursprungsserver wählt, der der logischen URL entspricht, wird die IP-Adresse des gewählten Ursprungsservers, wie zum Beispiel die IP-Adresse des Ursprungsservers 107 an den Browser in dem anfordernden Klient 101-1 zurückgegeben. Diese IP-Adresse dient dann als die IP-Adresse, an die an den Ursprungsserver von dem Klient gerichtete Pakete gerichtet werden. Http-Anforderungen werden gewöhnlich an Port 80 eines Ursprungsservers gerichtet.
Wenn die IP-Adresse des Ursprungsservers bestimmt und an den Klient zurückgegeben worden ist, stellt der Browser eine TCP-Verbindung zwischen dem Klient und dem Ursprungsserver durch einen dreiseitigen Handshaking-Prozeß her. Genauer gesagt sendet der Klient ein an die IP-Adresse des gewählten Ursprungsservers adressiertes SYN-Paket. Das Handshaking ist abgeschlossen, wenn der Klient eine Bestätigung des Empfangs dieses SYN-Pakets durch ein durch diesen Ursprungsserver gesendetes ATK-SYN-Paket empfängt und dem Ursprungsserver mit einem ACK-Paket antwortet. Der Browser sendet dann eine GET-Anforderung, die das bestimmte angeforderte Objekt spezifiziert.
Nachdem die IP-Adresse des dem logischen URL-Namen entsprechenden Ursprungsservers durch DNS-Nachschlagen bestimmt wurde, stellt gemäß der vorliegenden Erfindung der Proxyumlenker 104, statt eine TCP-Verbindung zu dem Ursprungsserver an der bestimmten IP-Adresse herzustellen, transparent eine TCP-Verbindung zwischen dem Klient und einem Proxy her. Wenn das angeforderte Objekt in dem Cache gespeichert ist, wird eine Kopie dieses Objekts transparent an den anfordernden Klient zurückgegeben. Deshalb wird keine TCP-Verbindung über das Internet 105 zu dem tatsächlichen Ursprungsserver 107 hergestellt, um dem anfordernden Klient das angeforderte Objekt zuzuführen. Die Kosten des Übertragens der Anforderung zu dem Ursprungsserver über das Internet und des Übertragens der Kopie des angeforderten Objekts zurück über das Internet werden dadurch gespart, und auch die erforderliche Zeit zum Übertragen einer solchen Anforderung über das Internet und das Warten auf eine Antwort von dem Ursprungsserver. Wenn der Proxy-Cache, an den die Anforderung gerichtet ist, das angeforderte Objekt nicht enthält, wird eine separate TCP-Verbindung zwischen dem Proxy-Cache und dem Ursprungsserver hergestellt, um eine Kopie des angeforderten Objekts zu erhalten. Wenn der Proxy-Cache dann die Kopie des angeforderten Objekts von einem Ursprungsserver über diese separate TCP-Verbindung empfängt, wird die Kopie über die ursprüngliche TCP-Verbindung, die zwischen dem Klient und dem Proxy-Cache hergestellt wurde, zu dem Klient weitergeleitet.
Bei der in 1 gezeigten Ausführungsform ist ein Proxy-Cache 110-1 beispielhaft mit einem LAN 111 verbunden gezeigt, das durch einen Router 112 mit dem LAN 102 verbunden ist. Ein weiterer Proxy-Cache 115 ist auf einem anderen LAN 116 durch den Router 103 verbunden gezeigt. Weitere Proxy-Caches können sich an einer beliebigen Stelle auf den LANs 102, 111 oder 116 befinden, oder auf einem anderen LAN, der mit dem Internet 105 verbunden ist, wie zum Beispiel dem Proxy-Cache 117. Der Proxyumlenker 104 wählt einen der verfügbaren Proxy-Caches, an den Klient-Anforderungen weiterzuleiten sind, auf der Basis einer Metrik, wie zum Beispiel geringste Belastung oder Zyklus auf der Basis von IP-Kopfteilinformationen, wie zum Beispiel der Ursprungsserver-IP-Adresse. In bezug auf letzteres werden alle Objekte von einem spezifischen Ursprungsserver durch einen spezifischen Proxy versorgt.
Bei der hier beschriebenen bevorzugten Ausführungsform enthält der Proxyumlenker 104 ein programmierbares Netzwerkelement des Typs, der in der gleichzeitig anhängigen US-Patentanmeldung, Laufnummer 09/190, 355, registriert am 12.11.1998, nunmehr US-B-6 434 618 beschrieben wird. Wie in dieser Anwendung beschrieben wird, läuft dieses programmierbare Netzwerkelement bei der bevorzugten Ausführungsform auf einer Linux-Maschine. Wie in 2 gezeigt, enthält das programmierbare Netzwerkelement 200 einen Dispatcher-Prozeß 202, mit dem mehrere verschiedene Gateway-Programme (204, 205 und 206) IP-Pakete, die auf spezifische Beschreibungen passen, registrieren und einen Zugriff auf diese anfordern. Solche Programme werden über einen lokalen Programminjektor 211 oder einen abgesetzten Programminjektor 212 durch einen Zulassungsdämon 210 geladen. Ein Gateway-Programm kann zum Beispiel Zugriff auf ankommende Pakete zu der Netzwerkschnittstelle 208 anfordern, die mit bestimmten Quellen- und Ziel-IP-Adressenbereichen und -Portnummern übereinstimmen. Der Dispatcher-Prozeß 202 verwendet ein Paketfilter 203 in dem Linux-Kern 201, um durch die Gateway-Programme angeforderte Pakete zu erhalten, und verwendet ein Raw-IP-Socket 215, um Pakete, die gemäß dem Gateway-Programm manipuliert wurden, zur Ausgabe zurück auf das Netzwerk durch das Filter 203 durch die Netzwerkschnittstellen 208 zu dem Kern zurückzusenden. In dem programmierbaren Netzwerkelement sind Bibliothekfunktionen vorgesehen, die es einem Gateway-Programm ermöglichen, mit dem Dispatcher-Prozeß 202 zu kommunizieren, um Regeln zu registrieren, die die Art von IP-Paketen spezifizieren, die ein Gateway-Programm zu ihm umgelenkt haben möchte. Ein Gateway-Programm kann entweder ein vollständiges IP-Paket anfordern, oder nur den IP- und TCP-Kopfteil eines Pakets, und kann sowohl den Kopfteil als auch das Nutzsignal eines Pakets verändern.
Bei der vorliegenden Erfindung ist dieses programmierbare Netzwerkelement in Kombination mit einem Gateway-Programm betreibbar, das die Ziel- und Quellenadressen von dorthindurch fließenden Paketen auf noch zu beschreibende Weise manipuliert, sowie zum Modifizieren auf noch zu beschreibende Weise von Informationen in dem Paket bzw. in den Paketen mit der GET-Anforderung, die die URL des angeforderten Objekts spezifizieren. Genauer gesagt operiert das programmierbare Netzwerkelement in Kombination mit dem Gateway-Programm an Paketen, die HTTP-Anforderungen zugeordnet sind, die aus der Zielportnummer bestimmt werden. Wie bereits erwähnt, sind HTTP-Anforderungen gewöhnlich an Port 80 eines Ursprungsservers adressiert. Das programmierbare Netzwerkelement bzw. das Gateway-Programm, die bei dieser Ausführungsform zusammen den Proxyumlenker 104 umfassen, erfassen also durch den Dispatcher-Prozeß des programmierbaren Netzwerkelements an Port 80 gerichtete Pakete und führen dann Adressenübersetzungen an diesen erfaßten Paketen durch, um diese Pakete zu einem gewählten Proxy umzuadressieren. Mit Bezug auf Adressenübersetzungen übersetzt das Gateway-Programm die Ziel-IP-Adresse von an den Ursprungsserver adressierten Paketen in die IP-Adresse eines gewählten Proxy-Cache und übersetzt die Quellen-IP-Adresse solcher Pakete aus der des Klient in die IP-Adresse des Proxyumlenkers 104. Damit der Proxyumlenker 104 Anforderungen von mehreren Klient-Endgeräten identifiziert, die an denselben Proxy gerichtet sind, wird ferner die Quellenportnummer in dem Proxyumlenker in eine falsche Ghost-Portnummer übersetzt. Wenn der Proxy-Cache antwortet, weisen die durch den Cache übertragenen Pakete also eine Ziel-IP-Adresse des Proxyumlenkers 104 an dieser falschen Portnummer auf, die eindeutig dem Klient zugeordnet ist. Das Gateway-Programm in dem Proxyumlenker 104 übersetzt die IP-Zieladresse dieser Antwortpakete aus dem Proxy in die IP-Adresse des Klient und übersetzt die falsche Zielportnummer in die Portnummer, von der aus der Klient seine Anforderung tätigte. Weiterhin übersetzt das Gateway-Programm die Quellen-IP-Adresse solcher Antwortpakete aus der des Proxy in die IP-Adresse des Ursprungsservers und die Portnummer in den Port (80), an den die Anforderungen des Klient ursprünglich gerichtet waren. Die Pakete, die von dem Proxy an den Klient zurückgegeben werden, täuschen also vor, sie stammten aus dem Ursprungsserver, von dem der Klient „glaubte", daß seine Anforderung zu ihm gesendet wurde.
Durch Durchführen der oben beschriebenen Netzwerkadressenübersetzungen (NATs) und Portadressenübersetzungen (PATs) werden Pakete von einem Klient 101-1 transparent durch den Proxyumlenker 104 zu einem Proxy-Cache gelenkt. Antwortpakete von dem Proxy-Cache werden zu dem Proxyumlenker 104 gesendet und dort zu dem Klient 101-1 umgelenkt.
Bei der Herstellung einer TCP-Verbindung, die an einen Ursprungsserver gerichtet ist, sendet der Klient 101-1 zuerst ein SYN-Paket, das durch den Proxyumlenker 104 abgefangen wird. Der Proxyumlenker 104 wählt einen Proxy-Cache, wie zum Beispiel den Proxy 110-1 um diese Anforderung umzulenken, und erzeugt einen Verbindungssteuerblock (CCB), um Informationen über die Verbindung zu führen. Die Auswahl des bestimmten Proxy wird wie oben beschrieben durch einen von mehreren möglichen Algorithmen bestimmt. Der CCB dient zum Speichern der Klient-IP-Adresse und der TCP-Portnummer und der Ursprungsserver-IP-Adresse und TCP-Portnummer, die beide in dem IP-Kopfteil des SYN-Pakets enthalten sind, und der IP-Adresse des gewählten Proxy. Die Zieladresse wird dann in die des gewählten Proxy umgeändert, und das Paket wird zur Umlenkung zu seiner neuen Zieladresse des Proxy 110-1 zu dem Netzwerk zurückgesendet. Alle nachfolgenden Pakete, die von demselben Klient mit derselben TCP-Portnummer stammen, werden dann zu demselben Proxy weitergeleitet. Der Proxy 110-1 antwortet mit einem ACK-SYN-Paket, das über seine Zieladresse zu dem Proxyumlenker 110-1 umgelenkt wird. Der Proxyumlenker 104 übersetzt dann die Quellen-IP-Adresse und Portnummer dieser des Ursprungsservers und die Ziel-IP-Adresse und Portnummer dieser des Klient. Wenn das Paket am Klient ankommt, glaubt der Klient, daß er mit dem Ursprungsserver verbunden ist. Der Klient antwortet dann mit einem ACK-Paket zu dem Ursprungsserver, das durch den Proxyumlenker 104 zu dem Proxy-Cache 110-1 umgelenkt wird, um den Handshaking-Prozeß abzuschließen.
Nachdem die TCP-Verbindung zwischen dem Klient 101-1 und Proxy-Cache 110-1 hergestellt wurde, sendet der Klient 101-1 ein oder mehrere Pakete, die eine an den Ursprungsserver adressierte GET-Anforderung enthalten. Solche Pakete werden also von dem Proxyumlenker 104 „erfaßt" und zu dem Proxy-Cache 110-1 umgelenkt. Wie bereits besprochen, enthält die von dem Klient gesendete GET-Anforderung nur die durch den Klient-Browser gesendete vollständige URL, die für sich nicht genug Informationen für den Proxy-Cache liefert, um zu bestimmen, ob er das angeforderte Objekt besitzt und, wenn dies nicht der Fall ist, sie zu dem Ursprungsserver weiterzuleiten, der es besitzt. Gemäß der vorliegenden Erfindung erfaßt das Gateway-Programm, das mit dem programmierbaren Netzwerkelement des Proxiumlenkers 104 wirkt, dieses Paket oder Pakete und transformiert zusätzlich zu den bereits beschriebenen Adressenübersetzungen die vollständige URL in eine absolute URL, indem er ihr die IP-Adresse des Ursprungsservers voranstellt, die aus der Ziel-IP-Adresse des Pakets bzw. der Pakete mit der GET-Anforderung erhalten wird. Somit werden Informationen der Ebene 7 (Anwendung) modifiziert, um bei dem Routing der Ebene 4 zu helfen.
Um die URL-Transformation sowohl für den Klient- als auch den Proxy-Cache-Endpunkt transparent zu machen, sind auch Änderungen an IP- und TCP-Kopfteilen erforderlich. Da die GET-Anforderungsmodifikation die Länge des IP-Pakets, das die GET-Anforderung führt, vergrößert, wird das Gesamtlängenfeld des IP-Kopfteils dieses Pakets um ein Offset vergrößert. Der Offsetbetrag wird in dem CCB verzeichnet. Zusätzlich enthält der TCP-Kopfteil Sequenznummern (seq) und Bestätigungssequenznummern (ack_seq), die übersetzt werden müssen. Die seq in dem TCP-Kopfteil gibt die Bytezahl des ersten Byte auf diesem Paket an, das über die TCP-Sitzung von dem Sender zu dem Empfänger geht, und ack_seq gibt die Bytezahl des nächsten Byte an, dessen Empfang von dem Empfänger der Absender erwartet. Für alle Pakete nach dem GET-Paket bzw. den GET-Paketen, die von dem Klient zu dem Proxy-Cache gehen, wird seq um ein Offset vergrößert, das gleich lengthof (absolute URL)-lengthof (vollständige URL) ist, sodaß seq mit der Bytezahl des Byte übereinstimmt, dessen Empfang von dem Klient der Proxy-Cache erwartet. An allen Paketen, die mit der Bestätigung für das GET-Paket beginnen, die durch den Proxyumlenker von dem Proxy-Cache zu dem Klient gehen, wird ähnlich ack_seq um dasselbe Offset verkleinert, sodaß ack_seq mit der Bytezahl des Byte übereinstimmt, von dem der Proxy-Cache erwarten würde, daß es der Klient in dem nächsten Paket nach dem GET-Paket sendet. Durch Durchführen dieser Änderungen an dem Kopfteil bleiben der Klient- und der Proxy-Cache-Endpunkt unbewußt über die Modifikation in den GET-Paketen von der vollständigen URL zu der absoluten URL.
Tabelle 1 zeigt die URL- und andere Kopfteiltransformationen, die durchgeführt werden. Tabelle 1

an einem GET-Paket durchgeführt werden, das von einem Klient 101-1 an dem Proxyumlenker 104 ankommt. Das Paket ist für einen Ursprungsserver an einer Ziel-IP-Adresse (daddr) 204.71.200.244 (www.yahoo.com) an einem Zielport (dport)80, anforderndes Objekt /a/ya/yahoomail/promol.gif, bestimmt. Wie in dem modifizierten Paket zu sehen ist, wird das Paket zu einem Proxy-Cache 110-1 an der IP-Adresse 135.104.25.31 Port 7000, umgelenkt, indem die Kopfteilinformationen daddr und dport verändert werden. Auferdem wird die vollständige URL des Objekts in der GET-Anforderung in dem übersetzten Paket modifiziert, indem ihr http://204.71.200.244 vorangestellt wird, um die absolute URL zu bilden, wobei dieser Präfix aus dem daddr-Kopfteil in dem ankommenden Paket erhalten wird. Diese Transformation vergrößert die Länge des Pakets um 21 Byte, sodaß das Feld pkt_len in den Kopfteil von 346 in 367 Byte umgeändert wird. Außerdem wird der Quellenport in eine falsche Portnummer umgeändert, indem sport in 5000 umgeändert wird.
Tabelle 2 zeigt die Übersetzungen, die durch den Proxyumlenker 104 an einer Bestätigung von dem Proxy-Cache 110-1 der GET-Anforderung durchgeführt werden. Tabelle 2

das Paket wird an die IP-Adresse des Proxy-Umlenkers an dem falschen Port (dport) 5000, der von dem Proxyumlenker für diese TCP-Verbindung verwendet wird, adressiert (daddy). Die Quellen-IP-Adresse (saddr) und der Quellenport (sport) sind die des Proxy-Cache, an den die GET-Anforderung gerichtet war. Das Feld ack_seq gibt die Bytezahl des ersten Byte an, von dem erwartet wird, daß es in dem Paket nach dem GET-Paket gesendet wird. In diesem Beispiel ist ack_seq gleich der Sequenznummer (seq) 218908427 des GET-Pakets, plus der Länge des GET-Pakets, die in diesem Fall per Tabelle 1 367 beträgt. Somit beträgt ack_seq des ankommenden Pakets 218908754. Da dem Klient 101-1 nicht bewußt ist, daß ein Proxyumlenker die Länge des GET-Pakets um 21 Byte vergrößert hat, verkleinert der Proxyumlenker 104 das Feld ack_seq um die Anzahl der hinzugefügten Byte (21). Ferner übersetzt der Proxyumlenker 104 diese Ziel-IP-Adresse und Portnummer in die des Klient 101-1 und die Quellen-IP-Adresse und -Portnummer in die des Ursprungsservers. Das modifizierte Paket erscheint, wenn es durch den Klient empfangen wird, also dem Klient als aus dem Ursprungsserver stammend, und das Feld ack_seq gibt eine Bytezahl an, deren Sendung der Klient als nächstes erwarten würde, wenn er zuvor ein Paket der Länge von 367 Byte gesendet hat. Alle Pakete, die danach durch den Proxyumlenker 104 von dem Proxy-Cache 110-1 zu dem Klient 101-1 gesendet werden, werden ähnlich modifiziert, um das Feld ack_seq um die Anzahl der zu dem GET-Paket hinzugefügten Byte (21) zu erniedrigen.
Tabelle 3 zeigt ein nächstes Paket, das durch den Klient 101-1 nach dem GET-Paket zu dem Ursprungsserver gesendet wird. In diesem Paket ist die Sequenznummer (seq) gleich dem modifizierten ack_seq, das zu dem Klient gesendet wird, per Tabelle 2. Die Ziel-IP-Adresse und -Portnummer sind die des Ursprungsservers und die Quellen-IP-Adresse und -Portnummer die des Klient. Wenn es durch den Proxyumlenker 104 empfangen wird, wird das Paket modifiziert, um die Quellen-IP-Adresse und -Portnummer in die IP-Adresse und falsche Portnummer des Proxyumlenkers umzuändern. Die Zieladressen-IP- und -Portnummer werden in die des Proxy-Cache 110-1 übersetzt. Die Sequenznummer (seq) wird um denselben Wert von 21 erhöht, um Übereinstimmung mit der Bytezahl zu erreichen, deren Empfang der Proxy-Cache auf der Basis der zuvor in dem GET-Paket empfangenen Sequenznummer und der Länge 367 des empfangenen GET-Pakets zu emfpangen erwartet.
Tabelle 3
Alle nachfolgenden Pakete, die von dem Klient 101-1 an den Ursprungsserver gerichtet werden, werden ähnlich modifiziert, bevor sie zu dem Proxy-Cache 110-1 gelenkt werden.
In der obigen Beschreibung wurde angenommen, daß die Länge der GET-Anforderung sowohl vor der Modifikation als auch nach der URL-Erweiterung kleiner als die maximale TCP-Segmentgröße ist. Tatsächlich kann die Länge der GET-Anforderung größer als ein TCP-Segment sein. Wenn die Länge der die vollständige URL führenden GET-Anforderung x-Nummer des TCP-Segments einnnimmt und nachdem es modifiziert wird, um die absolute URL zu führen, immer noch in diese selbe x-Anzahl von TCP-Segmenten paßt, dann wird das die URL-führende Segment modifiziert und überlaufende Zeichen werden im Pipeline-Verfahren von einem Segment in das nächste überführt. Die überlaufenden Zeichen von einem vorherigen Paket werden also dem Anfang des nächsten Pakets vorangestellt usw., bis zum letzten Paket, dessen Länge aufgrund der URL-Modifikation um die vergrößerte Anzahl von Byte vergrößert wird. Deshalb wird die Paketlänge nur des letzten Segments modifiziert, sodaß sie die Zeichen enthält, die in dieses Segment hineingeschoben wurden. Der Parameter ack_seq in Paketen von der Proxy-Cache zu dem Klient wird beginnend mit der Bestätigung für das letzte GET-Paket modifiziert.
Wenn das Umändern der URL in die absolute URL bewirken könnte, daß das letzte TCP-Segment der GET-Anforderung in ein anderes Segment überläuft, müßte ein neues TCP-Segment durch den Proxyumlenker konstruiert und injiziert werden. Der Proxyumlenker müßte dann die Fähigkeit aufweisen, dieses Segment neu zu senden, wenn es verloren ging. Somit müßte der Proxyumlenker bestimmte Funktionalitäten der TCP-Schicht aufweisen. Um das Hinzufügen höherer Funktionalität zu dem Proxyumlenker zu vermeiden, werden Segmentgrößen auf Größen begrenzt, die kleiner sind, als die Größen, die der Proxy-Cache tatsächlich empfangen kann. Wenn die vollständige URL in eine erweiterte URL transformiert wird, beträgt die maximale Zunahme der Größe 22 Byte, gleich der maximalen Länge einer IP-Adresse von 15 Byte plus 7 Byte aus dem Präfix: http://. Dem Klient wird vorgetäuscht, Segmente zu senden, deren maximale Größe 22 Byte kleiner als das von dem Protokoll zum Senden zulässig ist. Die von dem Klient gesendete TCP-Segmentgröße wird durch das bestimmt, wodurch der Proxy-Cache bei seinem Handshake mit dem Klient die maximale Segmentgröße, die er empfangen kann, angibt. Dies wird durch den Proxy-Cache durch das Feld der maximalen Segmentgröße (MSS) in dem ACK-SYN-Paket angegeben. Folglich fängt der Proxyumlenker 104 die ACK-SYN-Pakete ab und vermindert den spezifizierten MSS-Betrag um 22. Wenn zum Beispiel die durch den Proxy-Cache spezifizierte MSS 1460 beträgt, wird sie vor dem Senden zu dem Klient durch den Proxyumlenker in 1438 umgeändert. Wenn der Klient das nächste Mal eine GET-Anforderung sendet, werden die TCP-Segmente auf 1438 Byte begrenzt. Im ungünstigsten Fall werden, wenn der Klient eine GET-Anforderung sendet, dem x-ten TCP- Segment, das diese Anforderung führt, 22 Byte hinzugefügt. Die Länge diese x-ten TCP-Segments liegt dann immer noch innerhalb der durch den Proxy-Cache spezifizierten maximalen Länge. Für den Fall, daß der Proxy-Cache keine maximale MSS in dem ACK-SYN-Pakete vorgibt, ist der vom Klient verwendete Vorgabewert 536 Byte. Der Proxyumlenker fügt dann eine MSS-Option hinzu, um den Klient zu informieren, daß die Maximale von dem anderen Ende der TCP-Verbindung erwartete MSS 514 Byte beträgt.
Wie bereits beschrieben, führt der Proxyumlenker 104 an allen durch den Klient 101-1 an einen Ursprungsserver adressierten Paketen und an allen durch den Proxy-Cache 110-1 an den Proxyumlenker 104 zur Rückgabe an den Klient adressierten Paketen eine NAT und PAT durch. Der Proxyumlenker 104 führt also an diesen in beiden Richtungen fließenden Paketen eine NAT und eine PAT durch. Wenn der Proxyumlenker 104 einen Proxy-Cache wählt, der sich an einem solchen Punkt in dem Netzwerk befindet, das Pakete von dem Proxy-Cache, die direkt an den Klient 101-1 adressiert sind, aufgrund der Netzwerkkonfiguration durch den Proxyumlenker 104 laufen müssen, dann muß der Proxyumlenker an den durch ihn fließenden Paketen nur eine Halb-NAT durchführen. Wenn der Proxyumlenker 104 einen Proxy-Cache wie zum Beispiel den Proxy-Cache 117 wählt, müssen genauer gesagt alle an den Klient 101-1 adressierten Pakete durch den Proxyumlenker 104 laufen. Der Proxyumlenker 104 muß also nur die Ziel-IP-Adresse und -Portnummer von Paketen von dem Klient 101-1 in die IP-Adresse und Portnummer des Proxy-Cache 117 transformieren, während die Quellen-IP-Adresse und -Portnummer als die des Klient 101-1 erhalten werden. Die von dem Proxy-Cache 117 zurückgegebenen Pakete werden also an die IP-Adresse und Portnummer des Klient adressiert. Wenn sie durch den Proxyumlenker 104 laufen, werden sie erfaßt und die Transformation von Quellen-IP-Adresse und-Port in die des Ursprungsservers sind die einzigen Adressenänderungen, die bewirkt werden müssen.
Die Probleme des Stands der Technik in bezug auf persistente Verbindungen werden gemäß der vorliegenden Erfindung beseitigt. Wie bereits erwähnt, kann ein Klient während persistenter Verbindungen mehrere GET-Anforderungen durchführen. Wie beschrieben kann im Stand der Technik jede GET-Anforderung zu einer Verbindung von einem Proxy-Cache zu einem verschiedenen Ursprungsserver führen, wenn der Proxy-Cache die angeforderten Objekte nicht besitzt. Die Möglichkeit eines Servers, den Zustand der Verbindung eines Klient während der gesamten Dauer der Verbindung zu führen, wird kompromitiert, wenn jede GET-Anforderung zu Verbindungen zu mehreren Servern führt. Nachdem die IP-Adresse des Ursprungsservers bei dem anfänglichen DNS-Nachschlagen bestimmt wurde, wird gemäß der vorliegenden Erfindung dieselbe IP-Adresse von dem Proxyumlenker als Präfix für jede vollständige URL in jeder GET-Anforderung verwendet, die von dem Klient während der gesamten Dauer der persistenten Verbindung ausgegeben wird. Unter der Annahme, daß der Proxy-Cache keine der angeforderten Objekte enthält, stellt der Proxy-Cache also als Reaktion auf jede durch den Klient erzeugte GET-Anforderung eine TCP-Verbindung zu demselben Ursprungsserver her. Es ist zu beachten, daß, wenn mehrere Klient-GET-Anforderungen durch den Proxyumlenker zu einem Proxy-Cache mit einer persistenten TCP-Verbindung weitergeleitet werden, der Parameter ack_seq in Paketen, die nach jeder GET-Anforderung von dem Proxy durch den Proxyumlenker fließen, die kumulativen Änderungen wiedergeben muß, die durch Übersetzen der vollständigen URL in die absolute URL jeder der vorherigen GET-Anforderungen innerhalb derselben TCP-Verbindung bewirkt werden. Ähnlich muß in allen Paketen, die von dem Proxyumlenker aus dem Klient empfangen werden, die an den Ursprungsserver in einer persistenten TCP-Verbindung gerichtet sind, der seq-Parameter kumulative Änderungen wiedergeben.
3 und 4 zeigen zusammen Flußdiagramme der Funktionen des Proxyumlenkers 104 bei der Herstellung einer TCP-Verbindung zu einem Proxy-Cache und beim Modifizieren der GET-Anforderung dergestalt, daß solche Anforderungen transparent zu dem Proxy weitergeleitet werden können. Im Schritt 301 kommt ein SYN-Paket von dem Klient an dem Proxyumlenker an. Im Schritt 302 wählt der Proxyumlenker einen Proxy-Cache auf der Basis eines Lastausgleichalgorithmus oder einer willkürlichen oder zufälligen Auswahl. Im Schritt 303 führt der Proxyumlenker eine volle NAT durch, wobei das daddr von dem des Ursprungsserver in das des gewählten Proxy und das saddr von dem des Klient in das des Proxyumlenkers umgeändert wird. Im Schritt 304 wird eine PAT durchgeführt, wobei sport in das einer falschen Ghost-Portnummer und dport in die Portnummer des Proxy umgeändert wird. Im Schritt 305 wird das SYN-Paket zu dem Proxy gesendet. Als Reaktion auf dieses SYN-Paket antwortet der Proxy im Schritt 306 mit einem SYN-ACK-Paket, das einen MSS-Parameter in dem TCP-Kopfteil enthält. Im Schritt 307 wird sowohl an den IP-Adressen als auch den Portnummern eine Rückübersetzung durchgeführt, wobei saddr und Sport in die des Ursprungsservers und daddr und dport in die des Klient umgeändert werden. Im Schritt 308 wird das MSS-Feld verändert, indem der Wert der aus dem Proxy empfangenen MSS um 22 reduziert wird. Im Schritt 309 wird das ACK-SYN-Paket zum Klient gesendet. Im Schritt 310 empfängt der Proxyumlenker ein Antwort-ACK-Paket von dem Klient. Im Schritt 311 werden eine volle NAT und PAT an diesem Paket durchgeführt, und im Schritt 312 wird das modifizierte Paket zu dem Proxy gesendet, wodurch die Handshake-Sequenz abgeschlossen wird.
Im Schritt 313 wird ein eine GET-Anforderung enthaltendes Paket von dem Klient empfangen. Im Schritt 314 wird eine volle NAT durchgeführt, und im Schritt 315 wird eine PAT durchgeführt. Im Entscheidungsschritt 316 wird bestimmt, ob dies ein erstes Paket in der GET-Anforderung ist. Wenn dies der Fall ist, wird im Schritt 317 die IP-Adresse des Ursprungsservers, die aus dem daddy des ankommenden Pakets erhalten wird, der vollständigen URL in der GET-Anforderung vorangestellt. Wenn im Schritt 316 das Paket nicht ein erstes Paket in einer GET-Anforderung ist, dann werden im Schritt 318 die Überlaufbyte von dem vorherigen GET-Paket den Byte in dem aktuellen Paket vorangestellt, und wenn die Gesamtzahl von Byte in dem resultierenden Paket als die tatsächliche MSS ist, die durch den Proxy gesendet wird, werden die Überlaufbyte zur Voranstellung an das nächste Paket gepuffert. Nach den alternativen Schritten 316 oder 318 wird im Schritt 319 bestimmt, ob das aktuelle Paket das letzte Paket einer GET-Anforderung ist. Wenn nicht, wird im Schritt 320 das aktuelle Paket zu dem Proxy gesendet und der Fluß kehrt zum Schritt 313 zurück, um das nächste Paket in der GET-Anforderung von dem Klient zu empfangen. Wenn im Schritt 319 das aktuelle Paket das letzte Paket in einer GET-Nachricht ist, dann wird im Schritt 321 der Parameter pkt_len dieses Pakets verändert, um die Längenänderung des Pakets wiederzugeben. Im Schritt 322 wird das modifizierte Paket zu dem Proxy gesendet.
5 zeigt die Schritte, die von dem Proxyumlenker für jedes von dem Proxy empfangene Paket durchgeführt werden, beginnend von dem ACK für die GET-Anforderung bis zum Ende der Verbindung. Im Schritt 501 empfängt der Proxyumlenker das ACK auf die GET-Anforderung oder jedes andere Paket, das logisch dem ACK für die GET-Anforderung folgt. Im Schritt 502 werden Rück-NAT und -PAT durchgeführt, wobei daddr und dport in die des Klient und saddr und Sport in die des Ursprungsservers übersetzt werden. Im Schritt 503 wird ack_seq um den in der vorherigen GET-Anforderung hinzugefügten Betrag vermindert. Im Schritt 504 wird das modifizierte Paket zu dem Klient gesendet.
6 zeigt die Schritte, die von dem Proxyumlenker für jedes Paket durchgeführt werden, das für den Ursprungsserver von dem Klient im Anschluß an die GET-Anforderung bestimmt ist. Im Schritt 601 wird ein der GET-Anforderung nachfolgendes Paket von dem Klient empfangen. Im Schritt 602 werden eine volle NAT und PAT durchgeführt. Im Schritt 603 wird seq_no um den Betrag der durch Modifizieren der vorherigen GET-Anforderung hinzugefügten Byte vergrößert. Im Schritt 604 wird das Paket zu dem Proxy gesendet.
In der obigen Besprechung von 3, 4, 5 und 6 wurde angenommen, daß sich der Proxy-Cache an einer dergestaltigen Position befindet, daß an den Klient gerichtete Pakete nicht automatisch durch den Proxyumlenker fließen. Somit werden alle Pakete aus dem Proxy an den Proxyumlenker adressiert. Für von dem Klient fließende Pakete und von dem Proxy fließende Pakete führt der Proxyumlenker deshalb eine volle NAT und PAT durch. Wenn sich wie zuvor beschrieben jedoch der von dem Proxyumlenker gewählte Proxy-Cache so in dem Netzwerk befindet, daß alle Pakete von dem Proxy zu dem Klient automatisch durch den Proxyumlenker fließen, dann muß in den in 3, 4, 5 und 6 gezeigten Schritten nur eine Halb-NAT durchgeführt werden.
Obwohl er in Verbindung dem in 2 gezeigten programmierbaren Netzwerkelement beschrieben wurde, könnte der Proxyumlenker der vorliegenden Erfindung durch andere Mittel implementiert werden, wobei Hardware, Software oder eine Kombination von beiden verwendet wird. Zum Beispiel könnte eine Vermittlung der Ebene 4 mit dem Festprogramm zur Durchführung der von der vorliegenden Erfindung benötigten erforderlichen Paketmanipulationen verwendet werden.
Wie beschrieben, gibt der Proxy-Cache angeforderte Objekte an die Adresse zurück, von der eine Anforderung stammte, wie durch die Parameter saddr und sport in den IP-Kopfteilinformationen angegeben wird, wobei es sich um die Adresse des Proxyumlenkers 104 handelt, wenn der Proxy-Cache nicht in dem Netzwerk verbunden ist, sodaß alle Antworten nicht automatisch durch den Proxyumlenker laufen. Die Wechselwirkungen zwischen dem anfordernden Klient und dem Proxy-Cache sind sowohl für den Klient als auch den Proxy-Cache transparent, da der Klient nicht „weiß", daß seine Anforderung durch den Proxyumlenker zu dem Proxy umgelenkt wird und der Proxy-Cache beim Empfang einer GET-Anforderung mit einer absoluten URL nicht weiß, was der Browser des Klient, der in einem nichttransparenten Modus arbeitet, keine absolute URL formuliert. Vorteilhafterweise erfordert der Proxy-Cache keine Softwaremodifikationen, und es können Standard-Proxy-Caches, die an einer beliebigen Stelle in dem Netzwerk verbunden sind, in Verbindung mit dem Proxyumlenker verwendet werden. Wenn der Proxy jedoch modifiziert wird, wobei wie zuvor beschrieben zum Beispiel ein programmierbares Netzwerkelement verwendet wird, kann das durch den Proxy aus seinem eigenen Cache abgerufene oder von einem Ursprungsserver empfangene angeforderte Objekt direkt zum Klient zurückgesendet werden, wodurch es unnötig wird, solche Pakete für Adressenübersetzungen und zum Umlenken zu dem Klient zu dem Proxyumlenker zurückzusenden. Indem in dem Proxyumlenker nur eine Halb-NAT durchgeführt und das saddr und sport des Klient als die Quellen-IP-Adresse und -Portnummer in dem Kopfteil des SYN-Pakets, GET-Anforderungspaket (e) und andere durch den Proxyumlenker 104 von dem Klient umgelenkte Pakete gelassen werden, kann der Proxy-Cache als Reaktion auf die Anforderung Pakete direkt zu dem Klient senden, indem er seine eigene Adresse durch die IP-Adresse und Portnummer des Ursprungsservers als Quellenadresse ersetzt. Wenn der Proxyumlenker eine volle NAT und PAT durchführt, dann muß ein weiterer Mechanismus vorgesehen werden, um die Klient-Adresse dem Proxy-Cache zuzuführen, wie zum Beispiel Aufnehmen der Klient-Adresseninformationen als Teil eines Anhangs für die absolute Adresse in der modifizierten GET-Anforderung und Entfernen der angefügten Klient-Adresseninformationen im Proxy vor der Bestimmung, ob das angeforderte Objekt in dem fache gespeichert ist und ob eine Verbindung zu dem Ursprungsserver hergestellt werden muß. Indem die Pakete direkt von dem Proxy-Cache zu dem Klient zurückgesendet werden, entfällt vorteilhafterweise die Verzögerung, die bei dem Zurücksenden solcher Pakete zu dem Proxyumlenker für die Adressenübersetzung und -Umlenkung auftritt. Nachteiligerweise muß der Proxy-Cache modifiziert werden, um diese Funktionen durchzuführen, sodaß die Verwendung von standardmäßigen verfügbaren Proxy-Caches ausgeschlossen ist.
Obwohl sie oben in Verbindung mit GET-Anforderungen beschrieben wurde, kann die vorliegende Erfindung genauso auf die Umlenkung einer beliebigen Art von Anforderungsnachricht angewandt werden, bei der das Token zum Beispiel GET, POST oder HEAD ist oder jede beliebige andere Art von Token, die noch implementiert und/oder standardisiert werden könnte.
Das obige veranschaulicht lediglich die Prinzipien der Erfindung. Es ist ersichtlich, daß Fachleute in der Lage sein werden, verschiedene Anordnungen zu konzipieren, die zwar hier nicht explizit beschrieben oder gezeigt wurden, aber die Erfindung, die in den Ansprüchen definiert wird, realisieren. Somit ist zum Beispiel für Fachleute erkennbar, daß die hier beschriebenen Blockschaltbilder und Flußdiagramme Konzeptansichten von beispielhaften Schaltkreisen und Prozessen repräsentieren, die die Prinzipien der Erfindung realisieren. Ähnlich versteht sich, daß alle Ablaufdiagramme, Flußdiagramme, Zustandsübergangsdiagramme, jeder Pseudocode und dergleichen verschiedene Prozesse repräsentieren, die im wesentlichen in einem computerlesbaren Medium repräsentiert und somit durch einen Computer oder Prozessor ausgeführt werden können, gleichgültig, ob ein solcher Computer oder Prozessor explizit gezeigt ist oder nicht.
Die Funktionen der verschiedenen in den Figuren gezeigten Elemente, einschließlich als „Prozessor" bezeichnete Funktionsblöcke, können durch Verwendung eigener Hardware und auch durch Verwendung von Hardware, die Software ausführen kann, in Verbindung mit entsprechender Software bereitgestellt werden. Bei Bereitstellung durch einen Prozessor können die Funktionen durch einen einzigen eigenen Prozessor, durch einen einzigen gemeinsam benutzten Prozessor oder durch mehrere einzelne Prozessoren, von denen einige gemeinsam benutzt sein können, bereitgestellt werden. Die explizite Benutzung des Begriffs „Prozessor" oder „Steuerung" sollte darüberhinaus nicht als sich ausschließlich auf Hardware, die Software ausführen kann beziehend aufgefaßt werden und kann implizit ohne Einschränkung Hardware für digitale Signalverarbeitung (DSP), Nurlesespeicher (ROM) zum Speichern von Software, Direktzugriffsspeicher (RAM) und nichtflüchtige Speicherung umfassen. Außerdem kann jede Hardware, herkömmlich und/oder angepaßt, eingeschlossen sein. Ähnlich sind etwaige in den Figuren gezeigte Schalter nur Konzepte. Ihre Funktion kann durch den Betrieb von Programmlogik, durch eigene Logik, durch die Wechselwirkung von Programmsteuerung und eigener Logik oder sogar manuell ausgeführt werden, wobei die konkrete Technik vom Implementierer so wählbar ist, wie es spezifischer aus dem Kontext hervorgeht.
In den vorliegenden Ansprüchen soll jedes als Mittel zur Durchführung einer spezifizierten Funktion ausgedrückte Element jede beliebige Art der Durchführung dieser Funktion umfassen, darunter zum Beispiel a) eine Kombination von Schaltungselementen, die diese Funktion durchführen, oder b) Software in beliebiger Form, darunter deshalb Firmware, Mikrococe oder dergleichen kombiniert mit entsprechenden Schaltkreisen zur Ausführung dieser Software, um die Funktion durchzuführen.

Claims

Verfahren zum transparenten Umlenken einer HTTP-Verbindungsanforderung, die an einen Ursprungsserver (107, 109) gerichtet ist, zu einem Proxy-Cache (110-1, 110-2, 115, 117) über ein paketgestütztes Computernetzwerk (105), mit den folgenden Schritten: Empfangen (313) mindestens eines Pakets, das eine Anforderungsnachricht enthält, in der HTTP-Verbindung, wobei das mindestens eine Paket einen IP-Kopfteil aufweist, der eine Zieladresse eines Ursprungsservers umfaßt, wobei die Anforderungsnachricht eine vollständige Adresse eines spezifizierten Objekts in dem Ursprungsserver enthält, wobei die vollständige Adresse nicht die Zieladresse des Ursprungsservers enthält; Modifizieren (317) der Anforderungsnachricht; und Weiterleiten (320) des mindestens einen Pakets, das die modifizierte Anforderungsnachricht enthält, zu dem Proxy-Cache über das paketgestützte Netzwerk; dadurch gekennzeichnet, daß das Verfahren in einer Vermittlung der Schicht 4 durchgeführt wird und der Schritt des Modifizierens (317) der Anforderungsnachricht die Anforderungsnachricht durch Voranstellen der Zieladresse des Ursprungsservers vor die vollständige Adresse in der Anforderungsnachricht modifiziert.
Verfahren nach Anspruch 1, weiterhin mit dem folgenden Schritt: Übersetzen der Zieladresse in einem IP-Kopfteil des mindestens einen Pakets, das die modifizierte Anforderungsnachricht enthält, in die Adresse des Proxy-Cache.
Verfahren nach Anspruch 2, weiterhin mit dem folgenden Schritt: Übersetzen einer Quellenadresse in einem IP-Kopfteil des mindestens einen Pakets, das die modifizierte Anforderungsnachricht enthält, von einer Adresse des Client in eine Adresse der Vermittlung der Schicht 4.
Verfahren nach Anspruch 2, weiterhin mit dem folgenden Schritt: in einem TCP-Kampfteil in aus dem Proxy-Cache empfangenen Paketen, die mit einer Bestätigung für die modifizierte Anforderungsnachricht beginnen, Modifizieren eines Werts in einem Bestätigtes-Byte-Sequenznummernfeld, um die vergrößerte Anzahl von Byte in der modifizierten Anforderungsnachricht zu berücksichtigen, die sich aus dem Schritt des Voranstellens der Zieladresse des Ursprungsservers vor die vollständige Adresse ergibt.
Verfahren nach Anspruch 4, wobei der Schritt des Modifizierens des Werts in dem Bestätigtes-Byte-Sequenznummernfeld den Schritt des Verkleinerns des Werts in dem Bestätigtes-Byte-Sequenznummernfeld um die Anzahl von durch Voranstellen der Zieladresse des Ursprungsservers vor die vollständige Adresse in der Anforderungsnachricht hinzugefügten Byte umfaßt.
Verfahren nach Anspruch 5, weiterhin mit dem folgenden Schritt: Übersetzen der Zieladresse in die Adresse des Client und der Quellenadresse in die des Ursprungsservers in dem IP-Kopfteil in den aus dem aus dem Proxy-Cache empfangenen Paketen, die mit der Bestätigung für die Anforderungsnachricht beginnen.
Verfahren nach Anspruch 2, weiterhin. mit dem folgenden Schritt: Modifizieren eines Werts in einem Gesendetes-Byte-Sequenznummernfeld, um die vergrößerte Anzahl von Byte in der modifizierten Anforderungsnachricht wiederzugeben, die sich aus dem Voranstellen der Zieladresse des Ursprungsservers vor die vollständige Adresse in einem TCP-Kopfteil in nach dem Empfang der Anforderungsnachricht aus dem Client empfangenen Paketen ergibt.
Verfahren nach Anspruch 7, wobei der Schritt des Modifizierens des Werts in dem Gesendetes-Byte-Sequenznummernfeld den Schritt des Vergrößerns des Werts in dem Gesendetes-Byte-Sequenznummernfeld um die Anzahl von Byte, die sich durch Voranstellen der Zieladresse des Ursprungsservers vor die vollständige Adresse in der Anforderungsnachricht ergibt, umfaßt.
Verfahren nach Anspruch 8, weiterhin mit dem folgenden Schritt: Übersetzen der Zieladresse in die Adresse des Proxy-Cache in dem IP-Kopfteil in jedem nach dem Empfang der Anforderungsnachricht aus dem Client empfangenen Paket.
Verfahren nach Anspruch 1 weiterhin mit dem Schritt des Auswählens des Proxy-Cache aus einer Vielzahl von verschiedenen Proxy-Caches vor dem Empfang des mindestens einen die Anforderungsnachricht enthaltenden Pakets.
Verfahren nach Anspruch 1, weiterhin mit den folgenden Schritten vor dem Schritt des Empfangens des mindestens eines Pakets: Empfangen eines Pakets aus dem Proxy-Cache, das eine maximale Segmentgröße angibt, die danach zu ihm gesendete Pakete aufweisen sollten; Verringern der maximalen Segmentgröße von danach zu dem Proxy-Cache zu sendenden Paketen um eine vorbestimmte Zahl; und Senden eines Pakets zu dem Client, das die verringerte maximale Segmentgröße angibt, die danach durch den Client zu dem Ursprungsserver gesendete Pakete aufweisen sollten.
Verfahren nach Anspruch 11, wobei die vorbestimmte Zahl mindestens gleich der maximalen Anzahl von Byte ist, die durch den Schritt des Voranstellens der Zieladresse vor die vollständige Adresse hinzugefügt werden.
Verfahren nach Anspruch 12, weiterhin mit den folgenden Schritten: sukzessives Schieben von durch den Schritt des Voranstellens der Zieladresse vor die vollständige Adresse in der Anforderungsnachricht verursachten Überlaufbyte zu einem nächsten Paket in der Anforderungsnachricht, wenn die Anforderungsnachricht in mehr als einem Paket enthalten ist; und Ändern eines Länge-des-Pakets-Parameters in dem IP-Kopfteil in einem letzten Paket einer Mehrpaket-Anforderungsnachricht, um die aus einem vorherigen Paket in das letzte Paket geschobenen Byte zu berücksichtigen.
Verfahren nach Anspruch 12, weiterhin mit dem Schritt des Änderns eines Länge-des-Pakets-Parameters in dem IP-Kopfteil, um die durch den Schritt des Voranstellens der Zieladresse vor die vollständige Adresse in der Anforderungsnachricht verursachte Längenänderung dieses Pakets zu berücksichtigen, wenn die Anforderungsnachricht in einem Paket enthalten ist.
Verfahren nach Anspruch 1, wobei die Anforderungsnachricht eine GET-Anforderung ist.
Verfahren nach Anspruch 1, wobei die Anforderungsnachricht eine POST-Anforderung ist.
Verfahren nach Anspruch 1, wobei die Anforderungsnachricht eine HEAD-Anforderung ist.
Proxy-Umlenker (104) zum transparenten Umlenken einer HTTP-Verbindungsanforderung, die an einen Ursprungsserver (107, 109) gerichtet ist, zu einem Proxy-Cache (110-1, 110-2, 115, 117) über ein paketgestütztes Computernetzwerk (105), mit Mitteln, die dafür ausgelegt sind, jeden Schritt eines in einem beliebigen der vorhergehenden Ansprüche beanspruchten Verfahrens auszuführen.
Proxy-Umlenker nach Anspruch 18, wobei das Mittel zum Modifizieren der Anforderungsnachricht ein dynamisch auf ein programmierbares Netzwerkelement geladenes Gateway-Programm ist.
Computerlesbares Medium, das Computerprogrammanweisungen speichert, die auf einem Computersystem ausführbar sind, das eine Vermittlung der Schicht 4 implementiert, zum transparenten Umlenken einer HTTP-Verbindungsanforderung von einem Client zu einem Proxy-Cache über ein paketgestütztes Computernetzwerk, wobei die Computerprogrammanweisungen Anweisungen umfassen, die die Schritte eines Verfahrens nach einem der Ansprüche 1 bis 17 definieren.
Direkt in den internen Speicher eines Computersystems, das eine Vermittlung der Schicht 4 implementiert, ladbares Computerprogrammprodukt mit Softwarecodeteilen zum Durchführen der Schritte eines Verfahrens nach einem der Ansprüche 1 bis 17, wenn das Produkt auf einem solchen Computersystem ausgeführt wird.