Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?-Soal Jawab bahagian hadapan-php.cn

Artikel ini akan berkongsi dengan anda beberapa soalan temu bual tentang penyemak imbas. Lihat berapa banyak yang anda boleh jawab? Analisis jawapan yang betul dan lihat berapa banyak yang anda boleh dapatkan dengan betul!

Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?

Apakah inti pelayar biasa?

Inti penyemak imbas boleh dibahagikan kepada dua bahagian:

渲染引擎 dan JS引擎 (Nota: kami sering berkata Teras penyemak imbas merujuk kepada enjin rendering)

Apabila enjin JS menjadi semakin bebas, teras hanya merujuk kepada enjin rendering Enjin rendering digunakan terutamanya untuk meminta sumber halaman rangkaian untuk dihuraikan dan ditaip sebelum disampaikan kepada pengguna

浏览器/RunTime	内核（渲染引擎）	JavaScript 引擎
Chrome	Blink（28~） Webkit（Chrome 27）	V8
FireFox	Gecko	SpiderMonkey
Safari	Webkit	JavaScriptCore
Edge	EdgeHTML	Chakra（For JavaScript）
IE	Trident	Chakra（For JScript）
Opera	Presto->blink	Linear A（4.0-6.1）/ Linear B（7.0-9.2）/ Futhark（9.5-10.2）/ Carakan（10.5-）
Node.js	-	V8

2. Apakah komponen utama pelayar?

Antara muka pengguna: termasuk bar alamat, ke hadapan/belakang/refresh/penanda halaman dan butang lain
Enjin penyemak imbas: dalam antara muka pengguna dan enjin pemaparan Pindahkan arahan antara
Enjin pemaparan: digunakan untuk melukis kandungan yang diminta
Rangkaian: digunakan untuk menyelesaikan panggilan rangkaian, seperti permintaan http, ia Mempunyai antara muka bebas platform dan boleh berfungsi pada platform yang berbeza
JavaScript penterjemah: digunakan untuk menghuraikan dan melaksanakan kod JavaScript
Ujung belakang antara muka pengguna : Digunakan untuk melukis widget asas, seperti kotak kombo dan tingkap Lapisan bawah menggunakan antara muka pengguna sistem pengendalian
Storan data: Ia tergolong dalam lapisan kegigihan dan penyemak imbas menyimpan. kuki serupa pada cakera keras Untuk pelbagai data, HTML5 mentakrifkan teknologi pangkalan data web, yang merupakan teknologi storan sisi pelanggan yang ringan dan lengkap

Nota : Tidak seperti kebanyakan penyemak imbas, setiap tab dalam Google Chrome sepadan dengan contoh enjin pemaparan. Setiap tab adalah proses bebas

Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?

3. Mari kita bincangkan tentang apa yang berlaku daripada memasukkan URL ke pemaparan halaman Apa?

Soalan ini boleh dikatakan sebagai soalan yang paling biasa dalam temu bual dan boleh menjadi sangat sukar Secara amnya, penemuduga bertanya soalan ini untuk menguji kedalaman pengetahuan bahagian hadapan anda.

1 Penyemak imbas menerima URL dan membuka rangkaian permintaan rangkaian (melibatkan: mekanisme penyemak imbas, rangkaian dan proses, dsb.)

2 permintaan http lengkap (Melibatkan: pertanyaan DNS, permintaan TCP/IP, protokol rangkaian 5 lapisan, dll.)

3 Terima permintaan daripada pelayan ke bahagian belakang yang sepadan (melibatkan: pengimbangan beban, pemintasan keselamatan, pemprosesan dalaman bahagian belakang dll.)

4 Interaksi HTTP antara bahagian belakang dan hujung hadapan (melibatkan: pengepala http, kod respons, struktur mesej, kuki, dll.)

5. melibatkan: http cache kuat Rundingkan cache, pengepala cache, etag, tamat tempoh, kawalan cache, dsb.)

6. Proses penghuraian selepas pelayar menerima paket http (melibatkan analisis leksikal html, menghuraikan ke dalam pepohon DOM , menghuraikan pokok CSSOM generasi CSS digabungkan untuk menjana pepohon pemaparan Kemudian reka letak, pemaparan lukisan, sintesis lapisan komposit, lukisan GPU, pemprosesan pautan luaran, dll.)

7. Model visual CSS (melibatkan: peraturan pemaparan elemen. , seperti: Mengandungi blok, kotak kawalan, BFC, IFC, dsb.)

8. Proses penghuraian enjin JS (melibatkan: fasa penghuraian JS, fasa prapemprosesan, fasa pelaksanaan untuk menjana konteks pelaksanaan, VO (objek global ), rantai skop , mekanisme kitar semula, dsb.)

Anda akan mendapati bahawa terdapat begitu banyak proses yang berlaku antara URL input mudah dan pemaparan halaman Adakah anda berasa seperti terhantuk sekejap? (Jangan risau, kami tidak akan melakukan ini dalam bab ini. Biar saya mengajar anda cara menjawab soalan ini dahulu. Bahagian ini akan dibincangkan dalam artikel berasingan)

