Was kann Javascript? Oder was nimmt man sonst?

[zukzuk]

Hallo zusammen.

Kurz zu meiner Person: Ich habe vor kurzem eine Umschulung zum Fachinformatiker Anwendungsentwicklung abgeschlossen, habe aber schon früher einen Nebenjob in der Richtung gehabt. Jetzt fange ich in Kürze bei meinem neuen AG an zu arbeiten.

Im Vorfeld habe ich schon eine E-Mail mit einem "Wunsch" bekommen, den ich zwar noch nicht umsetzen soll, aber ich (w|s)ollte mir darüber doch mal ein paar Gedanken machen.

Und zwar soll eine Browseranwendung entstehen, die

a: einen Ping zu einer bestimmten IP-Adresse durchführt (ich vermute, der soll per ICMP gemacht werden, genau ist die Anforderung aber nicht spezifiziert) und das Ergebnis darstellt

b: die maximale MTU auf diesem Pfad bestimmt und darstellt

c: eine TCP- oder UDP-Verbindung zu einer bestimmten IP durchführt und den Erfolg des Verbindungsaufbaus darstellt

 

Gut, die serverseitige Programmierung dafür umzusetzen stelle ich mir noch einigermaßen machbar vor. Aber die Clientseite (Browseranwendung) macht mir einiges Kopfzerbrechen.

 

Zum Thema Javascript:

zu a: Einen ICMP-Ping kann Javascript soweit ich verstehe nicht. Als Workaround könnte man vmtl. einen HTTP-Request auf eine 0 Byte große Datei durchführen und dessen Zeit messen. Aber das entspricht dann natürlich nicht demselben Ergebnis, wie wenn der Benutzer einen Ping in der Eingabeaufforderung durchführt, insbesondere da das ja dann ein TCP-Request wäre (ICMP könnte ja auf Firewall-Ebene blockiert sein) und außerdem noch weitere Verzögerungen hinzukommen könnten ...

Da das "Projekt" soweit ich verstehe zur Diagnose von Netzwerkfehlkonfigurationen dienen soll, wäre das vmtl. schon relevant. Insbesondere kommt denke ich ein Ping vom Server zum aufrufenden Client nicht in Frage, da der ja dann in der "falschen" Richtung passieren würde (unterschiedliche Firewall-Konfigurationen für in/outgoing usw.).

zu b: da habe ich gar keine Idee, wie das mit JavaScript gehen soll, m. W. kann es soetwas "Netzwerknahes" wie "Bruteforcen" der maximalen MTU schlicht nicht (würde die Bestimmung der MTU von der Gegenseite, sprich, vom Server aus, evtl. zum selben Ergebnis führen? Ganz so fit bin ich in Netzwerkdingen dann auch nicht).

zu c: für den Test der TCP-Verbindung könnte man wieder den Workaround aus a) (HTTP-Request) bemühen, aber UDP? Mit Javascript? Wohl eher nicht.

 

Für die Parts die Javascript nicht kann: wie könnte man das denn überhaupt als Browseranwendung umsetzen? Mit einem Java-Applet (damit habe ich null Erfahrung)? Ist das überhaupt noch massentauglich? (auf wie vielen PCs ist denn das Java-Browser-Plugin noch installiert?)

Hoffe, ihr könnt mir etwas "Erleuchtung" bringen, ob meine Überlegungen in die richtige Richtung gehen bzw. wie ihr die Sache angehen würdet. Mein erster Impuls wäre halt, meine Bedenken vorzubringen, dass da hinterher was "Brauchbares" bei rauskommt. Aber damit sollte ich dann halt nach Möglichkeit schon "richtig" liegen ;-). Und das will ich mit diesem Post "absichern" ;-).

Vielen Dank im Voraus für eure Hilfe.

zukzuk

 

Bearbeitet 23. August 2016 von zukzuk

[Whiz-zarD]

Ich hab zwar auch nicht so viel mit Javascript zu tun aber ich würde es als Client-server-applikation entwickeln. Der Client schickt per Ajax-technik ein HTTP-Request an den Server und der Server führt dann den Request (z.B. der ICMP-Echo-Request) aus und das Ergebnis schickt er zum Client zurück, welches der Client dann anzeigt. 

