計算機網絡知識

時間 2020-06-11

標籤計算機網絡知識简体版

原文原文鏈接

OSI參考模型

OSI（參考模型）將通訊功能劃分爲7個分層，稱做OSI參考模型。OSI協議以OSI參考模型爲基礎界定了每一個階層之間接口相關的標準。css

OSI參考模型中各個分層的做用

分層名稱	功能	功能概覽
應用層	爲應用程序提供服務並規定應用程序中通訊相關的細節。	電子郵件協議、遠程登陸協議、文件傳輸協議
表示層	設備固有數據格式和網絡標準數據格式的轉換。將應用處理的信息轉換爲適合網絡傳輸的格式，或未來自下一層數據轉換成爲上層可以處理的格式。所以它主要負責數據格式的轉換。	接受不一樣表現形式的信息，如文字流、圖像、聲音等
會話層	通訊管理。負責創建和斷開通訊鏈接（數據流動的邏輯通路），以及數據的分割等數據傳輸相關的管理，管理傳輸層如下的分層	什麼時候創建鏈接，什麼時候斷開鏈接以及保持多久的鏈接
傳輸層	管理兩個節點之間的數據傳輸。負責可靠傳輸（確保數據被可靠地傳送到目標地址），只在通訊雙方節點上進行處理，而無需在路由器上處理。	是否有數據丟失
網絡層	將數據傳輸到目標地址。目標地址能夠是多個網絡經過路由器鏈接而成的某一個地址。所以這一層主要負責地址管理與路由選擇	通過哪一個路由傳遞到目標地址
數據鏈路層	負責物理層面上互連的、節點之間的通訊傳輸。例如與1個以太網相連的2個節點之間的通訊。互連設備之間傳送和識別數據幀	數據幀與比特流之間的轉換，將0、1序列劃分爲具備意義的數據幀傳送給對端（數據幀的生成與接收）
物理層	負責0、1比特流（0、1序列）與電壓的高低、光的閃滅之間的互換。界定鏈接器和網線的規格。	比特流與電子信號之間的切換

OSI模塊化通訊傳輸

通訊與7個分層：
html

發送方從第7層到第6層最後到第1層由上至下按照順序傳輸數據，而接收端則從第1層開始由下至上向每一個上一級分層傳輸數據。
每一個分層上，在處理由上一層傳過來的數據時能夠附上當前分層的協議所必須的「首部」信息。而後接受端對收到的數據進行數據「首部」與「內容」的分離，再轉發給上一層，並最終將發送端的數據恢復爲原狀。

應用層的工做
從用戶輸入完成所要發送的內容並點擊「發送」按鈕的那一刻開始，就進入了應用層協議的處理。該協議會在所要傳輸數據的前端附加一個首部（標籤）信息。該首部標明瞭郵件內容「早上好」和收件人爲「B」。這一附有首部信息的數據傳送給主機B 之後由該主機上的收發郵件軟件經過「收信」功能獲取內容。
主機B上的應用收到主機A發送過來的數據後，分析其數據首部與數據正文，並將郵件保存到硬盤或者是其餘非易失性存儲器以備進行相應的處理。若是主機B上收件人的郵箱空間已滿沒法接收新的郵件，則會返回一個錯誤給發送方。對這類異常的處理也正屬於應用層須要解決的問題。
表示層的工做
將數據從「某個計算機特定的數據格式」轉換爲「網絡通用的標準數據格式」後再發出去。接受端主機收到數據之後將這些網絡標準格式的數據恢復爲「該計算機特定的數據格式」，而後再進行相應的處理。因爲數據被轉換成爲了通用標準的格式再進行處理，使得異構的機型之間也能保持數據的一致性。這也正是表示層的做用所在。即表示層是進行「統一的網絡數據格式」與「某一臺計算機或某一款軟件特有的數據格式」之間互相轉換的分層。
表示層（主機A）與表示層（主機B）之間爲了識別編碼的格式也會附加首部信息，從而將實際傳輸的數據轉交給下一層去處理。
會話層的工做
假定用戶A新建了5封郵件準備發送給用戶B。這5封郵件的發送順序能夠有不少種。例如，能夠每發一封郵件時創建一次鏈接（通訊鏈接），隨後斷開鏈接。還能夠一經創建好鏈接後就將5封郵件連續發送給對方。決定採用何種鏈接方法是會話層的主要責任。
會話層也像應用層或表示層那樣，在其收到的數據前端附加首部或標籤信息後再轉發給下一層。而這些首部或標籤中記錄着數據傳送順序的信息。

以上說明了在應用層寫入數據經由表示層格式化編碼、再由會話層標記發送順序後才被髮送出去的大體過程。然而會話層只對什麼時候創建鏈接、什麼時候發送數據等問題進行管理（定時間），並不具備實際傳輸數據的功能。真正負責在網絡上傳輸具體數據的是會話層如下的。

