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

  • 时间:
  • 浏览:2

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

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

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

为了下文描述方便,一群人一群人一群人 将三次握手分别称为:SYN 报文SYNACK 报文ACK 报文

关键就在里边两步。

服务器不断为有有哪些半开连接分配资源(但从未使用),导致 服务器的连接资源被消耗殆尽,不过所幸,一群人一群人一群人 可不还能不能 使用SYN Cookie进行有效地防御。

嘴笨 这道题更加深挖了TCP 建立连接的过程,一群人一群人一群人 可不还能不能 在rfc793中了解到完整性信息。

客户端接收到服务端传来的FIN 报文后,知道服务器不可能 准备好关闭了,发送另另另三个小确认包,并进入 TIME-WAIT清况 ,守候不可能 出現的要求重传的ACK 报文;服务器端接收到你什儿 确认包刚刚 ,关闭连接,进入 CLOSED 清况 。

你什儿 细节和大难题深究第3题是一致的,服务器使用特定的初始序列号 server_isn(从目的地IP端口散列中获取)可不还能不能 用来抵御SYN洪水攻击。具体为有哪些,以及有哪些是SYN 洪泛攻击,大难题深究主次一群人一群人一群人 会再详谈。

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

三次握手

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

不可能 现在A并这麼发出建立连接的请求,但会 越多再理睬B的确认,而是会向B发送数据,但B却以为新的运输连接不可能 建立了,并总是守候A发来的数据。B的你什儿 资源就从前白白浪费了。

事实上我在阿里边试的刚刚 嘴笨 被问到了你什儿 大难题,HTTP、HTTPS、TCP/IP、Socket通信、三次握手四次挥手过程?当时嘴笨 思路正确,可惜最终你什儿 你什儿 要算完整性答对

rfc793-page33

现假定并是是否是异常清况 ,即A发出的SYN报文段并这麼丢失,而是在你什儿 网络节点长时间滞留了,以致延误到连接释放后的某个时间才到达B。从前这是另另另三个小早已失效的报文段。但B收到此失效的连接请求报文段后,却误以为是A又发出一次新的连接请求,于是就向A发出确认报文段,同意建立连接。

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

所谓SYN 洪泛攻击,而是利用SYNACK 报文的刚刚 ,服务器会为客户端请求分配缓存,这麼黑客(攻击者),就可不还能不能 使用一批虚假的ip向服务器血块地发建立TCP 连接的请求,服务器为有有哪些虚假ip分配了缓存后,位于SYN_RCVD清况 ,存上放半连接队列中;另外,服务器发送的请求又越多再可能 得到回复(ip是是否是假的,能回复是是否是鬼了),不到不断地重发请求,直到达到设定的时间/次数后,才会关闭。

讲过程的刚刚 嘴笨 不可能 讲了,第三次握手是可不还能不能 携带数据的,而前两次不行。

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

嘴笨 说明了TCP B不到检测你什儿 旧的SYN 报文是是否是正确,你什儿 你什儿 正常返回。而客户端收到会进行检测,发现是旧的报文,就会返回RST 报文

要确保服务器是是否是不可能 收到了一群人一群人一群人 的ACK 报文,不可能 这麼收到句子,服务器会重新发FIN 报文给客户端,这麼客户端再次收到FIN 报文刚刚 ,就知道刚刚 的 ACK 报文丢失了,就会再次发送ACK 报文

先上一张TCP报文形态学 图,待会一群人一群人一群人 会回来看这张图:

接下来一群人一群人一群人 完整性来看看上图中,另另另三个小请求一齐相互发起时,另另另三个小TCP均会经历如下清况 的转换:

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

不可能 使用两次握手,就不到确认上述所说的并是是否是能力,这麼就会导致 大难题。

不固定,client_isn是随机生成的,而server_isn则可不还能不能 根据SYN 报文中的源、ip和端口,加进服务器并是是否是的密码数进行相同的散列得到,显然这你什儿 你什儿 是固定的。

假定不采用第三次报文握手,这麼但会 B发出确认,新的连接就建立了。

这段时间面试官都挺忙的,频频出現在博客文章标题,嘴笨 我是是否是怪怪的想蹭热度,但会 嘴笨 想不到好的标题了-。-,蹭蹭就蹭蹭 :)

ACK报文丢失导致 第三次握手失败

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

同步请求的清况 转换

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

服务器端准备好关闭连接时,向客户端发送结束了了英语 连接请求,FIN 置为1;发送完毕后,服务器端进入 LAST-ACK 清况 ,守候来自客户端的最后另另另三个小ACK

先上三次握手的流程图:

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

What if a TCP handshake segment is lost?

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

接下来一群人一群人一群人 来完整性讲解下上图的过程:

服务端接收到FIN 报文后,会返回另另另三个小ACK 报文回去,此时设置ACK1确认号u + 1;表明买车人接受到了客户端关闭连接的请求,但还这麼准备好关闭连接。发送完毕后,服务器端进入 CLOSE-WAIT 清况 ,客户端接收到你什儿 确认包刚刚 ,进入 FIN-WAIT-2 清况 ,守候服务器端关闭连接。

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

rfc793-RST

面试官不可能 从整体到局部入手,从前们就先讲讲整个三次握手和四次挥手的过程,但越多忘记,讲的一齐应该适当体现你对该知识点掌握的层厚和广度,具体为何么说,一群人一群人一群人 里边慢慢道来。

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

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

你什儿 结论也可不还能不能 在STACKFLOW上找到验证:

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

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

上图圈住的主次:

TCP报文形态学

总的来说,不可能 另另另三个小ACK 报文丢失了,但它的下另另另三个小数据包这麼丢失,这麼连接正常,但会 ,连接会被重置。

结束了了英语 后花了一段时间分派了下思路,参考和查阅了一下资料,分派如下:

来源:编程充电宝

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

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

rfc793-正常的关闭例子

这里一群人一群人一群人 再来看下rfc793中关于四次挥手的简单例子:

大难题就在这里,客户端不可能 认为连接建立,而服务端则不可能 位于SYN-RCVD不可能 CLOSED,接下来一群人一群人一群人 可不还能不能 考虑这并是是否是清况 下服务端的应答:

rfc793-一齐启动

关于RST 报文,我一结束了了英语 也很疑惑,直到看得人rfc793 原文

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

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

作者:在所不辞

首先考虑失败的清况 :

你什儿 大难题在网上找到的答案质量参差不齐,翻阅了rfc793,仔细研究后,最终分派出以下答案:

SYN Cookie 防御

当然你什儿 方案是是否是一定缺点,最明显的而是服务器不保存连接的半开清况 ,就丧失重发SYN-ACK消息的能力,你什儿 方面会降低正常用户的连接成功率,买车人面会导致 你什儿 清况 下正常通信的双方会对连接是是否是成功打开产生误解,如客户端发给服务端的第三次握手消息(ACK)半路遗失,客户端认为连接成功了,服务端认为没收到ACK,连接没成功,你什儿 清况 就可不还能不能 上层应用采取策略怪怪的补救了。

这里先给一群人一群人一群人 讲一下上图中你什儿 符号的含义: