DE60130011T2

DE60130011T2 - Http-multiplexer/demultiplexer

Info

Publication number: DE60130011T2
Application number: DE60130011T
Authority: DE
Inventors: Christopher Campbell PEIFFER; Israel Redline Networks Inc. Campbell L'Heureux
Original assignee: Juniper Networks Inc
Current assignee: Juniper Networks Inc
Priority date: 2000-10-10
Filing date: 2001-10-10
Publication date: 2008-05-15
Anticipated expiration: 2021-10-11
Also published as: DE60130011D1; EP1332437A1; EP1332437A4; US7231446B2; ATE370455T1; AU2002214574A1; EP1332437B1; WO2002031676A1; US20020052931A1; US20020042839A1

Description

Technisches Gebiet
Die vorliegende Erfindung betrifft im Allgemeinen die Datenübertragung in Computernetzwerken, und insbesondere ein Netzwerkgerät einschließlich eines Multiplexers/Demultiplexers für das Hypertext Transfer Protocol (HTTP).
Hintergrund der Erfindung
Das Internet hat in den letzten Jahren ein explosives Wachstum erfahren. Das Aufkommen des World Wide Web hat es Millionen von Nutzern auf der Welt ermöglicht, Quellen aus dem Web (Web-Ressourcen), die Text, Grafiken, Video und Klangdaten enthalten, leicht herunter zu laden, während sie sich zu Hause, bei der Arbeit oder an entfernten (remote) Stellen über drahtlose Geräte befinden. Diese Web-Ressourcen haben oft eine erhebliche Größe und benötigen daher eine lange Zeit, um herunter geladen zu werden, was beim Nutzer zu Verzögerungen und Frustration führt. Verzögerungen führen oft dazu, dass die Nutzer die angefragte Seite im Web (Web-Seite) aufgeben und sich einer anderen Web-Seite zuwenden, was bei kommerziellen Angeboten im Web (Websites) zu verlorenen Einnahmen führt und sie in ein schlechtes Licht rückt.
Ein Grund für die Verzögerung liegt in der Ansammlung von Hypertext Transfer Protocol (HTTP)-Anfragen innerhalb eines Puffers für das Transfer Control Protocol (TCP) eines Server-Sockets (logischer Anschluss im Server). Wenn ein Nutzer eine Webseite anfordert, sendet ein Webbrowser HTTP-Anfragen an ein Server-Socket über eine bestehende TCP-Verbindung. Wenn der Server die Anfragen an ein Socket nicht schnell genug bearbeitet, sammeln sich HTTP-Anfragen in dem TCP-Puffer für dieses Socket, was zu einer verzögerten Bearbeitung in diesem Socket führt.
Ein zusätzlicher Grund für die Verzögerung ist der Overhead (administrativer Aufwand) bei der Verarbeitung, der auf das Socket bezogen ist. Herkömmliche Netzwerksysteme öffnen ein Server-Socket für jeden Client, der sich mit dem Server verbindet, so dass der Server-Overhead dazu neigt, sich in Proportion mit der Anzahl der verbundenen Clients zu erhöhen. Ein gegebener Server kann nur einen begrenzten Overhead gleichzeitig effizient bewältigen. Daher begrenzt der Ansatz, ein Socket je Client (one-socket-per-client) zu verwenden, die Anzahl der Clients, die gleichzeitig auf einen Server zugreifen können, grundlegend. Diese Beschränkung ist in sicheren Umgebungen noch schwerwiegender, da aufgrund des Austausch von Schlüsseln und anderen sicherheitsbezogenen Aspekten noch mehr Overhead je Socket auftritt.
Es ist aus der WO 98/26559 bekannt, ein verteiltes Computersystem (distributed computing system) bereitzustellen und ein Verfahren zum Verteilen von Nutzeranfragen auf nachgebildete Netzwerk-Server (replicated network servers) zu verteilen).
Außerdem ist aus Goldszmidt, G.S. „Load Management for Scaling Up Internet Services"; NOMS 98; IEEE New Orleans, USA 15-20^th Feb 1998; IEEE, US, vol. 3, 15^th February 1998, pp 828-835, bekannt, ein Hilfsmittel bzw. Tool für die Lastverwaltung bei TCP/IP bereitzustellen.
Keines dieser Systeme gemäß dem Stand der Technik betrifft jedoch das Auswählen von einer aus einer Vielzahl von TCP-Verbindungen mit einem einzelnen Server, sondern lehren statt dessen das Auswählen aus einer Vielzahl von Servern.
Zusammenfassende Darstellung der Erfindung
Es werden ein System, ein Verfahren und ein Gerät zum Verbessern der Datenübertragung über ein Computernetzwerk bereitgestellt, wie in den angehängten Ansprüchen dargelegt wird.
Es können Mittel zum Multiplexen und Demultiplexen von HTTP-Anfragen und -Antworten bereitgestellt werden. Das Verfahren kann das Empfangen von HTTP-Anfragen von einer Vielzahl von Clients und das Weiterleiten dieser Anfragen an ein einzelnes Socket des Server-Systems beinhalten. Die HTTP-Anfragen können an ein spezielles Server-Socket weitergeleitet werden, und zwar basierend auf der Antwortzeit (response time) des Sockets, der Art oder der Größe der angefragten Daten und/oder auf anderen Parametern, die im Zusammenhang mit den HTTP-Anfragen stehen. Das Verfahren kann auch das Empfangen von HTTP-Antworten von dem Server-System und das selektive Weiterleiten dieser Anfragen an die entsprechenden Clients beinhalten.
Das Verfahren kann bei einem zwischengelagerten Netzwerkgerät beinhalten, HTTP-Anfragen von mehreren Ursprungs-Clients (originating clients) zu empfangen, die HTTP-Anfragen zu multiplexen und die multiplexten HTTP-Anfragen an ein optimales Server-Socket zu senden. Das Verfahren kann des Weiteren beinhalten, die HTTP-Antworten von dem Server-System zu empfangen, die HTTP-Antworten zu demultiplexen und die demultiplexten HTTP-Antworten an die entsprechenden Ursprungs-Clients zu senden.
Das System weist typischerweise ein Server-System auf, eine Vielzahl von Clients, die in der Lage sind, sich mit dem Server-System über ein Computernetzwerk zu verbinden, und ein Computernetzwerkgerät, das zwischen dem Server-System und den Clients im Computernetzwerk angeordnet ist. Das Computernetzwerkgerät hat typischerweise einen Multiplexer/Demultiplexer für HTTP, der in der Lage ist, HTTP-Anfragen von mehr als einem der Clients zu empfangen und diese Anfragen als eine multiplexte Übertragung an ein Socket in dem Server-System über eine TCP-Verbindung zu verteilen.
Das Gerät weist typischerweise einen Multiplexer/Demultiplexer für HTTP auf, der in der Lage ist, HTTP-Anfragen von einer Vielzahl von Clients zu empfangen und diese Anfragen in multiplexter Form an ein Server-System über eine TCP-Verbindung zu verteilen. Das Gerät ist typischerweise des Weiteren in der Lage, HTTP-Antworten von dem Server-System zu empfangen, die Antworten zu demultiplexen und die demultiplexten Antworten an die entsprechenden Clients zu leiten.
Kurze Beschreibung der Zeichnung
1 ist eine schematische Ansicht einer Netzwerkkonfiguration gemäß dem Stand der Technik.
2 ist eine schematische Darstellung eines Netzwerkgeräts und eines Systems gemäß der vorliegenden Erfindung, einschließlich eines Multiplexers/Demultiplexers für HTTP.
3 ist eine schematische Ansicht des Netzwerkgeräts und des Systems gemäß der 2, in der die Merkmale bezüglich des Weiterleitens, des Multiplexens und des Demultiplexens gezeigt sind, für deren Ausführung das Gerät und das System ausgebildet sein kann.
4 ist eine schematische Ansicht eines Client-Computergeräts, das mit dem Gerät und mit dem System gemäß der 2 verwendet werden kann.
5 ist eine schematische Ansicht einer Ausführungsform des Netzwerkgeräts gemäß der 2.
6 ist eine schematische Ansicht einer weiteren Ausführungsform des Netzwerkgeräts gemäß der 2.
7 ist ein Flussdiagramm eines Verfahrens zum Demultiplexen und Multiplexen von HTTP-Anfragen und -Antworten gemäß einer Ausführungsform der vorliegenden Erfindung.
Detaillierte Beschreibung der Erfindung
Zunächst sei auf 1 Bezug genommen, wo ein Netzwerksystem gemäß dem Stand der Technik allgemein mit 10 bezeichnet ist. Das System 10 weist eine Vielzahl von Remote-Clients (entfernte Clients) 12 und einen Server 14 auf. In dem System 10 ist eine einzelne Transmission Control Protocol (TCP)-Verbindung 16 zwischen jedem Remote-Client 12 und dem Server 14 aufgebaut. Jede TCP-Verbindung 16 wird zwischen einem einzelnen Socket 16a in jedem Remote-Client und einem entsprechenden Socket 16b in dem Server 14 hergestellt, so dass ein 1:1-Verhältnis bezüglich der Sockets besteht. Mit anderen Worten, wird ein Server-Socket für jeden verbundenen Client geöffnet. Die Remote-Clients 12 senden Hypertext Transfer Protocol (HTTP)-Anfragen über bestehende TCP-Verbindungen an einen TCP-Puffer, der dem Server-Socket 16b zugeordnet ist. Die im TCP-Puffer empfangenen Anfragen werden nur so schnell verarbeitet, wie der Server auf sie antworten kann. Oft sammeln sich Anfragen in dem Puffer an, weil der Server nicht schnell genug antworten kann, so dass eine Verzögerung auf der Serverseite (auch als Latenzzeit bezeichnet) häufig entsteht. Dies ist ineffizient und frustrierend und kann dazu führen, dass der Nutzer das Herunterladen der Seite abbricht.
Zudem erfordert jedes geöffnete Server-Socket 16b ein bestimmtes Maß an Overhead-Verarbeitung durch den Server. Diese Overhead-Verarbeitung neigt dazu, sich in Proportion mit der Anzahl der geöffneten Sockets zu erhöhen, und damit in Proportion zu der Anzahl von Clients, die sich mit dem System verbinden. Um akzeptable Antwortzeiten aufrecht zu erhalten, muss das Serversystem die Anzahl von Client-Computern limitieren, die sich zu einer beliebigen Zeit verbinden dürfen, wobei hin und wieder eine Zeitüberschreitung (timing out) bei den bestehenden Client-Verbindungen entsteht.
In der 2 ist ein System zum Verarbeiten von HTTP-Anfragen gemäß einer Ausführungsform der vorliegenden Erfindung allgemein mit 20 bezeichnet. Das System 20 weist typischerweise eine Vielzahl von Remote-Clients 12 auf, die in der Lage sind, sich mit dem Server-System 22 über ein Computer-Netzwerk 24 und ein Netzwerkgerät 26 zu verbinden. Wie man in der 3 erkennen kann, kann das Server-System 22 einen oder mehrere Server 14 aufweisen, einschließlich von Web-Servern, Applikations-Servern und ähnlichen. Bei einer typischerweise verwendeten Konfiguration, weist das Server-System eine Website 25 auf und stellt den Zugang zu ihr bereit. Wie noch genauer unter Bezug auf 3 erläutert wird, werden Verbindungen zwischen Clients 12 und dem Server-System 22 über Client-TCP-Verbindungen 120 auf der „Client-Seite" („client side") des Netzwerkgeräts 26 und über Server-TCP-Verbindungen 124 auf der „Server-Seite" („server side") des Netzwerkgeräts hergestellt. Das Netzwerkgerät 26 kann einen Multiplexer/Demultiplexer für HTTP aufweisen, wie weiter unten noch genauer erklärt wird, der in der Lage ist, die HTTP-Anfragen/Antworten und anderen Netzwerkverkehr zwischen den Clients 12 und dem Server-System 22 weiterzuleiten. Die Funktion des Weiterleitens (routing function) kann dafür ausgelegt sein, das Kombinieren oder Multiplexen von Verkehr, der von mehreren Client-Verbindungen empfangen wird, auf eine einzelne Verbindung in das Server-System bereitzustellen. Bei diesen Ausführungen ist das System typischerweise auch in der Lage, den auf der einzelnen Server-Verbindung empfangenen Verkehr zu trennen oder zu demultiplexen, um ein selektives Weiterleiten und Ausliefern an die entsprechenden verbundenen Clients durchzuführen.
Das Multiplexen und Demultiplexen reduziert die Anzahl der Server-Sockets, die notwendig sind, um eine gegebene Anzahl von verbundenen Clients zu bedienen. Die resultierende Verringerung der Overhead-Verarbeitung, die auf ein Socket bezogen ist, verbessert die Leistungsfähigkeit des Systems und/oder stellt Ressourcen frei, um es mehr Clients zu ermöglichen, sich mit dem System zu verbinden. Zudem ist es so, dass, wenn mehrere Server-Sockets zur Verfügung stehen, das System ausgestaltet werden kann, um die Leistungsfähigkeit weiter zu optimieren, und zwar durch eine Auswahl der Server-Sockets, die auf der Leistungsfähigkeit basiert. So können z.B. HTTP-Anfragen selektiv an ein bestimmtes Server-Socket geleitet werden, und zwar basierend auf einer optimalen Antwortzeit, um eine effiziente Verarbeitung der Anfragen sicherzustellen. Es sollte klar sein, dass der Begriff „Socket", wie er im Zusammenhang mit der vorliegenden Erfindung verwendet wird, sich auf einen Port, Puffer, logischen Knoten oder ein Objekt bezieht, das in der Lage ist, Daten in HTTP und anderen Formaten von einem Remote-Device (entferntes Gerät) über eine Netzwerkverbindung zu empfangen, und nicht auf ein „Socket" beschränkt ist, wie es in der Umgebung des Betriebssystems Unix definiert ist.
Bezugnehmend auf die 4, handelt es sich bei dem Remote-Client 12 typischerweise um einen Personal Computer mit einem Prozessor 30, der mit einem Kommunikationsbus 32 verbunden ist. Mit dem Kommunikationsbus 32 sind des Weiteren ein Massenspeicher 34, wie z.B. eine Festplatte, ein CD-ROM-Laufwerk, ein Bandlaufwerk, etc., und ein Speicher 36 verbunden. Der Speicher 36 weist typischerweise ein Random Access Memory (RAM) 38 und ein Read-Only Memory (ROM) 40 auf. Das ROM 40 weist üblicherweise ein Basic Input/Output System (BIOS) 42 auf, das in der Lage ist, den Remote-Client zu starten und seine grundlegenden Funktionen zu bedienen. Der Remote-Client 12 ist typischerweise dafür ausgelegt, auf ein Computernetzwerk 24 über eine Netzwerkschnittstelle 46 zuzugreifen. Alternativ kann es sich bei dem Remote-Client 12 um einen tragbaren Datenassistenten handeln, ein kabelloses Gerät, das für das Web ausgelegt ist, einen Hauptcomputer oder ein anderes geeignetes Computergerät handeln.
Der Remote-Client 12 ist typischerweise in der Lage, ein Betriebssystem (operating system, OS) 48 auszuführen, um Programme und Applikationen zu verwalten. Das Betriebssystem 48 ist im Massenspeicher 34 gespeichert. Zu den Beispielen von geeigneten Betriebssystemen gehören UNIX, Windows, MacOS, VMS und OS/2, obwohl im Prinzip jedes geeignete Betriebssystem verwendet werden kann. Der Remote-Client 12 weist ein Browserprogramm 50 auf, das in dem Massenspeicher 34 gespeichert ist und in der Lage ist, die angefragten Web-Ressourcen einem Nutzer des Remote-Clients 12 anzuzeigen. Zu den Browserprogrammen 50 zählen beispielsweise der Netscape-Browser, der kommerziell von Netscape Communications Corporation in Santa Clara, Kalifornien erhältlich ist und der Internet Explorer Browser, der kommerziell von der Microsoft Corporation in Redmond, Washington erhältlich ist.
Der Server 14 ist typischerweise auch ein Computer, der dem in der 4 dargestellten ähnelt. Der Server 14 weist typischerweise ein Serverprogramm auf, das in der Lage ist, mit den Remote-Clients unter Verwendung des HTTP-Protokolls zu kommunizieren. Das Server-Programm ist typischerweise in der Lage, HTTP-Anfragen zu empfangen, und als Antwort HTTP-Antworten an den Browser 50 auf einem Remote-Client 24 über das Computernetzwerk 24 zu senden.
Das Netzwerkgerät 26 kann mit dem Server-System 22 und den Remote-Clients 12 auf verschiedene Weisen angeschlossen sein. Auf der Client-Seite ist das Gerät 26 typischerweise mit den Remote-Clients 12 über ein öffentliches Netzwerk verbunden, wie z.B. einem Wide Area Network (WAN) 24, wie man es in den 5 und 6 sehen kann, das ein Teil des Internets bilden kann. Die Verbindung auf der Server-Seite zwischen dem Gerät 26 und dem Serversystem 22 ist üblicherweise ein privates bzw. nicht-öffentliches Netzwerk, wie z.B. ein Intranet oder ein „Local Area Network (LAN) 84".
Die Website 25 weist typischerweise eine Sammlung von Web-Ressourcen auf, die sich typischerweise an einer Adresse im Web (Web-Adresse) befinden, die als URL (Uniform Ressource Locator) bezeichnet wird oder an einer anderen Form eines URI (Uniform Ressource Identifier). Der Begriff „Web-Ressource" bezieht sich im Allgemeinen auf eine Datenquelle, die herunter geladen werden kann oder auf die durch einen Web-Browser zugegriffen werden kann. Web-Ressourcen können Webseiten, ausführbaren Code, Skripte, Grafiken, Video, Klänge, Text und/oder andere Daten enthalten. Web-Ressourcen können statisch sein (z.B. eine gespeicherte Datei) oder dynamisch (z.B. ein dynamisch erzeugter Output). Web-Ressourcen können auf einem einzelnen Server 14 oder auf einer Anzahl von Servern 14 gespeichert sein und von ihm bzw. ihnen bedient werden. Zum Beispiel können Bilder auf einem Server gespeichert sein, wohingegen Code auf einem anderen Server gespeichert ist, und alternativ dazu können Kopien von Bildern und Code auf mehreren redundanten Servern gespeichert sein.
Wie es in der 5 gezeigt ist, weist das Netzwerkgerät 26 typischerweise eine Steuereinheit 70 auf, die einen Speicher 72 und einen Prozessor 74 hat, die mit einem Bus 76 verbunden sind. Mit dem Bus 76 ist auch ein Massenspeicher 78 verbunden, der einen Multiplexer/Demultiplexer 80 aufweist, der auch als „Mux/Demux" bezeichnet wird. Das Netzwerkgerät 26 weist typischerweise auch eine Netzwerkschnittstelle 82 auf, die mit dem Bus 76 verbunden ist. Die Netzwerkschnittstelle 82 ist in der Lage, es dem Netzwerkgerät 26 zu ermöglichen, mit dem Client 12 über das WAN 24 und mit dem Server 22 über das LAN 84 zu kommunizieren. Ein Beispiel einer geeigneten Netzwerkschnittstelle ist die Netzwerkkarte Intel Ethernet Pro 100, die kommerziell von der Intel Corporation in Santa Clara, Kalifornien erhältlich ist.
In der 6 ist eine weitere Ausführungsform eines Netzwerkgeräts gemäß der vorliegenden Erfindung im Allgemeinen mit 26' bezeichnet. Das Netzwerkgerät 26' weist typischerweise eine integrierte Schaltplatine 90 auf. Die integrierte Schaltplatine weist einen Bus 92 auf, der eine Netzwerkschnittstelle 94, einen Speicher 96, einen Prozessor 98, einen Application Specific Integrated Circuit (ASIC) 100 und ein Massenspeichergerät 102 verbindet. Die Netzwerkschnittstelle 94 ist in der Lage, es dem Netzwerkgerät 26' zu ermöglichen, mit dem Remote Client 12 über das WAN 24 und mit dem Serversystem 22 über das LAN 84 zu kommunizieren. ASIC 100 weist typischerweise einen Multiplexer/Demultiplexer 104 auf. ASIC 100, der Prozessor 98 und der Speicher 96 bilden eine Steuereinheit 106, die in der Lage ist, Anfragen bezüglich Web-Ressourcen gemäß den unten beschriebenen Verfahren zu verarbeiten. Es ist klar, dass die Ausgestaltungen des Netzwerkgeräts 26, 26' ein eigenständiges Netzwerkgerät sein oder in einem Web-Server integriert sein können. Außerdem handelt es sich bei dem Massenspeichergerät des Netzwerkgeräts 26, 26' typischerweise um einen Flash-Speicher, ein ROM oder eine andere Form eines nicht flüchtigen Speichers, auch wenn klar ist, dass eine Festplatte oder ein anderes Laufwerk verwendet werden kann.
Wie oben erwähnt wurde, ist das Netzwerkgerät 26 typischerweise mit dem Server-System 22 über das LAN 84 verbunden. Weil die Verbindung auf der Server-Seite eine nicht-öffentliche Verbindung ist, wohingegen die Client-Verbindungen öffentlich sind (z.B., das WAN 24), kann man das Netzwerkgerät 26 als einen Proxy-Server auf der Server-Seite verstehen. Ein Proxy-Server ist ein Programm oder Gerät, das als ein Zwischenelement zwischen einem Browser und einem Server fungiert. Das Netzwerkgerät 26 repräsentiert diese Zwischenstelle, indem es HTTP-Anfragen von den Remote-Clients 12 empfängt und diese Anfragen an ein Socket in dem Server-System 22 sendet und indem es vom Server erzeugte HTTP-Antworten empfängt und diese Antworten an den Remote-Client sendet, von dem die Anfragen kamen.
Die Netzwerkgeräte gemäß der vorliegenden Erfindung werden typischerweise mittels eines durch Software oder Firmware realisierten Multiplexers/Demultiplexers bereitgestellt, der in der Lage ist, den Netzwerkverkehr zwischen Remote-Clients und einem Server-System weiterzuleiten. Typischerweise wird dies erzielt, indem HTTP-Anfragen, die vom Netzwerkgerät 26 über mehrere Client-HTTP-Verbindungen 120 empfangen werden, multiplext werden, so dass diese Anfragen von dem Gerät 26 als eine multiplexte Übertragung an das Server-System 22 weitergeleitet werden. Diese multiplexte Übertragung findet normalerweise über eine einzelne Server-TCP-Verbindung 124 statt, so dass nur ein Socket auf der Server-Seite geöffnet ist. Das Server-System 22 erzeugt dann wiederum HTTP-Antworten, die den verschiedenen Anfragen der Remote-Clients 12 zugeordnet sind. Diese Antworten werden entlang einer einzelnen Server-TCP-Verbindung 124 an das Gerät 26 geliefert, wo sie demultiplext werden, so dass sie selektiv an den entsprechenden Ursprungs-Client 12 weitergeleitet und dort abgeliefert werden können.
Die oben genannte Beschreibung schließt das Weiterleiten des gesamten Verkehrs von mehreren Client-TCP-Verbindungen an eine einzelne TCP-Verbindung auf der Server-Seite ein. Alternativ hierzu, wie man es im Hinblick auf 3 erkennt, können Anfragen und Antworten an und von mehr als ein bzw. einem Server-Socket geleitet werden. Es ist jedoch bevorzugt, dass die Anzahl der verwendeten Server-Sockets kleiner ist als die Anzahl der Client-Verbindungen, um den Overhead, der an der Server-Seite des Systems je Socket auftritt, zu reduzieren. Wie oben bereits erwähnt, kann die Overhead-Verarbeitung die Gesamtleistungsfähigkeit erheblich beeinflussen. Einer der Vorteile des vorliegenden Systems ist eine Reduzierung des Server-Overheads, der auf das Socket bezogen ist, wodurch es den einzelnen Servern ermöglicht wird, mehr Client-Verbindungen zu bewältigen.
In der 3 ist gezeigt, dass jeder Remote-Client 12 eine zugeordnete Client-TCP-Verbindung 120 hat, die mit dem Netzwerkgerät 26 besteht, typischerweise über ein Telekommunikationsnetzwerk, wie z.B. ein WAN 24 (2). Zu jeder Client-Verbindung 120 gehört ein Client-Socket 120a, das einem der Client-Computer 12 zugeordnet ist, und ein Geräte-Socket 120b auf der Client-Seite (oder, einfach Client-Seite-Socket 120b), das dem Netzwerkgerät 26 zugeordnet ist. Die Remote-Clients 12 sind üblicherweise in der Lage, HTTP-Anfragen/Antworten 122 über die Verbindungen 120 zu senden.
Das Server-System 22 ist über mehrere Server-TCP-Verbindungen 124 mit dem Netzwerkgerät 26 verbunden. In ähnlicher Weise wie bei der Client-Seite, weist jede Server-Verbindung 124 ein Geräte-Socket 124b auf der Server-Seite (oder, einfach Server-Seite-Socket 124b), das dem Netzwerkgerät 26 zugeordnet ist, und ein Server-Socket 124a, das dem Server-System 22 zugeordnet ist. Wie bereits erwähnt, kann das Server-System 22 eine Vielzahl von Servern 14 aufweisen, die in der Lage sind, eine Vielzahl von Funktionen durchzuführen. Die Server-Verbindung 124 und die Ihnen zugeordnete Sockets können eine 1:1-Beziehung mit den Servern 14 aufweisen, oder es können mehrere Verbindungen 124 einem bestimmten individuellen Server zugeordnet sein.
Die zuvor beschriebenen Fähigkeiten des Multiplexens, des Demultiplexens und des Weiterleitens ersieht man besser mit Bezugnahme auf die 3. Betrachtet man z.B. die oberen drei Client-Computer auf der rechten Seite der Figur, zeigt die Figur das Kombinieren, (z.B. durch Multiplexen) des Verkehrs, der diesen Client-Computern zugeordnet ist (z.B. die Anfrage/Antwort-Ströme R1, R2 und R3) in eine einzige Server-TCP-Verbindung 124. Dies ermöglicht es mehreren Clients 12, sich mit dem Server-System 22 unter Verwendung lediglich eines Server-Sockets 124a zu verbinden. Dies stellt einen erheblichen Vorteil über herkömmliche Arten der Client-Server-Verbindung dar, die drei getrennte Server-Sockets benötigen würde, um Verbindungen für alle drei Clients bereitzustellen. Indem nur ein Server-Socket verwendet wird, anstelle von dreien, wird die Overhead-Verarbeitung, die auf das Socket bezogen ist, auf der Server-Seite reduziert, wodurch es ermöglicht wird, dass eine größere Anzahl von verbundenen Clients zu jeder Zeit bedient werden kann.
Wie bereits erwähnt, ist das Netzwerkgerät 26 in der Lage, HTTP-Anfragen und -Antworten selektiv zwischen den Client- und Server-Sockets weiterzuleiten. Z.B. ist es so, wie mittels der HTTP-Anfrage/Antwort-Ströme R1, R2 und R3 angezeigt, dass das Netzwerkgerät 26 in der Lage ist, HTTP-Anfragen von einem oder mehreren Client-Computern 12 zu empfangen und diese Anfragen selektiv über eine der Server-Verbindungen 124 an ein bestimmtes Server-Socket 124a weiterzuleiten. Das Netzwerkgerät ist auch in der Lage, HTTP-Antworten von dem Serversystem 22 zu empfangen und diese Antworten an den entsprechenden Ursprungs-Client 12 zurückzuleiten.
Das Netzwerkgerät 26 kann in der Lage sein, Anfragen von mehreren Clients zu multiplexen, z.B. indem die HTTP-Anfragen von mehreren Clients aufgegriffen werden und diese Anfragen über eine einzelne Server-Verbindung 124 an das Server-System 22 weitergeleitet werden. So ist z.B. in der 3 dargestellt, dass HTTP-Anfragen von den oberen drei Clients auf eine einzelne Server-Verbindung 124 multiplext werden. Dieser Prozess wird üblicherweise als Multiplexen bezeichnet, weil der Verkehr von einer Anzahl von Verbindungen 120 der Client-Seite auf eine kleinere Anzahl von Verbindung 124 der Server-Seite geleitet wird, und auch weil eine Vielzahl von Verbindungen 120 der Client-Seite auf eine einzelne Verbindung 124 der Server-Seite geleitet werden kann.
Verschiedene Verfahren können verwendet werden, um die Anfragen zur Übertragung über eine einzelne Verbindung 124 der Server-Seite zu kombinieren. Typischerweise wird ein Multiplex-Statusmittler (multiplexing state agent), wie bei M1-M6 gezeigt, jedem Socket 120b der Client-Seite bei einem Netzwerkgerät zugeordnet. Jeder Multiplex-Statusmittler ist in der Lage, für jede Anfrage, die vom Client empfangen wird, die Anfrage an ein optimales Socket 124b der Server-Seite bei dem Netzwerkgerät weiterzuleiten, und zwar für die Übertragung an einen Server 14 des Server-Systems 22. Wenn eine Antwort auf die Anfrage von dem Server an dem Socket 124b der Server-Seite empfangen wird, ist der Multiplex-Statusmittler in der Lage, die Anfrage zurück an das Socket 124b der Client-Seite an den anfragenden Client zurückzuleiten. Der Multiplex-Statusmittler kann dabei frei entscheiden, nachfolgende Anfragen von demselben Client an ein optimales Socket 124b der Server-Seite zu leiten, egal ob es sich dabei um ein anderes Server-Socket oder das gleiche Server-Socket handelt, wie es bei den vorherigen Anfragen verwendet wurde. Auch wenn jeder Multiplex-Statusmittler üblicherweise dafür ausgelegt ist, Anfragen nur von einem Socket 120b der Client-Seite an ein optimales einer Vielzahl von Sockets 124b der Server-Seite weiterzuleiten, ist es klar, dass alternativ dazu ein einzelner Multiplex-Statusmittler so ausgelegt sein kann, dass Anfragen von mehr als einem Socket 120b der Client-Seite (1) an ein optimales aus einer Vielzahl von Sockets 124b der Server-Seite und/oder (2) an ein einzelnes Socket 124b der Server-Seite zu leiten.
Das Netzwerkgerät 26 kann des Weiteren in der Lage sein, den Antwort-Strom zu demultiplexen, der von Sockets 124b der Server-Seite als Antwort auf die Client-Anfragen empfangen wird. Insbesondere wird eine Reihe von Antworten, die von einem bestimmten Server-Socket empfangen wurden, von dem Multiplex-Statusmittler verarbeitet, der die Transaktionen für das Socket verwaltet, um den Antwortstrom in diskrete Antworten oder in Ströme zu entbündeln, die einem bestimmten der Clients 12 entsprechen. Jeder Multiplex-Mittler ist in der Lage, die Antworten am Socket 124b der Server-Seite zu erkennen, die Anfragen von dem Client entsprechen, dem der Mittler zugeordnet ist, und die Antworten über das Socket 120b der Client-Seite für den Ursprungs-Client zurück an den Ursprungs-Client zu leiten. Dieses Verfahren wird als Demultiplexen bezeichnet, weil eine Reihe von Antworten aus einer einzelnen Verbindung 124 der Server-Seite aufgeteilt wird und über eine Vielzahl von Client-Verbindungen 120 an eine Vielzahl von Clients 12 geleitet wird.
Wie bereits erwähnt, können die Verbindungen 120 der Client-Seite in vielfältiger Weise den Verbindungen 124 der Server-Seite zugeordnet werden. Z.B. kann das System so betrieben werden, dass alle Verbindungen auf eine bestimmte Server- Verbindung multiplext werden. Dort wo Multiplexen verwendet wird, ist das Netzwerkgerät 26 in der Lage, HTTP-Antworten, die von zwei oder mehr Client-Verbindungen (z.B. die Verbindungen, die R1, R2 und R3 zugeordnet sind) in eine einzelne Server-Verbindung zu multiplexen, so dass nur ein Server-Socket geöffnet werden muss. Alternativ hierzu können mehrere Server-Verbindungen verwendet werden, wobei jede Server-Verbindung entweder einer bestimmten Client-Verbindung zugeordnet oder multiplext ist, um so einer Vielzahl von Client-Verbindungen zu entsprechen. In jedem Fall wird es normalerweise wünschenswert sein, dass die Anzahl der Server-Verbindungen geringer ist, als die der Client-Verbindungen, um eine optimale Reduzierung der Overhead-Verarbeitung, die auf ein Socket bezogen ist, auf der Server-Seite des Systems zu erzielen. Unabhängig von der bestimmten Ausgestaltung des Multiplexens, ist das Netzwerk 26 ferner in der Lage, die vom Server-System 22 erzeugten Antworten zu demultiplexen und dafür zu sorgen, dass diese Antworten selektiv an den entsprechenden Ursprungs-Client 12 geleitet werden.
Dort, wo eine Vielzahl von Server-Verbindungen zur Verfügung steht, können verschiedene Ansätze der Optimierung angewendet werden, um die Verzögerung zu reduzieren oder auf andere Weise die Leistungsfähigkeit zu verbessern. Insbesondere kann das Netzwerkgerät 26 in der Lage sein, HTTP-Anfragen an ein optimales Server-Socket weiterzuleiten, wobei es sich typischerweise um das am wenigstens beschäftigte Server-Socket handelt. Um das optimale Server-Socket zu bestimmen, kann der Multiplexer/Demultiplexer 80 (5) in der Lage sein, die Antwortzeit von jedem Server-Socket 124a zu bestimmen, indem die entsprechenden Sockets 124b der Serverseite bei dem Netzwerkgerät überwacht werden. Das Server-Socket mit der schnellsten Antwortzeit kann im Sinne des am wenigsten beschäftigten Server-Sockets verstanden werden. Alternativ dazu, oder zusätzlich, können verschiedene Sockets überwacht werden, um zu bestimmen, welches Server-Socket die am wenigsten nicht-bearbeiteten Anfragen (unfulfilled requests) hat. Außerdem kann das Weiterleiten davon abhängig gemacht werden, auf welches der Server-Sockets zuletzt zugegriffen wurde.
Zusätzlich zu oder anstelle von den oben beschriebenen Techniken zur Optimierung, kann das Netzwerkgerät 26 in der Lage sein, die Art der Anfrage, die gemacht wurde zu bestimmen und/oder die Art der Daten, die angefragt werden, und diese Information zu verwenden, um ein optimales Weiterleiten (routing) zu erzielen. Z.B. können alle Bildanfragen von einer vorbestimmten Gruppe von Sockets des Server-Systems 22 bedient werden, wohingegen alle HTML-Anfragen von einer anderen vorbestimmten Gruppe von Sockets bedient werden. Zusätzlich können bestimmte Sockets dafür vorgesehen sein, bestimmte Protokolle oder Protokollversionen zu bedienen. Z.B. könnte eine Gruppe von Sockets dafür vorgesehen sein, alle Anfragen mit HTTP 1.0 zu bedienen, wobei eine weitere Gruppe dafür vorgesehen ist, Anfragen mit HTTP 1.1 zu bedienen.
Unabhängig von der bestimmten Implementierung, erhöhen diese Techniken der Optimierung die Gesamteffizienz und die Antwortzeit des Server-Systems 22, indem der Fluss von Anfragen weg von langsamen, verstopften Server-Sockets in Richtung von schnellen, verstopfungsfreien Server-Sockets angepasst wird. Diese Technikenoptimierung kann bei den beschriebenen Netzwerkgeräten gemäß der vorliegenden Erfindung zusätzlich oder anstelle der Merkmale bezüglich des Weiterleitens, des Multiplexens und des Demultiplexens verwendet werden, wie sie oben beschrieben wurden.
Typischerweise handelt es sich bei den Verbindungen zwischen dem Netzwerkgerät 26, dem Server-System 22 und den Clients 12 (z.B. den Verbindungen 120 und 124) um dauerhafte TCP-Verbindungen (persistent TCP connections). Dauerhafte TCP-Verbindungen sind Verbindungen, die solange offen bleiben, bis sie explizit geschlossen werden oder bis der Server die Verbindung mit einer Zeitüberschreitung belegt. Alternativ dazu kann eine Verbindung, die eine andere ist als eine dauerhafte TCP-Verbindung, auch verwendet werden. Die effektive Nutzung der dauerhaften Verbindungen ist ein erheblicher Vorteil der vorliegenden Erfindung gegenüber den Systemen gemäß dem Stand der Technik. Üblicherweise wird das Merkmal der Dauerhaftigkeit nicht bei herkömmlichen Netzwerksystemen verwendet, oder wird nur teilweise verwendet, weil das Maß des Overheads, mit dem das System je Verbin dung belastet wird, erheblich ist. Wie es oben erläutert wurde, beschränkt dieser Overhead die Anzahl der Clients, die sich zu jeder Zeit verbinden können, grundlegend. Um Zugang zu einer großen Anzahl von möglichen zu verbindenden Clients bereitzustellen, beenden viele existierende Systeme periodisch die Client-Verbindungen, um es anderen zu ermöglichen, auf das System zuzugreifen. Dies unterbindet im Ergebnis das Merkmal der Dauerhaftigkeit, das bei neueren Netzwerkprotokollen zur Verfügung steht. Das Fehlen der Dauerhaftigkeit ist insbesondere ein Nachteil in sicheren Umgebungen, wie z.B. bei SSL, wo das Aufbauen und Abbauen von TCP-Verbindungen einen Schlüsseltausch sowie andere sicherheitsbezogene Aufgaben einschließt, die einen intensiven Overhead haben. Indem der exzessive Overhead reduziert wird, der es notwendig macht, die Client-Verbindungen periodisch zu beenden, ist das Netzwerkgerät in der Lage, dauerhafte Verbindungen mit den Clients und den Servern aufzubauen und zu unterhalten.
Es ist klar, dass die beschriebenen Netzwerkgeräte und Systeme sehr flexibel sind und in einer nahezu unbegrenzten Anzahl von Möglichkeiten ausgestaltet werden können, um die Leistungsfähigkeit von Client-Server-Netzwerksystemen zu verbessern. Andere Implementierungen des Netzwerkgeräts sind in den ebenfalls anhängigen US-Patentanmeldungen mit den Serien-Nrn. 09/680,675 , 09/680,997 und 09/680,998 , die am 6. Oktober 2000 eingereicht wurden, Nrn. 60/239,552 und 60/239,071 , die am 10. Oktober 2000 eingereicht wurden, Nr. 60/287,188 , die am 27. April 2001 eingereicht wurde, Nr. 60/308,234 , die am 26. Juli 2001 eingereicht wurde und Nr. 60/313,006 , die am 16. August 2001 eingereicht wurde, wobei die dort enthaltenen Offenbarungen hiermit für alle Zwecke in ihrer Gesamtheit durch Bezugnahme in diese Anmeldung aufgenommen werden. Die Merkmale diese Vorrichtungen können auf verschiedene Weise in Verbindung mit den Netzwerkgeräten und den Systemen gemäß der vorliegenden Verbindung implementiert werden.
In der 7 ist gezeigt, wie ein Verfahren 140 gemäß der vorliegenden Erfindung durchgeführt werden kann. Die Schritte des Verfahrens 140 erzielt man üblicherweise mittels eines Netzwerkgeräts 26 in Verbindung mit Remote-Clients 12 und einem Server-System 22, die über die beschriebenen Netzwerkverbindungen kommu nizieren. Alternativ dazu kann man das Verfahren auch mittels einer speziellen Software auf dem Server-System 14 oder durch eine andere Art der Software oder eines Hardware-Geräts realisieren. Wie bei 142 gezeigt, weist das Verfahren typischerweise das Aufbauen bzw. das Herstellen von dauerhaften TCP-Verbindungen zwischen einem Netzwerkgerät 26 und einem oder mehreren Sockets bei einem Server-System 14 auf. Wie bei 144 gezeigt, weist das Verfahren typischerweise das Herstellen von dauerhaften TCP-Verbindungen zwischen dem Netzwerkgerät 26 und einem oder mehreren Remote-Clients 12 auf. Wie bei 146 gezeigt, weist das Verfahren außerdem das Horchen bzw. Warten (Listening) auf HTTP-Anfragen von den ursprünglichen Remote-Clients 12 und/oder auf HTTP-Antworten von den verschiedenen Server-Sockets auf.
Wenn HTTP-Anfragen beim Netzwerkgerät 26 detektiert werden, wird das Verfahren 140 bei 148 fortgesetzt, und zwar mit dem Empfangen von HTTP-Anfragen bei einem oder mehreren Sockets 120b der Client-Seiten. Das Verfahren 140 weist des Weiteren wie bei 150 gezeigt, das Multiplexen von HTTP-Anfragen auf, so dass die multiplexten Anfragen an das Server-System über eine einzelne TCP-Verbindung übertragen werden können. Wie bei 152 gezeigt, weist das Verfahren des Weiteren das Weiterleiten der Anfragen an das Server-System auf, typischerweise, indem die multiplexten Anfragen an ein optimales Server-Socket gesendet werden.
Vor dem Schritt 152 kann das Verfahren 140 auch die Überwachung der Server-Sockets aufweisen, um ein optimales Server-Socket zu bestimmen. Das optimale Server-Socket kann bestimmt werden, indem man ein Server-Socket mit einer am wenigsten langen Antwortzeit identifiziert. Alternativ dazu kann das optimale Server-Socket bestimmt werden, indem man das Server-Socket bestimmt, auf das zuletzt zugegriffen wurde, indem man ein Server-Socket mit den am wenigsten nicht-ausgeführten Anfragen bestimmt, indem man die Art oder die Größe der angefragten Daten oder Parameter bestimmt, die sich auf die HTTP-Anfragen beziehen, oder indem man alle oder einige dieser Bedingungen gewichtet. Indem man ein optimales Server-Socket bestimmt, ist der Multiplexer/Demultiplexer in der Lage, die Leistungs fähigkeit zu verbessern, indem eine effizientere Verwendung der Server-Resourcen erleichtert wird.
Wenn bei dem Multiplexer/Demultiplexer HTTP-Antworten im Schritt 146 erkannt werden, wird das Verfahren 140 bei 154 fortgesetzt und weist das Empfangen von HTTP-Antworten von dem Server-System auf. Der Multiplexer/Demultiplexer ist typischerweise in der Lage, das Ziel aus den HTTP-Antworten zu bestimmen. Wie in 156 gezeigt, weist das Verfahren das Demultiplexen der HTTP-Antworten auf, die von dem Server-System empfangen wurden, um ein selektives Weiterleiten und Ausliefern von einigen dieser Antworten bei dem entsprechenden Ursprungs-Client zu ermöglichen. Wie bei 158 gezeigt, weist das Verfahren 140 das Senden der demultiplexten Antworten an den ursprünglichen Remote-Client auf.
Wenn ein neuer Remote-Client oder Server bei 160 erkannt wird, weist das Verfahren das Rückkehren zum Schritt 144 auf, um eine dauerhafte TCP-Verbindung mit dem neuen Remote-Client aufzubauen, oder kehrt zum Schritt 142 zurück, um eine dauerhafte TCP-Verbindung mit dem neuen Server aufzubauen, jeweils entsprechend. Es ist auch klar, dass das Netzwerkgerät 26 in der Lage sein kann, eine Vielzahl von TCP-Verbindungen mit einer Vielzahl von Servern und einer Vielzahl von Remote-Clients aufzubauen, so dass es in der Lage ist, TCP-Anfragen und HTTP-Antworten von mehreren Servern und Remote-Clients gleichzeitig zu bewältigen.
Ähnlich wie die oben beschriebenen Geräte und Systeme, verbessert das beschriebene Verfahren die Leistungsfähigkeit von Client-Server-Netzwerksystemen. Dies wird durch das Multiplexen und Demultiplexen von HTTP-Anfragen/Antworten erzielt, um die Overhead-Verarbeitung zu reduzieren, die sich bei herkömmlichen Systemen aus dem Öffnen eines Server-Sockets für jeden Client-Computer ergeben, der sich mit dem Server verbindet. Dies ermöglicht auch eine bessere Nutzung der Merkmale für eine dauerhafte Verbindung, die nun im Zusammenhang mit HTTP und anderen Protokollen zur Verfügung stehen. Zusätzlich oder alternativ dazu kann das Verfahren die Auswahl von optimalen Server-Sockets aufweisen, um die Server-Effizienz weiter zu verbessern.
Auch wenn die vorliegende Erfindung hier insbesondere im Hinblick auf die vorgenannten bevorzugten Ausgestaltungen gezeigt und beschrieben wurden, ist es dem Fachmann auf diesem Gebiet klar, dass viele Abwandlungen gemacht werden können, ohne dabei den Bereich der Erfindung zu verlassen, wie er sich aus den nachfolgenden Ansprüchen ergibt. Die Beschreibung der Erfindung sollte dahingehend verstanden werden, dass alle neuen und nicht-offensichtlichen Kombinationen der hier beschriebenen Elemente umfasst sein sollen, und dass Ansprüche in dieser oder späteren Anwendungen bezüglich jeder neuen und nicht-offensichtlichen Kombination dieser Elemente aufgestellt werden können. Dort wo die Ansprüche von „ein" oder „ein erstes" Element oder den entsprechenden Äquivalenten davon sprechen, sollten die Ansprüche dahingehend verstanden werden, dass ein solches Element oder mehrerer solcher Elemente davon umfasst sind, und dass das Vorhandensein von zwei oder mehr Elementen weder erforderlich noch ausgeschlossen ist.

