计网知识总结 之 运输层

1. 知识回顾

• 物理层完成了数据转换为信号，使其能够在信道上进行传输；

• 数据链路层实现了点对点信道和广播通信信道的数据传输；

• 网络层通过路由器的分组与转发就能完成数据在整个网络间的数据传输。

 除了这三层，在五层结构还有两层——运输层以及最高层的应用层，现在我们要探讨的是次高层——运输层。运输层是面向通信部分的最高层，也是用户功能中的最低层。

2. 概念

 在运输层中，通信的真正端点并不是主机，而是主机中的进程，是这台主机中的一个进程和另一台主机中的一个进程在交换通信，所以运输层是为相互通信的应用进程提供逻辑通信。因为在一台主机中经常有多个应用进程同时分别和另一台主机中的多个应用进程通信，所以运输层还有一个很重要的功能—— 复用 (multiplexing)和分用 (demultiplexing)，这里的复用是指不同的应用进程可以使用同一个运输层协议，分用是指接收方运输层能正确把数据交付给目的进程。运输层也会对收到的报文进行差错检测。

总结来说，运输层的作用是：

• 为相互通信的应用进程提供逻辑通信
• 复用和分用
• 对收到的数据进行差错检测

3. 端口

 运输层要为两个进程之间提供服务，首先要解决如何标记正在通信的两个进程这个问题。网络层中利用IP地址来标识每一台设备，运输层这里则是利用了 端口 来标记每一个进程。这里的端口是指软件端口，是由进程向操作系统申请，操作系统给端口分配的一个地址。由于端口是由操作系统分配的，所以端口号只具有本地意义，不同的计算机中，相同的端口号是没有关联的。

端口号分为为：

• 服务器端使用的端口号
  • 熟知端口号：数值一般为 0~1023
  • 登记端口号：数值为 1024~49151，为没有熟知端口号的应用程序使用的。使用这个范围的端口号必须在 IANA 登记，以防止重复
• 客户端上使用的端口号/短暂端口号
  • 数值为 49152~65535，留给客户进程选择暂时使用
  • 当服务器进程收到客户进程的报文时，就知道了客户进程所使用的动态端口号。通信结束后，这个端口号可供其他客户进程以后使用

4. 运输协议

 根据应用程序的不同需求，运输层需要有两种不同的运输协议，即面向连接的 TCP 和无连接的 UDP 。运输层为上层提供的逻辑信道因运输层使用的不同协议而有很大的差别：

• 当运输层采用面向连接的 TCP 协议时，尽管下面的网络是不可靠的（只提供尽最大努力服务），但这种逻辑通信信道就相当于一条全双工的可靠信道
• 当运输层采用无连接的 UDP 协议时，这种逻辑通信信道是一条不可靠信道。

两个协议具体的区别如下：

特点	UDP	TCP
1	UDP使用前不需要建立连接	TCP是面向连接的服务，在正式发送数据前要先建立可靠连接（三次握手），发送完数据后要断开连接（四次握手）
2	UDP是面向报文的	TCP是面向字节流的
3	UDP没有拥塞控制	TCP有拥塞控制
4	UDP支持一对一、一对多、多对多的交互通信	TCP支持一对一的交互通信
5	UDP首部开销小	TCP首部开销大

4.1 UDP

 UDP只是在IP数据报上添加了复用、分用和差错检测功能，解释一下UDP的一些特点

• UDP使用前不需要建立连接，所以减少了开销和发送数据之前的时延

• UDP是 面向报文 的，UDP对应用层交下来的报文，既不合并，也不拆分，添加首部后就向下交付给网络层。

  • 如果报文太长，UDP把它交给网络层后，网络层会在传输时进行分片，这会降低网络层的的效率
  • 如果报文太短，UDP把它交给网络层后，会使IP数据报的首部相对长度大，这也降低了网络层的工作效率
    

• UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低

• UDP首部开销小，只有8个字节，比TCP的20个字节的首部要短

• UDP支持一对一、一对多、多对多的交互通信

UDP用户数据报格式如下：

 UDP用户数据报如果在传输过程中出错，会直接丢掉，以及接收UDP发现收到的报文中的目的端口不正确，也会直接丢弃报文，并且由网际控制报文协议ICMP发送“端口不可达”差错报文给发送方。

