Foreword
Computer-transport layer in the hierarchy, is mainly responsible for the data transmission between computers, TCP and UDP transport layer protocol belongs. In the actual development process, it is necessary to select an appropriate transmission protocol according to the actual needs.
Here we briefly summarize under TCP, UDP characteristics and differences between the actual development and how to choose.
The definition of TCP and UDP
TCP is a connection-oriented, reliable stream protocol. Up to ensure the communication between the communication ends hosts, packet loss can be handled, and other abnormal disorder, bandwidth can be effectively alleviate network congestion.
UDP is a connectionless unreliable datagram protocol. It does not handle packet loss, disorder and other abnormalities, generally to the upper application layer.
UDP characteristics and usage scenarios
UDP does not provide a complex control mechanism for providing a communication service using IP connectionless data may be transmitted at any time, the process is simple and efficient, is often used in the following scenarios:
① smaller total packet communication (DNS, SNMP)
② video, audio and other multimedia communications (instant messaging)
③ broadcast communication
TCP characteristics and usage scenarios
With respect to the UDP, TCP implements various control data during transmission, retransmission control can be performed when packet loss may also be the order of the sub mess sequence control.
In the high reliability requirements, you can use TCP, UDP does not consider that is the time, you can select TCP.
to sum up
Here a brief summary follows:
1.TCP is connection-oriented, UDP is connectionless; it needs to establish a TCP connection and disconnection, UDP does not.
2.TCP is a stream protocol, UDP is a datagram protocol; TCP data so there is no size limitation, UDP datagrams have a size limit (UDP protocol itself limits the data link layer of the MTU, cache size).
3.TCP reliable protocol, UDP is an unreliable protocol; it handles TCP retransmission packet loss and disorder and the like, UDP is not processed.
Why TCP three-way handshake, four wave?
Foreword
TCP is transport layer protocol is connection-oriented, reliable stream protocol. Face connection this feature, TCP will have to establish a connection and disconnection procedures. We were established understand some questions connected and disconnected processes and among.
TCP connection is established and disconnected processes
First, we look at the flow chart of this classic:
Handshake process can be simplified into the following four interactive:
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 建立连接和断开连接，这类的优秀博客太多了，我们这篇就单纯作为话题引出，加上自己的一些理解，希望给有需要的朋友带来不一样的阅读体验。