服務(wù)端/瀏覽器/HTTP ?？紗栴}

瀏覽器

瀏覽器緩存（http緩存）

  • 瀏覽器緩存是將文件保存在客戶端，在同一個(gè)會(huì)話中會(huì)檢查緩存的副本是否足夠新，在后退網(wǎng)頁時(shí)，訪問過的資源可以直接從緩存中拿出來使用。通過這種方式減少服務(wù)器處理請(qǐng)求量，用戶獲得更快的 訪問體驗(yàn)。

  • 瀏覽器的緩存分為強(qiáng)緩存和協(xié)商緩存。瀏覽器向服務(wù)端發(fā)送請(qǐng)求時(shí)，先判斷是否命中強(qiáng)緩存在判斷是否命中協(xié)商緩存。所以強(qiáng)緩存不發(fā)送request到服務(wù)端。

  • 強(qiáng)緩存根據(jù)header信息中的expires和cache-control判斷。Cache-Control 與 Expires 可以在服務(wù)端配置同時(shí)啟用，同時(shí)啟用的時(shí)候 Cache-Control 優(yōu)先級(jí)高。 expires是http1.0的規(guī)范，它包含一個(gè)gmt格式的絕對(duì)事件字符串，代表資源失效時(shí)間。cache-control是http1.1出現(xiàn)的header信息，通過該字段中的max-age值來判斷資源失效時(shí)間，是一個(gè)相對(duì)事件，單位是秒。還有其他幾個(gè)設(shè)置值：

    s-maxage 它用于設(shè)置代理服務(wù)器的緩存時(shí)間

    no-cache：需要進(jìn)行協(xié)商緩存，發(fā)送請(qǐng)求到服務(wù)器確認(rèn)是否使用緩存。

    no-store：禁止使用緩存，每一次都要重新請(qǐng)求數(shù)據(jù)。

    public：可以被所有的用戶緩存，包括終端用戶和 CDN 等中間代理服務(wù)器。

    private：只能被終端用戶的瀏覽器緩存，不允許 CDN 等中繼緩存服務(wù)器對(duì)其緩存

  • 如果沒有命中強(qiáng)緩存，發(fā)送請(qǐng)求到服務(wù)器查看是否命中協(xié)商緩存。服務(wù)器通過請(qǐng)求中的header的內(nèi)容判斷如果命中協(xié)商緩存，服務(wù)器返回304告訴瀏覽器使用本地緩存，否則返回新的資源。

  • last-modify/if-modify-since 瀏覽器第一次請(qǐng)求一個(gè)資源時(shí)，瀏覽器返回的header中會(huì)包含一個(gè)last-modify值，這是資源最后一次更新的時(shí)間。再次發(fā)送請(qǐng)求時(shí)，header中會(huì)包含一個(gè)if-modify-since值，該值等于之間返回的last-modify。服務(wù)器收到后判斷是否命中緩存，如果命中則返回304，且不會(huì)返回任何資源。這樣做的缺點(diǎn)是當(dāng)資源在一個(gè)周期內(nèi)有回到原來的樣子，last-modify會(huì)認(rèn)為無法使用，于是有了ETag/If-None-Match

  • ETag根據(jù)資源內(nèi)容編碼，當(dāng)資源回到原來的樣子，ETag值保持不變。服務(wù)器通過瀏覽器request header中If-None-Match判斷hi否命中緩存。

  • Last-Modified 與 ETag 是可以一起使用的，服務(wù)器會(huì)優(yōu)先驗(yàn)證 ETag，一致的情況下，才會(huì)繼續(xù)比對(duì) Last-Modified，最后才決定是否返回 304。

