作者:晨鐘暮鼓c
個人微信公眾號:程式猿的月光寶盒
1.說說TCP三次握手
1.0 在此之前,什么是TCP?
? TCP(傳輸控制協議)
? 1.面向連接的,可靠的,基于位元組流的傳輸層通信協議
? 2.將應用層的資料流分割成報文段并發送給目標節點的TCP層
? 3.資料包都有序號,對方收到則發送ACK確認,未收到則重傳
? 4.使用校驗和來檢驗資料在傳輸程序中是否有誤
**注: ACK--確認序號標志,即接收端物體對已成功收到的包的確認,(確認后+1)
? SYN--同步序號,用于建立連接程序
? 在連接請求中,SYN=1,ACK=0-->該資料段沒有使用捎帶的確認域,SYN=1,ACK=1-->連接應答捎帶一個確認域
? FIN:finish標志,用于釋放連接,等于1時,表示發送方已經沒有資料發送,即關閉資料流
? Sequence Numbe:資料包的序號,用來保證不丟包
1.1 "握手"是為了連接,TCP三次握手如上圖所示
**圖注:第一次握手,seq-->初始序號,x是任意正整數.發送的不能攜帶資料,但是,要消耗掉一個序號.
? 第二次握手,如果同意連接,就發出確認報文,ack=x+1(第一次握手中seq=x,1即上一個報文消耗的序列),同時,為自己的快取初始化序列號,即seq=y,SYN-RCVD:同步收到狀態.(也不能攜帶資料,并且也要消耗一個序號)
? 第三次握手,當TCP客戶行程收到確認報文之后,還要向服務器給出確認,ack=y+1(上一次seq=y,1是小號的序號),seq=x+1(先前告知客戶端序號+1),此時,客戶端連接建立,ESTAB-LESHED(已建立連接狀態),TCP規定,第三次握手的時候可以(也不是必須,如果不攜帶資料,就不會消耗序號)攜帶資料
? 當服務器接收到后,也進入,ESTAB-LESHED(已建立連接狀態),,雙方開始通信
?
? 在TCP/IP協議中,TCP協議提供可靠的連接服務,采用三次握手建立一個連接
? 第1次握手:建立連接時,客戶端發送SYN包(syn=j)到服務器,并進入 SYN_SENT(同步已發送)狀態,等待服務器確認
? 第2次握手:服務器收到SYN包,必須確認客戶的SYN(ack=j+1),同時,自己也發送一個SYN包(syn=k),即SYN+ACK包,此時服務器進入SYN_RCVD狀態;
? 第3次握手:客戶端接收到服務器的SYN+ACK包,向服務器發送確認包ACK(ack=k+1),此包發送完畢,客戶端和服務器進入ESTAB-LISHED狀態,完成三次握手.
1.2 為什么需要三次握手才能建立連接
? 為了初始化Sequence Number的初始值,通信的雙方要互相通知對方,自己的初始化的Sequence Number,也就是上圖中的x和y,這個Number要作為以后的資料通信的序,以保證接收到的資料不會因為網路的問題而亂序,即TCP會用這個序號來拼接資料,因此,在服務器回發他的Sequence Number(第二次握手之后),還需要發送確認報文給服務器,告知服務器,客戶端已接收到你發的初始化的Sequence Number了.
1.3 首次捂手的隱患---SYN超時
? 問題起因:
? Server收到Client的SYN,回復SYN-ACK時沒有收到ACK確認
? Server不斷重試直到超時,linux默認重試次數為5次,時間從一秒開始,每次翻倍. 5次總共31s,在第五次發出去之后還需要等待32s才能被判定為超時,總共31+32=63s,此時TCP斷開連接.
? 后果:
? 可能會讓服務器遭到SYN Flood的風險.
? 解決方案:
? linux下,SYN佇列滿后,通過tcp_syncookies(Sequence Number的簡稱)引數回發SYN Cookie
? 若正常連接則Client會回發SYN Cookie,直接建立連接
1.4 建立連接后,Client出故障怎么辦
TCP的保活機制
1.向對方發送保活探測報文,如果未收到回應則繼續發送
2.嘗試次數達到保活探測數仍未收到回應則中斷連接
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/10539.html
標籤：其他
上一篇：VoIP性能測驗工具輯一下載