傳輸層的工做
進行創建鏈接或者斷開鏈接的處理，在兩個主機之間建立邏輯上的通訊鏈接便是傳輸層的主要做用。此外，傳輸層爲確保所傳輸的數據到達目標地址，會在通訊兩端的計算機之間進行確認，若是數據沒有到達，它會負責進行重發。
例如，主機A將「早上好」這一數據發送給主機B。期間可能會由於某些緣由致使數據被破壞，或因爲發生的某些網絡異常致使只有一部分數據到達目標地址。假設主機B只收到了「早上」這一部分，那麼它會在收到數據後將本身沒有收到「早上」以後那部分數據的事實告知主機A。主機A得知這個狀況後就會將後面的「好」重發給主機B，並再次確認對端是否收到。

保證數據傳輸的可靠性是傳輸層的一個重要做用。爲了確保可靠性，在這一層也會爲所要傳輸的數據附加首部以識別這一分層的數據。然而，實際上將數據傳輸給對端的處理是由網絡層來完成的。

網絡層的工做
網絡層的做用是在網絡與網絡互相鏈接的環境中，將數據從發送端主機發送到接受端主機。兩端主機之間雖然有衆多數據鏈路，但可以將數據從主機A送到主機B也都是網絡層的功勞。
在實際發送數據時，目的地址相當重要。這個地址是進行通訊的網絡中惟一指定的序號。也能夠把它想象成爲平常生活中的電話號碼。只要這個目標地址肯定了，就能夠在衆多計算機中選出該目標地址所對應的計算機發送數據。基於這個地址，就能夠在網絡層進行數據包的發送處理。而有了地址和網絡層的包發送處理，就能夠將數據發送到世界上任何一臺互連設備。網絡層中也會將其從上層收到的數據和地址信息等一塊兒發送給下面的數據鏈路層，進行後面的處理。

傳輸層與網絡層的關係
在不一樣的網絡體系下，網絡層又是也不能保證數據的可達性。例如，在至關於TCP/IP網絡層的IP協議中，就不能保證數據必定會發送到對端地址。所以，數據傳送過程當中出現數據丟失、順序混亂等問題可能性會大大增長。像這樣沒有可靠性傳輸要求的網絡層中，能夠由傳輸層負責提供「正確傳輸數據的處理」。TCP/IP中，網絡層與傳輸層相互協做以保證數據包可以傳送到世界各地，實現可靠傳輸。

數據鏈路層、物理層
通訊傳輸實際上就是經過物理的傳輸介質實現的。數據鏈路層的做用就是在這些經過傳輸介質互連的設備之間進行數據處理。
物理層中，將數據0、1轉換爲電壓和脈衝光傳輸給物理的傳輸介質，而相互直連的設備之間使用地址實現傳輸。這種地址被稱爲MAC地址（Media Access Control，介質訪問控制），也可稱爲物理地址或硬件地址。採用MAC地址，目的是爲了識別鏈接到同一個傳輸介質上的設備。所以在這一分層中將包含MAC地址信息的首部附加到從網絡層轉發過來的數據上，將其發送到網絡。

網絡層與數據鏈路層都是基於目標地址將數據發送給接受端的，可是網絡層負責將整個數據發送給最終目標地址，而數據鏈路層則只負責一個分段內的數據。

TCP和UDP

TCP/IP中有兩個具備表明性的傳輸層協議，分別是TCP和UDP前端

TCP

TCP是面向鏈接的、可靠的流協議。流就是指不間斷的數據結構，你能夠把它想象成排水管道中的水流。當應用程序採用TCP發送消息時，雖然能夠保證發送的順序，但仍是猶如沒有任何間隔的數據流發送給接收端。爲提供可靠性傳輸，實行「順序控制」或「重發控制」機制。

TCP首部包括：linux

源端口號和目標端口號（用以識別發送主機跟接收主機上的應用）
序列號（用以表示該包中數據是發送端整個數據中第幾字節的序列號）
確認應答號（下一次應該收到的數據的序列號，已收到確認應答號前一位爲止的數據，發送端收到這個確認應答之後能夠認爲這個序號之前的數據已經被正常接收）
校驗和（用以判斷數據是否被損壞）
數據偏移（表示TCP所傳輸的數據部分應該從TCP包的哪一個位開始計算，也能夠把它當作TCP首部的長度）
控制位（字段長8位，包括ACK(值爲1，確認字段應答變爲有效)SYN（爲1表示但願創建鏈接，並在其序列號字段進行序列初始值的設定）FIN（爲1時表示從此不會發送數據，但願斷開鏈接，每一個主機對對方的FIN包進行確認後就能夠斷開鏈接））

