TCP的特點
TCP（Transmission Control Protocol 傳輸控制協議）是一種面向連接的、可靠的、基于字節流的。為了通過IP數據報實現可靠性傳輸，需要考慮很多事情，側如數據的破壞、丟包、重復以及分片順序混亂等問題。如不能解決這些問題，也就無從談起可靠傳輸。TCP通過校驗和、序列號、確認應答、重發控制、連接管理、以及窗口控制等機制來實現可靠性傳輸。TCP建立連接的實質是，主機A和主機B告知彼此的第一個發送字節的初始序列號，建立連接后對每一個發送的字節都需要以初始序列號為基點進行編號，需要對方來確認每一個字節編號都已經成功接收，雙方初始序列號是由操作系統動態生成的隨機的值，一般每個TCP 會話都會有不一樣的初始序列號，占四個字節。
ACK
TCP通過肯定的確認應答(ACK) 實現可靠的數據傳輸。當發送端將數據發出之后會等待對端的確認應答。如果有確認應答，說明數據已經成功到達對端。反之，則數據丟失的可能性很大。在一定時間內沒有等到確認應答，發送端就可以認為數據已經丟失，并進行重發由此，即使產生了丟包，仍然能夠保證數據能夠到達對端，實現可靠傳輸。如果數據被重發之后若還是收不到確認應答，則進行再次發送。此時確認應答的時間將會以2倍、4信的指數函數延長。達到一定次數后，如果任沒有任何確認應答返回，就會判斷為網絡發生異常，強制關閉連接，并且通知應用通信異常強行終止。
流控制
發送端根據自己的實際情況發送數據。但是，接收端可能收到的是一個毫無
關系的數據包又可能會在處理其他問題上花費一些時間。因此在為這個數據包做其他處理時會耗費一些時間，甚至在高負荷的情況下無法接收任何數據。如此一來，如果接收端將本應該接收的數據丟棄的話，就又會觸發重發機制，從而導致網絡流量的無端浪費。為了防止這種現象的發生，TCP 提供一種機制可以讓發送端根據接收端的實際接收能力控制發送的數據量。這就是所謂的流控制。它的具體操作是，接收端主機向發送端主機通知自己可以接收數據的大小，于是發送端會發送不超過這個限度的數據。該大小限度就被稱作窗口大小。在前面6.4.6 節中所介紹的窗口大
小的值就是由接收端主機決定的。TCP 首部中，專門有一個字段用來通知窗口大小。接收主機將自己可以接收的緩沖區大小放人這個字段中通知給發送端。這個字段的值越大，說明網絡的吞吐量越高。不過，接收端的這個緩沖區一旦面臨數據溢出時，窗口大小的值也會隨之被設置為一個更小的值通知給發送端，從而控制數據發送量。也就是說，發送端主機會根據接收端主機的指示，對發送數據的量進行控制。這也就形成了一個完整的TCP 流控制(流量控制)。
擁塞控制
因為 TCP 的窗口控制，收發主機之間即使不再以一個數據段為單位發送確認應答，也能夠連續發送大量數據包。然而，如果在通信剛開始時就發送大量數據，也可能會引發其他問題。一般來說，計算機網絡都處在一個共享的環境。因此也有可能會因為其他主機之間的通信使得網絡擁堵。在網絡出現擁堵時，如果突然發送一個較大量的數據，極有可能會導致整個網絡的癱瘓。TCP 為了防止該問題的出現，在通信一開始時就會通過一個叫做慢啟動的算法得出的數值，對發送數據量進行控制。首先，為了在發送端調節所要發送數據的量，定義了一個叫做“擁塞窗口”的概念。于是在慢啟動的時候，將這個擁塞窗口的大小設置為1個數據段發送數據，之后每收到一次確認應答(ACK)，擁塞窗口的值就加1MSS。在發送數據包時，將擁塞窗D的大小與接收端主機通知的窗口大小做比較，然后按照它們當中較小那個值，發送比其還要小的數據量。如果重發采用超時機制，那么擁塞窗口的初始值可以設置為1以后再進行慢啟動修正。有了上述這些機制，就可以有效地減少通信開始時連續發包導致的網絡擁堵，還可以避免網絡擁塞情況的發生。
慢啟動
慢啟動算法的基本思想是當TCP開始在一個網絡中傳輸數據或發現數據丟失并開始重發時，首先慢慢的對網路實際容量進行試探，避免由于發送了過量的數據而導致阻塞。主機發送了一個報文后就要停下來等待應答，每收到一個應答，擁塞窗口就增加一段長度，直至等于設定的閾值。比如我們可以先讓發送方發一個包，等這個包被 ack 之后，我們再發 2 個包，這 2 個被 ack 之后再發 4 個包，以此類推，讓一次所發的包數量慢慢增加，這就是慢啟動。
Window
談 TCP 離不開 窗口的概念，有 congestion window，receive window，sliding window 等等。window 是以 tcp segment 數量為單位，我們可以說當前 window 值由幾個 tcp 包構成，而當我們說 window size 的時候，又是在說一個 window 所包含的字節數。window size 除了和 tcp segment 的數量有關之外，還和單個 tcp segment 的最大 size 有關，即 MSS 值。發送方的 Window 大小稱之為 CWND（congestion window），接收方的 Window 大小稱之為 RWND（receiver window，或 advertised window）。CWND 表示當前發送方可以發送多少個 TCP 包，而 RWND 表示當前接收方還能接收多少個 TCP 包。值得注意的是，CWND 是一個發送方本地的值，并不會在網絡上傳輸。而 RWND 則是由接收方告知發送方的，是存在于 TCP 包的協議中，會通過網絡傳輸。比如，A主機發送給B window 大小為8192，意思是：B主機最多可以連續發送8192 字節給A主機（一般來說，8192字節就是A主機的接收緩沖區大小），如果B主機不小心發送超過8192字節，如果application 沒有及時取走，則超過 8192 自己數據可能會因為A主機的接收緩沖區滿而被丟棄，所以B主機會嚴格遵守A的 RWND 的大小，如果A主機通告它的window大小為 0，則B主機一定不會發送數據。TCP首部中 Window Size 占兩個byte，最大值為65535。
MTU
MTU： Maximum Transmit Unit，最大傳輸單元，即物理接口（數據鏈路層）提供給其上層（通常是IP層）最大一次傳輸數據的大小；以普遍使用的以太網接口為例，缺省MTU=1500 Byte，這是以太網接口對IP層的約束，如果IP層有<=1500 byte 需要發送，只需要一個IP包就可以完成發送任務；如果IP層有> 1500 byte 數據需要發送，需要分片才能完成發送，這些分片有一個共同點，即IP Header ID相同。
MSS
MSS：Maximum Segment Size ，TCP提交給IP層最大分段大小，不包含TCP Header和 TCP Option，只包含TCP Payload ，MSS是TCP用來限制application層最大的發送字節數。如果底層物理接口MTU= 1500 byte，則 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果application 有2000 byte發送，需要兩個segment才可以完成發送，第一個TCP segment = 1460，第二個TCP segment = 540。
Persist Timer
Persist Timer: 用于周期探測對方receiver window size 是否依然為0的定時器。比如，A主機通告它的window大小為 0，則B一定不會發送數據。B主機也不會一直等下去，如果一直等下去則會發生死鎖。為了防止這種情況的死鎖發生，發送者使用了一個持續計時器（persiet timer）來周期性的詢問接收者是否已增加了窗口。從發送者發出的這些段稱為窗口探測（window probes）。
tcpdump
在iOS設備上抓包比較方便，除了常用的，如：Charles、Paw 等軟件外，我們還可以使用tcpdump。以下是抓包的步驟：
1、先將iPhone用數據線連到你的Mac設備；
2、通過各類助手或者iTunes獲取iPhone的UDID；
3、通過Mac上的rvictl程序，創建一個虛擬網卡，然后通過這個虛擬網卡監聽設備上所有的網絡流量。終端命令
rvictl -s udid啟動tcpdump。終端命令：
sudo tcpdump -i rvi0 -AAl（ rvi0 為創建的虛擬網卡）。
（待續）
