IP 协议报头结构
4位版本
实际上只有两个取值
4
==>IPv4
(主流)6
==>IPv6
IPv2
,IPv5
在实际中是没有的,可能是理论上/实验室中存在
4位首部长度
IP 协议报头也是变长的,因为选项个数不确定,所以报头长度也不确定。因此就需要使用 4 位首部长度进行区分
4 位首部长度范围:0~15,所以报头长度 *4
才是实际的长度
- 当报头长度为 15,则实际报头长度为
15*4=60
8位服务类型
type of service
3位优先权字段(已经弃⽤),4位 TOS
字段,和 1位保留字段(必须置为 0)。4位 TOS
分别表⽰:
- 最⼩延时:从 A 到 B 的时间消耗更少
- 最⼤吞吐量:从 A 到 B,单位时间内传输的数量更多
- 最⾼可靠性:数据丢包概率更小(IP 协议并不想 TCP 那样有严格的可靠性)
- 最⼩成本:设备上消耗的资源更少
这四者相互冲突,只能选择⼀个。其中一个为 1,那么其他的都得为 0。IP 协议拥有变身技能!
16位总长度
IP 数据报的长度
UDP 也是 16 位(2 个字节,64KB
)。但并非 IP 协议报头最多能携带的数据就是 64KB
IP 协议内置了拆包组包机制,单个 IP 数据报确实没法超过 64KB
,但是不代表 IP 协议不能传输超过 64KB
的数据。IP 协议会自动把大的数据包,拆成多个 IP 数据报携带传输,在接收方再进行拼装
装修的时候,装柜子/床,进不了电梯,也进不了房门,怎么办?
- 厂家发的货就不是拼装好的柜子和床,而是零件
- 我们就可以先把零件搬进去,然后再组装起来
16位标识、3位标志、13位片偏移
IP 协议会自动拆包,统一个载荷的数据,会被分成多分,交给多个 IP 数据报来携带。多个 IP 数据包之间:
-
16位标识 是相同的数值,
-
13位片偏移 决定组包时候数据报的位置
- 网络传输数据的时候会存在后发先至的情况,所以不能按照发送顺序就确定接受顺序
-
3位标志 只有两位有效(有一位是保留位,现在不用,以后可能用,先占个位置)
- 其中一个标识这个包是否需要组包(是否是拆包的一部分)
- 另一个表示当前包是否是组包中的最后一个单位
最后组包的时候,根据 16 位标识 确定哪些数据包放在一组,然后根据 13位片偏移 决定顺序,最后根据 3位标志位 决定是不是最后一个
如果就是想使用 UDP 实现传输找过 64KB 的数据,该怎么做呢?
- 此处参考 IP 协议
- 在应用层编写代码的时候
- 引入“标识”,约定标识相同的数据,就应该进行组包
- 引入“片偏移”,约定组包的时候的先后顺序
- 引入“标志位”,区分是否需要组包,标识最后一个包
8位生存时间
描述了一个数据包在网络上存活的最长时间
- 假设构造一个 IP 数据报,目的 IP 写错了(不存在的 IP 地址),结果这个数据包就在网络上传输了很久,也没有达到目的地。
- 如果让这样的数据包无限传输的话,就会消耗很多网络资源
- 这样的数据包存在一个两个还好,要是存在很多呢?总不能让这些数据包把路全部堵死了吧
TTL
就是约定了一个传输时间的上限,当达到上限之后,数据包就会被自动丢弃掉
- 它的单位不是
s
或者min
,而是次数(经过路由器转发的次数)
发送一个 IP 数据报的时候,会有一个初识的 TTL
的值(32,64,128…)。数据包每次经过一个路由器转发,TTL
就会 -1
(经过交换机不减)。一旦 TTL
减到 0
了,此时这个数据包就会被当前的路由器直接丢弃掉
ping命令
:用来检测网络的连通性- 输入命令后,我们的电脑就会给百度发送一个数据包,百度收到这个 ping 命令的数据包之后,就会返回一个响应
- 我们发送了四次 32 字节的数据包
- 几十毫秒,说明网络比较好;上百,上千毫秒说明网络比较卡
- 咱们初始 TTL 应该是 64,中间经过了 12 个路由器的转发,最终到达了百度
64
这样的TTL
够用吗?
- 正常情况下,
64
这样的TTL
是非常充裕的
- 六度空间理论(社会科学中的理论)
- 而且发送数据的时候,还有
128
这样的TTL
8位协议
IP 数据包中,携带的载荷,是哪种传输层协议的数据包
通过这里的不同数值,感知到接下来要把数据给 TCP 解析,还是 UDP 解析,还是其他协议解析
- 类似于 TCP/UDP 报头中的“端口号”,决定要将这个数据交个哪个应用程序,也就是要将这个数据交给哪个应用层的具体协议进行处理
现在 IP 协议要先交给传输层,交给哪个传输层协议进行处理,就通过 8位协议 进行标识
具体的数值这里不谈,这里暂时只聊作用
16位首部校验和
验证数据在传输中是否出错(只是针对首部,IP 报头)
- 载荷部分
TCP/UDP
都有自己的校验和,此处就不需要再次进行验证了