Logo Image

Blog Article

HTTP通信の仕組みについて

00

HTTPとは

HTTP (HyperText Transfer Protocol)は、インターネット上でデータを転送するためのプロトコルの一つです。HTTPは、クライアント (通常はウェブブラウザ)とウェブサーバー間でデータを送受信するための規則や手順を定めています。HTTPはテキストベースのプロトコルであり、主にHTMLページや画像、動画、スタイルシート、JavaScriptファイルなどのウェブリソースを取得および表示するために使用されます。

以下はHTTPの主な特徴と動作原理です。

リクエスト-レスポンスモデル

HTTPはクライアントとサーバーの間でリクエストとレスポンスを交換するモデルを採用しています。クライアントがウェブサーバーに対してリクエストを送信し、サーバーはそのリクエストに対するレスポンスを返します。

プロトコルの状態を保持しない

HTTPは状態を保持しないプロトコルです。これは、各リクエストとレスポンスが互いに関連性を持たず、それぞれが独立して処理されることを意味します。サーバーはクライアントの過去のリクエストやセッション情報を保持しないため、各リクエストはその独自の情報を含む必要があります。

テキストベース

HTTPのリクエストとレスポンスはテキスト形式であり、可読性が高いため、デバッグや監視が比較的容易です。しかし、データの転送にはテキスト形式のため、データの効率的な転送が制約されることもあります。

非安全

HTTPは通信内容を暗号化しないため、データが平文で送信されます。これは通信のセキュリティ上の脆弱性を意味します。特に機密情報を扱うウェブサイトでは、HTTPS（HTTPのセキュア版）を使用することが推奨されます。

ポート80

HTTPのデフォルトポート番号は80です。したがって、HTTPのURLは通常、ポート番号を指定せずに"http"スキームで始まります。

拡張性

HTTPは拡張可能で、新しい機能やヘッダーを追加することが可能です。これにより、ウェブアプリケーションやウェブサービスの開発者は、HTTPをカスタマイズして特定の要件に合わせることができます。

HTTPはウェブブラウジングやウェブサービスの基本的なプロトコルとして非常に重要であり、ほとんどのウェブトラフィックはHTTPによって処理されます。ただし、セキュリティの向上を目的として、多くのウェブサイトはHTTPSに移行し、通信内容を暗号化しセキュリティを強化しています。

HTTPSとは

HTTPS（Hypertext Transfer Protocol Secure）は、通信が暗号化されたセキュアな通信を提供するためのプロトコルです。HTTPSは、HTTPの上位に「TLS（Transport Layer Security）」または「SSL（Secure Sockets Layer）」と呼ばれるプロトコルを使用して、通信の機密性とデータの完全性を保護します。

以下はHTTPSの基本的な仕組みです。

暗号化 (Encryption)

HTTPSは、通信の暗号化を提供します。これにより、第三者が通信を傍受してもデータを理解できなくなります。一般的に、公開鍵暗号化（Public Key Cryptography）と共通鍵暗号化（Symmetric Key Cryptography）の組み合わせが使用されます。

公開鍵と秘密鍵

サーバーは公開鍵と秘密鍵のペアを生成します。公開鍵は一般に公開され、秘密鍵はサーバー内に安全に保存されます。公開鍵暗号化は、公開鍵で暗号化されたデータは秘密鍵でのみ復号できるという特性を利用します。

SSL/TLSハンドシェイク

クライアントがサーバーに接続する際、SSL/TLSハンドシェイクが行われます。このハンドシェイクでは、以下のステップが含まれます。

  • クライアントがサーバーに接続リクエストを送信し、サーバーは公開鍵と証明書を返す。
  • クライアントはサーバーの証明書を検証し、共通の暗号化アルゴリズムと共通鍵を生成する。
  • 共通鍵を使用して通信が暗号化されます。

証明書

