バイトサービング(別名:範囲リクエスト、バイト範囲サービング、[ 1 ]ページオンデマンド[ 2 ] )は、 HTTPプロトコル 1.1 で導入された、サーバーからクライアントにメッセージの一部のみを送信するプロセスです。バイトサービングは、HTTP サーバーがAccept-Rangesレスポンス ヘッダーを使用して部分リクエストを処理する意思を通知することから始まります。次に、クライアントはRangeリクエスト ヘッダーを使用して、サーバーからファイルの特定の部分を要求します。範囲が有効な場合、サーバーは206 Partial Contentステータス コードと送信範囲をリストしたContent-Rangeヘッダーを使用して、それをクライアントに送信します。範囲が無効な場合、サーバーは416 Requested Range Not Satisfiableステータス コードで応答します。[ 3 ]
バイトサービングを要求するクライアントは、大きなファイルが部分的にしか配信されておらず、特定の範囲でファイルのごく一部しか必要とされない場合にそうする可能性があります。したがって、バイトサービングは帯域幅最適化の方法となります。[ 4 ] HTTP/1.0 標準では、クライアントはドキュメント全体を要求することしかできませんでした。バイトサービングを許可することで、クライアントはリソースの任意の部分を要求することを選択できます。この機能の利点の 1 つは、大きなメディア ファイルが要求され、そのメディア ファイルが適切にフォーマットされている場合、クライアントは関心のあることがわかっているファイルの一部だけを要求できる可能性があることです。これはビデオ ファイルの配信に不可欠です。サーバーにこの機能がない場合、そのサーバーでホストされているビデオは、クライアントがファイル全体をダウンロードするまで再生できない可能性があり、ファイル内のシークが無効になる場合があります。
同様に、PDFファイルはバイト配信用に最適化することができ、現在のページを表示するために必要なデータのみを要求することで、大きなファイルをブラウザで即座に表示できます。[ 5 ] Adobe は、Adobe Acrobatの機能により、ページ単位でのダウンロードに最適化されたオプションの「高速 Web ビュー」構造で PDF ファイルを保存することで、バイト配信の使用を長年支援してきました。[ 5 ]
バイトサービングは、マルチホームクライアントが複数のネットワークインターフェイスを介してリソースを同時にダウンロードするためにも使用できます。 [ 6 ]このようなアプリケーション層のリンクアグリゲーションを実現するには、複数のHTTPセッションが確立され、論理ファイルセグメントがサーバーから共同でダウンロードされ、クライアントで再構成されます。これにより、複数のエンドツーエンドパスを最大限に活用できるため、ダウンロード速度が向上します。
バイトサービングは、数値気象予報モデルによって生成および共有される多変量GRIBデータファイルなどの大規模データセットの比較的小さなサブセットにアクセスするためにも使用されます。WGRIB2などのソフトウェアは、NOAAなどのシステムによって提供される気象予報データから個々のバイト範囲を識別して選択することができます。
チャンク転送エンコーディングの使用はバイトサービングではなく、HTTP/1.1 サーバーがリソース全体を複数の別々の部分 (またはチャンク) に分けて送信する方法です。[ 7 ]これは、サーバーが応答全体のデータ量が正確にわからない場合によく使用され、サーバーは応答をバッファリングしてクライアントに送信する前に正確な長さを決定する必要なく、すぐにクライアントにデータを送信できます。これにより、応答が完了した後に接続を再利用する機能を維持しながら、レイテンシが改善され、メモリ要件が削減されます。バイトサービングとチャンキングは互換性があり、どちらか一方のみで使用しても使用できます。HTTP プロトコルの後のバージョンでは、バイトサービングが引き続きサポートされていますが、[ 8 ]チャンク転送エンコーディングの使用は代替方法に置き換えられています。