計算機網絡基礎知識 - 應用層

                                              第六章 應用層

1. 對等模式與C/S模式的差別

客戶機/伺服器網模式（C/S模式）：在客戶機/伺服器網絡中，伺服器是網絡的核心，而客戶機是網絡的基礎，客戶機依靠伺服器獲得所需要的網絡資源，而伺服器為客戶機提供網絡必須的資源。

對等連接配接（P2P模式）：指兩個主機在通行時并不區分哪一個是服務請求方還是服務提供方。隻要兩個主機都運作了對等連接配接軟體（P2P軟體），它們就可以進行平等的、對等連接配接通信。

雖然對等網是平等的，但仍然不能共享可執行程式，隻有上升到客戶/伺服器結構的區域網路，才能共享伺服器上的可執行程式。客戶伺服器模式，需要專人維護、管理伺服器，增加費用。它比較适合較大的網絡。像較小的網絡。如10PC以下的，使用對等網就可以了。

 2. HTTP協定的主要特點

• 支援客戶/伺服器模式
• 簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯系的類型不同。由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以标記。
• 無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。
• 無狀态：HTTP協定是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。HTTP協定自身不對請求和響應之間的通信狀态進行儲存。每當有新的請求，就會有對應的新響應産生。協定本身并不保留之前一切的請求或響應資訊，是以在購物網站中一般使用Cookie技術。

 3. HTTP和HTTPS的基本概念

• HTTP：是網際網路上應用最為廣泛的一種網絡協定，是一個用戶端和伺服器端請求和應答的标準，用于從WWW伺服器傳輸超文本到本地浏覽器的傳輸協定，它可以使浏覽器更加高效，使網絡傳輸減少。
• HTTPS：是以安全為目标的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，是以加密的詳細内容就需要SSL。HTTPS協定的主要作用可以分為兩種：一種是建立一個資訊安全通道，來保證資料傳輸的安全；另一種就是确認網站的真實性。

 4. HTTP與HTTPS有什麼差別？

HTTP協定運作在TCP之上，明文傳輸（未加密的），用戶端與伺服器端都無法驗證對方的身份，是以使用HTTP協定傳輸隐私資訊非常不安全。

HTTPS協定是運作于SSL之上，SSL運作于TCP之上，由SSL+HTTP協定建構的可進行加密傳輸、身份認證的網絡協定，要比HTTP協定安全。

HTTPS和HTTP的差別主要如下：

1. HTTPS協定需要申請證書，一般免費證書較少，需要向認證機構購買。
2. HTTP是超文本傳輸協定，資訊是明文傳輸，HTTPS則是具有安全性的SSL加密傳輸協定，HTTPS的加密機制是一種共享密鑰加密和公開密鑰加密并用的混合加密機制。
3. HTTP和HTTPS使用的是完全不同的連接配接方式，用的端口也不一樣，前者是80，後者是443。
4. HTTP的連接配接很簡單，是無狀态的；HTTPS協定是由SSL+HTTP協定建構的可進行加密傳輸、身份認證的網絡協定，比HTTP協定安全。

 5. HTTP1.1和HTTP1.0的差別（什麼是長連接配接和短連接配接）

在HTTP1.0中預設使用短連接配接。也就是說，用戶端和伺服器每進行一次HTTP操作，就建立一次連接配接，任務結束就中斷連接配接。當用戶端浏覽器通路的某個HTML或其他類型的Web頁中包含有其他的Web資源，每遇到這樣一個Web資源，浏覽器就會重建立立一個HTTP會話。

HTTP1.1，預設使用長連接配接，用以保持連接配接特性。在使用長連接配接的情況下，當一個網頁打開完成後，用戶端和伺服器之間用于傳輸HTTP資料的TCP連接配接不會關閉，用戶端再次通路這個伺服器時，會繼續使用這一條已經建立的連接配接。

