有關於瀏覽器的常見問題

從輸入url到展現的過程發生了什麼。

1. 輸入網址
2. DNS解析
   • 什麼是DNS（域名系統）解析，經過解析主機名，最終獲得主機名對應的IP地址。通俗的講，咱們更習慣記住一個網站的名字，例如www.baidu.com而不是它的ip地址，DNS就至關於電話本，好比你要找百度，我就得翻翻個人電話本，找到對應的ip。ip簡單粗暴理解就是服務器。
3. 創建TCP鏈接（三次握手四次揮手）
   1. 三次握手
   • 第一次握手：客戶端將帶有SYN（聯機標識）發送給服務器
   • 第二次握手：服務器收到SYN後，給客戶端發送一個ACK（確認標識）和SYN標識
   • 第三次握手：客戶端收到SYN標識後，給服務器發送ACK標識創建鏈接，並開始傳輸數據
   2. 四次揮手
   • 客戶端向服務器發送帶FIN（結束標識），告知服務器即將斷開；等待服務器確認。
   • 服務器收到結束標識（FIN）後，向客戶端發送確認標識（ACK）。收到斷開請求
   • 待數據傳輸完成後，服務器向客戶端發送結束標識FIN，告知客戶端能夠斷開。
   • 客戶端收到結束標識後，向服務器發送確認標識ACK，而後斷開鏈接。
4. 客戶端發送HTTP請求
5. 服務器處理請求
6. 服務起響應請求
7. 瀏覽器顯示HTML

HTTP和HTTPS

HTTP和HTTPS的區別

1. HTTP：http是超文本傳輸協議，http協議是以明文的方式發送信息，若是黑客截取了瀏覽器和服務器之間的傳輸報文，就能夠直接獲取其中的信息。存在信息竊聽、篡改、劫持的風險
2. HTTPs：htpps是基於http上基礎上添加了SSL，SSL對數據進行壓縮、加密，使得數據傳輸更加的安全。

HTTP中的get和post請求的區別

1. get：指的是從指定的資源請求數據。
2. post：向指定的資源提交要被處理的數據。例如提交表單。
3. get的參數經過url傳遞，長度也有限制，而post沒有。
4. post的參數經過請求體（request body）傳遞
5. get的安全係數比post低，由於參數傳遞直接暴露在url中，因此不能用來傳遞敏感信息。
6. get請求只能進行url編碼，而post支持多種編碼。

HTTP狀態碼

• 1xx收到請求正在處理
• 2XX該請求已被成功處理
  • 200 表示客戶端的請求已被服務器正常處理

  • 204 客戶端請求成功，可是服務器端沒有資源返回

  • 206 範圍請求

• 3XX重定向，響應結果代表，瀏覽器須要執行某些特殊的處理以正確處理請求
  • 301永久重定向

  • 302臨時重定向

  • 304該狀態碼錶示客戶端發送附帶的請求條件時，服務器容許請求訪問資源，但未知足條件的狀況。

附帶條件的請求指的是get方法的請求報文中包含If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since 中任一首部。

• 4XX客戶端錯誤
  • 400 錯誤請求，表示該請求報文中語法錯誤

  • 401 未經受權
  • 403 資源不可用，服務器理解客戶端請求，但拒絕處理它，因爲權限的緣故。

  • 404 服務器沒有找到該網址

• 5XX服務器錯誤
  • 500 內部服務錯誤，有多是前端請求參數傳錯，或者是服務器的問題

  • 503 服務器處於超負載或者是停機維護狀態（服務器正忙）

爲何產生跨域？怎麼解決

1. 跨域產生的緣由：由於瀏覽器的同源策略，在協議、域名、端口號不同的狀況下就會產生跨域。
2. 跨域的解決方法。
   1. proxy代理
      • proxy原理：瀏覽器和服務器之間存在跨域問題，而服務器和服務器之間不存在跨域問題，因此瀏覽器將請求代理給本身的服務器，再由服務器發起和後端服務器發起請求。
   2. jsonp動態建立script
   3. CORS請求頭

存儲

1. 爲何須要cookie和storage?
   • 由於http協議是無狀態的，致使了服務器沒法分辨是誰瀏覽了網頁，爲了維持用戶在網站的狀態。
