網站設計 | 廢棄物清運,大型垃圾清運,大型家具回收-台北清潔公司

WireShark——IP協議包分析(Ping分析IP協議包)

Posted on 2020-10-062020-10-06 by admin

互聯網協議 IP 是 Internet Protocol 的縮寫，中文縮寫為“網協”。IP 協議是位於 OSI 模型中第三層的協議，其主要目的就是使得網絡間能夠互聯通信。前面介紹了 ARP 協議，該協議用在第二層處理單一網絡中的通信。與其類似，第三層則負責跨網絡通信的地址。在這層上工作的不止一個協議，但是最普遍的就是互聯網協議（IP）

1. IP協議介紹

互聯網協議地址（Internet Protocol Address，又譯為網際協議地址），縮寫為 IP 地址（IP Address）。在上一章介紹了 ARP 協議，通過分析包可以發現它是依靠 MAC 地址發送數據的。但是，這樣做有一個重大的缺點。當 ARP 以廣播方式發送數據包時，需要確保所有設備都要接收到該數據包。這樣，不僅傳輸效率低，而且局限在發送者所在的子網絡。也就是說，如果兩台計算機不在同一個子網絡，廣播是傳不過去的。這種設計是合理的，否則互聯網上每一台計算機都會受到所有包，將會導致網絡受到危害。互聯網是無數子網共同組成的一個巨型網絡。

圖中就是一個簡單的互聯網環境，這裏列出了兩個子網絡。如果想要所有電腦都在同一個子網絡內，這幾乎是不可能的。所以，需要找一種方法來區分那些 MAC 地址屬於同一個子網絡，那些不是。如果是同一個子網絡，就採用廣播方式發送。否則就採用“路由”發送。這也是在 OSI 七層模型中“網絡層”產生的原因。

它的作用就是引進一套新的地址，使得用戶能夠區分不同的計算機是否屬於同一個子網絡。這套地址就叫做“網絡地址”，簡稱“網址”。但是，人們一般叫做是 IP 地址。這樣每台計算機就有了兩種地址，一種是是 MAC 地址，另一種是網絡地址（IP 地址）。但是，這兩種地址之間沒有任何聯繫，MAC 地址是綁定在網卡上的，網絡地址是管理員分配的，它們只是隨機組合在一起。

2. IP地址

IP 地址是 IP 協議提供的一種統一的地址格式。它為互聯網上的每一個網絡和每一台主機分配一個邏輯地址，以此來屏蔽物理地址的差異。IP 地址分為 IPv4（IP 協議的第四版）和 IPv6（IP 協議第六版）兩大類。目前，最廣泛使用的是 IPv4。在該版本中規定，該地址是由 32 個二進制位組成，用來標識連接到網絡的設備。由於讓用戶記住一串 32 位長的 01 字符確實比較困難，所以 IP 地址採用點分四組的表示法。

在點分四組表示法中，以 A、B、C、D 的形式構成 IP 地址的四組 1 和 0。它們分別轉換為十進制 0 到 255 之間的數，如圖 3.2 所示。

圖 3.2 显示了 IPv4 地址 11000000.10101000.00000000.00000001，進行了點分四組的表示法。從圖 3.2 中，可以看到這樣一串 32 位長的数字很不容易記住或者表示。但是採用點分四組的表示法，就可以將以上一個很長的字符串表示為 192.168.0.1。這樣，用戶就比較容易記住。

3. IP地址的構成

IP 地址之所以會被分成四個單獨的部分，是因為每個 IP 地址都包含兩個部分，分別是網絡地址和主機地址。網絡地址用來標識設備所連接到的局域網，而主機地址則標識這個網絡中的設備本身。例如，IP 地址 172.16.254.1 是一個 32 位的地址。假設它的網絡部分是前 24 位（192.168.254），那麼主機部分就是后 8 位（1）。處於同一個子網絡的計算機，它們 IP 地址的網絡部分必定是相同的。也就是說 172.16.254.2 應該與 172.16.254.1 處在同一個子網絡。

但是，只查看 IP 地址是無法判斷網絡部分的。這時候就需要使用另一個參數“子網掩碼”來判斷。所謂的“子網掩碼”就是表示子網絡特徵的一個參數。它在形式上等同於 IP 地址，也是一個 32 位二進制数字。它的網絡部分全部為 1，主機部分全部為 0。

下面以IP地址10.10.1.22為例，其二進制形式為00001010.00001010.00000001.00010110。為了能夠區分出 IP 地址的每一個部分，將使用子網掩碼來表示。在本例中，10.10.1.22 的子網掩碼是 11111111.11111111.00000000.00000000。這就意味着 IP 地址的前一半（10.10 或者 00001010.00001010）是網絡地址，而後一半（1.22 或者 00000001.00010110）表示是該網絡上的主機，如圖 3.3 所示。

在該圖中的子網掩碼也可以寫成點分四組的形式。比如子網掩碼11111111.11111111.0000000.000000，可以被寫成 255.255.0.0。

IP 地址和子網掩碼為簡便起見，通常會被些成無類型域間選路（Classless Inter Domain Routing，CIDR）的形式。在這種形式下，一個完整的 IP 地址後面會有一個左斜杠（/），以及一個用來表示 IP 地址中網絡部分位數的数字。例如，IP 地址 10.10.1.22 和網絡掩碼 255.255.0.0，在 CIDR 表示法下就會被寫成 10.10.1.22/16 的形式。

4. 捕獲IP數據包

1）什麼是 IP 數據報

TCP/IP 協議定義了一個在因特網上傳輸的包，稱為 IP 數據報（IP Datagram）。IP 數據報是一個與硬件無關的虛擬包，由首部（header）和數據兩部分組成。首部部分主要包括版本、長度、IP 地址等信息。數據部分一般用來傳送其它的協議，如 TCP、UDP、ICMP 等。

IP 數據報的“首部”部分的長度為 20 到 60 個字節，整個數據報的總長度最大為 65535 字節。因此，理論上一個數據報的“數據”部分，最長為 65515 字節。由於以太網數據報的 “數據”部分，最長只有 1500 字節。因此如果 IP 數據報超過了 1500 字節，就需要分割成幾個以太網數據報分開發送了。

2）TTL

捕獲 IP 協議包和其它包有點區別，因為在 IP 協議中涉及到一個 TTL（time-to-live，生存時間）值問題。TTL 值指定數據包被路由器丟棄之前允許通過的網段數量。當數據包每經過一個路由器，其 TTL 值將會減一。關於 TTL 的詳細信息，在後面進行介紹。下面將介紹捕獲 IP 協議包，Wireshark 的位置。

