TCP基础知识----3次握手 4次挥手

TCP连接由四元组唯一标识

一：三次握手协议

建立连接 最少需要3次握手。需要client主动发起请求

 

为什么需要3次握手：

这是考虑到丢包情况的，如果丢包情况不存在，2次就够了。。。。但是丢包是实实在在存在的

如果只握手2次，第二次握手时server发送给client的数据包丢失了，此时server认为已经准备好了，而client一直没有收到确认报文，所以client就不知道服务器是否准备好了，这时client不会给server发数据，而且也会忽略server给client发来的数据。。。

如果是握手3次，即便发生丢包也不会有问题，如果第一次握手数据包丢了，client在等待接收第二次握手数据包时会超时，这个时候client就知道第一次握手数据包要么丢了，要么就是server收到了第一次握手的消息但是第二次握手的消息丢了。重新建立连接

如果第三次握手的数据包丢了，server端在一段时间内没有收到ACK报文的话，server端会再次发送第二次握手，重新发送SYN报文段，直到server收到client发来的第三次握手协议。

三次握手的原因：

• 三次握手才可以阻止重复历史连接的初始化（主要原因）
• 三次握手才可以同步双方的初始序列号
• 三次握手才可以避免资源浪费

客户端连续发送多次 SYN 建立连接的报文，在网络拥堵情况下：一个「旧 SYN 报文」比「最新的 SYN 」 报文早到达了服务端；那么此时服务端就会回一个 SYN + ACK 报文给客户端；客户端收到后可以根据自身的上下文，判断这是一个历史连接（序列号过期或超时），那么客户端就会发送 RST 报文给服务端，表示中止这一次连接。

如果是两次握手连接，就不能判断当前连接是否是历史连接，三次握手则可以在客户端（发送方）准备发送第三次报文时，客户端因有足够的上下文来判断当前连接是否是历史连接：如果是历史连接（序列号过期或超时），则第三次握手发送的报文是 RST 报文，以此中止历史连接；如果不是历史连接，则第三次发送的报文是 ACK 报文，通信双方就会成功建立连接；所以，TCP 使用三次握手建立连接的最主要原因是防止历史连接初始化了连接。

 

两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收 

二：四次挥手协议

 

 关闭连接 close(socket) client和server端都可以主动提出请求，上图只是以client 主动发起关闭请求为例。

为什么需要4次挥手协议：

client发出FIN报文时只能保证client没有数据了，server端还是否有数据要发给client端它是不知道的。所以server端在收到client端发来的FIN报文后先给client回一个ACk确认报文来告诉client 你发的FIN我收到了。server端还有一些数据没有发完，等这些数据都发完了之后才给client发送FIN报文。（所以不能一次性将确认报文和FIN报文发送给client，相比建立连接时的3次握手 这就多出来这么一次来了）

TIME_WAIT存在的理由：

首先调用close()发起主动关闭的一方，在发送最后一个ACK之后会进入time_wait的状态，也就说该发送方会保持2MSL时间之后才会回到初始状态。MSL值得是数据包在网络中的最大生存时间。

产生这种结果使得这个TCP连接在2MSL连接等待期间，定义这个连接的四元组（客户端IP地址和端口，服务端IP地址和端口号）不能被使用

1：为实现TCP全双工连接的可靠释放

假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，该TCP连接才能恢复初始的CLOSED状态。

如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常。

2）为使旧的数据包在网络因过期而消失

可以保证当成功建立一个新TCP连接的时候，来自旧连接重复分组已经在网络中消逝。为说明这个问题，我们先假设TCP协议中不存在TIME_WAIT状态的限制，再假设当前有一条TCP连接：(local_ip, local_port, remote_ip,remote_port)，因某些原因，我们先关闭，接着很快以相同的四元组建立一条新连接。本文前面介绍过，TCP连接由四元组唯一标识，因此，在我们假设的情况中，TCP协议栈是无法区分前后两条TCP连接的不同的，在它看来，这根本就是同一条连接，中间先释放再建立的过程对其来说是“感知”不到的。这样就可能发生这样的情况：前一条TCP连接由local peer发送的数据到达remote peer后，会被该remot peer的TCP传输层当做当前TCP连接的正常数据接收并向上传递至应用层（而事实上，在我们假设的场景下，这些旧数据到达remote peer前，旧连接已断开且一条由相同四元组构成的新TCP连接已建立，因此，这些旧数据是不应该被向上传递至应用层的），从而引起数据错乱进而导致各种无法预知的诡异现象。作为一种可靠的传输协议，TCP必须在协议层面考虑并避免这种情况的发生，这正是TIME_WAIT状态存在的第2个原因。

避免TIME_WAIT

首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。

connect、accept发生在三次握手的哪一步:

connect在第二次握手时返回、accept是在第三次握手时返回。

第一次握手时，创建连接，connect处于阻塞状态，等待服务器accept，第二次握手成功，connect从阻塞返回。同样的accept需要收到客户端的ACK以后才从阻塞返回，连接建立完成。。。

TCP在listen时的参数backlog的意义

linux内核中会维护两个队列：
　　1）未完成队列：接收到一个SYN建立连接请求，处于SYN_RCVD状态
　　2）已完成队列：已完成TCP三次握手过程，处于ESTABLISHED状态
　　当有一个SYN到来请求建立连接时，就在未完成队列中新建一项。当三次握手过程完成后，就将套接口从未完成队列移动到已完成队列。
　　backlog曾被定义为两个队列的总和的最大值，也曾将backlog的1.5倍作为未完成队列的最大长度
一般将backlog指定为5

SYN攻击：

1：client伪的IP向服务器发送一个SYN请求建立连接，然后服务器向该IP回复SYN和ACK，但是找不到该IP对应的主机或者是找到了对应的主机但是该主机都没有握手连接的需求它肯定会无视这个SYN+ACK，这个时候服务器收不到第三次握手的ACK，一直处于SYN_RECV状态 坐等超时。。当超时时服务器收不到ACK会重复第二次握手发送数据。当大量的攻击者请求建立连接时，服务器就会存在大量未完成三次握手的连接，服务器主机backlog被耗尽而不能响应其它连接。即SYN泛洪攻击 （属于DOS的一种，发送大量的半连接请求，耗费CPU和内存资源，引起网络堵塞甚至系统瘫痪）   netstat -n -p TCP | grep SYN_RECV

2：当一个主机向服务器发送SYN请求连接，服务器回复ACK和SYN后，攻击者截获ACK和SYN。然后伪装成原始主机继续与服务器进行通信。

DOS攻击(拒绝服务攻击)

DOS攻击利用合理的服务请求占用过多的服务资源，使正常用户的请求无法得到相应。

常见的DOS攻击有计算机网络带宽攻击和连通性攻击。

带宽攻击指以极大的通信量冲击网络，使得所有可用网络资源都被消耗殆尽，最后导致合法的用户请求无法通过。

连通性攻击指用大量的连接请求冲击计算机，使得所有可用的操作系统资源都被消耗殆尽，最终计算机无法再处理合法用户的请求

防御 SYN 攻击的方法：

• 增大半连接队列；
• 开启 tcp_syncookies 功能
• 减少 SYN+ACK 重传次数

RST包出现的原因：

服务器端口没有打开  客户端就来连接时

在一个已经关闭的socket 上收数据