HTTP報文格式、TCP、IP報頭,以及鏈接過程總結

本身總結了一下tcp報頭,,ip報頭和三次握手四次揮手的過程,以及狀態鏈接圖中鏈接斷開的過程,以此記錄。緩存

關於TCP、IP報頭,以及鏈接過程總結

TCP報頭

圖片描述

  1. 首先是源端口號和目標端口號,各佔16位,標誌的鏈接的端口號和被鏈接的端口號,它和IP報頭中的源IP以及目的IP一塊兒標識出一條TCP的連接。
  2. 而後是序號seq,這個佔32位,增加由1-2^32-1,它由數據字節號增加,增加範圍在0~2^32-1,換句話說也就是說對於發送數據的長度計數。
  3. 下來則是確認序號ack,也是佔32位,當ACK爲1時候有效,它的值通常爲seq+1。
  4. 首部長度,佔4位,,用來記錄TCP的報頭長度,它的值能夠直接偏移到數據位置。
  5. 後面則是保留了6位,規定不能使用。
  6. URG,佔一位,當爲1時標誌緊急指針有效。
  7. ACK,佔一位,當爲1時標誌ack確認序號有效。
  8. PSH,佔一位,當爲1時標誌緊急傳輸,也就是說這個包應當不用等待緩衝區放滿就能夠發送。
  9. RST,佔一位,當爲1時標誌重置鏈接,用於復位。
  10. SYN,佔一位,當爲1時標誌發起鏈接請求。
  11. FIN,佔一位,當爲1時標誌發起斷開鏈接的請求。
  12. 窗口大小,佔16位,指出接收方的接收窗口的大小,控制流量。
  13. 校驗和,佔16位,將總TCP報文計算出一個校驗值放入其中,用於檢驗。
  14. 緊急指針,佔16位,TCP是面向數據流的協議,但當有時一些應用程序在某些緊急狀況下(如在某些鏈接中進行強制中斷),要求在接收方在沒有處理完數據以前就可以發送一些緊急數據,這就使得發送方將CODE字段的URG置爲1 即緊急指針字段有效,這樣能夠沒必要考慮你發送的緊急數據在數據流中的位置,也就是至關於優先級最高,緊急指針指出的是緊急數據在報文段中結束的位置。
  15. 選項,在下面單獨說。

TCP報頭選項

圖片描述

  1. 0:選項結束
  2. 1:空選項,通常用來將報文填充到4字節整數倍
  3. 2:服務器

    • 最大報文段長度選項,通訊雙方在鏈接初始化的時候用此選項來協商最大報文段長度MSS。
    • TCP模塊通常將MSS設置爲(MTU-40)字節(減去TCP報頭20字節,減去IP報頭20字節),這樣攜帶TCP報文段的IP數據報長度就不會超過MTU,從而避免IP分片。
    • 通常MSS值爲1460字節(1500-40)。
  4. 3:tcp

    • 是窗口擴大選項,TCP鏈接初始化時候雙方用該選項來協商接收窗口的擴大因子,在TCP頭部中,接收通告窗口大小是用15位來表示的,所以最大爲65535字節。但實際TCP模塊容許的窗口大小遠不止這個數(提升TCP通訊吞吐量)。
    • 擴大選項是一個移位數,若是窗口大小爲M,移位數爲n,那麼至關於M*2n字節,也就是M左移n位
  5. 4:確認性選擇(Selectibe Acknoewledgment, SACK)選項。TCP通訊時,某個報文段丟失則TCP模塊會重傳被確認的TCP報文段後面全部的後續報文。SACK便是改善這種狀況使TCP只發送丟失的報文段,不用發送全部的未確認報文段的技術,在TCP鏈接初始化時,用該選項來確認是否支持SACK技術
  6. 5:是SACK技術工做時候的選項。該選項告訴發送端本端已經接收並緩存且不連續的數據塊,使得發送方檢查重發丟失的報文段。
  7. 8:時間戳選項,該選項提供了較準確的計算通訊雙方之間的迴路時間(RTT)的方法,從而爲TCP流量控制提供重要信息。

IP報頭

