IP協議是無連接的通訊協議不會占用兩個正在通訊的計算機之間的通訊線路,這樣IP就降低了對網絡線路的需求,每條線可以同時滿足許多不同計算機之間的通訊需要。

通過IP,消息或者其他數據會被分割為較小的獨立的包并通過因特網在計算機之間傳送。

IP負責將每個包路由到目的地,但是IP協議沒用做任何工作去確認數據是否按順序發送或者包是否被破壞,所以IP數據包是不可靠的,因此需要它的上層傳輸層TCP協議來做控制!

[[286827]]

TCP(Transmission Control Protocol 傳輸控制協議)：

• 面向連接的、可靠的、基于字節流的傳輸層通信協議
• 將應用層的數據流分割成報文段(報文段長度受MTU影響)并發送給目標節點的TCP層
• 數據包都有序號，對方收到則發送ACK(確認字符)確認，未收到則重傳
• 使用校驗和來檢驗數據在傳輸過程中是否有誤

報文頭介紹

源端口標識發起通信的那個進程，目的端口標識接受通信的那個進程。

有了端口號，接受到報文后才能夠知道將報文發送到哪個進程。

在TCP傳輸中，每一個字節都是有序號的，從0開始。通過序號的方式保存數據的順序,接收端接受到之后進行重新排列成為需要的數據。

因此，我對于SEQ和ACK的了解就是：

• seq(Sequence Nubmer) 代表：發送的這個包中第一個字節(如果有payload的話)的序號
• ack(Acknowledgement) 代表：已成功接受序列號到 ack-1 的數據，期望接收的下一個字節的序號為 ack
• 首部長度(Data Offset)：表示TCP報文首部信息的長度。由于首部可能含有選項內容，因為TCP首部的長度是不確定的。首部長度指示了數據區在報文段中的起始偏移值。沒有任何選項字段的TCP頭部長度為20字節，做多可以有60字節的TCP頭部。
• 保留(Reserved)：6位保留字段，值通常為0;

TCP Flags標志位(每個標志位表示一個控制功能)

(1) URG：緊急指針(為0無效忽略,為1有效)

(2) ACK：確認序號(為0表示報文中不含確認信息忽略確認號字段,為1表示確認號有效)

(3) PSH：(為1表示帶有PAH數據讓接收方應該盡快將這個報文段交給應用層,不在緩沖區排隊)

(4) RST：重建連接。(用于重置由于主機崩潰或其他原因出現錯誤的鏈接或用于拒絕非法報文段和非法請求)

(5) SYN：同步序列號,用于建立連接過程

(6) FIN：finsh標志,用于釋放連接。為1時表示發送方已經沒有數據發送了

• window指滑動窗口大小,用來告知發送端目的接收端的緩存大小以此來控制發送端發送數據的速率以此達到流量控制的效果
• CheckSum 校驗和：奇偶校驗。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算以16位進行計算所得,由發送端計算和存儲，并由接收端進行驗證
• 緊急指針(Urgent Pointer)：只有TCPFlags中URG=1時有效,如果TCP通信中，一方有緊急的數據需要盡快發送給接收方，并且讓接收方的TCP協議盡快通知相應的應用程序，可以將URG置位，并通過緊急指針指示緊急數據在報文段中的結束位置。占16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最后一個字節的序號。
• Options可定義一些其他參數

TCP的三次握手流程

這里每次傳遞seq ack+1的原因是每次一個報文傳送告知，都要消耗一個序號。

書面解釋,專業回答```在TCP/IP協議中，TCP協議提供可靠的連接服務，采用三次握手建立一個連接。

• 第一次握手：建立連接時，客戶端發送SYN包(syn=j)到服務器，并進入SYN_SEND狀態，等待服務器確認;
• 第二次握手：服務器收到SYN包，必須確認客戶的SYN(ack=j+1),同時自己也發送一個SYN包(syn=k) 即SYN+ACK包，此時服務器進入SYN_RECV狀態;
• 第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發送確認包ACK(ack=k+1]，此包發送完畢 客戶端和服務器進入ESTABLISHED狀態，完成三次握手。

三次握手模擬,只限理解,專業回答看上面：

兩者建立鏈接的過程類似于彼此確認彼此能否正確的收到信息(類似于相互在進行一次小型的通訊)```AB在一個很高的樓層想嘗試帶彼此東西上樓,于是要嘗試能不能收到彼此的東西：

• 第一次握手,SYN=1,A告訴B,老子要給你送東西了,seq=X,你在x樓等包裹；
• 第二次握手,ACK=1,老子聽到了你說啥了,SYN=1,B告訴A,老子愿意收,我這就去x樓等你,ack=x+1,我在在x樓了,下一次x+1樓,seq=y,我把你的重新給你我再給你我自己的東西你試試能不能收到,你到y樓等我)；
• 第三次握手,ACK=1,我收到我發的包和你發的包了,沒問題,seq=x+1,你下次去的樓是x+1樓,sck=y+1,老子到y樓了,下一層y+1樓;```哈哈哈除了我大概別人也難看懂

為什么需要三次握手才能建立鏈接???

為了初始化Sequence Number的初始值,其實就是上面的x和y,通訊雙方要告訴彼此自己的Sequence Number這個號要作為以后數據通訊的序號,以保證應用層接收到的數據接收到的數據不會因為網絡上的問題而產生問題,即TCP會用這個序號來拼接數據,因此服務器端收到客戶端的Sequence Number要發送一個確認報文,告訴客戶端,我已收到你的Sequence Number;

首次握手的隱患-SYN超時

問題原因：

• Server收到Client的SYN，回復SYN-ACK的時候未收到ACK確認(比如IP地址是偽造的,服務器找不到)
• Server不斷重試直至超時，Linux默認等待63秒才斷開連接(重試5次,間隔時間翻倍1,2,4,8,16,32)

后果

可能服務器收到SYN Flood的風險,每一次這樣的鏈接會讓服務器等待63秒,如果有很多這樣的請求，導致服務器打開了大量的SYNC_RECV半連接,就會把TCP的連接隊列耗盡，最后導致TCP無法對其他TCP連接進行響應。

針對SYN Flood的預防措施

• SYN隊列滿后，TCP通過源地址端口目標地址端口和時間戳打造出一個tcp_syncookies(可看作Sequence Numbe)參數回發SYN Cookie
• 若為正常連接則Client會回發SYN Cookie，直接建立連接(即使服務器隊列滿了也可以)

若建立連接后Client出現故障怎么辦?

TCP設有保活機制：

• 若一段時間內(保活時間)若連接處于非活動狀態,開啟保活功能的一段向對方發送保活探測報文，如果未收到響應則繼續發送
• 嘗試次數達到保活探測數仍未收到響應(這時可以確認對方主機為不可達)則中斷連接