服務器端面試篇

1、狀態(tài)碼

2XX（成功處理了請求狀態(tài)）
          200 服務器已經(jīng)成功處理請求，并提供了請求的網(wǎng)頁
          201 用戶新建或修改數(shù)據(jù)成功
          202 一個請求已經(jīng)進入后臺
          204 用戶刪除成功
3XX（每次請求使用的重定向不要超過5次）
          304 網(wǎng)頁上次請求沒有更新，節(jié)省帶寬和開銷
4XX（表示請求可能出錯，妨礙了服務器的處理）
          400 服務器不理解請求的語法
          401 用戶沒有權限（用戶名，密碼輸入錯誤）
          403 用戶得到授權（401相反），但是訪問被禁止
          404 服務器找不到請求的網(wǎng)頁，
5XX（表示服務器在處理請求的時候發(fā)生內部錯誤）
          500 服務器遇到錯誤，無法完成請求
          503 服務器目前無法使用（超載或停機維護）

2、304的緩存原理（添加Etag標簽.last-modified）

• 1.服務器首先產(chǎn)生Etag,服務器可在稍后使用它來判斷頁面是否被修改。本質上，客戶端通過該記號傳回服務器要求服務器驗證（客戶端）緩存）
• 2.304是HTTP的狀態(tài)碼，服務器用來標識這個文件沒有被修改，不返回內容，瀏覽器接受到這個狀態(tài)碼會去去找瀏覽器緩存的文件
• 3.流程：客戶端請求一個頁面A。服務器返回頁面A，并在A上加一個Tage客服端渲染該頁面，并把Tage也存儲在緩存中?？蛻舳嗽俅握埱箜撁鍭并將上次請求的資源和ETage一起傳遞給服務器。服務器檢查Tage.并且判斷出該頁面自上次客戶端請求之后未被修改。直接返回304

last-modified: 客服端請求資源，同時有一個last-modified的屬性標記此文件在服務器最后修改的時間，客服端第二次請求此url時，根據(jù)http協(xié)議。瀏覽器會向服務器發(fā)送一個If-Modified-Since報頭，詢問該事件之后文件是否被修改，沒修改返回304

 有了Last-Modified，為什么還要用ETag？
  1、因為如果在一秒鐘之內對一個文件進行兩次更改，Last-Modified就會不正確（Last—Modified不能識別秒單位的修改）
  2、某些服務器不能精確的得到文件的最后修改時間
  3、一些文件也行會周期新的更改，但是他的內容并不改變（僅僅改變修改的事件），這個時候我們并不希望客戶端認為文件被修改，而重新Get

ETag，為什么還要用Last-Modified？
  1、兩者互補，ETag的判斷的缺陷，比如一些圖片等靜態(tài)文件的修改
  2、如果每次掃描內容都生成ETag比較，顯然要比直接比較修改時間慢的多。


ETag是被請求變量的實體值（文件的索引節(jié)，大小和最后修改的時間的Hash值）
  1、ETag的值服務器端對文件的索引節(jié)，大小和最后的修改的事件進行Hash后得到的。

3、get/post的區(qū)別

• 1.get數(shù)據(jù)是存放在url之后，以？分割url和傳輸數(shù)據(jù)，參數(shù)之間以&相連； post方法是把提交的數(shù)據(jù)放在http包的Body中
• 2.get提交的數(shù)據(jù)大小有限制，（因為瀏覽器對url的長度有限制），post的方法提交的數(shù)據(jù)沒有限制
• 3.get需要request.queryString來獲取變量的值，而post方式通過request.from來獲取變量的值
• 4.get的方法提交數(shù)據(jù)，會帶來安全問題，比如登錄一個頁面，通過get的方式提交數(shù)據(jù)，用戶名和密碼就會出現(xiàn)在url上

4、http和https的總結

4.1、http協(xié)議的理解

1.超文本的傳輸協(xié)議，是用于從萬維網(wǎng)服務器超文本傳輸?shù)奖镜刭Y源的傳輸協(xié)議
2.基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)（HTML，圖片資源）
3.基于運用層的面向對象的協(xié)議，由于其簡潔、快速的方法、適用于分布式超媒體信息系統(tǒng)
4.http請求信息request：
    請求行（request line）、請求頭部（header）,空行和請求數(shù)據(jù)四部分構成

    請求行，用來說明請求類型,要訪問的資源以及所使用的HTTP版本.
    請求頭部，用來說明服務器要使用的附加信息
    空行，請求頭部后面的空行是必須的
    請求數(shù)據(jù)也叫主體，可以添加任意的其他數(shù)據(jù)。
