计算机网络之传输层

最新推荐文章于 2024-09-02 15:19:35 发布

_清欢

最新推荐文章于 2024-09-02 15:19:35 发布

阅读量228

点赞数

文章标签： TCP UDP 三次握手四次挥手滑动窗口

本文链接：https://blog.csdn.net/qq_42191317/article/details/97615538

版权

简介

从通信和信息处理的角度看，运输层向它上面的应用层提供通信服务，它属于面向通信部分的最高层，同时也是用户功能中的最底层。通信真正的端点并不是主机，而是主机中的进程。

运输层具有复用和分用的功能。

复用是指在发送方不同的应用程序中都可以使用同一个运输层协议传输数据。
分用是指接收方的运输层在剥去报文的首部后能够把这些数据正确交付目的应用进程。

运输层提供应用进程间的逻辑通信。

逻辑通信是指：从应用层来看，只要应用层把报文交给下面的传输层，传输层就可以把这个报文传达到对方的传输层，好像这种通信就是沿水平方向直接传送数据。但是事实上，这两个传输层之间并没有一条水平方向的物理连接。

网络层为主机之间提供逻辑通信，而运输层为应用进程之间提供端到端的逻辑通信。

运输层还会对收到的报文进行差错检测。

根据应用的不同需求，运输层需要两种不同的运输协议：面向连接的TCP和无连接的UDP

应用层常用协议对应的传输层协议：

UDP

UDP概述

UDP（User Datagram Protocol）：用户数据报协议

按照OSI术语，两个对等运输实体通信时传送的数据单位叫运输协议数据单元TPDU（Transport Protocol Data Unit）。在TCP/IP中，根据所使用的协议，分别称之为TCP报文段和UDP用户数据报。

UDP在传送数据之前不需要先建立连接，远程主机的运输层在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下UDP却是最有效的工作方式。

UDP主要特点：

UDP是无连接的，即发送数据之前不需要建立连接，因此减少了开销和发送数据之前的时延
UDP使用尽最大努力交付，即不可保证可靠交付，因此主机不需要维持复杂的连接状态表
UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层，UDP对应用层交下来的报文既不合并，也不拆分，而是保留这些报文的边界。这就是说，应用层交给UDP的报文多长，UDP都照样发送，UDP一次交付一个完整的报文，因此应用程序必须选择合适大小的报文
UDP没有拥塞控制，因此网络出现的拥塞不会使源主机的发送速率降低，这对某些实时应用很重要。在很多实时应用（如IP电话，实时视频会议等）要求源主机以恒定的速率发送数据，并允许在网络发生阻塞时丢失一些数据，但却不允许数据有太大的时延。UDP刚好合适
UDP支持一对一、一对多、多对一和多对多的交互通信
UDP的首部开销小，比TCP的20个字节短很多

虽然某些实时应用需要使用没有拥塞控制的UDP，但当很多源主机同时都向网络发送高速率的实时视频流时，网络就有可能发生拥塞，结果大家都无法正常接收。因此，不使用拥塞控制的UDP可能会引起网络严重的拥塞问题。

还有一些使用UDP的实时应用，需要对UDP的不可靠的传输进行适当地改进，以减少数据的丢失。常用手段有：采用向前纠错或重传已丢失的报文。

UDP报文首部格式

用户数据报UDP有两个字段：数据字段和首部字段。

首部字段只有 8 个字节，包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。

源端口：源端口号，在需要对方回信时选用，不需要时可用全0
目的端口：目的端口号，在终点交付报文时必须使用
长度：UDP用户数据报的长度，最小值为8（仅有首部）
检验和：检测UDP用户数据报在传输中是否有错，有错就丢弃

TCP

TCP概述

TCP（Transmission Controller Protocol）：传输控制协议

TCP的主要特点：

TCP是面向连接的运输层协议。在传送数据之间必须先建立连接，完毕后，必须释放建立的连接
每一条TCP连接只能有两个端点。TCP是点对点传输的
TCP提供可靠交付的服务。通过TCP连接传送的数据，无差错，不丢失，不重复并且有序到达
TCP提供全双工服务。TCP允许通信双方的应用程序在任何时候都可以发送数据，TCP连接两端都设有发送缓存和接受缓存，用来临时存放双向通信的数据
面向字节流。TCP中的"流'指的是流入到进程或从进程流出的字节序列。字节流的含义是：虽然应用程序和TCP的交互是一次一个数据块（大小不等），但TCP把应用程序交下来的数据仅仅看做是一连串的无结构的字节流TCP并不知道传输的字节流的具体含义

