ここに投稿:
http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html
「ブラウザーが実行できる最小のダウンロードは1Kバイトです。」
これは、ネットワーク全体のパケットの最小サイズが原因ですか?そうでない場合、これの理由は何ですか(本当にそうである場合)?
ここに投稿:
http://blogs.adobe.com/dreamweaver/2011/02/optimal-css-tiled-background-image-size.html
「ブラウザーが実行できる最小のダウンロードは1Kバイトです。」
これは、ネットワーク全体のパケットの最小サイズが原因ですか?そうでない場合、これの理由は何ですか(本当にそうである場合)?
回答:
パケットは、送信のさまざまな要素を参照するために誤用されることがあるので、ここではあいまいな用語です。データがどのようにまとめられているかを見てみましょう。つまり、私が何を意味しているのかがわかります。うまくいけば、望んだ答えが得られます。
TCP / IPモデルで、1バイトのデータ1をインターネット経由で送信するとします。
データ、アプリケーションレベルやニーズに始まり、それが周りに渡すことができるように、低いレベルのヘッダーに包まれます。
まず、データがTCPセグメントでラップされ、20バイトのヘッダーが追加されます(最小サイズは21バイトになりました)。
これは私たちを輸送レベルに置きます。
次に、これはIPパケットにラップされ、20バイトの別のヘッダーが追加されます(最小サイズは41バイトになりました)。
今、私たちはインターネットのレベルにいます。
このラッピングは、新しいルーターがデータを新しいサブネットに転送するたびに変更されることに注意してください。
これは、あるタイプのリンクフレームでラップされます-ヘッダーとフッターのサイズは、使用されるリンクのタイプに依存する、使用されるフレームのタイプによって異なります。
これはリンクレベルです。
このラッピングは、2つのエンティティ間で送信される場合、ユニットが変更されるたびに変更されます。
最後に、物理的な伝送(ケーブル、電波などの電気信号)です。
何が起こっているのか視覚的に説明するために役立つ、WikipediaのTCP / IPモデルページから入手できるいくつかの有益な画像を次に示します。
1. 0バイトを送信できると思いますが、まだ確認していません。実際、1バイトも許可されているかどうかは確認していませんが、ちょっと。
一見すると、引用元のブログ投稿は正しくありません。HTTPの「最小ダウンロードサイズ」はありません。(そして、最小パケットサイズに関するあなたの理論も間違っています。)
しかし、これには一粒の真実があります。つまり、ダウンロードするファイルのサイズが十分に小さい場合、HTTP応答メッセージ(ファイルとHTTP応答ヘッダーで構成される)は単一のネットワークパケットに収まります。その場合、ブラウザは、応答を送信するために2つ以上のパケットを必要とする場合よりも、ファイルを取得する可能性が高くなります。
(応答に1つのパケットが含まれていると、パケットがドロップされて再送信する必要が生じる可能性が低くなり、TCP / IPフロー制御ウィンドウがパケット確認のために余分な往復遅延を追加しない可能性が高くなります。 )
送受信されるパケットの一般的な最大サイズ(MTU)は、イーサネットの場合は1500バイトです。IPとTCPのオーバーヘッド、および一般的なHTTP応答ヘッダーのサイズを考慮に入れると、応答の最初のパケットのファイルデータ用に約1Kを残すことができます。したがって、ブロガーのコメントにおける真実の粒度。
それはあなたが考えるよりも悪いです。
ページの読み込みが遅いのは、ブラウザが1x1ピクセルを800000回レンダリングするときに問題があるためです(たとえば、ブラウザウィンドウが1000x800に設定されている場合)。何年も前、おそらく1999年に、16x16をタイリングの「最速」x最小として規定した記事をどこかで読みました。もちろん、現在はレンダリングが異なる場合があります。
ブログの投稿を読んだ場合、苦情は実際にはページの読み込みが遅いことです。ダウンロードが遅くない。それは興味深い議論でしたが、パケットとは何の関係もありません。
したがって、おそらく質問を書き直す必要があります。
size
は、ピクセル寸法とバイト数の両方に「」を使用し、それらを統合することである可能性があります。あなたの説明は理にかなっていますが、画像のバイト数とは無関係です(ブログの内容とは異なります)。