Http協議再理解（一）經典模型、三次握手、四次揮手 DannyCloud

寫在前面

本來是本身整理的,可是發現仍是原博主寫的比較的全面,在這裏附上原文章地址,同時貼出來方便往後本身查閱學習.
原文章地址

本身的理解

三次握手:

• 客戶端->服務端: 我要準備鏈接你了
• 服務端->客戶端: 好的我知道了 + 這是我專門給你的特殊標記
• 客戶端->服務端: 我收到你的特殊標記了
• (服務端收到客戶端的確認,此時就已經成功的創建鏈接了)

四次揮手:

• 客戶端->服務端: 我數據所有發送完了
• 服務端->客戶端: 我知道了,可是我仍是會向你發送後面的數據的(若是服務端還有數據發到客戶端,客戶端仍是會繼續接收數據的)
• 服務端->客戶端: 個人全部數據也發送完了
• 客戶端->服務端: 我知道了(我等待2MSL以後我就會關閉鏈接了),你能夠關閉鏈接了
• (服務端收到客戶端的確認以後就會斷開鏈接)

爲何是三次握手不是更多後者是更少?
**假如次數是兩次若是是客戶端->服務端請求鏈接,服務端->客戶端贊成鏈接,這樣客戶端直接發送數據,這樣無非是最好的也最節約資源的.可是會出現如下的狀況
**可是假如是兩次,可是客戶端->服務端發送請求鏈接的請求時,若是有由於網絡的緣由致使請求在某一個節點滯留,一直延誤到此次請求鏈接釋放了以後纔到達的服務端,服務端->客戶端贊成鏈接,而且一直等待着客戶端發送請求過來,可是對於客戶端來講根本就沒有此次的請求,可是服務端的資源就這樣一直白白的浪費在這裏
** 若是使用的三次握手的話,服務端發出了贊成鏈接的確認以後,可是因爲客戶端一直沒有給出確認的回覆,那麼服務端是不會建立鏈接的
** 由上面的解釋咱們就知道兩次不能完美的解決鏈接的問題,可是三次已經解決了,因此若是次數更多的話固然是能夠完美解決建立鏈接的問題,可是這已是一種浪費了.

爲何揮手是四次?
由於TCP是全雙工的數據傳輸服務(數據能夠在兩個方向上傳輸)就算此時(1)客戶端->服務端,我已經發送完請求的數據了,(2)服務端->客戶端,我知道了,可是此時收到確認的客戶端並不會執行關閉鏈接的操做,由於就算此時客戶端已經不會在發送請求的數據了,可是這個時候服務端仍是會向客戶端發送相應的數據,只有當(3)服務端->客戶端,我全部相應的數據也已經發送完畢了,收到確認的(4)客戶端->服務端,我知道你沒有數據給我了,再等待2MSL以後客戶端關閉鏈接,而此時收到確認的服務端就會關閉鏈接了

在斷開鏈接的時候要等2MSL是爲何?

• 是爲了保證客戶端發送的最後一次的確承認以到達服務端(由於此次確認有可能會丟失),對於服務端來講在服務端->客戶端,我已經沒有相應的數據給你了以後,若是沒有收到服務端的確認們就會一直的發送這個確認,延時2MSL是爲了能夠在這個時間內收到服務端的重傳,接着給出迴應,在從新計時
• 當出現這2MSL時其實客戶端已經確認了知道服務端沒有數據在傳輸過來了,準備關閉鏈接了,那在這個世間內能夠清除全部本次鏈接內所產生的報文段,這樣新的請求不會出如今舊的請求報文中

1、網絡協議分層--經典五層模型

各層做用請參見

• 物理層：定義物理設備之間如何傳輸數據
• 數據鏈路層：在通訊的實體間創建數據鏈路連接
• 網絡層：爲數據在節點之間的傳輸建立邏輯鏈路
• 傳輸層：向用戶提供可靠的端到端的服務，傳輸層經過封裝向高層屏蔽了下層數據通訊的細節
• 應用層：爲應用軟件提供了不少服務，構建於tcp協議之上，屏蔽了網絡傳輸相關的細節

2、Http三次握手和四次揮手

前置：

• Http請求是基於Tcp connection這個連接的