2. 咱們常常須要對業務中進行一些存儲，一般分爲短暫性存儲和持久性存儲
   • 短暫性存儲，咱們只須要將數據存在內存中，只在運行時可用。
   • 持久性存儲，瀏覽器能夠存在cookie，localStorage/sessionStorage
     • cookie：一般存儲用戶的身份，登錄信息等等；http中自動攜帶，體積上限爲4K，可自行設置過時時間。通常引用js-cookie，vue-cli自行安裝依賴，引用就行。

     //一、先安裝依賴
     npm i js-cookie
     //二、在main.js中引入
     import Cookie from 'js-cookie'
     //通常的使用方法
     this.Cookie.set('name','小可愛');//設置key爲name;value爲小可愛
     this.Cookie.set("age","20",{expires:7});//設置數據，並設置有效期爲7天
     this.Cookie.get('name')//獲取數據
     this.Cookie.remove('name')//刪除數據
     複製代碼

     • storage:不會在網絡中進行傳輸，相對於cookie安全許多，可是storage是依賴cookie的。當咱們訪問一個站點時，服務器會爲這個用戶產生一個storage_id，並將這個id以cookie的形式發送給客戶端。之後這個客戶端的全部請求都會自動攜帶這個cookie。

     //storage的使用方法
     window.localStorage.setItem('key','value'); //存數據
     window.sessionStorage.setItem('key','value');
     window.localStorage.getItem('key');//獲取數據
     複製代碼

3. cookie、localStorage、sessionStorage的區別。
   • cookie：存儲數據在4k左右，每次都會攜帶http請求頭中，通常由服務器生成，能夠設置失效時間。若是由瀏覽器生成的話，默認是關閉瀏覽器失效。
   • localStorage：除非被永久清除，要否則永久保存。
   • sessionStorage：僅在當前會話有效，關閉瀏覽器或者頁面被清除。
   • Storage的存儲大小爲5m，僅在瀏覽器中存儲，不參與服務器中的通訊。

內存泄漏和內存溢出

內存泄漏：

• 內存泄漏是內存一直被佔用，致使內存浪費，導致系統崩潰。
• 內存泄漏的場景：
  • 意外的全局變量，沒法被收回。
  • 定時器沒法被正確關閉，致使所引用的外部變量沒法釋放
  • 閉包
  • 死循環

內存溢出：

• 內存溢出是指內存不夠用，內存泄漏堆積過多就會致使內存溢出。

前端網頁性能的優化

頁面上的優化

• 減小HTTP請求
  • 合併js和cs文件
  • 使用icon 圖標庫
• 減小DNS查詢
• 避免重定向
• 利用緩存；緩存文件（好比圖片）在本地存有副本，瀏覽器下次請求的時候能夠從本地磁盤直接讀取，而不會再次請求圖片的url。
  • 強緩存：不用請求服務器，直接從緩存中獲取資源。強緩存的設置是根據請求頭的cache-control字段設置的；cache-control字段有如下屬性
    • cache-control:max-age = xxxx,public
      • 客戶端和代理服務器端均可以緩存資源
      • 客戶端在xxx秒內的有效期內，若是有請求資源的需求直接讀取，狀態碼返回200
      • 若是用戶作了刷新，就像服務器發起http請求
    • cache-control:max-age = xxxx,private
      • 只容許客戶端緩存資源，服務器端不能夠
    • cache-control:max-age =xxxx,immutable
      • 客戶端在xxxx秒的有效期內，若是有請求資源的需求，直接讀取，狀態碼返回200
      • 即便用戶作了刷新操做也不會向服務器發送http請求
    • cache-control:no-cache
      • 跳過強緩存，可是不阻礙設置協商，通常作了強緩存，只有強緩存失效了纔會走協商緩存。設置了no-cache就不會走強緩存，每次請求都會詢問服務器
    • cache-control:no-store
      • 不緩存，這個讓客戶端和服務器都不能緩存資源，也就沒有所謂的強緩存和協商緩存了。
  • 協商緩存：向服務器發送請求；服務器根據這個請求頭的一些參數（Etag和last-modified）來判斷是否命中協商緩存，若是命中則返回304狀態碼，並帶上新的請求頭通知瀏覽器從緩存中讀取資源。
• 延遲加載
  • js延遲加載的方式
    • <script async></script>//只是用與外部腳本文件
    • 讓js放在頁面底部
  • 圖片懶加載利用vue-lazyload插件
