网站制作后还能更改么谷歌seo排名优化服务
应用层
我们之前编写完了基本的java socket, 要知道,我们之前所写的所有代码都在应用层中,都是为了完成某项业务,如翻译等.关于应用层,后面会有专门的讲解,在此处先讲一下基础知识.
应用层对应着应用程序,是程序员打交道最多的一层,调用系统提供的网络api写出的代码都是应用层的.
应用层这里虽然有很多协议,但程序员应该按照场景,自定义协议.(网络传输的数据要怎么用,也要考虑数据是什么格式,里面包含哪些内容).
自定义协议约定:1.服务器,客户端要交互哪些信息
2.数据具体格式(网络上是字符串/二进制比特流).
客户端按照上述约定发送请求,服务器按照上述约定解析请求.
服务器按照上述约定构造响应,客户端也按照上述约定解析响应.
举个例子:点餐软件
打开点餐软件,显示出主页.主页里就要显示出商家列表,而且这些商家都是附近的(打开软件的时候,就需要把你的位置告诉服务器).显示的商家列表中,也会包含一些信息:如商家名称,图片,商家的评分,商家的简介等.(交互过程中需要传输哪些信息,并不是程序员规定的,而是产品经理规定)
而这里的数据格式组织,就有了固定的套路,属于程序员的事情.
客户端和服务器之间往往要交互的是"结构化数据"(一个结构体/类:包含很多属性).
网络传输的数据其实是"字符串","二进制比特流".
约定协议的过程,就是把结构化数据转成字符串/二进制比特流的过程.
把结构化的数据,转成字符串/二进制比特流这个操作,称为"序列化".
把字符串/二进制比特流还原成结构化数据,这个操作,称为"反序列化".
序列化/反序列化具体要组织成什么样的格式,这里包含哪些信息.
约定这两件事的过程就是自定义协议的过程.
为了让程序员简单约定这里的协议格式,这里有几个供参考的方案.
xml, json, protobuffer
这里就简单一下json,其它的如果有兴趣的话可以自行了解.
json是当今非常主流,非常常用的数据组织格式了,举个例子如下:
请求:
{
userId: 1000,
position: [经纬度]
}
响应:
[
{
id: 1001,
name: "老八秘制小汉堡"
},
{
id: 1002,
name: "初饮味来"
}
]
解释:主要用到的是键值对格式. 键和值之间用 : 分割. 键值对之间用 , 分割
把若干个键值对使用{ }括起来,此时就形成了一个json对象.
还可以把多个json对象放到一起,使用 , 分割开, 并且使用[ ]整体括起来.
特性:可读性很好,扩展性也很好,通过key来对数据起到解释说明的作用.
对于xml来说解释说明是通过标签,需要有开始和结束两个标签,比较占用空间.相比之下json只使用一个key就能描述,占用的空间就比xml更少,更节省带宽了.
虽然json比xml是节省了带宽但是很明显,当前这里的带宽仍是有浪费的部分.
尤其是这种数组格式的json,这种情况下往往传输的数据字段都是相同的.使刚才这里的key名字被重复传输了.
传输层
负责数据能够从发送端到接收端.
这一层是系统内核实现好了的,提供socket的api供程序员使用.
再谈端口号
端口号(port)标识了一个主机上进行通信的不同的应用程序;
在TCP/IP协议中,用"源IP","源端口号","目的IP","目的端口号","协议号"这样一个五元组来表识一个通信.
端口号范围划分
0-1023:知名端口号:HTTP,FTP,SSH等这些广为使用的应用层协议,他们的端口号都是固定的.
1024-65535:操作系统动态分配的端口号.客户端程序的端口号,就是由操作系统从这个范围中分配的.
认识知名的端口号
有些服务器是非常常用的,为了使用方便,人们约定一些常用的服务器,都是用以下固定的端口号:
ssh服务器,使用22端口
ftp服务器,使用21端口
telnet服务器,使用23端口
http服务器,使用80端口
https服务器,使用443
我们自己写一个程序使用端口号时,要避开这些知名端口号.
UDP协议
UDP协议端格式
我们知道,研究一个协议,主要就是研究报文格式,基于报文格式,了解这个协议其它各个属性.
UDP = 报头(重点) + 载荷(应用层数据包).
UDP报头中一共有4个字段,每个字段两个字节(一共八个字节),由于协议报头中使用两个字节表示端口号,端口号范围是: 0 ~ 65535. (这里的最大值是64kb),一旦数据超过64kb就会被截断.
16位UDP长度, 表示整个数据报(UDP首部 + UDP数据)的最大长度;
如果校验和出错,直接丢弃.
下面来讲解一下校验和:
校验和起到的效果,就是去尝试检查当前的数据是否存在问题.是否出现了比特翻转(网络中的校验和并非是简单的按照长度/数量作为校验标准的,一定是能让数据加入进去),就可以把错误的数据包丢掉.
简单讲一下校验的方法:
1.CRC算法完成校验(循环冗余校验):
比如要产生一个两个字节的校验和.
short checksum = 0;
for(循环遍历取出数据报中每个字节的数据) {
checksum += 当前字节的数据;
}
加的过程,也有可能会溢出,这里也不用管.
UDP数据报发送方,在发送之前,先计算一遍CRC,把算好的CRC值放到UDP数据报中.(设这个CRC值为value1). 接下来这个数据包通过网络传输到接收端.接收端收到这个数据之后,也会按照同样的算法,再算一遍CRC的值,得到的结果是value2.比较自己计算的value2和收到的value1是否一致.如果是一致的,就说明数据ok,如果不一致,传输过程中就发生了比特翻转了.
上述CRC算法中,如果只有一个bit位发生翻转,能够100%发现问题,但如果有两个/多个bit位发生翻转,有可能恰好校验和和之前一样.
虽然这种概率比较低,可以忽略不计,但是要想有更高的精确度,就需要其它算法了.
除了CRC,还有精度更高的md5/sha1算法.
其中md5就涉及到一系列更加复杂的数学公式了.
介绍一下MD5算法的特点:
1.定长:无论数据有多长,算出来的md5最终值为固定长度.
2.分散:计算md5时,原始数据变化一点点,计算的md5差异就会很大,(这种特性,决定md5可作为字符串的hash算法).
3.不可逆:给一个源字符串,计算md5值很简单,但要想将md5值还原为字符串,几乎无法实现.
UDP特点
UDP传输过程类似于寄信.
1.无连接:知道对端的IP和端口号就可以直接传输,不需要建立连接.
2.不可靠:没有确认机制,没有重传机制;如果因为网络故障无法发送到对方,UDP协议层也不会给应用层返回任何错误信息;
3.面向数据报:不能够灵活的控制读写数据的次数和数量.
面向数据报
应用层交给UDP多长的报文,UDP原样发送,既不会拆分,也不会合并;
用UDP传输100个字节的数据.
如果发送端调用一次sendto,发送100字节,那么接收端也必须调用对应的一次recvfrom,接收100个字节;而不能循环调用10次recvfrom,每次接收10个字节.
基于UDP的应用层协议
NFS:网络文件系统,
TFTP:简单文件传输协议
DHCP:动态主机配置协议
BOOTP:启动协议(用于无盘设备启动)
DNS:域名解析协议.
当然,也包括你写的UDP程序时自定义的应用层协议.