一、 UDP （user datagram protocol）用戶數據報協議

①： 一種簡單的面向數據報的通訊協議，即：應用層傳下來的報文，不合并，不拆分，只是在其上面加上首部后就交給了下面的網絡層。無論應用層交給UDP多長的報文，它統統發送，一次發送一個報文。

②： 接收方，接到后直接去除首部，交給上面的應用層就完成任務

③：UDP報頭包含4個字段，每個字段占用2個字節，標題段，開銷小

特點：
1）UDP不提供復雜的控制機制，利用IP提供面向無連接的通訊服務 —— 連接

2）傳輸途中出現丟包， UDP也不負責重發 —— 丟包不處理

3）當報的到達順序出現亂序時，UDP沒有糾正的能力 —— 無糾正能力

4）接收方接收到數據的那一刻，立即按照原樣發送到網絡上的一種機制。即使是出現網絡擁堵的情況，UDP 也無法進行流量控制等避免網絡擁塞的行為。 —— 網絡擁塞無法處理

1、UDP為什么不可靠？ bind和connect對于UDP的作用是什么？

UDP 只有一個socket接受緩沖區，沒有socket發送緩存區。 即為：只要有數據就發，不管對方是否可以正確接收。而在對方的 socket 接收緩沖區滿了之后，新來的數據報無法進入到 socket 接受緩沖區，此數據報就會被丟棄，因此 UDP 不能保證數據能夠到達目的地，此外，UDP 也沒有流量控制和重傳機制，故UDP的數據傳輸是不可靠的。

connect: 和 TCP 建立連接時采用三次握手不同，UDP 中調用 connect 只是把對端的 IP 和 端口號記錄下來，并且 UDP 可多多次調用 connect 來指定一個新的 IP 和端口號，或者斷開舊的 IP 和端口號（通過設置 connect 函數的第二個參數）。和普通的 UDP 相比，調用 connect 的 UDP 會提升效率，并且在高并發服務中會增加系統穩定性。

bind: 當 UDP 的發送端調用 bind 函數時，就會將這個套接字指定一個端口，若不調用 bind 函數，系統內核會隨機分配一個端口給該套接字。當手動綁定時，能夠避免內核來執行這一操作，從而在一定程度上提高性能。

二、 TCP （Transmissioin Control Protocl）傳輸控制協議

①：一種可靠、面向字節流的通訊協議，把上面應用層交下來的數據看成無結構的字節流來發送。

②：可以想象成為流水形式，發送方TCP 會將數據放入“蓄水池”（緩存區），等到可以發送的時候發送，不能發送就等著。

③：TCP會根據網絡的擁塞狀態來確定每個報文段的大小。

④：報文首部有20個字節，額外開銷大。

TCP結構

URG 表示緊急指針標志，該位為 1 時表示緊急指針有效，為 0 則忽略；

ACK 為確認序號標志，即相應報文段包括一個對已被成功接收報文段的確認；

PSH 為 push 標志，當該位為 1 時，則指示接收方在接收到該報文段以后，應盡快將這個報文段交給應用程序，而不是在緩沖區排隊；

RST 為重置連接標志，當出現錯誤連接時，使用此標志來拒絕非法的請求；

SYN 為同步序號，在連接的建立過程中使用，例如三次握手時，發送方發送 SYN 包表示請求建立連接；

FIN 為 finish 標志，用于釋放連接，為 1 時表示發送方已經沒有數據發送了，即關閉本方數據流。

接收窗口：主要用于 TCP 流量控制。該字段用來告訴發送方其窗口（緩沖區）大小，以此控制發送速率，從而達到流量控制的目的。

校驗和：奇偶校驗，此校驗和是對整個 TCP 報文段，包括 TCP 頭部和 數據部分。該校驗和是一個端到端的校驗和，由發送端計算和存儲，并由接收端進行驗證，主要目的是檢驗數據是否發生改動，若檢測出差錯，接收方會丟棄該 TCP 報文。