同源政策與跨域

  • 同源策略可防止 JavaScript 發(fā)起跨域請(qǐng)求。源被定義為協(xié)議、主機(jī)名和端口號(hào)的組合。兩個(gè)頁面同時(shí)擁有相同的協(xié)議、主機(jī)名和端口號(hào)，則被認(rèn)為是同源的。此策略可防止頁面上的惡意腳本通過該頁面的文檔對(duì)象模型，訪問另一個(gè)網(wǎng)頁上的敏感數(shù)據(jù)。常見的處理跨域的方法，jsonp和cors。
  • JSONP （JSON with Padding） 這種方式跨域是通過script標(biāo)簽引入js文件，這個(gè)js文件又會(huì)返回一個(gè)js函數(shù)調(diào)用，也就是請(qǐng)求后通過callback的方式回傳結(jié)果，將需要的數(shù)據(jù)通過參數(shù)傳入
    優(yōu)點(diǎn): 兼容性更好,支持老版本瀏覽器
    缺點(diǎn)：只支持get請(qǐng)求
  • CORS （Cross Origin Resources Sharing）
    其原理是使用自定義的http頭部請(qǐng)求，能是服務(wù)器支持XMLHttpRequest跨域請(qǐng)求。
    優(yōu)點(diǎn)：
    1.支持所有類型的http請(qǐng)求
    2.比jsonp有更好的錯(cuò)誤處理機(jī)制
    3.被大多數(shù)瀏覽器所支持
  • h5的postMessage方法
    window.postMessage(message,targetOrigin) 方法是html5新引進(jìn)的特性，可以使用它來向其它的window對(duì)象發(fā)送消息，無論這個(gè)window對(duì)象是屬于同源或不同源。這種方法不能和服務(wù)端交換數(shù)據(jù)，只能在兩個(gè)窗口（iframe）之間交換數(shù)據(jù)。

瀏覽器渲染

  • 將html代碼按深度優(yōu)先遍歷生成dom樹，將css渲染成cssom樹，dom樹和cssom樹構(gòu)成render tree。瀏覽器進(jìn)入layout環(huán)節(jié)，將所有的節(jié)點(diǎn)位置計(jì)算出來，最后繪制（paint）所有節(jié)點(diǎn)的內(nèi)容

回流（reflow）和重繪（repaint）

  • 回流發(fā)生在頁面中的元素發(fā)生布局變化時(shí)，比如改變寬高，元素的規(guī)模尺寸和布局。每個(gè)頁面都會(huì)至少經(jīng)歷一次回流，就是頁面第一次渲染的時(shí)候
  • 重繪發(fā)生在元素的樣式發(fā)生變化，頁面只需要重新渲染，比如顏色改變，而不改變盒子的位置、大小等其他屬性。

為什么css放在頂部，js放在后面

  • 瀏覽器預(yù)先加載css后可以，可以提前開始渲染
  • js大部分事件處理功能在頁面渲染后才執(zhí)行，這樣可以節(jié)省加載時(shí)間，提高用戶體驗(yàn)

輸入url到瀏覽器地址欄

  1. 輸入url到地址欄按下回車
  2. 瀏覽器開始解析url，并在緩存中查找，比較緩存是否過期
  3. dns解析url對(duì)應(yīng)的ip
  4. 根據(jù)ip建立tcp連接
  5. http發(fā)起請(qǐng)求，請(qǐng)求對(duì)應(yīng)的資源
  6. 服務(wù)端處理請(qǐng)求，瀏覽器處理http響應(yīng)
  7. 瀏覽器html解析器將html文件解析，按代碼深度遍歷生成dom樹，css解析器構(gòu)建cssom樹。根據(jù)dom樹cssom樹構(gòu)成渲染樹。瀏覽器進(jìn)入layout環(huán)節(jié)，將所有的節(jié)點(diǎn)位置計(jì)算出來，最后繪制（paint）所有節(jié)點(diǎn)的內(nèi)容。
  8. 關(guān)閉tcp連接

瀏覽器的垃圾回收

?

儲(chǔ)存方式與運(yùn)輸方式

cookie，sessionStorage，localStorage

  • cookie是在客戶端記錄用戶信息的一種機(jī)制，保存在客戶端，最大4kb
  • session實(shí)在服務(wù)端記錄用戶狀態(tài)的一種機(jī)制。session對(duì)象數(shù)據(jù)儲(chǔ)存在服務(wù)端，通過瀏覽器和服務(wù)端之間傳輸session_id找到對(duì)應(yīng)的session對(duì)象。
  • sessionstorage和localstorage是webstorage提供的兩種存儲(chǔ)方式，sessionstorage僅在會(huì)話存在期間可用，localstorage除非數(shù)據(jù)被清除，否則一直可用。

