大厂系列:计算机网络八股文,速速收藏(一)

1.计算机网络的各层协议及作用?

计算机网络体系可以大致分为一下三种,OSI七层模型、TCP/IP四层模型和五层模型。

- OSI七层模型:大而全,但是比较复杂、而且是先有了理论模型,没有实际应用。

- TCP/IP四层模型:是由实际应用发展总结出来的,从实质上讲,TCP/IP只有最上面三层,最下面一层没有什么具体内容,TCP/IP参考模型没有真正描述这一层的实现。

- 五层模型:五层模型只出现在计算机网络教学过程中,这是对七层模型和四层模型的一个折中,既简洁又能将概念阐述清楚。

七层网络体系结构各层的主要功能:

- 应用层:为应用程序提供交互服务。在互联网中的应用层协议很多,如域名系统DNS,支持万维网应用的HTTP协议,支持电子邮件的SMTP协议等。

- 表示层:主要负责数据格式的转换,如加密解密、转换翻译、压缩解压缩等。

- 会话层:负责在网络中的两节点之间建立、维持和终止通信,如服务器验证用户登录便是由会话层完成的。

- 运输层:有时也译为传输层,向主机进程提供通用的数据传输服务。该层主要有以下两种协议:

- TCP:提供面向连接的、可靠的数据传输服务;

- UDP:提供无连接的、尽最大努力的数据传输服务,但不保证数据传输的可靠性。

- 网络层:选择合适的路由和交换结点,确保数据及时传送。主要包括IP协议。

- 数据链路层:数据链路层通常简称为链路层。将网络层传下来的IP数据包组装成帧,并再相邻节点的链路上传送帧。

- 物理层:实现相邻节点间比特流的透明传输,尽可能屏蔽传输介质和通信手段的差异。

2. TCP和UDP的区别?

对比如下:

总结:

TCP 用于在传输层有必要实现可靠传输的情况,UDP 用于对高速传输和实时性有较高要求的通信。TCP 和 UDP 应该根据应用目的按需使用。

3. UDP 和 TCP 对应的应用场景是什么?

TCP 是面向连接,能保证数据的可靠性交付,因此经常用于:

- FTP文件传输

- HTTP / HTTPS

UDP 面向无连接,它可以随时发送数据,再加上UDP本身的处理既简单又高效,因此经常用于:

- 包总量较少的通信,如 DNS 、SNMP等

- 视频、音频等多媒体通信

- 广播通信

4. 详细介绍一下 TCP 的三次握手机制?

在讲TCP三次握手和四次挥手之前,先说一下TCP标志位,方便后续的理解。

简单来说,TCP标志位的值代表了当前请求的目的。

标志位一共有6种,分别是:

1. SYN(synchronous): 发送/同步标志,用来建立连接,和下面的第二个标志位ACK搭配使用。连接开始时,SYN=1,ACK=0,代表连接开始但是未获得响应。当连接被响应的时候,标志位会发生变化,其中ACK会置为1,代表确认收到连接请求,此时的标志位变成了 SYN=1,ACK=1。

2. ACK(acknowledgement):确认标志,表示确认收到请求。

3. PSH(push) :表示推送操作,就是指数据包到达接收端以后,不对其进行队列处理,而是尽可能的将数据交给应用程序处理;

4. FIN(finish):结束标志,用于结束一个TCP会话;

5. RST(reset):重置复位标志,用于复位对应的TCP连接。

6. URG(urgent):紧急标志,用于保证TCP连接不被中断,并且督促中间层设备尽快处理。

此外,还有两个序号:

1. Sequence number :顺序号,发送数据包中的第一个字节的序列号,一般为小写的seq。

2. Acknowledge number:确认号,响应前面的seq,值为seq+1,可以理解为期望下次发出的序列号为seq+1;

所谓三次握手(Three-way Handshake),是指建立一个TCP连接时,需要客户端和服务器总共发送3个包。 三次握手的目的是连接服务器指定端口,建立TCP连接,并同步连接双方的顺序号和确认号并交换 TCP信息

- 第一次握手:客户端Client发送位码为SYN=1,随机产生seq=x的数据包到服务器,服务器Server由SYN=1知道,客户端Client要求建立联机;

- 第二次握手:服务器Server收到请求后要确认联机信息,向客户端Client发送ack=(客户端Client请求连接时的seq)+1,SYN=1,ACK=1,产生seq=y的包,代表接收到连接请求并且向客户端再次确认;

