【计算机网络】TCP协议详解
目錄
1. TCP協議頭部格式
2. TCP協議原理?
2.1 可靠傳輸機制
2.1.1 確認應答機制
2.1.2 超時重傳機制
2.1.3 連接管理機制（三次握手，四次揮手）
2.1.4 流量控制
2.1.5 擁塞控制?
2.2 效率機制?
2.2.1 滑動窗口?
2.2.2 延遲應答?
2.2.3 捎帶應答?
3. 粘包問題?
4. TCP的異常情況?
5. TCP協議特點總結
6. 基于TCP的應用層協議?
1. TCP協議頭部格式
- 源/目的端口：表示數據從哪個進程發送，發送到哪個進程去
- 32位序號：發送的數據按照一個字節一個編號存放進去
- 32位確認號：用于給對方的響應，值為收到TCP報文段的序號值加1（表示當前的應答報文針對的是哪個消息進行的確認應答）
- 4位TCP報頭長度：表示TCP頭部有4個字節（32位），所以TCP頭部最大長度為15*4=60
- 6個boolean值標志位：
URG：緊急指針是否有效
ACK：確認號是否有效
PSH：提示接收端應用程序立刻從TCP緩沖區把數據讀走
RST：對方要求重新建立連接，把攜帶RST標識的稱為復位報文段
SYN：請求建立連接，把攜帶SYN標識的稱為同步報文段
FIN：通知對方，要關閉連接了，把攜帶FIN標識的稱為結束報文
- 16位窗口大小：進行流量窗口控制
- 16位校驗和：檢驗數據是否一致
- 16位緊急指針：標識哪部分數據是緊急數據
2. TCP協議原理?
TCP協議是對數據傳輸提供的一個管控機制，主要體現在可靠和效率兩個方面，即在保證數據可靠傳輸的情況下盡可能的提高效率?
2.1 可靠傳輸機制
2.1.1 確認應答機制
向對方發送一個數據報，對方要返回一個確認應答的數據報?
實現的方式：序號和確認序號保證了響應應答針對的是哪一條消息的應答
說明：
- 發送的數據是基于TCP報頭中的“32位序號”來保存的，一個字節對應一個序號
- 確認應答的數據是基于TCP報頭中的“32位確認序號”來保存的，ack（確認信息）標志位置為1，返回某個序列號，說明某個序列號之前的數據全部接收到
- 有了確認應答，它才可以繼續發送后邊的數據
2.1.2 超時重傳機制
發送的數據報可能因為網絡擁堵等原因，超過一定時間，還沒有收到確認應答的數據報，就需要重新發送?
- 沒有收到確認應答，可能是因為發送數據時候就已經發生了丟包
??
- 也可能是因為ACK丟包了?
?
這種情況，主機B可能會接收到許多重復的數據，TCP內部有去重操作，接收的數據會放在操作系統內核的接收緩沖區中，接收緩沖區可以是一個內存空間，視為是一個阻塞隊列，對于收到的數據，TCP會根據序號檢查這個數據是不是在緩沖區中已經存在，如果存在則丟棄，如果不存在則放進去
超時時間如何確定？
如果超時時間設置的太長，會導致重傳的效率
如果超時時間設置的太短，會導致頻繁發送重復的數據
因此TCP協議為了保證在任何環境中都能有較高性能的通信，系統會動態的計算這個超時時間
- 超時以500ms為一個單位，每次判定超時重發的時間都是500ms的整數倍
- 重發一次，仍然不能收到應答，等待2*500ms后再進行重傳
- 仍然等不到應答，等待4*500ms進行重傳，以此類推，以指數形式增長
- 累積到一定重傳次數，TCP協議認為網絡或者對端主機出現異常，強制關閉連接
2.1.3 連接管理機制（三次握手，四次揮手）
真正發送數據之前，要先通過三次握手建立連接，不需要發送數據了，通過四次揮手斷開連接
三次握手
??
三次握手主要是為了檢查當前網絡的情況是否滿足可靠運輸的基本條件，同時也是在檢測雙方發送和接收數據的能力是否正常?
四次揮手?
說明：關閉的時候服務端申請關閉或者客戶端申請關閉都可以
思考：
- 為什么服務端不將ACK和FIN合并一起發送，形成三次揮手呢？
答：主要是ACK和FIN的發送時機不同，ACK是操作系統內核響應的（立即執行），而此時服務端還可能在繼續發送數據，待處理完數據后由程序調用close方法后才發送FIN
- 為什么客戶端要等待一段時間狀態才置為CLOSED，而不之間將狀態置為CLOSED？
答：如果客戶端給服務端的ACK丟包后，服務端得重新給和客戶端發送FIN，此時客戶端得給服務端應答，所以此時狀態不能置為CLOSED，得等待一段時間（2MSL，MSL為網絡上任意兩點傳輸的最大時間）確保服務端收到客戶端的應答?
2.1.4 流量控制
接收端主機處理數據的速度有限，如果發送端發送數據太快，導致接收端緩沖區被填滿，這時，發送端繼續發送數據的話就會造成丟包，繼而引起丟包重傳等一些列連鎖反應，因此TCP協議根據接收端接收數據的能力，來決定發送端發送數據的速度，這個機制就叫作流量控制?
- 接收端將自己剩余緩沖區大小存入TCP頭部中的“16位窗口大小”字段?，通過ACK通知發送端
- 窗口大小越大，說明網絡吞吐量越高
- 發送端根據接收到這個窗口的大小，控制自己的發送速度
- 如果接收緩沖區滿了，就會將窗口設置為0，這時，發送端不在發送數據，而是定期的發送一個窗口探測報文（只是為了知道窗口的大小），讓接收端將窗口大小告訴發送端
2.1.5 擁塞控制?
剛開始發送數據時，由于中間結點的網絡情況不清楚，如果貿然發送大量數據，就會造成大量丟包，所以TCP協議引入慢啟動的方式，先發少量數據探探路，再決定按照多大速度發送數據
此處引入擁塞窗口，剛開始時，擁塞窗口設置為1，每收到一個ACK時，擁塞窗口加1，每次發送數據的時候，擁塞窗口和流量窗口的較小的值作為實際發送的窗口，即滑動窗口的大小?
注意：上述增長方式是指數級別的，指數式增長可以快速接近丟包的極限
擁塞窗口變化的方式?
為了不增長那么快，引入一個慢啟動的閾值，當擁塞窗口的大小超過了這個閾值，不在按照指數方式增長，而是按照線性方式增長，如下圖所示：
開始時，慢啟動的閾值為窗口的最大值，線性增長到一定程度時會發生丟包
網絡擁塞時，擁塞窗口置1，慢啟動閾值變為擁塞窗口/2，重新開始增長
2.2 效率機制?
2.2.1 滑動窗口?
前面的確認應答機制指出，對每一個發送的數據都對應有一個ACK確認應答，這樣采取一發一收的方式有一個很大的缺點就是效率太差，為了提高效率采用滑動窗口，即一次性發送多個數據
- 窗口大小：指無需等待而可以繼續發送數據的最大值，上圖的窗口大小為4000個字節（四個段）
- 具體如何設置窗口大小：min(流量窗口的大小，擁塞窗口的大小)?
- 窗口如何滑動：接收到的ACK下一個是n，滑動到n-1的位置
操作系統內核為了維護這個滑動窗口，需要開辟發送緩沖區來記錄當前還有哪些數據沒有應答，只有應答過的數據才能從緩沖區中刪掉
如果出現了丟包，如何確保可靠傳輸？
- 情況一：數據已經收到，返回的ACK應答丟包
這種情況下，部分ACK丟了不要緊，因為可以通過后續的ACK進行確認?
- 情況二：發送數據的時候就已經丟包?
說明：
- 當1001~2000這段報文丟失后，發送端一直會收到1001這樣的ACK
- 如果發送端主機連續三次收到相同的ACK如1001應答，那發送端主機就會重新發送1001~2000數據
- 此時，接收端收到1001~2000數據后，再次返回的ACK應答就是7001了，因為2001~7000數據都已經接收到了，被放到接收端操作系統內核的接收緩沖區了
這種機制，即時不超時也會發生重傳，稱作“高速重發控制”也叫“快重傳機制”?
2.2.2 延遲應答?
如果接收端主機接收到數據時，立刻返回ACK應答，這時候返回的流量窗口就比較小，但是流量窗口越大，網絡吞吐量越大，傳輸效率就越高，所以等待一部分時間，待接收端處理完一部分數據?，就可以將流量窗口設置為大一點的值，這樣網咯吞吐量大，效率高
延遲是為了高吞吐量，但是也不能無限延遲
- 數量限制，每隔n個包就應答一次
- 時間限制，超過最大延遲時間，就應答一次
具體的數量和時間，不同操作系統有差異，一般n取2，超時時間取200ms?
2.2.3 捎帶應答?
服務端接收到客戶端的消息后，因為延遲應答機制，導致ACK不一定立即返回，可能ACK返回的時機和應用代碼中返回響應的時機重合了，此時九江
3. 粘包問題?
TCP是面向字節流的，可以多次的接收和發送，對于應用層來說，一連串的字節數據，不知道從哪到哪算一個完整的應用層數據包，對應發送多少次算一個應用層完整格式的數據，和接收多少次算一個應用層完整格式的數據就不知道了
如何解決粘包問題？明確包的邊界
- 對于定長的包，每次都按照固定大小讀取即可
- 對于變長的包，可以在包與包之間明確分隔符（應用協議，程序員自己定，只要保證分隔符和正文不起沖突即可）?
4. TCP的異常情況?
- 進程終止：進程終止會釋放文件描述符，仍然可以發送FIN，和正常關閉沒有什么區別
- 機器重啟：和進程終止的情況相同
- 機器掉電/網線斷開：接收端認為連接還在，一旦接收端有寫入操作，接收端發現連接已經不在了就會進行reset，即使沒有寫入操作，TCP自己也內置了一個保活定時器，會定期詢問對方是否還在，如果對方不在，也會把連接釋放
- 另外，應用層的某些協議，也有一些這樣的檢測機制，例如HTTP長連接中，也會定期檢測對方的狀態，例如QQ，在QQ斷線之后，也會定期嘗試重新連接?
5. TCP協議特點總結
- 有連接：通過三次握手建立連接后才可接發數據，TCP協議是全雙工的，即每端既可以發也可以收
- 可靠傳輸：網絡數據傳輸是一跳一跳的，經過路途中的設備可能發生數據丟失，可靠傳輸是可能發生數據丟失但有機制保證對方能接收到
- 面向字節流：可以多次的收發數據（連接沒有關閉時，可以多次的接收和發送數據）
- 有接收緩沖區和發送緩沖區：發送數據時，是先寫到發送緩沖區，再刷新緩沖區（flush）
- 大小不受限制：多次的收發數據，每次的數據可以很大?
6. 基于TCP的應用層協議?
- HTTP
- HTTPS
- SSH
- Telnet
- FTP
- SMTP
也包括自己寫TCP程序時自定義的應用層協議?
總結
以上是生活随笔為你收集整理的【计算机网络】TCP协议详解的全部內容，希望文章能夠幫你解決所遇到的問題。