經過序列號和確認號應答（ACK）TCP實現可靠性傳輸算法

UDP

UDP是無鏈接（發送報文段前，通訊雙方沒有握手的過程）的，不具備可靠性的數據報協議。細微的處理它會交給上層的應用去完成。在UDP的狀況下，雖然能夠確保發送消息的大小，卻不能保證消息必定會到達。所以，應用有時候會根據本身的須要進行重發處理。

UDP首部包括：數據庫

源端口號和目標端口號
包長度（保存了UDP首部的長度跟數據的長度之和）
校驗和（UDP差錯校驗機制可是沒有差錯恢復能力）

（TCP/IP中識別一個進行通訊的應用須要5大元素，「源IP地址」、「目標IP地址」、「源端口」、「目標端口」、「協議號」，然而UDP的首部中只包含它們當中的兩項「源端口和目標端口」，剩下的3項都包含在IP首部裏，若是這3項被破壞了可能致使收包應用收不到包，或者不應收到的應用收到了，因此有必要驗證通訊中5項識別碼是否正確，引入僞首部，`TCP/UDP經過僞首部，得以對5項數字進行驗證，從而實現即便在IP首部並不可靠地狀況下仍然可以提供可靠傳輸`）

TCP和UDP區分

TCP用於在傳輸層有必要實現可靠傳輸的的狀況。因爲它是面向有鏈接並具有順序控制、重發控制等機制，因此它能夠爲應用提供可靠傳輸。windows
- TCP 協議是面向鏈接的，在通訊雙方進行通訊前，須要經過三次握手創建鏈接。它須要在端系統中維護雙方鏈接的狀態信息；
- TCP 協議經過序號、確認號、定時重傳、檢驗和等機制，來提供可靠的數據傳輸服務；
- TCP 協議提供的是點對點的服務，即它是在單個發送方和單個接收方之間的鏈接；
- TCP 協議提供的是全雙工的服務，也就是說鏈接的雙方的可以向對方發送和接收數據；
- TCP 提供了擁塞控制機制，在網絡擁塞的時候會控制發送數據的速率，有助於減小數據包的丟失和減輕網絡中的擁塞程度；
- TCP 提供了流量控制機制，保證了通訊雙方的發送和接收速率相同。若是接收方可接收的緩存很小時，發送方會下降發送速率，避免由於緩存填滿而形成的數據包的丟失
UDP主要用於那些對高速傳輸和實時性有較高要求的通訊或廣播通訊。瀏覽器
- 由於UDP沒有握手的過程因此沒有創建鏈接的時延，沒有鏈接也不須要在端系統中保存鏈接的狀態；
- UDP提供盡力而爲的交付服務，也就是說UDP不保證數據的可靠交付
- UDP沒有擁塞控制和流量控制，因此報文段的發送速率沒有限制；
- 由於UDP套接字只使用目的地址和目的端口來標識，因此能夠支持一對1、一對多、多對一和多對多的交互通訊；
- UDP首部小，只有8個字節。

舉例：經過IP電話進行通訊，若是使用TCP，數據在傳送途中若是丟失會被重發，但這樣沒法流暢的傳輸通話人的聲音，會致使沒法進行正常交流。而採用UDP，他不會進行重發處理。從而也就不會有聲音大幅度延遲到達的問題。即便有部分數據丟失，也只是影響某一部分的通話。此外，在多播（一對多）與廣播（一對全體）通訊中，也使用UDP而不是TCP。

包、幀、數據報、段、消息

以上五個術語都是用來表述數據的單位，區分以下：緩存

包能夠說是全能性術語。
幀用於表示數據鏈路層中包的單位。
數據報是IP和UDP等網絡層以上的分層中包的單位。
段則表示TCP數據流中的信息。
消息是指應用協議中數據的單位。

TCP鏈接

使用TCP首部用於控制的字段來管理TCP鏈接。一個鏈接的創建與斷開，至少須要來回發送7個包才能完成。TCP經過檢驗和、序列號、確認應答、重發機制、鏈接管理以及窗口控制等機制實現可靠性傳輸。
安全

在TCP中，當發送端的數據到達接收主機時，接收端主機會返回一個已收到消息的通知。這個消息叫作確認應答（ACK）。當發送端將數據發出後會等待對端的確認應答，若是有確認應答，說明數據已經成功到達對端；在必定時間內沒有等到確認應答，發送端就會認爲數據已經丟失（有多是發送數據丟失或者確認應答消息丟失），從新發送。
若是確認應答由於某些緣由致使應答延遲到達，源主機會重複發出數據，目標主機反覆接受相同的數據，而爲了對上層應用提供可靠地傳輸，必須放棄重複的數據包。爲此引入一種機制，可以識別是否已經接受數據，又能判斷是否須要接收。這些確認應答處理、重發控制以及重複控制等功能都是能夠經過序列號實現。

