TCP三次握手/四次挥手常见疑问

最新推荐文章于 2022-09-19 23:59:36 发布

置顶那我懂你意思了

最新推荐文章于 2022-09-19 23:59:36 发布

阅读量298

点赞数 2

分类专栏：计算机网络内容梳理文章标签： tcpip socket 网络网络通信

本文链接：https://blog.csdn.net/hellow__world/article/details/111235561

版权

计算机网络内容梳理专栏收录该内容

3 篇文章 0 订阅

订阅专栏

三次握手常见问题：

首先TCP连接本质上并不是真的有什么东西连着在，只是说客户端和服务端为这次TCP连接创建了SOCKET，最终将SOCKET变为ESTABLLISHED状态，表明双方连接正常，可以通信。

这里主要总结下为什么必须是三次握手：

通过三次握手就可以确认通信双方的接收、发送能力是否正常:
- 第一次握手后，服务器可以知道：客户端的发送能力正常
- 第二次握手后，客户端可以知道：服务器的接收和发送能力正常
- 第三次握手后，服务器可以知道：客户端的接收能力也是正常的
防止服务器无效等待：假设客户端发送的SYN报文在某个网络节点滞留，因为客户端迟迟收不到回复报文，所以客户端会重新发起握手，此时建立连接。过了一段时候后，之前迷路的握手报文到达服务端，
假设只有两次握手，此时服务端回复报文，同时直接进入ESTABLISHED状态，等待客户端发送数据，然而客户端接受到这个回复报文后可能因为ack序列完全过时的原因直接丢弃这个报文，但是服务器无法感知，只能最终通过主动发送探测报文来决定是否主动关闭连接。
假设是三次握手，针对迷路报文建立起的连接可以通过第三次握手的复位标记来通知服务端释放资源。

常见的安全问题：SYN攻击

SYN 攻击会发送大量伪造的TCP连接请求（第一次握手），此时服务端会将这些连接放入到空间有限的半连接队列中，如果客户端不发出确认，服务器会等待到超时。假设半连接队列被打满，那正常连接就无法进入，服务器会返回拒绝连接或者直接丢弃掉正常连接的握手请求。
检测SYN攻击非常的方便，当你在服务器上看到大量的半连接状态时，特别是源IP地址是随机的，基本上可以断定这是一次SYN攻击。我们使用系统自带的netstat 工具来检测SYN攻击：

netstat -n -p TCP 
tcp　0　 0 10.11.11.11:23　124.173.152.8:25882　 SYN_RECV　- 
tcp　0　 0 10.11.11.11:23　236.15.133.204:2577　 SYN_RECV　- 
tcp　0　 0 10.11.11.11:23　127.160.6.129:51748　 SYN_RECV　- 
tcp　0　 0 10.11.11.11:23　222.220.13.25:47393　 SYN_RECV　- 
tcp　0　 0 10.11.11.11:23　212.200.204.182:60427 SYN_RECV　- 
tcp　0　 0 10.11.11.11:23　232.115.18.38:278　 SYN_RECV　- 
tcp　0　 0 10.11.11.11:23　239.116.95.96:5122　SYN_RECV　- 
tcp 0　0 10.11.11.11:23　236.219.139.207:49162 SYN_RECV　-

四次挥手常见问题：

为什么在TCP协议里，建立连接是三次握手，而关闭连接却是四次握手呢?

因为在三次握手时当处于LISTEN 状态的服务器端SOCKET当收到SYN报文(客户端希望新建一个TCP连接)后，它可以把
- ACK(应答作用)报文 
- SYN(同步作用)报文

放在同一个报文里来发送给客户端。

但在四次挥手关闭TCP连接时，当服务端收到客户端的FIN报文时，需要立即回复一个ACK表示应答，但是此时仅仅只客户端没有报文发送了，服务端的报文数据可能还没有都发送出去，所以在回复FIN报文关闭SOCKET前，需要发送完剩余的报文，接着再发送FIN报文回应给客户端表示你同意现在关闭连接了，所以通常情况下，这里的ACK报文和FIN报文都是分开发送的。可以看到服务端两次挥手的ack的序列是一样的。

客户端为什么有一个TIME-WAIT状态

在服务端连接关闭后
- 不能确定所有连接关闭前的报文都被客户端接受到了(报文的接受是没有先后顺序的)，所以需要等待一段时间。
- 客户端发送的第四次挥手的报文不一定会被服务端收到，就是说服务端处于LAST_ACK 状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，TIME_WAIT 状态的作用就可以用来重发可能丢失的第四次挥手报文。