三次握手和四次挥手的过程：
三次握手：
TCP建立连接的过程我们称之为3次握手。
（1）第一次握手
PC1使用一个随机的端口号向PC2的80端口发送连接请求，此过程的典型标志为SYN控制位为1，其他五位为0。
（2）第二次握手
这次握手实际上是分为2个步骤完成的。
首先，PC2收到PC1请求，向PC1回复确认信息。
并且，PC2也向PC1发送建立连接请求。
（3）第三次握手
PC1收到PC2回复，也要向PC1回复一个确认信息。
四次挥手：
TCP断开连接得过程分为4步，我们称之为四次挥手。
（1）服务器向客户端发送FIN,ACK位置1得TCP报文段。
（2）客户端向服务器返回ACK位置1得TCP报文段。
（3）客户端向服务器发送FIN,ACK位置1得TCP报文段。
（4）服务器向客户端返回ACK位置1得TCP报文段。
在TCP断开连接的过程中，有一个半关闭得概念。TCP一端可以中止发送数据，但是仍然可以接收数据，称之为半关闭：
（1）客户端发送FIN，半关闭了这个链接。服务器发送ACK接受半关闭。
（2）服务器继续发送数据，而客户端只发送ACK确认，不发送任何数据。
（3）当服务器所有数据传输完毕，就发送FIN报文段，客户再发送ACK报文段，这样就关闭了TCP连接。
三次握手和四次挥手的本质是什么？
三次握手的本质是确认通信双方收发数据的能力 。
四次挥手的目的是关闭一个连接 。
为什么TCP连接的时候是3次？2次不可以吗？
因为需要考虑连接时丢包的问题，如果只握手2次，第二次握手时如果服务端发给客户端的确认报文段丢失，此时服务端已经准备好了收发数(可以理解服务端已经连接成功)据，而客户端一直没收到服务端的确认报文，所以客户端就不知道服务端是否已经准备好了(可以理解为客户端未连接成功)，这种情况下客户端不会给服务端发数据，也会忽略服务端发过来的数据。
如果是三次握手，即便发生丢包也不会有问题，比如如果第三次握手客户端发的确认ack报文丢失，服务端在一段时间内没有收到确认ack报文的话就会重新进行第二次握手，也就是服务端会重发SYN报文段，客户端收到重发的报文段后会再次给服务端发送确认ack报文。
为什么TCP连接的时候是3次，关闭的时候却是4次？
因为只有在客户端和服务端都没有数据要发送的时候才能断开TCP。而客户端发出FIN报文时只能保证客户端没有数据发了，服务端还有没有数据发客户端是不知道的。而服务端收到客户端的FIN报文后只能先回复客户端一个确认报文来告诉客户端我服务端已经收到你的FIN报文了，但我服务端还有一些数据没发完，等这些数据发完了服务端才能给客户端发FIN报文(所以不能一次性将确认报文和FIN报文发给客户端，就是这里多出来了一次)。
为什么客户端发出第四次挥手的确认报文后要等2MSL的时间才能释放TCP连接？即为什么客户端在TIME-WAIT阶段要等2MSL？
MSL 指的是 Maximum Segment Lifetime：一段 TCP 报文在传输过程中的最大生命周期。
2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。
这里同样是要考虑丢包的问题，如果第四次挥手的报文丢失，服务端没收到确认ack报文就会重发第三次挥手的报文，这样报文一去一回最长时间就是2MSL，所以需要等这么长时间来确认服务端确实已经收到了。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP设有一个保活计时器，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
总结
A跟B打电话
A：你好，是B吗？ 1次握手
B：您好，我是B，请问您是？ 二次握手
A：我是A，我有个事要跟你说 三次握手
A： xxxx 内容
浏览器访问的过程
1、域名解析成IP地址 如果缓存里没有就要请求DNS服务器；
2、与目标服务器进行TCP连接（三次握手）
3、发送与接受数据（浏览器与服务器通过协议{http、FTP等}）访问过程
4、浏览器与服务器端口TCP连接（四次挥手）
TCP/UDP比较
两者都工作在主机到主机层（传输层）
TCP：传输控制协议，提供可靠的服务，属于面向连接的网络协议
使用TCP应用：Web浏览器；电子邮件；文件传输程序
UDP：用户报文协议，提供尽力而为的服务，属于无连接的网络协议
使用UDP应用：域名系统（DNS）；视频流