JavaEE初阶----网络协议（网络面试必考内容）

前言

上一篇博客详情点这篇博客，我们讲到五层模型，现在我们来讲讲具体的每层模型中的协议。

应用层协议

在应用层这里，最最重要的事情，就是“设计并实现一个应用层协议”–这是一个非常简单，同时也是在工作中经常要做的事情。

形如这样的工作，就是在设计一个应用层协议~~
图中下面部分的工作，其实就是在规划请求和响应之间要传递的信息~~

上面我们讲的其实就是在约定传的信息（数据），但是光约定传的信息，还不够，还得约定一个具体的格式~~

现在我们来简单的根据上述的需求，来设计一个自定义的协议（格式）

当前只是给出了一种可能的格式
此处这里数据的组织格式，也是可以随心所欲的约定的~~ （只要能够让客户端和服务器之间都按照一样的格式来交互就行了）

设计一个应用层协议，主要就是包含两个工作
1.明确传输的信息
2.明确数据的组织格式

由于这里的应用层的协议，可以随心所欲的设定，每个人写的也都不一样，这就导致两级分化非常严重！！
1）大佬们设计的协议就非常nice
2）菜鸡设计的协议就非常糟糕~~
例如我们上面设计的那个自定义的协议：
1）输出传输效率并不高，运行效率低
2）可读性也不好~开发效率也低

为了解决掉我们这些菜鸡瞎搞，大佬们发明了一些比较好的协议的模板，可以让我们直接往上套~~

当下比较流行的一些这种协议的模板（数据的组织格式）
1.xml ----可读性好，但是运行效率不高
2.json -----可读性好，但是运行效率不高
3.protobuffer -----可读性不好，但是运行效率很高
4.还有很多很多。。。。

xml

xml~~是属于一种比较老牌的数据格式了
虽然现在也在用，但是用的人越来越少了
xml的格式非常有特点，是由标签构成的
通过这些标签，就更好的体现了这个数据的可读性，尤其是哪个部分是啥意思，一目了然。

虽然xml提高了可读性，但是又引入了太多的辅助信息~~这些标签名啥的。
一个服务器程序，最贵的硬件资源，就是网络带宽（非常滴贵）
对于xml来说，因为要表示这些辅助的信息，就导致传输相同数目的请求的时候，占用的网络带宽是更高的~。
如果你的带宽是固定的话，那么相同时间能传输的请求个数就是更少的。

因此，xml现在很少作为应用层协议的设计模板了~~
现在使用xml主要是作为一些配置文件。

json

当下最流行的一种，设计应用层协议的数据格式，工作中也很常用到这个。

大概的格式如下：

json中表示字符串，单引号或者双引号都可以（和以前学过的SQL类似）
最后一个键值对，后面可以有逗号，也可以没有。

相比于xml，json同样能保证可读性，同时又没有xml那么繁琐（占用带宽少）

protobuffer

上面我们讲到json，虽然json传输效率雀氏比xml更高，但是仍然要多传递一些多余的信息，那就是key的名字
例如：你查询当天的购买记录，你买了蛋炒饭和炒面，按照上面的json的响应格式来说的话，每次都会有name：，price：，这样的key键。如果你买了一万种不一样的东西，那么就有一万个name：和price：这样的键。

当表示一个更复杂的数据，比如数组的时候，此时这里的很多key就会重复出现N次~~
也就占用了跟多的额外带宽

此时protobuffer应运而生

protobuffer 用的是一种二进制格式的数据，
在pritobuffer的数据中，没有上面key键的名字了，而是通过顺序以及一些特殊的符号，用来区分每个字段的含义
同时再通过一个IDL文件来描述这个数据格式，IDL只是起到一个辅助开发的效果，并不会真正进行传输
传输过程只有二进制的纯粹数据

虽然protobuffer中有这些好处， 但是protobuffer并不好调试，如果线上环境出问题，protobuffer全是二进制的数据完全没法肉眼看，如果是json的话，出问题的请求和响应，一目了然。
所以说当下最火的应用层协议其实还是json~~