長連接配接多用于操作頻繁，點對點的通訊，而且連接配接數不能太多情況。而像Web網站的HTTP服務由于有成千上萬甚至上億用戶端的連接配接，一般用短連接配接會更省一些資源。HTTP協定的長連接配接和短連接配接，實質上是TCP協定的長連接配接和短連接配接。

6. HTTPS的工作原理

用戶端在使用HTTPS方式與Web伺服器通信時有以下幾個步驟，如圖所示。

1. 客戶使用HTTPS的URL通路Web伺服器，要求與Web伺服器建立SSL連接配接。
2. Web伺服器收到用戶端請求後，會将網站的證書資訊（證書中包含公鑰）傳送一份給用戶端。
3. 用戶端的浏覽器與Web伺服器開始協商SSL連接配接的安全等級，也就是資訊加密的等級。
4. 用戶端的浏覽器根據雙方同意的安全等級，建立會話密鑰，然後利用網站的公鑰将會話密鑰加密，并傳送給網站。
5. Web伺服器利用自己的私鑰解密出會話密鑰。
6. Web伺服器利用會話密鑰加密與用戶端之間的通信。

 7. HTTPS的優缺點

優點

1. 使用HTTPS協定可認證使用者和伺服器，確定資料發送到正确的客戶機和伺服器。
2. HTTPS協定是由SSL+HTTP協定建構的可進行加密傳輸、身份認證的網絡協定，要比HTTP協定安全，可防止資料在傳輸過程中不被竊取、改變，確定資料的完整性。
3. HTTPS是現行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。

缺點

1. HTTPS協定握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電。
2. HTTPS連接配接緩存不如HTTP高效，會增加資料開銷和功耗，甚至已有的安全措施也會是以而受到影響。
3. SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
4. SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。
5. HTTPS協定的加密範圍也比較有限，在黑客攻擊、拒絕服務攻擊、伺服器劫持等方面幾乎起不到什麼作用。最關鍵的，SSL證書的信用鍊體系并不安全，特别是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

 8. HTTP的狀态碼含義

HTTP請求封包主要由請求行，請求頭部，請求正文3部分組成

HTTP響應封包主要由狀态行，響應頭部，響應正文3部分組成

狀态代碼：由三位數字組成，第一個數字定義了響應的類别，且有五種可能取值。

• 1xx：訓示資訊--表示請求已接收，繼續處理
• 2xx：成功--表示請求已被成功接收、了解、接受
• 3xx：重定向--要完成請求必須進行更進一步的操作
• 4xx：用戶端錯誤--請求有文法錯誤或請求無法實作
• 5xx：伺服器端錯誤--伺服器未能實作合法的請求

常見狀态代碼、狀态描述的說明如下：

• 200 OK：表示從用戶端發送給伺服器的請求被正常處理并傳回
• 204 No Content：表示用戶端發送給用戶端的請求得到了成功處理，但在傳回的響應封包中不含實體的主體部分（沒有資源可以傳回）
• 206 Patial Content：表示用戶端進行了範圍請求，并且伺服器成功執行了這部分的GET請求，響應封包中包含由Content-Range指定範圍的實體内容
• 301 Moved Permanently：永久性重定向，表示請求的資源被配置設定了新的URL，之後應使用更改的URL
• 302 Found：臨時性重定向，表示請求的資源被配置設定了新的URL，希望本次通路使用新的URL
• 303 See Other：表示請求的資源被配置設定了新的URL，應使用GET方法定向擷取請求的資源
• 304 Not Modified：表示用戶端發送附帶條件的請求時，伺服器端允許通路資源，但是請求為滿足條件的情況下傳回改狀态碼
• 307 Temporary Redirect：臨時重定向，與303有着相同的含義，307會遵照浏覽器标準不會從POST變成GET
• 400 Bad Request：用戶端請求有文法錯誤，不能被伺服器所了解
• 401 Unauthorized：請求未經授權，這個狀态代碼必須和WWW-Authenticate報頭域一起使用
• 403 Forbidden：伺服器收到請求，但是拒絕提供服務
• 404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL
• 500 Internal Server Error：伺服器發生不可預期的錯誤
• 503 Server Unavailable：伺服器目前不能處理用戶端的請求，一段時間後可能恢複正常

 9. HTTP協定請求方法

