[連載]網絡的琴弦：玩轉IP看監控（10月出版，401#ONVIF 396#GB/T 28181）

網語者

《網絡的琴弦：玩轉IP看監控》出版，感謝C114

筆者是家園的老網友了，我們以團隊執筆以確保每個部分的專業性：一群老家伙從IP網絡到IP監控，從業十多年，有扎實的積累。

去年春節，一位從事傳統模擬監控產品銷售和安裝的朋友咨詢：有沒一本合適的網絡教材，讓他能比較精通時下的IP監控知識，獨立定位和解決問題。我還真推薦不出一本適合的教材。

其實這也不奇怪，畢竟IP網絡本身擁有一個非常龐大的知識體系，每一小塊知識都足以編輯成為一本不薄的書籍。但對于從事IP監控研發和銷售的人員來說，并不需要對每一塊知識都深入至協議狀態機、異常處理、協議字段如何運用的程度，大家更需要的是一本貼合IP監控業務的IP網絡知識普及書籍，了解相關需求的背景，掌握相關特性的運用和相關知識的原理。有了這本書，若要繼續深入，可以直接閱讀相關RFC協議文檔。

所以，筆者以一位監控業務應用者的視角，按照需求問題提出、提供方案解決、基本原理剖析的方式，逐步深入闡述IP監控所涉及的相關IP特性知識點。

我們努力簡明清晰的梳理好，多用故事、知識結構化、圖表化，讓大�？戳擞鋹�，菜鳥獲得知識，所有人都有啟發提升。

補充內容 (2015-9-16 17:38):
書籍已經正式命名為《網絡的琴弦：玩轉IP看監控》，10月與大家見面

*******************************************
《網絡的琴弦：玩轉IP看監控》一書已正式出版，各大平臺有售！

網語者

通信技術你問我答 (積分兌獎)

點擊“只看該作者”高效瀏覽
http://www.wsonotifications.com/forum.php?mo ... =1&authorid=1129278


1        前言

2        老U的驛站監控
  2.1        模數混合監控……………………………………………… #3
  2.2        單點IP監控改造…………………………………………… #4
  2.3        以太網與交換機轉發
        2.3.1        以太網……………………………………………… #7
        2.3.2        轉發原理…………………………………………… #7
       2.3.3        基本配置典型實例
  2.4        互聯網與分層……………………………………………… #12
  2.5        IP與ARP解析
        2.5.1        IP地址……………………………………………… #36
        2.5.2        ARP解析…………………………………………… #40
        2.5.3        免費ARP…………………………………………… #43
        2.5.4        觸發機制…………………………………………… #43
  [Q&A]1萬路PON監控項目實戰疑惑：IP監控典型課題…… #45
        2.5.5        基本配置典型實例
  2.6        VLAN        
        2.6.1        VLAN基礎…………………………………………… #52
        2.6.2        交換機處理………………………………………… #52
        2.6.3        組網實戰…………………………………………… #60
        2.6.4        基本配置典型實例……………………………… #64
  [Q&A]我們的世界觀和方法論：反對病態的互聯網觀…… #73
  2.7        以太風暴與生成樹協議        
        2.7.1        以太風暴…………………………………………… #76
        2.7.2        生成樹協議………………………………………… #81
        2.7.3        基本配置典型實例………………………………… #82
  2.8        路由表與路由器轉發
        2.8.1        路由表……………………………………………… #86
        2.8.2        路由轉發…………………………………………… #88
        2.8.3        三層交換…………………………………………… #92
        2.8.4        基本配置典型實例……………………………… #102
  [Q&A]攝像頭的視頻流量到后端存儲和監控屏過程，組播… #103
  2.9        視頻碼流與突發
        2.9.1        基本概念…………………………………………… #110
  [Q&A]模擬高清四種制式優劣……………………… #111
        2.9.2        突發與緩存………………………………………… #119
        2.9.3        解決方案…………………………………………… #125
  2.10 WLAN
        2.10.1 無線技術…………………………………………… #148
        2.10.2 無線組網…………………………………………… #153
        2.10.3 信道干擾…………………………………………… #159
  2.11 POE
        2.11.1 POE原理............................................................ #170
        2.11.2 供電模式............................................................ #179
        2.11.3 功率限制...........................................................  #181
        2.11.4 基本配置典型實例.............................................  #182
3   老U的遠程監控
  3.1典型寬帶上網架構
        3.1.1 ADSL寬帶............................................................ #183
        3.1.2 PPPoE原理.......................................................... #194
        3.1.3 DHCP原理........................................................... #215
        3.1.4 DNS  原理........................................................... #239
        3.1.5 DNS高級特性...................................................... #333
   3.2 NAT
        3.2.1 NAT.................................................................... #339
        3.2.2 NAPT.................................................................. #341
        3.2.3 NAT映射表項與靜態映射.................................... #342
        3.2.4 不同類型的NAT................................................. #343
        3.2.5 ALG................................................................... #346
        3.2.6UPnP.................................................................. #349
  3.3 DDNS
        3.3.1 互聯網DDNS方案.............................................. #357
        3.3.2 安防DDNS方案................................................ #369

