2022大厂高频面试题之计算机网络篇

2022大厂高频面试题之计算机网络篇,第1张

系列文章:
2022前端大厂面试题之JavaScript篇(1)
2022前端大厂面试题之JavaScript篇(2)
2022前端大厂面试题之JavaScript篇(3)
2022大厂高频面试题之 *** 作系统篇
2022前端大厂高频面试题之HTTP篇
2022大厂高频面试题之计算机网络

文章目录
  • 计算机网络
    • TCP三次握手建立连接
    • TCP四次挥手断开连接
    • TCP三次握手,为什么要三次握手,四次挥手
    • TCP协议保证数据传输可靠性的方式
    • TCP的拥塞控制算法
    • TCP和UDP的区别
    • TCP为什么比UDP慢
    • UDP协议为什么不可靠
    • TCP和UDP的应用场景
    • TCP粘包问题
    • 怎么理解端到端、点到点?
    • Cookie、Session、Token
    • 常见的应用层协议
    • DNS 协议
    • WebSocket

计算机网络 TCP三次握手建立连接

1.第一次握手,由浏览器发起,告诉服务器我要发送请求了;
2.第二次握手,由服务器发起,给浏览器发一个确认,告诉浏览器我准备接受了,你赶紧发送吧;
3.第三次握手,由浏览器发送,告诉服务器,我收到确认了,马上就发了,准备接受吧。

TCP四次挥手断开连接

1.第一次挥手:由浏览器发起的,发送给服务器FIN报文,我请求报文发送完了,你准备关闭吧;
2.第二次挥手:由服务器发起的,发送ACK确认告诉浏览器,我请求报文接受完了,我准备关闭了,你也准备吧;
3.第三次挥手:由服务器发起,向客户端发送FIN以及ACK,进入LAST-ACK状态,告诉浏览器,我响应报文发送完了,你准备关闭吧;
4.第四次挥手:由浏览器发起,告诉服务器,我响应报文接受完了,我准备关闭了,你也准备吧。客户端收到服务端发来的FIN后,发送 ACK 给服务端。在等待2MSL后进入CLOSED状态

TCP三次握手,为什么要三次握手,四次挥手

三次握手:为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误;为了确认双方的接收能力和发送能力都正常。
第三次握手的作用是客户端对服务器端的初始序号的确认。如果只使用两次握手,那么服务器就没有办法知道自己的序号是否 已被确认。
四次挥手
TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的,所以需要双方分别释放到对方的连接,单独一方的连接释放,只代 表不能再向对方发送数据,连接处于的是半释放的状态。

1.因为是双方彼此都建立了连接,因此双方都要释放自己的连接,A向B发出一个释放连接请求,他要释放链接表明不再向B发送数据了,此时B收到了A发送的释放链接请求之后,给A发送一个确认,A不能再向B发送数据了,它处于FIN-WAIT-2的状态,但是此时B还可以向A进行数据的传送。此时B向A 发送一个断开连接的请求,A收到之后给B发送一个确认。此时B关闭连接。A也关闭连接。

2.为什么要有TIME-WAIT这个状态呢,这是因为有可能最后一次确认丢失,如果B此时继续向A发送一个我要断开连接的请求等待A发送确认,但此时A已经关闭连接了,那么B永远也关不掉了,所以我们要有TIME-WAIT这个状态。

当然TCP也并不是100%可靠的。
详细的可以查看:
参考1
参考2

TCP协议保证数据传输可靠性的方式

校验和:发送方在发送数据之前计算校验和,接收方收到数据后同样计算,如果不一致,那么传输有误。
序列号
确认应答
超时重传:如果发送方发送数据一段时间后没有收到ACK,那么就重发数据。
连接管理
流量控制:TCP采用大小可变的滑动窗口进行流量控制
拥塞控制
参考

TCP的拥塞控制算法

