フロントエンドのインタビューの質問の概要 (理論パート 1) -- ページの読み込みとリクエスト、ネットワーク

URLの入力からページのレンダリングまでの全プロセス

1) URLを入力してください

2) キャッシュを確認する

3) DNS ドメイン名解決による IP アドレスの取得

4) ブラウザはサーバーとの接続を確立します (TCP スリーウェイハンドシェイク)

4) HTTP リクエストをサーバーに送信すると、サーバーは応答を返します。

5) ブラウザは応答を解析し、ページをレンダリングします。

6) 切断 (4 波)

ページのレンダリングとリソースのページ読み込み順序

1) ページのロード順序は上から下へ順次ロードされ、ロードとレンダリングが同時に実行されます。

2) 外部 js ファイルを参照する場合、読み込み中に <script> タグが見つかると、ブラウザはサーバーにリクエストを送信し、リクエストが返されるのを待ちます。

ブラウザーには安定した DOM ツリー構造が必要であり、document.write や appendChild を使用したり、location.href を直接使用してジャンプしたりするなど、DOM ツリー構造を直接変更するコードが JS 内に存在する可能性が非常に高いためです。 JS が DOM ツリーを変更できないようにするには、DOM ツリーを再構築する必要があるため、JS を読み込むと、後続のコンテンツのダウンロードと表示がブロックされます。

3) 埋め込み js を使用すると、すべてのコンテンツのレンダリングがブロックされます。

4) 読み込みプロセス中に <style> タグが検出されると、ブラウザは CSS または画像を要求するリクエストを送信し、リクエストの戻りを待たずに次の変換の実行を続行します。 need 返されたコンテンツを DOM ツリー内の対応する位置に配置しても問題ありません。そのため、通常、CSS はページをブロックしません ( DOM の解析はブロックしませんが、 Dom のレンダリングはブロックします)。

ただし例外もあります。CSS の後に埋め込み JS が続く場合、CSS は後続のリソースのダウンロードをブロックします。

理由: ブラウザーは HTML 内の CSS と JS の順序を維持するため、埋め込まれた JS が実行される前にスタイルシートをロードして解析する必要があります。埋め込まれた JS はその後のリソースの読み込みをブロックするため、上記の CSS ブロックダウンロードが表示されます。

ブラウザはページレンダリングプロセスを読み込みます。

ブラウザのレンダリングプロセスは次のとおりです。

1. レンダリングエンジンは、まず、要求されたドキュメントのコンテンツをネットワーク経由で取得します。

2. HTML ファイルを解析して DOM ツリーを生成します

3. CSS ファイルを解析して CSSOM (CSS Object Model) を生成します。

4. DOM TreeとCSSOMを統合してRender Tree（レンダーツリー）を生成する

5. Render Tree のレンダリングと描画に従って、ピクセルを画面にレンダリングします。

6.レイアウトレイアウト（ここでの並べ替えは、サイズや位置などを決める、ページを切り分けるようなイメージです）

7. 各ノードをレンダリングします (再描画はこのステップで行われます。そのため、再配置を再描画する必要があります。再描画は必ずしも再配置ではありません)。

js がブラウザのレンダリングをブロックするのはなぜですか?

ブラウザが DOM ツリーを構築しているときに js に遭遇すると、DOM ツリーの構築を中断し、制御を js エンジンに渡し、js の実行が完了した後も DOM ツリーの構築を続行するためです。

CSS がブラウザのレンダリングをブロックするのはなぜですか?

1) CSS はレンダリングツリーの生成をブロックします。ブロックされていない場合、CSS が読み込まれるときに再描画またはリフローが行われ、不必要なパフォーマンスの消費が発生します。

2) css は DOM ツリーの構築を直接ブロックしませんが、js の実行をブロックし、js は DOM ツリーの構築をブロックするため、css は間接的に DOM ツリーの構築をブロックします。

CSS が JS の実行をブロックするのはなぜですか?

js は CSSOM を通じてノードスタイルを読み取り、変更する必要があるため、CSSOM アーキテクチャを待ってから実行します。

主要な要約:

DOM 解析と CSS 解析は 2 つの並列プロセスであるため、CSS の読み込みによって DOM 解析がブロックされない理由もこれで説明されます。

ただし、レンダーツリーは DOM ツリーと CSSOM ツリーに依存しているため、レンダリングを開始する前に、CSSOM ツリーが構築されるまで、つまり CSS リソースの読み込みが完了する (または CSS リソースの読み込みが失敗する) まで待つ必要があります。したがって、CSS の読み込みにより Dom のレンダリングがブロックされます。

js は以前の Dom ノードと css スタイルを操作する可能性があるため、ブラウザーは html 内の css と js の順序を維持します。したがって、後続の js が実行される前に、スタイルシートが読み込まれて実行されます。したがって、css は後続の js の実行をブロックします。

スクリプトタグの async 属性と defer 属性の機能と違いは何ですか?

機能: スクリプトのロードによってブラウザのレンダリングがブロックされません。

違い：

1) defer は HTML4 標準、async は HTML5 標準

2) defer はドキュメントの順序に従ってロードおよび実行され、async はスクリプトが最初にロードされ、最初に実行されることを意味します。

3) defer は DOM ツリーの構築後に実行され、async は DOM ツリーの構築を待たずに実行されます。

リフローと再塗装

再配置が発生します。

1) ページの初期レンダリング

2) 表示される DOM 要素の追加/削除

3) 要素の位置を変更する

4) 要素のサイズを変更します (幅、高さ、内側と外側のマージン、境界線など)。

5) 要素の内容（テキストや画像など）を変更します。

6) ウィンドウサイズを変更する

再描画が発生します:outline、visibility、color、background-color等

再配置と再描画を減らす方法

リフローと再描画はパフォーマンスに多大なオーバーヘッドをもたらすため、パフォーマンスを向上させるために、開発中のリフローと再描画の回数を回避または削減するように努める必要があります。

1. リフロー/再描画を引き起こすプロパティを頻繁に読み取らないようにし、どうしても複数回使用する必要がある場合は、変数を使用してキャッシュします。

2. 複雑なアニメーションを持つ要素には絶対配置を使用して、要素がドキュメントフローから外れるようにします。そうしないと、親要素と後続の要素のリフローが頻繁に発生します。

3. DOM を頻繁に操作することを避けるために、documentFragment を作成し、すべての DOM 操作を完了して、最後にそれをドキュメントに追加します。

4. スタイルの頻繁な操作を避けるには、スタイル属性を一度に書き換えるか、スタイルリストをクラスとして定義し、クラス属性を一度に変更することをお勧めします。

基本型と参照型とは何ですか? どれがスタックにありますか? どれが山の中に入っていますか？

基本タイプ: 基本データタイプは、スタックに格納される単純なデータセグメントです (比較は値の比較です)。

文字列数値ブール値の未定義のヌル記号

参照型: 参照データ型はヒープメモリに格納されたオブジェクトです。ヒープメモリ内の特定の内容の参照アドレスはスタックメモリに格納されます。このアドレスを通じて、オブジェクトをすぐに見つけることができます (比較は比較です)。参考文献の）

配列オブジェクト関数日付

変数が参照型の値を別の変数に代入すると、スタックメモリ内の値もコピーされ、新しい変数によって割り当てられた領域に配置されますが、スタックメモリに格納される参照型の変数はアドレスです。アドレスはヒープメモリ内のオブジェクトを指しているため、この変数は実際にはアドレスをコピーし、2 つのアドレスは同じオブジェクトを指しているため、変数のいずれかを変更すると相互に影響します。

スタックメモリに格納されているアドレスはヒープメモリ内のオブジェクトを指します

JavaScript_js の基本データ型と参照型プリミティブデータ型と参照データ型_Xiaohanhan はあえてしません。ブログ-CSDN ブログ

なぜjsはシングルスレッドなのでしょうか?

