UDP与TCP的联系与区别：
首先，这两个都是运输层协议
{
复习一下TCP四层模型：
应用层、Telnet FTP email
运输层、TCP UDP
网络层、ip ICMP igmp
链路层 设备驱动程序以及接口
OSI七层
应用层、表示层、会话层、
传输层、
网络层、
数据链路层、物理层
}
都是建立在ip之上的 TCP叫做流式套接字，UDP是报文套接字
我们来看看为什么要在ip之上，再做这样的一步工作：
ip中包含的信息有：源ip 目的ip 然而一个网络中的进程的自由度是5：源ip 目的ip 源端口 目的端口 协议
也就是说通过ip可以确定到计算机，但是没有办法将消息发送给具体的进程，而这个工作是交给TCP、UDP来完成的。
也就是说。TCP、UDP都对ip来的数据进行的分发，交给上层应用。
但是在这个过程中，TCP做的工作要比UDP多很多。
区别：tcp基于连接、UDP无连接。
这就决定了TCP是P2P的，而UDP是支持一对一，一对多，多对一，多对多的：因为它根本就没有连接（但是还是可以绑定端口），所以一个UDP套接字可以给其他任意套接字发东西。（这里有一个问题叫做 确认UDP套接字。多个套接字绑定一个端口的时候，程序员希望负载均衡，但实际上是达不到的，因为每次都只会命中一个套接字。解决方案是打开***选项）
这里可以展开说连接与可靠是个什么意思：我的理解是，TCP通过一系列机制（确认号，重传等），尽管底层是不可靠的，但是不可靠发生的时候，TCP总可以纠正错误，保证用户不需要操心数据的到来是乱序的，或者数据丢失了，用户通过TCP建立连接之后，就可以放心的认为数据是对着的。 而TCP实现数据的可靠传输，是通过事先（三次握手）双发约定好的一些数据（序列号，确认号，窗口大小）来完成的，这个东西就叫做连接，所以必然是点对点的，不可能对多，也不可能中通换对象。
但是UDP就不管这么多，UDP完成的是最初的任务：原本的任务就是要解决IP无法将数据递交给用户期望的进程的问题的。所以UDP的结构相对简单，占用的资源少，通过ip+端口号，将数据发过去就好了，也不管数据丢失没有，接收方也不管数据有没有到达，有没有重复。所有这也工作都要交给上层应用完成，也就是所谓的 网络中的某个问题，在各层都可以解决，如果底层不解决就让上层解决。 既然UDP如此不方便，为什么还要用UDP？尤其是我们熟悉的DNS似乎就是用UDP实现的？A:UDP开销小，负载消耗小，在一些对精度要求不大，但是对速度要求大的场合，用UDP是合理的，即使一次失败，重试的损失也不大。就拿DNS来说，它的任务就是通过网址找到IP然后返回，一次不行就再来一次，开销很小，但是要尽量快，要降低服务器负载。 但是DNS服务器之间进行同步的时候用的就是TCP，这种场合要保证数据的正确。
最后总结一下：TCP是有连接的可靠的传输。
UDP是无连接的不可靠的传输。
我们来看看TCP比UDP多做了哪些事情：
1.首先，在发送数据的时候：
TCP在发送大块数据的时候，会对数据进行分段，每个分段可以携带的数据为1个MSS（MSS是TCP双发协定好的报文长度，这个长度既要尽量多的发送用户数据，又要避免IP分片，所以定一个合理的MSS是一件困难的事情），然后TCP将决定一次发送多少段数据过去(这个时候就要考虑对方能处理多少数据——滑动窗口、以及网络的情况允许发送多少数据——拥塞控制，这两点其实就是TCP的流量控制与拥塞控制) TCP在发送大量小的数据的时候，为了充分利用带宽，会启动Nagle算法（可以配置是否启动），对较小的数据进行合并。（但是这样就又会造成粘包问题，处理方法有短连接，应用层分包 等。。。）
UDP发送的时候无论大小，该发就发（所以没有粘包问题，你看多好。。。）然而，如果UDP发的数据太多了，就会在底层发生分片。来算一算UDP发多少数据是合适的：
{
以太网数据帧的长度必须在[46-1500]字节之间，1500叫做MTU，最大传输单元，是有以太网的物理特性决定的。然后，1500不包括链路层的首尾（18字节），多以1500实际上是ip数据报的长度限制，IP首部20字节，留给UDP或者TCP的有1480字节，然后UDP自己的首部用掉8字节，所以一个UDP中的数据应该不超过1472字节。
又因为英特网上执行的MTU标准是576字节，同理，UDP的数据长度要限制在548字节（576-20-8）；
{
以太网协议头，
IP头，
TCP头，
UDP头
}
}
如果UDP数据超过长度会怎么样？A： 首先会造成IP分片，接收方就要重组，使得效率变低，更加容易出现错误，如果数据错误或者丢失了，那么UDP整个数据报就要丢掉。
那么可不可以稍微长一点?(手动狗头)
从IP包的总长度来看，ip包最大长度65536，减去头（去掉头就可以吃了），再减一个UDP头，就有65507个。
所以，不要超过1472（建议548），超过了就不要超65507.
2.然后，接收数据的时候：
TCP会检验自己的ack与对面发来的seq，确认收到的数据是想要的数据（这里边有重复，丢失，乱序等）。如果不是想要的数据 比如我收到了1 2 3，接下来想要4，但是对面给我传了5，那我只好再给对面传一个（seq = x，ack=3）的报文，告诉对方，我这里只确认到3，那对方就再给我传一个4过来（具体实现没有这么简单，上述的实际是一种丢包问题，具体可能要重出3次同样的ack才会触发重传，或者超时重传，或者用sack机制重传。。。）
然后，乱序的包，TCP重新整理好了顺序。
最后，TCP会告诉发送方自己收到了哪些数据。
3.另外，在1中提到过，TCP实现了流量控制，网络拥塞控制。
流量控制还好理解，双方时刻关注对方的吞吐能力就可以了。网络的情况是难以预期的，难以观测的，只能间接的了解网络的情况，TCP是如何做到拥塞控制的，还有TCP为何要控制拥塞，这是TCP应该完成的任务吗？
TCP正是通过一些量，间接的观测出网络的状况，来实现拥塞控制的。至于要不要控制？答案是要，因为TCP的出现会（重传等）造成网络的拥塞，那么TCP必须要负责。试想：如果某一时刻网络出现拥堵，TCP不管不顾，只认为自己的数据没有送达，不断地重传，只会造成网络更加拥堵，恶性循环。
TCP通过：慢启动 拥塞避免 拥塞发生时的策略 快速恢复 这一系列策略，决定当前可以发送的 段的数量，控制拥塞。
一句话：TCP可靠，控流，控制拥塞。
ps：有人说ping是基于UDP的，对吗？
不对。尽管ping的特点和UDP很像：发送的数据少，要求速度等，，，但是ping是基于原始套接字，使用ICMP协议完成的。和数据报套接字，流式套接字完全没有关系，甚至从层次上看，ICMP是IP的子协议，ping的实现在网络层，TCP/UDP在运输层，所以上述说法显然是错误的。