前端面試總結(jié)(2)--從輸入U(xiǎn)RL到頁(yè)面加載完成，都發(fā)生了什么

眾里尋他千百度。驀然回首，那人卻在，燈火闌珊處。
只因?yàn)槊嬖嚬僭谌巳褐卸嗫戳四阋谎?，你回首，笑靨如花，那一刻，仿佛三千寵愛(ài)寄予你一身，你的生活充滿了無(wú)限的可能性，你的腦海構(gòu)建了無(wú)數(shù)的未來(lái)，你有著無(wú)限的潛力，不用多久，你就能升職加薪，當(dāng)上總經(jīng)理，出任CEO，迎娶白富美，走上人生巔峰。
直到那句“從輸入U(xiǎn)RL到頁(yè)面加載完成，都發(fā)生了什么”傳入耳中，你才明白，那日夕陽(yáng)下的問(wèn)答，是你逝去的青春。

序言

本文基于面試中經(jīng)典面試題“從輸入U(xiǎn)RL到頁(yè)面加載完成，都發(fā)生了什么”這個(gè)問(wèn)題整理相關(guān)的知識(shí)點(diǎn)。

當(dāng)你讀完本文，無(wú)論是否贊同，是否收藏轉(zhuǎn)載，是否推薦分享，都掙脫不了一個(gè)事實(shí)——于你的面試毫無(wú)意義。

除非，當(dāng)你看到下面列出來(lái)的每一個(gè)知識(shí)點(diǎn)時(shí)，腦中頓時(shí)生出一篇500字小黃作文，言語(yǔ)風(fēng)輕云淡卻擲地有聲，邏輯無(wú)懈可擊時(shí)，你便可以與面試官談笑風(fēng)生了。那時(shí)，當(dāng)你手中握著100+offers時(shí)，別忘了，回來(lái)點(diǎn)個(gè)贊，順便談?wù)劅艋痍@珊下，你心中的小作文~

因此，本文目的是匯總這個(gè)問(wèn)題可能遇到的考點(diǎn)，重點(diǎn)在于拋磚引玉。

P.S. 博主?真?嘔心瀝血整理，各位靚仔靚妹覺(jué)得有用的話點(diǎn)個(gè)贊再收藏唄~

從輸入U(xiǎn)RL到頁(yè)面加載完成，都發(fā)生了什么

一個(gè)經(jīng)典、復(fù)雜、沒(méi)有標(biāo)準(zhǔn)答案而又直擊程序猿/媛靈魂深處的考題，網(wǎng)上答案一籮筐，類似回答看了一百遍，內(nèi)心仿佛有了一百種表達(dá)，總覺(jué)得遇到這個(gè)問(wèn)題必然會(huì)對(duì)答如流，結(jié)果往往是，話到嘴邊不知如何出口，一出口便被懟得滿地找牙。

經(jīng)典總是有其經(jīng)典的道理的。這個(gè)問(wèn)題即要考廣度，又要考深度，可謂面試題中的老流氓，你了解http協(xié)議，他問(wèn)你DNS解析都做了什么，你和他談tcp的三次握手，他問(wèn)你跨域請(qǐng)求都有哪些解決方案。總之，這道題總是可以讓面試官處立于不敗之地。

本文同樣給不出標(biāo)準(zhǔn)答案。在本文，這個(gè)問(wèn)題討論的重點(diǎn)，不在于問(wèn)題的答案，而在于如何思考問(wèn)題，以及給出問(wèn)題背后可能存在的考點(diǎn)。

首先，給出一個(gè)總體的流程。

1. 一個(gè)極其粗糙且簡(jiǎn)化的流程

這個(gè)回答來(lái)自stackoverflow 中的一個(gè)問(wèn)題：what happens when you type in a URL in browser的最高贊回答，大意是這樣的：