サーバーは「SSLサーバー証明書」を使用して、公開鍵を検証することで、利用者はWebサイトを運営する会社の身元を確認することができます。証明書は信頼されたサードパーティから発行され、サーバーの身元確認と通信の暗号化を保証します。一般的にはSSLサーバー証明書は、「認証局（認証機関）」によって署名されます。

暗号アルゴリズム

SSL/TLSでは、様々な暗号アルゴリズムが使用されます。これには、公開鍵暗号化、共通鍵暗号化、ハッシュ関数などが含まれます。HTTPSのセキュリティは、これらのアルゴリズムとプロトコルの組み合わせに依存しています。

HTTPSを使用することで、Webサイトの通信が暗号化され、セキュリティが向上します。特に、個人情報やパスワードなどの重要なデータを送信する際にはHTTPSが重要です。

HTTPメッセージ

HTTP（Hypertext Transfer Protocol）メッセージは、クライアントとサーバー間でデータをやり取りするための通信プロトコルです。

HTTPメッセージは通常、「HTTPリクエスト」と「HTTPレスポンス」の2つの種類があります。HTTPでは基本的に、1つのHTTPリクエストに対して1つのHTTPレスポンスを返します。

HTTPリクエストメッセージの構成

HTTPリクエストメッセージは、クライアントがサーバーに対してリソースの取得やアクションの実行などを要求するために使用されるメッセージです。

以下に、HTTPリクエストメッセージの主要な要素を詳細に説明します。

  1. リクエストライン (Request Line)

    リクエストの始まりで、次のような形式を持ちます。

    Webサーバーに対して、どのような処理を依頼するのかを伝える情報が含まれています。

    例:

    GET /index.html HTTP/1.1
    メソッド/リクエストURI/HTTPバージョン
    • メソッド (Method)

      リクエストの目的を指定します。一般的なメソッドには、GET（データの取得）、POST（データの送信）、PUT（データの更新）、DELETE（データの削除）などがあります。

    • リクエストURI (Uniform Resource Identifier)

      リクエストされたリソースの識別子。通常は絶対パスや相対パスが含まれます。

    • HTTPバージョン

      使用されているHTTPプロトコルのバージョン。一般的にはHTTP/1.1が使われます。

  2. メッセージヘッダー (HTTPヘッダー)

    キーと値のペアで構成され、リクエストに関する追加の情報を提供します。

    一般的なヘッダーには、Host（要求されたリソースのホスト名）、Accept（クライアントがサポートするメディアタイプ）、User-Agent（クライアントの情報）、Content-Type（リクエストの本文のメディアタイプ）などがあります。

    他にもWebブラウザの種類や対応しているデータタイプ、データの圧縮方法、言語などの情報を伝えます。

    例:

    Host: www.example.com
Accept-Language: en-us
  3. 空行 (Blank Line)

    ヘッダーとボディを区切るための空行。ヘッダーが終わり、本文が始まることを示します。

  4. ボディ (Body)

    リクエストの本文。一部のリクエスト（例: GETリクエスト）ではボディが空であることがありますが、POSTリクエストなどではデータが含まれることがあります。

    ボディの内容や形式は、リクエストメソッドや要求された操作によって異なります。

    例:

    key1=value1&key2=value2

以上が、HTTPリクエストメッセージの基本的な構成要素です。これらの要素が組み合わさって、クライアントはサーバーに対して特定のアクションを要求します。

HTTPレスポンスのメッセージ構成

HTTPレスポンスメッセージもHTTPリクエストメッセージと同様に、いくつかの要素から構成されています。以下にHTTPレスポンスメッセージの主要な要素を詳細に説明します。

  1. ステータスライン (Status Line)

    レスポンスの始まりで、次のような形式を持ちます。

    例:

    HTTP/1.1 200 OK
    HTTPバージョン / ステータスコード / 状態テキスト
    • HTTPバージョン

      使用されているHTTPプロトコルのバージョン。通常はHTTP/1.1が使われます。

    • ステータスコード

      レスポンスの結果を示す3桁の数値。例えば、200は成功、404はリソースが見つからない、500はサーバーエラーなどがあります。

    • 状態テキスト

      ステータスコードに対応する状態の説明。人が理解しやすくするためのテキストですが、プログラムが処理する上で重要ではありません。

  2. ヘッダー (Headers)

    キーと値のペアで構成され、レスポンスに関する追加の情報を提供します。

    一般的なヘッダーには、Content-Type（レスポンスの本文のメディアタイプ）、Content-Length（レスポンスの本文の長さ）、Server（サーバーの情報）などがあります。

    例:

    Content-Type: text/html