發送的請求資訊包括：請求行，請求頭，空行，可選的消息體

HTTP/1.1協定中共定義了八種方法來表明Request-URI指定的資源的不同操作方式：

OPTIONS：傳回伺服器針對特定資源所支援的HTTP請求方法

HEAD：在不必傳輸整個響應内容的情況下，就可以擷取包含在響應消息頭中的元資訊

GET：向特定的資源送出請求

POST：向指定資源送出資料進行處理請求

PUT：向指定資源位置上傳其最新内容

DELETE：請求伺服器删除Request-URI所辨別的資源

TRACE：回顯伺服器收到的請求，主要用于測試或診斷

CONNECT：HTTP/1.1協定中預留給能夠将連接配接改為管道方式的代理伺服器

方法名稱是區分大小寫的；HTTP伺服器至少應該實作GET和HEAD方法，其他方法都是可選的。

 10. 簡述HTTP中GET和POST的差別？

GET與POST是我們常用的兩種HTTP Method，二者之間的差別主要包括如下五個方面：

1. 從功能上講：GET一般用來從伺服器上擷取資源，POST一般用來更新伺服器上的資源
2. 從REST服務角度上說：GET是幂等的，即讀取同一個資源，總是得到相同的資料，而POST不是幂等的，因為每次請求對資源的改變并不是相同的；進一步地，GET不會改變伺服器上的資源，而POST會對伺服器資源進行改變；
3. 從請求參數形式上看：GET請求的資料會附在URL之後，即将請求資料放置在HTTP封包的請求頭中；而POST請求會把送出的資料放置在是HTTP請求封包的請求體中。
4. 就安全性而言：POST的安全性要比GET的安全性高，因為GET請求送出的資料将明文出現在URL上，而且POST請求參數則被包裝到請求體中，相對更安全。
5. 從請求的大小看：GET請求的長度受限于浏覽器或伺服器對URL長度的限制，允許發送的資料量比較小，而POST請求則是沒有大小限制的。

 11. DHCP協定

定義：動态主機配置協定，是一個應用在區域網路中的網絡協定，它使用UDP協定工作。其最終的目的就是擷取響應的IP位址，其中這過程中有多種配置設定方式，以及發送封包的格式要求等。

作用：動态配置設定IP位址，過程自動化，終端無需一一手工配置，提高配置IP位址效率，減少配置工作量，減少IP位址沖突

配置設定IP位址的方式：

1. 手工配置方式：通過網絡管理者手工配置某台用戶端特定的IP位址，當用戶端請求配置設定時，DHCP伺服器就将手動配置的IP位址配置設定給用戶端。
2. 自動配置方式：當DHCP用戶端第一次向服務端租用到第一個IP位址後，就将這個IP位址永久配置設定給用戶端使用。
3. 動态配置方式：伺服器暫時配置設定一個IP位址給用戶端，根據租約到期或者續約租期的方式來管理配置設定的IP位址。

DHCP封包種類：DHCP-DISCOVERY，DHCP-OFFER，DHCP-REQUEST，DHCP-ACK，DHCP-NAK，DHCP-RELEASE，DHCP-DECLINE，DHCP-INFORM。（8種）

DHCP自動配置設定IP位址的原理：

DHCP動态擷取IP位址的過程主要分為發現階段、提供階段、選擇階段、确認階段四個階段。

1. 發現階段：客戶機發廣播，搜尋DHCP伺服器
2. 提供階段：DHCP伺服器發出邀請，提供一個可用的IP位址
3. 選擇階段：客戶機正式請求使用該IP位址
4. 确認階段：DHCP伺服器确認，并提供其他配置參數

 12. DNS（域名解析系統）協定

DNS工作原理：

