この記事では、コンピューター ネットワークに関する 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 特性を継承し、データグラムに基づいています
ヘッダー圧縮
複数チャネルの多重化
プログラミング関連の知識については、
プログラミング ビデオをご覧ください。 !

字节跳动旗下的创意视频剪辑工具CapCut在中国、美国和东南亚拥有大量用户。该工具支持安卓、iOS和PC平台市场调研机构data.ai最新报告指出,截至2023年9月11日,CapCut在iOS和GooglePlay上的用户总支出已突破1亿美元(本站备注:当前约7.28亿元人民币),成功超越Splice(2022年下半年排名第一)成为2023年上半年全球最吸金的视频剪辑应用,与2022年下半年相比增长了180%。截至2023年8月,全球有4.9亿人通过iPhone和安卓手机使用CapCut。da

据南山区政府官方微信公众号“创新南山”透露,深圳字节跳动后海中心项目最近取得了重要进展。根据中建一局建设发展公司的消息,该项目主体结构提前3天全部完成封顶工作。这一消息意味着南山后海核心区将迎来一个新的地标建筑。深圳字节跳动后海中心项目位于南山区后海核心区,是今日头条科技有限公司在深圳市的总部办公大楼。总建筑面积为7.74万平方米,高约150米,共有地下4层和地上32层。据悉,深圳字节跳动后海中心项目将成为一座创新型超高层建筑,集办公、娱乐、餐饮等功能为一体。该项目将有助于深圳推动互联网产业的集

一. 背景介绍在字节跳动,基于深度学习的应用遍地开花,工程师关注模型效果的同时也需要关注线上服务一致性和性能,早期这通常需要算法专家和工程专家分工合作并紧密配合来完成,这种模式存在比较高的 diff 排查验证等成本。随着 PyTorch/TensorFlow 框架的流行,深度学习模型训练和在线推理完成了统一,开发者仅需要关注具体算法逻辑,调用框架的 Python API 完成训练验证过程即可,之后模型可以很方便的序列化导出,并由统一的高性能 C++ 引擎完成推理工作。提升了开发者训练到部署的体验

近日,人工智能国际顶会AAAI2023公布评选结果。新加坡国立大学(NUS)与字节跳动机器学习团队(AML)合作的CowClip技术论文入围杰出论文(DistinguishedPapers)。CowClip是一项模型训练优化策略,可以在保证模型精度的前提下,实现在单张GPU上的模型训练速度提升72倍,相关代码现已开源。论文地址:https://arxiv.org/abs/2204.06240开源地址:https://github.com/bytedance/LargeBatchCTRAAA

IT之家1月18日消息,针对近日TikTok国内员工转岗海外的传言,据接近字节跳动的人士透露,该公司正在加拿大、澳大利亚等地筹建研发中心。目前,部分研发中心已试运营半年左右,未来将支持TikTok、CapCut、Lemon8等多个海外业务研发。字节跳动计划以当地招聘为主,并辅助少量外派的方式筹建相关研发中心。据了解,过去半年,该公司已从美国、中国、新加坡等地选派少量工程师参与筹建。其中,从中国向两地研发中心累计派出包括产品、研发和运营岗位120人。相关人士表示,此举是为了应对海外业务的发展,更好

近期,科技圈再次掀起了一股虚拟现实(VR)的热潮。据称,字节跳动旗下的VR子公司Pico即将推出全新的独立VR头显——Pico4S。一位名为@Lunayian的用户在社交媒体上发布了一张3D模型图片,声称该图片来自PicoConnectPC客户端,展示了Pico4S的右控制器设计。这款控制器的外观与去年9月在网络上泄露的"Pico5"控制器非常相似,但与Pico4的控制器有一些明显的差异,主要体现在取消了定位环。这一设计调整可能预示着Pico4S将带来全新的用户体验和交互方式。据了解,Pico在

本站12月13日消息,据TheInformation,字节跳动准备砍掉其PICO新一代VR头显PICO5,因为现款PICO4的销量远远低于预期。根据EqualOcean在今年10月的一篇文章,据称字节跳动将逐步关闭PICO,并放弃元宇宙领域。文章指出,字节跳动认为PICO所处的硬件领域并非其专长,几年来的成绩未达到预期,并且对未来缺乏希望在当时,字节跳动的相关负责人对于关于“逐步放弃PICO业务”的传闻进行了回应,称这一消息是不实的。他们表示PICO业务仍在正常运营,并且公司将会长期投入扩展现实

本站8月17日消息,字节跳动旗下LLM人工智能机器人“豆包”现已开始小范围邀请测试,用户可通过手机号、抖音或者AppleID登录。根据报道,据称字节跳动公司开发了一款名为"豆包"的AI工具,该工具基于云雀模型,提供聊天机器人、写作助手和英语学习助手等功能。它可以回答各种问题并进行对话,帮助人们获取信息。"豆包"支持网页Web平台、iOS和安卓平台,但在iOS平台上需要通过TestFlight进行安装官网用户协议显示,“豆包”软件及相关服务系指北京春田知韵科

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SecLists
SecLists は、セキュリティ テスターの究極の相棒です。これは、セキュリティ評価中に頻繁に使用されるさまざまな種類のリストを 1 か所にまとめたものです。 SecLists は、セキュリティ テスターが必要とする可能性のあるすべてのリストを便利に提供することで、セキュリティ テストをより効率的かつ生産的にするのに役立ちます。リストの種類には、ユーザー名、パスワード、URL、ファジング ペイロード、機密データ パターン、Web シェルなどが含まれます。テスターはこのリポジトリを新しいテスト マシンにプルするだけで、必要なあらゆる種類のリストにアクセスできるようになります。

Safe Exam Browser
Safe Exam Browser は、オンライン試験を安全に受験するための安全なブラウザ環境です。このソフトウェアは、あらゆるコンピュータを安全なワークステーションに変えます。あらゆるユーティリティへのアクセスを制御し、学生が無許可のリソースを使用するのを防ぎます。

EditPlus 中国語クラック版
サイズが小さく、構文の強調表示、コード プロンプト機能はサポートされていません

mPDF
mPDF は、UTF-8 でエンコードされた HTML から PDF ファイルを生成できる PHP ライブラリです。オリジナルの作者である Ian Back は、Web サイトから「オンザフライ」で PDF ファイルを出力し、さまざまな言語を処理するために mPDF を作成しました。 HTML2FPDF などのオリジナルのスクリプトよりも遅く、Unicode フォントを使用すると生成されるファイルが大きくなりますが、CSS スタイルなどをサポートし、多くの機能強化が施されています。 RTL (アラビア語とヘブライ語) や CJK (中国語、日本語、韓国語) を含むほぼすべての言語をサポートします。ネストされたブロックレベル要素 (P、DIV など) をサポートします。
