四次握手

Posted 2023-05-11

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了四次握手相关的知识，希望对你有一定的参考价值。

参考技术A 详细过程可参考《802.11-2012》11.6.6 4-Way Handshake

WPA2 或者WPA认证在association成功前都是基于open的认证方式，然后在association以后通过四次握手协商出PTK和GTK

1.Client生成SNonce并告知AP

2.AP生成ANonce并告知Client

3.AP和Client自己计算出PMK，并通过PMK在四次握手中衍生出PTK，GTK，并在四次握手中验证对方的PTK和GTK是正确的。

AA：client的MAC

SPA:AP的MAC

ANonce:AP产生的随机值

SNonce:Client 产生的随机值

PMK

对于PSK和EAP，AA、SPA、ANonce、SNonce这四个值的获取方式没有区别都是现成的或者随机生成的。但是PMK不一样:

PSK:PMK由SSID和密码等导出，公式如下

PMK=PSK=pdkdf2_SHA1(passphrase,SSID,SSID length, 4096), 其中passphrase就是客户输入的登录密码

EAP：在Radius认证成功后，AP和client同时会获得一个相同的key(MSK, 这个可以参考另外一篇文章802.1x+EAP的认证过程.）这个key就是用于派生出PMK.

PMK=L(MSK, 0, 256)

PMK转化成PTK是通过下面的函数完成的：

PTK<----PRF-X(pPMK, "Pairwise key expansion", Min(AA,SPA)||Max(AA,SPA)||Min(ANoce,SNoce)||Max(ANonce, SNoce))

(1)X指生成的PTK的长度，X=256+TK_bit，即256加上对应加密的TK位数，不同的加密方式TK_bits不一样。可查下表：

（2）KCK ← L(PTK, 0, 128)，它是PTK的前128bit（0-127），用于计算密钥生成消息的完整性校验值.使用方法可参考四次握手流程里面。

（3）KEK ← L(PTK, 128, 128)，它是PTK的中间128bit（128–255），用来加密密钥生成消息。使用方法可以参考四次握手流程

（4）TK ← L(PTK, 256, TK_bits)，它是PTK中256bit以后的所有位（256 — 255 + TK_bits），用来对数据包中的数据进行加密。从表中可看出，对于TKIP加密PTK的长度是512bit, 对于CCMP加密PTK的长度是384bit。

四次握手第一个报文:

发送方向:AP---->Station

携带参数:ANonce

第一次我握手后，Client将会获取到AP的ANonce和AA，这个时候client已经拥有了可以计算出PTK的所有参数，通过

PTK=PRF(PMK+ANonce+SNonce+AA+SPA)

Client将会派生出密钥PTK。生成的PTK前128位是KCK，用于计算密钥生成消息的完整性密钥值。

四次握手第二个报文:

发送方向:Station------>AP

携带参数:SNonce和MIC。其中MIC=mic(KCK,EAPOL),计算方法是令这个第二个报文的初始key mic为0，然后使用KCK加密该EAPOL报文得到报文完整性校验值即为WPA KEY MIC的值。

第二次握手后，AP将会从client处得到SNonce和已经计算好的MIC，这个时候AP拥有了所有能计算出PTK的参数，然后AP将进行同样的计算得到PTK，然后用得到的前128位对EAPOL报文进行完整性校验，看得到的值是否和收到报文中的WPA KEY MIC的值一致，如果一致，则验证成功，说明client端拥有的PMK是正确的，否则判定Client端拥有的PMK错误，整个握手就此停止。

AP对于第二个包的处理流程:

1.检查重播计数器看是否和第一包相关联，如果不是AP将默默丢掉报文

2.生成PTK

3.根据生成的PTK，得到前128位为KCK，然后计算EAPOL报文得到MIC值，如果不相等，AP将默默丢掉报文

4.如果MIC是相等的，且没有打开roaming，AP将会check 第二个EAPOL报文中携带的RSNE信息和Association request报文中的RSNE信息是否一致。

i)如果不完全一致，AP发送MLME-DEAUTHENTICATE去终止这次关联

