TCP/IPスタックのアプリケーション層プロトコルを理解しようとしています。 HTTPとDNSの両方のプロトコルが最上位層(アプリケーション層)に留まることを知っています。そのため、ブラウザがリソースにアクセスする場合、次のようにHTTPサーバーにリクエストを送信する必要があります。
GET www.pippo.it/hello.htm HTTP/1.1
このリクエストはHTTPプロトコルのルールに従って行われ、IPアドレスではなくページのURLが使用されます。
URLをIPに変換するにはDNSリクエストが必要であることを知っています。だから私の質問は:HTTPはDNSプロトコルを呼び出すのですか?どちらもトップレイヤープロトコルであるため、私には不可能に思えます(したがって、DNSはHTTPにサービスを提供できません)。同様に、TCP(これは下位レベルにとどまります)でも、DNSのような上位レベルのプロトコルでサービスを要求することはできません。
では、DNSリクエストはいつ発生しますか?そして、誰がそのような要求を実行しますか?
問題のHTTPリクエストは実際には ブラウザが仲介者(プロキシ)と通信していない限り無効です
ブラウザーがWebサーバーと直接通信している場合、例は次のようになります。
GET /hello.htm HTTP/1.1
Host: www.pippo.it
ここで、これを概観するために、OSIモデルを検討します。
3つのシステムが動作しています。
関連するプロトコルは、下から上へ(OPに関連する最小セット):
HTTP通信はTCPプロトコル(TCPはIPプロトコルの上にあります)で行われますが、DNS通信はこの場合、UDPプロトコル上で行われます(UDPも上にあります) IPプロトコル)。
簡単な通信シーケンスは次のとおりです。
ブラウザを実行しているclientがDNSサーバーにA
を要求しますUDPプロトコルを使用したwww.pippo.it
のレコード。
1.1。クライアントでは、解決部分を実行し、ブラウザとやり取りするのはオペレーティングシステムです---ブラウザは、OSを介して gethostbyname() または新しい getaddrinfo() 。 Windowsでは、OSがアドレスを解決する順序は this のように定義される可能性がありますが、Linuxでは解決の優先順位は/etc/nsswitch.conf
で定義されます
DNSサーバーは、UDPプロトコルを使用して、clientに応答しますレコード/ IPアドレス(存在する場合)
clientは、TCPWebサーバーのポート80で接続を開きますそして次のテキストを書き込みます:
HTTPリクエスト:
GET /hello.htm HTTP/1.1
Host: www.pippo.it
コンソールまたはコマンドプロンプトで次のようにすることで、同じことを模倣できます。
> telnet www.pippo.it 80
Trying 195.128.235.49...
Connected to www.pippo.it.
Escape character is '^]'.
GET /hello.htm HTTP/1.1
Host: www.pippo.it
2つの空行が続きます。要求されたコンテンツが存在する場合、Webサーバーはそれを画面に印刷します。反対側にブラウザがある場合、応答テキストはブラウザによって解析され、すべてのタグ、リンク、スクリプト、および画像がWebページと呼ばれるものにレンダリングされます。
実際には、さらに詳細があります。すでに一部のドメインにアクセスしている場合、ブラウザはIPアドレスをキャッシュする場合があるため、DNS解決は不要になります。また、最近のブラウザーは、実際にブラウジングを高速化するために、実際にそれが必要になる前に( DNSプリフェッチ )解決を試みる場合があります。
さらに、コンピューターのhosts
ファイルに静的レコードがある場合があります。レコードが要求と一致する場合、ローカルの静的エントリが最初に使用され、DNSサーバーには接続されません。これは構成可能であり、必ずしも正しいとは限りませんが、私が使い慣れているオペレーティングシステムのデフォルトです。
HTTPは、IPプロトコルであるTCPを介して転送されます。 HTTP要求を行うには、ブラウザがTCP=接続を開く必要があります。これを行うには、宛先IPアドレス(つまり、サーバーのIPアドレス)が必要です。)To resolveサーバーのホスト名、つまりDNS要求を発行する必要があります(通常、プログラムが名前解決関数を呼び出すと、DNS要求自体がオペレーティングシステムによって送信されます。ただし、プログラムがそれ自体でDNS要求を送信することを妨げるものはありません。 DNSサーバー)。接続が確立されると、要求されたリソースへのパスを含むHTTP要求と、サーバーのホスト名を含むHostフィールド(例:Host: www.pippo.it
)。ホスト名はnotを要求行に入力します(実際にはGET /hello.htm HTTP/1.1
)、ただし、リクエストがHTTPプロキシに送信される場合を除きます(この場合、プロトコル部分を含む完全なURLが存在します。例:GET http://www.pippo.it/hello.htm HTTP/1.1
)、
手順は次のようになります。
http://www.pippo.it/hello.htm
_のようなURLを与えますブラウザはそれを3つの部分に分割します。
http
www.pippo.it
_/hello.htm
_(より複雑なURLにも他の部分がある可能性があります。今のところその可能性は無視します)
ブラウザは、IP接続を作成するためにIPアドレスが必要であることを認識しています。 IPアドレスを取得するには、DNSを使用する必要があります(アドレスがキャッシュされていない場合)。
8.8.8.8
_を取得するとします。ブラウザは、次の多層接続を構築します。
8.8.8.8
_に接続A
レコードのDNSリクエストを作成します_www.pippo.it
_もちろん、私は多くの詳細については省略しています。関連するパケットの正確な形式。
www.pippo.it
_のIPアドレスを与えるDNS応答(IPの上に重ねられたUDPの上に重ねられます)を受信します。たとえば、_10.11.12.13
_であるとしましょうhttp
を検索し、ポート80を使用する必要があります。ブラウザは、次の多層接続を構築します。
10.11.12.13
_に接続HTTPレイヤー:ホスト_/hello.htm
_でURL _www.pippo.it
_のHTTPリクエストを作成します(_10.11.12.13
_のコンピューターは複数のドメインをホストしている可能性があるため、どちらが望ましいかを知る必要があります)
_GET /hello.htm HTTP/1.1
Host: www.pippo.it
...
_
もちろん、TCPハンドシェイクなどの詳細はすべて省略しています。
hello.htm
_のコンテンツを含むHTTP応答(TCP IPの最上位に配置)などを受信します)そして適切な方法として、ブラウザーがその応答の内容を調べ、必要な追加のリソース(画像、CSS、Javascriptなど)を識別していることを述べます。その後、そのようなリソースごとにこのプロセス全体を繰り返します。