[LINUX] Einwegverzögerungsmessung des Netzwerks mit Python

Motivation

Bei internationaler Kommunikation mit großen Verzögerungen und Schwankungen möchte ich herausfinden, ob sich die Hin- oder Rückreise auf die Kommunikation auswirkt. Ich möchte die Hin- und Rückrouten getrennt messen, anstatt die RTT-Verzögerung durch Ping zu messen. Der Grund, warum eine Einwegverzögerung derzeit schwierig ist, besteht darin, dass die Zeiten der beiden zu messenden Knoten genau synchronisiert werden müssen. Da die internationale Leitung wie diese Zeit jedoch RTT 100 ms hat, ist die nächste NTP-Synchronisation gut. Es wird angenommen, dass der Fehler höchstens einige ms beträgt, die theoretisch kürzeste Einwegverzögerung geschätzt werden kann und der NTP-Synchronisationsabweichungswert bis zu einem gewissen Grad daraus geschätzt werden kann. In Anbetracht des Verarbeitungsaufwands sollte es auch nicht von einem Skript verarbeitet werden. Wenn es sich jedoch um ein Skript handelt, verursacht es bei einem aktuellen Server keinen Fehler von 1 ms. Daher habe ich mich für einfaches Python entschieden. Um es einfach auszudrücken: "Grob herausschneiden"

Methode

1 Roundtrip-Aktualisierungspaket zwischen Client und Server

1. Der Client (a) speichert die Startzeit und fragt den Server nach der Paketankunftszeit ab.
2. Der Server (b) gibt die Zeit zurück, zu der das Paket an den Client empfangen wurde.
3. Der Client (c) zeichnet die Zeit auf, zu der er die Antwort vom Server erhalten hat
4. (b) - (a) = ausgehende Verzögerung / (c) - (b) = eingehende Verzögerung

Code (Minimum)

Server

owpingserver.py

#!/usr/bin/env python

import socket
import time

host = '0.0.0.0'
port = 12345
bufsize = 512

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind((host,port))
while True:
   data,addr = sock.recvfrom(bufsize)
   sock.sendto("%.6f" % time.time(), addr)

Client

owpingclient.py

#!/usr/bin/env python

import socket
import time

host = 'localhost' #Geben Sie vorerst Ihre eigene IP an
port = 12345
bufsize = 512

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
stime = "%.6f" % time.time()
sock.sendto(stime, (socket.gethostbyname(host), port))
data, addr = sock.recvfrom(bufsize)
etime = "%.6f" % time.time()

print  "forward : " + str(float(data) - float(stime))
print  "backward: " + str(float(etime) - float(data))
print  "total:    " + str(float(etime) - float(stime))

time.sleep(1)
sock.close()

Eigentlich ist Pakeros auch schrecklich, daher sind Wiederholungs- und Timeout-Verarbeitung erforderlich, und ich habe es mit einer Ausgabe implementiert, die etwas einfacher zu handhaben ist, aber ich habe es jetzt weggelassen.

Vorerst auf lokalem Host ausführen

Wird im selben Host (localhost) durchgeführt

$ python owpingserver.py &
$ python owpingclient.py
forward : 0.000324964523315
backward: 4.81605529785e-05
total:    0.000373125076294

$ ping localhost -c 1
PING localhost (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.017 ms

--- localhost ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.017/0.017/0.017/0.000 ms

Es ist mindestens eine Größenordnung weniger genau als Ping. .. .. Hauptsächlich ist der ausgehende Overhead hoch. Nun, der Unterschied in der Genauigkeit zwischen 10 μs und 100 μs ist fast wie erwartet. Sie können es auf internationalen Linien ignorieren. (Aufgeben ist wichtig)

Messergebnisse auf tatsächlichen internationalen Linien

Blaue Linie: Hin- und Rückfahrt, orange: ausgehend, grün: eingehend. Sie können es etwa einen halben Tag lang im Batch ausführen und als Grafik lesen

1. Offensichtlich ist die Auswirkung der ausgehenden Verzögerung auf die RTT-Verzögerung enorm
2. Die geografische Route ist (sollte) fast gleich, und ich bin der Meinung, dass 15 ms in eine Richtung etwas kurz sind, sodass die Knotenzeit um bis zu 3 ms verschoben werden kann.
3. Was mache ich seit dem frühen Morgen der Ferien?

Übrigens, als ich es auf verschiedenen Instanzen desselben Rechenzentrums ausprobierte, kam die zukünftige Zeit ungefähr 1 Mikrosekunde zurück.

Nachtrag

26.02.2017: Ich habe den entsprechenden Code in C geschrieben, aber er hat sich um ca. 150 μs verringert. Es hat sich nicht so sehr verbessert, wie ich erwartet hatte. Python ist vorerst in Ordnung.