在網際網路上，建構了域名和IP位址互相映射的分布式資料庫，在IP位址和域名之間形成一種轉換和查詢機制。是以，DNS工作的過程可以簡單描述為：域名位址經過DNS伺服器解析後，得到對應的IP位址，通過該IP位址通路到伺服器擷取我們要通路的内容。

DNS基于UDP服務，端口53。當然，端口号可以修改，但是預設是使用53端口。

DNS封包格式：

概念解釋

域名：IP位址對應的主機名。

label：域名由多個label組成，label間常用符号＂.＂連接配接。

DNS用戶端：區域網路内的使用者程式向DNS用戶端送出請求，本地裝置收到請求封包後，會向DNS伺服器發送查詢封包。在收到DNS伺服器的應答封包後，本地會對封包進行解析，并決定下一步的操作，進而完成一次域名解析過程。

DNS代理：用來在DNS用戶端和DNS伺服器之間轉發DNS請求和應答封包。

DNS透明代理：可以修改部分DNS請求封包的目的位址，将其修改為其他ISP内的DNS伺服器位址，DNS請求被轉發到不同的ISP，解析後的Web伺服器位址也就屬于不同的ISP，所有上網流量将通過不同的ISP鍊路轉發。這樣就不會造成一個鍊路擁塞、其他鍊路卻閑置的情況，充分利用了所有鍊路資源。

DDNS（動态域名系統）：DNS僅提供了域名和IP位址之間的靜态對應關系，當節點的IP位址發生變化時，DNS無法動态地更新域名和IP位址的對應關系。DDNS通過動态更新DNS伺服器上域名和IP位址之間的對應關系，保證通過域名解析後得到正确的IP位址。

DNS64：将DNS查詢資訊中的A記錄（ipv4位址）合成到AAAA記錄（ipv6位址）中，傳回合成的AAAA記錄給ipv6側使用者。

細粒度訂閱：釋出端提供按需的資料釋出機制，訂閱端隻需要訂閱其關系的資料，一旦訂閱的資料發生變化，釋出者将相關資料實時釋出到相關的訂閱端。

DNS緩存：實際使用中，DNS伺服器會将接收到的DNS應答結果在本地緩存一段時間，直到資料老化才删除。當出現對相同域名的查詢時，便可以通過緩存的結果直接進行回複，隻有在本地緩存中找不到時才向DNS伺服器發起查詢請求。通過DNS緩存，大部分查詢都隻需要本地DNS伺服器即可完成解析，可以提高效率。

 13. DNS解析方式

DNS遞歸解析

遞歸解析是最常見，也是預設的解析方式。在這種解析方式中，如果用戶端配置的本地名稱伺服器不能解析，則後面的查詢全部由本地名稱伺服器代替DNS用戶端進行查詢，直到本地名稱伺服器從權威名稱伺服器得到正确的解析結果，然後由本地名稱伺服器告訴DNS用戶端查詢的結果。

在這個查詢過程中，一直是以本地名稱伺服器為中心的，DNS用戶端隻是發出原始的域名查詢請求封包，然後就一直處于等待狀态的，直到本地名稱伺服器發來了最終的查詢結果。

DNS疊代解析

滿足以下一個條件時就會采用疊代解析方式：

1. 查詢名稱伺服器時用戶端的請求封包中沒有申請使用遞歸解析，也就是說DNS請求封包的RD字段沒有設定1
2. 用戶端在DNS請求封包中沒有申請使用遞歸解析，但是所配置的本地名稱伺服器上是禁用遞歸查詢的

使用遞歸解析方式時，如果它所配置的主名稱伺服器不能解析的話，用戶端還會繼續向所配置的其他名稱伺服器查詢。

 14. DNS解析過程

從域名到IP位址的解析過程

當一個業務需要把域名解析為IP位址時，它就成為了DNS的一個用戶端，調用位址解析程式，把待解析的域名加入到DNS請求封包中，通過UDP先發送給本地DNS伺服器。本地DNS伺服器查找得到對應的IP位址後，通過回應封包将該IP傳回，用戶端獲得該IP位址後可繼續後續操作。如果本地域名伺服器不能回答該請求，則自身會成為一個新的DNS用戶端，向其他DNS伺服器發送請求封包。這個過程一直重複，直至得到回應封包為止。

