2024年前端最新前端网络基础-传输层TCP协议,2024年最新web前端面试你必须要知道的那些知识点

react和vue的比较

相同
1)vitual dom
2)组件化
3)props,单一数据流

不同点
1)react是jsx和模板;(jsx可以进行更多的js逻辑和操作)
2)状态管理(react)
3)对象属性(vue)
4)vue:view——medol之间双向绑定
5)vue:组件之间的通信(props,callback,emit)

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

TCP三次握手过程

TCP协议是一种面向连接的协议,即想要使用TCP进行通信,则必须先要建立连接。而TCP建立连接的是可信连接,而需要建立可信连接,需要通信双方经过三次握手。

一开始,客户端和服务器都是连接关闭状态,即CLOSED态。之后服务器会立刻进入LISTEN态,实时监听TCP建立连接请求。

然后客户端主动发起TCP请求连接消息到服务器,此时客户端状态变为 SYN_SENT,且请求连接消息中TCP头部的标志位SYN打开,且序号seq=i

服务器收到客户端的请求连接消息后,状态变为syn_received,之后会回复一条确认请求连接消息,在确认消息的TCP头部的SYN和ACK标志位被打开,且ack(确认号)变为 i + 1,表示期望下次发送的下一个序号的数据段,另外当前确认消息也要消耗一个序号,即确认消息也有seq = j

当客户端收到服务器发送的确认请求连接消息后,自身状态变为 established,即建立连接状态,并响应一条 确认连接建立消息,该消息TCP头部的 ACK标志位被打开,且ack= j + 1,表示期望下次响应序号为j+1的数据段,seq = i + 1, 这里seq需要满足上次服务端发送消息的ack期望。

当服务器收到客户端的确认建立连接请求消息后,进入established状态,即建立连接状态

三次握手的优点在于,只有通信双方都确认了连接建立后才能实现通信。

两次握手为什么不能建立TCP连接

思考一下,两次握手能不能实现建立TCP连接,有什么漏洞?

两次握手建立TCP连接,即表示,在服务器发送确认请求连接消息后,服务器立马就进入了established状态,而不管自身发送的确认消息是否被客户端接收到。

如果确认消息因为线路问题在传输过程中丢失了,那么客户端就收不到服务器的确认请求连接消息,也就无法进入established状态,在等待一段时间后,客户端会再次发送一个请求连接消息,但是此时服务器已经认为和客户端建立连接了,而忽略该消息,此时就会产生问题。

而三次握手,避免了该问题。

如果服务器发送确认请求连接消息,并没有被客户端接收到,客户端在等待一段时间后,会再次发送请求连接消息给服务器,服务器收到后,由于自身并没有进入established状态,所以会再次发送一个确认请求连接消息给客户端,当客户端接收到后,客户进入established状态,并进行第三次握手,即发送一个确认建立连接消息给服务器,服务器收到该消息后,才会进入established状态。

通信双方建立TCP连接后,就可以开始互相通信了。

另一种理解思路是:

TCP传输是全双工的,即通信双方的任意一方都可以在发送数据的同时,接收数据。

而这也要求通信双方(发起方和接收方)都具备发送和接收能力。

第一次握手:F  =》S,F发送了,但是F不知道S是否收到了

第二次握手:S =》 F,S回复了,F知道S收到了,但是S不知道F收到回复没

第三次握手:F =》 S,F回复了,S知道F收到回复了

此时F,S都知道对方了具备发送和接收能力了

第三次握手报文丢失

再思考一个问题,如果在客户端发送完第三次握手ACK包后,自身已经进入了established状态,但是第三次握手ACK在传输中丢失了,即服务器没有收到第三次握手消息,那会发生什么?

答:如果第三次握手报文没有到达服务器就丢失了,则服务器会一直处于SYN_RECEIVED状态,并依次等待3s,6s,12s后重新发送【SYN ACK】包给客户端。

但是客户端此时已经是established状态,即自认为TCP连接已建立,而不会理会服务端的【SYN ACK】。

而服务端会发送指定次数的【SYN ACK】包给客户端,如果都没有得到响应,则会关闭当前TCP连接。

而客户端由于自认为TCP连接已建立,所以正常向服务器发送数据报,但是服务器由于没有和客户端建立连接,所以会响应一个RST标志位的释放连接报文,让客户端得知服务端出错,而强制关闭TCP连接。

wireshark抓包演示TCP三次握手过程

下面用wireshark抓包,来说明下TCP建立连接的三次握手

这里 192.168.0.101:55615(客户端) 想和 192.168.0.118:80(服务器) 建立TCP连接

客户端 会发送一个SYN包,且序号seq = 0

服务端接收到该请求连接消息后,会返回一个【SYN ACK】包,并且ack = 1,seq = 0

客户端收到服务端的确认请求连接消息后,会再次发送一个确认建立连接消息【ACK】包,且seq = 1, ack = 1

之后客户端和服务端之间就可以开始通信了

TCP四次挥手过程

而当通信结束了,就需要释放TCP连接,此时客户端和服务端都处于established状态,双方都可以发起释放连接请求报文,我们以客户端主动释放连接,服务端被动释放连接为例

