重慶分公司,新征程啟航
為企業提供網站建設、域名注冊、服務器等服務
為企業提供網站建設、域名注冊、服務器等服務
TCP報文段傳輸控制協議(TCP,Transmission ControlProtocol)是一種面向連接的、可靠的、基于字節流的傳輸層通信協議,由IETF的RFC 793 定義。TCP協議建立的是一種點到點的,一對一的可靠連接,與UDP相比以犧牲效率為代價換取高可靠性的服務。
在阜新等地區,都構建了全面的區域性戰略布局,加強發展的系統性、市場前瞻性、產品創新能力,以專注、極致的服務理念,為客戶提供網站設計、成都做網站 網站設計制作定制網站建設,公司網站建設,企業網站建設,品牌網站設計,全網整合營銷推廣,成都外貿網站建設,阜新網站建設費用合理。
TCP報文段也叫TCP分組,是TCP協議傳輸和接收數據的一種封裝格式,只有按照該格式發送的數據才可以被TCP協議通信的雙方正確的接收與解析。
TCP報文的組成部分描述如下:
TCP連接的建立是通過三次握手的過程完成的,下面將具體講解何為三次握手:
第一次握手由客戶端向服務器 發出:客戶端發送一個TCP數據報,其中,TCP分組的源端口為客戶端發起通信建立的進程端口,而目的端口為服務器處理請求的進程端口號,比如80端口。在表示建立連接的TCP分組中,SYN標志位為被置1,則告知服務器發送該分組的目的是請求建立連接,并且當SYN置1時,該分組中的seq字段發送的是初始序列號cilent_isn,初始序列號的取值方案有多種,一般取隨機值。
第二次握手第二次握手由服務器向客戶端發出:服務器在成功接收了客戶端第一次握手發送的分組后,首先需要解析收到的TCP分組,發現SYN置1后,得知這個客戶端發送分組的目的是為了建立連接,在確認完畢分組信息后,服務器也會向客戶端發送一個TCP分組來代表第二次握手。
這個由服務器發送的TCP分組包含以下內容:
第三次握手由客戶端向服務器發出:客戶端在接收到服務器第二次握手的回復之后,同樣會接收來自于服務器的TCP分組并進行解讀:由SYN為1解讀該TCP分組的目的是繼續建立連接,由分組中的ACK確認號了解到服務器已經成功接收了前cilent_isn個字節的內容,并期望接收第cilent_isn+1個字節的字節序號,同時累計確認來自服務器的初始序列號。并發送最后一個TCP分組給服務器來完成第三次握手。
這個由客戶端發送給服務器的最后一個TCP分組的內容有:
為什么TCP的連接必須進行三次握手,而不是一次或兩次?
為了防止建立重復的連接而損耗資源或造成其他問題
謝希仁版《計算機網絡》中的例子:“已失效的連接請求報文段”的產生在這樣一種情況下:client發出的第一個連接請求報文段并沒有丟失,而是在某個網絡結點長時間的滯留了,以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后,就誤認為是client再次發出的一個新的連接請求。于是就向client發出確認報文段,同意建立連接。假設不采用“三次握手”,那么只要server發出確認,新的連接就建立了。由于現在client并沒有發出建立連接的請求,因此不會理睬server的確認,也不會向server發送數據。但server卻以為新的運輸連接已經建立,并一直等待client發來數據。這樣,server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現象發生。例如剛才那種情況,client不會向server的確認發出確認。server由于收不到確認,就知道client并沒有要求建立連接。”
也就是說,假如只采用兩次握手,會讓因網絡錯誤延時到達的客戶端連接請求被服務器接收時,服務器無從得知這是一個失效的請求而與客戶端建立一個無效的連接。在三次握手機制的情形下,這樣無效的請求分組會被返回給客戶端來確認,而客戶端不在等待該由該分組產生第三次握手的狀態,服務器得不到客戶端的回應,等待超時后會取消本次連接的建立。從而避免了錯誤連接的建立
TCP拆除連接的過程(四次揮手)四次握手的連接關閉過程與三次握手相類似:四次揮手的過程簡述如下:
第一次揮手: 客戶端因為不再有數據發送給服務器,所以向服務器發送FIN報文表示想要關閉連接,不會再發送數據了。同時包含客戶端的報文序號M
第二次揮手: 服務器在接收了來自客戶端的FIN報文后,得知客戶端不再發送數據,將要關閉連接。但是,此時服務器端獲取還有部分數據沒有回傳給客戶端,服務器可能還要向客戶端發送一部分數據才能關閉連接。所以服務器不會立馬同意關閉連接,而是先發送表示確認信息的ACK報文,該ACK報文中包含了值為M+1的確認號。
第三次揮手: 在服務器端完成向客戶端傳送最后的數據后,此時不再有數據需要傳輸了。那么服務器也準備關閉連接,所以向客戶端發送表示關閉連接的FIN報文,報文中包含了服務器端的序號N
第四次揮手: 在客戶端也收到了服務器端發送的FIN報文之后,得知服務器端也可以關閉連接了,此時再向服務器發送最后一次確認報文ACK,使連接成功關閉,ACK報文中的確認號為N+1
為什么需要四次揮手?為什么需要中間兩次揮手?
為什么需要其中的第二次和第三次的原因其實已經提到,假如在服務器收到客戶端的第一次揮手就準備關閉連接發送FIN報文,不再發送數據。那么只是客戶端單方面提出了中斷通信的請求而導致連接關閉,使服務器中要發往客戶端的最后數據不能正常傳送,會導致通信不完整。
為什么需要第四次揮手?
第四次揮手同樣是用來解決一個因網絡時延滯后到達的失效請求的問題。
請分析這樣一個情形:即假如客戶端一次發送了兩個關閉請求,其中一個滯后了很久才到達,此時它們當時建立的連接已經被第一個請求關閉。而服務器又再次和客戶端建立了新的連接,并且此時不需要關閉,但是這個失效的關閉請求滯后到達了。
假如沒有最后一次揮手,那么服務器以為客戶端要關閉連接,一次發送ACK和FIN報文后連接就被錯誤關閉了,這樣顯然是存在問題的。
假如有最后一次握手,服務器在收到失效報文后仍然會發送ACK和FIN報文給客戶端來確認客戶端是否真的要關閉連接。而客戶端此時的狀態并不是等待關閉連接的狀態,所以不會給服務器發送ACK報文進行關閉連接的確認回復,服務器在等待一段時間超時后會取消連接的關閉,從而不會因為失效的報文讓連接錯誤地關閉。
TCP數據的發送過程也與建立連接的過程相類似:
發送數據的過程采用了累計確認的機制,其中ACK表示的是累積確認的字節序號。
如上圖,發送的TCP分組中可以包含數據,也可以不包含數據,但是一定需要包含seq序號和確認號。seq序號表示數據區中第一個字節的序號,而回傳的ack確認號的值為seq的值加上發送的數據字節數。表示這些字節的數據已經被確認接受了,并表達了期望接收的下一個字節序號位置。
發送TCP分組的一方會在發送分組時設置超時時間并開啟計時器,當在超時時間內未收到該分組的ACK回復時,會認為該分組丟失,并重發該分組。假如之前的分組被連續發送,而該分組及之后的分組已經被接收端確認,那么本次重復分組收到的ACK是累計確認的字節序號值,而非該分組的seq+數據字節數,如上圖右側所示。
感謝閱讀,求關注收藏,等期末考試結束后會再出關于TCP流量控制和擁塞控制等方面更加詳細的內容。超鏈接寫好后會附在下面。
本文參考了哈工大mooc計算機網絡的內容
你是否還在尋找穩定的海外服務器提供商?創新互聯www.cdcxhl.cn海外機房具備T級流量清洗系統配攻擊溯源,準確流量調度確保服務器高可用性,企業級服務器適合批量采購,新人活動首月15元起,快前往官網查看詳情吧