網語者

2老U的驛站監控

2.1模數混合監控

20世紀90年代末，不甘沉湎于波瀾不驚的生活的老U選擇了下海自主創業，利用自己的微薄積蓄在杭州風景秀麗的虎跑路旁開了一家自助休閑的驛站，供顧客喝茶、打牌、社交。

一天下午場歇時分，冬日的霞光透過南高峰濃郁的樹林鋪滿整個陽光茶房。斑駁的光柱里沖進來一位神情焦慮的中年人，他是中午在此喝茶的顧客，剛才上公交時突然發現丟失了錢包。雖然顧客沒有堅持認定錢包丟失在驛站，但老U還是很難過，替顧客難過，也替自己難過。

經過一宿慎重的考慮，他決定在驛站安裝一套監控系統：一臺數字硬盤錄像機DVR（Digital Video Recorder）通過幾根同軸電纜一對一地分別連接幾個模擬攝像機，覆蓋驛站的各個茶房。這套模數混合的監控系統在當時稱得上主流配置，雖然模擬攝像機的圖像分辨率只達到CIF級別，但好歹可以勉強的看到一些模糊的影像，相當于VCD效果的錄像足夠為顧客提供必要的線索，同時也為自家驛站提供一個避免糾紛的證據。


圖1.DVR通過同軸線纜連接模擬攝像機

---

說明：
CIF：352×288像素
4CIF：704×576像素
D1 ：720×576像素
720P：1280×720像素
1080P：1920×1080像素

網語者

2.2單點IP監控改造

經過幾年的用心經營，老U的休閑驛站以其優質的服務和良好的口碑在同行中脫穎而出，日漸上升的客源使得休閑驛站經常是一座難求。趁著紅火的勢頭，老U決定擴大經營，兼并了附近的幾家門面。自然，監控的部署也是必不可少的。
然而，不爽的事情出現了：新擴的茶房每新增一個攝像機都需新拉一根同軸線纜接到DVR所在的機房，施工成本按照線纜的長度計算，十分不劃算。

世間安得雙全法，不負如來不負卿，但IT的世界里還真有雙全法。那時度娘還沒出世，但BBS已經流行。經過一番線上交流和電子市場淘寶，老U發現一種叫IP監控的方案可以化解這個難題：錄像機和攝像機分別更換成網絡硬盤錄像機NVR（Network Video Recorder）和網絡攝像機IPC（IP Camera），由一種叫以太網交換機的設備通過網線將它們連接起來；如此，只需在機房和新擴的茶房之間拉“一根“網線就可以解決問題。再考慮到，原先采用同軸線纜傳輸模擬信號，圖像質量受環境干擾太大——干脆淘汰DVR和模擬攝像機，全線升級成“NVR+IPC”的全數字解決方案，如下圖。


圖2.交換機通過網線連接NVR和IPC


完成監控改造的老U一時成就滿滿，但他很好奇：NVR怎么從一根網線上區分來自不同IPC的視頻流，又如何將點播請求發送給正確的IPC的呢？

yehua

有小區內用EPON來做IP監控傳輸的案例？

網語者

有的，不過在后面章節，敬請等待

網語者

2.3以太網與交換機轉發

同軸線纜互聯常見的低成本方案是采用轉接器進行物理連接，此時來自多個模擬攝像機的模擬視頻信號就會相互產生干擾，導致DVR無法進行有效區分，所以通常不會用同一根同軸線纜傳輸多路模擬視頻——當然，這并不是說沒有技術可以解決這個問題，方案很多，卻不經濟，一般只有在歷史模擬監控項目的高清改造時才會考慮。模擬監控逐漸被歷史淘汰的另一個重要原因是，以太網和IP技術的生命力和發展潛力已經獲得了通信界的一致認同，并在后續的歷史進程中不斷煥發出蓬勃的生機。

2.3.1以太網

以太網（Ethernet）常見的線纜有雙絞線（即常說的“網線”）和光纖兩種，前者通信采用電信號，后者通信采用光信號。以太網是一種分組通信技術，這個分組叫“以太幀“，它負責承載各種數據在以太網線纜中的傳輸，就像無數輛裝載著信息段的集裝箱車奔跑在高速公路上一樣。