Assume the simplest possible HTTP request (no HTTPS, no HTTP2, no extras), simplest possible DNS, no proxies, single-stack IPv4, one HTTP request only, a simple HTTP server on the other end, and no problems in any step. This is, for most contemporary intents and purposes, an unrealistic scenario; all of these are far more complex in actual use, and the tech stack has become an order of magnitude more complicated since this was written. With this in mind, the following timeline is still somewhat valid:
假設(shè)最簡(jiǎn)單的HTTP請(qǐng)求（沒(méi)有HTTPS，沒(méi)有HTTP2，沒(méi)有其他功能），最簡(jiǎn)單的DNS，沒(méi)有代理，單堆棧IPv4，僅一個(gè)HTTP請(qǐng)求，另一端同樣是一個(gè)簡(jiǎn)單的HTTP服務(wù)器，而且整個(gè)流程中每個(gè)步驟都不出錯(cuò)。
對(duì)于絕大多數(shù)現(xiàn)代瀏覽器實(shí)際的工作流程，這是一種過(guò)于簡(jiǎn)單且不現(xiàn)實(shí)的場(chǎng)景。盡管如此，基于上述假設(shè)，以下步驟仍然在一定程度上是有效的：

  1. browser checks cache; if requested object is in cache and is fresh, skip to #9 --> 瀏覽器檢查緩存，如果請(qǐng)求的對(duì)象在緩存中并且沒(méi)有過(guò)期，跳至步驟9
  2. browser asks OS for server's IP address --> 瀏覽器要求操作系統(tǒng)(OS)提供服務(wù)器的IP地址
  3. OS makes a DNS lookup and replies the IP address to the browser --> 操作系統(tǒng)(OS)進(jìn)行DNS查找并返回IP地址給瀏覽器
  4. browser opens a TCP connection to server (this step is much more complex with HTTPS) --> 瀏覽器與服務(wù)器建立TCP連接（如果使用https協(xié)議，這一步會(huì)更復(fù)雜）
  5. browser sends the HTTP request through TCP connection --> 瀏覽器通過(guò)TCP連接發(fā)送HTTP請(qǐng)求
  6. browser receives HTTP response and may close the TCP connection, or reuse it for another request --> 瀏覽器接收HTTP響應(yīng)，之后可能關(guān)閉TCP連接，也可能將其重新用于其他請(qǐng)求
  7. browser checks if the response is a redirect or a conditional response (3xx result status codes), authorization request (401), error (4xx and 5xx), etc.; these are handled differently from normal responses (2xx) --> 瀏覽器檢查響應(yīng)是重定向響應(yīng)還是條件響應(yīng)（3xx為重定向意義的一類狀態(tài)碼），授權(quán)請(qǐng)求（401），錯(cuò)誤（4xx和5xx）等； 瀏覽器對(duì)這些情況處理方式與正常響應(yīng)方式不同（2xx）。
  8. if cacheable, response is stored in cache --> 如果響應(yīng)是可緩存的，則將響應(yīng)存儲(chǔ)在緩存中
  9. browser decodes response (e.g. if it's gzipped) --> 瀏覽器對(duì)響應(yīng)進(jìn)行解析（例如，是否壓縮）
  10. browser determines what to do with response (e.g. is it a HTML page, is it an image, is it a sound clip?) --> 瀏覽器確定如何處理響應(yīng)（例如，響應(yīng)是HTML頁(yè)面，圖像還是音頻片段？）
  11. browser renders response, or offers a download dialog for unrecognized types --> 如果瀏覽器可以識(shí)別響應(yīng)的類型，就會(huì)渲染響應(yīng)；如果無(wú)法識(shí)別響應(yīng)的類型，則提供下載對(duì)話框。

簡(jiǎn)單來(lái)說(shuō)，基于一切流程最簡(jiǎn)化且正常工作的情況，從輸入U(xiǎn)RL到頁(yè)面加載完成，瀏覽器做了上述步驟的工作。換句話說(shuō)，上述步驟，是這個(gè)考點(diǎn)最簡(jiǎn)單的完整回答。如果你連這個(gè)最簡(jiǎn)單的流程都講不清楚，恐怕你只能用微笑來(lái)緩解你與面試官面面相覷的尷尬了。

2. 每個(gè)步驟都只是摘要

在你終于流暢地講完了上述流程，千萬(wàn)別沾沾自喜，這只是敲門磚，接下來(lái)才是殘酷的沙場(chǎng)，迎接你的將是面試官大量的虎狼之詞嚴(yán)謹(jǐn)問(wèn)題。

為了能夠應(yīng)付面試官千變?nèi)f化的提問(wèn)，最有效的辦法只有一個(gè)，掌握所有問(wèn)題的答案。這聽(tīng)起來(lái)很不現(xiàn)實(shí)，沒(méi)錯(cuò)，如果你能回答所有問(wèn)題，那坐在面試官位置的人應(yīng)該就是你了。但是，如果你比別人多答對(duì)一個(gè)問(wèn)題的話。。。這么想想是不是還有點(diǎn)小激動(dòng)呢~

面試官的問(wèn)題，無(wú)非就是對(duì)你掌握的知識(shí)點(diǎn)的考察。面對(duì)面試官的提問(wèn)，你首先需要從自己的知識(shí)體系中定位知識(shí)點(diǎn)。如果找不到，就說(shuō)明這是知識(shí)點(diǎn)盲點(diǎn)。

何為知識(shí)體系呢？知識(shí)體系通常呈現(xiàn)為金字塔結(jié)構(gòu)，以這個(gè)問(wèn)題為例：“從輸入U(xiǎn)RL到頁(yè)面加載完成，都發(fā)生了什么”這個(gè)主題，就是金字塔的塔尖；而塔尖下一層次，就是1.1節(jié)提到的步驟，塔尖的主題和下一層次的步驟呈縱向關(guān)系。在金字塔結(jié)構(gòu)中，位于某組思想上一層次的思想是對(duì)這一組思想的概括，這一組思想則是對(duì)其上一層次思想的解釋和支持。

到目前為止，本文只討論到了第二層次，而面試官會(huì)對(duì)第二層次中每個(gè)步驟都可以提出各種問(wèn)題，換句話說(shuō)，你需要基于現(xiàn)有的兩層架構(gòu)，繼續(xù)深入，建立第三層，第四層，甚至第五層結(jié)構(gòu)來(lái)完善自己的知識(shí)體系。這樣，面對(duì)考官對(duì)整個(gè)知識(shí)體系的考察，你才能從容不迫地應(yīng)對(duì)。

本文接下來(lái)主要對(duì)這個(gè)知識(shí)體系的第三層進(jìn)行總結(jié)歸納，可能適當(dāng)延伸，盡可能覆蓋主要考點(diǎn)。

2.1 瀏覽器中輸入U(xiǎn)RL

這是整個(gè)問(wèn)題的第一個(gè)點(diǎn)，下面會(huì)列出主要的考點(diǎn)。