[Fauch]

Gerade eben schrieb Whiz-zarD:

Ich hab zwar auch nicht so viel mit Javascript zu tun aber ich würde es als Client-server-applikation entwickeln. Der Client schickt per Ajax-technik ein HTTP-Request an den Server und der Server führt dann den Request (z.B. der ICMP-Echo-Request) aus und das Ergebnis schickt er zum Client zurück, welches der Client dann anzeigt. 

Würde ich auch sagen. Und wenn das ganze unbedingt 100% Javascript sein soll, könnte man Node.Js auf dem Server nutzen.

[zukzuk]

vor 3 Stunden schrieb Whiz-zarD:

Ich hab zwar auch nicht so viel mit Javascript zu tun aber ich würde es als Client-server-applikation entwickeln. Der Client schickt per Ajax-technik ein HTTP-Request an den Server und der Server führt dann den Request (z.B. der ICMP-Echo-Request) aus und das Ergebnis schickt er zum Client zurück, welches der Client dann anzeigt. 

Erstmal danke für die Antworten.

Naja, da kommt aber dann wie gesagt doch ein anderes Ergebnis raus, als wenn ich die Verbindungen vom Client aus aufbaue. Wie ich schrub, soll das ganze ja zur Analyse von Netzwerkproblemen auf Clientseite dienen, und es ist ja wohl ein Unterschied, ob Verbindungen ein- oder ausgehend fehlschlagen. Außerdem müsste dann auf dem Client bspw. ein Port geöffnet sein, zu dem man eine TCP/UDP Verbindung aufbauen kann, und das wird nicht der Fall sein. Die Clientkonfiguration ist nicht bekannt.

Bei der MTU bin ich mir wie gesagt nicht sicher, ob da das selbe Ergebnis rauskommt, ob man sie von Client- oder Serverseite aus misst (aber ich vermute, auch dort gibt es einen Unterschied).

Bearbeitet 24. August 2016 von zukzuk

[zukzuk]

vor 2 Stunden schrieb Fauch:

Würde ich auch sagen. Und wenn das ganze unbedingt 100% Javascript sein soll, könnte man Node.Js auf dem Server nutzen.

Danke, das kannte ich noch nicht (bzw. schon mal was von gehört, aber nie näher angeschaut). 100% Javascript ist übrigens keine Bedingung.

Sieht auf dem ersten Blick interessant aus, aber ich fürchte das wird auch nichts. Allenfalls könnte man es dafür verwenden, die Verbindungen in die andere Richtung aufzubauen (Vom Server zum Client), wenn man es auf dem Client installiert und den somit zum Server macht, was aber m. E. der falsche Weg ist, um das gewünschte Ergebnis (Netzwerkanalyse in die andere Richtung) zu erhalten. Außerdem wird der Client regelmäßig hinter einer Firewall sein. Aber da das nicht einfach im Browser läuft, scheidet es ohnehin schon von vorneweg aus.

[zukzuk]

Vielleicht nochmal zur Klarstellung die Eckpunkte auf die es denke ich ankommt:

- der Client ist eine Blackbox, deren Konfiguration nicht geändert werden soll. Lediglich ein herkömmlicher Internetbrowser kann vorausgesetzt werden

- die Verbindungen müssen vom Client zum Server aus aufgebaut werden, nicht anders herum. Es sollen Netzwerkprobleme analysiert werden, die vom Client zum Server hin auftreten

Ich vermute, dass man da mit einer Browseranwendung nicht weiterkommt (außer mit den im 1. Post erwähnten Einschränkungen), sondern schon zu härteren Geschützen greifen muss, sprich, ein Binary zu produzieren, das auf dem Client dann halt ausgeführt werden muss. Aber vielleicht gibt's da ja auch was Fertiges ... Bin mir aber wie gesagt noch nicht zu 100% sicher, ob ich damit richtig liege. Evtl. geht's ja mit Flash? (0 Erfahrung) Aber Flash ist ja sowieso "out".

Bearbeitet 24. August 2016 von zukzuk

[Whiz-zarD]

