UDP与TCP的对比

1、报头
(1)TCP协议报头
TCP指传输控制协议,其报头格式如下:
在这里插入图片描述
TCP协议中的六个标志分别是,URG、ACK、PSH、RST、SYN、FIN。
1)UGR(紧急):UGR=1表示紧急指针字段有效。它告诉系统此报文段有紧急数据,应当尽快传送。从报文段的开头,到紧急指针指向的地方就是紧急数据。
2)ACK(确认):ACK=1时,确认号字段才有效。
3)PSH(推送):让对方立即收到响应。与URG的区别就是URG中的紧急数据不经过缓冲区就直接上交给上层逻辑,而PSH还是要从缓冲区上交,只是不用等到缓冲区满了才上交。
4)RST(复位):RST=1时,表明TCP链接中出现严重差错,必须释放链接,然后再重新链接。以下几种场景中会使用RST报文(访问不存在的端口。异常终止一个链接,一般情况下是发送FIN,因为在所有排队数据都以发送之后才发送FIN,但是也有可能发送一个RST来异常释放连接。检测半打开的链接,即一端关闭,另一端不知道,这时会发送一个RST进行监测。当长时间不用连接,连接断开之后,再次访问的时候会发送RST)。
5)SYN(同步):在链接建立时用来同步序号。当SYN=1,ACK=0时表示请求报文。SYN=1,ACK=1表示链接接受。因此SYN=1表示一个链接请求或链接接受报文。
6)FIN(终止):用来释放一个链接。

(2)UDP协议报头
UDP指用户数据报协议,其报头格式如下:
在这里插入图片描述

2、TCP的优缺点
(1)TCP的优点:
TCP的优点是:可靠、稳定。它体现在TCP在传递数据之前,会有三次握手来建立连接;在数据传递时,采用校验和、序列号、确认应答、超时重发、流量控制、拥塞控制,为了提高性能,还采用了滑动窗口、延迟应答和捎带应答等机制;在数据传完后,会断开连接以节约系统资源。

(2)TCP的缺点:
TCP的缺点:运行速度慢,效率低,占用系统资源多,易被攻击。因为TCP在传递数据之前,要先建立连接,这会消耗时间;在数据传递时,确认机制、重传机制、拥塞控制机制等都会消耗大量的时间,而且要在每台设备上维护所有的传输连接,每个连接都会占用系统的CPU、内存等资源;TCP有确认机制、三次握手机制,这导致TCP容易受到DOS、DDOS、CC等攻击。收到STN洪水攻击,是因为使用 TCP的时候服务器端需要listen,这时需要设置backlog。

3、UDP的优缺点
(1)UDP的优点:运行速度较快,比TCP安全。
1)运行速度快,因为 UDP连接没有TCP的三次握手、确认应答、超时重发、流量控制、拥塞控制等机制,而且UDP是一个无状态的传输协议,所以它在传递数据时非常快。
2)较安全,因为没有TCP的那些机制,UDP较TCP被攻击者利用的漏洞就会少一些。但UDP也是无法避免攻击的,比如:UDP Flood攻击等。
(2)UDP的缺点:不可靠,不稳定。
因为UDP没有TCP那些可靠的机制,在数据传递时,如果网络质量不好,就会很容易丢包。

4、TCP和UDP的特点
(1)TCP的特点
TCP协议是一种有连接、可靠的、面向字节流、相对比较慢、点对点的传输层协议。TCP协议适用于对可靠性要求比较高的场合。
(2)UDP的特点
UDP协议是一种无连接,不可靠、面向数据报、速度比较快、可实现一对一,多对一的传输层协议。UDP协议适用于对实时性有要求的场合。因为UDP不保证可靠性,所以UDP也没有重传机制,也没有拥塞机制,它只是尽最大努力交付数据。

5、TCP保证数据可靠性和提高性能的机制
(1)确认应答(ACK)机制
TCP将每个字节的数据都进行了编号,即为序列号。每一个ACK都带有对应的确认序列号,意思是告诉发送者收到了哪些数据,下次从哪里开始发送。

(2)超时重传机制
1)超时重传机制的工作过程
主机A发送数据给B之后,可能因为网络拥堵等问题,数据无法到达主机B。如果主机A在一个特定时间间隔内没有收到B发来的确认应答,就会进行重发。但是,主机A未收到B发来的确认应答,也可能是因为ACK丢失了,因此主机B会收到很多重复数据。那么TCP协议需要能够识别出哪些包是重复的,并且把重复的丢弃掉,这时候可以利用序列号就可以很容易做到去重的效果。
2)如何确定超时时间?
最理想的情况下找到一个最小的时间,保证“确认应答”一定能在这个时间内返回。但是,这个时间的长短随着网络环境的不同是有差异的,如果超时时间设的太长会影响整体的重传效率;如果超时时间设得太短,有可能会频繁发送重复的包。
TCP为了保证无论在任何环境下都能比较高性能的通信,因此会动态计算这个最大超时时间。Linux中超时以500ms为一个单位进行控制,每次判定超时重发的超时时间都是500ms的整数倍。如果重发一次之后仍然得不到应答,等待2500ms后进行重传;如果仍然得不到应答,等待4500ms再进行重传,以此类推,以指数形式递增。累计到一定的重传次数,TCP认为网络或者对端主机出现异常,并强制关闭连接。

