TCP/IP三次握手和四次挥手总结

TCP/IP三次握手和四次挥手总结

这篇文章中的tcp/ip写的还是很简单的，真的用到面试中，还是复习这个好：https://blog.csdn.net/yyyxxxs/article/details/89605669

一.TCP报文格式

32位序号seq,32位确认序号ack,是对上一条发送的信息的确认；ACK是确认标志位，1/0；SYN位表示发起一个新的连接；FIN表示是否结束一个连接。

二.三次握手

具体的三次握手回答：
TCP/IP 协议是传输层的一个面向连接的安全可靠的一个传输协议，三次握手的机制是为了保证能建立一个安全可靠的连接。

1. 那么第一次握手是由客户端发起，客户端会向服务端发送一个报文，在报文里面：SYN标志位置为1，表示发起新的连接。
2. 当服务端收到这个报文之后就知道客户端要和我建立一个新的连接，于是服务端就向客户端发送一个确认消息包，在这个消息包里面：ack标志位置为1，表示确认客户端发起的第一次连接请求。
3. 以上两次握手之后，对于客户端而言：已经明确了我既能给服务端成功发消息，也能成功收到服务端的响应。但是对于服务端而言：两次握手是不够的，因为到目前为止，服务端只知道一件事，客户端发给我的消息我能收到，但是我响应给客户端的消息，客户端能不能收到我是不知道的。所以，还需要进行第三次握手，第三次握手就是当客户端收到服务端发送的确认响应报文之后，还要继续去给服务端进行回应，也是一个ack标志位置1的确认消息。

通过以上三次连接，不管是客户端还是服务端，都知道我既能给对方发送消息，也能收到对方的响应。那么，这个连接就被安全的建了。

为什么第三次握手，两次握手不行的原因：第三次握手保证了客户端和服务端既能给对方发送消息，又能响应对方。

三. 四次挥手

具体回答:

四次挥手机制也是由客户端去发起。

1. 客户端会发送一个报文，在报文里面FIN位标志位置一，
2. 当服务端收到这个报文之后，我就知道了客户端想要和我断开连接，但是此时服务端不一定能做好准备，因为当客户端发起断开连接的这个消息的时候，对于服务端而言，他和还有可能有未发送完的消息，他还要继续发送，所以呢，此时对于服务端而言，我只能进行一个消息确认，就是我先告诉服务端，我知道你要给我断开连接了，但是我这里边还可能没有做好准备，你需要等我一下，等会儿我会告诉你。
3. 于是呢，发完这个消息确认包之后，可能稍过片刻它就会继续发送一个断开连接的一个报文啊，也是一个FIN位置1的报文也是由服务端发给客户端的啊，这个报文表示服务端已经做好了断开连接的准备。
4. 那么当这个报文发给客户端的时候，客户端同样要给服务端继续发送一个消息确认的报文一共有四次。

那么，通过这四次的相互沟通和连接，我就知道了，不管是服务端还是客户端都已经做好了断开连接的准备，于是连接就可以被断开。

四. 生活化理解：

三次握手

客户端：你在线吗？
服务器：我在，你在线吗？

为什么不是两次握手？
因为在这两次握手之后，对于客户端来说，发送和接收都没有问题，但是对于服务器，只知道接受没有问题，发送的消息客户端有没有收到，服务器是不知道的，因此需要第三次握手，也就是

客户端：我也在

此时三次握手之后，服务器知道了自己发送是没问题，因此连接是可靠的。

为什么不是四次握手？
这是两种情况，第一种是把服务器的确认ACK和连接SYN分两次发送，这种在理论上是可行的，就好比

服务器：我在
服务器：你在线吗？

但是一次性能干完的事情，非分两次，太浪费资源了。
第二种情况就是客户端再次发送确认消息，也是同理，三次握手就已经保证了双方的连接是可靠的，客户端再确认也是浪费资源

四次挥手：
客户端：我数据传完了，我要下线了
服务器：知道了，我还有点数据，你等下
一段时间后
服务器：我数据发完了，你可以下线了
客户端：好的

为啥不是三次挥手？
因为客户端要关闭连接的时候，无法保证服务器已经将数据发送完成，所以此时服务器只能告诉客户端我收到你的关闭请求，知道你的数据发送完成。在服务器把数据发送完成之后，告知客户端，数据发送完了，可以关闭连接。此时，客户端也要应答，同意关闭连接。客户端的确认是为了让服务端知道服务端的fin确实到达了，否则服务端就会一直怀疑自己的fin丢了。