計算機網絡整理

TCP三次握手和四次揮手

最開始的時候客戶端和服務器都是處於CLOSED狀態。主動打開鏈接的爲客戶端，被動打開鏈接的是服務器。服務端進入監聽模式Listen

一、客戶端發送syn包到服務器，置發送序號爲x，並進入SYN_SENT（同步已發送狀態）狀態，等待服務器確認。

二、TCP服務器收到請求報文後，若是贊成鏈接，則發出確認報文。報文中包括標誌SYN和ACK，置發送序號爲y,確認序號x+1,此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態。

三、客戶端收到確認後，還要給服務器給出確認，發送ack報文確認序號爲Y+1.,置發送序號seq爲x+1,此時，TCP鏈接創建，客戶端進入ESTABLISHED（已創建鏈接）狀態。

當服務器收到客戶端的確認後也進入ESTABLISHED狀態，此後雙方就能夠開始通訊了。

數據傳輸完畢後，雙方均可釋放鏈接。最開始的時候，客戶端和服務器都是處於ESTABLISHED狀態，而後客戶端主動關閉，服務器被動關閉。

1. 客戶端進程發出鏈接釋放報文，而且中止發送數據。釋放數據報文首部，FIN=1，其序列號爲seq=u（等於前面已經傳送過來的數據的最後一個字節的序號加1），此時，客戶端進入FIN-WAIT-1（終止等待1）狀態。 TCP規定，FIN報文段即便不攜帶數據，也要消耗一個序號。
2. 服務器收到鏈接釋放報文，發出確認報文，ACK=1，ack=u+1，而且帶上本身的序列號seq=v，此時，服務端就進入了CLOSE-WAIT（關閉等待）狀態。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。這個狀態還要持續一段時間，也就是整個CLOSE-WAIT狀態持續的時間。
3. 客戶端收到服務器的確認請求後，此時，客戶端就進入FIN-WAIT-2（終止等待2）狀態，等待服務器發送鏈接釋放報文（在這以前還須要接受服務器發送的最後的數據）。
4. 服務器將最後的數據發送完畢後，就向客戶端發送鏈接釋放報文，FIN=1，ack=u+1，因爲在半關閉狀態，服務器極可能又發送了一些數據，假定此時的序列號爲seq=w，此時，服務器就進入了LAST-ACK（最後確認）狀態，等待客戶端的確認。
5. 客戶端收到服務器的鏈接釋放報文後，必須發出確認，ACK=1，ack=w+1，而本身的序列號是seq=u+1，此時，客戶端就進入了TIME-WAIT（時間等待）狀態。注意此時TCP鏈接尚未釋放，必須通過2∗∗MSL（最長報文段壽命）的時間後，當客戶端撤銷相應的TCB後，才進入CLOSED狀態。
6. 服務器只要收到了客戶端發出的確認，當即進入CLOSED狀態。一樣，撤銷TCB後，就結束了此次的TCP鏈接。能夠看到，服務器結束TCP鏈接的時間要比客戶端早一些。

 

爲何TCP客戶端最後還要發送一次確認呢？

一句話，主要防止已經失效的鏈接請求報文忽然又傳送到了服務器，從而產生錯誤。

若是使用的是兩次握手創建鏈接，假設有這樣一種場景，客戶端發送了第一個請求鏈接而且沒有丟失，只是由於在網絡結點中滯留的時間太長了，因爲TCP的客戶端遲遲沒有收到確認報文，覺得服務器沒有收到，此時從新向服務器發送這條報文，此後客戶端和服務器通過兩次握手完成鏈接，傳輸數據，而後關閉鏈接。此時此前滯留的那一次請求鏈接，網絡通暢了到達了服務器，這個報文本該是失效的，可是，兩次握手的機制將會讓客戶端和服務器再次創建鏈接，這將致使沒必要要的錯誤和資源的浪費。

若是採用的是三次握手，就算是那一次失效的報文傳送過來了，服務端接受到了那條失效報文而且回覆了確認報文，可是客戶端不會再次發出確認。因爲服務器收不到確認，就知道客戶端並無請求鏈接。

爲何客戶端最後還要等待2MSL？

MSL（Maximum Segment Lifetime），TCP容許不一樣的實現能夠設置不一樣的MSL值。