為了證明 TTL 值的變化，本例中選擇使用三個路由器來捕獲數據包。捕獲 IP 協議數據包的實驗環境，如圖 3.4 所示。

從圖中，可以看到使用兩個路由器，將三台主機分割成兩個網段。這三台主機的 IP 地址，在圖 3.4 中已經標出。在本例中，Wireshark 可以在 PC1 和 PC2 任意一台主機上運行。但是，不可以在 PC3 上運行。因為，在後面將會分別分析同網段和不同網段中 IP 協議包。如果在 PC3 上捕獲數據包，只能捕獲同網段的 IP 數據包。

3) 捕獲數據包

① 訪問一個網頁

打開瀏覽器，訪問 http://www.baidu.com 網站，將捕獲到如圖所示的界面。

從該界面的 Protocol 列，可以看到捕獲到有 DNS、TCP、HTTP 等協議的包。在這些包中，都包含由 IP 頭部的詳細信息。但是，這樣可能會影響對 IP 協議包的分析。

② 執行 ping 命令

為了不受很多協議的影響，這裏通過執行 ping 命令僅捕獲 ICMP 協議的數據包。此時在主機 PC1 上執行 ping 命令，分別 pingPC2 和 PC3。執行命令如下所示：

C:\Users\Administrator>ping 192.168.5.4 C:\Users\Administrator>ping 192.168.6.103

執行以上命令后，捕獲到的數據包如圖所示。

圖捕獲到的 IP 協議包

從該界面的 Protocol 列，可以看到都是 ICMP 協議的包，而且每個包的顏色也都是相同的。雖然從該界面看到捕獲到的數據包很多，但是只需要分析其中兩個包，就可以很清楚的理解 IP 協議包格式。此時，用戶還可以使用 IP 的显示過濾器對數據包進行過濾。如過濾僅显示主機 PC3（192.168.6.103）的數據包，輸入過濾器 ip.addr==192.168.6.103，显示界面如圖所示。

從該界面可以看到，以上數據包都是發送/來自 192.168.6.103 的數據包。

4) 捕獲 IP 分片數據包

在上面提到說，如果一個數據包超過 1500 個字節時，就需要將該包進行分片發送。通常情況下，是不會出現這種情況的。但是為了幫助用戶更清晰的理解 IP 協議，下面通過使用 ICMP 包，來產生 IP 分片數據包。本節將介紹如何捕獲到 IP 分片數據包。

使用 ICMP 包進行測試時，如果不指定包的大小可能無法查看到被分片的數據包。由於 IP 首部佔用 20 個字節，ICMP 首部占 8 個字節，所以捕獲到 ICMP 包大小最大為 1472 字節。但是一般情況下，ping 命令默認的大小都不會超過 1472 個字節。這樣，發送的 ICMP 報文就可以順利通過，不需要經過分片后再傳輸。如果想要捕獲到 IP 分片包，需要指定發送的 ICMP 包必須大於 1472 字節。

捕獲 IP 分片的數據包。具體操作步驟如下所示：

（1）啟動 Wireshark 捕獲工具。

（2）在 Wireshark 主界面的菜單欄中依次選擇 Capture|Options，或者單擊工具欄中的（显示捕獲選項）圖標打開 Wireshark 捕獲選項窗口，如圖所示。

圖捕獲選項界面

（3）在該界面設置捕獲接口、捕獲過濾器及捕獲文件的位置。這裏將捕獲的數據保存到 ip-fragment.pcapng 捕獲文件中，如圖 3.10 所示。以上信息配置完后，單擊 Start 按鈕開始捕獲數據包，如圖所示。

圖開始捕獲數據包

此時在主機 PC1 上執行 ping 命令，以產生 ICMP 數據包。執行命令如下所示：

C:\Users\lyw>ping 192.168.5.4 -l 3000

在該命令中，使用-l 選項指定捕獲包的大小為 3000 字節。執行以上命令后，將显示如下所示的信息：

正在 Ping 192.168.5.4 具有 3000 字節的數據:

來自 192.168.5.4 的回復: 字節=3000 時間=5ms TTL=64

從以上輸出信息中，可以看到捕獲到每個包的大小都為 3000 字節。這時候，返回到 Wireshark 界面停止捕獲數據，將显示如圖所示的界面。

圖 IP 分片數據包

從該界面可以很清楚的看到，和前面捕獲到的數據包不同。在該界面 Protocol 列，显示了 IPv4 協議的包。這是因為發送的數據包過大，所以經過了分片后發送的。

5、IP數據報首部格式

源 IP 地址和目的 IP 地址都是 IPv4 數據報首部最重要的組成部分。但是，在首部固定部分的後面還有一些可選字段，並且其長度是可變的。下面將詳細介紹 IP 數據報首部格式，如表 3-1 所示。

表 3-1 IP數據報首部格式

IP協議
偏移位	0～3	4～7	8～15	16～18	19～31
0	版本	首部長度	服務類型	總長度
32	標識符			標記	分段偏移
64	存活時間		1	首部校驗和
96	源IP地址
128	目的IP地址
160	選項
160或192+	數據

在表 3-1 中，每個字段代表的含義如下所示：

· 版本號：指 IP 協議所使用的版本。通信雙方使用的 IP 協議版本必須一致。目前廣泛使用的 IP 協議版本號為 4，即 IPv4。

· 首部長度：IP 的首部長度，可表示的最大十進制數值是 15。注意，該字段所表示的單位是 32 位字長（4 個字節）。因此，當 IP 首部長度為 1111（即十進制的 15）時，首部長度就達到 60 字節。當 IP 分組的首部長度不是 4 字節的整數倍時，必須利用最後的填充字段加以填充。

· 服務類型：優先級標誌位和服務類型標誌位，被路由器用來進行流量的優先排序。

· 總長度：指 IP 首部和數據報中數據之後的長度，單位為字節。總長度字段為 16 位，因此數據報的最大長度為 216-1=65535 字節。

· 標識符：一個唯一的標識数字，用來識別一個數據報或者被分片數據包的次序。

· 標識：用來標識一個數據報是否是一組分片數據報的一部分。標誌字段中的最低位記為 MF（More Fragment）。MF=1 即表示後面“還有分片”的數據報。MF=0 表示這已是若干數據包分片中的最後一個。標誌字段中間的一位記為 DF（Don’t Fragment），意思是“不能分片”。只有當 DF=0 時，才允許分片。

