第3章HTTP情報HTTPメッセージ

3886 ワード
Multipart MIME range request テキストリンク
これはHttp&Network Basicの本で、内容は図のようになっています.

1.HTTPメッセージ

  • HTTPで交換される情報をHTTPメッセージと呼ぶ.
  • 要求側HTTPメッセージを要求側HTTPメッセージと呼び、応答側HTTPメッセージをResponseメッセージと呼ぶ.
  • HTTPメッセージは、複数行のデータからなるテキスト文字列である.
  • HTTPメッセージは、大きく分けてメッセージヘッダ、メッセージボディとなる.
  • 先頭の書き換え文字で、タイトルと本体を区別します.
  • 本体は常に存在しない.

    • 2.要求メッセージと応答メッセージの構成

  • 要求ライン:要求のための方法と要求URI、HTTPバージョン
    • 用
  • ステータスライン:応答結果を示すステータスコードと説明;使用するHTTPバージョン
  • ヘッダーフィールド:要求と応答の様々な条件と属性を表す様々なヘッダーフィールドの一般ヘッダーフィールド、要求ヘッダーフィールド、応答ヘッダーフィールド、エンティティヘッダーフィールドの4種類.

    • 3.符号化による伝送効率の向上

  • HTTPにデータを転送する場合は、そのようにしてもよいが、符号化により伝送効率を向上させることができる.
  • の送信時に符号化を行い、大量アクセスを効率的に処理することができる.
  • コンピュータ上で符号化する必要があるため、CPUなどのリソースはより多く消費される.
  • メッセージ・ボディとエンティティ・ボディの違い
  • メッセージ:HTTP通信の基本単位は、8ビット八重ビットシーケンス(Octet sequence)の通信により伝送される.
  • エンティティ:要求と応答に送信されるペイロードの情報.エンティティヘッダーフィールドとエンティティエンティティエンティティエンティティから構成されます.
  • HTTPメッセージ本体の役割は、要求および応答を送信する関連エンティティ本体である.
  • のデフォルトでは、メッセージ本体とエンティティ本体は同じですが、トランスポート符号化が適用されると、エンティティ本体の内容が変化するため、メッセージ本体とは異なります.
  • 圧縮後に送信されるコンテンツ符号化
  • メールにファイルを添付するとzipを圧縮して容量を減らします.
  • HTTPは同様のコンテンツ符号化機能を有する.
  • コンテンツ符号化とは、エンティティ情報を保持したまま圧縮されるエンティティに適用される符号化を意味する.
  • コンテンツ符号化エンティティは、受信クライアントによって復号される.
  • の代表的なものはgzip、compress、deflate、identityである.
  • パケット送信符号化
  • HTTP通信では、要求されたリソース上でエンティティ本体の転送が完了していなければブラウザに表示されない.
  • サイズの大きなデータを転送する場合、データを少し分割して表示することができます.
  • のようにシンボル本体を分割する機能をブロック伝送符号化と呼ぶ.
  • ブロック伝送符号化は、シンボル本体をブロックに分解する.
  • ブロックサイズを16進数表示段落として使用し、エンティティボディは最後に0を記録します.
  • ブロック伝送符号化エンティティ本体は、受信クライアントによって元のエンティティ本体に復号される.

    • 4.複数のデータを送信する複数の部分

  • メールの場合は、メール本文または複数の添付ファイルを貼り付けて一緒に送信できます.
  • は多目的ネットワークメール拡張(MIME)と呼ばれ、テキスト、ビデオ、画像などの異なるデータをメールで処理する機能を使用する.
  • MIMEは、画像等のバイナリデータをAski文字列に符号化する方法や、データ型を表す方法等を規定している.
  • MIMEの拡張仕様は、複数の部分と呼ばれる複数の異なるタイプのデータを使用しています.
  • HTTPも複数の部分に対応しており、1つのメッセージ本体で複数のエンティティを送信することができる.
  • は主に画像やテキストファイルなどのアップロードに用いられる.
  • multipart/form-data
  • Webフォームからファイルをアップロードするための
  • multipart/byteranges
  • ステータスコード206は、メッセージが複数の範囲のコンテンツを含むことに応答する
    • を用いる.
  • HTTPメッセージは、複数のセクションを使用するときにコンテンツタイプヘッダフィールドを使用します.

    • 5.リモートオンデマンドの一部のみ受信

  • 現在のように,ユーザがブロードバンドネットワークを利用できるようになるまで,大容量データのダウンロードは困難である.
  • のダウンロードでは、接続が中断した場合、最初から再ダウンロードしなければならないからです.
  • この問題を解決するために、従来の再生機能が要求される.
  • 経由で、以前ダウンロードした場所から再ダウンロードできます.
  • 機能を実現するには、エンティティの範囲を指定してダウンロードする必要があります.
  • のように指定された範囲の要求をリモート要求と呼ぶ.
  • 電子レンジ要求が使用される場合、10,000バイトサイズのリソース全体において500~10,000バイトの範囲しか要求されない.
  • リクエストの場合、Range Headerフィールドを使用してリソースのバイト範囲を指定できます.
    • - 5001 ~ 10000바이트
Range: bytes = 5001-1000

- 5001 바이트 이상
Range: bytes = 5001-

- 처음부터 3000바이트, 그리고 5000~7000 바이트 복수범위
Range: bytes = -3000, 5000-7000
  • リクエストの場合、返信206.
  • マルチレンジのリモートリクエスト応答は、マルチセクション/byteranges応答を返します.
  • サーバがリモート要求を提供しない場合、200 OKの完全なエンティティが返されます.

    • 6.最適な内容の内容説明を提供する

  • のような内容ですが、複数のページを持つページも存在します.
  • は内容は同じだが、英語版と韓国版では言語が異なる.
  • このようなウェブページはURIにアクセスする際にそれぞれ英語版ウェブページと韓国語版ウェブページを表示する.
  • と同様の構造をコンテンツ宣言と呼ぶ.
  • コンテンツ宣言は、クライアントとサーバが提供するリソースのコンテンツについて協議するものである.
    • これは、
  • クライアントにより適切なリソースを提供するためです.
  • コンテンツ説明は、提供されるリソースを、言語および文字セット、符号化方式等に基づいて判断する.
  • 判定基準は、要求メッセージに含まれる以下の要求ヘッダフィールドである.
  • Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Language
  • サーバドライバの宣言(サーバドライバの交渉)
    -サーバ側のプレゼンテーション
    -要求ヘッダフィールド情報をサーバ側で参照して自動的に処理します.
    -ブラウザから送信された情報を根拠にしているので、ユーザーに適しているとは言えません.
  • エージェント駆動のネットワーク試験
    -クライアント側の宣言方法
    -ブラウザに表示されるオプションで、ユーザーが手動で選択します.
    -Javascriptなどを使ってWeb上で自動的に特定する場合もあります.
  • Transparent Negotiation
    これは
  • サーバドライバとエージェントドライバの混合です.
  • サーバとクライアントは、それぞれコンテンツのパブリッシュを行います.
    • Python 3共通モジュールのインストール
    Javaでresourcesに配置したテキストファイルがjar化すると読み込めません