三次握手四次挥手

三次握手四次挥手

三次握手简单介绍

首先由客户端发出连接请求, 此时客户端向服务器端发送一个 SYN 请求建立连接, 自己进入 SYN_SENT 状态, 当服务器端接收到这个 SYN 请求报文的的时候此时服务器向客户端发送一个 SYN + ACK 表名客户端发送过来的请求自己已经收到, 进入SYN_RCD状态, 客户端收到这个报文时, 此时客户端认为连接建立好了, 于是给服务器端发送一个 ACK 确认报文, 自己进入 ESTABLISHED 状态, 当服务器接受到这个确认应答的时候, 此时认为自己发送的连接也已经建立好, 进入 ESTABLISHED 状态于是连接建立, 双方便可以进行通信了.

四次挥手简单介绍

当服务器和客户端之间的数据已经发送完的时候, 此时客户端主动发起断开连接的请求报文 FIN, 此时客户端进入 FIN_WAIT1 状态, 当服务器端接受到这个消息的时候, 会给客户端发送一个确认应答的消息, 表名自己同意连接断开, 此时自己进入 CLOSE_WAIT 状态, 客户端接受到服务器端发送过来的确认应答 ACK 的时候, 客户端进入 FIN_WAIT2 状态, 此时服务器也会给客户端发送一个断开连接的请求报文 FIN,于是服务器的状态变为了LAST_ACK, 客户端接受到服务器发来的 FIN 这个消息的时候会进入 TIME_WAIT 状态, 同时客户端向服务器发送一个 ACK 应答报文, 当服务器接收到这个 ACK 确认应答报文的时候, 此时双方都进入 CLOSED 状态

三次握手中的几个问题

通过上面的简单介绍, 可以看出要建立连接, 进行一次握手肯定不行, 但是为什么要进行三次握手呢? 两次握手行不行呢?

为什么两次握手不行

我们都知道, 在进行网络通信的时候双方发送的报文都有可能丢失, 建立连接的过程中也不例外. 当建立连接的时候, 如果进行两次握手, 此时服务器向客户端发送的 SYN + ACK 一旦丢失, 客户端得不到服务器端的 ACK 确认应答报文, 此时客户端会认为自己发送的连接请求服务器没有接受到, 于是客户端不断的向服务器端发送 SYN 请求报文, 可是服务器发送的 SYN +ACK 一直会丢失, 此时服务器会认为双方连接已经建立起来了. 而操作系统在面对一大批的连接的时候, 此时肯定需要将这些连接进行管理, 于是将这些连接先描述后组织, 描述肯定会用到结构体, 组织肯定会用到链表. 于是将大批的无用连接管理. 但是想一想, 连接是不是资源呢? 连接肯定是一种资源, 既然连接是资源, 那么建立连接, 组织连接肯定需要花费时间精力成本等等, 此时服务器为了对这些无用连接进行管理势必会造成服务器端的压力特别特别大, 当无用连接达到一定数目的时候, 服务器就会崩溃.

为什么要进行三次握手

三次握手中最后一个报文肯定也有可能会丢失, 但是当最后一个 ACK 丢失的时候, 此时客户端认为连接已经建立, 而服务器端会认为连接没有建立, 此时无论客户端向服务器端发送多少个报文都不会影响到服务器端, 因为服务器端一直认为连接没有建立好.

为什么不是四次握手

连接是一种资源, 既然三次握手已经可以保证数据可靠性传输, 为什么还要进行四次握手? 这不就没有必要了呗.

四次挥手中的几个问题

为什么要进行两次的 FIN

应为连接的断开时双方的事, 所以必须经过双方的同意才能断开连接

为什么要进行 TIME_WAIT

我们可以发现主动断开连接的一方会进入 TIME_WAIT 状态, 即主动断开连接的一方会进入等待状态, 等待的时间是 2*MSL, 其中 MSL 表示报文从客户端发送报文到服务器端接受报文中间所花费的最大时间.
如果没有 TIME_WAIT 这段等待时间, 此时当客户端发送给服务器端的 ACK 丢失时, 此时客户端已经认为连接断开, 而服务器端会认为连接还没有断开, 于是服务器不断向客户端发送 FIN 报文, 但是客户端认为连接已经断开, 它根本就不会对服务器端的 FIN 进行受理, 此时势必会导致一些问题.

为什么 TIME_WAIT 是 2*SML

当主动发起连接的一方进入 TIME_WAIT 时, ACK 的传输需要 SML 时间, 而对端向主动发起连接的一方发送报文也需要 SML 时间, 一旦主动发起连接的 ACK 丢失, 对端肯定会给发起连接的一方发送FIN, 此时花费 SML 时间, 也就是说当等待 2*SML 时间端后主动发起连接的一方还没有接受到 FIN 则证明对端已经接受到了 ACK, 于是进入 CLOSED 状态, 连接断开.