网络原理-

文章目录

协议
- 应用层
- 传输层
- 网络层
数据链路层

协议

在网络通信中,协议是非常重要的概念.协议就是一种约定.

在网络通信过程中,对协议进行了分层

接下来就按照顺序向大家介绍每一种核心的协议.

应用层

应用层是咱们程序员打交道最多的一层协议.应用层里有很多现成的协议,但是有些并不适用于一些特定场景.需要咱们自己自定义协议.

自定义协议我们约束好两方面内容:
1.服务器和客户端要交互哪些信息
2.信息发送的具体格式

这里我们可以用两种方式编辑数据的格式

(1)xml
在这里插入图片描述
< requst >< /requst>就是标签(tag)
利用xml可读性和扩展性都明显提高.但是整个信息冗余太多了,会导致标签占据的空间比数据还多.在进行网络传输的时候,会占用网络带宽.

json
json是当下比较主流常用的数据组织格式了.

在这里插入图片描述
应用层我们就介绍到这里,接下来我们介绍传输层

传输层

UDP协议
特点:无连接,不可靠传输,面向数据报,全双工.

UDP数据报:报头+载荷.
在这里插入图片描述
UDP报头一共有四个字段,每个字段有2个字节.由于协议用2个字节表示端口号.端口号取值就是0-65535,所以最大值就是64kb.因此一个数据报最大长度就是64kb.一旦数据报长度超过64kb,就会发生数据截断.

端口号前文我们有过介绍,就是数据传输后,传到具体到哪个应用程序(每个程序都有自己的端口号).

校验和:验证数据在传输过程中是否正确.检查当前传输的数据是否存在bit翻转.如果错了,就把数据报丢弃.

校验和是如何实现的?
1.CRC算法(循环冗余校验)
在这里插入图片描述
UDP在发送数据之前就会先计算一下CRC值,把算好的CRC值放到UDP数据报中,发送给接收方,接收方在拿到数据后,也会计算CRC值,如果传过来的值和接收方计算的值相等.就证明数据是正确的.

2.md5算法

特点:
(1)长度一定
无论原始数据多长,最终算出的md5值都是固定的长度

(2)分散
计算md5值的时候,如果数据发生一点点变化,结果就会有很大差异.

(3)不可逆
一个字符串,计算md5的值.但是如果想根据计算出的md5的值得到字符串几乎是不可能的.

TCP协议(最重要)

特点:有连接,可靠传输,面向字节流,全双工

在这里插入图片描述
源端口和目的端口这里我们就不做介绍了

4位首部长度.就是报头长度.在TCP中报头前20字节是固定长度的.
他的最大长度是60字节.
在这里插入图片描述

保留(6位):为协议的未来发展提供了灵活性。如果未来网络通信的需求发生了变化，需要引入新的特性，保留位可以被重新定义，而不会影响到现有协议的正常运行。

TCP的可靠传输的十个机制

TCP的可靠传输,是TCP的在互联网浪潮的安身立命之本.

这里的可靠性并不是保证数据100%发送到对方,而是发送方能够知道对方是否收到.

用来确保可靠性,最核心的机制就是"确认应答"

1.确认应答:
在这里插入图片描述
就像我请女神去吃饭,女神欣然给我回应.这样我就知道女神接收到了我要请他吃饭的消息.

发送方发出数据,接收方给一个回应,就知道了接收方收到了发送方的数据.

后发先至:
在这里插入图片描述
由于数据传输的过程中会经过很多设备,路由器交换机.如果数据1先发送但是数据堵在了半路,数据2虽然后发送.但是路线通畅,可能就会导致后发先至.
可能就会导致接收方先接收到数据2并且返回ack(应答报文)给发送方,此时发送方就以为是数据1的应答报文,这就乱套了