Content-Length: 127
  3. 空行 (Blank Line)

    ヘッダーとボディを区切るための空行。ヘッダーが終わり、本文が始まることを示します。

  4. ボディ (Body)

    レスポンスの本文。HTML、画像、JSONなど、具体的なコンテンツの種類によって異なります。

    レスポンスの本文は、クライアントに対して要求された情報や操作の結果が含まれます。

    例:

    <!DOCTYPE html>
<html>
<head>
    <title>Example Page</title>
</head>
<body>
    <p>Hello, World!</p>
</body>
</html>

これらがHTTPレスポンスメッセージの基本的な構成要素です。ステータスライン、ヘッダー、空行、ボディが組み合わさって、サーバーはクライアントに対して要求に対する応答を提供します。

HTTPメソッド

HTTPメソッド（またはHTTPリクエストメソッド）は、クライアントがサーバーに対してどのようなアクションを実行するかを指定する手段です。

Webサーバーによっては、制限されているメソッドもありますが、「HEADメソッド」と「GETメソッド」は必須です。

以下に、一般的なHTTPメソッドとそれぞれの主な目的を示します。

HEADメソッド

GETリクエストと同様にリソースのヘッダー情報のみを取得しますが、本文（ボディ）は含まれません。

リソースが存在し、データのサイズや最終更新日時などのメタ情報が欲しい場合に使用されます。

GETメソッド

HTMLファイルや画像といったデータを取得をする際に利用する。リクエストURIに指定されたリソースをサーバーから取得します。

Webサイト閲覧時において使用頻度が高いです。

POSTメソッド

フォームに入力したパスワードといったデータを転送する場合に利用する。データの送信や新しいリソースの作成をリクエストします。

リクエストボディにデータを含めて送信し、サーバーで新しいリソースを作成するのに使用されます。

PUTメソッド

データ（ファイル）をアップロードする場合に利用します。また、リソースの更新または新規作成をリクエストします。

Webサーバー上のファイルを置き換えることができるため、利用できないように制限されている場合が多いです。

リクエストボディに更新されたデータを含め、指定されたURIのリソースを更新します。存在しない場合は新しく作成します。

DELETEメソッド

指定したリソースの削除をリクエストします。また、指定されたURIのリソースを削除します。

PUTメソッド同様に利用できないように制限されていることが多いです。

PATCHメソッド

リソースの部分的な更新をリクエストします。

リクエストボディに変更の適用される部分を含み、指定されたURIのリソースを一部更新します。

OPTIONSメソッド

利用できるHTTPメソッドを問い合わせる場合に利用します。PUTメソッドやDELETEメソッドのように利用を制限されているHTTPメソッドがあるため、サーバーがどのメソッドをサポートしているかなどを確認するために使用されます。

TRACEメソッド

WebブラウザとWebサーバーの経路をチェックする場合に利用します。リクエストをサーバーに送り、サーバーがそれをそのまま返すことで、リクエストがどのように変更されるかを確認します。TRACEメソッドを悪用した攻撃があるため、利用を制限されている場合が多いです。

主にデバッグやトラブルシューティングの目的で使用されます。

CONNECTメソッド

Webサーバーに接続するまでに別のサーバーを中継する場合に利用されます。CONNECTメソッドを悪用した攻撃があるため、利用を制限されている可能性が高いです。

主にHTTPS通信の際にプロキシを経由して別のサーバーにトンネリングするために使用されます。