2.1.1 URL的概念

  1. 定義：Uniform Resource Locator，統(tǒng)一資源定位符，是一種特殊類型的URI(Uniform Resource Identifiers)，是瀏覽器用來(lái)檢索web上公布的任何資源的機(jī)制。URL無(wú)非就是一個(gè)給定的獨(dú)特資源在Web上的地址。理論上說(shuō)，每個(gè)有效的URL都指向一個(gè)獨(dú)特的資源。這個(gè)資源可以是一個(gè)HTML頁(yè)面，一個(gè)CSS文檔，一幅圖像，等等。

  2. URL的組成，包括了協(xié)議，域名，端口，路徑等。詳細(xì)內(nèi)容參見(jiàn)： 什么是URL

  3. 同源策略與跨域問(wèn)題，基于URL的組成，這個(gè)問(wèn)題是對(duì)URL問(wèn)題的延伸，屬于更深層次的問(wèn)題。此處不做展開(kāi)，會(huì)在新開(kāi)一篇blog給出自己的理解。

  4. Get和Post有什么區(qū)別

    1. 直觀區(qū)別

      • 定義上，get是從指定的資源請(qǐng)求數(shù)據(jù)，而post是向指定的資源提交要被處理的資源
      • get請(qǐng)求的數(shù)據(jù)放在url后，以?分隔url和傳輸?shù)臄?shù)據(jù)，參數(shù)之間以&符號(hào)連接，post把提交的數(shù)據(jù)放在http的body中
      • get提交的數(shù)據(jù)大小有限，通常受到瀏覽器url長(zhǎng)度的限制，不同瀏覽器的限制不同；post提交的數(shù)據(jù)量沒(méi)有限制。
      • get通常只能傳遞ASCII字符，而post沒(méi)有限制。

    2. 深層次的討論：討論兩者的區(qū)別，實(shí)際上就是在理解，在哪些情況下，應(yīng)該去用get請(qǐng)求，哪些情況下應(yīng)該用post請(qǐng)求

      • 從http協(xié)議定義來(lái)說(shuō)，get和post區(qū)別在于語(yǔ)義上，get是請(qǐng)求數(shù)據(jù)，post是提交數(shù)據(jù)，對(duì)于怎樣攜帶數(shù)據(jù)，將數(shù)據(jù)放在url后還是http請(qǐng)求的body中，協(xié)議中并沒(méi)有相關(guān)的規(guī)定。換句話說(shuō)，如果不考慮具體的實(shí)現(xiàn)，get和post在定義上只有語(yǔ)義區(qū)別。
      • 光有定義是不行的，我們?cè)趯?shí)際使用中，需要實(shí)現(xiàn)get和post請(qǐng)求，那么問(wèn)題就歸結(jié)為，該怎樣使用get和post，應(yīng)該取決于實(shí)際中怎樣實(shí)現(xiàn)的get和post。根據(jù)RFC規(guī)范，get的語(yǔ)義上是請(qǐng)求資源，post語(yǔ)義上是處理資源，具體實(shí)現(xiàn)兩種方法時(shí)，必須考慮其語(yǔ)義，做出符合語(yǔ)義的行為。在理論上，get應(yīng)該是安全、冪等、可緩存的，而post不安全、不冪等、大部分情況下不可緩存。所謂安全，是指請(qǐng)求不會(huì)引起服務(wù)器資源的變化，因此是無(wú)害的；冪等是指多次請(qǐng)求和一次請(qǐng)求的結(jié)果完全相同。但是，規(guī)范定義的并不代表具體的實(shí)現(xiàn)，所謂的實(shí)現(xiàn)，通常是指瀏覽器根據(jù)RFC規(guī)范對(duì)方法的實(shí)現(xiàn)。
      • 對(duì)于具體的實(shí)現(xiàn)，通常是指，瀏覽器做了哪些事情來(lái)處理get和post請(qǐng)求。例如，通常情況下，get請(qǐng)求的數(shù)據(jù)可以再 url中可見(jiàn)，而post請(qǐng)求的數(shù)據(jù)不會(huì)顯示在url中；get和post請(qǐng)求的數(shù)據(jù)量大小不一致，數(shù)據(jù)編碼類型的不一致；get后退、刷新時(shí)無(wú)影響，而post數(shù)據(jù)會(huì)被重新提交（瀏覽器會(huì)提醒）等。瀏覽器在實(shí)現(xiàn)請(qǐng)求方法時(shí)提出了一些規(guī)范要求，這些要求最終體現(xiàn)在實(shí)際的get、post請(qǐng)求時(shí)所表現(xiàn)出來(lái)的不一致。
      • 瀏覽器的實(shí)現(xiàn)，是為了更好的讓get和post按照其語(yǔ)義來(lái)實(shí)現(xiàn)功能。在我們討論完get和post的這些區(qū)別后，問(wèn)題變成了，我們?cè)撛鯓觼?lái)選擇使用get請(qǐng)求和post請(qǐng)求？在實(shí)際中，不遵循語(yǔ)義去實(shí)現(xiàn)請(qǐng)求也是可行的，例如get修改數(shù)據(jù)，post獲取資源列表。我們可以在get和post請(qǐng)求時(shí)使用完全相同的語(yǔ)法，我們可以將get的數(shù)據(jù)放在http的body中，也可以在post的url中發(fā)送數(shù)據(jù)，盡管這些方式在瀏覽器中可能會(huì)受到限制，但實(shí)現(xiàn)了功能，語(yǔ)法上的正確并不代表語(yǔ)義的正確。我們應(yīng)該遵循對(duì)get、post請(qǐng)求方法的規(guī)范，去設(shè)計(jì)我們的請(qǐng)求，這樣才能更好地得到瀏覽器的支持，更好地處理實(shí)際的業(yè)務(wù)，讓我們的網(wǎng)站更易于理解。

2.1.2 瀏覽器對(duì)URL的長(zhǎng)度限制

瀏覽器對(duì)URL的長(zhǎng)度限制

  1. IE瀏覽器對(duì)URL的長(zhǎng)度現(xiàn)限制為2048字節(jié)。
  2. 360極速瀏覽器對(duì)URL的長(zhǎng)度限制為2118字節(jié)。
  3. Firefox(Browser)對(duì)URL的長(zhǎng)度限制為65536字節(jié)。
  4. Safari(Browser)對(duì)URL的長(zhǎng)度限制為80000字節(jié)。
  5. Opera(Browser)對(duì)URL的長(zhǎng)度限制為190000字節(jié)。
  6. Google(chrome)對(duì)URL的長(zhǎng)度限制為8182字節(jié)。
    ————————————————
    版權(quán)聲明：本文為CSDN博主「Martin_Yelvin」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
    原文鏈接：https://blog.csdn.net/qq_36279445/article/details/102854491

2.2 瀏覽器的緩存機(jī)制

又是一個(gè)龐大而又深刻的問(wèn)題，這里給出一篇Blog作為參考：

這篇文章字?jǐn)?shù)5k+，很長(zhǎng)，但是很系統(tǒng)很全面，而最最重要的一點(diǎn)是：這篇文章中的所有內(nèi)容都是考點(diǎn)。

換句話說(shuō)，請(qǐng)深刻理解這篇文章，并用自己的語(yǔ)言將整個(gè)機(jī)制系統(tǒng)地表述出來(lái)。

2.3 DNS域名解析

理解了緩存機(jī)制，你距離成功更近了一步。

當(dāng)瀏覽器沒(méi)有在緩存中找到請(qǐng)求的對(duì)象時(shí)，瀏覽器就要去存放資源的地方獲取請(qǐng)求的對(duì)象了。那資源到底存放在什么地方呢？這就涉及到當(dāng)前的話題，DNS域名解析了。

簡(jiǎn)單來(lái)說(shuō)，DNS域名解析過(guò)程，就是根據(jù)輸入U(xiǎn)RL中的域名信息，查詢獲取域名對(duì)應(yīng)主機(jī)IP的過(guò)程。

2.3.1 基本概念

  1. 什么是域名(domain name)

  2. IP Address

  3. DNS的定義

    百度百科
    域名系統(tǒng)（Domain Name System，縮寫(xiě)：DNS）是互聯(lián)網(wǎng)的一項(xiàng)服務(wù)。它作為將域名和IP地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)，能夠使人更方便地訪問(wèn)互聯(lián)網(wǎng)。DNS使用TCP和UDP端口53。當(dāng)前，對(duì)于每一級(jí)域名長(zhǎng)度的限制是63個(gè)字符，域名總長(zhǎng)度則不能超過(guò)253個(gè)字符。DNS協(xié)議是用來(lái)將域名轉(zhuǎn)換為IP地址（也可以將IP地址轉(zhuǎn)換為相應(yīng)的域名地址）。

    維基百科
    The Domain Name System (DNS) is a hierarchical decentralized naming system for computers, services, or other resources connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities. Most prominently, it translates more readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. By providing a worldwide, distributed directory service, the Domain Name System is an essential component of the functionality on the Internet, that has been in use since 1985.

2.3.2 DNS解析過(guò)程

這部分只給出簡(jiǎn)要步驟，記住，每一個(gè)步驟都是摘要，細(xì)節(jié)需要你自己去補(bǔ)充。

什么是DNS？
DNS查找信息通常會(huì)在查詢計(jì)算機(jī)內(nèi)部緩存或在DNS基礎(chǔ)結(jié)構(gòu)中遠(yuǎn)程緩存。DNS查找通常有8個(gè)步驟。緩存DNS信息時(shí)，將從DNS查找過(guò)程中跳過(guò)步驟，這樣可以更快地完成。下面的示例概述了沒(méi)有緩存任何內(nèi)容時(shí)的所有8個(gè)步驟。
DNS查找中的8個(gè)步驟：

  1. 用戶在Web瀏覽器中鍵入“example.com”，查詢將進(jìn)入Internet并由DNS遞歸解析程序接收。
  2. 解析器然后查詢DNS根名稱服務(wù)器（。）。
  3. 然后，根服務(wù)器使用頂級(jí)域（TLD）DNS服務(wù)器（例如.com或.net）的地址響應(yīng)解析器，該服務(wù)器存儲(chǔ)其域的信息。在搜索example.com時(shí)，我們的請(qǐng)求指向.com TLD。
  4. 解析器然后向.com TLD提出請(qǐng)求。
  5. 然后，TLD服務(wù)器使用域名服務(wù)器example.com的IP地址進(jìn)行響應(yīng)。
  6. 最后，遞歸解析器向域的名稱服務(wù)器發(fā)送查詢。
  7. 然后，example.com的IP地址將從名稱服務(wù)器返回到解析程序。
  8. 然后DNS解析器使用最初請(qǐng)求的域的IP地址響應(yīng)Web瀏覽器。
    ————————————————
    版權(quán)聲明：本文為CSDN博主「Mr_Wing5」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
    原文鏈接：https://blog.csdn.net/jiayu5100687/article/details/81985968

2.4 TCP連接

經(jīng)過(guò)DNS解析，終于拿到了服務(wù)器的IP地址。接下來(lái)，瀏覽器首先需要和目標(biāo)服務(wù)器建立連接。

這部分最常見(jiàn)的考點(diǎn)是TCP建立連接的過(guò)程（三次握手，四次分手），TCP與UDP的區(qū)別和TCP如何保證可靠性。

2.4.1 TCP三次握手與四次揮手

這里給出一篇講解TCP三次握手與四次揮手的文章，講的非常清楚：

除了基本的過(guò)程，這篇文章中提到的點(diǎn)也很重要，特意拉出來(lái)強(qiáng)調(diào)一下：