從IP位址到域名的解析過程

當在浏覽器内輸入URL時，便開始了DNS解析過程，最後會把找到後的IP位址告知浏覽器用戶端，友善它繼續發出HTTP（s）請求。在這個過程中，浏覽器提出的查詢記錄類型叫A記錄查詢，主要是針對ipv4，如果是ipv6的話，就是AAAA。這個A記錄意思是從域名解析得到IP位址。那麼反過來，從IP位址得到域名的解析過程也需要一個記錄，叫PTR記錄。我們可以通過查詢IP位址的PTR記錄來得到該IP位址指向的域名，達到反查的目的。

實際上網時域名的解析過程

1. 當使用者在位址欄輸入一個URL之後，浏覽器首先查詢浏覽器的緩存
2. 找不到就去查詢主機檔案和本地DNS緩存，如果主機和本地DNS緩存都沒有找到域名對應的IP，則自動進入路由器的緩存中檢查
3. 以上均為用戶端DNS緩存，若在用戶端DNS緩存還是沒找到，則進入ISP DNS緩存中查詢
4. 還是找不到，最終才向根DNS伺服器發出DNS查詢封包，再找不到就報錯

 15. DNS劫持與DNS污染

DNS劫持：

通過劫持DNS伺服器，使用某些手段取得某域名的解析記錄控制權，進而修改此域名的解析結果，導緻對該域名的通路由原IP位址轉入到修改後的指定IP，其結果就是對特定的網址不能通路或通路的是假網址，進而實作竊取資料或者破壞原有正常服務的目的。DNS劫持通過篡改DNS伺服器上的資料傳回給使用者一個錯誤的查詢結果來實作的。

DNS劫持症狀：某些地區的使用者在成功連接配接寬帶後，首次打開任何頁面都指向ISP提供的“電信互聯星空”、“網通黃頁廣告”等内容頁面，還有就是曾經出現過使用者通路Google域名的時候出現了百度的網站。這些都屬于DNS劫持。

DNS污染：

是一種讓一般使用者由于得到虛假目标主機IP而不能與其通信的方法，是一種DNS緩存投毒攻擊。其工作方式是：由于通常的DNS查詢沒有任何認證機制，而且DNS查詢通常基于的UDP是無連接配接不可靠的協定，是以DNS的查詢非常容易被篡改，通過對UDP端口53上的DNS查詢進行入侵檢測，一經發現與關鍵詞相比對的請求則立即僞裝成目标域名的解析伺服器給查詢者傳回虛假結果。

DNS污染症狀：目前一些被禁止通路的網站基本都是通過DNS污染來實作的，例如YouTube、Facebook等網站。

解決辦法：

對于DNS劫持，可以通過手動更換DNS伺服器為公共DNS解決。

對于DNS污染，可以說，個人使用者很難單單靠設定解決，通常可以使用VPN或者域名遠端解析的方法解決，但這大多需要購買付費的VPN或SSH等，也可以通過修改Hosts的方法，手動設定域名正确的IP位址。

 16. 電子郵件協定

常用的電子郵件協定有SMTP、POP3、IMAP4，它們都隸屬于TCP/IP協定簇，處于應用層的下層。

SMTP協定

SMTP協定幫助每台計算機在發送或中轉信件時找到下一個目的地；SMTP是一種推協定，即服務端向用戶端發送推送請求，用戶端接受，服務端發送郵件；SMTP用于将發送方的郵件伺服器發送封包到接收方郵件伺服器

SMTP服務工作在兩種情況下：一是從發送方把電子郵件傳輸到發送方郵件伺服器上；二是從發送方郵件伺服器傳輸到接收方郵件伺服器上

POP3協定

POP3協定僅用于使用者從自己的郵件伺服器上接收郵件；POP3可以下載下傳郵件、從伺服器中删除郵件或詢問是否有新郵件

POP3按照3個階段進行工作：特許、事務處理以及更新

1. 特許階段，使用者代理發送使用者名和密碼
2. 事務處理階段：使用者代理取回封包；還可以對封包做删除标記，取消封包删除标記，以及擷取郵件的統計資訊
3. 更新階段：結束該POP3會話；這個時候該郵件伺服器删除那些被标記的删除的封包

IMAP協定

一種功能更強大但是也更加複雜的郵件接收協定。網際網路資訊通路協定（IMAP）是一種優于POP的新協定,它可以決定客戶機請求郵件伺服器送出所收到郵件的方式，請求郵件伺服器隻下載下傳所選中的郵件而不是全部郵件

IMAP是雙向的，在本地的操作也會回報到伺服器

17. POP3和IMAP的差別

POP3協定允許電子郵件用戶端下載下傳伺服器上的郵件，但是在用戶端的操作不會回報到伺服器上，如移動郵件、标記已讀等。比如通過用戶端收取了郵箱中的3封郵件并移動到其他檔案夾，郵箱伺服器上的這些郵件是沒有同時被移動的。

而IMAP提供webmail與電子郵件用戶端之間的雙向通信，用戶端的操作都會回報到伺服器上，對郵件進行的操作，伺服器上的郵件也會做相應的動作。

同時，IMAP像POP3那樣提供了友善的郵件下載下傳服務，讓使用者能進行離線閱讀。IMAP提供的摘要浏覽功能可以讓你在閱讀完所有的郵件到達時間、主題、發件人、大小等資訊後才作出是否下載下傳的決定。此外，IMAP更好地支援了從多個不同裝置中随時通路新郵件。 

總之，IMAP整體上為使用者帶來更為便捷和可靠的體驗。POP3更易丢失郵件或多次下載下傳相同的郵件，而IMAP通過郵件用戶端與webmail之間的雙向同步功能很好地避免了這些問題。

 18. FTP協定

功能：FTP服務的主要功能是向使用者提供本地與遠端主機之間的檔案傳輸，通過搭建FTP伺服器實作檔案資源共享

優缺點：FTP服務的優點是可以傳輸任意類型的檔案，而不需要做任何處理；缺點是因為通過FTP協定傳輸檔案是要先建立兩種連接配接，是以有較大的延遲

兩種模式：FTP具有兩種模式，分别是主動模式和被動模式

在主動模式下：用戶端給伺服器端的21端口發指令說，我要下載下傳什麼什麼，并且還會說我已經打開了自己的20端口，你就從這裡把東西給我吧，伺服器收到後就會連接配接用戶端已打開的20端口把東西傳給用戶端，這就是主動模式，可以了解為服務端主動給用戶端傳輸檔案。

在被動模式下：用戶端給伺服器端的21端口發指令說，我要下載下傳什麼什麼，伺服器端知道後，就打開一個空閑的端口，然後告訴用戶端，我已經打開了某某端口，你自己進去拿吧，于是用戶端就從那個端口進去拿檔案了，這就是被動模式，可以了解為服務端被用戶端拿走了東西。

 19. SNMP協定

功能：利用SNMP，一個管理工作站可以遠端管理所有支援這種協定的網絡裝置，包括監視網絡狀态、修改網絡裝置配置、接收網絡事件警告等。

工作原理：SNMP采用特殊的C/S模式，即代理/管理站模型。對網絡的管理與維護是通過管理工作站與SNMP代理間的互動工作完成的。每個SNMP從代理負責回答SNMP管理工作站（主代理）關于MIB定義資訊的各種查詢。

管理程序和代理程序之間的通信有兩種方式，一種是管理程序向代理程序送出請求，詢問參數值，另一種方式是代理程序主動向管理程序報告某些重要的事件。

為什麼需要SNMP？

