一.?TCP/IP五層模型
1. 實體層：
光纜，電纜，無線電波，把電腦連接起來的物理手段。傳輸?shù)氖?和1這種電信號。但是光是0和1是沒有意義的，需要數(shù)據(jù)鏈路層來定義這些0和1代表什么意義。
2. 數(shù)據(jù)鏈路層：
上圖為一個幀，一組電信號構成一組數(shù)據(jù)包，就叫做幀。
head包含了發(fā)送者設備和接受者設備的信息。所謂的設備就是網(wǎng)卡，網(wǎng)卡的地址就是數(shù)據(jù)包的發(fā)送地址和接收地址，就是MAC地址。每個網(wǎng)卡在出廠的時候都有一個世界獨一無二的地址。長度是48個二進制位，12個十六進制數(shù)。
前6個十六進制數(shù)是廠商的編號，后六組是網(wǎng)卡的流水號。
那一個網(wǎng)卡如何知道另一個網(wǎng)卡的地址呢？以太網(wǎng)中有一個ARP協(xié)議解決這個問題。
廣播：比如1號要向2號設備發(fā)送數(shù)據(jù)，它會給所有網(wǎng)絡中的設備都發(fā)送數(shù)據(jù)，讓它們自己判斷自己是不是接收方。通過讀取這個數(shù)據(jù)包的包頭，找到接收方的地址，然后與自身的MAC地址做一個對比。
但是廣播這種方式有一個缺點，就是它只能在子網(wǎng)，就是同一塊局域網(wǎng)里進行廣播，那么如果上海的設備要向北京的設備發(fā)送數(shù)據(jù)，基本不可能。還有就是要向子網(wǎng)里所有的設備都發(fā)送一個數(shù)據(jù)包，效率太低。所以我們需要使用一種方法來確定哪些設備屬于同一個子網(wǎng)里的，如果確定了是屬于同一個子網(wǎng)的話，再去使用廣播的形式傳遞數(shù)據(jù)包。否則的話，我們就需要采取路由的方式發(fā)送。路由就是指如何向不同的子網(wǎng)絡去分發(fā)數(shù)據(jù)包。
3. 網(wǎng)絡層：
引入一套新的地址，讓我們能區(qū)分不同的計算機是否在同一個子網(wǎng)內。這套地址就叫做網(wǎng)絡地址，簡稱網(wǎng)址。
所以現(xiàn)在每臺計算機都有兩個地址，一個是MAC地址，一個是網(wǎng)址。二者沒有關聯(lián)。MAC地址是綁定在網(wǎng)卡上的，而網(wǎng)址是由管理員分配的。要先處理網(wǎng)絡地址，再處理Mac地址。
ip地址：
ip協(xié)議：規(guī)定網(wǎng)絡地址的協(xié)議。目前最廣泛采用的是ipv4協(xié)議。
由32個二進制位組成，一般分為4段10進制數(shù)字。
范圍：0.0.0.0 - 255.255.255.255
在互聯(lián)網(wǎng)上，每個計算機都會分配一個ip地址。
這個ip地址分為兩部分，前面部分代表網(wǎng)絡部分（舉個例子），后面代表主機：
所以同一個子網(wǎng)的前面部分是相同的，只有后面部分不同。但是，實際上網(wǎng)絡部分不一定是由前24位組成的，也有可能是由前16位組成的。
那么如何判斷兩個ip地址是不是在同一個子網(wǎng)里呢？
子網(wǎng)掩碼：表示子網(wǎng)絡特征的一個參數(shù)。指明哪些是主機部分，哪些是網(wǎng)絡部分，如果網(wǎng)絡部分相同，那主機就在同一網(wǎng)絡里。
形式上和ip一樣，也是32位二進制數(shù)字。但是它的網(wǎng)絡部分全部是1，主機部分全部是0。（二進制）。
11111111 11111111 11111111 00000000
255.255.255.0
通過將兩個IP地址分別和子網(wǎng)掩碼做 AND 運算，比較他們的結果是否相同，來判斷這兩個IP是不是在同一個子網(wǎng)下。
IP協(xié)議總結：有兩個作用：
1. 為每個計算機分配一個IP地址
2. 確定哪些地址在同一個子網(wǎng)內。
IP協(xié)議發(fā)送的數(shù)據(jù)叫做IP數(shù)據(jù)包
但是以太網(wǎng)的數(shù)據(jù)包幀head里只包含Mac地址，沒有包含IP地址，head長度也是固定的，那怎么將IP地址放進幀里？我們可以放入幀里的data里，這樣就不用去修改以太網(wǎng)的規(guī)格。這就是分層的好處，上層的變動不會影響下層的結構。
IP數(shù)據(jù)包head主要包含版本號，長度，IP地址等信息。長度在20-60個字節(jié)。
data包含了IP數(shù)據(jù)包的具體內容。
所以以太網(wǎng)的數(shù)據(jù)包幀的結構就變成這樣：幀的head還是不變，data放的是IP數(shù)據(jù)包的內容。
IP數(shù)據(jù)包的長度最大為65535個字節(jié)，減去head最小長度20個字節(jié)，就得到理論上IP數(shù)據(jù)包能裝下的最大容量的數(shù)據(jù)，65535 - 20 = 65515個字節(jié)。
而以太網(wǎng)數(shù)據(jù)包的數(shù)據(jù)部分最大是1500個字節(jié)。如果IP數(shù)據(jù)包超過了1500個字節(jié)，那就需要進行分割。
通常情況下，我們知道對方的IP地址，但是不知道對方的Mac地址，這時就需要ARP協(xié)議。
我們假設存在兩臺計算機，分為兩種情況：
1. 不在同一個子網(wǎng)絡，所以沒法知道對方的Mac地址，只能把數(shù)據(jù)包傳送到兩個子網(wǎng)絡相連的網(wǎng)關處（路由器）處理。
2. 在同一個子網(wǎng)絡，通過ARP協(xié)議我們就可以得知對方的Mac地址。具體就是向子網(wǎng)里每個計算機發(fā)送一個數(shù)據(jù)包，里面包含了目標計算機的IP地址，這時候其他的計算機接收到這個包會取出IP地址和自己比對，如果一樣那就把自己的Mac地址傳回去，如果不一樣就丟棄這個包。
所以，只要有IP地址和Mac地址，兩臺計算機就可以建立起通信了。
但是現(xiàn)在問題是，一個電腦上可能很多程序進程都需要進行網(wǎng)絡通信，那如何確定接收到的數(shù)據(jù)包是屬于哪個程序的呢？
這時候我們需要一個參數(shù)，端口（port）：
范圍在0～65535之間，正好16個二進制位。其中0～1023的端口是被系統(tǒng)占用的。用戶只能選擇1023以上的端口。
4. 傳輸層：
建立端口到端口之間的通信。
而網(wǎng)絡層是建立主機到主機之間的通信。
只要確定了主機和端口，我們就能進行程序之間的交流。
unix系統(tǒng)把主機+端口 叫做套接字（socket）有了socket之后，我們就能進行網(wǎng)絡編程了。
傳輸層有兩個重要的協(xié)議UDP? TCP。
UDP協(xié)議
head里包含了發(fā)出端口和接收端口。包含8個字節(jié)。
data就是真正的數(shù)據(jù)了。然后把整個udp包放到IP數(shù)據(jù)包的數(shù)據(jù)部分。
所以以太網(wǎng)的數(shù)據(jù)包現(xiàn)在變成這樣：
udp包總長度最大為65535字節(jié)。正好能放進一個IP數(shù)據(jù)包。
優(yōu)點：簡單，容易實現(xiàn)。
缺點：可靠性差，數(shù)據(jù)包發(fā)出去不知道是否已經被接收了。
為了解決這個問題，出現(xiàn)了TCP協(xié)議。
TCP協(xié)議
每發(fā)出一個tcp包就要進行確認，如果有一個數(shù)據(jù)包遺失，那就收不到確認。發(fā)送方就需要重新發(fā)送數(shù)據(jù)包了。
優(yōu)點：保證數(shù)據(jù)不會丟失。
缺點：過程復雜，實現(xiàn)困難。會消耗比較多的資源。
tcp傳包的時候，會通過：校驗和，重傳控制，序號表識，滑動窗口，確認應答去實現(xiàn)一個可靠的傳輸。
-TCP 提供一種面向連接的、可靠的字節(jié)流服務
-在一個 TCP 連接中，僅有兩方進行彼此通信（點對點）。廣播和多播不能用于 TCP
-TCP 使用校驗和，確認和重傳機制來保證可靠傳輸
-TCP 給數(shù)據(jù)分節(jié)進行排序，并使用累積確認保證數(shù)據(jù)的順序不變和非重復
-TCP 使用滑動窗口機制來實現(xiàn)流量控制，通過動態(tài)改變窗口的大小進行擁塞控制
注意：TCP 并不能保證數(shù)據(jù)一定會被對方接收到，因為這是不可能的。TCP 能夠做到的是，如果有可能，就把數(shù)據(jù)遞送到接收方，否則就（通過放棄重傳并且中斷連接這一手段）通知用戶。因此準確說 TCP 也不是 100% 可靠的協(xié)議，它所能提供的是數(shù)據(jù)的可靠遞送或故障的可靠通知。
udp適用于高速傳輸，實時性較高的通信，或者廣播通信。支持多對多的交互通信。
5. 應用層：
由于互聯(lián)網(wǎng)是開放的網(wǎng)絡，數(shù)據(jù)來源五花八門，比如email，www，ftp所以事先需要規(guī)定好數(shù)據(jù)格式。
而應用層做的就是規(guī)定這些數(shù)據(jù)格式。有不同的協(xié)議來規(guī)定這些數(shù)據(jù)格式，這些數(shù)據(jù)就放在了tcp數(shù)據(jù)包的data部分。
1向4發(fā)送數(shù)據(jù)包，就需要知道對方的Mac地址和IP地址。但是不在同一個子網(wǎng)下，是不能知道對方的Mac地址的。所以需要通過網(wǎng)關（Gateway）來轉發(fā)。
具體流程：
1. 判斷4是否和它屬于同一個子網(wǎng)。不是的話就把數(shù)據(jù)包發(fā)送給A網(wǎng)關。
2. 網(wǎng)關通過路由協(xié)議發(fā)現(xiàn)4處于B網(wǎng)關內，就把數(shù)據(jù)轉發(fā)到B網(wǎng)關，B網(wǎng)關再把數(shù)據(jù)轉發(fā)給4。
3. 1把數(shù)據(jù)包發(fā)給A網(wǎng)關需要知道A網(wǎng)關的Mac地址。所以數(shù)據(jù)包的目標地址實際上分為：
這里在同一個子網(wǎng)絡下，為什么還需要對方的IP地址呢？
同一子網(wǎng)下確實不需要IP層插手，但是他們之間的通信依然是要先封裝成IP報文，再封裝成以太幀。對方收到幀后，也是要先去幀頭，再去IP頭才能看到數(shù)據(jù)，這樣是為了網(wǎng)絡通信的統(tǒng)一性。
我們在配置一臺新電腦上網(wǎng)設置時，要配置如下信息：
1. 本機IP地址
2. 子網(wǎng)掩碼
3. 網(wǎng)關（路由器）的IP地址
4. dns的IP地址。
如果本機的IP地址保持不變，那就是靜態(tài)地址，這樣這個地址就被永久占用了。
大多還是使用動態(tài)IP地址。就是每次開機都會通過DHCP協(xié)議，重新分配一個IP地址。所有新計算機加入這個網(wǎng)絡必須像DHCP服務器發(fā)送一個DHCP請求數(shù)據(jù)包，去申請自己的IP地址和相關的網(wǎng)絡參數(shù)。
如果要發(fā)送數(shù)據(jù)包給對方，需要知道對方的Mac地址和IP地址，但是對于新加入的計算機并不知道這些信息。那么如何進行傳輸呢？通過DHCP協(xié)議去向DHCP服務器發(fā)送一個DHCP請求數(shù)據(jù)包，去申請自己的IP地址和相關的網(wǎng)絡參數(shù)。有了這些信息之后，這臺新電腦就可以在網(wǎng)上沖浪了。
DHCP協(xié)議是一種應用層協(xié)議，建立在udp協(xié)議之上。
當輸入一個網(wǎng)址后，發(fā)生了什么？
當我們從本地請求一個網(wǎng)絡地址（www.google.com）的時候，首先要通過dns協(xié)議，就是把這個網(wǎng)址轉換成一個IP地址。具體就是向dns服務器發(fā)送一個請求包，然后它會返回給你谷歌的IP地址。
這時得到了返回給我們的IP地址和端口號。
接下來我們要做的是判斷是否和自己屬于同一個子網(wǎng)下。通過與自己的子網(wǎng)掩碼和自己IP地址以及新浪的IP地址做一個按位與操作。不在同一個子網(wǎng)的話，就要通過網(wǎng)關（路由器）進行轉發(fā)，接收方的Mac地址是網(wǎng)關的Mac地址。
而我們?yōu)g覽網(wǎng)頁時使用的是http協(xié)議
與前面的udp不同的是，這里使用的是tcp的形式。
tcp協(xié)議需要設置一個端口，對方的端口一般默認是80，而發(fā)送方，就是本機則隨機選取1024到65535之間的一個整數(shù)，假設是14256，tcp標頭長度是20個字節(jié)。
再往下走是IP協(xié)議，需要設置雙方的IP地址。
再往下是以太網(wǎng)協(xié)議，需要設置雙方的Mac地址。（對方的Mac地址需要設置為網(wǎng)關的Mac地址）
以太網(wǎng)數(shù)據(jù)包長度最大為1500個字節(jié)，而如果目前IP數(shù)據(jù)包已經達到5000字節(jié)，這時這個IP數(shù)據(jù)包必須要被分割為4個包
這個過程經過多個網(wǎng)關的轉發(fā)。新浪服務器接收到了這四個包之后，會根據(jù)IP標頭里的序號對這四個包進行按序拼接。形成一個完整的tcp數(shù)據(jù)包，然后再去讀取http的請求。再作出一個http的響應，最后將他們應用tcp的協(xié)議再發(fā)回去。
當我們請求結束，服務端會告訴我們一個響應，返回了一個html的網(wǎng)頁，然后由瀏覽器幫我們渲染出來。
二. 面試相關：
1. 抓包，三次握手：
序列號seq：占4個字節(jié)，用來標記數(shù)據(jù)段的順序，TCP把連接中發(fā)送的所有數(shù)據(jù)字節(jié)都編上一個序號，第一個字節(jié)的編號由本地隨機產生；給字節(jié)編上序號后，就給每一個報文段指派一個序號；序列號seq就是這個報文段中的第一個字節(jié)的數(shù)據(jù)編號。
確認號ack number：占4個字節(jié)，期待收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號；序列號表示報文段攜帶數(shù)據(jù)的第一個字節(jié)的編號；而確認號指的是期望接收到下一個字節(jié)的編號；因此當前報文段最后一個字節(jié)的編號+1即為確認號。
?確認ACK：標志位，占1位。當ACK=1時，則表示這個報文是一個用于確認的報文。?僅當ACK=1時，確認號字段才有效。ACK=0時，確認號無效
?同步SYN：標志位，連接建立時用于同步序號。當SYN=1，ACK=0時表示：這是一個連接請求報文段。若同意連接，則在響應報文段中使得SYN=1，ACK=1。因此，SYN=1表示這是一個連接請求，或連接接受報文。SYN這個標志位只有在TCP建產連接時才會被置1，握手完成后SYN標志位被置0。
?終止FIN：用來釋放一個連接。FIN=1表示：此報文段的發(fā)送方的數(shù)據(jù)已經發(fā)送完畢，并要求釋放運輸連接
????PS：ACK、SYN和FIN這些大寫的單詞表示標志位，其值要么是1，要么是0；ack、seq小寫的單詞表示序號。
seq是數(shù)據(jù)包本身的序列號；ack是期望對方繼續(xù)發(fā)送的那個數(shù)據(jù)包的序列號。
所謂三次握手(Three-way Handshake)，是指建立一個 TCP 連接時，需要客戶端和服務器總共發(fā)送3個包。
三次握手的目的是連接服務器指定端口，建立 TCP 連接，并同步連接雙方的序列號和確認號，交換 TCP 窗口大小信息。在 socket 編程中，客戶端執(zhí)行?connect()?時。將觸發(fā)三次握手:
三次握手流程：
第一次握手(SYN=1, seq=x):
客戶端發(fā)送一個 TCP 數(shù)據(jù)包，會將SYN 標志位設置為1，還會隨機產生一個序列號seq,然后把這個數(shù)據(jù)包發(fā)送給服務器。發(fā)送完了客戶端進入?SYN_SEND?狀態(tài)。
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):
服務器看到客戶端發(fā)來的SYN=1就知道客戶端要請求建立一個連接，所以服務器需要發(fā)回給客戶端一個確認包(ACK)應答。這個確認包里會把即SYN 標志位和 ACK 標志位都設置為1。同時服務器還要隨機產生一個seq序列號，放到自己這個包的 Seq 域里，還要把確認序號就是ack number設置為客戶端的序列號+1。 發(fā)送完畢后，服務器端進入?SYN_RCVD?狀態(tài)。
第三次握手(ACK=1，ACKnum=y+1)
客戶端收到確認之后，會先檢查對方的ack number是不是自己的序列號+1，還有ACK標志位是不是為1，如果都正確的話，客戶端會再次發(fā)送確認包，具體就是把SYN 標志位設為0，這是因為SYN=1表示這是一個連接請求。只有在TCP建立連接時才會被置1，握手完成后SYN標志位被置0。同時ACK 標志位也是設為1，還要把ack number設置為服務器數(shù)據(jù)包的序列號+1，自己的序列號也要改成第一次握手時的序列號+1。
發(fā)送完了后，客戶端進入?ESTABLISHED?狀態(tài)，當服務器端接收到這個包時，也進入?ESTABLISHED狀態(tài)，TCP 握手結束。
三次握手的過程的示意圖如下：
四次揮手過程：
TCP 的連接的拆除需要發(fā)送四個包，因此稱為四次揮手(Four-way handshake)?？蛻舳嘶蚍掌骶芍鲃影l(fā)起揮手動作，在 socket 編程中，任何一方執(zhí)行?close()?操作即可產生揮手操作。
1）客戶端進程向服務器發(fā)出釋放連接報文，而且會開始停止發(fā)送數(shù)據(jù)。然后會釋放數(shù)據(jù)報文首部，并設置FIN標志位=1，序列號為seq=u（u等于前面服務器傳送過來的數(shù)據(jù)的最后一個字節(jié)的序號加1），這時候客戶端就進入FIN-WAIT-1（終止等待1）狀態(tài)。
2）服務器收到連接釋放報文，就會對客戶端發(fā)出一個確認報文，同時要設置ACK=1，ack number=u（收到數(shù)據(jù)包的序列號）+1，同時還要設置自己的序列號seq=v，這時服務端就進入了CLOSE-WAIT（關閉等待）狀態(tài)。TCP服務器通知高層的應用進程，客戶端向服務器的方向就釋放了，這時候服務器處于半關閉狀態(tài)，就是說客戶端已經沒有數(shù)據(jù)要發(fā)送了，但是服務器如果發(fā)送數(shù)據(jù)，客戶端仍然要接受。這個狀態(tài)還要持續(xù)一段時間，也就是整個CLOSE-WAIT狀態(tài)持續(xù)的時間。
3）客戶端收到服務器的確認請求后，會進入FIN-WAIT-2（終止等待2）狀態(tài)，還要等待服務器發(fā)送連接釋放報文（在這之前還需要接受服務器發(fā)送的最后的數(shù)據(jù)）。
4）服務器把最后的數(shù)據(jù)都發(fā)送完成之后，就向客戶端發(fā)送連接釋放報文，設置FIN標志位=1，ack number=u（收到數(shù)據(jù)包的序列號）+1。由于服務器這時在半關閉狀態(tài)，服務器很可能又發(fā)送了一些數(shù)據(jù)，所以服務器這時的序列號不一定是v+1了，假設這時的序列號為seq=w。發(fā)送完成后服務器就進入了LAST-ACK（最后確認）狀態(tài)，等待客戶端的確認。
5）客戶端收到服務器的連接釋放報文后，必須要再發(fā)出確認，設置ACK=1，ack number=w（最后一次服務器發(fā)的包的序列號）+1，然后它自己的序列號是seq=u+1。發(fā)送結束后客戶端就進入了TIME-WAIT（時間等待）狀態(tài)。這時候TCP連接還沒有釋放，必須經過2倍的MSL（最長報文段壽命）的時間后，才進入CLOSED狀態(tài)。
6）服務器只要收到了客戶端發(fā)出的確認，立即進入CLOSED狀態(tài)。結束這次連接。
【問題1】為什么連接的時候是三次握手，關閉的時候卻是四次握手？
答：因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，"你發(fā)的FIN報文我收到了"。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。
【問題2】為什么TIME_WAIT狀態(tài)需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？
答：雖然按道理，四個報文都發(fā)送完畢，我們可以直接進入CLOSE狀態(tài)了，但是我們必須假象網(wǎng)絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。在Client發(fā)送出最后的ACK回復，但該ACK可能丟失。Server如果沒有收到ACK，將不斷重復發(fā)送FIN片段。所以Client不能立即關閉，它必須確認Server接收到了該ACK。Client會在發(fā)送出ACK之后進入到TIME_WAIT狀態(tài)。Client會設置一個計時器，等待2MSL的時間。如果在該時間內再次收到FIN，那么Client會重發(fā)ACK并再次等待2MSL。所謂的2MSL是兩倍的MSL(Maximum Segment Lifetime)。MSL指一個片段在網(wǎng)絡中最大的存活時間，2MSL就是一個發(fā)送和一個回復所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那么Client推斷ACK已經被成功接收，則結束TCP連接。
【問題3】為什么不能用兩次握手進行連接？
答：3次握手完成兩個重要的功能，既要雙方做好發(fā)送數(shù)據(jù)的準備工作(雙方都知道彼此已準備好)，也要允許雙方就初始序列號進行協(xié)商，這個序列號在握手過程中被發(fā)送和確認。
???????現(xiàn)在把三次握手改成僅需要兩次握手，死鎖是可能發(fā)生的。作為例子，考慮計算機S和C之間的通信，假定C給S發(fā)送一個連接請求分組，S收到了這個分組，并發(fā) 送了確認應答分組。按照兩次握手的協(xié)定，S認為連接已經成功地建立了，可以開始發(fā)送數(shù)據(jù)分組?？墒牵珻在S的應答分組在傳輸中被丟失的情況下，將不知道S 是否已準備好，不知道S建立什么樣的序列號，C甚至懷疑S是否收到自己的連接請求分組。在這種情況下，C認為連接還未建立成功，將忽略S發(fā)來的任何數(shù)據(jù)分 組，只等待連接確認應答分組。而S在發(fā)出的分組超時后，重復發(fā)送同樣的分組。這樣就形成了死鎖。
【問題4】如果已經建立了連接，但是客戶端突然出現(xiàn)故障了怎么辦？
TCP還設有一個保活計時器，顯然，客戶端如果出現(xiàn)故障，服務器不能一直等下去，白白浪費資源。服務器每收到一次客戶端的請求后都會重新復位這個計時器，時間通常是設置為2小時，若兩小時還沒有收到客戶端的任何數(shù)據(jù)，服務器就會發(fā)送一個探測報文段，以后每隔75分鐘發(fā)送一次。若一連發(fā)送10個探測報文仍然沒反應，服務器就認為客戶端出了故障，接著就關閉連接。
【問題5】簡單解釋一些ARP協(xié)議的工作過程
【問題6】如果TCP三次握手的第三次的 ack包丟失會怎樣？
第三次的 ack 包丟失就是說在 client 端接收到 syn + ack 之后，向 server 發(fā)送的 ack 包 由于各種原因 server 沒有收到。這時 client, server 分別會進行怎樣的處理呢？
Server 端
? ? 第三次的ACK在網(wǎng)絡中丟失，那么Server 端該TCP連接的狀態(tài)為SYN_RECV,并且會根據(jù) TCP的超時重傳機制，會等待3秒、6秒、12秒后重新發(fā)送SYN+ACK包，以便Client重新發(fā)送ACK包。
? ? 而Server重發(fā)SYN+ACK包的次數(shù)，可以通過設置/proc/sys/net/ipv4/tcp_synack_retries修改，默認值為5.
? ? 如果重發(fā)指定次數(shù)之后，仍然未收到 client 的ACK應答，那么一段時間后，Server自動關閉這個連接。
Client 端
? ? 在linux c 中，client 一般是通過 connect() 函數(shù)來連接服務器的，而connect()是在 TCP的三次握手的第二次握手完成后就成功返回值。也就是說 client 在接收到 SYN+ACK包，它的TCP連接狀態(tài)就為 established （已連接），表示該連接已經建立。那么如果 第三次握手中的ACK包丟失的情況下，Client 向 server端發(fā)送數(shù)據(jù)，Server端將以 RST包響應，方能感知到Server的錯誤。
