《Unity3D高级编程之进阶主程》第六章，网络层(一) - TCP还是UDP

TCP和UDP的简介

===

我们日常使用的网络协议通常只有TCP和UDP两种，但事实上还有其他类型的协议，它们使用的范围比较特殊，TCP和UDP是比较通用网络协议使用范围比较广，下面我们来着重介绍TCP和UDP。

TCP（Transmission Control Protocol，传输控制协议）是面向连接的协议，也就是说在收发数据前，必须和对方建立可靠的连接。

一个TCP连接必须要经过三次“对话”才能建立起来，这里我们描述下这三次对话的形象过程：

    主机A向主机B发出连接请求数据包：“我想给你发数据，可以吗？”，这是第一次对话；

    主机B向主机A发送同意连接并要求同步的数据包（同步就是两台主机一个在发送，一个在接收的协调工作）：“可以，你什么时候发？”，这是第二次对话；

    主机A再发出一个数据包确认主机B的要求同步：“我现在就发，你接着吧！”，这是第三次对话。

三次“对话”的目的是使数据包的发送和接收同步，经过三次“对话”之后，主机A才向主机B正式发送数据。

TCP建立连接要进行3次握手,而断开连接却要进行4次，我们来看看它是怎样的一个过程：

    1，当主机A完成数据传输后,将控制位FIN置1，提出停止TCP连接的请求

    2，主机B收到FIN位置上的1信息后对其作出响应，确认这一方向上的TCP连接将关闭，将ACK置1

    3，B主机再提出反方向的关闭请求，并将控制位FIN置1，发送给A主机，并关闭连接

    4，主机A对主机B的请求进行确认，将ACK置1，并关闭连接，至此双方向的关闭结束.

由TCP的三次握手和四次断开可以看出，TCP使用面向连接的通信方式，大大提高了数据通信的可靠性，使发送数据端和接收端在数据正式传输前就有了交互，为数据正式传输打下了可靠的基础。

名词解释： ACK TCP报头的控制位之一,对数据进行确认.确认由目的端发出,用它来告诉发送端这个序列号之前的数据段都收到了。比如,确认号为X,则表示前X-1个数据段都收到了,只有当ACK=1时,确认号才有效,当ACK=0时,确认号无效,这时会要求重传数据,保证数据的完整性.

    SYN  同步序列号,TCP建立连接时将这个位置1
    
    FIN  发送端完成发送任务位,当TCP完成数据传输需要断开时,提出断开连接的一方将这位置1

我们来看看TCP的包头结构：

    源端口(source port) 16位

    目标端口(target port) 16位

    序列号(SYN) 32位

    回应序号(ACK) 32位

    TCP头长度(head size) 4位

    reserved 6位

    控制代码 6位

    窗口大小(size) 16位

    偏移量 16位

    校验和 16位

    选项  32位(可选)

这样我们把它们需要的空间位数都加起来得出了TCP包头的最小长度总共为：192-32位，最后32位的选项位可没有，所以最小长度为 160/8=20 字节。

上面描述的只是包头，也就是所有TCP数据包收到时的头部数据格式，头部数据后面跟着的才是真正的数据，后面具体跟着多少空间大小的数据由窗口大小(size)位置上的数据决定，也就是单个数据包最大能承受2^16-1=65535字节的容量。

这里有个有趣的概念，即TCP通过滑动窗口的概念来进行流量控制。由于在发送端发送数据的速度很快而接收端接收速度却很慢的时就很难保证数据不丢失，所以需要进行流量控制， 协调好通信双方的工作节奏。所谓滑动窗口概念，可以理解成接收端所能提供的缓冲区大小是有限的且是变化的。TCP利用一个滑动的窗口值来告诉发送端对它所发送的数据能提供多大的缓 冲区，以此来协调控制两边的传送节奏和速率。由于窗口只有16个比特的大小，所以接收端TCP 能最大提供65535个字节的缓冲。

UDP（User Data Protocol，用户数据报协议）

