meisw's blog http://meisw.wdlinux.cn// 工作,学习,生活,这里将会有一些记录. 备用域名:http://meisw.wdlinux.cn Copyright (C) 2004 Security Angel Team [S4T] All Rights Reserved. SaBlog-X Version 1.6 Build 20080806 Sun, 31 May 2026 00:55:28 +0000 30 http://meisw.wdlinux.cn//show-978-1.html JSON-RPC好，还是RESTful API好？ admin  作者：Vincross

链接：https://www.zhihu.com/question/28570307/answer/163638731
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

两者没有高下之分，无非是一种约定俗成的标准。习惯用RPC就用RPC，能理解REST就用REST。

JSON-RPC比较符合直观，格式也相对宽松；

REST最近正流行，有自己的一套设计规范。


REST面对的疑问跟当年刚开始流行面向对象时的情况是一样的。

它适合很多情况，但并不适合所有情况。

最差的结果就是盲目跟风，又对REST的概念和理念一知半解，最后搞出一个半吊子的怪胎，还自我标榜用了流行的RESTful API。


REST是一种设计风格，它的很多思维方式与RPC是完全冲突的。

RPC的思想是把本地函数映射到API，也就是说一个API对应的是一个function，我本地有一个getAllUsers，远程也能通过某种约定的协议来调用这个getAllUsers。至于这个协议是Socket、是HTTP还是别的什么并不重要；

RPC中的主体都是动作，是个动词，表示我要做什么。

而REST则不然，它的URL主体是资源，是个名词。而且也仅支持HTTP协议，规定了使用HTTP Method表达本次要做的动作，类型一般也不超过那四五种。这些动作表达了对资源仅有的几种转化方式。


这种设计思路是反程序员直觉的，因为在本地业务代码中仍然是一个个的函数，是动作，但表现在接口形式上则完全是资源的形式。

就像面向对象的「万物皆对象」理论在习惯了纯粹面向过程开发的程序员眼里显得十分别扭一样：我的代码本来就是按顺序、循环、分支这么运行的啊，为啥非得在很明确的结构上封装一层一层的基类子类接口，还要故意给两个函数起同一个名字，调用时才选择用哪一个呢？


使用「万物皆资源」的思想编写实际项目中的API接口时，最常见的问题就是「这玩意到底是个什么资源？………………算了，我就直接写吧，不管什么风格了」

  • 比如，login和logout应该怎么REST化？
  • 比如，多条件复合搜索在GET里写不下怎么办？
  • 比如，大量资源的删除难道要写几千个DELETE？

其实在理解了REST后，这些都不是什么无解的难题，只是思维方式要转换一下：

  • login和logout其实只是对session资源的创建和删除；
  • search本身就是个资源，使用POST创建，如果不需持久化，可以直接在Response中返回结果，如果需要（如翻页、长期缓存等），直接保存搜索结果并303跳转到资源地址就行了；
  • id多到连url都写不下的请求，应该创建task，用GET返回task状态甚至执行进度；

……等等等。


如果只是规定了一种规范，却不理解它表相下面的思维方式，实施中又按照自己的理解随意变动，那结果肯定是混乱不堪的。

当然，API怎么写是开发者的自由。但如果一个API在url里放一堆动词、资源设计混乱、各种乱用HTTP Method和Status Code，还自称RESTful API的话，那就像你养了一条狗，还管它叫猫一样。

这种混搭产物，不如叫它REFU吧。

（Remove Extension From Url：从url里去掉文件扩展名）


前面说了半天REST的理念和不懂REST造成的问题，但是，这并不代表REST比RPC更「高等」，更不是说不理解REST的人是落伍的。

所谓代码风格、接口形式、各种林林总总的格式规定，其实都是为了在团队内部形成共识、防止个人习惯差异引起的混乱。JSON-RPC当然也是有规范的，但相比REST实在宽松太多了。

如果一个开发团队规定必须在url里写action，所有请求都是POST，可以吗？当然也没问题，只是不要拿出去标榜自己写的是RESTful API就行。

规范最终还是为了开发者和软件产品服务的，如果它能带来便利、减少混乱，就值得用；反之，如果带来的麻烦比解决的还多，那就犯不上纯粹跟风追流行了。

 

