UDP:面向无连接(即发送数据之前不需要建立连接),数据传输不安全,对系统要求资源少,快,不区分客户端和服务端,具有较好的实时性,工作效率比TCP高,基于报文发送,不会出现粘包问题
TCP:面向连接,有三次握手四次挥手这个过程,慢,数据传输安全可靠,对系统资源要求量大,慢,区分客户端与服务端.基于字节流,会将数据看做一大片的字节流数据,无边界,会出现粘包问题
TCP面向字节流,实际上是TCP把数据看做一连串无结构的字节流,UDP是面向报文的.UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
每一条TCP连接只能是点到点的,UDP支持一对一,一对多,多对一和多对多的交互通信.
TCP首部开销20字节,UDP的首部开销只有8个字节.
TCP的逻辑通信信道是全双工的可靠通信,UDP则是不可靠通信
采用TCP,一旦发生丢包,TCP会将后续的包缓存起来,等前面的包重传并接收到后再继续发送,延时会越来越大,基于UDP对实时性要求较为严格的情况下,采用自定义重传机制,能够把丢包产生的延迟降到最低.
UDP不提供复杂的控制机制,利用IP提供面向无连接的通信服务.并且它是将应用程序发来的数据在收到的那一刻,立刻按照原样发送到网络上的一种机制.UDP将部分控制转移到应用程序去处理,自己却只作为传输层协议的最基本功能.
TCP充分实现了数据传输时各种控制功能,可以进行丢包的重发机制,还可以对次序乱掉的分包进行顺序控制.TCP作为一种面向有连接的协议,只有在确定通信对端存在时才会发送数据,从而控制通信流量的浪费.TCP通过校验和,序列号,确认应答,重发控制,连接管理以及窗口控制等机制实现可靠性传输.
tcp的粘包问题:
粘包,拆包发生原因
发生TCP粘包或者拆包有很多原因,常见几点如下:
1.要发送的数据大于TCP发送缓冲区剩余大小,将会发生拆包.
2.待发送数据大于MSS(最大报文长度),TCP在传输前将进行拆包.
3.要发送的数据小于TCP发送缓冲区的大小.TCP将多次写入缓冲区的数据一次发送出去,将会发生粘包.
4.接收数据端的应用层没有及时接收缓冲区中的数据,将发生粘包.
粘包,拆包问题的解决:
解决问题的关键在于如何给每个数据包添加边界信息.常用的方法有以下三种:
1.发送端给每个数据段添加包首部,首部中应该至少包含数据包的长度,这样接收端在接收到数据后,通过读取包首部的长度字段,便知道每一个数据包的实际长度了.
2.发送端将每个数据包封装为固定长度(不够的可以通过补0填充),这样接收端每次从接收缓冲区中读取固定的长度数据,从而将每个数据包拆分开来.
3.可以在数据包之间设置边界,如添加特殊符号,接收端通过这个边界就可以把不同的数据包拆分开.
TCP的流量控制 -- 滑动窗口协议:
流量控制就是让发送方的发送速率不要太快,既要让接收方来得及接收,也不要使网络发生拥塞.而TCP控制流量则是利用滑动窗口机制实现的.
滑动窗口协议原理:
对所有数据帧按顺序赋予编号,发送方在发送过程中始终保持着一个发送端口,只有落在发送窗口内的帧才允许被发送;同时接收方也维持着一个接收窗口,只有落在接收窗口内的帧才允许接收.
TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间数据传输.每个TCP/IP主机支持全双工数据传输,因此TCP有两个滑动窗口:一个用于接收数据,一个用于发送数据.TCP使用肯定确认技术,其确认号指的是下一个所期待的字节.
开始的时候窗口比较小,然后开始增长直到有错误发生为止,窗口的滑动依赖于网络性能.通过调整发送方窗口和接收方窗口的大小可以实现流量控制.也就是说TCP协议通过滑动窗口来实现流量控制和差错控制以至于实现可靠传输.而发送端口的大小由接收端口的大小决定.滑动窗口机制为端到端设备间的数据传输提供了可靠的流量控制机制.然而,它只能在源端设备和目的端设备起作用,当网络中间设备(例如路由器等)发生拥塞时,滑动窗口机制将不起作用.
TCP提供体积可变的滑动窗口机制,支持端到端的流量控制.TCP的窗口以字节为单位进行调整,以适应接收方的处理能力.处理过程如下:
TCP连接阶段,双方协商窗口尺寸,同时接收方预留数据缓冲区;
发送方根据协商的结果,发送符合窗口定义的数据字节流,并等待对方的确定;
发送方根据确认信息,改变窗口的尺寸,增加或减少发送未得到确认的字节流中的字节数.调整过程包括:如果出现发送拥塞,发送窗口缩小为原来的一半,同时将超时重传的时间间隔扩大一倍.
滑动窗口根据长度大小可以分为1比特滑动窗口,后退n及选择重传三种协议.1比特滑动窗口协议:发送窗口=1,接收窗口=1;后退n协议:发送窗口>1,接收窗口=1;选择重传协议:发送窗口>1,接收窗口>1.
1比特滑动窗口协议:
当发送窗口和接收窗口的大小固定为1时，滑动窗口协议退化为停等协议（stop-and-wait）。该协议规定发送方每发送一帧后就要停下来，等待接收方已正确接收的确认（acknowledgement）返回后才能继续发送下一帧。由于接收方需要判断接收到的帧是新发的帧还是重新发送的帧，因此发送方要为每一个帧加一个序号。由于停等协议规定只有一帧完全发送成功后才能发送新的帧，因而只用一比特来编号就够了。其发送方和接收方运行的流程图如图所示。
后退n协议:
由于停等协议要为每一个帧进行确认后才继续发送下一帧，大大降低了信道利用率，因此又提出了后退n协议。后退n协议中，发送方在发完一个数据帧后，不停下来等待应答帧，而是连续发送若干个数据帧，即使在连续发送过程中收到了接收方发来的应答帧，也可以继续发送。且发送方在每发送完一个数据帧时都要设置超时定时器。只要在所设置的超时时间内仍未收到确认帧，就要重发相应的数据帧。如：当发送方发送了N个帧后，若发现该N帧的前一个帧在计时器超时后仍未返回其确认信息，则该帧被判为出错或丢失，此时发送方就不得不重新发送出错帧及其后的N帧。
从这里不难看出，后退n协议一方面因连续发送数据帧而提高了效率，但另一方面，在重传时又必须把原来已正确传送过的数据帧进行重传（仅因这些数据帧之前有一个数据帧出了错），这种做法又使传送效率降低。由此可见，若传输信道的传输质量很差因而误码率较大时，连续测协议不一定优于停止等待协议。此协议中的发送窗口的大小为k，接收窗口仍是1。
选择重传协议:
在后退n协议中，接收方若发现错误帧就不再接收后续的帧，即使是正确到达的帧，这显然是一种浪费。另一种效率更高的策略是当接收方发现某帧出错后，其后继续送来的正确的帧虽然不能立即递交给接收方的高层，但接收方仍可收下来，存放在一个缓冲区中，同时要求发送方重新传送出错的那一帧。一旦收到重新传来的帧后，就可以原已存于缓冲区中的其余帧一并按正确的顺序递交高层。这种方法称为选择重发（SELECTICE REPEAT），其工作过程如图所示。显然，选择重发减少了浪费，但要求接收方有足够大的缓冲区空间。