HTTP是建立在TCP協(xié)議上的。

概念

TCP(Transmission Control Protocol)：傳輸控制協(xié)議

位碼: 即TCP標志位,有6種:

• SYN(synchronous建立聯機)
• ACK(acknowledgement 確認)
• PSH(push傳送)
• FIN(finish結束)
• RST(reset重置)
• URG(urgent緊急)

Sequence number(順序號碼) Acknowledge number(確認號碼)

其他概念:

seq: 序列號
ack: 確認序列號
ACK: 確認位碼
SYN: 發(fā)起連接標志位碼

簡單說

3次握手:

1. 客戶端發(fā)送連接請求到服務端,進入SYN-SENT 狀態(tài)
2. 服務端收到客戶端請求后,確認SYN成功后回復客戶端,進入SYN-RCVD 狀態(tài)
3. 客戶端收到服務端的回復,驗證ACK和ack后,給服務端回復一個確認報文,服務端確認通過后,進入ESTAB-LISHED狀態(tài),TCP連接建立成功

4次揮手:

1. 客戶端向服務端發(fā)送FIN位碼,表示要斷開連接,并進入FIN-WAIT-1第一階段等待狀態(tài)
2. 服務端接收到客戶端的斷開請求后,確認FIN成功后,給客戶端回復一段報文,服務端進入CLOSE-WAIT 關閉等待狀態(tài),客戶端進入FIN-WAIT-2第二階段等待狀態(tài)
3. 服務端繼續(xù)發(fā)送剩余的數據,等發(fā)送完后立即向客戶端發(fā)送FIN和ACK位碼,等待客戶端確認,自身進入LAST-ACK最終確認狀態(tài)
4. 客戶端接收到服務端的斷開請求,先確認服務端返回的報文,確認成功后給服務端發(fā)送最后的確認報文;服務端接收到確認報文后立馬關閉連接,而客戶端會進入2MSL(一個請求來+回的時間)的等待,之所以要等待,因為如果第四次揮手的報文丟失,服務端無法收到確認報文,就會重發(fā)第三次揮手的報文,報文一來一回的時間就是2MSL

詳細版

http的3次握手":

• 第一次握手: 客戶端 -> 服務端,發(fā)送連接請求,進入 SYN-SENT 狀態(tài)
  • 發(fā)送SYN=1給服務端
  • 發(fā)送seq=x,序列號給服務端,seq叫做序列號,x是個隨機數
  • 進入 SYN-SENT 狀態(tài)
• 第二次握手: 服務端校驗 + 服務端到客戶端,返回請求,進入 SYN-RCVD 狀態(tài)
  • 服務端收到SYN并且SYN=1,明白是客戶端請求建立連接(服務端校驗)
  • 返回SYN=1給客戶端
  • 返回ACK=1給客戶端
  • 返回seq=y,一個新的序列號,也是隨機生成
  • 返回ack=x+1給客戶端
  • 進入 SYN-RCVD 狀態(tài)
• 第三次握手: 客戶端校驗 + 客戶端 -> 服務端 + 服務端校驗
  • 客戶端收到回復發(fā)現ACK=1并且ack=x+1,也就是第一次握手時發(fā)送給服務端的seq,驗證通過(客戶端校驗)
  • 客戶端發(fā)送ACK=1給服務端
  • 客戶端發(fā)送seq=x+1,ack=y+1
  • 服務端收到后發(fā)現 ACK=1并且ack=y+1,驗證成功,連接建立成功

4次揮手:

假如:
建立連接時(第一次握手)的seq=x,客戶端共發(fā)送了n個字節(jié)的數據;
服務端初始(第二次我搜狐)返回的seq=y,服務端共發(fā)送了m個字節(jié)的數據.

• 第一次揮手: 客戶端 -> 服務端
  • 客戶端向服務端發(fā)送FIN=1
  • seq=u,u=x+1+n(其中的1是建立連接時占的一個序列號)
  • 進入: SYN-WAIT2 狀態(tài)
  • 此時客戶端不再發(fā)送數據,但還可以接收數據
