《UDP协议与TCP协议的比较》由会员分享，可在线阅读，更多相关《UDP协议与TCP协议的比较（4页珍藏版）》请在金锄头文库上搜索。
1、UDP 协议是无面向连接的、不可靠的、无序的、无流量控制的传输层协议，UDP 发送的每个数据报是记录型的数据报，所谓的记录型数据报就是接收进程可以识别接收到的数据报的记录边界。TCP 协议是面向连接的、可靠的、有序的、拥有流量控制的传输层协议，它是字节流的协议，无记录边界。1.1.记录与字节流记录与字节流UDP 协议：发送进程在发送每个数据报的时候并不等待多个数据报集中在一起以一个较大数据报发送出去，而是立即发送出去，它是记录型的协议。并且接收进程每次通过 read 或 recv获得的数据报必定是发送进程所发送的那个数据报不可能是多个数据报，接收进程可以识别到发送进程所发送的每个数据报的记录边
2、界。TCP 协议：发送进程在发送每个数据报的时候在内核处理过程中有可能并不立即发送出去，而是会将多个数据报集中在一起以一个较大的数据报来发送，它是字节流的协议。而接收进程每次通过 read 来读取发送进程发送过来的数据报并不一定是发送进程原先发送数据报，接收进程无法识别每个数据报的记录边界，所以 TCP 协议就是字节流的、无记录边界的协议。例如：QQ 聊天所用到的协议就应该是有记录边界的，聊天过程中是以“消息”为单位，消息可以看成一个记录，所以 QQ 聊天协议采取 UDP 协议而不是 TCP 协议。2.2.有序与无序有序与无序UDP 协议：发送进程所发送的每个数据报并不按照原先发送的顺序到达接
3、收进程，有可能早发送的数据报较后到达接收进程。因为数据报在经过中间路径的传送时会因为各个数据报传送的路径不同或者其它原因而造成这些数据报到达的顺序不同，UDP 协议是无序的传输协议。所以为了使基于 UDP 协议的应用程序有序，必须在应用程序中设置序号、确认机制来使其有序。TCP 协议：有序协议，有超时、序号、重传、确认机制。例如：FTP 协议是用于传送文件的协议，为了确保在传送文件内容的时候，传送的每个数据报协议有序接收，所以 FTP 协议是基于 TCP 协议。那为什么 TFTP 协议是基于 UDP 协议?因为为了保证有序，TFTP 协议中引入了确认、序号字段。这里还有一个问题，FTP 协议中
4、的控制连接传送的内容好像都是基于消息形式，客户端在控制连接上发出一个请求消息，服务器端返回一个请求结果消息，感觉应该 FTP 控制连接采取 UDP 协议，为什么采取 TCP 协议?因为控制连接上是交互式的消息传送，客户端在发送一个请求之后，在服务器端的响应消息未到达之前，客户端是不会发送第二个请求消息，所以不用担心这两个请求消息会叠加在一起。也就是对于交互式的消息传递也可以采用 TCP协议。3.3.流量控制流量控制UDP 协议：没有流量控制机制，如果发送进程发送数据报塞满了接收进程的接收缓冲区，就会丢弃数据报。出现这种情况，UDP 协议不会通知发送进程减缓数据的发送速率。TCP 协议：拥有流量
5、控制。4.4.客户端通信过程比较客户端通信过程比较4.1 客户端的连接过程比较UDP 协议在创建插口之后，可以同多个服务器端建立通信，而 TCP 协议只能与一个服务器端建立通信，TCP 不允许目的地址是广播或多播地址，UDP 允许。UDP 协议客户端同服务器端的通信关系可以是一对多的关系，而 TCP协议只能是一对一的关系。当然 UDP 协议也可以像 TCP 协议一样，通过 connect 来指定对方的 ip 地址、端口(对应下图 1 中的操作)，connect 是插口连接操作，connect 操作之后代表对应的插口已连接，与 TCP 协议不同，UDP 的 connect 实现不包含三向握手。不
6、管是 UDP 协议还是 TCP 协议，connect 实现的共同部分都包括：若所指定插口的本地地址、端口未指定，那么 connect 的时候由内核为其指定本地地址、本地端口，内核根据插口中的目的地址来判断外出接口，然后指定该外出接口的 IP 地址为插口的本地地址。UDP 协议通过 connect 操作之后同服务器端的通信关系成为一对一关系，不再是一对多的关系，而且这时也不能指定目的地址为广播或多播地址，因为 connect 函数不允许目的地址为广播或多播地址。UDP 协议经过 connect 之后，在通过 sendto 来发送数据报时不需要指定目的地址、端口，如果指定了目的地址、端口，那么会返
7、回错误。通过 UDP 协议可以给同一个插口指定多次 connect 操作，而TCP 协议不可以，TCP 只能指定一次 connect 操作。UDP 协议指定第二次 connect 操作之后会先断口第一次的连接，然后建立第二次的连接。客户端在建立同服务器端的连接过程中，第一步都会通过 socket 建立连接套接字，然后通过 bind 来绑定本地地址、本地端口，当然绑定操作可以不用指定。UDP 协议：若未指定绑定操作，那么可以通过下面 connect 操作来由内核负责插口的绑定操作，若 connect 又未指定，那么绑定操作只好通过插口的写操作(sendto、sendmsg)来指定目的地址、端口，
8、这时插口本地地址不会指定，为通配地址，而本地端口由内核指定，第一次 sendto 操作之后，插口的本地端口经过内核指定之后就不会更改。TCP 协议：若未指定绑定操作，可以通过下面 connect 操作来由内核负责插口的绑定操作。内核会根据插口中的目的地址来判断外出接口，然后指定该外出接口的 IP 地址为插口的本地地址。Connect 操作对于 TCP 协议的客户端是必不可少的，必须指定。(不管是 UDP 协议还是 TCP 协议，所对应插口经过 connect 操作之后就是已连接的插口，未经过 connect 就代表未连接的插口。)通过 bind 来绑定本地地址、本地端口的时候，不管是已连接的还
9、是未连接的插口，如果存在某一个插口的本地端口同用户所要绑定的本地端口相同，都会返回 EADDRINUSE(Address already in use)错误。如果要绑定同已存在插口的本地端口相同的端口，必须先设置插口选项 SO_REUSEADDR，然后再绑定。在 linux 系统中如果绑定的本地地址不同而本地端口相同可以不用设置插口选项 SO_REUSEADDR，而对于其它的类 UNIX 系统根据unix 网络编程中所描述的都要预先设置 SO_REUSEADDR 插口选项。对于 TCP 协议绝不允许绑定的本地地址、端口同已存在的插口(不管是已连接的还是未连接的插口)相同。对于 UDP 协议通过
10、设置插口选项 SO_REUSEPORT，允许绑定相同的本地地址、本地端口。在 linux 系统中，没有SO_REUSEPORT 这个选项，所以在 linux 系统中 UDP 协议同 TCP 协议一样都不允许存在两个插口有相同的本地地址、本地端口。TCP 协议同 UDP 协议还有一个很大的不同点：例如有一台多宿主机，它所拥有的 IP 地址有 A、B、C，现在创建 4 个相同的 TCP 监听端口 port，对应的四个插口地址结构(*，port)、(A，port)、(B，port)、(C，port)，现在有客户端要同(A，port)建立连接，那么只会同(A，port)插口建立连接，而不会同拥有通配地
11、址*的插口建立连接。而如果是创建 4 个相同的 UDP 监听端口 port，对应的四个插口地址结构(*，port)、(A，port)、(B，port)、(C，port)，那么有客户端要同(A，port)建立通信，那么发送到(A，port)的数据报也会拷贝一份到(*，port)插口。原因：TCP 协议之间的通信是一对一的关系，而 UDP 可以是一对多的关系。步骤UDP 协议TCP 协议socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP)socket(AF_INET,SOCK_STREAM,IPPROTO_TCP)bind 捆绑本地地址、本地端口（可忽略，在下面 conne
12、ct 中或第一次 sendto 由内核来指定）bind 捆绑本地地址、本地端口（可忽略，在下面的 connect 操作中由内核来指定本地地址、端口）connect 指定对方地址、端口，建立连接（可忽略由 sendto 指定对方地址、端口）connect 指定对方地址、端口，建立连接读或写操作读或写操作图 1 客户端连接过程4.2 服务器端的连接过程比较对于 UDP 协议客户端与服务器端没有什么本质的区别，每个 UDP 协议的客户端也是服务器端。而 TCP 协议就不同了，TCP 协议必须通过 listen 来申请监听，然后通过 accept 来接收一个客户端的连接，当接收客户端的连接会再创建一个
13、单独的插口用来同客户端之间进行数据通信，也就是说服务器端由一个单独的监听插口负责监听客户端的连接请求，当接收到一个来自客户端的连接请求之后，服务器会另外创建一个插口负责同客户端之间进行连接通信。服务端在通过 bind 来绑定本地地址、本地端口的时候应注意的情况，同客户端是相同的。步骤UDP 协议TCP 协议socket(AF_INET,SOCK_DGRAM,IPPROTO_UDP)socket(AF_INET,SOCK_STREAM,IPPROTO_TCP)bind 捆绑本地地址、本地端口（可忽略，在下面 connect 中或第一次 sendto 由内核来指定）bind 捆绑本地地址、本地端口（可忽略，在下面 listen 操作中由内核来指定本地地址、本地端口）connect 指定对方地址、端口，建立连接（可忽略由 sendto 指定对方地址、端口）listen 监听客户端的连接读或写操作accept 接受客户端的连接 读或写操作图 2 服务器端连接过程