Wozu soll dann der Server dienen, wenn die Logik im Client liegt?
Der Vorteil bei einer Client-Server-Applikation ist der, dass der Client dumm ist und nichts weiter macht, als die Eingabe vom Benutzer entgegen zu nehmen und die Resultate vom Server anzuzeigen. Der Client besitzt keinerlei Businesslogik. Außerdem müssste JavaScript dann auf native Anwendungen zurückgreifen (z.B. ping.exe) und wäre dann somit vom Betriebssystem abhängig und wäre somit nicht mehr Plattformunabhängig. 

[zukzuk]

vor 12 Minuten schrieb Whiz-zarD:

Wozu soll dann der Server dienen, wenn die Logik im Client liegt?
Der Vorteil bei einer Client-Server-Applikation ist der, dass der Client dumm ist und nichts weiter macht, als die Eingabe vom Benutzer entgegen zu nehmen und die Resultate vom Server anzuzeigen. Der Client besitzt keinerlei Businesslogik. Außerdem müssste JavaScript dann auf native Anwendungen zurückgreifen (z.B. ping.exe) und wäre dann somit vom Betriebssystem abhängig und wäre somit nicht mehr Plattformunabhängig. 

Na, der Server ist eben die Gegenstelle für die Requests des Clients. Etwa lauscht er auf einem bestimmten Port auf TCP- oder UDP-Anfragen und gibt ein "Ok" zurück, wenn eine Verbindung aufgebaut wurde. Bzw. bei den ICMP-Requests antwortet er halt (gut, dafür muss man natürlich keinen Code selbst produzieren, nichtsdestotrotz ist es doch eine Server-Anwendung).

Mit Javascript auf native Anwendungen zuzugreifen geht übrigens IIRC auch nicht (aus Sicherheitsgründen).

Oder verstehst du die Anforderung anders? Es geht um Kunden (also die Clientseite), die Probleme haben, bestimmte Verbindungen zum ISP herzustellen. Und dann muss eben in Richtung Client -> Server analysiert werden, was das Problem sein könnte, nicht andersherum.

Bearbeitet 24. August 2016 von zukzuk

[JimTheLion]

• Der Browser sendet einen Request an (d)einen Webserver und übergibt ihm die zu prüfende IP
• Auf dem Websever läuft dein Programm das die IP anpingt
• Der Websever werter das Ergebis des Pings aus
• Der Websever gibt die Auswertung an den Browser zurück

Das ist der Weg, der dir von den anderen Usern hier empfohlen wurde* und den ich wohl auch mal prüfen würde. (Ob du das per JavaScript löst ist eine Detailfrage, kann genauso gut über ein gewöhnliches Formular passieren. Ajax ist aber natürlich hübscher)

Ich denke du kommst hier ein wenig mit "Client" und "Server" durcheinander, der Webserver wäre in diesem Szenario der Client für den zu prüfenden Server. Da dreht sich nichts um, dass du damit von der falschen Seite etwas prüfen würdest.

 

* habe ich zumindest so verstanden

Bearbeitet 24. August 2016 von PVoss

[zukzuk]

vor 19 Minuten schrieb PVoss:

• Der Browser einen Request an einen Webserver und übergibt ihm die zu prüfende IP
• Auf dem Websever läuft dein Programm das die IP anpingt
• Der Server werter das Ergebis des Pings aus
• Der Server gibt die Auswertung an den Browser zurück

Das ist der Weg, der dir von den anderen Usern hier empfohlen wurde und den ich wohl auch mal prüfen würde. (Ob du das per JavaScript löst ist eine Detailfrage, kann genauso gut über ein gewöhnliches Formular passieren. Ajax ist aber natürlich hübscher)

Ich denke du kommst hier ein wenig mit "Client" und "Server" durcheinander, der Webserver wäre in diesem Szenario der Client für den zu prüfenden Server. Da dreht sich nichts um, dass du damit von der falschen Seite etwas prüfen würdest.

Also wenn ich von Client spreche, spreche ich grundsätzlich von der Seite, auf der die angedachte Browseranwendung ausgeführt wird. Das ist also der Rechner, auf dem das Javascript ausgeführt wird (zwar wird das natürlich auch erstmal vom Server geladen, aber eben dann lokal im Browser ausgeführt).

