前言
计算机分层中的传输层，主要是负责计算机之间的数据传输，TCP 和 UDP 都属于传输层协议。在实际开发过程中，需要根据实际需求的来选择适当的传输协议。
在这里我们简单总结下 TCP、UDP 的特点和区别以及实际开发中如何选择。
TCP 和 UDP 的定义
TCP 是面向有连接，可靠的流协议。保证两端通讯主机之间的通信可达，可以处理丢包、乱序等异常，可以有效利用带宽、缓解网络拥堵。
UDP 是面向无连接，不可靠的数据报协议。不会处理丢包、乱序等异常，一般交给上层的应用层处理。
UDP 的特点及使用场景
UDP 不提供复杂的控制机制，利用 IP 提供面向无连接的通信服务，随时都可以发送数据，处理简单且高效，经常用于以下场景：
① 包总量较小的通信（DNS、SNMP）
② 视频、音频等多媒体通信（即时通信）
③ 广播通信
TCP 的特点及使用场景
相对于 UDP，TCP 实现了数据传输过程中的各种控制，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。
在对可靠性要求较高的情况下，可以使用 TCP，即不考虑 UDP 的时候，都可以选择 TCP。
总结
这里简单总结下：
1.TCP 是面向连接的，UDP 是面向无连接的；故 TCP 需要建立连接和断开连接，UDP 不需要。
2.TCP 是流协议，UDP 是数据包协议；故 TCP 数据没有大小限制，UDP 数据报有大小限制（UDP 协议本身限制、数据链路层的 MTU、缓存区大小）。
3.TCP 是可靠协议，UDP 是不可靠协议；故 TCP 会处理数据丢包重发以及乱序等情况，UDP 则不会处理。
TCP 为什么要三次握手，四次挥手？
前言
TCP 属于传输层协议，是面向有连接，可靠的流协议。面对有连接这个特性，TCP 就有建立连接和断开连接的过程。我们分别了解建立连接和断开连接的流程以及当中的一些疑问。
TCP 建立连接和断开连接流程
首先我们来看下这张经典的流程图：
握手过程可以简化为下面的四次交互：
1.Client 端首先发送一个 SYN 包，告诉 Server 端我的初始序列号是 X；Client 端进入了 SYN-SENT（同步已发送状态）状态。
2.Server 端收到 SYN 包后回复给 Client 一个 ACK 确认包，告诉 Client 说我收到了；Server 端进入了SYN-RCVD（同步收到）状态。
3.接着 Server 端也需要告诉 Client 端自己的初始序列号，于是 Server 也发送一个 SYN 包告诉 Client 我的初始序列号是Y；
4.Client 端收到后，回复 Server 一个 ACK 确认包说我知道了。之后 Client 和 Server 进入ESTABLISHED（已建立连接）状态。
重点：Server 的 ACK 确认包和接下来的 SYN 包合成一个SYN ACK包一起发送的，没必要分别单独发送，这样子三次握手在进行最少次交互的情况下完成了两端的资源分配和初始化序列号的交换。
四次挥手过程：
1. 客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2. 服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3. 客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4. 服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5. 客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗
∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6. 服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
TCP 的三次握手改成两次握手可以吗？
不可以，一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
TCP 四次挥手能不能变成三次挥手呢？
答案是可能的。
TCP是全双工通信，Client 在自己已经不会在有新的数据要发送给 Server 后，可以发送 FIN 信号告知 Server，这边已经终止 Client 到对端 Server 那边的数据传输。但是，这个时候对端 Server 可以继续往 Client 这边发送数据包。于是，两端数据传输的终止在时序上是独立并且可能会相隔比较长的时间，这个时候就必须最少需要2+2 = 4 次挥手来完全终止这个连接。但是，如果Server在收到Client的FIN包后，在也没数据需要发送给Client了，那么对Client的ACK包和Server自己的FIN包就可以合并成为一个包发送过去，这样四次挥手就可以变成三次了(似乎linux协议栈就是这样实现的)。
总结
对于 TCP 建立连接和断开连接，这类的优秀博客太多了，我们这篇就单纯作为话题引出，加上自己的一些理解，希望给有需要的朋友带来不一样的阅读体验。
