1. コールバックを通じて非同期データを取得できるのはなぜですか? コールバック関数を理解するにはどうすればよいですか?
最初、コールバック関数が非同期データを取得できることは知っていましたが、データを取得する方法についてはよくわかりませんでした。今日、ブロガーの説明を読みました。非常に優れています。実際、理解するのは簡単です。コールバック関数関数は文字通り、後で呼び出すことを意味します。コールバックの文字通りの意味は、コールバックすることです。コールバック関数には通常、ある関数をパラメータとして別の関数に渡すという基本条件があります。たとえば、関数 A がパラメータとして関数 B に渡されるの場合、A は B のコールバック関数です。
2. では、コールバック関数は何に役立つのでしょうか? また、なぜ非同期データを取得できるのでしょうか?
コールバック関数は関数の実行を保証します。たとえば、最初に 1 を出力し、次に 2 を出力する場合、1 が時間のかかる操作である場合、js のイベント ループによれば、結果は 2 になることがわかります。 1 は、時間のかかる操作、つまり非同期操作が行われるため、実行を待つためにブラウザにスローされますが、print 2 を print 1 関数のコールバックとして使用すると、関数の実行順序を変更できます。保証されており、これは常に 1 2 です。では、なぜ 2 番目のものは非同期データを取得できるのでしょうか? ここでずっと誤解していたのですが、コールバック関数も非同期タスクなので非同期データが取得できると思っていましたが、実際はそうではありません。コールバック関数は同期タスクですが、内部に配置されているためです。非同期タスク、同期コードなのにラップされている 非同期タスクなので明日やるのと同じ 同期しても今日は反映できない まだ順番ではない コードの通り以下の例では、callback() は同期タスクですが、内部の非同期メソッド setTimeout. に配置されているため、すぐには実行されません。非同期タスクの実行を待機しているとき、すぐに 2 つの同期タスクが存在します: console (1) そして、コールバック関数を呼び出します。これが、コーヒーを作るのは時間がかかるプロセスであるため、コーヒーショップに行って注文するのと同じ非同期データを取得できる理由です。電話番号を残して買い物に行き、それを待ちます。彼にコールバック電話をかけ、待ち時間を買い物に充てることができます。ここに残した電話番号はコールバックです( ) 関数。コーヒーの準備ができたときにのみ、彼はあなたに電話します。これは関数を呼び出すのと同じです。電話番号はあなたです。店員があなたに電話をかけると、書かれた関数が実行されます。
コード例:
function print1(){
console.log(1)
}
function print2(){
console.log(2)
}
耗时操作：
function print1(){
setTimeout(()=>{
console.log(1)
},500)
}
函数作为参数(保证函数的执行顺序)：
function print1(callback){
setTimeout(()=>{
console.log(1)
callback()
},500)
}
function print2(){
console.log(2)
}
print1(print2)3. JavaScript はなぜシングルスレッドなのでしょうか?
JavaScript の主な目的はユーザーと対話して DOM を操作することであるため、ユーザーが情報を追加してから削除する場合は、削除操作を実行する前にまず情報を生成する必要があります。一度に 1 つずつ実行すると、一部のタスクは非常に時間がかかり、コードの実行がブロックされます。たとえば、視聴中にビデオを開くと、ビデオの読み込みに時間がかかることがありますが、それでも実行できます。いいねと投票があったのでコードを入れます さらに同期コードと非同期コードに分かれます 同期コードは実行のためにすぐにJSエンジン(jsメインスレッド)に参加して待機しますが、非同期コードは最初にJSエンジン(jsメインスレッド)に入れられます。ホスト環境 (通常は非同期タスクを処理するブラウザ環境)、待機する必要がなく、メインスレッドのブロックがなく、非同期結果は将来実行されます。
4. マクロタスクとは何ですか? マイクロタスクとは何ですか?
コードは同期コードと非同期コードに分けられ、非同期コードはマクロタスクとマイクロタスクに分けられます。
マクロ タスクには、スクリプト (コード全体)、seTimeout、setInterval、setImmediate、I/O (Ajax リクエストとバックグラウンドへのデータ送信はすべてマクロ タスクです) などが含まれます。
マイクロタスク：promise.then() catch() (promise自体は同期、非同期はそのthenとcatch) process.nextTick()(node)、async/await、object.observeなど。
次の図は、js イベント ループとは何かを説明し、イベント ループが存在する理由も説明します。
クロスドメインの問題:
クロスドメインの問題はブラウザに基づいています。ブラウザには同一オリジン ポリシーが存在するため、最初に同一オリジン ポリシーとは何かを紹介します。同一オリジン ポリシーはブラウザにとって重要なセキュリティ ポリシーです。ソースは次のとおりです。プロトコル、ホスト名、ポート番号の情報です。はい、通常、フロントエンドはバックグラウンド データをリクエストするときにインターフェイスを設定する必要があります。リクエストするインターフェイスは、実際には Baseurl + インターフェイス名で構成されます。では、Baseurl とは何ですか? これは私が呼びたい名前です。たとえば、必要なデータをhttp://test.yee.com/auth/role/listアドレスからリクエストする必要がある場合、
この URL を分析します。最初のものはプロトコル名です。通常よく見るのは http と https です。次はドメイン名 (ホスト名) です。ドメイン名 (ホスト名) はリソースを要求する場所です。 IP は、自分でテストするときにデータを提供するローカル サーバーを作成する場合、このドメイン名 (ホスト名) の IP が私たち自身のコンピューターの IP になります。平たく言えば、私たちのアドレスです。リソース、仮想ディレクトリ部分はフロントエンドに多くの連絡先があります。これは API で設定するインターフェイス アドレスです。実際、ローカル ディレクトリと類似して理解できます。ネットワーク リクエストにはセキュリティと検証の問題があるため、先頭には追加のプロトコルがあります。実際、プロトコル + ドメイン名 (ホスト名) はルート ディレクトリとしてローカル ディレクトリとして認識され、仮想アドレスはローカル リソースを取得するために通常使用するパスです。URL にアクセスするということは、外部サーバーからデータを取得します。URL はデータを取得するためのパスです。リソースの後に、それをユーザーに表示する方法については、フロントエンドの作業部分です。その後、戻って完全な URL を導入します。完全な URL は通常、次のようになります: http://www.example.com:8080/role/list? name=123&password=123456#people
完全な URL。これはそのすべてのコンポーネントです。
1. 同意:
プロトコルとしては http と https が一般的ですが、http で送信されるデータは平文であることが多く、一度データを乗っ取られると相手に簡単に情報を知られてしまうリスクがあるため、より機密性の高い情報の送信には適していません。 httpsはhttpを暗号化したもので、送信情報をSSLで暗号化することで、たとえ相手がデータを乗っ取っても直感的にその内容を理解することができません。暗号文を平文に変換すると、区切り文字として // で終わる対称暗号化、非対称暗号化、デジタル証明書、一方向認証および双方向認証など、検討する価値のあるものが数多くあります。
2. ドメイン名（ホスト名）：
www.example.comは URL のドメイン名部分です。ドメイン名は一般にwww.bilibili.com、www.baidu.comなどのようにある程度の認知度がありますが、ここで注意すべき点があります。たとえば、サーバーをローカルで起動すると、ドメイン名またはホスト番号が IP になります。たとえば、192.168.31.1 はホスト番号です。ここでデータを直接リクエストできますが、ここでのドメイン名はホスト番号や IP ではありませんこれには、DNS ドメイン名解決という別の知識ポイントが関係します。したがって、その機能は、2 つの IP 間の通信を確立し、アドレスに基づいて対応する IP アドレスを見つけるため、実際にはドメイン名を対応する IP アドレスに解決することです。ドメイン名は、マッピング関係に似ています。なぜでしょうか。これを行うのは簡単です。たとえば、www.bilibili.com をしばらく覚えているかもしれませんが、 www.192.168.31.1.comの場合、認識率は非常に低く、区別するのが難しいため、この手順でドメイン名を入力すると、対応する Web サイトを見つけることができるのは、DNS ドメイン名解決のプロセスがあるためです。
3.ポート:
ポートについてはあまり理解していません。デフォルトのポート番号は 80 または 8080 です。nodejs を使用してサーバー側のコードを記述するときは、最初に検出用のポート番号を記述する必要があります。ここにガイドがあります。ハードウェア ドメインでは、ポートはインターフェイスとも呼ばれることを理解するのに役立ちます。
4. 仮想ディレクトリ部分: (URL の必須ではない部分)
仮想ディレクトリは、ドメイン名の最初の / から最後の / までが、フロントエンド開発用のインターフェイス アドレスです。コンピュータを使用する人にとっては、ローカル ディレクトリが理解できます。これは必須の部分ではありません。たとえば、そうでない場合は、ここに書かれている場合、通常は Web サイトのホームページまたはログインページにアクセスすることを意味します
5.パラメータ部分:
パラメータ部分はどこから？先頭の#部分は検索部、クエリ部とも呼ばれます。通常、パラメータには複数のパラメータを使用でき、パラメータは & で区切られます。http://www.baidu.com/?wd=空腹時に食べてもいいですか? これは例です。空腹時に食べてもいいですか? パラメータ部分はパラメータ名 wd とパラメータ値で構成されています。ただし、プレーン テキストで表示するのは一般に安全ではないため、アカウント パスワードなどのデータの送信には通常使用できません。私の写真 例えば、平文が表示されれば、あなたの重要な情報が一目で他人に知られてしまいますが、今、魔法の場所を発見しました。Baidu から平文が含まれる URL をコピーして貼り付け、暗号化します。単純に暗号化する必要があるため、平文コンテンツを取得することが困難になります。
6. アンカー部分: (詳細な説明は見つかりません)
#の先頭から最後まではCSSでアンカージャンプというものがあり、divのclass属性をid="people"とし、リンクにhref="#prople"を指定して、クリックしてジャンプします div 位置に移動します。ページに入ったときに画面をフリーズさせる場所はここだと理解していますか? 通常は設定せずに一番上にありますが、一番下の要素に定義しておくと、入ってきた瞬間に自動的に一番下に描画されるのではないかと思います。
ここでは、URL の完全なコンポーネントを紹介しました。主な目的は、ポート番号を紹介することです。一般的に、URL では、また URL のコピー アンド ペーストのプロセス中にポート番号を確認できないためです。少し馴染みがないかもしれません。 -ドメインの問題は主に プロトコル、ドメイン名、ポート番号はそれぞれ異なりますが、前述したように送信元はこの 3 つで決まりますが、なぜこのようなセキュリティ ポリシーがあるのでしょうか。ブラウザには比較的重要な情報が含まれているため、アカウントとパスワードはサーバー上に保存されていますが、ブラウザにはCookieと呼ばれる重要なものが保存されています。引き続き、サーバーはクライアントに Cookie を返します。この Cookie を使用すると、クライアントは次回検証なしでサーバーに直接データを要求できます。ブラウザーに同一オリジン ポリシーがない場合、サーバーはローカルで動作します。 JS コードを介したブラウジング。サーバーは別のサーバーとの間で Cookie を取得し、ログインをバイパスして別のサーバーとの接続を確立できるため、ユーザーの ID を使用して悪事を行うことができます。これを防ぐには、 、ブラウザは基本的な保護である同一生成元ポリシーを策定しています。
クロスドメインの問題にどう対処するか? 一般に 3 つの解決戦略があります
1.JSONPの原則:
実際、<script><link><img> の src には画像リソース接続や JS 外部リンクなどを記入できるだけでなく、インターフェイス URL にリンクすることもできますが、コールバック関数の関数名は必要ですデータを返すときに、コールバック関数を呼び出す js コードを返し、そのデータをパラメータとして返すことで、返されたデータを取得できるようにするため、サーバーは、 get リクエストのみを開始できますが、post などは開始できません。
2.コル：
これは最も基本的な解決策であると言われており、バックエンド プログラマーが cors 構成を実装する必要があります。
3.proxy プロキシ (通常はローカル開発に使用されます)
日常の開発で最も一般的に使用されるプロキシは、プロキシを構成することです。その原理も非常に単純です。クライアントがクロスドメイン Web サイトからリソースを要求すると、クライアントは要求をインターセプトし、ローカル サーバー経由でターゲット サーバーにネットワーク リクエストを送信します。プロキシサーバー. 以前に苦労して紹介した同一オリジンポリシーはブラウザベースであり、サーバー間には存在しません. 少し説明を加えたいと思います. 実は同一オリジンポリシーの影響で、クライアントは引き続きデータをサーバーに送信します。サーバーも応答しましたが、返されたデータがクライアントに到達したときに、クライアントによって拒否されました。
4. 質問の提起と調査:
このような疑問を持つ人はいるでしょうか。同一生成元ポリシーの目的はセキュリティ問題を解決することではないでしょうか? では、プロキシ サーバーが同一オリジン ポリシーを回避すると、サーバー A は Cookie の存在を取得できなくなりますか? このように、Cookie とセッションのいくつかの概念を詳しく紹介する必要があります (おそらく基礎がしっかりしておらず、この概念が忘れられているため、この質問が生じます)
サーバー上に存在するものをセッションと呼び、クライアント上に存在するクッキーは、クッキーがキー、セッションがロックであると理解でき、プロキシサーバーからデータを取得してもセキュリティ上問題がない理由が説明できます。ブラウザの同一オリジン ポリシーにより、サーバー A はサーバー B からブラウザに送信された Cookie をブラウザ経由で取得できませんが、プロキシ サーバーから取得できるでしょうか。プロキシ サーバーはネットワーク リクエストの転送に役立ちますが、サーバー B にブラウザに提供した Cookie を要求することはできません。冒頭で、セッションと Cookie はサーバーとブラウザーの間にのみ存在すると紹介しました。サーバーとサーバーの間にはセッションのみが存在します。2 つのロックは相互に開くことはできません。これは明らかに不合理なので、この方法で回避できます。同一生成元ポリシーを適用し、対応するロックを取得すると、サーバー上のデータが保存され、ブラウザーが懸念するセキュリティ問題が回避されます。
nginx リバースプロキシもありますが、私のレベルが低いため、対応する知識をまだカバーしていませんが、知っている場合はできるだけ早く共有します。