ByteDance が頻繁にテストする基本的なコンピューター ネットワークの面接の質問をぜひ見てください。
- 青灯夜游転載
- 2021-04-26 10:02:269703ブラウズ
この記事では、コンピューター ネットワークに関する ByteDance のフロントエンド面接でよくある質問のいくつかを紹介します。一定の参考値があるので、困っている友達が参考になれば幸いです。
注: 各質問の前に表示される (xx) 数字は、この質問の頻度を表します。このコンピュータ ネットワーク基盤は、30 のフロントに基づいています。 -end インタビューからまとめられた質問とその回答、参考リンクなど。記事の内容はオファーを受けた本人がまとめたものです。
#(3) 質問: HTTP キャッシュ
HTTP キャッシュは強力なキャッシュとネゴシエーション キャッシュに分かれています:
- 最初に、キャッシュ制御を通じて強力なキャッシュが使用可能かどうかを確認します。強力なキャッシュが使用可能な場合は、キャッシュを直接読み取ります。
- そうでない場合は、ネゴシエーション キャッシュに入りますフェーズを開始して HTTP リクエストを開始すると、サーバーは条件付きリクエスト フィールド If-Modified-Since および If-None-Match をリクエスト ヘッダーに含めることで、リソースが更新されたかどうかを確認します。リソースが更新された場合は、リソースと 200 が返されます。 ステータス コード
- リソースが更新されていない場合は、キャッシュを直接使用してリソースを取得するようにブラウザに指示します。
- ##( 5) 質問: 一般的に使用されるステータス コードと HTTP の使用シナリオは何ですか?
- リソースが更新されていない場合は、キャッシュを直接使用してリソースを取得するようにブラウザに指示します。
1xx: プロトコルが現在中間状態にあり、後続のリクエストが必要であることを示します
- 2xx:リクエストが成功したことを示します
- 3xx: リダイレクト ステータスを示し、再リクエストが必要です
- #4xx: リクエスト メッセージ エラーを示します
- 5xx: サーバー側エラー
- 一般的なステータス コード:
- 200 リクエストは成功し、応答本文があります #301 永続的なリダイレクト: キャッシュされます
- ##302 一時リダイレクト: キャッシュしません
- 304 ネゴシエーション キャッシュ ヒット
- 403 サーバー アクセス禁止
- 404 リソースが見つかりません
#400 リクエスト エラー
500 サーバー側エラー
-
503 サーバー ビジー
- 302 ステータス コードをご存知ですか? Web を閲覧するときに遭遇した 302 のシナリオは何ですか?
- そして 302 は一時的なリダイレクトを意味します。このリソースは一時的にアクセスできませんが、一定の時間が経過すると引き続きアクセスできます。通常、特定の Web サイトのリソースにアクセスするときに許可が必要な場合、ユーザーはログインページに飛んでログイン後はそのままアクセス可能です。
たとえば、http://baidu.com から https://baidu.com
# にジャンプします。 ##ドメイン名変更
- (2) 質問: 一般的な HTTP リクエスト メソッド、その違いと用途は何ですか? http/1.1 では、次のリクエスト メソッドが指定されています:
- GET: データのユニバーサル取得
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 回手を振ります
- 最初は ESTABLISH 状態ですが、クライアントが seq = p の FIN メッセージを送信し、FIN-WAIT-1
- # 状態に変わります。 ##サーバー 受信後、確認のため 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 は再送信されます。
なぜなら、待機しないと、サーバーにクライアントに送信するデータ パケットがまだ多くあり、クライアント ポートが新しいアプリケーションによって占有されている場合、無駄なデータ パケットが受信されてしまうからです。したがって、最も安全な方法は、サーバーから送信されたすべてのデータ パケットがなくなるまで待ってから、新しいアプリケーションを開始することです。
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
- #Q: WebSocket と Ajax の違いは何ですか
本質が異なる
Ajax は非同期の JavaScript と XML であり、インタラクティブな Web アプリケーションを作成するための Web 開発テクノロジです。
websocket は、Real-Socket を実装する HTML5 の新しいプロトコルです。ブラウザとサーバー間の通信時間さまざまなライフサイクル:
Websocket は接続が長く、セッションは常に維持されます
ajax は送受信後に切断されます
アプリケーションの範囲:
- ##websocket はフロントエンドとバックエンドのリアルタイム インタラクティブ データに使用されます
- ajax 非リアルタイム
イニシエーター:
- # #AJAX クライアントが開始されました
- WebSocket サーバーとクライアントは相互にプッシュします
ロング ポーリングとショート ポーリング。WebSocket はロング ポーリングです。
たとえば、電子商取引のシナリオでは、商品の在庫が変更される可能性があるため、それをユーザーに適時に反映する必要があるため、クライアントはリクエストを送信し続け、サーバーはチェックし続けることになります。変更の場合は、変更に関係なく、すべてが返されます。これはショートポーリングです。
ロングポーリングのパフォーマンスは、変更がない場合は返されず、変更またはタイムアウト (通常は 10 秒以上) を待ってから返されます。リクエストを送信し続ける必要がないため、双方のプレッシャーが軽減されます。
#参考リンクhttps://www.jianshu.com/p/3fc3646fad80
- HTTP で長い接続を実装するにはどうすればよいですか?どの時点でタイムアウトになりますか?
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
- https://www.jianshu.com/p/3fc3646fad80
- 質問: Fetch API と従来の Request の違い
fetch は関心事の分離に準拠しており、Promise を使用します。 API がより豊富になり、Async/Await をサポート
- セマンティクスがシンプルになり、よりセマンティックになりました
- #同型フェッチを使用でき、同型は便利です
-
参考リソース
https://github.com/camsong/blog/ issues/2
- (2) 質問: 一般に POST で送信できるファイルの種類とデータ処理の問題
text/image/audio/ または application/json など
##質問: TCP はどのようにして効果的な送信と輻輳制御の原則を保証しますか。
- #tcp は、コネクション指向で信頼性の高いトランスポート層通信プロトコルです。
信頼性は次の点に反映されます。ステートフル、制御可能
- ステートフルとは、TCP がどのメッセージが送信されたか、どのメッセージが受信者に受信されたか、どのメッセージが未受信であるかを確認し、データ パケットが順番に到着することを保証することを意味します。エラー
- 制御可能とは、パケット損失が発生したり、ネットワークの状態が悪い場合に、独自の動作に移行し、送信速度を低下させたり、再送信したりすることを意味します
- したがって、上記により、データ パケットの効果的な送信が保証されます。
- 輻輳制御の原則
- 理由は、ネットワーク環境全体が特に劣悪でパケット損失が起こりやすいため、送信者が料金を支払う必要があるためです。注意。
主に 3 つの方法を使用します。
スロー スタートしきい値の輻輳回避#
##高速再送信 クイック返信- スロー スタートしきい値の輻輳回避
#
##輻輳制御では、TCP は主に 2 つのコアを維持します状態: - 輻輳ウィンドウ (cwnd)
スロースタートしきい値 (ssthresh)
送信側で輻輳ウィンドウを使用して、送信ウィンドウのサイズを制御します。輻輳しきい値が輻輳ウィンドウの半分に減ります
その後、輻輳が解消されます。ウィンドウ サイズが輻輳しきい値になります
その後、ネットワーク状況に適応するために輻輳ウィンドウが直線的に増加します
- 柔軟かつスケーラブルで、単語を区切るためのスペースとフィールドを区切るための改行の規定を除き、その他の制限はありません。テキストのみを送信するだけでなく、写真やビデオなどのリソースも送信します #TCP/IP に基づいた信頼性の高い送信により、この機能を継承します
- #リクエストとレスポンス、応答があります。
- ステートレス、各 HTTP リクエストは独立しており、無関係であり、デフォルトではコンテキスト情報を保存する必要はありません
#欠点:
- なし 長時間接続のシナリオでは、大量の繰り返し情報の送信を避けるために大量のコンテキストを保存する必要があります
- Q: OSI 7 層モデルと TCP/IP 4 層モデル
- セッション層
- トランスポート層
- ネットワーク層
- データリンク層
- 物理層
- TCP/IP 4 層概念:
ネットワーク層: ネットワーク層: IP
データリンク層: データリンク層、物理層
- (3) 質問: TCP プロトコルの信頼性はどのように確保され、なぜ UDP は信頼できないのでしょうか?
- #TCP は、コネクション型で信頼性の高いトランスポート層通信プロトコルです。
- なぜ TCP は信頼できるのでしょうか? TCP の信頼性は、ステートフルで制御された
- に反映されており、どのデータが送信されたか、どのデータが相手に受信されたか、どのデータが受信されなかったかを正確に記録し、次のことを保証します。データ パケットは順番に到着します。間違いは許されません。これはステートフルです。
- 逆に、UDP はステートレスで制御不可能です HTTP 2 の改善
- パフォーマンスの向上:
- サーバープッシュ
参考資料
- ##https://juejin.im/post/5d032b77e51d45777a126183
その後、比較的保守的なスロー スタート アルゴリズムを使用して、ネットワークにゆっくりと適応します。最初の送信期間中、送信者と受信者はまず 3 ウェイ ハンドシェイクを通じて接続を確立し、それぞれのサイズを決定します。次に、両方のパーティの輻輳ウィンドウを初期化し、スロー スタートしきい値に達するまで、RTT (受信遅延と送信遅延) の各ラウンド後に輻輳ウィンドウのサイズを 2 倍にします。
次に、輻輳回避を開始します。輻輳回避の具体的な方法は、RTT の前の各ラウンドで輻輳ウィンドウを 2 倍にし、各ラウンドで 1 つずつ追加することです。
高速再送信
TCP 送信プロセス中にパケット損失が発生すると、受信側は 5 パケットなどの繰り返し ACK を送信します。このとき、送信側は 3 回の ACK を繰り返し受信します。 、RTO (タイムアウト再送信時間) を待たずにすぐに再送信されます。
選択的再送信: オプションでメッセージ ヘッダーに SACK 属性を追加し、左端と右端から到着したパケットにマークを付けてから再送信します。未配信パケット
迅速な回復
送信者が 3 つの重複 ACK を受信し、パケット損失を発見した場合、ネットワーク状態が異常事態に入ったように感じます。輻輳状態にある場合、急速回復フェーズに入ります。
質問: OPTION とは何ですか?する？ OPTION の使用例を教えてください。
プローブ リクエストを送信して、特定のターゲット アドレスに対するリクエストにどのような制約が必要かを判断し、その制約に従って実際のリクエストを送信することを目的としています。
たとえば、クロスドメイン リソースの事前チェックは、HTTP OPTIONS メソッドを使用して最初に送信されます。クロスドメインリクエストの処理に使用されます
#Q: http をご存知ですか?合意のどの層ですか? (アプリケーション層)
クリア テキスト送信は安全ではありません
- ##TCP リンクを再利用するとピアの輻輳が発生します
OSI 7 層モデル
#アプリケーション層
プレゼンテーション層#アプリケーション層: アプリケーション層、プレゼンテーション層、セッション層: HTTPトランスポート層: トランスポート層: TCP/UDP
UDP は、コネクションレス型のトランスポート層通信です。プロトコル、IP 特性を継承し、データグラムに基づいています
ヘッダー圧縮
複数チャネルの多重化
プログラミング関連の知識については、
プログラミング ビデオをご覧ください。 ！