计网：运输层
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了计网：运输层相关的知识，希望对你有一定的参考价值。
参考技术A本篇文章先概括介绍运输层协议的特点、进程之间的通信和端口等重要概念，然后讲述比较简单的UDP协议。然后讨论较为复杂但非常重要的TCP协议和可靠传输的工作原理，包括停止等待协议和ARQ协议。在详细讲述TCP报文段的首部格式之后，讨论TCP的三个重要问题：滑动窗口、流量控制和拥塞控制机制。最后，介绍TCP的连接管理。
从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最低层。
当网络的边缘部分中的两台主机使用网络 的核心部分的功能进行端到端的通信时，只有主机的协议栈才有运输层，而网络核心部分中的路由器在转发分组时都只用到下三层的功能。
运输层有一个很重要的功能 复用和分用：
从IP层来说，通信的两端是两台主机。但实际上，真正进行通信的实体是 在主机中的进程，是这台主机中的一个进程和另一台主机中的一个进程在交换数据(即通信)。运输层提供应用进程间的逻辑通信。“逻辑通信”的意思是：从应用层来看，只要把应用层报文交给下面的运输层， 运输层就可以把这报文传送到对方的运输层。但事实上这两个运输层之间并没有一条水平方向的物理连接。数据的传送是沿着图中的虚线方向（经过多个层次）传送的。
从这里可以看出网络层和运输层有明显的区别。网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。
运输层还要对收到的报文进行差错检测，而在网络层，IP数据报首部中的检验和字段，只检验首部是否出现差错而不检查数据部分。
根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的TCP和无连接的UDP,这两种协议就是本章要讨论的主要内容。
当运输层采用面向连接的TCP协议时，尽管下面的网络是不可靠的(只提供尽最大努力服务)，但这种逻辑通信信道就相当于一条全双工的可靠信道。但当运输层釆用无连接的UDP协议时，这种逻辑通信信道仍然是一条不可靠信道。
TCP/IP运输层的两个主要协议都是互联网的正式标准，即：
在TCP/IP体系中，则根据所使用的协议是TCP或 UDP，分别称之为TCP报文段或UDP用户数据报。
UDP在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是一种最有效的工作方式。
TCP则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或多播服务。由于TCP要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，占用许多处理机资源。
前面己经提到过运输层的复用和分用功能。应用层所有的应用进程都可以通过运输层再传送到IP层（网络层），这就是复用。运输层从IP层收到发送给各应用进程的数据后，必须分别交付指明的各应用进程，这就是分用。显然，给应用层的每个应用进程赋予一个非常明确的标志是至关重要的。
为了使运行不同操作系统的计算机的应用进程能够互相通信，就必须用统一的方法（而这种方法必须与特定操作系统无关）对TCP/IP体系的应用进程进行标志。
解决这个问题的方法就是在运输层使用协议端口号，或通常简称为端口。这就是说，虽然通信的终点是应用进程，但只要把所传送的报文交到目的主机的某个合适的目的端口，剩下的工作（即最后交付目的进程）就由TCP或UDP来完成。
在协议栈层间的抽象的协议端口是软件端口，和路由器或交换机上的硬件端口是完全不同的概念。软件端口是应用层的各种协议进程与运输实体进行层间交互的一种地址。
TCP/IP的运输层用一个16位端口号来标志一个端口。但请注意，端口号只具有本地意义，它只是为了标志本计算机应用层中的各个进程在和运输层交互时的层间接口。在互联网不同计算机中，相同的端口号是没有关联的。
两个计算机中的进程要互相通信，不仅必须知道对方的IP地址（为了找到对方的计算机），而且要知道对方的端口号（为了找到对方计算机中的应用进程）。
因此运输层的端口号分为下面的两大类：
用户数据报协议UDP只在IP的数据报服务之上增加了很少一点的功能，这就是复用和分用的功能以及差错检测的功能。
UDP的主要特点是：
用户数据报UDP有两个字段：数据字段和首部字段。首部字段很简单，只有8个字节。由四个字段组成，每个字段的长度都是两个字节。各字段意义如下：
当运输层从IP层收到UDP数据报时，就根据首部中的目的端口，把UDP数据报通过相应的端口，上交最后的终点——应用进程。
如果接收方UDP发现收到的报文中的目的端口号不正确(即不存在对应于该端口号的应用进程)，就丢弃该报文，并由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。
UDP用户数据报首部中检验和的计算方法有些特殊。在计算检验和时，要在UDP用户 数据报之前增加12个字节的伪首部。所谓“伪首部”是因为这种伪首部并不是UDP用户数 据报真正的首部。只是在计算检验和时，临时添加在UDP用户数据报前面，得到一个临时的 UDP用户数据报。检验和就是按照这个临时的UDP用户数据报来计算的。伪首部既不向下传
送也不向上递交，而仅仅是为了计算检验和。
UDP计算检验和的方法和计算IP数据报首部检验和的方法相似。但不同的是：IP数据 报的检验和只检验IP数据报的首部，但UDP的检验和是把首部和数据部分一起都检验。
TCP是TCP/IP体系中非常复杂的一个协议，下面介绍TCP最主要的特点：
前面己经讲过，每一条TCP连接有两个端点，TCP连接的端点叫做套接字或插口。端口号拼接到IP地址即 构成了套接字。
因此，套接字的表示方法是在点分十进制的IP地址后面写上端口号，中间用冒号或逗号隔开，例如说：
每一条TCP连接唯一地被通信两端的两个端点(即两个套接字)所确定，例如：
这里IP1和IP2分别是两个端点主机的IP地址，而port1和port2分别是两个端点主机中的端口号。TCP连接的两个套接字就是socket1和socket2。
总之，TCP连接就是由协议软件所提供的一种抽象。
虽然有时为了方便，我们也可以说，在一个应用进程和另一个应用进程之间建立了一条TCP连接，但一定要记住：TCP连 接的端点是个很抽象的套接字，即(IP地址：端口号)。
我们知道，TCP发送的报文段是交给IP层传送的。但IP层只能提供尽最大努力服务，也就是说，TCP下面的网络所提供的是不可靠的传输。因此，TCP必须釆用适当的措施才能使得两个运输层之间的通信变得可靠。
“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
停止等待协议有以下四种情况：
停止等待协议的优点是简单，但缺点是信道利用率太低。
信道利用率U可以用以下公式计算：
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是釆用流水线传输，这种传输方式可以获得很高的信道利用率。
滑动窗口协议比较复杂，是TCP协议的精髓所在。这里先给出连续ARQ协议最基本的概念，但不涉及许多细节问题。
发送方维持的发送窗口，它的意义是：位于发送窗口内的分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
连续ARQ协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
如果原来己经发送了前5个分组，那么现在就可以发送窗口内的第6个分组了。
接收方一般都是釆用累积确认的方式。这就是说，接收方不必对收到的分组逐个发送 确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。
累积确认有优点也有缺点。优点是：容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。
如果发送方发送了前5个分组，而中间的第3个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N（回退N）。
TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，而TCP的全部功能都体现在它首部中各字段的作用。
TCP报文段首部的前20个字节是固定的，后面有4n字节是根据需要而增加的选项。因此TCP首部的最小长度是20字节。
首部固定部分各字段的意义如下：
TCP的滑动窗口是以字节为单位的。
现假定A收到了 B发来的确认报文段，其中窗口是20字节，而确认号是31（这表明B期望收到的下一个序号是31,而序号30为止的数据已经收到了）。
A的发送窗口表示：在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
发送窗口后沿的后面部分表示己发送且己收到了确认。发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。
发送窗口里面的序号表示允许发送的序号。窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。但A的发送窗口一定不能超过B的接收窗口数值。
发送窗口前沿的前面部分表示不允许发送的。发送窗口前沿通常是不断向前移动，但也有可能不动。这对应于两种情况：一是没有收到新的确认，对方通知的窗口大小也不变；二是收到了 新的确认但对方通知的窗口缩小了，使得发送窗口前沿正好不动。
现在假定A发送了序号为31〜41的数据。这时，发送窗口位置并未改变， 但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9个字节（42〜50）是允许发送但尚未发送的。
从以上所述可以看出，要描述一个发送窗口的状态需要三个指针：P1，P2和P3，小于P1的是已发送并已收到确认的部分，而大于P3的是不允许发送的部分：
再看一下B的接收窗口。B的接收窗口大小是20。在接收窗口外面，到30号为止的数据是已经发送过确认，并且已经交付主机了。因此在B可以不再保留这些数据。接收窗口内的序号（31〜50）是允许接收的。
此时B收到了序号为32和33的数据。这些数据没有按序到达，因为序号为31的数据没有收到（也许丢失了，也许滞留在网络中的某处）。请注意，B只能对按序收到的数据中的最高序号给出确认，因此B发送的确认报文段中的确认号仍然是31 （即期望收到的序号），而不能是32或33。
现在假定B收到了序号为31的数据，并把序号为31〜33的数据交付主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A发送确认，其中窗口值仍为20，但确认号是34。这表明B已经收到了到序号33为止的数据。我们注意到，B还收到了序号为37, 38和40的数据，但这些都没有按序到达，只能先暂存在接收窗口中。
A在继续发送完序号42〜53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认(图5-18)。由于A的发送窗口己满，可用窗口已减小到零，因此必须停止发送。为了保证可靠传输，A只能认为B还没有收到这些数据。于是，A在经过一段时间后(由超时计时器控制)就重传这部分数据，重新设置超时计时器，直到收到B的确认为止。
CP的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP最复杂的问题之一。
如果把超时重传 时间设置得太短，就会引起很多报文段的不必要的重传，使网络负荷增大。但若把超时重传 时间设置得过长，则又使网络的空闲时间增大，降低了传输效率。
那么，运输层的超时计时器的超时重传时间究竟应设置为多大呢？
TCP釆用了一种自适应算法，它记录一个报文段发出的时间，以及收到相应的确认的 时间。这两个时间之差就是报文段的往返时间RTT。TCP保留了 RTT的一个加权平均往返时间RTT s 。
每当第一次测量到RTT样本时，RTTs值就取为所测量到的RTT样本 值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTT s ：
显然，超时计时器设置的超时重传时间RTO应略大于上面得 出的加权平均往返时间RTT s ，所以RTO应该这样计算。
而RTT D 是RTT的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。
现在发送出一个报文段，设定的重传时间到了，还没有收到确认。于是重传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段 是对先发送的报文段的确认，还是对后来重传的报文段的确认？
Kam算法进行修正。方法是：报文段每重传一次，就把超时重传时间RTO增大一些。典型的做法是取新的重传时间为旧的重传时间的2倍。当不再发生报文段的重传时，才根据上面给出的式子计算超时重传时间。
现在还有一个问题没有讨论。这就是若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的。选择确认就是一种可行的处理方法。
举一个例子来说明选择确认的工作原理。TCP的接收方在接收对方发送过来的数据字节流的序号不连续，结果就形成了一些不连续的字节块。
可以看出，序号1〜1000收到了，但序号1001〜1500没有收到。接下来的字节流又收到了，可是又缺少了3001〜3500。再后面从序号4501起又没有收到。
也就是说，接收方收到了和前面的字节流不连续的两个字节块。如果这些字节的序号都在接收窗口之内，那么接收方就先收下这些数据，但要把这些信息准确地告诉发送方，使发送方不要再重复发送这些已收到的数据。
一般说来，我们总是希望数据传输得更快一些。但如果发送方把数据发送得过快，接 收方就可能来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口rwnd = 400”。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
我们应注意到，接收方的主机B进行了三次流量控制。第一次把窗口减小到rwnd = 300, 第二次又减到rwnd = 100,最后减到rwnd = 0,即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B重新发出一个新的窗口值为止。
TCP协议使得在发送方不发送很小的报文段的同时，接收方也不要 在缓存刚刚有了一点小的空间就急忙把这个很小的窗口大小信息通知给发送方。
在计算机网络中的链路容量（即带宽）、交换结点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞，即对资源需求之和 > 可用资源。
网络拥塞往往是由许多因素引起的。简单地将处理机的速率提高或简单地扩大缓存的存储空间，可能会使上述情况缓解一些，但往往又会将瓶颈转移到其他地方。问题的实质往往是整个系统的各个部分不匹配。只有所有的部分都平衡了，问题才会得到解决。
拥塞控制与流量控制的关系密切，它们之间也存在着一些差别。拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。流量控制往往是指点对点通信量的控制，是个端到端的问题（接收端控制发送端）。
下图中横坐标是提供的负载，代表单位时间内输入给网络的分组数目。纵坐标是吞吐量，代表单位时间内从网络输出的分组数目。
实践证明，拥塞控制是很难设计的，因为它是一个动态的(而不是静态的)问题。
从大的方面看，可以分为 开环控制 和 闭环控制 两种方法：
TCP进行拥塞控制的算法有四种，即慢开始、拥塞避免、快重传和快恢复。
为了集中精力讨论拥塞控制，我们假定：
拥塞控制也叫做基于窗口的拥塞控制。为此，发送方维持一个叫做拥塞窗口cwnd的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则是：只要网络没有出现拥塞，拥塞窗口就可以再增大一些，以便把更多的分组发送出去，这样就可以提高网络的利用率。但只要网络出现拥塞或有可能出现拥塞，就必须把拥塞窗口减小一些，以减少注入到网络中的分组数，以便缓解网络出现的拥塞。
发送方又是如何知道网络发生了拥塞呢？我们知道，当网络发生拥塞时，路由器就要丢弃分组。因此只要发送方没有按时收到应当到达的确认报文，也就是说，只要出现了超时，就可以猜想网络可能出现了拥塞。现在通信线路的传输质量一般都很好，因传输出差错而丢弃分组的概率是很小的(远小于1%)。因此，判断网络拥塞的依据就是出现了超时。
慢开始算法的思路是这样的：当主机开始发送数据时，由于并不清楚网络的负荷情况，所以如果立即把大量数据字节注入到网络，那么就有可能引起网络发生拥塞。因此我们由小到大逐渐增大拥塞窗口数值。
新的RFC5681把初始拥塞窗口cwnd设置为不超过2至4个SMSS（发送方的最大报文段）的数值。慢开始规定，在每收到一个对新的报文段的确认后，可以把拥塞窗口增加最多一个SMSS的数值。
下面用例子说明慢开始算法的原理。在一开始发送方先设置cwnd = 1,发送第一个报文段M1，接收方收到后确认M1。发送 方收到对M1的确认后，把cwnd从1增大到2,于是发送方接着发送M2和M3两个报文 段。接收方收到后发回对M2和M3的确认。发送方每收到一个对新报文段的确认（重传的不算在内）就使发送方的拥塞窗口加1,因此发送方在收到两个确认后，cwnd就从2增大到4,并可发送M4〜M7共4个报文段。
与慢开始算法相辅助的算法是拥塞避免算法。
拥塞避免算法的思路是让拥塞窗口 cwnd缓慢地增大，即每经过一个往返时间RTT就 把发送方的拥塞窗口cwnd加1，而不是像慢开始阶段那样加倍增长。在拥塞避免阶段，拥塞窗口 cwnd按线性规律缓慢增长，比慢开始算法的拥塞窗口增长速率缓慢得多。
为了防止拥塞窗口 cwnd增长过大引起网络拥塞，还需要设置一个慢开始门限ssthresh 状态变量。慢开始门限ssthresh的用法如下：
下面用图片说明慢开始算法和拥塞避免算法相互配合的原理。
其中ssthresh的初始值设置为16，开始时使用慢开始算法，成指数性增长，当到达ssthresh值时，TCP协议预测可能会出现拥塞，所以开始使用避免拥塞算法，成线性增长，当发生超时重传时，立即减小拥塞窗口，重复上述步骤。
但是，有时，个别报文段会在网络中丢失，但实际上网络并未发生拥塞。如果发送方迟迟收 不到确认，就会产生超时，就会误认为网络发生了拥塞。这就导致发送方错误地启动慢开 始，把拥塞窗口cwnd又设置为1,因而降低了传输效率。
釆用快重传算法可以解决上述问题。快重传算法可以让发送方尽早知道发生了个别报文段的丢失。快重传算法首先要求接收方不要等待自己发送数据时才进行捎带确认，而是要立即发送确认，即使收到了失序的报文段也要立即发出对已收到的报文段的重复确认。
下面举一个例子来说明快重传算法的原理。接收方收到了M1和M2后都分别及时发出了确认。现假定接收方没有收到M3但却收到了 M4。本来接收方可以什么都不做。但按照快重传算法，接收方必须立即发送对M2的重复确认，以便让发送方及 早知道接收方没有收到报文段M3。发送方接着发送M5和M6。接收方收到后也仍要再次分别发出对M2的重复确认。这样，发送方共收到了接收方的4个对M2的确认，其中后3个都是重复确认。快重传算法规定，发送方只要一连收到3个重复确认，就知道接收方确实没 有收到报文段M3，因而应当立即进行重传（即“快重传”），这样就不会出现超时，发送方也不就会误认为出现了网络拥塞。
快恢复算法与快重传算法配合使用，当使用快重传算法发现是由于数据丢失而引起的超时（不是网络拥塞引起的），就使用快恢复算法，此时发送方调整门限值ssthresh=cwnd/2，同时设置拥塞窗口cwnd=ssthresh，并开始执行拥塞避免算法。
慢开始、拥塞避免、快重传和快恢复这四种算法相辅相成，构成了TCP的拥塞控制。
网络层的策略对TCP拥塞控制影响最大的就是路由器的分组丢弃策略。在最简单的情 况下，路由器的队列通常都是按照“先进先出”的规则处理到来的分组。
由于队列长度总是有限的，因此当队列已满时，以后再到达的所有分组(如果能够继续排队，这些分组都将排在队列的尾部)将都被丢弃。这就叫做尾部丢弃策略。
路由器的尾部丢弃往往会导致一连串分组的丢失，这就使发送方出现超时重传，使 TCP进入拥塞控制的慢开始状态，结果使TCP连接的发送方突然把数据的发送速率降低到 很小的数值。更为严重的是，在网络中通常有很多的TCP连接(它们有不同的源点和终 点)，这些连接中的报文段通常是复用在网络层的IP数据报中传送。在这种情况下，若发生了路由器中的尾部丢弃，就可能会同时影响到很多条TCP连接，结果使这许多TCP连接在同一时间突然都进入到慢开始状态。这在TCP的术语中称为全局同步。
为了避免发生网络中的全局同步现象，可以使用主动队列管理AQM。
所谓“主动”就是不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面到达的分组。这样就太被动了。应当在队列长度达到某个值得警惕的数值时 (即当网络拥塞有了某些拥塞征兆时)，就主动丢弃到达的分组。这样就提醒了发送方放慢发送的速率，因而有可能使网络拥塞的程度减轻，甚至不出现网络拥塞。
TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次面向连接的通信中必不可少的过程。因此，运输连接就有三个阶段，即：连接建立、数据传送和连接释放。运输连接的管理就是使运输连接的建立和释放都能正常地进行。
在TCP连接建立过程中要解决以下三个问题：
TCP连接的建立釆用客户服务器方式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。
TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段。
下面举一个例子来说明TCP建立连接的过程。假定主机A运行的是TCP客户程序，而B运行TCP服务器程序。最初两端的TCP进程都处于CLOSED（关闭）状态。图中在主机下面的方框分别是TCP进程所处的状态。请注意，在本例中，A主动打开连接，而B被动打开连接。
一开始，B的TCP服务器进程先创建传输控制块TCB，准备接受客户进程的连接请求。然后服务器进
尽力详解：计网基础 ·运输层
文章目录
摘要
运输层是整个网络体系结构中的关键层次之一，本篇主要围绕以下几个主题展开：
1、运输层的作用
2、UDP
3、TCP
4、在不可靠的网络上实现可靠传输的工作原理
5、TCP滑动窗口、流量控制、拥塞控制和连接管理
前情提要：
我问你这篇保熟不？！ – 做服务端开发，不懂网络层，真的可以吗？
为什么需要运输层？
运输层向它上面的应用层提供通信服务，属于面向通信部分的最高层，同时也是用户功能中的最底层。
看图说话：
从IP层来说，通信的两端是两台主机。严格地讲，两台主机进行通信就是两台主机中的应用进程互相通信。
从运输层的角度看，通信的真正端点并不是主机而是主机中的进程。
可以看到，每台主机中都有不少于一个的进程，主机A中的AP1、AP2要和主机B中的AP3、AP4进行通信，却共用一个传输层，这说明传输层有很重要的功能：复用&分用。
复用是指在发送方不同的应用进程都可以使用同一个运输层协议传送数据。
分用时指接收方的运输层在去掉报文的首部后能够把这些数据正确交付目的应用进程。
总结一下：网络层为主机之间提供逻辑通信，运输层为应用进程之间提供端到端的逻辑通信。
此外，运输层还向高层用户屏蔽了下面网络核心的细节。
用户数据报协议UDP
用户数据报协议UDP只在IP的数据服务之上增加了很少一点功能，这就是复用和分用的功能以及差错检测功能。
1.UDP是无连接的。
2.UDP不保证可靠交付。
3.UDP是面向报文的，发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。
应用层交给UDP多长的报文，UDP就发送多少，因此应用程序必须选择长度合适的报文，
若报文太长，UDP把它交给IP层后，IP层传送时可能要进行分片，降低IP层效率。
4.UDP没有拥塞控制。
5.UDP首部开销很小，只有8个字节。
6.UDP支持一对一、一对多、多对一、多对多的交互通信。
所以，UDP将速度点满，但是稳定性就比较缺乏了。
UDP首部
伪首部仅仅是为了计算检验和。
（好可怜）
如果接收方UDP发现端口号不正确，就丢弃该报文，并由网际控制协议ICMP发送“端口不可达”差错报文给发送方。
传输控制协议TCP
TCP 是面向连接的运输层协议.
每一条 TCP 连接只能由两个端点(endpoint), 每一条 TCP 连接只能是点对点的.
TCP 提供可靠交付的服务. 通过 TCP 连接传送的数据, 无差错, 不丢失, 不重复, 并且能够按序到达.
TCP 提供全双工通信. TCP 连接的两端都设有发送缓存和接收缓存, 用来临时存放双向通信的数据.
面向字节流. TCP 中的流(stream)指的是流入到进程或从进程流出的字节序列.
TCP的连接是逻辑连接，虚拟连接，不是物理连接。
TCP 连接的端点叫做套接字 (socket)，套接字=IP：port。
停止等待协议
其实这点已经是初见端倪了。前面说，UDP以稳定性换速度，那么TCP作为另一个传输协议，很自然的能想到其为稳定性放弃了一定的速度。
理想的传输有以下两个特点：
1、传输信道不产生差错
2、不管发送方以多块的速度发送数据，接收方总来得及处理收到的数据
很显然，目前不现实。
这里先讲一下停止等待协议：
每发完一个分组就停下来等待对方的确认，收到确认后再发送下一个分组。
接收端接收分组检测出现了差错, 就丢弃分组, 其它什么也不做.。发送端超过了一段时间没有收到确认信息, 即认为发送的分组丢失了, 因而重传前面发送过的分组, 叫超时重传。
所以，发送端必须暂时保留已发送的分组的副本, 只有收到相应的确认后才能清除保留的分组副本; 分组和确认分组必须进行编号, 这样才能明确是哪一个发送出去的分组收到了确认, 而哪一个分组还没有收到确认; 超时计时器设置的重传时间应当比数据在分组传输的平均往返时间更长一些（网络时延）。
这里面细节很多，会引出很多东西。
确认丢失和确认迟到：
确认丢失: 接收端发送的确认丢失了。 这时发送端需要重传数据分组, 接收端又会收到这个分组, 接收端应该丢弃这个重复的分组, 并再次向发送端发送确认, 不能认为发送过确认就不再发送确认.
确认迟到: 接收端发送的确认迟到了, 接收端会收到重复的确认, 然后丢弃重复的确认. 接收端收到重复的分组, 丢弃重复的分组, 并重传确认分组.
利用确认和重传机制, 可以在不可靠的传输网络上实现可靠的通信, 上面这种可靠传输称为自动重传请求 ARQ(Automatic Repeat Request)
概念讲的差不多了，该上算法了。
滑动窗口
TCP 的滑动窗口是以字节为单位的。
现假定 A 收到了 B 发来的确认报文段，其中窗口是 20 字节，而确认号是 31（这表明 B 期望收到的下一个序号是 31，而序号 30 为止的数据已经收到了）。
在没有收到B的确认的情况下，A可以连续把窗口内的数据都发送出去，凡是已经发送过的数据，在未收到确认前都必须暂时保留，以便在超时重传的时候使用。
显然，窗口越大，发送方就可以在收到对方确认之前连续发送更多的数据，因而可能获得更高的传输效率。
此外，发送方的窗口一定不能大于接收方的窗口大小，发送方的窗口大小还要受到当时网络拥塞程度的制约。
流量控制
如果发送方把数据发送得过快，接收方可能会来不及接收，这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP连接上实现对发送方的流量控制。
设A向B发送数据。在连接建立时，B告诉了A：“我的接收窗口是rwnd = 400”（这里的rwnd表示receiver window）。因此，发送方的发送窗口不能超过接收方给出的接收窗口的数值。
拥塞控制
拥塞控制与网络的拥堵情况相关联，而流量控制与接收方的缓存状态相关联。
了解TCP三次握手的朋友都知道，两台主机在传输数据包的时候，如果发送方迟迟没有收到接收方反馈的ACK，那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。
然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，发送的数据包被堵在了半路，迟迟没有到达。这个时候发送方误认为是发生了丢包情况，会重新传输这个数据包。
结果就是不仅浪费了信道资源，还会使网络更加拥塞。因此，我们需要进行拥塞控制。
探测网络拥塞情况
无论如何，在探测的过程中都会出现瓶颈，或者说，类似于天花板了。
为了平衡各方面效率，使用以下方式：
前期指数增长，到达阈值之后，就以一个一个线性的速度来增长。我们也把指数增长阶段称之为慢启动，线性增长阶段称之为拥塞避免。
超时 == 拥塞？
有可能是因为某个数据包出现了丢失或者损害了，导致了这个数据包超时事件发生了
为了防止这种情况，我们是通过冗余 ACK来处理的。我们都知道，数据包是有序号的，如果A给B发送M1, M2, M3, M4, M5…N个数据包，如果B收到了M1, M2, M4…却始终没有收到M3，这个时候就会重复确认M2，意在告诉A,M3还没收到，可能是丢失
我们也把这种情况称之为快速恢复。
三次握手与四次挥手
重要字段
先别管啥握手挥手的，这几个字段先背一下。
1）序号（sequence number）：Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记。
2）确认号（acknowledgement number）：Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1。
3）标志位（Flags）：共6个，即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下：
URG：紧急指针（urgent pointer）有效。
ACK：确认序号有效。（这个）
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。
SYN：发起一个新连接。（这个）
FIN：释放一个连接。（这个）
三次握手
所谓的三次握手即TCP连接的建立。这个连接必须是一方主动打开，另一方被动打开的。以下为客户端主动发起连接的图解：
四次挥手
为什么握手只要三次，挥手要四次？
TCP释放连接时之所以需要“四次挥手”,是因为FIN释放连接报文与ACK确认接收报文是分别由第二次和第三次"握手"传输的。
为何建立连接时一起传输，释放连接时却要分开传输？
建立连接时，被动方服务器端结束CLOSED阶段进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。
为什么客户端在TIME-WAIT阶段要等2MSL?
为的是确认服务器端是否收到客户端发出的ACK确认报文
当客户端发出最后的ACK确认报文时，并不能确定服务器端能够收到该段报文。所以客户端在发送完ACK确认报文之后，会设置一个时长为2MSL的计时器。MSL指的是Maximum Segment Lifetime：一段TCP报文在传输过程中的最大生命周期。2MSL即是服务器端发出为FIN报文和客户端发出的ACK确认报文所能保持有效的最大时长。
服务器端在1MSL内没有收到客户端发出的ACK确认报文，就会再次向客户端发出FIN报文；
如果客户端在2MSL内，再次收到了来自服务器端的FIN报文，说明服务器端由于各种原因没有接收到客户端发出的ACK确认报文。客户端再次向服务器端发出ACK确认报文，计时器重置，重新开始2MSL的计时；否则客户端在2MSL内没有再次收到来自服务器端的FIN报文，说明服务器端正常接收了ACK确认报文，客户端可以进入CLOSED阶段，完成“四次挥手”。
所以，客户端要经历时长为2SML的TIME-WAIT阶段；这也是为什么客户端比服务器端晚进入CLOSED阶段的原因。
以上是关于计网：运输层的主要内容，如果未能解决你的问题，请参考以下文章