Bei Server spreche ich grundsätzlich von der Gegenstelle für die Requests, die vom Client-Browser durchführt werden.

TLDR:

Client = Browser

Server = Gegenstelle des Clients

 

Den von dir nochmal beschriebenen Weg habe ich ja schon geprüft, das Problem ist eben, dass in die falsche Richtung analysiert wird (nämlich vom Server zum Client anstatt andersherum). Den Grund warum es in die andere Richtung gehen muss, hatte ich ja einige Posts über dir nochmal beschrieben:

- die Verbindungen müssen vom Client zum Server aus aufgebaut werden, nicht anders herum. Es sollen Netzwerkprobleme analysiert werden, die vom Client zum Server hin auftreten

Oder reden wir aneinander vorbei?

 

Edit: Ich versuch's nochmal anders auszudrücken:

Rechner A = Client

Rechner B = Server

Jetzt ist bspw. interessant, ob Rechner A eine Verbindung zu einem bestimmten Port von Rechner B herstellen kann. Die Gegenrichtung interessiert dabei nicht. Auch wenn man die Begrifflichkeiten Server/Client austauscht, ändert sich daran nichts.

Auf Rechner B kann beliebige Software ausgeführt werden, auf Rechner A soll lediglich eine Browseranwendung (Javascript) laufen. (was, so vermute ich, nicht geht, wenn alle Anforderungen erfüllt werden sollen)

Bearbeitet 24. August 2016 von zukzuk

[arlegermi]

Das was du da vorhast, ist mit JavaScript (im Browser*) nicht möglich.

Ich würde dir raten, da im Augenblick nicht zuviel drüber nachzudenken. Wenn's dann soweit ist, kannst du mit deinem Chef ja mal genauer drüber reden, was die wirklich wollen. Ich vermute, dass da einfach ein Missverständnis vorliegt.

 

* du kannst lokal (mit bspw. Node.js) natürlich deutlich mehr machen. Das ist dann aber nicht im Browser und muss installiert, bzw. auf den Client kopiert werden

Bearbeitet 24. August 2016 von arlegermi

[zukzuk]

vor 27 Minuten schrieb arlegermi:

Das was du da vorhast, ist mit JavaScript (im Browser*) nicht möglich.

Ich würde dir raten, da im Augenblick nicht zuviel drüber nachzudenken. Wenn's dann soweit ist, kannst du mit deinem Chef ja mal genauer drüber reden, was die wirklich wollen. Ich vermute, dass da einfach ein Missverständnis vorliegt.

 

* du kannst lokal (mit bspw. Node.js) natürlich deutlich mehr machen. Das ist dann aber nicht im Browser und muss installiert, bzw. auf den Client kopiert werden

Ok, dass das in dieser Form nicht mit einer Webanwendung im Browser möglich ist, war auch meine Einschätzung. Danke dafür.

[SilentDemise]

wenn ihr doch nur langweilig clients überwachen wollt, warum dann nicht gleich ne echte monitoring anwendung wie SCOM, icinga, spiceworks etc. etc.einsetzen. Die sind fertig, rel. einfach aufzusetzen und die kosten deutlich geringer als hier selber was zu bauen....

[zukzuk]

vor 2 Stunden schrieb SilentDemise:

wenn ihr doch nur langweilig clients überwachen wollt, warum dann nicht gleich ne echte monitoring anwendung wie SCOM, icinga, spiceworks etc. etc.einsetzen. Die sind fertig, rel. einfach aufzusetzen und die kosten deutlich geringer als hier selber was zu bauen....

Also "überwachen" ist das falsche Wort.

Kunde x hat irgendwelche Netzwerkprobleme, jetzt soll er unter Anleitung des Supports auf die Seite gehen, damit man idealerweise sehen kann, auf welcher Ebene das Problem liegt.

Wenn aber jemand eine Idee hat, welche Third Party Software die o. g. Anforderungen erfüllt und evtl. noch irgendwie schön darstellen kann, wäre das natürlich auch eine Option, die ich dem AG gerne nahebringen werde :-).