これらのHTTPメソッドは、クライアントとサーバーの相互作用を定義し、ウェブアプリケーションやAPIなどで様々な操作を実現するために使われます。

「GET」と「POST」の違い

HTTP通信において、GETとPOSTは異なるリクエストメソッド（HTTPメソッド）であり、主にクライアント（通常はWebブラウザ）からサーバーに対して情報を要求したり、データを送信したりするために使用されます。

以下にGETとPOSTの主な違いを示します。

  1. データの転送方法
    • GET

      データはURLのクエリパラメータとして転送されます。データはURLの末尾に続く「?」以降のキーと値のペアとして含まれます。例: http://example.com/resource?name=value

    • POST

      データはHTTPリクエストのボディに格納されます。データは直接リクエスト本文に含まれ、URLには表示されません。

  2. データの長さ制限
    • GET

      URLにデータが含まれるため、URLの制限に従います。一般的には制約があり、大量のデータを送信するのには適していません。

    • POST

      データはHTTPリクエストのボディに含まれるため、理論的にはより大きなデータセットを送信できます。ただし、サーバーやブラウザによる制限もあります。

  3. ブックマーク
    • GET

      URLにデータが含まれるため、ブラウザのブックマークに保存できます。また、リンクをクリックした場合、そのリンクに含まれるデータが直接表示されます。

    • POST

      データがリクエストボディに含まれるため、ブラウザのブックマークに保存することはできません。

  4. キャッシュ
    • GET

      リクエストはブラウザによってキャッシュされやすく、同じリクエストが繰り返された場合、ブラウザはキャッシュからデータを取得することがあります。

    • POST

      リクエストは通常キャッシュされません。毎回新しいデータを送信するため、ブラウザは再度サーバーにリクエストを送信します。

  5. セキュリティ
    • GET

      データがURLに含まれるため、ブラウザのアドレスバーなどで簡単に見える可能性があります。パスワードや個人情報などはGETリクエストに含めるべきではありません。

    • POST

      データはリクエストボディに含まれるため、URLには表示されません。一般的にはセキュアですが、SSL/TLSなどの暗号化がさらにセキュリティを向上させます。

どちらのメソッドを使用するかは、データの転送の性格やセキュリティの要件に依存します。通常、データの要求（GET）とデータの送信（POST）の目的に基づいて選択されます。

「GET」と「POST」の選択基準

使用目的

GETは主にデータの取得に使用され、リクエストがキャッシュ可能で、URLに表示されても問題がないデータに適しています。

POSTはデータの送信や新しいデータの作成、センシティブな情報の送信に適しています。

データ量

GETはURLの制約により、送信できるデータ量に制限があります。一方で、POSTはリクエストボディにデータを含めるため、比較的大きなデータを送信できます。

安全性

セキュリティ上の理由から、センシティブなデータの送信はPOSTが適しています。

ステータスコード

HTTP（Hypertext Transfer Protocol）では、サーバーがクライアントに返すレスポンスの結果を示すために、3桁のステータスコードが使用されます。ステータスコードはリクエストの成功、リダイレクト、クライアントエラー、サーバーエラーなど、様々な状態を表現します。

以下に、いくつかの一般的なステータスコードとその意味を記載します。

1xx (情報)

  • 100 Continue

    クライアントがリクエストを続行できることを示す。ヘッダーが受け入れられ、クライアントはボディを送信することが期待されます。

2xx (成功)

  • 200 OK

    リクエストが成功し、リクエストされた情報がレスポンスに含まれます。

3xx (リダイレクト)

  • 301 Moved Permanently

    リクエストされたリソースが新しい場所に永続的に移動します。ブラウザは次のリクエストから新しい場所を使用します。

  • 302 Found (またはMoved Temporarily)

    リクエストされたリソースが一時的に新しい場所に移動します。ブラウザは次のリクエストから新しい場所を使用します。

  • 304 Not Found

    リクエストされたコンテンツが未更新であることを通知します。Webブラウザに一次保存されたコンテンツが表示されます。