為什么TCP客戶端最后還要發(fā)送一次確認(rèn)呢？
一句話，主要防止已經(jīng)失效的連接請(qǐng)求報(bào)文突然又傳送到了服務(wù)器，從而產(chǎn)生錯(cuò)誤。
如果使用的是兩次握手建立連接，假設(shè)有這樣一種場(chǎng)景，客戶端發(fā)送了第一個(gè)請(qǐng)求連接并且沒(méi)有丟失，只是因?yàn)樵诰W(wǎng)絡(luò)結(jié)點(diǎn)中滯留的時(shí)間太長(zhǎng)了，由于TCP的客戶端遲遲沒(méi)有收到確認(rèn)報(bào)文，以為服務(wù)器沒(méi)有收到，此時(shí)重新向服務(wù)器發(fā)送這條報(bào)文，此后客戶端和服務(wù)器經(jīng)過(guò)兩次握手完成連接，傳輸數(shù)據(jù)，然后關(guān)閉連接。此時(shí)此前滯留的那一次請(qǐng)求連接，網(wǎng)絡(luò)通暢了到達(dá)了服務(wù)器，這個(gè)報(bào)文本該是失效的，但是，兩次握手的機(jī)制將會(huì)讓客戶端和服務(wù)器再次建立連接，這將導(dǎo)致不必要的錯(cuò)誤和資源的浪費(fèi)。
如果采用的是三次握手，就算是那一次失效的報(bào)文傳送過(guò)來(lái)了，服務(wù)端接受到了那條失效報(bào)文并且回復(fù)了確認(rèn)報(bào)文，但是客戶端不會(huì)再次發(fā)出確認(rèn)。由于服務(wù)器收不到確認(rèn)，就知道客戶端并沒(méi)有請(qǐng)求連接。
————————————————
版權(quán)聲明：本文為CSDN博主「小書(shū)go」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qzcsu/article/details/72861891

為什么建立連接是三次握手，關(guān)閉連接確是四次揮手呢？
建立連接的時(shí)候， 服務(wù)器在LISTEN狀態(tài)下，收到建立連接請(qǐng)求的SYN報(bào)文后，把ACK和SYN放在一個(gè)報(bào)文里發(fā)送給客戶端。
而關(guān)閉連接時(shí)，服務(wù)器收到對(duì)方的FIN報(bào)文時(shí)，僅僅表示對(duì)方不再發(fā)送數(shù)據(jù)了但是還能接收數(shù)據(jù)，而自己也未必全部數(shù)據(jù)都發(fā)送給對(duì)方了，所以己方可以立即關(guān)閉，也可以發(fā)送一些數(shù)據(jù)給對(duì)方后，再發(fā)送FIN報(bào)文給對(duì)方來(lái)表示同意現(xiàn)在關(guān)閉連接，因此，己方ACK和FIN一般都會(huì)分開(kāi)發(fā)送，從而導(dǎo)致多了一次。
————————————————
版權(quán)聲明：本文為CSDN博主「小書(shū)go」的原創(chuàng)文章，遵循 CC 4.0 BY-SA 版權(quán)協(xié)議，轉(zhuǎn)載請(qǐng)附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qzcsu/article/details/72861891

2.4.2 TCP與UDP的對(duì)比

同樣用一篇blog作為回答，更多地展開(kāi)就需要靠自己咯。

2.4.3 TCP如何保證傳輸可靠性

2.5 瀏覽器發(fā)送HTTP請(qǐng)求

當(dāng)瀏覽器終于與服務(wù)器建立了TCP連接了，瀏覽器就可以發(fā)送HTTP請(qǐng)求了。

TCP與HTTP之間什么關(guān)系呢？引用知乎上的一個(gè)回答：

打個(gè)比方，你有一些想法，你把他們變成文字寫(xiě)在信紙上，這是http
你把這個(gè)信紙塞進(jìn)信封，這個(gè)信封是tcp
你把這個(gè)信封寫(xiě)上地址交給郵局，這地址是IP

引自：TCP/IP 和 HTTP 的區(qū)別和聯(lián)系是什么？ - 無(wú)胖次不生活的回答 - 知乎
https://www.zhihu.com/question/38648948/answer/239925503

這個(gè)比喻非常貼切，可以很好地理解TCP與HTTP之間的關(guān)系。

作為前端攻城獅，HTTP是最常被問(wèn)起的考點(diǎn)。接下來(lái)列考點(diǎn)，這里只列出了部分關(guān)鍵點(diǎn)，其中大部分引用內(nèi)容標(biāo)題可點(diǎn)擊查看細(xì)節(jié)~

2.5.1 HTTP

定義
超文本傳輸??協(xié)議（HTTP）是一個(gè)用于傳輸超媒體文檔（例如 HTML）的應(yīng)用層協(xié)議。它是為 Web 瀏覽器與 Web 服務(wù)器之間的通信而設(shè)計(jì)的，但也可以用于其他目的。HTTP 遵循經(jīng)典的客戶端-服務(wù)端模型，客戶端打開(kāi)一個(gè)連接以發(fā)出請(qǐng)求，然后等待它收到服務(wù)器端響應(yīng)。HTTP 是無(wú)狀態(tài)協(xié)議，這意味著服務(wù)器不會(huì)在兩個(gè)請(qǐng)求之間保留任何數(shù)據(jù)（狀態(tài)）。該協(xié)議雖然通?；?TCP/IP 層，但可以在任何可靠的傳輸層上使用；也就是說(shuō)，不像 UDP，它是一個(gè)不會(huì)靜默丟失消息的協(xié)議。RUDP——作為 UDP 的可靠化升級(jí)版本——是一種合適的替代選擇。

  • HTTP概述
    HTTP是一種能夠獲取如 HTML 這樣的網(wǎng)絡(luò)資源的 protocol(通訊協(xié)議)。它是在 Web 上進(jìn)行數(shù)據(jù)交換的基礎(chǔ)，是一種 client-server 協(xié)議，也就是說(shuō)，請(qǐng)求通常是由像瀏覽器這樣的接受方發(fā)起的。一個(gè)完整的Web文檔通常是由不同的子文檔拼接而成的，像是文本、布局描述、圖片、視頻、腳本等等。
    在這里插入圖片描述

    客戶端和服務(wù)端通過(guò)交換各自的消息（與數(shù)據(jù)流正好相反）進(jìn)行交互。由像瀏覽器這樣的客戶端發(fā)出的消息叫做 requests，被服務(wù)端響應(yīng)的消息叫做 responses。
    在這里插入圖片描述

    HTTP被設(shè)計(jì)于20世紀(jì)90年代初期，是一種可擴(kuò)展的協(xié)議。它是應(yīng)用層的協(xié)議，通過(guò)TCP，或者是TLS－加密的TCP連接來(lái)發(fā)送，理論上任何可靠的傳輸協(xié)議都可以使用。因?yàn)槠淞己玫臄U(kuò)展性，時(shí)至今日，它不僅被用來(lái)傳輸超文本文檔，還用來(lái)傳輸圖片、視頻或者向服務(wù)器發(fā)送如HTML表單這樣的信息。HTTP還可以根據(jù)網(wǎng)頁(yè)需求，僅獲取部分Web文檔內(nèi)容更新網(wǎng)頁(yè)。