以太網交換機負責在局域網內連接各個設備：NVR、DVR、IPC、路由器、PC機、服務器等。這些設備各自擁有全球唯一的MAC地址（Media Access Control Address），或稱為硬件地址，采用十六進制數表示，共六個字節（48位）。其中，前三個字節（高位24位）是廠家的標識符，后三個字節（低位24位）由廠家自行指派給所生產的設備。例如：“48:EA:63:0E:B7:BF”，“48:EA:63”是浙江宇視科技有限公司的標識符，該設備由宇視科技出品。任何一個設備往其他設備發送以太幀，都需將自己的MAC地址寫在以太幀的源地址信息中，將目的設備的MAC地址寫在以太幀的目的地址信息中。

2.3.2轉發原理

交換機怎么知道該指引一個特定的以太幀往哪個或哪些端口轉發呢？交換機內部存在一個MAC地址表，每個表項至少包含MAC地址和設備端口號。轉發原則是：如果該表中存在該以太幀的目的MAC地址，則引導該幀往這個表項所對應的端口轉發出去；如果不存在，則往入端口之外的所有其他端口進行復制轉發。


圖3.MAC地址表

如圖3，當交換機s7502E-1收到一個目的地址為0000-0000-0006的以太幀，發現MAC地址表中存在該地址所對應的MAC表項，表項中的端口號為GigabitEthernet2/0/3，則引導該以太幀從該端口轉發出去。

---

說明：
這個原則適用于最常見的單播幀和廣播幀，組播幀的處理有些復雜，后續談到組播時再細聊。關于單播、組播和廣播的概念，我們將在下一節詳細闡述。

---

交換機有一個源（MAC）學習的關鍵特性：任何一個以太幀進入交換機，交換機都會記住該幀的源MAC地址，并將該MAC地址和入端口號綁定記錄在MAC地址表里，今后若收到目的地址為該MAC地址的以太幀，交換機就知道該指引它往該端口轉發了。例如，交換機從端口GigabitEthernet2/0/33收到一個源地址為0001-2828-0800的以太幀，就生成一個MAC地址表項，包含該MAC地址和該端口，如圖3。

交換機的原理是不是非常的簡單？我們再稍微擴展學習下。MAC表項通常還具備另外兩個屬性：老化時間和狀態。因為交換機的表項容量有限，所以暫時不用的MAC表項應該清除以節省表項空間，這就需要設置一個表項的存活期，即“老化時間”——H3C設備通常默認設置為300秒，300秒內若無對應源MAC地址的以太幀進來，表項就會被刪除，否則存活期會被刷新回300秒。既然有動態的源（MAC）學習機制，自然也可以通過手工靜態配置MAC表項，“狀態”這個字段就用來指明該表項源自動態學習還是靜態配置，靜態配置的表項沒有老化時間。兩個屬性的示例可見圖3。

---

說明：
現在大部分交換機的MAC表項都有VLAN ID這個重要屬性，我們留到后面講述VLAN時再詳細闡述。
交換機的基本原理清楚了，那么一根網線能夠同時承載多路視頻的原理也就清楚了：來自各個IPC的各路視頻被分拆成一個個小包（即所謂的“分組”），分別一個個裝載進以太幀并標記好源和目的MAC地址（即所謂的“封裝”）送往NVR，反過來NVR向各個IPC發送報文的過程也是一樣；由于采用的是分組技術，也就不存在相互干擾的困擾了。

---

不枉一番努力。老U心滿意足地泡了杯龍井茶，對著D1分辨率的清晰畫面，慢慢的品味起這明前新茶的芳香和杭城特有的滿園春色。
曼妙的霧氣讓他突然產生一個疑問：IPC將報文發給NVR時需將NVR的MAC地址填寫在以太幀的目的地址字段中，但它怎么知道NVR的MAC地址呢？

taojian723

樓主加油更新呀�。�！

spring_sky24

樓主繼續啊，不要tj了:)

網語者

spring_sky24 發表于 2015-6-23 15:10
樓主繼續啊，不要tj了

請放心，有保障：

連載前有思想準備是冷門，怕堅持不下去，提前寫好了70%才開始連載的：）

kakalala

樓主加油�。�！

網語者

2.4互聯網與分層

獨的人生是可悲的，于是家庭誕生了；再大的家庭也就那么點人脈，于是社會誕生了；在龐大復雜的社會體系里，個人才能體現出各方面的價值。計算機也是一樣，80年代為了實現資源共享，人們決定將單體計算機組建成網絡；到了90年代，人們不再滿足于這樣的局域網，決定將網絡聯網組建成網絡的網絡，于是出現了互聯網（Internet）。

由于局域網的技術紛繁多樣，除了現在占主流的以太網之外，歷史上還有各種其他網絡技術，相應的，硬件地址也不一定是MAC地址了。于是便產生了路由器，由路由器來負責連接這些網絡。這就意味著，每個局域網內部的信息傳輸有自己的鏈路層地址系統，且僅在該局域網內部有效，跨局域網的信息傳輸就需要制定一個更高層次的地址規范，來統一標記互聯網中的個體設備，于是，網絡的地址就出現了“分層“的需求，需要分層的，還有相應的協議處理機制。