4xx (クライアントエラー)

  • 400 Bad Request

    クライアントのリクエストが不正であるため、サーバーがリクエストを理解できない場合表示されます。

  • 401 Unauthorized

    認証が必要なリソースに対して、クライアントが認証されていない場合表示されます。

  • 403 Forbidden

    クライアントがリソースにアクセスする権限がない場合表示されます。

  • 404 Not Found

    リクエストされたリソースが見つからない場合表示されます。

5xx (サーバーエラー)

  • 500 Internal Server Error

    サーバー内部でエラーが発生し、リクエストが処理できない場合表示されます。

  • 502 Bad Gateway

    ゲートウェイまたはプロキシサーバーが不正な応答を受け取り、サーバーがエラーを返した場合表示されます。

  • 503 Service Unavailable

    サーバーが一時的にダウンしているか、過負荷状態であるため、リクエストを処理できない場合表示されます。

これらは一般的なステータスコードの例であり、HTTPプロトコルには他にも多くのステータスコードが存在します。各ステータスコードは、通信の成功やエラーの詳細な状態をクライアントに伝えるために使われます。

メッセージヘッダー

HTTPメッセージヘッダー（Message Headers）は、HTTPリクエストまたはレスポンス内の情報を伝達するためのメタデータの部分です。メッセージヘッダーを利用することでHTTPメッセージに関する詳細な情報を送信することが出来ます。

ヘッダーはキーと値のペアから構成され、通信の制御、認証、コンテンツの形式、クッキーなど、さまざまな目的で使用されます。

以下は、HTTPヘッダーフィールドの一般的な例です。

一般的ヘッダーフィールド

  • Cache-Control: キャッシュの動作を指定します。
  • Connection: リクエスト後はTCPコネクションを切断など接続状況に関する通知を示します。また、クライアントとサーバーの接続の管理方法を指定します。
  • Date: HTTPメッセージが作成された日時を指定します。
  • Upgrade: HTTPのバージョンをアップデートするように要求します。
  • Cookie: クライアントからサーバーへのクッキーの送信やサーバーからのクッキーの受け取りに使用されます。

リクエストヘッダーフィールドの例

  • Host: リクエスト先のサーバー名を指定します。
  • Referer: 直前にリンクしていた（訪れていた）WebページのURLを指定します。
  • User-Agent: ブラウザやクライアントの固有情報を提供します。（プロダクト名、バージョンなど）
  • Accept: クライアントがサポートするメディアタイプを指定します。

レスポンスヘッダーフィールドの例

  • Location: リダイレクト先のWebページ情報を指定します。
  • Content-Type: レスポンスの本文のメディアタイプと文字エンコーディングを指定します。
  • Content-Length: レスポンス本文の長さを指定します。
  • Server: Webサーバーの種類やバージョンなどの情報を提供します。（プロダクト名、バージョンなど）

エンティティヘッダーフィールド

  • Allow: 利用可能なHTTPメソッドの一覧を指します。
  • Content-Encoding: コンテンツのエンコード（データ変換）方式を指します。
  • Content-Language: コンテンツの使用言語を指します。
  • Content-Length: コンテンツのサイズを指します。単位はバイト（byte）
  • Content-Type: コンテンツの種類（テキスト、画像）などを指します。
  • Expires: コンテンツの有効期限を指します。
  • Last-Modified: コンテンツの最終更新時刻

TCPによるデータ通信

WebブラウザからのHTTPリクエストと、それに対してのWebサーバーからのHTTPレスポンスを繰り返し行うことでWebサイトを閲覧できますが、これらHTTPデータのやりとりを行うのは「TCP (Transmisson Control Protocol)」の役割です。

TCPは、コンピュータネットワークでのデータ通信において、信頼性の高いストリーム指向の通信を提供するプロトコルです。

