一 TCP傳輸的特點：

1 TCP是面向連接的傳輸層協議。與UDP不同的是，TCP在發送數據的時候，需要進行連接，在TCP傳輸完數據后，必須要對連接進行釋放
2 TCP連接只能提供點對點的連接
3 TCP提供可靠的交付服務。通過TCP傳輸的數據可以保證無差錯、無丟失、不重復、按序到達
4 TCP提供全雙工通訊。在同一條TCP連接上的兩個點可以互相傳輸數據
5 TCP是面向字節流的傳輸，應用程序與TCP的交互式一次一個數據塊，但是對于TCP來說，數據只是一連串無結構的字節流，TCP并不知道傳輸的字節流的含義。

二 什么是可靠的傳輸？

1 簡介：
我們知道，IP層只能提供最大努力的服務，所以，IP層的傳輸是不可靠的，所以TCP必須采用某種措施，才能讓傳輸變得可靠。可靠傳輸有兩個特點，分別是：
（1）傳輸信道不產生差錯
（2）不管發送方傳輸數據的速度有多快，接收方都必須跟上發送方的節奏，及時處理傳輸過來的數據。

2 如何保證可靠傳輸？
2.1 停止等待協議
發送方發送一段數據后，就停止傳輸數據，等待接收方接受完數據后，返回確認指令，然后發送方繼續發送接下來的一段數據。這個時候，如果接收方檢測發送方數據的時候出錯，或者發送方自己丟失了數據，導致接收方什么都接受不到，那么，發送方這個時候是不會接收到任何接收方的確定指令的。如果發送方持續等待，就會造成資源的浪費。所以，停止等待協議提出了超時重傳機制：發送方每發送一次數據的時候，都會開啟一個計時器，如果在規定時間內接到接收方的確定，那么就發送數據，同時把計時器重置；如果在規定時間內，未能接收到接收方的確定指令，那么，就重新發送這段數據，同時重置數據，這個就是超時重傳機制。
超時重傳需要注意：
（1）發送方在發送完數據后，必須保留數據的副本，以備超時重傳；
（2）發送方和接收方對數據發送和確認必須進行編號，這樣發送方才知道，需要重新發送的是哪段數據；
（3）超時時間不能設置過短，這樣會導致資源浪費，同時不能設置過長，長時間處于等待確認狀態也是會耗費大量的網絡資源。超時重傳時間應該比平均往返時間還要略長一點。
確認丟失和確認遲到處理：
在傳輸過程中，還有兩種情況，那就是，接收方確實是接到了發送方的數據，但是在給發送方的確認丟失了，或者遲到了。由于超時重連機制，發送方會繼續發送認為丟失的數據。這個時候，接收方接收到這個數據，應該做出以下動作:
1 丟棄接收到的重復數據，不傳輸給應用層；
2 發送確認報文，通知發送方這段數據已經收到，不用繼續發送。
到此，我們已經可以讓網絡進行可靠的數據傳輸了，但是停止等待協議會讓信道利用率降低數據傳輸的往返和接收方數據梳處理都需要耗費大量的時間，因此需要停止等待協議進行改進，于是，一種新的停止等待協議就誕生了：流水線傳輸。流水線傳輸就是讓發送方可以連續傳輸多個分組，不必等到發送方一個一個確定才發送數據，這樣可以使信道上一直有數據在傳輸

2.2 連續ARQ協議
ARQ協議的全名是Automatic Repeat reQuest。也就是我們所說的滑動窗口協議。滑動窗口協議的精髓是，發送方維持一個發送窗口，這個窗口可以發送5個分組。發送方每次的發送動作，其實就是把這個發送窗口往前移動。比如發送方把1-5的分組發送到接收方，接收方接收到1后，對1進行確認，那么發送窗口就可以繼續遷移到6的分組處，然后繼續發送數據。
為了提高速度，一般接受方不會一條條對分組進行確認，而是累計起來，一次性對數據進行確認。但這個的問題是，不能向發送方反饋已經接收到的所有分組的信息。比如發送方已經發送了1-5的數據分組，但是接收方由于第3的分組丟失，導致接收方只能返回第2分組的確認。發送方無法確認4 5分組是否已經發送成功，只能繼續傳輸3-5的分組。這樣也會造成資源的浪費。

