隨意談談tcp

tcp做爲四層中可靠到傳輸協議，爲上層協議提供了字節流的可靠到傳輸，之因此能作到可靠主要由於如下幾點：

一、流與分段：流即字節流，計算機處理程序時通常以字節爲單位，若是上層協議接收到到是字節流而且跟發送時候字節流順序相同那麼會很是舒服。但大量的字節流都塞到一個報文中傳輸會有些問題，網絡設備都有本身到最大傳輸單元，若是報文超過傳輸單元會被丟棄，因此tcp會將要傳輸到字節流進行分段傳輸。

二、應答：每一段都會有一個序號，接收端會將接收到到報文按照序號進行序號加1（能夠理解成下一個指望接收的序號）的應答。

三、滑動窗口和流量控制：IP層的報文傳輸是不保序的，這就致使一個後面tcp的分段可能先到，好比發送端發送 1 2 3 4 5 個分段報文，接收端可能收到的順序是1 2 5 4 3，這樣爲了在接收端保序，一個很容易的方法就是按照順序接收，沒按照順序到來的報文直接丟掉，依靠重傳機制，好比上述例子中，接收到收到1 2報文以後，接收到了5，發現沒按照順序，則直接丟掉，而後接收到4也丟掉，而後接收到3，等4到重傳接收，而後等5，這樣能夠達到保序到要求，可是大量到丟報文，重傳會致使效率較低。另外一個極端到想法就是把不按照順序來到報文緩存到本地，直到全部到報文都接收到再送給上層協議，但這樣作也有一個問題，就是不知道設備上會有多少沒按照順序但報文，這樣都緩存在本地的話，根本不知道會用多少內存。因此就有了個折中的辦法---滑動窗口，滑動窗口能夠理解緩存。超出緩存的才丟掉，緩存內的就放着等收齊了上報。

    實際上發送方和接收方都有滑窗，發送方的滑窗能夠理解爲對發送報文速度的限制，若是隻在接收方緩存，而發送方不受限制，將會致使大量報文在緩存外，形成資源浪費。

發送方滑窗：

 offered window爲整個滑窗的大小，能夠分爲下面兩個部分發送但未接收到應答部分和可用於發送到部分。

接收方滑窗：

 

接收方的滑窗相對於發送方的滑窗多了一個"Received; ACKed; Not Sent to Proc"的部分，接收方接收到的文本流必須等待進程來讀取。若是進程正忙於作別的事情，那麼這些文本流即便已經正確接收，仍是須要暫時佔用接收緩存。另外就是已經接收但將來得及應答但部分和未使用的部分。

如今還有一個問題，發送方的滑動窗口應該設置多大？這個實際上是在報文交互過程當中由接收方通知的，接收方根據本身接收能力，通知發送方本身指望的窗口大小。這樣經過調整窗口的大小也天然的起到了流量控制的目的。

四、丟包重傳：每個分段在接收到收到以後都會進行確認。發送端發送報文以後會啓動定時器，若是定時器超時還沒收到這段的回覆，則認爲是丟包，那麼會重傳。

五、擁塞控制：本質上就是限制本身的行爲，發現網絡擁堵的時候減小本身發送報文的速度，發現網絡不擁堵則多發報文。發送方有本身的擁塞窗口，會根據用塞算法調整這個窗口。