スキルアップカレッジ 運ぶ話——TCP と UDP、そして HTTP
レッスン5：運ぶ話——TCP と UDP、そして HTTP
このレッスンで学ぶこと
- TCP と UDP の違いと、それぞれの使いどころを説明できる
- 3 ウェイハンドシェイクの流れを説明できる
- ポート番号の役割を理解する
- HTTP のリクエストとレスポンスの基本構造を理解する
- 主なステータスコードの意味を読み解ける
前回のレッスンでは、パケットがハブ・スイッチ・ルーターを経由して、宛先のサーバーまで運ばれる仕組みを学びました。番地がわかり、届ける経路も整ったところで、残る疑問は「そのパケットが、確実に、正しい相手に届いたかどうかを、どう保証するのか」です。今回は、レッスン 1 で学んだ階層のうち、まだ扱っていなかったトランスポート層とアプリケーション層に焦点を当てます。パケットが「確実に届いたか」をどう保証するか、そして届いたあとに、Web ブラウザとサーバーがどんな会話をしているかを見ていきましょう。
TCP と UDP——確実さと速さ、2 つの流儀
トランスポート層を代表するプロトコルには、TCP と UDP の 2 つがあります。どちらもデータを運ぶ役割を持ちますが、運び方の流儀がまったく異なります。
TCP（Transmission Control Protocol）は、データが確実に、正しい順番で届くことを保証するプロトコルです。送った側は、相手が受け取ったことを確認しながら通信を進め、届いていないデータがあれば再送します。順番が入れ替わって届いたデータも、正しい順序に並べ直してから、上位の層に渡します。その分、確認や再送のやり取りが発生するため、多少のオーバーヘッド（余分な手間）がかかります。
UDP（User Datagram Protocol）は、確認や再送のやり取りを行わず、データを送りっぱなしにするプロトコルです。届いたかどうかの保証はありませんが、その分、余分なやり取りがなく、速く、軽く送り出せます。
| 観点 | TCP | UDP |
|---|---|---|
| 信頼性 | 届いたことを確認し、必要なら再送する | 確認や再送を行わない |
| 順序保証 | 正しい順序に並べ直して渡す | 順序が入れ替わっても、そのまま渡す |
| 速度・軽さ | 確認のやり取りがある分、やや重い | 確認のやり取りがない分、軽い |
| 向いている用途 | Web ページの閲覧、メール、ファイル転送など、抜け漏れが困る通信 | 動画配信、音声通話、ゲームなど、多少の欠落より速さが優先される通信 |
Web ページの閲覧やファイルのダウンロードで、1 文字でも文字化けやデータの欠落があっては困ります。こうした用途には TCP が使われます。一方、動画のライブ配信や音声通話では、多少のコマ落ちや音切れがあっても、止まってしまうよりはましです。こうした用途には UDP が使われます。
💡 ポイント 「TCP は確実さ優先の宅配便、UDP は速さ優先のラジオ放送」と例えると覚えやすくなります。宅配便は届いたかどうかを確認し、届かなければ再配達します。ラジオ放送は、電波が届かなかった瞬間があっても、いちいち再送はせず、そのまま流し続けます。
📝 補足 レッスン 3 で扱った DNS の問い合わせの多くも、実は UDP で行われています。短い問い合わせと応答を、素早くやり取りすることが優先されるためです。
身近な例で、この使い分けを実感してみましょう。オンライン会議の音声や映像は、UDP で送られることが一般的です。回線の状態が不安定なときに、映像がわずかにブロック状に乱れたり、音声が一瞬途切れたりすることがありますが、会議そのものは止まりません。もし音声通話に TCP が使われていたら、パケットが 1 つ届かないたびに再送を待つことになり、リアルタイムの会話が成立しなくなってしまいます。一方、資料のファイルを 1 つダウンロードするときに、途中のデータが 1 バイトでも欠けていたら、ファイルは正しく開けません。だからこそ、ファイル転送には TCP が使われます。
3 ウェイハンドシェイク——TCP が接続を確立する手順
TCP が「確実に届ける」ことを実現している理由の 1 つが、通信を始める前に、送信側と受信側が「これから通信を始めます」という約束を交わす手順です。この手順を 3 ウェイハンドシェイク（three-way handshake）と呼びます。3 回のやり取りで、通信の準備を整えることから、この名前が付いています。
sequenceDiagram
participant C as クライアント
participant S as サーバー
C->>S: SYN：接続を始めたいです
S->>C: SYN／ACK：了解しました、こちらも始めます
C->>S: ACK：了解しました、それでは始めましょう
Note over C,S: ここから実際のデータのやり取りが始まるレッスン 1 で、プロトコルを電話の会話に例えました。3 ウェイハンドシェイクは、まさに電話をかけるときの「もしもし」のやり取りに近い手順です。
- SYN（同期）：クライアントが、サーバーに「接続を始めたい」という信号を送ります
- SYN／ACK（同期・確認応答）：サーバーが、「了解しました、こちらからも接続を始めます」という信号を返します
- ACK（確認応答）：クライアントが、「了解しました、それでは始めましょう」という信号を返します
この 3 回のやり取りが完了して、初めて、実際のデータのやり取りが始まります。電話で「もしもし、聞こえますか」「はい、聞こえます」「では本題に入りましょう」という短いやり取りを経てから会話が始まるのと同じ発想です。UDP には、この手順がありません。いきなり本題のデータを送りつける、電報のような通信方式だとイメージすると対比しやすくなります。
🔰 初学者の方へ SYN や ACK という略語を覚える必要はありません。大事なのは、「TCP は、いきなりデータを送りつけるのではなく、最初に短い挨拶を交わしてから本題に入る」という流儀を持っている、という点です。
通信を終えるときにも、同じように挨拶を交わします。電話を切るときに、いきなり無言で切るのではなく、「では失礼します」「はい、失礼します」というやり取りを経てから切るのと同じで、TCP の通信も、双方が「もう送るデータはありません」という信号を送り合ってから、接続を終了します。始めるときも終えるときも、いきなりではなく、必ず合図を交わす。これが、TCP が信頼性を実現している土台の 1 つです。
ポート番号——同じ機器の中の「窓口番号」
ここまでの説明で、パケットは IP アドレスという番地を頼りに、目的のサーバーまで届くことがわかりました。しかし、1 台のサーバーは、Web ページの提供、メールの受け渡し、ファイルの共有など、複数のサービスを同時に動かしていることが珍しくありません。IP アドレスだけでは、「そのサーバーの中の、どのサービス宛てなのか」までは指定できません。
この、サービスごとの窓口を示す番号が、ポート番号（port number）です。ポート番号は 0 から 65,535 までの範囲の数値で、よく使われるサービスには、あらかじめ決まった番号が割り当てられています。
| ポート番号 | 用途 |
|---|---|
| 80 | HTTP による Web 通信 |
| 443 | HTTPS による、暗号化された Web 通信 |
| 53 | DNS による名前解決の問い合わせ |
例えば、あるサーバーの IP アドレスが「203.0.113.10」だとすると、そのサーバーの Web サービスへの通信は「203.0.113.10 の 80 番窓口宛て」というように、IP アドレスとポート番号の組み合わせで指定されます。マンションの住所に例えると、IP アドレスは建物の住所、ポート番号は部屋番号にあたります。同じ建物（サーバー）の中に、複数の部屋（サービス）があり、それぞれに届け先を分けているイメージです。
📖 もっと詳しく 0 番から 1,023 番までのポート番号は、あらかじめ用途が決められた「ウェルノウンポート」と呼ばれる範囲です。HTTP の 80 番、HTTPS の 443 番も、この範囲に含まれます。
サーバー側のポート番号だけでなく、実は通信を送り出すクライアント側にも、一時的なポート番号が割り当てられています。パソコンが Web サイトにアクセスするとき、宛先は「サーバーの IP アドレスと 443 番ポート」ですが、送信元も「自分の IP アドレスと、そのときだけ使われる一時的なポート番号」の組み合わせになっています。この送信元・宛先それぞれの IP アドレスとポート番号、合わせて 4 つの情報の組み合わせによって、1 台のパソコンで同時にいくつものタブを開いていても、それぞれの通信がどのタブのものかを区別できます。
HTTP のリクエストとレスポンス
TCP のやり取りが確立したあと、Web ブラウザとサーバーのあいだで実際に交わされるのが、HTTP（HyperText Transfer Protocol）という約束事です。HTTP は、アプリケーション層で、Web ページの取得に使われる代表的なプロトコルです。
HTTP のやり取りは、ブラウザからサーバーへの「リクエスト（要求）」と、サーバーからブラウザへの「レスポンス（応答）」の組み合わせで進みます。
GET /docs/page.html HTTP/1.1
Host: www.example.comこのリクエストは、「GET というメソッドで、www.example.com というサーバーの、/docs/page.html というパスの情報がほしい」という要求を表しています。メソッドとは、「取得したい」「送信したい」といった、リクエストの種類を表す言葉です。
| メソッド | 主な用途 |
|---|---|
| GET | ページや画像などの情報を取得する |
| POST | フォームに入力した内容など、データをサーバーへ送信する |
| PUT | サーバー上の情報を、指定した内容に置き換える |
| DELETE | サーバー上の情報を削除する |
Web ページを表示するだけの操作の多くは GET メソッド、フォームに入力した内容を送信する操作の多くは POST メソッドが使われます。1 行目のリクエストラインに続けて、いくつかの「ヘッダー」と呼ばれる付加情報が並びます。先ほどの例にある「Host: www.example.com」は、どのホスト宛てのリクエストかを示すヘッダーです。1 台のサーバーが複数のドメインを受け持っていることもあるため、このヘッダーで宛先のドメインを明示します。
このリクエストに対して、サーバーは次のようなレスポンスを返します。
HTTP/1.1 200 OK
Content-Type: text/htmlレスポンスの先頭にある「200 OK」が、この通信の結果を表す情報です。この数値が、次に説明するステータスコードです。
主なステータスコードの読み方
ステータスコード（status code）は、HTTP のレスポンスの先頭に付けられる、3 桁の数値です。リクエストがどんな結果になったかを、数値の範囲で大まかに分類しています。
| 範囲 | 意味 | 代表例 |
|---|---|---|
| 200 番台 | 成功 | 200：正常に処理できた |
| 300 番台 | 転送・リダイレクト | 301：ページが別の場所に恒久的に移動した |
| 400 番台 | クライアント側の問題 | 401：認証が必要、403：アクセスが許可されていない、404：指定されたページが見つからない |
| 500 番台 | サーバー側の問題 | 500：サーバー内部の異常、503：サーバーが一時的に処理できない状態 |
普段、私たちがブラウザで Web ページを見ているとき、多くは「200」という結果を受け取っており、画面には特にその数値は表示されません。一方、ページが見つからないときに表示される「404 Not Found」のような画面は、多くの方が目にしたことがあるはずです。ステータスコードの範囲を知っておくと、エラー画面が表示されたときに、「自分の指定した場所が間違っているのか（400 番台）」「相手のサーバー側で問題が起きているのか（500 番台）」という、大まかな見当をつけられるようになります。
⚠️ 注意 「404」だけを見て「回線が壊れている」と誤解する方がいますが、404 はサーバーまで通信が届いたうえで、「指定されたページが存在しない」という応答を受け取った状態です。ここまで通信が届いているという意味では、むしろネットワークとしては正常に動作しています。
逆に、画面に何も表示されず、ブラウザが「応答がありません」「読み込み中」のまま止まってしまう状態は、ステータスコードすら受け取れていない可能性を示しています。この場合は、レッスン 3 で扱った名前解決の失敗や、レッスン 4 で扱った経路上の不具合など、もっと手前の層でつまずいていることが疑われます。「エラー画面が出る」ことと「何も表示されないまま止まる」ことは、どちらも「つながらない」という結果は同じでも、疑うべき層がまったく異なります。この見分け方は、レッスン 7 で改めて体系的に整理します。
HTTPS——HTTP に手順が 1 つ挟まる
最後に、URL の先頭でよく見かける「https」について、レッスン 3 で予告した内容に触れておきます。HTTPS（HTTP Secure）は、ここまで説明してきた HTTP のやり取りに、暗号化の手順を 1 つ挟んだものです。
具体的な暗号化の方式や、通信の安全性を保証する仕組みの詳しい中身は、本コースの範囲ではありません。情報セキュリティ関連の入門コースが、その領域を専門に扱っています。本コースで押さえておきたいのは、「https で始まる通信は、http のやり取りの手前に、暗号化のための手順が 1 つ追加されている」という、階層の中での位置づけだけです。TLS（Transport Layer Security）と呼ばれる仕組みが、この暗号化の手順を担っています。
📝 補足 レッスン 1 の階層の図で振り返ると、HTTP も HTTPS も、どちらもアプリケーション層のやり取りです。HTTPS は、HTTP という約束事そのものを置き換えるのではなく、その手前に暗号化の手順を挟み込む、追加のレイヤーだと捉えると理解しやすくなります。
現在の多くの Web ブラウザは、HTTPS ではないサイトにアクセスすると、アドレスバーに注意を促す表示を出すようになっています。これは、暗号化の手順が挟まれていない通信では、途中の経路で内容をのぞき見られたり、書き換えられたりする可能性を、利用者に知らせるための仕組みです。本コースで持ち帰っていただきたいのは、「https で始まっているかどうかで、通信の途中に暗号化の手順が挟まれているかどうかが変わる」という、階層のうえでの位置づけです。暗号化の中身がどう安全性を実現しているかは、情報セキュリティ関連の入門コースで深く学べます。
まとめ
このレッスンでは、以下のことを学びました。
- TCP は確実さを優先し、届いたことを確認しながら通信するプロトコル。UDP は速さを優先し、確認や再送を行わないプロトコル
- 3 ウェイハンドシェイクは、TCP が通信を始める前に交わす、SYN ・SYN／ACK ・ACK という 3 回のやり取り
- ポート番号は、同じサーバーの中の、サービスごとの窓口を示す番号
- HTTP は、ブラウザからのリクエストと、サーバーからのレスポンスの組み合わせで進む
- ステータスコードは、200 番台が成功、400 番台がクライアント側の問題、500 番台がサーバー側の問題を示す
- HTTPS は、HTTP のやり取りに、暗号化の手順を 1 つ挟んだもの
次のレッスンでは、パケットが物理的にどう空間を渡るのか、Wi-Fi や光回線といった「最後の 1 メートル」と、その先に広がる外の世界に進みます。
確認クイズ
このレッスンの理解度をチェックしましょう。