自定义Udp/Tcp协议，通信协议Socket/WebSocket，IM粘包、分包解决等(2)，ProtocolBuffer
> 自定义Udp/Tcp协议/通信协议(Java/C)；自定义构建和解析IM协议消息；IM自定义UDP通信协议
类似于网络通信中的TCPIP协议一般，比较可靠的通信协议往往包含有以下几个组成部分：帧头、地址信息、数据类型、数据长度、数据块、校验码、帧尾。因为在TCP流传输的过程中，可能会出现分包与黏包的现象。我们为了解决这些问题，需要我们自定义通信协议进行封包与解包。
C/S的聊天框架源程序，即支持UDP又支持TCP- https://download.csdn.net/download/aaa629690/3701088
一个简单的TCP自定义通信协议- https://www.2cto.com/net/201706/644587.html
TCP调试工具SocketTestDlg- http://www.zlmcu.com/document/tcp_debug_tools.html
Android 基于TCP协议的Socket编程(自定义协议)- https://blog.csdn.net/houxuehan/article/details/79296853
用于简化 WebSocket 在 Android 平台使用的封装方法- https://github.com/0xZhangKe/WebSocketDemo
> ProtocolBuffer消息与IM，IM与Socket与ProtocolBuffer
建议将Protobuf作为你的即时通讯应用数据传输格式。
protobuf是google开发出来的一些协议；采用了二进制进行传输，而不是文本（json，xml）。
Protobuf协议：
优点：非常小、非常快、非常简单，一条消息数据用Protobuf序列化后的大小是JSON的1/10、XML格式的1/20、是二进制序列化的1/10。缺点：不能表示复杂的数据结构，但是对于IM来讲，已经足够。强烈推荐此协议。
Protocol Buffer还有一个非常重要的优点就是可以保证同一消息报文新旧版本之间的兼容性。
JSON当然也是跨语言的。
处理websocket的建立、连接、重连、心跳、监听等，提供一些钩子函数；
websocket-heartbeat-js- https://github.com/zimv/websocket-heartbeat-js
Facebook的thrift据说也很有特色，2007年由Facebook开发，之后在2008年加到Apache计划中。是一个跨语言的轻量级RPC消息和数据交换框架，Thrift能生成的语言有: C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, Smalltalk, and OCaml，这是它的一大优点。
- 进行Socket编程, 常见使用的协议UDP/TCP：
TCP：传输控制协议 。是专门设计用于在不可靠的因特网上提供可靠的，端到端的字节流通信的协议。它是一种面向连接的协议。TCP连接是字节流而非报文流。
UDP：用户数据报协议 。不需要建立连接，不可靠。
> TCP与UDP的区别
TCP和UDP的区别- https://www.cnblogs.com/steven520213/p/8005258.html
TCP和UDP的最完整的区别- https://blog.csdn.net/li_ning_/article/details/52117463
TCP 和 UDP 区别：
1.面向连接vs无连接，
TCP 有三次握手的连接过程，UDP 适合消息的多播发布，从单个点向多个点传输消息
2.可靠性
TCP 利用握手， 确认（ACK） 和重传的机制，提供了可靠性保证，而 UDP 可能丢失，不知道到底有没有接收
3.有序性：
TCP 利用序列号保证了消息包的的顺序交付，到达可能无序，但 TCP 会排序
4.速度：
TCP 速度比较慢，因为要创建连接，保证消息的可靠性和有序性等，需要做额外的很多事情，UDP 更适合对速度比较敏感的应用，比如在线视频媒体，电视广播，多人在线游戏等。
5.重量级
TCP 重量级，UDP 轻量级，体现在元数据的头大小是，TCP 20字节，UDP 8字节。
TCP 适合金融等大多数领域，UDP适合游戏和娱乐场景。
TCP与UDP区别总结：1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保 证可靠交付3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的 UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信5、TCP首部开销20字节;UDP的首部开销小，只有8个字节6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。
TCP与UDP区别：
1.TCP提供的是面向连接的、可靠的数据流传输；
UDP提供的是非面向连接的、不可靠的数据流传输。
2.TCP提供可靠的服务，通过TCP连接传送的数据，无差错、不丢失，不重复，按序到达；UDP尽最大努力交付，即不保证可靠交付。
3.TCP面向字节流；
UDP面向报文。
4.TCP连接只能是点到点的；
UDP支持一对一、一对多、多对一和多对多的交互通信。
5.TCP首部开销20字节；
UDP的首部开销小，只有8个字节。
6.TCP的逻辑通信信道是全双工的可靠信道；
UDP的逻辑通信信道是不可靠信道。
TCP的优点： 可靠，稳定 TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源。 TCP的缺点： 慢，效率低，占用系统资源高，易被攻击 TCP在传递数据之前，要先建连接，这会消耗时间，而且在数据传递时，确认机制、重传机制、拥塞控制机制等都会消耗大量的时间，而且要在每台设备上维护所有的传输连接，事实上，每个连接都会占用系统的CPU、内存等硬件资源。 而且，因为TCP有确认机制、三次握手机制，这些也导致TCP容易被人利用，实现DOS、DDOS、CC等攻击。
UDP的优点： 快，比TCP稍安全 UDP没有TCP的握手、确认、窗口、重传、拥塞控制等机制，UDP是一个无状态的传输协议，所以它在传递数据时非常快。没有TCP的这些机制，UDP较TCP被攻击者利用的漏洞就要少一些。但UDP也是无法避免攻击的，比如：UDP Flood攻击…… UDP的缺点： 不可靠，不稳定 因为UDP没有TCP那些可靠的机制，在数据传递时，如果网络质量不好，就会很容易丢包。 基于上面的优缺点，那么： 什么时候应该使用TCP： 当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。 在日常生活中，常见使用TCP协议的应用如下： 浏览器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ文件传输 ………… 什么时候应该使用UDP： 当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。 比如，日常生活中，常见使用UDP协议的应用如下： QQ语音 QQ视频 TFTP ……
> 粘包、分包、解包
-- 高性能大容量socket并发（四）：粘包、分包、解包。
socket在api19之前没有继承Closeable接口;在熄屏的情况下，安卓端是接收不到UDP广播的。
socket在通信的时候可能需要启动多个线程，可以考虑使用线程池。
-- TCP
TCP 是全双工协议。websocket 底层使用的tcp 协议。 当一次发送数据过长时，tcp 会把数据封成多个包发送；同样当数据过短时， 会把数据合并成一个包发送，这种现象就是粘包。粘包的情况也有可能是接收端造成的。你自己数据协议也解决不了这个问题，TCP协议都会遇到粘包问题。
TCP协议是面向流的协议，这也是容易出现粘包问题的原因。而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。怎样定义消息呢？可以认为对方一次性write/send的数据为一个消息，需要明白的是当对方send一条信息的时候，无论底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。所谓粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。
须知：只有TCP有粘包现象，UDP永远不会粘包。
-- Websocket
Websocket协议已经做了iframe分帧处理了，不用做断包粘包处理.
Websocket需要像TCP Socket那样进行逻辑数据包的分包与合包吗？
RFC规范指出，WebSocket是一个message-based的协议，它可以自动将数据分片，并且自动将分片的数据组装。
也就是说，WebSocket的RFC标准是不会产生粘包、半包问题的。无需应用层开发人员关心缓存以及手工组装message。
然而理想与现实的不一致：RFC规范与实现的不一致，现实当中有几个问题：
1. 每个message可以是一个或多个分片。message不记录长度，分片才记录长度。
2. message最大的长度可以达到 9,223,372,036,854,775,807 字节，是由于Payload的数据长度有63bit的限制。
3. 很多WebSocket的实现其实并不按照标准的RFC实现完全，很多仅仅实现了50%就拿来用了。
这就导致了，在WebSocket实现上的最大长度很难达到这个大小，于是，很多API的实现上是会有限制的，可能会限制你的发送的长度，也可能会把过长的数据直接以流式发送。
-- socket的半包，粘包与分包的问题- https://blog.csdn.net/sunmenggmail/article/details/38952131
一个包没有固定长度，以太网限制在46－1500字节，1500就是以太网的MTU，超过这个量，TCP会为IP数据报设置偏移量进行分片传输，现在一般可允许应用层设置8k（NTFS系）的缓冲区，8k的数据由底层分片，而应用看来只是一次发送。windows的缓冲区经验值是4k,Socket本身分为两种，流(TCP)和数据报(UDP)，你的问题针对这两种不同使用而结论不一样。甚至还和你是用阻塞、还是非阻塞Socket来编程有关。
- 产生粘包问题的原因有以下几个：
第一、应用层调用write方法，将应用层的缓冲区中的数据拷贝到套接字的发送缓冲区。而发送缓冲区有一个SO_SNDBUF的限制，如果应用层的缓冲区数据大小大于套接字发送缓冲区的大小，则数据需要进行多次的发送。
第二种情况是，TCP所传输的报文段有MSS的限制，如果套接字缓冲区的大小大于MSS，也会导致消息的分割发送。
第三种情况由于链路层最大发送单元MTU，在IP层会进行数据的分片。
-- 产生分包与黏包现象的原因是什么？
1.产生分包原因：
可能是IP分片传输导致的，也可能是传输过程中丢失部分包导致出现的半包，还有可能就是一个包可能被分成了两次传输，在取数据的时候，先取到了一部分（还可能与接收的缓冲区大小有关系），总之就是一个数据包被分成了多次接收。
2.产生黏包的原因：
由于TCP协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发往服务器，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些）然后再发送（超时或者包大小足够）。那么这样的话，服务器在接收到消息（数据流）的时候就无法区分哪些数据包是客户端自己分开发送的，这样产生了粘包；服务器在接收到数据后，放到缓冲区中，如果消息没有被及时从缓存区取走，下次在取数据的时候可能就会出现一次取出多个数据包的情况，造成粘包现象
3.什么是封包与解包？
TCP/IP 网络数据以流的方式传输，数据流是由包组成，如何判定接收方收到的包是否是一个完整的包就要在发送时对包进行处理，这就是封包技术，将包处理成包头，包体。 包头是包的开始标记，整个包的大小就是包的结束标。
4.如何自定义协议？
发送时数据包是由包头+数据 组成的：其中包头内容分为包类型+包长度。
接收时，只需要先保证将数据包的包头读完整，通过收到的数据包包头里的数据长度和数据包类型，判断出我们将要收到一个带有什么样类型的多少长度的数据。然后循环接收直到接收的数据大小等于数据长度停止，此时我们完成接收一个完整数据包。
-- IM粘包 分包等
Socket本身分为两种，流(TCP)和数据报(UDP)。
对于UDP而言，要是其中一个分片丢失，那么接收方的IP层将把整个发送包丢弃，这就形成丢包。
TCP协议定义有一个选项叫做最大报文段长度（MSS，Maximum Segment Size），该选项用于在TCP连接建立时，收发双方协商通信时每一个报文段所能承载的最大数据长度。
数据帧的有效载荷(payload)比以太网的最大传输单元（MTU）大的时候，进行了IP分片。
-- 半包
指接受方没有接受到一个完整的包，只接受了部分，这种情况主要是由于TCP为提高传输效率，将一个包分配的足够大，导致接受方并不能一次接受完。（在长连接和短连接中都会出现）。
-- 粘包与分包
指发送方发送的若干包数据到接收方接收时粘成一包，从接收缓冲区看，后一包数据的头紧接着前一包数据的尾。出现粘包现象的原因是多方面的，它既可能由发送方造成，也可能由接收方造成。发送方引起的粘包是由TCP协议本身造成的，TCP为提高传输效率，发送方往往要收集到足够多的数据后才发送一包数据。若连续几次发送的数据都很少，通常TCP会根据优化算法把这些数据合成一包后一次发送出去，这样接收方就收到了粘包数据。接收方引起的粘包是由于接收方用户进程不及时接收数据，从而导致粘包现象。这是因为接收方先把收到的数据放在系统接收缓冲区，用户进程从该缓冲区取数据，若下一包数据到达时前一包数据尚未被用户进程取走，则下一包数据放到系统接收缓冲区时就接到前一包数据之后，而用户进程根据预先设定的缓冲区大小从系统接收缓冲区取数据，这样就一次取到了多包数据。分包是指在出现粘包的时候我们的接收方要进行分包处理。（在长连接中都会出现）
1.正常情况：如果Socket Client 发送的数据包，在Socket Server端也是一个一个完整接收的，那个就不会出现粘包和分包情况，数据正常读取。
2.粘包情况：Socket Client发送的数据包，在客户端发送和服务器接收的情况下都有可能发送，因为客户端发送的数据都是发送的一个缓冲buffer，然后由缓冲buffer最后刷到数据链路层的，那么就有可能把数据包2的一部分数据结合数据包1的全部被一起发送出去了，这样在服务器端就有可能出现这样的情况，导致读取的数据包包含了数据包2的一部分数据，这就产生粘包，当然也有可能把数据包1和数据包2全部读取出来。
3.分包情况：意思就是把数据包2或者数据包1都有可能被分开一部分发送出去，接着发另外的部分，在服务器端有可能一次读取操作只读到一个完整数据包的一部分。
- 粘包的问题的解决思路：
1.发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
2.包尾加上\r\n标记。FTP协议正是这么做的。但问题在于如果数据正文中也含有\r\n，则会误判为消息的边界。
3.包头加上包体长度。包头是定长的4个字节，说明了包体的长度。接收对等方先接收包体长度，依据包体长度来接收包体。
4.使用更加复杂的应用层协议。
- 解决数据粘包的两种方法：
方法一：数据粘包问题的出现是因为缓冲区过大，因此采用发送/接收变长消息的方法，在发送/接收消息时，将消息的长度作为消息的一部分发送出去，从而接收方可以根据传来的长度信息，制定相应长度的缓冲区；
方法二：将发送的每条消息的首尾都加上特殊标记符，前加"<" 后加">"。这里我采取的是先将要发送的所有消息，首尾加上特殊标记后，都先放在一个字符串string中，然后一次性的发送给接收方，接受之后，再根据标记符< >，将一条条消息择（zhái）出来。
-- 粘包解决：自定义协议，如：dataLen+data+type+md5；Socket本身分为两种，流(TCP)和数据报(UDP)
socket粘包是避免不了的，主要在于接收方如何解包和控制。处理方法：
定制socket传输协议，增加包头、命令、数据长度、数据体、结束位。比如发送消息：如发送“你好”消息
String msg = "你好";
byte[] byBuffer = msg.getBytes();
//加入定制的协议该条数据位：
byte[] b = new byte[4+byBuffer.length];
b[0] = 0xFFFFF; //随便定义,包头
b[1] = 0x01; //命令
b[2] = byBuffer.length; //数据长度
b[3 - n] = byBuffer; //数据
b[b.length -1] = 0x0d; //结束
接收方接收到该数据后判断包头是否一致，不一致则不要，根据b[2]数据长度来去数据，第一次未接收完继续接收第二次，直到接收数据长度==b[2]为止。一条完整的数据就出来了。
-- 解决数据分包和粘包的基本策略如下
1.消息定长，比如定一个100，那么读取端每次读取数据就截取100个长度的数据，然后交给业务成去做解析
2.在消息的尾部加一些特殊字符，那么在读取数据的时候，只要读到这个特殊字符，就认为已经可以截取一个完整的数据包了，这种情况在一定的业务情况下实用。
3.读取缓存的数据是不定长的，所以我们把读取到的数据添加到我们自己的一个byte[]数组中，然后根据我们的业务逻辑来找到指定的特殊协议头部，协议长度，协议尾部，然后从我们的byte[]中获取一个完整的数据包，然后再对数据包进行业务解析就可以得到正确结果。
4.在数据包发送的情况下，有可能后面的数据包分开成2个或者多个，但是最前面的部分包，黏住在前面的一个完整或者部分包的后面，也就是粘包和分包同时产生了。
-- 粘包、分包的问题两种通用且常用的方案：google的protobuf
1. 添加分隔符 =>[数据流][分隔符][数据流] [分隔符]
2. 添加一个包长 => [包长][数据流][包长][数据流]
protobuf，google开源项目，是一种二进制的格式，比使用 xml, json 进行数据交换快许多。一条消息数据，用protobuf序列化后的大小是json的10分之一，xml格式的20分之一，是二进制序列化的10分之一。websocket的建立、连接、重连、心跳、监听等，Protobuf作为你的即时通讯应用数据传输格式。
Protobuf官方主页：https://github.com/52im/protobuf
有关移动端IM通信协议的坑- https://blog.csdn.net/hanj456/article/details/53461865
使用Protobuf，理由如下：
1.灵活、高效：灵活（方便接口更新）、高效（效率经过google的优化，传输效率比普通的XML等高很多）；
2.易于使用：开发人员通过按照一定的语法定义结构化的消息格式，然后送给命令行工具，工具将自动生成相关的类，可以支持java、c++、python等语言环境。通过将这些类包含在项目中，可以很轻松的调用相关方法来完成业务消息的序列化与反序列化工作。
3.语言支持：原生支持c++、java、python等多达10余种语言。
-- 移动端IM有哪些难点需要解决：
1.流量：
采取哪种协议、图片缩略图、附件的压缩三点决定了流量的大小。
2.耗电：
(1)流量越小，耗电越低。(2)心跳策略，减少心跳次数，耗电量就会降低。
3.心跳时长：
wifi，2G，3G，4G，移动、电信、联通,不同网络，不同运行商，NAT失效时间不一样，因此心跳的时间也就不一样。
4.网络连接：
cmnet和cmwap下连接处理机制。
5.网络不稳定：
移动端最大的特点就是网络不稳定，在不稳定的网络状态下，如何保证消息以最快的速度到达？如何避免重联风暴？这些既需要从整体架构考虑，也需要在移动端采取巧妙的策略加以避免。
网络中出现TCP、UDP粘包、分包的两点解决办法- https://blog.csdn.net/cherish_2012/article/details/41681853
以太网，IP,TCP,UDP数据包分析- http://www.cnblogs.com/feitian629/archive/2012/11/16/2774065.html
分包产生的原因就简单的多：可能是IP分片传输导致的，也可能是传输过程中丢失部分包导致出现的半包，还有可能就是一个包可能被分成了两次传输，在取数据的时候，先取到了一部分（还可能与接收的缓冲区大小有关系），总之就是一个数据包被分成了多次接收。
-- 粘包与分包的处理方法：常用的解决方案
一个是采用分隔符的方式，即我们在封装要传输的数据包的时候，采用固定的符号作为结尾符（数据中不能含结尾符），这样我们接收到数据后，如果出现结尾标识，即人为的将粘包分开，如果一个包中没有出现结尾符，认为出现了分包，则等待下个包中出现后 组合成一个完整的数据包，这种方式适合于文本传输的数据，如采用/r/n之类的分隔符；
另一种是采用在数据包中添加长度的方式，即在数据包中的固定位置封装数据包的长度信息（或可计算数据包总长度的信息），服务器接收到数据后，先是解析包长度，然后根据包长度截取数据包（此种方式常出现于自定义协议中），但是有个小问题就是如果客户端第一个数据包数据长度封装的有错误，那么很可能就会导致后面接收到的所有数据包都解析出错（由于TCP建立连接后流式传输机制），只有客户端关闭连接后重新打开才可以消除此问题，我在处理这个问题的时候对数据长度做了校验，会适时的对接收到的有问题的包进行人为的丢弃处理（客户端有自动重发机制，故而在应用层不会导致数据的不完整性）；
另一种不建议的方式是TCP采用短连接处理粘包（这个得根据需要来，所以不建议）；
-- 用帧同步的项目，帧同步方案对网络有着极大的影响，于是采用了RUDP（可靠UDP）;TCP提供了过多的保护，在及时性上做了很多的妥协，比如：控制微包（Nagle算法），延时ACK，流量控制，超时重传等，这些设计严重影响了Tcp的速度和及时性。
首先思考RUDP需要解决哪些问题，然后根据问题加上必要的包头字段:
1. 数据完整性 –> 加上一个16或者32位的CRC验证字段
2. 乱序 –> 加上一个数据包序列号SEQ
3. 丢包 –> 需要确认和重传机制，就是和Tcp类似的Ack机制;在思考一下既然是自定义协议是不是需要一个协议号字段来过滤一些非法包，那么又可以加入一个新字段：
4. 协议字段 –> protol 字段，标识当前使用协议
-- IM，视频中的tcp、udp Rtmp，Socket/WebSocket应用及IM粘包 分包等
通常IM采取的协议有xmpp、mqtt、protobuf等数据通信私有协议。
Java干货之Socket自定义传输协议，可用于一般即时通讯- https://blog.csdn.net/qq_27070443/article/details/62225780
TCP协议攻略- https://www.jianshu.com/p/65605622234b
rtmp 协议中对视频格式的封装- https://blog.csdn.net/ddr77/article/details/54349004
-- 互动直播是怎样实现的呢？主要有以下几种可以实现的技术方案：
1.基于RTMP 和 CDN 技术的连麦
2.基于 WebRTC（P2P）与旁路直播的连麦
3.基于低延时网络的连麦
如果是为了快速出产品，到不必纠结是TCP还是UDP做直播，大佬们已经把协议、客户端、服务器端都准备好了，都是基于TCP，比如nginx，但是如果是想重造轮子，当然UDP好。
RTMP是Real Time Messaging Protocol（实时消息传输协议）的首字母缩写。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。
当数据传输的性能必须让位于数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。当强调传输性能而不是传输的完整性时，如：音频和多 媒体应用，UDP是最好的选择。在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：DNS交换。把 SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。TCP丰富的功能有时会导致不可预料 的性能低下，但是我们相信在不远的将来，TCP可靠的点对点连接将会用于绝大多数的网络应用。
RTMP、RTSP、HTTP这三个协议都属于互联网 TCP/IP 五层体系结构中应用层的协议。理论上这三种都可以用来做视频直播或点播。但通常来说，直播一般用 RTMP、RTSP。而点播用 HTTP。基于UDP和TCP的RTSP推流。
网页看视频的视频网站？（优酷、爱奇艺）。那必须HTTP/HTTPS；直播？那是rtmp（也是tcp）；视频聊天？像qq那样的貌似是udp？？？
> Socket/WebSocket应用, MutilcastSocket/DatagramPacket/DatagramSocket等
-- Socket的使用类型主要有两种：
流套接字（StreamSocket） ：基于 TCP协议，采用 流的方式 提供可靠的字节流服务；
数据报套接字(datagramsocket)：基于 UDP协议，采用 数据报文 提供数据打包发送的服务。
-- Socket 与 Http 对比:
Socket属于传输层，因为 TCP / IP协议属于传输层，解决的是数据如何在网络中传输的问题；
HTTP协议 属于 应用层，解决的是如何包装数据。
-- socket编程实现UDP数据传输基于DatagramSocket与DatagramPacket API实现.
okhttp websocket断线重连的机制- https://github.com/Rabtman/WsManager
a simple demo for socket- https://github.com/Carson-Ho/Socket_learning
使用MutilcastSocket实现多点广播- http://www.cnblogs.com/fysola/p/6088893.html
DatagramPacket与DatagramSocket 详解- http://blog.csdn.net/myhu730/article/details/44921387
Android Socket 发送广播包的那些坑- https://www.2cto.com/kf/201510/448077.html
当Android设备被设置为Wi-Fi热点的时候，上面的函数得到的地址是"0.0.0.0"，因此，我们需要探究当Android设备被设置为Wi-Fi热点的时候，它的IP地址究竟是多少
有人研究了Android底层源码发现，当Android设备被设置为Wi-Fi热点的时候，其IP地址是hardcode写死在源码中的，地址是：“192.168.43.1”，对应的广播地址是："192.168.43.255"
-- WebSocket的frame？google的protobuf在IM中的使用？
IM、金融、股价、视频会议等这样一些应用来说，所需要的不过是高实时、低延时。比较好的可选方案呢？比较流行的是 socket 和 websocket。
Websocket是应用层第七层上的一个应用层协议，它必须依赖 HTTP 协议进行一次握手 ，握手成功后，数据就直接从 TCP 通道传输，与 HTTP 无关了。WebSocket是HTML5开始提供的一种浏览器与服务器间进行全双工通信的网络技术，WebSocket通信协议于2011年被IETF定为标准RFC6455，WebSocket API被W3C定为标准。HTTP的半双工协议.WebSocket基于TCP双向全双工进行消息传递.
-- WebSocket的frame
Websocket的数据传输是frame形式传输的，比如会将一条消息分为几个frame，按照先后顺序传输出去。这样做会有几个好处：
1.大数据的传输可以分片传输，不用考虑到数据大小导致的长度标志位不足够的情况。
2.和http的chunk一样，可以边生成数据边传递消息，即提高传输效率。
WebSocket的ping与pong的java实现…- https://blog.csdn.net/u010770993/article/details/70312279
How to parse and validate a WebSocket frame in Java?- https://stackoverflow.com/questions/18368130/how-to-parse-and-validate-a-websocket-frame-in-java
-- WebSocket和Socket的开源框架
Socket封装，支持TCP/UDP客户端和服务端，支持自定义粘包处理、验证处理、解析处理- https://github.com/Blankeer/XAndroidSocket
WebSocket & WAMP in Java for Android and Java 8- https://github.com/crossbario/autobahn-java
仿茄子快传的一款文件传输应用，涉及到Socket通信，包括TCP，UDP通信- https://github.com/mayubao/KuaiChuan
JS WebSocketHeartBeat- https://github.com/zimv/WebSocketHeartBeat
Java Socket编程（二）Socket基础- https://blog.csdn.net/dc_726/article/details/7830998
Java Socket编程（五）NIO- https://blog.csdn.net/dc_726/article/details/7836877
nodeJS实现的socket服务器端Demo，使用protobuf作为数据格式- https://github.com/bobo892589/socket_server_demo
基于Java Socket的自定义协议，实现Android与服务器的长连接（二）-https://blog.csdn.net/u010818425/article/details/53448817
-- Socket的自定义协议设计思路：一般自定义协议会设计好多个字段组成，比如：dataLen+data+type+md5，数据长度+数据+类型+MD5，解析处理就是把这4个字段解析出来，返回byte[4][]，便于后续处理。
网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。
建立网络通信连接至少要一对端口号(socket)。socket本质是编程接口(API)，对TCP/IP的封装，TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口；HTTP是轿车，提供了封装或者显示数据的具体形式；Socket是发动机，提供了网络通信的能力。
-- Socket编程发送和接收数据，这些处理数据的方法根据抽象层次，由低到高分别有：
1.手动编码：使用位运算逐个自己编码和解析。
2.利用流来自动编码：组合使用OutputStream和ByteArrayOutputStream。
3.序列化：将数据放入一个数据对象中，直接将这个对象序列化后发送。使用起来很方便，但要注意效率的损失，以及接收方也要使用Java。
4.RMI：将对方法的调用都发送过去了，直接实现了方法的远程调用。
-- 在最底层的方法1中，我们需要自己解决一些底层的问题：
1.整型的发送：要考虑是大尾端还是小尾端，是无符号的还是有符号的整数。
2.字符串的发送：要考虑编码问题。
3.无长度限制的类型，如大整数：要编码成帧Frame，通过定界符或者长度位来区分每帧。
-- 我们可以向每个接受者单播一个数据副本，但这样做效率可能非常低。只有UDP套接字允许广播和多播，两者的区别是：广播会发送到网络上所有可达的主机，有些操作系统可能不允许普通用户进行广播操作；而多播只发送给感兴趣的主机。具体来说是调用MulticastSocket的joinGroup()加入到多播组的主机。
public class MulticastReceiverTest {
public static void main(String[] args) throws Exception {
final InetAddress address = InetAddress.getByName("224.1.1.1");
final int port = 45599;
for (int i = 0; i < 5; i++) {
new Thread("Thread #" + i){
@Override
public void run() {
try {
MulticastSocket sock = new MulticastSocket(port);
sock.joinGroup(address);
byte[] msg = new byte[256];
DatagramPacket packet = new DatagramPacket(msg, msg.length);
sock.receive(packet);
System.out.println(Thread.currentThread().getName() +
" receive: " + new String(packet.getData()));
}
catch (IOException e) {
e.printStackTrace();
}
}
}.start();
}
Thread.sleep(2000);
MulticastSocket sock = new MulticastSocket();
sock.setTimeToLive(32);
byte[] msg = "hellomulticast".getBytes();
DatagramPacket packet = new DatagramPacket(msg, msg.length, address, port);
sock.send(packet);
System.out.println("Message sent");
}
}
自定义Udp/Tcp协议，通信协议Socket/WebSocket，IM粘包、分包解决等(2)，ProtocolBuffer相关推荐
- 4-10：TCP协议之面向字节流和粘包问题
文章目录 一:面向字节流 二:粘包(应用层数据包)问题 三:TCP异常情况 一:面向字节流 经过前面的叙述,现在我们对TCP面向字节流的理解就更加深刻了. 创建一个TCP的socket,就会在内核中创 ...
- java socket 通信协议_java 基于TCP协议的Socket编程和通信
java 基于 TCP 协议的 Socket 编程和通信 在网络通讯中,第一次主动发起通讯的程序被称作客户 端 (Client) 程序, 简称客户端, 而在第一次通讯中等待连接的 程序被称作服务器端 ...
- java socket发送定长报文_一个基于TCP协议的Socket通信实例
原标题:一个基于TCP协议的Socket通信实例 1. 前言 一般接口对接多以http/https或webservice的方式,socket方式的对接比较少并且会有一些难度.正好前段时间完成了一个so ...
- Linux网络-UDP/TCP协议详解
Linux网络-UDP/TCP协议详解 零.前言 一.UDP协议 二.TCP协议 1.应答机制 2.序号机制 3.超时重传机制 4.连接管理机制 三次握手 四次挥手 5.理解CLOSE_WAIT状态 ...
- 基于TCP协议的Socket网络通信
前言 一. 什么是网络(了解七层网络模型)? 二. 什么是TCP/UDP协议? 三.什么是socket? 定义 四.基于TCP协议的socket通信的实现步骤是怎样的? 客户端的实现 服务端的实现 测 ...
- python 网络编程 套接字的初使用 基于TCP协议的socket
文章目录 基于TCP协议的socket server端 client端 尝试启动 基于TCP协议的socket tcp是基于链接的,必须先启动服务端,然后再启动客户端去链接服务端 server端 # ...
- 【Linux】一篇文章搞定 CPP模拟实现TCP协议下socket通信
CPP模拟实现TCP协议下socket通信 1. TCP 编程流程图 2. 数据收发阶段使用的API 2.1 send接口 2.2 recv接口 3. 两个队列 4. 总结TCP 编程双端流程 5. ...
- python/socket编程之粘包
python/socket编程之粘包 粘包 只有TCP有粘包现象,UDP永远不会粘包. 首先需要掌握一个socket收发消息的原理 1 2 3 4 5 6 7 8 9 10 11 12 13 14 发 ...
- Linux IPC udp/tcp/UNIX域 socket编程
UNIX域套接字本地通信即在socket第一个参数中选择AF_LOCAL,socket是BSD提出的一种适用于所有的情况的进程间通信的方式,虽然现在多用于网络通信,但是本机内的进程间通信也是没有问题的 ...
最新文章
- postfix 遇到的问题
- php拆分jsion_Php如何返回json数据，前后端分离的基本解决方案
- 2-4 js基础-事件对象小结
- phpstudy2018 安装xdebug扩展
- 蓝桥杯java第五届决赛第四题--排列序数
- 在串口通信开发中实现自动查找串口端口的方法
- nginx 重启和配置include的位置
- DWM1000 收发RXLED TXLED控制代码修改
- 欧姆龙cp1h指令讲解_欧姆龙cp1h常用指令学习（十五）网络通讯指令SEND,RECV,CMND...
- 运行QT打包后的程序出现d:\Program Files (x86)\SogouInput\...错误
- FLTK--轻量级C++跨平台GUI库
- esp8266_deauther将html压缩成字节码
- 从零配置专属neovim - 1.配置设计概述
- 以计件积分为纽带-探索客户中心团队再造模式
- 【python量化】将Transformer模型用于股票价格预测
- 链表结点的物理顺序与逻辑顺序
- 徐家福对计算机科学发展的影响或作用,徐家福先生的两句话
- 小册上新 | 掌握 SpringBoot 场景整合，成为开发多面手！
- 基于Linux的Spark安装与环境配置
- 11 个非常实用的 Python 和 Shell 拿来就用脚本实例！