IT セキュリティ ネットワーク

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

投稿日:2021年6月20日 更新日:

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

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

構成図

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

HTTPの通信フロー

HTTPはWeb閲覧の際に用いられるプロトコルです。
TCPでポート番号は80番です。

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

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

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

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

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

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

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

①:ブラウザに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
  1. ブラウザにURLを入力
  2. DNSサーバへ問い合わせ
  3. DNSサーバからの返答で宛先IPアドレスがわかる
  4. Webサーバと3wayハンドシェイク
  5. TLSハンドシェイク
  6. GETリクエストとレスポンス(暗号化)
  7. ブラウザに表示される

①~④までは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サーバ自体の障害などが考えられます。

ファイアウォールの穴あけ

上位にファイアウォールやルータなどでACLを設定している場合は、
通信を許可してあげること、つまり穴あけをしてあげる必要があります。

通信フローでご紹介したようにHTTPのTCP80番、HTTPSのTCP443番の他に、
DNSのUDP53番の穴あけも必要となります。

私もネットワークエンジニアに成り立ての頃はDNSを許可し忘れて、
インターネットが閲覧できないということが何度かありました。。

NAT・NAPT

NAT・NAPTに失敗していることもWeb通信ができない1つの原因として挙げられます。

単純に設定に失敗している場合や、
通信量が多い環境では、NAPTのポート数の割当に失敗しているなどが挙げられます。

まとめ

HTTPとHTTPSの通信フローをご紹介しました。
両方とも重要なプロトコルですので、
ポート番号および通信フローを理解しておきましょう。

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

HTTP通信フロー図

HTTPS通信フロー図

YouTube解説動画

【初級者・中級者向け】Webページを閲覧するときの通信フロー【HTTP・HTTPS】

その他の動画はこちらから。

-IT, セキュリティ, ネットワーク

Copyright© NWWブログ , 2021 All Rights Reserved Powered by STINGER.