序列號是按順序給發送數據的每個字節（8位字節）都標上號碼的編號。接收端查詢接收數據TCP首部中的序列號和數據長度，將本身下一步應該接收的序列號做爲確認應答返送回去。就這樣，經過序列號和確認應答號，TCP實現可靠性傳輸。

三次握手

第一次握手，客戶端向服務器發送一個 SYN 鏈接請求報文段，報文段的首部中 SYN 標誌位置爲 1，序號字段是一個任選的隨機數。它表明的是客戶端數據的初始序號。（客戶端調用connect發起主動打開active open），客戶端狀態SYN_SENT
第二次握手，服務器端接收到客戶端發送的 SYN 鏈接請求報文段後，服務器首先會爲該鏈接分配 TCP 緩存和變量，而後向客戶端發送 SYN ACK 報文段，報文段的首部中 SYN 和 ACK 標誌位都被置爲 1，表明這是一個對 SYN 鏈接請求的確認，同時序號字段是服務器端產生的一個任選的隨機數，它表明的是服務器端數據的初始序號。確認號字段爲客戶端發送的序號加一。(服務端socket\bind\listen被動打開passive open)，接收端狀態SYN_RECEIVE
第三次握手，客戶端接收到服務器的確定應答後，它也會爲此次 TCP 鏈接分配緩存和變量，同時向服務器端發送一個對服務器端的報文段的確認。第三次握手能夠在報文段中攜帶數據。客戶端和接收端狀態ESTABLISHED

TCP 三次握手的創建鏈接的過程就是相互確認初始序號的過程，告訴對方，什麼樣序號的報文段可以被正確接收。第三次握手的做用是客戶端對服務器端的初始序號的確認。若是隻使用兩次握手，那麼服務器就沒有辦法知道本身的序號是否已被確認。同時這樣也是爲了防止失效的請求報文段被服務器接收，而出現錯誤的狀況。

四次揮手

由於 TCP 鏈接是全雙工的，也就是說通訊的雙方均可以向對方發送和接收消息，因此斷開鏈接須要雙方的確認。

第一次揮手，客戶端認爲沒有數據要再發送給服務器端，它就向服務器發送一個 FIN 報文段，申請斷開客戶端到服務器端的鏈接。發送後客戶端進入 FIN\_WAIT\_1 狀態
第二次揮手，服務器端接收到客戶端釋放鏈接的請求後，向客戶端發送一個確認報文段，表示已經接收到了客戶端釋放鏈接的請求，之後再也不接收客戶端發送過來的數據。可是由於鏈接是全雙工的，因此此時，服務器端還能夠向客戶端發送數據。服務器端進入 CLOSE\_WAIT 狀態。客戶端收到確認後，進入 FIN\_WAIT\_2 狀態。
第三次揮手，服務器端發送完全部數據後，向客戶端發送 FIN 報文段，申請斷開服務器端到客戶端的鏈接。發送後進入 LAS T\_ACK 狀態。
第四次揮手，客戶端接收到 FIN 請求後，向服務器端發送一個確認應答，並進入 TIME\_WAIT 階段。該階段會持續一段時間，這個時間爲報文段在網絡中的最大生存時間，若是該時間內服務端沒有重發請求的話，客戶端進入 CLOSED 的狀態。若是收到服務器的重發請求就從新發送確認報文段。服務器端收到客戶端的確認報文段後就進入 CLOSED 狀態，這樣全雙工的鏈接就被釋放了。

TCP 使用四次揮手的緣由是由於 TCP 的鏈接是全雙工的，因此須要雙方分別釋放到對方的鏈接，單獨一方的鏈接釋放，只代表不能再向對方發送數據，鏈接處於的是半釋放的狀態。
最後一次揮手中，客戶端會等待一段時間再關閉的緣由，是爲了防止發送給服務器的確認報文段丟失或者出錯，從而致使服務器端不能正常關閉。

HTTPS

TLS/SSL和HTTPS

Web中能夠經過TSL/SSL對HTTP通訊進行加密。使用TSL/SSL的HTTP通訊叫作HTTPS通訊。HTTPS中採用對稱加密方式。而在發送其公共密鑰時採用的則是公鑰加密方式。

確認公鑰是否正確主要使用認證中心（CA）簽發的證書，而主要的認證中心信息已經嵌入到瀏覽器出廠設置中。若是Web瀏覽器中還沒有加入某個認證中心，那麼會在頁面上提示一個警告信息。此時，判斷認證中心是否合法與否就要由用戶本身決定。

