网络协议+报文抓包学习笔记

目录

1.1通用数据包格式详解
1.2 ARP
1.3DNS
1.4 HTTP
1.5 mDNS
1.6 SIP
1.7 SNMP
1.8 SSDP
1.9 DHCP

1.认识Wireshark捕获数据包

当我们对Wireshark主窗口各部分作用了解了，学会捕获数据了，接下来就该去认识这些捕获的数据包了。Wireshark将从网络中捕获到的二进制数据按照不同的协议包结构规范，显示在Packet Details面板中。为了帮助用户能够清楚的分析数据，本文将介绍识别不同类型数据包的方法。

1.1 通用数据包格式详解

从该界面可以看出显示了五行信息，默认这些信息是没有被展开的。各行信息如下所示：

• Frame：物理层的数据帧概况。
• Ethernet II：数据链路层以太网帧头部信息。
• Internet Protocol Version 4：互联网层IP包头部信息。
• Transmission Control Protocol：传输层的数据段头部信息，此处是TCP协议。
• Hypertext Transfer Protocol：应用层的信息，此处是HTTP协议。

下面分别介绍下帧、包和段内展开的内容。如下所示：

（1）Frame 物理层的数据帧概况

• Frame 5: 268 bytes on wire (2144 bits), 268 bytes captured (2144 bits) on interface 0 #5号帧，线路268字节，实际捕获268字节
• Interface id: 0 #接口id
• Encapsulation type: Ethernet (1) #封装类型
• Arrival Time: Jun 11, 2015 05:12:18.469086000 中国标准时间 #捕获日期和时间
• [Time shift for this packet: 0.000000000 seconds]
• Epoch Time: 1402449138.469086000 seconds
• [Time delta from previous captured frame: 0.025257000 seconds] #此包与前一包的时间间隔
• [Time since reference or first frame: 0.537138000 seconds] #此包与第一帧的时间间隔
• Frame Number: 5 #帧序号
• Frame Length: 268 bytes (2144 bits) #帧长度
• Capture Length: 268 bytes (2144 bits) #捕获长度
• [Frame is marked: False] #此帧是否做了标记：否
• [Frame is ignored: False] #此帧是否被忽略：否
• [Protocols in frame: eth:ip:tcp:http] #帧内封装的协议层次结构
• [Number of per-protocol-data: 2]
• [Hypertext Transfer Protocol, key 0]
• [Transmission Control Protocol, key 0]
• [Coloring Rule Name: HTTP] #着色标记的协议名称
• [Coloring Rule String: http || tcp.port == 80] #着色规则显示的字符串

（2）Ethernet II 数据链路层以太网帧头部信息

• Ethernet II, Src: Giga-Byt_c8:4c:89 (1c:6f:65:c8:4c:89), Dst: Tp-LinkT_f9:3c:c0 (6c:e8:73:f9:3c:c0)
• Destination: Tp-LinkT_f9:3c:c0 (6c:e8:73:f9:3c:c0) #目标MAC地址
• Source: Giga-Byt_c8:4c:89 (1c:6f:65:c8:4c:89) #源MAC地址
• Type: IP (0x0800)

（3）Internet Protocol Version 4 互联网层IP包头部信息

• Internet Protocol Version 4, Src: 192.168.0.104 (192.168.0.104), Dst: 61.182.140.146 (61.182.140.146)
• Version: 4 #互联网协议IPv4
• Header length: 20 bytes #IP包头部长度
• Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #差分服务字段
• Total Length: 254 #IP包的总长度
• Identification: 0x5bb5 (23477) #标志字段
• Flags: 0x02 (Don’t Fragment) #标记字段
• Fragment offset: 0 #分的偏移量
• Time to live: 64 #生存期TTL
• Protocol: TCP (6) #此包内封装的上层协议为TCP
• Header checksum: 0x52ec [validation disabled] #头部数据的校验和
• Source: 192.168.0.104 (192.168.0.104) #源IP地址
• Destination: 61.182.140.146 (61.182.140.146) #目标IP地址

（4）Transmission Control Protocol 传输层TCP数据段头部信息

