此章切换英文版

基本介绍
- TCP/IP协议簇中的传输层位于应用层和网络层中间，接受网络层的服务，并向应用层提供服务。
- 是TCP/IP协议簇中的核心。
- 是因特网上从一个点到另一个点传输数据的端到端的逻辑传输媒介。

3.1 介绍和传输层服务

传输层协议提供运行在两个主机应用进程间的逻辑连接。

发送方传输层将从应用进程接收到的接收到的报文转换为段（segment），会在每个段中加入传输层header。然后会将段发送至网络层，在这里会被装进网络层数据报。网络路由器仅对数据报的网络层字段起作用。接收方，网络层从数据报中提取段，然后传给传输层，传输层处理接收到的段，使段中数据可用于接收端应用。

3.1.1 传输层和网络层的关系

传输层提供运行在不同主机的进程的逻辑连接，网络层协议提供主机间的逻辑连接。
传输层提供的服务经常受到底层限制，比如，如果网络层协议不能保证主机间发送的传输层数据段的延迟和带宽，那么传输层协议就不能保证进程间传输的应用报文的延迟和带宽。
在底层网络层协议不能提供对应服务时，传输也能提供某些服务。如网络层协议不可靠时，传输层也能向应用提供可靠的数据传输服务；网络层不保证传输层数据段的机密性时，传输层也能通过使用加密使实习无法被入侵者读取。

3.1.2 传输层概述

TCP/IP网络为应用层提供了两种不同的传输层协议，TCP/UDP。
- UDP（User Datagram Protocol）：不可靠，无状态。
- TCP（Transmission Control Protocol）：可靠，面向连接的服务。
我们将传输层数据包(packet)称为段（segment），有时我们也将TCP的分组数据包称为段，而将UDP的称为数据报文（datagram）。
UDP和TCP的基本职责是将终端间的传输服务扩展为终端进程间的传输服务。称为多路复用和多路分解。
TCP和UDP还通过分段头中包含的检测字段来进行完整性检查.
- UDP只提供进程间的数据传输和错误检查服务，与IP服务一样是不可靠的。
- TCP向应用提供其他服务，TCP是可靠的数据传输服务，使用流控制（flow control）、序列号（sequence number）、确认（acknowledgments）、定时器（timers）可以保证数据正确有序的传输。可将主机间不可靠的IP服务转变为进程间可靠地数据传输服务。
  - 拥塞控制：防止过量通信淹没链路和路由器。
  - 通过调整发送端可发送的速率来力争通过拥塞链路的每个连接均分链路带宽。位于网络层和应用层直接，负责向应用层提供服务，接收来自网络层的服务。

3.2 多路复用和多路分解

传输层有将段中数据传输给合适的进程的职责。一个进程可以有多个socket，socket是数据在进程和网络间的转换和传递的通道，每个socket都有独特的识别码（IP+Port）。

在接收端，每个传输层分段都有一组字段，传输层检测这些字段去识别接收的socket，并将这些分段引导到socket，称为多路分解。
收集来自不同的socket的数据块，添加头信息并封装为分段，将分段传递给网络层叫多路复用。

多路复用和多路分解条件：

socket有独特的识别码
每个数据段有特殊字段标识此段的目标socket
- 来源端口字段
- 目的端口字段

端口号

实现进程到进程通信，最常用的是通过客户-服务器模式（client-server paradigm）。客户和服务器（两个进程）有相同的名字，如要从服务器上获取时间，需要在本地主机和远程服务器上运行Daytime服务。

由于计算机可以在同一时间运行多个服务器程序，我们必须定义本地主机、本地进程、远程主机和远程进程。我们使用IP地址定义主机，使用端口号（port number）定义进程。在TCP/IP协议簇中，端口号是在0到65535之间的16位整数。

客户程序用临时端口号（ephemeral port number）定义自己，推荐值大于1023。
服务器进程一般使用固定端口号，在TCP/IP决定使用全局端口号，经常使用也称为熟知端口号。
IP地址在世界范围内确定一个主机，端口号定义了在该特定主机上的一个服务。

不面向连接的多路复用和多路分解

以UDP为例子，使用二元信息（ip+端口号）来标识UDP socket。来源ip+端口号不同，但具有相同目的ip+端口号的UDP数据段会被通过同一个socket发送到相同的进程。

面向连接的多路复用和多路分解

以TCP为例子，使用四元信息来标识，源IP/源端口号和目的IP/目的端口号。不同源标识但是有相同目的标识的数据段（除了携带原始连接建立请求的TCP段）会被引导到不同的socket.