Achso, ping unter Anleitung ist keine Lösung bzw. von dieser Lösung will man wohl gerade wegkommen ;-). Sollte also schon etwas komfortabler sein. Wie die TCP/UDP Verbindungen derzeit getestet werden, weiß ich nicht. Evtl. mit telnet oder netcat ... Auf jeden Fall vmtl. mit irgendwelchen Kommandozeilentools. Und es sollte halt schon ein Tool sein, das "alles" was in den Anforderungen im 1. Post steht abdecken kann.

Bearbeitet 25. August 2016 von zukzuk

[Whiz-zarD]

vor einer Stunde schrieb zukzuk:

Kunde x hat irgendwelche Netzwerkprobleme, jetzt soll er unter Anleitung des Supports auf die Seite gehen, damit man idealerweise sehen kann, auf welcher Ebene das Problem liegt.

Das funktioniert aber nur so lange, wenn die Netzwerkverbindung tatsächlich steht aber diese nur langsam ist. Hat Kunde x gar keine Netzwerkverbindung, so kann er auch die Webseite nicht aufrufen.

Ich bin zwar kein Netzwerkadministrator aber es gibt doch tonnenweise Tools für die Netzwerkanalyse.

Bearbeitet 25. August 2016 von Whiz-zarD

[zukzuk]

vor 27 Minuten schrieb Whiz-zarD:

Das funktioniert aber nur so lange, wenn die Netzwerkverbindung tatsächlich steht aber diese nur langsam ist. Hat Kunde x gar keine Netzwerkverbindung, so kann er auch die Webseite nicht aufrufen.

Ich bin zwar kein Netzwerkadministrator aber es gibt doch tonnenweise Tools für die Netzwerkanalyse.

Das ist natürlich richtig. Wenn der Seitenaufruf nicht klappt, weiß man aber auch gleich, dass das Netz "ganz" weg ist (fragt sich dann nur welches ^^) ;-). Zudem muss ich noch etwas relativieren, es geht wohl auch darum, die Voraussetzungen für ein bestimmtes Vorhaben abzuklären (welches, ist mir nicht ganz klar), für das eben 2 Bedingungen gegeben sein müssen müssen:

a: Ping zu bestimmter Adresse muss klappen

b: TCP- bzw. UDP-Verbindung zu bestimmter Adresse/Port müssen klappen

Außerdem soll die maximale MTU zu einer bestimmten IP ermittelt werden (nicht die im Betriebssystem eingestellte, sondern die tatsächlich mögliche, also Ermittlung per ICMP)

Die Vorgehensweise als solche will ich auch gar nicht hinterfragen, da mir der zugrundeliegene Geschäftsprozess auch gar nicht bekannt ist.

Gewünscht ist soweit ich verstehe eben eine Lösung nicht mit mehreren Tools, sondern mit einem einzigen.

Vielleicht hat ja auch jemand einen Tipp für ein Netzwerkanalysetool, das das einigermaßen hübsch kann. Idealerweise sollte dieses natürlich auch für mehrere Plattformen existieren. Meine Erfahrung mit derartigen Tools beschränkt sich auf die allg. verfügbaren Kommandozeilentools unter Linux.

Sonst dürfte des Rätsels Lösung vmtl. die Erstellung einer eigenen Java-Applikation o. ä. sein, die das macht. Ist dann halt keine Browser-App mehr (Java-Plugin benutzt man ja nicht mehr).

Naja, vielleicht sollte ich bevor der Thread hier noch ausartet auch einfach erst mal abwarten, bis ich mit den Leuten vor Ort gequatscht habe ;-).

Bearbeitet 25. August 2016 von zukzuk

[pr0gg3r]

