【図解HTTP・HTTPS】Web閲覧時の通信フローについて【YouTube解説動画あり】

Webを閲覧する際にどのような流れで通信が行われているかについてご紹介します。
通常のルータでインターネットを閲覧を行う際はもちろんのこと、
最近ではSD-WANルータやファイアウォールでは、
Web通信（HTTP・HTTPS）の識別を行いますので、
検証内容にHTTP・HTTPS通信が盛り込まれることも多いのではないでしょうか。

HTTP・HTTPSの通信フローを理解することで、
検証効率化やトラブルシューティングなどに役立てることができますので、
正しく理解していきましょう。

構成図
HTTPの通信フロー
HTTPSの通信フロー
トラブルの原因例
まとめ
YouTube解説動画

構成図

検証で用いた構成図は簡易的なものになります。

HTTPの通信フロー

HTTPはWeb閲覧の際に用いられるプロトコルです。
TCPでポート番号は80番です。
かなりよく用いられるプロトコルですので、
ポート番号から通信フローまで理解しておきましょう。

プロトコル名	TCP/UDP	ポート番号
HTTP	TCP	80

HTTPでWebを閲覧する際にどのような順番で何が行われているかをご紹介してきます。

ブラウザにURLを入力
DNSサーバへ問い合わせ
DNSサーバからの返答で宛先IPアドレスがわかる
Webサーバと3wayハンドシェイク
GETリクエストとレスポンス
ブラウザに表示される

図解するとこのようになります。

実際のパケットキャプチャはこのようになります。

それでは順番にフローを追っていきます。

①：ブラウザにURLを入力

ブラウザにURLを入力とだけ記載していますが、
実際はお気に入りをクリックすることや、リンクをクリックすることなども含まれます。

②：DNSサーバへ問い合わせ

PCは”http://yahoo.co.jp”、いわゆるURLの状態では通信をすることができません。
通信を行うためにはURLのドメイン部分”yahoo.co.jp”に対応する、
通信先（宛先IPアドレス）を知る必要があります。

PCはDNSサーバに対して、
“yahoo.co.jp”に対応するIPアドレスを教えてという問い合わせを行います。

③：DNSサーバからの返答で宛先IPアドレスがわかる

DNSサーバにPCからの要求に対して、
ドメイン”yahoo.co.jp”の通信先（宛先IPアドレス）を回答します。

④：Webサーバと3wayハンドシェイク

DNSサーバからの回答でPCは通信先（宛先IPアドレス）がわかりましたので、
Webサーバに対して通信を開始しますが、TCP通信の場合は、
実際の通信を開始する前に、
まずは3wayハンドシェイクでコネクションの確立を行います。

SYN、SYN+ACK、ACKの3回通信が行われるため、
3wayハンドシェイクと呼びます。
応用情報やネットワークスペシャリストの午前問題でもよく出題されています。

⑤：GETリクエストとレスポンス

クライアント（PC）からWebページを閲覧したいという要求（GETリクエスト）を行います。
その要求を受け取ったWebサーバはそれに対応する返答（レスポンス）を行います。
このレスポンスの中にWebサーバのページの情報（データ）が含まれています。

図では簡略化のため1つの要求に対して、1つの返答しか記載していませんが、
実際の通信では、
画像や広告などを表示させるためにクライアントから何回も要求を行ったり、
画像や動画など容量の多い情報を返答するために、
サーバから何回も返答を行ったりもします。
一般的にはクライアントのGETリクエストよりも、
サーバのレスポンスの方が多く通信量を使用します。

⑥：ブラウザ上に表示される

Webサーバからのレスポンスをすべて受信して、ようやくブラウザ上に表示されます。
クリックして1秒も立たずにブラウザ上に表示されますが、
実際にはこれだけの通信が行われています。

HTTPSの通信フロー

HTTPの通信は暗号化されていませんので、
他人の通信を盗聴することで、
そのサイトへログインするためのID・パスワードを盗まれてしまう可能性があります。
そこで使われるようになったのがHTTPを暗号化したHTTPSです。
現在ではID・パスワードを用いないサイトでも、
多くのサイトでHTTPSが用いられるようになっています。
閲覧頂いている本サイトもHTTPSを使用して閲覧頂いているかと思います。

HTTPSもHTTP同様かなりよく用いられるプロトコルですので、
ポート番号から通信フローまで理解しておきましょう。

プロトコル名	TCP/UDP	ポート番号
HTTPS	TCP	443

ブラウザにURLを入力
DNSサーバへ問い合わせ
DNSサーバからの返答で宛先IPアドレスがわかる
Webサーバと3wayハンドシェイク
TLSハンドシェイク
GETリクエストとレスポンス（暗号化）
ブラウザに表示される

①～④まではHTTPの通信と同様です。
⑤TLSハンドシェイクからがHTTPの通信フローと異なる点です。

図解するとこのようになります。

実際のパケットキャプチャではこのようになります。

注意：証明書エラーの関係でRSTパケットが生じていますので無視してください。

HTTP通信と異なる⑤TLSハンドシェイクから追っていきます。

⑤TLSハンドシェイク

クライアントとサーバ間でどのように暗号化するかを決め、
実際に暗号化まで行うTLSのハンドシェイクを行います。

細かいシーケンスについては別途触れたいと思いますので、
本記事では行われているんだというところまでご理解ください。

⑥GETリクエストとレスポンス（暗号化）

その後はHTTPと同じようにGETリクエスト、レスポンスを行いますが、
この通信は暗号化されています。
パケットキャプチャなどで確認すると暗号化されていますので、
クライアントとWebサーバ以外は通信内容を確認することができません。
つまり、IDやパスワードなどの情報は他の人が確認することができません。

⑦ブラウザ上に表示される

HTTPと同じようにサーバからのレスポンスをすべて受信すれば、
ブラウザ上などに表示されます。

クライアント、Webサーバでは暗号化されたデータの復号化を行いますので、
クライアントからのリクエスト内容はWebサーバへきちんと伝わり、
サーバからのレスポンスを受信したデータを、
クライアントはブラウザなどにきちんと表示させることができます。

トラブルの原因例

Web通信に失敗する際に、よくあるトラブルの原因例をご紹介します。

DNSの名前解決に失敗している
ファイアウォールの穴あけ
NAT・NAPT

実際にパケットキャプチャを行うことで、
通信フローのどこまで行うことができているのかなどを確認することができます。

DNSの名前解決に失敗している

HTTP・HTTPS通信にDNSの名前解決は不可欠です。
WindowsでもMac、Linuxでも、
“ping yahoo.co.jp”を行うことでで、名前解決を行うことができるか、
インターネットへの疎通性があるかを同時に確認することができます。
もちろん宛先は”google.com”でも何でも構いません。

“ping yahoo.co.jp”には失敗するが”ping 8.8.8.8″には成功する場合は、
まさにDNSの名前解決に失敗しています。

DNSの名前解決に失敗している場合は、
DNSの設定漏れやDNSサーバまでの経路、DNSサーバ自体の障害などが考えられます。