· 分片偏移：一個數據報是一個分片，這個域中的值就會被用來將數據報以正確的順序重新組裝。

· 存活時間：用來定義數據報的生存周期，以經過路由器的條數/秒數進行描述。

· 協議：用來識別在數據包序列中上層協議數據報的類型。如,ICMP則協議值為1,TCP協議值為6,UDP協議值為17;更多的請自行百度

· 首部校驗和：一個錯誤檢測機制，用來確認 IP 首部的內容有沒有被損壞或者篡改。

· 源 IP 地址：發出數據報的主機的 IP 地址。

· 目的 IP 地址：數據報目的地的 IP 地址。

· 選項：保留作額外的 IP 選項。它包含着源站選路和時間戳的一些選項。

· 數據：使用 IP 傳遞的實際數據

1）存活時間 TTL

存活時間（TTL）值定義了在該數據報被丟棄之前，所能經歷的時間，或者能夠經過的最大路由數目。TTL 在數據報被創建時就會被定義，而且通常在每次被發往一個路由器的時候減 1。

例如，如果一個數據報的存活時間是 2，那麼當它到達第一個路由器的時候，其 TTL 會被減為 1，並會被發向第二個路由。這個路由接着會將 TTL 減為 0。這時，如果這個數據報的最終目的地不在這個網絡中，那麼這個數據報就會被丟棄，如圖 3.13 所示。

圖 3.13就是數據報經過路由器后，TTL 值的變化。由於 TTL 的值在技術上還是基於時間的，一個非常繁忙的路由器可能會將 TTL 的值減去不止 1。但是通常情況下，還是可以認為一個路由器設備在多數情況下只會將 TTL 的值減去 1。

了解 TTL 值的變化是非常重要的。一般用戶通常所關心的一個數據報的生存周期，只是其從源前往目的地所花去的時間。但是考慮到一個數據報想要通過互聯網發往一台主機需要經過數十個路由器。在這個數據報的路徑上，它可能會碰到被錯誤配置的路由器，而失去其到達最終目的地的路徑。在這種情況下，這個路由器可能會做很多事情，其中一件就是將數據報發向一個網絡，而產生一個死循環。如果出現死循環這種情況，可能導致一個程序或者整個操作系統崩潰。同樣的，如果數據報在網絡上傳輸時，數據報可能會在路由器直接持續循環，隨着循環數據報的增多，網絡中可用的帶寬將會減少，直至拒絕服務（DoS）的情況出現。IP 首部中的 TTL 域，就是為了防止出現這種潛在的問題。

2）IP分片

數據報分片是將一個數據流分為更小的片段，是 IP 用於解決跨越不同類型網絡時可靠傳輸的一個特性。一個數據報的分片主要是基於第二層數據鏈路層所使用的最大傳輸單元（Maximum Transmission Unit，MTU）的大小，以及使用這些二層協議的設備配置情況。在多數情況下，第二層所使用的數據鏈路協議是以太網，以太網的 MTU 是 1500。也就是說，以太網的網絡上能傳輸的最大數據報大小是 1500 字節（不包括 14 字節的以太網頭本身）。

當一個設備準備傳輸一個 IP 數據報時，它將會比較這個數據報的大小，以及將要把這個數據報傳送出去的網絡接口 MTU，用於決定是否需要將這個數據報分片。如果數據報的大小大於 MTU，那麼這個數據報就會被分片。將一個數據報分片包括下列幾個步驟，如下所示：

（1）設備將數據分為若干個可成功進行傳輸的數據報。

（2）每個 IP 首部的總長度域會被設置為每個分片的片段長度。

（3）更多分片標誌將會在數據流的所有數據報中設置為 1，除了最後一個數據報。

（4）IP 頭中分片部分的分片偏移將會被設置。

（5）數據報被發送出去

6、分析 IP 數據包

通過前面對 IP 協議的詳細介紹及數據包的捕獲，現在就可以來分析 IP 數據包了。

1）分析IP首部

這裏以捕獲文件的第一幀為例，介紹 IP 數據包首部，如圖 3.14 所示。

在該圖中從 Packet Details 面板中，可以看到有 IPv4 協議的包。這裏就詳細介紹在該包中的詳細信息，如下所示：

Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0

以上信息表示是第一幀信息，其大小為 74 個字節。

Ethernet II, Src: Elitegro_3f:c3:e5 (00:19:21:3f:c3:e5), Dst: Giga-Byt_eb:46:8d (50:e5:49:eb:46:8d)

以上信息表示是以太網幀頭部信息。其中，源 MAC 地址為 00:19:21:3f:c3:e5，目標 MAC 地址為 50:e5:49:eb:46:8d。

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

以上信息表示IPv4包頭部信息。其中源IP地址為192.168.5.2，目標IP地址為192.168.5.4。在該包首部中還有很多其它字段的信息，下面將介紹該包中展開的所有信息。如下所示：

以上信息包括 IP 包首部的所有字段，對應到包首部格式中，如表 3-2 所示。

表 3-2 IP包首部格式

IP協議
偏移位	0～3	4～7	8～15	16～18	19～31
0	4	20	0x00	60
32	0x050e			0x00	0
64	64		ICMP(1)	0xea5c
96	192.168.5.2
128	192.168.5.4
160
160或192+

在該包中最後一行信息如下所示：

Internet Control Message Protocol

以上信息表示 ICMP 協議包信息。關於該協議的分析，在後面進行介紹。

2）分析IP數據包中TTL的變化

前面介紹過 TTL 值是經過路由器后才發送變化。也就是說如果在同一網段中傳輸數據包時，TTL 值是不變的。只有與非同網段的主機進行通信時，該數據包的 TTL 值才會發生變化。下面通過分析捕獲文件，來確定 TTL 值是否是這樣變化的。

① 分析同網段中數據包的 TTL 值

這裏同樣以捕獲文件為例，分析同網段 TTL 值的變化。在 ip.pcapng 捕獲文件中，1~8 幀都是主機 PC1（192.168.5.2）和 PC2（192.168.5.4）之間的通信。這八幀可以說是 4 個完整的數據包，也就是通過 ICMP 協議的發送和響應包。這裏以 ip.pcapng 捕獲文件中的 3、4 幀為例，分析這兩個包中的 TTL 值。其中，3、4 幀的信息如圖 3.15 所示。