JavaScript の単一スレッドはその使用に関連しています。JavaScript の主な目的は、ユーザーと対話し、DOM を操作することです。これにより、JavaScript はシングルスレッドでしか実行できないことが決まります。そうしないと、非常に複雑な同期の問題が発生します。たとえば、JavaScript に同時に 2 つのスレッドがあり、1 つのスレッドが特定の DOM ノードにコンテンツを追加し、もう 1 つのスレッドがこのノードを削除すると仮定すると、ブラウザはどちらのスレッドを基準にすべきでしょうか?

js はシングルスレッドのブロッキング問題を解決します

シングルスレッドとは、すべてのタスクをキューに入れる必要があり、次のタスクは前のタスクが完了した後にのみ実行されることを意味します。前のタスクに時間がかかると、後のタスクは永遠に待たなければなりません。キューイングの原因が大量の計算であり、CPU がビジー状態である場合は、そのことを忘れてください。ただし、IO デバイス (入出力デバイス) が非常に遅いため (Ajax 操作の読み取りなど)、ほとんどの時間 CPU はアイドル状態です。ネットワークからのデータ）の場合は、続行する前に結果が出るまで待つ必要があります。

JavaScript 言語の設計者は、現時点では、メインスレッドが IO デバイスを完全に無視し、待機中のタスクを一時停止し、最初にキューに入れられたタスクを実行できることに気づきました。IO デバイスが結果を返すまで待ってから、戻って中断されたタスクの実行を続行します。

したがって、すべてのタスクは、同期タスク (synchronous) と非同期タスク (asynchronous) の 2 種類に分類できます。同期タスクとは、メインスレッドで実行するためにキューに入れられるタスクを指します。前のタスクが実行される場合にのみ、次のタスクを実行できます。非同期タスクは、メインスレッドには入らず、「タスク」に入るタスクを指します。「キュー」（タスクキュー）タスクは、「タスクキュー」がメインスレッドに非同期タスクの実行が可能であることを通知した場合にのみ、タスクはメインスレッドに入り実行されます。

イベントループ EventLoop

同期タスクと非同期タスクは異なる実行環境に入り、メインスレッド、つまりメイン実行スタックに同期的に入り、タスクキュー (イベントキュー、メカニズムは先入れ先出し) に非同期的に入ります。メインスレッドのタスクは実行後は空になり、タスクキューに移動して対応するタスクを読み取り、それをメインスレッドにプッシュして実行します。上記の処理が連続的に繰り返されることをイベントループ (イベントループ) と呼びます。

(JS の実行時、同期タスクが発生すると、そのタスクは実行のためにコールスタックに直接プッシュされます。非同期タスクが発生すると、タスクは一時停止されます。非同期タスクが戻った後、タスクキューにプッシュされます。コールスタック内のすべてのタスクが実行され、タスクキューを1つずつPushして実行する、この一連の動作を繰り返すことをイベントループと呼びます)

①同期タスク（同期）

時間のかからないタスクとも呼ばれ、メインスレッドで実行するためにキューに入れられるタスクを指します。

次のタスクは、前のタスクが完了した後にのみ実行できます

②非同期タスク（非同期）

時間のかかるタスクとも呼ばれる非同期タスクは、JavaScript によって実行のためにホスト環境に委託されます。

非同期タスクの実行が完了すると、JavaScript メインスレッドに非同期タスクのコールバック関数を実行するように通知されます。

同期タスク: メインスレッドで実行するためにキューに入れられたタスクで、前のタスクが完了した場合にのみ次のタスクを実行できます。

非同期タスク: メインスレッドには入らないが「タスクキュー」に入るタスク。メインスレッドのタスクがすべて実行された後でのみ、「タスクキュー」内のタスクは実行のためにメインスレッドに入ります。

1. マクロタスク: setInterval() setTimeout() setImmediate() ajax イベントバインディング

2. マイクロタスク: new Promise()、新しい MutationObserver、process.nextTick の後の then and catch 関数

process.nextTick() と Promise コールバック、どちらが最初に実行されるか

process.nextTick(function(){

    console.log(7);

});

new Promise(function(resolve){

    console.log(3);

    resolve();

    console.log(4);

}).then(function(){

    console.log(5);

});

process.nextTick(function(){

    console.log(8);

});

//这段代码运行结果是3，4，7，8，5