作為運維人員，我們很大一部分的工作就是為了保證我們的網絡能夠正常、穩定的運作。是以監控，控制，管理各種網絡裝置成了我們日常的工作。在網絡興起的早期，維護方式就是運維人員蹲在近端對裝置進行各種操作，當網絡裝置越來越多，網絡規模越來越大時，管理工作會變得越來越單調乏味，這樣的近端維護方式也近乎不可能。是以，遠端管理網絡的需求日益迫切，SNMP應運而生。使用SNMP，一個運作網管軟體的工作站就能對成千上萬的網絡裝置進行監控和資訊采集，這些資訊可以用來建構網絡或者定位網絡中的問題。

 20. 在浏覽器中輸入一個URL至頁面呈現，網絡上都發生了什麼事？

解析URL

URL：統一資源定位符。俗稱網頁位址或者網址。URL用來表示某個資源的位址。

當在浏覽器中輸入URL後，浏覽器首先對拿到的URL進行識别，抽取出域名字段。

DNS解析

DNS解析，DNS實際上是一個域名和IP對應的資料庫。

IP位址往都難以記住，但機器間互相隻認IP位址，于是人們發明了域名，讓域名與IP位址之間一一對應，它們之間的轉換工作稱為域名解析，域名解析需要由專門的域名解析伺服器來完成，整個過程是自動進行的。

可以在浏覽器中輸入IP位址浏覽網站，也可以輸入域名查詢網站，雖然得出的内容是一樣的但是調用的過程不一樣，輸入IP位址是直接從主機上調用内容，輸入域名是通過域名解析伺服器指向對應的主機的IP位址，再從主機調用網站的内容。

通過以上的查找，就可以擷取到域名對應的IP了。接下來就是向該IP位址定位的HTTP伺服器發起TCP連接配接。

浏覽器與網站建立TCP連接配接（三次握手）

第一次握手：用戶端向伺服器端發送請求（SYN=1）等待伺服器确認；

第二次握手：伺服器收到請求并确認，回複一個指令（SYN=1，ACK=1）；

第三次握手：用戶端收到伺服器的回複指令并傳回确認（ACK=1）。

通過三次握手，建立了用戶端和伺服器之間的連接配接，現在可以請求和傳輸資料了。

請求和傳輸資料

通過get請求通路網站，請求頭中包含了這個cookie資訊。

cookie可以用來儲存一些有用的資訊：Cookies如果是首次通路，會提示伺服器建立使用者緩存資訊，如果不是，可以利用Cookies對應鍵值，找到相應緩存，緩存裡面存放着使用者名，密碼和一些使用者設定項。

通過這種GET請求，和伺服器的響應。可以将伺服器上的目标檔案傳輸到浏覽器進行渲染。

浏覽器渲染頁面

用戶端拿到伺服器端傳輸來的檔案，找到HTML和MIME檔案，通過MIME檔案，浏覽器知道要用頁面渲染引擎來處理HTML檔案，最終呈現給使用者一個完整的頁面。

 21. 在浏覽器中輸入www.baidu.com後執行的全部過程

事件順序：

1. 浏覽器擷取輸入的域名www.baidu.com
2. 浏覽器向DNS請求解析www.baidu.com的IP位址
3. 域名系統DNS解析出百度伺服器的IP位址
4. 浏覽器與該伺服器建立TCP連接配接(預設端口号80)
5. 浏覽器發出HTTP請求，請求百度首頁
6. 伺服器通過HTTP響應把首頁檔案發送給浏覽器
7. TCP連接配接釋放
8. 浏覽器将首頁檔案進行解析，并将Web頁顯示給使用者

涉及的協定：

應用層：HTTP(www通路協定)，DNS(域名解析服務)

傳輸層：TCP(為HTTP提供可靠的資料傳輸)，UDP(DNS使用UDP傳輸)

網絡層：IP協定；ICMP(提供網絡傳輸過程中的差錯檢測)；ARP(将本機的預設網關IP位址映射成實體MAC位址)

各層具體作用分析：