2.5.2 HTTPS

HTTPS又是一個(gè)很復(fù)雜的問(wèn)題，這里不再展開(kāi)，只列出幾個(gè)考點(diǎn)。

HTTPS
HTTPS （安全的HTTP）是 HTTP 協(xié)議的加密版本。它通常使用 SSL 或者 TLS 來(lái)加密客戶端和服務(wù)器之間所有的通信 。這安全的鏈接允許客戶端與服務(wù)器安全地交換敏感的數(shù)據(jù)，例如網(wǎng)上銀行或者在線商城等涉及金錢的操作。

  • http與https的區(qū)別
  • https工作流程
  • https的優(yōu)缺點(diǎn)

2.5.3 HTTP Headers

HTTP Headers
根據(jù)不同上下文，可將消息頭(Headers)分為：

  • General headers: 同時(shí)適用于請(qǐng)求和響應(yīng)消息，但與最終消息主體中傳輸?shù)臄?shù)據(jù)無(wú)關(guān)的消息頭。
  • Request headers: 包含更多有關(guān)要獲取的資源或客戶端本身信息的消息頭。
  • Response headers: 包含有關(guān)響應(yīng)的補(bǔ)充信息，如其位置或服務(wù)器本身（名稱和版本等）的消息頭。
  • Entity headers: 包含有關(guān)實(shí)體主體的更多信息，比如主體長(zhǎng)(Content-Length)度或其MIME類型。

2.5.4 HTTP 請(qǐng)求方法

HTTP 請(qǐng)求方法
HTTP 定義了一組請(qǐng)求方法, 以表明要對(duì)給定資源執(zhí)行的操作。指示針對(duì)給定資源要執(zhí)行的期望動(dòng)作. 雖然他們也可以是名詞, 但這些請(qǐng)求方法有時(shí)被稱為HTTP動(dòng)詞. 每一個(gè)請(qǐng)求方法都實(shí)現(xiàn)了不同的語(yǔ)義, 但一些共同的特征由一組共享：: 例如一個(gè)請(qǐng)求方法可以是 safe, idempotent, 或 cacheable.

  • GET方法請(qǐng)求一個(gè)指定資源的表示形式. 使用GET的請(qǐng)求應(yīng)該只被用于獲取數(shù)據(jù).
  • HEAD方法請(qǐng)求一個(gè)與GET請(qǐng)求的響應(yīng)相同的響應(yīng)，但沒(méi)有響應(yīng)體.
  • POST方法用于將實(shí)體提交到指定的資源，通常導(dǎo)致在服務(wù)器上的狀態(tài)變化或副作用.
  • PUT方法用請(qǐng)求有效載荷替換目標(biāo)資源的所有當(dāng)前表示。
  • DELETE方法刪除指定的資源。
  • CONNECT方法建立一個(gè)到由目標(biāo)資源標(biāo)識(shí)的服務(wù)器的隧道。
  • OPTIONS方法用于描述目標(biāo)資源的通信選項(xiàng)。
  • TRACE方法沿著到目標(biāo)資源的路徑執(zhí)行一個(gè)消息環(huán)回測(cè)試。
  • PATCH方法用于對(duì)資源應(yīng)用部分修改。

2.5.5 HTTP訪問(wèn)控制（CORS）

HTTP訪問(wèn)控制（CORS）
跨域資源共享(CORS) 是一種機(jī)制，它使用額外的 HTTP 頭來(lái)告訴瀏覽器 讓運(yùn)行在一個(gè) origin (domain) 上的Web應(yīng)用被準(zhǔn)許訪問(wèn)來(lái)自不同源服務(wù)器上的指定的資源。當(dāng)一個(gè)資源從與該資源本身所在的服務(wù)器不同的域、協(xié)議或端口請(qǐng)求一個(gè)資源時(shí)，資源會(huì)發(fā)起一個(gè)跨域 HTTP 請(qǐng)求。
比如，站點(diǎn) http://domain-a.com 的某 HTML 頁(yè)面通過(guò) <img> 的 src 請(qǐng)求 http://domain-b.com/image.jpg。網(wǎng)絡(luò)上的許多頁(yè)面都會(huì)加載來(lái)自不同域的CSS樣式表，圖像和腳本等資源。

2.6 瀏覽器接收HTTP響應(yīng)并解析

目標(biāo)服務(wù)器接收并解析了HTTP請(qǐng)求后，將相應(yīng)的HTTP響應(yīng)返回給了瀏覽器。此時(shí)，瀏覽器會(huì)對(duì)HTTP響應(yīng)進(jìn)行解析。
在HTTP響應(yīng)中，包含著指示特定 HTTP 請(qǐng)求是否已成功完成的HTTP 響應(yīng)狀態(tài)碼，瀏覽器會(huì)針對(duì)不同的狀態(tài)碼進(jìn)行不同的操作。結(jié)合HTTP響應(yīng)頭，瀏覽器還會(huì)對(duì)獲取到的資源進(jìn)行解析和操作（例如解壓縮，緩存等）。

2.6.1 HTTP 響應(yīng)代碼

HTTP 響應(yīng)代碼
HTTP 響應(yīng)狀態(tài)代碼指示特定 HTTP 請(qǐng)求是否已成功完成。響應(yīng)分為五類：信息響應(yīng)(100–199)，成功響應(yīng)(200–299)，重定向(300–399)，客戶端錯(cuò)誤(400–499)和服務(wù)器錯(cuò)誤 (500–599)。狀態(tài)代碼由 section 10 of RFC 2616定義

2.6.2 HTTP 緩存

HTTP 緩存
重用已獲取的資源能夠有效的提升網(wǎng)站與應(yīng)用的性能。Web 緩存能夠減少延遲與網(wǎng)絡(luò)阻塞，進(jìn)而減少顯示某個(gè)資源所用的時(shí)間。借助 HTTP 緩存，Web 站點(diǎn)變得更具有響應(yīng)性。

2.6.3 HTTP cookies

HTTP cookies
HTTP Cookie（也叫Web Cookie或?yàn)g覽器Cookie）是服務(wù)器發(fā)送到用戶瀏覽器并保存在本地的一小塊數(shù)據(jù)，它會(huì)在瀏覽器下次向同一服務(wù)器再發(fā)起請(qǐng)求時(shí)被攜帶并發(fā)送到服務(wù)器上。通常，它用于告知服務(wù)端兩個(gè)請(qǐng)求是否來(lái)自同一瀏覽器，如保持用戶的登錄狀態(tài)。Cookie使基于無(wú)狀態(tài)的HTTP協(xié)議記錄穩(wěn)定的狀態(tài)信息成為了可能。
Cookie主要用于以下三個(gè)方面：

  • 會(huì)話狀態(tài)管理（如用戶登錄狀態(tài)、購(gòu)物車、游戲分?jǐn)?shù)或其它需要記錄的信息）
  • 個(gè)性化設(shè)置（如用戶自定義設(shè)置、主題等）
  • 瀏覽器行為跟蹤（如跟蹤分析用戶行為等）
    Cookie曾一度用于客戶端數(shù)據(jù)的存儲(chǔ)，因當(dāng)時(shí)并沒(méi)有其它合適的存儲(chǔ)辦法而作為唯一的存儲(chǔ)手段，但現(xiàn)在隨著現(xiàn)代瀏覽器開(kāi)始支持各種各樣的存儲(chǔ)方式，Cookie漸漸被淘汰。由于服務(wù)器指定Cookie后，瀏覽器的每次請(qǐng)求都會(huì)攜帶Cookie數(shù)據(jù)，會(huì)帶來(lái)額外的性能開(kāi)銷（尤其是在移動(dòng)環(huán)境下）。新的瀏覽器API已經(jīng)允許開(kāi)發(fā)者直接將數(shù)據(jù)存儲(chǔ)到本地，如使用 Web storage API （本地存儲(chǔ)和會(huì)話存儲(chǔ)）或 IndexedDB 。

2.6.4 Web Storage API

Web Storage API
Web Storage API 提供機(jī)制， 使瀏覽器能以一種比使用Cookie更直觀的方式存儲(chǔ)鍵/值對(duì)。
Web Storage 包含如下兩種機(jī)制：

  • sessionStorage 為每一個(gè)給定的源（given origin）維持一個(gè)獨(dú)立的存儲(chǔ)區(qū)域，該存儲(chǔ)區(qū)域在頁(yè)面會(huì)話期間可用（即只要瀏覽器處于打開(kāi)狀態(tài)，包括頁(yè)面重新加載和恢復(fù)）。
  • localStorage 同樣的功能，但是在瀏覽器關(guān)閉，然后重新打開(kāi)后數(shù)據(jù)仍然存在。

這兩種機(jī)制是通過(guò) Window.sessionStorage 和 Window.localStorage 屬性使用（更確切的說(shuō)，在支持的瀏覽器中 Window 對(duì)象實(shí)現(xiàn)了 WindowLocalStorage和 WindowSessionStorage 對(duì)象并掛在其 localStorage 和 sessionStorage 屬性下）—— 調(diào)用其中任一對(duì)象會(huì)創(chuàng)建 Storage 對(duì)象，通過(guò) Storage 對(duì)象，可以設(shè)置、獲取和移除數(shù)據(jù)項(xiàng)。對(duì)于每個(gè)源（origin）sessionStorage 和 localStorage 使用不同的 Storage 對(duì)象——獨(dú)立運(yùn)行和控制。