process.nextTick()Node環境でのメソッドですので、Nodeベースでお話します。

process.nextTick()これは、どのイベントループフェーズにも属さない特別な非同期 API です。実際、ノードがこの API に遭遇すると、イベントループはまったく続行されず、すぐに実行が停止されprocess.nextTick()、実行後もイベントループが続行されます。

クロスドメインの問題解決

JSONP : jsonp の原理は、ブラウザの同一オリジンポリシーによって制限されないように script タグを使用し、バックエンドと連携してクロスドメインの問題を解決することです。

CORS : cors は、クロスドメインリソース共有です。HTTP ヘッダーに基づくメカニズムです。サーバーが自分以外の他のオリジン (ドメイン、プロトコル、ポート) をマークできるようにすることで、ブラウザーはこれらのオリジンが独自のリソースにアクセスしてロードできるようにします。 . . CORS は、Access-Control-Allow-Origin がサーバー側で設定されている場合に有効になるため、バックエンドがこの方法で CORS を実装している限り、クロスドメインの問題は解決でき、フロントエンドを構成する必要はありません。

クロスドメインを解決するためのノードプロキシサーバーの構築: 同一オリジンポリシーはブラウザによって制限されるため、サーバーリクエストサーバーはブラウザの同一オリジンポリシーによって制限されないため、プロキシする独自のノードサーバーを構築できます。サーバーへのアクセス。

一般的なプロセスは、クライアント側で独自のノードプロキシサーバーをリクエストし、ノードプロキシサーバー内のサーバーにアクセスするクライアントのリクエストをクライアントに転送して返します。また、クライアントと独自に構築したプロキシサーバーとの間ではクロスドメインの問題も発生するため、プロキシサーバーにCORSを設定する必要があります。

Nginx リバースプロキシはクロスドメインを解決します。nginx はリバースプロキシを通じてクロスドメインを解決します。これは、サーバーを使用してブラウザの同一オリジンポリシーによって制限されないようにサーバーを要求することによっても実現されます。

window.postMessage() メソッドは、クロスオリジン通信を安全に実装できます。このメソッドは、この制限を回避するための制御されたメカニズムです。正しく使用されている限り、このメソッドは非常に安全です。

主な目的は、マルチウィンドウ、マルチドキュメント通信を実現することです。

ページと開いた新しいウィンドウのデータ転送

複数のウィンドウ間でのメッセージの受け渡し

ネストされた iframe メッセージングを含むページ

概要:
jsonp の原則は、script タグはブラウザーの同一生成元ポリシーによって制限されず、img タグとリンクタグはブラウザーの同一生成元ポリシーによって制限されないということです。
クロスドメインはブラウザの制限であり、サーバー間の通信はブラウザの同一オリジンポリシーによって制限されません。
すべてのクロスドメインソリューションにはサーバーの協力が必要です。
最も一般的に使用されるクロスドメインソリューションは、CORS、ノードプロキシサーバー、および Nginx リバースプロキシです。
postMessage は、複数のドキュメントとウィンドウ間でデータを送信するためによく使用されます。

クロスドメインはいつ表示されますか

ソースポリシーが異なるとクロスドメインの問題が発生する

まず、URL は 3 つの部分で構成されます: プロトコルドメイン名ポート

リクエストURLのプロトコル、ドメイン名、ポートのいずれかが現在のURLと異なる場合、クロスドメインとなります。

v-ifとv-showの違い

1) v-if は、DOM 要素を DOM ツリーに動的に追加または削除します。

v-showはDOM要素の表示属性を設定して表示・非表示を制御します。

2) v-if 切り替えには部分的なコンパイルとアンインストールのプロセスがあり、切り替えプロセスでは内部イベントリスナーとサブコンポーネントが適切に破棄および再構築されます。

v-show は単純な CSS トグルです

3) v-if はスイッチング消費量が多く、v-show は初期レンダリング消費量が多い

4) v-if は遅延、初期条件は false で何も行わず、部分的なコンパイルが初めて行われた場合のみ条件が true になります。

v-show は任意の条件でコンパイルされ、DOM 要素によってキャッシュされて保持されます。

