説明「パースペクティブのHTTPプロトコルは、」私は、参照のみを目的として、ノートを勉強何オタクがレッスンの列を開く時、記録の羅Jianfeng（Qihooは360人の技術専門家）です。
私たちは、体内でHTTPメッセージの話最後の時間は、データのHTTP転送多くの種類だけでなく、テキストを知ることができるだけでなく、画像、オーディオおよびビデオを送信することができます。
初期のインターネットの伝送は、基本的にテキストや小さな絵のほんの数Kの大きさであり、今の状況は非常に異なっています。Webページには、情報が含まれている高品質の画像がM理論にあるKの何百も、それらの映画、テレビ番組、およびいくつかのGはもちろんのこと、おそらくあまりカジュアルホームページのHTMLで、Gの数十があります可能。
これとは対照的に、これらの大きなファイルの圧力下で100M光ファイバ固定回線または4Gモバイルネットワークは「小さなパイプ」、アップロードまたはダウンロードのどちらかになり、ネットワークの伝送リンクは「つばにフル」を絞るます
だから、どのように迅速かつ効率的に限られた帯域幅でこれらの大きなファイルを転送することが重要な課題となっています。これは、冷蔵庫のドアのように閉じたドア（完全転送）にそれを行く方法を象（ファイル）し、その後である、（コネクションを確立）すでに開かれているのですか？
今日は手段は、この問題を解決するには、HTTPプロトコルを見てみましょう。
データ圧縮
それは、「データの種類とエンコーディング」に来るとき、それを最後の講義を覚えていますか？あなたが印象を持っている場合は、確かにある基本的な解決策、と考えることができ、「データ圧縮」、象は冷蔵庫の中へそして豚ペチ、となります。
典型的には、ブラウザが要求を「取る送信するとき受け入れエンコード」に、サーバは、1つの圧縮アルゴリズムを選択することができるように、等ブラウザリストによってサポートされている圧縮フォーマットである」ヘッダフィールド、例えばGZIP、DEFLATE、BRをエンコード・コンテンツ事前に」応答は、その後、元のデータは、ブラウザに圧縮されています。
圧縮率はデータの100Kが50Kのサイズに圧縮することが可能である50％とすることができる場合、その後、加速効果は非常に明白一定速度倍増帯域幅の場合に相当します。
しかし、この解決策はまた、gzipの圧縮アルゴリズムは通常、すでに高度に圧縮されたテキストファイル、画像、オーディオ、ビデオなどのマルチメディアデータ自体のためのより良い圧縮率を持って、その後、gzipのプロセスは（小さくならないような欠点を持っていますでも、）ので、それは無効少しが増加する可能性があります。
ただし、データ圧縮効果はまだ非常に良いですが、そのための手段として、このテキストを扱う際に主要なサイトのサーバーが使用されます「最後にセキュリティを提供します。」例えば、それはnginxの中の命令「にはgzip」を使用します、「text / htmlの」の圧縮を有効です。
送信ブロック
データ圧縮に加えて、大規模なファイルそれの問題を解決する方法がないでしょうか？
圧縮は、より小さな、私たちが考えるように回すことができ、そうでない場合は全体の大きなファイルが小さく、それが「オープン」になり、全体的な大きなファイルである小片に分け、ブラウザにバッチでこれらの作品を入れて、ブラウズ受信して、回復を再組み立て。
このようなブラウザとサーバは、時間のメモリに保存されているすべてのファイルを持っているし、ネットワークのほんの一部には大容量のファイル、メモリ、帯域幅および他のリソースの長期占領されません送信されませんダウン保存されます。
これは、「断片的な」HTTPプロトコルにおけるアイデアが「チャンクヘッダーフィールドと応答パケットに、チャンク転送符号化」を「転送エンコード：チャンク」パケットは、本体部分を示すために、意味ではないこと使い捨て送ったが、個々の送信ブロック数（チャンク）に分けました。
これは、宛先に到達するために一緒に入れ、その後、キャスト冷蔵庫に1つのプットずつ壊す「レゴ」に魔法の象のようなものだ「血液復活の完全な。」
ブロック送信は動的データベースによって生成されたフォームページ「データストリーミング」を使用することができる、例えば、この場合、本体の長さではないヘッダフィールドに、未知のデータである「コンテンツ長は、ここで正確な長さを与えます」あなたは唯一のチャンク伝送モードをブロックすることができます。
「転送エンコーディング：チャンク」と「のContent-Length」この2つのフィールドがあり、相互に排他的な、これらの二つのフィールドでの応答メッセージが同時に表示することはできませんと言うことです、応答パケットの伝送距離が知らいずれか、または（チャンク）、未知の長さがあり、これはあなたが覚えておく必要がありますものです。
ここでは、ルールのブロック符号化伝送を見て、実際には、非常にシンプルな、同じクリアテキスト、非常に類似したレスポンスヘッダを使用しています。
各ブロックは二つの部分、ヘッダとデータブロックの長さを含みます。
ヘッドの長さはCRLF（キャリッジリターンライン、すなわち\ R \ n）はライン無地端、16進数の長さで表されます。
最後にCRLFで終わる直ちにヘッダの後のデータブロック長が、データは、CRLFを含んでいません。
最後に、0の長さ、すなわち、 "0 \ R \ n \ R \ n" は、ブロックの終わりを示します。
それはのようなマップを見て、理解し、理解することは少し難しいように聞こえます：
URIでの実験環境「/ 16-1は、」単にこのアドレスが結果にクロームの外観を使用してアクセスすることができ、ブロックの伝送をシミュレート：
しかし、ルールに従ったデータブロックの送信を受信した後、ブラウザを自動的に除去チャンク符号化、再組み立て手動でTelnetを使用して要求を送信する必要があり、サーバによって送信された元のメッセージの形式を見たい（またはWiresharkのを把握し、コンテンツをパック）：
| GET / 16-1 HTTP / 1.1 |
|
| ホスト：www.chrono.com |
コードをコピーし
六角最初の行の長さ、および、データを、その後16：Telnetは唯一ビンに応答パケットを受信するので、データブロックは、チャンク、それは明らかに応答パケットデータ形式で見ることができる、解決されていません長さとバイナリデータは、最後のブロックがゼロの長さの端部である繰り返します。
レンジリクエスト
チャンク転送エンコードを使用すると、サーバーは簡単に大容量のファイルを送受信することができますが、G上の非常に大きなファイルのために、考慮すべきいくつかの問題があります。
たとえば、あなたが肯定的で直接見て、タイトルをスキップしたい、ドラマを通して打たれた瞬間を見ている、またはいくつかの非常に退屈な物語のため、プログレスバーをドラッグしたいと早送り取得したい大きなファイルが実際にある数分、データフラグメント、およびサブブロック転送は、この能力を持っていません。
この需要を満たすためにHTTPプロトコルは、「提案された範囲の要求」のコンセプト（範囲要求を）、およびクライアントがファイルの一部は、同等の表現、事前に専用のフィールドを要求することを可能にする「断片的な」クライアントを。
サーバは、事前に応じてフィールドを使用しなければならないので、要求の範囲には、Webサーバーの機能を実現することができるか、実現することはできませんのために必要ではありません「のAccept-範囲：バイト」明確にクライアントに通知：「私はリクエストの範囲をサポートします」
そうでない場合には、どのようにそれを行うには？サーバーは、「同意する-範囲：なし」送信することができ、単に、または「同意する-範囲」フィールド送信しないが、ので、クライアントは、それが範囲要求機能を実装していないことを前提としていないだけ正直にファイル全体をトランシーバことができます。
要求ヘッダー範囲形式「であり、HTTPの範囲は、特定のフィールドを要求されたバイト= XY」、ここでxおよびyは、範囲データはバイトです。
xが、yが「オフセット」、範囲は、例えば、0からカウントされなければならない表すことに留意すべきで、最初の10のバイトは、「第10バイトは、「10-19」と表記され、「0-9」のように表されます0-10は、「実際には最初の11バイトです。
範囲はまた、Yが省略されてもよいX、それは容易に相互正または範囲を表すことができ、非常に柔軟な形式、開始点と終了点です。その後、ファイルが100バイトであると仮定すると：
「0-」とは、ファイル全体で文書の最初から最後までの文書、「0-99」の同等;
「10-」文書の最後に10バイトから開始され、「10-99」に対応します。
「-1」ファイルの最後のバイトは、「99〜99」に対応しています。
「-10」は、文書の末尾から10バイトの逆数に相当し、「90-99」。
サーバがRangeフィールドを受信すると、次の4つのことを行う必要があります。
まず、このようなファイルのように、範囲の合法性を検査しなければならない唯一の100バイトが、クロスボーダーの範囲である請求「200-300」です。サーバはステータスコードを返す416の手段は、「あなたの要求の範囲が間違っている、私は扱うことができないが、もう一度確認してください。」
第二の範囲が正しい場合、サーバは、オフセットによるRangeヘッダを計算するクリップファイルを読み、ステータス・コードを戻すことができる「206部分コンテンツ」、意味ほぼ200が、元のデータ本体の一部のみを表します。
第三に、に応じてヘッダーフィールドを追加するサーバコンテンツレンジ実際のオフセット値やリソースを伝えるために、フラグメントの合計サイズ、フォーマットが「XY /長さをバイト頭差範囲「=」、より範囲ないで、」全体の長さ。例えば、「0~10」の要求の範囲について、値が「0〜10/100バイト」です。
最後に、残りのデータは、レンジ要求が完成した処理であっても、TCPセグメントを使用して、クライアントに直接送信されます。
あなたは「/ 16-2」、実験環境と、それは「/mime/a.txt」を扱うオブジェクトをリクエストURIの範囲をテストすることができます。しかし、それは（容易ではない。この点についてFirefoxなどの良いように）何の編集機能のHTTPリクエストヘッダを持っていないので、我々は、Chromeブラウザを使用することはできません、それはまだTelnetを使用しています。
次の例で、Rangeフィールドを使用して、この要求は、ファイルの最初の32バイトを取得しました。
| GET / 16-2 HTTP / 1.1 |
|
| ホスト：www.chrono.com |
|
| 範囲：バイト= 0-31 |
コードをコピーし
データは、（複数の独立したフィールドを削除）が返されます。
| HTTP / 1.1 206部分コンテンツ |
|
| コンテンツの長さ：32 |
|
| 受け入れ-範囲：バイト |
|
| コンテンツ範囲：0〜31/96バイト |
|
|
|
|
| //これは、プレーンテキストのJSONドキュメントであります |
コードをコピーし
あなたは、要求のスコープを持っていたら、HTTPそれは簡単に大容量のファイルを処理するため、およびビデオファイルを見るとき、コンテンツ存在の正確なデータピースを取得するために、直接ファイル全体をダウンロードすることなく、時間にレンジポイントに基づいて算出することができます。
ドラッグ進行に必要な範囲要求、一般的にマルチセグメントのダウンロード、HTTPで使用されるダウンロードツールを参照するには、ビデオはまた、その実装に基づいているだけでなく、ポイントは以下のとおりです。
サーバーがサポートする要求の範囲かどうかを確認するために、HEADの起動、ファイルのサイズを取得します。
オープンNスレッド、Rangeフィールドを用いて、各スレッドは、それぞれ分割され断片は、ダウンロード、データの再送要求を送信する責任があります。
計画外の停止をダウンロードして恐れていない、それのその部分の範囲残りのダウンロード要求に基づく限り、前のレコードのように、何度も繰り返し起動する必要はありません。
複数のデータ
ただ、断片を得るために一度だけの要求の範囲を言う、実際には、それはまた、1回のデータの複数のセグメントを取得し、範囲内の複数の使用先に「XY」をサポートしています。
「：この状況は、特別なMIMEタイプを使用する必要マルチパート/ byterangesをメッセージ本体がマルチバイトシーケンスのセグメントから構成され、また、パラメータ」であることを示す、「境界= XXX」セグメント間の分離を与えていますマーク。
複数のデータのトランスポートブロックの形式は比較的類似しているが、図によって比較することができる、異なる境界セグメントを区別するために、分割マークを必要とします。
各セグメントは、で開始しなければならない - （2で前に「 - 」）、次いで普通のように、このデータが存在するの「コンテンツタイプ」と「コンテンツレンジ」タグタイプとスコープを使用する「境界線」 「 - -boundary- - 」（2つずつ前後「 - 」）セグメントのすべてことを示すキャリッジリターンラインのヘッドエンドに応答し、一緒にしたデータ・セグメント、および最終的にと同様。
例えば、我々は実験環境のTelnetの範囲を持つ2つの要求を送信されました：
| GET / 16-2 HTTP / 1.1 |
|
| ホスト：www.chrono.com |
|
| 範囲：バイト= 0-9、20-29 |
コードをコピーし
取得しますこれは、次のとおりです。
| HTTP / 1.1 206部分コンテンツ |
|
| コンテンツタイプ：マルチパート/ byteranges。境界= 00000000001 |
|
| コンテンツの長さ：189 |
|
| 接続：キープアライブ |
|
| 受け入れ-範囲：バイト |
|
|
|
|
|
|
|
| --00000000001 |
|
| コンテンツタイプ：text / plainの |
|
| コンテンツ範囲：バイト0~9 / 96 |
|
|
|
|
| // これは |
|
| --00000000001 |
|
| コンテンツタイプ：text / plainの |
|
| コンテンツ範囲：20-29 / 96バイト |
|
|
|
|
| EXT JSON D |
|
| --00000000001-- |
コードをコピーし
「--- 00000000001」のメッセージは、クライアントが容易にマルチレンジ領域データを分離するために使用することができ、多段分離装置です。
概要
今日はここに簡単な要約を作成し、HTTP転送大きなファイルに関連する知識を学びました：
HTMLは、大きなファイルを転送するための基本的な方法であるとして圧縮テキストは、そのようなファイル;
ブロック伝送は、レスポンスヘッダフィールド「転送エンコード：チャンク」を用いて送信し、ストリーミングデータを受信し、メモリバンド幅節約することができるブロックのフォーマットを示すためには16進数ヘッダ長+データブロックであると、
Range要求は、ビデオまたはドラッグHTTPのための唯一のいくつかのデータ、つまり、「セグメント要求」を、取得してもよい、リクエストヘッダフィールド「範囲」とレスポンスヘッダフィールドの「Content-範囲」は、レスポンスステータスコードは206でなければなりません。
複数の範囲を要求することができる、パケットデータの種類に応じて、この時間は、「マルチパート/ byteranges」、複数の部分における本体は、境界文字列で分離されています。
これは相互に排他的ではなく、組み合わせて使用することができることに留意すべき4つの方法の後に、例えば、その後、ブロック又はセグメント、実験環境URI「/ 16-3」圧縮ブロック伝送は、A上でシミュレート場合は、Telnet独自の試みを使用することができます。
職場でのレッスン
データは、キャリッジリターンラインフィード（\ R \ n）を含んでいる場合、データの時間ブロック伝送、処理ブロック、それに影響を与えるだろうか？
そのような「範囲：バイト= 10-19」としてGZIPファイル要求の実装の範囲場合、この範囲は、元のファイルまたは圧縮ファイルが適用されますか？