SSL/TLS協議的基本思路是採用公鑰加密法；
SSL/TLS協議的基本過程是這樣的：
（1）客戶端向服務器端索要並驗證公鑰。
（2）雙方協商生成」對話密鑰」。客戶端用公鑰對對話祕鑰進行加密。
（3）服務器經過私鑰解密出對話祕鑰
（3）雙方採用」對話密鑰」進行加密通訊。
上面過程的前兩步，又稱爲」握手階段」

注意：服務器有兩個密鑰，一個公鑰、一個私鑰，只有私鑰才能夠解密公鑰加密的消息；

對稱加密：加密效率高，速度快，適合大數據量加密。DES/AES

非對稱加密：算法複雜，加密速度慢，安全性更高。結合對稱加密使用。RSA、DH RSA 算法的可靠性基礎：對極大整數作因數分解是很困難的。

信息加密技術

單向散列加密

單向散列加密是指經過對不一樣輸入長度的信息進行散列計算，獲得固定長度的輸出，這個散列計算過程是單向的，即不能對輸出進行計算從而獲得輸入信息。

利用散列表這個特性，能夠進行密碼加密保存，即用戶註冊時輸入的密碼不直接保存在數據庫中，而是對密碼進行單向散列表加密，將密文存入數據庫，用戶登錄時，進行密碼驗證，一樣計算獲得輸入密碼的密文，並和數據庫中的密文比較，若是結果一致，則密碼驗證成功。
具體過程如圖：

這樣保存在數據庫中的是用戶輸入的密碼的密文，並且是不可逆計算獲得的密碼的明文，所以即便數據庫被「暴露」，也不會泄露用戶的密碼信息。
另外，雖然不能經過算法將單向散列密文反算獲得明文，可是因爲人們設置密碼具備必定的模式，所以經過彩虹表（人們經常使用的密碼與對應的密文關係表，具體我還不瞭解。。。）等手段進行猜想式破解。~~（沒有絕對的安全～～～）~~
爲了增強單向散列計算的安全性，還會給散列算法加點鹽（salt），salt至關於加密的密鑰，增長破解的難度。

經常使用的單向散列算法有MD五、SHA等。單向散列算法還有一個特色就是輸入的任何微小變化都會致使輸出的徹底不一樣，這個特性有時也會被用來生成信息摘要、計算具備高離散程度的隨機數等用途。

對稱加密

對稱加密就是加密和解密使用的密鑰是同一個密鑰。
對稱加密一般用在信息須要安全交換或存儲的場合，如cookie加密、通訊加密等。

優勢是：算法簡單，加密解密效率高，系統開銷小，適合對大量數據加密。
缺點是：加解密使用同一個密鑰，遠程通訊的狀況下如何安全的交換密鑰是個難題，若是密鑰丟失，那麼全部的加密信息也就咩有什麼祕密可言了。

經常使用的對稱加密算法有DES算法、RC算法等。對稱加密是一種傳統加密手段，也是最經常使用的加密手段，適用於絕大多數須要加密的場合。

非對稱加密

不一樣與對稱加密，非對稱加密和解密使用的密鑰不是同一密鑰，其中一個對外界公開，被稱做公鑰。另外一個只有全部者知道，被稱做私鑰。用公鑰加密的信息必須用私鑰才能解開，反之，用私鑰加密的信息只有用公鑰才能解開。
非對稱加密技術一般用在信息安全傳輸，數字簽名等場合。

信息發送者A經過公開渠道得到接收者B的公鑰，對提交信息進行加密，而後經過非安全傳輸通道將密文信息發送給B，B獲得密文信息後，用本身的私鑰對信息進行解密，得到原始的明文信息。
數字簽名則相反，簽名者用本身的私鑰對信息進行加密，而後發送給對方，接收方用簽名者的公鑰對信息進行解密，得到原始明文信息，因爲私鑰只有簽名者本身擁有，所以該信息是不可抵賴的，具備簽名的性質。

在實際應用中，經常會混合使用對稱加密和非對稱加密。先使用非對稱加密技術對對稱密鑰進行安全傳輸，而後使用對稱加密技術進行信息加密解密與交換。而有時，對同一個數據兩次使用非對稱加密，可同時實現信息安全傳輸和數字簽名的目的。

非對稱加密的經常使用算法有RSA算法等。HTTPS傳輸中瀏覽器使用的數字證書實質上是通過權威機構認證的非對稱加密的公鑰。

應用層相關問題

1.http與https工做方式

HTTP協議

輸入一個網頁：
域名解析 --> 發起TCP的3次握手 --> 創建TCP鏈接後發起http請求 --> 服務器響應http請求，瀏覽器獲得html代碼 --> 瀏覽器解析html代碼，並請求html代碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給用戶。

其完整的工做過程可分爲四步：