下面我们来介绍下UDP，它最大的特点可以分6部分：

    （1）UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。

    （2）由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。

    （3）UDP信息包的包头很短，只有8个字节相对于TCP的20个字节包头信息，UDP的包头开销很小。

    （4）吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。

    （5）UDP会尽最大努力去传输和接受数据且没有限制但并不保证可靠的数据交付，主机也不需要维持复杂的链接状态表（这里面有许多参数）。

    （6）UDP是面向报文的。发送方的UDP对应用程序传过来的报文，在添加包头后就向下交付给IP层。既不拆分，也不合并，而只是保留这些报文的边界，因此应用程序需要自己限制合适的报文大小，以免报文太大丢失率高。

我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包到达的消息及时反馈回来，那么网络就是通的，并且可以通过返回回来的数据包计算响应时间。

其中UDP的包头结构为：

    源端口 16位

    目的端口 16位

    长度 16位

    校验和 16位

包头总共64位8个字节就足以。与TCP同样包头只是数据的头部，其真正数据是跟随在包头后面，具体长度由长度这个字段来决定，最大为2^16-1=65535字节的容量。

用TCP，还是用UDP？

前面介绍了TCP和UDP，我们来看看TCP与UDP的它们的不同之处：

    1，TCP是基于连接的，UDP则是无连接；
    
    2，对系统资源开销，TCP开销较多，UDP开销少；
    
    3，TCP包头大各类状态多程序结构稍显复杂，UDP包头小没有状态程序结构较简单；

    4，TCP为流模式，UDP为数据报模式，相当于TCP是自来水那样需要管子以便把书举不断流入盆中，而UDP则不需要管子连接两端只要像机关枪一样不停扫射到目的地就可以。

    5，TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证。

从原理上，TCP的优势有，简单直接的长连接，可靠的信息传输，能确保数据到达有确认机制，并且数据到达后是有序的，数据包的大小没有限制，不需要自己切分数据包，TCP的底层程序本身就已经帮助我们做了数据包切分。UDP是基于数据包构建，这意味着在某些方面需要我们完全颠覆在TCP下的观念。

由于UDP只使用一个socket进行通信，不像TCP需要为每一个客户端建立一个socket连接，这虽然是UDP还不错的地方，但是大多数情况下我们需要的仅仅是一些连接的概念罢了，一些基本的数据包先后次序功能，以及传输时的可靠性。可惜的是这些功能UDP都没有办法简单的提供给你，而我们使用TCP却都可以免费得到。这也是人们为什么经常推荐TCP的原因之一，在用TCP的时候你可以不考虑这些问题。

UDP没有提供所有的解决方法，但这也正是UDP有巨大潜力的地方，它的吞吐量可以巨大但需要我们去控制它丢失率和可靠性。在某种意义上来说，TCP对UDP就好比是自动档汽车和手动挡汽车的区别，驾驶者需要掌握的技巧和关注度比自动档要多很多，但在效率上的潜力却是巨大的。

容易造成巨大的延迟问题是TCP的性质决定的，在发生丢包的时候，会产生巨大的延迟，因为TCP首先会去检测哪些包发生了丢失，然后重发所有丢失的包，直到他们都被接收到。虽然UDP也是有延迟的，但是由于它是在UDP的基础之上建立的通信协议，所以可以通过多种方式来减少延迟，不像TCP，所有的东西都要依赖于TCP协议本身而无法被更改。

那么为什么魔兽世界采用TCP呢？首先我们需要解释这个问题。这个问题其实是“为什么魔兽世界有的时候1000毫秒以上的延迟还能够运行？”魔兽世界以及其他的一些游戏是怎么处理延迟问题的呢？方法也很简单，他们能够隐藏掉延迟带来的影响。

我们看一下魔兽世界的战斗就会发现，玩家的攻击指令发送给服务器的操作，一些类似发起攻击动作和释放技能特效就能够在没有收到服务器确认的情况下就直接执行，比如展现冰冻技能的效果就可以在服务器没有返回数据前在客户端就做出来。客户端直接开始进行计算而不等待服务端确认是一种典型的隐藏延迟的技术。这也意味着，我们到底是使用TCP还是UDP取决于我们能否隐藏延迟。

那么到底是用UDP还是TCP呢？提供如下参考：

    如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。

    如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。

    如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，以及少部分MMO类游戏），那么使用UDP吧。

为了保证作者理解的正确性，部分参考来自知乎问答。