2023年7月23日发(作者：)

设备发现过程分析总体⽽⾔，SSDP协议规定了两种发现设备的途径:第⼀种途径，控制端发送搜索设备消息,并监听响应消息;第⼆种途径，控制端监听设备的宣告消息。这两种只要有⼀种途径成功，就实现了设备发现。抓包分析以腾讯App发现XXX为例分析，假设两台设备加⼊局域⽹络后，⼿机获取了IP地址192.168.1.102，⽽XXX获取了IP地址192.168.1.112。⼿机发送搜索设备消息，并监听响应消息图1的tcpdump请求过程是192.168.1.102发现192.168.1.112，即⼿机发现XXX的过程.⾸先192.168.1.102发了⼀个多播消息，消息地址是239.255.255.250:1900，基于HTTP/1.1协议；192.168.1.112收到了多播消息；并给192.168.1.102发了⼀条响应消息；携带了192.168.1.112的⼀些信息；如设备名称，设备描述⽂件位置，设备标识等。192.168.1.102收到响应就会获得关于192.168.1.112的信息，这就实现了192.168.1.102对192.168.1.112的发现，即⼿机发现了XXX设备。66和67两条消息是ARP消息，地址解析协议，根据地址192.168.1.102解析其MAC地址，⽤于⽹络层传输。下⾯分析两条消息的报⽂结构。⼿机发的搜索消息.图2的tcpdump数据是192.168.1.02搜索消息的报⽂。192.168.1.102每隔1s时间发⼀条SSDP消息到239.255.255.250:1900,请求⾏M-SEARCH * HTTP/1.1，有header，⽆body。header携带了⼀些字段,解读如下:ST(Search Target)，搜索的⽬标是upnp:rootdevice；MX等待响应的延时时间；MAN消息的类型 "ssdp:discover"是搜索消息的必要值；HOST多播地址和端⼝, 239.255.255.250:1900是必要值。这条消息实现了搜索upnp:rootdevice设备。⼿机收的响应消息。图3的tcpdump是192.168.1.112收到这条M-SEARCH消息后响应的tcpdump抓包数据。响应消息是⼀个UDP消息，有header，⽆body。由于SSDP消息使⽤的是HTTP/1.1，因此响应⾏时HTTP/1.1 200 OK。header携带的消息解读如下:Content-Type 内容类型；Server 服务器名字；Content-Length 字节单位的消息长度；Cache-Control 告知客户端这条消息的缓存时长,以秒为单位；EXT；Date 服务器产⽣并发送该报⽂的⽇期和时间；ST 搜索⽬标；USN Unique Service Name 唯⼀服务名称；Location 资源位置；…后⾯的字段是⼚商⾃⼰定义的字段，因此⼚商可根据需求扩展header字段。编程实践⼿机端进程需要:新起⼀个线程管理SSDP消息的发送,称为搜索线程新起⼀个线程监听响应,称为搜索响应监听线程电视果进程需要:新起⼀个线程监听搜索消息,称为搜索监听线程收到搜索消息后新起⼀个线程发送响应消息,称为搜索响应线程控制端监听设备的宣告消息SSDP协议还规定了⽬标设备需要发送通知消息宣告在线, 如图4所⽰192.168.1.112不定时发送多播消息,宣告设备在线,消息基于HTTP/1.1，携带了设备的⼀些信息，如设备名称，设备描述⽂件位置，设备标识等。192.168.1.102收到这个NOTIFY消息时，会获得192.168.1.112的信息，从⽽完成了设备发现过程。下⾯分析NOTIFY消息的报⽂格式。在线消息NOTIFY消息有header，⽆body。与M-SEARCH消息的响应消息相似。在Header⾥定义了设备相关的字段和值。编程实践⼿机端上:新起⼀个线程监听在线消息,称为在线监听线程.电视果上:新起⼀个线程管理在线消息的发送,称为在线消息线程.Bonjour协议图1的tcpdump发现过程是192.168.1.100发现192.168.1.112的过程,即⼿机发现XXX的过程.mDNS使⽤5353端⼝，mDNS协议定义了协议消息的基本格式和顺序:224.0.0.251/5353是mDNS使⽤的多播消息地址；xx:xx:xx:255/5353(如192.168.1.255:5353)是mDNS使⽤的⼴播消息地址。为搜所设备，⼿机将query消息发到多播地址。⽽电视果将response消息同时发多播地址和⼴播地址。为及时发现设备，XXX会每10s就发⼀次response消息，称为不请⾃来的消息，虽然并没有收到query消息也会发response消息。在图1的发现过程看到192.168.1.102每次发6条消息，3条多播消息，3条⼴播消息。⼿机上发的消息图2的tcpdump⼿机上发的query消息.这个query消息的Queries有3条记录：_airplay.__raop.__airplay._消息从192.168.1.100:5353(⼿机上)发送到了224…0.0251:5353，该消息是⼀个多播消息。1和3是⼀样的，因此这个query消息⼿机搜索⽀持_airplay._tcp和_raop._tcp的设备。XXX上发的Query Response消息：XXX上每⼀次发送的消息都包含6条没，3条⼴播到192.168.1.255:5353，另3条多播到224.0.0.251:5353，多播和⼴播的消息内容重复的，因此电视果总共发了3中query response消息,每⼀种消息包含⼀种服务记录：: type A, class IN, cache flush, addr 192.168.1.112_raop._: type PTR, class IN, CCB8A813D00E@347224265356234(103)._raop.__airplay._: type PTR, class IN, 347224265356234(103)._airplay._这6条消息都是"不请⾃来"的消息，因为没有收到query消息⽽发的query response消息。开源库上设备发现的过程：⾸先probing消息连续发3次，间隔250ms；然后announcing消息连续发2次，间隔1分钟；在announced状态之后，Renewer每隔10s钟发送⼀次消息，每次都是6条，3条多播3条⼴播，类似DLNA的在线消息；announced状态之后的消息在在图1发现过程中可以看到，但是probing和announcing的过程还没有找到tcpdump分析的⽅法。