TCP总结
TCP這些東西，基本每個程序猿都或多或少是掌握的了。雖然感覺在實際開發中沒有什么用武之處，但，面試他要問啊
?
?
?
而最近大家伙過完年，也都在準備春招，我也一樣。閱讀了一些okHttp源碼之后，又屁顛屁顛地跑回來重新把tcp、http這些東西給重新學了一遍。okHttp基本都是這些協議的實現，而理解源碼的基礎是，理解tcp、http。
?
重新看了一遍tcp之后，我把這些東西給總結了下來，也就有了這篇文章。
?
計算機網絡的知識特點就是：瑣碎?？勘痴b“面試八股文”估計沒多久就忘了。TCP是計算機網絡運輸層的一個協議，所以首先要對計網分層結構以及運輸層有一定的理解。然后是TCP的四個重點：面向連接、可靠傳輸原理、流量控制和擁塞控制，最后再補充一點粘包和拆包的知識。
?
/? ?計網分層結構? ?/
?
考慮最簡單的情況：兩臺主機之間的通信。這個時候只需要一條網線把兩者連起來，規定好彼此的硬件接口，如都用USB、電壓10v、頻率2.4GHz等，這一層就是物理層，這些規定就是物理層協議?。
?
?
我們當然不滿足于只有兩臺電腦連接，因此我們可以使用交換機把多個電腦連接起來，如下圖：
?
?
這樣連接起來的網絡，稱為局域網，也可以稱為以太網（以太網是局域網的一種）。在這個網絡中，我們需要標識每個機器，這樣才可以指定要和哪個機器通信。這個標識就是硬件地址MAC。硬件地址隨機器的生產就被確定，永久性唯一。在局域網中，我們需要和另外的機器通信時，只需要知道他的硬件地址，交換機就會把我們的消息發送到對應的機器。
?
這里我們可以不管底層的網線接口如何發送，把物理層抽離，在他之上創建一個新的層次，這就是數據鏈路層?。
?
我們依然不滿足于局域網的規模，需要把所有的局域網聯系起來，這個時候就需要用到路由器來連接兩個局域網：
?
?
但是如果我們還是使用硬件地址來作為通信對象的唯一標識，那么當網絡規模越來越大，需要記住所有機器的硬件地址是不現實的；同時，一個網絡對象可能會頻繁更換設備，這個時候硬件地址表維護起來更加復雜。這里使用了一個新的地址來標記一個網絡對象：IP地址?。
?
通過一個簡單的寄信例子來理解IP地址。
?
我住在北京市，我朋友A住在上海市，我要給朋友A寫信：
?
寫完信，我會在信上寫好我朋友A的地址，并放到北京市郵局（給信息附加目標IP地址，并發送給路由器）
郵局會幫我把信運輸到上海市當地郵局（信息會經過路由傳遞到目標IP局域網的路由器）
上海市當地路由器會幫我把信交給朋友A（局域網內通信）
?
因此，這里IP地址就是一個網絡接入地址（朋友A的住址），我只需要知道目標IP地址，路由器就可以把消息給我帶到。在局域網中，就可以動態維護一個MAC地址與IP地址的映射關系，根據目的IP地址就可以尋找到機器的MAC地址進行發送?。
?
這樣我們不需管理底層如何去選擇機器，我們只需要知道IP地址，就可以和我們的目標進行通信。這一層就是網絡層。網絡層的核心作用就是?提供主機之間的邏輯通信?。這樣，在網絡中的所有主機，在邏輯上都連接起來了，上層只需要提供目標IP地址和數據，網絡層就可以把消息發送到對應的主機。
?
一個主機有多個進程，進程之間進行不同的網絡通信，如邊和朋友開黑邊和女朋友聊微信。我的手機同時和兩個不同機器進行通信。那么當我的手機收到數據時，如何區分是微信的數據，還是王者的數據？那么就必須在網絡層之上再添加一層：運輸層?：
?
?
?
運輸層通過socket（套接字），將網絡信息進行進一步的拆分，不同的應用進程可以獨立進行網絡請求，互不干擾。這就是運輸層的最本質特點：提供進程之間的邏輯通信?。這里的進程可以是主機之間，也可以是同個主機，所以在android中，socket通信也是進程通信的一種方式。
?
現在不同的機器上的應用進程之間可以獨立通信了，那么我們就可以在計算機網絡上開發出形形式式的應用：如web網頁的http，文件傳輸ftp等等。這一層稱為應用層。
?
應用層還可以進一步拆分出表示層、會話層，但他們的本質特點都沒有改變：完成具體的業務需求?。和下面的四層相比，他們并不是必須的，可以歸屬到應用層中。
?
最后對計網分層進行小結：
?
?
最底層物理層，負責兩個機器之間通過硬件的直接通信；
數據鏈路層使用硬件地址在局域網中進行尋址，實現局域網通信；
網絡層通過抽象IP地址實現主機之間的邏輯通信；
運輸層在網絡層的基礎上，對數據進行拆分，實現應用進程的獨立網絡通信；
應用層在運輸層的基礎上，根據具體的需求開發形形式式的功能。
?
這里需要注意的是，分層并不是在物理上的分層，而是邏輯上的分層。通過對底層邏輯的封裝，使得上層的開發可以直接依賴底層的功能而無需理會具體的實現，簡便了開發。
?
這種分層的思路，也就是責任鏈設計模式，通過層層封裝，把不同的職責獨立起來，更加方便開發、維護等等。okHttp中的攔截器設計模式，也是這種責任鏈模式。
?
/? ?運輸層? ?/
?
本文主要是講解TCP，這里需要增加一些運輸層的知識。
?
本質：提供進程通信
?
?
在運輸層之下的網絡層，是不知道該數據包屬于哪個進程，他只負責數據包的接收與發送。運輸層則負責接收不同進程的數據交給網絡層，同時把網絡層的數據拆分交給不同的進程。從上往下匯聚到網絡層，稱為多路復用，從下往上拆分，稱為多路拆分?。
?
運輸層的表現，受網絡層的限制。這很好理解，網絡層是運輸層的底層支持。所以運輸層是無法決定自己帶寬、時延等的上限。但可以基于網絡層開發更多的特性：如可靠傳輸。網絡層只負責盡力把數據包從一端發送到另一端，而不保證數據可以到達且完整。
?
底層實現：socket
?
前面講到，最簡單的運輸層協議，就是提供進程之間的獨立通信 ，但底層的實現，是socket之間的獨立通信?。在網絡層中，IP地址是一個主機邏輯地址，而在運輸層中，socket是一個進程的邏輯地址；當然，一個進程可以擁有多個socket。應用進程可以通過監聽socket，來獲取這個socket接受到的消息。
?
?
socket并不是一個實實在在的東西，而是運輸層抽象出來的一個對象。運輸層增加了端口這個概念，來區分不同的socket。端口可以理解為一個主機上有很多的網絡通信口，每個端口都有一個端口號，端口的數量由運輸層協議確定。
?
不同的運輸層協議對socket有不同的定義方式。在UDP協議中，使用目標IP+目標端口號來定義一個socket；在TCP中使用目標IP+目標端口號+源IP+源端口號來定義一個socket。我們只需要在運輸層報文的頭部附加上這些信息，目標主機就會知道我們要發送給哪個socket，對應監聽該socket的進程就可獲得信息。
?
運輸層協議
?
運輸層的協議就是大名鼎鼎的TCP和UDP。其中，UDP是最精簡的運輸層協議，只實現了進程間的通信；而TCP在UDP的基礎上，實現了可靠傳輸、流量控制、擁塞控制、面向連接等等特性，同時也更加復雜。
?
當然除此之外，還有更多更優秀的運輸層協議，但目前廣為使用的，就是TCP和UDP。UDP在后面也會總結到。
?
/? ?TCP協議首部? ?/
?
TCP協議，表現在報文上，就是會在應用層傳輸下來的數據前附加上一個TCP首部，這個首部附加了TCP信息，先來整體看一下這個首部的結構：
?
?
這張圖是來自我大學老師的課件， 非常好用，所以一直拿來學習。最下面部分表示了報文之間的關系，TCP數據部分就是應用層傳下來的數據。
?
TCP首部固定長度是20字節，下面還有4字節是可選的。內容很多，但其中有一些我們比較熟悉的：源端口，目標端口。嗯？socket不是還需要IP進行定位嗎？IP地址在網絡層被附加了。其他的內容后面都會慢慢講解，作為一篇總結文章，這里放出查閱表，方便復習：
?
?
選項字段中包含以下其他選項：
?
?
講完下面內容，再回來看這些字段就熟悉了。
?
/? ?TCP面向字節流特性? ?/
?
TCP并不是把應用層傳輸過來的數據直接加上首部然后發送給目標，而是把數據看成一個字節?流，給他們標上序號之后分部分發送。這就是TCP的?面向字節流?特性：
?
?
-
TCP會以流的形式從應用層讀取數據并存放在自己的發送緩存區中，同時為這些字節標上序號
-
TCP會從發送方緩沖區選擇適量的字節組成TCP報文，通過網絡層發送給目標
-
目標會讀取字節并存放在自己的接收方緩沖區中，并在合適的時候交付給應用層
?
面向字節流的好處是無需一次存儲過大的數據占用太多內存，壞處是無法知道這些字節代表的意義，例如應用層發送一個音頻文件和一個文本文件，對于TCP來說就是一串字節流，沒有意義可言，這會導致粘包以及拆包問題，后面講。
?
/? ?可靠傳輸原理? ?/
?
前面講到，TCP是可靠傳輸協議，也就是，一個數據交給他，他肯定可以完整無誤地發送到目標地址，除非網絡炸了。他實現的網絡模型如下：
?
?
對于應用層來說，他就是一個可靠傳輸的底層支持服務；而運輸層底層采用了網絡層的不可靠傳輸。雖然在網絡層甚至數據鏈路層就可以使用協議來保證數據傳輸的可靠性，但這樣網絡的設計會更加復雜、效率會隨之降低。把數據傳輸的可靠性保證放在運輸層，會更加合適。
?
可靠傳輸原理的重點總結一下有：滑動窗口、超時重傳、累積確認、選擇確認、連續ARQ?。
?
停止等待協議
?
要實現可靠傳輸，最簡便的方法就是：我發送一個數據包給你，然后你跟我回復收到，我繼續發送下一個數據包。傳輸模型如下：
?
?
這種“一來一去”的方法來保證傳輸可靠就是停止等待協議（stop-and-wait）。不知道還記不記得前面TCP首部有一個ack字段，當他設置為1的時候，表示這個報文是一個確認收到報文。
?
然后再來考慮一種情況：丟包。網絡環境不可靠，導致每一次發送的數據包可能會丟失，如果機器A發送了數據包丟失了，那么機器B永遠接收不到數據，機器A永遠在等待。解決這個問題的方法是：超時重傳?。當機器A發出一個數據包時便開始計時，時間到還沒收到確認回復，就可以認為是發生了丟包，便再次發送，也就是重傳。
?
但重傳會導致另一種問題：如果原先的數據包并沒有丟失，只是在網絡中待的時間比較久，這個時候機器B會受到兩個數據包，那么機器B是如何辨別這兩個數據包是屬于同一份數據還是不同的數據？這就需要前面講過的方法：給數據字節進行編號。這樣接收方就可以根據數據的字節編號，得出這些數據是接下來的數據，還是重傳的數據。
?
在TCP首部有兩個字段：序號和確認號，他們表示發送方數據第一個字節的編號，和接收方期待的下一份數據的第一個字節的編號。前面講到TCP是面向字節流，但是他并不是一個字節一個字節地發送，而是一次截取一整段。截取的長度受多種因素影響，如緩存區的數據大小、數據鏈路層限制的幀大小等。
?
連續ARQ協議
?
停止等待協議已經可以滿足可靠傳輸了，但有一個致命缺點：效率太低。發送方發送一個數據包之后便進入等待，這個期間并沒有干任何事，浪費了資源。解決的方法是：連續發送數據包。模型如下：
?
?
和停止等待最大的不同就是，他會源源不斷地發送，接收方源源不斷收到數據之后，逐一進行確認回復。這樣便極大地提高了效率。但同樣，帶來了一些額外的問題:
?
發送是否可以無限發送直到把緩沖區所有數據發送完？不可以。因為需要考慮接收方緩沖區以及讀取數據的能力。如果發送太快導致接收方無法接受，那么只是會頻繁進行重傳，浪費了網絡資源。所以發送方發送數據的范圍，需要考慮到接收方緩沖區的情況。這就是TCP的流量控制?。解決方法是：滑動窗口?。基本模型如下：
?
?
-
發送方需要根據接收方的緩沖區大小，設置自己的可發送窗口大小，處于窗口內的數據表示可發送，之外的數據不可發送。
-
當窗口內的數據接收到確認回復時，整個窗口會往前移動，直到發送完成所有的數據
?
在TCP的首部有一個窗口大小字段，他表示接收方的剩余緩沖區大小，讓發送方可以調整自己的發送窗口大小。通過滑動窗口，就可以實現TCP的流量控制，不至于發送太快，導致太多的數據丟失。
?
連續ARQ帶來的第二個問題是：網絡中充斥著和發送數據包一樣數據量的確認回復報文，因為每一個發送數據包，必須得有一個確認回復。提高網絡效率的方法是：累積確認?。接收方不需要逐個進行回復，而是累積到一定量的數據包之后，告訴發送方，在此數據包之前的數據全都收到。例如，收到 1234，接收方只需要告訴發送方我收到4了，那么發送方就知道1234都收到了。
?
第三個問題是：如何處理丟包情況。在停止等待協議中很簡單，直接一個超時重傳就解決了。但，連續ARQ中不太一樣。例如：接收方收到了 123 567，六個字節，編號為4的字節丟失了。按照累積確認的思路，只能發送3的確認回復，567都必須丟掉，因為發送方會進行重傳。這就是GBN（go-back-n)?思路。
?
但是我們會發現，只需要重傳4即可，這樣不是很浪費資源，所以就有了：選擇確認SACK?。在TCP報文的選項字段，可以設置已經收到的報文段，每一個報文段需要兩個邊界來進行確定。這樣發送方，就可以根據這個選項字段只重傳丟失的數據了。
?
可靠傳輸小結
?
到這里關于TCP的可靠傳輸原理就已經介紹的差不多。最后進行一個小結：
?
-
通過連續ARQ協議與發送-確認回復模式來保證每一個數據包都到達接收方
-
通過給字節編號的方法，來標記每一個數據是屬于重傳還是新的數據
-
通過超時重傳的方式，來解決數據包在網絡中丟失的問題
-
通過滑動窗口來實現流量控制
-
通過累積確認+選擇確認的方法來提高確認回復與重傳的效率
?
當然，這只是可靠傳輸的冰山一角，感興趣可以再深入去研究（和面試官聊天已經差不多了[狗頭]）。
?
/? ?擁塞控制? ?/
?
擁塞控制考慮的是另外一個問題：避免網絡過分擁擠導致丟包嚴重，網絡效率降低?。
?
拿現實的交通舉例子：
?
高速公路同一時間可通行的汽車數量是一定的，當節假日時，就會發生嚴重的堵車。在TCP中，數據包超時，會進行重傳，也就是會進來更多的汽車，這時候更堵，最后導致的結果就是：丟包-重傳-丟包-重傳。最后整個網絡癱瘓了。
?
這里的擁塞控制和前面的流量控制不是一個東西，流量控制是擁塞控制的手段：為了避免擁塞，必須對流量進行控制。擁塞控制目的是：限制每個主機的發送的數據量，避免網絡擁塞效率下降。就像廣州等地，限制車牌號出行是一個道理。不然大家都堵在路上，誰都別想走。
?
擁塞控制的解決方法是流量控制，流量控制的實現是滑動窗口，所以擁塞控制最終也是通過限制發送方的滑動窗口大小來限制流量?。當然，擁塞控制的手段不只是流量控制，導致擁塞的因素有：路由器緩存、帶寬、處理器處理速度等等。提升硬件能力（把4車道改成8車道）是其中一個方法，但畢竟硬件提升是有瓶頸的，沒辦法不斷提升，還是需要從tcp本身來增加算法，解決擁塞。
?
擁塞控制的重點有4個：慢開始、快恢復、快重傳、擁塞避免。這里依舊獻祭出大學老師的ppt圖片：
?
?
Y軸表示的是發送方窗口大小，X軸表示的是發送的輪次（不是字節編號）。
?
-
最開始的時候，會把窗口設置一個較小的值，然后每輪變為原來的兩倍。這是慢開始。
-
當窗口值到達ssthresh值，這個值是需要通過實時網絡情況設置的一個窗口限制值，開始進入擁塞避免，每輪把窗口值提升1，慢慢試探網絡的底線。
-
如果發生了數據超時，表示極可能發生了擁塞，然后回到慢開始，重復上面的步驟。
-
如果收到三個相同的確認回復，表示現在網絡的情況不太好，把ssthresh的值設置為原來的一半，繼續擁塞避免。這部分稱為快恢復。
-
如果收到丟包信息，應該盡快把丟失的包重傳一次，這是快重傳。
-
當然，窗口的最終上限是不能無限上漲的，他不能超過接收方的緩存區大小。
?
通過這個算法，就可以在很大程度上，避免網絡擁擠。
?
除此之外，還可以讓路由器在緩存即將滿的時候，告知發送方我快滿了，而不是等到出現了超時再進行處理，這是主動隊列管理AQM。此外還有很多方法，但是上面的算法是重點。
?
/? ?面向連接? ?/
?
這一小節講的就是無人不曉的TCP三次握手與四次揮手這些，經過前面的內容，這一小節其實已經很好理解。
?
TCP是面向連接的，那連接是什么？這里的連接并不是實實在在的連接，而是通信雙方彼此之間的一個記錄?。TCP是一個全雙工通信，也就是可以互相發送數據，所以雙方都需要記錄對方的信息。根據前面的可靠傳輸原理，TCP通信雙方需要為對方準備一個接收緩沖區可以接收對方的數據、記住對方的socket知道怎么發送數據、記住對方的緩沖區來調整自己的窗口大小等等，這些記錄，就是一個連接。
?
在運輸層小節中講到，運輸層雙方通信的地址是采用socket來定義的，TCP也不例外。TCP的每一個連接只能有兩個對象，也就是兩個socket，而不能有三個。所以socket的定義需要源IP、源端口號、目標IP、目標端口號四個關鍵因素，才不會發生混亂。
?
假如TCP和UDP一樣只采用目標IP+目標端口號來定義socket，那么就會出現多個發送方同時發送到同一個目標socket的情況。這個時候TCP無法區分這些數據是否來自不同的發送方，就會導致出現錯誤。
?
既然是連接，就有兩個關鍵要點：建立連接、斷開連接。
?
建立連接
?
建立連接的目的就是交換彼此的信息，然后記住對方的信息。所以雙方都需要發送彼此的信息給對方：
?
?
但前面的可靠傳輸原理告訴我們，數據在網絡中傳輸是不可靠的，需要對方給予我們一個確認回復，才可以保證消息正確到達。如下圖：
?
?
機器B的確認收到和機器B信息可以進行合并，減少次數；而且發送機器B給機器A本身就代表了機器B已經收到了消息，所以最后的示例圖是：
?
?
步驟如下：
?
機器A發送syn包向機器B請求建立TCP連接，并附加上自身的接收緩沖區信息等，機器A進入SYN_SEND狀態，表示請求已經發送正在等待回復；
機器B收到請求之后，根據機器A的信息記錄下來，并創建自身的接收緩存區，向機器A發送syn+ack的合成包，同時自身進入SYN_RECV狀態，表示已經準備好了，等待機器A 的回復就可以向A發送數據；
機器A收到回復之后記錄機器B 的信息，發送ack信息，自身進入ESTABLISHED狀態，表示已經完全準備好了，可以進行發送和接收；
機器B收到ACK數據之后，進入ESTABLISHED狀態。
?
三次消息的發送，稱為三次握手。
?
斷開連接
?
斷開連接和三次握手類似，直接上圖：
?
?
1. 機器A發送完數據之后，向機器B請求斷開連接，自身進入FIN_WAIT_1狀態，表示數據發送完成且已經發送FIN包（FIN標志位為1）；
?
2. 機器B收到FIN包之后，回復ack包表示已經收到，但此時機器B可能還有數據沒發送完成，自身進入CLOSE_WAIT狀態，表示對方已發送完成且請求關閉連接，自身發送完成之后可以關閉連接；
?
3. 機器B數據發送完成之后，發送FIN包給機器B ，自身進入LAST_ACK狀態，表示等待一個ACK包即可關閉連接；
?
4. 機器A收到FIN包之后，知道機器B也發送完成了，回復一個ACK包，并進入TIME_WAIT狀態
?
TIME_WAIT狀態比較特殊。當機器A收到機器B的FIN包時，理想狀態下，確實是可以直接關閉連接了；但是：
我們知道網絡是不穩定的，可能機器B 發送了一些數據還沒到達（比FIN包慢）；
同時回復的ACK包可能丟失了，機器B會重傳FIN包；
如果此時機器A馬上關閉連接，會導致數據不完整、機器B無法釋放連接等問題。所以此時機器A需要等待2個報文生存最大時長，確保網絡中沒有任何遺留報文了，再關閉連接
?
5. 最后，機器A等待兩個報文存活最大時長之后，機器B 接收到ACK報文之后，均關閉連接，進入CLASED狀態
?
雙方之間4次互相發送報文來斷開連接的過程，就是四次揮手。
?
現在，對于為什么握手是三次揮手是四次、一定要三次/四次嗎、為什么要停留2msl再關閉連接等等這些問題，就都解決了。
?
/? ?UDP協議? ?/
?
運輸層協議除了TCP，還有大名鼎鼎的UDP。如果說TCP憑借他完善穩定的功能獨樹一幟，那UDP就是精簡主義亂拳打死老師傅。
?
UDP只實現了運輸層最少的功能：進程間通信。對于應用層傳下來的數據，UDP只是附加一個首部就直接交給網絡層了。UDP的頭部非常簡單，只有三部分：
?
-
源端口、目標端口：端口號用來區分主機的不同進程
-
校驗碼：用于校驗數據包在傳輸的過程中沒有出現錯誤，例如某個1變成了0
-
長度：報文的長度
?
所以UDP的功能也只有兩個：校驗數據報是否發生錯誤、區分不同的進程通信。
但，TCP的功能雖然多，但同時也是要付出相對應的代價。例如面向連接的特性，在建立和斷開連接的時候會有開銷；擁塞控制的特性，會限制傳輸的上限等等。下面來羅列一下UDP的優缺點：
?
UDP的缺點
?
-
無法保證消息完整、正確到達，UDP是一個不可靠的傳輸協議；
-
缺少擁塞控制容易互相競爭資源導致網絡系統癱瘓
?
UDP的優點
?
-
效率更快；不需要建立連接以及擁塞控制
-
連接更多的客戶；沒有連接狀態，不需要為每個客戶創建緩存等
-
分組首部字節少，開銷小；TCP首部固定首部是20字節，而UDP只有8字節；更小的首部意味著更大比例的數據部分
-
在一些需要高效率允許可限度誤差的場景下可以使用。如直播場景，并不需要保證每個數據包都完整到達，允許一定的丟包率，這個時候TCP的可靠特性反而成為了累贅；精簡的UDP更高的效率是更加適合的選擇
-
可以進行廣播；UDP并不是面向連接的，所以可以同時對多個進程進行發送報文
?
UDP適用場景
?
UDP適用于對傳輸模型需要應用層高度自定義、允許出現丟包、需要高效率的場景、需要廣播；例如
?
-
視屏直播
-
DNS
-
RIP路由選擇協議
?
/? ?其他補充? ?/
?
分塊傳輸
?
我們可以發現，運輸層在傳輸數據的時候，并不是把整個數據包加個首部直接發送過去，而是會拆分成多個報文分開發送；那他這樣做原因是什么？
?
有讀者可能會想到：數據鏈路層限制了數據長度只能有1460。那數據鏈路層為什么要這么限制？他的本質原因就是：網絡是不穩定的。如果報文太長，那么極有可能在傳輸一般的時候突然中斷了，這個時候就要整個數據重傳，效率就降低了。把數據拆分成多個數據報，那么當某個數據報丟失，只需要重傳該數據報即可。
?
那是不是拆分得越細越好？報文中數據字段長度太低，會使得首部的占比太大，這樣首部就會成為網絡傳輸最大的負擔了。例如1000字節，每個報文首部是40字節，如果拆分成10個報文，那么只需要傳輸400字節的首部；而如果拆分成1000個，那么需要傳輸40000字節的首部，效率就極大地降低了。
?
路由轉換
?
先看下圖：
?
?
-
正常情況下，主機A的數據包可以又 1-3-6-7路徑進行傳送
-
如果路由3壞掉了，那么可以從 1-4-6-7進行傳送
-
如果4也壞掉了，那么只能從2-5-6-7傳送
-
如果5壞掉了，那么就中斷線路了
?
可以看出來，使用路由轉發的好處是：提高網絡的容錯率，本質原因依舊是網絡是不穩定的 。即使壞掉幾個路由器，網絡依舊暢通。但是如果壞掉路由器6那就直接導致主機A和主機B無法通信，所以要避免這種核心路由器的存在。
?
使用路由的好處還有：分流。如果一條線路太擁堵，可以從別的路線進行傳輸，提高效率。
?
粘包與拆包
?
在面向字節流那一小節講過，TCP不懂這些數據流的意義，他只知道從應用層拿到數據流，切割成一份份報文，然后發送給目標對象。而如果應用層傳輸下來的是兩個數據包，那么極有可能出現這種情況：
?
?
-
應用層需要向目標進程發送兩份數據，一份音頻，一份文本
-
TCP只知道接收到一個流，并把流拆分成4段進行發送
-
中間第二個報文的數據就出現兩個文件的數據混在一起，這就是粘包
-
目標進程應用層在接收到數據之后，需要把這些數據拆分成正確的兩個文件，就是拆包
?
粘包與拆包都是應用層需要解決的問題，可以在每個文件的最后附加上一些特殊的字節，如換行符；或者控制每個報文只包含一個文件的數據，不足的用0補充等等。
?
惡意攻擊
?
TCP的面向連接特點可能會被惡意的人利用，對服務器進行攻擊。
?
前面我們知道，當我們向一個主機發送syn包請求創建連接時，服務器會為我們創建緩沖區等，然后向我們返回syn+ack報文；如果我們偽造IP和端口，向一個服務器進行海量的請求，會使得服務器創建了大量的創建一半的TCP連接，使得其無法正常響應用戶的請求，導致服務器癱瘓。
?
解決的方法可以有限制IP的創建連接數、讓創建一半的tcp連接在更短的時間內自行關閉、延緩接收緩沖區內存的分配等等。
?
長連接
?
我們向服務器的每一次請求都需要創建一個TCP連接，服務器返回數據之后就會關閉連接；如果在短時間內有大量的請求，那么頻繁創建TCP連接關閉TCP連接是一個很浪費資源的行為。所以我們可以讓TCP連接不要關閉，在這個期間進行請求，提高效率。
需要注意長連接維持時間、創建條件等，避免被惡意利用創建大量的長連接，消耗殆盡服務器的資源。
總結
- 上一篇： Linux系列（一）：简介与目录结构
- 下一篇： HDFS-简介