我們常用的TCP/IP協議棧定義了一個五層架構：應用層、傳輸層、網絡層、鏈路層和物理層。其中協議部分只關注上面的四層。


TCP/IP協議棧定義的五層架構

---

說明：
開放系統互連參考模型 (Open System Interconnect 簡稱OSI）定義了七層模型：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層和應用層。其中會話層、表示層和應用層在TCP/IP協議棧中合并為應用層。

---

物理層指網線、光纖等物理傳輸媒介。

鏈路層主要包括操作系統中的設備驅動程序，包括網卡驅動，常與物理層傳輸媒介打交道。我們前面提到的以太幀和以太網交換機轉發即屬于本層范疇，而MAC地址就是鏈路層的硬件地址信息。

網絡層主要處理IP（Internet Protocol）報文在網絡之間的選路，這一層協議包括IP協議、Ping程序用到的ICMP協議等。
傳輸層主要為兩臺主機的應用程序通信提供傳輸通道的建立，常見的有TCP（Transmission Control Protocol 傳輸控制協議）和UDP（User Datagram Protocol用戶數據報協議）兩種。TCP協議提供可靠的傳輸保障機制，而UDP協議則不保證可靠性，傳輸可靠性由應用程序負責保證。

應用層負責特定應用程序的細節處理，比如錄像回放的點播功能處理等。

看到這里，老U心頭是一群泥馬呼嘯而過啊，為什么弄得這么復雜？好吧，我們來看個形象的比喻。A、B兩家公司是分別位于杭州和舊金山的知名安防公司，他們準備進行戰略合作，兩位CEO需要互通公函。在這個信息爆炸瞬息萬變的年代，CEO是絕不可能親自走路去送公函的，何況快遞業現在這么發達。公函需從杭州的A公司總部到達舊金山的B公司總部，什么交通工具可以一步到達呢？目前沒有，這中間需要經過杭州快遞員開車上門取貨，通過貨車送到杭州蕭山機場，然后通過飛機航運送到舊金山國際機場，然后再通過貨車送到B公司。至于怎么協調兩地貨車和飛機以保證公函的送達，那是快遞公司的事情。由于公函的重要性，公司的行政部門必須跟蹤確認公函的及時到達，若中間出現丟失，他們必須重新發函并與快遞公司進行交涉。

過程非常完美，對不對？其實整個模型與TCP/IP的五層架構非常類似：公路和空中航線是物理層；兩地的貨車和飛機是鏈路層，貨車只知道且負責本地區域的陸路傳遞，飛機只知道且負責航空傳遞，三個角色均不知道也不必知道其他兩個角色范疇內的傳輸機制；快遞公司負責協調公函從A公司送達B公司，這是網絡層；兩家公司的行政部門要確保公函的及時到達，這是傳輸層；兩家公司的CEO只管簽署公函即可，這就是應用層——協議其實就是現實社會的模型抽象，很有意思！

讓我們回到真實的TCP/IP世界，簡單瀏覽下這里的運作機制。

當我們在NVR的人機界面上點播了一路前端IPC的實況視頻，IPC的視頻流處理程序（應用層）對視頻進行壓縮編碼，然后交付TCP發送程序；TCP發送程序（傳輸層）根據實際傳輸狀況控制報文段的大小和重傳的必要性，進行TCP封裝后交付給IP包發送程序；IP包發送程序（網絡層）收到TCP報文后再封裝成IP包，通過查找路由表找到網關的IP地址和出接口，然后交付給以太幀發送程序；以太幀發送程序（鏈路層）通過查找ARP表（Address Resolution Protocol地址解析協議）完成對IP包的以太幀封裝，從正確的網口發送出去。而NVR從鏈路層收到這個以太幀，會剝掉以太幀封裝，再通過IP包接收程序剝掉IP封裝，最后通過TCP接收程序剝掉TCP封裝，還原出最初的視頻包交給視頻解碼程序處理。

這個過程中，TCP協議對發送報文段的尺寸控制和重傳控制是為了保證業務數據的完整性，而IP包處理程序的目標是實現網絡之間的信息選路和傳遞，以太幀處理程序的作用是為了實現局域網內的報文傳輸。任何一層的協議處理機制都是必不可少的。

網語者

歡迎各位網友提供任何建議和意見。

網語者

也歡迎安防領域的網友們提供項目設計和實施過程中遇到的各種問題，筆者會將相關信息補充到相關章節中。

junmily

有沒有無線監控的?

爻..

這作者看著像是宇視的吧？

網語者

無線當然是必須的啊，呵呵

wuhuanhao

學習

毒霸世界

一直在學習。

caoyy35

好貼