Comment mesurer le temps de réponse entre un serveur et un client de communiquer en utilisant le protocole UDP?

Le but du test est de vérifier la forme du réseau, le temps de réponse entre deux hôtes (client et serveur). Réseau de réponse = le voyage aller-retour du temps qu'il faut pour envoyer un paquet de données et de le recevoir. Je suis en utilisant le protocole UDP. Comment pourrais-je calculer le temps de réponse ? Je pourrais juste soustraire TimeOfClientRequest - TimeOfClientResponseRecieved. Mais je ne suis pas sûr si c'est la meilleure approche. Je ne peux pas le faire uniquement de l'intérieur le code et je pense que le système d'exploitation et l'ordinateur charge peut interférer dans le processus de mesure initiée par le client. En passant, je suis en utilisant Java.

J'aimerais entendre vos idées.

  • Le système d'exploitation et la charge de votre ordinateur seront des facteurs dans votre temps de réponse peu importe ce que vous faites
InformationsquelleAutor | 2009-03-05
  1. 2

    Suffit d'utiliser ping - RTT ( round trip time ) est l'une des choses que les mesures. Si la taille du paquet que vous envoyez des questions puis de ping vous permet également de spécifier la taille des données dans chaque paquet.

    Par exemple, je viens d'envoyer 10 paquets, chacun avec une résolution de 1024 octets de charge utile à ma passerelle en affichant uniquement le résumé statistiques:

    ping -c 10 -s 1024 -q 192.168.2.1

    PING 192.168.2.1 (192.168.2.1) 1024(1052) octets de données.

    --- 192.168.2.1 ping statistics ---

    10 paquets transmis, reçu 10, 0% packet loss, time 9004ms

    rtt min/avg/max/mdev = 2.566/4.921/8.411/2.035 ms

    La dernière ligne de départ avec le rtt ( round trip time ) est l'info que vous êtes probablement à la recherche pour.

    InformationsquelleAutor Robert S. Barnes
  2. 1

    Je pense que la méthode que vous mentionnez est fine. L'OS et de la charge de votre ordinateur peut interférer, mais leur effet serait probablement négligeable par rapport à la quantité de temps qu'il faut pour envoyer les paquets sur le réseau.

    À même les choses un peu, vous pouvez toujours envoyer plusieurs paquets d'avant en arrière et en moyenne le temps.

    InformationsquelleAutor Eric Petroelje
  3. 1

    Si vous avez accès au code, alors oui, il suffit de mesurer le temps entre le moment où la demande a été envoyée et la réception de la réponse. Gardez à l'esprit que la norme de la minuterie en Java uniquement a milliseconde.

    Vous pouvez également utiliser Wireshark pour capturer les paquets sur le fil que le logiciel enregistre également les horodateurs contre les paquets.

    Clairement dans les deux cas, le temps mesuré dépend de la rapidité de l'autre extrémité répond à votre demande initiale.

    Si vraiment vous voulez juste mesure réseau de latence et de contrôle au bout de vous-même, utilisez quelque chose comme la echo 7/udp service que la plupart des serveurs UNIX encore le support (même si c'est généralement désactivé pour empêcher son utilisation réfléchie des attaques DDoS).

    • Sur Windows XP, le currentTimeMillis a seulement 1/60ème de seconde précision.
    InformationsquelleAutor Alnitak
  4. 0

    il serait bien si vous pouviez envoyer des paquets ICMP - je suppose, parce qu'ils sont pris directement par la couche réseau, votre réponse ne lâche pas le temps en mode utilisateur sur le serveur.

    L'envoi de paquets ICMP en java semble toutefois ne pas être possible. Vous pouvez:

     boolean status = InetAddress.getByName(host).isReachable(timeOut)

    cela va envoyer un paquet ICMP, mais ce n'est pas ce que vous voulez.

    Toutefois, si vous commencez à le répondeur démon sur le côté serveur avec une priorité plus élevée, vous permettra de réduire l'effet de la charge du serveur.

    Effectivement la charge du serveur de ne pas jouer un rôle, aussi longtemps qu'il est ci-dessous de 100% de CPU.

    • Je suis confus. Vous dites qu'en Java il n'est pas possible d'envoyer un paquet ICMP, et de vous fournir le code. Veuillez expliquer.
    • Vous ne pouvez pas envoyer des premières paquets IP (nécessaire pour ICMP) sans les privilèges de root sur de nombreux O/S, et Java rend pas publiques les méthodes disponibles pour créer vos propres paquets ICMP.
    InformationsquelleAutor siddhadev
  5. 0

    Utiliser la commande ping, mais vous pouvez vous mesurer la RTT par l'envoi d'un paquet et l'autre la fin de l'envoi du paquet.

    Il est important que vous mesurez lorsque les boîtes sont sous typique charge, car c'est vous dire la RTT, vous pouvez vous attendre pour obtenir.

    Vous pouvez la moyenne des latences plus grand nombre de paquets, des millions ou des milliards d'obtenir une valeur cohérente.

    InformationsquelleAutor Peter Lawrey
  6. 0

    Outre quelques réponses a mentionné à propos de l'utilisation du ping ICMP pour mesurer la RTT, le temps est un bon moyen.

    Je souhaite apporter une autre façon de mesurer la RTT via UDP si vous pouvez à la fois contrôler le serveur&côté client. Le débit de base comme suit:

    1. Envoyer un paquet UDP P1 avec horodatage C1 du client vers le serveur
    2. Serveur actuels d'horodatage S1 pour le paquet tout reçu P1.
    3. Côté serveur de traitement
    4. Serveur actuels d'horodatage S2 pour le paquet avant de l'envoyer au client.
    5. Clients actuels d'horodatage C2-paquet tout reçu P1.

    Après cela, on peut calculer la RTT = (C2-C1) - (S2-S1).

    Il convient peut-être pas précis comme le ping ICMP et besoin de plus de contrôle à la fois sur le client&côté serveur, mais c'est gérable.

    InformationsquelleAutor foxty
  7. 0

    Tandis que ping est un bon début pour mesurer la latence, c'est en utilisant le protocole ICMP au lieu de UDP. Les paquets de différentes protols généralement ont des priorités différentes sur les routeurs etc.

    Vous pouvez utiliser netperf pour mesurer l'UDP aller-retour du temps:
    http://www.netperf.org/netperf/training/Netperf.html#0.2.2Z141Z1.SUJSTF.9R2DBD.T

    InformationsquelleAutor Sebastian Jespersen