(3)滑动窗口
1)为什么需要滑动窗口?
前面讨论了确认应答策略,对每一个发送的数据段都要给一个ACK确认应答,收到ACK后再发送下一个数据段。这个做有一个比较大的缺点就是性能较差,尤其是数据往返的时间较长的时候。既然这样一发一收性能较低,那么如果一次发送多条数据,不是就可以将多个段的等待时间重叠在一起提高性能了吗?
2)工作过程
窗口大小指的是无须等待确认应答而可以继续发送数据的最大值,规定发送前4个段的时候,需要等待任何ACK直接发送。收到第一个ACK后,滑动窗口向后移动,继续发送第5个段的数据,以此类推。操作系统内核为了维护这个滑动窗口,需要开辟发送缓冲区来记录当前还有哪些数据没有应答,只有确认应答过的数据才能从缓冲区删掉,窗口越大网络吞吐率就越高。那么如果出现丢包,如何进行重传?
情况一:数据包已经抵达,ACK被丢了。
这种情况下,部分ACK丢了并不要紧,因为可以通过后续的ACK进行确认。
情况二:数据包直接丢了。
当某一段报文丢失之后,发送端会一直收到1001这样的ACK,就像是在提醒发送端“接收端想要的就是1001”一样。如果发送端主机连续三次收到了同样一个“1001”,就会将对应的数据1001-2000重新发送.这个时候接收端收到了1001之后,再次返回的ACK就是7001了,因为2001-7000接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中。这种机制被称为“高速重发控制”,也称为“快重传”。

(4)流量控制
1)什么是流量控制?
接收端处理数据的速度是有限的,如果发送端发得太快,导致接收端的缓冲区被填满,这个时候如果发送端继续发送就会造成丢包,继而引起丢包重传等等一系列连锁反应。因此,TCP支持根据接收端的处理能力来决定发送端的发送速度,这个机制就叫做流量控制。
2)工作流程
接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段,通过ACK端通知发送端。窗口大小字段越大,说明网络的吞吐量越高。接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端,发送端接收到这个窗口之后就会减慢自己的发送速度。如果接收端缓冲区满了就会将窗口置为0,这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。
3)接收端如何把窗口大小告诉发送端?
在TCP首部中,有一个16位窗口字段就是用于存放窗口信息的。16位数字最大表示65535,那么TCP窗口最大就是65535字节么?实际上,TCP首部40字节选项中还包含了一个窗口扩大因子M,实际窗口大小是窗口字段的值左移M位。

(5)拥塞控制
1)拥塞控制的必要性
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量数据,但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵,在不清楚当前网络状态下贸然发送大量的数据,是很有可能雪上加霜的。
2)慢启动
TCP引入慢启动机制,先发少量的数据探探路,摸清当前的网络拥堵状态再决定按照多大的速度传输数据。此处引入一个概念——拥塞窗口,发送开始的时候,定义拥塞窗口大小为1。每次收到一个ACK应答拥塞窗口就加1,每次发送数据包的时候将拥塞窗口和接收端主机反馈的窗口大小做比较,取较小的值作为实际发送的窗口。
3)慢启动阀值
像上面这样的拥塞窗口增长速度是指数级别的。“慢启动”只是指初始时慢,但是增长速度非常快。为了不增长得那么快,因此不能使用拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阀值,当拥塞窗口超过这个阀值的时候,不再按照指数方式增长,而是按照线性方式增长。 当TCP开始启动的时候,慢启动阀值等于窗口最大值,在每次超时重发的时候,慢启动阀值会变成原来的一半,同时拥塞窗口置回1。少量的丢包仅仅是触发超时重传,大量的丢包就会认为是网络拥塞。当TCP通信开始后,网络吞吐量会逐渐上升,随着网络发生拥堵,吞吐量会立刻下降。拥塞控制。归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大的压力的折中方案。(TCP拥塞控制这样的过程就好像热恋的感觉)

(6)延迟应答
如果接收端数据的主机立刻返回ACK应答,这个时候返回的窗口可能性比较小。假设接收端缓冲区为1M,一次收到了500k的数据,如果立刻应答,返回的窗口就是500k。但是实际上可能处理端处理的速度很快,10ms之内就把500k数据从缓冲区消费掉。在这种情况下,接收端处理还远没有达到自己的极限,即使窗口再放大一些,也能处理过来。如果接收端稍微等一会儿在应答,比如等待200ms在应答,那么这个时候返回的窗口大小就是1M。注意:窗口越大,网络吞吐量就越大,传输效率就越高,应在保证网络不拥塞的情况下尽量提高传输效率。那么所以的包都可以延迟应答么?肯定不行,因为规定有数量限制,每隔N个包就应答一次;而且有时间限制,超过最大延迟时间就应答一次,具体的数量和时间依操作系统不同也有差异,一般N取2,超时时间取200ms。

(7)捎带应答
在延迟应答的基础上,很多情况下客户端服务器在应用层也是“一发一收”的,意味着客户端给服务器说了“how are you”,服务器也会给客户端会一个“Fine,thank 有”,那么这个时候ACK就可以搭顺风车和服务器回应的“Fine,thank you”一起会给客户端。

猜你喜欢

转载自blog.csdn.net/m0_38121874/article/details/82914634