HTTP/HTTPS：その概要、データ転送プロトコルとTLS暗号化

HTTPとHTTPSとは？

HTTP（HyperText Transfer Protocol）は、World Wide Web上でハイパーテキストドキュメントやその他のデータを転送するために設計されたOSIモデルのアプリケーション層プロトコルです。1989年にTim Berners-Leeによって開発されたHTTPは、HTTP/0.9（GETリクエストとHTMLレスポンスのみ）から最新のHTTP/2やHTTP/3まで、いくつかのバージョンを経てきました。このプロトコルはリクエスト-レスポンスモデルで動作します。クライアントがサーバーにリクエストを送信し、サーバーがそれを処理してレスポンスを返します。

HTTPS（HTTP Secure）は、TLS（Transport Layer Security）による暗号化層を追加するHTTPプロトコルの拡張です。HTTPSは独立したプロトコルではなく、HTTPとTLSの組み合わせです。HTTPSを介して送信されるデータはクライアント側で暗号化され、サーバーで復号化されるため、傍受や改ざんが不可能になります。HTTPSはまた、SSL/TLS証明書によるサーバー認証を提供し、クライアントが攻撃者ではなく実際のサーバーに接続していることを保証します。

HTTPとHTTPSの主な違いはセキュリティです。HTTPはデータを平文で送信するため、クライアントとサーバー間のネットワークノードはリクエストやレスポンスの内容を読むことができます。HTTPSはURL、ヘッダー、リクエストボディを含むすべてのコンテンツを暗号化し、サーバーのIPアドレスと接続ポートのみを可視化します。公共Wi-Fiネットワークを介して動作するモバイルアプリケーションにとって、HTTPSは必須のセキュリティ要件です。

HTTPの仕組み

HTTPはTCP/IP上で動作するステートレスプロトコルです。クライアントはサーバーとのTCP接続を確立し（通常HTTPはポート80、HTTPSはポート443）、HTTPリクエストを送信し、HTTPレスポンスを受信して接続を閉じます（HTTP/1.1では接続を再利用できます）。クライアントとサーバー間の各やり取りは、リクエストとレスポンスで構成されます。ステートレスであることは、サーバーが以前のクライアントリクエストに関する情報を保存しないことを意味し、各リクエストは独立して処理されます。

HTTPのやり取りのプロセスには以下の手順が含まれます：

• DNS解決 — ブラウザまたはクライアントがDNSを介してドメイン名をIPアドレスに変換
• TCPハンドシェイク — 3ウェイハンドシェイク（SYN、SYN-ACK、ACK）でTCP接続を確立
• TLSハンドシェイク — HTTPSの場合、暗号化接続を追加で確立（証明書と鍵の交換）
• HTTPリクエスト — クライアントがメソッド、URL、ヘッダー、オプションでリクエストボディを送信
• HTTPレスポンス — サーバーがステータスコード、ヘッダー、レスポンスボディを返す

HTTPの重要な特性はメソッドの冪等性です。GET、HEAD、PUT、DELETE、OPTIONSは冪等です。同じリクエストを繰り返し実行しても、最初の実行後のサーバーの状態は変わりません。POST、PATCH、CONNECTは冪等ではなく、呼び出すたびに新しいリソースを作成したり状態を変更したりする可能性があります。モバイル開発において冪等性の理解は重要です。ネットワークエラーでリクエストを再送する際、クライアントはリクエストを再試行しても安全かどうかを知る必要があります。

HTTPSとTLS暗号化

HTTPSは、送信データを保護するために暗号プロトコルTLS（Transport Layer Security）を使用します。TLSは、1995年にNetscapeによって開発されたSSL（Secure Sockets Layer）の後継です。SSL 2.0および3.0は時代遅れで安全でないと見なされており、最新のTLS 1.2（2008年リリース）とTLS 1.3（2018年リリース）が広く使用されています。特にTLS 1.3は、接続確立時間を2ラウンドトリップから1に削減し、モバイルデバイスでの読み込みを大幅に高速化します。

