网络原理(1)—

一、应用层

举个例子：点外卖

约定数据格式简单粗暴的例子

客户端和服务器的交互：

序列化和返序列化

xml、json、protobuffer

1、xml

2、json

3、protobuffer

二、传输层

端口

端口号范围划分

认识知名的端口号

三、UDP协议

端口

UDP长度

UDP校验和

UDP特点

面向数据报

UDP使用注意事项

基于UDP的应用层协议

一、应用层

我们之前编写完了基本的 java socket，要知道，我们之前所写的所有代码都在应用层中，都是为了完成某项业务，如翻译等。关于应用层,后面会有专门的讲解，在此处先讲一下基础知识。

应用层对应着应用程序，程序员打交道最多的就是这一层，调用系统提供的网络api 写出的代码都是属于应用层的。

应用层这里当然也有很多现成的协议，但更多的，程序员需要根据实际场景，自定义协议：网络传输的数据要怎么使用，也要考虑数据是什么样的格式，里面包含了哪些内容。

而协议就是一种约定，虽然存在很多现有的协议（一般都是大佬们已经搞好了的），但除此之外，咋们程序员也可以自己来约定协议。

自定义协议，要约定好两方面内容，如下：

1、服务器和客户端之间要交互哪些信息

2、数据的具体格式

客户端按照上述约定发送请求，服务器按照上述约定解析请求。

服务器按照上述约定构造响应，客户端也按照上述约定解析响应。

举个例子：点外卖

打开点餐软件，显示出页面，页面里就会显示出商家列表，而这些商家都是在你附近的（打开软件的时候，就会把你的位置告诉给点餐软件的服务器）

显示的商家列表，也会包含一些信息，商家的名称、图片、商家的评分、商家的简介等等

以上交互过程中需要传输哪些信息，并不是程序员规定的，而是产品经理规定的。要交互哪些信息，一方面是产品经理约定的，一方面是程序员补充的，这些都要根据实际的场景来确定。

上述的数据按照啥样的格式来组织，就是有一些固定套路；而数据格式如何组织，和产品经理无关，属于程序员自己的事情，往往需要客户端的程序员和服务器的程序员，这两伙人坐在一起，共同把这个事给敲定下来。（这里的格式怎么约定都行，只要这两伙程序员达成共识即可）

约定数据格式简单粗暴的例子

1、请求：约定使用行文本的格式来表示

userId，position \n （一个请求以 \n 为结尾，多个字段之间使用，用来分割）

1000，[经纬度] \n

2、响应：也是使用文本行来表示，一个响应中可能会包含多个商家；每个商家占一行，每个商家要返回 id、名称、图片、评分、简介。

1001，杨国福，[logo图片地址]，4.8，非常好吃的麻辣烫 \n

1002，魏家凉皮，[logo图片地址]，4.7，很好吃的凉皮

.......

若干行的最后，使用空行作为所有数据的结束标记

(上面的这一系列内容是同一个响应中的数据)

上述的例子里，约定的这个格式太过于简单粗暴了，虽然能解决问题，但实战中，很少真的会这么约定，这样的约定，不太适合拓展，可读性也不高。

客户端和服务器的交互：

客户端和服务器之间往往要进行交互的是 “结构化数据”（数据是还有个结构体 / 类，包含很多个属性），而网络传输的数据其实是 “字符串” “二进制 bit 流”。

协议约定的过程，就是把结构化数据转成字符串 / 二进制比特流的过程。

序列化和返序列化

把结构化数据，转成字符串 / 二进制比特流，这个操作称为 序列化。

把字符串 / 二进制比特流还原成结构化数据，这操作称为 反序列化。

序列化 / 反序列化具体要组织成什么样的格式，这里包含哪些信息，约定这两件事的过程就是自定义协议的过程。

xml、json、protobuffer

为了让程序员更方便的去约定这里的协议格式，业界也给出了几个比较好用的方案，可以直接套进来（xml、json、protobuffer等待）

1、xml

大概模型如下：

可读性和扩展性都提升很多，标签的名字可以对数据起到描述的效果，后续要增加一些属性，就新增一个标签即可，对于已有的代码影响不大，代码中按照标签名字获取到标签的值，新增新的标签对于已有代码都没啥影响。

缺点：整个数据，冗余信息非常多，标签（描述性信息）占据的空间反而比数据本身更多，尤其是网络传输的时候，这些数据都要通过网络传输的（消耗带宽），而国内最贵的硬件资源，就是网络带宽。

当前存在大量的库可以方便我们解析处理 xml 格式的数据，通过这些库就可以使用 xml 来进行数据的组织和传输，保存。

2、json

非常主流 / 非常常用的数据组织格式，大概模型如下：

键值对结构，键和值之间的使用：分割，简直对的使用，进行分割

把若干个键值对使用 { } 括起来，此时就形成了一个 json 对象，还可以把多个 json 对象放到一起使用，分隔开，并且使用 [ ] 整体括起来，就形成了 json 数组。

json的可读性很好，扩展性也很好，通过 key 来对数据起到解释寿命，对于 xml 来说，解释说明通过标签，需要有开始和结束两个标签，比较占用空间。相比之下，json值使用一个key就能描述，，占用空间比xml更少，就更节省带宽了。

虽然 json 比 xml 节省了带宽，但是很明显，当前这里的带宽仍然是有浪费的部分；尤其是这种数组格式的 json，这种情况下往往传输的数据字段都是相同的，使刚才这里的key名字被重复传输了。

3、protobuffer

更节省带宽的，效率最高的方式

只是开发阶段（代码）定义出这里都有哪些资源，描述每个字段的含义。程序真正运行的时候，实际传输的数据是不包含这样的描述信息。而这样的数据是按照二进制的方式来组织的。

因为数据是按二进制的方式传输的，所以这样的设定，是最高效的做法，程序运行的效率高，但并不有利于程序员阅读。

虽然 protobuffer 运行效率更高，但是使用的并没有 json 更广泛。只是那些对于性能要求非常高的场景，才会使用 protobuffer。应用层也有很多现成的协议，比如 HTTP 这种，HTTP 协议非常重要，独立成章节。

二、传输层

负责数据能够从发送端到接收端。这一层是系统内核实现好了的，提供socket的api供程序员使用。

端口

端口号：端口号是一个 2 个字节的整数，使用端口号的时候，1~1024 都属于系统保留自用的端口（知名端口号）。

端口号(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 个字段，每个字段 2 个字节（一共 8 个字节）

16位UDP长度，表示整个数据报(UDP首部 + UDP数据)的最大长度。

如果校验和出错，直接丢弃。

端口

由于协议报头使用 2 个字节表示端口号，端口号的取值范围就是：0 ~ 65535（最大值是64K）。

UDP长度

因此，一个 UDP 数据报最大长度就是 64K，无法更长了，整个数据报的长度超出 64 K，此时就可能导致数据出现截断（本来数据是完整的，后面的部分没了）。

总的 UDP 数据报最大长度是 64 K，载荷部分实际能承担的最大长度，应该是 64K - 8；但是 64K - 8 约等于 64K，使用语言表述的时候，会采取约数的这种近似值。

UDP校验和

校验和的作用就是用来识别当前的数据是否出现比特翻转，是否是正确的数据。

验证数据在传输过程中是否正确。因为数据在网络传输过程中，可能会坏掉。

网络数据传输，本质上是光信号 / 电信号 / 电磁波，因此，在传输过程中就可能会收到干扰

外界有形形色色的电磁波，传输数据时，是使用高电平低电平表示 0 1，这时，外界如果加上一个磁场，就可能把其中低电平变成高电平；此时，出现 0 -> 1 或者 1 -> 0，这种情况，这种情况称为：比特翻转。

像十几年前的时候，如果出现太阳黑子 / 太阳耀斑，就会引起地球上的通信中断；现代的传输体系，其实有一系列的保护机制，减少外界的干扰；现在的技术更加发达、成熟，不太害怕这些影响，影响还是有的，只不过少很多了。

在 UDP 中，校验和使用比较简单的方式：CRC算法来完成校验，循环冗余校验。

UDP 数据报发送方，在发送之前，会先计算一遍 CRC，把算好的 CRC 值放到 UDP 数据报中（设这个 CRC 值为 value1）。接下来这个数据报通过网络传输到达接收端，接收单收到这个数据之后，也会按照同样的算法，再计算一遍 CRC 的值，得到的结果是 value2，比较自己计算的 value2 和收到的 value1 是否一致，如果是一致，就说明数据是ok的，如果不一致，传输过程就发生了比特翻转了。

上述 CRC 算法中，如果只有一个 bit 位发生翻转，此时 100% 能够发现问题。如果有两个 / 多个比特位发生翻转，校验和有可能恰好和之前的一样（这种情况概率比较低，可以忽略不计，如果希望这里有更高的检查精度，就需要使用其他的更严格的校验和算法了）。

所以，严格的来说，校验和只能用来 “证伪”，证明数据是出错了，无法确保这个数据 100% 正确，但时间中可以近似的人为校验和一致，原来的数据就是一致的。

除 CRC 算法外，还有一些更高精度的校验和算法。业界还有其他常用的算法：md5 算法 / sha 1算法。如图：

UDP特点

UDP传输过程类似于寄信。

1.无连接：知道对端的IP和端口号就可以直接传输，不需要建立连接。

2.不可靠：没有确认机制，没有重传机制；如果因为网络故障无法发送到对方，UDP协议层也不会给应用层返回任何错误信息。

3.面向数据报：不能够灵活的控制读写数据的次数和数量。

4、全双工

面向数据报

应用层交给UDP多长的报文，UDP原样发送，既不会拆分，也不会合并。

用UDP传输100个字节的数据。

如果发送端调用一次sendto，发送100字节，那么接收端也必须调用对应的一次recvfrom，接收100个字节；而不能循环调用10次recvfrom，每次接收10个字节。

UDP使用注意事项

        我们注意到,UDP协议首部中有⼀个16位的最大长度。也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部)。
        然而64K在当今的互联网环境下，是⼀个非常小的数字。
        如果我们需要传输的数据超过64K,就需要在应用层手动的分包,多次发送,并在接收端手动拼装。