TCP 建立连接的三次握手 断开连接时的四次挥手

三次握手

1.客户端发送请求同步，将SYN标识位 设置为1，此时不能携带任何数据，将seqence number设置为x（x为一随机值）然后客户端进入SYN-SEND状态

2.服务器接收到SYN报文段，将SYN标识位 设置为1，将ACK标识位 设置为1 ，将sequence number设置为y，将acknowledge number设置为x+1，服务器进入SYN-RECEIVED (半连接)状态

3.客户段再一次确认，将ACK标识位 设置为1 ，将sequence number设置为x+1, 将acknowledge number设置为 y+1，最后客户端和服务器都进入Establish Listen状态

为何需要第三次握手，再一次确认连接？

这主要是为了已经失效的连接请求报文突然又传回服务端，而产生错位的场景。

假设两次握手，客户端客户端发送的第一个报文请求由于网络延迟等原因，造成服务端未接收到。继而客户端又发送了第二个报文请求，此时服务端接收到客户端的第二个报文请求，做出相关请求确认建立了连接。数据传输结束后，客户端断开了与服务端的连接。然而此时意外出现了，刚才客户端发送的第一个报文请求居然在此时奇迹般的发送给了服务端，而服务端以为客户端又需要建立请求传输数据就确认了连接，之后服务端就傻傻的等待客户端与其传输数据，然而此时客户端早以去别处玩耍，剩下服务端一人在那傻傻的等待，浪费了大量时间和资源。

而三次握手下，就能有效避免这种场景。同样的情况当客户端发送的第一个报文请求居然在此时奇迹般的发送给了服务端，此时服务端发送确认报文请求，进入半连接状态，但是之后服务端却无法收到客户端的再一次确认请求，自然无法建立连接，因而不会在那傻等，可以干其他事情去了。

四次挥手

1.客户端发送结束请求报文给服务端（没有数据），将FIN标识位 设置为1，将sequence number设置为x，客户端进入FIN_WAIT_1状态

2.服务端接收到来自客户端的请求报文，发送确认报文给客户端，将ACK标识位 设置为1，将sequence number设置为y，将acknowledge number设置为x+1,服务端进入CLOSED_WAIT状态

3.服务端准备好后，发送结束报文请求给客户端，将FIN标识位 设置为1，将ACK标识位设置为1，将sequence number设置为z，将acknowledge number设置为y+1，服务端进入LAST_ACK状态

4.客户端收到服务端的确认报文后，进入TIME-WAIT状态，然后再一次发送确认报文给服务端，将ACK标识位 设置为1，将sequence number设置为y+1，将acknowledge number设置为z+1，最后客户端和服务端都进入CLOSED状态。

另外补充一点TCP与UDP的对比：

UDP:

面向无连接的，无需三次握手，可以直接发送数据包

只是数据报文的搬运工，不会对报文进行任何拆分和拼接操作

支持一对一，一对多，多对多传输方式

网络环境的好坏对UDP没有影响，因为UDP没有拥塞控制，不会对传输速率进行调整，一直会以恒定的速度发送数据。这样的弊端就是在网络不好的情况下会出现丢包的情况。而这也是它的优点，适合对于某些实时性要求高，而数据允许不太完整的场景，例如电话会议。

TCP

面向连接的，需要三次握手，建立连接才能发送数据

仅仅支持一对一的数据传输

一个TCP连接上是可以发送多个http请求的

当网络出现拥塞时，TCP能够减小网络注入数据的速率和数量，缓解网络拥塞。