TCP三次握手详解_tcp三次握手报文分析

 准备工作

进行连接

能把三次握手改为两次握手吗？

改为四次握手行不行？

TCP第三次握手失败了怎么办？

初始序列号ISN(Initial Sequence Number)是固定的吗？

三次握手是否可以携带数据？

SYN泛洪攻击

总结

---

---

 

TCP提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好通信两端之间的准备工作。

准备工作

TCP服务器先创建传输控制块TCB，时刻准备接收客户进程的连接请求，此时服务器处于LISTEN(监听)状态，客户端处于CLOSE(关闭)状态。

什么是传输控制块？

TCB传输控制块包含了数据发送双方对应的socket信息以及拥有装载数据的缓冲区。

在两个设备在建立连接之前，双方都必须要做一些准备工作，分配内存建立起TCB传输控制块就是连接之前必须要做的工作。

进行连接

第一次握手：客户端给服务器发送一个同步报文段SYN，并指定客户端的初始序列号ISN，此时客                        户端处于SYN_SENT状态。

                      首部的同步位SYN = 1(SYN只是一个比特位，0表示不是SYN，1表示是SYN)，初始                       序列号seq = m。

                      SYN = 1的报文段不能携带任何的数据，但要指定序号。

第二次握手：服务器接收到来自客户端的同步报文段SYN后，会以自己的SYN报文作为应答，                             并且也指定了自己的初始序列号ISN。同时会把客户端的 seq+1 确认序列号ack的                           值，表示自己已经收到了客户端的同步报文段SYN，此时服务器处于SYN_RCVD的                       状态。

                    确认报文段中SYN = 1,ACK = 1(ACK也只是一个比特位，0表示不是ACK，1表示是                        ACK)，确认序列号ack = m+1，初始序列号seq = n。

第三次握手：客户端收到来自服务器的同步报文段SYN之后，会发送一个确认报文段ACK，以服                         务器的 seq+1作为ack的值 ，表明自己已经收到来自服务器的同步报文段SYN。客                         户端进入ESTABLISHED状态，服务器确认报文段ACK之后，也会进入                                           ESTABLISHED状态。

                     确认报文段中，ACK = 1，确认序列号 ack = n+1，序列号 seq = m+1。

双方已经建立起连接，可以正常的发送数据。

能把三次握手改为两次握手吗？

肯定不行！！！第三次握手是为了防止失效的请求连接到达服务器，让服务器错误的打开连接。

举个列子:

TCP的三次握手和打电话非常的类似 

        电话拨通后，发送方不知道自己的发送能力是否正常，

 于是“歪？歪？”两声看看对方能不能听到。

接收方听到发送方的声音后，此时接受方就可以得出发送方的发送能力和自己的接收能力是正常的。但此时发送方还不知道自己的发送能力是否正常，于是接收方对发送方回复: "歪 你找我干啥"。

发送方收到来自接收方的回复后，就知道 自己的发送能力和接收能力是正常的，接受方的发送能力和接收能力也是正常的。但此时接收方并不知道自己的发送能力和发送方的接收能力是否正常。

 

发送方为了让接收方知道自己已经收到回复，就向接收发发送了"你是猪"。接收方收到后，接收方就知道自己的发送能力和发送方的接收能力也是正常的。

这下子双方可以进行愉快的交流啦！

总的来说，经过三次握手让客户端和服务器互相知道了自己的发送、接收和对方发送、接收都是正常的。

改为两次握手会出现什么后果？

假如客户端发出了连接请求，但因为网络波动导致服务器并没有收到来自客户端的请求连接，于是客户端又重发了一次连接请求，客户端和服务器经过两次握手就建立好连接。双方开始传输数据，数据传输完成以后，双方断开连接。过一段时间后，原本在网络传输中搁置的连接请求到达了服务器。服务器以为是客户端又发出来一次新的连接请求，于是就向客户端发送确认报文段，同意建立连接(两次握手只需要服务器发出确认报文段，就建立好连接)。此时服务器一直在等待客户端发送的数据，一直浪费着系统资源。

改为四次握手行不行？

行！！！TCP三次握手原本应该是"四次握手"，但是中间的同步报文段SYN和应答报文ACK是可以合在一起的，这两个操作在时间上是同时发送的。

当客户端的到达同步报文段SYN到达服务器的时候，服务器的内核就会第一时间进行应答报文段ACK， 同时也会第一时间发起同步报文段SYN,这两件事情同时触发，于是就没必要分成两次传输，直接一步到位。分成两次反而会更浪费系统资源(需要进行两次的封装和分用)。

TCP第三次握手失败了怎么办？

服务器发送了SYN+ACK报文后就会启动一个定时器，等待客户端返回的ACK报文。如果服务器在定时器的范围内没有收到来自客户端的ACK报文，服务器会再次重发SYN+ACK报文。重传的次数可以根据/proc/sys/net/ipv4/tcp_synack_retries来指定，默认为5次。

达到重传的指定次数后仍然没有收到ACK应答，那么一段时间后，服务器自动关闭这个连接。但是client认为这个连接已经建立好了。

如果客户端向服务器发送数据，服务器将以RST包(重置连接)响应。

初始序列号ISN(Initial Sequence Number)是固定的吗？

序列号是按顺序给发送数据的每一个字节（8位字节）都标上号码的编号。

当一端为建立连接而发送它的SYN时，它会为连接选择一个初始的序列号ISN(客户端和服务器会分别选择一个初始序列号ISN)。初始序列号ISN并非为0，而是由随机数生成，而后面的计算则是对每一字节加一。

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

三次握手是否可以携带数据？

第一次、第二次不可以，第三次可以。

如果第一次握手可以携带数据的话，那么将会使服务器更容易遭受攻击。如果第一次握手携带就大量的数据，那么服务器需要花老长的时间才能对此解析。如果进行重复的发送，那么服务器就会因为系统资源殆尽而崩溃。

第三次握手可以携带数据。第三次握手时客户端处于ESTABLISH状态。对于客户端来说，它已经建立好了连接，并且它已经知道服务器的接收能力和自己的发送能力是正常的，所以可以进行正常的发送数据。

SYN泛洪攻击

SYN泛洪攻击利用的是TCP的三次握手机制，攻击端利用伪造的IP地址向服务器发出请求，而被服务器发出的响应响应将永远发送不到目的地，那么就会触发服务器的超时重传机制等待客户端的响应(客户端的IP地址不存在，根本不会进行响应)。那么被服务器在等待关闭这个连接的过程中消耗了资源，如果有成千上万的这种连接，主机资源将被耗尽，从而达到攻击的目的。

措施：

        降低SYN timeout时间

        采用SYN cookie设置

        增加半连接数

        合理地采用防火墙等外部网络安全设施

总结

         三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的。三次握手的过程中会同步客户端和服务器的序列号，为确认应答处理、重发控制以及重复控制等功能提供了保证。