可靠的、面向链接的协议(eg:打电话)、传输效率低全双工通讯(发送缓存&接收缓存)、面向字节流。算法
使用TCP的应用:Web浏览器;电子邮件、文件传输程序。浏览器
不可靠的、无链接的服务,传输效率高(发送前时延小),一对1、一对多、多对1、多对多、面向报文,尽最大努力服务,无拥塞控制。缓存
使用UDP的应用:域名系统 (DNS);视频流;IP语音(VoIP)。网络
UDP以其简单、传输快的优点,在愈来愈多场景下取代了TCP,如实时游戏。计算机网络
(1)网速的提高给UDP的稳定性提供可靠网络保障,丢包率很低,若是使用应用层重传,可以确保传输的可靠性。视频
(2)TCP为了实现网络通讯的可靠性,使用了复杂的拥塞控制算法,创建了繁琐的握手过程,因为TCP内置的系统协议栈中,极难对其进行改进。server
采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会愈来愈大,基于UDP对实时性要求较为严格的状况下,采用自定义重传机制,可以把丢包产生的延迟降到最低,尽可能减小网络问题对游戏性形成影响。blog
如上图所示,若是仅仅是2次握手的话,可能出现的问题以下:游戏
Host A发送的数据包因为网络的缘由,出现了滞留,即延时到达了HostB。此时,B觉得HostA发来了请求,因而就向HostA发送确认报文,以创建链接。而HostA收到报文后,因为其没有向HostB发起创建链接的请求,所以不会理睬HostB的确认,也不会向HostB发送数据。而此时的B认为已经创建起链接了,就等待HostA发送的数据,致使HostB的资源白白浪费!资源
另外一种表述:
这个例子很清晰的阐释了“三次握手”对于创建可靠链接的意义。
TCP三次握手之打电话的例子:
A : 你好我是A,你听获得我在说话吗
B : 听到了,我是B,你听到我在说话吗
A : 嗯,听到了
创建链接,开始聊天!
为何TCP协议终止连接要四次?
一、当主机A确认发送完数据且知道B已经接受完了,想要关闭发送数据口(固然确认信号仍是能够发),就会发FIN给主机B。
二、主机B收到A发送的FIN,表示收到了,就会发送ACK回复。
三、但这是B可能还在发送数据,没有想要关闭数据口的意思,因此FIN与ACK不是同时发送的,而是等到B数据发送完了,才会发送FIN给主机A。
四、A收到B发来的FIN,知道B的数据也发送完了,回复ACK, A等待2MSL之后,没有收到B传来的任何消息,知道B已经收到本身的ACK了,A就关闭连接,B也关闭连接了。
通俗例子:
A:“喂,我不说了。”A->FIN_WAIT1
B:“我知道了。等下,上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了,说完了,我也不说了。”B->LAST_ACK
A:”我知道了。”A->TIME_WAIT | B->CLOSED
A等待2MSL,保证B收到了消息,不然重说一次”我知道了”,A->CLOSED