UDP与TCP简要总结体会

最新推荐文章于 2022-10-31 04:28:24 发布

ZLWhappyisOK

最新推荐文章于 2022-10-31 04:28:24 发布

阅读量1.4k

点赞数 1

分类专栏：计算机网络文章标签：计算机网络 TCP UDP 传输层

本文链接：https://blog.csdn.net/ZLWhappyisOK/article/details/82630508

版权

计算机网络专栏收录该内容

4 篇文章 0 订阅

订阅专栏

传输层的两个重要协议

在计算机网络中，UDP和TCP是传输层的两个最重要的协议。最近看了关于二者的一些书籍，越发觉得二者都是基于较为朴素的思想而设计的，在不断理解这两个协议的过程中，觉得它们都是很形象很具体的实在的东西，而不是一些空洞的概念。但由于内容上，尤其是TCP，实在是有些琐碎，特此整理一下。

我们应该知道传输层在整个网络体系（这里以五层体系模型为讨论对象）中所处的位置，即传输层为上面的应用层的各种应用进程屏蔽了下面的网际层的各种细节，这样会更容易理解UDP和TCP的各种功能和作用。

UDP（User Datagram Protocol）

首先来介绍用户数据报协议，UDP相比于TCP有一个整体上的特点，那就是设计得非常简单。这个简单体现在如下几个方面：

UDP是无连接的
UDP尽最大努力交付（UDP只进行报文的头部和数据部分的校验，如果出错就丢弃，丢弃后就丢了，不作其他处理）
UDP是面向报文的，即对于应用进程交下来的报文，不作任何分割或合并
UDP不进行拥塞控制
UDP可以进行一对一，一对多，多对多通信
UDP报文的首部开销相比TCP要小，仅为8个字节（包括源端口、目的端口、报文长度、检验和）

虽然UDP看上去很简单，但对一些应用场景来说，UDP是十分有用的，比如IP电话、实时视频会议。

TCP（Transmission Control Protocol）

传输控制协议相比于UDP要复杂的多，因此相关的内容也更多。首先来对比着看一下TCP的一些特点：

TCP是面向连接的
TCP提供可靠服务
TCP是面向字节流的
TCP使用全双工通信
TCP提供的是端到端的通信

这几个特点其实是相互联系的，例如，因为TCP要在通信之前在客户进程和服务器进程之间建立一条连接，因此提供的必然是端到端的通信。而TCP之所以能提供可靠服务，就是在面向字节流和全双工通信这两个特点的基础上实现的。这些观点将在下面的介绍中有所体现。

>>TCP可靠传输的原理

为了在不可靠的网际层上实现可靠的传输，TCP采用了一种停止等待的方法，意思就是如果发送方发送出一个报文后长时间没有收到接收方返回的确认，就不再等待，将未收到确认的报文重新发送一遍。这种方法称为ARQ（Automatic Repeat reQuest）自动重传请求。而为了提高信道利用率，TCP使用的其实是连续ARQ，即不用对每个报文都进行一一确认，而是采用累积确认的方式，这样发送方就可以一次连续发送好几个分组。

>>TCP可靠传输的实现

刚刚讲了TCP可靠传输的大致原理，即停止等待和重传。但TCP在具体实现这些原理时要更为复杂。TCP采用了一种被称为滑动窗口的方式，而这种方式的实现部分依赖于TCP报文的首部的支持。

TCP首部格式

TCP的首部要比UDP的复杂得多。其固定长度部分有20个字节，包括源端口、目的端口、序号、确认号、数据偏移、保留字段、标志位（URG、ACK、SYN、FIN、PSH、RST）、窗口、检验和、紧急指针。除此之外，还有最大长度为40个字节的选项字段。

而在这么多的首部字段当中，序号、确认号和窗口是与滑动窗口的实现密切相关的。因为TCP是面向字节流的，这就是说TCP是以字节为单位对报文进行处理的，具体体现在TCP对报文的每个字节都赋予了一个序号；而确认号也表示的是一个序号，它的作用是接收方收到发送方发送的报文后，告诉发送方确认号之前的所有字节都已经正确收到；窗口字段则指明了发送方某一时刻可以发送的字节流的大小。

滑动窗口的实现

滑动窗口的机制让人不禁联想到火车站进站检票时的情景：在人比较多的情况下，进站安检口一般都会有一名工作人员拿一个手牌，数十个人进站安检，然后用手牌把路一档，后面的人在前面十个人安检完成之前，只能先等着。接下来会看到这个情景和发送窗口很相像。