https://www.zhihu.com/question/28570307 

]]> http://meisw.wdlinux.cn//show-978-1.html 传输协议 2017-11-03 16:52 http://meisw.wdlinux.cn//show-977-1.html 为什么需要RPC，而不是简单的HTTP接口 admin  转载自：http://www.oschina.net/question/271044_2155059?sort=default&p=1#answers

目前有很多Java的RPC框架，有基于Json的，有基于XML，也有基于二进制对象的。

论复杂度，RPC框架肯定是高于简单的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP协议，需要带HTTP请求头，导致传输起来效率或者说安全性不如RPC。

现在问题是，遇到怎样的瓶颈了才需要或者说更适合用RPC（比如像阿里这么大的请求并发量，简单的HTTP肯定达不到预期），但问题是大家所在的公司，要有像阿里这么大的量是比较少的，甚至说1/1000的量可能都没有，那我们还需要使用RPC吗？

技术应该不是为了使用新技术而去使用，而应该是旧技术存在某些瓶颈，存在难以支撑或者扩展性越老越差等问题暴露出来之后，用新技术来进行解决。

那RPC最大的优点，或者说它相比简单的HTTP接口，它的优势、更适合它的业务场景是怎样呢？简单的HTTP又哪里不足，哪些场景明显不太适合呢？

---

RPC=Remote Produce Call 是一种技术的概念名词. HTTP是一种协议,RPC可以通过HTTP来实现,也可以通过Socket自己实现一套协议来实现.所以楼主可以换一个问法,为何RPC还有除HTTP 之外的实现法,有何必要.毕竟除了HTTP实现外,私有协议不具备通用性.那么我想唯一的答案就在于HTTP不能满足其业务场景的地方,所以这个就要具体 案例具体分析了.

------

http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议 进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统 一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑

---

rpc是一种概念，http也是rpc实现的一种方式。论复杂度，dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多，http的几乎都被废弃了。

至于为什么用，其实很简单，业务场景不一样。我最早的单位所有的代码都在一个工程里，一次要发布几百m的代码。这种架构是非常有利于小程序的。但是我们为什么要应用rpc层呢，一个功能，一套代码下来不就解决了么？我觉得有几个好处：

1 灵活部署 2 解耦 至于为什么，当你用到的时候，你会体会。

系统做大了，肯定是需要做微服务的。 现在我们做电商就是这样，单独有一个订单系统，支付系统，商品系统，用户系统。都是分开部署，单独上线的。 但我们交互是用HTTP接口来交互的，我想转用RPC，但问题是我现在还没发现为什么需要用RPC，我还没能理解它的作用和意义。

用http交互其实就已经属于rpc了。

---------

RPC:远程过程调用。RPC的核心并不在于使用什么协议。RPC的目的是让你在本地调用远程的方法，而对你来说这个调用是透明的，你并不知道这个调用的方法是部署哪里。通过RPC能解耦服务，这才是使用RPC的真正目的。RPC的原理主要用到了动态代理模式，至于http协议，只是传输协议而已。简单的实现可以参考spring remoting，复杂的实现可以参考dubbo。

--------

RPC是一个软件结构概念，是构建分布式应用的理论基础。就好比为啥你家可以用到发电厂发出来的电？是因为电是可以传输的。至于用铜线还是用铁丝还是其他 种类的导线，也就是用http还是用其他协议的问题了。这个要看什么场景，对性能要求怎么样。比如在java中的最基本的就是RMI技术，它是java原 生的应用层分布式技术。我们可以肯定的是在传输性能方面，RMI的性能是优于HTTP的。那为啥很少用到这个技术？那是因为用这个有很多局限性，首先它要 保证传输的两端都要要用java实现，且两边需要有相同的对象类型和代理接口，不需要容器，但是加大了编程的难度，在应用内部的各个子系统之间还是会看到 他的身影，比如EJB就是基于rmi技术的。这就与目前的bs架构的软件大相径庭。用http必须要服务端位于http容器里面，这样减少了网络传输方面 的开发，只需要关注业务开发即可。所以在架构一个软件的时候，不能一定根据需求选定技术。

]]> http://meisw.wdlinux.cn//show-977-1.html 传输协议 2017-11-03 15:32 http://meisw.wdlinux.cn//show-970-1.html 看完让你彻底搞懂Websocket原理 admin  偶然在知乎上看到一篇回帖，瞬间觉得之前看的那么多资料都不及这一篇回帖让我对 websocket 的认识深刻有木有。所以转到我博客里，分享一下。比较喜欢看这种博客，读起来很轻松，不枯燥，没有布道师的阵仗，纯粹为分享。废话这么多了，最后再赞一个~

