TCP基礎知識有哪些

本篇內容介紹了“TCP基礎知識有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

TCP報文段： 概念：分為頭部和數據兩部分。

TCP報文段頭部中的字段：
	源端口/目的端口	這兩個字段與IP頭部中的源IP地址和目的IP地址一起, 唯一地標識了每個連接。一個ip地址和一個端口的組合被稱為一個socket或一個endpoint。
	序列號(seq)		本報文段所發送的數據的第一個字節的序列號，seq的值等于前面已發送過的數據的最后一個字節的序列號+1。(TCP傳輸時將每個字節的數據都進行了編號，這個編號就是序列號)
	確認號(ack)		期望收到對方下一個報文段的第一個數據字節的序列號，若ack為x，則到序號x-1為止(包括x-1)的所有數據都已正確收到。
	確認(ACK)		僅當ACK=1時，ack字段才有效，當ACK=0時，ack無效。
	同步(SYN)		SYN=1且ACK=0 表明這是一個連接請求報文段，若對方同意建立連接，則對方應在響應報文中包含SYN=1和ACK=1。
	終止(FIN)		FIN=1表明此報文的發送方已經結束向對方發送數據，并要求釋放連接。
	重置(RST) 		重置連接。
	窗口大小			接收端接收緩沖區剩余的大小。這是一個16位的字段，單位是字節數。窗口大小字段最大能表示65535個字節(64K)，
					但是TCP的接收窗口大小最大并不是64K。TCP實際的接收窗口大小為16位窗口大小字段的值左移M(M表示：窗口擴大因子)位，每移一位，窗口擴大兩倍。

	校驗和 			該字段覆蓋了TCP頭部和數據，由發送方進行計算，然后由接收方來驗證。
					其目的是為了發現TCP頭部和數據在發送端到接收端之間發生的任何改動，如果接收方檢測到校驗和有差錯，則TCP報文會被直接丟棄。


	說明：
		在連接建立后所有傳送的報文都必須把ACK置1。
		SYN報文段、FIN報文段不能攜帶數據，但會消耗掉一個序列號。
		ACK報文段可以攜帶數據，但如果不攜帶數據則不消耗序列號。

TCP數據

TCP三次握手

概念：建立一個TCP連接時，客戶端和服務器需要交互3次，即發送3次TCP報文段，故稱為3次握手。

目的：與服務器建立TCP連接，并同步連接雙方的序列號、確認號、TCP窗口大小等信息。

說明：
	三次握手改為兩次握手會產生死鎖：
		兩次握手：A發送連接請求報文，B接收A的請求報文并發出確認報文后，則認為連接建立。
		舉例：A發送連接請求報文，B收到A的請求報文并發出確認報文，如果B的確定報文在傳輸過程中丟失了，此時，B認為連接已建立并開始發送數據，而A一直在等待著B的確定報文，且不會接受B發送的數據，而B在發送數據后將一直處于等待A確定的狀態中，從而造成A和B相互等待，形成死鎖。

第一次握手：
	客戶端向服務器發出連接請求報文段(報文段頭部：(初始)序列號seq=x、同步SYN=1)，此時客戶端進入SYN_SENT(同步已發送)狀態。
	說明：同步SYN=1會消耗一個序列號位，即把x這個序列號位給占了，故下次發送的序列號應該從x+1開始，第一次揮手時的FIN也同理。

第二次握手：
	服務器收到連接請求報文段后，若同意建立連接，則向客戶端發送響應報文段(報文段頭部：同步SYN=1、確認ACK=1、確認號ack=x+1、序列號seq=y，此時服務器進入SYN_RECV(同步已收到)狀態。此時的TCP連接稱為半連接(half-open connect)。

第三次握手：
	客戶端收到服務器的響應報文段后，再次向服務器發出用于確認的報文段(報文段頭部：同步SYN=0、確認ACK=1、確認號ack=y+1、序號seq=x+1)，此時TCP連接已建立，客戶端和服務器都進入ESTABLISHED(已建立連接)狀態。

TCP四次揮手

概念：釋放一個TCP連接時，客戶端和服務器需要交互4次，即發送4次TCP報文段，故稱為4次揮手。

說明：
	1)斷開TCP連接 即 客戶端關閉發送數據的通道 并且 服務器關閉發送數據的通道。
	2)為什么連接的時候是三次握手，關閉的時候卻是四次握手：
		1>建立連接時：當Server端收到Client端的SYN連接請求報文后，Server端可以直接發送SYN+ACK報文，其中ACK報文是用來應答的，SYN報文是用來同步的。
		2>關閉連接時：當Server端收到Client端的FIN報文后，Server端很可能不會立即關閉SOCKET，而是先回復一個ACK報文，告訴Client端，"你發的FIN報文我收到了，但是我(可能)還有數據要發送"，當Server端所有的報文都發送完了，Server端才會發送FIN報文，即Server端通知Client端的過程中需要揮兩次手，故在關閉連接的時候總共需要四次揮手。