在TCP的发送方和接收方，分别都构建了一个一定大小的以字节为单位的窗口，分别称作发送窗口和接收窗口。发送窗口表示位于窗口内部的字节都可以立即发送，而接收窗口则指明了目前接收方的接收能力，发送方应该根据接收窗口调整发送窗口的大小。当发送方收到接收方的确认后，发送窗口的前后沿可以分别向前移动，以便继续发送其他字节流，而接收方在收到发送方的数据并向上交付给应用程序后，就可以腾出来额外的空间继续接受发送方发来的字节流，这种情形下，两个窗口就像是分别在发送缓存和接收缓存上不断向前滑动一样。而对于发送方来说，发送窗口就类似于工作人员数十个人进站安检，前面的人安检完，后面的人接着进去，就好像发送窗口在人群中滑动一样。

总的来说，滑动窗口有如下几个重要的点需要记住：1）发送方通过接收方确认报文中的确认号和窗口值来调整其发送窗口的位置和大小；2）接收方采用累积确认的方式；3）接收方根据当前可用接收缓存的大小调整接收窗口的大小。

>>TCP的流量控制

TCP的流量控制其实主要依赖的还是滑动窗口机制，即通过接收方调整接收窗口的大小，并告诉发送方，从而使发送方发送的数据量减小或增大。

>>TCP的拥塞控制

引起网络拥塞的原因可以简单概括为：对于网络资源整体的需求大于可用的资源数量。但引起网络拥塞的原因其实是十分复杂的，而解决拥塞问题也不能只简单地采取增加结点缓存或者网络带宽等单一的措施，而是应该使得网络整体能够维持一个平衡。TCP的拥塞控制的方法可以简单归纳为控制流入网络中的流量的大小，并且与滑动窗口的机制密切相关，具体包括如下四种方法：

1）慢开始算法

慢开始算法的思想很朴素，给我的感觉就像是一个贪污犯，最一开始贪污只敢收一两千块钱，然后由于贪了之后并没有人发现，胆子越来越大，开始成倍地贪污，贪污的钱数成指数级上升趋势。而回到慢开始算法，它的做法也类似，就是一开始给发送方的滑动窗口设置一个很小的值，然后每收到接收方发回的一次确认，就将发送窗口增大被确认过的字节数大小，这样，当一个窗口内的字节全部被确认后，窗口就增大了一倍。

2）拥塞避免算法

可以看出，若不对慢开始算法加以控制，发送窗口会无限制的增大，这当然是不被允许的（这里我们只考虑拥塞控制对发送窗口的影响，而不考虑接收窗口的大小）。因此必须为慢开始算法设置一个门限值，当发送窗口大小超过这个门限值后，就改用拥塞避免算法。拥塞避免算法的思想是减缓发送窗口的增长速度，相比于慢开始算法，拥塞避免在发送窗口内的字节全部确认完后，才让发送窗口增加一个最大报文段大小（MSS）（具体实现的方法其实也是每收到一个确认就增大发送窗口，只不过每次增大的幅度比较小，当一个窗口内的字节全部确认完毕，刚好增加了一个MSS大小）。

拥塞避免算法也是在不断增大发送窗口的大小，当网络中出现拥塞时（出现拥塞的标志是超时），就改用慢开始算法，并把门限值设置为当前发送窗口的一半。

3）快重传 4）快开始

快重传算法的目的是为了尽早检测出接收方没有收到某个报文，而不是等待超时才进行处理，而尽早检测的方法就是：接收对没有收到的报文段重复发送请求，比如当0~100号字节已经正确收到，而101~200号字节在传输过程中丢失，接收方就会不停地发送确认号为101的报文，告诉发送方我现在需要101~200的报文，再重新发给我一次。当发送方连续收到三次这样的报文后，就会认为101~200号字节确实丢失了，然后使用快开始算法，将门限值设置为设置为当前发送窗口的一半，然后发送窗口改为当前的门限值，接下来开始使用拥塞避免算法进行处理。这样，就可以避免等到101~200号超时的时候才让发送方知道101~200号丢失，导致发送方使用慢开始算法使得发送窗口一下子变得很小，降低传输效率。

此外，在网络层，还有主动队列管理（AQM）策略与TCP的拥塞控制关系比较密切，这里不再详细阐述。