-- Socket读写数据：流Socket，数据包Socket。？
1.流套接字（SOCK_STREAM）：流套接字用于提供面向连接、可靠的数据传输服务。该服务将保证数据能够实现无差错、无重复发送，并按顺序接收。流套接字之所以能够实现可靠的数据服务，原因在于其使用了传输控制协议，即TCP（The Transmission Control Protocol）协议。
2.数据报套接字（SOCK_DGRAM）：数据报套接字提供了一种无连接的服务。该服务并不能保证数据传输的可靠性，数据有可能在传输过程中丢失或出现数据重复，且无法保证顺序地接收到数据。数据报套接字使用UDP（User Datagram Protocol）协议进行数据的传输。由于数据包套接字不能保证数据传输的可靠性，对于有可能出现的数据丢失情况，需要在程序中做相应的处理。
3.原始套接字(SOCK_RAW)：原始套接字与标准套接字（标准套接字指的是前面介绍的流套接字和数据报套接字）的区别在于：原始套接字可以读写内核没有处理的IP数据包，而流套接字只能读取TCP协议的数据，数据报套接字只能读取UDP协议的数据。因此，如果要访问其他协议发送数据必须使用原始套接字。
-- Socket类型，名字/常量 描述
SOCK_STREAM 这个协议是按照顺序的、可靠的、数据完整的基于字节流的连接。这是一个使用最多的socket类型，这个 socket是使用TCP来进行传输。
SOCK_DGRAM 这个协议是无连接的、固定长度的传输调用。该协议是不可靠的，使用UDP来进行它的连接。
SOCK_SEQPACKET 这个协议是双线路的、可靠的连接，发送固定长度的数据包进行传输。必须把这个包完整的接受才能进行读取。
SOCK_RAW 这个socket类型提供单一的网络访问，这个socket类型使用ICMP公共协议。（ping、traceroute使用该协议）
SOCK_RDM 这个类型是很少使用的，在大部分的操作系统上没有实现，它是提供给数据链路层使用，不保证数据包的顺序
socket接收数据长度设置记录：近期在项目中使用原先封装的socket库时发现当长度超过1024时，接收到的字符串会有“烫烫烫”的标志出现，之前有看过大神调侃的“烫烫烫屯屯屯”，直觉地想到应该是数组的长度部分设置有问题。检查代码发现，用于接收的buffer长度为1024，而在使用socket的recv函数中也将最大长度设置为了1024，同时将buffer中的数组拷贝出去的长度也为1024，因此该字符串中没有‘\0’的结束符，打印出来未初始化栈空间的值，也就出现了著名的"手持两把锟斤拷，口中疾呼烫烫烫。脚踏千朵屯屯屯，笑看万物锘锘锘"。将recv函数中最大长度设置为1023或者将buffer的长度改为1025即可解决，这样就也有结束符，也就不会出现上述现象了。
WebSocket连接本质上是TCP连接，不需要每次传输都带上重复的头部数据，所以它的数据传输量比轮询和Comet技术小 了很多。Comet技术又可以分为长轮询和流技术。
Android使用Socket分包下载字节流数据并生成文件- https://blog.csdn.net/S_Alics/article/details/81558075
任务要求：1、请求需要下载数据的总大小； 2、使用Socket从服务器分段下载字节流数据(byte[]数据)； 3、以byte[]的形式追加保存到.txt文件中。
- websocket协议,长连接；Http短连接
WebSocket如何建立连接、交换数据的细节，以及数据帧的格式。
WebSocket复用了HTTP的握手通道。具体指的是，客户端通过HTTP请求与WebSocket服务端协商升级协议。协议升级完成后，后续的数据交换则遵照WebSocket的协议。
websocket协议是基于tcp的网络协议，实现了浏览器与客户端的全双工通信,与http协议不同的是，它允许服务器主动推送消息给客户端。
websocket协议分为两部分，一是握手建立连接；二是数据传输。
建立连接：websocket的连接建立是基于http协议的。数据传输：websocket协议中数据是通过一系列的帧来传输。出于安全性考虑，所有客户端发往服务器的数据帧需要掩码，若服务器收到未掩码的数据帧将会主动断开连接；所有服务器发往客户端的数据帧不能掩码，若客户端收到掩码的数据帧将会主断开连接。
- Android 长连接,怎么处理心跳机制
维护任何一个长连接都需要心跳机制，客户端发送一个心跳给服务器，服务器给客户端一个心跳应答，这样就形成客户端服务器的一次完整的握手，这个握手是让双方都知道他们之间的连接是没有断开，客户端是在线的
如果超过一个时间的阈值，客户端没有收到服务器的应答，或者服务器没有收到客户端的心跳，那么对客户端来说则断开与服务器的连接重新建立一个连接，对服务器来说只要断开这个连接即可。
- (websocket)协议中Ping Pong，长连接
WebSocket为了保持客户端、服务端的实时双向通信，需要确保客户端、服务端之间的TCP通道保持连接没有断开。然而，对于长时间没有数据往来的连接，如果依旧长时间保持着，可能会浪费包括的连接资源。但不排除有些场景，客户端、服务端虽然长时间没有数据往来，但仍需要保持连接。这个时候，可以采用心跳来实现。
发送方->接收方：ping；
接收方->发送方：pong；
ping、pong的操作，对应的是WebSocket的两个控制帧，opcode分别是0x9、0xA。
websocket ping pong:目前的话，浏览器中没有相关api发送ping给服务器，只能由服务器发ping给浏览器，浏览器返回pong消息；
WebSocket控制帧有3种：Close(关闭帧)、Ping以及Pong。控制帧的操作码定义了0x08(关闭帧)、0x09(Ping帧)、0x0A(Pong帧)。Close关闭帧很容易理解，客户端如果接受到了就关闭连接，客户端也可以发送关闭帧给服务端。Ping和Pong是websocket里的心跳，用来保证客户端是在线的，一般来说只有服务端给客户端发送Ping，然后客户端发送Pong来回应，表明自己仍然在线。
WebSocket协议深入探究-https://www.sohu.com/a/227600866_472869
OPCODE：4位 ， 解释PayloadData，如果接收到未知的opcode，接收端必须关闭连接。
0x0表示附加数据帧
0x1表示文本数据帧
0x2表示二进制数据帧
0x3-7暂时无定义，为以后的非控制帧保留
0x8表示连接关闭
0x9表示ping
0xA表示pong
0xB-F暂时无定义，为以后的控制帧保留
- WebSocket分包，粘包，连包，半包
网上很多资料都说WebSocket不会粘包，半包。OK，这是正确的，因为上述将数据帧的时候我们已经看到WebSocket会将大的数据，自动分片发送。所以WebSocket会自动分包发送，因为这种分包发送，WebSocket的数据不会溢出接收缓冲区，所以也不会有半包的情况发送。
但是关于粘包，和连包，我看到一部分资料都说不会。因为WebSocket具有帧头信息，所以不会粘包？这是不完全正确的，要知道Tcp的报文也是具有包头信息的，只不过Socket已经处理了。而且经过我对我们项目服务器实际压力测试，发现WebSocket会粘包，连包。不同的是，WebSocket的数据中拥有包头信息，但Tcp没有（实际开发中，我们自己一定会加个包头来分割封包的，WebSocket只是替我们设计了一个包头而已），但对这个包头分割的处理，还是要我们自己完成，WebSocket不会代劳，如果我们自己不处理，抱歉，妥妥的粘包，连包
Websocket协议原理与实现（一）- https://www.jianshu.com/p/1ee01218097b
A barebones WebSocket client and server implementation written in 100% Java- https://github.com/TooTallNate/Java-WebSocket
WebSocket协议详解及应用- https://blog.csdn.net/u014520745/article/details/52639452
WebSocket的ping与pong的java实现- https://blog.csdn.net/u010770993/article/details/70312279
- Socket通讯ping pong
做一个socket网络传输的项目，在使用TCP进行传输的时候，接收端有时候会因为写入到文件的时间而造成一定的延时，所以在接收端使用了ping-pong buffer的策略进行优化。
ping-pong机制- https://blog.csdn.net/chenyu201003/article/details/81449762
项目用到的Socket通讯ping pong流程图- https://blog.csdn.net/hufei20082008/article/details/53513918?utm_source=blogxgwz2
Socket默认是长链接，为了知道Client和Server链接是否正常，项目中使用的ClientSocket和ServerSocket都有一个心跳的线程，这个线程主要是为了检测Client和Server是否正常链接，Client和Server是否正常链接主要是用ping pong流程来保证的.