1. 應用層：用戶端浏覽器通過DNS解析到www.baidu.com的IP位址220.181.27.48，通過這個IP位址找到用戶端到伺服器的路徑。用戶端浏覽器發起一個HTTP會話到220.181.27.48，然後通過TCP進行資料包封裝，輸入到網絡層。
2. 傳輸層：在用戶端的傳輸層，把HTTP會話請求分成封包段，添加源和目的端口，如伺服器使用80端口監聽用戶端的請求，用戶端由系統随機選擇一個端口如5000，與伺服器進行交換，伺服器把相應的請求傳回給用戶端的5000端口，然後使用IP層的IP位址查找目的端。
3. 網絡層：用戶端的網絡層不用關心應用層或者傳輸層的東西，主要做的是通過查找路由表确定如何到達伺服器，期間可能經過多個路由器
4. 資料鍊路層：用戶端的鍊路層，包通過鍊路層發送到路由器，通過鄰居協定查找給定IP位址的MAC位址，然後發送ARP請求查找目的位址，如果得到回應後就可以使用ARP的請求應答交換的IP資料包現在就可以傳輸了，然後發送IP資料包到達伺服器的位址。

 22. Session和Cookie的差別？

Cookie的作用與原理

在用戶端通路某個位址時，會将請求交到伺服器進行處理，在發送請求的時候，浏覽器會将頁面的頭部資訊一并的交到伺服器端進行處理。在處理的過程中，Cookie在伺服器端生成，在此同時，可以将一些需要儲存的資訊，存放到此Cookie中。

生成Cookie對象時，需要确定具體的名稱及具體的值，可以設定目前Cookie的過期時間，設定過期時間後，就相當于持久化了Cookie中的資料，此時的Cookie會以之前的Cookie名稱，儲存在用戶端。如果不設定過期時間，則目前Cookie的生命期是浏覽器會話期間，一旦關閉了該浏覽器，目前的Cookie就會不存在了，此時的Cookie資訊是儲存在記憶體中。

在伺服器端，處理完後，會将生成的Cookie，随着HTTP響應，會在HTTP響應頭中，加上Cookie資訊，浏覽器接受到響應後，會按照HTTP響應頭裡的Cookie，在用戶端建立Cookie。在下次客戶進行請求的時候，HTTP會附帶着已經存儲過的Cookie，一并發送到伺服器。一個域，在用戶端建立的是以Cookie都是可以共享的，隻要Cookie沒有過期。

Session的作用與原理

Session是在伺服器端生成的，存儲在伺服器端，即存在記憶體中。

可以對生成的Session設定過期時間，如果不設定過期時間，預設的Session過期時間是30分鐘（在不同的伺服器中，它的過期時間略有不同）。但是，Session的生成的同時，會生成一個與之相關聯的的SessionID，此SessionID的存儲是需要Cookie來完成的。SessionID其值應該是一個既不會重複，又不容易被找到規律以仿造的字元串。SessionID會随着此次HTPP響應，一并傳回到用戶端，并儲存在用戶端中。到目前請求再次發出後，該SessionID會随着HTTP頭部，傳到伺服器中，伺服器依據目前SessionID得到與之對應的Session。

差別

二者都是用于保持使用者的會話，用于儲存使用者的使用者名和密碼等個人資訊。

1. 存儲位置：cookie存儲在用戶端，即浏覽器上；session存儲于伺服器端。
2. 實作機制：Session的實作常常依賴于Cookie機制，通過Cookie機制回傳SessionID
3. 大小限制：Cookie有大小限制并且浏覽器對每個站點也有Cookie的個數限制；Session沒有大小限制，理論上隻與伺服器的記憶體大小有關
4. 安全性：Cookie存在安全隐患，通過攔截或本地檔案找得到Cookie後可以進行攻擊；Session由于儲存在伺服器端，相對更加安全
5. 伺服器資源消耗：Session儲存在伺服器端上會存在一段時間才會消失，如果Session過多會增加伺服器的壓力