三次握手，四次挥手

最新推荐文章于 2024-10-22 08:30:00 发布

Mango_WXL

最新推荐文章于 2024-10-22 08:30:00 发布

阅读量176

点赞数

分类专栏：计算机网络基础

计算机网络基础专栏收录该内容

5 篇文章 0 订阅

订阅专栏

http连接分为：建立连接，即tcp三次握手

发送请求信息

发送响应信息

关闭连接（tcp四次握手）；下面讲此过程：

TCP(Transmission Control Protocol)　传输控制协议

TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:

位码即tcp标志位,有6种标示:SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)

Sequence number(顺序号码) Acknowledge number(确认号码)

第一次握手：主机A发送位码为syn＝1,随机产生seq number=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；

第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包

第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。

完成三次握手，主机A与主机B开始传送数据。

在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。完成三次握手，客户端与服务器开始传送数据.

实例:

IP 192.168.1.116.3337 > 192.168.1.123.7788: S 3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack 3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1

第一次握手：192.168.1.116发送位码syn＝1,随机产生seq number=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;

第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送ack number=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;

第三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。

图解：
一个三次握手的过程（图1，图2）

（图1）

（图2）

第一次握手的标志位（图3）
我们可以看到标志位里面只有个同步位，也就是在做请求(SYN)

（图3）

第二次握手的标志位（图4）
我们可以看到标志位里面有个确认位和同步位，也就是在做应答(SYN + ACK)

（图4）

第三次握手的标志位（图5）
我们可以看到标志位里面只有个确认位，也就是再做再次确认(ACK)

（图5）

一个完整的三次握手也就是请求---应答---再次确认