此處補(bǔ)充一個(gè)點(diǎn)：

  1. cookie，localStorage和sessionStorage比較
    1. 相同點(diǎn)：都將數(shù)據(jù)保存在瀏覽器端，且是同源的
    2. 區(qū)別
      1. 是否與服務(wù)器端交互：
        1. cookie數(shù)據(jù)始終在同源的http請(qǐng)求中攜帶（即使不需要），即cookie在瀏覽器和服務(wù)器之間相互傳遞。
        2. sessionStorage和localStorage不會(huì)自動(dòng)把數(shù)據(jù)傳給服務(wù)器，只在本地保存
      2. 存儲(chǔ)大小限制：
        1. cookie存儲(chǔ)的數(shù)據(jù)不能超過(guò)4k（各個(gè)瀏覽器不同，4095-4097之間），由于http請(qǐng)求每次都會(huì)攜帶cookie，會(huì)占用帶寬，因此cookie適合存儲(chǔ)較小的數(shù)據(jù)，比如會(huì)話標(biāo)識(shí)。
        2. sessionStorage和localStorage大小一般為5M
      3. 數(shù)據(jù)有效期不同：
        1. cookie數(shù)據(jù)的生命期一般有服務(wù)器生成，可設(shè)置失效時(shí)間。如果不設(shè)置失效時(shí)間，則關(guān)閉瀏覽器時(shí)cookie失效
        2. sessionStorage為每一個(gè)給定的源（given origin）維持一個(gè)獨(dú)立的存儲(chǔ)區(qū)域，該存儲(chǔ)區(qū)域在頁(yè)面會(huì)話期間（page session）有效（即只要瀏覽器打開(kāi)狀態(tài)，包括頁(yè)面重新加載或恢復(fù)），頁(yè)面刷新不會(huì)清除數(shù)據(jù)，瀏覽器或是頁(yè)面關(guān)閉才會(huì)清除數(shù)據(jù)
        3. localStorage無(wú)過(guò)期設(shè)置，保存數(shù)據(jù)后始終有效，瀏覽器或頁(yè)面關(guān)閉也一直保存，可作為持久數(shù)據(jù)
      4. 作用域不同：
        1. cookie在所有同源窗口中都是共享的
        2. localStorage在所有同源窗口中也是共享的
        3. sessionStorage在不同的瀏覽器窗口中是不共享的，即使是同源頁(yè)面
      5. 其他：
        1. cookie數(shù)據(jù)有路徑（path）的概念，可以限制cookie只屬于某個(gè)路徑
        2. web storage（sessionStorage和localStorage）支持事件通知機(jī)制，可以將數(shù)據(jù)更新的通知發(fā)送給監(jiān)聽(tīng)者
        3. web storage的API更方便
    3. 應(yīng)用場(chǎng)景
      1. cookie常用的場(chǎng)景是判斷用戶是否登錄
      2. localStorage 可以用來(lái)記錄用戶的瀏覽歷史
      3. sessionStorage可以用來(lái)統(tǒng)計(jì)頁(yè)面上元素的點(diǎn)擊次數(shù)
    4. 安全性
      1. 敏感數(shù)據(jù)不適宜放在瀏覽器存儲(chǔ)中，可以被隨意修改
      2. cookie的安全性比較復(fù)雜，需要單獨(dú)討論

2.6.5 數(shù)據(jù)壓縮

HTTP協(xié)議中的數(shù)據(jù)壓縮
數(shù)據(jù)壓縮是提高 Web 站點(diǎn)性能的一種重要手段。對(duì)于有些文件來(lái)說(shuō)，高達(dá)70%的壓縮比率可以大大減低對(duì)于帶寬的需求。隨著時(shí)間的推移，壓縮算法的效率也越來(lái)越高，同時(shí)也有新的壓縮算法被發(fā)明出來(lái)，應(yīng)用在客戶端與服務(wù)器端。

2.6.6 內(nèi)容協(xié)商

內(nèi)容協(xié)商
在 HTTP 協(xié)議中，內(nèi)容協(xié)商是這樣一種機(jī)制，通過(guò)為同一 URI 指向的資源提供不同的展現(xiàn)形式，可以使用戶代理選擇與用戶需求相適應(yīng)的最佳匹配（例如，文檔使用的自然語(yǔ)言，圖片的格式，或者內(nèi)容編碼形式）。
一份特定的文件稱為一項(xiàng)資源。當(dāng)客戶端獲取資源的時(shí)候，會(huì)使用其對(duì)應(yīng)的 URL 發(fā)送請(qǐng)求。服務(wù)器通過(guò)這個(gè) URL 來(lái)選擇它指向的資源的某一變體——每一個(gè)變體稱為一種展現(xiàn)形式——然后將這個(gè)選定的展現(xiàn)形式返回給客戶端。整個(gè)資源，連同它的各種展現(xiàn)形式，共享一個(gè)特定的 URL 。當(dāng)一項(xiàng)資源被訪問(wèn)的時(shí)候，特定展現(xiàn)形式的選取是通過(guò)內(nèi)容協(xié)商機(jī)制來(lái)決定的，并且客戶端和服務(wù)器端之間存在多種協(xié)商方式。

在這里插入圖片描述

2.7 瀏覽器渲染流程

如何瀏覽器解析得到的響應(yīng)內(nèi)容是HTML文檔，瀏覽器將其解析渲染呈現(xiàn)給用戶。仍然用一篇優(yōu)秀的blog來(lái)回答這個(gè)非常重要的考點(diǎn)：

講的很清楚也很全面，不看你真的會(huì)后悔的。

后記

終于整理完了，太累了。。。

我盡可能完整地整理了“從輸入U(xiǎn)RL到頁(yè)面加載完成，都發(fā)生了什么”這個(gè)問(wèn)題的三層金字塔知識(shí)結(jié)構(gòu)，也引用了很多優(yōu)秀且理解深刻的博文，但終歸而言，這些東西都是別人的東西。如果你不能用自己的話正確且完整地表述這些問(wèn)題，你仍然無(wú)法真正理解這些知識(shí)。面對(duì)久經(jīng)沙場(chǎng)的老司機(jī)面試官，一知半解的知識(shí)只會(huì)得到無(wú)情的毒打，當(dāng)然如果你是抖M，就當(dāng)我沒(méi)有說(shuō)過(guò)這句話。

謝謝各位看官的閱讀~

?著作權(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)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

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

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