• Transmission Control Protocol, Src Port: 51833 (51833), Dst Port: http (80), Seq: 1, Ack: 1, Len: 214
• Source port: 51833 (51833) #源端口号
• Destination port: http (80) #目标端口号
• Sequence number: 1 (relative sequence number) #序列号（相对序列号）
• [Next sequence number: 215 (relative sequence number)] #下一个序列号
• Acknowledgment number: 1 (relative ack number) #确认序列号
• Header length: 20 bytes #头部长度
• Flags: 0x018 (PSH, ACK) #TCP标记字段
• Window size value: 64800 #流量控制的窗口大小
• Checksum: 0x677e [validation disabled] #TCP数据段的校验和

1.2 ARP(Address Resolution Protocol)

地址解析协议是将IP地址解析为以太网MAC地址（或称物理地址）的协议。

在局域网中，当主机或其它网络设备有数据要发送给另一个主机或设备时，它必须知道对方的网络层地址（即I地址IP）但是仅仅有IP地址是不够的，因为IP数据报文必须封装成帧才能通过物理网络发送，因为发送站还必须有接收站的物理地址，所以需要从IP地址到物理地址，所以需要从IP地址到物理地址的映射。ARP就是实现这个功能的协议。

ARP报文格式如下

ARP报文结构

• Hardware type：表示硬件地址的类型，值为1表示以太网地址
• Protocol type：表示要映射的协议地址类型。它的值为0x0800表示IP地址类型
• Hardware/Protocol size: 硬件地址长度和协议地址长度以字节为单位，对于以太网上的IP地址的ARP请求或应答来说，他们的值分别为6和4；
• 操作类型（Opcode）:1表示ARP请求，2表示ARP应答
• Sender (发送端) MAC address：发送方设备的硬件地址；
• Sender (发送端) IP address：发送方设备的IP地址；
• Targrt MAC address：接收方设备的硬件地址。
• Targrt IP address：接收方设备的IP地址。

1.3 DNS(Domain Name System)

DNS 分为查询请求和查询响应，请求和响应的报文结构基本相同。DNS 报文格式如图所示。

DNS 报文的基础结构部分指的是报文首部(Header)，如图所示。

该部分中每个字段含义如下。

• 事务 ID：DNS 报文的 ID 标识。对于请求报文和其对应的应答报文，该字段的值是相同的。通过它可以区分 DNS 应答报文是对哪个请求进行响应的。
• 标志：DNS 报文中的标志字段。
• 问题计数：DNS 查询请求的数目。
• 回答资源记录数：DNS 响应的数目。
• 权威名称服务器计数：权威名称服务器的数目。
• 附加资源记录数：额外的记录数目（权威名称服务器对应 IP 地址的数目）。

1) 在下图中，Queries 部分的信息为问题部分信息，每个字段说明如下：

Domain Name System (query)                        #查询请求
    Queries                                       #问题部分
        baidu.com: type A, class IN
            Name: baidu.com                       #查询名字段, 这里请求域名baidu.com
            [Name Length: 9]
            [Label Count: 2]
            Type: A (Host Address) (1)            #查询类型字段, 这里为A类型
            Class: IN (0x0001)                    #查询类字段, 这里为互联网地址

2) 回答问题区域字段的资源记录部分信息如下：

Answers                                                      #“回答问题区域”字段
    baidu.com: type A, class IN, addr 220.181.57.216         #资源记录部分
        Name: baidu.com                                      #域名字段, 这里请求的域名为baidu.com
        Type: A (Host Address) (1)                           #类型字段, 这里为A类型
        Class: IN (0x0001)                                   #类字段
        Time to live: 5                                      #生存时间
        Data length: 4                                       #数据长度
        Address: 220.181.57.216                              #资源数据, 这里为IP地址

3) 权威名称服务器区域字段的资源记录部分信息如下：

Authoritative nameservers                               #“权威名称服务器区域”字段
baidu.com: type NS, class IN, ns ns7.baidu.com      #资源记录部分
Name: baidu.com
Type: NS (authoritative Name Server) (2)        #类型字段, 这里为NS类型
Class: IN (0x0001)
Time to live: 5
Data length: 6
Name Server: ns7.baidu.com                      #权威名称服务器

4) 附加信息区域字段的资源记录部分信息如下：

