TCP和UDP区别以及TCP的三次握手和四次挥手

TCP和UDP的概念

TCP：传输控制协议（TCP，Transmission Control
Protocol）是一种面向连接的、可靠的、基于字节流的传输层通信协议

UDP： Internet 协议集支持一个无连接的传输协议，该协议称为用户数据报协议（UDP，User Datagram
Protocol）。UDP 为应用程序提供了一种无需建立连接就可以发送封装的 IP 数据包的方法

TCP和UDP的区别

一、是否基于连接

TCP是面向连接的协议，而UDP是无连接的协议。即TCP面向连接;
UDP是无连接的，即发送数据之前不需要建立连接。

二、可靠性和有序性区别

TCP提供交付保证（Tcp通过校验和，重传控制，序号标识，滑动窗口、确认应答实现可靠传输），无差错，不丢失，不重复，且按序到达，也保证了消息的有序性。该消息将以从服务器端发出的同样的顺序发送到客户端，尽管这些消息到网络的另一端时可能是无序的。TCP协议将会为你排好序。
UDP不提供任何有序性或序列性的保证。UDP尽最大努力交付，数据包将以任何可能的顺序到达。
TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

三、实时性

UDP具有较好的实时性，工作效率比TCP高，适用于对高速传输和实时性有较高的通信或广播通信。

四、协议首部大小

TCP首部开销20字节;
UDP的首部开销小，只有8个字节。

五、运行速度

TCP速度比较慢，而UDP速度比较快，因为TCP必须创建连接，以保证消息的可靠交付和有序性，毕竟TCP协议比UDP复杂。

六、拥塞机制

UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）

七、流模式（TCP）与数据报模式(UDP);

TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;
UDP是面向报文的。

八、资源占用

TCP对系统资源要求较多，UDP对系统资源要求较少。
TCP被认为是重量级的协议，而与之相比，UDP协议则是一个轻量级的协议。因为UDP传输的信息中不承担任何间接创造连接，保证交货或秩序的的信息。这也反映在用于承载元数据的头的大小。

九、应用

每一条TCP连接只能是点到点的;
UDP支持一对一，一对多，多对一和多对多的交互通信。基于UDP不需要建立连接，所以且适合多播的环境，UDP是大量使用在游戏和娱乐场所。

TCP和UDP的优缺点

UDP

UDP 优点：简单、传输快。

网速的提升给UDP的稳定性提供可靠网络保障，丢包率很低，如果使用应用层重传，能够确保传输的可靠性。
TCP为了实现网络通信的可靠性，使用了复杂的拥塞控制算法，建立了繁琐的握手过程，由于TCP内置的系统协议栈中，极难对其进行改进。采用TCP，一旦发生丢包，TCP会将后续的包缓存起来，等前面的包重传并接收到后再继续发送，延时会越来越大，基于UDP对实时性要求较为严格的情况下，采用自定义重传机制，能够把丢包产生的延迟降到最低，尽量减少网络问题对游戏性造成影响。

UDP缺点：不可靠，不稳定；

UDP应用场景：
1.面向数据报方式
2.网络数据大多为短消息
3.拥有大量Client
4.对数据安全性无特殊要求
5.网络负担非常重，但对响应速度要求高

TCP

TCP：优点：可靠稳定

TCP的可靠体现在TCP在传输数据之前，会有三次握手来建立连接，而且在数据传递时，有确认. 窗口. 重传. 拥塞控制机制，在数据传完之后，还会断开来连接用来节约系统资源。

缺点：慢，效率低，占用系统资源高，易被攻击

TCP应用场景：
当对网络质量有要求时，比如HTTP，HTTPS，FTP等传输文件的协议；POP，SMTP等邮件传输的协议。

TCP的三次握手和四次挥手

简单来说

三次握手：

主机A向主机B发送了请求连接
主机B收到请求后响应答应建立连接
主机A收到主机B答应连接的回应连接建立

四次挥手：

主机A向主机B发送了断开连接的请求
主机B收到请求后响应同意断开连接请求
主机B向主机A反向再发送断开连接请求
主机A收到请求断开连接

详细来说的话：

三次握手：

建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence
Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认
服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置AcknowledgmentNumber为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，SequenceNumber为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；
客户端收到服务器的SYN+ACK报文段。然后将AcknowledgmentNumber设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

四次挥手

主机1（可以使客户端，也可以是服务器端），设置Sequence Number和Acknowledgment
Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；
主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，AcknowledgmentNumber为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求
主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态；
主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

为什么需要三次握手，两次不行吗？

弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。
第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。

试想如果是用两次握手，则会出现下面这种情况：

如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

三次握手过程中可以携带数据吗？

其实第三次握手的时候，是可以携带数据的。

但是，第一次、第二次握手不可以携带数据

为什么这样呢?大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据。因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。

也就是说，第一次握手不可以放数据，其中一个简单的原因就是会让服务器更加容易受到攻击了。而对于第三次的话，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据也没啥毛病。

挥手为什么需要四次？

因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四次挥手。

TCP的三次握手和四次挥手详解