所谓三次握手(Three-way Handshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口，建立TCP连接,并同步连接双方的序列号和确认号并交换 TCP 窗口大小信息.在socket编程中，客户端执行connect()时。将触发三次握手。

id="iframe_0.8992152938930862" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fblogimg.chinaunix.net%2Fblog%2Fupfile2%2F100327002629.png&maxWidth=742&origin=http://www.cnblogs.com&iframeId=iframe_0.8992152938930862" frameborder="0" scrolling="no" height="20" style="margin: 0px; padding: 0px; border: none; width: 742px;">

第一次握手:
客户端发送一个TCP的SYN标志位置1的包指明客户打算连接的服务器的端口，以及初始序号X,保存在包头的序列号(Sequence Number)字段里。

id="iframe_0.7967048575244087" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fblogimg.chinaunix.net%2Fblog%2Fupfile2%2F100327002911.png&maxWidth=742&origin=http://www.cnblogs.com&iframeId=iframe_0.7967048575244087" frameborder="0" scrolling="no" height="20" style="margin: 0px; padding: 0px; border: none; width: 742px;">

第二次握手:
服务器发回确认包(ACK)应答。即SYN标志位和ACK标志位均为1同时，将确认序号(Acknowledgement Number)设置为客户的I S N加1以.即X+1。

id="iframe_0.5317043835607378" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fblogimg.chinaunix.net%2Fblog%2Fupfile2%2F100327003054.png&maxWidth=742&origin=http://www.cnblogs.com&iframeId=iframe_0.5317043835607378" frameborder="0" scrolling="no" height="20" style="margin: 0px; padding: 0px; border: none; width: 742px;">

第三次握手.
客户端再次发送确认包(ACK) SYN标志位为0,ACK标志位为1.并且把服务器发来ACK的序号字段+1,放在确定字段中发送给对方.并且在数据段放写ISN的+1

SYN攻击

在三次握手过程中，服务器发送SYN-ACK之后，收到客户端的ACK之前的TCP连接称为半连接(half-open connect).此时服务器处于Syn_RECV状态.当收到ACK后，服务器转入ESTABLISHED状态.

Syn攻击就是攻击客户端在短时间内伪造大量不存在的IP地址，向服务器不断地发送syn包，服务器回复确认包，并等待客户的确认，由于源地址是不存在的，服务器需要不断的重发直至超时，这些伪造的SYN包将长时间占用未连接队列，正常的SYN请求被丢弃，目标系统运行缓慢，严重者引起网络堵塞甚至系统瘫痪。

Syn攻击是一个典型的DDOS攻击。检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击.在Linux下可以如下命令检测是否被Syn攻击

netstat -n -p TCP | grep SYN_RECV

一般较新的TCP/IP协议栈都对这一过程进行修正来防范Syn攻击，修改tcp协议实现。主要方法有SynAttackProtect保护机制、SYN cookies技术、增加最大半连接和缩短超时时间等.

但是不能完全防范syn攻击。

TCP 四次挥手

TCP的连接的拆除需要发送四个包，因此称为四次挥手(four-way handshake)。客户端或服务器均可主动发起挥手动作，在socket编程中，任何一方执行close()操作即可产生挥手操作。

id="iframe_0.7030089056638649" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fblogimg.chinaunix.net%2Fblog%2Fupfile2%2F100327022731.jpg&maxWidth=742&origin=http://www.cnblogs.com&iframeId=iframe_0.7030089056638649" frameborder="0" scrolling="no" height="20" style="margin: 0px; padding: 0px; border: none; width: 742px;">

参见wireshark抓包，实测的抓包结果并没有严格按挥手时序。我估计是时间间隔太短造成。

id="iframe_0.7649347638457134" src="https://www.cnblogs.com/show-blocking-image.aspx?url=http%3A%2F%2Fblogimg.chinaunix.net%2Fblog%2Fupfile2%2F100327023334.png&maxWidth=742&origin=http://www.cnblogs.com&iframeId=iframe_0.7649347638457134" frameborder="0" scrolling="no" height="20" style="margin: 0px; padding: 0px; border: none; width: 742px;">

 在TCP断开的过程中会有四个状态变化过程,如下图所示:  在连接撤销过程中，有如下过程: 1.HOST1上的应用程序关闭己方的连接导致TCP发送一个FIN消息给HOST2。 2.HOST2发送一个确认消息给HOST1,并且HOST2把FIN作为EOF递交给HOST2上的应用程序。 3.一段时间过后，HOST2上的应用程序关闭它那边的连接，引发一个FIN消息给HOST1。 4.HOST1给HOST2发送一个确认消息，然后HOST2关闭连接并释放资源，然而，HOST1却没有关闭连接，而是进入了TIME_WAIT状态，并为两个最大段生存时间(2MSL)保留在此状态.
 
为什么需要TIME_WAIT? 1.因为在第四步的时候，HOST1发送的ACK可能丢失并导致HOST2重新发送FIN消息，TIME_WAIT维护连接状态.
  如果执行主动关闭的一方HOST1 不进入到TIME_WAIT状态就关闭连接那会发生什么呢？当重传的FIN消息到达时，因为TCP已经不再有连接的信息了，所以就用RST(重新启动)消息应答，导致HOST2进入错误的状态而不是有序终止状态，如果发送最后ACK消息的一方处于TIME_WAIT状态并仍然记录着连接的信息，它就可以正确的响应对等方HOST2的FIN消息了. 2.TIME_WAIT为连接中”离群的段”提供从网络中消失的时间.
  考虑一下，如果延迟或者重传段在连接关闭后到达时会发生什么呢？通常情况下，因为TCP仅仅丢弃该数据并响应RST消息，所以这不会造成任何问题。当RST消息到达发出延时段的主机时，因为该主机也没有记录连接的任何信息，所以它也丢弃该段。然而，如果两个相同主机之间又建立了一个具有相同端口号的新连接，那么离群的段就可能被看成是新连接的，如果离群的段中数据的任何序列号恰恰在新连接的当前接收窗口中，数据就会被重新接收，其结果就是破坏新连接。