网络原理-TCP/IP(1)

「爱情、让人受尽委屈。」 2024-04-06 15:14 49阅读 0赞

## 应用层 ##

我们之前编写完了基本的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)标识了一个主机上进行通信的不同的应用程序;

![298bda7cbe18463fb130c40193e2227d.png][]

在TCP/IP协议中,用"源IP","源端口号","目的IP","目的端口号","协议号"这样一个五元组来表识一个通信.

#### ![29313c3dae3a402d8fb69a6950422bee.png][] ####

#### 端口号范围划分 ####

> 0-1023:知名端口号:HTTP,FTP,SSH等这些广为使用的应用层协议,他们的端口号都是固定的.
> 
> 1024-65535:操作系统动态分配的端口号.客户端程序的端口号,就是由操作系统从这个范围中分配的.

#### **认识知名的端口号** ####

有些服务器是非常常用的,为了使用方便,人们约定一些常用的服务器,都是用以下固定的端口号:

> ssh服务器,使用22端口
> 
> ftp服务器,使用21端口
> 
> telnet服务器,使用23端口
> 
> http服务器,使用80端口
> 
> https服务器,使用443

我们自己写一个程序使用端口号时,要避开这些知名端口号.

### UDP协议 ###

#### UDP协议端格式 ####

我们知道,研究一个协议,主要就是研究报文格式,基于报文格式,了解这个协议其它各个属性.

UDP = 报头(重点) + 载荷(应用层数据包).

![b12c3b9d69904d12ab6e197372fa16a1.png][]

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程序时自定义的应用层协议.

[298bda7cbe18463fb130c40193e2227d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/c683c73db98f40449d6a153b9c3717e3.png
[29313c3dae3a402d8fb69a6950422bee.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/5dcc3f1fd1264a958ccc27bc55ac70a9.png
[b12c3b9d69904d12ab6e197372fa16a1.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/06/7f7618fbf7204f6083b27c96d8ab3842.png