阿里面试官: HTTP、HTTPS、TCP/IP、Socket通信、三次握手四次挥手过程?(附全网最具深度的三次握手、四次挥手讲解)

  • 时间:
  • 浏览:0
  • 来源:5分快乐8_5分快乐8官网

当然本身 方案完整完整都是一定缺点,最明显的也不服务器不保存连接的半开清况 ,就丧失重发SYN-ACK消息的能力,本身 方面会降低正常用户的连接成功率,此人 面会是原因分析分析但会 清况 下正常通信的双方会对连接算是成功打开产生误解,如客户端发给服务端的第三次握手消息(ACK)半路遗失,客户端认为连接成功了,服务端认为没收到ACK,连接没成功,本身 清况 就不能上层应用采取策略有点儿处理了。

三次握手的清况 转换图(建议达到能默写下来的熟练程度)

可能性现在A并没法发出建立连接的请求,但会 不不理睬B的确认,也不会向B发送数据,但B却以为新的运输连接可能性建立了,并经常等待英文A发来的数据。B的但会 资源就没法 白白浪费了。

首先考虑失败的清况 :

SYN Cookie 防御

可能性自顶向上这本书里边的图比较简略,这里采用谢希仁版本的计算机网络中的图:

What if a TCP handshake segment is lost?

这段时间面试官都挺忙的,频频出先在博客文章标题,我着实我完整完整都是有点儿想蹭热度,但会 我我着实想不能好的标题了-。-,蹭蹭就蹭蹭 :)

你不能讲解一下TCP的三次握手与四次挥手呢?

ACK报文丢失是原因分析分析第三次握手失败

客户主机发起连接释放的请求,设置FIN1,当然,序号seq也会带上,这里假设为u;发送完毕后,客户端进入 FIN-WAIT-1 清况 。

要确保服务器算是可能性收到了大伙儿儿的ACK 报文,可能性没法收到说说,服务器会重新发FIN 报文给客户端,没法客户端再次收到FIN 报文没法 ,就知道没法 的 ACK 报文丢失了,就会再次发送ACK 报文

先上一张TCP报文社会形态图,待会大伙儿儿会回来看这张图:

服务器端准备好关闭连接时,向客户端发送开始英语 连接请求,FIN 置为1;发送完毕后,服务器端进入 LAST-ACK 清况 ,等待英文来自客户端的最后有三个ACK

这里先给大伙儿儿讲一下上图中但会 符号的含义:

限于篇幅,此处暂时不讲,留意后续文章。

上述的清况 转换图不能跟前面的三次握手的转换图进行对比理解,同時 发起的有三个请求最终只会建立有三个连接

首先,当前客户端和服务器的清况 都为ESTABLISHED,接下来大伙儿儿完整讲解下上图的过程:

客户端接收到服务端传来的FIN 报文后,知道服务器可能性准备好关闭了,发送有三个确认包,并进入 TIME-WAIT清况 ,等待英文可能性出先的要求重传的ACK 报文;服务器端接收到本身 确认包没法 ,关闭连接,进入 CLOSED 清况 。

所谓的SYN Cookie防御系统,与前面接收到SYN 报文就分配缓存不同,此时暂不分配资源;同時 利用SYN 报文目的地IP端口,以及服务器存储的有三个秘密数,使用它们进行散列,得到server_isn,但会 附着在SYNACK 报文中发送给客户端,接下来也不对ACK 报文进行判断,可能性其返回的ack字段正好等于server_isn + 1,说明这是有三个合法的ACK,没法服务器才会为其生成有三个具有套接字的全开的连接。

rfc793-page33

首先理解题意,大伙儿儿知道三次握手正是建立TCP连接的过程,大伙儿儿假设 A 是客户端,B 是服务端:

事实上我在阿里边试的没法 我我着实被问到了本身 哪几个的现象,HTTP、HTTPS、TCP/IP、Socket通信、三次握手四次挥手过程?当时我着实思路正确,可惜最终也完整都是也不算完整答对

上图圈住的累积:

本身 哪几个的现象在网上找到的答案质量参差不齐,翻阅了rfc793,仔细研究后,最终挂接出以下答案:

总的来说,可能性有三个ACK 报文丢失了,但它的下有三个数据包没法丢失,没法连接正常,但会 ,连接会被重置。

服务端接收到FIN 报文后,会返回有三个ACK 报文回去,此时设置ACK1确认号u + 1;表明此人 接受到了客户端关闭连接的请求,但还没法准备好关闭连接。发送完毕后,服务器端进入 CLOSE-WAIT 清况 ,客户端接收到本身 确认包没法 ,进入 FIN-WAIT-2 清况 ,等待英文服务器端关闭连接。

rfc793-RST

可能性使用两次握手,就不能确认上述所说的并完整都是能力,没法就会是原因分析分析哪几个的现象。

开始英语 后花了一段时间挂接了下思路,参考和查阅了一下资料,挂接如下:

来源:编程充电宝

客户主机发起连接请求,设置SYN标志位为1,同時 客户端随机选则了有三个初始序号client_isn,但会 存中放TCP报文字段的序号中,如下图:

计算机网络-谢希仁-四次挥手

我我着实说明了TCP B不能检测本身 旧的SYN 报文算是正确,所以正常返回。而客户端收到会进行检测,发现是旧的报文,就会返回RST 报文

