【IP协议】IP协议报头结构（上）
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都有自己的校验和，此处就不需要再次进行验证了