C++服務端面試準備（5）網絡協議相關

聲明：本文內容純屬博主本身查找和概括的我的所需的知識點，僅做參考，若有錯誤，博主強烈但願您指出。若是您是某個知識點的原創博主，若有須要，可聯繫本人加上連接。本文內容會根據博主所需進行更新，但願你們多多關照。

因爲博主不是計算機專業出身，我的能力有限，本文內容涉及到博主的知識盲區，在這領域不知道須要掌握多少，只是把本身看到的大概概括一下，請見諒。也但願網友們能夠指點指點，謝謝！

網絡層次劃分

TCP/IP 4層模型：應用層、傳輸層、網絡層、網絡接口層
TCP/IP 5層模型：應用層、傳輸層、網絡層、數據鏈路層、物理層
OSI 7層模型：應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層

• 物理層：發送高低電壓即電信號
• 數據鏈路層：電信號分組，以太網協議，單位爲幀
• 網絡層：對子網間的數據包進行路由選擇，IP協議，單位爲IP數據報
• 傳輸層：負責端到端的可靠數據傳輸，網關，TCP協議和UDP協議
• 會話層：進程間的會話
• 表示層：數據的加密、壓縮、格式轉換等
• 應用層：應用程序

以太網數據包

       以太網數據包的頭爲14字節，包括源地址、目標地址、數據類型，尾4字節。

       數據部分最短46字節，最長1500字節，這個大小稱爲MTU（最長傳輸單元），內容爲IP數據報，報頭佔20字節。所以以太網包最短64字節，最長1518字節

       數據部分超過MTU就分片發送，分片需包含IP頭和TCP/UDP頭

       以TCP爲例，以太網數據包數據部分有2000字節，包含IP頭20字節，TCP頭20字節（UDP8字節），以及應用數據1960字節，須要作分片操做，第一部分1500字節，包含IP頭20字節，TCP頭20字節，應用數據1460字節（這個值稱爲最大報文段長度MSS），第二部分540字節，包含IP頭20字節，TCP頭20字節，應用數據500字節

       另外，1492的MTU值的來源，是由於PPPoE協議。PPP協議是寬帶運營商用於對用戶認證計費的（TCP/IP以太網無此功能）。PPPoE頭尾一共8字節，因此有效載荷MTU變小了，原來有1500字節，如今只剩1492

TCP協議和UDP協議

       TCP傳輸控制協議協議是是一種面向鏈接的、可靠的、基於字節流的傳輸層通訊協議。

       TCP/IP協議是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。通俗而言：TCP負責發現傳輸的問題，一有問題就發出信號，要求從新傳輸，直到全部數據安全正確地傳輸到目的地。而IP是給因特網的每一臺聯網設備規定一個地址。

       UDP用戶數據報協議，是面向無鏈接的通信協議，因爲通信不須要鏈接，因此能夠實現廣播發送。UDP通信時不須要接收方確認，屬於不可靠的傳輸，可能會出現丟包現象，實際應用中要求程序員編程驗證（例如模擬TCP的鏈接和斷開，要保證數據的有效性、有序性）。

       TCP 與 UDP 的區別：TCP是面向鏈接的，可靠的字節流服務；UDP是面向無鏈接的，不可靠的數據報服務。

三次握手和四次揮手

三次握手：

• 客戶端發送SYN報文給服務端，進入SYN-SEND狀態；
• 服務端收到SYN報文後發送SYN+ACK報文給客戶端，進入SYN-RCVD狀態；
• 客戶端收到SYN+ACK報文後發送ACK報文給服務端，雙方進入ESTABLISED狀態

四次揮手：

• 客戶端發送FIN報文給服務端，進入FIN_WAIT-1狀態；
• 服務端收到FIN報文，發送ACK報文，繼續回覆完客戶端前面的事務，進入CLOSE-WAIT，客戶端收到ACK報文後進入FIN-WAIT-2狀態，接收服務端剩下的回覆；
• 服務端也發送FIN報文給客戶端，進入LAST-ACK狀態；
• 客戶端收到FIN報文後發送ACK報文給服務端，進入TIME-WAIT狀態，若是服務端沒有收到ACK報文則能夠重傳FIN報文，服務端收到ACK報文後關閉服務

