互联网中,主流的是 TCP/IP 五层协议
日常开发中最常用到的一层:
HTTP
协议就是约定
自定义应用层协议,具体要做什么事情:
举个例子:开发一个外卖软件,打开软件后,首先需要展示一个“商家列表”
此处就需要先确定传递的信息是什么
请求:用户是谁(用户的 ID),用户所处的位置
响应:商家列表,包含多个商家,每个商家信息中,又有商家的名字、图片、距离、评分
这里的信息如何确定,都是根据当前的需求来产生的
举个例子:使用行文本的方式来组织上述数据
请求:
用户id,用户位置\n
响应:
商家的id,商家名称,商家的图片地址,商家的距离,商家的评分\n
关于组织数据的格式,还有一些说法,上述“行文本”简单粗暴的方案,在实际开发中,很少会这样做
Maven 中就会见到,通过“成对的标签”表示“键值对”信息
<request>
<userid>1001</userid>
<postion>E45N60</postion>
</request>
XML
来传输网络数据,也可以作为程序的配置文件XML
进行网络传输的时候,又有一个明显的缺点——会消耗大量的带宽
- 网络通信中,带宽是一个非常贵的硬件设备
- 在传输标签的时候,都得传输成对的标签,传入的信息更多XMl
一般都是在配置文件,不进行网络传输了XMl
里面的标签(键值对)都是程序员固定的,而 HTMl
里面的标签都是固定的(已经有一套标准,约定好哪些标签是合法标签,这些标签都是什么含义)当前主流的网络通信的数据格式,相比 xml
来说,可读性是很好的,同时能节省一定的带宽
{
"userid":1001,
"postion":""E45N60"
}
JSON
也是“键值对”格式,
- 键和值之间用 :
分割
- 键值对之间用 ,
分割
- 所有的键值对,都使用 {}
括起来强制要求了数据组织的格式,强制要求写成“可读性非常高”的格式
前三个方案,都是关注可读性,而 protobuffer 关注性能,牺牲了可读性(通过二进制的方式组织数据)
端口号是一个整数,用来区分不同的进程。
什么时候会涉及到一个进程(服务器)绑定多个端口?
当需要针对服务器运行状态进行检测和调试,需要查看服务器运行中某个关键变量的数值的时候,千万不能用调试器来进行调试,一旦使用调试器调试这个服务,就会使服务器的一些线程被阻塞住,无法给客户端正确提供服务了
客户端连上服务器之后,一个连接中,会发起多次请求,接收多个响应
客户端连上服务器之后,一个连接只发一个请求,然后就断开连接了
学习一个网络协议,主要就是学习“数据格式”/“报文格式”
端口号是属于传输层的概念
UDP 报头使用两个自己的长度来表示端口号
之所以端口号的范围是 0~65535,是因为底层网络协议做出了强制要求
如果使用一个 10 w 这样的端口,就会在系统底层被“截断”
UDP报文长度:报头长度 + 载荷长度
UDP 用了好多年,一直挺好用,但随着业务的发展,广告越来越多,越来越复杂,导致一个网络响应数据报的体积越来越大,逐渐逼近 64 KB。一旦数据超过了 64 KB,就可能到值数据被截断,这样广告可能就无法正常显示了。对于这样的情况,有两个解决方案:
前提:网络传输过程中,非常容易出现错误
校验和存在的目的,就是为了能够“发现”或者“纠正”这里的错误。就可以给传输的数据中,引入“额外信息”,用来发现/纠正传输数据的错误
checksum
举个例子:你妈让你去买菜,西红柿、鸡蛋、茄子、晃过,最后补充一句“一共四样”
这里的“一共四样”起到的作用就相当于是“校验和”。通过“一共四样”你可以对手里的菜进行检查,有没有买多、买少
但这样的“校验和”并不能准确的识别出问题,而且容易误判。所以我们希望校验和可以更严格地检查数据的内容,可以结合内容/内容的片段来生成校验和
比如你在默写金庸先生的十五部作品的名称,写完后,你可以通过“飞雪连天射白鹿,笑书神侠倚碧鸳”这一幅对联和你写的书名的第一个字对一下,若能对象,就说名此处的名字都是正确的
这样的校验和就是基于内容来进行校验的
把 UDP 数据报整个数据都进行遍历,分别取出每个字节,往一个两个字节的变量上进行累加
UDP
数据报UDP
数据,基于这些数据,计算得到一个 checksum1
checksum1
- 接收方就可以根据数据的内容,按照同样的算法,再算一遍校验和,得到 checksum2
checksum1 == checksum2
本质上是一个“字符串 hash 算法”
特点:
MD5
的结果都是固定长度——>适合做校验和算法MD5
的值都会相差很大——>适合做 hash 算法MD5
非常简单,但是如果想通过 MD5
值还原出原始的内容,理论上是不可行——>适合作为加密算法原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。