UDP是面向无连接的协议，它只负责将数据传输给客户端，而不会保证数据的完整性。这种特性导致其在Web应用程序方面很是吃亏，所以说Web应用程序使用都为TCP连接，但是在音频传播和实时视频传播方面，UDP确是可以做到比TCP更好的效果，虽然也会发生数据丢失，但是少量数据的丢失对于声音和视频的效果显示没有太大的影响.
一个UDP套接字由一个二元组来进行标识，该二元组包括一个目的IP地址和一个目的端口号.
源端口号用途 当A到B的报文段中，源端口号作为返回地址的一部分，即当B要回发一个报文段给A时，B到A的报文段的目的端口号便从A到B的源端口号中取值.UDP首部包括源端口号、目的端口号、长度、检验和.
长度 指示了在UDP报文段（包括UDP首部和数据）中的字节数.检验和 接收方通过检查检验和来检查该报文段是否出现差错.TCP是面向连接的协议，在两个进程之间要发生数据传输的时候，需要在两个进程之间建立连接，也就是先互相握手，互相发送一些特殊的预备报文段，以建立确保数据传输的参数.
一个TCP套接字由一个四元组来进行标识，该四元组包括源IP地址、源端口号、目的IP地址、目的端口号.
客户进程通过套接字传递数据流，数据一旦通过套接字，它就由运行中的TCP控制了，TCP将这些数据引导到该连接的发送缓存中，发送缓存是三次握手初期设置的缓存之一.当TCP在另一端接受到一个报文段后，该报文段的数据就被放在该TCP连接的接收缓存中，TCP可从缓存中取出并放入报文段中的数据数量受限于最大报文段长度(MSS). TCP的每一端都有各自的发送缓存和接收缓存
客户TCP状态：初始为CLOSED(关闭)
第一步，客户端的TCP首先向服务器端的TCP发送一个特殊的TCP报文段，该报文段不含应用层数据， 报文段首部中的一个标志位(SYN比特)被置为1，因此，该报文段被称为SYN报文段.另外，客户会随机选择一个初始序号(client_isn),并将此编号放置于该起始的TCP SYN报文段的序号字段中。该报文段会被封装在一个IP数据中，并发送给服务器，完成后客户TCP状态为SYN_SEND.第二步，一旦包含TCP SYN报文段的IP数据报到达服务器主机，服务器会从该数据报中提取出TCP SYN数据报，为该TCP连接分配TCP缓存和变量，并向客户发送允许连接的报文段.这个报文段也不包含应用层数据.但是该报文段却包含3个重要的信息：1.SYN比特被置为1，2.该TCP报文段的首部确认号字段被置为client_isn + 1 3.服务器选择自己的初始序号server_isn，并将其放置到TCP报文段首部的序号字段中.该允许连接的报文段通常被称为SYNACK报文段，完成后客户TCP状态仍为SYN_SEND.第三步，在收到SYNACK报文段之后，客户也要给该连接分配缓存和变量。客户主机向服务器发送另一个报文段，对服务器的允许连接报文段进行确认，该客户通过将值server_isn + 1放置到TCP报文段首部的确认字段中来完成。因为连接已经建立，所以说SYN比特被置为0，这次可以在报文段中携带客户到服务器的数据，完成后客户TCP状态为ESTABLISHED(已建立).参与TCP连接中的两个进程任何一个都能关闭连接，当连接结束后，主机中的缓存和变量将被释放. 以客户要关闭连接为例
第一步 客户应用进程发出一个关闭连接命令，这会引起客户TCP向服务器进程发送一个特殊报文段，这个特殊报文段首部中的一个标志位，即FIN比特被设置为1，客户TCP状态处于FIN_WAIT_1状态.第二步 当服务器收到该报文段的后，就向发送发送一个确认报文段，客户TCP收到确认报文段之后，客户TCP状态处于FIN_WAIT_2状态.第三步 服务器 发送它自己的终止报文段，其FIN比特被置为1。第四步 客户对服务器的终止报文段进行确认，客户TCP状态处于TIME_WAIT状态。以下问题解答均为个人理解，如有错误，请指出.
答案就是UDP的优点，可以总结概括一下：
关于何时、发送什么数据的应用层控制更为精细。无需连接建立。TCP连接需要三次握手，而UDP则不需要，所以可以省去握手阶段的时间。无连接状态。TCP需要在端系统中维护连接的状态，包括接收和发送缓存、拥塞控制参数以及序号与确认号的参数。分组首部开销小。每个TCP的报文段首部都有20字节的首部开销，而UDP仅有8字节的开销。如果第一眼看到这个，一般直接就会说出TCP的可靠数据传输服务和拥塞控制机制，但是题目明确指出和TCP的拥塞控制机制没有关系，所以说，这就需要思考了. 这是我在书上看到的一个题目，书本的作者是这样回答的：
Since most firewalls are configured to block UDP traffic, using TCP for video and voice traffic lets the traffic though the firewalls.翻译一下也就是大概意思就是：因为大多数端系统的防火墙会阻止UDP流量，因此需要使用TCP发送。（英语渣在此 = =）
可能可以得到，可以在应用程序中建立可靠地传输机制，例如重传机制.
假设现在只有前两次握手，没有第三次握手，客户向服务器发送一个SYN报文段，请求建立连接，但是因为网络原因延迟了，服务器未能在一定时间内收到报文段，因为TCP的重传机制，所以客户会再次发送SYN报文段，且与第一个报文段的序列号是一样的，这个报文段可以到达服务器，服务器接受，连接建立。在通信结束后，连接断开，但是第一次的SYN报文段到达了，服务器以为客户要再次建立连接，所以就接受，连接建立，但是客户已经不会使用这条连接，那么不会通过这条连接向服务器发送数据，那么这条连接就是一个空的连接，浪费了资源. 使用三次握手后，在第三次握手的时候，当服务器收到客户的确认之后，才会建立连接，如果没有收到确认，是不会建立连接的. 总结来说就是：三次握手的目的是为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误.
在第二次握手之后，服务器会等待客户发送过来的ACK，如果没有收到，那么会重新发送SYN + ACK，一般会重复几次，如果还没有收到，那么服务器会关闭这次连接，即进入CLOSED状态，但是客户会以为连接已经建立，会向服务器发送数据，这时服务器会发送RST包来告诉客户重新建立连接(从第一次握手开始)。
在第三次挥手中，客户对服务器的终止报文段进行确认，并发送ACK，此时客户进入TIME_WAIT状态，如果ACK丢失，服务器就会重新发送第三步的终止报文段，来使客户的计时器重置，再次发送ACK，但是，如果服务器重发的终止报文段未能在客户的计时器销毁之前到达客户，那么客户会进入CLOSED状态，服务器收不到ACK确认报文段，那么本次关闭不会成功.