緊急數據指針：緊急數據用于告知緊急數據所在的位置，在URG標志位為 1 時才有效。當緊急數據存在時，TCP 必須通知接收方的上層實體，接收方會對緊急模式采取相應的處理。

選項：該字段一般為空，可根據首部長度進行推算。主要有以下作用：

① TCP 連接初始化時，通信雙方確認最大報文長度。

② 在高速數據傳輸時，可使用該選項協商窗口擴大因子。

③ 作為時間戳時，提供一個 較為精準的 RTT。

數據：TCP 報文中的數據部分也是可選的，例如在 TCP 三次握手和四次揮手過程中，通信雙方交換的報文只包含頭部信息，數據部分為空，只有當連接成功建立后，TCP 包才真正攜帶數據。

特點：
1）TCP充分地實現了數據傳輸時各種控制功能，可以進行丟包時重發控制，還可以對次序亂掉的分包進行順序控制，而這些在UDP中都沒有 —— 丟包處理、糾正處理

2）TCP是面向連接的協議，只有確認通訊對端存在時才會發送數據，從而可以控制通信流量的浪費 —— 可避免擁塞的控制

3）根據TCP這些機制，IPO這種無連接的網絡上也能夠實現高可靠性的通訊（主要通過：校驗和、序列號、確認應答、重發控制、連接管理以及窗口控制等機制實現）—— 基于無連接的IP進行高可靠的協議的需要處理的

1、TCP的定[計]時器

TCP有 7 中計時器：

1. 建立連接定時器：該定時器是在建立TCP連接的時候使用的，在TCP三次握手的過程中，發送方發送SYN時，會啟動一個定時器(默認為3秒)，若SYN包丟失了，那么3秒以后會重新發送SYN包直到達到重傳的次數。
   
2. 重傳定時器：該計時器主要用于TCP超時重傳機制中， 當TCP發送報文段時，就會創建特定報文的重傳計時器，并可能出現兩種情況：

①：若在計時器截止之前發送方收到的ACK報文，則撤銷該計時器。

②：若計時器截止時間內并沒有收到接收方的ACK報文，則發送方重傳報文，并將計時器復位。

3. 堅持計時器：TCP通過讓接收方指明希望從發送方接受的數據字節數(窗口大小)來進行流量控制，當接收端的接收窗口滿時，接收端會告訴發送端此時窗口已滿，請停止發送數據。此時，發送端和接收端的窗口大小均為0，直到窗口變為非0時，接收端將發送一個確認ACK告訴發送端可以再次發送數據，但是該報文有可能在傳輸時丟失。若該ACK報文丟失，則雙方可能會一直等待下去，為了避免這種死鎖情況，發送方使用一個堅持定時器來周期性的向結合搜發發送探測報文段，以查看接受方窗口是否變大。 —— 發送方和接收方窗口都是0，若是接收方窗口變成了非0，發送一個ack給發送端，但是丟失了，從而產生了客戶端輪詢的定時器 ——> 堅持計時器
4. 延遲應答計時器：【又稱捎帶ACK】， 在延遲應答的時候使用的。 為了提高網絡傳輸的效率，當服務器接收到客戶端的數據后，不是立即回ACK給客戶端，而是等一段時間，這樣如果服務端有數據需要發送給客戶端的話，就可以把數據和ACK一起發送給客戶端了。
5. 保活定時器：該定時器是在建立 TCP 連接時指定 SO_KEEPLIVE 時才會生效，當發送方和接收方長時間沒有進行數據交互時，該定時器可以用于確定對端是否還活著。
6. FIN_WAIT_2定時器：主動請求關閉的一方發送FIN報文給接收端并且收到其對FIN的確認ACK后進入FIN_WAIT_2狀態。如果這個時候因為網絡突然斷掉、被動關閉的一端宕機等原因，到時請求方沒有收到接收方發來的FIN，主動關閉的一方回一直等待。—— 該定時器的作用就是為了避免這種情況的發生。當該定時器超時的時候，請求關閉比方將不再等待，直接釋放連接。
7. TIME_WAIT定時器：TCP四次揮手中，發送方在最后一次揮手之后回進入TIME_WAIT狀態，不直接進入CLOSE狀態的主要原因是被動關閉方玩意在超時時間內沒有收到最后一個ACK，則還會重發最后的FIN。 —— （1）2MSL等待時間保證了重發的FIN會被主動關閉的一端收到且重新發送以后一個ACK。（2）在這2MSL的時間段內任何遲到的報文段會被接受方丟棄，從而防止老的TCP連接的包在新的TCP連接里面出現。

2、TCP如何保證可靠性的？

1. 數據分塊: 應用數據被分割成TCP認為最適合發送的數據塊
   
2. 序列號和確認應答：TCP給發送的每個包進行編號，在傳輸的過程中，每次接收方收到數據后，都會對傳輸方進行確認應答，即發送ACK報文，這個ACK報文當中帶有對應的確認序列號，剛告訴發送方成功接收了哪些數據以及下一次的數據從哪里開始發。除次之外，接收方可以根據序列號對數據進行排序，把有序數據傳送給應用層，并丟棄重復的數據。
   
3. 校驗和：TCP將保持它首部和數據部分的校驗和，目的是檢測數據在傳輸過程中的任何變化。 如果收到報文段的校驗和也有差錯，TCP將丟棄這個報文段并且不確認收到的此報文
   
4. 流量控制：TCP連接的雙方都一個固定大小的緩沖空間，發送方發送的數據量不能夠超過接收端緩沖區的大小，當接收方來不及處理發送方的數據，會提示發送方降低發送的速率，防止產生丟包。TCP通過滑動窗口協議來支持流量控制機制。
   
5. 擁塞控制：當網絡某個節點發生擁塞時，減少數據的發送
   
6. ARQ協議：也是為了實現可靠傳輸的，它的基本原理就是每發完一個分組就定制發送，等待對方確認。 在收到確認后，再發下一個分組。
   
7. 超時重傳：當TCP發出一個報文段后，它啟動一個定時器，等待目的段確認收到這個報文段，如果超過某個時間還沒有收到確認，將重發這個報文段。
   

3、TCP超時重傳原理？

發送方在發送一次數據后就開啟一個定時器，在一定時間內如果沒有得到發送數據包的 ACK 報文，那么就重新發送數據，在達到一定次數還沒有成功的話就放棄重傳并發送一個復位信號。其中超時時間的計算是超時的核心，而定時時間的確定往往需要進行適當的權衡，因為當定時時間過長會造成網絡利用率不高，定時太短會造成多次重傳，使得網絡阻塞。在 TCP 連接過程中，會參考當前的網絡狀況從而找到一個合適的超時時間。

4、TCP的停止等待協議是什么？

停止等待協議是為了實現 TCP 可靠傳輸而提出的一種相對簡單的協議，該協議指的是發送方每發完一組數據后，直到收到接收方的確認信號才繼續發送下一組數據。【在已發送但未確認的報文被確認之前, 發送方的滑動窗口將不會滑動】

四種情形：理解停等協議是人如何實現可靠傳輸的：

<1> 發送方發送的 Msg 1 在中途丟失了，接收方完全沒收到數據。

<2> 接收方收到 Msg 1 后檢測出現了差錯，直接丟棄 Msg 1。

上面兩種情況，接收方都不會回任何消息給發送方，此時就會觸發超時傳輸機制，即發送方在等待一段時間后仍然沒有收到接收方的確認，就認為剛才發送的數據丟失了，因此重傳前面發送過的數據。

③ 確認丟失
當接收方回應的 Msg 1 確認報文在傳輸過程中丟失，發送方無法接收到確認報文。于是發送方等待一段時間后重傳 Msg 1，接收方將收到重復的 Msg1 數據包，此時接收方會丟棄掉這個重復報文并向發送方再次發送 Msg1 的確認報文。

④ 確認遲到
當接收方回應的 Msg 1 確認報文由于網絡各種原因導致發送方沒有及時收到，此時發送方在超時重傳機制的作用下再次發送了 Msg 數據包，接收方此時進行和確認丟失情形下相同的動作（丟棄重復的數據包并再次發送 Msg 1 確認報文）。發送方此時收到了接收方的確認數據包，于是繼續進行數據發送。過了一段時間后，發送方收到了遲到的 Msg 1 確認包會直接丟棄。

5、TCP最大的連接數限制？

Client 最大 TCP 連接數
client 在每次發起 TCP 連接請求時，如果自己并不指定端口的話，系統會隨機選擇一個本地端口（local port），該端口是獨占的，不能和其他 TCP 連接共享。TCP 端口的數據類型是 unsigned short，因此本地端口個數最大只有 65536，除了端口 0不能使用外，其他端口在空閑時都可以正常使用，這樣可用端口最多有 65535 個。

Server最大 TCP 連接數
server 通常固定在某個本地端口上監聽，等待 client 的連接請求。不考慮地址重用（Unix 的 SO_REUSEADDR 選項）的情況下，即使 server 端有多個 IP，本地監聽端口也是獨占的，因此 server 端 TCP 連接 4 元組中只有客戶端的 IP 地址和端口號是可變的，因此最大 TCP 連接為客戶端 IP 數 × 客戶端 port 數，對 IPV4，在不考慮 IP 地址分類的情況下，最大 TCP 連接數約為 2 的 32 次方（IP 數）× 2 的 16 次方（port 數），也就是 server 端單機最大 TCP 連接數約為 2 的 48 次方。

然而上面給出的是只是理論上的單機最大連接數，在實際環境中，受到明文規定（一些 IP 地址和端口具有特殊含義，沒有對外開放）、機器資源、操作系統等的限制，特別是 sever 端，其最大并發 TCP 連接數遠不能達到理論上限。對 server 端，通過增加內存、修改最大文件描述符個數等參數，單機最大并發 TCP 連接數超過 10 萬 是沒問題的。

6、TCP流量控制與擁塞控制

流量控制

所謂流量控制就是讓發送方的發送速率不要太快，讓接收方來得及接收。如果接收方來不及接收發送方發送的數據，那么就會有分組丟失。在 TCP 中利用可變長的滑動窗口機制可以很方便的在 TCP 連接上實現對發送方的流量控制。主要的方式是接收方返回的 ACK 中會包含自己的接收窗口大小，以控制發送方此次發送的數據量大小（發送窗口大小）。

擁塞控制

在實際的網絡通信系統中，除了發送方和接收方外，還有路由器，交換機等復雜的網絡傳輸線路，此時就需要擁塞控制。擁塞控制是作用于網絡的，它是防止過多的數據注入到網絡中，避免出現網絡負載過大的情況。常用的解決方法有：慢開始和擁塞避免、快重傳和快恢復。

擁塞控制和流量控制的區別

1. 擁塞控制往往是一種全局的，防止過多的數據注入到網絡之中，而TCP連接的端點只要不能收到對方的確認信息，猜想在網絡中發生了擁塞，但并不知道發生在何處
   
2. 流量控制往往指點對點通信量的控制，是端到端的問題。

困惑：滑動窗口和擁塞窗口的不明確：

滑動窗口（協議）：是傳輸層將進行流量控制的一種措施，接收方通過通告發送方自己的窗口大小，從而控制發送方的發送速度，從而達到防止發送方發送速度過快二人導致自己被淹沒的目的。 —— 滑動窗口可以理解為協議、機制、或者服務器滑動窗口大小。 ——> 主要的是：接收方還可以接收的大小通告發送方控制發送的大小。

擁塞窗口【congestion window 簡稱：cwnd】：可以看做是發送端用來進行流量（擁塞）控制的窗口。擁塞是指一個或者多個交換點的數據報超載而導致時延劇烈增加的現象。為了控制擁塞，TCP使用了第二個窗口限制，即擁塞窗口限制。對于擁塞窗口大小的限制采用慢開始和乘法減小兩種技術。

乘法減小的擁塞避免策略：一旦發現報文段丟失，就把擁塞窗口的大小減半（直到減至最小的窗口，窗口中應至少包含一個報文段）。

慢開始恢復：擁塞窗口隨著一個確認的到達，擁塞窗口的大小每次增加一個報文段。

擁塞窗口是發送方使用的流量控制，而通告/滑動窗口則是接收方使用的流量控制。

7、如果接收方滑動窗口滿了，發送方會怎么做？

基于 TCP 流量控制中的滑動窗口協議，我們知道接收方返回給發送方的 ACK 包中會包含自己的接收窗口大小，若接收窗口已滿，此時接收方返回給發送方的接收窗口大小為 0，此時發送方會等待接收方發送的窗口大小直到變為非 0 為止，然而，接收方回應的 ACK 包是存在丟失的可能的，為了防止雙方一直等待而出現死鎖情況，此時就需要堅持計時器來輔助發送方周期性地向接收方查詢，以便發現窗口是否變大【堅持計時器參考問題】，當發現窗口大小變為非零時，發送方便繼續發送數據。

8、擁塞控制采用的四種算法

ssthresh: ss閾值

cwnd: Congestion Window 擁塞窗口

rwnd：Receiver Window 接收者窗口 —— 即為：滑動窗口 Sliding window

慢開始的乘以2的原因

網絡擁塞 —— 即為超時

快重傳示意圖，cwnd這個時候應該是不變的

快恢復

1. 慢開始（慢啟動） —— 傳數據從1快速增加
   當發送方開始發送數據時，由于一開始不知道網絡負荷情況，如果立即將大量的數據字節傳輸到網絡中，那么就有可能引起網絡擁塞。一個較好的方法是在一開始發送少量的數據先探測一下網絡狀況，即由小到大的增大發送窗口（擁塞窗口 cwnd）。慢開始的慢指的是初始時令 cwnd為 1，即一開始發送一個報文段。如果收到確認，則 cwnd = 2，之后每收到一個確認報文，就令 cwnd = cwnd* 2。
   
   但是，為了防止擁塞窗口增長過大而引起網絡擁塞，另外設置了一個慢開始門限 ssthresh。
   
   ① 當 cwnd < ssthresh 時，使用上述的慢開始算法；
   
   ② 當 cwnd > ssthresh 時，停止使用慢開始，轉而使用擁塞避免算法
   

2. 擁塞避免 —— 傳數量慢慢增加
   擁塞控制是為了讓擁塞窗口 cwnd 緩慢地增大，即每經過一個往返時間 RTT （往返時間定義為發送方發送數據到收到確認報文所經歷的時間）就把發送方的 cwnd 值加 1，通過讓 cwnd 線性增長，防止很快就遇到網絡擁塞狀態。
   
   當網絡擁塞發生時，讓新的慢開始門限值變為發生擁塞時候的值的一半,并將擁塞窗口置為 1 ,然后再次重復兩種算法（慢開始和擁塞避免）,這時一瞬間會將網絡中的數據量大量降低。

3. 快重傳 —— 傳輸缺失的數據
   快重傳算法要求接收方每收到一個失序的報文就立即發送重復確認，而不要等到自己發送數據時才捎帶進行確認，假定發送方發送了 Msg 1 ~ Msg 4 這 4 個報文，已知接收方收到了 Msg 1，Msg 3 和 Msg 4 報文，此時因為接收到收到了失序的數據包，按照快重傳的約定，接收方應立即向發送方發送 Msg 1 的重復確認。 于是在接收方收到 Msg 4 報文的時候，向發送方發送的仍然是 Msg 1 的重復確認。這樣，發送方就收到了 3 次 Msg 1 的重復確認，于是立即重傳對方未收到的 Msg 報文。由于發送方盡早重傳未被確認的報文段，因此，快重傳算法可以提高網絡的吞吐量。

4. 快恢復
   快恢復算法是和快重傳算法配合使用的，該算法主要有以下兩個要點：

① 當發送方連續收到三個重復確認，執行乘法減小，慢開始門限 ssthresh 值減半；

② 由于發送方可能認為網絡現在沒有擁塞，因此與慢開始不同，把 cwnd 值設置為 ssthresh 減半之后的值，然后執行擁塞避免算法，線性增大 cwnd。

小結：
1）滑動窗口和擁塞窗口大小比較，取小的值。

2. 上面討論的慢啟動和擁塞避免算法都是在 擁塞窗口<滑動窗口的情況下。 否則，就直接使用滑動窗口了。
   
3. 主要就是：慢啟動、擁塞避免、快恢復
   
4. 判斷是使用快恢復/擁塞避免還是慢啟動+擁塞避免，要看擁塞當前是超時了，還是快恢復？如果我收到了多次的同一個序列號的ack，那就是快恢復，如果是超時了，那就是擁塞避免。
   

滑動串口和擁塞窗口的合作：

1. 發送端主機在確認發送報文段的速率時，既要根據接收端的接收能力，又要從全局考慮不要使網絡發生擁塞
   
2. 因此，每個tcp連接需要也有以下兩個狀態變量：a:接收端窗口 b:擁塞窗口
3. 收端窗口：是接收端根據其一目前的接收緩存大小所許諾的最新窗口值，時來自接收端的流量控制。接收端將此值放在TCP報文的首部中的窗口字段，傳給發送端
4. 擁塞窗口：是發送端根據自己估計的網絡擁塞程度而設置的窗口值，是來自發送端的流量控制
5. 發送端的發送窗口的上限值取自接收端窗口和擁塞窗口兩這種較小的一個。

參考： https://blog.csdn.net/weixin_41501074/article/details/110941340

9、TCP粘包問題

為什么會發生TCP粘包和拆包?

① 發送方寫入的數據大于套接字緩沖區的大小，此時將發生拆包。

② 發送方寫入的數據小于套接字緩沖區大小，由于 TCP 默認使用 Nagle 算法，只有當收到一個確認后，才將分組發送給對端，當發送方收集了多個較小的分組，就會一起發送給對端，這將會發生粘包。

③ 進行 MSS （最大報文長度）大小的 TCP 分段，當 TCP 報文的數據部分大于 MSS 的時候將發生拆包。

④ 發送方發送的數據太快，接收方處理數據的速度趕不上發送端的速度，將發生粘包。

常見解決方法

① 在消息的頭部添加消息長度字段，服務端獲取消息頭的時候解析消息長度，然后向后讀取相應長度的內容。

② 固定消息數據的長度，服務端每次讀取既定長度的內容作為一條完整消息，當消息不夠長時，空位補上固定字符。但是該方法會浪費網絡資源。

③ 設置消息邊界，也可以理解為分隔符，服務端從數據流中按消息邊界分離出消息內容，一般使用換行符。

什么時候需要處理粘包問題？
當接收端同時收到多個分組，并且這些分組之間毫無關系時，需要處理粘包；而當多個分組屬于同一數據的不同部分時，并不需要處理粘包問題。

10、為什么服務端易受到 SYN 攻擊

在 TCP 建立連接的過程中，因為服務端不確定自己發給客戶端的 SYN-ACK 消息或客戶端反饋的 ACK 消息是否會丟在半路，所以會給每個待完成的半開連接狀態設一個定時器，如果超過時間還沒有收到客戶端的 ACK 消息，則重新發送一次 SYN-ACK 消息給客戶端，直到重試超過一定次數時才會放棄。

服務端為了維持半開連接狀態，需要分配內核資源維護半開連接。當攻擊者偽造海量的虛假 IP 向服務端發送 SYN 包時，就形成了 SYN FLOOD 攻擊。攻擊者故意不響應 ACK 消息，導致服務端被大量注定不能完成的半開連接占據，直到資源耗盡，停止響應正常的連接請求。

解決方法：

1. 直接的方法是提高 TCP 端口容量的同時減少半開連接的資源占用時間，然而該方法只是稍稍提高了防御能力；
   
2. 部署能夠辨別惡意 IP 的路由器，將偽造 IP 地址的發送方發送的 SYN 消息過濾掉，該方案作用一般不是太大；

這兩種方法雖然在一定程度上能夠提高服務器的防御能力，但是沒有從根本上解決服務器資源消耗殆盡的問題

下面的方法出發點都是在發送方發送確認回復后才開始分配傳輸資源，從而避免服務器資源消耗殆盡：

1. SYN Cache：該方法首先構造一個全局 Hash Table，用來緩存系統當前所有的半開連接信息。在 Hash Table 中的每個桶的容量大小是有限制的，當桶滿時，會主動丟掉早來的信息。當服務端收到一個 SYN 消息后，會通過一個映射函數生成一個相應的 Key 值，使得當前半連接信息存入相應的桶中。當收到客戶端正確的確認報文后，服務端才開始分配傳輸資源塊，并將相應的半開連接信息從表中刪除。和服務器傳輸資源相比，維護表的開銷要小得多。
   
2. SYN Cookies:該方案原理和 HTTP Cookies 技術類似，服務端通過特定的算法將半開連接信息編碼成序列號或者時間戳，用作服務端給客戶端的消息編號，隨 SYN-ACK 消息一同返回給連接發起方，這樣在連接建立完成前服務端不保存任何信息，直到發送方發送 ACK 確認報文并且服務端成功驗證編碼信息后，服務端才開始分配傳輸資源。若請求方是攻擊者，則不會向服務端會 ACK 消息，由于未成功建立連接，因此服務端并沒有花費任何額外的開銷。
   

存在缺點：由于服務端并不保存半開連接狀態，因此也就喪失了超時重傳的能力，這在一定程度上降低了正常用戶的連接成功率。 此外，客戶端發送給服務端的去人不保溫存在傳輸丟是的可能，當ACK確認報文丟失時，服務端和客戶端會對連接的成功與否產生歧義，此時就不需要上層應用采取相應的策略進行處理了。

SYN Proxy：在客戶端和服務器之間部署一個代理服務器，類似于防火墻的作用。通過代理服務器與客戶端進行建立連接的過程，之后代理服務器充當客戶端將成功建立連接的客戶端信息發送給服務器。這種方法基本不消耗服務器的資源，但是建立連接時間變長了。

SYN FLOOD 參考：
https://zhuanlan.zhihu.com/p/29539671
https://dun.163.com/news/p/69294ba2366f49ae9f21d904f661023c

11、高并發服務器：客戶端主動關閉連接 和 服務器主動關閉連接的區別：

服務端主動關閉連接
在高并發場景下，當服務端主動關閉連接時，此時服務器上就會有大量的連接處于TIME-WAIT狀態

客戶端主動關閉連接
當客戶端主動關閉連接時，我們并不需要關心TIME-WAIT狀態過多造成的問題，但是需要關注服務端保持大量的CLOSE-WAIT狀態時會產生的問題。

無論是客戶端還是服務器主動關閉連接，從本質上說，在高并發場景下主要關心的就是服務端的資源占用問題，而這也是采用TCP傳輸協議必須要面對的我呢提，其問題解決的發出點也是如何處理好服務質量和資源消耗之間的關系。

三 、區別

1. 連接：TCP面向連接，3次握手，4次揮手; UDP是面向無連接，數據傳輸前后不連接，發送端只負責將數據發送到網絡，接收端從消息隊列讀取。
   
2. 可靠：TCP 提供可靠的服務，傳輸過程采用流量控制、編號、確認、計時器等手段確保數據誤差錯、不丟失。 UDP則盡可能傳遞數據，但并不保證傳遞給付給對方
   
3. 傳輸數據：TCP面向字節流，將應用層報文看成一串無結構的字節流，分解為多個TCP報文段傳輸后，在目的站重新裝配； UDP協議面向報文，不拆分應用層報文，只保留報文邊界，一次發送一個報文了，接受方去除報文首部，原封不動將報文交給上層應用。
   
4. 雙工：TCP只能夠點對點雙工通信，UDP支持1-1/1-n/n-1/n-n的交互通信。

四、應用場景

TCP 使用對效率要求低，對準確性要求高或要求也有鏈接的場景

UDP 對效率要求高，對準確性要求低的場景

本文由mdnice多平臺發布