例如以太⽹中的⽹线必须使⽤双绞线; 传输速率有10M, 100M, 1000M等;
以太⽹是当前应⽤最⼴泛的局域⽹技术; 和以太⽹并列的还有令牌环⽹, ⽆线LAN等;
以太⽹帧格式:

- 源地址和目的地址
源地址和⽬的地址是指⽹卡的硬件地址(也叫MAC地址), ⻓度是48位,是在⽹卡出⼚时固化的;
- 帧协议类型
字段有三种值,分别对应IP、ARP、RARP;
- 帧末尾是CRC校验码。
- MAC地址⽤来识别数据链路层中相连的节点,比如说,路由器和路由器间的地址。
- ⻓度为48位, 及6个字节. ⼀般⽤16进制数字加上冒号的形式来表⽰(例如: 08:00:27:03:fb:19)
- 在⽹卡出⼚时就确定了, 不能修改. mac地址通常是唯⼀的(虚拟机中的mac地址不是真实的mac地址, 可能会冲突; 也有些⽹卡⽀持⽤⼾配置mac地址)
1.2.1 对⽐理解MAC地址和IP地址
IP地址描述的是路途总体的起点和终点。
MAC地址描述的是路途上的每⼀个区间的起点和终点;
MTU相当于发快递时对包裹尺⼨的限制. 这个限制是不同的数据链路对应的物理层, 产⽣的限制.
- 以太⽹帧中的数据⻓度规定最⼩46字节,最⼤1500字节,ARP数据包的⻓度不够46字节,要在后⾯补填充位;
- 最⼤值1500称为以太⽹的最⼤传输单元(MTU),不同的⽹络类型有不同的MTU;
- 如果⼀个数据包从以太⽹路由到拨号链路上,数据包⻓度⼤于拨号链路的MTU了,则需要对数据包进⾏分⽚(fragmentation);
- 不同的数据链路层标准的MTU是不同的;
由于数据链路层MTU的限制, 对于较⼤的IP数据包要进⾏分包.
我们回顾一下IP协议:
- 将较⼤的IP包分成多个⼩包, 并给每个⼩包打上标签,
- 每个⼩包IP协议头的 16位标识(id) 都是相同的;
- 每个⼩包的IP协议头的3位标志字段中, ;
- 到达对端时再将这些⼩包, 会按顺序重组, 拼装到⼀起返回给传输层;
- ⼀旦这些⼩包中任意⼀个⼩包丢失, 接收端的重组就会失败. 但是IP层不会负责重新传输数据;


由于数据链路层MTU的限制, 对于较⼤的IP数据包要进⾏分包.
让我们回顾⼀下UDP协议:
- ⼀旦UDP携带的数据超过1472(1500 - 20(IP⾸部) - 8(UDP⾸部)), 那么就会在⽹络层分成多个IP数据报.
- 这多个IP数据报有任意⼀个丢失, 都会引起接收端⽹络层重组失败. 那么这就意味着, 如果UDP数据报在⽹络层被分⽚, 整个数据被丢失的概率就⼤⼤增加了.
让我们再回顾⼀下TCP协议
- TCP的⼀个数据报也不能⽆限⼤, 还是受制于MTU. TCP的单个数据报的最⼤消息⻓度, 称为MSS(Max Segment Size);
- TCP在建⽴连接的过程中, 通信双⽅会进⾏MSS协商.
- 最理想的情况下, MSS的值正好是在IP不会被分⽚处理的最⼤⻓度(这个⻓度仍然是受制于数据链路层的MTU).
- 双⽅在发送SYN的时候会在TCP头部写⼊⾃⼰能⽀持的MSS值.
- 然后双⽅得知对⽅的MSS值之后, 选择较⼩的作为最终MSS.
- MSS的值就是在TCP⾸部的40字节变⻓选项中(kind=2);
ARP协议的作⽤:
ARP(Address Resolution Protocol,地址解析协议)的作用是将网络层的IP地址解析为数据链路层的物理地址(MAC地址)。
ARP协议建⽴了主机 IP地址 和 MAC地址 的映射关系;

ARP协议的工作流程
- 请求:当一个设备(比如主机A)想要与同一局域网内的另一台设备(比如主机B)通信,并且只知道主机B的IP地址而不知道其MAC地址时,主机A会广播一个ARP请求报文到整个局域网。这个请求包含主机A自己的IP地址和MAC地址,以及目标主机B的IP地址。
- 响应:所有接收到该ARP请求的设备都会检查报文中提到的目标IP地址是否与自己匹配。只有主机B发现目标IP地址是自己的,它才会响应这个请求。主机B会发送一个ARP响应报文给主机A,其中包含了主机B的MAC地址。
- 缓存:一旦主机A收到了主机B的ARP响应,它就会把主机B的IP地址与MAC地址之间的对应关系记录在一个叫做ARP缓存表的地方。这样,在一段时间内,如果主机A再次需要与主机B通信,它可以直接从ARP缓存中查找对应的MAC地址,而不需要重新发起ARP请求。
- 通信:有了目标设备的MAC地址后,主机A就可以使用该MAC地址来封装数据帧,并通过以太网等物理网络将其发送给主机B。
好了数据链路层的理解就到在这里,感谢观看。
到此这篇ip报文格式与实例分析的解读与注意事项(ip报文格式与实例分析的解读与注意事项是什么)的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章,希望大家都能在编程的领域有一番成就!版权声明:
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符,请将相关资料发送至xkadmin@xkablog.com进行投诉反馈,一经查实,立即处理!
转载请注明出处,原文链接:https://www.xkablog.com/haskellbc/47865.html