從該界面的 Packet List 面板中，Info 列可以看到 3、 4 幀包信息分別是 Echo（ping）request （請求）和 Echo（ping）reply（響應）。也就是說 192.168.5.2（PC1）發給 192.168.5.4 的包是一個請求包，192.168.5.4（PC2）的包是一個響應包。其中，這兩台主機是在同一個網絡中，所以這兩個包的 TTL 值應該相同。下面分別來看這兩個包中 IP 包首部的相信信息。

第三幀的 IP 包首部信息如下所示：

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

Version: 4 #IP 協議版本號

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

Total Length: 60 #總長度

Identification: 0x050f (1295) #標識符

Flags: 0x00 #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不進行分片

..0. …. = More fragments: Not set #更多分片

Fragment offset: 0 #分片偏移

Time to live: 64 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0xea5b [validation disabled] #首部校驗和

Source: 192.168.5.2 (192.168.5.2) #源 IP 地址

Destination: 192.168.5.4 (192.168.5.4) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

以上信息是第三針中 IPv4 首部的詳細信息。從中可以看到，該包中的 TTL 值是 64。第四幀的 IP 包首部信息如下所示

Internet Protocol Version 4, Src: 192.168.5.4 (192.168.5.4), Dst: 192.168.5.2 (192.168.5.2)

Version: 4 #IP 協議版本號

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

Total Length: 60 #總長度

Identification: 0xc71d (50973) #標識符

Flags: 0x00 #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不進行分片

..0. …. = More fragments: Not set #更多分片

Fragment offset: 0 #分片偏移

Time to live: 64 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0x284d [validation disabled] #首部校驗和

[Good: False]

[Bad: False]

Source: 192.168.5.4 (192.168.5.4) #源 IP 地址

Destination: 192.168.5.2 (192.168.5.2) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

從以上信息中，可以看到每個字段的信息都和第三幀 IP 包首部的信息都相同。這兩個包中的生存期（TTL），沒有發生變化。這是因為，主機 PC1 和 PC2 在同一個網段內，它們之間傳輸的數據不需要經過路由器。

② 分析不同網段中數據包的 TTL 值

下面以捕獲文件為例，分析不同網段 TTL 值的變化。在 ip.pcapng 捕獲文件中，9-16 幀是兩台（PC1 和 PC3）不同網段主機之間通信的數據包，如圖 3.16 所示。

在該界面显示的包同樣是四個完整的 ICMP 包，一個是請求包，一個是響應包。這裏分析 9、10 幀中 IPv4 首部的詳細信息，如下所示。

第 9 幀 IPv4 首部信息，如下所示：

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.6.103 (192.168.6.103)

Version: 4 #IP 協議版本號

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

Total Length: 60 #總長度

Identification: 0x0512 (1298) #標識符

Flags: 0x00 #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不進行分片

..0. …. = More fragments: Not set #更多分片

Fragment offset: 0 #分片偏移

Time to live: 64 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0xe8f5 [validation disabled] #首部校驗和

[Good: False]

[Bad: False]

Source: 192.168.5.2 (192.168.5.2) #源 IP 地址

Destination: 192.168.6.103 (192.168.6.103) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

以上包信息，是主機 PC1 發送給 PC3 的 IP 包首部信息。其中，TTL 值為 64。

第 10 幀 IPv4 首部信息，如下所示：

Internet Protocol Version 4, Src: 192.168.6.103 (192.168.6.103), Dst: 192.168.5.2 (192.168.5.2)

Version: 4 #IP 協議版本號

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

Total Length: 60 #總長度

Identification: 0xa206 (41478) #標識符

Flags: 0x00 #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不進行分片

..0. …. = More fragments: Not set #更多分片

Fragment offset: 0 #分片偏移

Time to live: 63 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0x4d01 [validation disabled] #首部校驗和

[Good: False]

[Bad: False]

Source: 192.168.6.103 (192.168.6.103) #源 IP 地址

Destination: 192.168.5.2 (192.168.5.2) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

以上包信息，是主機 PC3 發送給 PC1 的 IP 包首部信息。從以上信息中，可以看到該 IPv4 首部中 TTL 值為 63。由此可以說明，PC3 發送回 PC1 的數據包經過了一個路由器。

③ IP 分片數據包分析

下面以捕獲文件為例，詳細分析 IP 分片。打開 ip-fragment.pcapng 捕獲文件，显示界面如圖 3.17 所示。

在該捕獲文件中，也是捕獲了四個 ping 包。1~6 幀是一個完整的 ping 包，其中 1~3 幀是 ping 請求包，4~6 幀是 ping 響應包。也就是說，將第一個 ping 請求包，分為了 1~3 個數據包。下面將詳細分析 1~3 幀的詳細信息。

⑴ 第 1 幀數據包

第 1 幀數據包詳細信息如圖 3.18 所示。

從該界面的 Packet Details 面板中，可以看到有四行信息。分別如下所示：

Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0

以上信息表示第 1 幀數據包的信息，其大小為 1514 字節。

Ethernet II, Src: Elitegro_3f:c3:e5 (00:19:21:3f:c3:e5), Dst: Giga-Byt_eb:46:8d (50:e5:49:eb:46:8d)

以上信息表示以太網幀頭部信息。其中源 MAC 地址為 00:19:21:3f:c3:e5，目標 MAC 地址為 50:e5:49:eb:46:8d。

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

以上信息表示 IPv4 頭部信息。在該頭部包括了具體的詳細信息。展開該行信息，內容如下所示：

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

Version: 4 #IP 協議版本

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

0000 00.. = Differentiated Services Codepoint: Default (0x00)

…. ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)

Total Length: 1500 #總長度

Identification: 0x05a3 (1443) #標識符

Flags: 0x01 (More Fragments) #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不能分片。這裏的值為 0，表示可以進行分片

..1. …. = More fragments: Set #更多分片。這裏的值為 1，表示還有分片的數據包

Fragment offset: 0 #分片偏移

Time to live: 64 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0xc427 [validation disabled] #首部校驗和

[Good: False]

[Bad: False]

Source: 192.168.5.2 (192.168.5.2) #源 IP 地址

Destination: 192.168.5.4 (192.168.5.4) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

Reassembled IPv4 in frame: 3 #重組 IPv4 包

Data (1480 bytes) #數據

Data: 0800cfd0000100016162636465666768696a6b6c6d6e6f70…

[Length: 1480] #長度為 1480 字節

以上信息是第 1 幀 IPv4 首部的詳細信息。從以上更多分片和分片偏移域部分，可以判定該數據包是分片數據包的一部分。這是后被分片的數據包，就會有一個大於 0 的分片偏移或者就是設定了更多標誌為。從以上信息，可以看到更多分片標誌位被設定，也就是接收設備應該等待接收序列中的另一個數據包。分片偏移為 0，表示這個數據包是這一系列分片中的第一個包。所以，後面至少還有一個包。接下來看第二幀包信息。以上信息對應的 IPv4 首部格式中，显示結果如表 3-3 所示