一、websocket与http

WebSocket是HTML5出的东西（协议），也就是说HTTP协议没有变化，或者说没关系，但HTTP是不支持持久连接的（长连接，循环连接的不算）

首先HTTP有 1.1 和 1.0 之说，也就是所谓的 keep-alive ，把多个HTTP请求合并为一个，但是 Websocket 其实是一个新协议，跟HTTP协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是HTTP协议上的一种补充可以通过这样一张图理解

有交集，但是并不是全部。

另外Html5是指的一系列新的API，或者说新规范，新技术。Http协议本身只有1.0和1.1，而且跟Html本身没有直接关系。。通俗来说，你可以用HTTP协议传输非Html数据，就是这样=。=

再简单来说，层级不一样。

二、Websocket是什么样的协议，具体有什么优点

首先，Websocket是一个持久化的协议，相对于HTTP这种非持久的协议来说。简单的举个例子吧，用目前应用比较广泛的PHP生命周期来解释。

HTTP的生命周期通过 Request 来界定，也就是一个 Request 一个 Response ，那么在 HTTP1.0 中，这次HTTP请求就结束了。

在HTTP1.1中进行了改进，使得有一个keep-alive，也就是说，在一个HTTP连接中，可以发送多个Request，接收多个Response。但是请记住 Request = Response ， 在HTTP中永远是这样，也就是说一个request只能有一个response。而且这个response也是被动的，不能主动发起。

教练，你BB了这么多，跟Websocket有什么关系呢？_(:з」∠)_好吧，我正准备说Websocket呢。。

首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。

首先我们来看个典型的 Websocket 握手（借用Wikipedia的。。）

GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13 Origin: http://example.com

熟悉HTTP的童鞋可能发现了，这段类似HTTP协议的握手请求中，多了几个东西。我会顺便讲解下作用。

Upgrade: websocket Connection: Upgrade

这个就是Websocket的核心了，告诉 Apache 、 Nginx 等服务器：注意啦，我发起的是Websocket协议，快点帮我找到对应的助理处理~不是那个老土的HTTP。

Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw== Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

首先， Sec-WebSocket-Key 是一个 Base64 encode 的值，这个是浏览器随机生成的，告诉服务器：泥煤，不要忽悠窝，我要验证尼是不是真的是Websocket助理。

然后， Sec_WebSocket-Protocol 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。简单理解：今晚我要服务A，别搞错啦~

最后， Sec-WebSocket-Version 是告诉服务器所使用的 Websocket Draft（协议版本），在最初的时候，Websocket协议还在 Draft 阶段，各种奇奇怪怪的协议都有，而且还有很多期奇奇怪怪不同的东西，什么Firefox和Chrome用的不是一个版本之类的，当初Websocket协议太多可是一个大难题。。不过现在还好，已经定下来啦~大家都使用的一个东西~ 脱水： 服务员，我要的是13岁的噢→_→

然后服务器会返回下列东西，表示已经接受到请求， 成功建立Websocket啦！

HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk= Sec-WebSocket-Protocol: chat

这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦~

Upgrade: websocket Connection: Upgrade

依然是固定的，告诉客户端即将升级的是 Websocket 协议，而不是mozillasocket，lurnarsocket或者shitsocket。

然后， Sec-WebSocket-Accept 这个则是经过服务器确认，并且加密过后的 Sec-WebSocket-Key 。 服务器：好啦好啦，知道啦，给你看我的ID CARD来证明行了吧。。

后面的， Sec-WebSocket-Protocol 则是表示最终使用的协议。

至此，HTTP已经完成它所有工作了，接下来就是完全按照Websocket协议进行了。具体的协议就不在这阐述了。

——————技术解析部分完毕——————

你TMD又BBB了这么久，那到底Websocket有什么鬼用， http long poll ，或者ajax轮询 不都可以实现实时信息传递么。

好好好，年轻人，那我们来讲一讲Websocket有什么用。来给你吃点胡（苏）萝（丹）卜（红）

三、Websocket的作用

在讲Websocket之前，我就顺带着讲下 long poll 和 ajax轮询 的原理。

ajax轮询