TCP和UDP在发送报文时所采用的的方式完全不同。TCP不关心应用程序一次把多长的报文发送到TCP的缓存中，而是根据接收方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节。

TCP把连接作为最基本的抽象。TCP有两个连接的端点，称之为套接字（Socket）。具体就是IP地址和端口号的拼接。

TCP报文首部格式

TCP虽然是面向字节流的，但TCP传送的数据单元却是报文段。一个TCP报文段分为首部和数据两部分，首部如下所示。

序号：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
窗口：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。

可靠传输的原理

理想的传输条件有以下两个特点：

传输信道不产生差错
不管发送方以多快的速度发送数据，接收方总是来得及处理接收到的数据

再这样理想的传输条件下，不需要采取任何措施都可以实现可靠传输。

然而实际的网络都不具备以上两个理想条件。因此我们采用一些可靠传输协议，当出现差错时让发送发重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告知发送方适当降低发送数据的速率。这样就可以实现可靠传输。

停止等待协议

停止等待协议就是发送方每发送完一个分组就停止发送，等待对方确认。在收到确认之后再发送下一个分组。

无差错情况

无差错时，A发送数据给B，然后A停止发送，等待B确认。B接受数据后，就向A发送确认，A收到确认后就可以开始发送下一组数据。

出现差错

A只要超过一段时间仍然没有收到确认，就认为刚才发送的分组丢失了，因而重传前面发送过的分组。这就是超时重传。要实现超时重传，就要在每发送完一个分组后设置一个超时计时器。

确认丢失和确认迟到

如果出现网路问题，B没有收到A发送的数据，则B也不会发送确认，A在指定时间内没有收到确认，就是重新发送。

如果出现网络延迟，B在指定时间之后收到了数据，此时A已经重新发送了一次，那么第二次B收到的数据会丢弃。

通过这种确认和重传机制，我们就可以在不可靠的网络上实现可靠的通信。这种机制常称为自动重传请求ARQ（Automatic Repeat reQuest）。

停止等待协议的优点是实现简单，但缺点是信道利用率太低。

为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输。流水线传输就是发送方可以连续发送多个分组，不必发完每个分组就停下来等待对方确认。这样可使信道一直有数据传输。

连续ARQ协议

连续ARQ协议维持一个发送方窗口，可以发送窗口中的多个分组，而不需要等待对方确认，接收方采用累积确认的方式，在收到几个分组后，按序号最后到达的一个分组发送确认。

优点：容易实现，即使确认丢失也不必重传，解决了停止等待协议信道利用率低的问题。

缺点：不能向发送方反映出接收方已经正确接收到的所有分组的信息。

例如发送方发送5个分组，而接收方中间的第三个分组丢失了，这时接收方只能给前两个分组发送确认，后三个分组都需要重传。

可靠传输的实现

以字节为单位的滑动窗口

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。

发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。

接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

超时重传时间选择

TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段，这种重传机制很简单，但重传时间选择确实TCP最复杂的问题之一。如果把超时重传时间设置的太小，就会引起不必要的重传，使网络负荷增大。设置太大，又会使网络的空闲时间增大，降低传输效率。

TCP采用了一种自适应算法，它记录一个报文段发出时间以及收到确认的时间。两时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间RTTS。RTTS计算如下：

其中，0 ≤ a ＜ 1，RTTs 随着 a 的增加更容易受到 RTT 的影响。

超时时间 RTO 应该略大于 RTTs，TCP 使用的超时时间计算如下：

选择确认SACK

若收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？答案是可以的，选择确认就是一种可行的方法。

选择确认会接收发送方发来的所有滑动窗口内的数据，然后返回这些数据的边界，让发送方将缺少的数据重传。

需要注意的是，要使用SACK，需要在建立TCP连接时设置允许SACK。

TCP的流量控制

流量控制是为了控制发送方发送速率，保证接收方来得及接收。

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

TCP的拥塞控制

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。

发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。

为了便于讨论，做如下假设：

接收方有足够大的接收缓存，因此不会发生流量控制；
虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段。

1. 慢开始与拥塞避免

发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...

注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。

如果出现了超时，则令 ssthresh = cwnd / 2，cwnd为1，然后重新执行慢开始。

2. 快重传与快恢复

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

三次握手

假设 A 为客户端，B 为服务器端。

首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。
A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。（客户端进入SYNSENT同步发送状态）
B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。（服务端进入SYNRCVD同步接收状态）
A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。（客户端进入ESTABLISHED已建立连接状态）
B 收到 A 的确认后，连接建立。（服务端进入ESTABLISHED已建立连接状态）

三次握手的原因

第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。