计算机网络自顶向下方法第3章-传输层 (Transport Layer).1

3.1 概述和运输层服务

　　运输层协议为运行在不同主机上的应用进程之间提供了逻辑通信(logic communication)功能。

　　3.1.1 运输层和网络层的关系

　　网络层提供了主机之间的逻辑通信，而运输层为运行在不同的主机上的进程提供了逻辑通信。

　　3.1.2 因特网运输层概述

　　Internet上提供TCP(传输控制协议) 和 UDP(用户数据报协议)两种

3.2 多路复用和多路分解

　　一个进程有一个或多个套接字（socket），它相当于从网络向进程传递数据和从进程向网络传递数据的门户。

接收端将运输层报文段中的数据交付到正确的套接字（即不同的进程）的工作称为多路分解（demultiplexing）。
而在源主机中从不同套接字中收集数据块，并为每个数据块封装上头部信息从而生成报文段，然后将报文段传递到网络层，所有这些工作称为多路复用（multiplexing）。

　　1.无连接的多路复用与多路分解

　　在运输层，无连接的网络传输是通过UDP来实现的，一个UDP套接字是由一个含有目的IP地址和目的端口号的一个二元组来全面标识的。

　　主机收到UDP段后检查段中的目的端口号，并将UDP段导向绑定在该端口号的Socket，因此如果两个UDP报文段有不同的源IP地址/端口号，却有相同的目的端口号，那么两个报文段将通过相同的目的套接字被定向到相同的目的进程。

　　2.面向连接的多路复用与多路分解

　　在运输层中面向连接的网络传输多使用TCP，而TCP套接字和UDP套接字之间有一个细微的差别，TCP套接字是由一个四元组（源IP地址、源端口号，目的IP地址，目的端口号）来标识的。当一个TCP报文段从网络到达一台主机时，主机会使用全部4个值来将报文段定向，即多路分解到相应的套接字。

　　与UDP不同的是，两个具有不同源IP或源端口号的到达的TCP报文段将被重定向到两个不同的套接字。

　　3.Web服务器与TCP

　　当今的高性能Web服务器通常只使用一个进程，但是为每个新的客户连接创建一个具有新连接套接字的新线程。

3.3 无连接运输 : UDP

　　UDP的优势

应用层能更好发控制要发送的数据和发送时间。
无须建立连接。
无连接状态。
分组首部开销小。

　　3.3.1 UDP报文段结构

　　UDP报文段结构由RFC 768定义，UDP首部只有4个字段，每个字段由两个字节组成。　　

源端口号：本机（客户端）的应用程序的套接字所对应的端口号，服务器端可利用此端口号向客户端发送数据。
目的端口号：服务端上的应用进程的套接字所对应的端口号，例如HTTP服务器的80端口。
长度：指明了首部和数据部分的UDP报文段的总长度，单位为字节，即首部+数据。
检验和：提供了差错检测功能，即检验和用于确定当UDP报文段从源到达目的时，其中的比特是否发生了改变。

　　3.3.2 UDP 检验和

发送方
- 将段的内容视为16-bit整数
- 校验和计算：计算所有整数的和，进位加在和的后面，将得到的值按位求反，得到校验和
- 发送方将校验和放入校验和字段
接收方
- 计算所得到段的检验和，并将其余检验和字段进行比较。
- 如果不相等，则检验出错误，但若相等也可能有错误。

3.4 可靠数据传输原理

　　3.4.1 构造可靠数据传输协议

　　1.经完全可靠信道的可靠数据传输 :rdt 1.0

　　有限状态机(FSM) 可以表示有限个状态及在这些状态之间的转移和动作等行为的数学模型，下图即表示发送方和接收方的有限状态机，底层信道是完全可靠的，发送方和接收方有各自的FSM，每个FSM都只有一个状态。

　　（图解：FSM描述中的箭头指示了协议从一个状态变迁到另一个状态。引起变迁的事件显示在横线的上方，事件发生时所采用的运动显示在横线的下方。FSM的初始状态用虚线表示。）

因为信道可靠，接收方也不需要提供任何反馈信息给发送方
假定了接收方接收数据的速率能够与发送方发送数据的速率一样快，所以接收方也没有必要请求发送方慢一点发送。

　　2.经具有比特差错信道的可靠数据传输: rdt2.0

　　下图为rdt 2.0 的有限状态机描述图，该数据传输协议（自动重传请求协议）采用了差错检测、肯定确认与否定确认。

在发送端左边的初始状态中，发送端协议正等待来自较高层传下来的数据。当触发 rdt_send(data) 事件时：
- 通过 sndpkt = make_pkt(data, checksum) 产生一个包含待发送数据且带有校验和的分组
- 然后将该分组通过 udt_send(sndpkt) 发送到信道中
执行完上述的两个动作后，发送端的状态变迁为“等待接收接收端的 ACK 或 NAK 分组”。即转变为右侧状态，接下来根据接收端的响应不同会有不同的变迁方案：
- 如果收到了一个 ACK 分组（rdt_rcv(rcvpkt) && isACK(rcvpkt)），那么发送方知道最近一个分组已经被正确接收，因此协议返回左边状态，继续等待下一次由较高层传下来的数据发送请求
- 如果收到了一个 NAK 分组（rdt_rcv(rcvpkt) && isNAK(rcvpkt)），那么发送端知道接收端接收到的分组是受损的，所以调用 udt_send(sndpkt) 重新发送该分组，然后状态不变，继续等待接收接收端的 ACK 或 NAK 分组。

　　在上述协议中，当发送方处于等待ACK或NAK状态时，它不能从上层获得更多数据。这样子的协议被称为停等协议 (stop-and-wait)。

rdt 2.0 的接收端仍然只有一个状态。状态变迁取决于收到的分组是否受损，有两种方式：
- 如果收到的分组受损，即 rdt_rcv(rcvpkt) && corrupt(rcvpkt)，则返回 NAK 分组
- 如果收到的分组完好，即 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)，则返回 ACK 分组
处理完后仍然返回自身这个状态，继续等待下一次从底层接收分组并处理。

　　3.经具有比特差错的丢包信道的可靠数据传输 rdt 3.0

　　在现实的网络环境中，除了比特受损外，底层信道还会丢包；有很多可能的方法可以解决丢包问题，这里我们让发送方负责检测和恢复丢包工作。

　　假定发送端传输一个数据分组，该分组发生丢失或者接收端对该分组的 ACK 发生了丢失。在这两种情况下，发送端都收不到应当到来的接收端的响应。所以，如果发送端愿意等待足够长的时间以确定该分组缺失已丢失，则它只需要重传该数据分组即可。

　　从发送端的观点来看，重传是一个万能灵药。为了实现基于时间的重传机制，需要一个倒数计时器 (countdown timer)，在一个给定的时间量过期之后，可中断发送方。发送方需要做到：1）每次发送一个分组（包括第一次分组和重传分组）时，就启动一个定时器；2）相应定时器中断；3）终止定时器。

　　下图是rdt 3.0的发送方FSM，该协议运行在可能发生出错和丢失的信道上。

　　rdt 2.2 协议中的接收端有限状态机描述图仍然适用于 rdt 3.0 协议，下面我仍然用文字来简要描述一下上图中的发送端发送分组流程：

首先由较高层触发 rdt_send(data) 事件，通过 sndpkt = make_pkt(0, data, checksum) 产生一个序号为 0，包含待发送数据且带有校验和的分组，接着通过 udt_send(sndpkt) 将其发送到信道中并启动定时器，然后状态变迁为“等待接收接收端的 ACK 0”
当发送端在“等待接收接收端的 ACK 0”的时候：
- 如果收到了受损的分组（即 corrupt(rcvpkt)）或者收到了 ACK 1（即 isACK(rcvpkt, 1)，也就是收到了自己发送的上一个分组的 ACK），则直接忽略
- 如果定时器时间到，则由 udt_send(sndpkt) 重新发送该分组并重新启动定时器
- 如果收到了完好的分组且 ACK 为 0，那么发送端知道接收端已经成功接收了刚才发送的序号为 0 的分组，直接停止定时器，此时发送端状态变迁到等待较高层传下来的数据发送请求
注意在继续等待从较高层传下来的数据发送请求的过程中，如果收到了任何分组数据包，都直接忽略，因为它们一定是冗余的

　　3.4.2 流水线可靠数据传输协议

　　停等协议可能会限制底层网络硬件所提供的能力

　　解决方法是：不使用停止等待方式，运行发送方发送多个分组而无需等待确认。由于许多从发送方向接收方输送的分组可以被看成是填充到一条流水线中，因此这种技术被称为流水线 (pipelining)。当然，流水线会增加协议的复杂度：

　必须增加序号范围

　　因为信道中的分组要有一个唯一的序号，会有多个分组在信道中未被确认。

协议的发送方和接收方必须缓存多个分组

　　发送方至少应该缓存已经发送却还没有被确认的分组。接受方也许应该缓存已经正确接收的分组。

所需的序号范围和对缓存大小的要求取决于协议如何处理丢失、损坏及延时大的分组

　　解决流水线差错错误的两种基本思路：回退N步和选择重传。

　　3.4.3 回退N步

　　GBN 协议被称为滑动窗口协议 (silding-window protocol)

　　3.4.4 选择重传

　　选择重传协议让发送方仅重传那些它怀疑在接收方出错的分组，避免了不需要的重传。

参考:

https://www.cnblogs.com/hithongming/p/9379397.html

https://www.cnblogs.com/oxspirt/p/6496434.html

https://www.cnblogs.com/huahuahu/p/liu-shui-xian-ke-kao-shu-ju-chuan-shu-xie-yi.html