金三銀四，磨礪鋒芒；劍指大廠，揚帆起航（2020年最全大廠WEB前端面試題精選）中

時間 2020-09-14

標籤磨礪鋒芒大廠揚帆起航 2020年 web 端面試題精選欄目 HTML 简体版

原文原文鏈接

金三銀四，磨礪鋒芒；劍指大廠，揚帆起航（2020年最全大廠WEB前端面試題精選）中

引言

元旦匆匆而過，2020年的春節又接踵而來，你們除了忙的提着褲子加班、年末沖沖衝外，還有着對於明年的迷茫和期待！2019年有多少苦澀心酸，2020年就有更多幸福美好，加油，奧利給！懷着一顆積極向上的心，來面對將來每一天的挑戰！javascript

所謂「兵馬未動，糧草先行」，咱們打響明天的戰役也須要精神食糧來作後勤保障纔是。在此我整理了多位從業者和我在2019年末至2020年初的一廠面試精選題，但願對磨礪鋒芒、奮發向上的小夥伴有所幫助，祝你早日劍指大廠，揚帆起航，奧利給！css

瀏覽器

1.實現一個postMessage跨域（快手一面 2019.08）

// 發送消息端
window.parent.postMessage('message', 'http://test.com')
// 接收消息端
var mc = new MessageChannel()
mc.addEventListener('message', event => {
  var origin = event.origin || event.originalEvent.origin
  if (origin === 'http://test.com') {
    console.log('驗證經過')
  }
})

2.node和瀏覽器的事件循環機制區別（京東到家二面 2019.04）

瀏覽器環境下，microtask 的任務隊列是每一個 macrotask 執行完以後執行。而在 Node.js 中，microtask 會在事件循環的各個階段之間執行，也就是一個階段執行完畢，就會去執行 microtask 隊列的任務。html

瀏覽器和 Node 環境下，microtask 任務隊列的執行時機不一樣前端

Node 端，microtask 在事件循環的各個階段之間執行
瀏覽器端，microtask 在事件循環的 macrotask 執行完以後執行

參考地址：http://www.javashuo.com/article/p-nwpynnbs-z.htmlvue

cookie數據始終在同源的http請求中攜帶（即便不須要），即cookie在瀏覽器和服務器間來回傳遞。而sessionStorage和localStorage不會自動把數據發給服務器，僅在本地保存。
存儲大小限制不一樣，cookie數據不能超過4k，同時由於每次http請求都會攜帶cookie，因此cookie只適合保存很小的數據，如會話標識。sessionStorage和localStorage雖然也有存儲大小的限制，但比cookie大得多，能夠達到5M或更大。
數據有效期不一樣，sessionStorage：僅在當前瀏覽器窗口關閉前有效，天然也就不可能持久保持；localStorage：始終有效，窗口或瀏覽器關閉也一直保存，所以用做持久數據；cookie只在設置的cookie過時時間以前一直有效，即便窗口或瀏覽器關閉。
做用域不一樣，sessionStorage不在不一樣的瀏覽器窗口中共享，即便是同一個頁面；localStorage 在全部同源窗口中都是共享的；cookie也是在全部同源窗口中都是共享的。

特性	cookie	localStorage	sessionStorage	indexDB
數據生命週期	通常由服務器生成，能夠設置過時時間	除非被清理，不然一直存在	頁面關閉就清理	除非被清理，不然一直存在
數據存儲大小	4k	5M	5M	無限
與服務端通訊	header中，對於請求性能影響	不參與	不參與	不參與

4. cookie某些屬性的做用？

屬性	做用
value	若是用於保存用戶登陸態，應該將該值加密，不能使用明文的用戶標識
http-only	不能經過JS訪問Cookie，減小XSS攻擊
secure	只能在協議爲HTTPS的請求中攜帶
same-site	規定瀏覽器不能在跨域請求中攜帶Cookie，減小CSRF攻擊

4.輸入URL發生什麼？（螞蟻金服一面 2019.03）

DNS 域名解析（域名解析成ip地址，走UTP協議，所以不會有握手過程）：瀏覽器將 URL 解析出相對應的服務器的 IP 地址（1. 本地瀏覽器的 DNS 緩存中查找 2. 再向系統DNS緩存發送查詢請求 3. 再向路由器DNS緩存 4. 網絡運營商DNS緩存 5. 遞歸搜索），並從 url 中解析出端口號
瀏覽器與目標服務器創建一條 TCP 鏈接（三次握手）
瀏覽器向服務器發送一條 HTTP 請求報文
服務器返回給瀏覽器一條 HTTP 響應報文
瀏覽器進行渲染
關閉 TCP 鏈接（四次揮手）

5. 強緩存和協商緩存（螞蟻金服一面 2019.03）

強緩存 能夠經過設置兩種 HTTP Header 實現：Expires 和 Cache-Control 。強緩存表示在緩存期間不須要請求，state code 爲 200。

Expires 是 HTTP/1 的產物，表示資源會在 Wed, 22 Oct 2018 08:41:00 GMT 後過時，須要再次請求。而且 Expires 受限於本地時間，若是修改了本地時間，可能會形成緩存失效。
Cache-Control 出現於 HTTP/1.1，優先級高於 Expires 。該屬性值表示資源會在 30 秒後過時，須要再次請求。

指令	做用
public	表示響應能夠被客戶端和代理服務器緩存
private	表示響應只能夠被客戶端緩存
max-age=30	緩存30秒後就過時，須要從新請求
s-maxage=30	覆蓋max-age,做用同樣，只在代理服務器中生效
no-store	不緩存任何響應
no-cache	資源被緩存，可是當即失效，下次會發起請求驗證資源是否過時
max-stale=30	30秒內，即便緩存過時，也使用該緩存
min-fresh=30	但願在30秒內獲取最新的響應

協商緩存 若是緩存過時了，就須要發起請求驗證資源是否有更新。協商緩存能夠經過設置兩種 HTTP Header 實現：Last-Modified 和 ETag 。當瀏覽器發起請求驗證資源時，若是資源沒有作改變，那麼服務端就會返回 304 狀態碼，而且更新瀏覽器緩存有效期。

Last-Modified 表示本地文件最後修改日期，If-Modified-Since 會將 Last-Modified 的值發送給服務器，詢問服務器在該日期後資源是否有更新，有更新的話就會將新的資源發送回來，不然返回 304 狀態碼。可是 Last-Modified 存在一些弊端：1.若是本地打開緩存文件，即便沒有對文件進行修改，但仍是會形成 Last-Modified 被修改，服務端不能命中緩存致使發送相同的資源；2.由於 Last-Modified 只能以秒計時，若是在不可感知的時間內修改完成文件，那麼服務端會認爲資源仍是命中了，不會返回正確的資源
ETag 相似於文件指紋，If-None-Match 會將當前 ETag 發送給服務器，詢問該資源 ETag 是否變更，有變更的話就將新的資源發送回來。而且 ETag 優先級比 Last-Modified 高。

啓發式緩存 若是什麼緩存策略都沒設置，那麼瀏覽器會怎麼處理？對於這種狀況，瀏覽器會採用一個啓發式的算法，一般會取響應頭中的 Date 減去 Last-Modified 值的 10% 做爲緩存時間。

6. 實際場景應用緩存策略舉例

頻繁變更的資源 對於頻繁變更的資源，首先須要使用 Cache-Control: no-cache 使瀏覽器每次都請求服務器，而後配合 ETag 或者 Last-Modified 來驗證資源是否有效。這樣的作法雖然不能節省請求數量，可是能顯著減小響應數據大小。
代碼文件 這裏特指除了 HTML 外的代碼文件，由於 HTML 文件通常不緩存或者緩存時間很短。通常來講，如今都會使用工具來打包代碼，那麼咱們就能夠對文件名進行哈希處理，只有當代碼修改後纔會生成新的文件名。基於此，咱們就能夠給代碼文件設置緩存有效期一年 Cache-Control: max-age=31536000，這樣只有當 HTML 文件中引入的文件名發生了改變纔會去下載最新的代碼文件，不然就一直使用緩存。

7. 重繪（Repaint）和迴流（Reflow）是啥？如何優化？（快手一面 2019.08）

重繪是當節點須要更改外觀而不會影響佈局的，好比改變 color 就叫稱爲重繪。
迴流是佈局或者幾何屬性須要改變就稱爲迴流。
迴流一定會發生重繪，重繪不必定會引起迴流。迴流所需的成本比重繪高的多，改變父節點裏的子節點極可能會致使父節點的一系列迴流。
優化方案：

使用 transform 替代 top
使用 visibility 替換 display: none ，由於前者只會引發重繪，後者會引起迴流（改變了佈局）
不要把節點的屬性值放在一個循環裏當成循環裏的變量
不要使用 table 佈局，可能很小的一個小改動會形成整個 table 的從新佈局
動畫實現的速度的選擇，動畫速度越快，迴流次數越多，也能夠選擇使用requestAnimationFrame
CSS 選擇符從右往左匹配查找，避免節點層級過多
將頻繁重繪或者回流的節點設置爲圖層，圖層可以阻止該節點的渲染行爲影響別的節點。好比對於 video 標籤來講，瀏覽器會自動將該節點變爲圖層。

8. 同源策略是什麼？（網易互娛 2019.11）

同源策略是指只有具備相同源的頁面纔可以共享數據，好比cookie，同源是指頁面具備相同的協議、域名、端口號，有一項不一樣就不是同源。有同源策略可以保證web網頁的安全性。java

DOM 同源策略：禁止對不一樣源頁面 DOM 進行操做。這裏主要場景是 iframe 跨域的狀況，不一樣域名的 iframe 是限制互相訪問的。node

XMLHttpRequest 同源策略：禁止使用 XHR 對象向不一樣源的服務器地址發起 HTTP 請求。webpack

跨域解決方法： 1. CORS（跨域資源共享）； 2. JSONP跨域； 3. 圖像ping跨域； 4. 服務器代理； 5. document.domain 跨域； 6. window.name 跨域； 7. location.hash 跨域； 8. postMessage 跨域；web

9.DOM Tree是如何構建的？

轉碼: 瀏覽器將接收到的二進制數據按照指定編碼格式轉化爲HTML字符串
生成Tokens: 以後開始parser，瀏覽器會將HTML字符串解析成Tokens
構建Nodes: 對Node添加特定的屬性，經過指針肯定 Node 的父、子、兄弟關係和所屬 treeScope
生成DOM Tree: 經過node包含的指針肯定的關係構建出DOM
Tree

10.前端須要注意哪些seo(搜索引擎優化)？（拼多多 2019.11）

合理的title、description、keywords：搜索對着三項的權重逐個減少，title值強調重點便可，重要關鍵詞出現不要超過2次，並且要靠前，不一樣頁面title要有所不一樣；description把頁面內容高度歸納，長度合適，不可過度堆砌關鍵詞，不一樣頁面description有所不一樣；keywords列舉出重要關鍵詞便可
語義化的HTML代碼，符合W3C規範：語義化代碼讓搜索引擎容易理解網頁
重要內容HTML代碼放在最前：搜索引擎抓取HTML順序是從上到下，有的搜索引擎對抓取長度有限制，保證重要內容必定會被抓取
重要內容不要用js輸出：爬蟲不會執行js獲取內容
少用iframe：搜索引擎不會抓取iframe中的內容
非裝飾性圖片必須加alt
提升網站速度：網站速度是搜索引擎排序的一個重要指標

11.什麼是會話跟蹤，有哪幾種方法？（拼多多 2019.11）

對同一個用戶對服務器的連續的請求和接受響應的監視。經常使用的方法有：

URL重寫 的技術就是在URL結尾添加一個附加數據以標識該會話,把會話ID經過URL的信息傳遞過去，以便在服務器端進行識別不一樣的用戶。
隱藏表單域 將會話ID添加到HTML表單元素中提交到服務器,此表單元素並不在客戶端顯示。
Cookie Cookie是Web服務器發送給客戶端的一小段信息，客戶端請求時能夠讀取該信息發送到服務器端，進而進行用戶的識別。對於客戶端的每次請求，服務器都會將Cookie發送到客戶端,在客戶端能夠進行保存,以便下次使用。
session 每個用戶都有一個不一樣的session，各個用戶之間是不能共享的，是每一個用戶所獨享的，在session中能夠存放信息。在服務器端會建立一個session對象，產生一個sessionID來標識這個session對象，而後將這個sessionID放入到Cookie中發送到客戶端，下一次訪問時，sessionID會發送到服務器，在服務器端進行識別不一樣的用戶。

12.Doctype做用?嚴格模式與混雜模式如何區分？它們有何意義?（快手一面 2019.08）

Doctype聲明於文檔最前面，告訴瀏覽器以何種方式來渲染頁面，這裏有兩種模式，嚴格模式和混雜模式。
嚴格模式 的排版和JS 運做模式是以該瀏覽器支持的最高標準運行。
混雜模式，向後兼容，模擬老式瀏覽器，防止瀏覽器沒法兼容頁面。

自動化工具

1. 什麼是webpack，webpack的運行原理，如何打包（字節跳動）

webpack是一個打包模塊化javascript的工具，在webpack裏一切文件皆模塊，經過loader轉換文件，經過plugin注入鉤子，最後輸出由多個模塊組合成的文件，webpack專一構建模塊化項目。
WebPack能夠看作是模塊打包機：它作的事情是，分析你的項目結構，找到JavaScript模塊以及其它的一些瀏覽器不能直接運行的拓展語言（Scss，TypeScript等），並將其打包爲合適的格式以供瀏覽器使用。面試

二、webpack如何配置？

參考：https://www.webpackjs.com/configuration/

3. webpack與grunt、gulp的不一樣？（招行信用卡中心）

Grunt、Gulp是基於任務運行的工具： 它們會自動執行指定的任務，就像流水線，把資源放上去而後經過不一樣插件進行加工，它們包含活躍的社區，豐富的插件，能方便的打造各類工做流。
Webpack是基於模塊化打包的工具: 自動化處理模塊,webpack把一切當成模塊，當 webpack 處理應用程序時，它會遞歸地構建一個依賴關係圖(dependency graph)，其中包含應用程序須要的每一個模塊，而後將全部這些模塊打包成一個或多個 bundle。
所以這是徹底不一樣的兩類工具,而如今主流的方式是用npm script代替Grunt、Gulp,npm script一樣能夠打造任務流。

4.什麼是bundle,什麼是chunk，什麼是module?

bundle：是由webpack打包出來的文件
chunk：代碼塊，一個chunk由多個模塊組合而成，用於代碼的合併和分割
module：是開發中的單個模塊，在webpack的世界，一切皆模塊，一個模塊對應一個文件，webpack會從配置的entry中遞歸開始找出全部依賴的模塊

5.什麼是Loader?什麼是Plugin?

1）Loaders是用來告訴webpack如何轉化處理某一類型的文件，而且引入到打包出的文件中
2）Plugin是用來自定義webpack打包過程的方式，一個插件是含有apply方法的一個對象，經過這個方法能夠參與到整個webpack打包的各個流程(生命週期)。

6. 有哪些常見的Loader？他們是解決什麼問題的？

file-loader：把文件輸出到一個文件夾中，在代碼中經過相對 URL 去引用輸出的文件
url-loader：和 file-loader 相似，可是能在文件很小的狀況下以 base64 的方式把文件內容注入到代碼中去
source-map-loader：加載額外的 Source Map 文件，以方便斷點調試
image-loader：加載而且壓縮圖片文件
babel-loader：把 ES6 轉換成 ES5
css-loader：加載 CSS，支持模塊化、壓縮、文件導入等特性
style-loader：把 CSS 代碼注入到 JavaScript 中，經過 DOM 操做去加載 CSS。
eslint-loader：經過 ESLint 檢查 JavaScript 代碼

7. 有哪些常見的Plugin？

define-plugin：定義環境變量
html-webpack-plugin：簡化html文件建立
uglifyjs-webpack-plugin：經過UglifyES壓縮ES6代碼
webpack-parallel-uglify-plugin: 多核壓縮,提升壓縮速度
webpack-bundle-analyzer: 可視化webpack輸出文件的體積
mini-css-extract-plugin: CSS提取到單獨的文件中,支持按需加載

8.webpack中loader和plugin的區別（字節跳動搜狐）

Loader直譯爲"加載器"。Webpack將一切文件視爲模塊，可是webpack原生是隻能解析js文件，若是想將其餘文件也打包的話，就會用到loader。因此Loader的做用是讓webpack擁有了加載和解析_非JavaScript文件_的能力。
Plugin直譯爲"插件"。Plugin能夠擴展webpack的功能，讓webpack具備更多的靈活性。在 Webpack 運行的生命週期中會廣播出許多事件，Plugin 能夠監聽這些事件，在合適的時機經過 Webpack 提供的 API 改變輸出結果。
Loader在module.rules中配置，也就是說他做爲模塊的解析規則而存在。類型爲數組，每一項都是一個Object，裏面描述了對於什麼類型的文件（test），使用什麼加載(loader)和使用的參數（options）
Plugin在plugins中單獨配置。類型爲數組，每一項是一個plugin的實例，參數都經過構造函數傳入。

9.webpack的構建流程是什麼?從讀取配置到輸出文件這個過程儘可能說全

Webpack 的運行流程是一個串行的過程，從啓動到結束會依次執行如下流程：

初始化參數：從配置文件和 Shell 語句中讀取與合併參數，得出最終的參數；
開始編譯：用上一步獲得的參數初始化 Compiler 對象，加載全部配置的插件，執行對象的 run 方法開始執行編譯；
肯定入口：根據配置中的 entry 找出全部的入口文件；
編譯模塊：從入口文件出發，調用全部配置的 Loader 對模塊進行翻譯，再找出該模塊依賴的模塊，再遞歸本步驟直到全部入口依賴的文件都通過了本步驟的處理；
完成模塊編譯：在通過第4步使用 Loader 翻譯完全部模塊後，獲得了每一個模塊被翻譯後的最終內容以及它們之間的依賴關係；
輸出資源：根據入口和模塊之間的依賴關係，組裝成一個個包含多個模塊的 Chunk，再把每一個 Chunk 轉換成一個單獨的文件加入到輸出列表，這步是能夠修改輸出內容的最後機會；
輸出完成：在肯定好輸出內容後，根據配置肯定輸出的路徑和文件名，把文件內容寫入到文件系統。

10. webpack的plugins和loaders的實現原理？（達達京東到家 2019.04）

Loader像一個"翻譯官"把讀到的源文件內容轉義成新的文件內容，而且每一個Loader經過鏈式操做，將源文件一步步翻譯成想要的樣子。
編寫Loader時要遵循單一原則，每一個Loader只作一種"轉義"工做。每一個Loader的拿到的是源文件內容（source），能夠經過返回值的方式將處理後的內容輸出，也能夠調用this.callback()方法，將內容返回給webpack。還能夠經過 this.async()生成一個callback函數，再用這個callback將處理後的內容輸出出去。此外webpack還爲開發者準備了開發loader的工具函數集——loader-utils。
相對於Loader而言，Plugin的編寫就靈活了許多。webpack在運行的生命週期中會廣播出許多事件，Plugin 能夠監聽這些事件，在合適的時機經過 Webpack 提供的 API 改變輸出結果。

11.如何利用webpack來優化前端性能？（達達京東到家 2019.04）

壓縮代碼。刪除多餘的代碼、註釋、簡化代碼的寫法等等方式。能夠利用webpack的UglifyJsPlugin和ParallelUglifyPlugin來壓縮JS文件，利用cssnano（css-loader?minimize）來壓縮css
利用CDN加速。在構建過程當中，將引用的靜態資源路徑修改成CDN上對應的路徑。能夠利用webpack對於output參數和各loader的publicPath參數來修改資源路徑
刪除死代碼（Tree Shaking）。將代碼中永遠不會走到的片斷刪除掉。能夠經過在啓動webpack時追加參數--optimize-minimize來實現
提取公共代碼。

12. webpack、rollup、parcel優劣？

webpack適用於大型複雜的前端站點構建: webpack有強大的loader和插件生態,打包後的文件實際上就是一個當即執行函數，這個當即執行函數接收一個參數，這個參數是模塊對象，鍵爲各個模塊的路徑，值爲模塊內容。當即執行函數內部則處理模塊之間的引用，執行模塊等,這種狀況更適合文件依賴複雜的應用開發.
rollup適用於基礎庫的打包，如vue、d3等: Rollup 就是將各個模塊打包進一個文件中，而且經過 Tree-shaking 來刪除無用的代碼,能夠最大程度上下降代碼體積,可是rollup沒有webpack如此多的的如代碼分割、按需加載等高級功能，其更聚焦於庫的打包，所以更適合庫的開發.
parcel適用於簡單的實驗性項目: 他能夠知足低門檻的快速看到效果,可是生態差、報錯信息不夠全面都是他的硬傷，除了一些玩具項目或者實驗項目不建議使用

13. 如何提升webpack的打包速度?

happypack: 利用進程並行編譯loader,利用緩存來使得 rebuild 更快,遺憾的是做者表示已經不會繼續開發此項目,相似的替代者是thread-loader
外部擴展(externals): 將不怎麼須要更新的第三方庫脫離webpack打包，不被打入bundle中，從而減小打包時間,好比jQuery用script標籤引入。
dll: 採用webpack的 DllPlugin 和 DllReferencePlugin 引入dll，讓一些基本不會改動的代碼先打包成靜態資源,避免反覆編譯浪費時間
利用緩存: webpack.cache、babel-loader.cacheDirectory、HappyPack.cache均可以利用緩存提升rebuild效率
縮小文件搜索範圍: 好比babel-loader插件,若是你的文件僅存在於src中,那麼能夠include: path.resolve(__dirname, 'src'),固然絕大多數狀況下這種操做的提高有限,除非不當心build了node_modules文件

14. 如何提升webpack的構建速度？（天壤智能）

多入口狀況下，使用CommonsChunkPlugin來提取公共代碼
經過externals配置來提取經常使用庫
利用DllPlugin和DllReferencePlugin預編譯資源模塊經過DllPlugin來對那些咱們引用可是絕對不會修改的npm包來進行預編譯，再經過4. DllReferencePlugin將預編譯的模塊加載進來。
使用Happypack 實現多線程加速編譯
使用webpack-uglify-parallel來提高uglifyPlugin的壓縮速度。原理上webpack-uglify-parallel採用了多核並行壓縮來提高壓縮速度
使用Tree-shaking和Scope Hoisting來剔除多餘代碼

15. AMD和CMD的區別？

最明顯的區別就是在模塊定義時對依賴的處理不一樣
AMD推崇依賴前置，在定義模塊的時候就要聲明其依賴的模塊
CMD推崇就近依賴，只有在用到某個模塊的時候再去require

參考：前端模塊化，AMD與CMD的區別

16. 介紹模塊化發展歷程

模塊化主要是用來抽離公共代碼，隔離做用域，避免變量衝突等。

IIFE：使用自執行函數來編寫模塊化，特色：在一個單獨的函數做用域中執行代碼，避免變量衝突。
AMD：使用requireJS 來編寫模塊化，特色：依賴必須提早聲明好。
CMD：使用seaJS 來編寫模塊化，特色：支持動態引入依賴文件。
CommonJS： nodejs 中自帶的模塊化。
UMD：兼容AMD，CommonJS 模塊化語法。
webpack(require.ensure)：webpack 2.x 版本中的代碼分割。
ES Modules： ES6 引入的模塊化，支持import 來引入另外一個 js 。

17.webpack 熱更新原理

參考：http://www.javashuo.com/article/p-bwoptull-ke.html

服務端和網絡

1.進程與線程的區別（字節跳動一面 2019.08）

地址空間：同一進程的線程共享本進程的地址空間，而進程之間是獨立的地址空間。
資源擁有：同一進程內的線程共享本進程的資源如內存、I/O、cpu等，可是進程之間的資源是獨立的。
一個進程崩潰後，在保護模式下不會對其餘進程產生影響，可是一個線程崩潰整個進程都會死掉，因此多進程要比多線程健壯。
線程執行開銷小，可是不利於資源的管理和保護。線程適合在SMP機器（雙CPU系統）上運行。進程執行開銷大，可是可以很好的進行資源管理和保護。進程能夠跨機器前移。
對資源的管理和保護要求高，不限制開銷和效率時，使用多進程。要求效率高，頻繁切換時，資源的保護管理要求不是很高時，使用多線程。

2.什麼是會話跟蹤，有哪幾種方法？（字節跳動一面 2019.08）

對同一個用戶對服務器的連續的請求和接受響應的監視。經常使用的方法有：

URL重寫 的技術就是在URL結尾添加一個附加數據以標識該會話,把會話ID經過URL的信息傳遞過去，以便在服務器端進行識別不一樣的用戶。
隱藏表單域 將會話ID添加到HTML表單元素中提交到服務器,此表單元素並不在客戶端顯示。
Cookie Cookie是Web服務器發送給客戶端的一小段信息，客戶端請求時能夠讀取該信息發送到服務器端，進而進行用戶的識別。對於客戶端的每次請求，服務器都會將Cookie發送到客戶端,在客戶端能夠進行保存,以便下次使用。
session 每個用戶都有一個不一樣的session，各個用戶之間是不能共享的，是每一個用戶所獨享的，在session中能夠存放信息。在服務器端會建立一個session對象，產生一個sessionID來標識這個session對象，而後將這個sessionID放入到Cookie中發送到客戶端，下一次訪問時，sessionID會發送到服務器，在服務器端進行識別不一樣的用戶。

3.ssl加密使用了哪一種算法，如何加密（阿里巴巴 2019.08）

在客戶端與服務器間傳輸的數據是經過使用對稱算法（如 DES 或 RC4）進行加密的。
公用密鑰算法（一般爲 RSA）是用來得到加密密鑰交換和數字簽名的，此算法使用服務器的SSL數字證書中的公用密鑰。

4.TCP三次握手的過程，爲何是三次而不是兩次或者四次？（阿里巴巴 2019.08）

第一次握手：客戶端A發送一個syn（同步）包（syn=x）給服務器B，進入SYN_SEND狀態，等待服務器確認
第二次握手：服務端B收到客戶端A發送的同步包，確認客戶端的同步請求（ack=x+1）,同時也發送一個同步包，也就是一個ACK包+SYN包服務器進入SYN_RECV狀態
第三次握手：客戶端A收到服務器B的SYN+ACK包，向服務器B發送一個確認包，此包發送完畢，客戶端和服務器進入 ESTABLISHED狀態，完成三次握手
三次握手的緣由是爲了防止已失效的鏈接請求報文段忽然又傳送到了服務端，於是產生錯誤

5.講一下TCP的四次揮手（快手二面 2019.10）

第一次：主動關閉方發送一個FIN包，用來關閉主動關閉方到被動關閉方的數據傳送，也就是告訴另外一方我再也不發送數據了，但此時仍能夠接收數據
第二次：被動關閉方收到FIN包以後，發送一個確認（ACK）包給對方
第三次：被動關閉方發送一個FIN包，告訴對方不帶發送數據
第四次：主動關閉方收到FIN包以後，發送一個ACK包給對方，至此完成四次揮手

6.用戶登錄過程的簡要說明，如何判斷用戶是否登陸？（快手二面 2019.10）

用戶輸入用戶名和密碼，經過post請求將密碼和用戶名發送給服務器，服務器比對收到的用戶名、密碼和數據庫中的數據進行比對，不一致則作出響應，反饋信息給客戶端，若是比對一致則服務端生成一個session，這個session能夠存儲在內存、文件、數據庫中，同時生成一個與之一一對應的sessionID做爲cookie發送給客戶端，比對成功以後反饋信息，這時通常會進行一次重定向，重定向至登錄以後的默認頁面。判斷用戶登陸則是根據這個sessionID，每次請求會先檢查有沒有此次相似sessionID的cookie發送過來，沒有則認爲沒有登陸，有則是否有相應的session，這個session是否過時等，來判斷用戶是否登陸，登陸是否過時。

7. Get和Post的區別（字節跳動一面 2019.08）

Get 請求能緩存，Post 不能
Post 相對 Get 安全一點點，由於 Get 請求都包含在 URL 裏，且會被瀏覽器保存歷史紀錄。Post 不會，可是在抓包的狀況下都是同樣的。
URL有長度限制，會影響 Get 請求，可是這個長度限制是瀏覽器規定的，不是 RFC 規定的。
Post 能夠經過 request body來傳輸比 Get 更多的數據，Get 沒有這個技術。
Post 支持更多的編碼類型且不對數據類型限制。
Get 多用於無反作用，冪等的場景，例如搜索關鍵字。Post 多用於反作用，不冪等的場景，例如註冊。
備註：反作用指對服務器上的資源作改變，搜索是無反作用的，註冊是反作用的。冪等指發送 M 和 N 次請求（二者不相同且都大於 1），服務器上資源的狀態一致，好比註冊 10 個和 11 個賬號是不冪等的，對文章進行更改 10 次和 11 次是冪等的。由於前者是多了一個帳號（資源），後者只是更新同一個資源。

8.介紹一下DNS的查找過程？（網易互娛一面 2019.11）

遞歸查詢

第一步：在hosts靜態文件、DNS解析器緩存中查找某主機的ip地址

第二步：上一步沒法找到，去DNS本地服務器（即域服務器）查找，其本質是去區域服務器、服務器緩存中查找

第三步：本地DNS服務器查不到就根據‘根提示文件’向負責頂級域‘.com’的DNS服務器查詢

第四步：‘根DNS服務器’根據查詢域名中的‘xyz.com’，再向xyz.com的區域服務器查詢

第五步：DNS服務器直接解析該域名，將查詢到的ip再原路返回給請求查詢的主機

9. 強制緩存和協商緩存（網易互娛一面 2019.11）

強制緩存：瀏覽器在請求某一資源時，會先獲取該資源緩存的header信息，判斷是否命中強緩存（cache-control和expires信息），若命中直接從緩存中獲取資源信息，包括緩存header信息；本次請求根本就不會與服務器進行通訊；
協商緩存：若是沒有命中強緩存，瀏覽器會發送請求到服務器，請求會攜帶第一次請求返回的有關緩存的header字段信息（Last-Modified/If-Modified-Since和Etag/If-None-Match），由服務器根據請求中的相關header信息來比對結果是否協商緩存命中；若命中，則服務器返回新的響應header信息更新緩存中的對應header信息，可是並不返回資源內容，它會告知瀏覽器能夠直接從緩存獲取；不然返回最新的資源內容
關於緩存是從磁盤中獲取仍是從內存中獲取，查找了不少資料，得出了一個較爲可信的結論：Chrome會根據本地內存的使用率來決定緩存存放在哪，若是內存使用率很高，放在磁盤裏面，內存的使用率很高會暫時放在內存裏面。

10.寫一個jsonp的實現（搜狐一面 2019.12 ）

利用了 script 標籤沒有跨域限制這一「漏洞」來達到與第三方通信的目的。簡單地說，該協議就是，容許用戶傳遞一個callback參數給服務端，而後服務端返回數據時會將這個callback參數做爲函數名包裹json數據，這樣客戶端就能夠隨意定製本身的函數自動處理返回的數據了。

var flightHandler = data=>{
      console.log(data);
    }
    var url = "http://flightQuery.com/jsonp/flightResult.aspx?code=CA1998&callback=flightHandler";
    var script = document.createElement('script');
    script.setAttribute('src', url);
    document.getElementsByTagName('head')[0].appendChild(script);