说起RTMP协议，相信很多人都比较陌生，这个协议相对HTTP、HTTPS、TCP等我们常见的协议而言，我们在工作中确实较少接触它，但是对现在如火如荼的直播行业，RTMP是一个重要的协议，它在实时音视频场景中使用非常广泛，而且目前市占率很高。 本文的主要内容是分析RTMP的协议，当然不是纯理论分析，这样没多大意思，还是结合实践抓包文件来具体分析，这样才能较好地理解RTMP的内涵。具体如何抓包见本文末尾的“Android抓包”模块。希望你阅读完本章之后，自己也能简单地动手操作一下，这样理解深刻一下。
原版的协议内容太冗长了，感兴趣可以看一下www.adobe.com/devnet/rtmp…
RTMP基础介绍 RTMP协议的主要特点：
RTMP协议是应用层协议，是要靠底层可靠的传输层（TCP）
协议（通常是TCP）来保证信息传输的可靠性的。在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接。播放一个RTMP协议的流媒体需要经过以下几个步骤：握手，建立网络连接，建立网络流，播放。服务器和客户端之间只能建立一个网络连接，但是基于该连接可以创建很多网络流。
这儿埋下一个小疑问？为什么传输层已经建立了TCP连接，RTMP还需要再次建立一个连接，有这个必要吗？
RTMP协议传输时会对数据做自己的格式化，这种格式的消息我们称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。
RTMP握手
RTMP基于TCP，已知TCP需要3次握手才可以建立连接，在TCP3次握手成功之后，应用层的RTMP也是需要握手的，就是认证过程。具体的认证过程如下：
客户端发送 C0、C1、 C2，服务器发送 S0、 S1、 S2。
首先，客户端发送 C0 表示自己的版本号，不必等对方的回复，然后发送 C1 表示自己的时间戳。
服务器只有在收到 C0 的时候，才能返回 S0，表明自己的版本号，如果版本不匹配，可以断开连接。
服务器发送完 S0 后，也不用等什么，就直接发送自己的时间戳 S1。客户端收到 S1 的时候，发一个知道了对方时间戳的 ACK C2。同理服务器收到 C1 的时候，发一个知道了对方时间戳的 ACK S2。
握手建立完成。
现在回答上面提出的问题，为什么RTMP还需要单独建立一个连接？ 因为它们需要商量一些事情，保证以后的传输能正常进行。主要就是两个事情，一个是版本号，如果客户端、服务器的版本号不一致，则不能工作。另一个就是时间戳，视频播放中，时间是很重要的，后面的数据流互通的时候，经常要带上时间戳的差值，因而一开始双方就要知道对方的时间戳。 光讲纯理论，没意思，还是抓包看一下具体的流程吧。 1.首先TCP 3次握手
2.RTMP握手过程
★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。
见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
我们发现真实发包是C0+C1一起发；S0、S1、S2一起发。但是发送的时候还是会严格按照时序来控制的，这样才能真正校验好版本号等字段。
RTMP拉流的核心流程如下：
1.建立网络连接
客户端发送命令消息中的“连接”(connect)到服务器，请求与一个服务应用实例建立连接。 StreamID是每个消息的唯一标识，划分成Chunk和还原Chunk为Message的时候都是根据这个ID来辨识是否是同一个消息的Chunk的，这里面为0说明这个消息是初始的0消息。 Chunk stream ID：一个RTMP message会拆分成多个chunk，同一个Chunk Stream ID必然属于同一个Message。这样在传送过程中发过来的chunk就是通过chunk stream ID最终组装成功我一个完成的message数据的。 message type id(消息的类型id)：表示实际发送的数据的类型，如8代表音频数据、9代表视频数据。如下面的两张图，这样看上去是不是好理解一点了。
type。共有4种不同的格式，其中第一种格式字段为0，可以表示其他三种表示的所有数据，但由于其他三种格式是基于对之前chunk的差量化的表示，因此可以更简洁地表示相同的数据，实际使用的时候还是应该采用尽量少的字节表示相同意义的数据。因为type 0是表示不同数据，其他是差量，所以可以想象如果搜不到type 0的包说明这个流肯定有问题。可以通过“rtmpt.header.format == 0”过滤。 2.建立一个网络流 网络流代表了发送多媒体数据的通道。服务器和客户端之间只能建立一个网络连接，且多个网络流可以复用这一个网络连接。这个在上面已经反复说过。 客户端向服务器请求创建流：
服务器收到请求后向客户端发送_result()，对创建流的消息进行响应。此时NetStream创建完成。
客户端发送命令消息中的“播放”（play）命令到服务器。
接收到播放命令后，服务器发送设置块大小（ChunkSize）协议消息。 服务器发送用户控制消息中的“streambegin”，告知客户端流ID。
播放命令成功的话，服务器发送命令消息中的“响应状态” NetStream.Play.Start，告知客户端“播放”命令执行成功。
我们发现执行了3个动作，分别如下：
共用一个Stream ID，并且在可以播放消息回来之后，已经解析出视频的基本属性。
分析完拉流的所有操作，启示推流也是类似的，区别在Play ---> Publishing了。
Android抓包
进入网站：www.androidtcpdump.com/android-tcp… tcpdump工具，现在最新版本是4.9.3
找一个root的手机，将下载好的tcpdump文件先push到/sdcard/ 下面，adb push tcpdump /sdcard/tcpdump
adb shell进入手机adb 模式下，cp -rf /sdcard/tcpdump /data/local/，将tcpdump拷贝到/data/local/目录下
chmod 777 /data/tcpdump，赋予tcpdump完全的执行权限
./data/local/tcpdump -i any -p -s 0 -w /sdcard/capture.pcap
然后开始访问rtmp的请求，访问完成后，会在/sdcard/目录下生成capture.pcap文件
adb pull /sdcard/capture.pcap ，本地使用wireshare分析capture.pcap文件
rtmp的测试源提供一个：rtmp://58.200.131.2:1935/livetv/hunantv
作者：安纯旦
★文末名片可以免费领取音视频开发学习资料，内容包括（FFmpeg ，webRTC ，rtmp ，hls ，rtsp ，ffplay ，srs）以及音视频学习路线图等等。
见下方!↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
最近在学习CAN，记录一下，也供大家参考交流。推荐几个我觉得很好的CAN学习，本文也是在看了他们的好文之后做的笔记首先是瑞萨的CAN入门，真的通透；秀！靠这篇我竟然2天理解了CAN协议！实战STM32F4CAN！原文链接：https://blog.csdn.net/XiaoXiaoPengBo/article/details/116206252CAN详解（小白教程）原文链接：https://blog.csdn.net/xwwwj/article/details/105372234一篇易懂的CAN通讯协议指南1一篇易懂的CAN通讯协议指南1-知乎(zhihu.com)视频推荐CAN总线个人知识总
尝试通过SSL连接到ImgurAPI时出现错误。这是代码和错误:API_URI=URI.parse('https://api.imgur.com')API_PUBLIC_KEY='Client-ID--'ENDPOINTS={:image=>'/3/image',:gallery=>'/3/gallery'}#Public:Uploadanimage##args-Theimagepathfortheimagetoupload#defupload(image_path)http=Net::HTTP.new(API_URI.host)http.use_ssl=truehttp.verify
一、什么是MQTT协议MessageQueuingTelemetryTransport：消息队列遥测传输协议。是一种基于客户端-服务端的发布/订阅模式。与HTTP一样，基于TCP/IP协议之上的通讯协议，提供有序、无损、双向连接，由IBM（蓝色巨人）发布。原理：（1）MQTT协议身份和消息格式有三种身份：发布者（Publish）、代理（Broker）（服务器）、订阅者（Subscribe）。其中，消息的发布者和订阅者都是客户端，消息代理是服务器，消息发布者可以同时是订阅者。MQTT传输的消息分为：主题（Topic）和负载（payload）两部分Topic，可以理解为消息的类型，订阅者订阅（Su
一、RIPV2协议简介 RIP(RoutingInformationProtocol)路由协议是一种相对古老，在小型以及同介质网络中得到了广泛应用的一种路由协议。RIP采用距离向量算法，是一种距离向量协议。RIP-1是有类别路由协议（ClassfulRoutingProtocol），它只支持以广播方式发布协议报文。RIP-1的协议报文无法携带掩码信息，它只能识别A、B、C类这样的自然网段的路由，因此RIP-1不支持非连续子网（DiscontiguousSubnet）。RIP-2是一种无类别路由协议（ClasslessRoutingProtocol），支持路由标记，在路由策略中可根据路由标记对
RTS在阿里云视频直播的基础上进行底层技术优化，通过集成阿里云播放器SDK，支持在千万级并发场景下节点间毫秒级延时直播的能力，弥补了传统直播存在3~6秒延时的问题，确保了超低延时、低卡顿、秒开流畅的直播观看体验。本文介绍了基于RTS超低延迟直播优化强互动场景体验的最佳实践方案，并以阿里云播放器Aliplayer为例，详细介绍RTS超低延迟拉流接入、自动降级、排障信息获取等逻辑的实现，助力企业打造互动直播行业的产品竞争力。适用场景该方案适用于对超低延迟直播有诉求的客户，尤其是业务中存在强互动场景直播的场景。强互动场景直播主要是指对主播和观众存在互动，或观众存在更高实时性观看、画面互动需求的情况，
我正在寻找一种方法来监视流上的事件，以便我可以确定是否有任何内容通过流。如果有，我将开始使用rtmpdump进行录制。我想象这是通过运行一个每60秒检查一次流的cron任务来实现的。如果它确定流正在通过，则调用rtmpdump开始记录它。如果没有，则什么都不做，并在60秒后再次检查。由于rtmpdump只是在没有流数据时出现错误，因此尝试使用它来监视流似乎不是一个好主意，但也许我错了。如果我在逐个案例的基础上手动执行此操作会很容易，但我正在尝试自动执行自动录制流的任务(如果它们可用)。有没有人遇到过这样做的方法？也许我可以在命令行(linux)中使用其他一些工具？如果有帮助，我正在使用
我尝试执行此页面中显示的ruby示例:http://tomayko.com/writings/unicorn-is-unix但我得到的只是echo.rb:9:in`bind':Addressfamilynotsupportedbyprotocolfamily-bind(2)(Errno::EAFNOSUPPORT)fromecho.rb:9:in`'有什么想法吗？ 最佳答案 我遇到了同样的问题。只需将localhost更改为0.0.0.0:address=Socket.pack_sockaddr_in(4242,'0.0.0.0')
最近我使用了一个由单个开发人员创建的不错的gem，它托管在Github上。在我的工作中，我不得不对它进行一些实质性的修改，添加一些改进。有些是特定于项目的，有些是特定于gem的，还有一些是独立的改进。对于特定于gem的改进(例如，错误修复)，我fork了存储库，应用了修复，并提出了拉取请求。然后，然而，我注意到独立的改进有点属于原始gem的并行、持续的分支类别。更清楚地说，你以前见过它；我重写了原始gem的View以使用TwitterBootstrap框架。因此，我也将它推送到了Github，但是，当然，我没有提出拉取请求——相反，我更新了README以解释不同之处，并感谢gem的原作
我关注了很多关于这个问题的帖子，但没有一个对我有帮助。我正在尝试使用最简单的irb命令进行连接:require'open-uri'open('https://aristo4stu3.bgu.ac.il')奇怪的是，对于我尝试过的任何其他httpsuri，它都工作正常(即https://google.com)。出于调试目的，我什至尝试使用以下方法禁用SSL验证:OpenSSL::SSL::VERIFY_PEER=OpenSSL::SSL::VERIFY_NONE这似乎也没有帮助。我的设置是(在AWS上):$rvm-vrvm1.21.3(stable)byWayneE.Seguin,Mic
我有一个共享对话框。在开发中它看起来像:http://xxxxxx.com/stuff产品上:https://yyyyyyyyyyy.com/stuff输出#Protocol##URL#的最佳Rails方式是什么我可以在哪里设置它们？谢谢 最佳答案 request.protocolrequest.url参见requestobject. 关于ruby-on-rails-如何使用rails输出当前协议(protocol)和url？，我们在StackOverflow上找到一个类似的问题：