⑵ 第 2 幀數據包

第 2 幀數據包詳細信息如圖 3.19 所示。

從 Wireshark 的 Packet Details 面板中，可以看到有四行詳細信息。而且包大小，和第一個數據包的大小相同。下面將分析該包的詳細信息，如下所示。

Frame 2: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) on interface 0

以上信息表示，這是第 2 幀的詳細信息。其中，該包的大小為 1514 個字節。

Ethernet II, Src: Elitegro_3f:c3:e5 (00:19:21:3f:c3:e5), Dst: Giga-Byt_eb:46:8d (50:e5:49:eb:46:8d)

以上信息表示以太網幀頭部信息。其中，源 MAC 地址為 00:19:21:3f:c3:e5，目標 MAC 地址為 50:e5:49:eb:46:8d。

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

以上信息表示 IPv4 首部的詳細信息。下面將詳細分析該包中每個字段的值，如下所示：

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

Version: 4 #IP 協議版本

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

0000 00.. = Differentiated Services Codepoint: Default (0x00)

…. ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)

Total Length: 1500 #總長度

Identification: 0x05a3 (1443) #標識符

Flags: 0x01 (More Fragments) #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不能分片。這裏的值為 0，表示可以進行分片

..1. …. = More fragments: Set #更多分片。這裏的值為 1，表示還有分片的數據包

Fragment offset: 1480 #分片偏移

Time to live: 64 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0xc36e [validation disabled] #首部校驗和

[Good: False]

[Bad: False]

Source: 192.168.5.2 (192.168.5.2) #源 IP 地址

Destination: 192.168.5.4 (192.168.5.4) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

Reassembled IPv4 in frame: 3 #重組 IPv4 包

Data (1480 bytes) #數據

Data: 6162636465666768696a6b6c6d6e6f707172737475767761…

[Length: 1480] #長度為 1480 字節

根據以上信息介紹，可以看到在該包的 IPv4 首部也設定了更多分片的標誌為。而且可以看到，這裏的分片偏移值為 1480。該值是由最大傳輸單元（MTU）1500，減去 IP 首部的 20 個字節得到的。以上信息對應到 IPv4 首部格式中，显示信息如表 3-4 所示。

IP協議
偏移位	0～3	4～7	8～15	16～18	19～31
0	4	20	0x00	1500
32	0x05a3			0x01	1480
64	64		ICMP(1)	0xc36e
96	192.168.5.2
128	192.168.5.4
160
160或192+	1480

⑶ 第 3 幀數據包

第 3 幀數據包詳細信息如圖 3.20 所示。

從 Wireshark 的 Packet Details 界面可以看到，該包中显示了四行信息，並且該包的協議為 ICMP。下面將詳細分析該包中的信息。

Frame 3: 82 bytes on wire (656 bits), 82 bytes captured (656 bits) on interface 0

以上信息表示這是第 3 幀的詳細信息，其中包大小為 82 個字節。

Ethernet II, Src: Elitegro_3f:c3:e5 (00:19:21:3f:c3:e5), Dst: Giga-Byt_eb:46:8d (50:e5:49:eb:46:8d)

以上信息表示以太網幀頭部的詳細信息。其中，源 MAC 地址為 00:19:21:3f:c3:e5，目標 MAC 地址為 50:e5:49:eb:46:8d。

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

以上信息表示 IPv4 首部信息，這裏着重分析該部分的詳細信息。如下所示：

Internet Protocol Version 4, Src: 192.168.5.2 (192.168.5.2), Dst: 192.168.5.4 (192.168.5.4)

Version: 4 #IP 協議版本

Header length: 20 bytes #首部長度

Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #服務標識符

0000 00.. = Differentiated Services Codepoint: Default (0x00)

…. ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)

Total Length: 68 #總長度

Identification: 0x05a3 (1443) #標識符

Flags: 0x01 (More Fragments) #標誌

0… …. = Reserved bit: Not set #保留位

.0.. …. = Don’t fragment: Not set #不能分片。

..0. …. = More fragments: Not set #更多分片。

Fragment offset: 2960 #分片偏移

Time to live: 64 #生存期

Protocol: ICMP (1) #協議

Header checksum: 0xe84d [validation disabled] #首部校驗和

[Good: False]

[Bad: False]

Source: 192.168.5.2 (192.168.5.2) #源 IP 地址

Destination: 192.168.5.4 (192.168.5.4) #目標 IP 地址

[Source GeoIP: Unknown] #源 IP 地理位置

[Destination GeoIP: Unknown] #目標 IP 地理位置

[3 IPv4 Fragments (3008 bytes): #1(1480), #2(1480), #3(48)] #三個 IPv4 分片，共 3000 個字節

[Frame: 1, payload: 0-1479 (1480 bytes)] #第 1 幀加載了 1480 個字節

[Frame: 2, payload: 1480-2959 (1480 bytes)] #第 2 幀加載了 1480 個字節

[Frame: 3, payload: 2960-3007 (48 bytes)] #第 3 幀加載了 48 個字節

[Fragment count: 3] #分片數為 3

[Reassembled IPv4 length: 3008] #重組 IPv4 長度為 3008

[Reassembled IPv4 data: 0800cfd0000100016162636465666768696a6b6c6d6e6f70…] #重組 IPv4 數據

根據以上信息的描述，可以看到該數據包沒有設定更多分片標誌位，也就表示該數據包是整個數據流中的最後一個分片。並且其分片偏移設定為 2960，是由 1480+(1500-20)得出的結果。這些分片可以被認為是同一個數據序列的一部分，因為它們 IP 首部中的標誌位於擁有相同的值。以上信息對應到 IP 首部格式，如表 3-5 所示

IP協議
偏移位	0～3	4～7	8～15	16～18	19～31
0	4	20	0x00	68
32	0x05a3			0x00	2960
64	64		ICMP(1)	0xe84d
96	192.168.5.2
128	192.168.5.4
160
160或192+

在該包中最後一行信息如下所示：

Internet Control Message Protocol

以上信息表示 ICMP 協議包信息。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

設計模式入門

Posted on 2020-10-062020-10-06 by admin

最近想學設計模式，網上說 HeadFirst 設計模式書挺好的，我來此再鞏固一篇。

故事是這樣的：小明是一個剛畢業的小伙子，他來到了一個遊戲公司實習，項目經理分配了一個實習任務給小明：

設計一個遊戲角色，角色屬性包括(攻擊力，防禦力，敏捷度…等等)，以及兩個召喚師技能(閃現和引燃)。

小明想這麼簡單的嗎，如是他用了一天的時間寫好了如下代碼

public class GameRole {
    
    private int atk; // 攻擊力
    private int def; // 防禦力
    private int dex; // 敏捷度
    
    public void flash_move() {
        System.out.println("指定方向瞬移一段距離");
    }
    
    public void ignite() {
        System.out.println("使其處於燃燒狀態 5 s");
    }
}

項目經理看到小明這麼快就完成了任務，表揚了一下小明，小明心裏樂開了花。然後項目經理又布置了一項任務給小明：
再設計兩個角色，他們的召喚師技能分別為(閃現，治療),（閃現，傳送)。