• 第二次揮手: 關閉等待狀態(tài): 服務端驗證 + 服務端 -> 客戶端
  • 服務端收到 FIN并且FIN=1,知道客戶端想要斷開連接(服務端驗證)
  • 返回ACK=1給客戶端
  • 返回seq=v給客戶端,v=y+m
  • 返回ack=u+1給客戶端
  • 進入CLOSE-WAIT狀態(tài),這時不是立馬發(fā)送FIN給客戶端,因為可能還有數據沒有發(fā)送完
• 第三次揮手: 數據發(fā)送完成: 服務端 -> 客戶端
  • 服務端將最后的數據(如 o個字節(jié))發(fā)送完畢后向客戶端發(fā)送釋放報文: FIN=1
  • 服務端發(fā)送ACK=1給客戶端
  • 服務端發(fā)送seq=w給客戶端,w=v+o
  • 服務端發(fā)送ack=u+1給客戶端,這個ack與第二次揮手的值一樣
• 第四次揮手: 客戶端驗證 + 客戶端 -> 服務端 + 服務端驗證
  • 客戶端收到服務端的FIN并且FIN=1,知道服務端同意關閉連接(客戶端驗證)
  • 客戶端發(fā)送ACK=1給服務端(客戶端確認報文, 客戶端 -> 服務端)
  • 客戶端發(fā)送ack=w+1給服務端(客戶端確認報文, 客戶端 -> 服務端)
  • 客戶端發(fā)送seq=u+1給服務端(客戶端確認報文, 客戶端 -> 服務端)
  • 客戶端進入2MSL的等待期(最長報文段壽命的2倍時長)后釋放TCP連接
  • 服務端收到客戶端的確認報文后立馬釋放TCP連接,所以服務端結束TCP連接的時間要比客戶端早一些。

第四次揮手后為什么要進行2MSL時間的等待?
考慮丟包的問題，如果第四次揮手的報文丟失，服務端沒收到確認ack報文就會重發(fā)第三次揮手的報文，這樣報文一去一回最長時間就是2MSL，所以需要等這么長時間來確認服務端確實已經收到了。

HTTP2 比 HTTP1.X 的優(yōu)勢

• 增加二進制解析，1.x是文本解析
• 多路復用： 即連接共享，原來是一次請求一個連接建立和斷開過程，現在支持一次連接可以進行多次請求，解決了同域名下并行下載數量的限制(chrome是6個，其他瀏覽器也不會超過10個)
• 頭部壓縮，減小了數據包大小

TCP三次握手和四次揮手的好處

確保數據的安全和完整。

響應頭: 服務器會告訴瀏覽器數據的長度，瀏覽器數據長度和響應頭數據長度相同，說明數據已經接收完畢了。

TCP和UDP對比

• TCP連接的建立要通過3次握手和4次揮手,確保數據傳輸的完整性和安全性
• UDP連接沒有TCP復雜,通過暴力手段傳輸數據,而不管接收方是否能全部接受到,常見應用有: 音視頻通話
• TCP面向連接,擁有可靠性,有序性,UDP都沒有這些優(yōu)點
• TCP有流量控制能力,TCP通常在發(fā)送包之前會測試網絡的快慢情況
• TCP是重量級的,UDP是輕量級的: 因為TCP要保證可靠性和有序性，所以TCP數據報文報頭的信息量大，報頭大小是20個字節(jié)，UDP報頭的大小是8個字節(jié)。所以TCP占用的系統(tǒng)的開銷大。
• TCP沒有數據邊界,UDP有數據邊界: 因此TCP容易發(fā)生粘包的現象。在UDP中數據包是單獨發(fā)送的，只有當他們到達時才會再次集成，包有明確的界限來判斷哪些包已經收到。
• UDP用來:在線視頻媒體，電話視頻聊天，qq聊天，電視廣播，多人在線游戲,DOS攻擊也是利用UDP,是利用犧牲傳輸可靠性換取時實性