5) v- 動作条件が変化する可能性が低いのに適している場合

v-show は頻繁な切り替えに適しています

バインド、適用、呼び出し

1) fn.call が呼び出されると、fn の this ポイントが thisArg に渡される最初のパラメータに変更され、次のパラメータが fn に渡され、関数 fn が直ちに実行されます。

fn.call(thisArg, arg1, arg2, arg3, ...)

2) fn.apply の機能は call と同じです。この点を変更して直ちに fn を実行します。違いは、パラメータの受け渡しの形式が異なることです。apply は 2 つのパラメータを受け取ります。最初のパラメータは指す this オブジェクトで、2 番目のパラメータは配列です。配列内の要素は展開され、次の形式で fn に渡されます。 fnのパラメータ。

 apply(thisArg, [argsArr])

3) fn.bind の機能は this ポイントを変更するだけであり、fn をすぐに実行するわけではなく、this ポイントを変更した後に fn を返します。を実行するには呼び出す必要があります: bind(thisArg, arg1, arg2, arg3, ...)()。bind のパラメータの受け渡しは call の場合と同じです。

bind(thisArg, arg1, arg2, arg3, ...)

1. 同じ点
この 3 つは this の方向を変更するために使用されます;
最初に受け取ったパラメータは this が指すオブジェクトです;
それらはすべて後続のパラメータを使用してパラメータを渡すことができます。
2. 違いは、
call と apply は同じパラメータを渡し、複数のパラメータが 1 つずつ渡されることです。apply にはパラメータが
2 つだけあり、2 番目のパラメータは配列です。call
と apply は両方とも関数を直接呼び出し、bind はメソッドはすぐには呼び出されませんが、これを変更する関数を返します。

ウェブソケットについて話す

webscoket はネットワーク通信プロトコルです。http には欠陥があり、通信はクライアントによってのみ送信でき、サーバーはクライアントにメッセージを積極的に送信できません。WebSocketは全二重通信を行うため、複数タブのページ間での通信を実現できます。

Webscoket のライフサイクルとハートビートメカニズム - Holly31 のブログ - CSDN ブログ

HTTPリクエスト

HTTP リクエストとは、クライアントからサーバーへのリクエストメッセージを指します。

HTTP はハイパーテキスト転送プロトコルであり、クライアントとサーバー間のテキスト送信仕様を定義します。

HTTP リクエストには、プロトコル、リクエストメソッド、リクエストヘッダー、リクエスト本文が含まれます。

1) リクエストメソッド: get、post、put、delete、options、head、connect

2) URLアドレス

3) プロトコル名とバージョン番号

4) HTTPメッセージヘッダー

5) メッセージ本文

取得と投稿の違い

1. Get はサーバーからデータを取得するために使用され、Post はサーバーへのデータ転送に使用されます。

2. Get は、フォーム内のデータを、アクションが指す URL に、variable=value の形式で追加し、「?」を使用して 2 つを接続し、「&」を使用して各変数を接続します。Post は、フォームのデータはフォームのデータ本体に配置され、変数が値に対応する方法に従ってアクションが指す URL に渡されます。

3. Get は安全ではありません。送信プロセス中にデータがリクエストの URL に配置され、多くの既存のサーバー、プロキシサーバー、またはユーザーエージェントがリクエストの URL をログファイルに記録し、それをこのように、一部の個人情報は第三者に見られる可能性があります。また、ユーザーは提出されたデータをブラウザ上で直接見ることもでき、一部の内部システム情報がユーザーの目の前に表示されます。すべての Post 操作はユーザーには表示されません。

4. Get は URL 長の制限により送信されるデータ量が少ないのに対し、Post は大量のデータを送信できるため、ファイルをアップロードする場合にのみ Post を使用できます (もちろん別の理由があります) 、これについては後述します）。

5. Get は Form フォームのデータセットの値を ASCII 文字に制限しますが、Post は ISO10646 文字セット全体をサポートします。

6. Get は Form のデフォルトのメソッドです。