小明心想這難不倒我，然後他仍然只花了一天的時間就寫好了如下代碼：

public class GameRole {
    
    private int atk; // 攻擊力
    private int def; // 防禦力
    private int dex; // 敏捷度
    
    public void flash_move() {
        System.out.println("指定方向瞬移一段距離");
    }
    
    public void ignite() {
        System.out.println("使附近100碼內隊友恢復30%的血量");
    }
}

public class GameRole {
    
    private int atk; // 攻擊力
    private int def; // 防禦力
    private int dex; // 敏捷度
    
    public void flash_move() {
        System.out.println("指定方向瞬移一段距離");
    }
    
    public void ignite() {
        System.out.println("傳送至己方非英雄單位位置處");
    }
}

小明興高采烈的跑去給項目經理看了，項目經理看到小明過來了，心裏覺得這小伙子不錯麻，這麼快就做完了。

然後項目經理便看了他的代碼，這不看不要緊，一看便指着小明罵道：你真是一個糟糕的程序員！！！然後便讓小明改代碼去了。

小明此時還不太明白，我功能都實現了啊，沒啥毛病阿，然後小明不明所以的便問了辦公室的職員，職員告訴他，你代碼冗餘度太高了。

小明一看發現果然如此，然後便花了一天的時間改成如下代碼：

public abstract class GameRole {
    
    private int atk; // 攻擊力
    private int def; // 防禦力
    private int dex; // 敏捷度
　　
　　// 省略 Getter and Setter method 
    
    public void flash_move() {
        System.out.println("指定方向瞬移一段距離");
    }   
    public abstract void skill();
}

public class Role_One extends GameRole {
    @Override
    public void skill() {
        // TODO Auto-generated method stub
        System.out.println("使其處於燃燒狀態 5 s");
    }
}

public class Role_Two extends GameRole {
    @Override
    public void skill() {
        // TODO Auto-generated method stub
        System.out.println("使附近100碼內隊友恢復30%的血量");
    }
}

public class Role_Three extends GameRole {
    @Override
    public void skill() {
        // TODO Auto-generated method stub
        System.out.println("傳送至己方非英雄單位位置處");
    }
}

這次小明覺得冗餘度確實降低了，然後便給項目經理看，項目經理看后覺得確實還行，便又分配了一個任務：
(遊戲用戶希望能自由選擇召喚師技能就好了)，所以任務是召喚師技能任意搭配。

小明心想：我寫的這種代碼似乎不用改耶，可以交差了，於是小明便偷懶了两天，然後便上報給項目經理了。

項目經理一看，這代碼沒有變化啊，便問小明，你代碼就這？小明回答是的，然後小明又被罵的狗血淋頭。

不明所以的小明又去問問辦公室的職員，你仔細想想，如果有100個(閃現，引燃)，100個(閃現，治療),100個(傳送，治療)呢？

小明突然恍然大悟，那還是有好高的冗餘度啊，經過三天思考後，小明想出了最終答案：

public abstract class GameRole {

    private int atk; // 攻擊力
    private int def; // 防禦力
    private int dex; // 敏捷度
    private Skills skill_One;
    private Skills skill_Two;
　　// 省略 Getter and Setter method
}

public class Role_Demo extends GameRole {
}

public interface Skills {
    public void skill();
}

public class Flush_Move implements Skills {
    @Override
    public void skill() {
        // TODO Auto-generated method stub
        System.out.println("指定方向瞬移一段距離");
    }
}

public class Ignite implements Skills {
    @Override
    public void skill() {
        // TODO Auto-generated method stub
        System.out.println("使其處於燃燒狀態 5 s");
    }
}

public class Treat implements Skills {

    @Override
    public void skill() {
        // TODO Auto-generated method stub
        System.out.println("使附近100碼內隊友恢復30%的血量");
    }
}

public class Main {
    public static void main(String[] args) {
        // TODO Auto-generated method stub
        Role_Demo role = new Role_Demo();
        role.setSkill_One(new Flush_Move());
        role.setSkill_Two(new Ignite());
        role.getSkill_One().skill();
        role.getSkill_Two().skill();
    }
}

小明寫完了，這次小明怕又被罵，便去問問職員小花了，小花說寫的不錯嗎，於是小明膽戰心驚的去交差了。

項目經理看到小明過來，看着小明的囧樣，內心是想笑的，然後看了看代碼發現這回沒啥問題了，便放心的交給它最後一個任務：

給每個英雄添加四個不相同的技能：

小明經過幾次寫代碼的經歷后，一天便寫出來了：

public abstract class GameRole {
    private int atk; // 攻擊力
    private int def; // 防禦力
    private int dex; // 敏捷度
    private Skills skill_One;
    private Skills skill_Two;
    
    // 省略 Getter and Setter method
    
    public abstract void Skill_One();
    public abstract void Skill_Two();
    public abstract void Skill_Three();
    public abstract void Skill_Four();
}

public class Role_Demo extends GameRole {

    @Override
    public void Skill_One() {
        // TODO Auto-generated method stub
    }

    @Override
    public void Skill_Two() {
        // TODO Auto-generated method stub    
    }

    @Override
    public void Skill_Three() {
        // TODO Auto-generated method stub    
    }

    @Override
    public void Skill_Four() {
        // TODO Auto-generated method stub    
    }
}

經過這幾次任務，小明感覺寫的代碼更漂亮，更優雅了，腰也不酸了，背也不疼了。小明上交任務后，項目經理也露出了滿意的笑容！

最後，小明成功通過了實習，然而項目經理給他分配了下一項任務……

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

巴西海岸漏油原因仍是謎成千上萬志工「挖黑泥」