TCPではまずクライアントとサーバーがお互いに通信ができる状態なのかを確認し、「コネクション」と呼ばれる通信経路を確立した後に、データはクライアントとサーバー間で信頼性のあるストリームとして転送されます。データはシーケンス番号と確認応答番号を使用してセグメントに分割され、それぞれが相手に届いたかどうかが確認されます。

このコネクションの確立は、次の3回のやりとりにより行われます。

  1. クライアントがサーバーに接続要求を送信 (SYN)

    クライアントがサーバーに接続を要求するとき、クライアントは「SYNパケット」をサーバーに送信します。これは通常、TCPヘッダーの中でフラグフィールドの一部です。SYNパケットを受け取ったサーバーは、それに対して応答します。

  2. サーバーが接続要求を受信し、応答 (SYN-ACK) を返信

    TCPでは信頼性のある通信を実現するために、データを送信した後、必ず送信相手からの確認応答を受け取ってデータの送信が完了したと判断します。この確認応答が「ACKパケット」です。

    クライアントからの接続要求に対してサーバーがACKパケットを送信することで、接続可能であることを伝えます。また、サーバーはACKパケットを送信するのと同時に、サーバー自身の接続要求としてSYNフラグがセットされたSYNパケットを送信します。これを「SYN-ACKパケット」と言います。

  3. クライアントがサーバーの応答を確認 (ACK)

    クライアントはサーバーからのSYN-ACKパケットを受信すると、これを確認するために「ACKパケット」をサーバーに返信します。これにより、双方向で通信可能なことを確認して、コネクションの確立が完了します。

この手順は通常、「Three-Way Handshake」と呼ばれ、クライアントとサーバーの間で確実な通信の開始を保証します。この接続の確立後、クライアントとサーバーはデータの送受信を開始し、通信が終了するまでデータのやり取りが可能です。

HTTP / 1.1のやりとり

HTTPキープアライブとは

HTTPキープアライブ（HTTP Keep-Alive）は、HTTPプロトコルにおいて、単一のTCP接続を使用して複数のHTTPリクエストおよびレスポンスをやり取りする仕組みを指します。通常、クライアントがサーバーにリクエストを送信し、サーバーがレスポンスを返すと、接続が閉じられます。しかし、HTTPキープアライブを使用すると、同一のTCP接続を再利用して複数のリクエストやレスポンスを行うことができます。

HTTPパイプラインとは

HTTPパイプライン（HTTP Pipelining）は、HTTPプロトコルにおいて、複数のリクエストを一つのTCP接続で並行して送信し、サーバーからのレスポンスも同様に一つのTCP接続で非同期に受け取る仕組みです。通常、クライアントがサーバーに複数のリクエストを送信し、サーバーがその順序通りにレスポンスを返すまで待つ代わりに、HTTPパイプラインではリクエストが非同期に送信され、レスポンスも非同期に受信されます。

HTTPパイプラインの主な特徴と利点は以下の通りです。

  1. 並列処理

    複数のリクエストを同時に送信できるため、通信の効率が向上します。これにより、通信の待ち時間が減少し、パフォーマンスが向上します。

  2. TCP接続の再利用

    パイプラインが有効な接続では、同一のTCP接続を再利用して複数のリクエストおよびレスポンスを処理できるため、接続の確立や切断に伴うオーバーヘッドが減少します。

  3. リソースの効率的な利用

    パイプラインを使用することで、サーバーとクライアントのリソースがより効率的に利用されます。

HTTP / 2のやりとり

ストリームとは

HTTPパイプラインではHTTPリクエストを順番どおりにレスポンスしなければならないという制約があり、1つのHTTPレスポンス処理に時間がかかると、それ以降のHTTPレスポンスはその処理が終わるまで待つ必要があります。この問題を解決するためにHTTP/2では「ストリーム」という仮想的な通信経路を複数生成し、ストリーム上でHTTPリクエストとHTTPレスポンスのやりとりを可能にしています。

HTTP/2のストリーム（Stream）は、複数の並行した双方向通信チャネルを指します。HTTP/2は、単一のTCP接続上で複数のストリームを同時に処理することができるマルチプレキシングをサポートしています。これにより、一つの接続を通じて同時に多くのデータをやり取りでき、通信の効率が向上します。

