系统设计01-如何设计应用层协议（未完待续）

第一个问题：我为什么学习他

程序员的自我修养—链接、装载与库p88

第二个问题：这个太难了，我不知道如何掌握

https://app.diagrams.net/#G1PhnRks5A6CWAfC_PciixgG7DQYyq6nZv

从htttp协议我没看出有效信息，哪里有扩展了，哪里有分割了。

htttp我整体在用哪里需要学

消息：key/value方式传递

关键部分

应用层协议考虑拆分数据情况

字段代表了内容的类型：

消息头里必然有对消息体类型，范围大小描述

看到“TCP粘包”这个专有名词，我表示极度震惊。连夜打车回到家里，战战兢兢翻开《计算机网络》，拿着放大镜仔细看了半夜，也没看到“粘包”两个字。我的后背不觉地渗出致密的汗水，双手止不住地发抖。匆忙打开电脑，一篇篇地翻着论文，试图寻找关于这个词的信息。可眼看天就要亮了，我依旧一无所获。我失望的躺在床上，满脑子都是“粘包，粘包，粘包！”，横竖睡不着，不得已打开了知乎，写下了一个问题“究竟什么是TCP粘包”。不一会儿答案就如雪花儿般涌了出来，每一片雪花上都写着一句话“TCP没有粘包”。我颤抖的双手终于停了下来，一股热流从我心底涌到泪腺。啊，原来我并不孤独。

我用json不就行了，我平时都这样解析的

http://www.cppblog.com/noflybird/archive/2014/05/26/207100.html

为什么使用.proto，这又什么用

自己demo传输字符串，因此不需要考虑这个问题

Java默认提供的序列化：无法跨语言、序列化后的码流太大、序列化的性能差
XML，优点：人机可读性好，可指定元素或特性的名称。缺点：序列化数据只包含数据本身以及类的结构，不包括类型标识和程序集信息；只能序列化公共属性和字段；不能序列化方法；文件庞大，文件格式复杂，传输占带宽。适用场景：当做配置文件存储数据，实时数据转换。
JSON，是一种轻量级的数据交换格式，优点：兼容性高、数据格式比较简单，易于读写、序列化后数据较小，可扩展性好，兼容性好、与XML相比，其协议比较简单，解析速度比较快。缺点：数据的描述性比XML差、不适合性能要求为ms级别的情况、额外空间开销比较大。适用场景（可替代ＸＭＬ）：跨防火墙访问、可调式性要求高、基于Web browser的Ajax请求、传输数据量相对小，实时性要求相对低（例如秒级别）的服务。
Fastjson，采用一种“假定有序快速匹配”的算法。优点：接口简单易用、目前java语言中最快的json库。缺点：过于注重快，而偏离了“标准”及功能性、代码质量不高，文档不全。适用场景：协议交互、Web输出、Android客户端
Thrift，不仅是序列化协议，还是一个RPC框架。优点：序列化后的体积小, 速度快、支持多种语言和丰富的数据类型、对于数据字段的增删具有较强的兼容性、支持二进制压缩编码。缺点：使用者较少、跨防火墙访问时，不安全、不具有可读性，调试代码时相对困难、不能与其他传输层协议共同使用（例如HTTP）、无法支持向持久层直接读写数据，即不适合做数据持久化序列化协议。适用场景：分布式系统的RPC解决方案
Avro，Hadoop的一个子项目，解决了JSON的冗长和没有IDL的问题。优点：支持丰富的数据类型、简单的动态语言结合功能、具有自我描述属性、提高了数据解析速度、快速可压缩的二进制数据形式、可以实现远程过程调用RPC、支持跨编程语言实现。缺点：对于习惯于静态类型语言的用户不直观。适用场景：在Hadoop中做Hive、Pig和MapReduce的持久化数据格式。
Protobuf，将数据结构以.proto文件进行描述，通过代码生成工具可以生成对应数据结构的POJO对象和Protobuf相关的方法和属性。优点：序列化后码流小，性能高、结构化数据存储格式（XML JSON等）、通过标识字段的顺序，可以实现协议的前向兼容、结构化的文档更容易管理和维护。缺点：需要依赖于工具生成代码、支持的语言相对较少，官方只支持Java 、C 、python。适用场景：对性能要求高的RPC调用、具有良好的跨防火墙的访问属性、适合应用层对象的持久化

对象怎么在网络中传输？

一种自动反射消息类型的 Google Protobuf 网络传输方案

Google Protobuf 本身具有很强的反射(reflection)功能，可以根据 type name 创建具体类型的 Message 对象。

RTMP(Real-Time Messaging Protocol, 实时消息传输协议)

是 Adobe 开发的一种用于实时数据通信的应用层网络协议，

基于 TCP 传输。

RTMFP 是 RTMP 基于 UDP 传输的一种协议，用于 P2P 通信。

该协议主要用于解决多媒体数据传输流中的多路复用和分包问题

RTMP 协议中的分块 (Chunk) 可以用来实现流多路复用和分包，其中块大小是可以设置的。

显然，将消息分块传输会带来额外开销，所以需要尽可能减少额外开销。

块越小可能开销越大，块越大可能延迟越大（某些重要优先级的消息到达也缓慢）。

RTMP 消息格式：消息头和负载。消息头包括消息类型 (Msg Type，第 1-7 位表示)、负载长度 (Payload Length)、消息时间戳 (Timestamp)、消息流

对于多路复用和分包的处理，RTMP 协议在传输时会用 RTMP Message（消息）来封装数据，而每一条 Message 在发送端会被划分为一个或多个带有 Message ID 的 Chunk（分块）。接收端根据约定格式和 ID 将 Message 还原。

rtmp 推流过程中，很容易出现延迟较大的情况（虽然名字上叫实时协议，但延迟高达 10s 不是梦啊......）。这主要来源于两部分——网络抖动和 TCP 重传（实际上工程应用中，还有音视频采集和编码模块的不稳定性、硬件设备受限等各种因素）。重连策略 RTMP 默认的超时时间是比较长的，在实际应用场景中一般无法忍受。同样需要开发人员根据业务需求，修改配置并优化重连策略。主要是针对移动网络下网络断开、延迟过大等情况，需要开发人员按需重连。