服务进程有一个等待连接的welcome socket，三次握手是与welcome socket之间。
客户端创建针对某个端口号的连接建立数据段。
连接建立请求只有一个带有目标端口号和极少的特殊连接建立TCP头信息的TCP段。
服务器系统接收到带有这个目的端口的连接请求段，找到此端口的等待连接的服务进程，然后服务器进程创建一个新的socket。
同时，服务端传输层记录下四元信息（源IP/源端口、目的IP/目的端口），新创建的socket使用四元信息标识。随后所有匹配这四元信息的段被解复用到这个socket。

Web服务器和TCP

Web服务器为每个连接创建一个新的进程，这些进程都有自己的连接socket。但是事实上，连接socket和进程间并不是一一对应的，现在的高性能Web服务器只用一个进程，而对每个客户端连接创建一个带有连接socket的新线程。

非持久HTTP连接会有频繁的创建过程，会严重影响Web服务的性能。

3.3 无状态传输：UDP

UDP只做这些工作：
- 从应用进程获得报文，为多路复用/多路解复用添加源和目的端口号字段
- 添加两个别的小字段
- 将处理过的数据段发给网络层
因为不存在握手建立连接的过程，所以UDP又被叫做无连接的。
DNS典型的应用UDP的例子：
- 构建DNS查询报文，并传送给UDP
- 不与目标端系统UDP实例握手的情况下，UDP向报文添加头字段，并将结果段数据传送给网络层
- 网络层封装UDP段数据为数据报，并发送给域名服务
- 主机的DNS应用等待他的查询回复，如果没有收到回复，那么向另一个域名服务重复上述步骤，或通知应用没有收到回复
UDP的优势与适用：
- 更好的应用级别的控制发送什么数据，什么时候发送数据：TCP的可靠性和拥塞控制机制会带来延迟等问题。低速率、能容忍数据丢失、需要低延迟的数据发送的及时应用就需要使用UDP作为应用的一部分。
- 不建立连接：没有握手过程会更快。
- 没有连接状态：服务可以支持更多的客户端。
- 更小的数据包头信息开销：每个数据段UDP只有8字节的开销，而TCP有20字节。
需求低延迟并能容忍丢包的应用会选择UDP，如多媒体应用。当丢包降低，出于安全原因，一些组织组织UDP流量，TCP成为越来越受流媒体传输欢迎的协议。
UDP没有拥塞控制机制可能导致数据溢出路由器，从而导致大量数据丢失，甚至显著影响TCP的速率。同时虽然UDP是不可靠的，但是我们可以在应用中自己实现使UDP变得可靠，并且不用限制在TCP拥塞机制强加的速率限制下。

3.3.1 UDP段结构

源端口 #	目的端口 #
长度	校验
报	文

报文部分包含查询信息和返回信息
header有只有4个字段，每个字段有2个字节
接收方用校验部分插件段中是否被加入了错误数据

3.3.2 UDP校验

检验过程：

发送方将段中所有16位的字的总和的补码添加到UDP段的校验字段中。如0110011001100000、0101010101010101、1000111100001100求得和为0100101011000010，补码为1011010100111101作为校验字段的值。
接收方将所有16位的字的总和和校验字段的值相加，如果不是111111111111，有1位是0则说明数据有误。

由于低层协议会发生错误，并且并不是百分百的提供错误校验机制，同时某些功能在低层提供成本高或价值不大，所以这些功能需要在端到端（传输层是端到端的基础）提供。

虽然UDP有错误校验机制，但是它并不会主动修复错误，一般是丢弃段，或者将损坏数据带有警告的发送给应用，所以它还是不可靠的。

3.4 可靠的数据传输原理

可参考此文章可靠数据传输原理（上）

向上一层实体提供可靠地数据传输通道是可靠地数据传输协议的职责，通过这个通道，没有信息会被损毁或丢失，所有信息都会被按照顺序的传输。

抽象：数据传输协议的发送方会被上层调用rdt_send()（reliable data transfer）方法；在接收方，packet抵达接收方时，会调用rdt_rcv()方法（表示可靠地数据接收），随后需要将数据传递给上层（应用层/ssl/xxx）时，使用deliver_data()方法。

除了包含将要被传输的数据的packets外，可靠数据传输也会来回交换控制packets。

3.4.1 创建一个可靠数据传输协议

经完美的可靠通道的可靠数据传输：rdt 1.0

这种协议是很普通的，接收方和发送方的状态机都是只有一个状态。接收方：等待底层的调用；发送方：等待上层的调用。

