网络原理详解（应用层+传输层（UDP/TCP）+网络层(IP)等各层协议及功能详解）-优快云博客

本文链接：https://blog.youkuaiyun.com/weixin_63018754/article/details/139044578

文章目录

前言
一、应用层(后端开发必知必会)
二、传输层(UDP,TCP)
三、网络层
- 1.IP协议
四、数据链路层(越往下,距离程序猿就越远)
- mac地址
- 域名解析系统.
总结

前言

一、应用层(后端开发必知必会)

1.自定义协议

这一层,也有很多现成的协议.(后面还会重点介绍HTTP协议)
也有很多时候,是需要程序猿自己定义协议.

定义协议：
做出如下设计:
1.明确当前请求和响应中包含哪些信息(根据需求来的)
2.明确具体的请求和响应的格式.

网络上,传输的数据,本质就是字符串。Java 写代码,都是各种对象。
[序列化]：最后在发送数据的时候,就需要把对象转成(二进制)字符串
[反序列化]：在收到数据的时候,也需要把(二进制)字符串转换回对象
在这里插入图片描述
实际上，上述这样的格式约定,咋搞都行.任意进行约定的.只要保证，客户端和服务器遵守同一个约定即可!!

实际开发中如何约定：
1.实际开发中,客户端和服务器,往往是两伙不同的人分别开发的。为保证,双方的配合是有效的。在开发之前,就要共同商量一下这里的数据格式如何确定(具体怎么设定无所谓,一定要统一)
2.指定一个人,由这个人整理出一个最终的前后端交互的数据格式规范。发一个邮件出来,抄送客户端和后端这里的相关开发,还会抄送给测试。双方再按照这个规则进行各自写代码.测试也需要根据这个规范设计测试用例.
3.等到双方都把代码写完之后，客户端和后端先各自测各自的…双方都测试完了，还需要进行联调。把两份代码的程序放到一起一个环境中,试试看能不能正确通信。
4.客户端和服务器这边的开发,以及测试,都坐到一起。配合完成这个工作。

2.通用的协议格式

虽然说，自定义的协议格式,是可以任意的.但是为了避免出现过于天马行空的设计。
“通用的协议格式”,参考这些格式,就可以对咱们的协议设计产生重要的指导作用

1.xml（越来越少）

是以成对的标签,来表示"键值对”信息,同时标签支持嵌套,就可以构成一些更复杂的树形结构数据.
在这里插入图片描述

优点: xml非常清晰的把结构化数据表示出来了
缺点:表示数据需要引入大量的标签,看起来繁琐,同时也会占用不少的网络带宽.
（国内,最贵的硬件资源,就是网络带宽!!）

xml里的标签都是程序猿自定义的.
html里的标签,都是有一套标准规定好的。
(html可以视为是xml的特化版本)

2. json(最流行一种数据组织格式)

本质上也是键值对,看起来,比xml要干净不少

在这里插入图片描述
优势:相比于xml，表示的数据简洁很多.
可读性非常好的.方便程序猿观察中间结果,方便调试问题.
劣势:终究是需要花费一定的带宽来传输key的名字的.

json对于换行并不敏感，如果这些内容全都放在同一行,也是完全合法的.
一般网络传输的时候,会对json进行压缩(去掉不必要的换行和空格),同时把所有数据都放到一行去,整体占用的带宽就更降低了.(影响到可读性)
也有很多现成的json格式化工具.

二、传输层(UDP,TCP)

1.UDP的结构

UDP基本特点:无连接,不可靠传输,面向数据报全双工
在这里插入图片描述

1.端口

一次通信,涉及到5元组:源端口，目的端口,源ip,目的ip,协议类型

以下数字,要求大家能够熟练背诵!!最常用的一些数据!!
在这里插入图片描述
端口号用使用范围：1025~65535
1-1024这个范围的端口号（知名端口号(known port)），系统赋予了特定的含义,一般也不建议咱们使用。
你当然也可以写个程序,使用1024之前的端口。(需要你的程序有管理员权限)

2.UDP报文长度

UDP报文长度：2字节（64kb）。不够用
此时,能否把这个长度给改大?分配4个字节表示这个UDP长度~是否可行呢??
相当困难，甚至完全不可行。（因为标准已经统一，很难改变）
可以采用以下两种来解决，第二中最佳。
在这里插入图片描述

3.UDP的校验和具体实现

UDP的校验和具体是咋实现的?使用了一种简单粗暴的CRC校验算法.(循环冗余校验和)
1）把UDP数据报中的每个字节,都依次进行累加。
2）传输数据的时候,就会把原始数据和校验和一起传递过去.
3）接收方收到数据,同时也收到了发送端送过来的校验和(旧的校验和)。接收方按照同样的方式再算一遍，得到新的校验和。
4）如果旧的校验和和新的校验和,相同,就可以视为数据传输过程中,是正确的。如果不同,则视为传输过程中数据出错了。