mdns协议 mdns协议C#实现

linux内核启动时每次都卡在mDNS/DNS-SD Daemon处什么意思，也可以告诉我在内核什么地方可以关掉这个选项

mdns嘛。就是zeroconf的协议。水果的。怎么会卡住？

mdns协议 mdns协议C#实现

通常是ahi的服务。类似

/etc/init/ahi-daemon.conf

看你什么系统，有些是init.d下。

服务在不同系统是不同的。有sysv upstart等。

隐藏在网络邻居背后的协议,快来看看你家网络有几种?

分析/验证对比常见局域网服务发现协议在Windows/Linux/Mac等不同系统下的支持和表现

在使用不同系统的智能硬件时,如常见的树莓派/Openwrt路由器/Debian/Fedora/Windows/Mac等系统是,系统间相互发现以及

网络共享本应是系统的基础服务,无需用户过多参与.不过现实旺旺和理想之间的距让我们惊讶,不同系统相互之间的发现以及

共享并没有那么轻松.

开发的硬件设备无法在常见系统的网络邻居正确的现实出来,实在是很丧气的事情.

那么,就系统来看看局域网服务发现协议在不同系统上的支持及表现.

想要访问局域网网络里面的设备,远没有应有的轻松. 每次新装系统或者设备入网,总是有这样或者那样的问题,哎,器啊,你在哪里.

先看看最简单和常用的ping工具,这么简单和实用的工具,简单的搜索竟然有三千八百万条记录

大名鼎鼎的树莓派,用起来想来应该更简单一些,可事实往往触目惊心,仅仅是ping通的问题,也有三百万的记录

![pdnas-raspberry-pi-ping]]( )

再来看看最常见的文件共享服务,也有两千万之巨

这都2120年了,为什么这么常见的服务还有这么多为问题呢.

干货放前面各系统网络邻居正常工作的协议汇总:

Linux和Macos比较相似,但是实现起来还是有明显的异,下文会具体描述.

Windows一如既往的走在自己的路上,网络邻居发现协议自搞一套.

Web Servs Dynamic Discovery (WS-Discovery) WS-Discovery

下图是此协议的抓包

此协议和UPnP极其相似,都是基于SSDP协议衍生的XML表达的,如果不支持此协议,则无法在Windows10 的网络邻居里面显示为PC,无法直接点击访问共享.

支持此协议后,Windows10的网络邻居里面会在计算机类型的里面显示设备.

UPnP 是早期路由器常用的协议,目前从不同系统的验证来看,Windows默认在文件浏览器里面支持,Ubuntu和MacOS都需要单独配置或者应用程序才能浏览.

这个协议目前各种路由器基本都能支持,不过其安全问题频出,作用并不明显.

此协议在Windows系列里面基本都能支持,会在网络邻居里面显示出设备的信息.

MAC整体表现和Linux比较接近,双方使用的协议也是类似,只是在细节处理上有些区别.

mDNS 协议本身应用比较广泛,MAC比较早就支持.在Mac新版本里面,网络邻居默认可以发现mDNS设备.

因为历史原因,早期的AFP协议升级后已经没有开源协议可以完美支持,因此使用ahi的mDNS服务时,如果还使能了AFP业务的话,MAC会显示为大问号.

使用配置好的服务文件,MAC可以正常显示设备

在调试过程中,还看到了网络邻居显示为PC的图标,有知道显示为这个图标的条件的小伙伴吗?

Message Block SMB 是MS家

的协议,奇怪吧:<>

Samba是nix系统上的一个SMB协议的实现,是早期为了和Windows兼容文件共享而做的功能.目前MAC已经全面放弃自己的AFP协议转而投向SMB协议.

设备仅支持SMB协议而没有mDSN协议辅助的话,MAC也可以识别此系统,不过会显示为超级古老的图标.

Ubuntu系统的网络邻居可以自动发现mDNS服务并展示为不同的图标. 在Ubuntu 20.04里面,除去图标的不同,还增加了每个服务的描述.

同样的,Ubuntu系统天然支持SMB协议,但是SMB协议需要mDNS协议的支撑,否则无法显示在网络邻居里面.

除去前面流行并且工作的协议外,还有一些曾经使用但是已经废弃或者即将废弃的协议,在设备设计时,如果考虑兼容性,也同时需要支持.

SSDP是一个基础协议,UPnP以及WS-Discovery 都是基于这个协议来实现的.

Apple Filing Protocol AFP

Apple家的私有协议,开源有 netatalk 实现. AFP升级加密后,netatalk也不能和新版本的MAC兼容.

苹果已经全面投向SMB的怀抱,AFP基本上可以忽略了.

Network Basic Input/Output System NetBIOS 这个是Windows 9x/Me/XP等早期系统支持的名称解析协议,

类似于mDNS,新的Windows 10已经不建议支持此协议.

Link-Local Multicast Name Resolution LLMNR , 这个也是和mDNS竞争的失败者,主要聚焦于局域网的名称解析,可以直接忽略了.

mdnsd是什么进程

mdnsd是多播DNS和DNS服务发现的守护程序。

mdns即多播dns（Multicast DNS），mDNS主要实现了在没有传统DNS的情况下使局域网内的主机实现相互发现和通信，使用的端口为5353，遵从dns协议，使用现有的DNS信息结构、名语法和资源记录类型。并且没有指定新的作代码或响应代码。

协议概述

当mDNS客户端需要解析主机名时，它会发送一个IP多播查询消息，要求具有该名称的主机标识自己。然后该目标机器多播包含其IP地址的消息。然后，该子网中的所有计算机都可以使用该信息来更新其mDNS高速缓存。任何主机都可以通过发送生存时间（TTL）等于零的响应数据包来放弃其对名称的声明。

默认情况下，mDNS仅限并且专门解析以．local域（TLD）结尾的主机名。如果该域包括未实现mDNS但可以通过传统单播DNS找到的主机，则会导致问题。解决此类冲突需要违反零配置目标的网络配置更改。

关于LLMNR

在DNS 不可用时，DNS 客户端计算机可以使用本地链路多播名称解析 (LLMNR—Link-Local Multicast Name Resolution)（也称为多播 DNS 或 mDNS）来解析本地网段上的名称。例如，如果路由器出现故障，从网络上的所有 DNS 切断了子网，则支持 LLMNR 的子网上的客户端可以继续在对等基础上解析名称，直到网络连接还原为止。

LLMNR（本地链路组播名称解析）在DNS不可用时，DNS 客户端计算机可以使用本地链路组播名称解析，通过UDP发送到组播地址224.0.0.252:5355，来解析本地网段上的名称，使用的也是普通DNS的数据包格式。类似的另一种协议是mDNS（组播DNS），通过UDP协议发送到组播地址224.0.0.251:5353，用于家庭局域网等小型网络。

LLMNR为使用IPv4、IPv6或者同时使用这两种地址的设备提供了点对点名称解析服务，可以让同一子网中的IPv4和IPv6设备不需要WINS或DNS就可以解析对方的名称。

例如，如果路由器出现故障，从网络上的所有 DNS 切断了子网，则支持 LLMNR 的子网上的客户端可以继续在对等基础上解析名称，直到网络连接还原为止。除了在网络出现故障的情况下提供名称解析以外，LLMNR 在建立临时对等网络方面也非常有用。

除了在网络出现故障的情况下提供名称解析以外，LLMNR 在建立临时对等网络（例如，机场候机区域）方面也非常有用。