ByteDance が頻繁にテストする基本的なコンピューターネットワークの面接の質問をぜひ見てください。-見出し-php.cn

この記事では、コンピューターネットワークに関する ByteDance のフロントエンド面接でよくある質問のいくつかを紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。

ByteDance が頻繁にテストする基本的なコンピューターネットワークの面接の質問をぜひ見てください。

注: 各質問の前に表示される (xx) 数字は、この質問の頻度を表します。このコンピュータネットワーク基盤は、30 のフロントに基づいています。 -end インタビューからまとめられた質問とその回答、参考リンクなど。記事の内容はオファーを受けた本人がまとめたものです。

#(3) 質問: HTTP キャッシュ

HTTP キャッシュは強力なキャッシュとネゴシエーションキャッシュに分かれています:

最初に、キャッシュ制御を通じて強力なキャッシュが使用可能かどうかを確認します。強力なキャッシュが使用可能な場合は、キャッシュを直接読み取ります。
そうでない場合は、ネゴシエーションキャッシュに入りますフェーズを開始して HTTP リクエストを開始すると、サーバーは条件付きリクエストフィールド If-Modified-Since および If-None-Match をリクエストヘッダーに含めることで、リソースが更新されたかどうかを確認します。リソースが更新された場合は、リソースと 200 が返されます。ステータスコード
- リソースが更新されていない場合は、キャッシュを直接使用してリソースを取得するようにブラウザに指示します。
- ##( 5) 質問: 一般的に使用されるステータスコードと HTTP の使用シナリオは何ですか?

1xx: プロトコルが現在中間状態にあり、後続のリクエストが必要であることを示します

2xx:リクエストが成功したことを示します
3xx: リダイレクトステータスを示し、再リクエストが必要です
#4xx: リクエストメッセージエラーを示します
5xx: サーバー側エラー
一般的なステータスコード:

101 リクエストプロトコルを HTTP からWebSocket

200 リクエストは成功し、応答本文があります
##302 一時リダイレクト: キャッシュしません
304 ネゴシエーションキャッシュヒット
403 サーバーアクセス禁止
404 リソースが見つかりません
#400 リクエストエラー
500 サーバー側エラー
503 サーバービジー
302 ステータスコードをご存知ですか? Web を閲覧するときに遭遇した 302 のシナリオは何ですか?
そして 302 は一時的なリダイレクトを意味します。このリソースは一時的にアクセスできませんが、一定の時間が経過すると引き続きアクセスできます。通常、特定の Web サイトのリソースにアクセスするときに許可が必要な場合、ユーザーはログインページに飛んでログイン後はそのままアクセス可能です。

301 も同様で、新しい Web サイトにジャンプしますが、301 は、アクセスされたアドレスのリソースが完全に削除されたことを表します。このアドレスは今後アクセスされるべきではありません。検索エンジンも新しい Web サイトを使用します。この古いものをアドレスに置き換えます。返されたアドレスは、返された応答の location ヘッダーから取得できます。 301 のシナリオは次のとおりです。

たとえば、http://baidu.com から https://baidu.com

# にジャンプします。 ##ドメイン名変更

(2) 質問: 一般的な HTTP リクエストメソッド、その違いと用途は何ですか?

HEAD:リソースの取得メタ情報

POST: データの送信
PUT: データの変更
DELETE:データの削除
CONNECT: プロキシサーバーに使用される接続トンネルを確立します
OPTIONS: リソースに対して実行できるリクエストメソッドをリストします。ドメイン全体でよく使用されます
TRACE: リクエストとレスポンスの伝送パスの追跡
（）Q: コンピュータネットワークについてどのように理解していますか
アプリケーション層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層、物理層

(3 ) Q: HTTPS とは何ですか?特定のプロセス

HTTPS は、HTTP と TCP の間にセキュリティ層を確立します。HTTP が TCP と通信するときは、まずセキュリティ層を通過し、データパケットを暗号化し、次に暗号化されたデータパケットを通過する必要があります。は TCP に送信され、対応する TCP はデータパケットを上記の HTTP に送信する前に復号化する必要があります。