圖片描述

  1. 版本號,佔4位,用來指明IP版本號。
  2. IP頭長度,佔4位,用來指明IP報頭長度值,能夠用來偏移到數據位置。
  3. 服務類型,佔用8位性能

    有3bits的優先權字段,如今已經閒置。
    4bitsTOS字段,這四位中只能有一個爲1,用來選中選項,分別是最小時延,最大吞吐量,最高可靠性,最小費用。
    1bit棄用。
  4. 總長度,佔16位,記錄整個報文長度。
  5. 標識,佔16位,用來標識數據報序號。
  6. 標誌,佔3位。測試

    【2】爲1標誌這是最後一個分段。
    【1】爲1標誌這個數據報可分段。
    【0】保留,統一置零。
  7. 片偏移,佔13位,,標誌這段數據在本來數據中所處的位置。
  8. 生存時間,TTL,佔8位,由DNS查詢到所訪問的目標服務器這個過程來計時,而後保存在DNS緩存中,當DNS緩存過時時再重複這個過程。與其說它是個時間,不如說它更像一個跳數,每通過一個路由,規定路由對於這個字段的值至少減1,當它爲零時候這個數據報會被拋棄,以用來處理永遠抵達不了的數據。
  9. 協議,佔8位,用來指明處理後由哪一個上層協議來接收,例如TCP。
  10. 頭部校驗和,佔16位,確保IP報頭信息。
  11. 源IP,佔用32位,標記發送方的IP地址。
  12. 目的IP,佔用32位,標記目標方的IP地址。
  13. 選項,可選,最多40位,會用0填充以保證是32的倍數。

三次握手

圖片描述

第一二次鏈接時候不能加數據,也必須消耗序號。
在第三次握手時候,能夠加入數據,那麼會消耗序號,可是若是不攜帶數據的話是不消耗數據的,下次發送時候seq = x + 1。

四次揮手

圖片描述

四次揮手這個過程也是能夠在三次完成的,也就是將二三合一,服務器同時將ACK和FIN返回給客戶端,那麼就能夠簡潔到三次揮手。

狀態轉移圖斷開

圖片描述

圖片描述


加入一個HTTP的報文格式,emmmmm,好像違背了開閉原則哈,連題目都改了。。。。。編碼

HTTP請求報文格式:

圖片描述

  1. 請求方法spa

    GET:請求獲取Request——URL所標識的資源
    POST:在Request——URL所標識的資源後附加資源
    HEAD:請求獲取由Request——URL所標識的資源的響應消息報頭
    PUT:請求服務器存儲一個資源,由Request——URL做爲其標識
    DELETE:請求服務器刪除由Request——URL所標識的資源
    TRACE:請求服務器回送收到的請求信息(用於測試和診斷)
    CONNECT:保留
    OPTIONS:請求查詢服務器性能
  2. URL
    URI全名爲Uniform Resource Indentifier(統一資源標識),用來惟一的標識一個資源,是一個通用的概念,URI由兩個主要的子集URL和URN組成。URL全名爲Uniform Resource Locator(統一資源定位),經過描述資源的位置來標識資源。URN全名爲Uniform Resource Name(統一資源命名),經過資源的名字來標識資源,與其所處的位置無關,這樣即便資源的位置發生變更,其URN也不會變化。
  3. 協議版本
    格式爲 HTTP/主版本號.次版本號,經常使用爲:HTTP/1.1 HTTP/1.0
  4. 請求頭部3d

    Host:接受請求的服務器地址,能夠是IP或者是域名
    User-Agent:發送請求的應用名稱
    Connection:指定與鏈接相關的屬性,例如(Keep_Alive,長鏈接)
    Accept-Charset:通知服務器端能夠發送的編碼格式
    Accept-Encoding:通知服務器端能夠發送的數據壓縮格式
    Accept-Language:通知服務器端能夠發送的語言

HTTP響應報文:

圖片描述

    1. 協議版本,同請求報文
    2. 狀態碼,100~199表示請求已收到繼續處理,200~299表示成功,300~399表示資源重定向,400~499表示客戶端請求出錯,500~599表示服務器端出錯指針

      200:響應成功
      302:跳轉,重定向
      400:客戶端有語法錯誤
      403:服務器拒絕提供服務
      404:請求資源不存在
      500:服務器內部錯誤
    1. 響應頭部orm

      Server:服務器應用軟件的名稱和版本 Content-Type:響應正文的類型 Content-Length:響應正文的長度 Content-Charset:響應正文所使用的編碼 Content-Encoding:響應正文使用的數據壓縮格式 Content-Language:響應正文使用的語言
    相關文章
    相關標籤/搜索