HTTP/2のストリームは、ウェブページの複数のリソース（例: CSS、JavaScript、画像）を同時に取得する際や、ウェブアプリケーションにおいて複数のデータストリームを同時に処理する場合などに利用されます。これにより、従来のHTTP/1.xよりもウェブのパフォーマンスが向上し、効率的な通信が実現されます。

HTTPパイプラインとストリームは、どちらも複数リクエストを送信できることに変わりありません。しかし、HTTPパイプラインは順番通りにレスポンスする制約があるため、処理に時間がかかった際に待ち時間が発生します。

バイナリ形式の利用

バイナリ形式は、コンピュータがデータを表現するための形式の一つであり、テキスト形式とは対照的です。バイナリ形式では、データは0と1のビットの組み合わせで表現されます。

バイナリ形式を採用することで、変換処理にかかる時間と、ブラウザやサーバーへの負担を軽減できます。

以下は、バイナリ形式とテキスト形式の主な違いです。

データ表現

  • バイナリ形式

    データは2進数で表現され、コンピュータが直接理解できる形式です。バイナリ形式では、ビットやバイトなどが組み合わさって数値や文字、画像、音声などが表現されます。

  • テキスト形式

    データは通常、人間が読み書きしやすい形式で表現されます。ASCIIやUnicodeなどの文字コードを使用し、テキストエディタなどで直接編集できる形式です。

拡張性

  • バイナリ形式

    バイナリ形式は効率的であり、データをコンパクトに表現できるため、通常は効率的なデータ転送やストレージに向いています。しかし、人間が直接読み書きするのは難しいことがあります。

  • テキスト形式

    テキスト形式は人間が理解しやすい反面、データが増えると容量が大きくなりやすい傾向があります。

可読性

  • バイナリ形式

    直接的な意味がなく、一般の人が理解するのは難しいです。通常は専用のプログラムやツールが必要です。

  • テキスト形式

    人間が理解しやすく、エディタやテキスト処理ツールで簡単に編集できます。

用途

  • バイナリ形式

    画像、音声、ビデオ、実行可能ファイルなど、コンピュータが直接扱う多くのデータ形式がバイナリ形式で表現されます。

  • テキスト形式

    プログラムのソースコード、設定ファイル、文書、メッセージなど、人間が読み書きするデータがテキスト形式で表現されることが一般的です。

バイナリ形式は効率的であり、特に構造が複雑なデータを表現する際に重要ですが、可読性の点ではテキスト形式が優れていることがあります。どちらを使用するかは、データの性質や使用目的によります。

ヘッダーコンプレッション

HTTP/2では、ヘッダーの圧縮が導入されています。これにより、以前のHTTP/1.1では発生していたヘッダーの冗長な転送を削減し、通信効率を向上させます。ヘッダーは静的なもの（一般的によく使用されるヘッダー）と動的なもの（特定のストリームに関連するヘッダー）に分類され、適切に圧縮されます。

HTTP/2ではヘッダー情報の中から差分だけを送る「HPACK」と呼ばれる圧縮方式を利用することで、データ転送を削減できます。

サーバープッシュ

サーバープッシュ（Server Push）は、HTTP/2プロトコルで導入された機能の一つであり、ウェブページのパフォーマンス向上を目的としています。通常、ウェブページはクライアント（ブラウザ）がリクエストを送信してサーバーが応答するというリクエスト-レスポンスモデルに基づいていますが、サーバープッシュではサーバーがクライアントに対して必要なリソースを積極的にプッシュすることができます。

サーバープッシュは、特にウェブページの初回読み込み時や、必要なリソースを予測してプッシュすることで通信の待ち時間を削減し、ページの読み込み速度を向上させることが期待されます。ただし、適切な使用が求められ、無駄なリソースをプッシュしてしまうことが逆効果になる可能性もあります。

カテゴリ

目次