Claims

Computernetzwerkgerät (26) zum Verbessern der Datenübertragung mittels eines Computernetzwerks (20), wobei das Computernetzwerkgerät (26) dafür ausgebildet ist, HTTP (Hypertext Transfer Protocol)-Anfragen von einer Vielzahl von Clients (12) über eine Vielzahl von Client-TCP (Transmission Control Protocol)-Verbindungen (120) zu empfangen, und wobei das Computernetzwerkgerät (26) dadurch gekennzeichnet ist, dass es des Weiteren dafür ausgebildet ist: für jede aus einer Vielzahl von Server-TCP-Verbindungen (124) von dem Computernetzwerkgerät (26) mit einem einzelnen Server (14) zumindest einen Antwortparameter zu überwachen; basierend auf dem überwachten Antwortparameter eine der Vielzahl von Server-TCP-Verbindungen (124) auszuwählen; und die HTTP-Anfragen über die ausgewählte Server-TCP-Verbindung (124) an ein entsprechendes Socket (124a) auf dem Server (14) als eine multiplexte HTTP-Anfrage zu leiten.
Computernetzwerkgerät (26) nach Anspruch 1, ferner mit einem HTTP-Multiplexer/Demultiplexer (104), der dafür ausgebildet ist: für jede aus einer Vielzahl von Server-TCP-Verbindungen (124) von dem Computernetzwerkgerät (26) zu dem Server (14) zumindest einen Antwortparameter zu überwachen; eine der Vielzahl von Server-TCP-Verbindungen (124) basierend auf dem überwachten Antwortparameter auszuwählen; und die HTTP-Anfragen über die ausgewählte Server-TCP-Verbindung (124) an ein entsprechendes Socket (124a) auf dem Server (14) als eine multiplexte HTTP-Anfrage zu leiten.
Computernetzwerkgerät (26) nach Anspruch 2, wobei der HTTP-Multiplexer/Demultiplexer (104) des Weiteren dafür ausgebildet ist, HTTP-Antworten von dem Server (14) über die ausgewählte Server-TCP-Verbindung (124) zu empfangen und diese Antworten an die Clients (12) über die Vielzahl von Client-TCP-Verbindungen (120) zu leiten.
Computernetzwerkgerät (26) nach Anspruch 2 oder 3, wobei der HTTP-Multiplexer/Demultiplexer (104) eine Vielzahl von Vermittlern aufweist, von denen jeder Vermittler einer anderen der Client-TCP-Verbindungen (120) zugeordnet ist; und wobei beim Empfang einer der HTTP-Anfragen von einem der Clients (12), der entsprechende Vermittler eine aus der Vielzahl der Server-TCP-Verbindungen (124) basierend auf dem Antwortparameter auswählt und die HTTP-Anfrage an die ausgewählte Server-TCP-Verbindung (124) leitet.
Computernetzwerkgerät (26) nach einem der Ansprüche 2 bis 4, wobei der HTTP-Multiplexer/Demultiplexer (104) dafür ausgebildet ist, die Server-TCP-Verbindung (124) zum Empfangen der multiplexten HTTP-Anfragen auszuwählen, indem die Server-TCP-Verbindung (124) bestimmt wird, die die am wenigsten lange Antwortzeit basierend auf der Überwachung hat.
Computernetzwerkgerät (26) nach einem der vorhergehenden Ansprüche, wobei die Server-TCP-Verbindungen (124) dauerhaft sind.
Computernetzwerksystem zur Verwendung mit einem Computernetzwerk (20), das System aufweisend: einen Server (14); eine Vielzahl von Clients (12); und ein Computernetzwerkgerät (26) nach einem der vorhergehenden Ansprüche, das zwischen dem Server (14) und der Vielzahl von Clients (12) angeordnet ist.
Computernetzwerkverfahren zum Verarbeiten von HTTP (Hypertext Transfer Protocol)-Anfragen von einer Vielzahl von Clients (12) über eine Vielzahl von Client-TCP (Transmission Control Protocol)-Verbindungen (120), das Verfahren gekennzeichnet durch: Überwachen einer Vielzahl von Server-TCP-Verbindungen (124) von einem Computernetzwerkgerät (26) mit einem einzelnen Server (14), um zumindest einen Antwortparameter für jede der Server-TCP-Verbindung (124) zu ermitteln; Auswählen einer der Server-TCP-Verbindungen (124) basierend auf dem ermittelten Antwortparameter; und Leiten der HTTP-Anfragen an ein einzelnes Netzwerk-Socket (124a) auf dem Server (14) über eine Server-TCP-Verbindung (124) als eine multiplexte HTTP-Anfrage.
Verfahren nach Anspruch 8, wobei der Antwortparameter ausgewählt ist aus einer Gruppe bestehend aus der am wenigsten langen Antwortzeit, dem Socket, auf das zuletzt zugegriffen wurde, der geringsten Anzahl von nicht-erfüllten Anfragen, der Art der angefragten Daten und der Größe der angefragten Daten.
Verfahren nach Anspruch 8 oder 9, ferner aufweisend: Empfangen von HTTP-Antworten von dem Server (14) über die ausgewählte Server-TCP-Verbindung (124); und selektives Leiten der HTTP-Antworten an die Vielzahl von Ursprungs-Clients (12) über die Client-TCP-Verbindungen (120).
Verfahren nach einem der Ansprüche 8 bis 10, wobei die Client-(120) und Server-(124)TCP-Verbindungen dauerhaft sind.
Verfahren nach einem der Ansprüche 8 bis 11, wobei das Auswählen einer der Server-TCP-Verbindungen (124) basierend auf dem ermittelten Antwortparameter, ein Bestimmen eines Server-Sockets (124a) mit einer am wenigsten langen Antwortzeit aufweist.
Verfahren nach einem der Ansprüche 8 bis 12, wobei das Auswählen einer der Server-TCP-Verbindungen (124) basierend auf dem ermittelten Antwortparameter, ein Bestimmen eines Server-Sockets (124a), auf das zuletzt zugegriffen wurde, aufweist.
Verfahren nach einem der Ansprüche 8 bis 13, wobei das Auswählen einer der Server-TCP-Verbindungen (124) basierend auf dem ermittelten Antwortparameter, das Bestimmen eines Server-Sockets (124a) mit der geringsten Anzahl an nicht-erfüllten Anfragen aufweist.
Verfahren nach einem der Ansprüche 8 bis 14, des Weiteren aufweisend ein Horchen nach HTTP-Antworten von dem einzelnen Server-Socket (124a).
Verfahren nach Anspruch 15, des Weiteren aufweisend ein Empfangen von HTTP-Antworten von dem einzelnen Server-Socket (124a) über die ausgewählte Server-TCP-Verbindung (124).
Verfahren nach Anspruch 16, ferner aufweisend ein Demultiplexen der empfangenen HTTP-Antworten um ein selektives Leiten und Übertragen der empfangenen Antworten an die entsprechenden Ursprungs-Clients (12) zu ermöglichen.
Verfahren nach Anspruch 17, ferner aufweisend ein Senden der demultiplexten HTTP-Antworten an die entsprechenden Ursprungs-Clients (12) über die entsprechenden Client-TCP-Verbindungen (120).