爲何3次握手

       假設改成兩次握手，client端發送的一個鏈接請求在服務器滯留了，因爲鏈接超時client端會放棄，這個鏈接請求是無效的，但等到服務器收到這個無效的請求，服務器仍是會繼續認爲client想要創建一個新的鏈接，因而就創建鏈接了，服務器此時會一直等client端發數據，這樣就浪費掉不少server端的資源

爲何4次揮手

       若是客戶端在收到服務器給它的斷開鏈接的請求以後，迴應完服務器就直接斷開鏈接的話，若是由於一些緣由，服務器沒有收到迴應，會覺得客戶端還沒關閉，這樣服務器就會一直開着。因此客戶端要等待兩個最長報文段壽命的時間，以便於服務器沒有收到請求以後從新發送請求。
       在釋放鏈接的過程當中會有一些無效的滯留報文，這些報文在通過2MSL的時間內就能夠發送到目的地，不會滯留在網絡中。這樣就能夠避免在下一個鏈接中出現上一個鏈接的滯留報文了

Socket通訊流程

• 服務端這邊首先建立一個Socket（Socket()），而後綁定IP地址和端口號（Bind()），以後註冊監聽（Listen()），這樣服務端就能夠監聽指定的Socket地址了；
• 客戶端這邊也建立一個Socket（Socket()）並打開，而後根據服務器IP地址和端口號向服務器Socket發送鏈接請求（Connect()）；
• 服務器Socket監聽到客戶端Socket發來的鏈接請求以後，被動打開，並調用Accept()函數接收請求，這樣客戶端和服務器之間的鏈接就創建好了；
• 成功創建鏈接以後客戶端和服務器就能夠進行數據交互（Receive()、Send()）；
• 交互完以後，各自關閉鏈接（Close()），交互結束。

擁塞控制

       參考：TCP慢啓動、擁塞避免、快速重傳、快速恢復

       背景：爲了防止網絡的擁塞現象，TCP提出了一系列的擁塞控制機制。最初由V. Jacobson在1988年的論文中提出的TCP的擁塞控制由「慢啓動(Slow start)」和「擁塞避免(Congestion avoidance)」組成，後來TCP Reno版本中又針對性的加入了「快速重傳(Fast retransmit)」、「快速恢復(Fast Recovery)」算法，再後來在TCP NewReno中又對「快速恢復」算法進行了改進，近些年又出現了選擇性應答( selective acknowledgement,SACK)算法，還有其餘方面的大大小小的改進，成爲網絡研究的一個熱點

       TCP的擁塞控制主要原理依賴於一個擁塞窗口(cwnd)來控制，還有一個對端的接收窗口(rwnd)用於流量控制。所以TCP的真正的發送窗口=min(rwnd, cwnd)。可是rwnd是由對端肯定的，網絡環境對其沒有影響，因此在考慮擁塞的時候咱們通常不考慮rwnd的值，咱們暫時只討論如何肯定cwnd值的大小。

       關於cwnd的單位，在TCP中是以字節來作單位的，假設TCP每次傳輸都按照MSS大小來發送數據，則能夠認爲cwnd按照數據包個數來作單位，因此有時咱們說cwnd增長1也就是至關於字節數增長1個MSS大小。

慢啓動
       當新建鏈接時，cwnd初始化爲1個最大報文段(MSS)大小，發送端開始按照擁塞窗口大小發送數據，每當有一個報文段被確認，cwnd就增長1個MSS大小。這樣cwnd的值就隨着網絡往返時間(RTT)呈指數級增加，事實上，慢啓動的速度一點也不慢，只是它的起點比較低一點而已。咱們能夠簡單計算下：

       開始 ---> cwnd = 1
       通過1個RTT後 ---> cwnd = 2 * 1 = 2
       通過2個RTT後 ---> cwnd = 2 * 2 = 4
       通過3個RTT後 ---> cwnd = 4 * 2 = 8

       若是帶寬爲W，那麼通過RTT*log2W時間就能夠佔滿帶寬

