Total Pageviews

Friday 9 June 2017

mDNS原理的简单理解

mDNS : multicast DNS ,规范文档地址: http://www.ietf.org/rfc/rfc6762.txt


在局域网内,你要通过一台主机和其他主机进行通信,你需要知道对方的 ip 地址,但是有些时候,你并不知道对方的 ip 地址,因为一般使用 DHCP 动态分配 ip 地址的局域网内,各个主机的 IP 地址是由 DHCP 服务器来帮你分配 IP 地址的。所以在很多情况下,你要知道对方的 IP 地址是比较麻烦的。转载请注明来自:http://www.binkery.com/
鉴于发现这篇文章最近的浏览量比较多,晚上也有不少转载,特别声明一下,文章水平可能不大够,只是我当时的一些理解,所以希望大家以批判的角度来看,然后又什么问题欢迎讨论。真心不希望误导大家^_^转载请注明来自:http://www.binkery.com/

mDNS 的工作原理

首先,在 IP 协议里规定了一些保留地址,其中有一个是 224.0.0.251,对应的 IPv6 地址是 [FF02::FB]。转载请注明来自:http://www.binkery.com/
mDNS 协议规定了一个端口,5353。转载请注明来自:http://www.binkery.com/
mDNS 基于 UDP 协议。转载请注明来自:http://www.binkery.com/
每个进入局域网的主机,如果开启了mDNS服务的话,都会向局域网内的所有主机组播一个消息,我是谁,和我的IP地址是多少。然后其他也有该服务的主机就会响应,也会告诉你,它是谁,它的IP地址是多少。当然,具体实现要比这个复杂点。转载请注明来自:http://www.binkery.com/
比如,A主机进入局域网,开启了 mDNS 服务,并向 mDNS 服务注册以下信息:我提供 FTP 服务,我的IP是 192.168.1.101,端口是 21。当B主机进入局域网,并向 B 主机的 mDNS 服务请求,我要找局域网内 FTP 服务器,B主机的 mDNS 就会去局域网内向其他的 mDNS 询问,并且最终告诉你,有一个IP地址为 192.168.1.101,端口号是 21 的主机,也就是 A 主机提供 FTP 服务,所以 B 主机就知道了 A 主机的 IP 地址和端口号了。转载请注明来自:http://www.binkery.com/
大概的原理就是这样子,mDNS提供的服务要远远多于这个,当然服务多但并不复杂。转载请注明来自:http://www.binkery.com/
在Apple 的设备上(电脑,笔记本,iphone,ipad等设备)都提供了这个服务。很多Linux设备也提供这个服务。Windows的设备可能没有提供,但是如果安装了iTunes之类的软件的话,也提供了这个服务。转载请注明来自:http://www.binkery.com/
这样就可以利用这个服务开发一些局域网内的自动发现,然后提供一些局域网内交互的应用了。转载请注明来自:http://www.binkery.com/
jmDNS 是一个 JAVA 平台的,提供 mDNS 服务的第三方库。在这个 jar 包引入到 Android 项目里,就可以获得 mDNS 服务了。Android 在 3.x 还是 4.x 之后已经提供局域网内自动发现的 API 了,所以不需要使用 jmDNS 第三方库就能实现了。


下文是来自 http://www.multicastdns.org/ 的说明。
Multicast DNS is a way of using familiar DNS programming interfaces, packet formats and operating semantics, in a small network where no conventional DNS server has been installed.
Multicast DNS is a joint effort by participants of the IETF Zero Configuration Networking (zeroconf) and DNS Extensions (dnsext) working groups. The requirements are driven by the Zeroconf working group; the implementation details are a chartered work item for the DNSEXT group. Most of the people working on mDNS are active participants of both working groups.
While the requirements for Zeroconf name resolution could be met by designing an entirely new protocol, it is better to provide this functionality by making minimal changes to the current standard DNS protocol. This saves application programmers from having to learn new APIs, and saves application programmers from having to write application code two different ways — one way for large configured networks and a different way for small Zeroconf networks. It means that most current applications need no changes at all to work correctly using mDNS in a Zeroconf network. It also means that engineers do not have to learn an entirely new protocol, and current network packet capture tools can already decode and display DNS packets, so they do not have to be updated to understand new packet formats.
--------

http://agnat.github.io/node_mdns/user_guide.html ,mdns User Guide

https://supportforums.cisco.com/document/12160121/basic-theory-behind-mdns

http://www.multicastdns.org/

No comments:

Post a Comment