Post で送信されるデータはエンコードを設定することで正しく中国語に変換されますが、Get で送信されるデータはそのままです。今後の番組ではこの点に留意しなければなりません。

HTTP メソッド: GET と POST | チュートリアル

HTTPキャッシュ

ブラウザがWebサイトを訪問する際、初回訪問であれば様々なリソース(html・js・css・imgなど)を読み込む必要があり、その後再訪問する場合にはサーバーから再度取得する必要はありませんが、キャッシュから直接取得できるため、Web サイトのアクセス速度が向上します。

クライアントがリソースを要求する簡単なプロセス:

1) 初めてリクエストするとき、サーバーはリソースを返し、応答ヘッダーにキャッシュパラメータを示し、クライアントはリソースをキャッシュします。2) 再度リクエストするとき、最初にブラウザのキャッシュにアクセスします
。強力なキャッシュがある場合、リソースは直接抽出され、ステータスコードは 200 を返します。
3) 強力なキャッシュが見つからない場合は、サーバーにリクエストを送信して、ローカルネゴシエーションキャッシュが無効かどうかを判断し、有効な場合は 304 を返します。 4
) ネゴシエーションキャッシュがヒットしない場合、サーバーは完全なリソースを返し、キャッシュを更新します。

必須のキャッシュ: 応答ヘッダーにキャッシュ制御: max-age= (秒単位) を設定します。(cache-control: no-cache はキャッシュしません) ブラウザはファイルをローカルキャッシュに保存します。次回リソースファイルが要求されたときに、max-age の有効期限が切れているかどうかを確認します。

ネゴシエーションキャッシュ: ブラウザが Web サイトにアクセスすると、サーバーはリソースとリソース識別子を返し、ブラウザはリソースとリソース識別子をブラウザに保存し、再度 Web サイトにアクセスすると、ブラウザはリクエストとリソースを送信します。現在のバージョンがサーバーのバージョンと一致しているかどうかを判断し、一致している場合は 304 を返し、ブラウザはキャッシュからファイルを直接フェッチし、一致していない場合は 200 を返し、新しいリソースを返します。リソース ID と同時に、ブラウザはキャッシュを実行します。

ページキャッシュ（ブラウザキャッシュ）Cookie、localStorage、sessionStorageの違い

1. 保存時間の有効期限が異なります

1) Cookie の有効期間は設定可能で、デフォルトではブラウザを閉じると有効期限が切れます。

2) sessionStorage の有効期間は現在のページ上でのみ保持され、現在のセッションページまたはブラウザを閉じると無効になります。

3) localStorage の有効期間は手動で削除しなくても常に有効です

2. ストレージのサイズが異なります

1) Cookie の保存容量は約 4kb と比較的小さく、通常 1 ページに最大 20 件の情報を保存できます。

2) localStorage と sessionStorage のストレージ容量は 5Mb (公式導入、ブラウザによって多少の違いがある可能性があります)

3. サーバーとの通信

1) Cookie はサーバーとの通信に参加し、通常、一部のキーの検証など、http リクエストのヘッダーに組み込まれます。

2) localStorage と sessionStorage は純粋なフロントエンドストレージであり、サーバーとの通信には関与しません。

4. 読み書き操作の利便性

1) Cookie関連の操作、Cookieの操作が煩雑になり、一部のデータを読み取って操作できない場合があります。

//JavaScript 中，创建 cookie 如下所示：
document.cookie="username=John Doe";
//您还可以为 cookie 添加一个过期时间（以 UTC 或 GMT 时间）。默认情况下，cookie 在浏览器关闭时删除：
document.cookie="username=John Doe; expires=Thu, 18 Dec 2043 12:00:00 GMT";
//您可以使用 path 参数告诉浏览器 cookie 的路径。默认情况下，cookie 属于当前页面。
document.cookie="username=John Doe; expires=Thu, 18 Dec 2043 12:00:00 GMT; path=/";
//cookie的读取
var x = document.cookie;

2) sessionStorageの関連操作

//存储一条数据
sessionStorage.setItem('数据名', '数据值');
//读取一条数据
let data = sessionStorage.getItem('数据名');
//清除一条数据
sessionStorage.removeItem('数据名');
//移除所有数据
sessionStorage.clear();