①鏈接：首先客戶機與服務器須要創建鏈接（由TCP/IP握手鍊接實現）。只要單擊某個超級連接，HTTP的工做開始；

②請求：創建鏈接後，客戶機發送一個請求給服務器，請求方式的格式爲：統一資源標識符（URL）、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容；

③應答：服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。客戶端接收服務器所返回的信息經過瀏覽器顯示在用戶的顯示屏上；

④關閉：當應答結束後，瀏覽器和服務器關閉鏈接，以保證其餘瀏覽器能夠與服務器進行鏈接。

更完整的過程可能以下：

若是在以上過程當中的某一步出現錯誤，那麼產生錯誤的信息將返回到客戶端，有顯示屏輸出。對於用戶來講，這些過程是由HTTP本身完成的，用戶只要用鼠標點擊，等待信息顯示就能夠了。

Https協議

HTTPS握手過程包括五步：

1）瀏覽器請求鏈接；
2）服務器返回證書：證書裏面包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
服務器採用非對稱加密算法（RSA）生成兩個祕鑰，私鑰本身保留。
3）瀏覽器收到證書後做如下工做：

a) 驗證證書的合法性；
b) 生成隨機（對稱）密碼，取出證書中提供的公鑰對隨機密碼加密；

瀏覽器即客戶端使用非對稱加密來加密對稱加密規則，對稱加密用於加密後續傳輸的信息。

c) 將以前生成的加密隨機密碼等信息發送給網站；

4）服務器收到消息後做如下的操做：

a) 使用本身的私鑰解密瀏覽器用公鑰加密後的消息，並驗證HASH是否與瀏覽器發來的一致；得到瀏覽器發過來的對稱祕鑰。
b) 使用加密的隨機對稱密碼加密一段消息，發送給瀏覽器；

5）瀏覽器解密並計算握手消息的HASH：若是與服務端發來的HASH一致，此時握手過程結束，以後進行通訊。

2. HTTP和HTTPS的區別

HTTP和HTTPS的基本概念

HTTP：是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準（TCP），用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議，它可使瀏覽器更加高效，使網絡傳輸減小。
HTTP風險：
一、竊聽風險，採用明文傳輸
二、篡改風險，第三方能夠修改
三、冒充風險，第三方冒充他人身份進行通訊

HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。
HTTPS協議的主要做用能夠分爲兩種：
一種是創建一個信息安全通道，來保證數據傳輸的安全；另外一種就是確認網站的真實性。

HTTPS和HTTP的區別主要以下

1) https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。
2) http是超文本傳輸協議，信息是明文傳輸，https則是具備安全性的ssl加密傳輸協議。
3) http和https使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
4) http的鏈接很簡單，是無狀態的；https協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
5) 在OSI模型中，http工做於應用層，而https工做於傳輸層；

3. http有狀態嗎？

是無狀態協議

無狀態是指協議對於事務處理沒有記憶能力，服務器不知道客戶端是什麼狀態。從另外一方面講，打開一個服務器上的網頁和你以前打開這個服務器上的網頁之間沒有任何聯繫。
HTTP是一個無狀態的面向鏈接的協議，無狀態不表明HTTP不能保持TCP鏈接，更不能表明HTTP使用的是UDP協議（無鏈接）。

從HTTP/1.1起，默認都開啓了Keep-Alive，保持鏈接特性，簡單地說，當一個網頁打開完成後，客戶端和服務器之間用於傳輸

4. HTTP1.0、HTTP1.一、HTTP2.0的區別？

HTTP1.0

一、默認短鏈接，每一個TCP鏈接只能發送一個請求，而創建TCP成本很高。須要使用keep-alive參數來告知服務器要創建一個長鏈接，

二、HTTP1.0是沒有host域的，HTTP1.1才支持這個參數；

HTTP 1.1

一、在HTTP/1.1中已經默認使用Connection: keep-alive，避免了鏈接創建和釋放的開銷，但服務器必須按照客戶端請求的前後順序依次回送相應的結果，以保證客戶端可以區分出每次請求的響應內容。經過Content-Length字段來判斷當前請求的數據是否已經所有接收。不容許同時存在兩個並行的響應。

二、支持只發送header信息(不帶任何body信息)，若是服務器認爲客戶端有權限請求服務器，則返回100，不然返回401；

三、HTTP1.1引入管道機制，即在同一個TCP鏈接中，能夠同時發送多個請求，服務器按順序響應。

四、引入分塊傳輸編碼機制，在耗時操做上，產生一塊數據，就發送一塊數據。

HTTP1.1的缺點：由於管道機制，使得多個請求可能由於先到請求比較耗時而阻塞。

HTTP2.0

一、使用了多路複用的技術，作到同一個鏈接併發處理多個請求，並且併發請求的數量比HTTP1.1大了好幾個數量級；

