【计算机网络原理】浅谈应用层协议的自定义和传输层UDP协议的总结

˃͈꒵˂͈꒱ write in front ꒰˃͈꒵˂͈꒱
ʕ̯•͡˔•̯᷅ʔ大家好，我是xiaoxie.希望你看完之后,有不足之处请多多谅解，让我们一起共同进步૮₍❀ᴗ͈ . ᴗ͈ აxiaoxieʕ̯•͡˔•̯᷅ʔ—CSDN博客
本文由xiaoxieʕ̯•͡˔•̯᷅ʔ 原创 CSDN 如需转载还请通知˶⍤⃝˶​
个人主页：xiaoxieʕ̯•͡˔•̯᷅ʔ—CSDN博客

系列专栏:xiaoxie的计算机网络学习系列专栏——CSDN博客●'ᴗ'σσணღ
我的目标:"团团等我💪( ◡̀_◡́ ҂)" 

( ⸝⸝⸝›ᴥ‹⸝⸝⸝ )欢迎各位→点赞👍 + 收藏⭐️ + 留言📝​+关注（互三必回）!

目录

​编辑 一.浅谈应用层协议

1.自定义应用层协议

1.场景假设

2.信息规定

3.数据格式

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

2.基于xml方式来传输

3.基于json的方式来传输

4.yaml的方式来传输数据

5.protobuffer(pb)的方式来传输数据

二.传输层协议总结1

1.传输层的作用

2.端口号.

1.端口号的特性

1端口号的范围

2. 使用命令行查看某个端口号是否被绑定

3.端口号在客服端和服务端的分配

4.多个进程是否能够绑定同一个端口号?

5.一个进程是否可以绑定多个端口号?

3.UDP协议

1.UDP的特点

2.UDP协议的格式

 3.源端口 vs 目的端口

4.UDP长度

5.校验和

6.应用场景

---

 一.浅谈应用层协议

我们可以从上图看到在TCP/ IP模型中,除了应用层是由我们来处理之外,其他层都是由操作系统来处理,虽然这样说并不代表其他层的工作原理和它们所使用协议不重要

原因包括：

• 故障排查：了解网络层次结构有助于在遇到网络问题时进行有效的故障排查。
• 性能优化：理解不同层次的协议如何工作可以帮助开发者优化应用程序的性能。
• 安全考虑：了解网络层次可以更好地设计安全措施，保护数据传输的安全。
• 协议设计：对于需要设计自定义协议的开发者，理解现有层次结构和协议是基础。
• 互操作性：了解不同层次的协议有助于确保应用程序能够与不同的系统和网络设备进行互操作

这里所以博主就先为大家先简单介绍一下应用层协议的几种格式类型,重点介绍一下其他层的协议之后,再重新重点详细的介绍应用层的原理和协议.

1.自定义应用层协议

1.场景假设

我们需要开发一个外卖软件,这个时候就需要 我们来自定义应用层协议,来传输信息了.其中自定义应用层协议就是我们要对传输的数据做出约定: 

1.传输的数据都有那些信息.

2.传输的信息都有遵守什么样的格式.

2.信息规定

这里的信息规定具体就是看你的业务需要,不同的业务需要传输的信息自然不同,这里并没有什么别的技巧,根据具体的业务来具体规定即可.我们根据这个外卖软件的场景,简单的规定一下需要传输什么信息.

1.请求: 用户id, 所在位置(这里只是举个例子)

2.响应:商家列表其中包含的元素:1.商家名称2.商家图片3,商家简介4.商家评价等等.

3.数据格式

上述的数据,都属于"结构化数据”(通过结构体来表示的数据)网络上传输的是字符串(二进制字符串),就需要对数据进行序列化.序列化的方式是有很多种的.

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

请求:用户ID,所在位置经纬度\n

例子: 123,123°18′\n

响应: 商家1名称,商家1图片,商家1简介,商家1评价;商家2名称,商家2图片,商家2简介,商家2评价\n

例子: 北京烤鸭,图片地址,北京烤鸭简介,北京烤鸭评价;海底捞,图片地址,海底捞评价,海底捞评价\n

上述格式就属于是一种自定义的格式.要包含哪些信息,分割符都使用哪个.…. 都是可以灵活的进行控制的只要确保, 客户端和服务器,使用同一套规则进行通信即可(非常重要)
上面这套规则,就属于是比较一般的的 可维护性比较差,特别是属性多了的时候,比较混乱.这种格式通常用于简化的通信场景，其中客户端和服务器之间的数据交换不需要复杂的结构

