应用层协议/传输层协议（UDP）

应用层

如何自定义应用层协议？

序列化方式

1.基于行文本的方式来传输

2.基于xml的方式

3.基于json的方式

4.yml的形式

5.protobuffer(pb)形式

传输层

端口号

协议

UDP

校验和

CRC

TCP

TCP/IP五层协议

应用层 -- 传输层 -- 网络层 -- 数据链路层 -- 物理层。

应用层

应用层和应用程序直接相关，是和程序员打交道最多的一层。

应用层协议里面描述的内容就是你写的程序，通过网络具体按照啥样的方式来传输数据，不同的应用程序就可以用不同的应用层协议。在实际开发中，很多时候需要自己去自定制应用层协议的。

自定义应用层协议，本质上就是对传输的数据做出约定：

1.约定传输的数据要有那些信息。

2.传输的数据要遵守什么样的格式。

如何自定义应用层协议？

1.确定传输信息

客户端发送请求，服务器响应数据。

比如开发一个外卖软件，用户发送请求：用户的id和所在位置，服务器返回响应：商家列表，商家名称，商家图片，商家评分简介等。

2.确定数据格式

上述的数据都属于”结构化数据“（通过结构体来表示的数据），网络上传输的是字符串（二进制字符串），就需要对数据进行序列化。

序列化方式

1.基于行文本的方式来传输

例如：

请求：用户id，位置信息

1234 180E40N

响应：商家名称，商家图片，商家评分

凉皮图片地址 9.2

这种格式属于自定义格式，包含的信息，分割符都可以灵活控制，只需要确保客户端和服务器使用同一套规则进行通信即可。但是这套规则的可维护性比较差，当属性多了的时候，看上去混乱。

2.基于xml的方式

一种经典的数据组织格式：

请求：

<request>

<userId>1234</userId>

<position>180E40N</position>

</request>

在使用maven使就是通过xml来配置管理的。

3.基于json的方式

使用{ }作为边界，里面是键值对，键值对之间，使用，进行分割,键和值之间使用：进行分割：

请求：

{

userId: 1234，

position: "180E40N"

}

可读性好，而且比xml更简洁。

4.yml的形式

属于缩进格式，通过缩进来表示包含/嵌套关系。xml通过标签来表示嵌套关系，yml通过缩进来表示的。并且对于缩进是强制要求的，可读性也很好，缩进不正确就会出错。

5.protobuffer(pb)形式

前面几种形式都是文本格式，肉眼可以看懂，pd则是二进制数据，肉眼看不懂。对于传输效率要求高的场景推荐使用这种方式，针对数据进行进一步的整理和压缩，虽然可读性不好，但是能够把空间最充分的利用，最节省网络宽带，效率也最高。

传输层

socket api都是由传输层协议提供的，操作系统内核实现。

端口号

端口号就是传输层提供的概念，用来寻找主机上的应用程序。端口号是一个整数，使用两个字节表示的无符号整数：0 -> 65535,其中，小于1024的端口号称为知名端口号，把这些端口号分配给一些比较知名的服务器程序作为这些服务器的“默认端口号”，自己写的服务器程序要避免知名端口号。

同一个机器上，同一时刻，端口号不能重复被绑定。可以使用 netstat 命令查看当前主机上是否有使用9090端口的进程，打开终端，输入命令：

9090端口号没有被使用，8080端口号被使用。两个进程不能同时绑定一个端口号。

协议

UDP: 无连接，不可靠传输，面向数据报，全双工

TCP:有连接，可靠传输，面向字节流，全双工

UDP

应用层数据到达UDP之后，就会给应用层数据报前面拼装上UDP报头。

UDP数据报 = UDP报头(8字节) + UDP载荷

一个UDP数据报，，最长就是64kb，UDP长度就描述了整个UDP数据报占多少个字节，通过UDP长度就能知道当前载荷一共是多少字节。如果使用UDP开发程序，就会有很大的限制，要确单个数据报在传输时不能超过64KB。

校验和

数据在网络传输中是可能会”出错“的。如比特翻转：

传输数据时是传输的二进制数，假设传输的是 0，但是实际到达对端却变成了 1。

这是因为数据在传输过程中变为电信号/光信号/电磁波的形式，可能受到外界干扰。比如电信号，在电信号中使用 0 表示高电平，使用 1 表示低电平，此时如果在传输过程中，遇到一个变化的磁场，就会把原来的高电平/低电平变为低电平/高电平，这就需要能够对传输的数据进行校验。UDP就使用CRC的方式来对错误信息进行校验。

校验和是数据引入冗余信息，通过冗余信息来验证原有的数据。就是拿着数据一部分进行一系列计算，得到的结果，如果数据发生变化，此时得到的结果也不一样。