DE202021103600U1

DE202021103600U1 - Dynamische Optimierung von Anfrageparametern für Proxy-Server

Info

Publication number: DE202021103600U1
Application number: DE202021103600.1U
Authority: DE
Original assignee: Metacluster LT UAB
Current assignee: Oxylabs UAB
Priority date: 2020-09-11
Filing date: 2021-04-07
Publication date: 2021-08-20
Anticipated expiration: 2031-04-08
Also published as: US11470174B2; US11140235B1; EP3994870A1; US10965770B1; US20220247829A1; US11343342B2; WO2022053880A1; US20220086248A1; CA3190449A1; IL300779A; CN116097620A

Abstract

System zum Extrahieren und Sammeln von Daten von einem Webserver, umfassend
einen Anfrageoptimierer (104), der konfiguriert ist zum
Vergleichen von Parametern einer von einem Benutzergerät (102) empfangenen Anfrage mit einer Liste von Scraping-Strategien;
Auswählen einer Scraping-Strategie aus der Liste von Scraping-Strategien, die zu den Parametern der Anfrage korrespondiert
Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie;
Anpassen der Parameter der Anfrage entsprechend der Scraping-Strategie zum Bilden einer angepasste Anfrage;
Senden der angepassten Anfrage an ein Ziel (116, 118) durch einen Proxy (108, 110), der entsprechend der Scraping-Strategie ausgewählt wurde;
Empfangen einer Antwort von dem Ziel (116, 118).

Description

FELD
In einem Aspekt beziehen sich die hierin beschriebenen Ausführungsformen auf den Datenabruf aus dem Web, um die Kommunikation zwischen einem Benutzer und Technologie zu verbessern, die für den Zugriff auf öffentlich verfügbare Internetressourcen benutzt wird. Die hierin beschriebenen Ausführungsformen verwenden Technologien zur Datenerfassung, um große Datenmengen aus öffentlichen Webressourcen effizienter zu erfassen.
HINTERGRUND
Proxy-Server sind Zwischenserver, die Anfragen von Clients annehmen und die Anfragen an andere Proxyserver oder einen Quellserver weiterleiten oder die Anfrage aus ihrem eigenen Cache bedienen. Proxy-Server sind an ein Netzwerk angeschlossene Computergeräte, die als Vermittler für Kunden-Computergeräte dienen, die Dienste oder Daten von „Netzwerkressourcen“ anfordern, die Anfrage von Kunden-Proxy-Servern annehmen und entweder die Anfrage an einen anderen Proxy weiterleiten, zur angeforderten Ressource umleiten oder die Anfrage aus ihrem eigenen Cache bedienen, der sich lokal oder entfernt befindet oder über mehrere Systeme verteilt ist.
Der Proxy wird auch als „Server“ oder „Gateway“ bezeichnet. Ein Proxy ermöglicht es Benutzern in einem Netzwerk, im Web zu surfen, Dateien über das File Transfer Protocol (FTP) zu senden und mit E-Mail und anderen Internetdiensten zu arbeiten. In einem Aspekt arbeitet ein Proxy auf folgende Weise: i) er empfängt eine Anfrage von einem Benutzer in einem öffentlichen Netzwerk oder einem privaten Netzwerk, das durch eine Firewall getrennt ist, an einen entfernten Server, der den gewünschten Inhalt enthält; ii) er erstellt einen Proxy-Tunnel in Richtung des entfernten Servers; iii) er leitet die Anfrage an den entfernten Server durch den eingerichteten Tunnel weiter; iv) er empfängt die Antwort vom entfernten Server; und v) er leitet die Antwort zurück an den Benutzer.
Die Proxys können in verschiedene Typen unterteilt werden, je nachdem, welche Funktionen bereitgestellt werden oder welche Server verwendet werden. Die Proxys können auch in Residential-Internetprotokoll(IP)-Proxys, Rechenzentrums-IP-Proxys und Mobile-IP-Proxys unterteilt werden. Ein Residential-IP-Proxy ist eine IP-Adresse, die mit einem physischen Gerät verbunden ist, z. B. einem Mobiltelefon oder einem Desktop-Computer. Die eigentlichen Eigentümer der Residential-IP-Proxys, nämlich Internet-Dienstanbieter (ISPs), registrieren Residential-IP-Adressen in öffentlichen Datenbanken, wodurch Webseiten den Internetanbieter, das Netzwerk und den Standort eines Geräts ermitteln können. Der Rechenzentrums-IP-Proxy ist der Proxy-Server, dem eine Rechenzentrums-IP zugewiesen ist. Rechenzentrums-IPs sind IPs, die Unternehmen und nicht Privatpersonen gehören. Die Rechenzentrums-Proxys sind eigentlich IP-Adressen, die sich nicht in einem Haushalt befinden. Stattdessen sind die Rechenzentrums-Proxys mit einem kommerziellen Rechenzentrum verbunden. Mobile-IP-Proxys verhalten sich ähnlich wie Proxys für Privathaushalte, da sie ihre IP-Adresse von einem Mobilfunkbetreiber aus einem Pool von IP-Adressen zugewiesen bekommen, die für mobile Clients bestimmt sind. Mobile-IP-Proxys verwenden mobile Daten, im Gegensatz zu einem privaten Proxy, der eine Breitband-ISP-Verbindung nutzt.
Ein Proxyserver ist im Grunde ein Computer im Internet mit einer eigenen IP-Adresse, die der Computer des Clients „kennt“. Wenn ein Client eine Web-Anfrage sendet, wird die Anfrage zuerst an den Proxy-Server gesendet. Der Proxy-Server stellt dann die Web-Anfrage im Namen des Clients, sammelt die Antwort vom Webserver und leitet die Daten der Webseite weiter, so dass der Client die Seite im Browser oder auf andere Weise sehen kann, z. B. als Daten, die in eine Datei auf der Festplatte geschrieben werden, um sie von Datenaggregations- und Analysetools zu verarbeiten. Wenn der Proxy-Server die Web-Anfragen weiterleitet, kann er Änderungen an den Daten vornehmen und dennoch die angeforderten Daten bereitstellen. Zum Beispiel kann ein Proxy-Server die IP-Adresse des Clients ändern, so dass der Webserver den geografischen Standort des Clients nicht erfährt. Außerdem kann ein Proxy-Server den Zugriff auf bestimmte Webseiten blockieren, basierend auf der IP-Adresse oder dem Domänennamen.
Moderne Proxyserver leisten viel mehr als nur die Weiterleitung von Webanfragen. So können moderne Proxyserver mehrere zusätzliche Funktionen ausführen, um die Datensicherheit und die Netzwerkleistung zu erhöhen. Proxy-Server können als Firewall und Webfilter fungieren, gemeinsam genutzte Netzwerkverbindungen bereitstellen und Daten im Cache speichern, um häufige Anfragen zu beschleunigen. Proxy-Server können ein hohes Maß an Datenschutz bieten. Proxy-Server können die IP-Adresse und andere identifizierende Informationen, die die Web-Anfrage enthält, ändern (z. B. sodass der Zielserver nicht weiß, wer die ursprüngliche Anfrage gestellt hat). Proxy-Server können auch verwendet werden, um die Internetnutzung von Mitarbeitern und Kindern zu kontrollieren (z. B. richten Unternehmen und Eltern Proxy-Server ein, um zu kontrollieren und zu überwachen, wie ihre Mitarbeiter oder Kinder das Internet nutzen) oder um die Browsing-Geschwindigkeit zu verbessern und Bandbreite zu sparen (z. B. können Proxy-Server beliebte Websites in einen Cache stellen, d.h. eine Kopie der entsprechenden Website-Daten lokal speichern, bei einer Anfrage die gespeicherte Kopie an den Client senden).
Proxys können verwendet werden, um bestimmte Internetbeschränkungen (z. B. Firewalls) zu umgehen, indem ein Benutzer den Inhalt über einen (entfernten) Proxy-Server anfordert, anstatt direkt auf den Inhalt zuzugreifen. Proxy-Server werden häufig verwendet, um geo-IP-basierte Inhaltsbeschränkungen zu umgehen. Wenn jemand Inhalte z. B. von einer US-amerikanischen Webseite abrufen möchte, aber von seinem Heimatland aus keinen Zugang hat, kann er die Anfrage über einen Proxyserver stellen, der sich in den USA befindet (und eine US-IP-Adresse hat). Durch die Verwendung von Proxy-Diensten scheint der Datenverkehr des Benutzers von der US-amerikanischen IP-Adresse zu kommen. Proxys können auch für Web Scraping, Data Mining und ähnliche Aufgaben verwendet werden.
Das Sammeln von Daten aus dem Web ist eine wichtige und oft lebenswichtige Aufgabe für viele Geschäftsbereiche. Die Bedeutung und der Wert von Daten nimmt ständig zu und daher wächst der Bedarf an effizienteren Werkzeugen zur Datenabfrage und -analyse. Die beiden wichtigsten Werkzeuge für den Zugriff auf Datenquellen im Web sind Web-Crawling und Web-Scraping.
Der allgemeine Zweck des Web-Crawling besteht darin, auf öffentlich verfügbare Web-Ressourcen (in der Regel Webseiten) zuzugreifen, deren Inhalt abzurufen und den Inhalt an den Benutzer weiterzuleiten. Der grundlegende Zweck des Web-Scraping besteht darin, die vom Web-Crawler abgerufenen Daten zu analysieren und die vom Benutzer angeforderten Informationen zu extrahieren.
Ein Web-Crawler (auch Web-Spider oder Bot genannt) ist ein Programm oder automatisiertes Skript, das methodisch und automatisiert im Web navigiert. Seine primäre Aufgabe ist es, die vom Benutzer bestellten Informationen zu sammeln. Der Web-Crawler tut dies, indem er das Web nach den angeforderten Informationen durchsucht und den rohen Hypertext Markup Language (HTML)-Code der aufgerufenen Websites abruft. Ein weiterer Zweck des Web-Crawling ist die Indizierung von Web-Inhalten durch Suchmaschinen.
Web-Scraping (auch Web-Harvesting, Web-Datenextraktion genannt) ist ein Prozess, bei dem die aufgerufenen Webseiten abgerufen und der Inhalt hinsichtlich der angeforderten Daten analysiert wird. Web-Scraping kann manuell von Hand durchgeführt werden, besteht aber typischerweise aus automatisierten Prozessen, die durch einen Web-Crawler implementiert werden.
Web-Crawling und Web-Scraping-Tools werden oft zusammen verwendet, da die Scraping-Funktionalität stark von den Ergebnissen des Web-Crawlings abhängt. Genauer gesagt ist das Web-Crawling eine Hauptkomponente des Web-Scraping. Daten, auf die ein Web-Crawler zugreift und die er abruft, werden dann von einem Web-Scraper verarbeitet, der die abgerufenen Inhalte analysiert und die benötigten Daten extrahiert.
Der Betrieb eines Web-Crawlers durchläuft eine Abfolge von Aufgaben, einschließlich der Entgegennahme der Anfrage, des Sammelns von Daten und des Lieferns von Daten. Genauer gesagt umfassen die Aufgaben eines Web-Crawlers: Annahme der Anfrage vom Benutzer; Verwaltung der Anfragewarteschlange; Lastverteilung zwischen Verarbeitungsdiensten; Versuch, die angeforderten Daten abzurufen; Datenspeicherung; und Datenlieferung. Die Aufgabe des Versuchs des Datenabrufs umfasst außerdem die Verwaltung von Anfragen in den Protokollen Hypertext Transfer Protocol (HTTP) und Hypertext Transfer Protocol Secure (HTTPS), rotierenden Proxys und Headern.
Ein Web-Crawler verwendet ein standardmäßiges HTTP/HTTPS-Anfrage-/Antwort-Modell, um Ziele aufzurufen und darauf zuzugreifen. Dieses Modell beschreibt die Client-Server-Kommunikation über das Web. Ein Client sendet eine HTTP-Anfrage an den Server und bittet um Zugriff auf bestimmte Daten. Ein Server sendet eine HTTP-Antwort mit den angeforderten Daten an den Client zurück. Die HTTP-Anfrage gibt den Uniform Resource Locator (URL) des Ziels, die Zugriffsmethode und die Header an. Die HTTP-Antwort gibt Statusinformationen, die Header und die angeforderten Daten zurück.
HTTP-Header ermöglichen es dem Client und dem Server, zusätzliche Informationen mit einer HTTP-Anfrage oder -Antwort zu übergeben. Kopfzeilen können nach ihren Kontexten gruppiert werden.
Allgemeine Header gelten sowohl für Anfragen als auch für Antworten, jedoch ohne Bezug zu den im Hauptteil übertragenen Daten. Anfrage-Header enthalten weitere Informationen über die abzurufende Ressource bzw. über den Client, der die Ressource anfordert. Response-Header enthalten zusätzliche Informationen über die Antwort, z. B. die URL der Quellwebseite oder den Server, der die Antwort liefert. Entity-Header enthalten Informationen über den Hauptteil der abgeholten Webseite, z. B. die Länge des Inhalts oder die Art des Inhalts.
Header können auch danach gruppiert werden, wie Proxys sie behandeln, z. B. Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization und andere.
End-to-End-Header: Diese Header müssen an den finalen Empfänger der Nachricht übertragen werden: den Server für eine Anfrage oder den Client für eine Antwort. Zwischengeschaltete Proxys müssen diese Header unverändert weitersenden und Caches müssen sie speichern.
Hop-by-Hop-Header: Diese Header sind nur für eine einzige Verbindung auf Transport-ebene sinnvoll und dürfen nicht von Proxys darüber hinaus erneut übertragen oder zwischengespeichert werden. Es ist zu beachten, dass nur Hop-by-Hop-Header über den Connection-General-Header gesetzt werden dürfen. Ein wesentliches Detail der Funktionalität, die Hop-by-Hop-Header verwendet, ist die Tatsache, dass solche Hea-der ausschließlich zwischen dem Gerät, von dem die Anfrage ausgeht, und dem Proxy übertragen werden, während der primäre Zweck solcher Header darin besteht, die Verwaltung der entsprechenden Proxy-Sitzung zu unterstützen.
Ein HTTP-Cookie (Web-Cookie, Browser-Cookie) ist ein kleines Datenelement, das ein Server an den Webbrowser des Benutzers sendet. Der Browser kann das Cookie speichern und es bei späteren Anfragen an denselben Server zurücksenden. Typischerweise wird das Cookie verwendet, um zu erkennen, ob zwei Anfragen vom selben Browser kamen - zum Beispiel, um einen Benutzer angemeldet zu halten. Das Cookie merkt sich zustandsbezogene Informationen für das zustandslose HTTP-Protokoll.
Cookies werden hauptsächlich für drei Zwecke verwendet: 1) Sitzungsmanagement (Logins, Warenkörbe, Spielstände oder alles andere, was der Server sich merken soll); 2) Personalisierung (Benutzerpräferenzen, Benutzeroberflächen und andere Einstellungen); 3) Nachverfolgung (Aufzeichnung und Analyse des Benutzerverhaltens).
Der Cookie-Header der HTTP-Anfrage enthält gespeicherte HTTP-Cookies, die zuvor vom Server mit dem Set-Cookie-Header gesendet wurden. Der Cookie-Header ist optional und kann weggelassen werden, wenn z. B. die Datenschutzeinstellungen des Browsers Cookies blockieren.
Die GET-Methode wird verwendet, um Informationen vom Ziel abzurufen. Bei Einhaltung der REST-API-Richtlinien werden bei Anfragen mit der GET-Methode nur die Quelldaten abgerufen, aber nicht verändert oder anderweitig beeinflusst. Die POST-Methode wird verwendet, um Daten an die angegebene Ressource zu übermitteln. Anfragen, die die POST-Methode verwenden, erstellen die Quelldaten oder, wenn die REST-Richtlinien nicht strikt befolgt werden, aktualisieren die Quelldaten.
Die POST-Methode ermöglicht es dem Benutzer, Daten an das Webziel zu senden und zu übermitteln. Diese Daten werden in einen HTTP-Nachrichtentext aufgenommen, der von einer HTTP-Anfrage übertragen wird. Diese Daten müssen codiert werden, bevor sie durch die Betriebsschritte des Systems gesendet werden. Die Daten werden aus Gründen der Datensicherheit codiert. Die Daten werden codiert, bevor die HTTP-Anfrage an den Proxy-Server gesendet wird.
Das Protokoll, das zur Übertragung von Informationen über Verbindungen zwischen Proxys verwendet wird, wird als Proxy-Protokoll bezeichnet. Das Proxy-Protokoll bietet eine praktische Möglichkeit, Verbindungsinformationen wie z. B. die Adresse eines Clients sicher über mehrere Schichten von Schemata von Network-Address-Translation (NAT) oder TCP-Proxys zu transportieren. Es ist so konzipiert, dass nur geringe Änderungen an bestehenden Komponenten erforderlich sind und die Leistungsbeeinträchtigung durch die Verarbeitung der transportierten Informationen begrenzt wird.
Der Proxy-Protokoll-Header ist der Block von Verbindungsinformationen, den der Verbindungsinitiator am Anfang einer Verbindung voranstellt, wodurch der Header aus Sicht des Protokolls die maßgebliche Bezeichnung für die Quelle der Verbindung ist.
Das Ziel des Proxy-Protokolls ist es, die internen Strukturen des Servers mit den vom Proxy gesammelten Informationen zu füllen, die der Server selbst hätte erhalten können, wenn sich der Client direkt mit dem Server statt über einen Proxy verbunden hätte. Die vom Protokoll übertragenen Informationen sind solche, die der Server mit den Methoden getsockname() und getpeername() erhalten würde:

- Adressfamilie (AF_INET für IPv4, AF_INET6 für IPv6, AF_UNIX)
- Socket-Protokoll (SOCK_STREAM für TCP, SOCK_DGRAM für UDP)
- Schicht 3 (IP) Quell- und Zieladressen
- Schicht 4 (z. B. TCP oder UDP) Quell- und Zielports, falls vorhanden

Der gesamte Header wird immer auf einmal geliefert, wenn die Socket-Puffer zu Beginn einer Verbindung noch leer sind. Der Sender muss immer sicherstellen, dass der Header auf einmal gesendet wird, damit die Transportschicht die Atomarität auf dem Weg zum Empfänger erhält. Der Empfänger kann tolerant gegenüber unvollständigen Headern sein oder die Verbindung einfach abbrechen, wenn er einen unvollständigen Header erhält.
Der Web-Crawler hat zwei Hauptansätze zur Umsetzung seiner Aufgaben: synchron und asynchron. Die synchrone Methode (auch als Echtzeit-Methode bezeichnet) holt die Daten über dieselbe Verbindung zum Benutzer ab. Die asynchrone Methode (auch Callback-Methode genannt) baut eine andere Verbindung für die Datenlieferung auf und verwendet diese. Die vorgestellten Ausführungsformen funktionieren generell im synchronen Web-Scraping-Modell.
Bei der synchronen Datenübermittlungsmethode sendet der Benutzer die Anfrage an den Web-Crawler, und der Crawler gibt die angeforderten Daten über dieselbe offene HTTP(S)-Verbindung zurück. Da die asynchrone Datenbereitstellungsmethode die Möglichkeit bietet, zu entscheiden, wann die angeforderten Daten abgerufen werden sollen, ist es nicht erforderlich, eine offene Verbindung zwischen dem Kunden und den Backend-Diensten, wie z. B. einem Web-Crawler, aufrechtzuerhalten. Der Web-Crawler informiert den Benutzer, wenn die Daten bereit sind. In beiden Fällen wird die Aufgabe für den Web-Crawler formuliert, indem eine Liste von Ziel-URLs bereitgestellt wird, auf die der Crawler zuzugreifen versuchen muss.
ZUSAMMENFASSUNG
Es gibt mehrere Probleme im Zusammenhang mit der Leistung von Web-Crawlern, darunter unzureichende Informationen, die von den Inhaltsquellen gesammelt werden, unzureichende Eigenschaften der Anfrage und begrenzte Fähigkeiten der eingesetzten Proxys. Ein Proxy der nächsten Generation kann für zusätzliche Zwecke eingesetzt werden, als nur den Datenverkehr des Benutzers weiterzuleiten und die Informationen zurückzugeben. Proxys der nächsten Generation können die Informationen des Benutzers einsehen und bei Bedarf ändern, um bessere Scraping-Ergebnisse zu erhalten. Mit Proxys der nächsten Generation ist es möglich, die Logik, die von Proxys abhängt, weiterhin zu nutzen. Außerdem kann ein Proxy der nächsten Generation den größten Teil der Entsperrungslogik übernehmen, die ein Benutzer persönlich verwalten müsste. Benutzer müssen die Logik zur Überwindung von Sperrungen nicht kennen, die Teil der vom Dienstanbieter eingesetzten Scraping-Funktionalität wird. Der Proxy der nächsten Generation ist in der Lage, die Scraping-Logik so anzupassen, dass mögliche Einschränkungen und Hindernisse umgangen werden können.
In einem Aspekt offenbaren die hierin beschriebenen Ausführungsformen ein Verfahren zur Optimierung der Parameter einer Scraping-Anfrage eines Benutzers auf der Seite des Dienstanbieters. Bei der Verarbeitung der Scraping-Anfrage, die über das HTTPS-Protokoll an ein Ziel gerichtet ist, findet der Standard-TLS-Handschlag (TLS: Transport Layer Security) zwischen der Infrastruktur des Dienstanbieters, d. h. dem eigentlichen Scraping-Agenten, und dem Ziel statt, während der für die Anfrage verwendete Ausgangsknoten unter Verwendung einer HTTP-Methode - CONNECT - zum Aufbau eines Netzwerktransportschichttunnels zum Ziel im Namen des Scraping-Geräts durchlaufen wird.
Die hierin detailliert beschriebenen Ausführungsformen erweitern die Verfahren zur Umsetzung von Aufgaben, einschließlich der Ausrichtung auf einen Schritt eines Web-Crawling-Prozesses - einen Schritt der Übermittlung einer Anfrage durch einen Kunden an einen Web-Crawler. Die hierin detaillierten Ausführungsformen ermöglichen es, eine komplexere Anfrage für einen Web-Crawler zu definieren und somit spezifischere Daten zu erhalten. Das Datenabrufsystem und - verfahren des Web-Crawlers bleibt dabei unverändert. Dies beinhaltet den gleichen allgemeinen Web-Crawler-Aufgabenablauf, d.h. die Annahme der Anfrage vom Benutzer, den Versuch, die angeforderten Daten abzurufen, und die Übermittlung der Daten an den Benutzer.
Die hierin beschriebenen Ausführungsformen arbeiten in einer Umgebung eines Datenabrufsystems, d. h. Benutzer - Datenabrufsystem - Ziel im Web, und beschreiben ein untrennbares strukturelles und funktionales Element eines Datenabrufsystems. Im Wesentlichen verbessern die hierin beschriebenen Ausführungsformen das System in drei Bereichen: Aufgabendefinition, sichere Aufgabenimplementierung und Ergebnisoptimierung. Die hierin beschriebenen Ausführungsformen ermöglichen es dem Benutzer, umfassendere Aufgaben für ein Datenabrufsystem zu formulieren, einschließlich der Möglichkeit, HTTP-Anfrage-Header und Cookies zu übermitteln, anstatt nur eine URL an reine Datenabrufsysteme zu übermitteln, die nicht zusätzlich mit einer Funktionalität zur Beachtung der Anfrageparameter ausgestattet sind.
Der Proxy der nächsten Generation ermöglicht es dem Benutzer, ein Token zu erstellen, mit dem der Proxy die gleiche IP-Adresse oder Sitzung wiederverwenden kann. Beim Betrieb eines Datenabrufsystems wird eine Sitzung aufrechterhalten, indem der gleiche Ausgangsknoten eines Proxy-Servers für mehrere HTTP-Anfragen beibehalten wird.
Zusätzlich zur regulären Funktion dieser Fähigkeit ermöglichen die hierin beschriebenen Ausführungsformen das Senden von benutzerdefinierten HTTP-Headern und Cookies über den reservierten Ausgangsknoten. Die Unterstützung von POST-Anfragen ermöglicht es dem Benutzer, auch während der gleichen Sitzung Daten an das Web-Ziel zu senden. Im regulären Betrieb des Datenabrufsystems wird die GET-Methode in HTTP-Anfragen verwendet, um das Ziel aufzurufen. Die hierin beschriebenen Ausführungsformen ermöglichen ebenfalls die Verwendung der POST-Methode. Bei der GET-Methode, die die Standardeinstellung ist, muss die HTTP-Anfrage nicht deklariert werden, während die POST-Methode explizit deklariert werden muss.
Die hierin beschriebenen Ausführungsformen erlauben es dem Benutzer, bestimmte, von den Standardwerten abweichende HTTP-Antwortstatuscodes als annehmbar zu deklarieren. Das System behandelt die Antworten mit den deklarierten Statuscodes als korrekt und leitet die abgerufenen Daten an den nächsten Datenverarbeitungsschritt weiter. Spezifische Statuscodes werden in der Nachricht der HTTP-Anfrage deklariert.
Die hierin beschriebenen Ausführungsformen ermöglichen es, zu prüfen, ob die URL des Benutzers korrekt ist, und, falls nicht, Änderungen an der URL vorzunehmen (in einer Weise, dass die URL nicht vom Ziel blockiert wird). Die Lösung ermöglicht auch das Ändern der HTTP-Header und Cookies oder das Hinzufügen benötigter HTTP-Header oder Cookies, wenn HTTP-Header oder Cookies vom Benutzer für den Proxy-Betrieb nicht ausreichend konfiguriert oder gesetzt sind.
Die hierin beschriebenen Ausführungsformen ermöglichen es, die Anfragen des Benutzers zu wiederholen, ohne den Benutzer zu benachrichtigen. Der Benutzer muss die Anfrage nicht wiederholt senden. Der Proxy der nächsten Generation sieht, dass die Anfrage nicht korrekt ausgeführt wurde und sendet die Anfragen erneut an das Ziel, bis zufriedenstellende Ergebnisse zusammengetragen wurden. Daher erhöht der Proxy der nächsten Generation die Erfolgsquote der Scraping-Ergebnisse erheblich.
Der Proxy der nächsten Generation kann die vom Benutzer bereitgestellten Parameter in Echtzeit überprüfen und direkt mitteilen, dass die Parameter technisch unzureichend sind oder nicht ausreichen, um den richtigen Anfrage-Antwort-Sitzungskontext zu gewährleisten. Der Proxy der nächsten Generation kann auch die Funktionalität des Scrapings durch einen großen Pool von Proxy-IP-Adressen als zusätzliche Sicherheitsebene gegen das Blockieren oder Verfälschen von Ergebnissen durch die Anti-Scraping-Techniken nutzen.
Figurenliste
Die Merkmale und Vorteile der hier beschriebenen Ausführungsbeispiele werden dem Fachmann auf dem Gebiet, auf das sich diese Offenbarung bezieht, beim Lesen der folgenden Beschreibung unter Bezugnahme auf die begleitenden Zeichnungen deutlich werden:

1 ist ein beispielhaftes Komponentendiagramm, das die Gesamtarchitektur der Komponenten und den Kontext von mindestens einem Aspekt der Lösungsfunktionen zeigt.
2A zeigt einen beispielhaften allgemeinen Aufbau aus dem Stand der Technik für derzeit verwendete Scraping-Funktionen.
2B zeigt eine beispielhafte erfindungsgemäße Implementierung von Scraping-Techniken mit Scraping-Logik, die beim Dienstanbieter angesiedelt ist.
3A ist ein beispielhaftes Sequenzdiagramm, das den Weg der Scraping-Anfrage unter Verwendung eines Proxys der nächsten Generation beschreibt.
3B ist eine beispielhafte Darstellung der Scraping-Anfrage und ist eine Fortsetzung von 3A.
4A ist ein beispielhaftes Sequenzdiagramm der Scraping-Anfrage, wenn das Ziel eine fehlerhafte Antwort zurückgibt.
4B ist ein beispielhaftes Sequenzdiagramm der Scraping-Anfrage, wenn das Ziel eine fehlerhafte Antwort zurückgibt, und ist eine Fortsetzung von 4A.
4C ist ein beispielhaftes Sequenzdiagramm der Scraping-Anfrage, wenn das Ziel eine fehlerhafte Antwort zurückgibt, und ist eine Fortsetzung von 4B
5 ist ein beispielhaftes Sequenzdiagramm, das die Optimierung der Scraping-Anfrage durch den Proxy der nächsten Generation beschreibt.
6 ist ein beispielhaftes Computersystem, das die offengelegten Methoden ausführt.

DETAILLIERTE BESCHREIBUNG
Einige allgemeine Beschreibungen der Terminologie können hilfreich sein und sind hier der Einfachheit halber enthalten und sind im weitestmöglichen Sinne zu interpretieren.
Die Elemente 104 bis 110 identifizieren Teile der Dienstanbieter-Infrastruktur, wobei die Elemente 102, 116, 118, 120 externe Komponenten oder Systeme zeigen.
Benutzergerät 102 - kann jedes geeignete Benutzer-Computergerät sein, einschließlich, aber nicht beschränkt auf ein Smartphone, ein Tablet-Computergerät, ein Personal Computer, ein Laptop-Computergerät, ein Spielgerät, ein Fahrzeug-Infotainment-Gerät, ein intelligentes Gerät (z. B. ein intelligenter Kühlschrank oder ein intelligentes Fernsehgerät), ein Cloud-Server, ein Großrechner, ein Notebook, ein Desktop, eine Workstation, ein mobiles Gerät oder ein anderes elektronisches Gerät, das für eine Scraping-Anfrage verwendet wird.
Anfrageoptimierer 104 - ist ein Proxy der nächsten Generation, der ein Teil der Infrastruktur des Dienstanbieters ist, der Anfragen vom Benutzergerät annimmt und Anfragen durch das System umsetzt. Mithilfe eines Analysealgorithmus kann der Anfrageoptimierer die Metadaten der Anfrage lesen und die Anfrage mithilfe verschiedener vorher festgelegter Scraping-Strategien anpassen, um das Ziel besser abzurufen. Es ist zu beachten, dass die Metadaten der Antwort für den Anfrageoptimierer 104 immer sichtbar sind, z. B. URL und HTTP-Header. Diese Funktionalität ist notwendig, damit der Anfrageoptimierer 104 die Anfrageparameter korrekt verarbeiten kann, um die Anfrage zu analysieren und anzupassen.
Proxy-Rotator 106 - ist ein Teil der Dienstanbieter-Infrastruktur und ist mit separaten externen Komponenten gekoppelt, die spezifische Assistenzfunktionen implementieren, und ist für die Proxy-Steuerung, Rotation, Wartung, das Sammeln von statistischen Daten und die Berichterstattung verantwortlich.
Proxy A 108 und Proxy B 110 - bezeichnen eine beispielhafte Vielzahl von Proxy-Servern (Computersysteme oder Anwendungen), die für die Client-Verbindung geöffnet sind und als Vermittler für Anfragen von Clients fungieren, die Ressourcen von anderen Servern suchen. Ein Client verbindet sich mit dem Proxy-Server und fordert einen Dienst an, z. B. eine Datei, eine Verbindung, eine Webseite oder andere Ressourcen, die von einem anderen Server verfügbar sind. Der Proxy-Server wertet die Anfrage nach Inhalten aus und leitet die Anfrage an die eigentliche(n) Zielressource(n) weiter, die den eigentlichen Inhalt enthalten. Nach Erhalt des Inhalts leitet der Proxy-Server den Inhalt normalerweise an den ursprünglichen Absender der Anfrage weiter, es können aber auch andere Aktionen des Proxys durchgeführt werden (z. B. Rückgabe einer Fehlermeldung). In einem Aspekt in mindestens einer der hierin beschriebenen Ausführungsformen hat ein Proxy-Server möglicherweise nicht die volle Einsicht in den tatsächlichen Inhalt, der für den ursprünglichen Absender der Anfrage abgerufen wird, z. B. im Falle einer verschlüsselten HTTPS-Sitzung, wenn der Proxy nicht der entschlüsselnde Endpunkt ist, dient der Proxy als Vermittler, der die Daten blind weiterleitet, ohne zu wissen, was weitergeleitet wird. Es ist jedoch zu beachten, dass die Metadaten der Antwort für den Dienstanbieter immer sichtbar sind, z. B. HTTP-Header. Diese Funktionalität ist notwendig, damit der Proxy die erhaltenen Daten korrekt an die richtige anfragende Partei - den Endbenutzer oder das vermittelnde Proxy-Gerät - weiterleiten kann. Proxy A und Proxy B werden hier als einfachen Hinweis darauf dargestellt, dass es mehr als einen Proxy-Server geben kann, der in der Dienstanbieter-Infrastruktur 114 vorgehalten wird. Die Ausführungsformen sollten nicht auf die Proxys beschränkt sein, die dem Dienstanbieter gehören. Die Proxys können im Besitz einer beliebigen dritten Partei sein und von dieser verwaltet werden, jedoch hat der Dienstanbieter immer Zugriff auf diese Proxys und kann sie nutzen.
Proxy-Datenbank 112 - ist eine strukturierte Datenbank (DB), die in einem Datenspeichergerät enthalten ist, z. B. einer Computerfestplatte oder einem Computerspeicher. Die Besonderheiten der Implementierung der Proxy-Datenbank sind für die bereitgestellte Funktionalität nicht relevant, sei es eine Anwendung von horizontaler oder vertikaler Partitionierung, hardwarebasiertes Clustering, ein verteiltes Modell auf Anwendungsebene; mit jeder dieser Optionen, die innerhalb eines einzelnen Hardware-Geräts oder in verteilter Weise betrieben werden, wobei die Daten über mehrere Schema-Instanzen, Server, Rechenzentren, Länder oder Kontinente verteilt sein können, um die Last zu verteilen, die Leistung zu verbessern, die Ausfallsicherheit der Plattform oder andere Ziele zu gewährleisten. Die Proxy-Datenbank wird mit Daten aus dem Proxy-Rotator bestückt und enthält Informationen über alle für den Dienstanbieter verfügbaren Proxys.
Ziel A 116 und Ziel B 118 - ist eine beispielhafte Vielzahl von Webservern, die den über HTTP/HTTPS-Protokolle zugänglichen Inhalt anbieten. Die beiden Ziele, Ziel A und Ziel B, werden hier als einfacher Hinweis darauf dargestellt, dass es mehr als ein Ziel geben kann, aber dies sollte in keiner Weise als Einschränkung des Umfangs der Offenlegung verstanden werden. Es kann eine unbegrenzte Anzahl von Zielen im Netzwerk geben.
Netzwerk 120 - ist ein digitales Telekommunikationsnetzwerk, das es den Knoten ermöglicht, Ressourcen gemeinsam zu nutzen und darauf zuzugreifen. Beispiele für ein Netzwerk: Local-Area-Networks (LANs), Wide-Area-Networks (WANs), Campus-Area-Networks (CANs), Metropolitan-Area-Networks (MANs), Home-Area-Networks (HANs), Intranet, Extranet, Internetwork, Internet.
Scraping-Logik 202 - ist ein Algorithmus, der vom Anfrageoptimierer 104 eingesetzt wird und die Aufgabe hat, eine Vielzahl von vorher festgelegten Anfrageparametern auszuwählen, die für eine bestimmte Scraping-Anfrage ausgewählt werden, um bestimmte Daten vom Ziel zu suchen und zu sammeln. Die Scraping-Logik 202 enthält eine große Anzahl von Scraping-Strategien 504.
Scraping-Strategie 504 - ist ein Satz von Anfrageparametern und deren Werten, die für einen bestimmten Typ von Anfrage oder Ziel optimiert sind und die der Anfrageoptimierer 104 auf die ursprüngliche Anfrage anwendet, basierend auf den Entscheidungen, welche Anpassungen in die ursprüngliche Anfrage eingeführt werden sollten. Die Entscheidungen beruhen auf der Scraping-Logik 202. Die Scraping-Strategie 504 kann ein vordefiniertes Artefakt sein, das zuvor geplant, entwickelt und manuell registriert wurde. Die Scraping-Strategie 504 kann auch von der Scraping-Logik 202 dynamisch auf Grundlage der automatischen aggregierten Analyse der Scraping-Ergebnisse gebildet werden.
Positive Antwort - ist eine HTTP-Antwort, die als relevant erachtet und standardmäßig an den Benutzer weitergeleitet wird, wie z. B.: 2xx - alle erfolgreichen Antworten; 4xx - Client-Fehler (mit 5 Ausnahmen: 429, 407, 408, 444, 499).
Negative Antwort - ist eine HTTP-Antwort, die vom Benutzer als nicht akzeptabel angesehen wird, oder Standard-Systemcodes, die erfolglose Ergebnisse bedeuten, wie z. B.: 429, 407, 408, 444, 499; 5xx - alle Serverfehler.
In einem Aspekt verwendet das (die) hierin beschriebene(n) Scraping-System(e) das Standard-HTTP-Anfrage/Antwort-Modell zum Aufrufen und Zugreifen auf Ziele. Dieses Modell beschreibt die Client-Server-Kommunikation über das Web. Ein Client sendet eine HTTP-Anfrage an den Server mit der Bitte, auf bestimmte Daten zuzugreifen. Ein Server sendet eine HTTP-Antwort mit den angeforderten Daten an den Client zurück. Die HTTP-Anfrage gibt die Ziel-URL, die Zugriffsmethode, die Header und den Hauptteil der Anfrage an. Die HTTP-Antwort gibt Statusinformationen, die Header und die angeforderten Daten zurück.
Im regulären Betrieb des Datenabrufsystems kann der Benutzer nur den URL-Parameter in der HTTP-Anfrage steuern. Alle anderen Parameter der Anfrage werden durch das Datenabrufsystem gesteuert.
1 zeigt ein beispielhaftes Komponentendiagramm der Gesamtarchitektur der offengelegten Komponenten und den Kontext von mindestens einem Aspekt der Lösungsfunktionen. In mindestens einem Aspekt zeigen die vorliegenden Ausführungsformen die Kommunikation zwischen dem Benutzergerät 102 und der Dienstanbieter-Infrastruktur 114, um ein beliebiges Ziel 116 zu erreichen; 118 im Netzwerk 120. Die Dienstanbieter-Infrastruktur 114 setzt sich zusammen aus dem Anfrageoptimierer 104; dem Proxy-Rotator 106; der Proxy-Datenbank 112; und mindestens einem Proxy 108; 110. 1 zeigt, dass das Benutzergerät 102 nicht Teil der Dienstanbieter-Infrastruktur 114 ist und sich als unabhängiges Gerät außerhalb dieser Infrastruktur befindet. Das Benutzergerät 102 kann ein beliebiges Gerät sein, das über ein beliebiges Netzwerk, in den meisten Fällen jedoch über das Internet, eine Verbindung zu einer Dienstanbieter-Infrastruktur herstellen kann. Solche Geräte können ein Computer, ein Mobiltelefon, ein Tablet oder ein beliebiges anderes elektronisches Gerät sein. 1 zeigt, dass sich die Ziele 116; 118 außerhalb der Dienstanbieter-Infrastruktur 114 befinden und sich in einem beliebigen Netzwerk 120 befinden. In den meisten Fällen ist das Netzwerk 120 das Internet. Der Anfrageoptimierer 104 ermöglicht es dem Benutzer, die Anfrageparameter - HTTP-Header & Cookies, HTTP-Methoden (wie POST, GET, PUT, PATCH und DELETE) bis zu einem gewissen Grad zu modifizieren. Der Benutzer hat auch die Möglichkeit, eine HTTP-Sitzung aufzubauen und Erfolgsbedingungen für die Anfrage an die Zielserver zu definieren.
2A stellt ein beispielhaftes Gerät nach dem Stand der Technik dar, bei dem sich die Scraping-Logik 202 im Benutzergerät 102 befindet. 2B zeigt aktuelle Ausführungsformen, bei denen sich die Scraping-Logik 202 in der Dienstanbieter-Infrastruktur 114 befindet. Die Scraping-Logik verfügt über mehrere hundert oder tausend Scraping-Strategien. Scraping-Strategien werden durch die Analyse der Parameter des Ziels und die Definition von Best Practices für das Scraping bestimmter Ressourcen auf der Grundlage der Untersuchung und Auswertung der Antwortdaten des Ziels entwickelt. Zumindest einige der Kontextparameter der Scraping-Anfrage werden festgelegt, damit die passende Scraping-Strategie ausgewählt und angewendet werden kann:

- Erstellen des anfänglichen Kontextes für die Scraping-Anfrage, der die notwendigen Parameter umfasst, z. B. Header, Cookies, Browsereinstellungen des Benutzers, die dem Webserver während des ersten Kontakts vorgelegt werden. Die Erstellung des besagten Kontexts kann einen strikten Prozess der Vorab-Erstellung eines organischen, menschenähnlichen Browsing-Profils erfordern, indem mindestens eine Seite innerhalb des Ziels besucht wird, die nicht die Seite ist, die der Zweck des Scrapings ist, um das Browsing-Profil mit den Cookies des Ziel-Webservers zu bestücken. Andere Aktivitäten zur Erstellung des entsprechenden Sitzungskontextes können das Durchsuchen mehrerer Seiten innerhalb desselben Ziel-Webservers oder - für ein reichhaltigeres Browsing-Profil - die Darstellung des Verlaufs von Besuchen auf anderen Webservern, Aktivitäten in den sozialen Netzwerken und Ähnliches umfassen.
- Der geeignete geografische Standort für den Proxy der letzten Meile.
- Die entsprechende Zeitüberschreitung, die definiert ist, damit die Seite als erfolgreich ausgegeben gilt, wenn ein Headless-Browser als Anwendung für die Scraping-Anfrage verwendet wird.
- Die Inhaltselemente, die zwingend erforderlich sind, damit die Seite als erfolgreich ausgegeben gilt, wenn ein Headless-Browser als Anwendung für die Scraping-Anfrage verwendet wird.
- Die definierten Richtlinien für die Verarbeitung von HTTP-Weiterleitungen.
- Die Richtlinien, die definieren, welche HTTP-Codes zur Signalisierung von blockierten Browsing-Versuchen zu betrachten sind, die wiedeholt werden sollten.
- Die Richtlinien, die definieren, welche HTTP-Codes als durch Captcha blockiert gelten und entsprechend wiederholt werden.
- Die Richtlinien, die definieren, welche HTTP-Header für die Scraping-Anfrage obligatorisch sind, unabhängig von ihrem Vorhandensein in der ursprünglichen Anfrage des Benutzers.
- Die Richtlinien, die definieren, welche HTTP-Cookies für die Scraping-Anfrage obligatorisch sind, unabhängig von ihrem Vorhandensein in der ursprünglichen Anfrage des Benutzers.
- Die Richtlinien, die definieren, welche HTTP-Header durch ihre Gegenstücke ersetzt werden müssen, die als effektiver angesehen werden.
- Die Richtlinien, die definieren, welche HTTP-Header entfernt werden müssen, unabhängig davon, ob der Benutzer sie absichtlich in die ursprüngliche Anfrage aufgenommen hat.
- Die Richtlinien, die definieren, welche HTTP-Header innerhalb der Scraping-Anfrage vorhanden sein sollen (z. B. ‚User-Agent‘ für Chrome oder Firefox).
- Die Richtlinien, die definieren, welche Art von Proxys für die Scraping-Anfrage verwendet werden sollen (Rechenzentrums-Proxys, Residential-Proxys, Mobile-Proxys, etc.). Der Hauptfaktor, an dem sich die Proxy-Auswahl orientiert, ist das Ziel, für das die Strategien verwendet werden sollen. Eine spezialisierte Strategie wird für ein bestimmtes Ziel erstellt, basierend auf der Durchführung von Scraping-Tests und der Auswahl der Optionen, die das beste Verhältnis zwischen Erfolg und Misserfolg ergeben. Die angewandte Scraping-Strategie kann auch vom Inhalt der Benutzeranfrage abhängen: HTTP-Methode, Anfrageparameter, spezifische benutzerdefinierte Anforderungen.

Die hierin beschriebenen Ausführungsformen unterscheiden sich von den aktuellen Industriestandards für die Verwaltung der Scraping-Logik in mehreren Aspekten, einschließlich der Tatsache, dass Scraping-Funktionen, die zuvor von einem Benutzer, d. h. dem Kunden, ausgeführt wurden, nun auf der Seite des Dienstanbieters ausgeführt werden. Im Stand der Technik modifiziert die Dienstanbieter-Infrastruktur 114 die vom Benutzergerät 102 empfangenen Anfragen nicht, sondern leitet die Anfrage blind an das Ziel 116 weiter. Die neue Lösung stellt einen Weg dar, um sicherzustellen, dass die Antwort des Ziels 116 genauer ist, indem der Dienstanbieter die Scraping-Logik 202 verwendet. Die Scraping-Logik enthält einen Satz vorher festgelegter Regeln für die Zuweisung einer bestimmten Scraping-Strategie oder Strategien zu einer Anfrage, basierend auf der Analyse der Anfrage (Scraping-Strategien). Ein Satz von vordefinierten Anfrageparametern und deren Werte, die für einen bestimmten Typ von Anfrage oder Ziel optimiert sind, werden im Anfrageoptimierer 104 platziert, können vom Anfrageoptimierer 104 gelesen werden und passen die vom Benutzergerät 102 empfangene Anfrage an.
3A ist ein Ablaufdiagramm, das den Weg einer Scraping-Anfrage beschreibt. 3B ist die Fortsetzung des Ablaufs der Scraping-Anfrage. Der Ablauf beginnt, sobald das Benutzergerät eine Anfrage (Schritt 302) an den Dienstanbieter sendet, genauer gesagt an den Anfrageoptimierer 104. Der Anfrageoptimierer 104 prüft die Anfrageparameter (Schritt 304), wobei mindestens die URL-Adresse, die Header und die Cookies geprüft werden. Der Hauptteil der Anfrage kann in bestimmten Situationen auch modifiziert werden, z. B. wenn das Ziel der Scraping-Anfrage eine Webseite innerhalb der Top-Level-Domain (TLD) „.com‟ ist, fügt die Strategie die Anforderung hinzu, die Proxys zu verwenden, die die USA als geografischen Standort haben. Der Hauptteil der HTTP-Antwort wird ebenfalls analysiert, um zu erfahren, ob die erhaltenen Daten mit der Anfrage übereinstimmen. Ebenso können die Parameter der Anfrage des Benutzers geändert werden, um bessere Scraping-Ergebnisse zu erhalten. Ein Beispiel für solche Änderungen kann wie folgt beschrieben werden:
Ein Benutzer sendet eine Scraping-Anfrage an den Dienstanbieter, wobei der Hauptteil der HTTP-Anfrage als Inhaltstyp einen der MIME-Typen (Multipurpose Internet Mail Extensions) „komprimierte Datei“ aufweist, z. B. im .zip-Format (MIME type= application/zip). Der Dienstanbieter identifiziert das Ziel jedoch als ein System, das besser mit komprimierten Daten im .gz-Format (MIME type= application/gzip) funktioniert. Die Anfrage-Optimierungsplattform innerhalb der Dienstanbieter-Infrastruktur untersucht die Header und den Hauptteil der Anfrage, identifiziert diese Diskrepanz und passt sie entsprechend an, indem sie den Inhalt in das passende Format konvertiert sowie die entsprechenden Header aktualisiert.
Ein weiteres Beispiel für die Anpassung des Hauptteils der HTTP-Anfrage ist die Anfrage eines Benutzers, die einen XML-Inhalt im Hauptteil enthält (d. h. MIME type=application/xml). Ein Dienstanbieter hat eine vorher festgelegte Scraping-Logik-Richtlinie, die besagt, dass das angefragte Ziel mit hoher Wahrscheinlichkeit HTTP-Anfragen mit XML-Inhalt im Hauptteil blockiert, der für einen Menschen nicht lesbar ist. Daher passt der Dinstanbieter die Anfrage an die Eigenheiten des Webservers an, indem er z. B. den Inhaltstyp ändert (z. B. auf MIME type= text/xml). In dieser Situation werden der Hauptteil und die Header der Anfrage vom Dienstanbieter angepasst, um eine Blockierung durch das Ziel zu vermeiden und dementsprechend bessere Scraping-Ergebnisse zu erhalten. In einem weiteren Beispiel kann der Hauptteil der HTTP-Anfrage unter Verwendung der Verschlüsselungswerkzeuge des Dienstanbieters verschlüsselt werden, während die Anfrage geändert wird, wobei die für die Beschreibung notwendigen Artefakte entweder über einen alternativen Kanal oder in einem benutzerdefinierten Header innerhalb der Anfrage an die Zielpartei übertragen werden.
Wenn also die Parameter in der Anfrage nicht als derart mit dem entsprechenden Ziel korrespondierend erachtet werden, wie es als am effektivsten angesehen wird, werden sie gemäß der Scraping-Logik 202 angepasst, die in den Speicher des Anfrageoptimierers 104 geladen ist (Schritt 306). Der Anfrageoptimierer 104 prüft, ob die URL-Adresse korrekt angegeben ist, und wenn nicht, dann wird die URL-Adresse so korrigiert, dass die Blockierungsrate minimiert wird. Der Anfrageoptimierer 104 prüft auch die Header und Cookies der Anfrage und passt sie so an, dass die Qualität der Anfrage sowie die Qualität der Daten, die von einem Ziel zu erwarten sind, erhöht werden.
Der Hauptteil der HTTP-Anfrage kann unter bestimmten Umständen auch modifiziert werden, z. B. wenn das Ziel der Scraping-Anfrage in einer „.com‟ TLD liegt, schreiben die Richtlinien der Scraping-Logik vor, dass Proxys mit US-amerikanischem Standort für die Bearbeitung der Anfrage angefragt werden. Der Hauptteil der HTTP-Anfrage wird ebenfalls analysiert und ggf. angepasst, um bessere Scraping-Ergebnisse zu gewährleisten.
In mindestens einem Fall werden, nachdem die Anfrage vom Benutzer erhalten und der initiale Scraping-Sitzungskontext konstruiert wurde, für die Auswahl einer zu bestimmenden Strategie für die Anfrage bestimmte Richtlinien auf Benutzeranfragen angewendet, bevor ein Scraping der eigentlichen Zielseite stattfindet:

- der Detaillierungsgrad, den das Browsing-Profil des Scraping-Agenten haben soll, d. h., wenn die Homepage des Ziels vor dem eigentlichen Scraping besucht werden soll, wie viele Besuche auf den Webseiten des Ziels erforderlich sind, wenn nur ein Besuch der Startseite oder anderer Seiten erforderlich ist, um einen organisches Profil eines Benutzers zu erstellen, und/oder wenn der Besuch anderer Webseiten als des Ziels, z. B. sozialer Netzwerke, Unterhaltungsseiten, elektronischer Shops usw., erforderlich ist
- Geografischer Standort des vom Proxy-Rotator 106 bereitgestellten Proxys.
- Timeout-Schwelle für das Darstellen der Seite, falls ein Headless-Browser verwendet wird.
- Inhaltselemente, die vorhanden sein müssen, damit die Seite als dargestellt gilt, wenn ein Headless-Browser verwendet wird.
- Ob Umleitungen verfolgt werden sollen.
- HTTP-Statuscodes, die als blockiert gelten und entsprechend wiederholt werden sollten.
- HTTP-Statuscodes, die als durch Captcha blockiert gelten und entsprechend wiederholt werden sollten.
- HTTP-Anfrage-Header, die immer in die Anfrage eingefügt werden sollen, unabhängig davon, ob der Benutzer sie ursprünglich eingefügt hat.
- HTTP-Request-Cookies, die immer in die Anfrage eingefügt werden sollen, unabhängig davon, ob der Benutzer sie ursprünglich eingebunden hat.
- HTTP-Anfrage-Header, die durch ihre besseren Gegenstücke ersetzt werden müssen.
- HTTP-Anfrage-Header, die aus der Anfrage entfernt werden müssen, auch wenn der Benutzer sie in die Anfrage aufgenommen hat.
- Typen von HTTP-Anfrage-Headern, die vorhanden sein sollten (z. B. ‚U-ser-Agent‘ für Chrome oder Firefox).
- Art der Proxys, die verwendet werden sollen (Rechenzentrum, Residential, Mobile, etc.)