小结：
设计应用层协议，是一件非常普通的事情，也是一件并不那么容易的事情~
设计应用层协议，要做的工作：
1）明确传输的信息（根据需求）
2）明确传输的格式（参考现有的模板，json，xml，protobuffer）
但是除此之外，业界也有一些现成的，以及被设计好的，已经被广泛使用了的应用层协议
也不是所有的时候，都需要从零设计，很多时候，可以直接基于现成的协议，稍加修改，扩充，进行二次开发
其中最最知名的应用层协议，当属HTTP

传输层协议

虽然传输层，是操作系统内核实现，程序猿不需要直接和传输层打交道，但是传输层对我们来说意义重大！！
进行网络编程都要用到socket，一旦调用socket代码就进入到传输层的范畴~~
如果一切顺利，就还好，一旦代码出现一些bug~~为了解决理解这些bug，传输层的一些知识就是必要的了。

传输层协议有很多，其中最常见的就是UDP和TCP
我们先来了解一下UDP

UDP

首先我们要明确一点：学习一个协议，很多时候就是在研究报文格式~~

所谓的把 应用层数据报分装成UDP数据报，本质上就是在应用层数据包的基础上，添加了8个字节的报头~~

代码中写的端口号，就会被打包成这样的UDP数据报中（在报头中体现）
以UDP客户端为例：

我们来讲讲校验和吧

校验和，是用来验证网络传输的这个数据是否是正确的~~
网络上传递的数据本质 光信号和电信号~
但是，如果有一些外界干扰，磁场之类的。。就可能会导致原有的一些传递的信息发生了改变~~
例如：
正常发一组连续的高频信号~~，因为遇到了一个强磁场，就可能导致其中的某些高频信号变成低频。。
需要尽可能的识别出数据是不是错了，不能将错就错~~
校验和就能帮助我们发现数据中的错误~~

报文长度：

此处报文的长度是两个字节，范围0-65535，0-64k
64k是大还是小呢？够不够用，这是我们该思考的一个问题
其实64k大小在现代互联网程序中，非常捉襟见肘了~~
这是UDP使用中的一个非常致命的缺陷，无法表示一个比较大的数据报

如果确实需要传一个大的数据~~
可以在应用层，针对大的数据报，进行分包（拆成多个部分），然后再通过多个UDP数据报分别发送
这个时候接收方再把收到的几个包重新拼接成完整的数据~~
但是这个显然只是下下策，因为他实在是太麻烦了，拆包组包的代码，写起来非常复杂，要考虑到很多情况（包丢了咋办~包的顺序错了咋办…）

这时候就该学习学习我们的TCP协议了~~

TCP

首先先上图简单介绍以下TCP这个东东，学习协议其实就是在学习这个协议的报文。

TCP中的一些核心机制~~

1）有连接-------- -----能在代码中体现出来
2）可靠传输------------虽然代码上不能直接体现出来，但是这个却是TCP最最核心的机制
3）面向字节流------- 代码中体现
4）全双工------------- 代码中体现

因此TCP中的很多机制，都是围绕这个可靠传输来展开 ，现在我们来追寻可靠传输的脚步来学习TCP的报文结构~

确认应答（保证可靠传输的核心机制）

可靠性：发送方发出去数据之后，能够知道对方有没有收到
关键就是接收方收到消息后，给发送方，返回一个应答报文（ACK，acknowledge），表示自己已经收到了~~

给大家举一个女神的例子让大家明白确认应答的重要性：

上面这种情况，是我们理想的情况，可是网络上，数据接受的顺序，不一定和发送的顺序完全一致，有可能会后发先至！！

为了解决上面的问题，办法其实也很简单~~对消息进行编号

确认序号，表示当前这个应答报文，是针对哪个消息进行确认应答~
对应我们一开始讲的图中的这两个部分
TCP的针对消息的序号，还有说法，并不是按“消息条数”来进行编号的，而是按照字节来编号~

超时重传

相当于对确认应答进行了补充~
确认应答是网络一切正常的时候，通过ACK通知发送方我收到了
如果出现了丢包的情况，超时重传机制就要起到效果了~

当我发出去消息之后，就担心这个消息是不是发丢了
所以我就在等这个ACK
如果确实发丢了，对方直接就没收到，我这里肯定也没法收到ACK。

这个时候可能就有小伙伴要问了：超时重传，重传的数据，一定会成功嘛？答案当然不是百分之100，如果只是因为网络抖动了一下，这个时候重传还是很容易成功的~~如果是网络遭受了严重的伤害（在这个情况下，重传不会一直进行），可能没那么容易恢复，重传也成功不了了，网线断了/没有网费了。。。

重传如果失败，可能还会再继续尝试，但是也不会无休止的重传
连续几次的重传都不行，就认为这个网络可能是遇到了严重的情况~
再怎么重传怕也是不行了，就只能放弃了（自动的断开TCP的连接）

基于上面两种机制
1）确认应答
2）超时重传
TCP的可靠性，就得到了有效的保障~~

连接管理（非常经典的面试题）

也是保证TCP的可靠性的一个机制

TCP连接管理，是网络部分最高频的面试题，没有之一！！！

1）如何建立连接

三次握手
客户端和服务器之间，通过三次交互，完成了建立连接的过程“握手”是一个形象的比喻~


简单举一个例子解释一下什么是三次握手（确保互相能联系上）：
有一天你和你老表打电话：你说老表你能听见我讲话吗？（SYN）
老表说：我能听见（ACK），你能听见我讲话吗？（SYN）
你对你老表说：老表我能听见（ACK），待会出来上网~
1）第一张图中的ACK和SYN大家有没有眼熟呢~~，
2）其实就是我们上面讲的TCP报文结构中存在的（忘记了的小伙伴可以翻上去看看）
3）如果ACK这一位为1，表示这个报文就是一个“确认报文段”（刚才说的确认应答报文，也是ACK为1）
4）如果SYN这一位为1，表示当前报文就是一个“同步报文段”主机A和主机B之间要建立连接~~

上面的过程还是比较复杂的，我们面试中，如果面试官问到这个问题，尽量还是不要画这个图给面试官看，毕竟这个图是属于比较细，当然出错的机率也就

更高，为了防止自己把自己给坑了~我建议大家使用下面第二个图：
这个过程就像表白哈哈~~，双向奔赴的过程，双方都向对方表白，这才算是正式确立关系。
其实图中中间的这两次，是一定会合二为一的！！！
每次要传输的数据，都要经过一系列的封装和分用，才能完成传输~（我在某淘宝店铺买了两件衣服，肯定是打一个包裹发给我更好）

经典面试题：

1）描述TCP三次握手的过程

针对这个问题，不要用嘴说！！！要画图~~
如果是线上面试（牛客），面试平台一般都是支持在线画图的~~
如果是线下面试，一定要记得带上纸笔噢~

2）为啥握手是三次 不能两次？四次？

首先，两次是绝对不行的，意味着缺少最后一次，此时客户端这边关于发生接受能力正常的情报是完整的，但是服务器这边是残缺的，服务器不知道自己的发生能力是否ok，也不知道客户端的接受能力是否ok~
其次，我如果是四次，行，但没必要，分开传输降低效率，不如合在一起好。

2）如何断开连接

四次挥手
三次握手，就让客户端和服务器之间建立好了连接~~
其实建立好连接之后，操作系统内核中，就需要使用一定的数据结构来保存连接相关的信息！！保存的信息其实最重要的就是前面说过的“五元组”
而且客户端服务器都得保存五元组~~
源IP，源端口，目的IP，目的端口，TCP
既然是保存了信息就需要占用系统资源（内存）

有朝一日，连接断开了~~（不复存在）
此时之前保存了连接信息就没意义了，对应得空间也就可以释放了~~

面试时也是画这个图就足够~~

双方各自向对方发送了FIN（结束报文）请求，并且各自给对方一个ACK确认报文~~

虽然面试时，我们画上面第一个图就行，但是在平时的学习中，我们还是尽量多学一点，有时间就该多学，合情合理嘛
关于状态转换的两个重要的状态：

CLOSE_WAIT
:四次挥手挥手了两次之后出现的状态，这个状态就是在等待代码中调用socket.close方法，来进行后续挥手的过程~，正常情况下，一个服务器上不应该存在大量的CLOSE_WAIT，如果存在，说明大概率是代码bug，close没有被执行到。

TIME_WAIT：
谁主动发起FIN，谁就进TIME_WAIT，起到的效果，就是给最后一次ACK提供重传机会~
表面上看起来，A发送完ACK之后，就没有A的啥事了~
按理说，A就应该销毁连接，释放资源了~~但是并没有直接释放，而是会进入TIME_WAIT状态等待一段时间，一段时间之后，再来释放连接，
等这一会儿的原因就是怕最后一个ACK丢包！！！如果是最后一个ACK丢包了，就意味着B过一会就会重传FIN~

那么可能有小伙伴又要问了：TIME_WAIT在这儿应该持续多久呢？是一直在傻傻的等待吗？
答案显然不是，这儿我们要了解一下TIME_WAIT设定的时间其实是2*MSL。
MSL表示网络上任意两点之间，传输需要的最大时间~
如何理解这个最大时间呢？
举一个简单的例子吧：
我的小外甥放五一长假了~但是我忘记啥时候开学了，我估测5月4号开学，于是我那天带她去学校，我告诉他叫他进去先看看有没有在上课，如果没有上课你就出来，在上课的话就不用出来了。于是我外甥就屁颠屁颠进去了。过了4分钟，还没出来我大概知道今天是要上课了，因为学校大门到教室的距离也就两分钟。

滑动窗口

TCP中的可靠性虽然是最高机制，但是TCP也会尽可能的提高传输效率

在这里可以看到，由于确认应答机制的存在，导致了当前每次执行一次发送操作，都需要等待上个ACK的到达，大量的时间都花在等ACK上了~

滑动窗口，本质就是在“批量的发送数据”一次发一波数据

1）窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000
个字节（四个段）。
2）发送前四个段的时候，不需要等待任何ACK，直接发送；
3）收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
4）操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有
应答；只有确认应答过的数据，才能从缓冲区删掉；
5）窗口越大，则网络的吞吐率就越高；

有了滑动窗口来帮助TCP提高传输效率，但是也有一个新的问题存在了：丢包~，在滑动窗口的背景下，如果丢包，该如果重传呢？

ACK丢了

如果中间的ACK丢了，其实是无足轻重的~

在这个图中，画的就是6组ACK，丢了三组~
在发送4001之前，发现收到一个2001，此时没有收到1001，2001表示的意思就是：2001之前的数据都已经确认收到了，1001能否收到就已经无足轻重了~~
ACK确认序列的特定含义，就保证了后一条ACK就能涵盖前一条。

数据丢了

核心就是利用超时重传：

在A重传1001-2000之前，B的接受缓冲区如右图

当A重传了1001-2000之后，B的接受缓存区，就把缺口给补上了，后续的2001-7000这些数据都是已经传输过了的~这些数据就不必再重传，接下来B就要向A索要7001开始的数据

这里的重传其实是一种快重传，只需要把丢了的那块数据给重传了即可，其他已经到了的数据就不必再重传了，整体的重传效率还是比较高。

流量控制

是上述的滑动窗口的延伸，目的是为了保证可靠性

在滑动窗口中，窗口越大，传输速率就越高，不光要考虑发送方，我们还得考虑接收方。

发送方发的太快，接收方可能根本就处理不过来，接收方就会把新收到的包给丢了，发送方又还得重传。。

为了解决上面的问题，流量控制机制就出现了，流量控制的关键，就是得能够衡量接收方得处理速度，此处就直接使用接收方接受缓冲区的剩余空间大小，来衡量当前的处理能力。

接收方的应用程序，在调用read方法的时候，就是在从接受缓冲区中（理解成一个阻塞队列）来取数据~
这样的数据传输过程，可以理解成“生成消费者模型”
A就是生产者
B的应用程序就是消费者
B的接收缓冲区，就是交易场所~
接收区肯定有一个总大小，随着A发送数据，接收缓冲区里就会逐渐放入一些数据，剩余空间就是逐渐缩小。
如果剩余空间比较大，就认为B的处理能力比较强，就可以让A发的快点。
如果剩余空间比较小，就认为B的处理能力是比较弱，就可以让A发的慢点。

