Letzthin war die Real User Experience in der Lage die KPI von Anwendungen, welche das Protokoll http/https verwenden, zu messen. Das neue TCP Plugin ermöglicht nun, mittels eines client request/server response Kommunikationsmodels, die KPI der TCP Kommunikation darzustellen.
Das neue Plugin ist in der Lage die Informationen unabhängig vom im Layer 7 implementierten Anwendungsprotokoll zu entnehmen.
Folgende qualitative Informationen werden vom Plugin exportiert:
KPI | Description |
Client/Server network latency | Netzwerk-Latenz auf Client/Server Seite |
Application server latency | Durchlaufzeit der Anfrage (ohne network time) |
Load Time | Zeitspanne zwischen der Anfrage des Clients und dem Versenden des letzten Bytes seitens der Anwendung, also gesamte Antwortzeit der Anwendung |
Application Throughput | Antwortgeschwindigkeit der Anwendung |
Network Throughput | Datenübertragungsgeschwindigkeit |
Retransmitted – OOO – Fragmented Packets | Weitergeleitete oder fragmentierte Packete |
Receive window close | Anzahl der vom Client/Server gemeldeten received full buffer und die dadurch verlangsamte Verarbeitung der Requests |
Reset | Auf Kommunikationsfehlern basierende Neustarts |
Zusätzlich zu den oben genannten qualitativen Daten, kann das TCP Plugin auch folgende quantitative Daten liefern:
KPI | Description |
Bytes | Anzahl übertragener Bytes vom Client/Server zuzüglich des TCP stack header |
Payload bytes | Nur die Bytes der Applikations – Inhaltsantwort |
Packets | Anzahl der vom Client oder Server versendeten Packete |
Transfer time | Datenübertragungszeit (Upload/Download) |
Das neue Plugin kann die oben genannten KPIs auch für Kommunikationen ermitteln, welche SSL/TLS Verschlüsselungen nutzen, ohne den entsprechenden Private Key installieren zu müssen. Dies erlaubt die Leistungsverfolgung verschlüsselter Kommunikationen Dritter innerhalb der Cloud.
Um Kommunikationen in SSL/TLS ausmessen zu können, muss die IP/der Port des Dienstes, oder alternativ, der Hostname/Port bekannt sein. Außerdem ist es notwendig, dass der Client die SNI Erweiterung (service name indicator) nutzt.
Die SNI Erweiterung ist hilfreich wenn Sie einen Dienst mit vielen dazugehörigen IPs überwachen wollen oder wenn sich die IPs stetig ändern (z.B. bei Cloud-Diensten). Mit SNI können wir den Dienst, ausgehend vom Hostname welcher vom Client für die Verbindung genutzt wird, erkennen. Dies geschieht unabhängig von möglichen Änderungen der IP in Verbindung mit dem Dienst.
Hier ein Beispiel der Darstellung von, nach „Netgroups“ zusammengefassten, TCP Daten: