參考網址：https://blog.csdn.net/m0_38121874/article/details/82914634
1、報頭
（1）TCP協議報頭
TCP指傳輸控制協議，其報頭格式如下：
TCP協議中的六個標志分別是，URG、ACK、PSH、RST、SYN、FIN。
1）UGR(緊急):UGR=1表示緊急指針字段有效。它告訴系統此報文段有緊急數據，應當盡快傳送。從報文段的開頭，到緊急指針指向的地方就是緊急數據。
2）ACK(確認):ACK=1時，確認號字段才有效。
3）PSH(推送):讓對方立即收到響應。與URG的區別就是URG中的緊急數據不經過緩沖區就直接上交給上層邏輯，而PSH還是要從緩沖區上交，只是不用等到緩沖區滿了才上交。
4）RST(復位):RST=1時，表明TCP鏈接中出現嚴重差錯，必須釋放鏈接，然后再重新鏈接。以下幾種場景中會使用RST報文(訪問不存在的端口。異常終止一個鏈接，一般情況下是發送FIN，因為在所有排隊數據都以發送之后才發送FIN，但是也有可能發送一個RST來異常釋放連接。檢測半打開的鏈接，即一端關閉，另一端不知道，這時會發送一個RST進行監測。當長時間不用連接，連接斷開之后，再次訪問的時候會發送RST)。
5）SYN(同步):在鏈接建立時用來同步序號。當SYN=1，ACK=0時表示請求報文。SYN=1，ACK=1表示鏈接接受。因此SYN=1表示一個鏈接請求或鏈接接受報文。
6）FIN(終止):用來釋放一個鏈接。
（2）UDP協議報頭
UDP指用戶數據報協議，其報頭格式如下：
2、TCP的優缺點
（1）TCP的優點：
TCP的優點是：可靠、穩定。它體現在TCP在傳遞數據之前，會有三次握手來建立連接；在數據傳遞時，采用校驗和、序列號、確認應答、超時重發、流量控制、擁塞控制，為了提高性能，還采用了滑動窗口、延遲應答和捎帶應答等機制；在數據傳完后，會斷開連接以節約系統資源。
（2）TCP的缺點：
TCP的缺點：運行速度慢，效率低，占用系統資源多，易被攻擊。因為TCP在傳遞數據之前，要先建立連接，這會消耗時間；在數據傳遞時，確認機制、重傳機制、擁塞控制機制等都會消耗大量的時間，而且要在每台設備上維護所有的傳輸連接，每個連接都會占用系統的CPU、內存等資源；TCP有確認機制、三次握手機制，這導致TCP容易受到DOS、DDOS、CC等攻擊。收到STN洪水攻擊，是因為使用 TCP的時候服務器端需要listen，這時需要設置backlog。
3、UDP的優缺點
（1）UDP的優點：運行速度較快，比TCP安全。
1）運行速度快，因為 UDP連接沒有TCP的三次握手、確認應答、超時重發、流量控制、擁塞控制等機制，而且UDP是一個無狀態的傳輸協議，所以它在傳遞數據時非常快。
2）較安全，因為沒有TCP的那些機制，UDP較TCP被攻擊者利用的漏洞就會少一些。但UDP也是無法避免攻擊的，比如：UDP Flood攻擊等。
（2）UDP的缺點：不可靠，不穩定。
因為UDP沒有TCP那些可靠的機制，在數據傳遞時，如果網絡質量不好，就會很容易丟包。
4、TCP和UDP的特點
（1）TCP的特點
TCP協議是一種有連接、可靠的、面向字節流、相對比較慢、點對點的傳輸層協議。TCP協議適用於對可靠性要求比較高的場合。
（2）UDP的特點
UDP協議是一種無連接，不可靠、面向數據報、速度比較快、可實現一對一，多對一的傳輸層協議。UDP協議適用於對實時性有要求的場合。因為UDP不保證可靠性，所以UDP也沒有重傳機制，也沒有擁塞機制，它只是盡最大努力交付數據。
5、TCP保證數據可靠性和提高性能的機制
（1）確認應答（ACK）機制
TCP將每個字節的數據都進行了編號，即為序列號。每一個ACK都帶有對應的確認序列號，意思是告訴發送者收到了哪些數據，下次從哪里開始發送。
（2）超時重傳機制
1）超時重傳機制的工作過程
主機A發送數據給B之后，可能因為網絡擁堵等問題，數據無法到達主機B。如果主機A在一個特定時間間隔內沒有收到B發來的確認應答，就會進行重發。但是，主機A未收到B發來的確認應答，也可能是因為ACK丟失了，因此主機B會收到很多重復數據。那么TCP協議需要能夠識別出哪些包是重復的，並且把重復的丟棄掉，這時候可以利用序列號就可以很容易做到去重的效果。
2）如何確定超時時間？
最理想的情況下找到一個最小的時間，保證“確認應答”一定能在這個時間內返回。但是，這個時間的長短隨着網絡環境的不同是有差異的，如果超時時間設的太長會影響整體的重傳效率；如果超時時間設得太短，有可能會頻繁發送重復的包。
TCP為了保證無論在任何環境下都能比較高性能的通信，因此會動態計算這個最大超時時間。Linux中超時以500ms為一個單位進行控制，每次判定超時重發的超時時間都是500ms的整數倍。如果重發一次之后仍然得不到應答，等待2500ms后進行重傳；如果仍然得不到應答，等待4500ms再進行重傳，以此類推，以指數形式遞增。累計到一定的重傳次數，TCP認為網絡或者對端主機出現異常，並強制關閉連接。
（3）滑動窗口
1）為什么需要滑動窗口？
前面討論了確認應答策略，對每一個發送的數據段都要給一個ACK確認應答，收到ACK后再發送下一個數據段。這個做有一個比較大的缺點就是性能較差，尤其是數據往返的時間較長的時候。既然這樣一發一收性能較低，那么如果一次發送多條數據，不是就可以將多個段的等待時間重疊在一起提高性能了嗎？
2）工作過程
窗口大小指的是無須等待確認應答而可以繼續發送數據的最大值，規定發送前4個段的時候，需要等待任何ACK直接發送。收到第一個ACK后，滑動窗口向后移動，繼續發送第5個段的數據，以此類推。操作系統內核為了維護這個滑動窗口，需要開辟發送緩沖區來記錄當前還有哪些數據沒有應答，只有確認應答過的數據才能從緩沖區刪掉，窗口越大網絡吞吐率就越高。那么如果出現丟包，如何進行重傳？
情況一：數據包已經抵達，ACK被丟了。
這種情況下，部分ACK丟了並不要緊，因為可以通過后續的ACK進行確認。
情況二：數據包直接丟了。
當某一段報文丟失之后，發送端會一直收到1001這樣的ACK，就像是在提醒發送端“接收端想要的就是1001”一樣。如果發送端主機連續三次收到了同樣一個“1001”，就會將對應的數據1001-2000重新發送.這個時候接收端收到了1001之后，再次返回的ACK就是7001了，因為2001-7000接收端其實之前就已經收到了，被放到了接收端操作系統內核的接收緩沖區中。這種機制被稱為“高速重發控制”，也稱為“快重傳”。
（4）流量控制
1）什么是流量控制？
接收端處理數據的速度是有限的，如果發送端發得太快，導致接收端的緩沖區被填滿，這個時候如果發送端繼續發送就會造成丟包，繼而引起丟包重傳等等一系列連鎖反應。因此，TCP支持根據接收端的處理能力來決定發送端的發送速度，這個機制就叫做流量控制。
2）工作流程
接收端將自己可以接收的緩沖區大小放入TCP首部中的“窗口大小”字段，通過ACK端通知發送端。窗口大小字段越大，說明網絡的吞吐量越高。接收端一旦發現自己的緩沖區快滿了，就會將窗口大小設置成一個更小的值通知給發送端，發送端接收到這個窗口之后就會減慢自己的發送速度。如果接收端緩沖區滿了就會將窗口置為0，這時發送方不再發送數據，但是需要定期發送一個窗口探測數據段，使接收端把窗口大小告訴發送端。
3）接收端如何把窗口大小告訴發送端？
在TCP首部中，有一個16位窗口字段就是用於存放窗口信息的。16位數字最大表示65535，那么TCP窗口最大就是65535字節么？實際上，TCP首部40字節選項中還包含了一個窗口擴大因子M，實際窗口大小是窗口字段的值左移M位。
（5）擁塞控制
1)擁塞控制的必要性
雖然TCP有了滑動窗口這個大殺器，能夠高效可靠的發送大量數據，但是如果在剛開始階段就發送大量的數據，仍然可能引發問題。因為網絡上有很多的計算機，可能當前的網絡狀態就已經比較擁堵，在不清楚當前網絡狀態下貿然發送大量的數據，是很有可能雪上加霜的。
2）慢啟動
TCP引入慢啟動機制，先發少量的數據探探路，摸清當前的網絡擁堵狀態再決定按照多大的速度傳輸數據。此處引入一個概念——擁塞窗口，發送開始的時候，定義擁塞窗口大小為1。每次收到一個ACK應答擁塞窗口就加1，每次發送數據包的時候將擁塞窗口和接收端主機反饋的窗口大小做比較，取較小的值作為實際發送的窗口。
3）慢啟動閥值
像上面這樣的擁塞窗口增長速度是指數級別的。“慢啟動”只是指初始時慢，但是增長速度非常快。為了不增長得那么快，因此不能使用擁塞窗口單純的加倍。此處引入一個叫做慢啟動的閥值，當擁塞窗口超過這個閥值的時候，不再按照指數方式增長，而是按照線性方式增長。 當TCP開始啟動的時候，慢啟動閥值等於窗口最大值，在每次超時重發的時候，慢啟動閥值會變成原來的一半，同時擁塞窗口置回1。少量的丟包僅僅是觸發超時重傳，大量的丟包就會認為是網絡擁塞。當TCP通信開始后，網絡吞吐量會逐漸上升，隨着網絡發生擁堵，吞吐量會立刻下降。擁塞控制。歸根結底是TCP協議想盡可能快的把數據傳輸給對方，但是又要避免給網絡造成太大的壓力的折中方案。（TCP擁塞控制這樣的過程就好像熱戀的感覺）
（6）延遲應答
如果接收端數據的主機立刻返回ACK應答，這個時候返回的窗口可能性比較小。假設接收端緩沖區為1M,一次收到了500k的數據，如果立刻應答，返回的窗口就是500k。但是實際上可能處理端處理的速度很快，10ms之內就把500k數據從緩沖區消費掉。在這種情況下，接收端處理還遠沒有達到自己的極限，即使窗口再放大一些，也能處理過來。如果接收端稍微等一會兒在應答，比如等待200ms在應答，那么這個時候返回的窗口大小就是1M。注意：窗口越大，網絡吞吐量就越大，傳輸效率就越高，應在保證網絡不擁塞的情況下盡量提高傳輸效率。那么所以的包都可以延遲應答么？肯定不行，因為規定有數量限制，每隔N個包就應答一次；而且有時間限制，超過最大延遲時間就應答一次，具體的數量和時間依操作系統不同也有差異，一般N取2，超時時間取200ms。
（7）捎帶應答
在延遲應答的基礎上，很多情況下客戶端服務器在應用層也是“一發一收”的，意味着客戶端給服務器說了“how are you”，服務器也會給客戶端會一個“Fine，thank 有”，那么這個時候ACK就可以搭順風車和服務器回應的“Fine，thank you”一起會給客戶端。
————————————————
版權聲明：本文為CSDN博主「編程鳥」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/m0_38121874/article/details/82914634