補充2 (傳輸模式)

Outline

™ Introduction

™ IP Address & MAC Address

™ TCP/UDP/ICMP

™ IP Gateway, Network Mask, TTL

™ Routing Protocol

™ Network Address Translation (NAT)

™ Domain Name System (DNS)

™ Dynamic Host Configuration Protocol (DHCP) / Asymmetric Digital Subscriber Line (ADSL)

™ HyperText Transfer Protocol (HTTP) Protocol

™ Virtual Private Network (VPN)

3. TCP/UDP/ICMP

™TCP (Transmission Control Protocol) :

ƒ 提供Connection Oriented (連結導向) 並達成End-to- End (兩端通訊端點對端點) Process-to-Process(程 序對程序)、Reliable Data Delivery (可信賴的資料遞 送)。

™UDP (User Datagram Protocol) :

ƒ 提供不可靠(Unreliable)的傳輸，也就是它並不能擔保 資料是否能確實地從來源傳送到目的地，因為UDP 除 了自己的Checksum 以外，並沒有做任何確保封包能 確實送達目的地的機制。

™ICMP (Internet Control Message Protocol) :

ƒ 提供主機或是網路設備之間交換錯誤訊息及其他重要 資訊。

™Question:

ƒ What is point-to-point connection?

ƒ What is end-to-end connection?

ƒ What is unicast / multicast / broadcast?

ƒ What is multiplexing?

補充1

™連接方式

ƒ 點對點( point-to-point )：直接相連(實體相連)

ƒ 端點對端點(End-to-End)：間接相連(跨網路相連)

補充2 (傳輸模式)

™Unicast (單點傳輸)

™Multicast (群播)

™Broadcast (廣播)

unicast

multicast

補充3 (多工:Multiplexing)

™分時多工

(Time-Division Multiplexing, TDM)

™分頻多工

(Frequency-Division Multiplexing, FDM)

3.1 UDP 通訊協定

™定義於RFC 768（User Datagram Protocol）

™提供應用程式能夠在最低的通訊協定機制下送訊 息給其他應用程式。

™無法保證是不是傳送得到或者是會被重製或有沒 有依照傳送順序到達。

™講究傳輸速度且容許一點資料流失(Data Loss) 或是封包遺失(Packet Loss) 的應用程式常用 UDP 通訊協定來實作。例如NetMeeting、

VoIP、MSN 使用語音等。

3.1.2 埠號(Port Number)與

多工(Multitasking)的觀念

用大樓的 “信箱” 來解釋IP 位址和埠的概念

當郵差送信 (要傳送的封包) 的時 候，他透過郵政系統 會幫我們把信 件投遞到指定地址 (IP 位址) 所在的 大樓。信件該投入此大樓的哪一個 信箱？就需要信封上各細部的門牌 號碼

舉例說明 ― 視訊會議

無法保證packet按順序到達

3.1.2 UDP資料格式

UDP資料格式― 細部說明

™Source Port :

ƒ 非必須的欄位，不使用時填零

™Destination Port :

ƒ 表示這個 Datagram 將送達的位置Port

™UDP Length :

ƒ 以八進位表示的 Datagram 的長度，包括了檔頭和資 料 (min: 8 bytes, i.e. only UDP header)。

™UDP Checksum :

ƒ 將 UDP 的 Pseudo Header、UDP Header 以及 UDP 的 Data的所有資料加總之後，取一的補數，再取 16 bit的一補數，若必要時會在後面加上一個 0，以確保 是兩個八進位數資料。

UDP Pseudo Header

之所以稱為虛擬(Pseudo)，是因為其中的 Source IP Address 與 Destinatin

IP Address 並不出現在 UDP 封包中，而是在 IP 封包中。但在進行校驗的時

侯，發送端與接收端則根據此 "虛擬" 的表頭及資料進行。然而，此表頭是不

UDP Pseudo Header― 細部說明

™UDP Pseudo Header :

ƒ 將部分 IP header 、UDP header看成集合成一個 header

™UDP Datagram 的最大長度 :

ƒ 理論上 : 65535 – 20(IP header) – 8(UDP header) = 65507 Bytes

ƒ 一般 socket 在實作上存取的緩衝區 (Buffer) 有限制 8192 Bytes)

ƒ 因此，像是一些使用 UDP的通信協定諸如 DNS、

TFTP、SNMP 等多將其 Datagram 大小限制在 512 Bytes

UDP Checksum

3.2 TCP 通訊協定

™定義於 RFC 793 (Transmission Control Protocol )

ƒ 提供 Connection Oriented (連結導向) 並達成End-to- End (兩端通訊端點對端點) Process-to-Process (程序對 程序)、Reliable Data Delivery (可信賴的資料遞送)。

™TCP提供以下三個基本功能：

ƒ Reliability：克服Packet Loss，傳送之Data 依照順序交 給Process (i.e. 封包正確無誤依照順序送達應用程式 (而非正確無誤依照順序送達電腦介面))

ƒ Multiplexing：藉由不同的Port 可使相同的IP Address 可以提供上層不同的服務，如FTP，Telnet，HTTP 等

ƒ Flow Control 或 Congestion Avoidance and Control：

避免網路或接收端壅塞，以便提供有效率的傳輸

TCP 資料格式

Header Length

TCP Header

™Source Port & Destination Port : 來源端 與目的端通訊埠號碼

™Sequence Number : 表示此資料段在訊息中 的序號，接收端依序組合資料段

™Acknowledgment Number : 接收端希望 下次收到的序號，也是回應已收到封包

™Header Length : TCP Header的長度

™Reserved : 保留給未來使用

TCP Header(Cont.)

™Window Size : 使用於流量控制，表示能接收 資料的數目(以8個位元組為單位)

™Checksum : 錯誤偵測號碼

™Urgent Pointer : 緊急指標。URG flag為1 時，此欄位才生效

™Options : 此資料段的發送者告訴對方能接受的 最大資料段長度

™Padding : 使header長度以32個位元結束

TCP flag

™TCP 連線都有一定之程序，並且分成幾個不同 的狀態(State)，它是透過 TCP Header 欄位 的 flag 欄位來實作

如果設定，表示此 封包有一個回應

重設連結

建立順序號碼

傳送資料到此為止

把要發送的資料發 送出去

URG | Urgent Pointer| 緊急指標

TCP 之連線建立

™三向交握( three-way handshaking)

Client Server

發送SYN

序列號碼(SEQ)為100 連結建立

收到SYN並回 應控制訊號 回應號碼(ACK)為201 序列號碼(SEQ)為101

發送資料

收到SYN 發送SYN

序列號碼(SEQ)為200 回應號碼(ACK)為100+1

連結建立

回應"已收到資料"

Flag=SYN

Flag=SYN, ACK

Flag=ACK

SYN Flooding

™SYN Flooding是針對TCP三向式交握的一種 DOS (Denial of Service) / DDOS

(Distributed Denial of Service)的攻擊法

SYN Flooding (DOS)

™Q: TCP連接的三次握手中，假設一個用戶向伺 服器發送了SYN報文後突然死機或掉 線，那麼 伺服器在發出SYN+ACK應答報文後是無法收到 用戶端的ACK報文的（第三次握手無 法完

成），這種情況下伺服器端一般會重試（再次發

送SYN+ACK給用戶端）並等待一段時 間後丟

棄這個未完成的連接，這段時間的長度我們稱為

數量級（大約為30秒-2分鐘）；一個用戶出現

™幾種簡單的解決方法 ：

ƒ 第一種是縮短SYN Timeout時間，由於SYN Flood攻擊的 效果取決於伺服器上保持的SYN半連接數，這個值=SYN 攻擊的頻度 x SYN Timeout，所以通過縮短從接收到SYN 報文到確定這個報文無效並丟棄改連接的時間，例如 設置 為20秒以下（過低的SYN Timeout設置可能會影響客戶的 正常訪問），可以成倍的降 低伺服器的負荷。

ƒ 第二種方法是設置SYN Cookie，就是給每一個請求連接的 IP位址分配一個Cookie，如果短 時間內連續受到某個IP的 重複SYN報文，就認定是受到了攻擊，以後從這個IP地址 來的包 會被一概丟棄。

™但上述的方法只能對付較原始的SYN Flood攻擊，

縮短SYN Timeout時間僅在對方 攻擊頻度不高的 情況下生效，SYN Cookie更依賴于對方使用真實 的IP位址，如果攻擊者以 數萬/秒的速度發送SYN 報文，同時利用SOCK_RAW隨機改寫IP報文中的 來源位址，以上的方法 將毫無用武之地。

TCP 之連線結束

™由於 TCP 為全雙工（Full-duplex）的通訊協 定，兩邊之連線都可以獨立進行結束連線

™如果只有單方面結束連線稱之為Half-Close，

在 Half-Close 之後過一陣子，TCP 會要求另 外一個方向的連線也結束

TCP 之連線結束

Client Server

FIN

ACK of FIN

Connection Terminated ACK of FIN

FIN

用一個完整的例子來說明

TCP Connection State Diagram

TCP Connection State Diagram 的 Connection Establish 部分

TCB: Transmission Control Block

TCP Connection Establishment步驟

TCP Connection State Diagram 的 Disconnection Establish 部分

™此端先關閉

ƒ Established -> FIN_WAIT_1 -> FIN_WAIT_2 ->

Time_Wait -> Closed

™另一端先關閉

ƒ Established -> CLOSE_WAIT -> LAST_ACK ->

Closed

™兩端同時關閉

ƒ Established -> FIN_WAIT_1 -> Closing -> Time_Wait -> Closed

此端先關閉

Timeout=2MSL / Delete TCB Established

FIN WAIT 1 Close Wait

FIN WAIT 2 Last ACK

Time Wait Closed

Close / Send FIN Receive FIN / Send ACK

Receive ACK of FIN Close / Send FIN

Receive FIN / Send ACK Receive ACK of FIN

此端此端 11

此端此端 33

此端此端 55

此端此端 77

另一端另一端 22

另一端另一端 44

MSL : Maximum Segment Lifetimes

另一端另一端 66

Closing

Receive FIN / Send ACK

Receive ACK of FIN SYN

Received Close / Send FIN

另一端先關閉

Timeout=2MSL / Delete TCB Established

FIN WAIT 1 Close Wait

FIN WAIT 2 Last ACK

Time Wait Closed

Close / Send FIN Receive FIN / Send ACK

Receive ACK of FIN Close / Send FIN

Receive FIN / Send ACK Receive ACK of FIN

另一端另一端 11

另一端另一端 33

另一端另一端 55

此端此端 22

此端此端 44

此端此端 66

Closing

Receive FIN / Send ACK

Receive ACK of FIN SYN

Received Close / Send FIN

兩端同時關閉

Timeout = 2MSL / Delete TCB Established

FIN WAIT 1 Close Wait

FIN WAIT 2 Closing Last ACK

Time Wait Closed

Close / Send FIN Receive FIN / Send ACK

Receive FIN / Send ACK

Receive ACK of FIN Receive ACK of FIN Close / Send FIN

Receive FIN / Send ACK Receive ACK of FIN

兩端兩端 11

Client 5 Client 5

兩端兩端 22

兩端兩端 33

兩端兩端 44

SYN Received Close / Send FIN

TCP 通訊協定的可靠性

™Checksum：確保Packet 正確

™Sequence Number：用來確保Packet 依照 順序

™Positive Acknowledgment (ACK)：

Packet Loss或錯誤重傳的策略

™Window Size：作流量控制(Flow Control)

™ Checksum：確保Packet 正確 (由Pseudo Header、

TCP Header與Data 一起計算而得，如果接收端計算結 果與Checksum 不同，就會認為這TCP Packet 錯誤而 要求傳送端重傳)

™ Sequence Number：用來確保Packet 依照順序 (每個 Packet都必須加上Sequence Number，如此才知道 Packet 重組時的順序)

™ Positive Acknowledgment (ACK)：Packet Loss 或錯誤重傳的策略

™ Window Size：作流量控制(Flow Control)

目的是當Server 或Client 端使用TCP 連線時，可以控制 傳送的速率。因為Packet傳送過程當中會因為傳輸和通過 中間Switch/Router 等因設備處理Packet產生延遲或 因處理能力不足而造成Packet Loss，如此一來若設計成 每傳送一Packet 都須等待ACK才傳下一Packet，將會大 幅降低傳輸的效率，如此的做法稱為Stop-and-Go ARQ

（Automatic Repeat Request）。

TCP 通訊協定的可靠性 ― Checksum

™如同UDP，TCP 的 Checksum 也是由

Pseudo Header、TCP Header與Data 一 起計算而得

™如果接收端計算結果與Checksum 不同，就會 認為這TCP Packet 錯誤而要求傳送端重傳

TCP 通訊協定的可靠性

― Sequence Number 的運用及ACK

TCP 通訊協定的可靠性

― Window Size 流量控制

3.3 ICMP 通訊協定

™定義於 RFC 792 (Internet Control Message Protocol)

™設計用來處理網路設備之間的錯誤的，報告網路 環境中錯誤狀態的發生

™沒辦法確保訊息確實送達或是轉回發送地

™ICMP 訊息基本上是用 Datagram 來傳送錯 誤訊息，為了避免無限制地傳送錯誤訊息，

ICMP 訊息傳送的錯誤並不會產生另一個ICMP 訊息

™訊息被分成幾個 Fragmentation 時，ICMP 訊息只會送第一個 Fragmentation 的錯誤訊 息

ICMP 訊息

™訊息格式是依照訊息種類不同而異，共通部分

ƒ TOS 欄位為 0，Protocol 的欄位為 1

ƒ ICMP 共通訊息部分

• Type : ICMP 訊息的類別

• Code 和下面的部分則是依各個訊息類別不同 (pp. 3-20~3-21)

• Checksum 的計算方式則是和 IP Checksum 相同

參考 http://www.iana.org/assignments/icmp-parameters

ICMP 應用― ping

™利用ICMP 訊息裡的 Type 0 和 8( Echo Reply/Request )

™測試本機到網路某一端的機器是否有連線，或是 測試遠端機器是否有開啟 ping 的回應

Type 0/8：Echo Reply/Request

™ Echo Reply 回應回去的 Identifier 和 Sequence Number 會和收到 Echo Request 的相同 。

舉一個ping例子說明

ICMP 應用― traceroute

™利用 IP Packet 的 TTL 欄位來進行測試網路 Packet 經過哪些路徑

ƒ router 會在 IP Packet 的 TTL欄位為 0 的時候，回送 ICMP Type 11 Time-to-Live Exceed 訊息的功能

™在實作上有兩種方法

ƒ 送 UDP 封包製造 TTL = 0 而回應的狀況

ƒ 送 ICMP Echo Request 封包製造 TTL = 0 回應的狀況

traceroute範例

# traceroute 168.95.1.1

traceroute to 168.95.1.1 (168.95.1.1), 30 hops max, 38 byte packets

1 61-218-177-193.HINET-IP.hinet.net (61.218.177.193) 0.917 ms 0.885 ms 0.844 ms 2 10.218.177.254 (10.218.177.254) 32.017 ms 34.033 ms 33.376 ms

3 tc-c6r1.router.hinet.net (168.95.144.202) 31.748 ms 32.338 ms 31.771 ms 4 tc-b-c12r1.router.hinet.net (168.95.254.129) 31.740 ms 32.338 ms 32.927 ms 5 210.65.2.22 (210.65.2.22) 36.282 ms 35.720 ms 35.018 ms

6 tp-s2-c6r9.router.hinet.net (211.22.35.1) 33.380 ms 34.851 ms 35.006 ms 7 tp-b-c6r2.router.hinet.net (168.95.1.61) 33.369 ms 33.940 ms 33.387 ms

承上例，解釋第一個封包

™第一個 Packet 的 TTL 設為 1，往外傳送

™第一個 Router 是 61.218.177.193，它收 到 Packet 後將 TTL 減 1 後(變成 0)

™於是 61.218.177.193 送一個 ICMP Time Exceed Packet 給 61.218.177.202

traceroute之packet 流程圖

™每個 Packet 的 TTL 會累加，直到抵達 168.95.1.1

額外補充說明

非連結導向(Connection-less oriented)

UDP Header

TCP Header

TCP 流量控制機制

™停止與等待法 (Stop-and-Wait)

™視窗大小 (Window Size)

™滑動視窗法 (Sliding Window)

TCP 流量控制 - Stop-and-Wait

TCP 流量控制 – Window Size

Sliding Window名詞說明

9 8

7 6

5 4

3 2

1

已收到ACK資料 可傳送或等待ACK的資料 尚未能傳送的資料

9 8

7 6

5 4

3 2

1

已傳送ACK的資料 等待接收的資料 尚未能接收的資料

傳送端傳送端

接收端接收端

Close Shrink Open

視窗的動作

Close Shrink Open

視窗的動作

TCP 流量控制 - Sliding Window

9 8 7 6 5 4 3 2

1 1 2 3 4 5 6 7 8 9

傳送端傳送端 接收端接收端

2 3

4 5

6 3 2 5

4 遺失 6

被接收端丟棄

9 8 7 6 5 4 3 2

1 1 2 3 4 5 6 7 8 9

3 ACK 4

？

NACK

ICMP Header

實驗導引

實驗 4.1 IP checksum與TCP checksum 實驗 4.2 了解port number的涵意

實驗 4.3 觀察TCP之連線及中斷連線

實驗 4.1 IP checksum與TCP checksum

實驗目的

™計算IP checksum

™計算TCP checksum

™比較IP checksum及TCP checksum

實驗架構圖

Step 1: 抓取TCP封包

™Host B:

ƒ 開啟 Ethereal ，interface選eth0，以觀察下列步驟之 封包

ƒ 開啟browser，於網址列輸入192.168.0.1 (在NetGuru 中每個Host皆內建Web server)

ƒ 利用抓取到的封包來計算IP checksum及TCP checksum

Step 2: 計算IP checksum

™抓取的封包展開Internet Protocol如下圖：

IP checksum計算方式

™IP header 的欄位，除了checksum 不列入 計算，以16 bits 為單位計算，如下表

4500+003c+3359+4000+4006+c0a8 +0002+c0a8+0001=279ee

ƒ 進位的2加回79ee中，2+79ee=79f0，換成二進位為 0111 1001 1111 0000， 取其1‘s補數1000 0110 0000

計算結果與原封包內容對照

Step 3: 計算TCP checksum

™抓取的封包展開Transmission Control Protocol如下圖：

Pseudo Header

™Source IP address = c0 a8 00 02 (192.168.0.2)

Destination IP address = c0 a8 00 01(192.168.0.1)

Protocol = 06 (TCP)

TCP length = 28 (40 bytes)

TCP header及TCP data

Checksum欄 位以0000取代

TCP checksum的計算方式

™將 TCP 的 Pseudo Header、TCP Header 及其 Data加總後(TCP checksum欄位不列 入計算)，若必要時會在後面補零，以確保是偶 數長度

™在本例，上列數字加起來為3fb58，將溢位 的”3”加回fb58結果為 fb5b，換成二進位為 1111 1011 0101 1011，取其補數0000 0100 1010 0100，轉換成16進位結果為 04a4

計算結果與原封包內容對照

™問題與討論

ƒ 比較IP checksum與TCP checksum計算方式有何不同?

實驗 4.2 了解port number的涵意

實驗目的

™了解如何查閱常用的port number

™觀察TCP封包

™觀察UDP封包

™觀察IP Fragment

實驗架構圖

Step 1: 觀察/etc/services 的內容

™任選NetGuru任一主機

ƒ 以命令列執行以下指令 more /etc/services

ƒ 請寫下pop3d, ftpd, telnetd的port number為何?

Step 2: 觀察TCP封包

™Host B：

ƒ 開啟 Ethereal ，interface選eth0

ƒ telnet 192.168.0.1 21

™另於Host B：

ƒ 再次開啟 Ethereal ，interface選eth0

ƒ telnet 192.168.0.1 ftp

™分析相關封包

ƒ 觀察上述兩者的封包有何不同?

ƒ 觀察telnet packet之source port為何?destination port 為何?

Port number說明

™Port 是用來區分同一台主機上面不同服務的機 制

™Port 的大小是 16 bits，也就是範圍從 0 到 65535

™在網路世界裡，有許多已經約定成俗的 Port Number，例如：Port 21 為 FTP； Port 23 為Telnet

ƒ 這些通用的Port Number可以參考 Linux 或Unix 系統 下 /etc/services 檔案的內容

ƒ 一般而言，0到1023保留給上述常用的服務，而 1024 到 65535可以供其他的程式或是使用者自行使用

Step 3: 使用udpsend與udpserver觀察UDP packets

™Host B:

ƒ 開啟 Ethereal ，interface選eth0，以觀察下列步驟之 封包

™Host A:

ƒ 執行#udpserver -p 9090

™Host B:

ƒ 執行#udpsend -d 192.168.0.1 -dport 9090 -m Hello (Host B傳送UDP Packet到Host A)

觀察UDP封包

™觀察source port，destination port等欄 位

™問題與討論：

ƒ 比較UDP封包與TCP封包的欄位有何差別，為什麼?

ƒ 假如udpserver尚未啟動，但udpsend已送出UDP封 包，會有什麼現象?

說明：udpserver與udpsend

™此二指令是NetGuru中特有的指令(非Linux標 準指令)，其目的為了方便老師講解及幫助學生 了解UDP，相關參數如下：

™udpserver

–p：指要開啟UDP Server 之 Port

–s：預計跟系統 “要” 一個的空間，以方便讀取接收到的 UDP Data

倘若沒有輸入此參數，就會執行預設值(1024 bytes) (直接執行udpserver就會顯示所有參數的簡介)

™udpsend

–dport：要傳送到 UDP Server 的哪一個 Port 倘若沒有輸入此參數，就會執行預設值(9090) –d：UDP Server IP 此參數一定要設定

–b：UDP Client 要傳送多少個 ‘*’ 字元的Data給UDP Server

例如： udpsend –b 4000 ，是指送出 UDP Data 為 4000 bytes ， 內容都是 ‘*’

–m ：UDP Client 要傳送什麼的Data給UDP Server 例如：udpsend –m bye ，是指送出 UDP Data 內容 為 ‘bye’

(直接執行udpsend就會顯示所有參數的簡介)

Step 4: 觀察IP fragment

™Host B：

ƒ 開啟 Ethereal ，interface選eth0，以觀察下列步驟之 封包

™Host A:

ƒ 執行#udpserver –p 9090

™Host B:

ƒ 執行#udpsend -d 192.168.0.1 -dport 9090 -b 2000 (Host B傳送一個data長度2000 bytes的UDP Packet 到Host A)

™分析相關封包

ƒ 在IP fragment的封包中，於第二個封包中有無port資 訊?

IP fragment圖解

IP header UDP

header UDP data (2000) bytes

IP header UDP

header UDP data (1472) bytes IP header UDP data (528) bytes

IP datagram

20 bytes 8 bytes

20 bytes 8 bytes 20 bytes

實驗 4.3 觀察TCP之連線及中斷連線

實驗目的

™了解TCP連線流程

™了解TCP中斷連線流程

™了解netstat指令用法

實驗架構圖

Step 1: 觀察telnet封包

™Host B：

ƒ 開啟 Ethereal ，interface選eth0，以觀察下列步驟之 封包

™Host B:

ƒ telnet 192.168.0.1

ƒ 帳號admin，密碼123456

ƒ exit

™分析相關封包

ƒ 觀察三向交握之過程(觀察Flag之變化)

ƒ 觀察輸入帳號和密碼的過程

ƒ 觀察exit的過程(觀察Flag之變化)

觀察三向交握之過程

觀察輸入帳號和密碼的過程

觀察exit的過程

Step 2: 觀察ftp封包

™Host B：

ƒ 開啟Ethereal，interface選eth0，以觀察下列步驟之封 包

™Host B:

ƒ ncftp –uadmin –p123456 192.168.0.1

ƒ exit

™分析相關封包

ƒ 觀察三向交握之過程(觀察Flag之變化)

ƒ 觀察輸入帳號和密碼的過程

ƒ 觀察logout(exit)的過程(觀察Flag之變化)

觀察三向交握之過程

觀察輸入帳號和密碼的過程

觀察logout的過程

Step 3:利用netstat指令，觀察TCP連線狀態

™Host A：

ƒ netstat –l (察看目前在LISTEN State有哪些 Socket)

ƒ netstat –tcp

™Host B：

ƒ ncftp –uadmin –p123456 192.168.0.1

™Host A：

ƒ Ctrl + C中斷netstat，觀察連線程序

netstat –l

™察看目前在LISTEN State有哪些 Socket

netstat –tcp

™觀察連線程序

TCP Connection State Diagram