0、目錄
1、爲什麼是三次握手
2、Tcp異常斷開及RST 報文
3、time_wait存在意義
4、什麼是半連接隊列？
5、ISN(Initial Sequence Number)是固定的嗎？
6、三次握手過程中可以攜帶數據嗎？
7、SYN攻擊是什麼？
8、粘包發生在那些情況下？
1、爲什麼是三次握手
單向傳輸一次信令的可靠性包括： 網絡是否允許， 對端是否準備好接收和發送。只有通過ack才能確認這種能力。Tcp保證雙向可靠通信，所以兩端都做一次發送和接收ack。其中第二三步可以合併一步，增加效率。
2、Tcp異常斷開及RST 報文
1、嘗試與服務器未監聽的端口建立TCP連接，服務器將會直接向客戶端發送reset報文
2、接收端收到TCP報文，但是發現該TCP的報文，並不在其已建立的TCP連接列表內，則其直接向對端發送reset報文（斷電重啓場景）(已關閉的鏈收到漫遊報文時返回)
3、在交互中的某一方長期未收到來自對方的確認報文，則在超出一定的重傳次數或時間後，會主動向對端發送Reset報文釋放Tcp連接
4、在設計系統時，會利用reset報文快速釋放已完成數據交互的TCP連接，以提高業務交互的效率
Reset報文的利用
1、安全設備利用reset報文阻斷異常連接
3、time_wait存在意義
存在意義：
①因爲被動關閉的可能因爲ACK沒收到而重新發送FIN,主動端最多等待2msl來接收。
②四元組(2 ip+2 port)確定一個鏈接，需要保證再次建立該TCP鏈接時，來自該鏈接先前化身的重複分組(漫遊分節)已經在網絡中消逝了
爲什麼time_wait在主動關閉一端？同意義①
2msl(MSL = IP報文段在網絡中存在的最大時間）是爲了保證接收重發的FIN。2代表 ack返回 + 重發的Fin
4、什麼是半連接隊列？
服務器第一次收到客戶端的 SYN 之後，就會處於 SYN_RCVD 狀態，此時雙方還沒有完全建立其連接，服務器會把此種狀態下請求連接放在一個隊列裏，我們把這種隊列稱之爲半連接隊列
服務器發送完SYN-ACK包，如果未收到客戶確認包，服務器進行首次重傳，等待一段時間仍未收到客戶確認包，進行第二次重傳。如果重傳次數超過系統規定的最大重傳次數，系統將該連接信息從半連接隊列中刪除
5、ISN(Initial Sequence Number)是固定的嗎？
當一端爲建立連接而發送它的SYN時，它爲連接選擇一個初始序號。ISN隨時間而變化，因此每個連接都將具有不同的ISN。ISN可以看作是一個32比特的計數器，每4ms加1 。這樣選擇序號的目的在於防止在網絡中被延遲的分組在以後又被傳送，而導致某個連接的一方對它做錯誤的解釋。
三次握手的其中一個重要功能是客戶端和服務端交換 ISN(Initial Sequence Number)，以便讓對方知道接下來接收數據的時候如何按序列號組裝數據。如果 ISN 是固定的，攻擊者很容易猜出後續的確認號，因此 ISN 是動態生成的。
6、三次握手過程中可以攜帶數據嗎？
其實第三次握手的時候，是可以攜帶數據的。但是，第一次、第二次握手不可以攜帶數據
假如第一次握手可以攜帶數據的話，如果有人要惡意攻擊服務器，那他每次都在第一次握手中的 SYN 報文中放入大量的數據。，然後瘋狂着重複發 SYN 報文的話，這會讓服務器花費很多時間、內存空間來接收這些報文。
也就是說，第一次握手不可以放數據，其中一個簡單的原因就是會讓服務器更加容易受到攻擊了。而對於第三次的話，此時客戶端已經處於 ESTABLISHED 狀態。對於客戶端來說，他已經建立起連接了，並且也已經知道服務器的接收、發送能力是正常的了，所以能攜帶數據。
7、SYN攻擊是什麼？
服務器端的資源分配是在二次握手時分配的，而客戶端的資源是在完成三次握手時分配的，所以服務器容易受到SYN洪泛攻擊。SYN攻擊就是Client在短時間內僞造大量不存在的IP地址，並向Server不斷地發送SYN包，Server則回覆確認包，並等待Client確認，由於源地址不存在，因此Server需要不斷重發直至超時，這些僞造的SYN包將長時間佔用未連接隊列，導致正常的SYN請求因爲隊列滿而被丟棄，從而引起網絡擁塞甚至系統癱瘓。SYN 攻擊是一種典型的 DoS/DDoS 攻擊。
檢測 SYN 攻擊非常的方便，當你在服務器上看到大量的半連接狀態時，特別是源IP地址是隨機的，基本上可以斷定這是一次SYN攻擊。在 Linux/Unix 上可以使用系統自帶的 netstats 命令來檢測 SYN 攻擊。
netstat -n -p -t | grep SYN_RECV
常見的防禦 SYN 攻擊的方法有如下幾種：
- 縮短超時（SYN Timeout）時間
- 增加最大半連接數
- 過濾網關防護
- SYN cookies技術
8、粘包發生在那些情況下？
TCP是端到端傳輸的，同時TCP連接是可複用，複用就是一條連接可以供一臺主機上的多個進程使用。
1. 由TCP連接複用造成的粘包問題。
如果沒有複用一個連接只提供給端到端的兩個進程使用，這是數據的傳輸方和發送方都是約定好了數據的格式的，但是多個進程使用一個TCP連接，此時多種不同結構的數據進到TCP的流式傳輸，邊界分割肯定會出這樣或者那樣的問題。
如果利用tcp每次發送數據，就與對方建立連接，然後雙方發送完一段數據後，就關閉連接，這樣就不會出現粘包問題
連接複用的問題
2. 因爲TCP默認會使用Nagle算法，此算法會導致粘包問題。
而Nagle算法主要做兩件事，1）只有上一個分組得到確認，纔會發送下一個分組；2）收集多個小分組，在一個確認到來時一起發送。
多個分組拼裝爲一個數據段發送出去，如果沒有好的邊界處理，在解包的時候會發生粘包問題。
3. 數據包過大造成的粘包問題。
比如應用進程緩衝區的一條消息的字節的大小超過了發送緩衝區的大小，就有可能產生粘包問題。因爲消息已經被分割了，有可能一部分已經被髮送出去了，對方已經接受了，但是另外一部分可能剛放入套接口發送緩衝區裏準備進一步發送，後半段就有可能是另外一組數據，直接導致了粘包問題的出現。
4. 流量控制，擁塞控制也可能導致粘包。
5. 接收方不及時接收緩衝區的包，造成多個包接收。
Nagle算法、接收方不及時處理兩種情況造成的粘包問題主要原因
粘包問題如何處理？
- Nagle算法 問題導致的，需要結合應用場景適當關閉該算法。
2.其他幾種情況的處理方法主要：
- 尾部標記序列。通過特殊標識符表示數據包的邊界，例如\n\r，\t，或者一些隱藏字符。
- 頭部標記分步接收。在TCP報文的頭部加上表示數據長度。
- 應用層發送數據時定長髮送。