擁塞避免
       從慢啓動能夠看到，cwnd能夠很快的增加上來，從而最大程度利用網絡帶寬資源，可是cwnd不能一直這樣無限增加下去，必定須要某個限制。TCP使用了一個叫慢啓動門限(ssthresh)的變量，當cwnd超過該值後，慢啓動過程結束，進入擁塞避免階段。對於大多數TCP實現來講，ssthresh的值是65536(一樣以字節計算)。擁塞避免的主要思想是加法增大，也就是cwnd的值再也不指數級往上升，開始加法增長。此時當窗口中全部的報文段都被確認時，cwnd的大小加1，cwnd的值就隨着RTT開始線性增長，這樣就能夠避免增加過快致使網絡擁塞，慢慢的增長調整到網絡的最佳值。

       擁塞現象的斷定：TCP對每個報文段都有一個定時器，稱爲重傳定時器(RTO)，當RTO超時且尚未獲得數據確認，那麼TCP就會對該報文段進行重傳。當發生超時時，出現擁塞的可能性就很大，某個報文段可能在網絡中某處丟失，而且後續的報文段也沒有了消息，在這種狀況下，TCP反應比較「強烈」：

       1.把ssthresh下降爲cwnd值的一半
       2.把cwnd從新設置爲1
       3.從新進入慢啓動過程

       從總體上來說，TCP擁塞控制窗口變化的原則是AIMD原則，即加法增大、乘法減少

快速重傳
       其實TCP還有一種狀況會進行重傳：那就是收到3個相同的ACK。TCP在收到亂序到達包時就會當即發送ACK，TCP利用3個相同的ACK來斷定數據包的丟失，此時進行快速重傳，快速重傳作的事情有：

       1.把ssthresh設置爲cwnd的一半
       2.把cwnd再設置爲ssthresh的值(具體實現有些爲ssthresh+3)
       3.從新進入擁塞避免階段

快速恢復
       後來的「快速恢復」算法是在上述的「快速重傳」算法後添加的，當收到3個重複ACK時，TCP最後進入的不是擁塞避免階段，而是快速恢復階段。快速重傳和快速恢復算法通常同時使用。

       快速恢復的思想是「數據包守恆」原則，即同一個時刻在網絡中的數據包數量是恆定的，只有當「老」數據包離開了網絡後，才能向網絡中發送一個「新」的數據包，若是發送方收到一個重複的ACK，那麼根據TCP的ACK機制就代表有一個數據包離開了網絡，因而cwnd加1。若是可以嚴格按照該原則那麼網絡中不多會發生擁塞，事實上擁塞控制的目的也就在修正違反該原則的地方。

       具體來講快速恢復的主要步驟是：

       1.當收到3個重複ACK時，把ssthresh設置爲cwnd的一半，把cwnd設置爲ssthresh的值加3，而後重傳丟失的報文段。（加3的緣由是由於收到3個重複的ACK，代表有3個「老」的數據包離開了網絡）
       2.若是再收到一樣的重複的ACK，擁塞窗口就再增長1，但ssthresh的值不變，若是是新的重複的ACK，則到達3個又重複第一步的動做。
       3.當收到新的數據包的ACK時，把cwnd設置爲第一步中的ssthresh的值。（緣由是由於該ACK確認了新的數據，說明從重複ACK時的數據都已收到，該恢復過程已經結束，能夠回到恢復以前的狀態了，也即再次進入擁塞避免狀態）

       然而在實際中，一個重傳超時可能致使許多的數據包的重傳，當多個數據包從一個數據窗口中丟失時而且觸發快速重傳和快速恢復算法時，問題就產生了。

       所以NewReno出現了，它在Reno快速恢復的基礎上稍加了修改，能夠恢復一個窗口內多個包丟失的狀況。具體來說就是：Reno在收到一個新的數據的ACK時就退出了快速恢復狀態了，而NewReno須要收到該窗口內全部數據包的確認後纔會退出快速恢復狀態，從而更一步提升吞吐量

