web-dev-qa-db-ja.com

最初から最後までインターネットがどのように機能するかについてのインタビューの質問に対して、より技術的な答えが必要

私は過去2週間に5人の個別のユーザーとの面接を行い、そのうち5人のうち3人がこの質問をしてきました:「Google.com」にアクセスしてからページが表示されるまでの流れ画面上。基本的に、インターネットの仕組み。 3度目は、この質問をもう一度受ける場合に備えておくとよいと思います。

私はいくつかのことを知っていますが、私の答えが十分であるとは完全には確信していません。基本的に、DNSサーバーは「google.com」をIPアドレスに変換することを述べました。私はTCP/IPについて少し光沢があります。それから、ブラウザがブラウザに解釈して表示するブラウザに送り返される、要求されたページを文字通り提供するWebサーバーについて話します。

前に言ったように、私の答えは十分に技術的であるとは思いません。私が除外しているステップは何ですか?

価値があるのは、これらの3回のうち2回は同じ会社に所属していて、3回目のインタビューのためにコールバックされているからです。爆破することはできませんtoo難しい。

13
Megacannon
  1. ブラウザはまず、OSの「hosts」ファイルで、ドメイン名をIPアドレスに変換するエントリを探します。これはARPANETから継承されたレガシー機能であり、単一のテキストファイルに、ARPANETを介してアクセス可能なすべてのコンピューター、およびそれに接続された各コンピューターの比較的新しいコピーを含むわかりやすい名前を含めることが可能でした。以前は、NetBIOSまたは類似のノード命名プロトコルを持たないコンピューターの小さなネットワークでいくつかの残された価値がありましたが、今日では、ハッカー(DNSをバイパスしてコンピューターをサイトに向けることができるハッカー)のターゲットになる可能性が高いですクライアントコンピュータまたはそのユーザー/所有者が正当に使用するかどうかを制御します。
  2. コンピュータにこのドメインのHOSTSエントリがないと仮定すると、ブラウザは、使用されている接続のOSのインターネット設定で構成されたDNSサーバーにUDPリクエストを送信し、リクエストの「ホスト名」またはドメイン名(すべて「http://」と、次に来る最初のコロンまたはスラッシュの間(例:「www.google.com」)。このDNSサーバーは通常、会社またはローカルのインターネットサービスプロバイダーに属しています。
    • UDPは「Universal Datagram Protocol」の略で、TCP(「network-layer」IPプロトコルの上、「application-layer」の下にある)と同じクラスの「transport-layer」プロトコルです。 "HTTP、FTP、SMTPなどのプロトコル。TCP=は、多くのエラーチェック機能とフォールトトレランス機能(追加のデータの追加とオーバーヘッドの増加)を提供します)ですが、UDPはより軽量なアプローチ、ネットデータ帯域幅の増加;トレードオフは、プロトコルがTCPのように大きなデータを複数のパケットに分割する(メッセージが小さい必要がある)など)またはreで利用可能な機能をサポートしないことです-送信中に失われたパケットを送信します。これは、1つのパケットが失われたかどうかに関係なく、小さくシンプルなメッセージ(DNSなど)やストリーミングのテレメトリタイプのデータに適しています。
  3. このDNSサーバーは、次の3つのことの1つを認識します。そのドメイン名をIPアドレスに直接変換する方法(つまり、そのドメインの「権威ネームサーバー」またはANSです)。 ANSまたはその親のIPアドレス。または、ANSに到達する方法を知っている可能性が高い独自の親ネームサーバー。サーバーがリクエスト自体を変換しない場合、サーバーはリクエストを「ダウン」して既知のANSに転送するか、「アップ」して親NSに転送し、このプロセスが再帰的に繰り返されます。
    • このツリー構造の「ルート」は、受け取った要求をいくつかの「トップレベルドメイン」またはTLDサーバーの1つに転送するだけの単一サーバーです。たとえば、「。com」ネームサーバーがあり、(これらの要求をISPレベルのネームサーバーに転送することにより)惑星上の「.com」ドメインのIPアドレスを見つける方法を知っています。これらのTLDは、ISPに属するインターネットの特定の「ブランチ」内のどのDNSにも認識されていないドメインネームサーバーへのリクエストを転送します。
  4. 信頼できるネームサーバーが見つかり、ドメイン名をIPアドレスに変換すると、このアドレスがクライアントとそのブラウザに返されます。 ANSが要求の「存続時間」(TTL;誤って構成されたサーバー間の無限の循環を回避するためにサーバー間で要求を転送する必要がある最大回数)内に見つからない場合、エラーがノードによってクライアントに返されますどの要求が「タイムアウト」するか(またはドメインの権限のあるサーバーであるが、特定のドメインプレフィックスを変換できないノード)。
  5. ブラウザは、HTTP接続の場合、「TCP SYN」要求をIPアドレスと指定されたポート(またはデフォルトのHTTPポート80)に送信して、接続を確立します。これは、「ネットワークレベル」のIPヘッダーの上にあるプロトコルレベルのリクエストであり、クライアントの優先応答ポート(「ソースポート」)、設定TCP =セグメントサイズ、ウィンドウスケール、オプションのプロトコル機能の使用などの通信。
  6. リクエストは、「リンクレベル」でルーティングされます(ネットワーク、トランスポート、およびアプリケーションレイヤーに含まれるデータを送信するために実際の電気回路を操作する方法を制御します)。通常、データはワイヤーまたはファイバーに沿って自宅または会社の「中央オフィス」(これは「ラストマイル」と呼ばれ、通常は帯域幅への最大のボトルネックを表す回路です)に送られます。情報スーパーハイウェイ。その後、COは高帯域幅のパイプ(Tキャリア、SONETなど)にアクセスできます。このパイプは、世界中の何十億ものリクエストとともに、世界中の宛先のCOに送信し、宛先のサーバーまたはネットワークに転送します。
    • この「IPルーティング」は、概念的にはDNS解決と同様に機能します。 「トップ層」のISPには、ICANNによって「クラスA」のIPネットワーク全体(既知の最初のバイトで可能なすべてのアドレス)が割り当てられており、他のISPは、そのクラスAネットワークの所有者と、そのネットワークに最も近い「フロント」にデータを取得する方法を知っていますドア」、「ルーティングテーブル」の情報を使用します。この最上位層のISPは、アドレスのブロックをリースします。一部はローカルISPにリースし、その他は企業ユーザーに直接リースします。これらのISPおよび企業には、IPアドレス(および独自のルーティングテーブル)を使用して他にパケットを送信するかどうかを決定するルーターがあります。近くの回線、他のローカルISPルーターの横、または上位層のトランクとルーターまで。
  7. サーバーはこのリクエストを受信し(ソケットやファイアウォールなどの下位の抽象化レイヤーで拒否されない場合)、接続を受け入れると決定すると、「SYN-ACK」リクエスト/応答ステップを送信し、両方が独自の設定を要求して指定する(対応できるクライアントの設定を含むが、指定できないものまたは指定されていないものを変更する)。
  8. サーバーが提供したオプションセットを使用してクライアントが通信をサポートしている場合、クライアントはACK応答を送信し、接続が「確立」されます。
  9. ブラウザは次に「HTTP GET」リクエストを送信します。リクエストには、ブラウザによってリクエストされたリソースの完全なURIが含まれます(www.google.comと話していることはわかっていますが、サーバーは、必要に応じてさらに解釈できるように、リクエストの一部としてその文字列を送信しますリクエストを送信するドメイン名)。このリクエストには「Cookie」が含まれる場合があります。リクエストを効率的かつ便利に処理するためにサーバーに提供できるクライアントに保存されたデータ(ユーザーの設定の識別など)。
  10. サーバーはGETリクエストを受信し、最初にそれを受け入れるかどうかを決定します(サーバーはTCPポート80へのリクエストをリッスンしていた可能性がありますが、FTPまたはVoIP。これはポート80ではまれですが、他のタイプのポートではより一般的です。受け入れ可能であると想定します。サーバーは、要求されたリソース(この場合、デフォルトページのHTML)を含むHTTP応答を返します。 Googleのユビキタス検索ページ。レスポンスには、サーバーがクライアントに保存するように要求する「Cookie」も含まれる場合があります(クライアントが保存する場合としない場合があります)。
  11. HTMLはブラウザによってダイジェストされ、ブラウザウィンドウにページを描画するためにレンダリングされます。これが発生している間、HTMLで規定された方法でページのすべてのコンテンツを表示するために必要なJavascript、スタイルシート、画像、およびその他のデータに対するHTTP GETリクエストがクライアントから送信され、結果のデータがサーバ。
  12. 昔、Googleは静的なフォームに基づいていました。テキストボックスに検索したいものを入力し、「検索」(または「私はラッキーな感じ」)を押します。これを行うと、HTTP POST要求がクライアントによってサーバーに送信されます。要求には、情報の送信先であるクライアントによって指定された場所が含まれます。情報自体。この情報はサーバーによってダイジェストされ、検索結果を見つけるために使用され、サーバーはこれらの結果のページを作成して送信します。または、検索語を「クエリ文字列」に変換できます。 「リダイレクト」で応答します;メッセージで指定された別のURIに別のリクエストを送信するようにブラウザーに要求します。ブラウザーはそれを行い、サーバーはthatページ。
  13. 現代では、Googleのトップページははるかに動的です。入力すると、ブラウザ内のクライアント側で実行されるJavaScriptが、入力した内容を「サイドチャネル」に沿ってGoogleに送信します(通信には同じプロトコルを使用しますが、ブラウザ自体がページ全体のリクエストを送信するわけではないためです) 、ブラウザ画面が完全にクリアされず、再描画されません)。フロントページの場合、これはクエリヒントを提供するために使用されます(他の人が最近行ったため、検索している可能性のあるものに対するオートコンプリートの提案)。結果ページでは、同じことを行いますが、リアルタイムの検索結果を提供し、ブラウザによるページ全体の再読み込みを必要とせずにページを完全に再描画するためにも使用できます。これらの種類のトリックは、AJAX(非同期のJavaScriptとXML、ただし、競合するJSON標準がデータのフォーマットに頻繁に使用されますが)の一般的な見出しに該当し、最新の「Webアプリケーション」に広く普及しています。 "インターネットの比較的静的でステートレスなコールアンドアンサーモデルを介して動的コンテンツを提供します。

この映画 は、大学で新入生の「Intro to IT」クラスを見せたもので、基本が親しみやすく、類似した形式で示されています。それは決して技術的ではありませんが、このパズルのピースの概念的な概要を提供します。

29
KeithS

Cookieとファイアウォールについての言及を省くと、ここではいくつか欠落することになります。 「Google.com」がユーザーを認識し、Googleにログインしていないユーザーとは異なるページを表示できるように、Cookieが送信されることについては注意が必要です。スマートフォン、タブレット、または通常のコンピューター(ラップトップまたはデスクトップ)のどこを探しているかという問題もあります。

あなたが尋ねるつもりだったけれどもそれをしなかったいくつかの副質問があるかもしれないのではないかと思います。これは、インターネットが少し広くなり、電子メールや私が思う他のものが含まれるため、Webがどのように機能するかという問題の詳細です。


私の推測では、それはあなたのコミュニケーション能力のテストでした。かなり技術的な質問をして、それを分解して、技術的および技術的ではない人が理解できるようにすることはできますか?ブラウザで「Google.com」のホームページを表示した人に説明を求められたら、どのような質問を返しますか?たくさんの仮定をしたり、質問したりしますか?ある意味では、これはホワイトボードの質問と並行していると私は考えています。正確に正しい答えを出すことができるように質問するか、答えを出す際に仮定を立てるのに十分なあいまいさが残っています。

1
JB King