关于TCP连接三次握手的详细总结

最新推荐文章于 2021-12-28 21:31:50 发布

生活甜甜好运连连

最新推荐文章于 2021-12-28 21:31:50 发布

阅读量696

点赞数

分类专栏： note 文章标签：网络

本文链接：https://blog.csdn.net/RitaAndWakaka/article/details/115867572

版权

note 专栏收录该内容

132 篇文章 1 订阅

订阅专栏

三次握手的过程：

开始时客户端状态：CLOSED 开始时服务器状态：LISTEN	第一次握手	第二次握手	第三次握手
From A to B	客户端 → 服务器	服务器 → 客户端	客户端 → 服务器
状态	客户端： CLOSED → SYN_SENT	服务器： LISTEN→ SYN_RCVD	客户端： SYN_SENT → ESTABLISHED 服务器收到ACK报文后： SYN_RCVD → ESTABLISHED
报文名字	SYN连接请求报文	SYN-ACK连接确认报文	ACK报文
发的啥（TCP标志位）	SYN = 1, ACK = 0 初始序号（ISN）：seq = x	SYN = 1，ACK = 1 确认号=客户端初始序列号（ISN）+ 1： ack = x + 1 seq = y	ACK = 1 确认号=服务器初始序列号（ISN）+ 1：ack = y + 1 seq = x + 1（客户端初始seq = x，发送一个SYN报文后消耗掉一个序号，所以这一次是第二个报文段，序号是x + 1）
消耗序号么？	消耗1个序号	不消耗	如果携带数据，则消耗。如果不携带数据就不消耗。
表示啥		表示服务器已经收到了客户端的SYN	表示客户端已经收到服务器的SYN。
报文能否携带数据？	不能	不能	能
半连接队列和全连接队列		服务器端收到客户端的SYN-ACK连接确认报文后，此时服务器处于SYN_RCVD状态，双方还没有完全建连接，服务器将此状态下的连接请求放在半连接队列中。如果 SYN 半连接队列已满，只能丢弃连接吗？并不是这样。开启 syncookies 功能就可以在不使用 SYN 队列的情况下成功建立连接。syncookies 是这么做的：服务器根据当前状态计算出一个值，放在己方发出的 SYN+ACK 报文中发出，当客户端返回 ACK 报文时，取出该值验证，如果合法，就认为连接建立成功。	服务器端收到客户端发送的ACK确认后，完成三次握手，TCP连接建立。建立的连接就放到全连接队列中。当全连接队列满了就可能出现丢包现象。
握手失败怎么办？	客户端发送 SYN 开启了三次握手，之后客户端连接的状态是 SYN_SENT，然后等待服务器回复 ACK 报文。正常情况下，服务器会在几毫秒内返回 ACK，但如果客户端迟迟没有收到 ACK 会怎么样呢？客户端会重发 SYN，重试的次数由 tcp_syn_retries 参数控制，默认是 6 次。		当第三次握手失败时，服务器并不会重传ACK报文，而是直接发送RST报文段，进入CLOSED状态。这样做的目的是为了防止SYN洪泛攻击。

为什么需要三次握手？（三次握手的目的是什么？能不能用两次握手达到同样的目的？）

	第一次握手	第二次握手	第三次握手
三次握手的目的：	1.确认双方的接收能力和发送能力是否正常 2.指定初始化序列号，为后面的可靠性传输做准备。
进行的操作	客户端发包，服务端收到包	服务器发包，客户端收到包	客户端发包，服务端收到包
谁，得出什么结论？	服务器知道，客户端的发送能力和服务器的接收能力正常。	客户端知道，客户端的接收发送ok 服务器的接收发送ok	服务器知道，客户端的接收能力和发送能力ok，服务器的接收和发送能力ok
因此需要三次握手才能确认双方的接收和发送能力是否正常。

三次握手过程中可以携带数据吗？

只有第三次握手的时候可以携带数据。

为什么这样？

如果第一次握手可以携带数据，会让服务器更加容易收到攻击。

如果第一次握手可以携带数据，如果有人恶意攻击服务器，可以在第一次握手中的 SYN连接请求报文中放入大量数据。因为攻击者不关心服务器的发送和接收能力是否正常，当客户端疯狂重复发送 SYN连接请求报文，会让服务器花费很多时间空间来接收这些报文。

第三次握手，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

什么是SYN（同步序列号：Synchronize Sequence Numbers）攻击？

SYN攻击就是客户端在短时间内伪造大量不存在的IP地址，并向服务器不断发送 SYN连接请求报文，服务器回复确认包，并等待客户端确认。由于源地址不存在，因此服务器要不断重发 SYN-ACK连接确认报文直至超时。这些伪造的SYN包将长时间占用半连接队列，导致正常的SYN连接请求报文因为队列已满而被丢弃，从而因此网络拥塞甚至系统瘫痪。