三 TCP的可靠性傳輸

3.1 TCP發送窗口
在前面的連續ARQ協議中，我們知道，在沒有收到接收方的確認時，A可以連續把窗口內的數據都發送出去，在未收到確認前，發送方都必須要保留發送數據的副本，以備超時重傳。發送窗口具有以下幾個特點：
（1）發送窗口的前沿數據表示不允許發送的數據，后沿數據表示已經發送并且受到確認的數據；
（2）發送窗口內的部分=已經發送待確定數據+允許發送的數據（可用窗口）。
（3）發送窗口的位置由前沿和后沿的位置決定，發送窗口后沿的變化有兩種，一是不動，而是前移（受到確認）

3.2 TCP緩存
發送方的應用進程把字節流寫入TCP發送緩存中，而接收方的應用進程從TCP的接受緩存中讀取字節流。那么，TCP發送緩存中，存放著以下緩存：
（1）發送方應用程序準備發送的數據；
（2）發送方已經發送，但是還沒有被確認的數據。
而接收方緩存，存放著以下的數據：
（1）按序到達的，但是沒有被接收方應用程序讀取的數據；
（2）未按序到達的數據。
如果接收應用程序來不及讀取收到的數據，那么接收緩存就會被填滿，而接收窗口就會被減少到0，反之，如果應用程序可以及時從接受緩存中接收到數據，那么接收窗口就可以增大，但最大不能超過緩存的大小。同時，我們還應該注意：
（1）發送窗口不一定和接收窗口一樣大，在一般情況下，發送窗口應該比接收窗口要小，甚至在網絡不暢的情況下，發送窗口還會自己減小發送窗口的大小；
（2）TCP對不按序到達的數據，都是先臨時存放在接收窗口中，等字節流所缺少的字節到達后，才交付給應用程序；
（3）TCP要求接收方必須要累積確認的功能，這樣可以減少傳輸開銷。接收方不可以過分推遲發送確認，因為這樣會導致發送方不必要的重傳。一般，推遲時間不能超過0.5s。

四 TCP流量控制

流量控制，指的是讓發送方的發送速率不要太快，要讓接收方來得及接收。
4.1 利用滑動窗口
滑動窗口總結來說，就是由接收方決定發送方發送多大的發送窗口rwnd。接收方發送數據格式 = ACK=1,ack=序號（100、200...),rwnd=XXX。
滑動窗口有一個問題，就是接收方給發送方的確認，在傳輸過程中，如果丟棄了，那么接收方在等待發送方的發送數據，而發送方一直在等待接收方返回的rwnd非0的通知，這樣就會造成死鎖的產生。
TCP為了解決這個問題，設計了持續計時器。在TCP接到對方的零窗口通知后，就啟動一個計時器，如果計時器事件到達后，接收方還沒有返回rwnd，那么探測器就會發送一個零窗口刺探報文，如果窗口依然是0，那么接到這個報文段后，計時器重置為0；如果窗口不為0，那么死鎖的局面就可以被打破。

五 TCP的擁塞控制

所謂擁塞控制，就是防止過多的數據注入網絡中，這樣可以使網絡中的路由器或者鏈路不導致過載，擁塞控制是全局性的過程，設計所有的主機、路由器以及降低網絡傳輸性能有關的所有因素。

5.1 擁塞控制的方法：

