TCPパケットの最小サイズはいくつですか


11

ここに投稿:

http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html

「ブラウザーが実行できる最小のダウンロードは1Kバイトです。」

これは、ネットワーク全体のパケットの最小サイズが原因ですか?そうでない場合、これの理由は何ですか(本当にそうである場合)?


2
混乱を避けたい場合は、標準的な用語を使用してください。「パケット」はIPレベルの用語です。「IPパケット」とも「TCPパケット」とも言い、「イーサネットパケット」とも言いません。
vtest

あなたが引用する文(「ブラウザーが実行できる最小のダウンロードは1Kバイトです。」)は間違いなく真実ではありません-最小ダウンロードサイズはありません。(@ DMA57361で説明されているように)最小TCP / IPパケットサイズあります、1KBではありません。
Piskvorが建物を去る

回答:


20

パケットは、送信のさまざまな要素を参照するために誤用されることがあるので、ここではあいまいな用語です。データがどのようにまとめられているかを見てみましょう。つまり、私が何を意味しているのかがわかります。うまくいけば、望んだ答えが得られます。


TCP / IPモデルで、1バイトのデータ1をインターネット経由で送信するとします。

データ、アプリケーションレベルやニーズに始まり、それが周りに渡すことができるように、低いレベルのヘッダーに包まれます。

まず、データがTCPセグメントでラップされ、20バイトのヘッダーが追加されます(最小サイズは21バイトになりました)。
これは私たちを輸送レベルに置きます。

次に、これはIPパケットにラップされ、20バイトの別のヘッダーが追加されます(最小サイズは41バイトになりました)。
今、私たちはインターネットのレベルにいます。
このラッピングは、新しいルーターがデータを新しいサブネットに転送するたびに変更されることに注意してください。

これは、あるタイプのリンクフレームでラップされます-ヘッダーとフッターのサイズは、使用されるリンクのタイプに依存する、使用されるフレームのタイプによって異なります。
これはリンクレベルです。
このラッピングは、2つのエンティティ間で送信される場合、ユニットが変更されるたびに変更されます。

最後に、物理的な伝送(ケーブル、電波などの電気信号)です。

何が起こっているのか視覚的に説明するために役立つ、WikipediaのTCP / IPモデルページから入手できるいくつかの有益な画像を次に示します。


UDP / IPを使用したデータのカプセル化


TCP / IPモデルのレイヤーを介した接続


1. 0バイトを送信できると思いますが、まだ確認していません。実際、1バイトも許可されているかどうかは確認していませんが、ちょっと。


4

不正解です。ダウンロードの最小サイズはありません。これを確認するには、Webサーバーに小さなファイルを作成し、wiresharkを使用して、そのファイルをダウンロードするときにネットワークトラフィックを監視します。

標準イーサネットパケットの最小サイズは64バイトです。


3

一見すると、引用元のブログ投稿は正しくありません。HTTPの「最小ダウンロードサイズ」はありません。(そして、最小パケットサイズに関するあなたの理論も間違っています。)

しかし、これには一粒の真実があります。つまり、ダウンロードするファイルのサイズが十分に小さい場合、HTTP応答メッセージ(ファイルとHTTP応答ヘッダーで構成される)は単一のネットワークパケットに収まります。その場合、ブラウザは、応答を送信するために2つ以上のパケットを必要とする場合よりも、ファイルを取得する可能性が高くなります。

(応答に1つのパケットが含まれていると、パケットがドロップされて再送信する必要が生じる可能性が低くなり、TCP / IPフロー制御ウィンドウがパケット確認のために余分な往復遅延を追加しない可能性が高くなります。 )

送受信されるパケットの一般的な最大サイズ(MTU)は、イーサネットの場合は1500バイトです。IPとTCPのオーバーヘッド、および一般的なHTTP応答ヘッダーのサイズを考慮に入れると、応答の最初のパケットのファイルデータ用に約1Kを残すことができます。したがって、ブロガーのコメントにおける真実の粒度。


それは正しいでしょう-たとえば、ウェブページとそれに関連するリソース(画像、JS、CSS)ではなく、その1つの画像のみをダウンロードしている場合-その場合は、とにかく複数のリソースにキープアライブとパイプラインを使用しているため、TCPオーバーヘッドとパケットサイズはそれほど重要ではありません。あなたはこの特定のケースで正しい(1つのイメージのみをダウンロードする)が、それはどのくらいの頻度で起こりますか?ブロガーは1999年に行き詰まっているようです。この場合、各HTTPリクエストには独自のTCP接続が必要でした。
Piskvorが建物を去る

2

それはあなたが考えるよりも悪いです。

ページの読み込みが遅いのは、ブラウザが1x1ピクセルを800000回レンダリングするときに問題があるためです(たとえば、ブラウザウィンドウが1000x800に設定されている場合)。何年も前、おそらく1999年に、16x16をタイリングの「最速」x最小として規定した記事をどこかで読みました。もちろん、現在はレンダリングが異なる場合があります。

ブログの投稿を読んだ場合、苦情は実際にはページの読み込みが遅いことです。ダウンロードが遅くない。それは興味深い議論でしたが、パケットとは何の関係もありません。

したがって、おそらく質問を書き直す必要があります。


その場合、私はブログ投稿を完全に誤解している可能性があります-私はコアがこの文にあると思っていました:「ブラウザーが実行できる最小のダウンロードは1Kバイトなので、画像サイズを1Kに調整してください」私は「画像が50バイトしかないにもかかわらず、とにかく1Kバイトを送信しているため」と読みました(これは明らかにナンセンスです)。ここでの問題sizeは、ピクセル寸法バイト数の両方に「」を使用し、それら統合することである可能性があります。あなたの説明は理にかなっていますが、画像のバイト数とは無関係です(ブログの内容とは異なります)。
Piskvorがビルを去る

ブログの投稿を再度読んだ後、3番目の段落が矛盾しているため、彼は道を外れているようです。
モックマン、2011

コメントをもう一度読んだ後...彼の意図するポイントは、最初の段落で提起された問題に対処することです。ただし、彼は誤ってこの問題をパケットサイズに起因し、残りの投稿をそれに費やしています。私の答えは、ページの読み込みが遅い理由を説明しました。他の人が指摘したように、パケットの特性は原因ではありません。
モックマン2011
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.