ajax轮询的原理非常简单，让浏览器隔个几秒就发送一次请求，询问服务器是否有新信息。

场景再现：

客户端：啦啦啦，有没有新信息(Request)

服务端：没有（Response）

客户端：啦啦啦，有没有新信息(Request)

服务端：没有。。（Response）

客户端：啦啦啦，有没有新信息(Request)

服务端：你好烦啊，没有啊。。（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：好啦好啦，有啦给你。（Response）

客户端：啦啦啦，有没有新消息（Request）

服务端：。。。。。没。。。。没。。。没有（Response） —- loop

long poll

long poll 其实原理跟 ajax轮询 差不多，都是采用轮询的方式，不过采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。

场景再现：

客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request）

服务端：额。。 等待到有消息的时候。。来 给你（Response）

客户端：啦啦啦，有没有新信息，没有的话就等有了才返回给我吧（Request） -loop

从上面可以看出其实这两种方式，都是在不断地建立HTTP连接，然后等待服务端处理，可以体现HTTP协议的另外一个特点，被动性。

何为被动性呢，其实就是，服务端不能主动联系客户端，只能有客户端发起。

简单地说就是，服务器是一个很懒的冰箱（这是个梗）（不会、不能主动发起连接），但是上司有命令，如果有客户来，不管多么累都要好好接待。

说完这个，我们再来说一说上面的缺陷（原谅我废话这么多吧OAQ）

从上面很容易看出来，不管怎么样，上面这两种都是非常消耗资源的。

ajax轮询 需要服务器有很快的处理速度和资源。（速度）long poll 需要有很高的并发，也就是说同时接待客户的能力。（场地大小）

所以 ajax轮询 和 long poll 都有可能发生这种情况。

客户端：啦啦啦啦，有新信息么？

服务端：月线正忙，请稍后再试（503 Server Unavailable）

客户端：。。。。好吧，啦啦啦，有新信息么？

服务端：月线正忙，请稍后再试（503 Server Unavailable）

客户端：然后服务端在一旁忙的要死：冰箱，我要更多的冰箱！更多。。更多。。（我错了。。这又是梗。。）

言归正传，我们来说Websocket吧

通过上面这个例子，我们可以看出，这两种方式都不是最好的方式，需要很多资源。

一种需要更快的速度，一种需要更多的’电话’。这两种都会导致’电话’的需求越来越高。

哦对了，忘记说了HTTP还是一个状态协议。

通俗的说就是，服务器因为每天要接待太多客户了，是个健忘鬼，你一挂电话，他就把你的东西全忘光了，把你的东西全丢掉了。你第二次还得再告诉服务器一遍。

所以在这种情况下出现了，Websocket出现了。他解决了HTTP的这几个难题。首先，被动性，当服务器完成协议升级后（HTTP->Websocket），服务端就可以主动推送信息给客户端啦。所以上面的情景可以做如下修改。

客户端：啦啦啦，我要建立Websocket协议，需要的服务：chat，Websocket协议版本：17（HTTP Request）

服务端：ok，确认，已升级为Websocket协议（HTTP Protocols Switched）

客户端：麻烦你有信息的时候推送给我噢。。

服务端：ok，有的时候会告诉你的。

服务端：balabalabalabala

服务端：balabalabalabala

服务端：哈哈哈哈哈啊哈哈哈哈

服务端：笑死我了哈哈哈哈哈哈哈

就变成了这样，只需要经过一次HTTP请求，就可以做到源源不断的信息传送了。（在程序设计中，这种设计叫做回调，即：你有信息了再来通知我，而不是我傻乎乎的每次跑来问你 ）

这样的协议解决了上面同步有延迟，而且还非常消耗资源的这种情况。那么为什么他会解决服务器上消耗资源的问题呢？

其实我们所用的程序是要经过两层代理的，即HTTP协议在Nginx等服务器的解析下，然后再传送给相应的Handler（PHP等）来处理。简单地说，我们有一个非常快速的 接线员（Nginx） ，他负责把问题转交给相应的 客服（Handler） 。

本身接线员基本上速度是足够的，但是每次都卡在客服（Handler）了，老有客服处理速度太慢。，导致客服不够。Websocket就解决了这样一个难题，建立后，可以直接跟接线员建立持久连接，有信息的时候客服想办法通知接线员，然后接线员在统一转交给客户。

这样就可以解决客服处理速度过慢的问题了。