4.2 TCP

TCP协议比较复杂，下面先来介绍TCP的主要特点：

• TCP 是面向连接的运输层协议。

   应用程序在使用TCP协议之前，必须通过 三次握手 先建立TCP连接。在传送数据完毕后，必须利用 四次握手 释放已经建立的TCP连接。

• 每一条 TCP 连接只能有两个端点 (endpoint)，每一条 TCP 连接只能是 点对点 的（一对一）。

• TCP 提供可靠交付的服务。通过 TCP 连接传送的数据，无差错、不丢失、不重复，并且按序到达。可靠传输是由TCP层提供的。

• TPC 提供全双工通信。TCP允许双方的应用进程在任何时候发送数据。

• TCP 面向字节流。

  TCP 中的“流”(stream)指的是流入或流出进程的 字节序列。

   “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。

   TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小的关系，但接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。

• TCP 连接是一条虚连接而不是一条真正的物理连接。

• TCP 对应用进程一次把多长的报文发送到TCP 的缓存中是不关心的。

• TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）。

• TCP 可把太长的数据块划分短一些再传送，也可等待积累有足够多的字节后再构成报文段发送出去。

TCP报文格式如下：

TCP是面向字节流的，所以在一个TCP连接中传送的字节流中每个字节都是按顺序编号，TCP首部中的序号九对应本报文段所发送的数据的第一个字节的序号。

4.3 可靠传输协议

 TCP实现的是可靠传输，因为运输层以下的提供的是不可靠传输（高质量 ≠ 可靠），所以要采取一定的措施使得两个运输层之间的通信可靠。可靠的传输条件有以下两个特点：

1. 传输信道不产生差错
2. 不管发送方以多快的速度发送数据，接收方总是能来得及处理接收到的数据（流量控制）

 为了使信道向这可靠的传输信道靠拢，我们使用可靠的传输协议，这些协议的作用是：当出现差错时让发送方重传出现差错的数据，同时在接收方来不及处理收到的数据时，及时告诉接收方适当降低发送数据的速度。下面列举了几个协议可以实现这些个功能。

可靠传输协议我之前也有在数据链路层那一部分的知识回顾中提及过，下面再来具体地讲解一下。

常见的可靠传输协议有三种：

• 停止等待协议
• 连续 ARQ 协议
• 滑动窗口机制

4.3.1 停止等待协议

 停止等待协议（stop-and-wati），基本原理就是说每发送一个分组，必须要停下来等待，等接收方确认后才可继续发送下一个分组。如果没收到确认，就只能超时重传，如图：A为发送方，B为接收方

• 发送方A给接收方B发送数据，开启超时计时器，同时会暂时保存已发送的分组的副本。接收方B收到报文后，通过差错检验检测报文，若报文无错误，就向发送方A发送确定报文。
• 当B接收到错误的报文，就会将错误报文丢弃，除此之外什么都不做。发送方A在超时计时器过期后都没有接收到接收方B发送的确定报文，会重发前面发送的分组，这个就叫 超时重传。

停止等待协议的优点是很显而易见的，它十分简单。缺点也是很明显，它的信道利用率太低。

4.3.2 连续 ARQ 协议

 连续 ARQ 协议就是停止等待协议的改进，它解决了信道利用率低的问题，增大了吞吐量。

 它是指发送方维护着一个窗口，这个窗口中不止一个分组，有好几个分组，窗口的大小是由接收方返回的win值决定的，所以窗口的大小是动态变化的。只要在窗口中的分组都可以被发送，这就使得TCP一次不是只发送一个分组了，从而大大提高了信道的利用率，并且它采用 累积确认 的方式，对于按序到达的最后一个分组发送确认。

4.3.3 滑动窗口机制

 滑动窗口机制是由连续 ARQ 协议发展过来的，与连续ARQ协议不同点在于：

• 滑动窗口机制中，除了发送方具有一个发送窗口，接收方也有一个接收窗口。
• 滑动窗口机制中，发送窗口和接收窗口都是可变长度的，但是发送窗口一定不能超过接收窗口数值。

下图是一个滑动窗口应用的实例：

