網絡相關

1.TCP和UDP的區別

　TCP的優勢： 可靠，穩定 TCP的可靠體如今TCP在傳遞數據以前，會有三次握手來創建鏈接，並且在數據傳遞時，有確認、窗口、重傳、擁塞控制機制，在數據傳完後，還會斷開鏈接用來節約系統資源。 TCP的缺點： 慢，效率低，佔用系統資源高，易被攻擊 TCP在傳遞數據以前，要先建鏈接，這會消耗時間，並且在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，並且要在每臺設備上維護全部的傳輸鏈接，事實上，每一個鏈接都會佔用系統的CPU、內存等硬件資源。 並且，由於TCP有確認機制、三次握手機制，這些也致使TCP容易被人利用，實現DOS、DDOS、CC等攻擊。

　　UDP的優勢： 快，比TCP稍安全 UDP沒有TCP的握手、確認、窗口、重傳、擁塞控制等機制，UDP是一個無狀態的傳輸協議，因此它在傳遞數據時很是快。沒有TCP的這些機制，UDP較TCP被攻擊者利用的漏洞就要少一些。但UDP也是沒法避免攻擊的，好比：UDP Flood攻擊…… UDP的缺點： 不可靠，不穩定 由於UDP沒有TCP那些可靠的機制，在數據傳遞時，若是網絡質量很差，就會很容易丟包。 基於上面的優缺點，那麼： 何時應該使用TCP： 當對網絡通信質量有要求的時候，好比：整個數據要準確無誤的傳遞給對方，這每每用於一些要求可靠的應用，好比HTTP、HTTPS、FTP等傳輸文件的協議，POP、SMTP等郵件傳輸的協議。 在平常生活中，常見使用TCP協議的應用以下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件傳輸 ………… 何時應該使用UDP： 當對網絡通信質量要求不高的時候，要求網絡通信速度能儘可能的快，這時就可使用UDP。 好比，平常生活中，常見使用UDP協議的應用以下： QQ語音 QQ視頻 TFTP ……

　　

TCP與UDP區別總結：

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

二、TCP提供可靠的服務。也就是說，經過TCP鏈接傳送的數據，無差錯，不丟失，不重複，且按序到達;UDP盡最大努力交付，即不保證可靠交付

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

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

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

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

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

 2.TCP爲何鏈接的時候是三次握手，關閉的時候倒是四次握手？

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

3.爲何TIME_WAIT狀態須要通過2MSL(最大報文段生存時間)才能返回到CLOSE狀態？

　　這是由於雖然雙方都贊成關閉鏈接了，並且握手的4個報文也都協調和發送完畢，按理能夠直接回到CLOSED狀態（就比如從SYN_SEND狀態到ESTABLISH狀態那樣）；可是由於咱們必需要假想網絡是不可靠的，你沒法保證你最後發送的ACK報文會必定被對方收到，所以對方處於LAST_ACK狀態下的SOCKET可能會由於超時未收到ACK報文，而重發FIN報文，因此這個TIME_WAIT狀態的做用就是用來重發可能丟失的ACK報文。

4.TCP三次握手和四次揮手，及TCP協議端口狀態說明

　　

 

　　第一次握手：創建鏈接時，客戶端發送SYN包（syn=j）到服務器，並進入SYN_SENT狀態，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）

　　第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時本身也發送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態；

　　第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1），此包發送完畢，客戶端和服務器進入ESTABLISHED（TCP鏈接成功）狀態，完成三次握手。

　　因爲TCP鏈接是全雙工的，所以每一個方向都必須單獨進行關閉。這原則是當一方完成它的數據發送任務後就能發送一個FIN來終止這個方向的鏈接。收到一個 FIN只意味着這一方向上沒有數據流動，一個TCP鏈接在收到一個FIN後仍能發送數據。首先進行關閉的一方將執行主動關閉，而另外一方執行被動關閉。

　　（1） TCP客戶端發送一個FIN，用來關閉客戶到服務器的數據傳送，表示我這邊沒有數據傳輸了。 狀態進入FIN_WAIT1

　　（2） 服務器收到這個FIN，它發回一個ACK，確認序號爲收到的序號加1。和SYN同樣，一個FIN將佔用一個序號。狀態進入CLOSE_WAIT

　　（3） 服務器關閉客戶端的鏈接，發送一個FIN給客戶端。 狀態進入LAST_ACK

　　（4） 客戶端發回ACK報文確認，並將確認序號設置爲收到序號加1 狀態進入 TIME_WAIT，2MSL後進入CLOSED

　　（5）服務端收到ACK報文並確認，進入CLOSE

　　CLOSED: 這個沒什麼好說的了，表示初始狀態。 
　　LISTEN: 這個也是很是容易理解的一個狀態，表示服務器端的某個SOCKET處於監聽狀態，能夠接受鏈接了。 
　　SYN_RECV: 這個狀態表示接受到了SYN報文，在正常狀況下，這個狀態是服務器端的SOCKET在創建TCP鏈接時的三次握手會話過程當中的一箇中間狀態，很短暫，基本 上用netstat你是很難看到這種狀態的，除非你特地寫了一個客戶端測試程序，故意將三次TCP握手過程當中最後一個ACK報文不予發送。所以這種狀態 時，當收到客戶端的ACK報文後，它會進入到ESTABLISHED狀態。 
　　SYN_SENT: 這個狀態與SYN_RECV遙想呼應，當客戶端SOCKET執行CONNECT鏈接時，它首先發送SYN報文，所以也隨即它會進入到了SYN_SENT狀 態，並等待服務端的發送三次握手中的第2個報文。　　SYN_SENT狀態表示客戶端已發送SYN報文。 
　　ESTABLISHED：這個容易理解了，表示鏈接已經創建了。