Additional records                                            #“附加信息区域”字段
    dns.baidu.com: type A, class IN, addr 202.108.22.220      #资源记录部分
        Name: dns.baidu.com                                   #“权威名称服务器”名称
        Type: A (Host Address) (1)                            #类型字段, 这里为A类型
        Class: IN (0x0001)
        Time to live: 5
        Data length: 4
        Address: 202.108.22.220                               #“权威名称服务器”的IP地址

1.4 HTTP（HyperText Transfer Protocol）

HTTP请求报文格式:

HTTP请求报文主要由请求行、请求头部、请求正文3部分组成

• 请求行：由3部分组成，分别为：请求方法、URL 以及协议版本，之间由空格分隔。

请求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，处于安全性的考虑也是不可用的

协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1

• 请求头部：请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔

常见请求头如下

请求头部的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少

• 请求正文：可选部分，比如GET请求就没有请求正文

GET请求示例：

POST请求示例：

HTTP响应报文格式:

HTTP响应报文主要由状态行、响应头部、响应正文3部分组成

• 状态行：由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔

状态代码为3位数字，200~299的状态码表示成功，300~399的状态码指资源重定向，400~499的状态码指客户端请求出错，500~599的状态码指服务端出错（HTTP/1.1向协议中引入了信息性状态码，范围为100~199）

这里列举几个常见的：

• 响应头部

与请求头部类似，为响应报文添加了一些附加信息

常见响应头部如下：

响应示例：

* URI、URL和URN之间的区别

• URI全名为Uniform Resource Indentifier（统一资源标识），用来唯一的标识一个资源，是一个通用的概念，URI由两个主要的子集URL和URN组成
• URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来标识资源
• URN全名为Uniform Resource Name（统一资源命名），通过资源的名字来标识资源，与其所处的位置无关，这样即使资源的位置发生变动，其URN也不会变化

HTTP规范将更通用的概念URI作为其资源标识符，但是实际上，HTTP应用程序处理的只是URI的URL子集

1.5 mDNS（Multicast DNS）

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

在局域网中，设备和设备之前相互通信需要知道对方的ip地址的，大多数情况，设备的ip不是静态ip地址，而是通过dhcp协议动态分配的ip 地址，如何设备发现呢，就是要mdns大显身手，例如：现在物联网设备和app之间的通信，要么app通过广播，要么通过组播，发一些特定信息，感兴趣设备应答，实现局域网设备的发现，当然mdns 比这强大的多
1）mDNS 基于UDP 协议
组播地址: 组播地址使用的是D类地址，地址范围为：224.0.0.0—239.255.255.255
2）mdns工作原理简单描述：
mdns 使用组播地址为： 224.0.0.251 （ipv6： FF02::FB） 端口为5353，mdns是用于局域网内部的，并且主机的域名为.local 结尾,每个进入局域网的主机，如果开启了mDNS服务的话，都会向局域网内的所有主机组播一个消息，我是谁（域名），和我的IP地址是多少。然后其他有mdns服务的主机就会响应，也会告诉你，它是谁（域名），它的IP地址是多少。当然设备需要服务时，就是使用mdns 查询域名对对应的ip地址，对应的设备收到该报文后同样通过组播方式应答，此时其他主机设备也是可以收到该应答报文，其他主机也会记录域名和ip 以及ttl 等，更新缓存。比如，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提供的服务要远远多于这个，当然服务多但并不复杂。
3）mDNSResponder与Bonjour的关系:
The mDNSResponder project is a component of Bonjour,Apple’s ease-of-use IP networking initiative: Bonjour是法语中的Hello之意。它是Apple公司为基于组播域名服务(multicast DNS)的开放性零配置网络标准所起的名字。使用Bonjour的设备在网络中自动组播它们自己的服务信息并监听其它设备的服务信息。设备之间就像在打招呼，这也是该技术命名为Bonjour的原因。Bonjour使得局域网中的系统和服务即使在没有网络管理员的情况下也很容易被找到。

举一个简单的例子：在局域网中，如果要进行打印服务，必须先知道打印服务器的IP地址。此IP地址一般由IT部门的人负责分配，然后他还得全员发邮件以公示此地址。有了Bonjour以后，打印服务器自己会依据零配置网络标准在局域网内部找到一个可用的IP并注册一个打印服务，名为“print service”之类的。当客户端需要打印服务时，会先搜索网络内部的打印服务器。由于不知道打印服务器的IP地址，客户端只能根据诸如”print service”的名字去查找打印机。在Bonjour的帮助下，客户端最终能找到这台注册了“print service”名字的打印机，并获得它的IP地址以及端口号。