• 預先加載
• 減小Dom元素數量
• 儘可能減小iframe使用
• 避免404錯誤
• 減小頁面的重繪和迴流

服務器方面的優化

• 使用CDN預解析；經過DNS預解析告訴瀏覽器將來咱們可能從某個特定的URL獲取資源，當瀏覽器真正使用到該域中的某個資源時就能夠儘快的完成DNS解析。
• 啓用Gzip
• 配置Etag
• ajax使用get方法
• 避免圖片src爲空

Cookie方面

• 減小cookie、storage大小

css方面

• 把樣式放在中
• 減小css表達式
• 使用link代替@import
  • link屬於HTML標籤，而@import是css提供的，頁面被加載時，link會同時加載，而@import引用的css會等到頁面加載完再加載
  • @import只在IE5以上才能被識別，而link是HTML標籤，沒有兼容性問題。
  • link的權重高於@import
• 雪碧圖
  • 多個圖片集合在一張的圖片
  • 使用雪碧圖能夠減小網絡請求次數。
  • 經過background-position去定位圖片在屏幕的哪一個位置

js方面

• 把腳本放在頁面底部
• 使用外部的css和js
• 移除重複腳本
• 減小Dom操做

web前端兼容性問題總結

• HTML獲取id元素
  • FireFox：document.getElementById('idname')
  • ie:document.idname或者document.getElementById('idname')
  • 解決辦法：統一使用document.getElementById('idname')
• const問題
  • FireFox：可使用var和const關鍵字定義變量
  • ie：只能使用var來關鍵字來定義變量
  • 解決辦法：所有使用var來定義變量
• window.location.href問題
  • FireFox和ie2.0版本下可使用window.location.href;FireFox1.5下只能使用window.location
  • 解決辦法：統一使用window.location
• css鼠標移上變小手的問題
  • FireFox：不支持cursor:hand，支持cursor：pointer
  • ie：支持cursor：hand和cursor：pointer
  • 解決辦法：統一使用cursor：pointer
• ie6下圖片下有空隙產生
  • 解決辦法：改變html排版，或者img設置display：block；或者vertical-align：top
• 1px的高度不一樣的問題
  • 利用flixeble.js解決。
    • 根據屏幕分辨率大小的不一樣，自動調整根元素html中的font-size，從而達到適配移動端。flixeble.js的原理是先獲取設備的像素比，而後根據設備的像素比動態的設定viewpoint的值，讓viewpoint的值（寬度）等於實際的設備物理寬度。
  • 利用僞類+transform解決
    • 給父級元素設定相對定位；position：relative，子元素利用僞類+絕對定位+transform:scale()解決。

    .parent{
        position:relative
    };
    .son::after{
        position:absolute;
        content:'';
        top:0;
        left:0;
        width:200%;
        height:200%;
        transform:scale(0.5);
        border:1px solid red;
        pointer-events:none //元素永遠不會成爲點擊事件
    }
    複製代碼

  • 利用媒體查詢判斷設備像素比值

    @midea screen and (min-device-pixel-ratio : 2){
         .son{
             border:0.5px solid red
         }
     }
     @midea screen and (min-device-pixel-ratio : 3){
         .son{
             border:0.33333px solid red
         }
     }
    複製代碼

• 解決移動端的適配問題
  • 在head設置meta

  <meta name = "viewpoint" content="width = device-width , initial-scale=1.0 , maximum-scale = 1 ,minimum-scale = 1 , user-scalable = no" />
  複製代碼

  • initial-scale：初始的縮放比
  • maximum-scale：容許用戶縮放的最大比例
  • minimum-scale：容許用戶縮放的最小比例
  • user-scalable：no；不容許用戶手動縮放

前端的安全性問題

• XSS跨站腳本攻擊是web瀏覽器攻擊中最多見的一種。原理是經過**對網頁注入可執行代碼且成功被瀏覽器執行，達成有效的攻擊目的。**通常有如下三種類型
  1. 反射性XSS；這種跨站代碼通常存在於某一連接中，當被攻擊者訪問這些連接時，跨站代碼就執行。攻擊原理:經過給別人發送帶有惡意腳本代碼參數的URL，當URL被打開時，特有的惡意代碼參數被HTML解析、執行。它的特色時非持久性，必須用戶點擊帶有特性參數的連接才能引發。
  2. 存儲型XSS：這種XSS用起來