最近半年都是在对接协议，可能是心态问题，这个协议真的是不想看，一大串的数字，乱七八糟的文档，无从下手的项目；
还好，最终的结果是需要接入的都接入了，什么国标，企标，tcp，udp，mqttt。 好久就想写一片文章来总结下，协议，到底是个什么鬼东西！
百度百科： 协议：* 网络协议的简称，网络协议是通信计算机双方必须共同遵从的一组约定。如怎么样建立连接、怎么样互相识别等。只有遵守这个约定，计算机之间才能相互通信交流。它的三要素是：语法、语义、时序。* 中间几个关键词，共同遵守，约定。通俗的来讲就是规则，斗地主的规则，麻将的规则，国标就是国家规定的打麻将的规则，企标就是企业规定的打麻将的规则。一起打麻将的人要一起遵守，才有的玩，要是有人不认。估计得挨揍。 网络层协议，tcp udp, 应用层协议，http，ftp 这里所说的网络层和应用层来自于计算机网络的五层协议： 
除去下面的链路层和物理层，tcp 和 udp 应该属于应用协议的最底层了。而 http 和 ftp 这些协议都是基于 tcp 和 udp 的封装的应用层协议； TCP：首先，tcp 是一种可靠的协议，很多人都听过三次握手，什么是三次握手，上图 这里面可靠性的点就是这个 ack（消息应答）多了一次应答，所以多了两次连接，总共三次动作，成为三次握手。 四次挥手
假设 Client 端发起中断连接请求，也就是发送 FIN 报文。Server 端接到 FIN 报文后，意思是说 “我 Client 端没有数据要发给你了”，但是如果你还有数据没有发送完成，则不必急着关闭 Socket，可以继续发送数据。所以你先发送 ACK，“告诉 Client 端，你的请求我收到了，但是我还没准备好，请继续你等我的消息”。这个时候 Client 端就进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文，“告诉 Client 端，好了，我这边数据发完了，准备好关闭连接了”。Client 端收到 FIN 报文后，“就知道可以关闭连接了，但是他还是不相信网络，怕 Server 端不知道要关闭，所以发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。“，Server 端收到 ACK 后，” 就知道可以断开连接了 "。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭，那好，我 Client 端也可以关闭连接了。Ok，TCP 连接就这样关闭了！
断包，粘包，丢包
断包，粘包的问题出现的原因 参考了这么多的文章，感觉自己的程序出现断包的原因应该是缓冲区的问题，如果一个 tcp 的发送的报文在 1460 字节以内，断包的出现大部分原因是出现自己的程序里面。因为以太网中存在一个对于帧的有效数据大小的限制，即 MTU，以太网的 MTU 为 1500 字节。 ip 首部有 20 字节，tcp 首部有 20 字节（udp 首部 8 字节），所以除了网络因素，造成断包的原因还是出在自己的程序里面。（还有就是一种就是传输的速率太快）
http
来源：CSDN
作者：JJiaper
链接：https://blog.csdn.net/pengxiaojia9516/article/details/103986657