嵌入式八股---计算机网络篇
前言
这块主要是结合着LWIP去理解计算机网络中常见的面试题
OSI四层/五层/七层模型
OSI分层(7层):物理层、数据链路层、网络层、传输层、会话层(http)、表示层(加密)、应用层。
TCP/IP分层(4层):网络接口层、网际层、运输层、应用层。
五层协议(5层):物理层、数据链路层、网络层、运输层、应用层。
- 物理层:
传递信息的媒介,比如是以太网还是光纤还是无线电 - 数据链路层:
数据链路层在不可靠的物理介质上提供可靠的传输。该层的作用包括:物理地址寻址、数据的成帧、流量控制、数据的检错、重发等
-
2.1以太网协议:
以太网协议则是用于实现链路层的数据传输和 MAC 地址封装
-
2.2ARP协议
工作就是建立IP地址与MAC地址的映射
ARP层: ARP广播请求(当我们进入网络的时候) ARP回应(更新自己的ARP缓存表)
当我们的IP层准备发包的时候 首先会通过缓存表查询MAC地址 查询不到的话就会发出ARP请求
-
网络层
网络层负责对子网间的数据包进行路由选择,主要是IP和ICMP协议-
3.1 IP地址的格式
IP地址 = 网络号 + 主机号 IP地址一共四个字节 所以根据所占字节不同分成了四类-
IP地址的分类
A类地址:以0开头,网络号占用一个字节,第一个字节范围:0~127
B类地址:以10开头,网络号占用两个字节,第一个字节范围:128~191
C类地址:以110开头,网络号占用三个字节,第一个字节范围:192~223
D类地址:以1110开头,第一个字节范围为224~239
-
子网掩码
后来又出现了一个子网掩码 实际上就是把IP地址进一步拆分了
此时 IP地址 = 网络号 + 子网号 + 主机号
子网掩码就是表示网络号 + 子网号一共占了多少位
因为网络号根据A B C D类占用的位数固定 就能算出子网号占了多少位
-
-
3.2 特殊IP地址
回环地址:127.0.0.1
网络地址:主机号全为0
广播地址:主机号全为1
私有地址(private address)也叫专用地址,它们不会在全球使用,只具有本地意义
-
3.3 IP层的分包
如果数据包过大 IP层会讲数据包分开发送 这也就设计到了接收端的组装过程 -
3.4 IPV4和 IPV6的区别
IPV4是32位长度 IPv6是128位长度
IPV6提供身份验证和加密 IPV4不提供
包头:IPv4长度为20~40字节;IPv6固定40字节。 -
3.5 ICMP协议
主要用来检测网络通信故障和实现链路追踪
ICMP协议我们用的最多的就是Ping指令
-
-
传输层: TCP 与 UDP
第一个端到端,即主机到主机的层次(所以很有可能俩主机之间通过不同的端口建立很多链接)
但是点对点不一样 点对点是基于 MAC 地址或 IP 地址,那就是一个主机一个的形式-
4.1 TCP报文格式
- 16位源端口 + 16位目标端口
- 32位SEQ + 32 位 ACK
- TCP头部大小 + 标志位 + 窗口大小
- 校验和 与 紧急指针
- 各种的选项
- 数据
-
4.2 TCP的三次握手与四次挥手
-
三次握手
在这个过程启用 SYN 和 ACK两个标志位
第一次: 客户端发送 seq = X ack = 无效 (SYN = 1 ACK = 0)
第二次: 服务器的发送 seq = Y ack = X + 1 (SYN = 1 ACK = 1)
第三次: 客户端回应 seq = x + 1 ack = Y + 1 (SYN = 1 ACK = 1)
-
三次握手的失败重传机制
如果第一次握手消息丢失,那么请求方不会得到 ack 消息,超时后进行重传
如果第二次握手消息丢失,那么请求方不会得到 ack 消息,超时后进行重传
如果第三次握手消息丢失,那么 Server 端该 TCP 连接的状态为 SYN_RECV,并
且会根据 TCP 的超时重传机制,会等待 3 秒、6 秒、12 秒后重新发送 SYN+ACK 包 -
三次握手改成两次行不行
不行 为什么不行 我们来分析三次握手
第二次握手结束的时候,能说明: 客户端有发送的能力 服务器有接收正确信息的能力
不能说明的是: 客户端到底能不能正确收到服务器发送的信息- 那么问题就来了,如果二次握手后服务器就认为建立了连接,客户端也不用回应的话,是不是可以利用这个特点进行服务器攻击呢 大量发送握手报文来占用服务器的资源
- 网络环境很复杂,假设你发送了两个第一次握手报文 结果到达时间差距很大 那第二个报文来的时候服务器又重新建立连接了,可是你的客户端对此一无所知,不知道连接发生改变了
-
四次挥手
- 客户端发送请求关闭 FIN = 1 seq = C ack无效
- 服务器收到之后回应一下 ACK = 1 seq: -; ack = C + 1
- 服务器在处理完后在发送 FIN = 1 seq : D ack:无效
- 客户端发送表明知道服务器断开 ACK = 1 seq:无效 ack: D + 1
-
四次挥手改为三次行不行
在某些状态下时可以的
四次挥手的主要原因在于服务器可能还没处理完客户端发送过来的消息
没有数据要发送并且「开启了 TCP 延迟确认机制」,那么第二和第三次挥手就会合并传输,这样就出现了三次挥手
= -
为什么客户端要等待2MSL?
保证客户端发送的最后一个 ACK 报文能够到达服务器,因为这个报文可能丢失,站在服务器的角度看来,我已经发送了 FIN+ACK 报文请求断开,客户端没有给我回应,应该我的请求报文没有收到,于是服务器就会重新发送一次,客户端就能够在这个 2MSL 时间内收到这个重传的报文,接着回应报文
防止已失效的连接请求报文段出现在本连接中。
-
-
4.3 TCP是如何保证传输的可靠性的?
-
数据校验和
-
确认应答机制(SEQ 和 ACK)
只要收到数据 必须发送ACK(确认报文) -
超时重传机制
超时没有收到ACK发送端就重传 -
快速重传机制
当发送方连续收到3个重复的ACK(冗余ACK)时,认为该ACK对应的数据包已丢失,立即重传该数据包。
-
窗口控制机制
窗口大小就是无需等待确认而可以继续发送数据的最大值,如果不使用窗口控制,每一个没收到应答的数据都要重发
-
-
4.4 TCP的滑动窗口原理(流量控制)
为什么会有?–TCP的分片传输机制 和 ACK确认要求
如果我们的发送端真的是发一个等待确认再发下一个的话 那实在是太慢了 所以我们可以一下子发很多,但这意味着我们要记录好这些包的状态才行
比如说发送端的报文,有以下几种状态:
发送端未发送,同时接收端也未准备接收的
发送端未发送,同时接收端也准备接收的 (窗口内)
发送端已发送,但是还没收到ACK (窗口内)
发送端已发送, 收到了ACK
同样的接收方的报文也会有以下几种状态
-
4.5 TCP的慢启动(拥塞控制)
TCP在最开始的阶段:先将拥塞窗口cwnd设置1个mss长度,然后有一个以指数形式增长的过程称为慢启动
当CWND >= ssthresh(慢启动阈值,默认约64KB)时,转为线性增长:
窗口增长方式:每RTT时间,CWND += 1 MSS。
目的:避免网络拥塞,谨慎增加发送速率。 -
4.6 UDP建立连接
UDP每次通信都需要指定好IP地址和端口号
-
4.7 TCP与UDP的区别
- 可靠性
TCP保证了数据传输的可靠性 但是UDP不保证(不会重传的没收到就GG),UDP的数据是可能乱序的 - 连接方式
TCP属于面向连接(得保证连得上),UDP则不关心直接发送 - 数据传输效率
TCP的效率肯定没有UDP高 - 流量控制与拥塞控制
这些UDP都没有 很有可能一个发送速度快一个接受处理的慢就丢包了 - 应用场景
- 可靠性
-
4.8 粘包现象与问题解决
-
粘包与半包问题
核心就是在应用层:你认为需要接收的A和B数据之前没有联系 但是由于发送的机制 实际上这俩数据是一起接收到的
-
解决
应用层发送和接受缓冲区的大小完全一样:每次只发10个 每次只接受10个
用特殊字符结尾(比如换行符)
自定义包头和包尾
=
-
-
4.9 TCP与UDP通信过程相关的API
-
T4.10 CP的分包和IP层的分包
-
-
应用层: DNS HTTP DHCP SMTP
-
6.1 DNS 从IP地址到网址的映射
浏览器缓存中是否存在—>本地HOST文件是否存在—>去访问DNS服务器了- 在浏览器中输入www.baidu.com后执行的全部过程?
- DNS解析 然后发起一次HTTP对话
- 传输层封包
- 网络层: 查找路由表确定如何到达服务器
- 链路层,包通过链路层发送到路由器
- 在浏览器中输入www.baidu.com后执行的全部过程?
-
6.2 HTTP协议
默认端口:80 HTTPS的端口为443
- 特点
- 明文传输
- 基于 请求–相应模型
- 灵活支持多种数据
- HTTP包括哪些请求?
GET:请求读取由URL所标志的信息。
POST:给服务器添加信息(如注释)。
PUT:在给定的URL下存储一个文档。
DELETE:删除给定的URL所标志的资源 - GET和POST的区别
Get是从服务器上获取数据,Post是向服务器传送数据。
Get是把参数数据队列加到提交表单的Action属性所指向的URL中,值和表单内各个字段一一对应,在URL中可以看到。
Get传送的数据量小,不能大于2KB;post传送的数据量较大,一般被默认为不受限制。
根据HTTP规范,GET用于信息获取,而且应该是安全的和幂等的
- 特点
-
6.3 DHCP:IP地址的自动分配
-
6.4 SMTP:邮件协议 FTP:文件传输协议 MQTT: TCP上层的一个简单封装
-