客户端发送一个 请求释放连接报文 给服务端,该报文TCP头部中 FIN标志位被打开(表示请求释放连接),且序号seq = n。

发送后,客户端进入fin_wait_1状态,即半关闭状态,并停止向服务端发送数据报文,但是任然可以从服务器接收数据报文。

服务端收到客户端的请求释放连接消息后,会立刻响应一条 确认请求释放连接(客户端->服务端)报文,报文TCP头部的ACK标志位被打开,确认号ack = n + 1,序号seq = m

且自身状态变为closed_wait,即半关闭状态,此时服务器开始准备释放和客户端之间的连接

客户端收到服务端的确认释放连接消息后,立马进入 fin_wait_2。

此时服务器已经知道了客户端想释放连接,客户端也已经知道了服务端收到了释放连接报文,所以客户端可以确认关闭通向服务器的TCP连接。

服务端在发送完确认释放连接消息后,会经过close_wait阶段,此阶段中会去准备关闭服务端通向客户端的TCP连接,当准备好后,就会发送一个请求释放连接(服务端->客户端)报文,报文TCP头部中FIN标志位被打开,同时也会将ACK标志位打开(和上次确认客户端请求释放连接报文的ACK相同),同时seq,ack也和上次相同。

此时服务端会停止向客户端发送数据报文,但是任然可以接收到客户端发送的报文。

当客户端收到服务端的请求释放连接消息后,会立马发送一条 确认消息 给服务端,该消息TCP头部的ACK标志位被打开,且seq = n+1,ack = m+1,发送后立马进入time_wait_1状态

服务端收到客户端的确认释放连接消息后,立马进入closed状态。

此时服务端关闭了(服务端->客户端)方向的连接。

而客户端在等待一段时间(2MSL)后,自动进入closed状态。

此时客户端关闭了(客户端->服务端)方向的连接。

以上就是TCP四次挥手全过程。

为什么第三次挥手不能和第二次挥手合并

注意:第三次挥手为什么不和第二次挥手合并,因为第二次挥手是为了告诉客户端已经收到请求释放连接的报文了,让客户端可以早点确认可以释放(客户端->服务端)的TCP连接,即遭到进入fin_wait_2。

而服务端此时还无法立即释放(服务端->客户端)的TCP连接,因为服务端是被动关闭连接,所以后知后觉,需要时间来准备关闭连接,这段时间就是close_wait阶段。

为什么第四挥手后,发送方要等待2MSL时间后才能关闭TCP连接

可能有人比较疑惑最后一次挥手后,客户端为什么不直接进入closed状态,而是要等一段时间(2MSL)?

MSL指的是Maximum Segment Lifetime:一段TCP报文在传输过程中的最大生命周期。

2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长

服务器端在1MSL内没有收到客户端发出的ACK确认报文,就会再次向客户端发出FIN报文;

  • 如果客户端在2MSL内,再次收到了来自服务器端的FIN报文,说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文,计时器重置,重新开始2MSL的计时;
  • 否则客户端在2MSL内没有再次收到来自服务器端的FIN报文,说明服务器端正常接收了ACK确认报文,客户端可以进入CLOSED阶段,完成“四次挥手”。

因为存在这样一种情况,客户端发送最后一次挥手消息后,如果直接进入closed状态,那么假如最后一次挥手消息在传输过程中丢包了,即服务端没有接收到该挥手消息,则服务端在等待一段时间后,会再次发送 请求释放连接消息给 客户端,但是此时客户端已经closed了,所以不会理会该消息。而服务端由于一直无法收到确认消息,所以一直无法进入closed状态。

所以客户端在发送完最后一次挥手消息后,不能立马进入closed状态,他需要等待一段时间,这段时间需要比:

服务端没有收到客户端确认消息的所等待的时间 + 发送二次 请求释放连接消息到客户端的时间

还要长。

这样就可以保证通信双方都确认断开连接了。

为什么建立TCP连接需要三次握手,释放TCP连接需要四次挥手

我们需要思考一下:为什么建立TCP连接只需要三次握手,而释放TCP连接需要四次挥手呢?释放时,为什么会多一次?

因为TCP数据传输是全双工的,全双工的意思就是,客户端通过TCP连接向服务器发送数据的同时,服务器也可以用同一个TCP连接向客户端发送数据,二者同时向对方发送数据不会产生冲突,就像一个双向马路一样。

全双工对应的是半双工,即同一时刻,只能传输线路中只能有一个方向的数据传输,就像潮汐车道一样。

总结

为了帮助大家更好温习重点知识、更高效的准备面试,特别整理了《前端工程师面试手册》电子稿文件。

内容包括html,css,JavaScript,ES6,计算机网络,浏览器,工程化,模块化,Node.js,框架,数据结构,性能优化,项目等等。

包含了腾讯、字节跳动、小米、阿里、滴滴、美团、58、拼多多、360、新浪、搜狐等一线互联网公司面试被问到的题目,涵盖了初中级前端技术点。

前端面试题汇总

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】

JavaScript

性能

linux

开源分享:【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】](https://bbs.csdn.net/forums/4304bb5a486d4c3ab8389e65ecb71ac0)**

JavaScript

性能

linux

  • 26
    点赞
  • 18
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值