Posted on 2020-10-052020-10-05 by admin

摘錄自2019年10月21日自由時報報導

巴西日前發生大規模漏油事件後，對當地北部約2100公里、橫跨數州的海岸線造成嚴重破壞，雖已進入調查，但至今漏油原因尚未查明，而當地政府因未積極採取行動，遭當地環保團體抨擊；所幸，已有成千上萬的志工在受污染區域「挖黑泥」，將遍布海灘的「油污」慢慢除去，而這些志工僅在伯南布哥州（Pernambuco）就已經清出30噸油污。

油污從9月2日開始出現，而這些污染物質經檢驗，已證實為石油原油。海洋學家阿勞霍（Maria Christina Araujo）指出，「此次漏油對受污染區域當地生物的破壞可能將無法彌補，需要數年才能逐漸恢復當地生態系統。」而巴西環境與可再生資源研究所（Ibama）也證實，有15隻海龜和2隻鳥被油污殺死，且有照片佐證這些生物遭黑色油污覆蓋致死，而巴西享譽世界的的珊瑚礁也受到油污的破壞。

照片來源：Kleber from Burgos / WWF-Brasil

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

.NET Core Hangfire周期性作業調度問題

Posted on 2020-10-052020-10-05 by admin

前言

四月中旬Hangfire團隊發布了1.7.11版本，在使用周期性作業調度過程中發現一個問題，這個問題應該一直未解決，故做此記錄，希望遇到的童鞋根據項目業務而避開這個問題。

周期性作業調度

我們依然是在控制台中進行測試，下載所需包請參考官方文檔，這裏不再敘述，首先我們在內存中存儲數據，如下：

var storageOpts = new MemoryStorageOptions();

GlobalConfiguration.Configuration.UseMemoryStorage(storageOpts);

using var server = new BackgroundJobServer();

RecurringJob.AddOrUpdate("job1", () => Print1(), "*/10 * * * * *", TimeZoneInfo.Local);

RecurringJob.AddOrUpdate("job2", () => Print2(), "*/10 * * * * *", TimeZoneInfo.Local);

RecurringJob.AddOrUpdate("job3", () => Print3(), "*/10 * * * * *", TimeZoneInfo.Local);

public static void Print1()
{
    Console.WriteLine("start1");
}

public static void Print2()
{
    Console.WriteLine("start2");
}

public static void Print3()
{
    Console.WriteLine("start3");
}

Hangfire已支持秒級（1.7+）周期作業調度，如上代碼，我們每隔10秒執行上述3個作業，打印如下：

基於內存存儲間隔10秒執行對應作業，根據上述打印結果來看沒有問題，接下來我們使用SQLite來存儲作業數據看看，首先下載Hangfire.SQLite包，針對控制台需進行如下配置

GlobalConfiguration.Configuration.UseSQLiteStorage("Data Source=./hangfire.db;");

當我們啟動控制台時一定會拋出如下異常，其異常旨在表明需要SQLite驅動

我們去下載微軟官方針對SQLite的驅動（Microsoft.Data.Sqlite）

接下來我們將發現對於每一個作業都會重複執行多次，如下：

猜測只會在SQLite數據庫中才會存在問題吧，為了解決這個問題，做了一點點嘗試，但還是無法從根本上完全解決，我們知道Hangfire服務的默認工作數量為當前機器的處理器數量乘以5即（Environment.ProcessorCount * 5），那麼我們嘗試給1是不是可以規避這個問題

var options = new BackgroundJobServerOptions()
{
    WorkerCount = 1
};

using var server = new BackgroundJobServer(options);

上述設置后，我們可以看到貌似只執行了一次，但是這種情況還是是隨機的並不靠譜，比如多執行幾次看看，會出現如下可能情況

沒招了，找了下官方issue列表，發現此問題（https://github.com/mobydi/Hangfire.Sqlite/issues/2）一直處於打開狀態並未得到解決，所以要麼看看能否根據項目業務規避這個問題或者下載源碼自行調試解決

總結

本文是在使用Hangfire過程中發現SQLite數據庫出現的問題，因針對Hangfire的SQLite具體實現並不是官方團隊所提供，所以暫不能確定到底是Hangfire.SQLite包提供者的問題，根據issue描述大概率是Hangfire的一個bug，希望在SQLite存儲作業等數據存在的問題引起使用者注意。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

咖啡渣做太陽眼鏡暨時尚又環保

Posted on 2020-09-302020-09-30 by admin

摘錄自2019年12月12日公視報導

根據估計，全球每天喝掉20到25億杯咖啡，產生的咖啡渣非常驚人。烏克蘭有位新創工作者靈機一動，把咖啡渣拿來廢物利用，做出時尚又環保的太陽眼鏡。

來自烏克蘭的嘉利藍科，原本以修眼鏡為業，為了讓鏡框也能符合環保可分解的概念，他不斷尋找可以替代塑膠的材料，從薄荷到小麥和稻米，他通通都試過。最後發現咖啡渣混合植物油和亞麻纖維，經壓縮後裁切成框，效果最好。初步成形的鏡框，再經由手工琢磨拋光，就成為質感和造型出眾的太陽眼鏡，連鏡片也採用類似的植物纖維製成。嘉利藍科說：「這不只是生產商品而已，而是改變人們的認知，讓他們喜歡使用自然材質和自然成分，養成良心消費的習慣。」

咖啡渣眼鏡不但看得出天然質感，還可以聞到咖啡的香氣。嘉利藍科為自行研發的太陽眼鏡冠上新品牌，主要在咖啡廳和網路銷售，結果自去年推出以來，消費者的反應相當不錯，主要客戶來自歐美。消費者波利亞科夫表示，「它很創新也對環境友善，就保護生態環境而言，不只是在我國，而是放眼全世界，往這個方向發展是很重要的。」

咖啡渣材質比一般鏡架更輕，而當它們不再使用，長久放置於水或泥土中，便會自動分解成天然的肥料。嘉利藍科看好咖啡渣再利用的前景，未來計畫將它製成餐盤、牙刷和手機殼等日用品，希望更多人一起加入減塑做環保的行列。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

南極「頰紋企鵝」半世紀數量減少七成七

Posted on 2020-09-302020-09-30 by admin

摘錄自2020年2月12日公視報導

美國生物學家最近在南極調查發現，當地常見的一種「頰紋企鵝」，數量比50年前大幅銳減了七成七。科學家指出，南極溫度在過去2、30年間上升了5°C。而冰棚快速融解崩塌，讓企鵝失去原本的棲息地，食物供應也大受影響。

