網(wǎng)絡協(xié)議

網(wǎng)絡協(xié)議

網(wǎng)絡的五層劃分是什么?

  • 應用層,常見協(xié)議:HTTP、FTP
  • 傳輸層,常見協(xié)議:TCP.UDP
  • 網(wǎng)絡層,常見協(xié)議:IP
  • 鏈路層
  • 物理層

TCP 和 UDP 的區(qū)別是什么

  • TCP/UDP 都屬于傳輸層的協(xié)議
  • TCP 是面向連接的傳輸層協(xié)議,能夠準確可靠的把數(shù)據(jù)傳遞給對方,當數(shù)據(jù)有丟包情況會重發(fā),但是需要在建立和斷開連接需要至少7次的發(fā)包和收包,會浪費網(wǎng)絡流量,主要用在對可靠性要求較高的地方。
  • UDP 是面向無連接的傳輸層協(xié)議,意思是只負責傳輸數(shù)據(jù),不能確保對方是否收到數(shù)據(jù)和數(shù)據(jù)的正確順序,數(shù)據(jù)的正確性由應用層來校驗。主要用于高速傳輸和實時性要求較高的場合如音視頻會議,廣播。

TCP 三次握手和四次揮手

  • 先來張圖
    image
  • 來張 wireShark 抓取的 tcp
    image

    image

TCP 三次握手

  • TCP 三次握手圖
    image
  1. 第一次握手:客戶端向服務器端發(fā)起請求,在請求中攜帶一個 SYN=1 標志,并攜帶一個隨機數(shù) seq = x,這時客戶端進入 SYN_SENT 狀態(tài),等待服務器確認
    image
  2. 第二次握手: 服務器端收到了該消息,由 SYN=1 可以知道客戶端請求建立連接,服務器將 SYN 和 ASK 都置為1,ask=x+1,隨機產(chǎn)生一個值 seq =k,并將數(shù)據(jù)包發(fā)送給客戶端以確認連接請求,服務器端進入 SYN_RCVD 狀態(tài)
    image
  3. 第三次握手: 客戶端接收到了該消息,檢查 ACK 是否為1,ack 是否為 x+1 , 如果正確則將標志位 ACK 置為1, ack = k+1,并將該數(shù)據(jù)包發(fā)送給服務器端,服務器端檢查 ACK 是否為1,ack 是否為 k+1,如果正確則連接建立成功,服務器端和客戶端進入 ESTABLISHED 狀態(tài),完成三次握手,隨后服務器端和客戶端可以開始傳輸數(shù)據(jù)。
    image
  • 為什么需要三次握手才能建立連接,兩次不可以嗎?

TCP 四次揮手

image

image

image

image

  1. 第一次揮手:client 發(fā)送報文,標志位 FIN =1,seq = n,此時客戶端進入到 FIN_WAIT_1 狀態(tài),表示客戶端沒有數(shù)據(jù)要發(fā)送給服務器
  2. 第二次揮手:服務端收到客戶端發(fā)送的 FIN 報文,向客戶端回一個 ACK =1 的報文,
  3. 第三次揮手:
  4. 第四次揮手:

https://blog.csdn.net/sssnmnmjmf/article/details/68486261
https://blog.csdn.net/oney139/article/details/8103223

  • 針對本人對 TCP 三次握手和四次揮手不了解,還有網(wǎng)絡上各種文章充斥甚至于兩篇文章都矛盾,所以使用 wireShark 對 Android 通訊進行了抓包,然后根據(jù)抓到的數(shù)據(jù)學習下 TCP 三次握手和四次揮手
  • 環(huán)境
    • whireShark: 2.6.1
    • Android device: HTC D820U
    • Android Version: 6.0
    • Android IP : 192.168.123.103
    • Destination IP : 183.192.196.182
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容