概述
在计算机网络这门课中, 往往是将各层协议拆开一章一章的讲, 每层协议是干嘛的, 都各种怎么工作的. 但如果有人问, 这些协议之间怎么协调工作, 有什么关系, 往往处于懵逼状态.
网络分层
网络为什么分层, 其实理解很简单, 复杂的东西都要分层. 就像写代码, 有 Controller 层, service 层, dao 层等, 如果这个代码很复杂, 都写在一个类里里, 不利于你后期维护(可能过两天你自己都看不懂了), 和同事之间的交流沟通也不方便. 所以复杂的程序都要分层, 这是基本的程序设计要求.
这是一次用户发起的请求, 浏览器用 http 协议打包用户的请求, 然后传给下一层, 调用下一层函数, 这个函数会在这个网络包里加上一个 TCP 头, 记录下源端口号, 目的端口号, 然后在调用下一层的函数, 这个函数会加一个 IP 的头, 记录源 IP 地址和目标 IP 的地址, 然后在调用下一次函数, 这个函数又加了一个本机器的 Mac 地址和目标 Mac 地址. 这个数据包完整后, 就可以从网口发出去.
网卡检测到这个网络包的目的地址是指向自己的, 把这个数据包拿进来调用一段函数来处理这个网络包, 把属于这层的东西剥离出去, 然后调用另一层的一个函数 (process_layer3()) 来处理这个网络包. 这一层检测一下, 目标 IP 是不是对上自己的 IP, 如果 IP 对不上, 就转发出去, 若是对上 IP, 取下属于这层的 IP 头, 在调用下一层的函数来处理. 那是调用 TCP 函数还是 UDP 的函数处理哪, 这个就得看协议字段, 我这次请求是 TCP 的, 就调用 TCP 的函数取下 TCP 头, 然后查看这是一个发起, 还是应答, 或者是一个正常数据包, 如果是发起或者应答, 还需要发送一个回复包, 若是一个正常数据包, 根据端口号就直接交给应用去处理, 然后浏览器解析 html, 用户现实界面.
网络上跑的包, 都是完整的, 可以有下层没上层, 绝对不可能有上层没下层. 这有点类似于俄罗斯套娃, 一层连着一层, 一开始是个很小的套娃, 套一层又套一层, 套完后就是一个完整的套娃. 网络世界中也是一样的, http 层数据包, 在套上 TCP 层, 在套上 IP 层, 又套上 Mac 层, 所有机制都得运行一遍才能成功从网口发出去.
IP
不管学没学过计算机, 一定都会听到的词 ===>IP. 有没有想过, Mac 地址就可以标识电脑了, 还要 IP 干嘛, 我刚开始也模糊, 后面才逐渐有点头绪(但现在也不知道理解是否全对, 毕竟计算机网络小白).Mac 地址与设备是一 一对应在局域网内是唯一的, 如果在局域网内, Mac 地址直接通信是没有问题的, 每次有消息的时候, 各个主机都接收一下, 对照下是不是自己的 Mac 地址, 如果不是, 就直接丢弃, 对上就接收并处理. 但是每次有消息都得接收和处理有点费事, 于是出现了交换机, 交换机记录所有与之连接的 Mac 地址并与端口一一对应, 现在 A 主机发消息给 B 主机并带上 B 主机的 Mac 地址, 现在先到交换机这里, 交换机查下记录的 Mac 对照表, 哦, 原来你要找 B 主机, 就按照这个端口发给 B 主机. 为什么会有 IP 哪, 以太网 Mac 地址就可以通信了, 但后来有了互联网, 兼容以前的模式才有了 IP + Mac 的通信模式, 长春这边的局域网有台 A 主机要与北京的局域网一台 B 主机通信. 长春的交换机记录了 A 主机的 Mac 地址, 可能还记录了北京交换机的 Mac 地址, 北京交换机记录了要通信的 B 主机 Mac 地址. 现在 A 给交换机发消息, 我要找 B 主机, 很遗憾, 交换机找不到 B 主机, 因为不是一个局域网内, 交换机没记录这个 Mac 地址, 没法通信.
Mac 地址是硬件提供商写在网卡中的, Mac 地址是唯一, 但没办法表示我在互联网的位置, 除非维护一个超级大的 Mac 地址对应表, 那寻址效率必定爆炸, 而且获取 Mac 地址是 ARP 协议完成的, 只用 Mac 地址通信广播风暴就是很难克服的问题, 但 IP 地址解决了这个问题, IP 地址是网络提供商给的, 你在哪里整个网络都是知道的(类似于定位功能), 找到你这个网络, 在这个网络环境找到你的 Mac 就显得容易得多. 但是 IP 地址不总是唯一的, 可能我今天在长春这个网络环境, 我下线了, 我这个 IP 就会动态分配给别的设备, 明天到了北京, 又动态分了一个 IP 地址, 然而我的 Mac 地址总是固定且唯一的, 通过这个我网络 IP 地址和 Mac 地址就很容易找到我.
ip addr
查看 ip 地址, 192.168.181.110 就是一个 IP 地址, 总共有四个部分, 每部分有 8 位, 总共有 32 位, 理论上可以有 42.9 亿个 IP 地址, 然而这些显然不能满足日益增长的计算机 IP 需求, 因为不够用, 所以有了 IPV6, 也就是我们的 fe80::20c:29ff:feb6:4146/64, 这个有 128 位, 有生之年都不可能分配完, 据说可以给地球的每粒沙子分配一个 IP, 就可以想象有多少 IP 地址了. IP 地址是一个网卡在网络世界的通讯地址, 也相当于现实世界的门牌号码, 所以不能重复, 它包括两个标识码 (网络 ID + 主机 ID). 在同一个物理网络上的所有主机都使用同一个网络 ID, 网络上的主机(路由器, 服务器等) 有一个主机 ID 与其对应, 早期 IP 地址为了便于寻址和层次化构造网络, 把 IP 分为 5 种类型, 即 A,B,C,D,E 类地址.
A 类
A 类的地址, 8 位网络地址, 和 24 位的主机地址组成. 地址范围 1.0.0.0 -> 126.255.255.255,A 类网络有 127 个, 每个网络能容纳 16777214 的主机.
B 类
B 类的地址, 16 位网络地址, 和 16 位的主机地址组成, 地址范围 128.0.0.0 -> 191.255.255.255,B 类网络有 16382 个, 每个网络可以有六万多主机
C 类
C 类的地址, 24 位的网络地址, 和 8 位的主机号, 地址范围 192.0.0.0 -> 223.255.255.0,C 类网络有 209 万个, 每个网络只能有可怜的 254 个主机
D 类
D 类的地址, 从图中就可以看到, 不分网络地址和主机地址, 被称为广播地址, 供特殊协议向选定节点发送消息时用, 第一个字节是固定的 1110, 地址范围 224.0.0.0 ->239.255.255.255
E 类
E 类的地址, 保留将来使用. 240.0.0.0 -> 255.255.255.254
特殊地址
大家在使用本地测试访问经常用到的 127.0.0.1 表示主机本身, 是一个回环测试地址.
在阿里云服务器使用监听地址 0.0.0.0 会有这样的设置, 他在 IPV4 表示的是无效的目标地址, 但在服务器端上它表示本机上所有的 IPV4 网段都能访问该服务
在 A,B,C 类地址中, 各自保留一个区域作为私有地址
A 类: 10.0.0.0 -> 10.255.255.255
B 类: 172.16.0.0 -> 172.31.255.255
C 类: 192.168.0.0 -> 192.168.255.255
CIDR
在一个网吧用 C 类的 IP 地址, 恐怕地址都不够, 但是若是用 B 类地址, 又是一种浪费. 于是出现一个折中的办法, 那就是无类域间路由, 简称 CIDR. 给某个网络分配 3 个 C 类地址, 然后适当的方法分配地址, 使得 3 个地址能够聚合成一个地址. 如果没有 CIDR 技术, ISP(地址网络提供商)的路由表就会有三条路由条目, 但如果有了 CIDR 技术, 就可以把这三个网段 198.168.1.0 198.168.2.0 198.168.3.0 汇聚成一条路由 198.168.0.0/16, 这样 ISP 的路由表就只记录了一条 198.168.0.0/16 这一条路由, 减少了路由表的条目, 但若是 ISP 连接了一个 172.168.1.0 的网段, 这些网络路由就没办法汇聚. CIRD 节省了存储空间加快了查询速度. 所以, 现在都是用 CIDR 表示, 为此引入子网掩码的概念, 就是说网络位的个数可以任意指定, 同时也兼容早期 IP 划分的方法. 它将某个 IP 地址划分成网络地址和主机地址两部分, 子网掩码是一个 32 位地址, 用于屏蔽 IP 地址的一部分, 它不能单独存在, 必须结合 IP 地址一起使用, 198.168.0.0/16 这个 16 就是指网络位有多少, 在二进制格式中的网络位全为 1, 然后将二进制格式的子网掩码和二进制的 IP 地址进行 '与' 运算, 就可以得出该 IP 的网络位.
IP 地址: 192.168.181.111 二进制: 11000000 10101000 10110101 01101110
子网掩码: 255.255.255.0 二进制: 11111111 11111111 11111111 00000000
运算: & 11000000 10101000 10110101 00000000
结果: 192.168.181.0
这就是网络号了
总结
简单的总结合和回忆了对 ip 的理解, 虽然是基础知识, 但是 lz 真的是计算机网络小白, 也不知道是否理解准确, 有大神有这方面的知识储备, 是否可留言讲解下 IP.
参考: https://www.jianshu.com/p/e7989a7a0e96
来源: https://www.cnblogs.com/dslx/p/10753382.html