第一次揮手：
	客戶端向服務器發出連接釋放報文段(報文段頭部：終止FIN=1、序號seq=u)，并停止發送數據，主動關閉TCP連接，此時客戶端進入FIN_WAIT1(終止等待1)狀態。

第二次揮手：
	服務器收到客戶端的連接釋放報文段后，向客戶端發送確認報文段(報文段頭部：確認ACK=1、確認號ack=u+1、序號seq=v)，此時服務器進入CLOSE_WAIT(關閉等待)狀態，并通知應用進程。
	客戶端收到服務器的確認報文段后，進入FIN_WAIT2(終止等待2)狀態。
	此時，客戶端已經沒有數據要發送了，但是服務器可能還有數據要發送，且客戶端依然可以接受服務器發送的數據，此時的TCP連接處于半關閉狀態。

第三次揮手：
	應用進程通知服務器釋放連接后，服務器發出連接釋放報文段(報文段頭部：確認ACK=1，終止FIN=1、序號seq=w(在半關閉狀態時服務器可能又發送了一些數據)、確認號ack=u+1)，此時服務器進入LAST_ACK(最后確定)狀態。

第四次揮手：
	客戶端收到服務器的連接釋放報文段后，向服務器發送確定報文段(報文段頭部：確認ACK=1、序號seq=u+1、確認號ack=w+1)，此時客戶端進入到TIME-WAIT(時間等待)狀態，等到等待時間過后，二者才都進入到CLOSED(關閉)狀態。

SYN攻擊： 概念：SYN攻擊是一個典型的DDOS(Distributed Denial of Service:分布式拒絕服務)攻擊。

原理：
	客戶端在短時間內偽造大量不存在的IP地址，然后向服務器不斷地發送SYN包(即不斷地發起第一次握手，建立大量的半連接狀態的請求)，
	服務器收到連接請求后發送響應報文，并等待客戶的確認，由于源地址是不存在的，故服務器需要不斷的重發直到超時，
	這些偽造的SYN包將長時間占用未連接隊列(syns queue)，正常的SYN請求被丟棄，目標系統運行緩慢，嚴重者引起網絡堵塞甚至系統癱瘓。

檢測：
	查看狀態為SYN_RECV的TCP連接：	netstat -npt | grep SYN_RECV   # 若Foreign Address的ip地址是隨機的，則服務器此時很可能正在被SYN攻擊。
	統計TCP連接的狀態：			netstat -npt | awk '{print $6}' | grep -v "Foreign" | sort | uniq -c

說明：一般較新的TCP/IP協議棧都對這一過程進行修正來防范SYN攻擊，修改tcp協議實現。主要方法有SynAttackProtect保護機制、SYN cookies技術、增加最大半連接和縮短超時時間等.但是不能完全防范SYN攻擊。

socket編程： Socket.connect() 會觸發TCP的三次握手。 Socket.close() 會觸發TCP的四次揮手。表示不發送數據也不接受數據了。

超時重傳： 概念：TCP傳輸數據時，發送方發送數據后會等待接收方響應的ACK報文，并根據ACK報文來判斷數據是否傳輸成功。如果發送方發送完數據后，長時間沒有等到接收方的ACK報文，那么發送方會重新發送這些數據。

發送方沒有收到ACK報文的原因：
	數據在傳輸過程中由于網絡原因等直接全體丟包，接收方根本沒有接收到。
	接收方接收到了響應的數據，但是響應的ACK報文卻由于網絡原因丟包了。之后接收方若再次收到發送方重新發送的數據(根據序列號可判斷是否是重復數據)，則會將這些重復的數據丟棄，但是仍然會響應ACK報文。