1.6 SIP (Session Initiation Protocol)

SIP消息是SIP客户终端和服务器之间通信的的基本信息单元。SIP消息基于文本，采用UTF-8编码（RFC 2279）中的ISO 10646字符集。SIP协议借鉴了HTTP协议（RFC 2068）的设计思想，有很多消息格式与之相同。SIP协议支持UDP传输协议

SIP消息消息分两类：请求消息 / 响应消息

请求消息（Request）：客户端为了激活特定操作而发给服务器的SIP消息，包括INVITE,ACK,OPTIONS,BYE,CANCEL和REGISTER消息。UAC到UAS。

响应消息（Response）：服务器向客户端反馈对应请求的处理结果的SIP消息，包括1xx,2xx,3xx,4xx,5xx,6xx响应消息，UAS到UAC

SIP消息格式与结构：

起始行

起始行分请求行（Request-Line）和状态行（Status-Line）两种。

1. 请求行（Request-Line）：请求消息的起始行，由请求消息类型，请求目的发送地址Request-URI，SIP协议的版本号，之间用空格隔开。

请求行的6种Request Method：
INVITE：用于发起呼叫请求。INVITE消息包括消息头和数据区两部分。INVITE 消息头包含主、被呼叫的地址，呼叫主题和呼叫优先级等信息。数据区则是关于会话媒体的信息，可由会话描述协议SDP 来实现。
BYE：当一个用户决定中止会话时，可以使用BYE 来结束会话。
OPTIONS：用于询问被叫端的能力信息，但OPTIONS 本身并不能发起呼叫。
ACK：对已收到的消息进行确认应答。
REGISTER：用于用户向SIP服务器传送位置信息或地址信息。
CANCEL：取消当前的请求，但它并不能中止已经建立的连接。

2. 状态行（Status-Line）：响应消息的起始行，SIP应答消息的Status-Line由SIP-Version开始，接着是一个数字编码的状态码Status-Code，最后是一个与状态码相关的描述性短语Reason-Phrase，然后由一个CRLF行结束符结束Status-Line。

SIP应答消息的六类应答状态编码
1xx：临时消息：表示表示请求消息已经收到，后面将继续处理该请求。
2xx：成功消息：表示请求已经被成功的理解、接受或执行。
3xx：重定向消息：表示为了完成请求还需采取更进一步的动作。
4xx：客户机错误：表示该请求含有语法错误或在这个服务器上不能被满足。
5xx：服务器错误：表示该服务器不能处理一个明显有效的请求。
6xx：全局性故障：表示该请求在任何服务器上都不能被实现。

消息头：

消息头的作用是进一步提供有关消息的其他信息，使代理服务器或客户代理服务器更好地对消息进行处理。消息头分四类：通用头（general-header ）、请求头（request-header ）、响应头（ response-header ）和实体头（ entityheader）

四大类

• general-header为描述消息基本属性的通用头域，可用于请求消息和应答消息；消息头有：Call-ID，From，To，Via，Contact，CSeq，Encryption，Expires，Record-Route，Timestamp，Date，Accept，Accept-Encoding，Accept-Language
• request-header为请求头域，只可用于请求消息，它被用来传递有关应答的附加信息，对请求进行补充说明；Subject，User-Agent，Organization，Contact，Authorization，Proxy-Authorization，Proxy-Require，Response-Key，Require，Priority，Hide，Route，Max-Forwards。
• response-header为应答头域，只可用于应答消息，它被用来传递有关应答的附加信息，对应答进行补充说明。Proxy-Authenticate，WWW-Authenticate，Retry-After，Server，Warning，Allow，Unsupported。
• entity-header是消息体头域，用于描述消息体内容的长度、格式和编码类型等属性，可用于请求消息或应答消息。Content-Encoding，Content-Length，Content-Type消息头格式：每个消息头都是一个“句子”，以CRLF行结束符表示一个头域的结束。它们都由字段名（field-name）和域值（field-value）两部分组成，中间以“：”相隔。

  常见消息头说明：