第一，保證客戶端發送的最後一個ACK報文可以到達服務器，由於這個ACK報文可能丟失，站在服務器的角度看來，我已經發送了FIN+ACK報文請求斷開了，客戶端尚未給我回應，應該是我發送的請求斷開報文它沒有收到，因而服務器又會從新發送一次，而客戶端就能在這個2MSL時間段內收到這個重傳的報文，接着給出迴應報文，而且會重啓2MSL計時器。

第二，防止相似與「三次握手」中提到了的「已經失效的鏈接請求報文段」出如今本鏈接中。客戶端發送完最後一個確認報文後，在這個2MSL時間中，就可使本鏈接持續的時間內所產生的全部報文段都從網絡中消失。這樣新的鏈接中不會出現舊鏈接的請求報文。

爲何創建鏈接是三次握手，關閉鏈接確是四次揮手呢？

創建鏈接的時候， 服務器在LISTEN狀態下，收到創建鏈接請求的SYN報文後，把ACK和SYN放在一個報文裏發送給客戶端。 
而關閉鏈接時，服務器收到對方的FIN報文時，僅僅表示對方再也不發送數據了可是還能接收數據，而本身也未必所有數據都發送給對方了，因此己方能夠當即關閉，也能夠發送一些數據給對方後，再發送FIN報文給對方來表示贊成如今關閉鏈接，所以，己方ACK和FIN通常都會分開發送，從而致使多了一次。

若是已經創建了鏈接，可是客戶端忽然出現故障了怎麼辦？

TCP還設有一個保活計時器，顯然，客戶端若是出現故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求後都會從新復位這個計時器，時間一般是設置爲2小時，若兩小時尚未收到客戶端的任何數據，服務器就會發送一個探測報文段，之後每隔75分鐘發送一次。若一連發送10個探測報文仍然沒反應，服務器就認爲客戶端出了故障，接着就關閉鏈接。 

七層網絡模型

七層結構記憶方法：應、表、會、傳、網、數、物（參考http://www.javashuo.com/article/p-fhcizesu-by.html）

OSI七層協議分別是：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。

• 物理層是咱們傳輸信息的一些介質，好比雙絞線、網線等
• 數據鏈路層是對數據傳輸最基本的協議，好比數據傳輸的0和1按照什麼方式進行理解，傳輸機制是全雙工仍是半雙工，主要將接收到的數據進行 MAC 地址（網卡地址）的封裝與解封裝。
• 網絡層是定義IP的選址，和一些路由的規則，怎麼講信息發送給網絡上另外的機器，主要將接收到的數據進行 IP 地址的封裝與解封裝。
• 傳輸層可以創建端到端的鏈接，進行數據的傳輸和理解
• 上三層能夠統一理解爲應用層，有封裝的不少種傳輸協議

HTTP與HTTPS的區別？

• HTTP通訊使用明文， 內容可能會被竊聽，不驗證通訊方的身份， 所以有可能遭遇假裝，沒法證實報文的完整性， 因此有可能已遭篡改，沒法阻止海量請求下的DoS 攻擊。

• HTTPS在HTTP協議基礎上增長了TLS/SSL加密傳送信息，使用443端口，https協議須要到ca申請證書，通常免費證書較少，於是須要必定費用。安全可是耗時多，緩存不是很好。

• TLS使用HMAC算法，更嚴密的警報 
  指紋是在證書信息後面加上一段內容（指紋算法），保證信息沒有被修改過。把前面的證書內容用指紋算法計算後與指紋內容比對，因爲指紋內容是由證書機構惟一的私鑰加密的，比對成功則是安全的。

• HTTPS加密解密過程：客戶端發起HTTPS請求–>服務端用CA配置–>傳送證書（公匙）–>客戶端解析證書（由TLS驗證後生成一個隨機值加密）–>傳送加密信息（隨機值）–>服務段解密信息（用私鑰解密隨機值，把內容經過該值進行對稱加密）–>傳輸加密後的信息–>客戶端解密信息（用以前生成的私鑰解密）

• SSL/TLS協議提供的服務：

  • 認證用戶和服務器，確保數據發送到正確的客戶機和服務器；
  • 加密數據以防止數據中途被竊取；
  • 維護數據的完整性，確保數據在傳輸過程當中不被改變

 TCP擁塞控制

連接