1.慢开始:开始的时候不要发送大量数据,而是先测试一下网络的拥塞程度,由小到大增加拥塞窗口的大小。
2.拥塞控制:把拥塞窗口控制为缓慢、按线性规律增长,使网络比较不容易出现拥塞,而不是完全能够避免拥塞。
3.快重传:要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)。发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。
4.快恢复

TCP和UDP的区别

1、tcp是基于连接的,可靠性高;udp是基于无连接的,可靠性较低;
2、由于tcp是连接的通信,需要有三次握手、重新确认等连接过程,会有延时,实时性差,安全性较高;而udp无连接,无建立连接的过程,因而实时性较强,安全性略差;
3、在传输相同大小的数据时,tcp首部开销20字节;udp首部开销只有8个字节,tcp报头比udp复杂,故实际包含的用户数据较少。tcp无丢包,而udp有丢包,故tcp开销大,udp开销较小;
4、每条tcp连接只能是点到点的;udp支持一对一、一对多、多对一、多对多的交互通信。
5、TCP是面向字节流的,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的。TCP是全双工的可靠信道,UDP是不可靠信道。
6、TCP有状态,可控制;UDP不可靠原因:无状态,不可控。

TCP为什么比UDP慢

UDP没有流控,没有握手,没有成功确认,一个数据包发过去就不管,从这个角度上说TCP是开销大一点。
1,基于连接与无连接
2,对系统资源的要求(TCP较多,UDP少)
3,UDP程序结构较简单
4,流模式与数据报模式
5,TCP保证数据正确性,UDP可能丢包,TCP保证数据顺序,UDP不保证

UDP协议为什么不可靠

UDP在传输数据之前不需要先建立连接:

  • 不保证消息交付:不确认,不重传,无超时
  • 不保证交付顺序:不设置包序号,不重排,不会发生队首阻塞
  • 不跟踪连接状态:不必建立连接或重启状态机
  • 不进行拥塞控制:不内置客户端或网络反馈机制
TCP和UDP的应用场景

TCP:效率要求相对低,需要传输大量数据且对数据可靠性要求高的场景;例如:文件传输(准确高要求高、但是速度可以相对慢)、接受邮件、远程登录。
UDP:可靠性要求低,追求效率,对实时性要求高和高速传输的场景;例如:QQ聊天、在线视频、网络语音电话(即时通讯,速度要求高,但是出现偶尔断续不是太大问题,并且此处完全不可以使用重发机制)、广播通信(广播、多播)。

TCP粘包问题

TCP粘包是指发送方发送的若干包数据到接收方接收时粘成一包,从接收缓冲区看,后一包数据的头紧接着前一包数据的尾。
粘包出现原因
简单得说,在流传输中出现,
1.发送端需要等缓冲区满才发送出去,造成粘包
2.接收方不及时接收缓冲区的包,造成多个包接收

为什么udp不会粘包?

  • TCP协议是面向流的协议,UDP是面向消息的协议。UDP段都是⼀条消息,应用程序必须以消息为单位提取数据,不能⼀次提取任意字节的数据。
  • UDP具有保护消息边界,在每个UDP包中就有了消息头(消息来源地址,端口等信息),传输协议把数据当作⼀条独立的消息在网上传输,接收端只能接收独立的消息。接收端⼀次只能接收发送端发出的⼀个数据包,如果⼀次接受数据的大小小于发送端⼀次发送的数据大小,就会丢失⼀部分数据,即使丢失,接受端也不会分两次去接收。