为了解决上面的现象.引入了序号和确认序号.告诉发送方,应答的是哪个数据.
发送方先发送序号为1的数据,后来发送了序号为2的数据,但是由于网络路径的原因可能序号为2的数据先被接收,此时序号的作用就是在接收方内会根据序号大小对数据进行排序,按照从小到大的顺序返回给发送方.
在这里插入图片描述

在这里插入图片描述
序号是发送方发给接受方的

报头中的序号只能存一个数字,但是由于序号都是连续的,我们存第一个就可以知道后续的序号.

确认序号是接收方返回给发送方的
在这里插入图片描述
如果发送的数据是1-1000,返回的确认序号是1001,就证明前面1000个数据都已经收到了.并且告诉发送方要从第1001个数据发送数据.

TCP的确认应答是保证TCP可靠性的最核心机制

2.超时重传(是确认应答的补充)
在发送方发送数据之后,并没有受到应答报文(ack报文),就是接收方并没有给出应答.

如果一切顺利,发送方就会接收到接收方发回的确认应答.
但是网络传输中会存在"丢包"现象,如果数据包丢了,自然也就收不到ack报文

小知识:
什么是丢包?
在这里插入图片描述
如果一台设备在同一时间涌入大量数据,超过设备本身承载的极限,就会丢弃一些数据,就会发生丢包.

丢包的情况在网络通信中还是很常见的.但是发送方接收不到ack报文(接收方返回的确认应答的报文),有两种情况:
1.数据在发送的时候发生丢包,接收方并没有收到数据
在这里插入图片描述
2.接收方接收到了数据,但是返回给发送方的ack报文丢了.

针对第二种情况,在没有收到ack报文,但是数据已经被接收方收到.那么TCP会怎么处理?

TCP socket在内核中有内存缓冲区,发送方发来的数据是要先放在接收方的缓冲区中的.然后应用程序调用read或者scanner.next来读取数据.
在这里插入图片描述
当发送方没接收到ack报文的时候,就会超时重传.发送的数据如果会存到接收方的内存缓存区中.此时新的数据会用自己的序号和缓冲区数据的序号做比较,如果有序号一样的,就丢弃新数据.

但是如果数据被应用程序读取走了,此时新的数据在缓冲区就无法和原来的数据比较序号了.我们应该怎么办?
注意,应用程序在读取数据的时候,是按照序号的从小到大顺序连续读取的.
此时socket api会记录上一次读取的数据的序号是多少.

比如上一次读取的数据的序号是3000,新收到的数据包的序号是1001,由于应用程序在缓冲区读取数据都是从小到大的,所以1001已经读取过了,这里又重新传来序号为1001的数据,所以就重复了,直接丢弃.

3 三.TCP的连接(三握四挥).
TCP的连接是热门高频面试题.十分的重要.

建立连接: 内核和应用程序的相互配合建立连接
在这里插入图片描述

那么客户端内核是如何操作才和服务器的内核建立连接的呢?重点来了

三次握手(建立连接)

此处谈到的连接是虚拟的连接,是"虚拟的,抽象的",我们把通信双方各自保存了对端的信息就称为连接
在这里插入图片描述
客户端这一方是主动的,第一次交互,一定是客户端发起的.就像是客户端求服务器办点事,一定是客户端先张嘴.

建立连接的流程:客户端主动发起连接请求.给服务器发送一个syn数据包,里面保存了客户端的信息.此时服务器接收到这个数据包之后会给客户端返回一个ack(应答报文),就是告诉客户端,我收到了.紧接着,服务器也给客户端发送了一个syn数据包,里面包含了服务器的信息,此时就和我们连接的概念一样了,通信双方都保存了对方的信息.客户端收到了服务器的syn后会给服务器返回一个ack,告诉服务器我收到了,这样就建立了连接

在这里插入图片描述

syn(同步报文段):是一个特殊的TCP数据报.
1.没有载荷.不会携带应用层的数据
2.是TCP6个标志位的第五个
syn表达的是:我(客户端)想和你(服务器)建立连接
虽然syn不带应用层载荷,但是会包含IP报头(包含设备IP)和TCP报头(包含设备应用程序的端口号).
包含的这些东西就是告诉接收方我是谁.我是哪个设备的哪个程序

