Linux網路編程–7. TCP/IP協議

你也許聽說過TCP/IP協議,那麼你知道到底什麼是TCP,什麼是IP嗎?在這一章裡面,我們一起來學習這個目前網路上用最廣泛的協議.

7.1 網路傳輸分層
如果你考過電腦等級考試,那麼你就應該已經知道了網路傳輸分層這個概念.在網路上,人們為了傳輸資料時的方便,把網路的傳輸分為7個層次.分別是:應用程式層,展示層,會話層,傳輸層,網路層,資料連結層和物理層.分好了層以後,傳輸資料時,上一層如果要資料的話,就可以直接向下一層要了,而不必要管資料轉送的細節.下一層也只向它的上一層提供資料,而不要去管其它東西了.如果你不想考試,你沒有必要去記這些東西的.只要知道是分層的,而且各層的作用不同.

7.2 IP協議
IP協議是在網路層的協議.它主要完成資料包的發送作用. 下面這個表是IP4的資料包格式

0 4 8 16 32
--------------------------------------------------
|版本 |首部長度|服務類型| 資料包總長 |
--------------------------------------------------
| 標識 |DF |MF| 片段位移 |
--------------------------------------------------
| 存留時間 | 協議 | 首部較驗和 |
------------------------------------------------
| 源IP地址 |
------------------------------------------------
| 目的IP地址 |
-------------------------------------------------
| 選項 |
=================================================
| 資料 |
-------------------------------------------------

下面我們看一看IP的結構定義

struct ip
{
#if __BYTE_ORDER == __LITTLE_ENDIAN
unsigned int ip_hl:4; /* header length */
unsigned int ip_v:4; /* version */
#endif
#if __BYTE_ORDER == __BIG_ENDIAN
unsigned int ip_v:4; /* version */
unsigned int ip_hl:4; /* header length */
#endif
u_int8_t ip_tos; /* type of service */
u_short ip_len; /* total length */
u_short ip_id; /* identification */
u_short ip_off; /* fragment offset field */
#define IP_RF 0x8000 /* reserved fragment flag */
#define IP_DF 0x4000 /* dont fragment flag */
#define IP_MF 0x2000 /* more fragments flag */
#define IP_OFFMASK 0x1fff /* mask for fragmenting bits */
u_int8_t ip_ttl; /* time to live */
u_int8_t ip_p; /* protocol */
u_short ip_sum; /* checksum */
struct in_addr ip_src, ip_dst; /* source and dest address */
};

ip_vIP協議的版本號碼,這裡是4,現在IPV6已經出來了

ip_hlIP包首部長度,這個值以4位元組為單位.IP協議首部的固定長度為20個位元組,如果IP包沒有選項,那麼這個值為5.

ip_tos服務類型,說明提供的優先權.

ip_len說明IP資料的長度.以位元組為單位.

ip_id標識這個IP資料包.

ip_off片段位移,這和上面ID一起用來重組片段的.

ip_ttl存留時間.沒經過一個路由的時候減一,直到為0時被拋棄.

ip_p協議,表示建立這個IP資料包的高層協議.如TCP,UDP協議.

ip_sum首部校正和,提供對首部資料的校正.

ip_src,ip_dst寄件者和接收者的IP地址

關於IP協議的詳細情況,請參考 RFC791

7.3 ICMP協議
ICMP是訊息控制協議,也處於網路層.在網路上傳遞IP資料包時,如果發生了錯誤,那麼就會用ICMP協議來報告錯誤.

ICMP包的結構如下:

0 8 16 32
---------------------------------------------------------------------
| 類型 | 代碼 | 校正和 |
--------------------------------------------------------------------
| 資料 | 資料 |
--------------------------------------------------------------------

ICMP在中的定義是
struct icmphdr
{
u_int8_t type; /* message type */
u_int8_t code; /* type sub-code */
u_int16_t checksum;
union
{
struct
{
u_int16_t id;
u_int16_t sequence;
} echo; /* echo datagram */
u_int32_t gateway; /* gateway address */
struct
{
u_int16_t __unused;
u_int16_t mtu;
} frag; /* path mtu discovery */
} un;
};

關於ICMP協議的詳細情況可以查看 RFC792

7.4 UDP協議
UDP協議是建立在IP協議基礎之上的,用在傳輸層的協議.UDP和IP協議一樣是不可靠的資料報服務.UDP的頭格式為:

0 16 32
---------------------------------------------------
| UDP源連接埠 | UDP目的連接埠 |
---------------------------------------------------
| UDP資料報長度 | UDP資料報校正 |
---------------------------------------------------

UDP結構在中的定義為:
struct udphdr {
u_int16_t source;
u_int16_t dest;
u_int16_t len;
u_int16_t check;
};

關於UDP協議的詳細情況,請參考 RFC768
7.5 TCP
TCP協議也是建立在IP協議之上的,不過TCP協議是可靠的.按照順序發送的.TCP的資料結構比前面的結構都要複雜.

0 4 8 10 16 24 32
-------------------------------------------------------------------
| 源連接埠 | 目的連接埠 |
-------------------------------------------------------------------
| 序號 |
------------------------------------------------------------------
| 確認號 |
------------------------------------------------------------------
| | |U|A|P|S|F| |
|首部長度| 保留 |R|C|S|Y|I| 視窗 |
| | |G|K|H|N|N| |
-----------------------------------------------------------------
| 校正和 | 緊急指標 |
-----------------------------------------------------------------
| 選項 | 填充位元組 |
-----------------------------------------------------------------

TCP的結構在中定義為:
struct tcphdr
{
u_int16_t source;
u_int16_t dest;
u_int32_t seq;
u_int32_t ack_seq;
#if __BYTE_ORDER == __LITTLE_ENDIAN
u_int16_t res1:4;
u_int16_t doff:4;
u_int16_t fin:1;
u_int16_t syn:1;
u_int16_t rst:1;
u_int16_t psh:1;
u_int16_t ack:1;
u_int16_t urg:1;
u_int16_t res2:2;
#elif __BYTE_ORDER == __BIG_ENDIAN
u_int16_t doff:4;
u_int16_t res1:4;
u_int16_t res2:2;
u_int16_t urg:1;
u_int16_t ack:1;
u_int16_t psh:1;
u_int16_t rst:1;
u_int16_t syn:1;
u_int16_t fin:1;
#endif
u_int16_t window;
u_int16_t check;
u_int16_t urg_prt;
};

source發送TCP資料的源連接埠
dest接受TCP資料的目的連接埠

seq標識該TCP所包含的資料位元組的開始序號

ack_seq確認序號,表示接受方下一次接受的資料序號.

doff資料首部長度.和IP協議一樣,以4位元組為單位.一般的時候為5

urg如果設定緊急資料指標,則該位為1

ack如果確認號正確,那麼為1

psh如果設定為1,那麼接收方收到資料後,立即交給上一層程式

rst為1的時候,表示請求重新串連

syn為1的時候,表示請求建立串連

fin為1的時候,表示親戚關閉串連

window視窗,告訴接收者可以接收的大小

check對TCP資料進行較核

urg_ptr如果urg=1,那麼指出緊急資料對於曆史資料開始的序號的位移值

關於TCP協議的詳細情況,請查看 RFC793

7.6 TCP串連的建立
TCP協議是一種可靠的串連,為了保證串連的可靠性,TCP的串連要分為幾個步驟.我們把這個串連過程稱為"三向交握".

下面我們從一個執行個體來分析建立串連的過程.

第一步客戶機向伺服器發送一個TCP資料包,表示請求建立串連. 為此,用戶端將資料包的SYN位設定為1,並且設定序號seq=1000(我們假設為1000).

第二步伺服器收到了資料包,並從SYN位為1知道這是一個建立請求的串連.於是伺服器也向用戶端發送一個TCP資料包.因為是響應客戶機的請求, 於是伺服器設定ACK為1,sak_seq=1001(1000+1)同時設定自己的序號.seq=2000(我們假設為2000).

第三步客戶機收到了伺服器的TCP,並從ACK為1和ack_seq=1001知道是從伺服器來的確認資訊.於是客戶機也向伺服器發送確認資訊.客戶機設定ACK=1,和ack_seq=2001,seq=1001,發送給伺服器.至此用戶端完成串連.

最後一步伺服器受到確認資訊,也完成串連.

通過上面幾個步驟,一個TCP串連就建立了.當然在建立過程中可能出現錯誤,不過TCP協議可以保證自己去處理錯誤的.

說一說其中的一種錯誤.
聽說過DOS嗎?(可不是作業系統啊).今年春節的時候,美國的五大網站一起受到攻擊.攻擊者用的就是DOS(拒絕式服務)方式.概括的說一下原理.
客戶機先進行第一個步驟.伺服器收到後,進行第二個步驟.按照正常的TCP串連,客戶機應該進行第三個步驟.
不過攻擊者實際上並不進行第三個步驟.因為用戶端在進行第一個步驟的時候,修改了自己的IP地址,就是說將一個實際上不存在的IP填充在自己IP資料包的寄件者的IP一欄.這樣因為伺服器發的IP地址沒有人接收,所以服務端會收不到第三個步驟的確認訊號,這樣服務務端會在那邊一直等待,直到逾時.
這樣當有大量的客戶發出請求後,服務端會有大量等待,直到所有的資源被用光,而不能再接收客戶機的請求.
這樣當正常的使用者向伺服器發出請求時,由於沒有了資源而不能成功.於是就出現了春節時所出現的情況.