フロントエンドの面接問題——ネット


1、同源戦略とは何ですか.ドメイン間で解決しますか.CORSプロセスのフィールド、プロセス全体について話します.
どうげんせんりゃく
同源:ドメイン名、ポート、プロトコルはすべて同じです
ポート、プロトコル、ドメイン名(ドメイン名に対応するipであっても)のいずれかが異なると、ドメイン間を構成する.
http://www.servicea.com/first.do
http://10.28.10.13/first.do
       ip,     

ドメイン間の解決
  • JSONP :
  •     <script>           js  (     )。
      src         
    var sc = document.createElement("script");
    sc.src = "http://localhost:8888/mybatis/ScriptServlet?name=script&callback=testscript";
    document.body.insertBefore(sc,document.body.firstChild);1get  ,   post  
    2JSONP       ,         。
    
  • CORS
  •     :
      (1)              ,      ;
      (2)        ;
        :         ;
    
  • nginx逆エージェント
  •    :  nginx           ,        ;
      :   nginx      ,     。
    

    CORS
    https://blog.csdn.net/nainaiqiuwencun/article/details/83003168
    CORSは主にサーバー側の配置、サーバーの流れは以下の通りである.
    まず、要求httpヘッダにOrigin、Originが有効であるか否かを判断し(無効戻り403)、有効であればmethodが有効であるか否か(無効であれば403)、有効であればOPTION要求であるか否かを確認し、単純な要求処理ではなく、プリチェック処理である.
    単純なリクエスト処理:Allow-Origin、Allow-CRedentialsなどを返し、通常の内容を返します.
    事前検査処理:Allow-Origin、Allow-CRedentialsなどを返します.コンテンツは空で、ブラウザが次回実際のhttpリクエストを発行してからコンテンツを返します.2回目はget/postという通常のリクエストです
    1、    :
    OPTIONS /cors HTTP/1.1
    Origin: http://manage.leyou.com
    Access-Control-Request-Method: PUT
    Access-Control-Request-Headers: X-Custom-Header
    
    2、  
    Access-Control-Allow-Origin: http://manage.wzy.com
    Access-Control-Allow-Credentials: true
    Access-Control-Allow-Methods: GET, POST, PUT
    Access-Control-Allow-Headers: X-Custom-Header
    Access-Control-Max-Age: 1728000
    max-age          ,    ,     ajax           。
    

    https://blog.csdn.net/u013089490/article/details/83781384
    注:ドメイン間リクエストでクッキーを操作するには、3つの条件を満たす必要があります.
  • サービスの応答ヘッダには、Access-Control-Allow-CRedentialsを携帯し、trueである必要がある.
  • ブラウザがajaxを開始するにはwithCredentialsをtrueとして指定する必要があります.
  • 応答ヘッダのAccess-Control-Allow-Originは*ではなく、指定されたドメイン名でなければなりません.

  • 2、HTTPSプロトコル、SSLプロトコル及び完全なインタラクションプロセス
    3、http 1.1はどんな欠陥があって、私はhttp 2.0の新しい特性に答えて、更に1.1を引っ張って対比します
    1、    :http2.0HTTP/1.*     -  ,      ,    ;             ;
    HTTP/22、     :1.1    ,   ,
    3、    :      (  )    
    4、     :              index.html        ,             。
             ,       ,                         。
    

    4、クッキーのフィールド:
  • httponly:jsアクセスクッキー禁止、セキュリティ手段
  • expires:クッキーの有効期限を設定する
  • path:クッキーの送信範囲のファイルディレクトリを指定し、pathパラメータはブラウザクッキーのパスを教えます.デフォルトでは、クッキーは現在のページに属します.
  • domain:ドメイン名を設定し、一般的にye.comのような2級ドメイン名を設定すると、www.ye.comとwww.ye.comはクッキー
  • を送信することができます.
    5、sessionidはどのように発生しますか?誰から生まれたの?どこに保存しますか?
    https://blog.csdn.net/qb170217/article/details/81482057 tomcatManagerBaseクラスはsessionidを作成する方法を提供する: + +jvmid;tomcatsessionのid値生成メカニズムは、乱数に時間を加えたjvm id であり、jvmのid値はサーバのハードウェア情報に基づいて計算されるため、異なるjvmのid値は、サーバ側のメモリに格納される唯一のsessionである.ただし、sessionは、特殊な方法で永続化管理(ファイル、データベースredis)を行うことができます.
    6、4種類の一般的なPOST提出データ方式に対応するcontent-type取値enctype(encode Type)プロパティは、サーバに送信する前にフォームデータをどのように符号化すべきかを規定します.値には、application/x-www-form-urlencoded、multipart/form-data、text/plainapplication/x-www-form-urlencoded】がデフォルトのタイプであり、ブラウザはフォームから送信されたデータを「 / 」ペアの形式で符号化する
    1from  ,   enctype(  ):application/x-www-form-urlencoded 
    2、form    enctype  ::multipart/form-data  (      ,        )
        <form action="form_action.asp" enctype="multipart/form-data">
        </form>
    1,23、application/json  :           JSON    
    4、text/xml :     , xml      ,          
    

    リクエスト時にcontent-typeを設定せずに、bodyに設定されている正しいデータ型をブラウザが認識し、content-typeを変更できます.
    fetch('url', {
        method: 'POST',
        body: {
            xxx:xxx,
        },
    })
    

    ブラウザはcontent-typeを自動的にアプリケーション/jsonに変更します.
    7、応答content-Typeはjsonですが、ブラウザはどのように処理しますか?
    だからjson形式を返すなら、どちらでもいいです.
    1JSON    : 
    Content-Type = 'application/json;charset=UTF-8' 
    json     js        ,       js    ,    json   。
    
    2JS     : 
    Content-Type = 'text/javascript;charset=UTF-8' 
        js   ,             ,         eval(result)      。
              ,     js   ,     js      。                  。
    

    8、option要求用途
    サーバのパフォーマンスの確認:CORSの事前検査要求
    9、xss、csrf(タイプと防御)
    1、xss取得クッキーの防止方法: httpOnly10、ステータスコード
    ステータスコードは3桁で構成され、最初の数字は応答のカテゴリを定義し、5つの可能な値があります.
  • 1 xx:指示情報–要求が受信されたことを示し、処理を継続する.一時応答
  • 2 xx:成功–要求が正常に受信、理解、受け入れられたことを示します.
  • 3 xx:リダイレクト–要求を完了するには、さらに別の操作が必要です.
  • 4 xx:クライアントエラー–構文エラーが要求されたか、要求が実現できません.
  • 5 xx:サーバー側エラー–サーバーは正当な要求を実現できませんでした.

  • 共通ステータスコード:200(成功):サーバがリクエストを正常に処理しました.204(コンテンツなし):サーバは要求を正常に処理したが、何も返さなかった.206:一部のみ戻る
    301永久性リダイレクト:新しいウェブサイトは古いウェブサイトを完全に継承し、古いウェブサイトの順位などは完全にクリア302一時的なリダイレクト:古いウェブサイトに影響はありませんが、新しいウェブサイトは301、302の違いはありません:
    例えば、私たちの前のサイトのドメイン名はa.comで、今はb.comに置き換えられました.しかし、ユーザーはドメイン名が変更されたことを知らないので、ブラウザにa.comを入力し、Webサーバ(apacheまたはngnix)は要求を受信した後、応答にはステータスコード301およびb.comが含まれている.ユーザーのブラウザは、応答を受信すると、入力バーのウェブサイトを自動的にb.comに変更します.またはステータスコード302およびb.com.ユーザーのブラウザは応答を受信した後も、入力欄には古いウェブサイトが表示されますが、b.comの内容が表示されます.301リダイレクトは、Webページがアドレスを変更した後、検索エンジンに友好的な最善の方法であり、一時的に移動しない限り、301を使用してアドレスを変更することをお勧めします.
    304(変更なし):サーバリソースは変更されず、ブラウザ上で最新であり、ブラウザキャッシュからリソースが読み込まれます.
    400(エラーリクエスト):リクエストメッセージに構文エラーがあり、サーバはリクエストの構文を理解していません.401(無許可):http認証の欠如を要求します.ログイン後に要求されたWebページに対して、サーバがこの応答を返す可能性があります.これは、リクエストにauthorizationフィールドが必要であることを示します.403(禁止):サーバ側は要求を理解するが処理を拒否し、クライアントにアクセス権限がないと理解できる.404(見つかりません):リソースが見つかりません
    500(サーバ内部エラー)503(サービスが利用できない):サーバが現在使用できない(オーバーロードまたはダウンタイムメンテナンスのため)
    11、HTTPとHTTPSの違い
    1、ポート:HTTP 80ポート、HTTPS 443ポート2、HTTPSはCAまで証明書を取得する必要があり、大部分の証明書は有料である.HTTPは証明書3、HTTPSはSSLとTLSに基づいているが、SSLとTLSはTCP上で実行され、HTTPsのデータは暗号化されている.HTTPはTCP上で実行され、データはすべて明文伝送である.
    12、HTTP2.0
    1、多重化:一つの接続で複数の要求を並列に実行する
    2、サーバープッシュ:サーバーは一つのクライアント要求に対して複数の応答を送ることができる.サーバーはクライアントに資源をプッシュするのはクライアントの明確な要求を必要としない.伝統的な要求index.html及びその中のstyle.css、example.pngは、三回の要求を出す必要がある.しかしサーバープッシュすると、ブラウザはindex.htmlだけを要求したが、サーバーはindex.html、style.css、example.pngはすべてブラウザに送信されます.これにより、HTTP通信を1回するだけで、ブラウザはすべてのリソースを得て、性能を向上させます.
    サーバのプッシュには面倒な問題があります.プッシュするリソースファイルは、ブラウザにキャッシュがある場合は、プッシュすると帯域幅が無駄になります.プッシュするファイルのバージョンが更新されても、ブラウザはローカルキャッシュを優先的に使用します.1つの解決策は、最初に訪問したユーザーに対してのみサーバプッシュを開始することです.
    3、バイナリフレーム分け(テキストではなくバイナリを使用)HTTP 2は低遅延高スループットを実現し、肝心な一つはアプリケーション層(HTTP)と伝送層(TCP)である.間に2進分割フレーム層を1つ追加する.伝送メッセージをより小さなフレームに分割する.HTTP 1.Xのヘッダ情報ヘッダをHeadersフレームにカプセル化し、request bodyをDataフレームにカプセル化する.フレームは乱順に送信され、各フレームヘッダのストリームフラグに従って組み立てる
    4、初回圧縮HTTP 1.x通信毎(要求または応答)いずれも、リソース属性を記述するためにヘッダ情報を携帯します.HTTP 2.0は、クライアントとサービス・エンドの間でヘッダ・テーブルを使用して、以前に送信されたキー値ペアを追跡および格納します.同じデータに対して、要求および応答のたびに送信を再開しません.新しいヘッダ・キー値ペアごとに、現在のテーブルの最後に追加するか、テーブルの前の値を置き換えます.ヘッダ・テーブルのHTTP 2.0へのリンク保存期間中は常に存在し、クライアントとサービス側が共同で漸進的に更新します.
    5、要求優先度ストリームごとに31 bitの優先値を持つことができる:0は最高優先度を表し、2^31-1は最低優先度を表す.クライアントは優先度を明確に指定し、サービス側はこの優先度に基づいてインタラクティブデータの根拠とすることができ、例えばクライアントは.css>.js>.jpgを優先する.サービス側はこの順序で結果を返すことで時間を節約し、ユーザー体験を高める.
    6、流量制御
    11、sql注入
       : ‘or 1 = 1 –—
      :
       sql    username='' and --     
    

    解決方法:
    	123、sql    : java  PreparedStatement
    		connection conn = this.getconnection();
    		string strsql = "select emp_id from employee where emp_id = ?";
    		preparedstatement pstmt = conn.preparestatement(strsql);
    		pstmt.setstring(1,"pma42628m"); //  1  
    		resultset rs = pstmt.executequery();