所谓建立连接的过程就是通信双方各自给对方发送一个syn(同步报文段),双方各自回应一个ack(应答报文).

有人会问,不是三次握手嘛,但是上面通信双方出现了四次交互啊?
虽然是四次交互,但是有两次可以合并.
在这里插入图片描述
于是就有下面的图

上面这个图就是三次握手,通过三次握手就建立了连接.

三次握手建立连接的意义:
1.三次握手.可以先针对通信路径.进行投石问路.初步检查下通信线路是否畅通.
就类似先行官一样,先在前面开路.确定路线不会出问题,大臣才会出发.

2.三次握手.验证通信双方,发送能力和接收能力是否正常
在这里插入图片描述

3.三次握手.过程中也会协商一些参数.

这里我们就只是介绍下,TCP通信的起始序号.TCP在一次通信中传输的数据的序号不是从0开始的,而是从一个很大的数开始的,以这个数字为开头计算.即使是同一个服务器和客户端,通信完再次连接的时候,传输的数据的序号也不是上一次的序号.这样做的目的就是为了防止"前朝的剑,斩本朝的官".
在这里插入图片描述
假设我们再传输数据的时候,数据"先发后至(先发出的数据最后到达)“.
通信双方连接已经断开了连接,并且已经建立了新的连接.此时上一个连接传输的数据才到达对端,但是发现已经改朝换代了.此时这个数据就会被丢弃.
那么接收方是如何识别当前的数据包是上一个连接的数据呢?
正常的数据包的序号都是连续的,即使发生"丢包”,但是整体差异不会很大,之前的包的序号和现在的连接的传输的包差异还是很大,就像鹤立鸡群了.一下子就发现了.

四次挥手(断开连接)
断开连接需要进行四次挥手,和三次握手(建立连接)不同的是,三次挥手必须是客户端是主动的一方,主动发起连接请求,而四次挥手(断开连接)哪一方主动都可以
在这里插入图片描述
FIN:结束报文段,是TCP的6个标志位中的最后一个.用于断开连接,FIN是通过close来触发.

TCP的状态转换(也很重要)
在建立连接(三次握手)的过程中的状态转换.
在这里插入图片描述

LISTEN状态:就是指ServerSocket 已经创建好,并且绑定了端口号.可以进行连接请求了.这个状态只有服务器这边才会有

 public TcpEchoServer(int port) throws IOException {
        socket=new ServerSocket(9090);
    }

在这里插入图片描述
可以看到当我们在编译器上运行我们的服务器的时候,打开cmd观察,此时我们并没有运行客户端的代码,自然也就没有连接.此时的LISTEN就是等待连接请求.

ESTABLISHED状态:此时就是已经建立连接完毕了

此时我们将客户端代码也运行,建立客户端-服务器的连接
在这里插入图片描述
再次打开cmd我们就发现,出现ESTABLITSHED就证明成功连接.

在断开连接(四次挥手)时TCP的状态.
在这里插入图片描述
CLOSE_WAIT状态:被动的断开连接.接收方知道对方不再发送数据,但是自己这边的可能还有数据要发送,所以不会立即关闭连接.等到逻辑执行完毕,调用socket.close()方法向对端发送FIN

TIME_WAIT:主动断开连接的一方,本端先给对面发送了FIN之后,对端也给本段发送了FIN,于是本端就进入了TIME_WAIT.它存在的意义就是为了防止最后一个ACK"丢包".
在这里插入图片描述

如果在TIME_WAIT断开连接,那么如果最后一个ACK丢包的话,那么服务器这边没有收到ack报文,于是会重新传FIN数据包.但是已经断开了连接.重传的FIN也就无法返回ACK了.

此时TIME_WAIT最多会等待2MSL.(一分钟),虽然生活中的一分钟很短,但是对于计算机来说,却是很长的.如果这么长时间都没重传.估计客户端返回给服务器最后的那个ack也已经被收到了.

