三次握手

本文大致上是对三次握手和四次挥手详细这篇文章的复述，文中出现的图片如未特殊说明，也均出自于该文章，本文仅用于个人学习记录，侵删。

三次握手的目的：

建立可靠的通信信道，双方彼此确认互相之间的接收与发送是正常的。

第一次握手：客户端（client）什么都不能确认，服务端（server）确认对方发送正常，确认自己接收正常。
第二次握手：客户端（client）确认自己发送正常，接收正常，对方发送正常，接收正常。
第三次握手：服务端（server）确认对方接受正常，自己发送正常。

具体过程

• 第一次握手
  首先服务端处于监听状态（Listen），客户端向服务端发出连接请求报文，设置首部中同步位SYN=1，同时选择一个初始序号seq=x，客户端进入同步发送状态（SYN-SENT）。
• 第二次握手
  服务器接收到请求报文段后，如果同意建立连接，则向客户端发送确认报文段，在确认报文段中，设置SYN=1，ACK=1，确认号是ack=x+1，表示服务端希望客户端下一次返回的数据的序列号为x+1。同时，也选择一个初始序号seq=y。服务端进入同步收到状态（SYN-RCVD）。
• 第三次握手
  客户端收到服务器发来的确认信号，还要再次发送确认信号给服务端。确认报文中，设置ACK=1，确认号是ack=y+1，而序列号则是seq=x+1。客户端进入已建立连接状态（ESTABLISHED），服务端接收到确认报文后，也进入已建立连接状态。

相关问题

TCP连接为什么是三次

• 服务端：防止已经失效的请求报文又传送到了服务端而产生连接的误判
  比如：客户端发送了一个请求A到服务端，由于网络原因，A在网络中滞留了很久，而客户端根据机制超时重发，重新发送了一个B请求，与服务端建立了连接，传输完成后又断开连接。之后，在网络中滞留的A终于到达了服务端，服务器就认为客户端又申请建立连接，如果不是三次握手的话，服务端只要发送了确认，就建立了连接，但是客户端不会理会服务端的确认，也不会发送数据，服务端就这么一直等着，直到超时，才会关闭连接，导致服务端资源浪费。如果采用三次握手，服务端由于收不到客户端发来的确认，就不会建立连接。
• 客户端
  假如没有第三次握手，在第二次握手失败的时候，服务端发出去请求就认为连接成功了。所以开始发送数据，客户端其实都没有收到第二次握手，都不知道服务端建立的什么样的序列号，可能会服务器发来的数据都忽略掉了。

附：SYN洪泛攻击

原理：攻击者伪造地址对服务端发起SYN请求，服务器回应（SYN+ACK）包，而真实的IP会认为，我没有发送请求，因此不会响应，服务器也就收不到回应。这样的话，服务器不知道（SYN+ACK）包是否发送成功，默认情况下会重试五次。这样对服务器的内存，带宽都有很大的消耗。

解决方法：
1． 无效连接监视释放
这种方法不停的监视系统中半开连接和不活动连接，当达到一定阈值时拆除这些连接，释放系统资源。这种绝对公平的方法往往也会将正常的连接的请求也会被释放掉，”伤敌一千，自损八百“
2． 延缓TCB分配方法
SYN Flood关键是利用了，SYN数据报文一到，系统立即分配TCB（线程控制块）资源，从而占用了系统资源，因此有俩种技术来解决这一问题

Syn Cache技术
这种技术在收到SYN时不急着去分配TCB，而是先回应一个ACK报文，并在一个专用的HASH表中（Cache）中保存这种半开连接，直到收到正确的ACK报文再去分配TCB
Syn Cookie技术
Syn Cookie技术则完全不使用任何存储资源，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方 的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源
3． 使用SYN Proxy防火墙
原理：对试图穿越的SYN请求进行验证之后才放行

参考文章

三次握手和四次挥手详细
一文读懂一个URL请求的过程是怎样的.