Daten jeglicher Art werden ja paketweise beim Down-/Upload übertragen. Haben diese Pakete immer die gleiche Größe, oder variiert das je nach Größe der Datei?
Seite 1 von 1
Größe von Datenpaketen ?
#1
geschrieben 10. Oktober 2014 - 18:37
Es ist nicht alles Chrome was glänzt. Firefox -Der bessere Browser
Anzeige
#2
geschrieben 10. Oktober 2014 - 18:47
Je nach Netzwerktyp ist die MTU (Maximum Transfer Unit) unterschiedlich.
Ein Ethernetpaket hat üblicherweise bis zu 1.5kB
Jumbo Packets können größer sein, wenn ich mich nich irre bis 10MB.
Lesestoff:
http://www.elektroni...net/0812211.htm
http://de.wikipedia....ansmission_Unit
Ein Ethernetpaket hat üblicherweise bis zu 1.5kB
Jumbo Packets können größer sein, wenn ich mich nich irre bis 10MB.
Lesestoff:
http://www.elektroni...net/0812211.htm
http://de.wikipedia....ansmission_Unit
Dieser Beitrag wurde von Sturmovik bearbeitet: 10. Oktober 2014 - 18:50
«Geschichte wiederholt sich nicht, aber sie reimt sich» (Mark Twain)
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#3
geschrieben 10. Oktober 2014 - 19:17
Kommt immer drauf an, WAS Du für ein Paket - oder Frame - Du betrachtest - IPv4-Pakete, oder -v6-Pakete, oder getunnelte Pakete, oder Ethernet-Frames, oder oder oder ![:)](https://www.winfuture-forum.de/public/style_emoticons/default/smile.gif)
Aber grundsätzlich: Ja, Frames auf der Leitung haben eine standardisierte Größe und während man Datenpakete darüber variieren KANN, hat es sich eingebürgert, diese entsprechend so zu bauen, daß sie ganz genau in den Ethernet Frame reinpassen. Dann ist die Leitungsnutzung optimal.
Aber "notwendig" ist es nicht. Man kann IP-Pakete (fast) beliebiger Größe durchs Netz schicken - die werden dann fragmentiert und auf meherere Ethernet Frames verteilt. Das ist dann nicht mehr so optimal in bezug auf die Leitungsnutzung.
![:)](https://www.winfuture-forum.de/public/style_emoticons/default/smile.gif)
Aber grundsätzlich: Ja, Frames auf der Leitung haben eine standardisierte Größe und während man Datenpakete darüber variieren KANN, hat es sich eingebürgert, diese entsprechend so zu bauen, daß sie ganz genau in den Ethernet Frame reinpassen. Dann ist die Leitungsnutzung optimal.
Aber "notwendig" ist es nicht. Man kann IP-Pakete (fast) beliebiger Größe durchs Netz schicken - die werden dann fragmentiert und auf meherere Ethernet Frames verteilt. Das ist dann nicht mehr so optimal in bezug auf die Leitungsnutzung.
#4
geschrieben 10. Oktober 2014 - 19:47
Das was ich wissen wollte scheint pauschal nicht zu beantworten sein.
Ich ging bis dato davon aus dass Dateien grundsätzlich in 1500 Bytes kleinen Stückchen zerhackt werden da der Client bzw Router ja für jedes Datenfragment eine Anfrage an den Server schicken muss damit dieser weiß wohin er das Paket verteilen muss/prüft ob überhaupt das richtige angekommen ist und passieren darf.
Ok, frage ich mal direkt was ich eigentlich selbst rausfinden wollte.
Wir hatten hier eine Diskussion in wieweit der Ping die Downloadzeit einer Datei beeinflusst.
Die Voraussetzungen sind gleich.
Gleiche Hardware, exakt gleiche Konfiguration, Download der gleichen Datei vom gleichen Server, welcher immer gleich schnell reagiert, usw usf
User A möchte mit seiner 10 MB/s Leitung und einem Ping von 15 ms per TCP/IP eine 100 MB Große Datei laden.
USER B die Gleiche. Er hat allerdings einen Ping von 100 ms.
Wer hat die Datei nun schneller gedownloadet?
Ich ging bis dato davon aus dass Dateien grundsätzlich in 1500 Bytes kleinen Stückchen zerhackt werden da der Client bzw Router ja für jedes Datenfragment eine Anfrage an den Server schicken muss damit dieser weiß wohin er das Paket verteilen muss/prüft ob überhaupt das richtige angekommen ist und passieren darf.
Ok, frage ich mal direkt was ich eigentlich selbst rausfinden wollte.
Wir hatten hier eine Diskussion in wieweit der Ping die Downloadzeit einer Datei beeinflusst.
Die Voraussetzungen sind gleich.
Gleiche Hardware, exakt gleiche Konfiguration, Download der gleichen Datei vom gleichen Server, welcher immer gleich schnell reagiert, usw usf
User A möchte mit seiner 10 MB/s Leitung und einem Ping von 15 ms per TCP/IP eine 100 MB Große Datei laden.
USER B die Gleiche. Er hat allerdings einen Ping von 100 ms.
Wer hat die Datei nun schneller gedownloadet?
Dieser Beitrag wurde von Ler-Khun bearbeitet: 10. Oktober 2014 - 19:48
Es ist nicht alles Chrome was glänzt. Firefox -Der bessere Browser
#5
geschrieben 10. Oktober 2014 - 20:05
Dass die Dateien zerhackt werden stimmt schonmal, und zwar nach Ethernetspezifikation in 1460B große Blöcke, damit noch der ganze Headerquatsch in dem 1500B Frame Platz hat.
Allerdings werden die Pakete nur am Anfang einer Übertragung einzeln rausgeschickt, um erstmal auf Antwort zu warten. Ist die Übertragung i.O. wird der Sender mehrere Pakete auf den Weg schicken und erst dann Antwort erwarten. So wird das Netz weniger von den sehr kleinen ACK-Packeten belastet und erst so werden bei langen Signallaufzeiten brauchbare Übertragungsraten erzielt.
Nebenbei müssen bei TCP auch nicht alle Pakete in der richtigen Reihenfolge ankommen. Die Pakete nehmen gerne mal unterschiedliche Wege durchs Netz, der Empfänger sortiert das dann und bestätigt die angekommenen.
Damit hat der Ping bei großen Übertragungen nur einen sehr begrenzten Einfluss.
Allerdings werden die Pakete nur am Anfang einer Übertragung einzeln rausgeschickt, um erstmal auf Antwort zu warten. Ist die Übertragung i.O. wird der Sender mehrere Pakete auf den Weg schicken und erst dann Antwort erwarten. So wird das Netz weniger von den sehr kleinen ACK-Packeten belastet und erst so werden bei langen Signallaufzeiten brauchbare Übertragungsraten erzielt.
Nebenbei müssen bei TCP auch nicht alle Pakete in der richtigen Reihenfolge ankommen. Die Pakete nehmen gerne mal unterschiedliche Wege durchs Netz, der Empfänger sortiert das dann und bestätigt die angekommenen.
Damit hat der Ping bei großen Übertragungen nur einen sehr begrenzten Einfluss.
«Geschichte wiederholt sich nicht, aber sie reimt sich» (Mark Twain)
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#6
geschrieben 10. Oktober 2014 - 20:58
Interessant. Das ist dann wohl auch der Grund wieso Downloads nicht am exakt gleichen Bit wieder aufgenommen werden wo sie unterbrochen wurden, sondern ein bisschen vorher.
Es weicht etwas vom Thema ab, aber gibt es eine Regel wann ein ACK Request stattzufinden hat?
Denn wenn ich's mir so recht überlege ist der Paketfilter des Router ja eigentlich ziemlich nutzlos und es ist recht einfach Malware durchzuschleusen wenn nicht jedes Paket kontrolliert wird.
Es weicht etwas vom Thema ab, aber gibt es eine Regel wann ein ACK Request stattzufinden hat?
Denn wenn ich's mir so recht überlege ist der Paketfilter des Router ja eigentlich ziemlich nutzlos und es ist recht einfach Malware durchzuschleusen wenn nicht jedes Paket kontrolliert wird.
![Eingefügtes Bild](http://www.smiliecenter.de/smilies/nachdenkliche/nachdenkliche_smilies_0008.gif)
Dieser Beitrag wurde von Ler-Khun bearbeitet: 10. Oktober 2014 - 21:00
Es ist nicht alles Chrome was glänzt. Firefox -Der bessere Browser
#7
geschrieben 10. Oktober 2014 - 21:23
Moment.. ich hatte da oben was verdreht.
Bei TCP wird grundsätzlich jedes Paket bestätigt.
Der Sender schickt zwar eine Reihe von Paketen raus ohne zwischen jedem einzelnen Paket auf Bestätigung zu warten, aber irgendwann möchte er doch mal ne Antwort haben.
Wenn eine Weile keine Bestätigung gekommen ist, wird von Packetloss ausgegangen und das Paket geht erneut auf Reisen.
Mit Paketfilterung hat das aber mal gar nichts zu tun. Hier wird anhand eines Regelwerks entschieden, ob ein Paket, das von einer bestimmten IP kommt, einen bestimmten Socket (IP+Port) erreichen darf. Welche Nummer das Paket in der Reihe hat, ist völlig egal, genauso was da drinsteckt.
Der Inhalt eines Pakets kann nur in höheren Schichten kontrolliert werden*, dazu muss aber eine Reihe von Paketen zusammengetüddelt werden, damit eine sinnvolle Inhaltsprüfung durchgeführt werden kann, wenn nicht gar die ganze Datei.
Sowas passiert z.B. in Application Layer Gateways, die wie der Name schon sagt, auf Schicht 7 arbeiten.
*) Geschichten wie Deep Packet Inspection, die das auch anhand von Signaturen auf Layer 2-3 machen lasse ich hier erstmal weg, das ist eher was für den Enterprisebereich.
Bei TCP wird grundsätzlich jedes Paket bestätigt.
Der Sender schickt zwar eine Reihe von Paketen raus ohne zwischen jedem einzelnen Paket auf Bestätigung zu warten, aber irgendwann möchte er doch mal ne Antwort haben.
Wenn eine Weile keine Bestätigung gekommen ist, wird von Packetloss ausgegangen und das Paket geht erneut auf Reisen.
Mit Paketfilterung hat das aber mal gar nichts zu tun. Hier wird anhand eines Regelwerks entschieden, ob ein Paket, das von einer bestimmten IP kommt, einen bestimmten Socket (IP+Port) erreichen darf. Welche Nummer das Paket in der Reihe hat, ist völlig egal, genauso was da drinsteckt.
Der Inhalt eines Pakets kann nur in höheren Schichten kontrolliert werden*, dazu muss aber eine Reihe von Paketen zusammengetüddelt werden, damit eine sinnvolle Inhaltsprüfung durchgeführt werden kann, wenn nicht gar die ganze Datei.
Sowas passiert z.B. in Application Layer Gateways, die wie der Name schon sagt, auf Schicht 7 arbeiten.
*) Geschichten wie Deep Packet Inspection, die das auch anhand von Signaturen auf Layer 2-3 machen lasse ich hier erstmal weg, das ist eher was für den Enterprisebereich.
Dieser Beitrag wurde von Sturmovik bearbeitet: 10. Oktober 2014 - 21:33
«Geschichte wiederholt sich nicht, aber sie reimt sich» (Mark Twain)
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
Unix won't hold your hand. You wanna shoot your foot, Unix reliably delivers the shot.
True Cloudstorage
#8
geschrieben 10. Oktober 2014 - 22:28
Es gibt keine ACK Anforderung. Die gehen "automatisch" raus (Packet ACKnowledged).
Es gibt aber eine Echo-Anforderung. Das ist der Ping.![:)](https://www.winfuture-forum.de/public/style_emoticons/default/smile.gif)
Wie Sturmovik schon schrieb, Pingzeiten haben mit der Downloadgeschwindigkeit nur sehr bedingt was zu tun. Insbesondere dann nicht, wenn es größere Dateien warden.
Pingzeiten haben dann Einfluß auf die Downloadgeschwindigkeit, wenn viele viele kleine Dateien auf einmal heruntergeladen werden UND die Verbindung jedesmal auf- und wieder abgebaut wird. Heutzutage wird das aber abgefedert, indem eine bestehende TCP-Verbindung für höhere Ebenen (wie den Download besagter Dateien) schlicht weiterverwendet wird.
Auf die Downloadgeschwindigkeit haben Einfluß (nur netztechnisch, "langsame Festplatte" mal außen vor gelassen):
- Die Geschwindigkeit, mit der der Server selber Daten auf die Leitung schreibt
- Die Kabelqualität
- Die Auslastung des Netzwerks (je höher, desto mehr Kollisionen auf der Leitung => mehr Pakete müssen neu übertragen werden und Unterwegsbahnhöfe wie Switches und Router können auch aus-/überlastet sein)
- Bodo mit dem Bagger (eine überraschend häufige Ursache)
- Und natürlich die Leitungs*länge*. Signale haben einfach eine gewisse Laufzeit, auch wenn diese auf Lichtwellenleitern ganz anders aussieht als auf Kupfer.![:)](https://www.winfuture-forum.de/public/style_emoticons/default/smile.gif)
Nur zur Info allerdings: Downloads werden "nicht ganz am Ende" wieder aufgenommen nicht wegen irgendwelcher TCP-Geschichten (Davon kriegen die Downloads nix mit) sondern einfach deswegen, weil Davon ausgegangen wird, daß der Datenstrom schlicht abgerissen ist und daher am Ende vermutlich "ausgefranst" sein wird. Also überschreibt man das "zerfetzte" Ende eben nochmal.
Es gibt aber eine Echo-Anforderung. Das ist der Ping.
![:)](https://www.winfuture-forum.de/public/style_emoticons/default/smile.gif)
Wie Sturmovik schon schrieb, Pingzeiten haben mit der Downloadgeschwindigkeit nur sehr bedingt was zu tun. Insbesondere dann nicht, wenn es größere Dateien warden.
Pingzeiten haben dann Einfluß auf die Downloadgeschwindigkeit, wenn viele viele kleine Dateien auf einmal heruntergeladen werden UND die Verbindung jedesmal auf- und wieder abgebaut wird. Heutzutage wird das aber abgefedert, indem eine bestehende TCP-Verbindung für höhere Ebenen (wie den Download besagter Dateien) schlicht weiterverwendet wird.
Auf die Downloadgeschwindigkeit haben Einfluß (nur netztechnisch, "langsame Festplatte" mal außen vor gelassen):
- Die Geschwindigkeit, mit der der Server selber Daten auf die Leitung schreibt
- Die Kabelqualität
- Die Auslastung des Netzwerks (je höher, desto mehr Kollisionen auf der Leitung => mehr Pakete müssen neu übertragen werden und Unterwegsbahnhöfe wie Switches und Router können auch aus-/überlastet sein)
- Bodo mit dem Bagger (eine überraschend häufige Ursache)
- Und natürlich die Leitungs*länge*. Signale haben einfach eine gewisse Laufzeit, auch wenn diese auf Lichtwellenleitern ganz anders aussieht als auf Kupfer.
![:)](https://www.winfuture-forum.de/public/style_emoticons/default/smile.gif)
Nur zur Info allerdings: Downloads werden "nicht ganz am Ende" wieder aufgenommen nicht wegen irgendwelcher TCP-Geschichten (Davon kriegen die Downloads nix mit) sondern einfach deswegen, weil Davon ausgegangen wird, daß der Datenstrom schlicht abgerissen ist und daher am Ende vermutlich "ausgefranst" sein wird. Also überschreibt man das "zerfetzte" Ende eben nochmal.
#9
geschrieben 11. Oktober 2014 - 23:28
Ach so ist das. Danke euch für die Informationen.
Es ist nicht alles Chrome was glänzt. Firefox -Der bessere Browser
Thema verteilen:
Seite 1 von 1