5.http相應信息Response
    狀態(tài)行、消息報頭、空行和響應正文

    狀態(tài)行，由HTTP協(xié)議版本號， 狀態(tài)碼， 狀態(tài)消息 三部分組成
    消息報頭，用來說明客戶端要使用的一些附加信息
    空行，消息報頭后面的空行是必須的
    響應正文，服務器返回給客戶端的文本信息。

4.2、http和https的區(qū)別

http https
是以安全為目標的HTTP通道，簡單講是HTTP的安全版本，通過SSL加密 超文本傳輸協(xié)議。是一個客服端和服務器端請求和應答的標準（tcp）,使瀏覽器更加高效，使網(wǎng)絡傳輸減少

4.3、http1.0、1.1、2.0的區(qū)別

1.0跟1.1的區(qū)別：

長連接：HTTP1.0需要使用keep-alive參數(shù)來告知服務器建立一個長連接，而HTP1.1默認支持長連接

節(jié)約寬帶：HTTP1.1支持只發(fā)送一個header信息（不帶任何body信息）

host域（設置虛擬站點，也就是說，webserver上的多個虛擬站點可以共享同一個ip端口）：HTTP1.0沒有host域

1.1跟2.0的區(qū)別：

• 1.http2采用的二進制文本傳輸數(shù)據(jù)，而非http1文本格式，二進制在協(xié)議的解析和擴展更好
• 2.數(shù)據(jù)壓縮：對信息頭采用了HPACK進行壓縮傳輸，節(jié)省了信息頭帶來的網(wǎng)絡流量
• 3.多路復用：一個連接可以并發(fā)處理多個請求
• 4.服務器推送：我們對支持HTTP2.0的webserver請求數(shù)據(jù)的時候，服務器會順便把一些客戶端需要的資源一起推送到客戶端，免得客戶端再次創(chuàng)建連接發(fā)送請求到服務器端獲取。這種方式非常合適加載靜態(tài)資源

5、web總結

5.1、web緩存

1.web緩存就是存在于客戶端與服務器之間的一個副本、當你第一個發(fā)出請求后，緩存根據(jù)請求保存輸出內容的副本
2.緩存的好處
        （1）減少不必要的請求
    （2）降低服務器的壓力，減少服務器的消耗
    （3）降低網(wǎng)絡延遲，加快頁面打開速度（直接讀取瀏覽器的數(shù)）

5.2、常見的web安全及防護原理

• 1.sql注入原理：通郭sql命令插入到web表單遞交或者輸入活命，達到欺騙服務器執(zhí)行的惡意sql命令
  防范：1.對用戶輸入進行校驗
  2.不適用動態(tài)拼接sql
• 2.XSS（跨站腳本攻擊）：往web頁面插入惡意的html標簽或者js代碼。
  舉例子：在論壇放置一個看是安全的鏈接，竊取cookie中的用戶信息
  防范：1.盡量采用post而不使用get提交表單
  2.避免cookie中泄漏用戶的隱式
• 3.CSRF(跨站請求偽裝）：通過偽裝來自受信任用戶的請求
  舉例子：黃軼老師的webapp音樂請求數(shù)據(jù)就是利用CSRF跨站請求偽裝來獲取QQ音樂的數(shù)據(jù)
  防范：在客服端頁面增加偽隨機數(shù)，通過驗證碼
• XSS和CSRF的區(qū)別：
  1.XSS是獲取信息，不需要提前知道其他用戶頁面的代碼和數(shù)據(jù)包
  2.CSRF代替用戶完成指定的動作，需要知道其他頁面的代碼和數(shù)據(jù)包

5.3、CDN(內容分發(fā)網(wǎng)絡)

1.盡可能的避開互聯(lián)網(wǎng)有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)。使內容傳輸?shù)母旄€(wěn)定。
2.關鍵技術：內容存儲和分發(fā)技術中
3.基本原理：廣泛采用各種緩存服務器，將這些緩存服務器分布到用戶訪問相對的地區(qū)或者網(wǎng)絡中。當用戶訪問網(wǎng)絡時利用全局負載技術
        將用戶的訪問指向距離最近的緩存服務器，由緩存服務器直接相應用戶的請求（全局負載技術）