Pelayar memperoleh alamat IP nama domain melalui pelayan DNS dan memintanya daripada alamat IP ini teks HTML
Proses pemaparan penyemak imbas menghuraikan teks HTML dan membina pepohon DOM
. Semasa menghuraikan HTML, jika ia menemui gaya sebaris atau fail gaya, ia memuat turun dan membina skrip JavaScript gaya, skrip pelaksanaan akan dimuat turun
Selepas pepohon DOM dan CSSOM dibina, proses pemaparan akan menggabungkan. dua menjadi pokok render (pokok render)
Proses rendering mula menyusun pokok rendering
Pokok rendering melukis pokok reka letak dan menjana rekod lukisan

Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?

4. Bagaimanakah penyemak imbas menghuraikan kod?

Menghuraikan HTML

HTML dihuraikan baris demi baris dan enjin pemaparan penyemak imbas akan menghuraikan dan menukar dokumen HTML kepada nod DOM.

Menghuraikan Token menjadi objek
Menggabungkan objek menjadi pokok DOM

Menghuraikan CSS

Pelayar akan menghuraikan pemilih CSS dari kanan ke kiri

Kami tahu bahawa pokok DOM dan pokok CSSOM digabungkan ke dalam Pokok render sebenarnya melampirkan CSSOM pada pokok DOM, jadi pokok DOM perlu dilalui berdasarkan maklumat yang diberikan oleh pemilih.

Mari kita lihat contoh:

<style>
.nav .title span {color:blue}
</style>

<div class=&#39;nav&#39;>
  <div class=&#39;title&#39;>
    <span>南玖</span>
  </div>
  <div class="sub_title">前端</header>
</div>

Salin selepas log masuk

Padanan kanan-ke-kiri:

Mula-mula cari semua rentang nod paling kanan, untuk setiap Satu span, cari ke atas untuk nod div.title
dari h3 dan kemudian cari ke atas untuk nod div.nav
dan akhirnya cari elemen akar html dan akhir Traversal cawangan ini.

Menghuraikan JS

Terdapat alat penghurai js dalam penyemak imbas, yang digunakan khas untuk menghuraikan js kami kod.

Apabila penyemak imbas menemui kod js, ia segera memanggil "penghurai js" untuk berfungsi.

Penghuraikan akan mencari semua pembolehubah, fungsi, parameter, dsb. dalam js dan menetapkan nilai pembolehubah kepada tidak ditentukan.

Keluarkan fungsi ke dalam blok fungsi dan simpan di dalam gudang. Selepas ini dilakukan, kod mula dihuraikan baris demi baris (dari atas ke bawah, kiri ke kanan), dan kemudian dipadankan dengan gudang.

5 Apakah perbezaan antara DOMContentLoaded dan load?

DOMContentLoaded: Dicetuskan hanya selepas penghuraian DOM selesai, tidak termasuk helaian gaya, imej dan sumber lain.
Muat: Dicetuskan apabila semua DOM, helaian gaya, skrip, imej dan sumber lain pada halaman telah dimuatkan.

6. Apakah perbezaan antara lukisan semula penyemak imbas dan penyusunan semula domain?

Penyusunan Semula: Sebahagian daripada pokok rendering atau keseluruhan pokok rendering perlu dianalisis semula dan saiz nod perlu dikira semula, yang bermaksud menjana semula reka letak dan menyusun semula elemen
Melukis semula: Disebabkan oleh perubahan dalam sifat geometri nod atau perubahan gaya, seperti elemen latar belakang elemen, penampilan beberapa elemen diubah

Melukis semula tidak semestinya Menyebabkan aliran semula, tetapi aliran semula mesti membawa kepada lukisan semula

Bagaimana untuk mencetuskan lukis semula dan aliran semula?

Sebarang perubahan pada maklumat yang digunakan untuk membina pepohon pemaparan akan menyebabkan pengaliran semula atau pengecatan semula:

Tambah, padam, kemas kini nod DOM
Sembunyikan nod DOM melalui paparan: tiada - mencetuskan pengaliran semula dan cat semula
Sembunyikan nod DOM melalui keterlihatan: tersembunyi - hanya mencetuskan cat semula, kerana tiada perubahan geometri
alih atau berikan Tambahkan animasi ke Nod DOM dalam halaman
Tambah helaian gaya dan laraskan atribut gaya
Tingkah laku pengguna, seperti mengubah saiz tetingkap, menukar saiz fon atau menatal.

Bagaimana untuk mengelakkan lukisan semula atau pengaliran semula?

Tukar gaya secara kolektif: Contohnya, gunakan kelas untuk menukar gaya secara kolektif
Gunakan document.createDocumentFragment(): Kita boleh Cipta nod di luar pepohon DOM melalui createDocumentFragment, kemudian laksanakan operasi kelompok pada nod ini, dan akhir sekali masukkan ia ke dalam pepohon DOM, jadi hanya satu penyusunan semula dicetuskan
Dipromosikan ke lapisan gubahan
Mempromosikan elemen kepada lapisan komposit mempunyai kelebihan berikut:
- Peta bit lapisan komposit akan disintesis oleh GPU, yang lebih pantas daripada pemprosesan CPU
- Apabila repaint diperlukan, hanya repaint itu sendiri diperlukan dan tidak akan menjejaskan lapisan lain
- Untuk transform dan opacity kesan, tidak akan mencetuskan layout dan paint
  Cara terbaik untuk meningkatkan lapisan gubahan ialah menggunakan sifat CSS will-change

7. Mengapa JS berbenang tunggal?

