2009-08-26 15:51:08| 分類: network | 標籤: |字號大中小 訂閱 php
前導碼(8bytes)|目的位址(6bytes)|來源位址(6bytes)|資料欄位通信(2bytes)|主要資料(46-1500bytes)|檢查碼(4bytes)
圖3、乙太網路的 MAC 訊框
在 這個 MAC 當中,最重要的就是那個 6 Bytes 的目的與來源位址了! 事實上,在全部的乙太網路卡當中都有一個獨一無二的網路卡卡號, 那就是上頭的『目的與來源位址』,這個位址是硬體位址( hardware address ), 共有 6 bytes ,分別由 00:00:00:00:00:00 到 FF:FF:FF:FF:FF:FF, 這 6 bytes 當中,前 3bytes 為廠商的代碼,後 3bytes 則是該廠商自行設定的裝置碼了。 在 Linux 當中,你可使用 ifconfig 這個指令來查閱你的網路卡卡號喔! 不過,由於 MAC 主要是與網路卡卡號有關,因此我們也經常將 MAC 做為網路卡卡號的代稱。
特別注意,在這個 MAC 的傳送中,他僅在區域網路內生效, 若是跨過不一樣的網域 (這個後面 IP 的部分時會介紹),那麼來源與目的的位址就會跟著改變了。 這是因為變成不一樣網路卡之間的交流了嘛!因此卡號當然不一樣了!以下所示:
圖4、在不一樣主機間持續傳送相同資料的 MAC 訊框變化
例 如上面的圖示,個人資料要由電腦 A 通過 B 後才送達 C ,而 B 電腦有兩塊網路卡, 其中 MAC-2 與 A 電腦的 MAC-1 互通,至於 MAC-3 則與 C 電腦的 MAC-4 互通。 可是 MAC-1 不能與 MAC-3 與 MAC-4 互通,為啥?因為 MAC-1 這塊網路卡並沒有與 MAC-3 及 MAC-4 使用同樣的 switch/hub 相接嘛!因此,資料的流通會變成:
- 先由 MAC-1 傳送到 MAC-2 ,此時來源是 MAC-1 而目的地是 MAC-2;
- B 電腦接收後,察看該訊框,發現目標其實是 C 電腦,而為了與 C 電腦溝通, 因此他會將訊框內的來源 MAC 改為 MAC-3 ,而目的改為 MAC-4 ,如此就能夠直接傳送到 C 電腦了。
也就是說,只要透過 B (就是路由器) 才將封包送到另外一個網域 (IP 部分會講) 去的時候, 那麼訊框內的硬體位址就會被改變,然後纔能夠在同一個網域裡面直接進行 frame 的流通啊!
MAC包大小:舊爲1900bytes,大爲9000bytes
IP 封包的表頭
現 在我們知道 IP 這個資料封包 (packet) 是須要放置在 MAC 訊框裡面的,因此當然不能比 MAC 所能容許的最大資料量還大!可是 IP 封包其實能夠到 65535 bytes 那麼大的吶! 那麼 IP 封包除了資料以外,他的表頭資料 (head) 是長怎樣呢? 在
圖三的 MAC 訊框表頭裡面最重要的莫過於那個網路卡硬體位址, 那麼在 IP 表頭裡面當然就以來源與目標的 IP 位址為最重要囉! 除此以外, IP 表頭裡面還含有哪些重要資料呢?如底下所示:(下圖第一行為每個欄位的
bit 數)
4 bits |
4 bits |
8 bits |
3 bits |
13 bits |
Version |
IHL |
Type of Service |
Total Length |
Identification |
Flags |
Fragmentation Offset |
Time To Live |
Protocol |
Header Checksum |
Source Address |
Destination Address |
Options |
Padding |
Data |
圖8、IP 封包的表頭資料
在上面的圖示中有個地方要注意,那就是『
每一行所佔用的位元數為 32 bits』, 也就是說, IP 封包的表頭資料是 32 bits 的倍數喔!那各個表頭的內容分別介紹以下:
- Version(版本)
宣告這個 IP 封包的版本,例如目前慣用的還是 IPv4 這個版本,在這裡宣告的。
- IHL(Internet Header Length, IP表頭的長度)
告知這個 IP 封包的表頭長度,單位為位元組(bytes)。 此 IHL 長度的範圍為 5~15。
- Type of Service(服務類型)
這個項目的內容為『PPPDTRUU』,表示這個 IP 封包的服務類型,主要分為:
PPP:表示此 IP 封包的優先度; D:若為 0 表示通常延遲(delay),若為 1 表示為低延遲;
T:若為 0 表示為通常傳輸量 (throughput),若為 1 表示為高傳輸量;
R:若為 0 表示為通常可靠度(reliability),若為 1 表示高可靠度。
UU:保留還沒有被使用。
我們前面談到 gigabit 乙太網路時曾提到 Jumbo frame 對吧!能夠提升 MTU, 由於 gigabit 乙太網路的種種相關規格能夠讓這個 IP 封包加速且下降延遲, 某些特殊的標誌就是在這裡說明的。
- Total Length(總長度)
指這個 IP 封包的總容量,包括表頭與內容 (Data) 部分。最大可達 65535 bytes。
- Identification(辨別碼)
我 們前面提到 IP 袋子必須要放在 MAC 袋子當中。不過,若是 IP 袋子太大的話, 就得先要將 IP 再重組成較小的袋子然後再放到 MAC 當中。而當 IP 被重組時, 每個來自同一筆資料的小 IP 就得要有個識別碼以告知接收端這些小 IP 其實是來自同一個封包才行。 也就是說,假如 IP 封包其實是 65536 那麼大 (前一個 Total Length 有規定), 那麼這個 IP 就得要再被分紅更小的 IP 分段後才能塞進 MAC 訊框中。那麼每個小 IP 分段是否來自同一個 IP 資料,呵呵!這裡就是那個識別碼啦!
- Flags(特殊旗標)
這個地方的內容為『0DM』,其意義為:
D:若為 0 表示能夠分段,若為 1 表示不可分段
M:若為 0 表示此 IP 為最後分段,若為 1 表示非最後分段。
- Fragment Offset(分段偏移)
表 示目前這個 IP 分段在原始的 IP 封包中所佔的位置。 就有點像是序號啦,有這個序號才能將全部的小 IP 分段組合成為本來的 IP 封包大小嘛! 透過 Total Length, Identification, Flags 以及這個 Fragment Offset 就能夠將小 IP 分段在收受端組合起來囉!
- Time To Live(TTL, 存活時間)
表示這個 IP 封包的存活時間,範圍為 0-255。當這個 IP 封包通過一個路由器時, TTL 就會減一,當 TTL 為 0 時,這個封包將會被直接丟棄。說實在的,要讓 IP 封包通過 255 個路由器,還挺難的~ ^_^
- Protocol Number(協定代碼)
由於網路上面的封包協定太多了,每個協定都是裝在 IP 當中的, 因此 IP 當然就得在表頭上面告知收受端,這個 IP 內含有的資料是什麼協定才行。 通常常見的網路協定以下所示:
IP 內的號碼 |
協定名稱(全名) |
1 |
ICMP (Internet Control Message Protocol) |
2 |
IGMP (Internet Group Management Protocol) |
3 |
GGP (Gateway-to-Gateway Protocol) |
4 |
IP (IP in IP encapsulation) |
6 |
TCP (Transmission Control Protocol) |
8 |
EGP (Exterior Gateway Protocol) |
17 |
UDP (User Datagram Protocol) |
當然啦,我們比較常見到的還是那個 TCP, UDP, ICMP 說!
- Header Checksum(表頭檢查碼)
用來檢查這個 IP 表頭的錯誤檢驗之用。
- Source Address
還用講嗎?當然是來源的 IP 位址,相關的 IP 我們以前提過囉!
- Destination Address
有來源還須要有目標才能傳送,這裡就是目標的 IP 位址。
- Options (其餘參數)
這個是額外的功能,提供包括安全處理機制、路由紀錄、時間戳記、 嚴格與寬鬆之來源路由等。
- Padding(補齊項目)
由於 Options 的內容不必定有多大,可是我們知道 IP 每個資料都必須要是 32 bits, 因此,若 Options 的資料不足 32 bits 時,則由 padding 主動補齊。
你 只要知道 IP 表頭裡面還含有: TTL, Protocol, 來源 IP 與目標 IP 也就夠了! 而這個 IP 表頭的來源與目標 IP ,以及那個判斷通過多少路由器的 TTL ,就能瞭解到這個 IP 將被如何傳送到目的端吶。下一節我們將介紹一下那麼 IP 封包是如何被傳送到目的地?
TCP 協定
在前幾個小節內談到的 IP 與路由的相關說明中,我們知道 IP 與路由僅能將資料封包傳送到正確的目標而已, 可是這個目的地是否真的能夠收下來這個封包?那可就不必定了。要確認該資料可否正確的被目的端所接收, 就必須要在資料封包上面多加一些參數來判斷才行。
在前面的 OSI 七層協定當中,在網路層的 IP 之上則是傳送層,而傳送層的資料打包成什麼? 最常見的就是 TCP 封包了。這個 TCP 封包資料必須要能夠放到 IP 的資料袋當中才行喔! 因此,我們能夠將 MAC, IP 與 TCP 的封包資料這樣看:
圖11、各封包之間的相關性
因此說,IP 除了表頭以外的 Data 內容其實就是 TCP 封包的表頭與內容;而 MAC 的 Data 內容, 就是一個完整的 IP 封包資料!這也是我們上頭提到的,最終還是得以 MAC 能夠支援的最大容許容量, 纔能夠決定 IP 與 TCP 封包是否須要再進行分段的工做。那麼既然 MAC 與 IP 都有表頭資料, 想當然爾,TCP 也有表頭資料來記錄該封包的相關資訊囉??沒錯啦~ TCP 封包的表頭是長這個樣子的:
4 bits |
6 bits |
6 bits |
8 bits |
8 bits |
Source Port |
Destination Port |
Sequence Number |
Acknowledge Number |
Data Offset |
Reserved |
Code |
Window |
Ckecksum |
Urgent Pointer |
Options |
Padding |
Data |
圖12、TCP 封包的表頭資料
上圖就是一個 TCP 封包的表頭資料,各個項目以 Source Port, Destination Port 及 Code 算是比較重要的項目,底下我們就分別來談一談各個表頭資料的內容吧!
- Source Port & Destination Port ( 來源埠口 & 目標埠口 )
什 麼是埠口(port)?我們知道 IP 封包的傳送主要是藉由 IP 位址連接兩端, 可是到底這個連線的通道是連接到哪裡去呢?沒錯!就是連接到 port 上頭啦! 舉例來說,鳥站 (http://linux.vbird.org) 有開放 WWW 伺服器, 這表示鳥站的主機必須要啟動一個能夠讓 client 端連接的端口,這個端口就是 port , 中文翻譯成為埠口。同樣的,用戶端想要連接到鳥哥的鳥站時,就必須要在 client 主機上面啟動一個 port ,這樣這兩個主機纔能夠利用這條『通道』來傳遞封包資料喔! 這個目標與來源 port 的紀錄,能夠說是 TCP 封包上最重要的參數了! 下個小單元我們還會繼續介紹。
- Sequence Number ( 封包序號 )
由於 TCP 封包必須要帶入 IP 封包當中,因此若是 TCP 資料太大時(大於 IP 封包的容許程度), 就得要進行分段。這個 Sequence Number 就是記錄每個封包的序號, 能夠讓收受端從新將 TCP 的資料組合起來。
- Acknowledge Number ( 回應序號 )
為 了確認主機端確實有收到我們 client 端所送出的封包資料,我們 client 端當然但願能夠收到主機方面的回應,那就是這個 Acknowledge Number 的用途了。 當 client 端收到這個確認碼時,就能夠確定以前傳遞的封包已經被正確的收下了。
- Data Offset (資料補償)
在圖十二倒數第二行有個 Options 欄位對吧!那個 Options 的欄位長度是非固定的, 而為了要確認整個 TCP 封包的大小,就須要這個標誌來說明整個封包區段的起始位置。
- Reserved (保留)
未使用的保留欄位。
- Code (Control Flag, 控制標誌碼)
當我們在進行網路連線的時候,必須要說明這個連線的狀態,好讓接收端瞭解這個封包的主要動做。 這但是一個很是重要的控制碼喔!這個欄位共有 6 個 bits ,分別表明 6 個控制碼,若為 1 則為啟動。分別說明以下:
- URG(Urgent):若為 1 則表明該封包為緊急封包, 接收端應該要緊急處理,且圖十二當中的 Urgent Pointer 欄位也會被啟用。
- ACK(Acknowledge):若為 1 表明這個封包為回應封包, 則與上面提到的 Acknowledge Number 有關。
- PSH(Push function):若為 1 時, 表明要求對方當即傳送緩衝區內的其餘對應封包,而無須等待緩衝區滿了才送。
- RST(Reset):若是 RST 為 1 的時候, 表示連線會被馬上結束,而無需等待終止確認手續。這也就是說,這是個強制結束的連線, 且發送端已斷線。
- SYN(Synchronous):若為 1 , 表示發送端但願雙方創建同步處理,也就是要求創建連線。一般帶有 SYN 標誌的封包表示『主動』要連接到對方的意思。
- FIN(Finish):若為 1 ,表示傳送結束, 因此通知對方資料傳畢,是否贊成斷線,只是發送者還在等待對方的回應而已。
其中比較常見到的應該是 ACK/SYN/FIN 等,這三個控制碼是務必要記下來的, 這樣未來在談到防火牆的時候,您才會比較清楚為啥每個 TCP 封包都有所謂的『狀態』條件! 那就是因為連線方向的不一樣所致啊!底下我們會進一步討論喔!
- Window (滑動視窗)
主要是用來控制封包的流量的,能夠告知對方目前自己有的緩衝器容量(Receive Buffer) 還能夠接收封包。當 Window=0 時,表明緩衝器已經額滿,因此應該要暫停傳輸資料。 Window 的單位是 byte。
- Checksum(確認檢查碼)
當 資料要由發送端送出前,會進行一個檢驗的動做,並將該動做的檢驗值標注在這個欄位上; 而接收者收到這個封包之後,會再次的對封包進行驗證,並且比對原發送的 Checksum 值是否相符,若是相符就接受,若不符就會假設該封包已經損毀,進而要求對方從新發送此封包!
- Urgent Pointer(緊急資料)
這個欄位是在 Code 欄位內的 URG = 1 時才會產生做用。能夠告知緊急資料所在的位置。
- Options(任意資料)
目前此欄位僅應用於表示接收端能夠接收的最大資料區段容量,若此欄位不使用, 表示可使用任意資料區段的大小。這個欄位較少使用。
- Padding(補足欄位)
如同 IP 封包須要有固定的 32bits 表頭一樣, Options 由於欄位為非固定, 因此也須要 Padding 欄位來加以補齊才行。同樣也是 32 bits 的整數。
TCP報文格式linux
— TCP :( Transmission Control Protocol) 面向鏈接的可靠傳輸協議,爲用戶應用端之間提供一個虛擬電路。編程
— 源端口(Source Port):呼叫端端口號安全
— 目端口(Destination Port):被叫端端口號網絡
— 序列號(Sequence Number):分配給報文的序號,用於跟蹤報文通訊順序,確保無丟失大數據
— 確認號(Acknowledgement Number):所期待的下一個TCP報文的序列號,並表示編碼
對此序列前報文正確接收的確認spa
— 報頭長度(HLEN):報文頭部的字節數3d
— 保留域(Reserved):設置爲0指針
— 編碼位(Code Bits):控制功能(如TCP鏈接的創建和終止)
— 窗口(Window):發送者贊成接收的字節數
— 校驗和(Checksum):報頭和數據字段的校驗和
— 緊急指針(Urgent Pointer):指示緊急數據段的末尾
— 選項(Option):當前定義TCP段的最大值
— 數據(Data):上層協議數據
TCP鏈接的創建其實是一同步過程(又稱三次握手)
三次握手:
1:主機A向主機B發出鏈接請求數據包
2:主機B向主機A發送贊成連結和要求同步(一個在發送,一個在接收)
3:主機A要發出一數據包確認主機B的要求同步
源端口和目的端口:發送方和接收方的TCP端口號。
序號:該報文數據在發送方的數據流中的位置。當前時間值計算出一個數值做爲起始序號。
首部長度:表示TCP報文首部信息的長度。因爲首部可能含有選項內容,所以TCP首部的長度是不肯定的。首部長度的單位是32位或4字節。首部長度實際上也指示了數據區在報文段中的起始偏移值。
碼元比特:6位
URG、ACK、PSH、RST、SYN、FIN。
URG表示緊急指針字段有效;
ACK置位表示確認號字段有效;
PSH表示當前報文須要請求推(push)操做;
RST置位表示復位TCP鏈接;
SYN用於創建TCP鏈接時同步序號;
FIN用於釋放TCP鏈接時標識發送方比特流結束
窗口:窗口通告值。發送方根據接收的窗口通告值調整窗口大小。
緊急指針:若是TCP通訊中,一方有緊急的數據(例如中斷或退出命令)須要儘快發送給接收方,而且讓接收方的TCP協議儘快通知相應的應用程序,能夠將URG置位,並經過緊急指針指示緊急數據在報文段中的結束位置。
校驗和:與UDP校驗和計算方法相同,一樣須要包含僞首部。僞首部中的協議類型值爲6。
選項:用於TCP鏈接雙方在創建鏈接時協商最大的報文段長度MSS(Maximum Segment Size)。
填充:爲了使選項字段對齊32比特,可能採用若干位0做爲填充數據。
UDP報文格式
— UDP :( User Datagram Protocol)無鏈接的非可靠傳輸協議
— 源端口(Source Port):呼叫端端口號
— 目端口(Destination Port):被叫端端口號
— 報頭長度(HLEN):報文頭部的字節數
— 校驗和(Checksum):報頭和數據字段的校驗和
— 數據(Data):上層協議數據
UDP 傳輸不提供ACK反向確認機制、流量和報文序列號控制,所以UDP報文可能會丟失、重複或無序到達,通訊的可靠性問題將由應用層協議提供保障。但UDP報 文格式和控制機制簡單,所以通訊開銷比較小,TFTP、SNMP、NFS和DNS應用層協議等都是用UDP傳輸的。
傳輸層:
對於UDP協議來講,整個包的最大長度爲65535,其中包頭長度是65535-20=65515;
對於TCP協議來講,整個包的最大長度是由最大傳輸大小(MSS,Maxitum Segment Size)決定,MSS就是TCP數據包每次可以傳
輸的最大數據分段。爲了達到最佳的傳輸效能TCP協議在創建鏈接的時候一般要協商雙方的MSS值,這個值TCP協議在實現的時候每每用MTU值代替(需
要減去IP數據包包頭的大小20Bytes和TCP數據段的包頭20Bytes)因此每每MSS爲1460。通信雙方會根據雙方提供的MSS值得最小值
肯定爲此次鏈接的最大MSS值。
IP層:
對於IP協議來講,IP包的大小由MTU決定(IP數據包長度就是MTU-28(包頭長度)。 MTU值越大,封包就越大,理論上可增長傳送速率,但
MTU值又不能設得太大,由於封包太大,傳送時出現錯誤的機會大增。通常默認的設置,PPPoE鏈接的最高MTU值是1492, 而以太網
(Ethernet)的最高MTU值則是1500,而在Internet上,默認的MTU大小是576字節
UDP一次發送數據包的大小,TCP一次發送數據包的大小。
MTU最大傳輸單元,這個最大傳輸單元實際上和鏈路層協議有着密切的關係,EthernetII幀的結構DMAC+SMAC+Type+Data+CRC因爲以太網傳輸電氣方面的限制,每一個以太網幀都有最小的大小64bytes最大不能超過1518bytes,對於小於或者大於這個限制的以太網幀咱們均可以視之爲錯誤的數據幀,通常的以太網轉發設備會丟棄這些數據幀。
由 於以太網EthernetII最大的數據幀是1518Bytes這樣,刨去以太網幀的幀頭(DMAC目的MAC地址48bit=6Bytes+SMAC源 MAC地址48bit=6Bytes+Type域2bytes)14Bytes和幀尾CRC校驗部分4Bytes那麼剩下承載上層協議的地方也就是Data域最大就只能有1500Bytes這個值咱們就把它稱之爲MTU。
PPPoE所謂PPPoE就是在以太網上面跑PPP協議,有人奇怪了,PPP協議和Ethernet不都是鏈路層協議嗎?怎麼一個鏈路層跑到另一個鏈路層上面去了,難道升級成網絡層協議了不成。其實這是個誤區:就是某層協議只能承載更上一層協議。
爲何會產生這種奇怪的需求呢?這是由於隨着寬帶接入(這種寬帶接入通常爲Cable Modem或者xDSL或者以太網的接入),由於以太網缺少認證計費機制而傳統運營商是經過PPP協議來對撥號等接入服務進行認證計費的.
PPPoE帶來了好處,也帶來了一些壞處,好比:二次封裝耗費資源,下降了傳輸效能等等,這些壞處俺也很少說了,最大的壞處就是PPPoE致使MTU變小了以太網的MTU是1500,再減去PPP的包頭包尾的開銷(8Bytes),就變成1492。
UDP 包的大小就應該是 1492 - IP頭(20) - UDP頭(8) = 1464(BYTES)
TCP 包的大小就應該是 1492 - IP頭(20) - TCP頭(20) = 1452(BYTES)
目前大多數的路由設備的MTU都爲1500
編程的時候必定要注意哦,不能超過這兩個值,不然你的傳輸效率就大打折扣了。