ii)如果完全比配，AP开始构造四次握手的报文三。

四次握手的第三个报文：

发送方向:AP------>Station

携带参数：组临时密钥GTK, WPA KEY MIC

GTK:用于后续更新组密钥，该密钥被KEK加密，KEK是PTK的中间128bit，MIC同样是KCK加密得来

GTK被包含于KEY DATA中.

KEY DATA中包含的数据有:AP在Beacon或者Probe Response中包含的RSNE，GTK，如果管理帧保护同样被协商了，也包含IGTK KDE。。。。。

Client收到报文三后

1. 如果key Reply Counter的值已经被使用或者报文三中的ANonce和报文一种的不一样，则Client默默丢弃该报文

2.利用KEK解密查看报文三中的RSNE, 如果没有开启Roaming，对比Station收到的AP发送的Beason或者Probe Response的RSNE，如果不匹配，取消关联AP，如果信息中有提供第二个RSNE，Client使用第二个RSNE中指定的密钥套件或者取消认证

3.检查MIC，同第二个报文检查流程一样，如果不一致，将默默丢弃第三个报文

步骤2和3的目的都是为了验证AP拥有正确的PMK

4.更新最后看到key replay Counter 的值

5.构造第四个报文

四次握手第四个报文:

发送方向:Station------>AP

携带参数：WPA KEY MIC

Client 最后发送一次EAPOL-KEY给AP用于确认，如果认证成功，双方将安装（Install）key，Install的意思是指使用它们来对数据进行加密。

AP在收到第四个报文后

1.检查Key Replay Counter的值，如果不是四次握手中使用的那个，就默默丢弃这个报文，如果是继续下面的流程

2.检查MIC，通报文二，三的检查方法一直，如果不一样默默丢弃该报文，如果一样，将告诉802.11 MAC去使用新的PTK发送或者接受MPDU

3.AP更新KEY Replay Counter的值，以方便需要rekey的时候能使用新值

每个STA都有一个独立的PTK，所有的STA和AP共同拥有一个相同的GTK。如下图所示：

比如我们比较常见的TKIP和CCMP混合加密，前者用于兼容旧的设备，后者用于规范新的加密，一般来说，为了兼容不同版本的设备， GTK会使用TKIP加密(因为GTK是所有设备共享的)， PTK既可以是TKIP加密，也可以是CCMP加密。如下图所示：

计算机网络 TCP三次握手四次挥手以及面试会碰到的相关问题（二次握手四次握手）

计算机网络 TCP三次握手四次挥手以及面试会碰到的相关问题

## 大多数人都高估了他们一天能做的事情，但低估了他们一年能做的事情

1.三次握手

第一次握手：Client将SYN置1，随机产生一个初始序列号seq发送给Server，进入SYN_SENT状态；
第二次握手：Server收到Client的SYN=1之后，知道客户端请求建立连接，将自己的SYN置1，ACK置1，产生一个acknowledge number=sequence number+1，并随机产生一个自己的初始序列号，发送给客户端；进入SYN_RCVD状态；
第三次握手：客户端检查acknowledge number是否为序列号+1，ACK是否为1，检查正确之后将自己的ACK置为1，产生一个acknowledge number=服务器发的序列号+1，发送给服务器；进入ESTABLISHED状态；服务器检查ACK为1和acknowledge number为序列号+1之后，也进入ESTABLISHED状态；完成三次握手，连接建立。

2.四次挥手