- 第三次握手:客户端Client收到后检查ack是否正确,即第一次发送的seq+1,以及位码ACK是否为1,代表收到了服务器端发过来的确认信息。之后客户端Client会再向服务器发送ack=(服务器Server的seq+1),ACK=1,服务器Server收到后确认ack 值与ACK=1,连接建立成功。

5. 为什么需要三次握手,而不是两次?

主要有三个原因:

1. 防止已过期的连接请求报文突然又传送到服务器,因而产生错误和资源浪费。

在双方两次握手即可建立连接的情况下,假设客户端发送 A 报文段请求建立连接,由于网络原因造成 A 暂时无法到达服务器,服务器接收不到请求报文段就不会返回确认报文段。

客户端在长时间得不到应答的情况下重新发送请求报文段 B,这次 B 顺利到达服务器,服务器随即返回确认报文并进入 ESTABLISHED 状态,客户端在收到 确认报文后也进入 ESTABLISHED 状态,双方建立连接并传输数据,之后正常断开连接。

此时姗姗来迟的 A 报文段才到达服务器,服务器随即返回确认报文并进入 ESTABLISHED 状态,但是已经进入 CLOSED 状态的客户端无法再接受确认报文段,更无法进入 ESTABLISHED 状态,这将导致服务器长时间单方面等待,造成资源浪费。

2. 三次握手才能让双方均确认自己和对方的发送和接收能力都正常。

第一次握手:客户端只是发送处请求报文段,什么都无法确认,而服务器可以确认自己的接收能力和对方的发送能力正常;

第二次握手:客户端可以确认自己发送能力和接收能力正常,对方发送能力和接收能力正常;

第三次握手:服务器可以确认自己发送能力和接收能力正常,对方发送能力和接收能力正常;

可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常,这样就可以愉快地进行通信了。

3. 告知对方自己的初始序号值,并确认收到对方的初始序号值。

TCP 实现了可靠的数据传输,原因之一就是 TCP 报文段中维护了序号字段和确认序号字段,通过这两个字段双方都可以知道在自己发出的数据中,哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增,如果是两次握手,只有发起方的初始序号可以得到确认,而另一方的初始序号则得不到确认。

6. 为什么要三次握手,而不是四次?

因为三次握手已经可以确认双方的发送接收能力正常,双方都知道彼此已经准备好,而且也可以完成对双方初始序号值得确认,也就无需再第四次握手了。

- 第一次握手:服务端确认“自己收、客户端发”报文功能正常。

- 第二次握手:客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常,客户端认为连接已建立。

- 第三次握手:服务端确认“自己发、客户端收”报文功能正常,此时双方均建立连接,可以正常通信。

7. 什么是 SYN洪泛攻击?如何防范?

SYN洪泛攻击属于 DOS 攻击的一种,它利用 TCP 协议缺陷,通过发送大量的半连接请求,耗费 CPU 和内存资源。

原理:

- 在三次握手过程中,服务器发送 [SYN/ACK] 包(第二个包)之后、收到客户端的 [ACK] 包(第三个包)之前的 TCP 连接称为半连接(half-open connect),此时服务器处于 SYN_RECV(等待客户端响应)状态。如果接收到客户端的 [ACK],则 TCP 连接成功,如果未接受到,则会不断重发请求直至成功。

- SYN 攻击的攻击者在短时间内伪造大量不存在的 IP 地址,向服务器不断地发送 [SYN] 包,服务器回复 [SYN/ACK] 包,并等待客户的确认。由于源地址是不存在的,服务器需要不断的重发直至超时。

- 这些伪造的 [SYN] 包将长时间占用未连接队列,影响了正常的 SYN,导致目标系统运行缓慢、网络堵塞甚至系统瘫痪。

检测:当在服务器上看到大量的半连接状态时,特别是源 IP 地址是随机的,基本上可以断定这是一次 SYN 攻击。

防范:

- 通过防火墙、路由器等过滤网关防护。

- 通过加固 TCP/IP 协议栈防范,如增加最大半连接数,缩短超时时间。

- SYN cookies技术。SYN Cookies 是对 TCP 服务器端的三次握手做一些修改,专门用来防范 SYN 洪泛攻击的一种手段。

8. 三次握手连接阶段,最后一次ACK包丢失,会发生什么?

服务端:

- 第三次的ACK在网络中丢失,那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制,会等待3秒、6秒、12秒后重新发送SYN+ACK包,以便客户端重新发送ACK包。

- 如果重发指定次数之后,仍然未收到 客户端的ACK应答,那么一段时间后,服务端自动关闭这个连接。

客户端:

客户端认为这个连接已经建立,如果客户端向服务端发送数据,服务端将以RST包(Reset,标示复位,用于异常的关闭连接)响应。此时,客户端知道第三次握手失败。

9. 详细介绍一下 TCP 的四次挥手过程?

- 第一次挥手:客户端向服务端发送连接释放报文(FIN=1,ACK=1),主动关闭连接,同时等待服务端的确认。

- 序列号 seq = u,即客户端上次发送的报文的最后一个字节的序号 + 1

- 确认号 ack = k, 即服务端上次发送的报文的最后一个字节的序号 + 1

- 第二次挥手:服务端收到连接释放报文后,立即发出确认报文(ACK=1),序列号 seq = k,确认号 ack = u + 1。

- 这时 TCP 连接处于半关闭状态,即客户端到服务端的连接已经释放了,但是服务端到客户端的连接还未释放。这表示客户端已经没有数据发送了,但是服务端可能还要给客户端发送数据。

- 第三次挥手:服务端向客户端发送连接释放报文(FIN=1,ACK=1),主动关闭连接,同时等待 A 的确认。

- 序列号 seq = w,即服务端上次发送的报文的最后一个字节的序号 + 1。

- 确认号 ack = u + 1,与第二次挥手相同,因为这段时间客户端没有发送数据

- 第四次挥手:客户端收到服务端的连接释放报文后,立即发出确认报文(ACK=1),序列号 seq = u + 1,确认号为 ack = w + 1。

- 此时,客户端就进入了 TIME-WAIT 状态。注意此时客户端到 TCP 连接还没有释放,必须经过 2*MSL(最长报文段寿命)的时间后,才进入 CLOSED 状态。而服务端只要收到客户端发出的确认,就立即进入 CLOSED 状态。可以看到,服务端结束 TCP 连接的时间要比客户端早一些。

10. 为什么连接的时候是三次握手,关闭的时候却是四次握手?

服务器在收到客户端的 FIN 报文段后,可能还有一些数据要传输,所以不能马上关闭连接,但是会做出应答,返回 ACK 报文段.

接下来可能会继续发送数据,在数据发送完后,服务器会向客户单发送 FIN 报文,表示数据已经发送完毕,请求关闭连接。服务器的ACK和FIN一般都会分开发送,从而导致多了一次,因此一共需要四次挥手。

全部评论

相关推荐

今天 08:20
门头沟学院 Java
1、这个项目是学校的项目还是你自己研发的?最后有上线吗?2、开发成果中支持一千的并发用户,核心接口响应时间小于一百毫秒,是怎么监测和统计的?3、做这个项目遇到了哪些难点,当时是怎么解决的?4、在 Kafka 里怎么保证它的消费幂等性?5、订单秒杀库存超卖用乐观锁是如何实现的?如果因为并发量高出现很多提交失败的情况,后续有什么补偿机制?6、乐观锁和悲观锁一般在什么场景下使用?7、用布降过滤器做缓存优化,它是怎么解决缓存穿透的?8、在 Bitmap 里面你的 key 是怎么设置的?如果存在跨越的签到情况怎么解决和存储?怎么判断多大的 Bitmap比较合适?相比普通存储方式能节省多少内存空间?9、更新数据库成功但删除缓存失败会导致什么问题?如何解决?10、如何计算两个用户的共同关注列表?如果系统规模变大,每个用户关注数达到百万级别,该怎么解决?11、为什么选择 Redis 的 Sorted set 存储排行榜数据?12、近几年大模型比较火,你在日常学习、工作或生活中有用到哪些大模型工具?你觉得这些工具中哪方面更好,更倾向于使用哪一个,为什么?13、在使用大模型时,对提问的prompt编写范式有什么了解?14、平时用哪种数据库较多?(MVSQL)MVSQL 常用的索引结构实现是什么?(B+树)决定其层高的因素有哪些?15、MySQL 中用到哪些索引类型?16、如果 MySQL 查询执行很慢,如何分析和处理?17、MySQL默认的隔离级别是什么?可重复读隔离级别存在什么问题,如何解决?18、间隙锁的实现原理是什么,锁的范围区间大概是怎样的?
查看18道真题和解析
点赞 评论 收藏
分享
深情的ssr在迎接o...:你要看一下这公司的投资 有没有盈利业务 同规模厂三年工作经验 五年工作经验招聘给的薪资多少 综合来要薪资啊 你这个相当于腾讯部分sp的价格了。。。。
谈薪时HR压价该怎么应对
点赞 评论 收藏
分享
评论
1
3
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务