Es wurde bereits ja erwähnt, dass ein Ping nicht im Browser funktioniert. Was aber funktionieren würde, wäre eine externe Ressource zu laden, zum Beispiel ein JavaScript, eine Bilddatei, etc. Dadurch weißt du schon einmal, dass die Verbindung mit der Gegenstelle besteht, das Gerät also nicht offline ist. Was dann aber wiederum nicht geht, wäre Informationen aus den Paketen herauszulesen. Auch die Zeit zwischen Anfrage und fertig-geladen würde z.B. nicht einem Ping entsprechen, da es im Browser ja alle Ebenen hoch geht, statt wie bei MCIP (u.a. Ping) auf Layer 3, was natürlich Verzögerungen verursacht. Was man dann eventuell (ich möchte mich da nicht zu weit aus dem Fenster lehnen) machen könnte, wäre mit Firebug, den Chrome-Entwicklertools o.ä. zusätzliche Paketinformationen herauszulesen... Das ist natürlich etwas aufwändig und einem Laien, der ggf. vom Support betreut wird, nicht zumutbar, aber vielleicht lässt sich etwas brauchbares zusammenwursteln, zB könnte man das Packet ja auch in der Gegenstelle, die angepingt wird auswerten bzw. Anpingen und diese Infos in das eingebundene Skript verpacken... bringt aber auch nichts, wenn die Infos nur benötigt werden, wenn das Dingends offline ist...

[zukzuk]

vor 22 Minuten schrieb pr0gg3r:

Es wurde bereits ja erwähnt, dass ein Ping nicht im Browser funktioniert. Was aber funktionieren würde, wäre eine externe Ressource zu laden, zum Beispiel ein JavaScript, eine Bilddatei, etc. Dadurch weißt du schon einmal, dass die Verbindung mit der Gegenstelle besteht, das Gerät also nicht offline ist. Was dann aber wiederum nicht geht, wäre Informationen aus den Paketen herauszulesen. Auch die Zeit zwischen Anfrage und fertig-geladen würde z.B. nicht einem Ping entsprechen, da es im Browser ja alle Ebenen hoch geht, statt wie bei MCIP (u.a. Ping) auf Layer 3, was natürlich Verzögerungen verursacht. Was man dann eventuell (ich möchte mich da nicht zu weit aus dem Fenster lehnen) machen könnte, wäre mit Firebug, den Chrome-Entwicklertools o.ä. zusätzliche Paketinformationen herauszulesen... Das ist natürlich etwas aufwändig und einem Laien, der ggf. vom Support betreut wird, nicht zumutbar, aber vielleicht lässt sich etwas brauchbares zusammenwursteln, zB könnte man das Packet ja auch in der Gegenstelle, die angepingt wird auswerten bzw. Anpingen und diese Infos in das eingebundene Skript verpacken... bringt aber auch nichts, wenn die Infos nur benötigt werden, wenn das Dingends offline ist...

Jupp, diesen Workaround hatte ich als Möglichkeit im Eingangspost auch schon erwähnt, obwohl meine Idee eben ein HTTP-Request auf eine leere Datei war. Kann Javascript eigentlich einen HTTP-Request auf eine andere (Sub-)Domain als die, von der der JS-Code geladen wurde, durchführen? Wenn nein, müsste man die Test-Webseite auf derselben Domain bzw. IP-Adresse laufen lassen, die "getestet" werden soll, oder alternativ mit irgendwelchen Redirect-Konstrukten arbeiten, die das Ergebnis weiter verfälschen.

Aber Ich denke schon, dass die Anforderungen ICMP-Ping, TCP- und UDP-Request auf bestimmte IPs und Path MTU Discovery (ICMP) zu bestimmter IP fix vorgegeben sind und daran nichts zu rütteln ist.

Bearbeitet 25. August 2016 von zukzuk

[Crash2001]

vor 6 Stunden schrieb pr0gg3r:

Es wurde bereits ja erwähnt, dass ein Ping nicht im Browser funktioniert. Was aber funktionieren würde, wäre eine externe Ressource zu laden, zum Beispiel ein JavaScript, eine Bilddatei, etc. Dadurch weißt du schon einmal, dass die Verbindung mit der Gegenstelle besteht, das Gerät also nicht offline ist. [...]

Das weisst du alleine schon, wenn die Seite, die du vom Server aufrufst, angezeigt wird auf dem Client.

[Whiz-zarD]

vor 7 Stunden schrieb zukzuk:

Kann Javascript eigentlich einen HTTP-Request auf eine andere (Sub-)Domain als die, von der der JS-Code geladen wurde, durchführen?

