Hallo,
mal eine Frage :
wenn man z.B. Skype verwendet oder z.B. ein FTP-Daten Transfer durchführt ist die erzeugte Paketgröße die durch das Internet gesendet wird IMMER gleich?
Also bei Skype wird es wohl TCP-Fragmente sein und bei FTP-Daten wohl UDP (vielleicht auch TCP)…
aber ist es immer so, dass NUR weil ein Tool auf TCP basis läuft, diese auch IMMER die gleiche Größe von Paketen produziert???
Gruß
aber ist es immer so, dass NUR weil ein Tool auf TCP basis
läuft, diese auch IMMER die gleiche Größe von Paketen
produziert???
Die Größe der Pakete ist abhängig von der Menge der zu übertragenden Nutzdaten. Was immer gleich bleibt, ist die maximale Größe eines unfragmentierten Paketes (MTU), und die ist hardwareabhängig. Welche Anwendung welche Protokolle fährt, ist dafür völlig unerheblich.
Gruß
Also bei Skype wird es wohl TCP-Fragmente sein und bei
FTP-Daten wohl UDP (vielleicht auch TCP)…
Das ist vermutlich genau andersherum und die Paketgröße ist, wie schon gesagt wurde, wurscht.
Hallo,
Danke für die Infos!
Hier mein Hintergrund :
Ich arbeite an einer Simulation von verschiedenen QoS-Klassen wie z.b. Skype, FTP, BestEffort usw… und dabei will ich den DURCHSATZ messen (sprich : Scheduler).
Ich will das es möglichst nah an der Realität ist und d.h. wusste ich nicht ob ich die Pakete von allen QoS-Klassen mit GLEICHER Größe simulieren sollte oder mit verschiedener!?!
Gruß
Moien
Ich arbeite an einer Simulation von verschiedenen QoS-Klassen
wie z.b. Skype, FTP, BestEffort usw…
BestEffort ist eine Bezeichnung aus dem QoS (Quality of Service) Umfeld, Skype ist eine Software mit eigenem, nicht dokumentieren Format und FTP ist Protokoll.
Was auch immer du vor hast …
Ich will das es möglichst nah an der Realität ist und d.h.
wusste ich nicht ob ich die Pakete von allen QoS-Klassen mit
GLEICHER Größe simulieren sollte oder mit verschiedener!?!
FTP geht eigentlich immer mit MTU über TCP raus. Was Skype tut weiss keiner, aber es ist viel UDP dabei. BestEffort ist eine Theorie, die schickt gar nichts.
cu
Ich will das es möglichst nah an der Realität ist
Mit tcpdump echten Traffic aufzeichnen und später, wann und wo du es brauchst, per replay wiedergeben.
Gruß
Ich arbeite an einer Simulation von verschiedenen QoS-Klassen
wie z.b. Skype, FTP, BestEffort usw… und dabei will ich den
DURCHSATZ messen (sprich : Scheduler).
So wie Du hier verschiedene Dinge durcheinander wirfst, hast Du andere Probleme, als die Paketgrößen. Ansonsten sollte die schon erwähnte Methode mit TCPdump brauchbare Durchsatzraten ermitteln.
Ok, nochmal im Klartext :
Ich werfe nichts durcheinander.
Man hat doch verschiedene Datenströme. D.h. verschiedene Bitraten, Anforderungen an Delay oder ähnliches.
D.h. z.B. Bei Skype hat man eine Bitrate zwischen 48-128bit/s und bei Webcam Stream hat man ca. 350kbit/s … und bei FTP Zugriff hat man den BestEffort Service bei z.B. ca. 64kbit/s … und diese verschiedenen „Datenströme“ kann man Anhand der „garantierter“ Datenrate oder des Delays in verschiedene QoS-Klassen einordnen.
Und die Frage war, ob die Paketgröße bei den verschiedenen QoS-Klassen überall GLEICH oder unterschiedlich ist.
d.h. es geht darum das man einen Traffic von vielen Menschen die mit Handy, PDA, Notebook auf Internet Zugriff haben und man diesen verschiedenen Traffic klassifizieren möchte und das dann in einer Simulation simulieren möchte.
Gruß
Moien
Man hat doch verschiedene Datenströme. D.h. verschiedene
Bitraten, Anforderungen an Delay oder ähnliches.
Ja, es gibt QoS Klassen. Die haben auch Namen. „Skype“ und „FTP“ gehören nicht dazu.
D.h. z.B. Bei Skype hat man eine Bitrate zwischen 48-128bit/s
und bei Webcam Stream hat man ca. 350kbit/s
Der Teil kann stimmen.
… und bei FTP Zugriff hat man den BestEffort Service
NEIN (nicht unbedingt).
bei z.B. ca. 64kbit/s
NEIN.
… und diese verschiedenen „Datenströme“ kann man Anhand der
„garantierter“ Datenrate oder des Delays in verschiedene
QoS-Klassen einordnen.
Das ursprüngliche TCP/IPv4 garantiert gar nichts. Kein Delay, keinen Durchsatz, keinen Jitter. IPv4 kennt aber ein TOS, welcher Einfluss auf die Werte haben kann. Kann, in der Realität aber nicht wirklich hat.
Das TOS-Feld wird inzwischen für DiffServ und ECN benutzt. Auch die 2 bringen in der Realität keine QoS Garantie. In der Realität bringen sie auch nicht wirklich was.
Und die Frage war, ob die Paketgröße bei den verschiedenen
QoS-Klassen überall GLEICH oder unterschiedlich ist.
Die Paketgrösse hat rein gar nichts mit dem QoS zu tun. Die maximale Paketgrösse und das benutzte Netzwerk haben was miteinander zu tun (Tokenring, Ethernet, ATM,… usw haben alle unterschiedliche maximale Grössen). Man kann auf bestimmten Netzen QoS fahren (Beispiel CAN), aber keines der QoS-fähigen Systeme wird real im Internet eingesetzt.
cu
Hallo Fragewurm,
Man hat doch verschiedene Datenströme. D.h. verschiedene
Bitraten, Anforderungen an Delay oder ähnliches.
D.h. z.B. Bei Skype hat man eine Bitrate zwischen 48-128bit/s
und bei Webcam Stream hat man ca. 350kbit/s
Bei Skype wirds wohl 1’000 mal mehr sein.
Und die Frage war, ob die Paketgröße bei den verschiedenen
QoS-Klassen überall GLEICH oder unterschiedlich ist.
Z.B. bei VoIP ist man eher bestrebt Datenpakete in zeitlich festen Abständen zu senden, als eine feste Blockgrösse zu verwenden. Man sampelt also in festen zeitlichen Abständen und komprimiert dann auch den Datenblock noch. Somit ergeben sich viele kleine Pakete mit unterschiedlicher Grösse, meist weit unterhalb des MTU-Wertes. Somit sind auch die hörbaren Störungen geringer, wenn ein Block verloren geht.
Aber jeder Programmierer kocht da sein eigenes Süppchen.
Bei FTP macht es mehr Sinn an die MTU-Grösse heran zu gehen. Allerdings ist es auch Teil des Protokolls, die Blockgrösse abzusprechen. Also je nach angesprochenem Host kann sich die Blockgrösse ändern.
Sinn und Zweck des ganzen TCP/IP ist es unterschiedliche Geräte zur Zusammenarbeit zu bekommen, deshalb ist auch die Blockgrösse variabel und Blöcke können fragmentiert werden, damit auch Geräte auf der Strecke mit kleineren Buffern noch mitkommen.
Bei Ethernet ist nur klar, dass die Blöcke