为了避免粘包现象,可采取以下几种措施:

  • 进行封包/拆包: 封包/拆包是目前业内常见的解决方案了。即给每个数据包在发送之前, 于其前/后放⼀些有特征的数据,
    然后收到数据的时 候根据特征数据分割出来各个数据包。
  • 多次发送之前间隔⼀个等待时间:只需要等上⼀段时间再进⾏下⼀次 send 就好, 适⽤于交互频率特别低的场景。
  • 对于发送方引起的粘包现象,用户可通过编程设置来避免,TCP提供了强制数据立即传送的 *** 作指令push,TCP软件收到该 *** 作指令后,就立即将本段数据发送出去,而不必等待发送缓冲区满;
  • 对于接收方引起的粘包,则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施,使其及时接收数据,从而尽量避免出现粘包现象;
  • 由接收方控制,将一包数据按结构字段,人为控制分多次接收,然后合并,通过这种手段来避免粘包。
    一种比较周全的对策是:接收方创建一预处理线程,对接收到的数据包进行预处理,将粘连的包分开。
怎么理解端到端、点到点?

点到点工作在物理层,是指两个网络设备直接相连,中间没有其他设备;
端到端工作在传输层,是指两个网络设备之间的逻辑互连,不管中间有多少物理设备。

Cookie、Session、Token

Cookie
Cookie实际上是一小段的文本信息。客户端请求服务器,如果服务器需要记录该用户状态,就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时,浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie,以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

Session
Session是另一种记录客户状态的机制,不同的是Cookie保存在客户端浏览器中,而Session保存在服务器上。客户端浏览器访问服务器的时候,服务器把客户端信息以某种形式记录在服务器上。这就是Session。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

Token(令牌)
Token的引入:Token是在客户端频繁向服务端请求数据,服务端频繁的去数据库查询用户名和密码并进行对比,判断用户名和密码正确与否,并作出相应提示,在这样的背景下,Token便应运而生。

Token的定义:Token 是令牌,访问资源接口(API)时所需要的资源凭证。Token是服务端生成的一串字符串,以作客户端进行请求的一个令牌,当第一次登录后,服务器生成一个Token便将此Token返回给客户端,以后客户端只需带上这个Token前来请求数据即可,无需再次带上用户名和密码。

使用Token的目的:Token的目的是为了减轻服务器的压力,减少频繁的查询数据库,使服务器更加健壮。

常见的应用层协议

三种常见的应用层协议:HTTP、FTP、SMTP。

DNS 协议

DNS 是域名系统 (Domain Name System) 的缩写,提供的是一种域名到 IP 地址的转换服务。DNS占用53号端口,同时使用TCP和UDP协议:区域传送(数据有变动时执行)使用TCP;在域名解析的时候使用UDP。

作用: 将域名解析为IP地址,客户端向DNS服务器(DNS服务器有自己的IP地址)发送域名查询请求,DNS服务器告知客户机Web服务器的 IP 地址。

WebSocket

WebSocket是HTML5提供的一种浏览器与服务器进行全双工通讯的网络技术,属于应用层协议。用来弥补http协议在持久通信能力上的不足。它基于TCP传输协议,并复用HTTP的握手通道。浏览器和服务器只需要完成一次握手,两者之间就直接可以创建持久性的连接, 并进行双向数据传输。

WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是:服务器可以向客户端主动推动消息,客户端也可以主动向服务器推送消息。

WebSocket原理:客户端向 WebSocket 服务器通知(notify)一个带有所有接收者ID(recipients IDs)的事件(event),服务器接收后立即通知所有活跃的(active)客户端,只有ID在接收者ID序列中的客户端才会处理这个事件。

WebSocket 特点:

  • 支持双向通信,实时性更强
  • 可以发送文本,也可以发送二进制数据‘’
  • 建立在TCP协议之上,服务端的实现比较容易
  • 数据格式比较轻量,性能开销小,通信高效
  • 没有同源限制,客户端可以与任意服务器通信
  • 协议标识符是ws(如果加密,则为wss),服务器网址就是 URL
  • 与 HTTP 协议有着良好的兼容性。默认端口也是80和443,并且握手阶段采用HTTP 协议,因此握手时不容易屏蔽,能通过各种 HTTP 代理服务器。

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/langs/869937.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2022-05-13
下一篇 2022-05-13

发表评论

登录后才能评论

评论列表(0条)

保存