同时，在传统的方式上，要不断的建立，关闭HTTP协议，由于HTTP是非状态性的，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。

虽然接线员很快速，但是每次都要听这么一堆，效率也会有所下降的，同时还得不断把这些信息转交给客服，不但浪费客服的处理时间，而且还会在网路传输中消耗过多的流量/时间。

但是Websocket只需要一次HTTP握手，所以说整个通讯过程是建立在一次连接/状态中，也就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求，这样就解决了接线员要反复解析HTTP协议，还要查看identity info的信息。

同时由客户主动询问，转换为服务器（推送）有信息的时候就发送（当然客户端还是等主动发送信息过来的。。），没有信息的时候就交给接线员（Nginx），不需要占用本身速度就慢的客服（Handler）了

——————–

至于怎么在不支持Websocket的客户端上使用Websocket。。答案是： 不能

但是可以通过上面说的 long poll 和 ajax 轮询 来 模拟出类似的效果

]]> http://meisw.wdlinux.cn//show-970-1.html 传输协议 2017-09-06 18:55 http://meisw.wdlinux.cn//show-922-1.html SSDP 简单服务发现协议 admin  SSDP 简单服务发现协议，是应用层协议，是构成UPnP（通用即插即用）技术的核心协议之一。它为网络客户端（network client）提供了一种发现网络服务（network services）的机制，采用基于通知和发现路由的多播方式实现。

SSDP多播地址：239.255.255.250:1900（IPv4），FF0x::C（IPv6）

两种类型的SSDP请求消息会通过SSDP多播地址发送：

1. 发现请求（Discovery request 或查询请求）。SSDP客户端向此地址发送HTTP UDP 发现请求，查询某种类型的服务。SSDP服务在此地址上监听服务发现请求。当服务监听到的HTTP UDP 发现请求和它自己提供的服务匹配时，它以单播方式发送HTTP UDP 响应。

2. 存在通知（notification）。SSDP服务向此多播地址发送HTTP UDP 通知消息来宣布自己的存在。

 

发现结果（discovery results）和存在通知消息（presence announcements）提供的信息包括：

服务的类型URI

服务名称USN：唯一标识一种服务实例。

位置信息：发现结果和存在通知可包含一个或多个位置URI，客户端利用位置信息可以找到它需要的服务。

期限信息：客户端在自己的cache中保存此服务多长时间。如果期限过了，关于此服务的信息会被从cache中拿掉。当客户端接收到的发现结果或存在通知包含的USN和cache中的某条匹配，则更新。

客户端的服务缓存像下面这样：

【SSDP发现请求】ssdp:discover

ssdp:discover 必须包含一个ST头，客户端使用ST头来表明他们想发现的服务类型。ssdp:discover 必须包含一个带 *  的请求URI。

M-SEARCH * HTTP/1.1

S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6

Host: 239.255.255.250:1900

Man: "ssdp:discover"

ST: ge:fridge

MX: 3

各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组织定义。

 

SSDP服务发现自己的服务类型和ST中指明的服务类型匹配时，可以向ssdp:discover来自的IP地址/端口响应。响应消息应该包含服务的位置信息（Location 或AL头），ST和USN头。响应消息应该包含cache控制信息（max-age 或者 Expires头），如果两者都包含了，Expires 头优先，如果两者都缺失，那么这条服务消息不能被cache。

HTTP/1.1 200 OK

S: uuid:ijklmnop-7dec-11d0-a765-00a0c91e6bf6

Ext:

Cache-Control: no-cache="Ext", max-age = 5000

ST: ge:fridge

USN: uuid:abcdefgh-7dec-11d0-a765-00a0c91e6bf6

AL: <blender:ixl><http://foo/bar>

各HTTP协议头的含义简介：

CACHE-CONTROL：max-age指定通知消息存活时间，如果超过此时间间隔，控制点可以认为设备不存在

DATE：指定响应生成的时间

EXT：向控制点确认MAN头域已经被设备理解

LOCATION：包含根设备描述得URL地址

SERVER：饱含操作系统名，版本，产品名和产品版本信息

ST：内容和意义与查询请求的相应字段相同

USN：表示不同服务的统一服务名，它提供了一种标识出相同类型服务的能力。

 

【SSDP存在通知消息】

SSDP服务通过存在通知消息来向客户端宣布自己的存在，更新期限信息，更新位置信息。

