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