三次握手及其扩展内容学习记录

前导知识：
要知道三次握手和四次挥手就必须要了解我们tcp报文的格式，下面图片就是tcp报文的格式

前置技能：这个地方不详细解释报文的每一个字段这里需要用到的字段有

紧急位URG：URG=1时，表明此报文段中有紧急数据，是高优先级的数据，应尽快传递，不用再缓冲中排队，配合紧急指针字段使用。

确认位ACK：ACK=1时，确认号有效，在连接建立后所有传送的报文段都必须把ACK置为1。

推送位PSH：PSH=1时，接收方尽快交付接收应用进程，不再等到缓存填满再向上交付。

复位RST ：RST=1时，表明TCP连接出现险种差错，必须释放连接，然后重新建立传输链接。

同步位SYN：SYN=1时，表明是一个连接请求/连接接受报文。

终止位FIN：FIN=1时，表明此报文段发送方数据已发送完，要释放连接。

---

SYN_SENT : 请求连接，当你要访问其它的计算机的服务时首先要发个同步信号给该端口，此时状态为SYN_SENT

ISN：初始化序列号，是在建立tcp三次握手的时候，存储在TCP头部的序列号位置中的数字的代称。

SYN_RCVD:TCP三次握手的中间状态，是服务端口如应用服务器端口，收到SYN包并发送[SYN，ACK]包后所处的状态

三次握手

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

每次握手的作用
第一次握手：
客户端的发送能力、服务端的接收能力是正常的。
第二次握手：
服务端的接收、发送能力，客户端的发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：
客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

延展问题1：四次握手可以吗？
答案是可以但是会浪费资源，三次握手是将这里的第三次握手和第四次握手合并在了一起，如果采用四次握手会浪费资源

延展问题2：那么两次握手能不能达到三次握手的效果？

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

延展问题3：什么是半连接队列？

顾名思义就是连接到一半的队列。服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

这里在补充一点关于SYN-ACK 重传次数的问题：

服务器发送完SYN-ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传。如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。

注意，每次重传等待的时间不一定相同，一般会是指数增长，例如间隔时间为 1s，2s，4s，8s…

延展问题4.什么是全连接队列？

就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

扩展问题5.isn(Initial Sequence Number)是固定的吗？

当一端为建立连接而发送它的SYN时，它为连接选择一个初始序号。ISN随时间而变化，因此每个连接都将具有不同的ISN。ISN可以看作是一个32比特的计数器，每4ms加1 。这样选择序号的目的在于防止在网络中被延迟的分组在以后又被传送，而导致某个连接的一方对它做错误的解释。

三次握手的其中一个重要功能是客户端和服务端交换 ISN(Initial Sequence Number)，以便让对方知道接下来接收数据的时候如何按序列号组装数据。如果 ISN 是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

5.1那么syn攻击是什么？

SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。当出现大量的半连接状态的时候，我们就需要考虑是不是SYN攻击。

服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。

5.2SYN攻击如何预防
1.缩短超时（SYN Timeout）时间
2.增加最大半连接数
3.过滤网关防护
4.SYN cookies技术

扩展问题6.三次握手过程能携带数据吗

大家可以想一个问题：
假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

所以，第三次握手的时候，是可以携带数据的。但是，第一次、第二次握手不可以携带数据

三次握手，期间造成半打开状态怎么办

半关闭：
当TCP链接中A向B发送 FIN 请求关闭，另一端B回应ACK之后，并没有立即发送 FIN 给A,A方处于半连接状态（半开关），此时A可以接收B发送的数据，但是A已经不能再向B发送数据。

半连接：
发生在TCP三次握手中
如果A向B发起链接，B也按照正常情况响应了，但是A不进行三次握手，这就是半连接。
半连接攻击：半连接，会造成B分配的内存资源就一直这么耗着，直到资源耗尽。（SYN攻击）

半打开：
如果一方关闭或者异常关闭（断电，断网），而另一方并不知情，这样的链接称之为半打开。处于半打开的连接，如果双方不进行数据通信，是发现不了问题的，只有在通信是才真正的察觉到这个连接已经处于半打开状态，如果双方不传输数据的话，仍处于连接状态的一方就不会检测另外一方已经出现异常

解决方法：
1.如何解决半打开问题，引入心跳机制就可以察觉半打开。

2.如果需要发数据的话，这边收到之后 其实发现这个连接并不存在了，就会回复RST包告知，这个时候就需要重新建立连接了！