保育生物學家佛瑞斯特表示，「我們認為這裡基礎食物鏈的建構出了問題，有可能是浮游生物或是磷蝦減少，食物不如以往充足，導致企鵝數量不斷減少。問題在於這種情況會不會持續惡化。」

頰紋企鵝、皇帝企鵝和國王企鵝，數量都在急劇減少，這也意味著生態的多樣性與豐富性正遭遇巨大衝擊。環保團體呼籲聯合國在2030年之前，將全球30%的海域列為保護區，因為目前只有4%受到保護實在太少。而從目前企鵝數量銳減的情況看來，將南極海域列為保護區已經刻不容緩。

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

萬向收購A123未出局但其軍工業務已剔除

Posted on 2020-09-292020-09-29 by admin

美國電池生產商A123系統公司將招標出售整體資產。此前一度被認為出局的中國萬向集團，將和美國江森自控(Johnson Controls)競逐標的。日前，萬向美國公司總裁倪頻先生在接受記者採訪時證實，目前江森控股與萬向是合格的競標人。萬向競標的內容包括A123的非汽車業務，但剔除了其軍工業務。

3個月前，A123曾與萬向簽訂高達4.65億的戰略投資協定。A123在兩個月後突然宣佈，因無法完成與萬向的協議而宣佈破產，並立即與美國企業——江森自控簽訂收購其汽車業務的1.25億美元協定，使得外界猜測萬向出局。但此後不到一個月，萬向重新進入“戰局”，11月7日發出收購整體資產的保密提議。

從目前各路檔對照來看，萬向對於收購A123成竹在胸，可能早在8月份簽署第一份協議的時候，萬向已經對現在的局面有了預估，一切都在掌控之中。

A123拒絕在此時進行置評。不過其市場行銷和傳訊副總裁安迪·朱(Andy Chu)在公司博客上，連發數文澄清競標協調過程和債務人融資細節等，試圖撇清與萬向的關係。

萬向與江森自控所扮演的不同角色，使這場競標頗值得玩味。

根據相關檔，江森自控目前以“底標”身份參與競標，以1.25億美元收購A123的汽車業務。特拉華州破產法庭法官凱文·凱瑞(Kevin Carey)認定，由於享受“假馬競拍”保護(stalking horse protection)，一旦江森自控沒有贏得標的，將得到大約550萬美元“分手費”和相關補償。

假馬競拍是指競標者提前競購資產，鎖定最低價格，其餘競標者則需要在此基礎之上出價。

儘管日本NEC和德國西門子表示了興趣，但目前真正走完程式的合格競標人，只有萬向與江森自控兩家。

不過，江森自控的底標是不完整的。由於目前江森自控競標的標的僅僅是A123的汽車業務，而萬向試圖收購的是其大部分業務，萬向的贏面更大。

倪頻表示：“到時候就需要看這些資產是否值這麼多錢了。如果資產價值存在的話，那麼對於我們來說，還有一些政府審批的工作要做完。”

他強調，新能源也是萬向的主要策略之一，今年萬向已經在美國投了5個新能源項目，A123這個專案從戰略上與萬向的發展計畫相符合。

此前維約曾向記者透露，大約在今年4月份，萬向主動找到了他們，開啟了談判。

不過倪頻強調：“萬向本身的投資策略比較保守，如果有其他企業進來，出了我們認為過高的價格，那麼我們可能也就不做了。”

12月11日，法庭將對競拍結果進行聽證。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

廣東省電動汽車產業標準體系建設項目正式啟動

Posted on 2020-09-292020-09-29 by admin

近日，廣東省產業標準體系及公共技術創新服務平臺建設專案在深圳啟動，加快對《廣東省電動汽車產業標準體系規劃與路線圖(2011-2015)》提出的72項缺失標準的研製，以促進廣東省電動汽車業快速發展。

此次啟動的項目將充分整合廣東全省電動汽車產業在人才、技術、設備和科研等方面的優勢，破解目前面臨的難題。同時，廣東省將建立電動汽車標準與專利資訊服務平臺，提供國內外電動汽車標準體系資料庫查詢、標準資訊服務等。到2015年，廣東全省將初步建立適應電動汽車發展要求的配套設施網路，形成電動汽車地方性標準規範，實現電動汽車在城市公交系統的規模應用，讓電動轎車走入普通家庭。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準

日產汽車2015年將生產首款中國品牌電動汽車

Posted on 2020-09-282020-09-28 by admin

日產汽車高管日前表示，公司到2015年將通過其中國品牌開始生產首款Venucia e30。

公司2013年還將在中國15座城市與當地政府聯合啟動試驗項目，以推廣Venucia e30。日產目前正在武漢和廣州推廣自己品牌的電動汽車Leaf。

日產在中國有多家生產廠房，並計畫2014年在大連再新增1處，但受日本“國有化”釣魚島鬧劇影響，日產在中國的銷售大幅衰退。其10月在華銷售新車6.43萬輛，同比下滑40.7%，降幅較9月的35%進一步擴大。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※帶您來了解什麼是 USB CONNECTOR ?

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※教你寫出一流的銷售文案?

特斯拉純電動轎車Model S醞釀漲價已預定者不受影響

Posted on 2020-09-282020-09-28 by admin

美國特斯拉公司旗下的Model S將在未來數周內迎來一次價格上漲，但已經成功預約，並交付訂金的消費者購買該車不在此次“漲價”範圍內。目前，特斯拉方面尚未公佈具體漲額。

雖然特斯拉旗下的Roadster和Model S銷售火爆，但特斯拉公司仍未擺脫負債困擾。顯然，特斯拉方面試圖通過提高Model S價格獲得更多利潤。

對於Model S漲價一事，特斯拉公司並未公佈更多細節，公司發言人克裡斯汀娜(Christina Ra)僅在官方博客上表示，“未來幾周內，我們會公佈更多資訊，但目前對此事不做回應”。

鑒於Model S受到眾多消費者熱捧，部分業內人士認為這款車價格上漲不會削弱消費者對特斯拉的興趣，特斯拉公司首席設計師弗朗茲(Franz von Holzhausen)也透露，Model S本季度的預訂量再創新高。

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理
【其他文章推薦】

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※台北網頁設計公司這麼多該如何選擇?

※智慧手機時代的來臨，RWD網頁設計為架站首選

※評比南投搬家公司費用收費行情懶人包大公開

※幫你省時又省力,新北清潔一流服務好口碑

※回頭車貨運收費標準