TLSハンドシェイクプロセスには以下の段階が含まれます：

• Client Hello — クライアントがサポートするTLSバージョンと暗号スイートのリストを送信
• Server Hello — サーバーがTLSバージョンと暗号スイートを選択し、SSL/TLS証明書を送信
• 証明書の検証 — クライアントがルートCAまでの信頼チェーンを通じてサーバーの証明書を検証
• 鍵交換 — クライアントとサーバーが共有秘密鍵（セッション鍵）を生成
• 暗号スイッチ — 両側が暗号化通信への切り替えを確認

SSL/TLS証明書の検証はセキュリティ上重要な段階です。クライアントは証明書が有効期限切れでないこと、信頼できる認証局（CA）によって署名されていること、URLのドメインと一致すること、失効していないこと（CRLまたはOCSP経由）を確認します。モバイルアプリケーションでは、証明書ピンニング（Certificate Pinning）の使用が推奨されます。これは特定のサーバー証明書または公開鍵にバインドするものです。これにより、CAが侵害された場合でもMITM攻撃を防ぐことができます。ただし、ピンニングには注意が必要です。証明書が変更された場合、アプリケーションを事前に更新する必要があります。

HTTPリクエストとレスポンスの構造

HTTPリクエストは、リクエストライン、ヘッダー、オプションのボディの3つの部分で構成されます。リクエストラインにはHTTPメソッド、リクエストURL、HTTPバージョンが含まれます。ヘッダーはメタ情報（コンテンツタイプ、認証トークン、キャッシュ設定）を伝達します。ボディはデータを送信するメソッド（POST、PUT、PATCH）にのみ存在し、GETやDELETEにはありません。

REST APIへのHTTPリクエストの例：

POST /api/v1/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
Cache-Control: no-cache

{
    "name": "アンナ",
    "email": "anna@example.com"
}

HTTPレスポンスも同様の構造を持ちます。HTTPバージョンとステータスコードを含むステータスライン、ヘッダー、ボディです。ステータスコードはリクエスト処理の結果を決定する3桁の数字です。レスポンスヘッダーにはContent-Type、Content-Length、Cache-Control、Set-Cookieなどが含まれます。レスポンスボディには、Content-Typeで指定された形式（通常APIの場合はJSON、Webページの場合はHTML、メディアコンテンツの場合は画像）のリクエストデータが含まれます。

ヘッダーはHTTPの動作において重要な役割を果たします。Content-TypeとAcceptはデータ形式を制御します。Authorizationはアクセストークンを伝達します。Cache-Controlはキャッシュを管理します。CORSヘッダー（Access-Control-Allow-Origin）はブラウザでの他ドメインからのアクセスを制御します。User-Agentはクライアントアプリケーションを識別します。モバイルアプリケーションにとって、キャッシュ制御ヘッダーは特に重要です。送信データ量を削減し、弱い信号でのパフォーマンスを向上させるのに役立ちます。

HTTPステータスコード

HTTPステータスコードは、最初の桁で示される5つのクラスに分類されます：1xx（情報）、2xx（成功）、3xx（リダイレクト）、4xx（クライアントエラー）、5xx（サーバーエラー）。これらのコードを理解することは、モバイルアプリケーションでレスポンスを適切に処理するために必要です。2xxは成功を意味しデータを表示できます。4xxはリクエストに問題があることを示し（ユーザーにエラーを表示）、5xxはサーバーに問題があることを示します（後でリクエストを再試行）。

モバイルアプリケーションでは、401 Unauthorizedコードの処理が特に重要です。このコードを受信した場合、クライアントはリフレッシュトークンを使用してアクセストークンを更新し、元のリクエストを再試行する必要があります。トークン更新でも401が返される場合、ユーザーをログイン画面にリダイレクトする必要があります。このロジックは通常、インターセプター（OkHttp）またはネットワーククライアントのミドルウェア層で実装されます。