ブラウザは client_random と暗号化方式のリストを送信し、サーバーはそれを受信すると、server_random、暗号化方式のリスト、デジタル証明書 (公開鍵を含む) をブラウザに渡し、ブラウザは法的な認証を実行します。デジタル証明書の検証。検証に合格すると、pre_random が生成され、公開鍵で暗号化されてサーバーに送信されます。サーバーは client_random、server_random、pre_random を使用して、公開鍵を使用して秘密を暗号化します。は、この秘密を秘密鍵として使用し、その後の送信でデータを暗号化および復号化します。

(4) 質問: 3 ウェイハンドシェイクと 4 ウェイウェーブ

3 ウェイハンドシェイクが必要な理由: 送信と送信を確認するため相手の受信能力。

スリーウェイハンドシェイク

スリーウェイハンドシェイクのメインプロセス:

最初は、双方が CLOSED 状態にあり、サーバーは特定のポートのリッスンを開始し、LISTEN 状態に入ります。
その後、クライアントは積極的に接続を開始し、SYN を送信します。その後、SYN-SENT、seq = x
になります。サーバーがそれを受信すると、SYN seq = y および ACK ack = x 1 ( SYN-REVD
になった後、クライアントは再度 ACK seq = x 1、ack = y 1 をサーバーに送信し、EASTABLISHED になります。サーバーが ACK を受信すると、ESTABLISHED にも入ります。

SYN はピア確認を必要とするため、ACK のシリアル化を 1 つ増やす必要があります。ピア確認が必要なものはすべて、 TCP メッセージのシリアル化を 1 ポイント消費

なぜ 2 回消費しないのでしょうか?

#クライアントの受信能力を確認できません。

クライアントが最初に SYN メッセージを送信したが、それがネットワーク内に残った場合、TCP はパケットが失われたと判断して再送信し、2 回のハンドシェイクで接続が確立されます。

クライアントが接続を閉じるまで待ちます。ただし、後でパケットがサーバーに到着すると、サーバーはそれを受信し、対応するデータテーブルを送信してリンクが確立されますが、この時点ではクライアントが接続を閉じているため、リンクリソースが無駄に消費されます。

なぜ 4 回ではないのでしょうか? ##4 回以上でも問題ありませんが、3 回でも十分です

4 回手を振ります

# 状態に変わります。 ##サーバー受信後、確認のため ACK を送信し、ack = p 1 にして CLOSE-WAIT 状態に移行します。
クライアントは受信後、FIN-WAIT- 状態に移行します。 2 状態
しばらくして、データが処理されるのを待ち、再度 FIN と ACK を送信し、seq = q、ack = p 1、LAST-ACK ステージに入ります
クライアントは FIN を受信後、TIME_WAIT (2MSL 待つ) を入力し、サーバーに ACK を送信します ack = 1 1
# #サーバーは受信後、CLOSED 状態に入ります
クライアントはこの時点でもまだ 2 つの MSL を待つ必要があります。サーバーから再送信リクエストを受信しない場合、クライアントは MSL を 2 つ待つ必要があります。 ACK が正常に到着したことを意味します。ウェーブが終了し、クライアントは CLOSED 状態に変わります。それ以外の場合、ACK は再送信されます。

なぜ 2MSL (最大セグメント存続期間) 待つ必要があるのですか:

なぜなら、待機しないと、サーバーにクライアントに送信するデータパケットがまだ多くあり、クライアントポートが新しいアプリケーションによって占有されている場合、無駄なデータパケットが受信されてしまうからです。したがって、最も安全な方法は、サーバーから送信されたすべてのデータパケットがなくなるまで待ってから、新しいアプリケーションを開始することです。

1 MSL は、4 つのウェーブにおけるアクティブな終了側からの最後の ACK メッセージが最終的にピアに到達できることを保証します。

1 MSL は、次の場合にピアに到達できることを保証します。 end が ACK を受信しない場合、再送信された FIN メッセージは
なぜ 3 回ではなく 4 回到達するのでしょうか?

**3 回の場合、サーバーの ACK と FIN は 1 つの波に結合されます。このような長い遅延により、TCP FIN がサーバーに到達できなくなり、クライアントはFIN

##参考文献

https://zhuanlan.zhihu.com/p/86426969

Q: インタラクション中にデータ送信が完了し、それでも切断したくない場合はどうすればよいですか? どのように維持すればよいですか?

HTTP では、応答本文の Connection フィールドはキープアライブとして指定されます。

TCP スライディングウィンドウについて何か知っていますか?

TCP リンクでは、送信側と受信側で、TCP は送信データを送信バッファー領域に配置し、受信したデータを ## に配置する必要があります。 #受信バッファ領域

。送信者が送信しすぎて受信者がそれを消化できない状況がよくあるため、受信バッファのサイズによって送信者の送信を制御するフロー制御が必要になります。相手の受信バッファがいっぱいの場合は送信を続けることができません。このフロー制御プロセスでは、送信側で送信ウィンドウを維持し、受信側で受信ウィンドウを維持する必要があります。

TCP スライディングウィンドウは、送信ウィンドウと 受信ウィンドウの 2 つのタイプに分類されます。

参考文献

https://juejin.im/post/5e527c58e51d4526c654bf41#Heading-38

本質が異なる

Ajax は非同期の JavaScript と XML であり、インタラクティブな Web アプリケーションを作成するための Web 開発テクノロジです。

websocket は、Real-Socket を実装する HTML5 の新しいプロトコルです。ブラウザとサーバー間の通信時間さまざまなライフサイクル:

Websocket は接続が長く、セッションは常に維持されます
ajax は送受信後に切断されます

アプリケーションの範囲:

##websocket はフロントエンドとバックエンドのリアルタイムインタラクティブデータに使用されます
ajax 非リアルタイム

イニシエーター:

WebSocket をご存知ですか?

ロングポーリングとショートポーリング。WebSocket はロングポーリングです。

たとえば、電子商取引のシナリオでは、商品の在庫が変更される可能性があるため、それをユーザーに適時に反映する必要があるため、クライアントはリクエストを送信し続け、サーバーはチェックし続けることになります。変更の場合は、変更に関係なく、すべてが返されます。これはショートポーリングです。

ロングポーリングのパフォーマンスは、変更がない場合は返されず、変更またはタイムアウト (通常は 10 秒以上) を待ってから返されます。リクエストを送信し続ける必要がないため、双方のプレッシャーが軽減されます。

#参考リンク

https://www.jianshu.com/p/3fc3646fad80

Connection: keep-alive をヘッダー (リクエストおよびレスポンスヘッダー) に設定すると、HTTP1.0 プロトコルがサポートされますが、デフォルトではオフになります。プロトコル以降、接続はデフォルトで長い接続になります

HTTP には通常、キープアライブタイムアウトを設定できる httpd デーモンがあります。TCP リンクがこの時間を超えてアイドル状態になると、 HTTP ヘッダーにタイムアウトを設定することもできます。Time

TCP のキープアライブには 3 つのパラメーターが含まれており、システムカーネルの net.ipv4 で設定できます。 : TCP コネクションがアイドル状態かつ tcp_keepalive_time がアイドルの場合、検出パケットが発生し、相手から ACK が受信されない場合は、tcp_keepalive_probes が送信されるまで tcp_keepalive_intvl ごとに再送信され、リンクは破棄されます。
#tcp_keepalive_intvl = 15
- ##tcp_keepalive_probes = 5
- tcp_keepalive_time = 1800
- #実際、HTTP には長いリンクと短いリンクがありません。TCP だけが持っています。TCP の長い接続では、TCP リンクを再利用して複数の HTTP リクエストを開始できます。これにより、次のようなリソースの消費を削減できます。一度に HTML をリクエストすると、後続の JS/CSS/画像などもリクエストする必要がある場合があります。

https://ブログ .csdn.net/weixin_37672169/article/details/80283935

質問: Fetch API と従来の Request の違い

fetch は関心事の分離に準拠しており、Promise を使用します。 API がより豊富になり、Async/Await をサポート

参考リソース

https://github.com/camsong/blog/ issues/2

#テキスト、写真、ビデオ、オーディオなどはすべて受け入れられます

text/image/audio/ または application/json など

##質問: TCP はどのようにして効果的な送信と輻輳制御の原則を保証しますか。
#tcp は、コネクション指向で信頼性の高いトランスポート層通信プロトコルです。

信頼性は次の点に反映されます。ステートフル、制御可能

主に 3 つの方法を使用します。

スロースタートしきい値の輻輳回避#

##高速再送信

クイック返信

スロースタートしきい値の輻輳回避
#

スロースタートしきい値 (ssthresh)

送信側で輻輳ウィンドウを使用して、送信ウィンドウのサイズを制御します。

その後、比較的保守的なスロースタートアルゴリズムを使用して、ネットワークにゆっくりと適応します。最初の送信期間中、送信者と受信者はまず 3 ウェイハンドシェイクを通じて接続を確立し、それぞれのサイズを決定します。次に、両方のパーティの輻輳ウィンドウを初期化し、スロースタートしきい値に達するまで、RTT (受信遅延と送信遅延) の各ラウンド後に輻輳ウィンドウのサイズを 2 倍にします。

次に、輻輳回避を開始します。輻輳回避の具体的な方法は、RTT の前の各ラウンドで輻輳ウィンドウを 2 倍にし、各ラウンドで 1 つずつ追加することです。

高速再送信

TCP 送信プロセス中にパケット損失が発生すると、受信側は 5 パケットなどの繰り返し ACK を送信します。このとき、送信側は 3 回の ACK を繰り返し受信します。、RTO (タイムアウト再送信時間) を待たずにすぐに再送信されます。

選択的再送信: オプションでメッセージヘッダーに SACK 属性を追加し、左端と右端から到着したパケットにマークを付けてから再送信します。未配信パケット

迅速な回復

送信者が 3 つの重複 ACK を受信し、パケット損失を発見した場合、ネットワーク状態が異常事態に入ったように感じます。輻輳状態にある場合、急速回復フェーズに入ります。

輻輳しきい値が輻輳ウィンドウの半分に減ります
その後、輻輳が解消されます。ウィンドウサイズが輻輳しきい値になります
その後、ネットワーク状況に適応するために輻輳ウィンドウが直線的に増加します

質問: OPTION とは何ですか?する？ OPTION の使用例を教えてください。

プローブリクエストを送信して、特定のターゲットアドレスに対するリクエストにどのような制約が必要かを判断し、その制約に従って実際のリクエストを送信することを目的としています。

たとえば、クロスドメインリソースの事前チェックは、HTTP OPTIONS メソッドを使用して最初に送信されます。クロスドメインリクエストの処理に使用されます

#Q: http をご存知ですか?合意のどの層ですか? (アプリケーション層)

柔軟かつスケーラブルで、単語を区切るためのスペースとフィールドを区切るための改行の規定を除き、その他の制限はありません。テキストのみを送信するだけでなく、写真やビデオなどのリソースも送信します
#リクエストとレスポンス、応答があります。
ステートレス、各 HTTP リクエストは独立しており、無関係であり、デフォルトではコンテキスト情報を保存する必要はありません
#欠点:

クリアテキスト送信は安全ではありません

Q: OSI 7 層モデルと TCP/IP 4 層モデル

OSI 7 層モデル

#アプリケーション層

セッション層
トランスポート層
ネットワーク層
データリンク層
物理層
TCP/IP 4 層概念:

#アプリケーション層: アプリケーション層、プレゼンテーション層、セッション層: HTTPトランスポート層: トランスポート層: TCP/UDP

ネットワーク層: ネットワーク層: IP
データリンク層: データリンク層、物理層
(3) 質問: TCP プロトコルの信頼性はどのように確保され、なぜ UDP は信頼できないのでしょうか?

UDP は、コネクションレス型のトランスポート層通信です。プロトコル、IP 特性を継承し、データグラムに基づいています

なぜ TCP は信頼できるのでしょうか? TCP の信頼性は、ステートフルで制御された
に反映されており、どのデータが送信されたか、どのデータが相手に受信されたか、どのデータが受信されなかったかを正確に記録し、次のことを保証します。データパケットは順番に到着します。間違いは許されません。これはステートフルです。