1.OSI七層模型指什么？

• OSI七層模型結構：
  OSI七層模型是通過七個層次化的結構模型使不同的系統(tǒng)不同的網絡之間實現(xiàn)可靠的通訊，因此其最主要的功能就是幫助不同類型的主機實現(xiàn)數據傳輸。完成中繼功能的節(jié)點通常稱為中繼系統(tǒng)。在OSI七層模型中，處于不同的中繼系統(tǒng)具有不同的名稱：物理層，數據鏈路層，網絡層，傳輸層，會話層，表示層，引用層。
  各層的作用：

  • 1.物理層：利用傳輸介質為數據鏈路層提供物理連接，實現(xiàn)比特流的透明傳輸。在這一層，數據的單位稱為比特（bit）。
  • 2.數據鏈路層：通過各種協(xié)議控制，將喲差錯的物理信道變?yōu)闊o差錯的、能可靠傳輸數據幀的數據鏈路。在這一層，數據的單位稱為幀（frame）。
  • 3.網絡層：通過路由選擇算法，為報文或分組通過通信子網選擇最適當的路徑。在這一層，數據的單位稱為數據包（packet）。
  • 4.傳輸層：向用戶提供可靠的端到端的差錯和流量控制，保證報文的正確傳輸。在這一層，數據的單位稱為數據段（segment）。
  • 5.會話層：組織和協(xié)調兩個會話進程之間的通信，并對數據交換進行管理。
  • 6.表示層：處理用戶信息的表示問題，如編碼、數據格式轉換和加密解密等。
  • 7.應用層：直接向用戶提供服務，完成用戶希望在網絡上完成的各種工作。

• TCP/IP協(xié)議
  實際上，OSI是一種理想化的協(xié)議模型，過于復雜?，F(xiàn)實中使用是更為精簡的TCP/IP協(xié)議的四層模型，TCP/IP協(xié)議與OSI協(xié)議的對應關系如下：

模型對比

• 鏈路層：用來處理鏈接網絡的硬件部分
• 網絡層：用來處理在網絡上流動的數據包
• 傳輸層：提供處于網絡鏈接中的兩臺計算機之間的數據傳輸，TCP協(xié)議（傳輸控制協(xié)議）和UDP協(xié)議（用戶數據協(xié)議）就在此層。
• 應用層：向用戶提供應用服務時通信的活動。FTP,DNS和HTTP協(xié)議就在此層。

2.HTTP的工作原理是什么？

在說明HTTP的工作原理之前，要先介紹在TCP/IP協(xié)議族中與HTTP協(xié)議密不可分的3個協(xié)議。

• 負責傳輸的IP協(xié)議
  按層次分，IP協(xié)議位于網絡層。它的作用就是把各種數據包傳送給對方。而為了準確無誤的把數據包傳遞給對方，需要知道2個非常重要的信息，IP地址和MAC地址。IP地址指明了節(jié)點被分配到的地址，是可以發(fā)生變化的。MAC地址是指的的網卡所屬的固定地址，基本上是不會改變的。我們可以用快遞的方式來理解IP協(xié)議：假如我要從武漢寄一份快遞到北京，首先填寫一個北京的具體送貨地址（IP地址），然后去離我家最近的一個快遞站點發(fā)貨（MAC地址，中轉站），這個小型站點是沒有能力直接把貨送到北京的，所以它會分析地址，送到武漢的某個大型站點（MAC地址,中轉站），武漢的大型站點再分析地址，送到北京的某個大型站點（MAC地址，中轉站），北京的大型站點再分析地址，送到地址對應的某個小型站點（MAC地址，中轉站），最后快遞員送貨到達最終的地址（MAC地址，IP地址）?；氐骄W絡通信中，除非是同一個局域網內，大部分的IP通信都是像快遞中轉一般，利用多臺計算機和網絡設備才能連接到對方。在進行中轉時，會利用ARP協(xié)議（一種解析地址的協(xié)議，已知對方的IP地址，反查出對方的MAC地址。），得到下一個中轉站的MAC地址來搜索下一個中轉目標，最終搜索到目標地址。

• 確?？煽康腡CP協(xié)議：
  按層次分，TCP位于傳輸層。TCP協(xié)議為了更容易的傳輸大數據，將大數據分割成以報文段（segment）為單位的數據包，并且通過三次握手的策略來確認數據送達目標處。
  三次握手：發(fā)送端首先發(fā)送一個帶SYN標志的數據包給對方。接收端收到后，回傳一個帶有SYN/ACK標志的數據以示傳達確認信息。最后，發(fā)送端再回傳一個帶ACK標志的數據包，代表握手結束。如果在握手過程中某個階段莫名中斷，TCP協(xié)議會再次以相同的順序發(fā)送相同的數據包。

• 負責域名解析的DNS服務
  DNS服務是和HTTP協(xié)議一樣位于應用層。它的作用是提供域名到IP地址之間的解析服務。一般我們都是直接輸入域名來訪問某個網頁，因為這樣更符合我們的記憶習慣，但是計算機更擅長處理一長串數字，所以需要DNS這樣的服務，能通過域名來查找IP地址，或逆向從IP地址反查域名。

結合以上三種協(xié)議，具體的HTTP協(xié)議的通信過程可以用下圖表示：
[圖片上傳中。。。（2）]http.jpg

3.URI的格式是什么？常見的協(xié)議有哪些？

URI是Uniform Resource Identifier的縮寫，它指的是某個協(xié)議方案表示的資源定位標識符。
協(xié)議方案指的是訪問資源所使用的協(xié)議類型名稱。常用的協(xié)議有http，https、file，mailto，telnet等。

URI有兩個子集，分別是URL(uniform resource location)統(tǒng)一資源定位符和URN（uniform resource name）統(tǒng)一資源命名。我們更常用的是URL，關于URI和URL的關系可以這么理解：URI描述了一個資源在網上的一切信息，包含這個資源的名字，這個資源在哪里等等。而URL描述了在網上如何找到這個資源，也就是這個資源在哪里。所以從邏輯上來講URL是URI的子集，在充分理解的基礎上，URL是可以替換URI的。
URI格式如下：

URI

• 協(xié)議方案名：常見的http，https，ftp等，不區(qū)分大小寫，最后記得要加上冒號：
• 登陸信息：指定用戶名和密碼作為從服務器獲取資源是必要的登陸信息。此項是可選項，由于太不安全，現(xiàn)在不常見了。
• 服務器地址：使用URI必須指定帶訪問的服務器地址，可以是NDS可解析的名稱或者是直接的IP地址名。
• 服務器端口：指定服務器連接的網絡端口號。此項也是可選項，若不寫則使用默認端口號。
• 帶層次的文件路徑：指定服務器上的文件路徑來定位特制的資源。
• 查詢字符串：針對已指定的文件路徑的資源，可以使用查詢字符串參入任意參數。此項可選。
• 片段標識符：使用片段標識符通?？蓸擞浺垣@取資源中的子資源（文檔內的某個位置）。該項也是可選項，在很多MVVM框架用做了路由功能。

4.HTTP協(xié)議有幾種和服務器交互的方法

• GET:用來請求訪問已被URI識別的資源。指定的資源經過服務器端解析后返回相應內容。
• POST：用來傳輸實體的主體。雖然POST的功能和GET很相似，但是POST的主要目的是向服務器傳輸大量數據。
• PUT：用來傳輸主體，在請求報文的主體中包含文件內容，然后保存到請求URI指定的位置。但是PUT自身不帶驗證機制，存在安全性問題，一般不會使用。
• HEAD：用來獲得報文首部，與GET方法一樣，但是不會返回報文主題，用來確認URI的有效性及資源更新的日期時間等。
• DELETE:用來刪除文件，是PUT相仿的方法，同樣由于安全性問題，一般不會使用。
• OPTIONS：用來查詢針對請求URI指定的資源支持方法。
• TRACE:用來讓Web服務器端將之前的請求通信環(huán)回給客戶端。
• CONNECT:該方法要求在與代理服務器通信時建立隧道，實現(xiàn)用隧道協(xié)議進行TCP通信。

5.狀態(tài)碼200，301， 304，403，404，500，503分別代表什么意思

服務器的響應類別有下面5種：

狀態(tài)碼類別

• 200：表示從客戶端發(fā)來的請求在服務器端被正常處理了。
• 301：永久性重定向，表示請求的資源已被分配了新的URI，新的URI出現(xiàn)在Location首部字段中，瀏覽器會自動訪問新的URI。
• 304：表示客戶端發(fā)送附帶條件（比如if-Modified-Since）的請求時，雖然未滿足條件，但是服務器端還是允許請求訪問資源。在瀏覽緩存文件時，會看到304的身影，說明這個緩存資源未發(fā)生變更，能繼續(xù)使用。
• 403：表示對請求資源的訪問被服務器拒絕了。
• 404：表示服務器上無法找到請求的資源，也可以在服務器端拒絕請求且不想說明理由時使用。
• 500：表示服務器端在執(zhí)行請求時發(fā)生了錯誤，也有可能是Web應用存在的bug或某些臨時的故障。
• S503：表示服務器暫時處于超負荷或正在進行停機維護，現(xiàn)在無法吃力請求。

6.報文有那幾部分組成？
總體上HTTP報文是由報文首部+空行（回車）+報文實體組成。由于HTTP協(xié)議服務于請求端和響應端，所以HTTP報文也分為兩種，請求端（客戶端）的HTTP報文叫做請求報文，響應端（服務器端）的叫做響應報文，二者的具體內容可見下圖：

請求報文

HTTP響應報文

7.請求頭的格式和作用是什么？給個范例截圖說明

Request Header

• GET / HTTP/1.1 ：請求方法是GET，HTTP協(xié)議版本1.1

• Host：URI信息。

• Connection：管理持久鏈接，keep-alive
  表示持久鏈接,HTTP/1.1版本默認持久鏈接，如果想要斷開，指定值為close即可。

• Cache-Control：控制緩存的行為，max-age=0
  意味著緩存服務器需要將請求轉發(fā)給源服務器。

• Upgrade-Insecure-Requests：讓瀏覽器升級自動http協(xié)議到https協(xié)議。
  這里解釋一下，如果一個用https協(xié)議承載的頁面加載一些用http協(xié)議定義的資源，是會報錯的，所以往往在服務器端的響應頭中，會加入header("Content-Security-Policy: upgrade-insecure-requests")這么一句話，讓瀏覽器自動將http協(xié)議升級成https協(xié)議，而在請求頭中的Upgrade-Insecure-Requests:1
  表明該瀏覽器支持該操作。

• User-Agent：告知服務器，客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本。

• Accept：告知服務器，瀏覽器能處理的媒體類型及媒體類型的相對優(yōu)先級。

• Accept-Encoding：告知服務器，瀏覽器支持的內容編碼饑內容編碼的優(yōu)先級順序?？芍付ǘ喾N。

• Accept-Language：告知服務器，瀏覽器支持的語言及語言的相對優(yōu)先級。

• Cookie：儲存一些臨時的數據在用戶的計算機中，雖然沒有編入標準化的HTTP/1.1協(xié)議中，但是在Web網站會廣泛使用。

8.首部的格式和作用是什么？給個范例截圖說明

首部

• Request URL：請求服務器的URL地址。
• Request Mothod：請求的方法。
• Status Code：狀態(tài)碼
• Remote Address：服務器的IP地址和端口號。

9.主體的作用是什么？給個范例截圖說明

主體就是HTTP報文實質要傳輸的數據，并不是所有的報文都有主體，例如get方法的請求報文就沒有主體。主體可以承載很多類型的數據，我們最熟悉的html文檔，圖片、視頻、應用程序、電子郵件等。當我打開B站的首頁，由于是get方法，并沒有請求報文主體，但是響應報文就會返回響應主體，就是B站首頁的HTML文檔，如下圖：

響應主體

當我進入B站的登陸頁面時，輸入我的賬號密碼點擊登陸后，可以看到POST方法請求的請求報文就有請求主體，如下圖：

請求主題

此時我的用戶名和密碼就上傳到了服務器。

10.簡述瀏覽器緩存是如何控制的

瀏覽器緩存分為強緩存和協(xié)商緩存，協(xié)商緩存是配合強緩存來使用的。當瀏覽器第一次請求資源時，根據開發(fā)者的要求或者協(xié)議的默認，服務器端會在響應頭中添加一些跟緩存有關的字段，最終這個資源和響應頭會綁定在一起緩存到瀏覽器中。當瀏覽器再次請求這個資源時，首先判斷它是否命中了強緩存，判斷依據來自于之前響應頭中的Expires或Cache-Control字段：

• 1.Expires：來自于HTTP/1.0，描述一個絕對時間，由服務器返回，用GTM格式的字符串表示，當瀏覽器再次請求資源時，先從緩存中找到這個資源和跟它綁定在一起的響應頭，拿出響應頭中的Expires跟當前請求時間對比，如果請求時間在Expires指定的時間之內，就能命中強緩存，直接在瀏覽器的緩存中讀取該資源，無需再向服務器請求資源了。但是Expires描述是一個服務器的絕對時間，而客戶端的時間與服務器時間存在時間差，而且客戶端時間可以人為修改，這些都會影響判斷結果，因此HTTP/1.1推出Cache-Control字段來更好的控制緩存。
• 2.Cache-Control：提供了更多的緩存設置，有一個描述相對時間max-age，單位是s，如果再次請求的時間間隔小于max-age，表示命中強緩存。Cache-Control和Expires可以同時存在，但是Cache-Control的優(yōu)先級更高

