TCP-IP header

來源:互聯網
上載者:User

我們都知道,不同類型的網路,其MTU(最大傳輸單
元)各不相同,如乙太網路中,最大的傳輸幀為1518位元組,FDDI為4500位元組,令牌環幀在4500位元組到17800位元組之間,而IP協議的一個重要功
能,就是能夠對傳輸的資料大於硬體介面的MTU時,對其進行分段傳輸。即大於MTU的資料報將被分為2個或多個的合適的大小被傳輸。一個分區在到達接收主
機的路徑中,還可能被繼續分區,因此,分區的IP資料報可能會以不同的路徑傳輸到接收主機,接收主機通過一系列的重組,將其還原為一個完整的IP資料報,
再提交給上層協議處理。

 

IP標識符

 

IP標識符、標誌、位移量3個欄位在IP前序中的位置如1所示:

 

 

 

圖1

 

在發送資料報前,發送主機給每個資料報一個ID值,放在16位的標識符欄位中。此ID用於標
識唯一的資料報或資料流。接收主機利用此ID對收到的資料報進行重組。正如前面所說,當分區的IP資料報從源地址發送到目的地址的時候,由於網路延遲或者
不同的傳輸路徑的關係,在到達目的主機時,這些分區資料報並不總是有序的排列,而是處於一種無序狀態,因此,接收主機便用此ID判斷接收的這些分區資料報
是否屬於同一個資料流,然後再進行重組(重組將在位移量中討論)。

 

標誌

 

標誌欄位在IP前序中佔3位,第1位作為保留,置0;第2位,分段,有兩個不同的取值:該位
置0,表示可以分段;該位置1,表示不能分段;第3位,更多分段,同樣有兩個取值:該位置0,表示這是資料流中的最後一個分段,該位置1,表示資料流未
完,後續還有分段,當一個資料報沒有分段時,則該位置0,表示這是唯一的一個分段。見2:

 

 

 

圖2

 

當目的主機接收到一個IP資料報時,會首先查看該資料報的標識符,並且檢查標誌位的第3位是置0或置1,以確定是否還有更多的分段,如果還有後續報文,接收主機則將接收到的報文放在緩衝直到接收完所有具有相同標識符的資料報,然後再進行重組。

 

更多分段位能夠讓接收主機判斷分區的資料報是否發送完畢;而分段位除了能夠將將資料報分段,
而且還能夠實現另一個用途,在某些情況下,可以利用分段位動態找到網路端到端的MTU大小。如果路由器配置時,置此位為0,則當主機嘗試發送一個比傳輸
路徑上的資料報大的幀時,路由器不轉寄該幀,而是丟棄,並給源主機發送ICMP報文,說明該資料報太大,源主機利用此資訊調整資料報大小,再重新發送。

 

位移量

 

13位的位移量欄位用來表示分段的資料報在整個資料流中的位置,即相當於分區資料報的順序
號。發送主機對第一個資料報的位移量置為0,而後續的分區資料報的位移量則以網路的MTU大小賦值。位移量對於接收方進行資料重組的時候,這是一個關鍵的
欄位。對於分區的資料區段(單位:位元組)必須為8的整數倍,否則IP無法表達其位移量。如3所示:

 

 

 

圖3

 

乙太網路中,源主機如果需要通過UDP傳送3000位元組的資料到目的主機,這時的分段情況如4所示(在同一網段):

 

 

 

圖4

 

此處需要注意的是對於分區1的前序,相對於其他兩個分區的前序而言,要多出8個位元組UDP協議的前序開銷,因此,在計算實際傳輸的資料淨載荷時,分區1要多減去8位元組UDP前序。最後,接收主機通過此位移值將資料重組成完整的資料報。

 

總結

 

IP協議雖然是我們司空見慣的一個協議,但是,對於其前序結構,前序中每個欄位的含義,還是需要我們不斷學習,才能真正理解IP協議的精髓。在此,希望各位兄弟多多交流,大家一起學習。

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

  最近狂補基礎,猛看TCP/IP協議。不過,書上的東西太抽象了,沒有什麼資料執行個體,看了不 久就忘了。於是,搬來一個sniffer,抓了資料包來看,呵呵,結合書裡面得講解,理解得 比較快。我就來灌點基礎知識。 

  開始吧,先介紹IP協議。 

 
 IP協議(Internet
Protocol)是網路層協議,用在網際網路上,TCP,UDP,ICMP,IGMP資料都是按照IP資料格式發送得。IP協議提供的是不可靠無串連得服
務。IP資料包由一個頭部和一個本文部分構成。本文主要是傳輸的資料,我們主要來理解頭部資料,可以從其理解到IP協議。 

  IP資料包頭部格式(RFC791)

  Example Internet Datagram Header
 

  上面的就是IP資料的頭部格式,這裡大概地介紹一下。 

  IP頭部由20位元組的固定長度和一個可選任意長度部分構成,以大段點機次序傳送,從左到 右。 

  TCP協議
 

  TCP協議(TRANSMISSION CONTROL PROTOCOL)是傳輸層協議,為應用程式層提供服務,和UDP不同的是,TCP協議提供的可靠的連線導向的服務。在RFC793中是基本的TCP描述。關於TCP協議的頭部格式內容的說明: 

  TCP Header FORMat 

 

  TCP Header FORMat 

  跟IP頭部差不多,基本的長度也是20位元組。TCP資料包是包含在一個IP資料報文中的。 

 
 好了,簡單介紹到此為止。來看看我捕獲的例子吧。這是一次FTP的串連,呵呵,是cuteftp預設的cuteftp的FTP網站,IP地址
是:216.3.226.21。我的IP地址假設為:192.168.1.1。下面的資料就是TCO/IP串連過程中的資料轉送。我們可以分析TCP
/IP協議資料格式以及TCP/IP串連的三向交握(ThreeWay-Handshake)情況。下面的這些十六進位資料只是TCP/IP協議的資料,
不是完整的網路通訊資料。 

  第一次,我向FTP網站發送串連請求(我把TCP資料的可選部分去掉了) 

  192.168.1.1->216.3.226.21 

  IP頭部: 45 00 00 30 52 52 40 00 80 06 2c 23 c0 a8 01 01 d8 03 e2 15 

  TCP頭部:0d 28 00 15 50 5f a9 06 00 00 00 00 70 02 40 00 c0 29 00 00 

  來看看IP頭部的資料是些什麼。 

 
 第一位元組,“45”,其中“4”是IP協議的版本(Version),說明是IP4。“5”是IHL位,表示IP頭部的長度,是一個4bit欄位,最大
就是1111了,值為12,IP頭部的最大長度就是60位元組。而這裡為“5”,說明是20位元組,這是標準的IP頭部長度,頭部報文中沒有發送可選部分數
據。 

  接下來的一個位元組“00”是服務類型(Type of
Service)。這個8bit欄位由3bit的優先權子欄位(現在已經被忽略),4 bit的TOS子欄位以及1
bit的未用欄位(現在為0)構成.4
bit的TOS子欄位包含:最小延時、最大輸送量、最高可靠性以及最小費用構成,這四個1bit位最多隻能有一個為1,本例中都為0,表示是一般服務。 

 
 接著的兩個位元組“00
30”是IP資料報文總長,包含頭部以及資料,這裡表示48位元組。這48位元組由20位元組的IP頭部以及28位元組的TCP頭構成(本來截取的TCP頭應該是
28位元組的,其中8位元組為可選部分,被我省去了)。因此目前最大的IP資料包長度是65535位元組。 

  再是兩個位元組的標誌位(Identification):“5252”,轉換為十進位就是21074。這個是讓目的主機來判斷新來的分段屬於哪個分組。 

 
 下一個位元組“40”,轉換為二進位就是“0100
0000”,其中第一位是IP協議目前沒有用上的,為0。接著的是兩個標誌DF和MF。DF為1表示不要分段,MF為1表示還有進一步的分段(本例為
0)。然後的“0 0000”是分段便移(Fragment Offset)。 

  “80”這個位元組就是
TTL(Time To
Live)了,表示一個IP資料流的生命週期,用Ping顯示的結果,能得到TTL的值,很多文章就說通過TTL位來判別主控件類型。因為一般主機都有預設
的TTL值,不同系統的預設值不一樣。比如WINDOWS為128。不過,一般Ping得到的都不是預設值,這是因為每次IP資料包經過一個路由器的時候
TTL就減一,當減到0時,這個資料包就消亡了。這也時Tracert的原理。本例中為“80”,轉換為十進位就是128了,我用的WIN2000。 

  繼續下來的是“06”,這個位元組表示傳輸層的協議類型(Protocol)。在RFC790中有定義,6表示傳輸層是TCP協議。 

  “2c 23”這個16bit是頭校正和(Header Checksum)。 

  接下來“c0 a8 01 01”,這個就是源地址(Source Address)了,也就是我的IP地址。

  轉換為十進位的IP地址就是:192.168.1.1,同樣,繼續下來的32位“d8 03 e2 15”是目標地址,216.3.226.21 

  好了,真累啊,終於看完基本的20位元組的IP資料前序了。繼續看TCP的頭部吧,這個是作為IP資料包的資料部分傳輸的。 

  TCP頭部:0d 28 00 15 50 5f a9 06 00 00 00 00 70 02 40 00 c0 29 00 00 

  一來就是一個兩位元組段“0d 28”,表示本地連接埠號碼,轉換為十進位就是3368。第二個兩位元組段“00 15”表示目標連接埠,因為我是串連FTP網站,所以,這個就是21啦,十六進位當然就是“00 15”。 

  接下來的四個位元組“50 5f a9 06”是順序號(Sequence Number),簡寫為SEQ,SEQ=1348446470下面的四個位元組“00 00 00 00”是確認號(Acknowledgment Number),簡寫為ACKNUM。 

 
 繼續兩個位元組,“70 02”,轉換為二進位吧,“0111 0000 0000
0010”。這兩個位元組,總共16bit,有好多東西呢。第一個4bit“0111”,是TCP頭長,十進位為7,表示28個位元組(剛才說了,我省略了8
位元組的option資料,所以你只看見了20位元組)。接著的6bit現在TCP協議沒有用上,都為0。最後的6bit“00
0010”是六個重要的標誌。這是兩個電腦資料交流的資訊標誌。接收和發送斷根據這些標誌來確定資訊流的種類。下面是一些介紹: 

  URG:(Urgent Pointer field significant)緊急指標。用到的時候值為1,用來處理避免TCP資料流中斷 

  ACK:(Acknowledgment fieldsignificant)置1時表示確認號(AcknowledgmentNumber)為合法,為0的時候表示資料區段不包含確認資訊,確認號被忽略。 

  PSH:(Push Function),PUSH標誌的資料,置1時請求的資料區段在接收方得到後就可直接送到應用程式,而不必等到緩衝區滿時才傳送。 

  RST:(Reset the connection)用於複位因某種原因引起出現的錯誤串連,也用來拒絕非法資料和請求。如果接收到RST位時候,通常發生了某些錯誤。 

 
 SYN:(Synchronize sequence
numbers)用來建立串連,在串連請求中,SYN=1,ACK=0,串連響應時,SYN=1,ACK=1。即,SYN和ACK來區分
Connection Request和Connection Accepted。 

  FIN:(No more data from sender)用來釋放串連,表明發送方已經沒有資料發送了。 

  這6個標誌位,你們自己對號入座吧。本例中SYN=1,ACK=0,當然就是表示串連請求了。我們可以注意下面兩個過程的這兩位的變換。 

  後面的“40 00 c0 29 00 00”不講了,呵呵,偷懶了。後面兩次通訊的資料,自己分開看吧。我們看看串連的過程,一些重要地方的變化。 

  第二次,FTP網站返回一個可以串連的訊號。 

  216.3.226.21->192.168.1.1 

  IP頭部: 45 00 00 2c c6 be 40 00 6a 06 cd ba d8 03 e2 15 c0 a8 01 01 

  TCP頭部:00 15 0d 28 4b 4f 45 c1 50 5f a9 07 60 12 20 58 64 07 00 00 

  第三次,我確認串連。TCP串連建立起來。 

  192.168.1.1->216.3.226.21 

  IP頭部: 45 00 00 28 52 53 40 00 80 06 2c 2a c0 a8 01 01 d8 03 e2 15 

  TCP頭部:0d 28 00 15 50 5f a9 07 4b 4f 45 c2 50 10 40 b0 5b 1c 00 00 

  好,我們看看整個Threeway_handshake過程。 

  第一步,我發出串連請求,TCP資料為:SEQ=50 5f a9 06,ACKNUM=00 00 00 00,SYN=1,ACK=0。 

  第二步,對方確認可以串連,TCP資料為:SEQ=4b 4f 45 c1,ACKNUM=50 5f a9 07,SYN=1,ACK=1。 

  第三步,我確認建立串連。SEQ=50 5f a9 07, ACKNUM=4b 4f45c2,SYN=0,ACK=1。 

  可以看出什麼變化嗎?正式建立串連了呢,這些東西是什麼值? 

  我接收從216.3.226.21->192.168.1.1的下一個資料包中: 

  SEQ=4b 4f 45 c2,ACKNUM=50 5f a9 07,SYN=0,ACK=1這些都是很基礎的東西,對於編寫sniffer這樣的東西是必須非常熟悉的。這裡只講解了TCP/IP協議的一點點東西,主要是頭部資料的格式。(T002)

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.