tcp的三次握手与四次握手过程，各个状态的名称与含义，一些问题？

迷南。 2021-12-10 20:47 162阅读 0赞

tcp建立连接的开始，会进行三次握手，tcp释放连接的时候，会进行四次挥手。

首先，三次握手

第一次握手，由客户端首先向服务器端发起请求，传送一个tcp连接请求的报文段，这个特殊的报文段不含应用层数据，其中首部的同步位SYN置1，ACK置0，另外，客户机会随机选择一个起始序号seq = x（连接请求不携带数据，但是需要消耗一个序号）。

第二次握手，由服务器的tcp收到连接请求报文段后，如果同意建立连接，就向客户机发回确认，并为该tcp连接分配缓存和变量。在确认报文段，SYN,ACK都置1，确认号字段值为ack=x+1,并且服务器随机产生一个起始序号seq=y,确认包同样不包含应用层数据。

第三次握手，当客户机收到服务器传来确认报文后，还要向服务器给出确认，并且也要给该连接分配缓存和变量。这个报文段的确认位ACK置1，序号段置seq= x+1,确认号字段为ack=y+1，该报文段可以携带数据，如果不携带数据则不消耗序号。

同时，一旦建立连接就是全双工通信，双方都能任何时候发送数据。

第一次握手时，客户机向服务器发送连接请求报文段。SYN=1,ACK=0,seq=x,请求发送后，客户机进入，SYN-SENT状态。

同时，SYN=1,ACK=0，代表连接请求报文。x为本次tcp通信的字节流初始序号。

第二次握手时，服务段收到连接请求报文段，如果同意连接，则会发送一个应答，SYN=1,ACK=1,seq=y,ack=x+1.该应答发送完成后便进入SYN-RCVD状态。

同时，SYN=1,ACK=1,代表报文段为连接同意报文段。seq=y代表服务端作为发送者，发送字节的初始序号。

ack=x+1代表服务器端希望下一个数据报从发送序号从x+1开始的字节。

第三次握手，当客户端收到连接同意的应答后，还要向服务端发送一个确认报文段，表示：服务端发来的连接同意应答已经成功收到。该报文段的头部为：ACK=1seq=x+1,ack=y+1.客户端发完这个报文段后便进入ESTABLISHED状态，服务端收到这个应答后也进入ESTABLISHED状态，此时连接的建立完成。

三次握手的隐患：

SYN Flood攻击，攻击者首先伪造地址对，服务器发起SYN请求，服务器回应（ACK+SYN）包，而真实的IP会认为，我没有发送请求，不作回应，服务器没有收到回应，这样的话,服务器不知道（SYN+ACK）是否发送成功。默认情况下重试5次，这样的话，对于服务器的内存，带宽都有消耗，攻击者处于公网ip，可以伪造Ip,对于服务器就很难根据ip来判断攻击者，给防护带来很大的困难。

防护：

1.无效连接监视释放

2.延缓分配资源

3.缩短超时时间

4.增加最大半连接数

5.过滤网管保护

6.SYN cookies技术

为啥采用三次握手，若采用二次握手可以吗？

1.tcp的三次握手过程：主机A向B发送连接请求；主机B对收到的主机A的请求的报文段进行了确认；主机A再次对主机B的确认进行确认。

2.采用三次握手是为了防止失效的连接请求报文段突然又传到主机B，因而产生错误。失效的连接请求报文段是指：主机A发出的连接请求没有收到主机B的确认，于是经过一段时间后，又重新 向B发送连接请求，且建立成功，顺序完成数据传输。考虑一种特殊情况，主机A第一次发送的连接请求没有丢失，因为网络情况延迟到达主机B，主机B以为是A又发起的新连接，于是同意连接，并向主机A发回确认，此时主机A根本不理会，主机B，就一直等待A发送数据，导致B资源浪费。

3.2次握手不行，就是因为上面说的特殊情况。

四次挥手过程，为什么四次挥手，主动方要等待2msl再关闭连接。？