如果這個資源沒有命中強緩存，瀏覽器就會發(fā)送一個請求到服務器，驗證協(xié)商緩存是否命中，如果命中，也是能夠在緩存中直接讀取資源了。協(xié)商緩存是依靠Last-Modified,If-Modified-Since
和ETag , If-None-Match
這個兩隊字段來控制。

• 1.Last-Modified,If-Modified-Since：同Expries相似，Last-Modified存在于上一次的響應頭中，描述了這個資源在服務器中最后一次修改的時間，當強緩存未命中時，瀏覽器會發(fā)送請求給服務器，請求頭中就有If-Modified-Since這個字段，這個字段等于上一次響應頭中的Last-Modifie的值，服務器收到請求后，根據傳過來的If-Modified-Since和資源在服務器上的最后修改時間判斷資源是否有更新，若資源更新了，則正常返回資源內容，HTTP200 。若資源沒有更新，則返回HTTP304，瀏覽器就直接讀取緩存中的資源。但是有時候Last-Modified不太可靠，比如時間只能精確到秒級，資源內容變化了但是時間沒有變等，就需要ETag來處理。
• 2.ETag，If-None-Macth：原理與Last-Modified一樣，只不過ETag是根據請求的資源生成的一個唯一標識，這個標識是一個字符串，生成規(guī)則跟服務器使用的程序有關。只要資源發(fā)生了變化，這個字符串就會發(fā)生變化，所以能夠很好的補充Last-Modified的問題。Last-Modified可以與ETag一起使用，服務器會優(yōu)先驗證ETag，一致的情況下，再驗證Last-Modified。

通過一張圖更好的理解緩存：

緩存

11.下圖各個參數是什么意思

Paste_Image.png

• Genaral:基本信息的概要。Request URL:請求資源的URL地址。

  • Request Method：請求的方法，這里為PUT
  • Stutus Code：響應的狀態(tài)碼和短語，200表示一切正常。
  • Remote Address：請求的服務器的IP地址和端口號。

• Response Headers：響應頭Connection：鏈接狀態(tài)，keep-alive為保持鏈接。

  • Content-Length：主體內容的大小，這里為12字節(jié)。
  • Content-Type：主體內容的媒體類型，這里為json。
  • Date：創(chuàng)建報文的日期和時間
  • Server：服務器上使用的應用程序的信息，這里使用的nginx/1.6.2。
  • X-Powered-By ：表示服務器是什么技術開發(fā)的，這里是Express。

• Request Headers：請求頭Accept：瀏覽器能處理的媒體類型，這里為一切。

  • Accept-Encoding：瀏覽器能支持的內容編碼格式，這里為gizp，defalte，sdch。

  • Accept-Language：瀏覽器能支持的語言和優(yōu)先級，默認權重值q為1，這里優(yōu)先考慮zh-CN。

  • Connection：鏈接狀態(tài)，keep-alive為保持鏈接。

  • Content-Length：主體內容的大小，這里為56字節(jié)。

  • Content-Type：主體內容的媒體類型，這里使用form表單的x-www-form-urlencoded格式。
    補充一下：form的enctype屬性為編碼方式，常用有兩種：application/x-www-form-urlencoded和multipart/form-data，默認為application/x-www-form-urlencoded。 當action為get時候，瀏覽器用x-www-form-urlencoded的編碼方式把form數據轉換成一個字串（name1=value1&name2=value2...），然后把這個字串append到url后面，用?分割，加載這個新的url。 當action為post時候，瀏覽器把form數據封裝到http body中，然后發(fā)送到server。 如果沒有type=file的控件，用默認的application/x-www-form-urlencoded就可以了。 但是如果有type=file的話，就要用到multipart/form-data了。瀏覽器會把整個表單以控件為單位分割，并為每個部分加上Content-Disposition(form-data或者file),Content-Type(默認為text/plain),name(控件name)等信息，并加上分割符(boundary)

  • Cookie：緩存的數據。

  • Host：服務器的主句和端口號，這里為note.ruoyu.site。

  • Origin：服務器的源地址。

  • Referer：告知服務器請求的原始資源的URI。

  • User-Agent：客戶端使用的操作系統(tǒng)和瀏覽器的名稱和版本

  • X-Requsted-With：表示使用的是Ajax異步請求。

• Form Data：表單數據article：數據的標題是若愚@饑人谷。