TCP为什么需要握手三次、握手四次？TCP是通过程序实现的、可靠的、面向连接的协议。 步骤很严密，每次建立连接时都会进行“三次握手”步骤。
连接的目的是可靠的数据传输。 因此，必须确保客户端和服务端能够正常发送和接收数据。
如果一方不能正常收发数据，则整个数据传输不可靠，也不会成功。
所以为什么需要三次而不是两次呢？
三次握手流程：
1 .最初客户端和服务端关闭，服务端始终处于监听状态，监听是否有建立连接的请求。
2 .如果客户端需要建立连接，则发送连接确认消息。 此消息为同步消息SYN=1，同时生产随机序列号3358www.Sina.com/。 这是seq=x。
在第一次握手时，客户端向服务端发送同步消息，客户端知道自己有发送数据的能力，不知道服务端是否有发送和接收数据的能力。 3 .当服务端接收到连接请求消息时，将发送同步消息确认消息。 此消息为第一次握手，且SYN=1seq=y，其中x是从客户端发送的同步消息序列号
在第二次握手时，服务端会收到同步消息并响应同步消息的确认。 此时，服务端知道自己有接收和发送数据的能力，而服务端有发送数据的能力，但不知道客户端是否有接收数据的能力。 4 .当客户端从服务端收到ACK消息时，将返回一条ACK确认消息，以确认收到确认消息。 此消息来自ACK=1（大写ACK表示报文为确认报文）,同时服务端也会生成一个随机序列号
第三次握手是因为客户端收到同步确认消息后，知道服务端具备发送、接收能力和自己具备的功能，但服务端只知道客户端具备发送能力，也不知道客户端具备接收能力。 三次握手流程结束后，客户端的服务端知道自己和对方有发送和接收数据的能力，连接完成后，可以进行数据传输。
因此，第二次握手不能满足上述条件。 因为服务端不知道客户端有接收数据的能力，所以需要第三次握手，客户端会让服务端知道自己有接收能力。
4挥手3次握手是为了建立可靠的数据传输通道，4挥手是为了数据传输结束后再关闭连接，直到双方达到关闭连接的条件才能断开连接。
4次挥手的过程：
客户端发出ack设置为x+1已断开连接的消息，携带随机生成的这是第二次握手发送到服务端，自己处于ACK = 1，seq = x + 1, ack = y + 1（y是确认报文序列号），这是第三次握手状态、状态
第一次挥手的客户端向服务端发起关闭连接的请求。 服务端收到FIN=1消息后，返回seq=u的确认消息，随机返回FIN-WAIT和http://www.Sina.com
第二次挥手：由于服务端收到关闭请求时，此时可能还没有发送数据，因此服务端首先知道客户端要关闭连接，但需要等待数据传输完成服务器端数据发送后，将这是第一次挥手消息发送到客户端，通知客户端。 服务端准备关闭连接。 此消息FIN，ACK = 1。
第三次挥手，数据传输玩耍后，服务端会主动发送FIN消息，通知客户端，识别数据发送给你，服务端准备关闭连接。 客户端收到seq=v确认消息时，发送ack=u+1(u为客户端发送报文的序列号)，这是第二次挥手的确认消息。 http://www.Sina.com/(w是服务器发送的消息的序列号。 进入http://www.Sina.com
第四次挥手，客户端从服务端收到FIN消息后，回复ACK消息，告知服务端自己知道，等待一会儿后关闭连接。
疑问：1.为什么握手三次，挥手要四次？
尾音我说的时候没有数据传输。 服务端的SYN和ACK消息可以一起发送，但挥手时有数据传输。 无法同时发送ACK和FIN消息。 因为需要分为两个阶段，所以增加了一个步骤的流程。
2 .为什么客户端在第四次挥手后也要等2MSL？
等待2MSL是为了确保服务器端接收到ACK信息。 由于网络复杂，ACK消息可能会丢失。 如果服务器没有接收到ACK信息，则重新发送FIN信息。 只有在客户端等待2MSL但未收到重发的FIN消息时，才表示服务端成功收到了ACK消息，此时客户端可以关闭。
综合TCP协议是一种面向连接的可信传输层协议，其拥塞控制、失败重传等机制对互联网数据传输至关重要。 目前，在互联网行业，基于TCP实现的程序数不胜数。 程序员很少有机会主动编写TCP相关代码，但了解其实现原理很有帮助。