二、支持header數據的壓縮，HTTP2.0使用HPACK算法對header的數據進行壓縮，這樣數據體積小了，在網絡上傳輸就會更快；

三、服務器推送：服務器除了對最初請求的響應外，服務器還能夠額外的向客戶端推送資源，而無需客戶端明確的請求。

5. HTTP 請求方法

GET
GET用於信息獲取。
POST
POST向服務器提交數據，能夠改變服務器上的資源。
HEAD
HEAD與GET本質是同樣的，區別在於主要用於獲取報文首部，不返回報文主體信息。
PUT
PUT與POST極爲類似，都是向服務器發送數據，但PUT一般制定了資源存放的位置，而POST沒有。
DELETE
DELETE用於刪除某一資源。
OPTIONS
OPTIONS用於獲取當前URL所支持的HTTP請求方法
TRACE
TRACE用於追蹤路徑，遠程診斷服務器，它會把服務器以前的請求通訊返回給客戶端。

6. GET和POST差異

（1）發送機制不一樣，GET通常用於查詢/獲取資源信息，而POST通常用於更新資源信息。

（2）GET請求的數據會附在URL以後，POST把提交的數據放置在HTTP請求體中

（3）GET方式提交的數據最多隻能是1024字節（取決於操做系統的支持），POST理論上沒有數據量的限制（取決於服務器的處理能力）。

（4）POST的安全性比GET的安全性高。經過GET提交數據，用戶名和密碼會以明文的形式出如今URL中

（5）GET請求會被瀏覽器自動緩存，而POST不會，除非手動設置。在瀏覽器回退時，GET是無害的，POST會再次提交請求。GET請求參數會被完整保留在瀏覽歷史記錄中，而POST中的參數不會被保留

（6）在發送請求時，GET產生一個TCP數據包，服務器響應200，POST產生兩個TCP數據包，瀏覽器先發送header，響應100，再發送data，響應200.

（7）GET請求只能進行url編碼，而POST支持多種編碼方式。

7. DNS是幹什麼的？？

1) 主機解析域名的順序：找緩存、找本機的 hosts文件、找 DNS服務器
2) DNS協議運行在 UDP協議之上，使用端口號 53
3) 根服務器： ISP的 DNS服務器還找不到的話，它就會向根服務器發出請求，進行遞歸查詢（ DNS服務器先問根域名服務器 .com域名服務器的 IP地址，而後再問 .com域名服務器，依次類推）

十個過程：

① 瀏覽器先檢查自身緩存中有沒有被解析過這個域名對應的ip地址；

② 若是瀏覽器緩存沒有命中，瀏覽器會檢查操做系統緩存中有沒有對應的已解析過的結果。在windows中可經過c盤裏hosts文件來設置；

③ 還沒命中，請求本地域名服務器來解析這個域名，通常都會在本地域名服務器找到；

④ 本地域名服務器沒有命中，則去根域名服務器請求解析；

⑤ 根域名服務器返回給本地域名服務器一個所查詢域的主域名服務器；

⑥ 本地域名服務器向主域名服務器發送請求；

⑦ 接受請求的主域名服務器查找並返回這個域名對應的域名服務器的地址；

⑧ 域名服務器根據映射關係找到ip地址，返回給本地域名服務器；

⑨ 本地域名服務器緩存這個結果；

⑩ 本地域名服務器將該結果返回給用戶；

運輸層相關問題

1. HTTP keep-aliave 和TCP keepaliave

HTTP的Keepalive，顧名思義，目的在於延長鏈接的時間，以便在同一條鏈接中傳輸多個HTTP請求。

HTTP服務器通常會提供Keepalive Timeout參數，用來決定鏈接保持多久，何時關閉鏈接。

當鏈接使用了Keepalive功能時，對於客戶端發送過來的一個請求，服務器端會發送一個響應，而後開始計時，

若是通過Timeout時間後，客戶端沒有再發送請求過來，服務器端就把鏈接關了，再也不保持鏈接了。

TCP的Keepalive，是掛羊頭賣狗肉的，目的在於看看對方有沒有發生異常，若是有異常就及時關閉鏈接。

當傳輸雙方不主動關閉鏈接時，就算雙方沒有交換任何數據，鏈接也是一直有效的。

若是這個時候對端、中間網絡出現異常而致使鏈接不可用，本端如何得知這一信息呢？

答案就是保活定時器。它每隔一段時間會超時，超時後會檢查鏈接是否空閒過久了，若是空閒的時間超過了設置時間，就會發送探測報文。而後經過對端是否響應、響應是否符合預期，來判斷對端是否正常，
若是不正常，就主動關閉鏈接，而不用等待HTTP層的關閉了。

2. 詳細說一下TCP協議，三次握手傳輸的內容？13種狀態