選擇性應答(SACK)算法
       SACK就是改變TCP的確認機制，最初的TCP只確認當前已連續收到的數據，SACK則把亂序等信息會所有告訴對方，從而減小數據發送方重傳的盲目性。

       例如，序號1，2，3，5，7的數據收到了，普通的ACK只會確認序列號4，而SACK會把當前的5，7已經收到的信息在SACK選項裏面告知對端，對端就能直接重發序號4和6的數據，不用再在序號6的數據上花時間，從而提升性能。

       當使用SACK的時候，NewReno算法能夠不使用，由於SACK自己攜帶的信息就可使得發送方有足夠的信息來知道須要重傳哪些包，而不須要重傳哪些包。

HTTP(可選)

       超文本傳輸協議HTTP是互聯網上應用最爲普遍的一種網絡協議。全部的WWW文件都必須遵照這個標準。

請求包
       當瀏覽器向Web服務器發出請求時，它向服務器傳遞了一個數據塊，也就是請求信息，HTTP請求信息由3部分組成：

l 請求方法URI協議/版本
l 請求頭(Request Header)

l 請求正文

       下面是一個HTTP請求的例子：

GET/sample.jspHTTP/1.1
Accept:image/gif.image/jpeg,/
Accept-Language:zh-cn
Connection:Keep-Alive
Host:localhost
User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0)
Accept-Encoding:gzip,deflate

username=jinqiao&password=1234

HTTP 協議包括的請求：

• GET：請求讀取由URL所標誌的信息。
• POST：給服務器添加信息（如註釋）。

（Get是從服務器上獲取數據，Post是向服務器傳送數據）

• PUT：在給定的URL下存儲一個文檔。
• DELETE：刪除給定的URL所標誌的資源。
• HEAD：相似於 GET 請求，只不過返回的響應中沒有具體的內容，用於獲取報頭
• CONNECT：HTTP/1.1 協議中預留給可以將鏈接改成管道方式的代理服務器
• OPTIONS：容許客戶端查看服務器的性能。
• TRACE：回顯服務器收到的請求，主要用於測試或診斷。
• PATCH：是對 PUT 方法的補充，用來對已知資源進行局部更新 。

       請求頭和響應頭的信息參考：HTTP 請求包和響應包 （網絡篇）

響應包
       HTTP響應也由3個部分構成，分別是：

l　協議狀態版本代碼描述
l　響應頭(Response Header)

l　響應正文

       下面是一個HTTP響應的例子：

HTTP/1.1 200 OK
Server:Apache Tomcat/5.0.12
Date:Mon,6Oct2003 13:23:42 GMT
Content-Length:112

<html>
<head>
<title>HTTP響應示例<title>
</head>
<body>
Hello HTTP!
</body>
</html>

HTTP答應碼：

• 1XX－信息類(Information),表示收到Web瀏覽器請求，正在進一步的處理中
• 2XX－成功類（Successful）,表示用戶請求被正確接收，理解和處理例如：200 OK
• 3XX-重定向類(Redirection),表示請求沒有成功，客戶必須採起進一步的動做。
• 4XX-客戶端錯誤(Client Error)，表示客戶端提交的請求有錯誤 例如：404 NOT Found，意味着請求中所引用的文檔不存在。
• 5XX-服務器錯誤(Server Error)表示服務器不能完成對請求的處理：如 500

其餘

       想實現網絡通訊，每臺主機需具有四要素：本機的IP地址、子網掩碼、網關的IP地址、DNS的IP地址

獲取這四要素分兩種方式：
       1.靜態獲取 即手動配置
       2.動態獲取 經過dhcp獲取

       DHCP（動態主機配置協議）是一個局域網的網絡協議。指的是由服務器控制一段lP地址範圍，客戶機登陸服務器時就能夠自動得到服務器分配的lP地址和子網掩碼。