面试官可能性从整体到局部入手,没法 们就先讲讲整个三次握手和四次挥手的过程,但完整都是也不忘记,讲的同時 应该适当体现你对该知识点掌握的角度和广度,具体为什么会么会说,大伙儿儿里边慢慢道来。

SYN-RECEIVEDSYN-RCVD是一样的,前者rcf793中的描述妙招,后者是《计算机网络-自顶向下妙招》中的使用妙招。

当客户端收到服务端的SYNACK应答后,其清况 变为ESTABLISHED,并会发送ACK包给服务端,准备发送数据了。可能性此时ACK在网络中丢失(如上图所示),过了超时计时器后,没法服务端会重新发送SYNACK包,重传次数根据/proc/sys/net/ipv4/tcp_synack_retries来指定,默认是5次。可能性重传指定次数到了后,仍然未收到ACK应答,没法一段时间后,Server自动关闭本身 连接。

所谓SYN 洪泛攻击,也不利用SYNACK 报文的没法 ,服务器会为客户端请求分配缓存,没法黑客(攻击者),就不能使用一批虚假的ip向服务器极少量地发建立TCP 连接的请求,服务器为哪几个虚假ip分配了缓存后,趋于稳定SYN_RCVD清况 ,存中放半连接队列中;另外,服务器发送的请求又可能性性得到回复(ip完整完整都是假的,能回复完整完整都是鬼了),不能不断地重发请求,直到达到设定的时间/次数后,才会关闭。

握手类事,每次挥手也代表一次报文的发出和接收。

先上三次握手的流程图:

从上图不能想看 ,第三行也不旧的SYN 连接到达服务器时,第四行是服务器照常返回,第五行是客户端给服务端发送RST 报文,将服务端重置为LISTEN

rfc793-同時 启动

TCP报文社会形态

所谓的握手即一次发包到接收的过程,可能性从客户端发送到服务端,也可能性从服务端发送到客户端。

本身 细节和哪几个的现象深究第3题是一致的,服务器使用特定的初始序列号 server_isn(从目的地IP端口散列中获取)不能用来抵御SYN洪水攻击。具体为哪几个,以及哪几个是SYN 洪泛攻击,哪几个的现象深究累积大伙儿儿会再详谈。

第三次握手,A发送ACKBB接收后,能确认哪几个呢?

哪几个的现象就在这里,客户端可能性认为连接建立,而服务端则可能性趋于稳定SYN-RCVD可能性CLOSED,接下来大伙儿儿不能考虑这并完整都是清况 下服务端的应答:

接下来大伙儿儿完整来看看上图中,有三个请求同時 相互发起时,有三个TCP均会经历如下清况 的转换:

我我着实这道题更加深挖了TCP 建立连接的过程,大伙儿儿不能在rfc793中了解到完整信息。

服务器不断为哪几个半开连接分配资源(但从未使用),是原因分析分析服务器的连接资源被消耗殆尽,不过所幸,大伙儿儿不能使用SYN Cookie进行有效地防御。

三次握手

现假定并完整都是异常清况 ,即A发出的SYN报文段并没法丢失,也不在但会 网络节点长时间滞留了,以致延误到连接释放后的某个时间才到达B。没法 这是有三个早已失效的报文段。但B收到此失效的连接请求报文段后,却误以为是A又发出一次新的连接请求,于是就向A发出确认报文段,同意建立连接。

简单来说,三次握手的目的是为了让双方验证个人 的接收能力和发送能力

作者:在所不辞

rfc793-正常的关闭例子

不固定,client_isn是随机生成的,而server_isn则不能根据SYN 报文中的源、ip和端口,打上去服务器并完整都是的密码数进行相同的散列得到,显然这也完整完整都是固定的。

本身 结论也不能在STACKFLOW上找到验证:

讲过程的没法 我我着实可能性讲了,第三次握手是不能携带数据的,而前两次不行。

接下来,当服务端接收到该报文后,会为其分配TCP 缓存和变量(这使得TCP容易受到被称为SYN 洪泛攻击的拒绝服务攻击)紧接着,服务端会返回有三个SYNACK 报文到客户端,其中SYN标志位为1确认号设置为client_isn + 1,但会 选有三个此人 的初始序号server_isn,并放置在序号字段中,如下图:

接下来大伙儿儿来完整讲解下上图的过程:

这里大伙儿儿再来看下rfc793中关于四次挥手的简单例子:

关于RST 报文,我一开始英语 也很疑惑,直到想看 rfc793 原文

当收到服务器发来的SYNACK报文段后,客户端也不能给该连接分配缓存和变量,但会 再次发送有三个确认报文给服务端,其中,SYN标志位设置为0,将确认号设置为server_isn + 1,另外,此次报文不能携带负载数据:

大伙儿儿不能从上图了解到的但会 是,服务端在SYN_RECEIVED清况 下,接收到旧的SYN 报文时是不能作出判断的,也不照常返回,当客户端接收到该报文后发现异常,才会发送RST 报文,重置连接。

为了下文描述方便,大伙儿儿将三次握手分别称为:SYN 报文SYNACK 报文ACK 报文

假定不采用第三次报文握手,没法我希望B发出确认,新的连接就建立了。

同步请求的清况 转换

关键就在里边两步。