1) 第一次握手：創建鏈接。客戶端發送鏈接請求報文段，將SYN位置爲1，Sequence Number爲x；而後，客戶端進入SYN\_SEND狀態，等待服務器的確認；

2) 第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，須要對這個SYN報文段進行確認，設置Acknowledgment Number爲x+1(Sequence Number+1)；同時，本身本身還要發送SYN請求信息，將SYN位置爲1，Sequence Number爲y；服務器端將上述全部信息放到一個報文段（即SYN+ACK報文段）中，一併發送給客戶端，此時服務器進入SYN\_RECV狀態；

3) 第三次握手：客戶端收到服務器的SYN+ACK報文段。而後將Acknowledgment Number設置爲y+1，向服務器發送ACK報文段，這個報文段發送完畢之後，客戶端和服務器端都進入ESTABLISHED狀態，完成TCP三次握手。

那四次分手呢？

當客戶端和服務器經過三次握手創建了TCP鏈接之後，當數據傳送完畢，確定是要斷開TCP鏈接的啊。那對於TCP的斷開鏈接，這裏就有了神祕的「四次分手」。

1) 第一次分手：主機1（可使客戶端，也能夠是服務器端），設置Sequence Number和Acknowledgment Number，向主機2發送一個FIN報文段；此時，主機1進入FIN\_WAIT\_1狀態；這表示主機1沒有數據要發送給主機2了；

2) 第二次分手：主機2收到了主機1發送的FIN報文段，向主機1回一個ACK報文段，Acknowledgment Number爲Sequence Number加1；主機1進入FIN\_WAIT\_2狀態；主機2告訴主機1，我「贊成」你的關閉請求；此時主機2進入CLOSE\_WAIT狀態

3) 第三次分手：主機2向主機1發送FIN報文段，請求關閉鏈接，同時主機2進入LAST\_ACK狀態；

4) 第四次分手：主機1收到主機2發送的FIN報文段，向主機2發送ACK報文段，而後主機1進入TIME\_WAIT狀態；主機2收到主機1的ACK報文段之後，就關閉鏈接；此時，主機1等待2MSL後依然沒有收到回覆，則證實Server端已正常關閉，那好，主機1也能夠關閉鏈接了。

5) 六大標誌位

SYN，同步標誌位；ACK確認標誌位；PSH傳送標誌位；FIN結束標誌位；RST重置標誌位；URG緊急標誌位；seq序號；ack確認號

3. TCP爲啥揮手要比握手多一次？

由於當處於LISTEN狀態的服務器端收到來自客戶端的SYN報文(客戶端但願新建一個TCP鏈接)時，它能夠把ACK(確認應答)和SYN(同步序號)放在同一個報文裏來發送給客戶端。但在關閉TCP鏈接時，當收到對方的FIN報文時，對方僅僅表示對方已經沒有數據發送給你了，可是你本身可能還有數據須要發送給對方，則等你發送完剩餘的數據給對方以後，再發送FIN報文給對方來表示你數據已經發送完畢，並請求關閉鏈接，因此一般狀況下，這裏的ACK報文和FIN報文都是分開發送的。

4. 爲何必定進行三次握手,不是兩次？

採用兩次握手，那麼若Client向Server發起的包A1若是在傳輸鏈路上遇到的故障，致使傳輸到Server的時間至關滯後，在這個時間段因爲Client沒有收到Server的對於包A1的確認，那麼就會重傳一個包A2，假設服務器正常收到了A2的包，而後返回確認B2包。因爲沒有第三次握手，這個時候Client和Server已經創建鏈接了。再假設A1包隨後在鏈路中傳到了Server，這個時候Server又會返回B1包確認，可是因爲Client已經清除了A1包，因此Client會丟棄掉這個確認包，可是Server會保持這個至關於「殭屍」的鏈接。

因此採用兩次握手，有可能會浪費Server的網絡資源。
還有，經過seq號和ACK號協商接下來發送數據的開始序號

5. 四次揮手能不能變成三次揮手呢？

答案是可能的。

TCP是全雙工通訊，Cliet在本身已經不會在有新的數據要發送給Server後，能夠發送FIN信號告知Server，這邊已經終止Client到對端Server那邊的數據傳輸。可是，這個時候對端Server能夠繼續往Client這邊發送數據包。因而，兩端數據傳輸的終止在時序上是獨立而且可能會相隔比較長的時間，這個時候就必須最少須要2+2 = 4 次揮手來徹底終止這個鏈接。可是，若是Server在收到Client的FIN包後，在也沒數據須要發送給Client了，那麼對Client的ACK包和Server本身的FIN包就能夠合併成爲一個包發送過去，這樣四次揮手就能夠變成三次了(彷佛linux協議棧就是這樣實現的)。