2.基于xml方式来传输

xml是通过成对的标签来组织数据的,是一种经典的数据组织格式,在十几二十年前是非常流行的,现在就比较少了,它和HTML的那个格式类似.

<result>

           <userID> 123</userID>

           <position>123°18′</position>

</result>

其中,标签的名称是啥,如何嵌套,都是可以自定义的,只要确保客户端和服务器都遵循相同的数据格式和标签定义，以保证数据的正确传输和解析.

虽然这套规则还是不够简洁高效,但它的结构性和自描述性使其在某些场景下仍然是一个不错的选择，特别是在需要高度结构化数据和元数据的情况下。

3.基于json的方式来传输

json是目前最流行,最广泛的轻量级数据交换格式。它易于人阅读和编写，同时也易于机器解析和生成

{

   userID:123,

   position:123°18′

}

使用{ }作为边界,{ }里面为键值对,键值对之间使用 , 来分割,键和值之间使用:来分割.

JSON的优点：

1. 轻量性：JSON格式简洁，没有XML那么冗长，通常比XML文件更小。

2. 易于阅读和编写：JSON的结构类似于编程语言中的结构，使得它易于人类阅读和编写。

3. 灵活的格式：JSON支持各种数据类型，包括字符串、数字、数组、对象（也称为字典或哈希表）、布尔值和null。

4. 与JavaScript的兼容性：JSON与JavaScript天然集成，可以直接被JavaScript解析为对象或序列化为字符串。

5. 跨语言支持：许多编程语言提供了原生的库来处理JSON，包括但不限于Python、Java、C#、Ruby等。

6. 自描述：JSON对象是键值对的集合，使得数据结构清晰且易于理解。

7. 不需要启动和结束标签：与XML不同，JSON不需要额外的开始和结束标签来标识文档。

8. 高效的数据交换：JSON通常用于APIs，因其高效性而成为RESTful Web服务中数据交换的首选格式。

JSON的应用场景：

1. Web API通信：作为客户端和服务器之间数据交换的标准格式。

2. 配置文件：存储应用程序的配置信息。

3. 数据存储：作为轻量级的数据存储格式，用于数据库或文件系统。

4. 消息队列：在消息传递系统中作为消息的格式。

5. 缓存：作为缓存数据的格式，因为它易于序列化和反序列化。

6. 前端开发：在网页开发中，JSON常用于与后端进行数据交换。

7. 微服务架构：在微服务架构中，服务之间通过JSON交换数据。

8. 移动应用开发：在移动应用中，JSON常用于客户端和服务器之间的通信。

9. 游戏开发：在游戏开发中，JSON用于存储游戏数据和配置。

10. 数据分析：在数据分析和机器学习中，JSON用于传输数据集或模型参数。

JSON的这些优点使其成为现代网络应用中数据交换的首选格式，尤其是在需要快速、高效和跨语言兼容的场景中。 同时注意确保客服端和服务端规则的统一.

4.yaml的方式来传输数据

基于缩进的格式来组织数据的

result

   userID:123

   position:123°18′

它是通过缩进来表示包含/嵌套关系的,而xml是通过标签来表示同时注意这个缩进是有讲究的

• 缩进：YAML严格使用空格进行缩进，通常是两个空格作为一级缩进，且不允许混用空格和制表符（Tab）。
• 一致性：整个文档的缩进必须保持一致，否则会导致解析错误。
• 空格敏感：除了缩进，YAML还对空格敏感，因此在键值对中使用空格需要特别注意。

YML的这些特性使其在需要高度可读性和结构化的配置文件或数据表示时非常适用。 

5.protobuffer(pb)的方式来传输数据

前面几种都是 文本格式，肉眼能看懂而 pb 是 二进制格式了,肉眼看不懂,博主这里也不好手搓出一个例子
pb 针对要传输的数据进一步的整理和压缩了虽然可读性不好,能够把空间最充分的利用,最节省网络带宽,效率也最高 .

Pb虽然在人机交互方面不如文本格式直观，但在机器之间传输数据时，其效率和性能优势非常明显。使用Pb时，首先需要定义数据结构的.proto文件，然后使用Pb工具生成相应语言的代码，之后就可以使用这些代码来序列化和反序列化数据。

由于Protobuf是二进制格式，确实无法直接提供一个手写的示例，但定义数据结构的.proto文件示例如下：

