TCP和UDP的区别

        首先TCP（传输控制协议）、UDP（用户数据报协议）是目前互联网体系主流的传输层协议，负责定义两台主机之间的数据传输规则，提供传输服务。

TCP协议：

        TCP协议是面向连接的可靠的传输协议，它在数据传输前必须确保先建立点对点之间的连接（客户端-服务器），建立连接后将应用层传下来的报文以字节流的形式封装成一个一个的TCP报文段（报文段内容包括TCP首部和TCP数据部分），以报文段的形式发送给另一端。

        建立连接的过程比较复杂，必须经历“三次握手”才能成功建立。第一次握手：客户端向服务端发送一个表示请求连接同步数据包；第二次握手：服务器根据数据包中TCP首部一些字段标志能知道这是一个请求建立连接的数据包，若服务器同意连接，则向对方也发送一个数据包作为响应，而响应数据包里TCP首部的一些字段值能够表示我同意连接，并且告诉对方应该从哪个字节开始向我发送数据；第三次握手：客户端收到服务器响应的数据包，根据TCP首部内容知道服务器同意建立连接，于是客户端再发送一个数据包，数据包TCP首部中控制位字段的值表示我get到了你的同意，我们成功建立了连接。于是一个TCP传输开始了。

        这个过程用一个情景来描述就是这样的：我给小明扔了一个篮球并告诉他：“我们一起打篮球啊，好不好”，小明拿到篮球传给我说：“好啊，我愿意跟你玩”，我再次告诉小明：“好的，我知道了，我们开始玩耍吧！”于是我们开始了愉快的打篮球！

        好像看似这个过程中，不就我向小明发出邀请，小明告诉我他来不就行了吗，我为什么还要再次告诉他，好的我知道你能来了，那就一起玩吧。没错，客户端向服务器发出建立连接的请求，服务器向客户端确认这个请求，足以证明客户端与服务器之间的网络是畅通的。但是很多时候由于网络原因，客户端向服务器发出的第一个连接请求服务器没收到，就不会响应回去；一段时间后客户端见没有反馈，于是再次向服务器发送连接请求，这次网络好，第二次的请求连接服务器很快收到了，于是发送数据包回去表示我同意你的连接请求，于是双方开始发送数据。但这时第一次由于网络原因没收到的连接请求也到达了服务器，服务器以为是再次连接请求，于是发送确认包回去，并等待对方发送数据，但是对于客户端这边已经建立好了连接，就不会去回复服务器，这时服务器会一直等待，造成资源浪费。

        所以，第三次握手的目的就是，告诉服务器你的确认数据包我收到了，我开始发送数据了。如果没有第三次回应，服务器不知道客户端是否收到了自己的回应，就会一直等。

        那么在传输过程中，传输字节数据的正确有序以及效率是如何保证的呢？那就是要靠上面所说过的所传输数据的TCP首部了，TCP首部包含了固定20个字节长度的固定首部和可变长度的其他选项，而20个字节的固定首部里包含了源端口、目的端口、序号、确认号、数据偏移、保留位、控制位、窗口、检验和以及紧急指针。其中源端口和目的端口即发送端和接收端端口，传输的一个字节都有自己的序号，数据偏移为当前报文段数据部分距离报文起始位置的字节长度，控制位即通过一系列的0,1值来表示当前报文段的各种状态以及想要向对方传达的信息，比如紧急URG=1这是紧急报文段，不用排队优先发送，再比如FIN=1表示此报文段的发送端的数据已发送完毕，并要求释放运输连接等等。TCP首部中的这些字段值记录当前TCP传输过程的连接状态以及传输状态，便于TCP随时调整字节数据的传输策略，也是维持TCP是可靠传输的信息支撑。

        释放连接时也要经历“四次挥手”，也就是为了在确保双方数据传输完成的情况下正常断开连接，这里不作赘述。

        总结TCP协议的特点：可靠、面向连接、仅支持点对点传输、面向字节流、支持拥塞控制和流量控制。

        使用场景：文件的上传与下载，邮件的发送，远程登录连接等对于数据完整性准确性要求高的传输场景。

UDP协议：

        相比于TCP协议复杂的传输机制，UDP协议就显得简单多了，UDP协议即用户数据包协议，没有复杂的控制协议，无连接，不保证可靠，面向报文传输。

        由于UDP是一个无连接的协议，所以一个主机发送数据时，直接扔到网络上，谁都可以已抓取，所以UDP协议支持一对一、一对多、多对多的传输，UDP传输数据的速度仅仅取决于他发送端发送数据的速度，所以传输速度较快。但同时因为没有拥塞避免流量控制的机制，而且它的首部很简单只有8个字节，记录了源端口、目的端口和数据长度这些内容，所以即使网络拥塞造成丢包，它也无法感知，所以说基于UDP协议的传输数据到达接收端后无法保证数据的完整性。

        基于UDP协议的特点，有以下应用场景：即时聊天（数据量小，一般不会丢失，需及时到达，避免每次都要连接耗时）、广播通信（一端发送，多端接收）、视频聊天（即时通信，有时丢包造成掉帧也可接受）等即时数据量小的传输场景。