4.滑动窗口
TCP的可靠传输固然很好,但是付出的代价也是很多的.每次传输一个数据后都要等待a接收到ck报文,才继续传输下一个.导致大量的时间都浪费在等待返回ack上了.
在这里插入图片描述
由此,滑动窗口出现了.它可以保证可靠性的基础上提高效率.

在这里插入图片描述
滑动窗口的核心机制就是批量传输.之前是发送一条数据,收到ack后,才能发送下一条数据.

批量传输,就是连续发好几条数据,不等ack,连续发了一定数据之后统一等ack.这样就减少了总的等待时间.
在这里插入图片描述
批量发送了四个数据之后,等到返回了一个ack,就往后发一组,接着返回接着发一组,以此类推.

如图,我们就把上面白色的区域(不等待ack,批量传输的数据量)称为窗口大小.上图就是四个数据为一个窗口.发送完数据后,等待一个ack返回后就继续执行.

就类似于假设我们设置窗口大小为4000字节.比如发送方发送了1-4000的数据,此时收到了1-1000的ack(应答报文).此时就会向右滑动,可以发送4001~5000的报文了.再收到ACK2001的话就可以发送5001~6000的报文了以此类推.

假如发送了上图1~1000 1001~2000 2001~3000 3001~4000 这个四个数据段,然后收到一个ack就开始走,等到收到ack确认序号是窗口中最后一个数据的序号(4000)的时候,4001-5000,5001-6000,6001-7000,7001-8000这几个数据段也已经被发送完毕了.

其实就是边返回ack边进行传输

滑动窗口,保证可靠性是前提,但是如果出现丢包会怎么办呢?
1.ack丢了
在这里插入图片描述

这里我们假设1-1000的确认序号为1001的ack报文丢了,但是确认序号为2001的ack报文成功返回.因为前面介绍过,确认序号返回有两个意思:这里假设确认序号为2001,(1).前2000个数据都已经被成功接收了.(2).可以开始传输2001开始往后的数据了

所以这里ack报文并不影响.

2.数据丢了
虽然ack报文丢了不会影响,但是数据就不一样了.
在这里插入图片描述
在上述重传的过程中,整体的效率还是非常高的.这里对于重传做了针对性重传.哪个丢了就重传哪个.
已经收到的数据不必重复发送,发送方连续三次收到重复ack,就会立即重传.这就是"快速重传".

5.流量控制
我们知道可以通过滑动窗口来提高传输效率.

而窗口大小越大,更多的数据用同一块时间等待.效率就会越高.但是窗口大小能无限大嘛?

很显然不能.如果你发送的数据太快,接收方的内存缓冲区满了.接收方处理不了.此时也会发生丢包.
与其知道他满了,不如提前感知到,减慢发送速度.改变窗口大小.
我们知道TCP包含了16位窗口号大小.接收方通过ack报文将接收缓冲区剩余空间的大小,作为ack中的窗口大小的数值.下一步发送方就会根据这个数值来调整窗口大小.

窗口大小是否就是64位?
不是的,TCP报头的选项中,包含了窗口扩展因子.实际上设置的窗口大小.是16位窗口大小*2^窗口扩展因子
在这里插入图片描述
流量控制的思想就是通过接收方内存缓冲区的大小来决定传输速率.因为接收方返回的ack报文会带上接受缓冲区剩余的时间.如上图,我们先传入1-1000的数据,接收方成功收到后,接收方还剩3000字节的空间,用ack告知发送方还剩3000字节的空间.继续传输1001-2000,2001-3000,3001-4000.
当传输完4000字节数据后.发现接收缓冲区满了,并且知道接收缓冲区一直是接收数据,数据并没有被应用层读取.由于已经满了,发送方就不能再发送数据了.否则会发生丢包.那么发生方什么时候才可以继续传输数据呢?