3) localStorageの関連操作

//存储一条数据
localStorage.setItem('数据名', '数据值');
//读取一条数据
let data = localStorage.getItem('数据名');
//清除一条数据
localStorage.removeItem('数据名');
//移除所有数据
localStorage.clear();

5. ブラウザのサポート

1. Cookie は以前に登場し、現在確認されているすべてのブラウザがそれらをサポートしています。

2. localStorage と sessionStorage は遅く表示され、それより古いバージョンのブラウザーをサポートしません (たとえば、IE8 より前のバージョンはサポートしません)。

Cookieとセッションの違い

①Cookieはブラウザまたはローカルに保存でき、セッションはサーバーにのみ存在できます。
②セッションは任意のJavaオブジェクトを保存でき、Cookieは文字列型のオブジェクトのみを保存できます。Cookieの
後に攻撃することができます）
④セッションはサーバーのパフォーマンスを消費し、セッションが多すぎる、サーバーの負荷が増加します
⑤ 1 つの Cookie によって保存されるデータは 4K を超えることはできず、多くのブラウザーではサイトが最大 20 個の Cookie を保存できるように制限されています。セッションにはサイズ制限がなく、サーバーはメモリサイズに関連します。

セッションは、クライアントのステータスを記録するためのもう 1 つのメカニズムですが、Cookie がクライアントのブラウザーに保存されるのに対し、セッションはサーバーに保存される点が異なります。クライアントのブラウザがサーバーにアクセスすると、サーバーはクライアントの情報を何らかの形式でサーバーに記録します。セッションです。クライアントのブラウザが再度アクセスするときは、セッションからクライアントのステータスを見つけるだけで済みます。

Cookie とセッションの組み合わせは
これまで Web 開発で使用されており、Cookie とセッションを使用するための非常に成熟したソリューションがいくつか登場しています。今日の市場または企業では、通常、次の 2 つのストレージ方法があります。

1. サーバー側に保存: Cookie を通じて session_id を保存し、特定のデータをセッションに保存します。ユーザーがすでにログインしている場合、サーバーは session_id を cookie に保存し、次回リクエストが再度行われたときに session_id が表示され、サーバーは次に従ってセッションライブラリ内のユーザーのセッションデータを取得します。 session_id。ユーザーが誰であるか、および以前に保存されたステータス情報を知ることができます。この専門用語はサーバーサイドセッションと呼ばれます。
2. セッションデータを暗号化して Cookie に保存します。この専門用語はクライアント側セッションと呼ばれます。Flask はこのメソッドを使用しますが、他の形式で置き換えることもできます。

スリーウェイハンドシェイクの原則:

最初のハンドシェイク: クライアントは SYN (同期) フラグを持つパケットをサーバーに送信します。

2 回目のハンドシェイク: サーバーがハンドシェイクを正常に受信すると、SYN/ACK フラグを含むパケットを返して、受信したことを示す確認情報を送信します。

3 回目のハンドシェイク: クライアントは、私が知っていることを示す ACK フラグ付きのデータパケットを送り返し、ハンドシェイクは終了します。

四回手を振った

最初の波: クライアントは FIN を送信してクライアントからサーバーへのデータ送信を終了し、クライアントは FIN_WAIT_1 状態に入ります。

2 番目の波: FIN を受信した後、サーバーはクライアントに ACK を送信し、シーケンス番号が受信したシーケンス番号 + 1 であることを確認します (SYN と同様、1 つの FIN が 1 つのシーケンス番号を占有します)。サーバーは CLOSE_WAIT 状態に入ります。 ;

3 番目の波: サーバーは FIN を送信してサーバーからクライアントへのデータ送信を終了し、サーバーは LAST_ACK 状態に入ります。

第 4 の波: クライアントが FIN を受信した後、クライアントは TIME_WAIT 状態に入り、シリアル番号が受信したシリアル番号 + 1 であることを確認してサーバーに ACK を送信し、サーバーは CLOSED 状態に入ります。 4つの手を振った状態が完成します。