image

IP 分类的优缺点

优点：简单、选路方便

缺点：

  • 同一网络下，没有层次
  • 不能很好与现实匹配（对于 B 类地址，主机号太多，一个企业难以用完，造成浪费；对于 C 类地址，主机号太少，不够用）

这些缺点均在 CIDR 编址解决

IPv6 基本认识

标识方法

IPv6 使用 128 位编码，每 16 位为一组，每组之间使用 : 隔开

例如：fe80::18f9:e2fe:e673:fe24

类型

  • 回环地址
  • 链路本地单播地址：不经过路由器转发
  • 唯一本地地址：相当于 IPv4 的私有 IP
  • 全局单播地址：相当于 IPv4 的公有 IP
  • 多播地址

图片来自小林 coding

首部

  • 删除了首部校验和字段
  • 删除了是否允许分片字段
  • 删除了选项字段

亮点

  • 可以为很多主机分配一个 IPv6 地址，不用担心用不完
  • 由于可分配的地址很多，可以避免多层 NAT 带来的性能开销
  • 删除了是否允许分片字段，避免在路由器分片带来的性能开销
  • 可自动配置，不需要 DHCP 服务器

IP 相关技术

ARP

ARP 协议用于：根据 IP 地址获取对应主机的 MAC 地址

由于数据的传输需要经过 IP 层 => 数据链路层

而数据链路层是 点对点 的，知道下一跳的 IP 还不行，必须知道下一跳的 MAC 地址，这样数据链路层才能知道该发给谁

ARP 协议获取 MAC 地址的大致流程：

  • 根据 IP 发送 广播 ARP 请求
  • 子网内，每个逐渐会检查自己的 IP 地址与请求的 IP 地址是否一致，如果一致，该主机会广播自己的 MAC 地址
  • 收到 MAC 地址后，请求方缓存 IP 到 MAC 的映射关系

还有一种协议：RARP

与 ARP 相反，RARP 用于：一个主机根据自己的 MAC 地址，获取自己的 IP 地址

DHCP

DHCP 协议提供一种机制：即插即用联网。用户可以在不手动配置的情况下，自动配置 IP 等信息

DHCP 有如下几种报文：

  • DHCP DISCOVER：服务发现报文
  • DHCP OFFER：提供配置信息
  • DHCP RESQUEST：请求使用配置
  • DHCP ACK
  • DHCP NACK
  • DHCP RELEASE：释放配置

使用 DHCP 的过程如下：

DHCP 协议是基于 UDP 的，在获取到 IP 之前，源 IP 为 0.0.0.0

问题来了，由于路由器不会转发广播请求，那每个子网都要一个 DHCP 服务器吗？

如果这样，比较浪费，实际处理时，会引入 DHCP 中继代理

每个子网都有一个 DHCP 中继，多个 DHCP 中继可以请求同一个 DHCP Server

NAT

IPv4 只有 32 位，再加上分类编址，实际可用的 IP 数不能满足目前的需求

于是出现了 NAT 技术来 缓解 这个问题

NAT 可以将一个子网内的私有 IP 映射到同一个公网 IP

但是，当子网内有一个设备正在使用 NAT 时，其它设备就得 等待 该设备释放 NAT Server 的资源

NAPT

NAPT 就是用来解决上面 串行化 的问题的

大部分应用使用的都是 TCP、UDP 协议，这意味着是 IP + Port 的形式

NAPT 就是引入了 端口 这个概念，实现一个公网 IP + Port 映射多个私有 IP + Port

缺点

但是，NAPT 仍然存在缺点：

  • 外部无法主动向子网内部建立连接
  • 通信过程中，如果 NAPT Server 挂了，那么 所有的 TCP 连接都将被 重置
  • 转换过程存在 性能开销：实际应用通常有多层 NAT 转换（大内网）

如何解决这些缺点？

  1. 使用 IPv6，源头上解决问题
  2. NAT 穿透