此时发送方会时不时的出发"窗口探测包","窗口探测包"不携带任何载荷,不会对业务产生影响.但是会出发ack,此时一旦有数据在接收方被读取,缓冲区就会有空闲空间并且通过ack返回给发送方,此时发送方就可以继续发送数据了.

6.拥塞控制
上述的流量控制是针对接收方的,而拥塞控制就是针对数据传输中路线的设备的.因为网络通信本身也是生产者-消费者模型,发送方是生产者,接收方是消费者,而中间的传输线路的设备(路由器,交换机)就是阻塞队列.如果生产者生产数据太快,此时阻塞队列就会满了,必须等消费者消费一波才可以继续发送.在网络通信中如果传输数据太快,超过设备本身负载量,也会发生丢包.
在这里插入图片描述
流量控制我们可以通过ack报文知道缓冲区的剩余空间.但是拥塞控制中是中间传输设备可能会满,传输数据中会有很多设备传输.而且我们也不知道是哪个设备负载量满了发生丢包.那么我们如何处理?

这里我们就把整个中间传输的线路看作一个整体.通过"实验"的方式找到一个合适的传输速率.
如果按照某个窗口大小发送数据之后,出现丢包,就视为中间路径存在拥堵,那么我们就要减少窗口大小.如果没出现丢包,我们就要增大传输速率.

拥塞控制是怎么把窗口大小试出来的.
1.慢启动.刚开始传输数据的时候,速率是比较小的.采用的窗口也就比较小.
2.如果上述传输数据的时候没有发生丢包,那么就增大窗口大小,就是增大传输速率.(这里是按照指数增大)
3.指数增长,不会一直保持的,当指数增长传输达到阈值,指数增长就会变成线性增长.
4.线性增长也是一直在增长,到达一定传输速率,还是会发生丢包.一旦出现丢包,就把滑动窗口重置成最小的值,回到第一条慢启动的过程.并且也会重新设置阈值.
在这里插入图片描述
7.延时应答
接收方在收到数据之后不会第一时间向发送方返回ack(确认报文),而是稍等一会.等这一会,接收方可能会在内存缓冲区中读取一些数据,缓冲区空间就会增大.此时再返回ack,那么窗口大小可能会设置的更大一点.
在这里插入图片描述
延时应答具体怎么延时,也不是单纯的按照时间,而是按照"ack"丢了来处理.
我们前面讨论,滑动窗口传输数据的时候如果ack丢了,影响其实不大的,我们知道接收方从缓冲区读取数据都是按照序号的从小到大顺序读取的.如果1-1000的数据的ack丢了,但是2001的ack返回了,我们也就知道了1-1000的数据也被读取成功了.

我们这里的处理方式正常每次传输一个数据都会返回一个ack,这里我们就可以没隔几个数据返回一个ack, 这样就起到了延时应答的效果,并且不用频繁的返回ack,也节省了开销.

8.捎带应答
基于上面的延时应答机制,我们可以把ack(应答报文)和requst/response一起发送/接收.从而提高效率.
在这里插入图片描述

正常我们传输一条数据后,接收方会立即返回一个ack,这是TCP机制控制的,由系统内核返回的.如果我们用延时应答,此时ack可能会和response或者requst一起发送,就达到了捎带的效果.
利用延时应答+捎带应答,四次挥手也可能会变成三次.

9.面向字节流

“粘包问题”.
在这里插入图片描述

如何解决:
1.通过特殊符号作为分隔符.见到第一个分割符,就认为一个包结束了.

2.指定出包的长度,比如在包开始的位置上,加上一块特殊空间表示整个数据的长度.
在这里插入图片描述
10.异常情况

网络层

网络中的IP协议,主要完成以下两方面的工作
1.地址管理
2.路由选择

首先我们先认识下IP协议的报头
在这里插入图片描述
++++++++++++++++++++++++++++++++++++++++++++++++++++++
4位首部长度: 指的就是报头长度,也是可以像TCP一样可变长的.