Die Aktivitäten zur Optimierung der von Kunden abgesendeten HTTP-Anfragen sind transparent, d. h., sobald die Anfrage vom Benutzer gestartet wurde, wird sie der Analyse und den Anpassungen gemäß der gewählten Scraping-Strategie unterzogen, wobei keine Interaktion seitens des verursachenden Benutzers erforderlich ist.
Wenn der Anfrageoptimierer 104 Ineffizienzen oder Fehler in den Headern und Cookies der Anfrage bemerkt, passt er die Parameter gemäß einem Satz vorher festgelegter Regeln an, die einer Anfrage eine bestimmte Scraping-Strategie oder Strategien zuweisen (gilt für die Scraping-Logik 202). HTTP-Header sind Bestandteile der Anfragenachricht und werden verwendet, um dem Server zusätzliche Informationen über das angeforderte Ziel zu übermitteln. Sie werden in der HTTP-Nachricht als Schlüssel-WertePaare definiert. Die Beispiel-HTTP-Anfragenachricht kann folgende Parameter enthalten: Zieladresse (z. B. http://scraping.com:60000), Sprachanforderungen (z. B. en-US); Inhalt/Typ der Anfrage (z. B. application/octetstream), benutzerdefinierten Header angeben, geografischer Standort (z. B. US), Cookie-Index (z. B. SID=1234567890; SLK_TJJ=0987654321). Wenn die Anfrage keine Änderungen benötigt, werden keine Korrekturen durch den Anfrageoptimierer 104 durchgeführt, jedoch prüft der Anfrageoptimierer 104 den Inhalt der Anfrage.
In mindestens einem Aspekt erläutern die hierin beschriebenen Ausführungsformen weiter, dass der Anfrageoptimierer 104 einen Proxy vom Proxy-Rotator 106 erhält. Sobald die Anfrageparameter angepasst sind, fragt der Anfrageoptimierer 104 den Proxy-Rotator 106 nach einem bestimmten Proxy (Schritt 308). Der Proxy-Rotator 106 greift auf die Proxy-Datenbank 112 zu und wählt einen bestimmten Proxy aus, der geeignet ist, die Anfrage des Benutzers umzusetzen (Schritt 310). Der Proxy-Rotator 106 stellt dem Anfrageoptimierer 104 die Informationen über den Proxy bereit (Schritt 312). In 3B werden die in 3A gezeigten Schritte fortgesetzt. Der Anfrageoptimierer 104 führt die Anfragen über den Proxy 108 aus, der vom Proxy-Rotator 106 bereitgestellt wird (Schritt 314). Nachdem der Anfrageoptimierer 104 einen Proxy erhalten hat, fährt er mit der Umsetzung einer vom Benutzergerät empfangenen Anfrage fort (Schritt 314). Der Proxy 108 erhält Daten vom angegebenen Ziel 116 (Schritt 316) und leitet diese Daten an den Anfrageoptimierer 104 weiter (Schritt 318). Der Proxy 108 erhält Daten vom Ziel 116 (Schritt 316). Das Ziel kann eine beliebige Webressource im Netzwerk sein, und das Netzwerk ist normalerweise das Internet. Sobald der Proxy 108 die Daten erhält, sendet der Proxy 108 die Daten zurück an den Anfrageoptimierer 104 (Schritt 318). Der Proxy 108 nimmt keine Änderungen an den empfangenen Daten vor und prüft nicht den Umfang oder die Qualität der Daten. Der Proxy 108 überträgt lediglich die vom Ziel 116 empfangenen Daten an den Anfrageoptimierer 104. Der Anfrageoptimierer 104 prüft die Metadaten der Antwort (Schritt 320). Der Proxy 108 ändert die vom Ziel 116 erhaltenen Informationen weder ab noch liest er sie aus, da er die Daten lediglich weiterleitet. Der Anfrageoptimierer 104 prüft jedoch die Metadaten der Antwort, d. h. er untersucht die Parameter der vom Ziel erhaltenen Antwort (Schritt 320), z. B. den HTTP-Antwortcode.
Wenn die Serverantwort empfangen wird, enthält die HTTP-Nachricht Details über den Antwortstatus. Der Antwortstatus informiert darüber, was das Ergebnis des Versuchs ist, das Ziel 116 zu erreichen. Antwortstatuscodes beziehen sich auf Gruppen möglicher Ergebnisse:

- 2xx - Erfolgreiche Antworten (positive Antwort);
- 3xx - Umleitungen (positive Antwort);
- 4xx - Client-Fehler (positive Antwort mit Ausnahmen);
- 5xx - Serverfehler (negative Antwort).

Im Betrieb des Web-Crawling- und Scraping-Systems werden die HTTP-Antworten die als positiv angesehen werden, an den nächsten Datenverarbeitungsschritt weitergegeben.
Im regulären Betrieb des Systems hat der Benutzer keine Kontrolle über diese Einstellung. Standardmäßig werden nur 2xx-Codes als annehmbar angesehen. Wenn der Anfrageoptimierer 104 im System implementiert ist, kann der Benutzer bestimmte, vom Standard abweichende, Statuscodes als annehmbar deklarieren. Das System behandelt die Antworten mit den deklarierten Statuscodes als korrekt und übergibt die abgeholten Daten an den nächsten Datenverarbeitungsschritt (322).
Spezifische Statuscodes werden in den HTTP-Anfrage-Headern deklariert durch ‚x-successful-status-codes‘-Header mit einem Wert, der eine Liste von erfolgreichen Statuscodes enthält: [500, 502, 42069]. Wenn der Benutzer keine spezifischen Statuscodes deklariert, arbeitet der Anfrageoptimierer 104 mit Standardeinstellungen:

- 1xx - Eine benachrichtigende Antwort zeigt an, dass die Anfrage empfangen und verstanden wurde. Sie wird vorläufig ausgegeben, während die Verarbeitung der Anfrage fortgesetzt wird. Sie weist den Client darauf hin, auf eine endgültige Antwort zu warten.
- 2xx - das System behandelt die Antwort als OK.
- 3xx - das System folgt Umleitungen standardmäßig für eine begrenzte Anzahl von Malen. Wenn die Obergrenze erreicht ist, registriert das System einen fehlgeschlagenen Auftrag.
- 4xx - das System behandelt die Antwort als OK mit fünf Ausnahmecodes 429, 407, 408, 444, 499.
- 5xx - das System führt eine eine begrenzte Anzahl von Wiederholungen durch. Wenn die Obergrenze erreicht ist, registriert das System einen fehlgeschlagenen Auftrag.

Wenn der Benutzer sich entscheidet, die benutzerdefinierten HTTP-Anfrage-Header zur Deklaration von Nicht-Standardverhalten für die Verarbeitung bestimmter HTTP-Antwortstatuscodes zu deklarieren, verhält sich der Anfrageoptimierer 104 folgendermaßen:

- 1xx - das System informiert den Benutzer, dass die angegebenen Statuscodes intermittierend sind und dass eine Änderung der Verarbeitungsweise nicht unterstützt wird.
- 2xx - das System teilt dem Benutzer mit, dass die angegebenen Statuscodes immer einen erfolgreichen Betrieb bezeichnen und eine Änderung ihrer Verarbeitungsweise nicht unterstützt wird.
- 3xx - das System teilt dem Benutzer mit, dass es dem Standardverhalten zum Folgen der Umleitungsanweisung des Servers befolgt.
- 4xx - das System informiert den Benutzer, dass die angegebenen Statuscodes an den Benutzer zurückgegeben werden, wobei die ausgeschlossenen Codes (unten aufgeführt) weggelassen werden. Die ausgeschlossenen Codes können als positives Ergebnis behandelt werden, wenn dies vom Benutzer gewünscht wird.
- 5xx - das System akzeptiert Benutzeränderungen am Standardverhalten, wenn der angegebene Code ein vollständiger 5xx HTTP-Antwortcode ist. Falls der Antwortcode in der Antwort genau mit der Konfiguration übereinstimmt - werden die Daten an den Benutzer zurückgegeben. Andernfalls folgt das System dem Standardverhalten, die Anfrage zu wiederholen.

4xx (mit fünf Ausnahmecodes 429, 407, 408, 444, 499) werden als positives Ergebnis behandelt und die Daten solcher Anfragen werden an den Benutzer zurückgegeben. Wenn das System eine der fünf Ausnahmen erhält, wiederholt es die Anfrage erneut, bis die positive Antwort eintrifft oder die Anzahl der Versuche erschöpft ist. Der Benutzer kann jedoch eine benutzerdefinierte Verarbeitung für die Ausnahmecodes festlegen und die Daten solcher Antworten an den Benutzer weiterleiten lassen.
Wenn die Antwort-HTTP-Header des Ziels die als positiv deklarierten HTTP-Antwortcodes enthalten, werden die Daten durch den Anfrageoptimierer 104 an das Benutzergerät 102 weitergeleitet (Schritt 322). In diesem Schritt erhält das Benutzergerät 102 die eigentlichen Daten, z. B. den Hauptteil der HTTP-Antwort, und die Metadaten - die Header, von denen einer den HTTP-Antwort-Statuscode enthält, und als Teil der Metadaten - die benutzerdefinierten Header, die detaillierte Informationen über den Status des Scraping-Auftrags enthalten.
Die 4A, 4B und 4C sind eine beispielhafte Reihe von Sequenzdiagrammen, die den den Weg der Scraping-Anfrage beschreiben, wenn das Ziel eine fehlerhafte Antwort zurückgibt. Diese Figuren zeigen im Wesentlichen die gleichen Schritte für die Anforderung eines Proxys durch den Anfrageoptimierer 104 und die Verwendung dieses Proxys, um die Anfrage des Benutzers umzusetzen. Der Ablauf beginnt, sobald das Benutzergerät eine Anfrage (Schritt 402) an den Dienstanbieter, genauer gesagt an den Anfrageoptimierer 104, sendet. Der Anfrageoptimierer 104 prüft die Parameter der Anfrage (Schritt 404) sowie die Header und Cookies. Wenn die Parameter nicht als korrekt angezeigt werden, werden sie gemäß der in den Speicher des Anfrageoptimierers 104 geladenen Scraping-Logik 202 angepasst (Schritt 406). In mindestens einer hierin beschriebenen Ausführungsform wird in der Offenlegung weiter erläutert, dass der Anfrageoptimierer 104 einen Proxy vom Proxy-Rotator 106 erhält. Der Anfrageoptimierer fordert als nächstes den Proxy an (Schritt 408). Der Proxy-Rotator 106 erhält den Proxy von der Proxy-Datenbank 112 (Schritt 410) und liefert den Proxy an den Anfrageoptimierer 104 (Schritt 412). Nachdem er einen Proxy erhalten hat, fährt der Anfrageoptimierer 104 fort, eine vom Benutzergerät empfangene Anfrage umzusetzen (Schritt 414). Der Proxy 108 erhält Daten von dem angegebenen Ziel 116 (Schritt 416) und leitet diese Daten an den Anfrageoptimierer 104 weiter (Schritt 418). Der Proxy 108 nimmt keine Änderungen vor zu den empfangenen Daten und überprüft nicht den Umfang oder die Qualität der Daten. Ein Proxy 108 überträgt die vom Ziel 116 empfangenen Daten einfach an den Anfrageoptimierer 104. Der Anfrageoptimierer 104 prüft die empfangenen Metadaten (Schritt 420), und wenn der Antwortstatus negativ ist (z. B. 4xx-Code-Ausnahmefälle wie 429, 407, 408, 444, 499 oder 5xx-Codes), behandelt der Anfrageoptimierer 104 die Antwort als fehlgeschlagen und sendet die Daten nicht an den Benutzer (Schritt 422). In solchen Situationen passt der Anfrageoptimierer 104 die Anfrageparameter an (Schritt 424) und wiederholt die angepasste Anfrage. Die Anfrage kann angepasst werden, indem einige Parameter der Anfrage gemäß den Anweisungen innerhalb der ausgewählten Scraping-Strategie geändert werden, versucht wird, eine andere vorher festgelegte Scraping-Strategie zu verwenden, oder die Scraping-Anfrage an das Ziel ohne Änderungen in der Strategie versuchsweise gerichtet wird.
Eine Scraping-Anfrage kann entsprechend der Analyse der Antwort des Ziels angepasst werden, z. B. wenn die Metadaten innerhalb der Antwort den HTTP-Antwortcode 504 darstellen - der Anfrageoptimierer kann eine Scraping-Strategie anwenden, die einen zusätzlichen Header einführt, wohingegen der HTTP-Antwortcode 403 die Anwendung einer Strategie erfordern kann, die die Anfrage mit organischen benutzerähnlichen Verhaltensmarkern anreichert, z. B. Cookies von früheren Besuchen des Ziels oder anderer Webressourcen.
Alle Teile der Antwort des Ziels sowie ihr Inhalt können für die Entscheidung über die geeigneten Anpassungen der gesamten Scraping-Strategie der Anfrage relevant sein. Einige Details darüber, wie das Ziel die angeforderten Daten zurückgibt, können ebenfalls relevant sein.
Der Anfrageoptimierer 104 fordert einen Proxy vom Proxy-Rotator 106 an (Schritt 426). Der Proxy-Rotator 106 erhält einen Proxy von der Proxy-Datenbank 112 (Schritt 428) und liefert die Informationen über den Proxy an den Anfrageoptimierer 104 (Schritt 430). Der Anfrageoptimierer 104 verwendet den Proxy 108, um die Anfrage umzusetzen (Schritt 432). Der Proxy 108 erhält die Daten vom Ziel 116 (Schritt 434) und leitet die Daten an den Anfrageoptimierer 104 weiter (Schritt 436). Der Anfrageoptimierer 104 prüft die Metadaten (Schritt 438) und sendet die Daten an das Benutzergerät 102, wenn die Antwort positiv ist (Schritt 440). Wenn die Antwort nicht positiv ist, wiederholt Anfrageoptimierer die Schritte der Anpassung der Anfrageparameter und des Sendens der Anfrage an das Ziel unter Verwendung des ausgewählten Proxys (d. h. die Schritte 406 bis 438 werden wiederholt). Diese Schritte des Überprüfens der Antwort des Ziels und des Wiederholens der Anfrage, wenn die Antwort negativ ist, können wiederholt werden, bis eine positive Antwort empfangen wird oder bis die Anzahl der negativen Antworten eine bestimmte angegebene Anzahl erreicht (z. B. kann der Anfrageoptimierer 104 so konfiguriert werden, dass er die Parameter der Anfrage 25 Mal oder öfter anpasst, und wenn innerhalb von 25 Mal die Antwort immer noch negativ ist, werden die negativen Ergebnisse an das Benutzergerät 102 gesendet).
In einem weiteren Aspekt ermöglicht mindestens eine hierin beschriebene Ausführungsform des Anfrageoptimierer 104 die Aufrechterhaltung einer Sitzung für mehrere HTTP-Anfragen, was ein Merkmal von Datenabrufsystemen ist. Hier wird eine Sitzung unter Verwendung desselben Ausgangsknotens für mehrere HTTP-Anfragen implementiert. In einem beispielhaften Betrieb des Anfrageoptimierers 104 beinhaltet eine Sitzung die Verwendung des gleichen IP-Proxys, der gleichen Header und der gleichen Cookies über die gesamte Sitzung. Der beispielhafte Betrieb ermöglicht auch das Senden von GET- und POST-Anfragen (d. h. das Empfangen und Senden von Daten) während derselben Sitzung. Der Anfrageoptimierer 104 kann dieselbe Sitzung mit demselben Proxy 108 für mehrere fortlaufende Anfragen im Kontext derselben Scraping-Sitzung offenhalten, die von einem einzigen Gerät des Benutzers kommen. Zunächst zeigt eine anfängliche Anfrage des Benutzers an, dass eine dauerhafte Sitzung für zukünftige Anfragen aufrechterhalten werden soll, indem eine Identifikationsmarkierung für die Sitzung im Format einer Zeichenkette erstellt wird, z. B. „1234567890abcdef“. Beim Empfang einer Anfrage mit der Sitzungsidentifikationsmarkierung wird der Anfrageoptimierer 104 ausreichend informiert, um der Proxy-Verwaltungsplattform anzuweisen, die Sitzung als persistent für diesen bestimmten Proxy zu registrieren und diese Verbindung mit dem angegebenen Sitzungsidentifikationsmarker zu registrieren. Um denselben Proxy für die nächste Anfrage weiter zu verwenden, gibt der Benutzer die zuvor eingerichtete Sitzungskennung an, während er die Scraping-Anfrage absendet. Die Proxy-Verwaltung stellt denselben Proxy zur Verfügung und stellt die Verbindung zum Ziel über denselben Proxy erneut her. Es ist jedoch zu beachten, dass die Sitzungskennung eine Ablaufschwelle hat, die als überschritten gilt, wenn entweder a) eine vordefinierte Zeitspanne verstrichen ist oder b) die Anzahl der Anfragen, die die selbe Sitzung nutzen können, erschöpft wurde. Nach dem Ablauf führt die nächste Anfrage, die die abgelaufene Sitzungskennung enthält, dazu, dass eine neue dauerhafte Sitzung initiiert wird.
Das System erstellt eine Sitzung mit der angegebenen session_id, paart die Sitzung mit dem spezifischen IP-Proxy und den angegebenen HTTP-Headern und behält denselben Ausgangsknoten für die gesamte Sitzung bei. Außerdem werden die folgenden Parameter vom System für die Sitzung gesetzt: session_uuid, session_expires_at, session_remaining. Diese Parameter sind systematisch, d. h. ein Benutzer hat keine Kontrolle über sie. Eine Sitzung wird offengehalten, bis die Sitzungszeit abläuft oder ein Fehler auftritt.
5 zeigt ein beispielhaftes Ablaufdiagramm, das die Optimierung der Scraping-Anfrage beschreibt. Die Anfrage mit nicht optimierter Logik wird vom Anfrageoptimierer 104 empfangen (Schritt 502). Der Anfrageoptimierer 104 wählt eine geeignete Scraping-Strategie entsprechend den Anforderungen und Zielen der Anfrage aus (Schritt 504), wobei eine Vielzahl von Scraping-Strategien erstellt und im Anfrageoptimierer 104 gespeichert wird. Jede solche Strategie oder eine Kombination davon kann vom Anfrageoptimierer 104 zur Anpassung der Anfrage genutzt werden, um bessere Scraping-Ergebnisse zu erhalten. Ein Beispiel für eine solche Strategie kann die Einführung oder Anpassung von benutzerdefinierten Headern sein, die den geografischen Standort, die Zeitzone oder die in der Anfrage zu verwendende lokale Sprache identifizieren. Sobald die Anfrage angepasst ist, wird sie einer weiteren Verarbeitung unterzogen (Schritt 506).
Jede der obigen Ausführungsformen hierin kann neu angeordnet und/oder mit anderen Ausführungsformen kombiniert werden. Dementsprechend sind die hierin enthaltenen Konzepte nicht auf eine bestimmte, hier offengelegte Ausführungsform beschränkt. Außerdem können die Ausführungsformen vollständig aus Hardware bestehen oder sowohl Hardware- als auch Software-Elemente umfassen. Teile der Ausführungsformen können in Software implementiert sein, was Firmware, residente Software, Mikrocode usw. einschließt, aber nicht darauf beschränkt ist.
6 veranschaulicht ein Computersystem 600, in dem ein computerlesbares Medium 606 Anweisungen zur Durchführung eines der hierin offenbarten Verfahren bereitstellen kann.
Darüber hinaus können die Ausführungsformen die Form eines Computerprogrammprodukts annehmen, auf das von dem computerlesbaren Medium 606 zugegriffen werden kann, das Programmcode zur Verwendung durch oder in Verbindung mit einem Computer oder einem beliebigen Befehlsausführungssystem bereitstellt. Für die Zwecke dieser Beschreibung kann das computerlesbare Medium 606 jede Vorrichtung sein, die das Programm zur Verwendung durch oder in Verbindung mit dem Befehlsausführungssystem, der Vorrichtung oder dem Gerät, einschließlich des Computersystems 600, greifbar speichern kann.
Das Medium 606 kann ein beliebiges greifbares elektronisches, magnetisches, optisches, elektromagnetisches, Infrarot- oder Halbleitersystem (oder Gerät oder Vorrichtung) sein. Beispiele für ein computerlesbares Medium 606 umfassen einen Halbleiter- oder Festkörperspeicher, ein Magnetband, eine austauschbare Computerdiskette, einen Direktzugriffsspeicher (RAM), einen NAND-Flash-Speicher, einen Festwertspeicher (ROM), eine starre Magnetplatte und eine optische Platte. Einige Beispiele für optische Platten sind Compact Disk - Nur-Lese-Speicher (CD-ROM), Compact Disk - Lesen/Schreiben (CD-R/W) und Digital Versatile Disc (DVD).
Das Computersystem 600, das zum Speichern und/oder Ausführen von Programmcode geeignet ist, kann einen oder mehrere Prozessoren 602 umfassen, die direkt oder indirekt über einen Systembus 610 mit dem Speicher 608 gekoppelt sind. Der Speicher 608 kann einen lokalen Speicher umfassen, der während der tatsächlichen Ausführung des Programmcodes verwendet wird, einen Massenspeicher und Cache-Speicher, die eine temporäre Speicherung von zumindest einem Teil des Programmcodes bereitstellen, um die Anzahl der Abrufe von Code aus dem Massenspeicher während der Ausführung zu reduzieren. Eingabe-/Ausgabe- oder E/A-Geräte 604 (einschließlich, aber nicht beschränkt auf Tastaturen, Displays, Zeigegeräte usw.) können entweder direkt oder über zwischengeschaltete E/A-Geräte mit dem System gekoppelt werden. Netzwerkadapter können auch an das System gekoppelt werden, damit das Computersystem 600 mit anderen Datenverarbeitungssystemen verbunden werden kann, z. B. über Host-System-Schnittstellen 612 oder entfernte Drucker oder Speichergeräte über dazwischenliegende private oder öffentliche Netzwerke. Modems, Kabelmodems und Ethernet-Karten sind nur einige der derzeit verfügbaren Arten von Netzwerkadaptern.
Obwohl mehrere Ausführungsformen beschrieben wurden, wird ein Fachmann erkennen, dass verschiedene Modifikationen und Änderungen vorgenommen werden können, ohne vom Umfang der hier beschriebenen Ausführungsformen abzuweichen. Dementsprechend sind die Beschreibung und die Figuren eher in einem illustrativen als in einem einschränkenden Sinne zu verstehen, und alle derartigen Modifikationen sollen in den Anwendungsbereich der vorliegenden Lehre einbezogen werden. Der Nutzen, die Vorteile, die Problemlösungen und jedes Element, das dazu führen kann, dass ein Nutzen, ein Vorteil oder eine Lösung auftritt oder ausgeprägter wird, sind nicht als kritische, erforderliche oder wesentliche Merkmale oder Elemente eines oder aller Ansprüche zu verstehen. Die Erfindung wird ausschließlich durch die beigefügten Ansprüche definiert, einschließlich aller Änderungen, die während der Anhängigkeit dieser Anmeldung vorgenommen wurden, und aller Äquivalente dieser Ansprüche in der erteilten Fassung.
Die Offenlegung stellt ein System und ein nicht-flüchtiges computerlesbares Speichermedium zum Extrahieren und Sammeln von Daten von einem Webserver vor, das Folgendes umfasst bzw. Anweisungen umfasst, die wenn sie von einer Rechenvorrichtung innerhalb einer Dienstanbieter-Infrastruktur ausgeführt werden, die Rechenvorrichtung dazu veranlassen, die folgenden Schritte durchzuführen: Vergleichen von Parametern einer von einem Benutzergerät empfangenen Anfrage mit einer Liste von Scraping-Strategien; Auswählen einer Scraping-Strategie aus der Liste von Scraping-Strategien, die zu den Parametern der Anfrage korrespondiert; Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie; Anpassen der Parameter der Anfrage entsprechend der Scraping-Strategie zum Bilden einer angepassten Anfrage; Senden der angepassten Anfrage an ein Ziel durch einen Proxy, der entsprechend der Scraping-Strategie ausgewählt wurde; Empfangen einer Antwort von dem Ziel.
Nach Erhalt der Anfrage führt eine Dienstanbieter-Infrastruktur die Anpassung der Parameter der Anfrage vom Gerät des Benutzers autonom aus.
Das Verfahren umfasst ferner das Prüfen und Analysieren der vom Ziel empfangenen Metadaten der Antwort und das Weiterleiten der Antwort an das Gerät des Benutzers gemäß der Analyse der Metadaten.
Wenn die vom Ziel empfangene Antwort negativ ist, wird das Verfahren wiederholt, indem die Parameter der Anfrage gemäß einer anderen Scraping-Strategie aus der Liste der Scraping-Strategien angepasst werden, um eine andere angepasste Anfrage zu bilden, die dann an das Ziel gesendet wird. Das Verfahren wird mit alternativen Scraping-Strategien wiederholt, die aus der Liste der Scraping-Strategien ausgewählt wurden, bis eine positive Antwort erhalten wird oder bis eine maximale Anzahl von Versuchen erreicht ist.
Bei den Anpassungen wird mindestens einer der Parameter innerhalb der folgenden Komponenten der Anfrage angepasst: URL-Adresse; Header; Cookies; Anfragehauptteil. Die Parameter der Anfrage werden nicht angepasst, wenn die vom Gerät des Benutzers empfangene Anfrage mit einer der Scraping-Strategien aus der Liste korrespondiert.
Der Proxy wird von einer Dienstanbieter-Infrastruktur aus einer Proxy-Datenbank ausgewählt. Der Proxy wird entsprechend der Scraping-Strategie ausgewählt und umfasst Einstellungen zum geografischen Standort, Proxy-Typ, Proxy-Verfügbarkeit oder eine beliebige Kombination davon. Der Proxy kann für Anfragen mehrerer Benutzergeräte verfügbar bleiben.
Das Verfahren verwendet den Anfrageoptimierer und seine Betriebseinstellungen umfassen mindestens eine der folgenden: Scraping-Strategien, Sitzungs-ID-Nummern, als Anfragesteller akzeptierte Server, Zeitfenster für den Betrieb, geplante Wartungsaufgaben, Zeitüberschreitungen von Verbindungssitzungen, Anfrageverarbeitungsprotokolle oder eine beliebige Kombination davon, und solche Einstellungen werden in einer Datenbank auf der Festplatte, einer Flat-File auf einer Festplatte, in einer Datenbank im Speicher oder in anderen Speichermedien gespeichert.
Das Ziel, das vom Proxy-Server erreicht wird, ist ein Webserver, der die über HTTP/HTTPS-Protokolle zugängliche Antwort bereitstellt und an ein Netzwerk angeschlossen ist. Das Verfahren kann einen Proxy-Server verwenden, der in eine Dienstanbieter-Infrastruktur integriert ist oder von einer Dienstanbieter-Infrastruktur getrennt ist.
Die Ausführungsformen offenbaren das System zur Extraktion und zum Sammeln von Daten aus einem Netzwerk, das mindestens umfasst einen Proxy-Rotator, der betreibbar ist, um eine Vielzahl von Proxys über das Netzwerk bereitzustellen und einen Anfrageoptimierer, der betreibbar ist, um Parameter einer von einem Benutzergerät empfangenen Anfrage mit einer Liste von Scraping-Strategien zu vergleichen, zum Auswählen einer Scraping-Strategie, die mit den Parametern der Anfrage korrespondiert, aus der Liste von Scraping-Strategien, zum Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie, zum Anpassen der Parameter der Anfrage gemäß der Scraping-Strategie zum Bilden einer angepassten Anfrage, und zum Senden der angepassten Anfrage über einen Proxy, der durch den Proxy-Rotator gemäß der Scraping-Strategie aus einer Proxy-Datenbank ausgewählt wird, an ein Ziel.
Die Offenbarungen stellen auch ein nicht-flüchtiges computerlesbares Medium zum Extrahieren von Sammeln von einem Web-Server vor, das Anweisungen umfasst, die, wenn sie von einer Rechenvorrichtung innerhalb einer Dienstanbieter-Infrastruktur ausgeführt werden, die Rechenvorrichtung veranlassen zum: Vergleichen von Parametern einer von einem Gerät des Benutzers empfangenen Anfrage mit einer Liste von Scraping-Strategien; Auswählen einer Scraping-Strategie, die den Parametern der Anfrage entspricht, aus der Liste von Scraping-Strategien; Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie; Anpassen der Parameter der Anfrage gemäß der Scraping-Strategie zum Bilden einer angepassten Anfrage; Senden der angepassten Anfrage an ein Ziel über einen Proxy, der gemäß der Scraping-Strategie ausgewählt wurde; Empfangen einer Antwort von dem Ziel. Später, Prüfen und Analysieren der Metadaten der vom Ziel empfangenen Antwort und Weiterleiten der Antwort an das Gerät des Benutzers gemäß der Analyse der Metadaten. Wenn die vom Ziel empfangene Antwort negativ ist, wird der Betrieb des Mediums wiederholt, indem die Parameter der Anfrage gemäß einer anderen Scraping-Strategie aus der Liste der Scraping-Strategien angepasst werden zum Bilden einer anderen angepassten Anfrage, die dann an das Ziel gesendet wird. Der Betrieb des Mediums wird mit alternativen Scraping-Strategien aus der Liste der Scraping-Strategien wiederholt, bis eine positive Antwort erhalten wird oder bis eine maximale Anzahl von Versuchen erreicht ist. Der Proxy kann für Anfragen von mehreren Benutzergeräten verfügbar bleiben. Mindestens einer der folgenden Parameter der Anfrage wird angepasst: URL-Adresse; Header; Cookies; Anfragehauptteil. Die Parameter der Anfrage werden nicht angepasst, wenn die vom Gerät des Benutzers empfangene Anfrage mit einer der Scraping-Strategien aus der Liste korrespondiert.
Darüber hinaus können in diesem Dokument Bezugsbegriffe wie „erster“ und „zweiter“ und dergleichen verwendet werden, um lediglich eine Einheit oder Aktion von einer anderen Einheit oder Aktion zu unterscheiden, ohne notwendigerweise eine tatsächliche derartige Beziehung oder Reihenfolge zwischen diesen Einheiten oder Aktionen zu erfordern oder zu implizieren. Die Begriffe „umfasst“, „hat“, „beinhaltet“, „enthält“ oder jede andere Abwandlung davon sollen eine nicht-exklusive Einbeziehung abdecken, so dass ein Prozess, ein Verfahren, ein Artikel oder eine Vorrichtung, der/die eine Liste von Elementen umfasst, hat, beinhaltet, enthält, nicht nur diese Elemente einschließt, sondern auch andere Elemente einschließen kann, die nicht ausdrücklich aufgeführt sind oder zu einem solchen Prozess, Verfahren, Artikel oder einer solchen Vorrichtung gehören. Ein Element, dem „umfasst ... ein“, „hat ... ein“, „beinhaltet ... ein“, „enthält ... ein“ vorangestellt ist, schließt ohne zusätzliche Einschränkungen die Existenz weiterer identischer Elemente in dem Prozess, Verfahren, Artikel und/oder Gerät, das das Element umfasst, hat, umfasst und/oder enthält, nicht aus. Der Begriff „ein“ ist als ein oder mehrere definiert, sofern hier nicht ausdrücklich anders angegeben. Die Begriffe „annähernd“, „ungefähr“ oder eine andere Version davon sind definiert als „nahegelegen“, wie es von einem Fachmann verstanden wird. Ein Gerät oder eine Struktur, die auf eine bestimmte Art und Weise „konfiguriert“ ist, ist mindestens auf diese Art und Weise konfiguriert, kann aber auch auf eine Weise konfiguriert sein, die nicht aufgeführt ist. Für die Angabe von Elementen kann eine Singular- oder Pluralform verwendet werden, was jedoch den Umfang der Offenbarung nicht einschränkt, und dieselbe Lehre kann für mehrere Objekte gelten, auch wenn in der vorliegenden Anwendung auf ein Objekt in seiner Singularform Bezug genommen wird.
Es wird gewürdigt, dass einige Ausführungsformen die Verwendung einer oder mehrerer generischer oder spezialisierter Datenbanken (wie z. B. „Proxy-Datenbank“ oder ähnlich) beschreiben, die eine Sammlung von Informationen enthält, die so organisiert ist, dass sie leicht zugänglich, verwaltet und aktualisiert werden kann. Computerdatenbanken enthalten typischerweise Aggregationen von Datensätzen oder Dateien, im vorliegenden Fall speichern Datenbanken üblicherweise verschiedene Informationen und Statistiken über die Proxys oder Ausgangsknoten, Informationen über die Auslastungsschwelle des Ausgangsknoten-Anbieters. Solche Datenbanken können auch Informationen über die Clients, die durchgeführten Anfragen, die verwendeten Netzwerke, die verwendeten Proxys, die Arten der angeforderten Proxys und ähnliche Daten enthalten. Datenbanken sind so strukturiert, dass sie das Speichern, Abrufen, Ändern und Löschen von Daten in Verbindung mit verschiedenen Datenverarbeitungsvorgängen ermöglichen.
Die hierin detailliert beschriebenen Ausführungsformen werden bereitgestellt, damit der Leser die Art der technischen Offenbarung schnell erfassen kann. Sie wird mit der Maßgabe vorgelegt, dass sie nicht zur Auslegung oder Einschränkung des Umfangs oder der Bedeutung der Ansprüche verwendet wird. Darüber hinaus wird in der vorstehenden detaillierten Beschreibung gezeigt, dass mehrere Merkmale in verschiedenen Ausführungsformen zum Zweck der Straffung der Offenbarung zusammengefasst sind. Diese Art der Offenlegung ist nicht so zu interpretieren, dass die beanspruchten Ausführungsformen mehr Merkmale erfordern, als in den einzelnen Ansprüchen ausdrücklich aufgeführt sind. Vielmehr liegt der Erfindungsgegenstand, wie die folgenden Ansprüche zeigen, in weniger als allen Merkmalen einer einzelnen offenbarten Ausführungsform. Daher werden die folgenden Ansprüche hiermit in die ausführliche Beschreibung aufgenommen, wobei jeder Anspruch für sich allein als separat beanspruchter Gegenstand steht.