syntax = "proto3";
package example;message Result {int32 userID = 1;string position = 2;
}

在这个例子中，Result是一个消息类型，包含一个整型的userID字段和一个字符串类型的position字段。字段后面的数字（如1和2）是字段的标签，用于序列化时标识字段。

使用Protobuf时，需要通过编译.proto文件生成对应的序列化和反序列化代码，然后才能在程序中使用。

以上就是关于应用层协议的一点介绍,具体的内容,在博主总结完其余几层协议和原理之后,会对应用层协议重点介绍.

二.传输层协议总结1

这里解释一下由于TCP的内容比较复杂,所以这里就主要是对UDP协议的总结,博主将会在下一篇博客重点介绍TCP协议(这个非常非常重要,属于是面试必考,大学考试的话也必考).

1.传输层的作用

传输层是OSI（开放系统互联）七层模型和TCP/IP四层模型中的一个关键层次，它位于网络层之上，应用层之下。传输层的主要作用是提供进程间的通信服务，负责在网络中不同主机的应用程序之间建立、维护和终止通信连接

2.端口号.

传输层中有个非常重要的名词就是端口号,端口号是网络套接字（通常称为套接字地址）的一个组成部分，用于区分同一IP地址上运行的不同网络服务或进程。端口号(传输层)与IP地址(网络层)一起构成了一个唯一的网络端点，允许数据被正确地路由到正确的应用程序。

1.端口号的特性

1端口号的范围

端口号是一个16位数字,所以它的范围为 0 - 65535 其中，0到1023是众所周知的端口（也叫系统端口或特权端口），通常被系统或者常见服务和应用程序使用.所以当我们写自己的服务器系统的时候最好要避开这些端口号.

2. 使用命令行查看某个端口号是否被绑定

同一台机器上,同一时刻,端口号不能被重复绑定,例如如果在一台机器上进程A绑定了端口号8023,进程B也尝试绑定端口号8023,就会绑定失败.那我们该如何确定某个端口号被进程绑定了呢.

Windows 

netstat -ano | findstr [端口号]

Linux

netstat -tuln | grep [端口号]

这里以Windows举例 

 就可以看到某个端口号是否被绑定

3.端口号在客服端和服务端的分配

客户端通常在动态分配的端口号（临时端口，通常在1024到65535之间）上发起通信，而服务器监听在固定的端口号上。

4.多个进程是否能够绑定同一个端口号?

前文提到虽然同一台机器上,同一时刻,端口号不能被重复绑定,但是操作系统允许TCP和UDP套接字绑定到同一个端口，因为它们在协议层面上是独立的，并且可以共存而不相互干扰。当然可以使用是可以使用,但是尽量避免使用,毕竟端口号多着呢.你就算是服务器系统也不可能同时启动六万多个进程.这有助于提高系统的清晰性、安全性和性能，并减少潜在的冲突和混淆.

5.一个进程是否可以绑定多个端口号?

在实际应用中，一个进程绑定多个端口是常见的，尤其是在提供多种服务或需要处理大量并发连接的服务器上,每个服务绑定到不同的端口号。并且也非常推荐使用.

举个栗子

比如写一个服务器程序,首先服务器需要有一个端口号,给客户端提供业务功能,这样的端口,称为“业务端口” 给普通用户用的
程序猿还需要能够对这个服务器进行更精细的控制.
比如控制让这个服务器重新加载配置/开启某个功能/重新启动/重新加载数据/修改某个选项设定...
这样的操作,经常会通过网络来进行操作,服务器就会另外绑定一个端口号,称为"管理端口"