HTTP/1.1、HTTP/2、HTTP/3

HTTP/1.1は1999年に公開され、今でも広く使用されているプロトコルバージョンです。その主な欠点はヘッドオブラインブロッキングです。同じサーバーへのリクエストは順次実行され、各リクエストは前のリクエストの完了を待ちます。この制限を回避するために、ブラウザは同じドメインに対して6〜8の並列TCP接続を開き、サーバーの負荷とメモリ消費を増加させます。HTTP/1.1はまた、ヘッダーを平文で送信し、サーバープッシュをサポートしていません。

HTTP/2（2015年）は多重化によってブロッキング問題を解決します。複数のデータストリームが単一のTCP接続で同時に送信されます。サーバーはクライアントがリクエストする前にリソースを送信できます（サーバープッシュ）。HTTP/2はまた、HPACKを使用してヘッダーを圧縮し、送信データ量を削減します。モバイルアプリケーションにとって、HTTP/2は特に有用です。1つの接続が複数の接続を置き換え、TLSハンドシェイク時間とバッテリー消費を削減します。

HTTP/3（2022年）はプロトコルの最新バージョンで、TCPの代わりにQUIC（Quick UDP Internet Connections）を使用します。QUICはUDP上で動作し、トランスポートプロトコルレベルでのヘッドオブラインブロッキング問題を排除します。HTTP/3は接続確立時間を最良の場合で0ラウンドトリップ（再接続時）、初回接続で1ラウンドトリップに削減し、2〜3ラウンドトリップのHTTP/2よりも大幅に高速です。モバイルデバイスにとって、HTTP/3はWi-Fiとモバイルネットワークの切り替え時に特に効果的です。QUICはIPアドレスではなく接続識別子を使用するため、接続が切断されません。

モバイル開発におけるHTTPS

モバイルアプリケーションでのHTTPSの使用は推奨ではなく必須要件です。Android 9（API 28）およびiOS 9（ATS — App Transport Security）以降、すべてのネットワークリクエストはデフォルトでHTTPSを使用する必要があります。HTTPリクエストはシステムによってブロックされ、許可するにはアプリケーション設定で明示的な例外が必要です。Google PlayストアとApp Storeは、パスワード、トークン、個人データを含む機密データをHTTPで送信するアプリケーションを拒否します。

AndroidモバイルアプリケーションでのHTTPS設定には以下が含まれます：

<!-- AndroidManifest.xml — ネットワークリクエストの許可 -->
<uses-permission android:name="android.permission.INTERNET" />

<!-- network_security_config.xml — HTTPS設定 -->
<?xml version="1.0" encoding="utf-8"?>
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">rDjsFv3bGf...</pin>
        </pin-set>
    </domain-config>
</network-security-config>

iOSでは、同様の設定がNSAppTransportSecurityキーを使用してInfo.plistで行われます。モバイルアプリケーションでのHTTPSトラフィックのデバッグには、プロキシツール（Charles Proxy、Proxyman、mitmproxy）が使用されます。これらはデバイスに信頼できるSSL証明書をインストールする必要があります。本番ビルドでは、デバッグ機能を無効にし、証明書ピンニングが正しく設定されていることを確認する必要があります。AndroidでのCertificatePinnerを使用したOkHttpや、iOSでのSecTrustEvaluateを使用したTrustManagerは、ピンニングを実装する標準的なアプローチです。

モバイル開発におけるHTTPSの重要なセキュリティ側面はSSLピンニングです。ピンニングがない場合、アプリケーションは既知のCAによって署名された任意の証明書を信頼します。CAが侵害された場合、攻撃者はアプリケーションのトラフィックを傍受する可能性があります。ピンニングはアプリケーションを特定のサーバー証明書または公開鍵にバインドします。サーバー証明書が変更された場合、アプリケーションの更新をリリースする必要があるため、ピンニングは余裕を持って計画されます。上位CA証明書へのバインドや、複数のバックアップ鍵の使用などが行われます。