[转帖]mDNS原理的简单理解

mDNS原理的简单理解

https://binkery.com/archives/318.html

发现还有avahi-daemon

mdns 

设置ip地址 等等事项

网络部分 自己学习的还是不够多 ,需要加强学习. 

• Android,Java,DNS,局域网,mDNS,组播,Java mDNS,Multicast DNS,mDNS原理,mDNS组播
• 2016-03-21 08:53:39

mDNS , multicast DNS, 可以理解为局域网内部的 DNS 系统，它和 DNS 有很多相似的地方，通过它可以实现局域网内部的服务发现、查找和广播。同时它是基于组播的协议。

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

在局域网内，你要通过一台主机和其他主机进行通信，你需要知道对方的 ip 地址，但是有些时候，你并不知道对方的 ip 地址，因为一般使用 DHCP 动态分配 ip 地址的局域网内，各个主机的 IP 地址是由 DHCP 服务器来帮你分配 IP 地址的。所以在很多情况下，你要知道对方的 IP 地址是比较麻烦的。

鉴于发现这篇文章最近的浏览量比较多，晚上也有不少转载，特别声明一下，文章水平可能不大够，只是我当时的一些理解，所以希望大家以批判的角度来看，然后又什么问题欢迎讨论。真心不希望误导大家 ^_^

mDNS 的工作原理

首先，在 IP 协议里规定了一些保留地址，其中有一个是 224.0.0.251，对应的 IPv6 地址是 [FF02::FB]。

mDNS 协议规定了端口为 5353，而 DNS 的端口是 53。

mDNS 基于 UDP 协议。DNS 一般也是基于 UDP 协议的，但是也可以使用 TCP 协议。

如果理解了 DNS 协议，再去理解 mDNS 协议就很简单了，区别只是 mDNS 一般作用在一个局域网内的，有特定的 IP 地址，也就是 224.0.0.251,有特定的端口 5353,mDNS 的作用是实现局域网内的服务发现，查询，注册，DNS 作用是实现域名的解析，作用大概是一样的。

每个进入局域网的主机，如果开启了 mDNS 服务的话，都会向局域网内的所有主机组播一个消息，我是谁，和我的IP地址是多少。然后其他也有该服务的主机就会响应，也会告诉你，它是谁，它的 IP 地址是多少。当然，具体实现要比这个复杂点。

比如，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 地址和端口号了。

大概的原理就是这样子，mDNS 提供的服务要远远多于这个，当然服务多但并不复杂。

在 Apple 的设备上（电脑，笔记本，iphone，ipad等设备）都提供了这个服务。很多 Linux 设备也提供这个服务。Windows 的设备可能没有提供，但是如果安装了 iTunes 之类的软件的话，也提供了这个服务。

这样就可以利用这个服务开发一些局域网内的自动发现，然后提供一些局域网内交互的应用了。

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.

- EOF -

本文链接 https://binkery.com/archives/318.html，欢迎转载，转载请注明出处。