DE69934871T2 - Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk - Google Patents

Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk Download PDF

Info

Publication number
DE69934871T2
DE69934871T2 DE69934871T DE69934871T DE69934871T2 DE 69934871 T2 DE69934871 T2 DE 69934871T2 DE 69934871 T DE69934871 T DE 69934871T DE 69934871 T DE69934871 T DE 69934871T DE 69934871 T2 DE69934871 T2 DE 69934871T2
Authority
DE
Germany
Prior art keywords
server
proxy
web
firewall
socks
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69934871T
Other languages
English (en)
Other versions
DE69934871D1 (de
Inventor
Olivier Daude
Olivier Hericourt
Andrew Richmond Forth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Trend Micro Inc
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of DE69934871D1 publication Critical patent/DE69934871D1/de
Application granted granted Critical
Publication of DE69934871T2 publication Critical patent/DE69934871T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2854Wide area networks, e.g. public data networks
    • H04L12/2856Access arrangements, e.g. Internet access
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0803Configuration setting
    • H04L41/0823Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability
    • H04L41/083Configuration setting characterised by the purposes of a change of settings, e.g. optimising configuration for enhancing reliability for increasing network speed
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0209Architectural arrangements, e.g. perimeter networks or demilitarized zones
    • H04L63/0218Distributed architectures, e.g. distributed firewalls
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1008Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1029Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers using data related to the state of servers by a load balancer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1036Load balancing of requests to servers for services different from user content provisioning, e.g. load balancing across domain name servers
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0876Aspects of the degree of configuration automation
    • H04L41/0879Manual configuration through operator
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08Configuration management of networks or network elements
    • H04L41/0876Aspects of the degree of configuration automation
    • H04L41/0886Fully automatic configuration
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/08Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852Delays
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00Arrangements for monitoring or testing data switching networks
    • H04L43/12Network monitoring probes
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1021Server selection for load balancing based on client or server locations
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/10Protocols in which an application is distributed across nodes in the network
    • H04L67/1001Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004Server selection for load balancing
    • H04L67/1023Server selection for load balancing based on a hash applied to IP addresses or costs

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • Computer And Data Communications (AREA)
  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Small-Scale Networks (AREA)

Description

  • TECHNISCHES GEBIET DER ERFINDUNG
  • Die vorliegende Erfindung betrifft Computernetze und insbesondere ein Verfahren und ein System in einem TCP/IP-Netz zur optimalen Auswahl einer Webfirewall gemäß bestimmten Kriterien der Antwortzeit und Verfügbarkeit.
  • ZUGRUNDE LIEGENDE TECHNIK
  • INTERNET
  • Das Internet ist ein globales Netz von Computern und Computernetzen (das „Netz"). Das Internet verbindet Computer, die eine Vielfalt von verschiedenen Betriebssystemen oder -sprachen verwenden, einschließlich UNIX, DOS, Windows, Macintosh und andere. Um die Kommunikation zwischen diesen verschiedenen Systemen und Sprachen zu erleichtern und zu ermöglichen, verwendet das Internet eine als TCP/IP bezeichnete Sprache („Transmission Control Protocol/Internet Protocol", Übertragungskontrollprotokoll/Internetprotokoll). Das TCP/IP-Protokoll unterstützt im Internet drei Hauptanwendungen:
    • • Übertragen und Empfangen von elektronischer Post,
    • • Einwählen in ferne Computer (das „Telnet"), und
    • • Übertragen von Dateien und Programmen von einem Computer an einen anderen Computer durch das FTP („File Transfer Protocol", Dateiübertragungsprotokoll).
  • WORLD WIDE WEB
  • Mit der zunehmenden Größe und Komplexität des Internets sind Tools zur Suche nach Informationen im Internet entwickelt worden, die oft als Navigatoren oder Navigationssysteme bezeichnet werden. Die entwickelten Navigationssysteme folgen solchen Standards wie Archie, Gopher und WAIS. Das World Wide Web („WWW" oder „das Web") ist ein modernes leistungsfähiges Navigationssystem. Das Web ist:
    • • ein internetbasiertes Navigationssystem,
    • • ein Informationsverbreitungs- und -verwaltungssystem für das Internet, und
    • • ein dynamisches Format zum Kommunizieren im Web.
  • Das Web integriert zur praktischen Nutzung nahtlos Datenformate wie Standbilder, Text, Audio- und Videodateien. Ein Benutzer im Web, der eine grafische Benutzeroberfläche (Graphical User Interface, „GUI", Aussprache: „Guui") verwendet, kann auf transparente Weise mit verschiedenen Hosts im System, verschiedenen Systemanwendungen (einschließlich FTP und Telnet) und verschiedenen Datenformaten für Dateien und Dokumente kommunizieren, zum Beispiel für Text, Audiodateien und Grafiken.
  • HYPERMEDIA
  • Das Web verwendet Hypertext und Hypermedia. Hypertext ist eine Teilmenge von Hypermedia und bezieht sich auf rechnerbasierte „Dokumente", in denen sich Leser auf nicht lineare Weise von einer Stelle des Dokuments zur anderen oder zu einem anderen Dokument bewegen können. Zu diesem Zweck verwendet das Web eine Client-Server-Architektur. Die Web-Server ermöglichen dem Benutzer den Zugriff auf Hypertext- und Hypermediainformationen über das Web und den Computer des Benutzers. (Der Computer des Benutzers wird als Client-Computer der Webserver-Computer bezeichnet.) Die Clients senden Anforderungen an die Webserver, die darauf reagieren, suchen und antworten. Das Web gestattet einer Anwendungssoftware des Clients, durch Hypertext-Links auf andere Hypermediadokumente diese Hypermediadokumente (einschließlich formatierter Text-, Audio-, Video- und Grafikdateien) von einem Webdateiserver anzufordern und zu empfangen. Ferner kann das Web als eine Ansammlung von Dokumentdateien angesehen werden, die in Web-Hosts untergebracht sind, die unter Verwendung von Netzprotokollen durch Hyperlinks miteinander verbunden sind und ein das Internet abdeckende virtuelles „Web" bilden.
  • URL
  • Eine Ressource des Internet wird durch eine Internetadresse (Uniform Resource Locator, URL) eindeutig gekennzeichnet, die ein Zeiger auf eine bestimmte Ressource an einem bestimmten Ort ist. Eine URL gibt das für den Zugriff auf einen Server verwendete Protokoll (z.B. HTTP, FTP, ...), den Namen des Servers und den Speicherplatz einer Datei auf diesem Server an.
  • HYPERTEXTÜBERTRAGUNGSPROTOKOLL
  • Jede auf Client-Monitoren des Web dargestellte Webseite kann als komplexes Dokument erscheinen, das zum Beispiel Text, Bilder, Klänge und bewegte Bilder in sich vereint. Jede derartige Webseite kann auch Hyperlinks auf andere Webdokumente enthalten, sodass ein Benutzer an einem Client-Computer durch Anklicken von Symbolen mit einer Maus Hyperlinks zum Springen auf eine neue Seite auf demselben oder einem anderen Webserver aktivieren kann (die eine grafische Darstellung einer anderen Dokumentdatei ist).
  • Ein Webserver ist ein Softwareprogramm auf einen Web-Host, der Anforderungen von Web-Clients üblicherweise über das Internet beantwortet. Das gesamte Web verwendet zur Kommunikation mit Web-Clients eine Sprache oder ein Protokoll, das als Hypertextübertragungsprotokoll (Hyper Text Transfer Protocol, „HTTP") bezeichnet wird. Unter Verwendung dieses Protokolls können alle Arten von Daten zwischen Web-Servern und -Clients ausgetauscht werden, einschließlich der Sprache zur Markierung von Hypertext (Hyper Text Markup Language, „HTML"), Grafik-, Audio- und Videodateien. HTML beschreibt die Gestaltung, die Inhalte und Hyperlinks der Dokumente und Seiten. Wenn Web-Clients nach Dokumenten suchen:
    • • wandeln sie Befehle des Benutzers in Abrufanforderungen in HTTP um,
    • • stellen sie zum Abrufen der Informationen eine Verbindung zu dem richtigen Web-Server her, und
    • • warten sie auf eine Antwort. Die Antwort vom Server kann in dem angeforderten Dokument oder in einer Fehlermeldung bestehen.
  • Nachdem das Dokument oder eine Fehlermeldung zurückgesendet worden sind, wird die Verbindung zwischen dem Web-Client und dem Web-Server getrennt.
  • Die erste Version von HTTP stellt ein statusfreies Protokoll dar. Das heißt, beim HTTP gibt es keine ununterbrochene Verbindung zwischen jedem Client und jedem Server. Der das HTTP verwendende Web-Client empfängt eine Antwort in Form von HTML-Daten oder anderen Daten. Diese Beschreibung gilt für die Version 1.0 des HTTP-Protokolls, während die neuere Version 1.1 diese Hürde des statusfreien Protokolls überwindet, indem die Verbindung zwischen dem Server und dem Client unter bestimmten Bedingungen erhalten bleibt.
  • BROWSER
  • Nach dem Empfangen der Daten formatiert der Web-Client die Daten und stellt sie dar oder aktiviert zur Darstellung der Daten eine Hilfsanwendung wie beispielsweise ein Audiowiedergabeprogramm. Zu diesem Zweck ermittelt der Server oder der Client die verschiedenen Arten der empfangenen Daten. Der Web-Client wird auch als Web-Browser bezeichnet, da dieser im Grunde die vom Web-Server empfangenen Dokumente durchsucht.
  • DOMÄNENNAMEN
  • Die Host- oder Computernamen (beispielsweise www.entreprise.com) werden unter Verwendung eines Verfahrens mit der Bezeichnung DNS („Domain Name System", Domänennamensystem) in eine numerische Internetadresse (beispielsweise 194.56.78.3) übersetzt oder umgekehrt. Das DNS wird durch Server im Netz unterstützt, die als Domänennamen-Server oder DNS-Server bekannt sind.
  • INTRANET
  • Manche Unternehmen nutzen zur Kommunikation innerhalb ihrer eigenen Gesellschaft denselben Mechanismus wie das Web. In diesem Falle wird dieser Mechanismus als „Intranet" bezeichnet. Diese Unternehmen nutzen dieselben Netz-/Transportprotokolle und lokalen Web-Server, um den ungeteilten Zugriff auf riesige Mengen von Unternehmensdaten zu ermöglichen. Da diese Daten unternehmensintern sein können und die Mitarbeiter des Unternehmens trotzdem den Zugriff auf öffentliche Webdaten benötigen, schützen sie den Zugriff auf ihr Netz durch die Verwendung einer speziellen Einrichtung mit der Bezeichnung Firewall, damit nicht zum Unternehmen gehörende Personen aus dem öffentlichen Internet nicht auf dieses private Intranet zugreifen können.
  • FIREWALL
  • Eine Firewall schützt einen oder mehrere Computer mit Internetverbindungen vor dem Zugriff durch mit dem Internet verbundene externe Computer. Eine Firewall ist eine Netzkonfiguration, die für gewöhnlich aus Hardware und Software besteht und eine Abgrenzung zwischen vernetzten Computern innerhalb der Firewall gegen solche außerhalb der Firewall bildet. Die Computer innerhalb der Firewall bilden ein sicheres Teilnetz mit internen Zugriffsmöglichkeiten und gemeinsamen Ressourcen, die für außenstehende Computer nicht zugänglich sind.
  • Oft erlaubt ein einzelner Computer, auf dem sich die Firewall befindet, den Zugriff sowohl auf interne als auch auf externe Computer. Da der Computer, auf welchem sich die Firewall befindet, direkt mit dem Internet interagiert, sind gegen den unerwünschten Zugriff von externen Computern konsequente Sicherheitsmaßnahmen erforderlich.
  • Eine Firewall dient gewöhnlich zum Schutz solcher Informationen wie elektronische Post und Datendateien innerhalb eines Gebäudes oder des Standortes einer Organisation. Eine Firewall verringert das Risiko des Eindringens unberechtigter Personen aus dem Internet, jedoch können dieselben Sicherheitsmaßnahmen den Zugriff für diejenigen Personen beschränken oder spezielle Software erfordern, die auf Informationen von außen zugreifen wollen. Eine Firewall kann unter Verwendung von Proxy-Servern oder SOCKS-Computern konfiguriert werden, um den Zugriff auf Informationen von beiden Seiten der Firewall zu erlauben.
  • PROXY-SERVER
  • Ein HTTP-Proxy ist ein spezieller Server, der normalerweise in Verbindung mit der Firewall-Software läuft und einen Zugriff auf das Internet von innen durch die Firewall erlaubt. Der Proxy-Server:
    • • wartet auf eine Anforderung (zum Beispiel eine HTTP-Anforderung) von innerhalb der Firewall,
    • • leitet die Anforderung an den fernen Server außerhalb der Firewall weiter,
    • • liest die Antwort, und
    • • sendet die Antwort zum Client zurück.
  • Ein einzelner Computer kann mehrere Server realisieren, wobei jede Serververbindung durch eine Anschlussnummer gekennzeichnet wird. Ein Proxy-Server belegt ebenso wie ein HTTP-Server oder ein FTP-Server einen Anschluss. Normalerweise verwendet eine Verbindung für jedes Protokoll standardisierte Anschlussnummern (zum Beispiel HTTP = 80 und FTP = 21). Aus diesem Grunde muss ein Endbenutzer für jeden definierten Proxy-Server eine bestimmte Anschlussnummer auswählen. Webbrowser verlangen normalerweise vom Endbenutzer die Eingabe des Hostnamens und der Anschlussnummer der Proxy-Server in einem einstellbaren Fenster. Protokolle wie HTTP, FTP, Gopher, WAIS und Security können für gewöhnlich spezielle Proxy-Server haben. Proxy-Server werden im Allgemeinen wegen ihrer Fähigkeit zur Zwischenspeicherung (Caching), zur Protokollierung auf höherer Ebene und der Zugriffskontrolle gegenüber SOCKS bevorzugt, da sie für jedes Netzprotokoll eine bestimmte Verbindung bereitstellen.
  • SOCKS
  • SOCKS-Server (auch als SOCKS-Gateway bezeichnet) ist auch eine Software, die Computern innerhalb einer Firewall den Zugriff auf das Internet gestattet. SOCKS wird normalerweise auf einem Server installiert, der entweder innerhalb oder auf der Firewall steht. Computer innerhalb der Firewall greifen als Clients auf den SOCKS-Server zu, um in das Internet zu gelangen. Webbrowser verlangen üblicherweise vom Endbenutzer die Eingabe des Hostnamens und der Anschlussnummer der SOCKS-Hosts (Server) in einem einstellbaren Fenster. Bei einigen Betriebssystemen wird der Host in einer separaten Datei (z.B. der Datei socks.conf) angegeben. Da der SOCKS-Server unterhalb der Protokollschicht (HTTP, FTP, ...) wirksam ist, kann er (im Gegensatz zum Proxy-Server) keine Daten zwischenspeichern, da er das Protokoll nicht decodiert, um die Art der durch ihn übertragenen Daten zu erfahren.
  • OPTIONEN
  • Der Webbrowser schlägt dem Endbenutzer oft vor, zwischen den verschiedenen Optionen „Kein Proxy", „Manuelle Proxykonfiguration" oder „Automatische Proxykonfiguration" zu wählen, um den Weg zwischen seinem Computer und dem Internet festzulegen.
    • • Benutzer mit einer direkten Verbindung zum Internet sollten die Standardeinstellung „Kein Proxy" verwenden.
    • • Wenn das Intranet durch eine oder mehrere Firewalls geschützt ist, kann der Endbenutzer: • eine dieser Firewalls als seinen Proxy-Server auswählen, indem er seinen Hostnamen in die „Manuelle Proxykonfiguration" eingibt, oder • automatisch die Unternehmensstrategie durch die Zuweisung von Proxy-Servern auf bestimmte Standorte akzeptieren, indem er auf eine gemeinsame Konfigurationsdatei in einem fernen Server zeigt. Dies erfolgt durch die Auswahl der Alternative „Automatische Proxykonfiguration" und durch Angeben der eindeutigen Adresse der gemeinsamen Konfigurationsdatei (URL) an den Webbrowser, die sich in dem fernen Server befindet.
  • Heutzutage sind die meisten Webbrowser so konfiguriert, dass sie alle Anforderungen, sogar Anforderungen für interne Hosts, durch die SOCKS-Firewall weiterleiten. Wenn also der Endbenutzer den Zugriff auf eine interne webbasierte Anwendung wünscht, wird seine Anforderung zur Firewall geleitet und von dort wieder in das interne Netz zurückgeleitet. Dieses schickt den internen Datenverkehr auf einen langen Weg, belastet die Firewall und das Netz zusätzlich und, was am schlimmsten ist, verzögert die Antwort, was der Endbenutzer an den Anwendungen und Webseiten erkennt, auf die er zuzugreifen versucht. Dies wird als „unflexibler" SOCKS-Zugriff bezeichnet (wenn alles über den SOCKS-Server abgewickelt wird).
  • MANUELLE PROXYKONFIGURATION
  • Die manuelle Proxykonfiguration im Webbrowser lässt sich einfach einstellen, jedoch besteht ihr Nachteil darin, dass die Auswahl der Firewall (oder des Proxy-Servers) dann statisch ist. Es gibt kein dynamisches Kriterium für die Auswahl der Firewall, zum Beispiel die Auswahl derjenigen Firewall, die die kürzeste Antwortzeit bietet. Wenn eine Firewall ausfällt, muss die Navigationssoftware manuell neu konfiguriert werden, damit sie auf eine andere aktive Firewall zeigt, da die manuelle Konfiguration für gewöhnlich nur die Definition einer einzigen Firewall für jedes Protokoll erlaubt und keine Möglichkeit zum Vorkonfigurieren einer Reserve-Firewall vorsieht. Zusätzlich zur manuellen Proxykonfiguration im Webbrowser können externe Prozeduren verwendet werden, um die Auswahl der Firewall etwas stabiler zu gestalten. Bei diesen Prozeduren können zum Beispiel mehrere Firewalls mit demselben Namen verwendet werden, die im Domänennamenserver (DNS) als Pseudonyme (Alias) definiert sind. Dieses auf der Pseudonymdefinition basierende Verfahren weist jedoch noch Nachteile auf, da der DNS zum Beispiel nicht immer zur Auflösung des Namens durch die Web-Clients aufgerufen wird, in denen die Namensauflösung lokal zwischengespeichert ist. Andere Techniken unter Verwendung externer Hardwareausrüstung wie beispielsweise die Last- und Anforderungsabwicklung machen das System stabiler und gleichen die Last aus, weisen jedoch immer noch Nachteile auf, beispielsweise den Bedarf an zusätzlicher und teurer Hardware.
  • AUTOMATISCHE PROXYKONFIGURATION
  • Die automatische Proxykonfiguration (die auch als „Autoproxy" bezeichnet wird) kann den Standort des HTTP-, FTP- und Gopher-Proxy-Servers bei jedem Start des Webbrowsers neu einstellen. Eine Autoproxy ruft eine Datei mit Adressbereichen ab und weist den Webbrowser an, entweder direkt auf interne IBM Hosts oder über den SOCKS-Server auf Hosts im Internet zuzugreifen.
  • Die automatische Proxykonfiguration ist eher zu empfehlen als die einfache Proxy-Serverkonfiguration im Webbrowser, da detailliertere Regeln für den Weg vorgegeben werden können, über den Webseiten (direkt oder indirekt) abgerufen werden.
  • Die automatische Proxykonfiguration ist für Benutzer von Vorteil, da dem Webbrowser bekannt ist, wie Seiten bei Ausfall des Proxy-Servers direkt abgerufen werden können. Proxyanforderungen können auf Veranlassung des Systemadministrators auch an einen oder mehrere andere Proxy-Server gerichtet werden, ohne dass der Endbenutzer an der Konfiguration seines Webbrowsers Änderungen vornehmen muss. Im Allgemeinen sind die Dateien für diese Proxykonfiguration (die auch als Autoproxy-Code bezeichnet werden) in der Sprache Javascript geschrieben. Die Autoproxyeinstellung kann auch eine Datei mit Adressbereichen enthalten, um den Webbrowser anzuweisen, entweder direkt auf interne Hosts oder über den SOCKS-Server auf Hosts im Internet zuzugreifen. Der SOCKS-Server schützt das interne Netz vor unerwünschtem öffentlichem Zugriff, gestattet jedoch den Teilnehmern des Netzes den Zugriff auf das Internet. Einer der Nachteile dieses „Autoproxy"-Mechanismus besteht darin, dass weder Ausfälle der Firewall aktiv erkannt werden noch die Antwortzeit in Betracht gezogen wird.
  • Weitere Erläuterung über das in den obigen Abschnitten dargestellte Thema sind in den folgenden Veröffentlichungen zu finden:
    • • „Java Network Programming", von Elliotte Rusty Harald, erschienen bei O'Reilly, Februar 1997.
    • • „Internet in a nutshell", von Valerie Quercia, erschienen bei O'Reilly, Oktober 1997.
    • • „Building Internet Firewalls", von Brent Chapman und Elizabeth Zwichky, erschienen bei O'Reilly, September 1995.
  • PROBLEM
  • Das zu lösende Problem besteht darin, einen optimalen Webzugriff zu schaffen, verbunden mit einer dynamischen Proxy- oder SOCKS-Serverauswahl zum Erreichen der günstigsten Antwortzeit und einer Erkennung von Fehlern im Proxy- oder im SOCKS-Server, um Unterbrechungen der Internet-Verbindung zu verhindern. Die gegenwärtig zur Verfügung stehenden Lösungen widmen sich diesem Problem nur teilweise:
    • • Webbrowser können manuell mit dem Ziel-Proxy- oder mit dem SOCKS-Server konfiguriert werden. Folgende Hauptnachteile sind mit dieser Lösung verbunden: • Es gibt keine dynamische Proxy-/SOCKS-Serverauswahl. Bei Ausfall des Proxy-/SOCKS-Servers muss der Webbrowser manuell neu konfiguriert werden. • Durch die statische Konfiguration des Webbrowsers ist nur ein „manueller" Lastausgleich möglich. • Die Namen der Proxy-/SOCKS-Server müssen bekannt sein und durch die Endbenutzer manuell konfiguriert werden.
    • • Webbrowser können mit ihren Autoproxydaten konfiguriert werden, indem von einem speziellen Autoproxy-URL-System eine statische Liste mit Proxy-/SOCKS-Servern heruntergeladen wird. Mit dieser Lösung ist der folgende Hauptnachteil verbunden: • Bei der Proxy-/SOCKS-Serverauswahl wird weder die Antwortzeit berücksichtigt noch für eine wirksame Erkennung von Fehlern des Proxy-/SOCKS-Servers gesorgt (d.h. der Webbrowser wartet selbst zu Anfang beim Laden der Autoproxyfunktion eine Zeitlimitüberschreitung ab, bevor er auf einen Reserve-Server umschaltet).
  • Eine Alternative zu diesen gegenwärtig üblichen Lösungen besteht im Zusammenschließen der Proxy-/SOCKS-Server zu einer Gruppe unter Verwendung eines externen Zuteilungssystems, das als einziger logischer Zugriffspunkt dient. Dann werden alle Webbrowser manuell mit dem Namen des externen Zuteilungssystems (als Zielproxy-/SOCKS-Server) konfiguriert, das den Datenverkehr dann zu einem ausgewählten Proxy-/SOCKS-Server weiterleitet. Ein Beispiel für ein solches Zuteilungssystem ist der Interactive Network Dispatcher von IBM. Weitere Informationen zu diesem Produkt sind zu finden in der IBM Publikation mit dem Titel „Interactive Network Dispatcher V1.2 – User's Guide", GC31-8496-01. Eine Lösung mit einem Zuteilungssystem ermöglicht zwar in den meisten Fällen einen wirksamen Lastausgleich, jedoch besteht ihr Hauptnachteil darin, dass ein zusätzliches spezielles System oder eine spezielle Hardware benötigt wird und der Webbrowser durch die Endbenutzer manuell mit dem externen Namen des Zuteilungssystems konfiguriert werden muss.
  • In der US-Patentschrift 5 459 837 mit dem Titel „System to facilitate efficient utilization of network resources in a computer network" wird von Caccavale Frank (Digital Equipment Corporation) ein Verfahren und ein System zum Überwachen der Leistung von Servern in einem Netz und zum Vorschlagen eines geeigneten Servers für einen Client beschrieben, der einen Dienst anfordert. In verschiedenen Clients im Netz wird durch einen Zuteilungs-Leistungsüberwachungs-Mechanismus (Broker-Performance Mechanism) eine Vielzahl von Sonden (Überwachungselementen) eingerichtet. Die Sonden fordern die Server zum Ausführen verschiedener Netzfunktionen auf und messen die Antwortzeit der Server bei der Erfüllung dieser Anforderungen. Der Zuteilungs-Leistungsüberwachungs-Mechanismus ruft die Daten für die Antwortzeit ab, wertet diese aus und speichert sie. Die gespeicherten Daten können einem Benutzer zur Verfügung gestellt werden, um das System zu überprüfen. Wenn ein bestimmter Client einen bestimmten Dienst anfordert, prüft der Zuteilungs-Leistungsüberwachungs-Mechanismus darüber hinaus die ausgewerteten Daten und ermittelt den Server, der zu diesem Zeitpunkt am besten geeignet ist, dem anfordernden Client den angeforderten Dienst zu bieten.
  • AUFGABEN DER ERFINDUNG
    • • Die Aufgabe der vorliegenden Erfindung besteht darin, die Auswahl des Proxy-/SOCKS-Servers anhand der Kriterien Verfügbarkeit und Antwortzeit zu optimieren.
    • • Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, die Leistung des Webdienstes durch Einbeziehen eines Antwortzeitfaktors in die Auswahl des Proxy-/SOCKS-Servers zu optimieren.
    • • Noch eine andere Aufgabe der vorliegenden Erfindung besteht darin, die Unterbrechungen des Webdienstes auf ein Minimum zu verringern und somit eine höhere Verfügbarkeit des Dienstes sicherzustellen, indem Ausfälle von Proxy-/SOCKS-Servern automatisch erkannt werden.
  • ÜBERBLICK ÜBER DIE ERFINDUNG
  • Die vorliegende Erfindung betrifft die dynamische Autoproxy-Konfiguration und insbesondere ein Verfahren und ein System zum Optimieren der Auswahl eines Proxy-/SOCKS-Servers anhand bestimmter Kriterien der Antwortzeit und der Verfügbarkeit. Die Erfindung basiert auf einem dynamischen Autoproxy-Mechanismus unter Verwendung von Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit.
  • Die vorliegende Erfindung basiert auf Sonden, die über jeden Proxy-/SOCKS-Server bekannte HTML-Seiten abrufen, die entsprechende Antwortzeit messen, Ausfälle von Proxy-/SOCKS-Servern und eine Verschlechterung der Antwortzeit erkennen.
  • Die vorliegende Erfindung verwendet auch ein CGI-Programm (Common Gateway Interface, allgemeine Vermittlungsrechner-Schnittstelle) zum dynamischen Erzeugen von Autoproxy-Code (bei einer bevorzugten Ausführungsart als Javascript-Code) in einem Autoproxy-URL-System zum Auswählen des Proxy-/SOCKS-Servers anhand der von den Sonden bereitgestellten Informationen zur Verfügbarkeit und Antwortzeit.
  • Die vorliegende Erfindung beseitigt die Nachteile der gegenwärtig üblichen Lösungen durch Einbeziehen dynamischer Kriterien für die Auswahl von Proxy-/SOCKS-Servern in Form der Verfügbarkeit und der Antwortzeit zum Autoproxy-Mechanismus.
  • Die vorliegende Erfindung bietet die folgenden Vorteile:
    • • Früherkennung von Ausfällen der Proxy-/SOCKS-Server und somit hohe Verfügbarkeit des Webdienstes.
    • • Einbeziehung eines Antwortzeitfaktors in die Auswahl des Proxy-/SOCKS-Servers und somit Leistungsoptimierung des Webdienstes.
    • • Minimierung des Datenverkehrs für HTTP-Abfragen durch Betreiben von Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit von einem einzigen Autoproxy-URL-System aus (anstelle von Sonden in jedem Webbrowsersystem).
    • • Einbeziehung der Verschlechterung der Antwortzeit in die Sonden und damit aktive Erkennung von Ausfällen der Proxy-/SOCKS-Server.
    • • Periodische Bereitstellung dynamisch aktualisierter Listen der „besten" Proxy-/SOCKS-Server für den Webbrowser.
    • • Minimierung überflüssigen Datenverkehrs mit ausgefallenen Proxy-/SOCKS-Servern, da diese nach dem Erkennen des Ausfalls aus der Liste der verfügbaren Ziel-Server genommen werden.
    • • Keine zusätzliche oder spezielle Hardware erforderlich.
    • • Leichtere Konfigurierung des Webbrowsers für mobile Benutzer (der Webbrowser wird nur einmal konfiguriert).
    • • Die Leistung des Webbrowsers wird nicht verschlechtert, da die Sonden für die Überwachung der Verfügbarkeit und der Antwortzeit nicht innerhalb des heruntergeladenen Autoproxy-Codes (Javascript-Code), sondern im Autoproxy-URL-System verarbeitet werden.
  • ZEICHNUNGEN
  • Die neuartigen und für die Erfindung als charakteristisch angesehenen Merkmale sind in den beiliegenden Ansprüchen dargelegt. Die Erfindung selbst sowie eine bevorzugte Ausführungsart und weitere ihrer Aufgaben und Vorteile lassen sich am besten unter Bezug auf die folgende detaillierte Beschreibung einer anschaulichen detaillierten Ausführungsart in Verbindung mit den beiliegenden Zeichnungen verstehen, wobei:
  • 1 eine logische Übersichtsdarstellung eines Endbenutzersystems nach dem Stand der Technik ist, das für den Zugriff auf das World Wide Web mit einem Webbrowser verbunden ist.
  • 2 eine physische Übersichtsdarstellung der in 1 gezeigten Anordnung nach dem Stand der Technik ist.
  • 3 eine logische Darstellung des externen Datenflusses der Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit gemäß der vorliegenden Erfindung ist.
  • 4 ein Flussdiagramm ist, das den internen logischen Ablauf der in 3 gezeigten Sonde zur Überwachung der Verfügbarkeit und der Antwortzeit gemäß der vorliegenden Erfindung zeigt.
  • 5 eine physische Darstellung der in 3 gezeigten logischen Umgebung gemäß der vorliegenden Erfindung ist.
  • 6 eine Darstellung der Datenströme zwischen den in 5 gezeigten Einheiten gemäß der vorliegenden Erfindung ist.
  • 7 die Speicherung der Messwerte der Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit gemäß der vorliegenden Erfindung zeigt.
  • 8 ein Flussdiagramm des im Autoproxy-URL-System laufenden Programms gemäß der vorliegenden Erfindung ist.
  • BEVORZUGTE AUSFÜHRUNGSART DER ERFINDUNG
  • Die vorliegende Erfindung basiert auf einer dynamischen Autoproxy-Konfiguration und insbesondere auf einem Verfahren und einem System zum Auswählen eines Proxy-/SOCKS-Servers anhand bestimmter Kriterien der Antwortzeit und der Verfügbarkeit. Sie basiert auf einem dynamischen Autoproxy-Mechanismus unter Verwendung von Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit. Darüber hinaus basiert die Erfindung auf Sonden, die über jeden Proxy-/SOCKS-Server bekannte HTML-Seiten abrufen, die entsprechenden Antwortzeiten messen sowie Ausfälle von Proxy-/SOCKS-Servern und Verschlechterungen der Antwortzeit erkennen.
  • Ferner nutzt die Erfindung zum Auswählen des Proxy-/SOCKS-Servers ein CGI-Programm zur dynamischen Erzeugung von Autoproxy-Code (bei einer bevorzugten Ausführungsart von Javascript-Code) in einem Autoproxy-URL-System.
  • LOGISCHE ÜBERSICHTSDARSTELLUNG EINES ENDBENUTZERS, DER AUF DAS WORLD WIDE WEB ZUGREIFT
  • 1 zeigt ein Benutzersystem mit einer Benutzeroberfläche (102), in welchem ein als Webbrowser (101) bekanntes Programm läuft, das den Zugriff auf das World Wide Web (WWW) ermöglicht. Die Inhalte des WWW werden unter Verwendung des HTTP-Protokolls übertragen. HTTP-Anforderungen und -Antworten werden an das Webbrowserprogramm (101) und von diesem weiter an einen Ziel-Webserver (103) gesendet, in dem sich die vom Benutzer gewünschten WWW-Inhalte befinden. Die Firewall (104) zwischen dem Webbrowser (101) und dem Webserver (103) tritt als vermittelnder HTTP-Proxy-Server auf, der HTTP-Anforderungen und -Antworten an ihr Ziel weiterleitet. Das Webbrowserprogramm (101) richtet eine HTTP-Anforderung an die Firewall (104) und diese leitet die Anforderung an den Ziel-Webserver (103) weiter. In umgekehrter Richtung läuft die HTTP-Antwort wiederum über die Firewall (104) zum Webbrowser (101) zurück. Auf diese Weise kann die Firewall den Datenverkehr der Transaktionen begrenzen, für die sie (auf Grundlage einer definierten Sicherheits- und Zugangskontrollstrategie) konfiguriert wurde. Somit schützt die Firewall das Netz, in dem sich der Webbrowser befindet.
  • PHYSISCHE ÜBERSICHTSDARSTELLUNG EINES ENDBENUTZERS, DER AUF DAS WWW ZUGREIFT
  • 2 ist eine physische Übersicht der in 1 gezeigten logischen Anordnung. Bei diesem speziellen Beispiel läuft der Webbrowser (201) auf einem mit einem Intranet (202) verbundenen System. Die Firewalls (203) zum Schutz des Intranets sind sowohl mit dem (privaten) Intranet (202) als auch mit dem (öffentlichen) Internet (204) verbunden. Der Ziel-Webserver (205) ist ebenso mit dem Internet verbunden. In dieser Umgebung führen der Webbrowser, die Firewall und der Webserver ihre Funktion aus, wenn der Benutzer im Internet (WWW) sucht. Hierzu ist anzumerken, dass die Firewall mit zwei Netzen verbunden ist und somit als Vermittler für die Kommunikation zwischen den beiden Netzen in Erscheinung treten kann. Oft werden mehrere Firewalls eingesetzt, um den Zugriff stabiler zu machen und einen besseren Lastausgleich zu erreichen.
  • LOGISCHE DARSTELLUNG DER SONDEN ZUR ÜBERWACHUNG DER VERFÜGBARKEIT UND DER ANTWORTZEIT
  • Das Gebiet der Erfindung ist in 1 und 2 dargestellt, in denen ein Benutzer innerhalb eines Intranet unter Verwendung eines Webbrowsers auf das Internet zugreifen möchte und das Intranet durch mehrere Firewalls gegenüber dem Internet geschützt wird, die die Aufgabe so genannter HTTP-Proxy-Server übernehmen (2). Die Aufgabe besteht darin, den „besten" Proxy-/SOCKS-Server auszuwählen, um dem Endbenutzer den Dienst mit einer optimalen Verfügbarkeit und Antwortzeit zur Verfügung zu stellen. Um diese Auswahl automatisch zu optimieren, wird eine Softwarekomponente mit der Bezeichnung „WWW availability and response time probe" (Sonde zur Überwachung der Verfügbarkeit und der Antwortzeit im Internet) eingeführt. Deren Aufgabe besteht darin, Auswahlkriterien bereitzustellen. 3 zeigt, dass diese Daten durch Messung der Antwortzeit auf die Anforderung bestimmter Inhalte eines bekannten Webservers erfasst werden. Der zusätzliche Datenverkehr durch die HTTP-Überwachung wird dadurch minimiert, dass die Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit (anstatt auf jedem Webbrowser-Client-System) auf einem einzigen Autoproxy-URL-System laufen.
  • 3 zeigt die Funktion einer flexiblen Sonde zur Überwachung der Verfügbarkeit und der Antwortzeit im Internet und wie mit deren Hilfe Messwerte zur Verfügbarkeit und zur Antwortzeit von HTTP-Proxy-Servern und SOCKS-Servern erfasst werden können. Im oberen Teil von 3 wird das Zusammenwirken der Sonde mit einem HTTP-Proxy-Server (304) gezeigt. Das Client-System (302), in welchem die (zur Prüfung von Proxy-Servern konfigurierte) Sonde läuft, fordert im Grunde wie bei dem in 1 gezeigten Prozess über den Proxy-Server (304) Internetinhalte (Webseiten) vom Webserver (307) an. Die HTTP-Anforderung stellt in diesem Falle einen „Datenfluss zur HTTP-Überwachung" (303) an den Proxy-Server dar. Der Proxy-Server leitet (306) die Anforderung (über die nicht dargestellte Firewall (305)) zum Webserver weiter. Das Client-System misst die Zeit, die der Datenfluss von Anforderung/Antwort für die HTTP-Überwachung benötigt und verwendet diese Information als Messwert für die Antwortzeit und die Verfügbarkeit über den geprüften Proxy-Server (für die geprüften Inhalte des Internet). Wenn das Client-System gleich dem Autoproxy-URL-System (301) ist, kann dieser Messwert für jeden Proxy-Server dazu verwendet werden, den Proxy-Server zu ermitteln, der am „besten" geeignet ist. Dieser Proxy-Server kann dann in der Autoproxy-URL codiert werden, die durch die Webbrowserprogramme zum Auswählen ihres passenden Proxy-Servers verwendet wird.
  • Im unteren Teil von 3 wird eine ähnliche Anordnung gezeigt, wobei in diesem Falle die Messwertdaten für ein Zugriffsverfahren über einen SOCKS-Server (Gateway) erfasst werden. Auch hier sendet eine Client-Sonde (309) eine HTTP-Anforderung ab, die als „Datenfluss zur HTTP-Überwachung" (310) über den SOCKS-Server (311) über das Internet (312) zur Ziel-Website (313) gelangt. Diese HTTP-Anforderung gilt für eine bestimmte Ziel-URL (308), von der bekannt ist, dass sie auf dem Ziel-Webserver vorhanden ist. Auch hier wird die Zeit gemessen, die diese Überwachung bis zur Bereitstellung der Messwertdaten in Anspruch nimmt, die zum Erzeugen einer Autoproxy-URL verwendet werden können, wobei die URL die Leistungsunterschiede einer Reihe von SOCKS-Servern (oder im ersten Falle von HTTP-Proxy-Servern) berücksichtigt.
  • Wenn auf den Datenfluss zur HTTP-Überwachung keine Antwort erfolgt, kann der betreffende geprüfte Proxy- oder SOCKS-Server als nicht verfügbar markiert werden. Auf diese Weise kann die Autoproxy-URL dazu verwendet werden, Proxy- oder SOCKS-Server nicht auszuwählen, die nicht arbeitsfähig sind.
  • INTERNER LOGISCHER ABLAUF DER SONDE ZUR ÜBERWACHUNG DER VERFÜGBARKEIT UND DER ANTWORTZEIT
  • Der interne Mechanismus der Sonde selbst wird in 4 beschrieben. Die Sonde simuliert einen Web-Client, indem sie über eine HTTP-Verbindung eine Webseite von einer Ziel-URL auf dem Ziel-Proxy-/SOCKS-Server (unter Verwendung dessen Hostnamens und Anschlusses als Bezugsadresse) anfordert. Die Webseite wird entweder über eine normale HTTP-Verbindung oder durch einen SOCKS-Datenfluss (Datenfluss durch einen SOCKS-Server) abgerufen. Üblicherweise dient ein normaler Datenfluss zum Abrufen einer Webseite von einem Proxy-Server oder von einem Webserver, während zum Abrufen einer Webseite von einem SOCKS-Server ein SOCKS-Datenfluss verwendet wird. Dann prüft die Sonde, ob die Webseite:
    • • innerhalb einer zulässigen Zeitspanne (in Sekunden) empfangen wurde, und
    • • ein bestimmtes Schlüsselwort enthält, um sicherzustellen, dass die empfangene Seite richtig empfangen wurde.
  • Wenn diese beiden Bedingungen erfüllt sind, gilt die Webseite als erfolgreich abgerufen.
  • Abschließend sendet die Sonde entweder die entsprechende Antwortzeit in Sekunden (erfolgreiches Abrufen) oder einen Fehlercode zurück. Durch diesen Mechanismus werden eine oder mehrere Ziel-Webseiten abgerufen. Wenn mehrere Webseiten abgerufen werden, prüft das Sondenprogramm nacheinander jede einzelne Webseite, bis eine Webseite erfolgreich übertragen oder die Übertragung aller Webseiten fehlgeschlagen ist. Sonden:
    • • rufen von jedem Proxy-/SOCKS-Server bekannte HTML-Seiten ab,
    • • messen die entsprechende Antwortzeit, und
    • • erkennen ferner Ausfälle von Proxy-/SOCKS-Servern und die Verschlechterung der Antwortzeit.
  • 4 ist ein Flussdiagramm, das den internen logischen Ablauf der in 3 eingeführten Sonde zur Überwachung der Verfügbarkeit und der Antwortzeit im Internet zeigt.
    • • Zuerst startet das Sondenprogramm einen Zeitgeber (401).
    • • Anschließend versucht das Sondenprogramm eine Verbindung (402) zu dem Ziel-Webserver herzustellen, um eine Webseite unter der Ziel-URL abzurufen. Das Sondenprogramm stellt die Verbindung entsprechend seiner Konfiguration her, z.B. über einen HTTP-Proxy-Server, einen SOCKS-Server (Gateway) oder direkt.
    • • Wenn der Versuch zur Herstellung der Verbindung fehlschlägt, wechselt das Sondenprogramm sofort in den Fehlermodus (408). Das Sondenprogramm sendet einen Fehlerwert zurück (407), um anzuzeigen, dass die Verbindung nicht möglich ist.
    • • Wenn der Versuch zur Herstellung der Verbindung erfolgreich ist, wird die Webseite (403) durch das Sondenprogramm abgerufen.
    • • Dann schließt das Sondenprogramm die Verbindung (404) gemäß der normalen HTTP-Protokollprozedur.
    • • Um sicherzustellen, dass die Webseite richtig abgerufen worden ist, sucht das Sondenprogramm dann nach bekannten Schlüsselwörtern (405), die in der Webseite vorkommen sollten.
    • • Wenn das Schlüsselwort in der Webseite gefunden wird (406), ist die Webseite erfolgreich abgerufen worden. Der Zeitgeber wird angehalten und die genaue Antwortzeit für die Operation zurückgesendet. Durch Speichern und Einfügen des Wertes in einen kurzen zeitlichen Verlauf der Antwortzeit kann das Sondenprogramm Verschlechterungen der Antwortzeit erkennen und zurücksenden, um so den Ausfall von Proxy-/SOCKS-Servern vorauszusehen.
    • • Wenn jedoch das richtige Schlüsselwort nicht in der Webseite gefunden wird (407), ist das Abrufen der Webseite erfolglos, und es wird wiederum ein Fehlerwert zurückgesendet. Das Ereignis, das diese Fehlerart auslösen kann, besteht darin, dass die Webseite bei einer erfolgreich hergestellten Verbindung fehlerhaft abgerufen wird.
    • • In den Wiederholungsmodus (409) wechselt die Sonde nur dann, wenn sie nicht nur zum Abrufen einer URL, sondern zum Abrufen mehrerer Ziel-URLs konfiguriert worden ist. Dies verleiht der Prüfung durch das Sondenprogramm zusätzliche Stabilität und macht es von kurzzeitigen Netzunterbrechungen weniger abhängig (z.B. von getrennten Verbindungen usw.).
  • PHYSISCHE ÜBERSICHT ÜBER DEN EXTERNEN DATENFLUSS DER SONDEN ZUR ÜBERWACHUNG DER VERFÜGBARKEIT UND DER ANTWORTZEIT
  • Die Sonden werden durch verschiedene Komponenten und in verschiedenen Datenflüssen genutzt (5 und 6), um dem Webbrowser den besten Proxy-/SOCKS-Server anzubieten. Die durch die Sonden erfassten Daten werden unter Verwendung eines Autoproxy-Mechanismus indirekt auf den Webbrowser heruntergeladen. Die vorliegende Erfindung gestattet eine Softwareausführung ohne zusätzliche oder spezielle Hardware.
  • Die von der Sonde ausgegebenen Werte werden in dem in 7 gezeigten Autoproxy-URL-System gespeichert und zum Erzeugen des Autoproxy-Codes (bei der bevorzugten Ausführungsart eines Javascript-Codes) verwendet. Innerhalb des Codes läuft kein weiterer Prozess ab. Die Leistung der Webbrowsers wird nicht verschlechtert, da die Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit nicht innerhalb des heruntergeladenen Autoproxy-Codes (Javascript-Code), sondern im Autoproxy-URL-System verarbeitet werden.
  • Ein CGI-Programm erzeugt dynamisch den in 8 dargestellten Autoproxy-Code mit den durch die Sonden bereitgestellten Werten der Verfügbarkeit und der Antwortzeit. Die Verwendung der Kriterien Verfügbarkeit und Antwortzeit zum Auswählen eines Proxy-/SOCKS-Servers durch die Sonden ist mit bereits vorhandenen Kriterien wie beispielsweise dem ursprünglichen IP-Teilnetz des Clients, voll kompatibel und kann mit diesen kombiniert werden.
  • Die Verwendung der Kriterien Antwortzeit und Verfügbarkeit bietet über den Verlauf der Verschlechterung der Antwortzeit auch eine aktive Erkennung für den Ausfall von Proxy-/SOCKS-Servern. Der Webbrowser kann periodisch und dynamisch mit einer neuen Auswahl der „besten" Proxy-/SOCKS-Server aktualisiert werden, indem:
    • • im Autoproxy-Code eine Markierung „Aktualisieren",
    • • ein externer Code (oder ein Java-Applet), oder
    • • eine neue Funktion im Webbrowser zum periodischen und automatischen Aktualisieren des Autoproxy-Codes verwendet wird.
  • Ein weiteres positives Ergebnis besteht in der Minimierung des überflüssigen Datenverkehrs mit den ausgefallenen Proxy-/SOCKS-Servern, da Proxy-/SOCKS-Server nach dem Erkennen des Ausfalls aus der Liste der verfügbaren Zielserver genommen werden. Da ein Autoproxy-Mechanismus verwendet wird, braucht die Proxykonfiguration im Webbrowser bei Ausfall eines Proxy- /SOCKS-Servers nicht manuell aktualisiert zu werden. Die Namen und Standorte der Proxy-/SOCKS-Server brauchen dem Endbenutzer nicht bekannt zu sein und müssen durch diesen nicht konfiguriert werden, sodass zum Beispiel mobilen Benutzern ein unterbrechungsfreier Dienst zur Verfügung steht.
  • 5 ist eine physische Darstellung der in 3 gezeigten Logikumgebung. Der mit dem Intranet (502) verbundene Webbrowser (501) ist so konfiguriert, dass er zur Ermittlung des Proxy-/SOCKS-Servers (Firewall) (503), über den er auf das Internet (504) und den Ziel-Webserver (505) zugreift, eine Autoproxy-URL verwendet. Das System (506), in dem sich die Autoproxy-URL befindet, betreibt auch die zur Prüfung der Proxy-/SOCKS-Server konfigurierten Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit. Zur dynamischen Erzeugung des Autoproxy-Codes der Autoproxy-URL verwendet die Autoproxy-URL die CGI (508). Der Autoproxy-Code basiert auf dem durch die Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit erfassten Daten. Auf diese Weise wird der Webbrowser so konfiguriert, dass er
    • • einen verfügbaren Proxy-/SOCKS-Server, und
    • • den vermeintlich besten Proxy-/SOCKS-Server kennt.
  • DATENFLUSS DER SONDEN FÜR DIE ÜBERWACHUNG DER VERFÜGBARKEIT UND DER ANTWORTZEIT
  • 6 zeigt eine Übersicht über den Datenfluss zwischen den in 5 dargestellten Einheiten. Auch hier ist der an das Intranet (602) angeschlossene Webbrowser (601) so konfiguriert, dass er zur Ermittlung des für den Zugriff auf das Internet (604) und den Ziel-Webserver (605) zu verwendenden Proxy-/SOCKS-Servers (Firewall) eine Autoproxy-URL verwendet. Der Webbrowser kann auf das Autoproxy-URL-System (606) zugreifen (609), um zuerst den zu verwendenden Proxy-/SOCKS-Server zu ermitteln. Der Webbrowser kann periodisch und dynamisch mit dem „besten" Proxy-/SOCKS-Server durch Verwendung:
    • • der Markierung „Aktualisieren" im Autoproxy-Code,
    • • eines externen Codes (oder Java-Applets), oder
    • • einer neuen Funktion des Webbrowsers zum periodischen und automatischen Aktualisieren des Autoproxy-Codes aktualisiert werden.
  • Das System, in dem sich die Autoproxy-URL befindet und die die Sonden (607) zur Überwachung der Verfügbarkeit und der Antwortzeit betreibt, verwendet zum dynamischen Erzeugen des Autoproxy-Codes (610) der Autoproxy-URL die CGI (608). Der Autoproxy-Code basiert auf den durch die Sonden zur Überwachung der Verfügbarkeit und der Antwortzeit erfassten Daten, nachdem die Sonden die Proxy-/SOCKS-Server durch die in 3 dargestellten Datenströme (611 und 612) zur HTTP-Überwachung geprüft haben. Auf diese Weise erfährt der Webbrowser, welcher der vermeintlich beste Proxy-/SOCKS-Server ist.
  • SPEICHERUNG DER MESSWERTE DER SONDEN ZUR ÜBERWACHUNG DER VERFÜGBARKEIT UND DER ANTWORTZEIT
  • 7 zeigt die interne Speicherung der durch die Sonden (701) zur Überwachung der Verfügbarkeit und der Antwortzeit gewonnenen Daten innerhalb des Autoproxy-URL-Systems. Jede Sonde aktualisiert (702) eine Tabelle im Autoproxy-URL-System (703) mit den Messwerten für jeden geprüften Proxy-/SOCKS-Server. Auf diese Weise enthält die Tabelle den aktuellen Stand aller zur Auswahl stehenden und durch den Webbrowser zu verwendenden Proxy-/SOCKS-Server. In konfigurierbaren oder periodischen Zeiträumen prüfen die Sonden die Proxy-/SOCKS-Server (704) erneut, und der Zyklus wird wiederholt.
  • IM AUTOPROXY-URL-SYSTEM LAUFENDES PROGRAMM
  • 8 betrifft wiederum den logischen Ablauf des im Autoproxy-URL-System laufenden Programms.
    • • Zu Anfang setzt sich ein Webbrowser (801) mit dem Autoproxy-URL-System in Verbindung und möchte erfahren, welcher Proxy-/SOCKS-Server (oder Firewall) am besten verwendet werden kann. Das wird zum Beispiel durch Auswahl der Option „automatische Proxykonfiguration" im Webbrowser und durch Angeben einer Information wie beispielsweise der URL des Autoproxy-Codes erreicht.
    • • Das Autoproxy-URL-System aktiviert (802) das CGI-Programm (über die Webservererweiterungen der CGI). Das CGI-Programm kann auf alle CGI-Standardvariablen einschließlich der IP(Internetprotokoll)-Adresse des Webbrowsers zugreifen.
    • • Das CGI-Programm (803) wählt ausgehend sowohl von der (als CGI-Variable vorgelegten) IP-Adresse des Webbrowsers als auch von den durch die Sonden für die Überwachung der Verfügbarkeit und der Antwortzeit für jeden Proxy-/SOCKS-Server erzeugten und in der Tabelle des Autoproxy-URL-Systems (807) gespeicherten Informationen den für das Client-System (Webbrowser) am besten geeigneten Proxy-/SOCKS-Server aus. Die IP-Adresse wird dazu verwendet, ein geografisches Kriterium zur Auswahl des Proxy-/SOCKS-Servers heranzuziehen. Wenn z.B. zwei Proxy-/SOCKS-Server dieselbe Antwortzeit liefern (einer in den USA, der andere in Europa), wird der nächstgelegene Proxy-/SOCKS-Server bevorzugt (der in Europa, wenn der Webbrowser in Europa steht).
    • • Zur Verbesserung der Robustheit der Auswahl des Proxy-/SOCKS-Servers wählt das CGI-Programm für den Webbrowser (804) einen besten „Reserve"-Proxy-/SOCKS-Server aus. Dieser „Reserve"-Proxy-/SOCKS-Server wird automatisch durch den Webbrowser verwendet, wenn er das Zeitlimit überschreitet, während dessen er versuchen kann, den seiner Ansicht nach „besten" Proxy-/SOCKS-Server zu nutzen. Dieser „Reserve"-Proxy-/SOCKS-Server wird wiederum unter Verwendung sowohl der (als CGI-Variable vorgelegten) IP-Adresse des Webbrowsers als auch der von den durch die Sonden für die Überwachung der Verfügbarkeit und der Antwortzeit für jeden Proxy-/SOCKS-Server erzeugten und in der Tabelle des Autoproxy-URL-Systems (807) gespeicherten Informationen ausgewählt.
    • • Nachdem das CGI-Programm den besten und den Reserve-Proxy-/SOCKS-Server ausgewählt hat, erzeugt es den Autoproxy-Code (805). Dieser Code ist normalerweise in der Sprache Javascript geschrieben.
    • • Nachdem der Autoproxy-Code erzeugt worden ist, lädt das Autoproxy-URL-System den Code wie alle anderen Ausgabedaten eines CGI-Programms über das HTTP-Standardprotokoll zum Webbrowser (806) herunter.

Claims (14)

  1. Verfahren zum dynamischen Auswählen eines Firewall-Servers (603) für einen Web-Client (601), insbesondere eines Webbrowsers (601) in einem TCP/IP-Netz (Netz mit Übertragungskontrollprotokoll/Internetprotokoll), das eine Vielzahl von Firewall-Servern (503) umfasst, wobei das Verfahren die folgenden Schritte umfasst: • Messen der Leistung und der Verfügbarkeit jedes Firewall-Servers (603) unter Verwendung von Messsonden (607), wobei dieser Schritt den Schritt des Messens der zum Abrufen bekannter Informationen durch jeden Firewall-Server (603) von einem Webserver (605) benötigten Antwortzeit umfasst; • Dynamisches Auswählen eines Firewall-Servers gemäß den Leistungs- und Verfügbarkeitsmesswerten (607).
  2. Verfahren nach dem vorhergehenden Anspruch, bei dem der Schritt des Messens der Leistung und der Verfügbarkeit jedes Firewall-Servers (603) unter Verwendung von Messsonden (607) weiterhin den folgenden Schritt umfasst: • Messen der zum Abrufen einer oder einer Vielzahl bekannter Webseiten von einem Webserver (605) durch jeden Firewall-Server (603) benötigten Antwortzeit.
  3. Verfahren nach dem vorhergehenden Anspruch, bei dem der Schritt des Messens der Antwortzeit weiterhin die folgenden Schritte umfasst: • Herstellen (402) einer Verbindung mit dem Webserver (605) durch jeden Firewall-Server (603); • Abrufen (403) der einen oder einer Vielzahl von bekannten Webseiten von dem Webserver (605); • Prüfen (405), ob die abgerufene eine oder die abgerufene Vielzahl von Webseiten ein oder eine Vielzahl von bekannten Schlüsselwörtern enthalten.
  4. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Messens der Leistung jedes Firewall-Servers (603) unter Verwendung von Messsonden (607) weiterhin den folgenden Schritt umfasst: • Vergleichen der gemessenen Antwortzeit mit vorher gemessenen Antwortzeiten für jeden Firewall-Server; • Ermitteln der Verschlechterung oder der Verbesserung der gemessenen Antwortzeit für jede Firewall (603).
  5. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Messens der Verfügbarkeit jedes Firewall-Servers unter Verwendung von Messsonden (607) weiterhin den folgenden Schritt umfasst: • Erkennen von Ausfällen in jedem Firewall-Server; • Ausschließen der von Ausfällen betroffenen Firewall-Server von dem Schritt des Auswählens eines Firewall-Servers.
  6. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Firewall-Server (603) ein Proxy-Server (304) und/oder ein SOCKS-Server (311) ist.
  7. Verfahren nach einem der vorhergehenden Ansprüche, das ferner die folgenden Schritte umfasst: • Verarbeiten der Leistungs- und Verfügbarkeitsmesswerte (607) von einem einzigen URL-System (606); • Dynamisches Erzeugen einer Konfigurationsdatei ausgehend von den Leistungs- und Verfügbarkeitsmesswerten in dem URL-System (606) zum Auswählen des Firewall-Servers (603).
  8. Verfahren nach Anspruch 7, bei dem der Schritt des dynamischen Erzeugens einer Konfigurationsdatei durch eine allgemeine Vermittlungsrechner-Schnittstelle CGI (608) im URL-System (606) ausgeführt wird.
  9. Verfahren nach Anspruch 7 oder 8, bei dem der Schritt des Auswählens eines Firewall-Servers (603) weiterhin den folgenden Schritt umfasst: • Herunterladen der Konfigurationsdatei vom URL-System (606) zum Web-Client.
  10. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Auswählens eines Firewall-Servers (603) weiterhin den folgenden Schritt umfasst: • Herunterladen der Konfigurationsdatei vom URL-System (606) zum Webbrowser (601).
  11. Verfahren nach einem der Ansprüche 8 bis 10, bei dem die Schritte des Messens der Leistung und der Verfügbarkeit und des dynamischen Auswählens eines Firewall-Servers (603) im URL-System (606) periodisch ausgeführt werden und die durch die allgemeine Vermittlungsrechner-Schnittstelle CGI (608) erzeugte Konfigurationsdatei periodisch zum Web-Client (601) heruntergeladen wird.
  12. Verfahren nach einem der vorhergehenden Ansprüche, das weiterhin die folgenden Schritte umfasst: • Vorauswählen eines Reserve-Firewall-Servers (603) in einem Hintergrundprozess; • Umschalten auf den Reserve-Firewall-Server, wenn der ausgewählte Firewall-Server ausfällt.
  13. Verfahren nach einem der vorhergehenden Ansprüche, bei dem der Schritt des Auswählens eines Firewall-Servers gemäß den Leistungs- und Verfügbarkeitsmesswerten weiterhin den folgenden Schritt umfasst: • Auswählen des Firewall-Servers gemäß einer IP-Adresse.
  14. System, das Mittel zum Ausführen des Verfahrens nach einem der vorhergehenden Ansprüche umfasst.
DE69934871T 1999-03-05 1999-03-05 Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk Expired - Lifetime DE69934871T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
EP99480011A EP1035708B1 (de) 1999-03-05 1999-03-05 Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk

Publications (2)

Publication Number Publication Date
DE69934871D1 DE69934871D1 (de) 2007-03-08
DE69934871T2 true DE69934871T2 (de) 2007-07-05

Family

ID=8242428

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69934871T Expired - Lifetime DE69934871T2 (de) 1999-03-05 1999-03-05 Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk

Country Status (4)

Country Link
US (1) US6892235B1 (de)
EP (1) EP1035708B1 (de)
JP (1) JP3742272B2 (de)
DE (1) DE69934871T2 (de)

Families Citing this family (61)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6820133B1 (en) * 2000-02-07 2004-11-16 Netli, Inc. System and method for high-performance delivery of web content using high-performance communications protocol between the first and second specialized intermediate nodes to optimize a measure of communications performance between the source and the destination
US7930285B2 (en) 2000-03-22 2011-04-19 Comscore, Inc. Systems for and methods of user demographic reporting usable for identifying users and collecting usage data
US7493655B2 (en) * 2000-03-22 2009-02-17 Comscore Networks, Inc. Systems for and methods of placing user identification in the header of data packets usable in user demographic reporting and collecting usage data
US20020124047A1 (en) * 2001-03-02 2002-09-05 M. Scott Gartner Interactive remote monitoring of client page render times
US7200679B2 (en) * 2001-04-13 2007-04-03 Telefonaktiebolaget Lm Ericsson (Publ) Creating distributed proxy configurations
US20020169868A1 (en) * 2001-04-20 2002-11-14 Lopke Michael S. Interactive remote monitoring of client page render times on a per user basis
EP1265398A1 (de) * 2001-06-08 2002-12-11 Hewlett Packard Company, a Delaware Corporation Proces für das Personifizieren einer Verhandlung durch ein Internet- oder Intranet
US7254834B2 (en) 2001-10-18 2007-08-07 The Board Of Regents Of The University Of Nebraska Fault tolerant firewall sandwiches
US7418484B2 (en) * 2001-11-30 2008-08-26 Oracle International Corporation System and method for actively managing an enterprise of configurable components
US7437450B1 (en) * 2001-11-30 2008-10-14 Cisco Technology Inc. End-to-end performance tool and method for monitoring electronic-commerce transactions
US7359992B2 (en) 2001-12-21 2008-04-15 International Business Machines Corporation Method of preserving symmetrical routing in a communication system based upon a server farm
US7231462B2 (en) 2001-12-21 2007-06-12 International Business Machines Corporation Method of preserving symmetrical routing in a communication system based upon a server farm
US8001279B2 (en) 2001-12-21 2011-08-16 International Business Machines Corporation Method of synchronizing firewalls in a communication system based upon a server farm
US8090866B1 (en) * 2002-01-18 2012-01-03 Cisco Technology, Inc. TCP proxy connection management in a gigabit environment
JP2003223378A (ja) * 2002-01-29 2003-08-08 Fujitsu Ltd コンテンツデリバリネットワークサービス方法及びシステム
US8527620B2 (en) 2003-03-06 2013-09-03 International Business Machines Corporation E-business competitive measurements
US7269651B2 (en) * 2002-09-26 2007-09-11 International Business Machines Corporation E-business operations measurements
US7412502B2 (en) * 2002-04-18 2008-08-12 International Business Machines Corporation Graphics for end to end component mapping and problem-solving in a network environment
US7047291B2 (en) * 2002-04-11 2006-05-16 International Business Machines Corporation System for correlating events generated by application and component probes when performance problems are identified
US7043549B2 (en) * 2002-01-31 2006-05-09 International Business Machines Corporation Method and system for probing in a network environment
US8086720B2 (en) * 2002-01-31 2011-12-27 International Business Machines Corporation Performance reporting in a network environment
US20030217173A1 (en) * 2002-05-15 2003-11-20 Butt Alan B. Automatic proxy detection
US20040006615A1 (en) * 2002-07-02 2004-01-08 Sun Microsystems, Inc., A Delaware Corporation Method and apparatus for cerating proxy auto-configuration file
US20050021526A1 (en) * 2002-07-11 2005-01-27 International Business Machines Corporation Method for ensuring the availability of a service proposed by a service provider
GB0217355D0 (en) * 2002-07-26 2002-09-04 Marconi Comm Ltd Communications system
US7650416B2 (en) 2003-08-12 2010-01-19 Riverbed Technology Content delivery for client-server protocols with user affinities using connection end-point proxies
US20040205184A1 (en) * 2003-03-06 2004-10-14 International Business Machines Corporation E-business operations measurements reporting
GB0306971D0 (en) * 2003-03-26 2003-04-30 British Telecomm Client server model
US7694021B1 (en) * 2003-05-28 2010-04-06 Cisco Technology, Inc. Firewall for gateway network elements between IP based networks
US7418486B2 (en) * 2003-06-06 2008-08-26 Microsoft Corporation Automatic discovery and configuration of external network devices
JP4596275B2 (ja) * 2004-01-09 2010-12-08 ペイパル イスラエル リミテッド. リレー通信を検知する方法、システム及びソフトウェア
US20060031469A1 (en) * 2004-06-29 2006-02-09 International Business Machines Corporation Measurement, reporting, and management of quality of service for a real-time communication application in a network environment
US7461162B2 (en) 2004-12-16 2008-12-02 International Business Machines Corporation Usage consciousness in HTTP/HTML for reducing unused data flow across a network
KR100807817B1 (ko) 2004-12-17 2008-02-27 엔에이치엔(주) 버스형 네트워크 구조의 통신 네트워크 시스템에서서브시스템 사이의 로드를 조절하는 방법
US8219622B2 (en) * 2005-02-09 2012-07-10 Verizon Business Global Llc Systems and methods for providing extended peering
US20060248194A1 (en) 2005-03-18 2006-11-02 Riverbed Technology, Inc. Connection forwarding
US20060212422A1 (en) * 2005-03-21 2006-09-21 Anil Khilani Efficiently executing commands against a large set of servers with near real time feedback of execution and presentation of the output of the commands
US7434041B2 (en) * 2005-08-22 2008-10-07 Oracle International Corporation Infrastructure for verifying configuration and health of a multi-node computer system
US8615578B2 (en) * 2005-10-07 2013-12-24 Oracle International Corporation Using a standby data storage system to detect the health of a cluster of data storage servers
WO2007149687A2 (en) 2006-05-30 2007-12-27 Riverbed Technology, Inc. Selecting proxies from among autodiscovered proxies
JP2008009892A (ja) * 2006-06-30 2008-01-17 Freebit Co Ltd データ管理システム及び管理方法
US9071506B2 (en) * 2006-07-31 2015-06-30 Hewlett-Packard Development Company, L.P. Accessing web services using network management information
US8301787B2 (en) * 2007-03-22 2012-10-30 Red Hat, Inc. Selective use of anonymous proxies
US8250584B1 (en) 2008-07-15 2012-08-21 Sprint Communications Company L.P. Device location application programming interface
TW201210245A (en) * 2010-08-27 2012-03-01 Atop Technologies Inc Network service providing system with high reliability
US8973088B1 (en) * 2011-05-24 2015-03-03 Palo Alto Networks, Inc. Policy enforcement using host information profile
US8955128B1 (en) 2011-07-27 2015-02-10 Francesco Trama Systems and methods for selectively regulating network traffic
US9386114B2 (en) * 2011-12-28 2016-07-05 Google Inc. Systems and methods for accessing an update server
US9077688B2 (en) * 2012-06-17 2015-07-07 Skycure Ltd Access control system for a mobile device
US20140013001A1 (en) * 2012-07-06 2014-01-09 Microsoft Corporation Parallel probing for efficient proxy selection in networked environments
CN103366134A (zh) * 2013-07-12 2013-10-23 浙江吉利汽车研究院有限公司杭州分公司 网络连线管理系统和方法
JP6311268B2 (ja) * 2013-10-25 2018-04-18 富士ゼロックス株式会社 データ処理装置及びプログラム
US9871878B2 (en) 2014-12-15 2018-01-16 Twin Prime, Inc. Network traffic accelerator
RU2598337C2 (ru) 2014-12-19 2016-09-20 Закрытое акционерное общество "Лаборатория Касперского" Система и способ выбора средств перехвата данных, передаваемых по сети
US10361997B2 (en) 2016-12-29 2019-07-23 Riverbed Technology, Inc. Auto discovery between proxies in an IPv6 network
CN115346525A (zh) * 2018-05-07 2022-11-15 谷歌有限责任公司 验证与数字助理应用交接的代理的操作状态
JP7120310B2 (ja) * 2018-07-17 2022-08-17 日本電気株式会社 通信分析装置、通信分析方法、およびプログラム
CN110336793B (zh) * 2019-06-10 2022-08-23 平安科技(深圳)有限公司 一种内网访问方法及相关装置
US10637956B1 (en) 2019-10-01 2020-04-28 Metacluster It, Uab Smart proxy rotator
CN111158776B (zh) * 2019-12-12 2023-12-26 杭州安恒信息技术股份有限公司 一种Web应用防护系统平滑重启方法
US10873647B1 (en) 2020-06-25 2020-12-22 Teso Lt, Ltd Exit node benchmark feature

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5459837A (en) * 1993-04-21 1995-10-17 Digital Equipment Corporation System to facilitate efficient utilization of network resources in a computer network
CA2176775C (en) * 1995-06-06 1999-08-03 Brenda Sue Baker System and method for database access administration
JPH1021334A (ja) 1996-07-02 1998-01-23 Fuji Photo Film Co Ltd 文字認識装置
US5870557A (en) * 1996-07-15 1999-02-09 At&T Corp Method for determining and reporting a level of network activity on a communications network using a routing analyzer and advisor
US6304904B1 (en) * 1997-03-27 2001-10-16 Intel Corporation Method and apparatus for collecting page-level performance statistics from a network device
CA2202572C (en) * 1997-04-14 2004-02-10 Ka Lun Eddie Law A scaleable web server and method of efficiently managing multiple servers
JP3354433B2 (ja) * 1997-04-25 2002-12-09 株式会社日立製作所 ネットワーク通信システム
JPH10307783A (ja) 1997-05-07 1998-11-17 N T T Data:Kk サイトアクセス制御システム及び記録媒体
JPH1155327A (ja) * 1997-08-05 1999-02-26 Matsushita Electric Ind Co Ltd 代理サーバの接続制御サーバ,代理サーバ,及びネットワーク制御方法
JPH11110324A (ja) * 1997-10-07 1999-04-23 Hitachi Ltd 代理サーバ選択装置および代理サーバ
US6446120B1 (en) * 1997-11-26 2002-09-03 International Business Machines Corporation Configurable stresser for a web server
JP3561139B2 (ja) 1998-01-27 2004-09-02 シャープ株式会社 ファイルオブジェクト中継方法、ファイルオブジェクト中継方法のプログラムを記録したコンピュータで読取り可能な記録媒体、およびゲートウェイ計算機
US6175869B1 (en) * 1998-04-08 2001-01-16 Lucent Technologies Inc. Client-side techniques for web server allocation
US6317786B1 (en) * 1998-05-29 2001-11-13 Webspective Software, Inc. Web service
US6327622B1 (en) * 1998-09-03 2001-12-04 Sun Microsystems, Inc. Load balancing in a network environment
US6138157A (en) * 1998-10-12 2000-10-24 Freshwater Software, Inc. Method and apparatus for testing web sites
US20010010059A1 (en) * 1998-10-28 2001-07-26 Steven Wesley Burman Method and apparatus for determining travel time for data sent between devices connected to a computer network
US6748416B2 (en) * 1999-01-20 2004-06-08 International Business Machines Corporation Client-side method and apparatus for improving the availability and performance of network mediated services

Also Published As

Publication number Publication date
DE69934871D1 (de) 2007-03-08
EP1035708B1 (de) 2007-01-17
JP2000259595A (ja) 2000-09-22
US6892235B1 (en) 2005-05-10
JP3742272B2 (ja) 2006-02-01
EP1035708A1 (de) 2000-09-13

Similar Documents

Publication Publication Date Title
DE69934871T2 (de) Verfahren und System zur optimalen Auswahl eines Webfirewalls in einem TCP/IP Netzwerk
DE69909839T3 (de) Optimierte Lokalisierung von Netzwerkbetriebsmittel
DE602005003449T2 (de) Verbesserte benutzerschnittstelle
DE69827638T2 (de) Verteiltes system und verfahren zum objektvorabholen
EP1887484B1 (de) Verfahren zum vorabübertragen strukturierter datenmengen zwischen einer clienteinrichtung und einer servereinrichtung
DE69929268T2 (de) Verfahren und System zur Überwachung und Steuerung der Netzzugriffe
DE69928860T2 (de) System und Verfahren zur Auswahl von Servern für gespiegelte Sites
DE69837508T2 (de) Verfahren zum Inhaltswiederauffinden über ein Netzwerk
DE69728182T2 (de) Verfahren und gerät zum entfernten netzwerkzugriffseintrag und netzwerkzugriffsbericht
DE60308700T2 (de) Dynamische fernkonfiguration eines webservers zur bereitstellung von kapazität auf anfrage
DE60033615T2 (de) Verfahren und System, um das Verteilen von IP-Datagrammen auf mehrere Server gemäß einer definierten Strategie zu erzwingen
DE112006000650B4 (de) Webbasiertes Verwaltungsverfahren und Vorrichtung zum Durchführen desselben
DE69602461T2 (de) Verfahren und server-rechner zum lastausgleich zwischen den prozessoren des server-rechners
DE60313567T2 (de) Zugriffsrelayvorrichtung
DE60110614T2 (de) Verfahren und vorrichtung zur prüfung eines inhaltservers
DE10003907B4 (de) Verfahren, Vorrichtung und Datenverarbeitungsprogramm für die Anwendung beim Zugriff auf Hypertext-Dokumente
DE69803369T2 (de) Verfahren und Vorrichtung zur Bereitstellung eines dritten Internet-Datenkanals
DE69730056T2 (de) Routen von duplikaten
DE69902620T2 (de) Anonyme Web-Site Benutzer Information Kommunikationsverfahren
DE69723432T2 (de) Informationsauffindungssystem mit einer cachedatenbank
DE69731994T2 (de) Verfahren und Gerät, um Informationen über Netzwerkanbieter zu bekommen und anzuzeigen
DE202008013034U1 (de) System zum Beschleunigen von Browsing-Sitzungen
DE102012213795A1 (de) Durch einen Computer implementiertes Verfahren, das es einer Web-Anwendung ermöglicht, mindestens eine native Funktion einer mobilen Einheit aufzurufen
DE60035348T2 (de) Verlängerbarer Bereitstellungsmechanismus für einen Diensten-gateway
DE202021103602U1 (de) Benchmark-Funktion für Ausgangsknoten

Legal Events

Date Code Title Description
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)
8327 Change in the person/name/address of the patent owner

Owner name: TREND MICRO INCORPORATED, TOKIO/TOKYO, JP

8328 Change in the person/name/address of the agent

Representative=s name: KAHLER, KAECK & MOLLEKOPF, 86899 LANDSBERG