发送方：
- 简单的接收通过rdt_send(data)事件从上层传递过来的数据，通过make_pkt(data)方法将数据包装成packet，并使用rdt_send(data)方法发送到通道中。
接收方：
- 接收底层通道通过rdt_rcv(packet)事件传输来的packet，通过extract(packet, data)方法将数据从packet中提出，然后通过deliver_data(data)将数据传输给上一层。

经会发生比特错误的通道的可靠数据传输 rdt 2.0

在不可靠的童话中，“信息听写协议”使用积极地确认方式（“OK”）和消极的确认方式（“请重复”）。这种控制方式使接收者能让发送发知道哪些消息正确传输，哪些消息发生了错误并且需要重复。在网络中，可靠地数据传输协议也是用类似的重发措施，称为ARQ协议（Automatic Repeat reQuest）(自动重传请求协议)。

ARQ中有三个附加协议：

错误发现：额外的比特会被收集到原本要发送的数据包的包检验字段。
接收反馈：2.0协议下，ACK（积极地）和NAK（消极地）确认回复会从接收方发送到发送方，原则上只需要一个字节长，如0标识NAK，1表示ACK。
重发：错误数据会被重发。

情形一

模型：简单的讲

2.0
- 发送方：
  - 等待上层调用和传输的数据。
  - 等待ACK或NAK。
- 接收方：
  - 等待下层调用，然后返回ACK或NAK。

因为发送方存在两个状态，且在收到确认前不会继续发送数据，所以这种协议又称为停止等待（stop-and-wait）协议。

情形二

当然，ACK和NAK也有可能损坏。

三种处理错误的可能：

不停地重复“你说啥”，“你说啥”（因为这些信息也可能损坏）
添加足够多的检查比特来时发送方不止能检查也能从比特错误中恢复数据。这种方式能解决损坏问题但是不能解决丢失问题。
发送方收到不清晰的ACK或NAK时，会直接重复发送原有数据。问题是，接收方再收到数据时不知道是新的数据还是一个重发数据。

针对第三种方式，现有的数据传输协议使用seq（sequence number）按序号标记发送的数据并作为新的字段。接收方只需要检测seq来确定是否是重发的数据。ACK和NAK并不需要标记是针对哪个数据包，发送方会将其当做最近发送的数据的响应。

模型：简单的讲

2.1
- 发送方：
  - 初态：等待上层调用和0分组
  - 等待ACK或NAK0
  - 等待上层调用和1分组
  - 等待ACK或NAK1，然后回到初态
- 接收方：
  - 等待下层调用和0分组。如果受损，返回NAK，如果数据正确（可能是1分组），则返回ACK，进入下个状态。
  - 等待下层调用和1分组，同上。
2.2

接收方不返回NAC，而是返回上次正确数据的ACK，发送方也能正确返回数据。

经过会丢失数据会发生比特错误的通道的可靠数据传输协议 rdt 3.0

因为数据包可能会丢失，那么发送方可能就收不到确认信息，所以会等足够的时间来确定数据丢失了。由于这个足够的时间的时长不能确定，实际上，会让发送者明智的选择一个时间。但是可能会在没有丢失的情况下重复发送数据包，2.2就能解决这个问题。

模型：

发送方比2.3多了一个倒数计时器，超时重发。

因为数据包的顺序号码（seq）在0和1间轮换，所以有称为比特交换协议（alternating-bit protocol）.

3.4.2 管线化可靠数据传输协议

由于前面阐述的协议需要停下等待，在现在的高速网络中，它的性能问题不是每个人都能接受的。

为了解决等待引起的效率低下问题，发送方可以在接收到确认前一次发送多个连续的数据包。因为这些数据包可被视为填充管道，又称为管线化（pipelining）。

需要有三个变化：

包的序号范围必须增加，因为途中的包和未确认的包变多了，都需要不同的标号。
发送和接收方可能都需要缓冲多个包。发送方需要缓冲已发送但是未确认的包。接收方也要缓冲，但是怎么缓冲与第三点有关。
所需的序号范围和缓冲要求取决于数据传输协议对丢失，损坏和过度延迟的数据包的响应方式。有两种基本的管线化方式：后退N帧（Go-Back-N）和选择性重传（selective repeat）。

3.4.3 后退 N 帧（GBN）

后退 N 帧协议中允许在未获得确认的情况下发送不超过最大限制数量的多个数据包，这个限制数与通道中未确认的数据包的个数有关。

阅读：《计算机网络教程》（3）传输层