本文介绍: 嵌入式面试题–计算机网络
说明:
- 面试群,群号: 228447240
- 面试题来源于网络书籍,公司题目以及博主原创或修改(题目大部分来源于各种公司);
- 文中很多题目,或许大家直接编译器写完,1分钟就出结果了。但在这里博主希望每一个题目,大家都要经过认真思考,答案不重要,重要的是通过题目理解所考知识点,好应对题目更多的变化;
- 博主与大家一起学习,一起刷题,共同进步;
- 写文不易,麻烦给个三连!!!
1.POST 方法比 GET 方法安全?
答案:
有人说
POST
比
GET
安全,因为数据在地址栏上不可见。
POST
比
GET
安全,因为数据在地址栏上不可见。
然而,从传输的角度来说,他们都是不安全的,因为
HTTP
在网络上是明文传输的,只要在网络节点上捉包,就能完整地获取数据报文。
HTTP
在网络上是明文传输的,只要在网络节点上捉包,就能完整地获取数据报文。
要想安全传输,就只有加密,也就是
HTTPS
。
HTTPS
。
2.Cookies和Session区别是什么?
答案:
Cookie
和
Session
都是客户端与服务器之间保持状态的解决方案
和
Session
都是客户端与服务器之间保持状态的解决方案
1. 存储的位置不同,
cookie
:存放在客户端,
session
:存放在服务端。
Session
存储的数据比较安全
:存放在客户端,
session
:存放在服务端。
Session
存储的数据比较安全
2. 存储的数据类型不同
两者都是
key-value
的结构,但针对
value
的类型是有差异的
key-value
的结构,但针对
value
的类型是有差异的
cookie
:
value
只能是字符串类型,
session
:
value
是
Object
类型
:
value
只能是字符串类型,
session
:
value
是
Object
类型
3. 存储的数据大小限制不同
cookie
:大小受浏览器的限制,很多是是
4K
的大小,
session
:理论上受当前内存的限制,
:大小受浏览器的限制,很多是是
4K
的大小,
session
:理论上受当前内存的限制,
4. 生命周期的控制
cookie
的生命周期当浏览器关闭的时候,就消亡了
的生命周期当浏览器关闭的时候,就消亡了
(1)cookie
的生命周期是累计的,从创建时,就开始计时,
20
分钟后,
cookie
生命周期结束,
的生命周期是累计的,从创建时,就开始计时,
20
分钟后,
cookie
生命周期结束,
(2)session
的生命周期是间隔的,从创建时,开始计时如在
20
分钟,没有访问
session
,那么
session
生命周期被销毁
的生命周期是间隔的,从创建时,开始计时如在
20
分钟,没有访问
session
,那么
session
生命周期被销毁
3.OSI 的七层模型的主要功能?
答案:
物理层:
利用传输介质为数据链路层提供物理连接,实现比特流的透明传输。
利用传输介质为数据链路层提供物理连接,实现比特流的透明传输。
数据链路层:
接收来自物理层的位流形式的数据,并封装成帧,传送到上一层。
接收来自物理层的位流形式的数据,并封装成帧,传送到上一层。
网络层:
将网络地址翻译成对应的物理地址,并通过路由选择算法为分组通过通信子网选择最适当的路径。
将网络地址翻译成对应的物理地址,并通过路由选择算法为分组通过通信子网选择最适当的路径。
传输层:
在源端与目的端之间提供可靠的透明数据传输。
在源端与目的端之间提供可靠的透明数据传输。
会话层:
负责在网络中的两节点之间建立、维持和终止通信。
负责在网络中的两节点之间建立、维持和终止通信。
表示层:
处理用户信息的表示问题,数据的编码,压缩和解压缩,数据的加密和解密。
处理用户信息的表示问题,数据的编码,压缩和解压缩,数据的加密和解密。
应用层:
为用户的应用进程提供网络通信服务。
为用户的应用进程提供网络通信服务。
4.三次握手过程中可以携带数据吗?
答案:
其实第三次握手的时候,是可以携带数据的。但是,
第一次、第二次握手不可以携带数据。
第一次、第二次握手不可以携带数据。
为什么这样呢
?
大家可以想一个问题,假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN
报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发 SYN
报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。
?
大家可以想一个问题,假如第一次握手可以携带数据的话,如果有人要恶意攻击服务器,那他每次都在第一次握手中的 SYN
报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常,然后疯狂着重复发 SYN
报文的话,这会让服务器花费很多时间、内存空间来接收这些报文。
也就是说,
第一次握手不可以放数据,其中一个简单的原因就是会让服务器更加容易受到攻击了。而对
于第三次的话,此时客户端已经处于
ESTABLISHED
状态。对于客户端来说,他已经建立起连接了,
并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没啥毛病。
第一次握手不可以放数据,其中一个简单的原因就是会让服务器更加容易受到攻击了。而对
于第三次的话,此时客户端已经处于
ESTABLISHED
状态。对于客户端来说,他已经建立起连接了,
并且也已经知道服务器的接收、发送能力是正常的了,所以能携带数据也没啥毛病。
5.2MSL等待状态?
答案:
TIME_WAIT
状态也称为
2MSL等待状态。
每个具体
TCP
实现必须选择一个报文段最大生存时间
状态也称为
2MSL等待状态。
每个具体
TCP
实现必须选择一个报文段最大生存时间
MSL
(
Maximum Segment Lifetime
),它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的,因为TCP
报文段以
IP
数据报在网络内传输,而
IP
数据报则有限制其生存时间的
TTL
字段。
(
Maximum Segment Lifetime
),它是任何报文段被丢弃前在网络内的最长时间。这个时间是有限的,因为TCP
报文段以
IP
数据报在网络内传输,而
IP
数据报则有限制其生存时间的
TTL
字段。
对一个具体实现所给定的
MSL
值,处理的原则是:当
TCP
执行一个主动关闭,并发回最后一个
ACK
,该连接必须在TIME_WAIT
状态停留的时间为
2
倍的
MSL
。这样可让
TCP
再次发送最后的
ACK
以防这个
ACK丢失(另一端超时并重发最后的FIN
)。
MSL
值,处理的原则是:当
TCP
执行一个主动关闭,并发回最后一个
ACK
,该连接必须在TIME_WAIT
状态停留的时间为
2
倍的
MSL
。这样可让
TCP
再次发送最后的
ACK
以防这个
ACK丢失(另一端超时并重发最后的FIN
)。
这种
2MSL
等待的另一个结果是这个
TCP
连接在
2MSL
等待期间,定义这个连接的插口(客户的
IP
地址和端口号,服务器的IP
地址和端口号)不能再被使用。这个连接只能在
2MSL
结束后才能再被使用。
2MSL
等待的另一个结果是这个
TCP
连接在
2MSL
等待期间,定义这个连接的插口(客户的
IP
地址和端口号,服务器的IP
地址和端口号)不能再被使用。这个连接只能在
2MSL
结束后才能再被使用。
6.为什么TIME_WAIT状态需要经过2MSL才能返回到CLOSE状态?
答案:
第一种回答
理论上,四个报文都发送完毕,就可以直接进入
CLOSE
状态了,但是可能网络是不可靠的,有可能最后一个ACK
丢失。所以
TIME_WAIT
状态就是用来重发可能丢失的
ACK
报文
。
CLOSE
状态了,但是可能网络是不可靠的,有可能最后一个ACK
丢失。所以
TIME_WAIT
状态就是用来重发可能丢失的
ACK
报文
。
第二种回答
对应这样一种情况,最后客户端发送的
ACK = 1
给服务端的
过程中丢失
了,服务端没收到,服务端怎么认为的?我已经发送完数据了,怎么客户端没回应我?是不是中途丢失了?然后服务端再次发起断开连接的请求,一个来回就是2MSL
。
ACK = 1
给服务端的
过程中丢失
了,服务端没收到,服务端怎么认为的?我已经发送完数据了,怎么客户端没回应我?是不是中途丢失了?然后服务端再次发起断开连接的请求,一个来回就是2MSL
。
客户端给服务端发送的
ACK = 1
丢失,
服务端等待
1MSL
没收到
,
然后重新发送消息需要
1MSL
。如果再次接收到服务端的消息,则重启
2MSL
计时器
,
发送确认请求
。客户端只需等待
2MSL
,如果没有再次收到服务端的消息,就说明服务端已经接收到自己确认消息;此时双方都关闭的连接,TCP
四次分手完毕。
ACK = 1
丢失,
服务端等待
1MSL
没收到
,
然后重新发送消息需要
1MSL
。如果再次接收到服务端的消息,则重启
2MSL
计时器
,
发送确认请求
。客户端只需等待
2MSL
,如果没有再次收到服务端的消息,就说明服务端已经接收到自己确认消息;此时双方都关闭的连接,TCP
四次分手完毕。
7.HTTP如何禁用缓存?如何确认缓存?
答案:
HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。
禁止进行缓存
no-store
指令规定不能对请求或响应的任何一部分进行缓存。
指令规定不能对请求或响应的任何一部分进行缓存。
Cache-Control: no-store
强制确认缓存
no-cache
指令规定缓存服务器需要先向源服务器验证缓存资源的有效性,只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。
指令规定缓存服务器需要先向源服务器验证缓存资源的有效性,只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。
Cache-Control: no-cache
8.应用层常见协议知道多少?了解几个?
答案:
9.网络层常见协议?可以说一下吗?
答案:
10.TCP四大拥塞控制算法总结?
答案:
拥塞控制主要是四个算法:1)慢启动,2)拥塞避免,3)拥塞发生,4
)快速恢复。这四个算法不是一天都搞出来的,这个四算法的发展经历了很多时间,到今天都还在优化中。
)快速恢复。这四个算法不是一天都搞出来的,这个四算法的发展经历了很多时间,到今天都还在优化中。
慢热启动算法
– Slow Start
– Slow Start
所谓慢启动,也就是
TCP
连接刚建立,一点一点地提速,试探一下网络的承受能力,以免直接扰乱了网络通道的秩序。
TCP
连接刚建立,一点一点地提速,试探一下网络的承受能力,以免直接扰乱了网络通道的秩序。
慢启动算法:
(1)
连接建好的开始先初始化拥塞窗口
cwnd
大小为
1
,表明可以传一个
MSS
大小的数据。
连接建好的开始先初始化拥塞窗口
cwnd
大小为
1
,表明可以传一个
MSS
大小的数据。
(2)
每当收到一个
ACK
,
cwnd
大小加一,呈线性上升。
每当收到一个
ACK
,
cwnd
大小加一,呈线性上升。
(3)
每当过了一个往返延迟时间
RTT(Round-Trip Time)
,
cwnd
大小直接翻倍,乘以
2
,呈指数让升。
每当过了一个往返延迟时间
RTT(Round-Trip Time)
,
cwnd
大小直接翻倍,乘以
2
,呈指数让升。
(4)
还有一个
ssthresh
(
slow start threshold
),是一个上限,当
cwnd >= ssthresh
时,就会进入
“
拥塞避免算法”
(后面会说这个算法)
还有一个
ssthresh
(
slow start threshold
),是一个上限,当
cwnd >= ssthresh
时,就会进入
“
拥塞避免算法”
(后面会说这个算法)
拥塞避免算法
– Congestion Avoidance
– Congestion Avoidance
如同前边说的,当拥塞窗口大小
cwnd
大于等于慢启动阈值
ssthresh
后,就进入拥塞避免算法。算法如下:
cwnd
大于等于慢启动阈值
ssthresh
后,就进入拥塞避免算法。算法如下:
(1)
收到一个
ACK
,则
cwnd = cwnd + 1 / cwnd
收到一个
ACK
,则
cwnd = cwnd + 1 / cwnd
(2)
每当过了一个往返延迟时间
RTT
,
cwnd
大小加一。
每当过了一个往返延迟时间
RTT
,
cwnd
大小加一。
过了慢启动阈值后,拥塞避免算法可以避免窗口增长过快导致窗口拥塞,而是缓慢的增加调整到网络的最佳值。
拥塞发生状态时的算法
一般来说,
TCP
拥塞控制默认认为网络丢包是由于网络拥塞导致的,所以一般的
TCP
拥塞控制算法以丢包为网络进入拥塞状态的信号。对于丢包有两种判定方式,一种是超时重传RTO[Retransmission Timeout]超时,另一个是收到三个重复确认
ACK
。
TCP
拥塞控制默认认为网络丢包是由于网络拥塞导致的,所以一般的
TCP
拥塞控制算法以丢包为网络进入拥塞状态的信号。对于丢包有两种判定方式,一种是超时重传RTO[Retransmission Timeout]超时,另一个是收到三个重复确认
ACK
。
超时重传是
TCP
协议保证数据可靠性的一个重要机制,其原理是在发送一个数据以后就开启一个计时器,在一定时间内如果没有得到发送数据报的ACK
报文,那么就重新发送数据,直到发送成功为止。
TCP
协议保证数据可靠性的一个重要机制,其原理是在发送一个数据以后就开启一个计时器,在一定时间内如果没有得到发送数据报的ACK
报文,那么就重新发送数据,直到发送成功为止。
但是如果发送端接收到
3
个以上的重复
ACK
,
TCP就意识到数据发生丢失,需要重传。这个机制不需要等到重传定时器超时,所以叫做快速重传,而快速重传后没有使用慢启动算法,而是拥塞避免算法,所以这又叫做快速恢复算法。
3
个以上的重复
ACK
,
TCP就意识到数据发生丢失,需要重传。这个机制不需要等到重传定时器超时,所以叫做快速重传,而快速重传后没有使用慢启动算法,而是拥塞避免算法,所以这又叫做快速恢复算法。
超时重传
RTO[Retransmission Timeout]
超时,
TCP
会重传数据包。
TCP
认为这种情况比较糟糕,反应也比较强烈:
RTO[Retransmission Timeout]
超时,
TCP
会重传数据包。
TCP
认为这种情况比较糟糕,反应也比较强烈:
- 由于发生丢包,将慢启动阈值ssthresh设置为当前cwnd的一半,即ssthresh = cwnd / 2.
- cwnd重置为1
- 进入慢启动过程
最为早期的
TCP Tahoe
算法就只使用上述处理办法,但是由于一丢包就一切重来,导致
cwnd
又重置为1,十分不利于网络数据的稳定传递。
TCP Tahoe
算法就只使用上述处理办法,但是由于一丢包就一切重来,导致
cwnd
又重置为1,十分不利于网络数据的稳定传递。
所以,
TCP Reno
算法进行了优化。当收到三个重复确认
ACK
时,
TCP
开启快速重传
Fast Retransmit
算法,而不用等到RTO
超时再进行重传:
TCP Reno
算法进行了优化。当收到三个重复确认
ACK
时,
TCP
开启快速重传
Fast Retransmit
算法,而不用等到RTO
超时再进行重传:
- cwnd大小缩小为当前的一半
- ssthresh设置为缩小后的cwnd大小
- 然后进入快速恢复算法Fast Recovery。
快速恢复算法
– Fast Recovery
– Fast Recovery
TCP Tahoe
是早期的算法,所以没有快速恢复算法,而
Reno
算法有。在进入快速恢复之前,
cwnd
和 ssthresh已经被更改为原有
cwnd
的一半。快速恢复算法的逻辑如下:
是早期的算法,所以没有快速恢复算法,而
Reno
算法有。在进入快速恢复之前,
cwnd
和 ssthresh已经被更改为原有
cwnd
的一半。快速恢复算法的逻辑如下:
- cwnd = cwnd + 3 MSS,加3 MSS的原因是因为收到3个重复的ACK。
- 重传DACKs指定的数据包。
- 如果再收到DACKs,那么cwnd大小增加一。
- 如果收到新的ACK,表明重传的包成功了,那么退出快速恢复算法。将cwnd设置为ssthresh,然后进入拥塞避免算法。
11.、UDP 与 TCP的特点有哪些?
答案:
UDP
- UDP是无连接的;
- UDP使用尽最大努力交付,即不保证可靠交付,因此主机不需要维持复杂的链接状态(这里面有许多参数);
- UDP是面向报文的;
- UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电
- 话,实时视频会议等);
- UDP支持一对一、一对多、多对一和多对多的交互通信;
- UDP的首部开销小,只有8个字节,比TCP的20个字节的首部要短。
TCP:
- TCP是面向连接的。(就好像打电话一样,通话前需要先拨号建立连接,通话结束后要挂机释放连接);
- 每一条TCP连接只能有两个端点,每一条TCP连接只能是点对点的(一对一);
- TCP提供可靠交付的服务。通过TCP连接传送的数据,无差错、不丢失、不重复、并且按序到达;
- TCP提供全双工通信。TCP允许通信双方的应用进程在任何时候都能发送数据。TCP连接的两端都设有发送缓存和接收缓存,用来临时存放双方通信的数据;
- 面向字节流。TCP中的“流”(stream)指的是流入进程或从进程流出的字节序列。“面向字节流”的含义是:虽然应用程序和TCP的交互是一次一个数据块(大小不等),但TCP把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。
12.数据链路层常见协议?可以说一下吗
答案:
原文地址:https://blog.csdn.net/weixin_45257157/article/details/135733532
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_61213.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!
声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。