程序员想对这个服务器进行管理操作,就通过管理端口给服务器发送一些对应的请求,服务器执行对应的逻辑
给程序猿+运营人员例如搞个后门,给指定用户的账户余额增加 1000.这样的操作势必要通过管理端口不能通过业务端口(万一被玩家发现了!
日常开发会遇到一些 bug,需要去査看服务器的一些运行状态 (比如服务器中的一些关键的变量是啥样的值...服务器不能直接用 就需要调试器 去调试(调试器一调试就会把服务器阻塞住,无法给别的客户端提供服务了)也会通过网络的方式,给服务器发调试请求,服务器返回对应的关键信息,称为"调试端口"

还有一些其他的方面这里就不多举例,总之这种一个进程绑定多个端口是一种常见的做法，它提供了灵活性和安全性，有助于构建可维护和可扩展的服务器应用程序。

3.UDP协议

UDP协议比较简单,这里就简单介绍

1.UDP的特点

1.无连接

UDP是一种无连接的协议，这意味着在数据传输之前，发送方和接收方之间不需要建立和维护一个连续的连接。发送端可以直接向接收端发送数据报，而无需事先通知或握手。这简化了通信流程，减少了延迟，但也意味着发送方不知道数据是否成功到达目的地。

2.不可靠传输

UDP不提供像TCP那样的数据包确认、重传机制或错误恢复服务。数据报可能会在网络中丢失、重复或乱序到达，UDP本身不负责解决这些问题。因此，数据的可靠传输需要由上层应用来保证，或者接受数据丢失的可能性。

3.面向数据报

UDP是面向数据报的协议，它将应用程序的数据封装成数据报（datagrams）进行传输。每个数据报都是独立传输的单元，包含完整的源地址和目的地址信息。这使得UDP适合传输少量数据或对实时性要求高的应用。

4.全双工

指的是数据可以同时在两个方向上传输。在UDP中，既然没有连接的概念，自然也没有限制数据只能单向流动，所以UDP支持全双工通信。发送方和接收方可以同时独立地发送数据，而不需要等待对方的响应，这增强了协议的灵活性和效率。

2.UDP协议的格式

1. 源端口（Source Port）：占用16位，标识发送方的应用程序端口。这个字段是可选的，但当使用时，它标明了发送方进程的端口号，有助于接收方回复消息到正确的应用程序。如果未使用，该字段通常被置为0。

2. 目的端口（Destination Port）：同样占用16位，表示接收方的应用程序端口。这个字段是必要的，确保数据能够被正确地路由到接收端的指定应用程序。

3. 长度（Length）：占用16位，指示整个UDP数据报的长度，包括UDP头部和数据部分。这个字段的单位是字节，因此最小的有效UDP数据报长度为8字节（仅头部）。

4. 校验和（Checksum）：占用16位，提供了一个基本的错误检测机制。校验和覆盖UDP头部和数据部分，以及一个伪头部（包含IP头部的部分信息），以确保数据的完整性。如果接收方计算的校验和与数据包中的校验和不匹配，该数据包将被丢弃。

 3.源端口 vs 目的端口

UDP源端口（Source Port）

1. 标识性：源端口号通常用于标识发送数据报的本地应用程序或服务。
2. 可选性：在UDP中，源端口号是可选的，应用程序可以选择不指定源端口号，让操作系统自动选择一个临时的源端口。
3. 客户端通信：当客户端应用程序向服务器发送数据报时，通常需要指定一个源端口号，以便服务器能够识别并可能需要向客户端发送响应。
4. 多任务处理：源端口号允许一台主机上的多个应用程序同时进行通信。

UDP目的端口（Destination Port）

1. 服务识别：目的端口号用于指定接收数据报的远程服务或应用程序。例如，如果一个客户端想要访问服务器上的DNS服务，它会将目的端口号设置为53（DNS服务的标准端口）。
2. 服务器监听：服务器应用程序通常会监听特定的端口，当它们接收到发往该端口的数据报时，会知道如何处理这些数据。
3. 无连接：由于UDP是无连接的，目的端口号不用于建立或维护连接，而仅仅是为了将数据报路由到正确的服务或应用程序。

4.UDP长度

由于UDP数据报 = UDP报头 + 载荷.而UDP长度表示的是整个UDP数据报的长度,而UDP长度最多为16位也就是65535即为64kb,所以传输数据时UDP最多传输的数据就为64kb不可以再多了,也正是因为这UDP数据报长度的制约导致了UDP无法传输数据量大的数据.

5.校验和

数据在网络的传输过程中,出错是不可以避免的,例如发生比特翻转等等,那么我们就需要对传输过来的数据进行校验知道数据在传输过程中是否出错,而UDP的校验和就是通过CRC(循环冗余校验)来完成的.

CRC是一种广泛使用的错误检测码，通过对数据执行多项式除法生成校验码，以确保数据的完整性。

UDP校验和的计算过程如下：

1. 伪首部的添加：在计算校验和时，UDP数据报前面会临时添加一个伪首部，这个伪首部包含了源IP地址、目的IP地址和UDP长度等信息，但这个伪首部仅用于计算校验和，并不随数据报一起发送。

2. 填充：如果UDP数据报的长度（包括伪首部、UDP首部和数据）不是16位的整数倍，则在数据报的末尾添加一个全零的字节进行填充。

3. 计算校验和：将整个UDP数据报（包括伪首部、UDP首部和数据）按照16位的单元进行累加，如果中间结果的高16位不为0，则继续与低16位相加，重复此过程直到高16位为0。然后将得到的16位数值进行按位取反，得到的结果就是校验和。

4. 发送：发送方将计算得到的校验和放入UDP数据报的校验和字段中，然后发送整个UDP数据报。

5. 接收：接收方在收到UDP数据报后，使用相同的过程重新计算校验和，如果计算得到的校验和与UDP数据报中的校验和字段相同，则认为数据报未损坏；如果不同，则认为数据报在传输过程中可能出现了错误。

UDP校验和虽然可以检测许多常见的错误，但它不是百分百可靠，有些错误可能无法被检测到。尽管如此，UDP校验和提供了一种简单、高效的错误检测方法，适用于那些可以容忍一定错误率的实时或流式数据传输应用。

除了使用CRC,还有一种方法-- MD5,MD5是一种广泛使用的哈希函数，它产生一个128位（16字节）的哈希值，通常用于验证数据的完整性。不光是在UDP中使用于校验和,在我们以后开发工作中,也算是会用到的一种方法.我们可以简单了解一下,当然现在的MD5已经变得容易破解了,我们需要这种在对数据安全领域比较高的场景中,推荐使用更加安全的哈希函数

当使用MD5作为UDP数据报的校验方法时，通常的做法是：

1. 计算MD5哈希：发送方首先对UDP数据负载计算MD5哈希值。

2. 附加MD5哈希：将计算得到的MD5哈希值作为UDP数据负载的一部分附加到原始数据之后。

3. 传输：发送方将整个UDP数据报（包括附加的MD5哈希值）发送给接收方。

4. 接收与验证：接收方在收到UDP数据报后，会提取出数据负载，并对接收到的数据负载重新计算MD5哈希值。

5. 比较哈希值：接收方比较重新计算的MD5哈希值与数据报中附带的MD5哈希值。如果两个哈希值相同，那么认为数据在传输过程中没有被篡改；如果不同，那么数据可能已经被篡改，接收方应该丢弃该数据报。

6.应用场景

UDP（用户数据报协议）由于其无连接、无状态、不可靠的特性，适用于一些特定的应用场景，尤其是那些对实时性要求较高、能够容忍一定数据丢失的场合。以下是UDP的一些典型应用场景：

1. 实时应用：如视频会议、IP电话（VoIP）、在线游戏等，这些应用对实时性的要求远高于对数据完整性的要求。

2. 网络广播：UDP支持广播和多播，适用于需要向多个目的地同时发送数据的情况。

3. DNS查询：域名系统（DNS）通常使用UDP进行域名解析，因为DNS查询通常是请求-响应模式，且响应数据量不大。

4. 简单网络管理协议（SNMP）：用于网络管理，包括设备监控和数据收集，通常数据量较小。

5. 流媒体传输：如音乐和视频流，这些应用可以容忍偶尔的数据丢失，但需要快速传输。

6. 远程登录和命令执行：如使用SSH（安全外壳协议）进行远程登录，虽然现代SSH协议也可以运行在TCP之上，但UDP提供了一种替代方案。

7. TFTP（简单文件传输协议）：用于在客户端和服务器之间进行简单的文件传输，不需要复杂的连接管理。

8. 网络监控和诊断工具：如ping和traceroute，这些工具用于测试网络连通性和路径。

9. 局域网（LAN）内的通信：在LAN中，由于网络环境相对可靠，UDP的无连接特性可以提供更快的通信速度。

10. 某些类型的在线游戏：特别是那些对实时性要求极高的游戏，可能会选择UDP来减少延迟。

11. 内容分发网络（CDN）：在某些情况下，CDN可能会使用UDP来传输数据，以减少处理开销。

12. DHCP（动态主机配置协议）：用于自动分配IP地址给网络中的设备。

13. VoIP系统中的某些控制信令：虽然VoIP通话本身可能使用RTP（实时传输协议）运行在UDP之上，但相关的信令协议可能也会直接使用UDP。

UDP的应用场景通常与它的简单性和低延迟特性有关。尽管UDP不提供TCP那样的可靠性保证，但在很多情况下，这些保证不是必需的，或者可以在应用层实现。在选择UDP还是TCP时，需要根据具体的应用需求来决定。

以上就是关于UDP协议和一些应用层格式的一点小小的介绍,感谢你的阅读,祝你一天愉快