6、前端呈現(xiàn)流程（TCP三次握手，DOM樹渲染）

6.1、從輸入url到獲取頁面的完整過程

1.查詢NDS(域名解析),獲取域名對應的IP地址  查詢?yōu)g覽器緩存
2.瀏覽器與服務器建立tcp鏈接（三次握手）
3.瀏覽器向服務器發(fā)送http請求(請求和傳輸數(shù)據(jù)）
4.服務器接受到這個請求后，根據(jù)路經(jīng)參數(shù)，經(jīng)過后端的一些處理生成html代碼返回給瀏覽器
5.瀏覽器拿到完整的html頁面代碼開始解析和渲染，如果遇到外部的css或者js，圖片一樣的步驟
6.瀏覽器根據(jù)拿到的資源對頁面進行渲染，把一個完整的頁面呈現(xiàn)出來

6.2、TCP三次握手

客服端發(fā)c起請求連接服務器端s確認，服務器端也發(fā)起連接確認客服端確認。

• 第一次握手：客服端發(fā)送一個請求連接，服務器端只能確認自己可以接受客服端發(fā)送的報文段
• 第二次握手： 服務端向客服端發(fā)送一個鏈接，確認客服端收到自己發(fā)送的報文段
• 第三次握手： 服務器端確認客服端收到了自己發(fā)送的報文段

6.3、瀏覽器渲染原理及流程 DOM -> CSSOM -> render -> layout -> print

流程：解析html以及構建dom樹 -> 構建render樹 ->  布局render樹 -> 繪制render樹
    概念：1.構建DOM樹： 渲染引擎解析HTML文檔，首先將標簽轉換成DOM樹中的DOM node(包括js生成的標簽)生成內容樹
          2.構建渲染樹： 解析對應的css樣式文件信息（包括js生成的樣式和外部的css）
          3.布局渲染樹：從根節(jié)點遞歸調用，計算每一個元素的大小，位置等。給出每個節(jié)點所在的屏幕的精準位置
          4.繪制渲染樹：遍歷渲染樹，使用UI后端層來繪制每一個節(jié)點
   
    重繪：當盒子的位置、大小以及其他屬性，例如顏色、字體大小等到確定下來之后，瀏覽器便把這些顏色都按照各自的特性繪制一遍，將內容呈現(xiàn)在頁面上
        觸發(fā)重繪的條件：改變元素外觀屬性。如：color，background-color等
        重繪是指一個元素外觀的改變所觸發(fā)的瀏覽器行為，瀏覽器會根據(jù)元素的新屬性重新繪制，使元素呈現(xiàn)新的外觀
    注意：table及其內部元素需要多次計算才能確定好其在渲染樹中節(jié)點的屬性值，比同等元素要多發(fā)時間，要盡量避免使用table布局
    
    重排（重構/回流/reflow）： 當渲染書中的一部分（或全部）因為元素的規(guī)模尺寸，布局，隱藏等改變而需要重新構建，這就是回流。
        每個頁面都需要一次回流，就是頁面第一次渲染的時候
    重排一定會影響重繪，但是重繪不一定會影響重排

7、前端儲存總結

7.1、存儲方式與傳輸方式

• 1.indexBD: 是h5的本地存儲庫，把一些數(shù)據(jù)存儲到瀏覽器中，沒網(wǎng)絡，瀏覽器可以從這里讀取數(shù)據(jù)，離線運用。5m

• 2.Cookie: 通過瀏覽器記錄信息確認用戶身份，最大4kb,這也就限制了傳輸?shù)臄?shù)據(jù)，請求的性能會受到影響

• 3.Session: 服務器端使用的一種記錄客戶狀態(tài)的機制（session_id存在set_cookie發(fā)送到客服端，保存為cookie）

