【计算机网络—TCP相关】| 三次握手+四次挥手（面试不慌）
三次握手+四次挥手
- 写在前面
- 1. 三次握手
- 1.1 作用： 为了在不可靠的信道上建立起可靠的连接；
- 1.2 建立过程
- 1.3 面试提问
- 2. 四次挥手
- 2.1 作用：为了在不可靠的网络信道中进行可靠的连接断开确认
- 2.2 断开过程
- 2.3 面试提问
写在前面
三次握手建立连接；四次挥手断开连接；
TCP协议里的标识：
SYN ：Synchronization（同步）
ACK：Acknowledgment（确认）
FIN：Finish（结束）
1. 三次握手
1.1 作用： 为了在不可靠的信道上建立起可靠的连接；
1.2 建立过程
当客户端向服务端发起连接请求时候：
- 先发一包连接请求数据（
SYN包）来询问能否与服务端建立连接，这包数据我们叫做SYN包：（想和你同步）； - 如果对端同意连接就会回复一包
SYN+ACK包（确认同步）； - 客户端收到之后回复一包
ACK包（确认）。
注：自己的序号用对方的确认号； 自己的确认号 用对方的序号+1
1.3 面试提问
问题1：为什么是三次握手而不是两次握手or四次握手？
答：
目的：握手是为了确认双方的接收与发送能力是否正常
-
第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的；
-
第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常；
-
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常；
- 如果是两次握手，服务端并不能确认客户端的接收能力是否正常；而且为了防止已经失效的请求报文，突然又传到服务器引起错误
- 三次握手是两端建立连接的所需要的最小收发包的次数，所以四次握手就没有必要了
问题2：两次握手可能产生的问题？
答：假设采取两次握手，客户端向服务端发起一个报文SYN1，因为某些未知错误，并未到达服务器，在中间某个网络节点产生了滞留；而为了建立连接客户端会重新发送一个SYN包，我们称之为SYN2，这次正常送达服务端，并且回复SYN+ACK后建立连接；这时阻塞的网络节点突然恢复，把SYN1重新发给了服务端，服务端就会误认为是客户端发起了新的连接；
服务端认为是两个连接，客户端认为是一个连接，造成了状态不一致的问题；
2. 四次挥手
握手之后就建立连接——连接建立好以后，客户端就可以发送http请求——然后服务端响应内容；
因为TCP协议是全双工的，所以两端都可以发送关闭请求；
2.1 作用：为了在不可靠的网络信道中进行可靠的连接断开确认
2.2 断开过程
- 第一次挥手：客户端发送
FIN+ACK（确认结束） - 第二次挥手：服务端回复
ACK（确认）因为服务端可能还存在未发送完毕的数据所以还需要等待数据全部发送完以后回复确认结束，也就是第三次挥手； - 第三次挥手：服务端回复
FIN+ACK（确认结束）； - 第四次挥手：客户端回复
ACK（确认）；进入超时等待状态
2.3 面试提问
问题1：为什么客户端在回复ACK包之后还需要等待超时时间？
答：
目的：为了在不可靠的网络信道中进行可靠的连接断开确认；
原因：因为如果客户端在发送完最后一包ACK包就释放了连接的话，一旦ACK包在网络中丢失，服务端就会一直停留在最后确认状态；若发送完最后一包ACK包，再等待一段时间，此时如果服务端没有收到ACK包，就会重发FIN包；客户端会响应这个FIN包，且重发ACK包，并刷新超时时间