4位版本:指的是当前IP协议版本(一般是IPv4和IPv6).

8位服务类型: 实际上只有4位有效.并且这4位彼此冲突,如果其中1位为1,剩下3位就都是0.这四位表示当前IP协议所处的模式.
(1)最小延时:表示数据传输中尽量减少延迟
(2)最大吞吐量:表示传输中尽量增加传输速率
(3)最高可靠性:虽然不像TCP那样,但是也保证了一定的可靠
(4)最小成本:硬件的开销

16位总长度: 描述了一个IP数据报的长度(报头+载荷),这里IP协议最大也是只能传输64kb的数据吗?如果构造一个特别大的TCP是不就传输不了了.
虽然IP协议本身有长度限制,但是它可以对数据进行拆包和组包这样的操作.

拆包:
在这里插入图片描述
这里本人绘画技术有限,献丑了各位O.o?

组包:
在这里插入图片描述
16位标识:就是指的是哪些数据报的载荷应该往一起组装.

3位标志:只有两位有效,其中1位标识当前数据是否已经拆包了,还有一位数据表示结束标记.

13位片偏移:表示这些包之间的先后顺序

8位生存时间(TTL):这里的生存时间不是s/ms,它指的是次数.当数据经过一个路由器转发,TTL-1.本质上是为了防止数据一直传输下去.TTL一般来说都是32/64位的整数.这些其实就已经完全够了.

假设我们访问美国官网,就经历了30次转发
在这里插入图片描述

8位协议:表示在传输层使用的哪个协议(TCP/UDP).

16位首部校验和:只是针对IP报头的校验,载荷已经在传输层检验了.

32位源IP地址和32位目的IP地址:表示发件人和收件人地址.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

IP协议如何管理的地址
IP地址就是一个32位整数,为了方便,用"点分十进制"表示.通过3个 . 分成了四个部分.每个部分一个字节,每个部分的取值是0-255.

IPv4 地址 . . . . . . . . . . . . : 192.168.10.208

IP地址存在就是为了区分网络上不同的设备.

32位的整数表示数据范围大概是42亿9千万.看起来是一个天文数字,但是现如今的互联网时代,这些数字不是很抗打.那么我们该如何解决呢?

1.动态分配IP地址
利用时间差,有人上网,也有人休息.不是全世界人民同时一起上网.

2.NAT机制(网络地址映射)
我们先把IP地址分为两大类
(1)私网IP/局域网IP
IP地址是以10*_,192.168*,172.16-172.31*都是私网IP
(2)公网IP/广域网IP
除了上述私网剩下的都是公网IP.

这里我们要求公网的IP必须是唯一的
私网IP在相同的局域网内必须是不同的,但是在不同的局域网中之间的IP可以重复

上述约定有一个重要的限制:
1.公网访问公网,是可以访问的
2.局域网访问局域网(同一局域网内),也是可以访问的
3.局域网访问局域网(不同局域网),是不可以访问的
4.局域网访问公网,需要对局域网设备的IP进行地址转换.
5.公网不允许主动访问局域网

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
在这里插入图片描述
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

当同一局域网内的不同设备访问同一个服务器,此时路由器在收到数据后,会有一个表,表内存储了,替换之前的IP,以及两个设备各自的端口号,以及目的IP和目的端口.当服务器返回响应给路由器的时候,路由器就不能根据访问的IP地址来转换IP地址了,因为两个设备访问的都是同一个服务器.此时就路由器就会拿出刚才的存储的表,通过源端口号进行分别,并且将IP地址转换回来
++++++++++++++++++++++++++++++++++++++++++++++++++++++
客户端分配的端口号是系统随机分配的,可能会存在两个端口号相同的情况,那么我们该如何返回数据
在这里插入图片描述
虽然我们认为不同的设备可能系统分配的端口号不会一样,但是是在大多数情况,如果是极少数情况我们会做如下应对.
如果两个设备端口号一样,并且访问的服务器也一样.那么我们将IP地址在路由器转换后,会先将端口号也替换掉,然后当服务器返回响应的时候,路由器会拿出存储好的表,根据替换好的端口号来将替换好的IP协议进行转换并且返回
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3.IPv6(根本上解决问题)
将IP地址从32位增加成了128位

相当于变成了2^128 个地址

“给每粒沙子都分配一个地址”

迟迟没有完全落地因为所有的硬件设备都得换,而且对体验提升不大

但是中国已经覆盖到70%,虽然使用率一般,但是防止了美国在IP地址上的垄断操作

避免大漂亮直接给你断网

路由选择

由于网络结构错综复杂,每个路由器都掌握了局部信息,无法掌握全局的信息.
不同于我们现在使用的地图软件,只需要我们将起点和终点输入就可以得到很多条路线,这是在上帝视角看来,站在全局的角度,而我们可以根据路线找到最优解.对于地图而言,出发之前,路线就已经规划好了
而对于路由器规划的网络传输线路,则是摸索式,自己一点一点走,路线不是固定的.出发之前并不是按照某一条线路固定的走.这种传输就像是我们没有导航一样的,从家里出发去到某一个地点,期间可能会找很多人问路,直到走到终点.
如何判定数据包应该发到哪里??
这就依赖路由器存储了一个路由表结构,能找到路线就直接发送,否则按照默认发送

在这里插入图片描述
每一次问路我们都会离目标更近一点.直到走到终点.

数据链路层

数据链路层的核心协议就是以太网

数据链路层引入另外一种地址体系:mac地址/物理地址

和IP地址不同的是,IP地址注重的是全局的转发,从起点到终点,而mac地址则是相邻设备之间的转发
举个例子:
假如我们从长沙出发前往北京,具体路线是长沙-武汉-石家庄-北京
此时我们从长沙到武汉—>源IP:长沙;目的IP:北京; 源mac;长沙目的mac:武汉
武汉->石家庄源IP:长沙; 目的IP;北京源mac:武汉目的mac:石家庄
石家庄->北京源IP:长沙;目的IP:北京; 源mac:石家庄目的mac:北京
类似我们传输数据,每次经过一个交换机/路由器的时候,IP地址是不变的,但是mac地址会改变.

因为mac地址的表示范围比IPv4大很多,所以mac地址是静态分配的,机器出厂的时候就分配一个,一直都只是这一个不会像IP地址一样可能会发生改变.
鉴于mac地址一个机器就有一个mac地址,有些程序可能会使用mac地址作为身份标识(比如外挂)

1.目的地址需要发送到的MAC地址
2.源地址发送的源地址

3.类型分为几种类型
类型 0800 + 数据报(16-1500字节) 可能是syn这样的特殊报文也可能是正常的业务数据
类型0806 ARP 请求/应答 + P
类型8035 RARP请求/应答 + PAD

ARP就是能够让路由器在内部建立一个结构可以通过IP地址找到mac地址
RARP和ARP一样,但是是通过mac地址找到IP地址

关于DNS(域名解析系统)
我们如果使用IP地址描述网络设备的位置,可读性不是很好.
这里我们用一串可读性更好的单词描述设备的位置,这就是域名
www.baidu.com就是域名
上古时期都是引入一个hosts文件,这里有很多文本,有很多IP和域名.通过hash表存储.每次访问域名就会进行查询,返回对应的IP地址
随着互联网的高速发展,不停的维护hosts文件也会耗时耗力,于是大佬们就搭建了一组服务器,来提供域名解析的服务.某个主机想要访问某个域名,此时就先查询一下域名解析服务器.将IP地址返回给主机

如果全世界的大量的用户访问DNS服务器,服务器不就崩了?
我们的解决办法就是每个国家的运营商通过搭建"镜像服务器",我们上网的时候,直接访问咱们中国的"镜像服务器"即可

网络原理就像大家介绍完了,如果有介绍不对或者有欠缺的,希望指出来