[连载]网络的琴弦：玩转IP看监控（10月出版，401#ONVIF 396#GB/T 28181）

网语者

《网络的琴弦：玩转IP看监控》出版，感谢Powered by ahtjzy.com

笔者是家园的老网友了，我们以团队执笔以确保每个部分的专业性：一群老家伙从IP网络到IP监控，从业十多年，有扎实的积累。

去年春节，一位从事传统模拟监控产品销售和安装的朋友咨询：有没一本合适的网络教材，让他能比较精通时下的IP监控知识，独立定位和解决问题。我还真推荐不出一本适合的教材。

其实这也不奇怪，毕竟IP网络本身拥有一个非常庞大的知识体系，每一小块知识都足以编辑成为一本不薄的书籍。但对于从事IP监控研发和销售的人员来说，并不需要对每一块知识都深入至协议状态机、异常处理、协议字段如何运用的程度，大家更需要的是一本贴合IP监控业务的IP网络知识普及书籍，了解相关需求的背景，掌握相关特性的运用和相关知识的原理。有了这本书，若要继续深入，可以直接阅读相关RFC协议文档。

所以，笔者以一位监控业务应用者的视角，按照需求问题提出、提供方案解决、基本原理剖析的方式，逐步深入阐述IP监控所涉及的相关IP特性知识点。

我们努力简明清晰的梳理好，多用故事、知识结构化、图表化，让大牛看了愉悦，菜鸟获得知识，所有人都有启发提升。

补充内容 (2015-9-16 17:38):
书籍已经正式命名为《网络的琴弦：玩转IP看监控》，10月与大家见面

*******************************************
《网络的琴弦：玩转IP看监控》一书已正式出版，各大平台有售！

网语者

威尼斯人官方网站技术你问我答 (积分兑奖)

点击“只看该作者”高效浏览
http://www.ahtjzy.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

好贴