第一次挥手：Client将FIN置为1，发送一个序列号seq给Server；进入FIN_WAIT_1状态；
第二次挥手：Server收到FIN之后，发送一个ACK=1，acknowledge number=收到的序列号+1；进入CLOSE_WAIT状态。此时客户端已经没有要发送的数据了，但仍可以接受服务器发来的数据。
第三次挥手：Server将FIN置1，发送一个序列号给Client；进入LAST_ACK状态；
第四次挥手：Client收到服务器的FIN后，进入TIME_WAIT状态；接着将ACK置1，发送一个acknowledge number=序列号+1给服务器；服务器收到后，确认acknowledge number后，变为CLOSED状态，不再向客户端发送数据。客户端等待2*MSL（报文段最长寿命）时间后，也进入CLOSED状态。完成四次挥手。

3.为什么不能把服务器发送的ACK和FIN合并起来，变成三次挥手（CLOSE_WAIT状态意义是什么）？

因为服务器收到客户端断开连接的请求时，可能还有一些数据没有发完，这时先回复ACK，表示接收到了断开连接的请求。等到数据发完之后再发FIN，断开服务器到客户端的数据传送。

4.如果第二次挥手时服务器的ACK没有送达客户端，会怎样？

客户端没有收到ACK确认，会重新发送FIN请求。

5.客户端TIME_WAIT状态的意义是什么？

第四次挥手时，客户端发送给服务器的ACK有可能丢失，TIME_WAIT状态就是用来重发可能丢失的ACK报文。如果Server没有收到ACK，就会重发FIN，如果Client在2*MSL的时间内收到了FIN，就会重新发送ACK并再次等待2MSL，防止Server没有收到ACK而不断重发FIN。

MSL(Maximum Segment Lifetime)，指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

6.TCP建立连接可以两次握手吗？为什么?

不可以。有两个原因：

首先，可能会出现已失效的连接请求报文段又传到了服务器端。

client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用 “三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用 “三次握手” 的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。

其次，两次握手无法保证Client正确接收第二次握手的报文（Server无法确认Client是否收到），也无法保证Client和Server之间成功互换初始序列号。

7.可以采用四次握手吗？为什么？

可以。但是会降低传输的效率。

四次握手是指：第二次握手：Server只发送ACK和acknowledge number；而Server的SYN和初始序列号在第三次握手时发送；原来协议中的第三次握手变为第四次握手。出于优化目的，四次握手中的二、三可以合并。

8.第三次握手中，如果客户端的ACK未送达服务器，会怎样？

Server端：
由于Server没有收到ACK确认，因此会重发之前的SYN+ACK（默认重发五次，之后自动关闭连接进入CLOSED状态），Client收到后会重新传ACK给Server。

Client端，两种情况：

在Server进行超时重发的过程中，如果Client向服务器发送数据，数据头部的ACK是为1的，所以服务器收到数据之后会读取 ACK number，进入 establish 状态
在Server进入CLOSED状态之后，如果Client向服务器发送数据，服务器会以RST包应答。

9.如果已经建立了连接，但客户端出现了故障怎么办？

服务器每收到一次客户端的请求后都会重新复位一个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

10.初始序列号是什么？

TCP连接的一方A，随机选择一个32位的序列号（Sequence Number）作为发送数据的初始序列号（Initial Sequence Number，ISN），比如为1000，以该序列号为原点，对要传送的数据进行编号：1001、1002…三次握手时，把这个初始序列号传送给另一方B，以便在传输数据时，B可以确认什么样的数据编号是合法的；同时在进行数据传输时，A还可以确认B收到的每一个字节，如果A收到了B的确认编号（acknowledge number）是2001，就说明编号为1001-2000的数据已经被B成功接受。

11.TCP如何实现流量控制？

使用滑动窗口协议实现流量控制。防止发送方发送速率太快，接收方缓存区不够导致溢出。接收方会维护一个接收窗口 receiver window（窗口大小单位是字节），接受窗口的大小是根据自己的资源情况动态调整的，在返回ACK时将接受窗口大小放在TCP报文中的窗口字段告知发送方。发送窗口的大小不能超过接受窗口的大小，只有当发送方发送并收到确认之后，才能将发送窗口右移。

发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力。