• TO：格式：TO:显示名<接收者URI>；tag=n;显示名和tag可选。接收者URI是SIP网络种唯一标识接收终端的标识符。例：TO:DENNY<SIP:caller@WORK.COM>;TAG=11111
• FROM: 消息头FROM给出标识会话发起者的URI。比如：FROM:sip:caller@work.com；tag=hyh8。tag是必需的。
• CALL-ID: 用于全局唯一标识正在建立的会话的标识符。 随机数加UAC标识信息
• CSeq: 用于标识同一会话中不同事务的序号，通常由一个用作序号的整型数和消息类型组成。整个会话操作过程由不同的事务组成，每一事务所涉及的消息的CSeq序号必须相同
• Via: 为响应消息提供传输路径，当请求消息经过每一跳节点时，每一跳节点都把自身的IP地址信息放入顶层Via中。响应消息则沿着请求消息记录下的传输路径反向传输，首先移走指明自身IP地址信息的顶层消息头

1.7 SNMP(Simple Network Management Protocol)

一套完整的SNMP系统主要包括管理信息库（MIB）、管理信息结构（SMI）及SNMP报文协议。

我们先来了解一下SNMP报文协议：

一、SNMP协议概述

简单网络管理协议（SNMP：Simple Network Management Protocol）是由互联网工程任务组（IETF：Internet Engineering Task Force ）定义的一套网络管理协议。该协议基于简单网关监视协议（SGMP：Simple Gateway Monitor Protocol）。利用SNMP，一个管理工作站可以远程管理所有支持这种协议的网络设备，包括监视网络状态、修改网络设备配置、接收网络事件警告等。 虽然SNMP开始是面向基于IP的网络管理，但作为一个工业标准也被成功用于电话网络管理。

SNMP报文格式

下图是封装成UDP数据报的5种操作的SNMP报文格式。可见一个SNMP报文共有三个部分组成，即公共SNMP首部、get/set首部，trap首部，变量绑定

公共SNMP首部

共三个字段：

• 版本 ：写入版本字段的是版本号减1，对于SNMP（即SNMPV1）则应写入0。
• 共同体（community）：共同体就是一个字符串，作为管理进程和代理进程之间的明文口令，常用的是6个字符“public”。
• PDU类型：根据PDU的类型，填入0～4中的一个数字，其对应关系如下图

get/set首部

• 请求标识符(request ID)： 这是由管理进程设置的一个整数值。代理进程在发送get-response报文时也要返回此请求标识符。管理进程可同时向许多代理发出get报文，这些报文都使用UDP传送，先发送的有可能后到达。设置了请求标识符可使管理进程能够识别返回的响应报文对于哪一个请求报文
• 差错状态（error status）：由代理进程回答时填入0～5中的一个数字，见下图描述

• 差错索引(error index)：当出现noSuchName、badValue或readOnly的差错时，由代理进程在回答时设置的一个整数，它指明有差错的变量在变量列表中的偏移。

trap首部

• 企业（enterprise）: 填入trap报文的网络设备的对象标识符。此对象标识符肯定是在图3的对象命名树上的enterprise结点{1.3.6.1.4.1}下面的一棵子树上。
• trap类型: 此字段正式的名称是generic-trap，共分为表4中的7种

当使用上述类型2、3、5时，在报文后面变量部分的第一个变量应标识响应的接口。

• 特定代码(specific-code): 指明代理自定义的时间（若trap类型为6），否则为0。
• 时间戳(timestamp): 指明自代理进程初始化到trap报告的事件发生所经历的时间，单位为10ms。例如时间戳为1908表明在代理初始化后1908ms发生了该时间。

变量绑定(variable-bindings)

指明一个或多个变量的名和对应的值。在get或get-next报文中，变量的值应忽略。

管理变量的表示方法是这样规定的：形如x.y，其中x是管理对象的object identifer。y是能唯一确定对象类型值的一组数字，在非表型变量中为0，在表型变量中是这个表的索引，比如接口表中的接口号，或路由表中的目的网络地址等等 。如：在MIB文件里定义了ipAdEntNetMask这一管理对象，其object identifier为1.3.6.1.1.5.6.1.3它是个路由表中的一项，它的一个实例就是路由表中某一行的子网掩码，如果这行的索引、目的网络地址为129.102.1.0。则这个变量名是：1.3.6.1.1.5.6.1.3.129.102.1.0。在以后的说明中，为了方便，把唯一确定管理变量的一组数字，也就是x.y中的y称作实例。

1.8 SSDP (Simple Sever Discovery Protocol)

简单服务发现协议，此协议为网络客户提供一种无需任何配置、管理和维护网络设备服务的机制。此协议采用基于通知和发现路由的多播发现方式实现。协议客户端在保留的多播地址：239.255.255.250：1900（IPV4）发现服务，（IPv6 是：FF0x::C）同时每个设备服务也在此地址上上监听服务发现请求。如果服务监听到的发现请求与此服务相匹配，此服务会使用单播方式响应。

常见的协议请求消息有两种类型，第一种是服务通知，设备和服务使用此类通知消息声明自己存在；第二种是查询请求，协议客户端用此请求查询某种类型的设备和服务。请求消息中包含设备的特定信息或者某项服务的信息，例如设备类型、标识符和指向设备描述文档的URL地址。

设备发现过程允许控制点使用一个设备类型或标识，或者是服务类型进行查询。这要求标准设备或服务类型，或者设备特定实例的发现和广告消息基于一个独一无二的标识，UPnP设备和服务类型的定义是UPnP论坛工作委员会的责任。从设备获得响应的内容基本上与多址传送的设备广播相同，只是采用单址传送方式。

SSDP 协议消息

1. 设备查询消息: 当一个控制点加入到网络中时，设备发现过程允许控制点寻找网络上感兴趣的设备。发现消息包括设备的一些特定信息或者某项服务的信息，例如它的类型、标识符、和指向XML设备描述文档的指针。从设备获得响应从本质上说，内容与多址传送的设备广播相同，只是采用单址传送方式。设备查询通过HTTP协议扩展M-SEARCH方法实现的。典型的设备查询请求消息格式：

M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover"
MX: seconds to delay response
ST: search target

各HTTP协议头的含义简介：

• HOST：设置为协议保留多播地址和端口，必须是：239.255.255.250:1900（IPv4）或FF0x::C(IPv6)
• MAN：设置协议查询的类型，必须是：ssdp:discover
• MX：设置设备响应最长等待时间，设备响应在0和这个值之间随机选择响应延迟的值。这样可以为控制点响应平衡网络负载。
• ST：设置服务查询的目标，它必须是下面的类型：
  • ssdp:all 搜索所有设备和服务
  • upnp:rootdevice 仅搜索网络中的根设备
  • uuid:device-UUID 查询UUID标识的设备
  • urn:schemas-upnp-org:device:device-Type: version 查询device-Type字段指定的设备类型，设备类型和版本由UPNP组织定义。
  • urn:schemas-upnp-org:service:service-Type:version 查询service-Type字段指定的服务类型，服务类型和版本由UPNP组织定义。

在设备接收到查询请求并且查询类型（ST字段值）与此设备匹配时，设备必须向多播地址239.255.255.250:1900回应响应消息。

HTTP/1.1 200 OK
CACHE-CONTROL: max-age = seconds until advertisement expires
DATE: when reponse was generated
EXT:
LOCATION: URL for UPnP description for root device
SERVER: OS/Version UPNP/1.0 product/version
ST: search target
USN: advertisement UUID

2. 设备通知消息

在设备加入网络，UPnP发现协议允许设备向控制点广告它的服务。它使用向一个标准地址和端口多址传送发现消息来实现。控制点在此端口上侦听是否有新服务加入系统。为了通知所有设备，一个设备为每个其上的嵌入设备和服务发送一系列相应的发现消息。每个消息也包含它表征设备或服务的特定信息。

• ssdp:alive消息

在设备加入系统时，它采用多播传送方式发送发现消息，包括告知设备包含的根设备信息，所有嵌入设备以及它包含的服务。每个发现消息包含四个主要对象：

1. 在NT头中包含的潜在搜索目标。
2. 在USN头中包含的复合发现标识
3. 在LOCATION头中关于设备信息的URL地址
4. 在CACHE-CONTROL头中表示的广告消息的合法存在时间。