那么接收方又如何告知发送方，剩余空间有多大呢？
这就又回到最初的TCP报文结构中了

这时候可能又有小伙伴提出疑问了：
要是当接收方为0，那么发送方又是如何处理的呢？

虽然B反馈的窗口大小是0，但是A也不能完全不发数据，其实还需要定期发送一个探测报文，探测报文不传输实际的数据，只是为了触发ACK，为了知道当前窗口大小是多少。

拥塞控制

也是滑动窗口的延申，也是限制滑动窗口的发送的速率

拥塞控制衡量的是，发送方到接收方，这整个链路之间，拥堵情况（处理能力）
虽然TCP有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大
量的数据，仍然可能引发问题。
因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发
送大量的数据，是很有可能引起雪上加霜的。
TCP引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传
输数据；

具体这个拥塞窗口是如何变化的呢？一图读懂：

延时应答

相当于流量控制的延伸~~
流量控制是踩下了刹车，使发送方，发的不要太快
延时应答，就想在这个基础上，能够尽量的再让窗口更大些~

这里可以理解为，发送方为输入水的一方，接收方为蓄水池。

上面的图是我们讲过的流量控制的模型，下面我们来讲延时应答的模型：

可能很多人不理解这个延时应答，给大家举一个例子：
我们上高中或者初中的时候，是不是老师经常催交作业阿，一般都是从第一排收作业开始往下，这时候你发现你作业压根没动笔，但是你和学习委员关系好，你就可以先叫他先去收后面的人，最后再来收你的作业，这时候等作业收完之后，你已经补了很多了，至少不会接受到老师的毒打、

捎带应答

又是延时应答的延伸

因为延时应答的存在，导致ACK不一定是立即返回的！！
如果当前的延时应答，导致了ACK的放回时机和应用代码中放回的响应时机重合了！！！就可以把这个ACK和响应数据合二为一。

面向字节流

TCP粘包指的是粘的是应用层数据报，在TCP接受缓冲区中，若干个应用层数据包混在一起了，分不清谁是谁了~

TCP的异常处理

1）进程终止

在进程毫无防备的情况下，偷袭他哈哈，突然结束进程~~这个时候该进程的TCP连接是咋样的呢？

其实，TCP连接，是通过socket来建立的，socket本质上是进程打开的一个文件，文件其实就存在于进程的PCB里面的文件描述表（在之前的博客中也详细讲过）
每次打开一个文件（包括socket），都在文件描述表里，增加一项
每次关闭一个文件，都在文件描述表里，进行删除一项
如果直接杀死进程，PCB也就没了，里面的文件描述表也就没了~~此处的文件相当于“自动关闭”了
这个过程其实和手动调用socket.close（）一样，都会触发四次挥手

2）机器关闭

按照操作系统约定的正常流程关机~ 正常流程的关机，会让操作系统，杀死所有进程，然后关机。

3）机器掉电/网线断开

台式机，直接拔掉电源~偷袭成功，操作系统不会有任何反应时间，更不会有任何的处理措施，

总结

TCPvsUDP对比

1.啥时候使用TCP？对可靠性有一定要求~~（日常开发中的大多数情况，都是基于TCP）
2.啥时候使用UDP？对可靠性要求不高，对于效率要求更高（典型的例子，机房内部的主机之间通信，分布式系统中）

网络层协议

可算是到网络层协议了~
IP协议~
完成两方面工作：

1）地址管理
2）路由选择

1)地址管理

首先还是老规矩：学习一个协议，本质上就是在研究协议的报文

4位版本：IP协议的版本号，当前只有两个取值，4和6，当前我们主要讨论的是IPv4
2）
4位首部长度~IP的报头和TCP类似，都是可变的，带有选项，4位的取值范围0-15，这里的单位也是4字节，如果取值是1111=》15，实际表示的首部长度就是60字节

3）
TOS说是8位，其实只有四位是有效的，四位TOS分别表示：最小延时，最大吞吐量，最高可靠性，最小成本。（同一时刻，只能取一种状态）
这里的TOS相当于是切换形态~~（类似于变身迪迦）
4）
16位总长度，UDP好像也有类似的情况~16位=》最大长度64k因此，单个IP数据报最大长度确实不能超过64k，如果要构造一个更长的数据报（比如搭载的载荷部分已经超过64k了咋办？）
其实IP协议自身就实现了分包和组包这样的操作
5）

这三个字段就是用来进行分包和组包的~

如果整个IP数据报太长了，IP协议就会把这个大包拆成多个小包，保证每个包都不超过64k

6）

表示一个IP数据报，在网络上还能存在多久~
这里的单位补上s或者ms，而是转发次数
IP数据报被发送的时候，会有一个初始的TTL（比如常见的取值，128或者64）
IP数据报每次经过了一个路由器，TTL就会-1
如果TTL减少到0了，此时收到这个包的路由器就会把这个包给丢弃
主要就是因为有些包里面的IP地址，可能是永远也到不了的，像这样的包，不可能在网络上无休止的转发（占用的硬件资源太多）
正常的IP数据报都会在既定的TTL内到达

7）

这个主要是说明传输层使用的是哪种协议
TCP或者UDP都有不同的取值~~
8）

也是用来校验数据是否正确
9）

源IP表示发件人地址，目的IP表示收件人地址
对于IPV4来说，一个IP地址本质上是32位的整数~~
通常会使用“点分十进制”这样的方式来表示这个IP地址
三个点，把32位整数分成4个部分，每个部分1个字节
，每个部分的取值就是0-255

给人看的IP通常就是点分十进制表示的
给机器存储的IP，在底层仍然是按照4个字节整数来表示


到底前多少个bit位是网络号？咋规定的呢？固定三个字节吗？
其实是不固定的！！

如何解决这个IP地址不够用的情况

了解一下一些特殊的IP地址

大家也可以查查自己的IP地址：

大家直接百度就可以，查查自己的IP，（最近抖音不是很火嘛，查id哈哈哈）你家里也可能有个设备是这个IP，因为内网IP是可以重复的。
本来我们预期IP地址应该就表示一个网络上的唯一地址，结果这咋同一个IP能表示不同的设备呢？
当前IPv4协议，使用的IP地址是32位的整数，32位能表示的数据范围大概是42亿9千万
如果给每个设备都分配一个唯一的IP地址，意味着世界上的设备就不能超过42亿9千万
随着网络的发展，现在世界上设备越来越多，已经超过了42亿9千万，让每个设备都有唯一的IP地址，已经有点不太现实了~~

那么如何解决的这个问题的呢？

1.动态分配IP地址

让每个设备连上网的时候，才有IP，不连接网的时候就没IP（这个IP就可以给别人用）但是这个方案不能从根本上解决问题（设备没有减少，IP地址也没有增加）这个方案只能说治标不治本。

2.NAT机制

让多个设备共用同一个IP（外网IP）
把网络分成了内网（局域网）和外网（广域网）
要求外网IP必须表示唯一设备
同时内网中的若干设备，可以共用一个外网IP！！
这个时候每个外网IP都可以表示着几千个，甚至上万个设备
这个时候IP地址的压力就缓解了很多了~

NAT机制，把IP分成了内网和外网，也就隐含了一个重要的结论：
1）对于一个外网IP，可以在互联网的任意位置都能访问到
2）对于一个内网IP，只能在当前局域网内部访问，局域网1的设备，不能使用内网IP访问局域网2的设备~~（内网IP可以重复出现，只有在当前局域网内才是唯一的。）

给大家举一个例子把：
我自己的这个IP只有在我自己的家里的局域网才能访问到，你们想跨越局域网来访问我的这个IP是不现实的。
如果我们之间想通信怎么办呢？
就需要一个带有外网IP的机器，这里其实就是CSDN服务器
CSDN服务器是有外网IP，我们都能访问CSDN，

如果没有NAT（如果所有的IP都是唯一的）就可以做到，不通过CSDN，我直接在我自己的电脑上架设一个服务器，大家直接访问我的IP就行了。

NAT只是续命了一波，但是不是从根本上解决问题。

IPV6

IPV6在报头中使用了一个更长的字段来表示IP地址，16个字节，128位，号称IPV6可以给地球上每个沙子都分配一个IP地址
IPV6是真正从根本上解决了IP地址不够用的问题！！

既然IPV6这么香，为啥现在还是在用IPV4+NAT呢？

这里最大的问题在于IPV6和IPV4是不兼容的！！
对于一个设备来说，支持IPV4和IPV6需要两个截然不同的机制，现有的大量的网络设备（路由器。。）很可能都是只支持IPV4，不支持IPV6。
因此，现在很多的公司要想升级IPV6，就得更换设备~~换设备就得加钱，很多公司就不想升级，因为要花很多钱这个钱谁都不愿意出，大部分的想法都是：IPV4又不是不能用，凭啥让我掏钱？
最近几年大部分企业在国家的推动下还是紧跟热潮，都开始紧锣密鼓的升级IPV6，现在中国的IPV6普及程度已经非常非常高了，主流的服务应用，大的运营商，不是特别特别偏远的地区，都已经升级的差不多了。

2）路由选择

路由选择，也就是规划路径，两个设备之间，要找到一条通道，能够完成传输的过程。

IP协议的路由选择就和你平时问路一样，先走到你认识的路，你知道大概的方位，但是不确定，然后不认识的路就找人问，就这样一步一步直到走到目的地。
在IP协议中，IP数据报中的目的地址，就表示了这个包要发到哪里去~
这个目的地址，如果当前路由器直接认识，就直接告诉你路，如果当前路由器不认识，就会告诉你一个大概的方向，让你走到下一个路由器的时候再来问问，依次往后走，其实也是在离目标越来越近，这个时候总会遇到一个认识这个地址的路由器，于是就可以具体的转发过去~
有时候不光能遇到一个认识这个地址的路由器，并且他还认识多个路~~就可以选一个更合适的路了。

啥叫路由器认识这个IP地址呢？？
其实在路由器内部维护了一个数据结构，路由表
路由器里面就记录了一些网段信息~~（网络号），（目的IP就再这些网络号中匹配）以及每个网络号对应的网络接口（网络接口其实就对应到路由器里面具体的接口）

数据链路层协议

数据链路层的主要协议，叫做“以太网”，像我们平时我们插的网线，就叫做“以太网线”

以太网这个协议不仅仅规定了数据链路层的内容
也规定了物理层的内容~~

当然还是老规矩，学一个协议，本质上就是在学习他的报头。以太网的数据帧的格式非常简单，比TCP和IP都简单很多。

通过6个字节来表示源地址和目的地址~
这个就要比IPV4更长，长了6w多倍
这里的地址被称为“mac地址”，mac地址做到了每个设备都是唯一的（每个网卡都是唯一的）是在网卡出厂的时候就写死了~

很多人不理解为啥已经有了IP地址还要有个物理地址（mac）呢？

其实这里只是一个美好的误会！！
当年网络层协议和数据链路层协议，是各自独立研发出来的
mac地址和IP地址，就有点重复了（一般来说一套地址就够了）
现在的现状呢，就是当前mac地址和IP地址同时使用，表示不同的功能~~
IP地址用来表示一次传输过程中的起点和终点（不考虑NAT的情况，一个IP数据报中的源IP和目的IP是固定的）
mac地址用来表示传输过程中，任意两个相邻节点之间的地址（一个以太网数据帧，在每次转发的过程中，源mac和目的mac都会改变）

继续来讲讲以太网数据帧中的内容：

ARP协议

虽然我们在这里介绍ARP协议，但是需要强调，ARP不是一个单纯的数据链路层的协议，而是一个介于数据链路层和网络层之间的协议；

ARP报文并不是用来传输数据的，只是起到一个辅助的效果

路由器这样的设备在转发数据的时候，首先拿到的是一个IP地址（目的IP），通过IP地址来决定接下来这个数据咋走（从哪个端口出去，发到哪个设备上），因此就得决定，接下来封装的以太网数据帧，目的mac是啥，需要根据ARP协议建立起IP->mac这样的映射关系，当设备启动时，就会向局域网中，广播ARP报文，每个设备收到之后，都会给出一个应答，应答的信息中就包含了自己的IP和mac，发起广播的那一方，就可以根据这些回应，建立起这个映射表了。