token、cookie、session

  • token是令牌，他的身份認(rèn)證是唯一的，安全性最好，用于判斷用戶是否授權(quán)
  • cookie是儲(chǔ)存在客戶端的txt文件，用于存儲(chǔ)用戶信息
  • session實(shí)在服務(wù)端記錄用戶狀態(tài)的一種機(jī)制。session對(duì)象數(shù)據(jù)儲(chǔ)存在服務(wù)端，通過瀏覽器和服務(wù)端之間傳輸session_id找到對(duì)應(yīng)的session對(duì)象，回話完成即被銷毀。cookie存在session_id。

http

http狀態(tài)碼

  • 1** 請(qǐng)求正在處理
  • 2** 請(qǐng)求被成功接收并處理( 200 請(qǐng)求成功；201 用戶新建或修改數(shù)據(jù)成功；202 一個(gè)請(qǐng)求已成功進(jìn)入后臺(tái)；204 用戶刪除成功）
  • 3** 重定向，需要進(jìn)一步操作以完成請(qǐng)求( 304命中緩存)
  • 4** 客戶端錯(cuò)誤，請(qǐng)求包含語法錯(cuò)誤或無法完成請(qǐng)求(400 格式錯(cuò)誤；401 用戶沒有權(quán)限，要求身份驗(yàn)證；403，用戶得到權(quán)限，但是禁止訪問；404 錯(cuò)誤路徑找不到文件)
  • 5** 服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過程中發(fā)生了錯(cuò)誤 （500 服務(wù)器出錯(cuò)；503 服務(wù)器超負(fù)荷或停機(jī)維護(hù)）

http1、http2、http3

  • Http1.0 與 http1.1

    Http1.0 為了支持多種類型的文件下載，引入了請(qǐng)求頭響應(yīng)頭，還提供了Cache機(jī)制、狀態(tài)碼等基本參數(shù)。

    http1.1 引入了持久連接來提高效率，即在一個(gè)tcp連接中傳輸多個(gè)http請(qǐng)求，瀏覽器為每個(gè)域名最多支持六個(gè)tcp持久連接。 使用CDN實(shí)現(xiàn)域名分片機(jī)制。

  • Http1.1 與 http2.0

    http1.1的缺陷：1. tcp慢啟動(dòng) 2. 多條tcp連接會(huì)競(jìng)爭(zhēng)固定帶寬 3. 表頭阻塞問題：在一個(gè)請(qǐng)求沒有結(jié)束之前，其他請(qǐng)求只能是等待狀態(tài)。

    http2.0 的改進(jìn)： 1. 一個(gè)與域名只使用一個(gè)tcp連接 2. 多路復(fù)用 解決表頭阻塞。

    HTTP2 使用了多路復(fù)用技術(shù)，可以將請(qǐng)求通過二進(jìn)制分幀層分成多個(gè)帶有ID編號(hào)的幀數(shù)據(jù)去傳輸，這樣帶來了一個(gè)額外的好處，就是當(dāng)收到一個(gè)優(yōu)先級(jí)高的請(qǐng)求時(shí)，比如接收到JavaScript或者CSS關(guān)鍵資源的請(qǐng)求，服務(wù)器可以暫停之前的請(qǐng)求來優(yōu)先處理關(guān)鍵資源的請(qǐng)求。

  • Http2.0 與 http3.0

    http2.0 的缺陷： tcp的隊(duì)頭阻塞，tcp建立連接的延時(shí)

    http3.0 的改進(jìn)： QUIC協(xié)議（Quick UDP Internet Connections）

http/https

  • http無需證書，https需要申請(qǐng)證書
  • http是超文本傳輸協(xié)議，是明文傳輸。https是具有安全性的ssl加密傳輸協(xié)議
  • http的端口號(hào)是80，https的端口號(hào)是443
  • https的加密過程：https是http將報(bào)文信息傳輸給ssl socket進(jìn)行加密，ssk socket加密后再將報(bào)文發(fā)送給tcp socket，目的主機(jī)將tcp套接字報(bào)文獲取后傳給ssl socket，ssl解密后交給對(duì)應(yīng)的進(jìn)程。

get/post

  • get：從指定的資源請(qǐng)求數(shù)據(jù) post： 向指定的資源提交已處理的數(shù)據(jù)
  • get：get數(shù)據(jù)放在url后，用？分隔url和傳輸數(shù)據(jù)，參數(shù)用&相連 post：post數(shù)據(jù)在http的header包的body中傳輸
  • get：get移交的數(shù)據(jù)長(zhǎng)度有限制，因?yàn)闉g覽器對(duì)url長(zhǎng)度有限制（2048字符），post沒有限制
  • get可被瀏覽器緩存，產(chǎn)生的url地址可以存為書簽,get請(qǐng)求參數(shù)會(huì)被保存在瀏覽器的歷史記錄里，post均不行
  • get的數(shù)據(jù)在url中對(duì)所有人都可見，安全性更差

