相同点
UDP协议和TCP协议都是传输层协议。
TCP（Transmission Control Protocol，传输控制协议）提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。
UDP（User Data Protocol，用户数据报协议）是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。
即：TCP面向连接，可靠，基于字节流，而UDP不面向连接，不可靠，基于数据报;
无连接：知道对端的IP和端口号就直接进行传输, 不需要建立连接。
不可靠：没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息。
面向数据报：不能够灵活的控制读写数据的次数和数量，应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并。
TCP三次握手过程
1：主机A通过向主机B 发送一个含有同步序列号标志位的数据段（SYN）给主机B ，向主机B 请求建立连接，通过这个数据段，主机A告诉主机B 两件事：我想要和你通信；你可以用哪个序列号作为起始数据段来回应我。
2：主机B 收到主机A的请求后，用一个带有确认应答(ACK)和同步序列号(SYN)标志位的数据段响应主机A，也告诉主机A两件事：我已经收到你的请求了，你可以传输数据了；你要用哪个序列号作为起始数据段来回应我。
3：主机A收到这个数据段后，再发送一个确认应答，确认已收到主机B 的数据段：“我已收到回复,我现在要开始传输实际数据了”。
这样3次握手就完成了，主机A和主机B 就可以传输数据了。
TCP四次挥手过程
1：当主机A完成数据传输后，将控制位FIN置1，提出停止TCP连接的请求。
2：主机B收到FIN后对其作出响应，确认这一方向上的TCP连接将关闭，将ACK置1。
3：由B 端再提出反方向的关闭请求，将FIN置1。
4：主机A对主机B的请求进行确认，将ACK置1，双方向的关闭结束。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
为什么TCP客户端最后还要发送一次确认呢？
一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。
udp如何实现可靠性传输？
UDP它不属于连接型协议，因而具有资源消耗小，处理速度快的优点，所以通常音频、视频和普通数据在传送时使用UDP较多，因为它们即使偶尔丢失一两个数据包，也不会对接收结果产生太大影响。
传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。
实现确认机制、重传机制、窗口确认机制。
让UDP可靠啊，那么就要向上封装，在应该层实现可靠性。
应用场景选择
- 对实时性要求高和高速传输的场合下使用UDP;在可靠性要求低，追求效率的情况下使用UDP;
- 需要传输大量数据且对可靠性要求高的情况下使用TCP
不管用TCP和UDP，应用只要看需求，对于TCP更加注重的是可靠性，而不是实时性，如果我发送的数据很重要一点也不能出错，有延迟无所谓的话，那就TCP啊。UDP更加注重是速度快，也就是实时性，对于可靠性要求不那么高，所以像斗鱼，熊猫这些在线直播网站应该在UDP基础是封装了其他协议，比如视频实时传输协议。而且UDP的支持多播，那就很符合这些直播网站了，有时候看直播视频卡顿，人飘逸那可能就是丢包了，但是你也只能往下看。
Moba类或者其他多人竞技游戏，你会选择哪种通信协议，为什么？
传输层协议和延迟
不同传输层协议在可靠性、流量控制等方面都有差别，而这些技术细节会对延迟造成影响。tcp追求的是完全可靠性和顺序性，丢包后会持续重传直至该包被确认，否则后续包也不会被上层接收，且重传采用指数避让策略，决定重传时间间隔的RTO(retransmission timeout)不可控制，linux内核实现中最低值为200ms，这样的机制会导致丢包率短暂升高的情况下应用层消息响应延迟急剧提高，并不适合实时性高、网络环境复杂的游戏。
加速方案：
基于udp定制传输层协议，引入顺序性和适当程度或者可调节程度的可靠性，修改流控算法。适当放弃重传，如：设置最大重传次数，即使重传失败，也不需要重新建立连接。
总结
在实时性方面，tcp协议的网络抗性欠佳，对moba类或其他实时性要求较高的游戏，我们不建议使用tcp作为协议载体。事实上，王者荣耀，乱斗西游的通信协议也确实是基于udp封装的。
后话
对于开发人员来说，优化协议和同步算法是在已有网络环境下提升用户体验的可用方法，也是较平民化的方法，在网络抖动有限、丢包并不频繁、网络环境不至于太差的情况下，的确能有效提高游戏体验；然而这种方法也存在局限性，在网络环境超出可控范围，如在地铁上、商场里等人潮拥挤、存在网络热点，延迟或丢包率极高的环境中，还是无法解决问题。
参考：
扫一扫
3876
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