Claims

System zum Extrahieren und Sammeln von Daten von einem Webserver, umfassend einen Anfrageoptimierer (104), der konfiguriert ist zum Vergleichen von Parametern einer von einem Benutzergerät (102) empfangenen Anfrage mit einer Liste von Scraping-Strategien; Auswählen einer Scraping-Strategie aus der Liste von Scraping-Strategien, die zu den Parametern der Anfrage korrespondiert Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie; Anpassen der Parameter der Anfrage entsprechend der Scraping-Strategie zum Bilden einer angepasste Anfrage; Senden der angepassten Anfrage an ein Ziel (116, 118) durch einen Proxy (108, 110), der entsprechend der Scraping-Strategie ausgewählt wurde; Empfangen einer Antwort von dem Ziel (116, 118).
System nach Anspruch 1, wobei der Anfrageoptimierer (104) ferner konfiguriert ist zum Prüfen und Analysieren der Metadaten der von dem Ziel (116, 118) empfangenen Antwort.
System nach Anspruch 2, wobei der Anfrageoptimierer (104) ferner konfiguriert zum Weiterleiten der Antwort an das Benutzergerät (102) gemäß der Analyse der Metadaten.
System nach Anspruch 1, wobei, wenn die von dem Ziel (116, 118) empfangene Antwort negativ ist, der Anfrageoptimierer (104) konfiguriert ist zum Wiederholen der Anpassung der Parameter der Anfrage gemäß einer anderen Scraping-Strategie aus der Liste der Scraping-Strategien zum Bilden einer anderen angepassten Anfrage, die dann an das Ziel (116, 118) gesendet wird.
System nach Anspruch 4, wobei der Anfrageoptimierer (104) konfiguriert ist zum Wiederholen des Anpassens der Parameter mit alternativen Scraping-Strategien, die aus der Liste der Scraping-Strategien ausgewählt sind, bis eine positive Antwort erhalten wird oder bis eine maximale Anzahl von Versuchen erreicht ist.
System nach Anspruch 1, wobei der Anfrageoptimierer (104) konfiguriert ist zum Anpassen mindestens einer der Parameter innerhalb der folgenden Komponenten der Anfrage: a. URL-Adresse; b. Kopfzeilen; c. Cookies; d. Anfragehauptteil.
System nach Anspruch 1, wobei eine Dienstanbieter-Infrastruktur (114) konfiguriert ist zum Auswählen des Proxys (108, 110) aus einer Proxy-Datenbank (112).
System nach Anspruch 7, wobei die Dienstanbieter-Infrastruktur (114) konfiguriert ist zum Auswählen des Proxys gemäß der Scraping-Strategie auswählt und Geolokalisierungseinstellungen, Proxy-Typ, Proxy-Verfügbarkeit oder eine beliebige Kombination davon umfasst.
System nach Anspruch 1, wobei der Proxy (108, 110) so konfiguriert ist, dass er für mehrere Anfragen von Benutzergeräten verfügbar bleibt.
System nach Anspruch 1, wobei der Anfrageoptimierer (104) so konfiguriert ist, dass er die Parameter der Anfrage nicht anpasst, wenn die von dem Benutzergerät (102) empfangene Anfrage mit einer der Scraping-Strategien aus der Liste korrespondiert.
System nach Anspruch 1, wobei der Anfrageoptimierer (104) Betriebseinstellungen umfasst, die mindestens eines der folgenden umfassen: Scraping-Strategien, Sitzungs-ID-Nummern, als Anfragesteller akzeptierte Server, Zeitfenster für den Betrieb, geplante Wartungsaufgaben, Zeitüberschreitungen von Verbindungssitzungen, Anfrageverarbeitungsprotokolle oder eine beliebige Kombination davon, und solche Einstellungen in einer Datenbank auf einer Festplatte, in einer Flat-File auf einer Festplatte, in einer Datenbank in einem Speicher oder in anderen Speichermedien gespeichert sind.
System nach Anspruch 1, wobei das Ziel (116, 118) ein Webserver ist, der die Antwort liefert, auf die über HTTP/HTTPS-Protokolle zugegriffen werden kann, und an ein Netzwerk (120) angeschlossen ist.
System nach Anspruch 1, wobei der Proxy (108, 110) ein Proxy-Server ist, der in eine Dienstanbieter-Infrastruktur (114) integriert ist.
System nach Anspruch 1, wobei der Proxy (108, 110) ein von einer Dienstanbieter-Infrastruktur (114) getrennter Proxy-Server ist.
System nach Anspruch 1, wobei die Dienstanbieter-Infrastruktur (114) so konfiguriert ist, dass sie das Anpassen der Parameter der Anfrage autonom von dem Benutzergerät (102) durchführt.
System zum Extrahieren und Sammeln von Daten aus einem Netzwerk, mindestens umfassend: einen Proxy-Rotator (106), der so konfiguriert ist, dass er eine Vielzahl von Proxys (108, 110) über das Netzwerk bereitstellt; und einen Anfrageoptimierer (104), der konfiguriert ist zum Vergleichen der Parameter einer von einem Benutzergerät (102) empfangenen Anfrage mit einer Liste von Scraping-Strategien, zum Auswählen einer Scraping-Strategie, die mit den Parametern der Anfrage korrespondiert, aus der Liste von Scraping-Strategien, zum Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie, zum Anpassen der Parameter der Anfrage gemäß der Scraping-Strategie zum Bilden einer angepassten Anfrage, und zum Senden der angepassten Anfrage über einen Proxy, der durch den Proxy-Rotator (106) gemäß der Scraping-Strategie aus einer Proxy-Datenbank (112) ausgewählt wird, an ein Ziel.
System nach Anspruch 16, wobei der Anfrageoptimierer (104) konfiguriert ist zum Anpassen der von dem Benutzergerät (102) empfangenen Anfrage anpasst, indem er mindestens einen der Parameter innerhalb der folgenden Komponenten modifiziert: a. URL-Adresse; b. Kopfzeilen; c. Cookies; d. Anfragehauptteil.
System nach Anspruch 16, wobei der Anfrageoptimierer (104) so konfiguriert ist, dass er denselben Proxy (108, 110) für eine unbegrenzte Anzahl von Anfragen verwendet, die von demselben Benutzergerät (102) empfangen werden.
Nicht-flüchtiges computerlesbares Medium zum Extrahieren und Sammeln von Daten von einem Web-Server umfassend Anweisungen, die, wenn sie von einer Rechenvorrichtung innerhalb einer Dienstanbieter-Infrastruktur ausgeführt werden, die Rechenvorrichtung dazu veranlassen, die folgenden Schritte durchzuführen: Vergleichen von Parametern einer von einem Benutzergerät (102) empfangenen Anfrage mit einer Liste von Scraping-Strategien; Auswählen einer Scraping-Strategie, die mit den Parametern der Anfrage korrespondiert, aus der Liste von Scraping-Strategien; Identifizieren von Diskrepanzen zwischen der Anfrage und der Scraping-Strategie; Anpassen der Parameter der Anfrage entsprechend der Scraping-Strategie zum Bilden einer angepassten Anfrage; Senden der angepassten Anfrage an ein Ziel (116, 118) durch einen Proxy (108, 110), der entsprechend der Scraping-Strategie ausgewählt wurde; Empfangen einer Antwort von dem Ziel (116, 118).
Nicht-flüchtiges computerlesbares Medium nach Anspruch 19, ferner umfassend einen Schritt zum: Prüfen und Analysieren der Metadaten der von dem Ziel (116, 118) empfangenen Antwort.
Nicht-flüchtiges computerlesbares Medium nach Anspruch 20, das weiterhin einen Schritt umfasst zum: Weiterleiten der Antwort an das Benutzergerät (102) gemäß der Analyse der Metadaten.
Nicht-flüchtiges computerlesbares Medium nach Anspruch 19, wobei, wenn die von dem Ziel (116, 118) empfangene Antwort negativ ist, der Betrieb des Mediums wiederholt wird, indem die Parameter der Anfrage gemäß einer anderen Scraping-Strategie aus der Liste der Scraping-Strategien angepasst werden zum Bilden einer anderen angepassten Anfrage, die dann an das Ziel (116, 118) gesendet wird.
Nicht-flüchtiges computerlesbares Medium nach Anspruch 22, wobei die Operation des Mediums mit alternativen Scraping-Strategien, die aus der Liste der Scraping-Strategien ausgewählt werden, wiederholt wird, bis eine positive Antwort erhalten wird oder bis eine maximale Anzahl von Versuchen erreicht ist.
Nicht-flüchtiges computerlesbares Medium nach Anspruch 19, wobei der Proxy (108, 11) für mehrere Anfragen von Benutzergeräten verfügbar bleibt.
Nicht-flüchtiges computerlesbares Medium nach Anspruch 19, wobei mindestens einer der folgenden Parameter der Anfrage angepasst wird: a. URL-Adresse; b. Header; c. Cookies d. Anfragehauptteil.
Nicht-flüchtiges computerlesbares Medium nach Anspruch 19, wobei die Parameter der Anfrage nicht angepasst werden, wenn die von dem Benutzergerät (102) empfangene Anfrage mit einer der Scraping-Strategien aus der Liste korrespondiert.