1 慢開始和擁塞避免
（1）慢開始：有小到大逐漸增大發送窗口，也就是說，有小到大逐漸增加擁塞窗口的數據，每收到一個對新的報文段的確認后，就把擁塞窗口增加一個mss的數量，逐漸增大發送方的擁塞窗口cwnd。
慢開始算法不可能無限制的增大擁塞窗口的大小，過大的擁塞窗口也會引起網絡擁塞，因此還需要設置一個慢開始門限。
當擁塞窗口<慢開始門限時：使用慢開始算法；
當擁塞窗口>慢開始門限時：使用擁塞避免算法；
當擁塞窗口=慢開始門限時：兩個算法都可以。
（2）擁塞避免算法：讓擁塞窗口緩慢的增大，每次把擁塞窗口+1而不是翻倍，這樣可以使擁塞窗口呈線性規律緩慢的增長。
無論是慢開始算法還是擁塞避免算法，只要發送方判斷網絡出現擁塞，那么就要把慢開始門限限制為出現擁塞時發送窗口的一半。然后把擁塞窗口重新賦值為1，執行慢開始算法，這樣做的目的是快速的減少網絡中的分組數，使發生擁塞的路由器有足夠的時間把隊列中的分組處理完畢。

2 快重傳和快恢復
（1）快重傳算法要求接收方每收到一個失序的報文段后立即發出重復確認而不要等待自己發送數據時才進行捎帶確認。快重傳算法規定，發送方一旦重復收到三次某個報文段的確認，就需要立即重傳對方尚未接收到的報文段，而不必繼續等待重傳計時器到期。
（2）快恢復算法一般配合快重傳算法一起使用，當發送方連續收到三個重復確認的時候，就執行算法減小算法，把慢開始門限減半，防止網絡擁塞。接著，把擁塞窗口的值設置為慢開始門限減半后的數值，然后開始執行擁塞避免算法，使擁塞窗口緩慢的線性增大。

六 TCP的運輸連接管理

6.1 TCP連接的建立（三次握手）
過程：
發送方發送：SYN=1，seq=x給接收方
接收方接到數據，返回：SYN=1，ack=x+1，seq=y，ACK=1；
發送方接到數據，返回：SYN=1，ack=y+1,seq=x+1;
經過這三個步奏，我們就可以確認已經建立了連接了。那么，問題來了，為什么TCP需要多一次的連接確定呢？這個是主要為了防止已經失效的連接請求報文又突然傳送給了B，因此產生錯誤。主要表現為：A向B發出了連接請求，但是這個時候，這個請求被滯留在了網絡中，這個時候由于超時重傳機制，A又重新發送了一個連接請求，B重新給與確定，這個時候AB連接成功，A發送完數據后，斷開了請求。這個時候，網絡中A的第一次請求又到了B出，B又重新給A確定連接的應答，但是A已經發送完了數據，因此不會去理會這個B的應答，而B確認為A需要傳輸數據，這樣B的資源就被浪費了。

6.2 TCP連接的斷開（四次揮手）
過程：
A發送FIN=1，seq=u給B；（FIN-WAIT-1）
B接收到數據，返回：ACK=1，seq=v，ack=u+1；(FIN-WAIT-2)
這個階段，表面A不再向B發送數據，但是B如果又數據放回個A的話，那么A還是必須接收到的
B發送 FIN=1，ACK=1，seq=w,ack=u+1;
A發送 ACK=1,ack=w+1,seq=u+1;
這個時候，B接收到A的應答，那么服務端就會斷開這次的TCP請求，而接收端并不會馬上斷開連接，而是要等待2個msl后，才會真正斷開tcp連接，這是為什么呢？
（1）A發送給B的應答報文可能會丟失。這個時候，B會發生超時重傳，因此，A總會在兩個msl內接收到B的請求斷開報文；
（2）防止已失效的連接請求報文出現在本連接中。
我們可以注意到，B斷開TCP連接的時間，要比A快~~

七 總結

至此，TCP的介紹已經結束，篇幅很長，還是需要好好研究呀~~