由图可知：

• 发送窗口的缓存中存放了
  • 允许发送但还没发送的数据
  • 已经发送但还没有收到确认信息的数据
• 接收窗口的缓存中存放了
  • 按序到达但还没有接受的数据
  • 未按序到达的数据

 发送窗口的位置由窗口前沿和后沿的位置决定的。发送窗口接收到新的确定且接收窗口规模也不变的话，发送窗口会整体前移；发送窗口接收到新的确定但接收窗口规模缩小，此时发送窗口前沿不变，后沿会前移；发送窗口没有接受到新的确认的话，就会保持窗口大小不变，如果超时计数器失效的话，会重传当前发送窗口的数据，直至接收到接收窗口的回应。

 TCP使用滑动窗口机制实现流量控制！

4.4 TCP的拥塞控制

 何为拥塞？按照我的理解，拥塞就是网络中有路由器超负荷工作，丢弃大量的数据包，多台主机超时重发，导致的网络性能变坏、网络拥堵。

 拥塞控制就是指防止过多的数据注入网络中，这样可以使网络中的路由器或者链路不致负载。

拥塞控制 VS 流量控制：

• 流量控制是指点到点通信量的控制，是个端到端的问题
• 拥塞控制是一个全局性的过程，涉及到所有主机、路由，以及与降低网络传输性能有关的所有因素

TCP的拥塞控制的算法有四种：

1. 慢开始
2. 拥塞避免
3. 快重传
4. 快恢复

 这四个算法的核心思想就是：网络状况好的时候就多传一点数据，网络情况差的时间就少传一点数据。但现在问题又来了，如何判断网络状况是好还是差呢？网络状况是动态的，这导致判断网络状况很难。在这些个算法中，利用了一些指标去判断网络状况，例如超时重传的分组数、平均分组时延等。算法具体内容请看书本，或者参考相关的博客。

4.5 TCP的运输连接管理

 TCP是面向连接的协议，在数据传输前要先建立连接，在数据传输结束后要断开连接。TCP建立连接的方法是通过三次握手，断开连接的方法是通过四次握手。握手其实就是指相互之间传送数据包，下面我们来了解一下三次握手和四次握手。

4.5.1 三次握手

三次握手的示意图如下：

 主动 发起连接建立的应用进程叫做客户，而 被动 等待连接建立的应用进程叫做服务器。三次握手的过程大致如下：

1. 首先客户端发送连接请求报文
2. 服务器接受连接后回复 ACK 报文，并为这次连接分配资源
3. 客户端接收到 ACK 报文后也向服务器端发生 ACK 报文，并分配资源，这样 TCP 连接就建立了

 理论上来讲，服务器给客户端回复 ACK 报文后，客户端就可以直接给服务器发送数据了，那为什么还需要第三次握手？

 如果只有两次握手的话，可能会出现这样子的问题：如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

 三次握手，每一次握手都有对应的意义：

• 第一次握手：客户端发送报文，服务端接受到了，服务器端可以确保客户端的发送能力、服务端的接收能力是正常的。
• 第二次握手：服务端发送报文，客户端收到了，客户端可以确保服务端的接收、发送能力，客户端的接收、发送能力是正常的。但是此时服务器并不能确认客户端的接收能力是否正常。
• 第三次握手：客户端发送报文，服务器端收到了，服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

4.5.2 四次握手

 建立一个连接需要三次握手，而终止一个连接要经过四次挥手（也有将四次挥手叫做四次握手的）。这由TCP的半关闭（half-close）造成的。所谓的半关闭，其实就是TCP提供了连接的一端在结束它的发送后还能接收来自另一端数据的能力。四次握手的示意图如下：

• 第一次握手：

   客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。

• 第二次握手：

   服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于 半关闭 状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。

    客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。

• 第三次握手：

   服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。

• 第四次握手：

   客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。

   服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么建立连接是三次握手，而断开连接时需要四次握手呢？

• 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，服务器的ACK和FIN一般都会分开发送，从而导致多了一次。
  TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

为什么建立连接是三次握手，而断开连接时需要四次握手呢？

• 建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
• 而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以服务器可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，服务器的ACK和FIN一般都会分开发送，从而导致多了一次。