TCP三次握手

  • 客戶端傳給服務(wù)端syn包請(qǐng)求建立連接客戶端進(jìn)入syn_send狀態(tài)，服務(wù)端返回確認(rèn)碼ack并發(fā)出一個(gè)自己的syn包，服務(wù)端進(jìn)入syn_recv狀態(tài)，客戶端收到收到服務(wù)端的syn+ack包，返回確認(rèn)碼ack?？蛻舳撕头?wù)端進(jìn)入established狀態(tài)，三次握手完成

TCP四次揮手

  • 客戶端向服務(wù)端發(fā)送fin碼請(qǐng)求關(guān)閉客戶端到服務(wù)端的數(shù)據(jù)連接，服務(wù)端返回ack碼。服務(wù)端關(guān)閉與客戶端的數(shù)據(jù)連接，發(fā)送一個(gè)fin碼，客戶端返回ack碼確認(rèn)。收到ack，服務(wù)端進(jìn)入closed狀態(tài)，客戶端再等待2msl（最大生存時(shí)間）時(shí)間后進(jìn)入closed狀態(tài)。為什么要等2msl？如果最后傳給服務(wù)端的ack丟失，服務(wù)端將在超時(shí)后重發(fā)fin包，如果在2msl時(shí)間內(nèi)沒有等到服務(wù)端重發(fā)的fin包，則證明四次揮手完成。

網(wǎng)絡(luò)七層模型

  • 應(yīng)用層: 向客戶提供應(yīng)用，文件傳輸，電子郵件，虛擬終端 http,ftp,telent,dns,smtp
  • 表達(dá)層： 數(shù)據(jù)格式化，代碼轉(zhuǎn)化
  • 會(huì)話層： 解除或建立與別的節(jié)點(diǎn)之間的聯(lián)系
  • 傳輸層: 對(duì)報(bào)文進(jìn)行分組或重組，以tcp/udp的形式封裝報(bào)文 tcp,udp
  • 網(wǎng)絡(luò)層： 為數(shù)據(jù)包選擇路由，將報(bào)文發(fā)送給目標(biāo)網(wǎng)絡(luò)或主機(jī) ip
  • 鏈路層： 負(fù)責(zé)封裝和解析ip報(bào)文
  • 物理層： 物理形式上的數(shù)據(jù)傳輸

CDN

  • Content Delivery Network 內(nèi)容分發(fā)網(wǎng)絡(luò)。是一組在地理上分散的服務(wù)器，他們協(xié)同工作以應(yīng)對(duì)互聯(lián)網(wǎng)的內(nèi)容的快速交付。CDN可以將用戶請(qǐng)求重定向到最近的服務(wù)節(jié)點(diǎn)上，解決網(wǎng)絡(luò)擁堵的問題，提高用戶的瀏覽體驗(yàn)。

常見的web安全與防御

  • sql注入 ：將sql代碼偽裝到請(qǐng)求的輸入?yún)?shù)中，傳入到服務(wù)器解析并執(zhí)行的一種方法。防御：對(duì)用戶輸入進(jìn)行校驗(yàn)
  • xss（cross site scripting）：跨站腳本攻擊，往web頁面中插入惡意的html標(biāo)簽和js腳本，比如在論壇中放置一個(gè)看似安全的連接，來獲取用戶的cookie信息。防御： 將重要的cookie設(shè)置為http only，js中的document.cookie會(huì)失效
  • csrf（cross site request forgery）：跨站點(diǎn)請(qǐng)求偽造，偽裝受信任的用戶發(fā)送請(qǐng)求。防御：通過驗(yàn)證碼，強(qiáng)制用戶進(jìn)行交互，避免用戶在不知情的情況下被發(fā)送請(qǐng)求。
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點(diǎn)，簡(jiǎn)書系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容