Natürlich geht das. Das Zauberwort habe ich schon im ersten Beitrag genannt: Ajax
Was meinst du, wie z.B. Google Maps in eine Webseite eingebunden wird? Das ist auch nichts anderes als ein asynchroner HTTP-Request. 

vor 7 Stunden schrieb zukzuk:

Aber Ich denke schon, dass die Anforderungen ICMP-Ping, TCP- und UDP-Request auf bestimmte IPs und Path MTU Discovery (ICMP) zu bestimmter IP fix vorgegeben sind und daran nichts zu rütteln ist.

Es gibt kein ICMP-Ping!
Ping ist nur der Name eines Tools, was nur die Paketumlaufzeit mit Hilfe eines ICMP Echo-Rquests misst. Der Name des Tools ist völlig unerheblich. Du könntest auch ein eigenes Tool schreiben, was ein Echo-Request abfeuert und es "Hallo" nennen.

Außerdem: Ein Echo Request ist so ziemlich nichtssagend, denn genauso gut könnte auch die Gegenstelle der Flaschenhals sein. Also nicht der Nutzer hat eine schlechte Verbindung, sondern der Server. Mit einem Echo Request würde man das nicht rausbekommen. Da müsste man sich u.a. dann schon die Route (z.B. mit dem Tool tracert (Windows) bzw. traceroute (Linux)) anschauen, die für das Datenpaket gewählt wurde. Netzwerkprobleme können so vielseitig sein. Es könnte auch ein DNS-Problem vorliegen. Die ganzen Probleme lassen sich nicht mit einem Echo-Request und einer UDP/TCP-Verbinung lokalisieren und deshalb ist es schon quatsch das Rad neuzuerfinden. Da wäre ich schon auf gängige Tools setzen.

Ein Beispiel für ein Netzwerkproblem: Vor einem Jahr beklagten Kabel Deutschland/Vodafone Kunden, dass sie Probleme mit dem Spiel Diablo 3 hatten. Die Paketumlaufzeit zu den Diablo 3-Servern war extrem hoch (die werden schon im Spiel gemessen). Schuldig war die Route, die für diese Pakete gewählt wurde, da diese durch mehrere Netzwerke gingen, die sehr langsam waren. Kabel Deutschland/Vodafone hat deswegen extra für die Diablo 3-Server eine andere Route festgelegt.

Bearbeitet 26. August 2016 von Whiz-zarD

[Crash2001]

...vor allem werden ICMP-echo-Pakete in heutigen Netzwerken dank QoS eh anders behandelt, als andere Pakete und somit ist mit ihnen eigentlich nur erkennbar, ob es generelle Probleme auf der Strecke gibt, jedoch ist keine wirkliche Bewertung anhand dieser Daten möglich.

Beispiel:
Sprachdaten werden im Normalfall mit höchster Priorität versehen (mehr oder weniger real time Verarbeitung und sollen nicht gedroppt werden - oft als Prioklasse Gold o.ä. bezeichnet). Wichtige andere Pakete (z.B. Pakete zwischen Outlook und Exchange-Server) haben meist auch eine hohe Priorität. Es gibt jedoch genauso auch Dienste, die nicht priorisiert sind (bzw. die Standarpriorität haben), und noch niedrigere Prioritäten, deren Pakete bei Auslastung der Anbindung z.B. einfach gedroppt werden, wenn der Paket-Puffer vollgelaufen ist.
Welche Regeln für ICMP-Pakete konfiguriert sind, ist unterschiedlich - je nach Firma. Ich habe schon alles zwischen höchste Priorität und niedrigste Priorität konfiguriert gesehen.

Genauso verhält es sich aber auch mit traceroute-Paketen. Von daher sagen derartige Traces eigentlich auch nicht wirklich mehr aus. Man kann anhand dessen halt grob beurteilen, ob eine verbindung generell zu ausgelastet oder falsch geroutet ist, jedoch kann man ansonsten keinerlei Aussage über Paketlaufzeiten im Netzwerk tätigen für andere Anwendungen. Je nachdem gibt es ja sogar separates Routing für spezielle Anwendungen bzw. Ports und es gibt Load-Balancer dazwischen, so dass man nicht immer über das selbe Gerät ins Netzwerk kommt, sondern die Eintrittspunkte z.B. anhand eines Round-Robin-Verfahrens wechseln pro Session/Anfrage.

Will man wirklich die Anbindung analysieren, dann reichen derartige grundlegenden Tools lange nicht mehr aus, sondern man muss schon andere Geschütze auffahren.

Hinzu kommen natürlich auch noch Sachen wie MPLS und VRFs, so dass z.B. das Management-Netz oft ein eigenes Netz ist und anders geroutet wird, bzw. eine in sich abgeschlossene Routinginstanz hat. Ein Netz am gleichen Switch kann so z.B. in einem anderen VRF oder MPLS-Netzwerk hängen und muss eventuell einige Stationen mehr passieren, als wenn es direkt lokal geroutet wäre, da z.B. per Routing über eine Firewall die Verbindung zwischen den beiden Netzen stattfindet und nicht lokal auf dem Switch.

[zukzuk]

vor 2 Stunden schrieb Whiz-zarD:

Natürlich geht das. Das Zauberwort habe ich schon im ersten Beitrag genannt: Ajax
Was meinst du, wie z.B. Google Maps in eine Webseite eingebunden wird? Das ist auch nichts anderes als ein asynchroner HTTP-Request. 

Es gibt kein ICMP-Ping!
Ping ist nur der Name eines Tools, was nur die Paketumlaufzeit mit Hilfe eines ICMP Echo-Rquests misst. Der Name des Tools ist völlig unerheblich. Du könntest auch ein eigenes Tool schreiben, was ein Echo-Request abfeuert und es "Hallo" nennen.

Außerdem: Ein Echo Request ist so ziemlich nichtssagend, denn genauso gut könnte auch die Gegenstelle der Flaschenhals sein. Also nicht der Nutzer hat eine schlechte Verbindung, sondern der Server. Mit einem Echo Request würde man das nicht rausbekommen. Da müsste man sich u.a. dann schon die Route (z.B. mit dem Tool tracert (Windows) bzw. traceroute (Linux)) anschauen, die für das Datenpaket gewählt wurde. Netzwerkprobleme können so vielseitig sein. Es könnte auch ein DNS-Problem vorliegen. Die ganzen Probleme lassen sich nicht mit einem Echo-Request und einer UDP/TCP-Verbinung lokalisieren und deshalb ist es schon quatsch das Rad neuzuerfinden. Da wäre ich schon auf gängige Tools setzen.

Ein Beispiel für ein Netzwerkproblem: Vor einem Jahr beklagten Kabel Deutschland/Vodafone Kunden, dass sie Probleme mit dem Spiel Diablo 3 hatten. Die Paketumlaufzeit zu den Diablo 3-Servern war extrem hoch (die werden schon im Spiel gemessen). Schuldig war die Route, die für diese Pakete gewählt wurde, da diese durch mehrere Netzwerke gingen, die sehr langsam waren. Kabel Deutschland/Vodafone hat deswegen extra für die Diablo 3-Server eine andere Route festgelegt.

Also Google Maps wird doch IIRC per Iframe direkt in HTML eingebunden, oder?

Was ich vorgehabt hätte (wenn ich das Vorhaben denn wirklich noch in dieser Form umsetzen würde), wäre, einen HTTP-Request per Javascript zu machen (Ajax), da ich ja die Zeit messen möchte, die dieser benötigt. Und da gibt es m. E. schon Einschränkungen: https://www.google.de/?#q=xmlhttprequest+same+origin+policy Aber soweit ich beim Überfliegen gesehen habe, kann man da wohl "drumrumarbeiten".

Dass mit ICMP Ping ein Echo Request gemeint ist, sollte eigentlich klar sein ;-). Dass ich den grundsätzlichen Ablauf nicht hinterfragen möchte, da dieser vorgegeben ist, hatte ich auch schon geschrieben.

Mir ist auch klar, dass Netzwerkprobleme vielschichtig sein können, aber trotzdem danke für deine Ausführungen.

Bearbeitet 26. August 2016 von zukzuk