• 4.localStroage: h5的本地存儲，數(shù)據(jù)永久保存在客服端

    1、cookie，sessionStorage，localStorage是存放在客戶端，session對象數(shù)據(jù)是存放在服務器上
       實際上瀏覽器和服務器之間僅需傳遞session id即可，服務器根據(jù)session-id找到對應的用戶session對象
        session存儲數(shù)據(jù)更安全一些，一般存放用戶信息，瀏覽器只適合存儲一般的數(shù)據(jù)
    2、cookie數(shù)據(jù)始終在同源的http請求中攜帶，在瀏覽器和服務器來回傳遞，里面存放著session-id
       sessionStorage，localStorage僅在本地保存
    3、大小限制區(qū)別，cookie數(shù)據(jù)不超過4kb，localStorage在谷歌瀏覽中2.6MB
    4、數(shù)據(jù)有效期不同，cookie在設置的（服務器設置）有效期內有效，不管窗口和瀏覽器關閉
      sessionStorage僅在當前瀏覽器窗口關閉前有效，關閉即銷毀（臨時存儲）
      localStorage始終有效    
  

7.2、SessionStorage和localStorage區(qū)別：

1.sessionStorage用于本地存儲一個會話（session）中的數(shù)據(jù)，這些數(shù)據(jù)只有在用一個會話的頁面中才能被訪問（也就是說在第一次通信過程中）
   并且在會話結束后數(shù)據(jù)也隨之銷毀，不是一個持久的本地存儲，會話級別的儲存
2.localStorage用于持久化的本地存儲，除非主動刪除數(shù)據(jù)，否則不會過期

7.3、token、cookie、session三者的理解

• 1、token就是令牌，比如你授權(登錄)一個程序時,他就是個依據(jù),判斷你是否已經(jīng)授權該軟件（最好的身份認證，安全性好，且是唯一的）用戶身份的驗證方式
• 2、cookie是寫在客戶端一個txt文件，里面包括登錄信息之類的，這樣你下次在登錄某個網(wǎng)站，就會自動調用cookie自動登錄用戶名服務器生成，發(fā)送到瀏覽器、瀏覽器保存，下次請求再次發(fā)送給服務器（存放著登錄信息）
• 3、session是一類用來客戶端和服務器之間保存狀態(tài)的解決方案，會話完成被銷毀（代表的就是服務器和客戶端的一次會話過程）cookie中存放著sessionID，請求會發(fā)送這個id。sesion因為request對象而產(chǎn)生。

7.3、基于Token的身份驗證：（最簡單的token: uid用戶唯一的身份識別 + time當前事件戳 + sign簽名）

  1、用戶通過用戶名和密碼發(fā)送請求
  2、服務器端驗證
  3、服務器端返回一個帶簽名的token，給客戶端
  4、客戶端儲存token，并且每次用于發(fā)送請求
  5、服務器驗證token并且返回數(shù)據(jù)
  每一次請求都需要token
 cookie與session區(qū)別
  1、cookie數(shù)據(jù)存放在客戶的瀏覽器上，session數(shù)據(jù)放在服務器上。
  2、cookie不是很安全，別人可以分析存放在本地的COOKIE并進行COOKIE欺騙考慮到安全應當使用session。
  3、session會在一定時間內保存在服務器上。當訪問增多，會比較占用你服務器的性能考慮到減輕服務器性能方面，應當使用COOKIE。
  4、單個cookie保存的數(shù)據(jù)不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。

7.4、session與token區(qū)別

• 1、session認證只是把簡單的User的信息存儲Session里面，sessionID不可預測，一種認證手段。只存在服務端，不能共享到其他的網(wǎng)站和第三方App
• 2、token是oAuth Token，提供的是認證和授權，認證針對用戶，授權是針對App，目的就是讓某APP有權訪問某用戶的的信息。Token是唯一的，token不能轉移到其他的App，也不能轉到其他用戶上。（適用app）
• 3、session的狀態(tài)是存在服務器端的，客戶端只存在session id， Token狀態(tài)是存儲在客戶端的

7.5、Cookie的弊端有哪些？？？（優(yōu)勢：保存客戶端數(shù)據(jù)，分擔了服務器存儲的負擔）

  1、數(shù)量和長度的限制。每個特定的域名下最多生成20個cookie（chorme和safari沒有限制）
  2、安全性問題。