Ini terutamanya berkaitan dengan tujuan JS Sebagai bahasa skrip penyemak imbas, JS pada mulanya digunakan terutamanya untuk merealisasikan interaksi antara pengguna dan penyemak imbas dan untuk mengendalikan DOM. Ini menentukan bahawa ia hanya boleh berbenang tunggal, jika tidak, ia akan membawa banyak masalah penyegerakan yang kompleks.

Contohnya: Jika JS berbilang benang, satu utas mahu mengubah suai elemen DOM dan satu lagi urutan mahu memadamkan elemen DOM, maka penyemak imbas tidak tahu apa yang perlu dilakukan Siapa yang anda dengar? Oleh itu, untuk mengelakkan kerumitan, JavaScript telah direka bentuk untuk menjadi satu benang sejak ia dilahirkan.

Untuk memanfaatkan kuasa pengkomputeran CPU berbilang teras, HTML5 mencadangkan piawaian Pekerja Web, yang membenarkan skrip JavaScript mencipta berbilang rangkaian, tetapi urutan anak dikawal sepenuhnya oleh rangkaian utama. benang dan tidak boleh mengendalikan DOM. Oleh itu, piawaian baharu ini tidak mengubah sifat berbenang tunggal JavaScript

8. Adakah pemuatan CSS menyekat DOM?

Kesimpulan pertama

CSS tidak akan menyekat penghuraian DOM, tetapi ia akan menyekat DOM Paparan
CSS akan menyekat pelaksanaan JS, tetapi tidak akan menyekat muat turun JS fail

Peranan CSSOM

Pertama ialah menyediakan JavaScript dengan keupayaan untuk mengendalikan helaian gaya
The kedua ialah untuk pepohon susun atur Sintesis menyediakan maklumat gaya asas
CSSOM ini ditunjukkan dalam DOM sebagai document.styleSheets

Kami menggunakan pemaparan penyemak imbas proses yang disebut sebelum Ia boleh dilihat:

DOM dan CSSOM biasanya dibina secara selari, jadi Pemuatan CSS tidak akan menyekat penghuraian DOM
Pokok render bergantung pada pokok DOM dan pokok CSSOM, jadi ia mesti menunggu sehingga kedua-duanya dimuatkan sebelum ia boleh mula membina pemaparan, jadi Pemuatan CSS akan menyekat pemaparan DOM
Memandangkan JavaScript boleh mengendalikan DOM dan CSS, jika anda mengubah suai sifat elemen ini dan memaparkan antara muka pada masa yang sama (iaitu, utas JavaScript dan utas UI diteruskan pada masa yang sama ), elemen yang diperoleh sebelum dan selepas benang pemaparan mungkin tidak konsisten. Oleh itu, untuk mengelakkan hasil pemaparan yang tidak dijangka, penyemak imbas menetapkan benang pemaparan GUI dan utas JavaScript untuk mempunyai hubungan yang saling eksklusif

JS memerlukan Menunggu CSS dimuat turun, mengapa ini? (CSS menyekat pelaksanaan DOM)

Jika kandungan skrip JS adalah untuk mendapatkan gaya elemen, maka ia mesti bergantung pada CSS. Oleh kerana penyemak imbas tidak dapat merasakan apa yang berlaku di dalam JS, untuk mengelakkan pemerolehan gaya, ia perlu menunggu sehingga semua gaya sebelumnya dimuat turun sebelum melaksanakan JS. Walau bagaimanapun, fail JS dan fail CSS dimuat turun secara selari, dan fail CSS akan dimuatkan dan dilaksanakan sebelum fail JS berikutnya dilaksanakan, jadi CSS akan menyekat pelaksanaan JS berikutnya

Elakkan skrin putih dan tingkatkan kelajuan pemuatan CSS

Gunakan CDN (CDN akan memilih nod terdekat dengan kandungan cache untuk memberikan anda sumber berdasarkan rangkaian anda syarat) , jadi masa pemuatan dapat dikurangkan)
Mampatkan CSS
Gunakan cache dengan sewajarnya
Kurangkan bilangan permintaan http dan gabungkan fail CSS

9 Adakah .JS akan menyekat halaman?

Kesimpulan pertama

JS akan menyekat penghuraian DOM, oleh itu ia juga akan menyekat pemuatan halaman

Inilah sebabnya kami sering mengatakan bahawa kami harus meletakkan fail JS di bahagian bawah

Memandangkan JavaScript boleh memanipulasi DOM, jika anda mengubah suai atribut elemen ini dan render antara muka pada masa yang sama ( Iaitu, thread JavaScript dan thread UI dijalankan pada masa yang sama), maka data elemen yang diperoleh sebelum dan selepas thread rendering mungkin tidak konsisten.

Oleh itu, untuk mengelakkan hasil pemaparan yang tidak dapat diramalkan, penyemak imbas menetapkan perhubungan **"benang pemaparan GUI dan enjin JavaScript adalah saling eksklusif"**.

Apabila enjin JavaScript sedang dilaksanakan, urutan GUI akan digantung dan kemas kini GUI akan disimpan dalam baris gilir dan dilaksanakan serta-merta apabila utas enjin melahu.

Apabila penyemak imbas melaksanakan program JavaScript, urutan pemaparan GUI akan disimpan dalam baris gilir dan tidak akan dilaksanakan sehingga program JS selesai.

Oleh itu, jika masa pelaksanaan JS terlalu lama, ia akan menyebabkan pemaparan halaman menjadi tidak konsisten, mengakibatkan perasaan bahawa pemaparan dan pemuatan halaman disekat.

10. Apakah perbezaan antara tangguh dan async?

Kedua-duanya memuatkan fail JS luaran secara tidak segerak dan tidak akan menyekat penghuraian DOM
Async dilaksanakan selepas pemuatan JS luaran selesai, apabila penyemak imbas melahu dan sebelum Muatkan peristiwa dicetuskan , skrip yang ditandakan sebagai async tidak dijamin akan dilaksanakan mengikut urutan yang ditetapkan Atribut ini tidak mempunyai kesan pada skrip sebaris (iaitu, skrip tanpa atribut "src".
tangguh dilaksanakan selepas JS dimuatkan, selepas keseluruhan dokumen dihuraikan dan sebelum acara DOMContentLoaded dicetuskan Jika atribut src (iaitu, skrip sebaris) tiada, atribut ini sepatutnya tidak boleh digunakan kerana ini Ia tidak berfungsi dalam kes ini

11. Mekanisme kutipan sampah penyemak imbas

Pengumpulan sampah ialah mekanisme pengurusan memori automatik. Memori dinamik pada komputer anda harus dikeluarkan apabila ia tidak diperlukan lagi.
Perlu diingatkan bahawa automatik bermakna penyemak imbas secara automatik boleh membantu kita mengitar semula sampah memori, tetapi ini tidak bermakna kita tidak perlu mengambil berat tentang pengurusan memori Jika tidak dikendalikan dengan betul, limpahan memori akan tetap berlaku dalam JavaScript, menyebabkan ranap sistem.

Memandangkan rentetan, tatasusunan, objek, dll. tidak mempunyai saiz tetap, ia perlu diperuntukkan secara dinamik apabila saiznya diketahui. Setiap kali program JavaScript mencipta rentetan, tatasusunan atau objek, penterjemah mesti memperuntukkan memori untuk menyimpan entiti tersebut.

Jurubahasa JavaScript boleh mengesan apabila program tidak lagi menggunakan objek Apabila ia menentukan bahawa objek itu tidak berguna, ia tahu bahawa objek itu tidak lagi diperlukan dan boleh melepaskan memori yang didudukinya.

Terdapat dua kaedah pengumpulan sampah yang biasa digunakan oleh penyemak imbas: pembersihan tanda, pengiraan rujukan.

Pembersihan tanda

Ini ialah kaedah pengumpulan sampah yang paling biasa digunakan dalam JavaScript

Sejak 2012 Sejak 2007, semua penyemak imbas moden telah menggunakan kaedah pengumpulan sampah tanda dan sapu, kecuali untuk versi IE yang lebih rendah, yang masih menggunakan kaedah pengiraan rujukan.

Jadi apakah itu penyingkiran tanda?

Terdapat objek global dalam JavaScript Secara berkala, pengumpul sampah akan bermula dari objek global ini, mencari semua objek yang dirujuk dari objek global ini, dan kemudian mencari objek yang dirujuk oleh ini. objek. Objek... tandakan objek aktif ini, ini adalah fasa penandaan. Peringkat pembersihan adalah untuk membersihkan objek yang tidak ditanda.

Ada masalah dengan pembersihan tanda iaitu selepas pembersihan ruang memori tidak berterusan iaitu pemecahan memori berlaku. Jika ruang memori berterusan yang agak besar diperlukan kemudian, ia tidak akan memenuhi keperluan. Kaedah pengisihan tag boleh menyelesaikan masalah ini dengan berkesan.

Dalam proses penandaan, konsep penandaan tiga warna diperkenalkan Tiga warna tersebut ialah:

Putih: objek tidak bertanda, iaitu objek tidak boleh dicapai (bukan objek diimbas. ), boleh dikitar semula
Kelabu: Objek telah ditanda (objek boleh dicapai), tetapi objek belum diimbas lagi dan tidak boleh dikitar semula
Hitam: Objek telah diimbas (boleh dicapai) ), tidak boleh dikitar semula

Isih teg:

Fasa penandaan tidak berbeza dengan kaedah pembersihan tanda, kecuali selepas penandaan selesai, kaedah pembersihan penandaan akan mengalihkan objek yang masih hidup ke satu sisi memori, dan akhirnya membersihkan memori sempadan.

Pengiraan rujukan

Maksud pengiraan rujukan ialah menjejak bilangan kali setiap nilai dirujuk. Apabila pembolehubah A diberikan nilai, bilangan rujukan kepada nilai ini ialah 1. Apabila pembolehubah A ditetapkan semula, bilangan rujukan kepada nilai sebelumnya dikurangkan sebanyak 1. Apabila bilangan rujukan menjadi 0, ini bermakna tiada cara untuk mengakses nilai ini lagi, jadi memori yang diduduki oleh nilai ini boleh dikosongkan.

Kebanyakan pelayar telah meninggalkan kaedah kitar semula ini

Kebocoran memori

Untuk mengelakkan kebocoran memori, sebaik sahaja data tidak digunakan lagi, sebaiknya keluarkan rujukannya dengan menetapkan nilainya kepada null Kaedah ini dipanggil Rujukan Kenalan

< 🎜. >

Apakah situasi yang boleh menyebabkan kebocoran ingatan? Bagaimana untuk mengelakkannya?

Mengambil Vue sebagai contoh, biasanya terdapat situasi berikut:

tidak dipisahkan window/body
Acara tidak melepaskan EventBus daripada
Vuex dan tiada $storewatchunwatch selepas
<🎜 tidak dipanggil >

beforeDestroy dalam masa dalam

dan ikat peristiwa

dalam DOM/BOM. objek. addEventListenerremoveEventListenerMod pemerhati
. $on$offJika pemasa digunakan dalam komponen, ia harus dimusnahkan.
Jika pemulaan perpustakaan pihak ketiga digunakan dalam cangkuk
mounted/createdGunakan rujukan yang lemah
. weakMapweakSet

Bilakah kenangan pelbagai jenis pembolehubah dalam penyemak imbas dikeluarkan?

Dikitar semula secara automatik oleh V8 selepas tiada rujukan.
Jika ia dalam penutupan, ia tidak akan dikitar semula oleh V8 sehingga penutupan tidak mempunyai rujukan.
- Dalam kes tidak ditutup, tunggu untuk kitar semula apabila generasi baharu V8 bertukar.

Memahami cache penyemak imbasApabila penyemak imbas meminta tapak web, ia akan memuatkan pelbagai sumber Untuk beberapa sumber yang tidak kerap berubah, The penyemak imbas akan menyimpannya dalam memori tempatan dan memuatkan sumber ini secara langsung pada kali seterusnya anda melawat untuk meningkatkan kelajuan akses.

Bagaimana untuk mengetahui sama ada sumber itu diminta oleh pelayan atau dibaca daripada cache?

Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul? Lihat gambar di atas, nilai saiz sesetengah sumber ialah saiz, ada yang

, dan ada yang

, menunjukkan saiz Ia adalah sumber pelayan yang diminta, dan dua yang terakhir ialah cache baca. from disk cachefrom memory cache

adalah untuk menyimpan sumber pada cakera Tidak perlu memuat turunnya semula apabila menunggu akses seterusnya Ia boleh dibaca terus dari cakera. Objek operasi langsungnya ialah . (Kecekapan adalah lebih perlahan daripada cache memori, tetapi kapasiti storan adalah besar dan masa storan adalah panjang) CurlCacheManager
adalah untuk cache sumber ke dalam memori dan tunggu sehingga akses seterusnya tanpa memuat turun semula Baca dari memori. (Ia adalah yang terpantas dari segi kecekapan dan terpendek dari segi masa hidup.)

Klasifikasi cache penyemak imbas

Cache kuat
Rundingkan cache

Apabila penyemak imbas meminta sumber daripada pelayan, ia mula-mula menentukan sama ada ia mencecah cache yang kuat Jika ia gagal, ia kemudian menentukan sama ada ia mencecah cache yang dirundingkan

Cache yang kuat<🎜. >

sumber cache setempat Jika ia mencecah, sumber dalam cache akan digunakan terus tanpa menghantar permintaan kepada pelayan. header (Maklumat dalam pengepala di sini merujuk kepada dan expires) cache-control

Tamat tempoh

http1.0 Nilainya ialah masa mutlak rentetan masa dalam format GMT, seperti Expires:Mon,18 Okt 2066 23:59. :59 GMT. Masa ini mewakili masa tamat sumber ini Sebelum masa ini, cache dipukul. Kaedah ini mempunyai kelemahan yang jelas Memandangkan masa tamat tempoh adalah masa mutlak, apabila sisihan masa antara pelayan dan klien adalah besar, ia akan menyebabkan kekeliruan cache. Jadi kaedah ini telah ditinggalkan dengan cepat dalam versi HTTP 1.1 yang kemudian.

Cache-Control

http1.1 Maklumat dinilai terutamanya dengan menggunakan nilai umur maks medan ini, iaitu masa relatif, seperti , yang bermaksud tempoh sah sumber adalah 3600 saat. Sebagai tambahan kepada medan ini, kawalan cache juga mempunyai nilai tetapan yang biasa digunakan berikut: Cache-Control:max-age=3600

tiada cache: Ia adalah perlu untuk merundingkan cache dan menghantar permintaan kepada pelayan untuk mengesahkan sama ada hendak menggunakan cache.

tiada kedai: Lumpuhkan cache dan minta semula data setiap kali.

awam: Boleh dicache oleh semua pengguna, termasuk pengguna akhir dan pelayan proksi perantaraan seperti CDN.

peribadi: Ia hanya boleh dicache oleh penyemak imbas pengguna akhir dan tidak dibenarkan untuk dicache oleh pelayan cache geganti seperti CDN.

Cache-Control dan Expires boleh didayakan pada masa yang sama dalam konfigurasi pelayan Apabila didayakan pada masa yang sama, Cache-Control mempunyai keutamaan yang lebih tinggi.

Runding Cache

maklumat untuk menentukan sama ada cache rundingan dipukul. Jika ia mencecah, header304 dikembalikan, memberitahu penyemak imbas bahawa sumber itu belum dikemas kini dan cache setempat boleh digunakan. (Maklumat pengepala di sini merujuk kepada dan Last-Modify/If-Modify-Since) ETag/If-None-Match

Ubahsuai Terakhir/Jika-Ubahsuai-Sejak

ETag/If-None-Match

Last-Modified dan ETag boleh digunakan bersama-sama Pelayan akan mengesahkan ETag terlebih dahulu Jika ia konsisten, ia akan terus membandingkan Last-Modified, dan akhirnya memutuskan sama ada untuk mengembalikan 304.

Ringkasan

Apabila penyemak imbas mengakses sumber yang telah dilawati, langkah-langkahnya ialah:

13.什么是浏览器的同源策略，以及跨域？

同源策略

同源策略是浏览器的一种自我保护行为。所谓的同源指的是：协议，域名，端口均要相同

浏览器中大部分内容都是受同源策略限制的，但是以下三个标签不受限制：

<img  src="..." / alt="Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?" >
<link href="..." />
<script src="..."></script>

Salin selepas log masuk

跨域

跨域指的是浏览器不能执行其它域名下的脚本。它是由浏览器的同源策略限制的。

你可能会想跨域请求到底有没有发送到服务器？

事实上，跨域请求时能够发送到服务器的，并且服务器也能过接受的请求并正常返回结果，只是结果被浏览器拦截了。

跨域解决方案（列出几个常用的）

JSONP

它主要是利用script标签不受浏览器同源策略的限制，可以拿到从其他源传输过来的数据，需要服务端支持。

优缺点：

兼容性比较好，可用于解决主流浏览器的跨域数据访问的问题。缺点就是仅支持get请求，具有局限性，不安全，可能会受到XSS攻击。

思路：

声明一个回调函数，其函数名(如show)当做参数值，要传递给跨域请求数据的服务器，函数形参为要获取目标数据(服务器返回的data)。

创建一个<script>标签，把那个跨域的API数据接口地址，赋值给script的src,还要在这个地址中向服务器传递该函数名（可以通过问号传参:?callback=show）。

服务器接收到请求后，需要进行特殊的处理：把传递进来的函数名和它需要给你的数据拼接成一个字符串,例如：传递进去的函数名是show，它准备好的数据是show('南玖')。

最后服务器把准备的数据通过HTTP协议返回给客户端，客户端再调用执行之前声明的回调函数（show），对返回的数据进行操作。

// front
function jsonp({ url, params, callback }) {
  return new Promise((resolve, reject) => {
    let script = document.createElement(&#39;script&#39;)
    window[callback] = function(data) {
      resolve(data)
      document.body.removeChild(script)
    }
    params = { ...params, callback } // wd=b&callback=show
    let arrs = []
    for (let key in params) {
      arrs.push(`${key}=${params[key]}`)
    }
    script.src = `${url}?${arrs.join(&#39;&&#39;)}`
    document.body.appendChild(script)
  })
}
jsonp({
  url: &#39;http://localhost:3000/say&#39;,
  params: { wd: &#39;wxgongzhonghao&#39; },
  callback: &#39;show&#39;
}).then(data => {
  console.log(data)
})

Salin selepas log masuk

// server 借助express框架
let express = require(&#39;express&#39;)
let app = express()
app.get(&#39;/say&#39;, function(req, res) {
  let { wd, callback } = req.query
  console.log(wd) // Iloveyou
  console.log(callback) // show
  res.end(`${callback}(&#39;关注前端南玖&#39;)`)
})
app.listen(3000)

Salin selepas log masuk

上面这段代码相当于向http://localhost:3000/say?wd=wxgongzhonghao&callback=show这个地址请求数据，然后后台返回show('关注前端南玖')，最后会运行show()这个函数，打印出'关注前端南玖'

跨域资源共享（CORS）

CORS（Cross-Origin Resource Sharing）跨域资源共享，定义了必须在访问跨域资源时，浏览器与服务器应该如何沟通。CORS背后的基本思想是使用自定义的HTTP头部让浏览器与服务器进行沟通，从而决定请求或响应是应该成功还是失败。

CORS 需要浏览器和后端同时支持。IE 8 和 9 需要通过 XDomainRequest 来实现。

浏览器会自动进行 CORS 通信，实现 CORS 通信的关键是后端。只要后端实现了 CORS，就实现了跨域。

服务端设置 Access-Control-Allow-Origin 就可以开启 CORS。该属性表示哪些域名可以访问资源，如果设置通配符则表示所有网站都可以访问资源。

虽然设置 CORS 和前端没什么关系，但是通过这种方式解决跨域问题的话，会在发送请求时出现两种情况，分别为简单请求和复杂请求。

简单请求： （满足以下两个条件，就是简单请求）

1.请求方法为以下三个之一：

GET
POST
HEAD

2.Content-Type的为以下三个之一：

text-plain
multiparty/form-data
application/x-www-form-urlencoded

复杂请求：

不是简单请求那它肯定就是复杂请求了。复杂请求的CORS请求，会在正式发起请求前，增加一次HTTP查询请求，称为预检请求，该请求是option方法的，通过该请求来知道服务端是否允许该跨域请求。

Nginx反向代理

Nginx 反向代理的原理很简单，即所有客户端的请求都必须经过nginx处理，nginx作为代理服务器再将请求转发给后端，这样就规避了浏览器的同源策略。

14.说说什么是XSS攻击

什么是XSS？

XSS 全称是 Cross Site Scripting，为了与css区分开来，所以简称XSS，中文叫作跨站脚本
XSS是指黑客往页面中注入恶意脚本，从而在用户浏览页面时利用恶意脚本对用户实施攻击的一种手段。

XSS能够做什么？

窃取Cookie
监听用户行为，比如输入账号密码后之间发给黑客服务器
在网页中生成浮窗广告
修改DOM伪造登入表单

XSS实现方式

存储型XSS攻击
反射型XSS攻击
基于DOM的XSS攻击

如何阻止XSS攻击？

对输入脚本进行过滤或转码

对用户输入的信息过滤或者转码，保证用户输入的内容不能在HTML解析的时候执行。

利用CSP

该安全策略的实现基于一个称作 Content-Security-Policy的HTTP首部。（浏览器内容安全策略）它的核心思想就是服务器决定浏览器加载那些资源。

限制加载其他域下的资源文件，这样即使黑客插入了一个 JavaScript 文件，这个 JavaScript 文件也是无法被加载的；
禁止向第三方域提交数据，这样用户数据也不会外泄；
提供上报机制，能帮助我们及时发现 XSS 攻击。
禁止执行内联脚本和未授权的脚本；

利用 HttpOnly

由于很多 XSS 攻击都是来盗用 Cookie 的，因此还可以通过使用 HttpOnly 属性来保护我们 Cookie 的安全。这样子的话，JavaScript 便无法读取 Cookie 的值。这样也能很好的防范 XSS 攻击。

通常服务器可以将某些 Cookie 设置为 HttpOnly 标志，HttpOnly 是服务器通过 HTTP 响应头来设置的，下面是打开 Google 时，HTTP 响应头中的一段：

set-cookie: NID=189=M8l6-z41asXtm2uEwcOC5oh9djkffOMhWqQrlnCtOI; expires=Sat, 18-Apr-2020 06:52:22 GMT; path=/; domain=.google.com; HttpOnly

Salin selepas log masuk

对于不受信任的输入，可以限制输入长度

15.说说什么是CSRF攻击？

什么是CSRF攻击？

CSRF 全称 Cross-site request forgery，中文为跨站请求伪造 ，攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。 CSRF攻击就是黑客利用用户的登录状态，并通过第三方站点来干一些嘿嘿嘿的坏事。

几种常见的攻击类型

1.GET类型的CSRF

GET类型的CSRF非常简单，通常只需要一个HTTP请求：

 <img  src="http://bank.example/withdraw?amount=10000&for=hacker"  alt="Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?" >

Salin selepas log masuk

在受害者访问含有这个img的页面后，浏览器会自动向http://bank.example/withdraw?account=xiaoming&amount=10000&for=hacker发出一次HTTP请求。bank.example就会收到包含受害者登录信息的一次跨域请求。

2.POST类型的CSRF

这种类型的CSRF利用起来通常使用的是一个自动提交的表单，如：

 <form action="http://bank.example/withdraw" method=POST>
    <input type="hidden" name="account" value="xiaoming" />
    <input type="hidden" name="amount" value="10000" />
    <input type="hidden" name="for" value="hacker" />
</form>
<script> document.forms[0].submit(); </script>

Salin selepas log masuk

访问该页面后，表单会自动提交，相当于模拟用户完成了一次POST操作。

3.链接类型的CSRF

链接类型的CSRF并不常见，比起其他两种用户打开页面就中招的情况，这种需要用户点击链接才会触发。这种类型通常是在论坛中发布的图片中嵌入恶意链接，或者以广告的形式诱导用户中招，攻击者通常会以比较夸张的词语诱骗用户点击，例如：

  <a href="http://test.com/csrf/withdraw.php?amount=1000&for=hacker" taget="_blank">
  重磅消息！！
  <a/>

Salin selepas log masuk

由于之前用户登录了信任的网站A，并且保存登录状态，只要用户主动访问上面的这个PHP页面，则表示攻击成功。

CSRF的特点

攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

CSRF通常是跨域的，因为外域通常更容易被攻击者掌控。但是如果本域下有容易被利用的功能，比如可以发图和链接的论坛和评论区，攻击可以直接在本域下进行，而且这种攻击更加危险。

防护策略

Penggodam hanya boleh menggunakan cookie mangsa untuk menipu kepercayaan pelayan, tetapi penggodam tidak boleh mendapatkan **"kuki"** dan tidak dapat melihat kandungan **"kuki". Selain itu, penggodam tidak boleh menghuraikan hasil yang dikembalikan oleh pelayan disebabkan oleh sekatan penyemak imbas "Dasar Asal Sama"**.

Ini memberitahu kita bahawa objek yang ingin kita lindungi adalah perkhidmatan yang boleh menghasilkan perubahan data secara langsung, manakala perkhidmatan yang membaca data tidak memerlukan perlindungan CSRF. Kunci perlindungan ialah "Letakkan maklumat dalam permintaan yang tidak boleh dipalsukan oleh penggodam"

Pengesanan asal asal

Memandangkan kebanyakan CSRF datang daripada tapak web pihak ketiga, kami secara langsung melarang domain luaran (atau nama domain yang tidak dipercayai) daripada membuat permintaan kepada kami.

Maka persoalannya, bagaimana kita menentukan sama ada permintaan itu datang daripada domain luaran?

Dalam protokol HTTP, setiap permintaan tak segerak membawa dua Pengepala, digunakan untuk menandakan nama domain sumber:

Origin Header
Referer Header

Kedua-dua pengepala ini dibawa secara automatik dalam kebanyakan kes apabila penyemak imbas memulakan permintaan dan kandungan tidak boleh disesuaikan dengan bahagian hadapan. Pelayan boleh menentukan domain sumber permintaan dengan menghuraikan nama domain dalam dua pengepala ini.

Gunakan Pengepala Asal untuk menentukan nama domain sumber

Dalam beberapa permintaan berkaitan CSRF, pengepala yang diminta akan membawa medan Asal. Medan mengandungi nama domain yang diminta (tidak termasuk laluan dan pertanyaan).

Jika Origin wujud, anda boleh terus menggunakan medan dalam Origin untuk mengesahkan nama domain sumber.

Tetapi Origin tidak wujud dalam dua kes berikut:

Dasar Asal IE11: IE 11 tidak akan menambah Origin pada tajuk permintaan CORS merentas tapak, pengepala Perujuk masih akan menjadi satu-satunya pengecam. Sebab paling asas ialah takrifan asal yang sama dalam IE 11 adalah berbeza daripada pelayar lain Terdapat dua perbezaan utama Anda boleh merujuk kepada Dasar_asal-mula MDN#IE_Exceptions
<🎜. >302 Ubah hala: Origin tidak termasuk dalam permintaan diubah hala selepas 302 redirect kerana Origin mungkin dianggap sebagai maklumat sensitif daripada sumber lain. Dalam kes 302 ubah hala, URL dihalakan ke pelayan baharu, jadi penyemak imbas tidak mahu membocorkan Origin ke pelayan baharu.

Gunakan Pengepala Perujuk untuk menentukan nama domain sumber

根据上面的表格因此需要把Referrer Policy的策略设置成same-origin，对于同源的链接和引用，会发送Referer，referer值为Host不带Path；跨域访问则不携带Referer。例如：aaa.com引用bbb.com的资源，不会发送Referer。

设置Referrer Policy的方法有三种：

在CSP设置
页面头部增加meta标签
a标签增加referrerpolicy属性

上面说的这些比较多，但我们可以知道一个问题：攻击者可以在自己的请求中隐藏Referer。如果攻击者将自己的请求这样填写：

 <img  src="http://bank.example/withdraw?amount=10000&for=hacker" referrerpolicy="no-referrer" alt="Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?" >

Salin selepas log masuk

那么这个请求发起的攻击将不携带Referer。

另外在以下情况下Referer没有或者不可信：

1.IE6、7下使用window.location.href=url进行界面的跳转，会丢失Referer。

2.IE6、7下使用window.open，也会缺失Referer。

3.HTTPS页面跳转到HTTP页面，所有浏览器Referer都丢失。

4.点击Flash上到达另外一个网站的时候，Referer的情况就比较杂乱，不太可信。

无法确认来源域名情况

当Origin和Referer头文件不存在时该怎么办？如果Origin和Referer都不存在，建议直接进行阻止，特别是如果您没有使用随机CSRF Token（参考下方）作为第二次检查。

如何阻止外域请求

通过Header的验证，我们可以知道发起请求的来源域名，这些来源域名可能是网站本域，或者子域名，或者有授权的第三方域名，又或者来自不可信的未知域名。

我们已经知道了请求域名是否是来自不可信的域名，我们直接阻止掉这些的请求，就能防御CSRF攻击了吗？

且慢！当一个请求是页面请求（比如网站的主页），而来源是搜索引擎的链接（例如百度的搜索结果），也会被当成疑似CSRF攻击。所以在判断的时候需要过滤掉页面请求情况，通常Header符合以下情况：

Accept: text/html
Method: GET

Salin selepas log masuk

但相应的，页面请求就暴露在了CSRF的攻击范围之中。如果你的网站中，在页面的GET请求中对当前用户做了什么操作的话，防范就失效了。

例如，下面的页面请求：

GET https://example.com/addComment?comment=XXX&dest=orderId

Salin selepas log masuk

注：这种严格来说并不一定存在CSRF攻击的风险，但仍然有很多网站经常把主文档GET请求挂上参数来实现产品功能，但是这样做对于自身来说是存在安全风险的。

另外，前面说过，CSRF大多数情况下来自第三方域名，但并不能排除本域发起。如果攻击者有权限在本域发布评论（含链接、图片等，统称UGC），那么它可以直接在本域发起攻击，这种情况下同源策略无法达到防护的作用。

综上所述：同源验证是一个相对简单的防范方法，能够防范绝大多数的CSRF攻击。但这并不是万无一失的，对于安全性要求较高，或者有较多用户输入内容的网站，我们就要对关键的接口做额外的防护措施。

CSRF Token

前面讲到CSRF的另一个特征是，攻击者无法直接窃取到用户的信息（Cookie，Header，网站内容等），仅仅是冒用Cookie中的信息。

而CSRF攻击之所以能够成功，是因为服务器误把攻击者发送的请求当成了用户自己的请求。那么我们可以要求所有的用户请求都携带一个CSRF攻击者无法获取到的Token。服务器通过校验请求是否携带正确的Token，来把正常的请求和攻击的请求区分开，也可以防范CSRF的攻击。

利用Cookie的SameSite属性

可以看看MDN对此的解释：

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Set-Cookie/SameSite

SameSite可以设置为三个值，Strict、Lax和None。

在Strict模式下，浏览器完全禁止第三方请求携带Cookie。比如请求sanyuan.com网站只能在sanyuan.com域名当中请求才能携带 Cookie，在其他网站请求都不能。
在Lax模式，就宽松一点了，但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可以携带 Cookie，其他情况均不能。
在None模式下，Cookie将在所有上下文中发送，即允许跨域发送。

更多编程相关知识，请访问：编程入门！！

Atas ialah kandungan terperinci Lihat soalan temu bual pelayar ini Berapa banyak yang anda boleh jawab dengan betul?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!