• 位碼即tcp標誌位,有6種標示:

  • SYN(synchronous創建聯機) 、
  • ACK(acknowledgement 確認)、
  • PSH(push傳送)FIN(finish結束)、
  • RST(reset重置)、
  • URG(urgent緊急)
  • Sequence number(順序號碼) 
  • Acknowledge number(確認號碼)

（一）三次握手：

• 第一次握手：主機A發送位碼爲syn＝1,隨機產生seq number=1234567的數據包到服務器，主機B由SYN=1知道，A要求創建聯機；
• 第二次握手：主機B收到請求後要確認聯機信息，向A發送ack number=(主機A的seq+1),syn=1,ack=1,隨機產生seq=7654321的包；
• 第三次握手：主機A收到後檢查ack number是否正確，即第一次發送的seq number+1,以及位碼ack是否爲1，若正確，主機A會再發送ack number=(主機B的seq+1),ack=1，主機B收到後確認seq值與ack=1則鏈接創建成功。

注：爲何要採用三次握手，兩次不行嗎？

（二）四次揮手：

• 第一次揮手：TCP發送一個FIN(結束)，用來關閉客戶到服務端的鏈接。
• 第二次揮手：服務端收到這個FIN，他發回一個ACK(確認)，確認收到序號爲收到序號+1，和SYN同樣，一個FIN將佔用一個序號。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候處於半關閉狀態，即客戶端已經沒有數據要發送了，可是服務器若發送數據，客戶端依然要接受。（服務器端繼續發送未發送完的數據）
• 第三次揮手：服務端發送一個FIN(結束)到客戶端，服務端關閉客戶端的鏈接。
• 第四次揮手：客戶端發送ACK(確認)報文確認，並將確認的序號+1，這樣關閉完成。

注：一、那麼爲何是4次揮手呢？tcp握手的時候爲什麼ACK(確認)和SYN(創建鏈接)是一塊兒發送。揮手的時候爲何是分開的時候發送呢？

由於當Server端收到Client端的SYN鏈接請求報文後，能夠直接發送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。可是關閉鏈接時，當Server端收到FIN報文時，極可能並不會當即關閉 SOCKET，因此只能先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了"。只有等到我Server端全部的報文都發送完了，我才能發送FIN報文，所以不能一塊兒發送。故須要四步握手。

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

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

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

3、TCP和UDP的區別  

一、TCP面向鏈接（如打電話要先撥號創建鏈接）；UDP是無鏈接的，即發送數據以前不須要創建鏈接  

（鏈接和無鏈接）

二、TCP提供可靠的服務。即經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;

     UDP盡最大努力交付，即不保證可靠交付

（可靠和不可靠）

三、TCP面向字節流，其實是TCP把數據當作一連串無結構的字節流；UDP是面向報文的

    UDP沒有擁塞控制，所以網絡出現擁塞不會使源主機的發送速率下降（對實時應用頗有用，如IP電話，實時視頻會議等）

（字節流和報文加擁塞）

四、每一條TCP鏈接只能是點到點的; UDP支持一對一，一對多，多對一和多對多的交互通訊

（一對一和一對多）

五、TCP首部開銷20字節;UDP的首部開銷小，只有8個字節

（開銷問題）

六、TCP的邏輯通訊信道是全雙工的可靠信道，UDP則是不可靠信道

簡單再瞭解

一、簡單快速：客戶向服務器請求服務時，只需傳送請求方法和路徑。請求方法經常使用的有GET、HEAD、POST。每種方法規定了客戶與服務器聯繫的類型不一樣。因爲HTTP協議簡單，使得HTTP服務器的程序規模小，於是通訊速度很快。

二、靈活：HTTP容許傳輸任意類型的數據對象。正在傳輸的類型由Content-Type加以標記。

3.無鏈接：無鏈接的含義是限制每次鏈接只處理一個請求。服務器處理完客戶的請求，並收到客戶的應答後，即斷開鏈接。採用這種方式能夠節省傳輸時間。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺乏狀態意味着若是後續處理須要前面的信息，則它必須重傳，這樣可能致使每次鏈接傳送的數據量增大。另外一方面，在服務器不須要先前信息時它的應答就較快。

五、支持B/S及C/S模式。

參考：http://www.cnblogs.com/ranyon...

          https://www.cnblogs.com/qdhxh...

         https://blog.csdn.net/qq_18425655/article/details/52163228

         https://blog.csdn.net/qzcsu/a...

        https://blog.csdn.net/yanxinr...