NAT 穿透：NAT 内层设备获取 NAT Server 的公网 IP，并手动添加映射

ICMP

ICMP（Internet Control Message Protocol），工作在网络层，用于：

  • 确认数据报是否到达
  • 报告数据报丢弃原因

ICMP 有两大类型：

  • 查询报文类型：包含 Echo Request 和 Echo Reply 类型
  • 差错报文类型：用于报告错误原因

Ping — 基于 ICMP 查询报文

执行 Ping 命令，实际上用到了 ICMP 的 Echo Request 和 Echo Reply 类型

IP 首部有一个 TTL 字段，每经过一跳，TTL 减一

当 TTL 为 0，路由器将会抛弃该报文

  • 执行 ping 命令，发送 icmp echo request
  • 如果目的主机收到 icmp echo request，会回复 icmp echo reply
  • 如果本机收到 reply，说明目的主机可达
  • 如果本机超时未收到 reply，说明目的主机不可达

traceroute – 基于 ICMP 差错报文

差错报文包括：

  • 目标不可达
  • 原点抑制：如果网络拥塞，返回原点抑制报文（不常用）
  • 重定向：如果有更短的路径，返回重定向报文（包含更近的路由信息）
  • 超时

目标不可达包括：

  • 网络不可达
  • 主机不可达
  • 协议不可达
  • 端口不可达
  • 需要分片，但是首部设置不允许分片

traceroute 的使用场景

==追踪从原主机到目的主机到路由信息==

Sky_Lee@SkyLeeMacBook-Pro IP % traceroute baidu.com
traceroute: Warning: baidu.com has multiple addresses; using 39.156.66.10
traceroute to baidu.com (39.156.66.10), 64 hops max, 52 byte packets
 1  192.168.0.1 (192.168.0.1)  1.981 ms  1.303 ms  1.055 ms
 2  192.168.1.1 (192.168.1.1)  2.001 ms  1.796 ms  1.740 ms
 3  100.69.0.1 (100.69.0.1)  5.775 ms  8.928 ms  5.350 ms
 4  110.190.151.153 (110.190.151.153)  7.396 ms
    110.190.151.165 (110.190.151.165)  6.344 ms
    110.190.151.153 (110.190.151.153)  5.360 ms
 5  * 110.188.7.25 (110.188.7.25)  9.507 ms
    171.208.196.125 (171.208.196.125)  13.722 ms
 6  * * *
 7  202.97.74.226 (202.97.74.226)  37.816 ms
    202.97.17.74 (202.97.17.74)  37.063 ms

原理：

  • 第一次的 TTL 设置为 1，到第一个路由器，TTL 为 0，返回超时差错报文
  • 第二次的 TTL 设置为 2，到第二个路由器，TTL 为 0，返回超时差错报文
  • ……

那么，traceroute 怎么知道是否到达目的主机？

traceroute 在发送 UDP 包的时候，为了避免目标误以为这是一个正常的 UDP 通信请求，通常会设置一个不太可能被应用程序使用的较大的端口号值作为目标 UDP 端口号。

当目的主机收到这个 UDP 包，会返回一个 ICMP 端口不可达报文

因此，当 traceroute 收到 ICMP 端口不可达报文，说明到达目的主机

如果目的主机恰好监听了这个端口呢？

这个行为是未定义的

==路径 MTU 发现==

原理：

  1. 发送端将要传输的数据包大小设置为本地主机的 MTU 大小，并且设置为 不允许分片
  2. 数据包经过第一个路由器时，如果该路由器的 MTU 小于数据包大小，那么该路由器会丢弃该数据包，并发送一个 ICMPFragmentationNeeded（需要分片，但是首部设置不允许分片） 消息给发送端。
  3. 发送端收到 “ICMPFragmentationNeeded” 消息后，会根据该消息中指示的最小 MTU 大小，将数据包大小缩减为最小 MTU 大小，并重新发送。
  4. 经过多个路由器的重复上述过程，直到数据包能够成功传输到目的主机。