超時時間的計算：
	默認500ms，重發一次后，若仍沒有響應，那么等待2*500ms的時間后，再次重傳。重傳的次數達到某個值后，TCP就認為網絡已經斷了或對方出現異常了，然后強制關閉連接。
	超時時間過長會降低TCP傳輸的整體效率。超時時間過短會導致頻繁的發送重復的包。

窗口機制： 概念：每個TCP連接的兩端都維護了一個發送窗口和一個接收窗口。

發送窗口：
	發送方的發送緩存內的數據都可以被分為4類，其中類型2和類型3屬于發送窗口：
		1>已發送，已收到ACK 
		2>已發送，未收到ACK 
		3>未發送，但允許發送 
		4>未發送，但不允許發送
接收窗口：
	接收方的緩存數據分為3類，其中類型2屬于接收窗口：
		1>已接收 
		2>未接收但準備接收 
		3>未接收而且不準備接收

滑動機制：
	發送窗口只有收到發送窗口內字節的ACK確認后，才會移動發送窗口的左邊界。
	接收窗口只有在前面所有的報文段都確認的情況下才會移動左邊界。
	若接收窗口前面還有字節未接收，此時如果收到后面的字節，則接收窗口不會移動，TCP也不會對后面的字節發送確認，發送方超時后會重傳這些數據。

流量控制： 概念：TCP根據接收端對數據的處理能力(窗口大小字段的值)來決定發送端的發送速度。 過程： 接收端在確認應答時發送ACK報文，ACK報文中包含了自己接收窗口的大小，發送方根據ACK報文里窗口大小的值的來設定自己發送數據的速度。 若ACK報文中窗口大小的值為0，那么發送方將停止發送數據，并定期向接收端發送窗口探測數據段，以便及時地獲取接收端最新窗口大小的值。

說明：如果發送端發送的數據太快，則接收端的接收緩沖區很快就會被填滿，接受端的接收緩存區被填滿后，發送端再發送的數據就會被接收端丟棄，進而觸發發送端的超時重傳。

擁塞控制： 概念：路由器因無法處理高速率到達的流量而被迫丟棄數據的現象稱為擁塞。 擁塞的原因：當路由器在單位時間內接收到的數據量大于其可發送的數據量時，路由器就需要把多余的數據存儲起來。若接收到的數據量持續大于可發送的數據量，那么會耗盡路由器的存儲資源，導致路由器丟棄部分數據。

原理：發送方維持一個擁塞窗口變量cwnd，擁塞窗口的大小取決于網絡的擁塞程度，發送方的發送窗口大小取 擁塞窗口的大小 和 接收端的接收窗口大小 的較小值，TCP通過動態地調整發送窗口的大小來實現擁塞控制。

慢啟動機制：
	擁塞窗口的初始值為1，發送方每次收到ACK報文后，將擁塞窗口的值加1。
	慢啟動中的"慢"，表示剛開始發送的數據少，發送的速度慢，但是擁塞窗口值的增長是指數級別的增長，故增長的非常快。當擁塞窗口的值達到閾值時，擁塞窗口值的增長就改為線性增長。
	在慢啟動開始的時候，慢啟動的閾值等于窗口的最大值，TCP一旦發現網絡擁塞，慢啟動的閾值將會變為當前閥值的一半，同時擁塞窗口重置為1。

TCP的可靠性： 連接管理：三次揮手四次握手 傳輸數據： 序列號和確認號機制 校驗和 超時重傳機制 流量控制 擁塞控制

常見問題：

服務器返回“RST”的問題： 分析：服務器關閉connection后，若客戶端還在connection上讀寫，服務器內核接收到數據后發現Socket已經close了，此時服務器會返回“RST”標志給客戶端。 說明： 服務器返回了“RST”時，若此時客戶端正在從Socket套接字的輸出流中讀數據則會提示Connection reset” 服務器返回了“RST”時，若此時客戶端正在往Socket套接字的輸入流中寫數據則會提示“Connection reset by peer”

解決：重試。

“TCP基礎知識有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！