如果一个根设备有n个嵌入设备，m个嵌入服务，而且包含k个不同的服务类型，这将会发出3 + 2n + k次请求。这些广告消息像控制点描述了设备的所有信息。这些消息必须作为一系列一起发出，发送的顺序无关紧要，但是不能对单个消息进行刷新或取消的操作。选择一个适当的持续期是在最小化网络通讯和最大化设备状态及时更新之间求得一个平衡，相对较短的持续时间可以保证控制点在牺牲网络流量的前提下获得设备的当前状态；持续期越长可以大大减少设备刷新造成的网络流量。一般而言，设备制造商应该选择一个适当的持续时间值。

由于UDP协议是不可信的，设备应该发送多次设备发现消息。而且为了降低控制点无法收到设备或服务广告消息的可能性，设备应该定期发送它的广告消息。在设备加入网络时，它必须用NOTIFY方法发送一个多播传送请求。NOTIFY方法发送的请求没有回应消息，典型的设备通知消息格式如下：

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL for UPnP description for root device
NT: search target
NTS: ssdp:alive
USN: advertisement UUID

各HTTP协议头的含义简介：

一个发现响应可以包含0个、1个或者多个服务类型实例。为了做出分辨，每个服务发现响应包括一个USN：根设备的标识。在同样的设备里，一个服务类型的多个实例必须用包含USN:ID的服务标识符标识出来。例如，一个灯和电源共用一个开关设备，对于开关服务的查询可能无法分辨出这是用于灯的。UPNP论坛工作组通过定义适当的设备层次以及设备和服务的类型标识分辨出服务的应用程序场景。这么做的缺点是需要依赖设备的描述URL。

• ssdp:byebye消息

在设备和它的服务将要从网络中卸载时，设备应该对于每个未超期的ssdp:alive消息多播方式传送ssdp:byebye消息。但如果设备突然从网络卸载，它可能来不及发出这个通知消息。因此，发现消息必须在CACHE-CONTROL包含超时值，如果不重新发出广告消息，发现消息最后超时并从控制点的缓存中除去。典型的设备卸载消息格式如下：

NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900NT: search target
NTS: ssdp:byebye
USN: advertisement UUID各HTTP协议头的含义简介：
HOST	设置为协议保留多播地址和端口，必须是239.255.255.250:1900
NT	在此消息中，NT头必须为服务的服务类型。
NTS	表示通知消息的子类型，必须为ssdp:alive
USN	表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力

专有设备或服务可以不遵循标准的UPNP模版。但如果设备或服务提供UPNP发现、描述、控制和事件过程的所有对象，它的行为就像一个标准的UPNP设备或服务。为了避免命名冲突，使用专有设备命名时除了UPNP域之外必须包含一个前缀”urn:schemas-upnp-org”。在与标准模版相同时，应该使用整数版本号。但如果与标准模版不同，不可以使用设备复用和徽标。

简单设备发现协议不提供高级的查询功能，也就是说，不能完成某个具有某种服务的设备这样的复合查询。在完成设备或者服务发现之后，控制点可以通过设备或服务描述的URL地址完成更为精确的信息查询。

1.9 DHCP（DynamicHostConfigurationProtocol）

动态主机配置协议，是一个局域网的网络协议，使用UDP协议工作， 主要有两个用途：给内部网络或网络服务供应商自动分配IP地址，给用户或者内部网络管理员作为对所有计算机作中央管理的手段。DHCP有3个端口，其中UDP67和UDP68为正常的DHCP服务端口，分别作为DHCP Server和DHCP Client的服务端口；546号端口用于DHCPv6 Client。

作用：

1. 保证任何IP地址在同一时刻只能由一台DHCP客户机所使用。
2. DHCP应当可以给用户分配永久固定的IP地址。
3. DHCP应当可以同用其他方法获得IP地址的主机共存（如手工配置IP地址的主机）
4. DHCP服务器应当向现有的BOOTP客户端提供服务。

引用：
1. 《HTTP请求、响应报文格式》

HTTP请求、响应报文格式_网络_怀揣梦想，努力前行-CSDN博客​blog.csdn.net

2. 网络协议篇之SNMP协议（一）–SNMP报文协议_网络_知秋一叶-CSDN博客

3. https://www.cnblogs.com/debin/archive/2009/12/01/1614543.html