　　FIN_WAIT_1: 這個狀態要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態的真正含義都是表示等待對方的FIN報文。而這兩種狀態的區別 是：FIN_WAIT_1狀態其實是當SOCKET在ESTABLISHED狀態時，它想主動關閉鏈接，向對方發送了FIN報文，此時該SOCKET即 進入到FIN_WAIT_1狀態。而當對方迴應ACK報文後，則進入到FIN_WAIT_2狀態，固然在實際的正常狀況下，不管對方何種狀況下，都應該馬 上回應ACK報文，因此FIN_WAIT_1狀態通常是比較難見到的，而FIN_WAIT_2狀態還有時經常能夠用netstat看到。 
　　FIN_WAIT_2：上面已經詳細解釋了這種狀態，實際上FIN_WAIT_2狀態下的SOCKET，表示半鏈接，也即有一方要求close鏈接，但另外還告訴對方，我暫時還有點數據須要傳送給你，稍後再關閉鏈接。 
　　TIME_WAIT: 表示收到了對方的FIN報文，併發送出了ACK報文，就等2MSL後便可回到CLOSED可用狀態了。若是FIN_WAIT_1狀態下，收到了對方同時帶 FIN標誌和ACK標誌的報文時，能夠直接進入到TIME_WAIT狀態，而無須通過FIN_WAIT_2狀態。 
　　CLOSING: 這種狀態比較特殊，實際狀況中應該是不多見，屬於一種比較罕見的例外狀態。正常狀況下，當你發送FIN報文後，按理來講是應該先收到（或同時收到）對方的 ACK報文，再收到對方的FIN報文。可是CLOSING狀態表示你發送FIN報文後，並無收到對方的ACK報文，反而卻也收到了對方的FIN報文。什 麼狀況下會出現此種狀況呢？其實細想一下，也不可貴出結論：那就是若是雙方几乎在同時close一個SOCKET的話，那麼就出現了雙方同時發送FIN報 文的狀況，也即會出現CLOSING狀態，表示雙方都正在關閉SOCKET鏈接。 
　　CLOSE_WAIT: 這種狀態的含義實際上是表示在等待關閉。怎麼理解呢？當對方close一個SOCKET後發送FIN報文給本身，你係統毫無疑問地會迴應一個ACK報文給對 方，此時則進入到CLOSE_WAIT狀態。接下來呢，實際上你真正須要考慮的事情是察看你是否還有數據發送給對方，若是沒有的話，那麼你也就能夠 close這個SOCKET，發送FIN報文給對方，也即關閉鏈接。因此你在CLOSE_WAIT狀態下，須要完成的事情是等待你去關閉鏈接。 
　　LAST_ACK: 這個狀態仍是比較容易好理解的，它是被動關閉一方在發送FIN報文後，最後等待對方的ACK報文。當收到ACK報文後，也便可以進入到CLOSED可用狀態了。

5.擁塞控制與流量控制的區別 

　　擁塞控制是防止過多的數據注入到網絡中，可使網絡中的路由器或鏈路不致過載，是一個全局性的過程。 
　　流量控制是點對點通訊量的控制，是一個端到端的問題，主要就是抑制發送端發送數據的速率，以便接收端來得及接收。

6.慢開始與擁塞避免

　　慢開始：

　　　　1.慢開始不是指cwnd的增加速度慢（指數增加），而是指TCP開始發送設置cwnd=1。
　　　　2.思路：不要一開始就發送大量的數據，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增長擁塞窗口的大小。這裏用報文段的個數的擁塞窗口大小舉例說明慢開始算法，實時擁塞窗口大小是以字節爲單位的。以下圖：

　　　　

　　　　3.爲了防止cwnd增加過大引發網絡擁塞，設置一個慢開始門限（ssthresh狀態變量） 
　　　　當cnwd＜ssthresh，使用慢開始算法 
　　　　當cnwd=ssthresh，既可以使用慢開始算法，也可使用擁塞避免算法 
　　　　當cnwd＞ssthresh，使用擁塞避免算法

　　　擁塞避免:

　　　　1.擁塞避免並不是徹底可以避免擁塞，是說在擁塞避免階段將擁塞窗口控制爲按線性規律增加，使網絡比較不容易出現擁塞。 
　　　　2.思路：讓擁塞窗口cwnd緩慢地增大，即每通過一個往返時間RTT就把發送方的擁塞控制窗口加一。

　　不管是在慢開始階段仍是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認，雖然沒有收到確承認能是其餘緣由的分組丟失，可是由於沒法斷定，因此都當作擁塞來處理），就把慢開始門限設置爲出現擁塞時的發送窗口大小的一半。而後把擁塞窗口設置爲1，執行慢開始算法。 

　　

7.快重傳與快恢復

　　　快重傳:

　　　　1.快重傳要求接收方在收到一個失序的報文段後就當即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到本身發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當當即重傳對方還沒有收到的報文段，而沒必要繼續等待設置的重傳計時器時間到期。 

　　

　　　　2.因爲不須要等待設置的重傳計時器到期，能儘早重傳未被確認的報文段，能提升整個網絡的吞吐量

　　

　　快恢復（與快重傳配合使用）：

　　　　1.採用快恢復算法時，慢開始只在TCP鏈接創建時和網絡出現超時時才使用。 　　　　2.當發送方連續收到三個重複確認時，就執行「乘法減少」算法，把ssthresh門限減半。可是接下去並不執行慢開始算法。 　　　　3.考慮到若是網絡出現擁塞的話就不會收到好幾個重複的確認，因此發送方如今認爲網絡可能沒有出現擁塞。因此此時不執行慢開始算法，而是將cwnd設置爲ssthresh的大小，而後執行擁塞避免算法。