ssdp:alive 消息必须将 NT 设置成自己的服务类型，USN头设置成自己的USN。ssdp:alive 应该包括Location或者AL头，如果没有DNS支持的话，使用SSDP服务的IP地址来代表位置。ssdp:alive还应该包括cache控制信息，max-age或者Expires头。

NOTIFY * HTTP/1.1

Host: 239.255.255.250:reservedSSDPport

NT: blenderassociation:blender

NTS: ssdp:alive

USN: someunique:idscheme3

AL: <blender:ixl><http://foo/bar>

Cache-Control: max-age = 7393

ssdp:alive 没有响应消息。

 

SSDP服务可以发送ssdp:byebye 来宣布自己下线。ssdp:byebye 必须将NT设置成自己的服务类型，将USN头设置成自己的USN。ssdp:byebye 也没有响应消息。当客户端接收到ssdp:byebye 消息，删掉cache里面的相关条目。

NOTIFY * HTTP/1.1

Host: 239.255.255.250:reservedSSDPport

NT: someunique:idscheme3

NTS: ssdp:byebye

USN: someunique:idscheme3

 

【SSDP Auto-Shut-Off Algorithm】

A mechanism is needed to ensure that SSDP does not cause such a high level of traffic that it overwhelms the network it is running on.

【ssdp:all】

A mechanism is needed to enable a client to enumerate all the services available on a particular SSDP multicast channel/port.

 

【参考】

SSDP 协议原文：http://tools.ietf.org/html/draft-cai-ssdp-v1-03

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

]]> http://meisw.wdlinux.cn//show-922-1.html 传输协议 2017-01-10 19:27 http://meisw.wdlinux.cn//show-921-1.html SSDP协议基础详解 admin  SSDP协议基础详解

 
SSDP协议，不知道大家是否听说过呢？这个协议的使用多出现在端口当中。下面我们就来了解一下这个协议的具体内容吧。什么是SSDP协议呢？SSDP就是简单服务发现协议（SSDP，Simple Service Discovery Protocol）是一种应用层协议，是构成通用即插即用(UPnP)技术的核心协议之一。
    
简单服务发现协议提供了在局部网络里面发现设备的机制。控制点（也就是接受服务的客户端）可以通过使用简单服务发现协议，根据自己的需要查询在自己所在的局部网络里面提供特定服务的设备。设备（也就是提供服务的服务器端）也可以通过使用简单服务发现协议，向自己所在的局部网络里面的控制点宣告它的存在。
 
实现
简单服务发现协议是在HTTPU和HTTPMU的基础上实现的协议。
按照协议的规定，当一个控制点（客户端）接入网络的时候，它可以向一个特定的多播地址的SSDP端口使用M-SEARCH方法发送“ssdp:discover”消息。当设备监听到这个保留的多播地址上由控制点发送的消息的时候，设备会分析控制点请求的服务，如果自身提供了控制点请求的服务，设备将通过单播的方式直接响应控制点的请求。
 
类似的，当一个设备接入网络的时候，它应当向一个特定的多播地址的SSDP端口使用NOTIFY方法发送“ssdp:alive”消息。控制点根据自己的策略，处理监听到的消息。考虑到设备可能在没有通知的情况下停止服务或者从网络上卸载，“ssdp:alive”消息必须在HTTP协议头CACHE-CONTROL里面指定超时值，设备必须在约定的超时值到达以前重发“ssdp:alive”消息。如果控制点在指定的超时值内没有再次收到设备发送的“ssdp:alive”消息，控制点将认为设备已经失效。    
 
当一个设备计划从网络上卸载的时候，它也应当向一个特定的多播地址的SSDP协议端口使用NOTIFY方法发送“ssdp:byebye”消息。但是，即使没有发送“ssdp:byebye”消息，控制点也会根据“ssdp:alive”消息指定的超时值，将超时并且没有再次收到的“ssdp:alive”消息对应的设备认为是失效的设备。
 
在IPv4环境，当需要使用多播方式传送相关消息的时候，SSDP一般使用多播地址239.255.255.250和UDP端口号1900。
根据互联网地址指派机构的指派，SSDP字而已在IPv6环境下使用多播地址FF0X::C，这里的X根据scope的不同可以有不同的取值。
]]> http://meisw.wdlinux.cn//show-921-1.html 传输协议 2017-01-10 18:44