6.1 Transport Service（传输服务）

6.1.1 提供给上层的服务 Services Provided to the Upper Layer

• 传输层提供了无连接（UDP协议）和面向连接（TCP协议）的服务给应用层

• 在传输层内使用网络层提供的服务的硬件和/或软件称为传输实体(transport entity)

• 传输实体实现位置：操作系统内核/链接库绑定到网络应用/独立的用户进程/网络卡口（前两种方式最常见）

• 与面向连接的网络服务都需要连接建立、数据传输和连接释放

• 都有寻址和流量控制

• 无连接传输服务与无连接网络服务也极为相似

• 在面向连接的网络服务上提供无连接传输服务很困难，为了发送单个数据包要建立一个连接，发送完毕后还要立即拆除，效率低

• 传输层代码完全运行在用户机器上，网络层代码主要运行在运营商的路由器上

• 用户对网络层没有控制权，但可以控制传输层来提高网络的服务质量

6.1.2 传输层服务原语 Transport Service Primitives

• Client calls CONNECT, SEND, RECEIVE, DISCONNECT

• Server calls LISTEN, RECEIVE, SEND, DISCONNECT

• 连接的释放分为对称和非对称

6.1.3 伯克利套接字 Berkeley Sockets

• 套接字socket表示通信的端点

• 与简单连接原语相比增加了SOCKET, BIND, and ACCEPT

• 套接字模型中连接的释放是对称的，双方都执行了CLOSE原语之后，连接就释放了

6.2 传输协议的要素

传输协议与数据链路协议的关系

相似之处：差错控制、流量控制、顺序性

不同之处：

• 传输协议需要明确的地址

• 连接过程更加复杂（由于网络缓存带来的重复数据）

• 缓冲区使用方式(传输层同时存在多个连接，带宽变化大，不适用给每个连接固定数量缓冲区的方法)

6.2.1 寻址 Addressing

寻址

Transport layer adds TSAPs（传输服务访问点，或端口）

网络层类似的端点叫做网络服务端口（NSAP），如IP地址

一个应用使用一个TSAP，多个TSAP可以共享一个NSAP，每台主机只有一个IP address

TSAPs 是TCP/UDP的端口ports

端口号：动态分配；某些端口号为一些常用的应用固定使用，例如port 80一般用于web服务器

 

端口映射器：将服务名字解析为端口

• 找到一个给定服务名字（e.g. Bittorrent）相对应的TSAP地址

• 用户与端口映射器发送消息指定想要的服务名字

• 端口映射器返回相应的TSAP地址

• 一个新服务建立时，必须向端口映射器注册

 

初始连接协议（进程服务器）：代理不常使用的进程

• 服务器上存在很多不常使用的服务进程，保持活跃状态是一种浪费

• 每台希望提供服务的机器由进程服务器充当不频繁使用的服务器的代理

• 在同一个时间监听一组端口，等待连接请求的到来

• 一个用户发出连接请求，并制定TSAP地址

• 如果TSAP对应的服务不在活跃状态，则与进程服务器连接。

• 进程服务器收到请求，派生出被请求的服务器进程，允许该服务器进程继承与用户的现有连接。

 

6.2.2 连接建立

建立连接三次握手

需要解决的关键问题是怎样在数据包可能发生丢失损坏延迟或重复情况下依然保障传输的可靠性

• 不要把旧的或重复的packet当作新的

• 对于丢失los/损坏corruption使用ARQ（自动重传请求）和校验和

重点是避免重复的连接建立，连接中的重复数据可以通过滑动窗口避免。

• 不能在【2T（T为数据包最大生存期） = 240secs】内使用sequence number两次

• 三次握手机制（three-way handshake）

(a) 主机1发起连接请求时的正常建立过程：

①主机 1选择一个序号x，并且发送一个包含x的CONNECTIONREQUEST段给主机2。

②主机2 回应一个ACK段作为对x 的确认，并且宣告它自己的初始序号y。

③最后，主机 1 在它发送的第一个数据段中，对主机2选择的初始序号进行确认。

(b) 出现延迟的重复控制段时三次握手协议

(c) 延迟的CONNECTION阻QUEST和ACK 同时出现在网络中

 

如何选取序号？

考试概率不大，但要搞明白

当建立一个连接时，时钟的低k位【选择低位：变化快，可以很快产生新的序号】被用于同样是k位的初始序号。因此每个连接都从一个完全不同的初始序号开始对它的段进行编号。序号空间应该足够大，以便当序号绕回时，原先那些具有老序号的段都已经消失。时间和初始序号之间的线性关系如图(a)，禁止区域显示了段序号非法使用的对应时间。

程序发出去的段，如果其序号恰好落在禁止区域，那么它可能被延迟，因为他会假冒将在之后发出的具有相同序号的段。例如，如果主机在70秒时崩溃并重新启动，它将初始序号，基于它崩溃后的时钟，因此主机不可能启用一个位于禁止区域的较低序号。一旦双方的传输实体已经统一了初始序号，则可用任何一个滑动窗口协议来控制数据流的传输。滑动窗口协议将发现并丢弃早已接收到到重复数据包。事实上，初始序号曲线（图中的粗线）并不是线性的，而是一条梯状线（想象一下相似的分段函数），因为时钟是离散前进的。

为了防止序号进入禁止区域，我们必须兼顾两个方面。协议可能以两种不同方式遇到麻烦。①如果一台主机在一个新打开的连接上发送得太快，则实际序号与时间的曲线可能比初始序号与时间的曲线还要陡，导致序号进入禁止（即数据包被延迟）。为了防止这种情况出现，每个连接上的最大数据速率是每个时钟滴答一次(单位时间)发送一段。这同时也意味着在机器崩溃并重启之后，传输实体必须等待时钟滴答，才能打开一个新的连接，以免同样的序号被使用两次。这两点都倾向于使用短的时钟滴答（1微秒甚至更短）。但是相对序号来说时钟不能滴答得太快。假设时钟速度为C（每滴答一次一段），序号空间大小为S（一个序号一段），则有S/C>T（S/C即滴答完一个S所用的时间，表达式也即一个T时间不能使用完S个序号），才能使得序号不至于回绕得太快（即导致序号进入禁止区域）。

由于发送速度太快而造成由下方往上进入禁止区域并不是带来麻烦的唯一情形，从图b可以看出，如果任何以低于时钟频率的数据率发送（图中的阴影区域向下倾斜，可以想象极端情形，比如阴影部分贴近x轴，那么就会与之后的阴影发生重叠），实际使用的序号与时间之间的曲线最终会从左边进入到禁止区域中。实际序号曲线的斜度越大，则这种事件发生的越晚，应该限制连接序号递增的速度不能太慢。

 

6.2.3 连接释放

释放连接三次握手

非对称

非对称释放连接是电话系统的工作方式：当一方挂机后，连接就被中断了。

不对称释放（当一侧断开连接时）是突然的，可能会丢失数据。

 

对称

对称释放连接是把连接看成两个独立的单向连接，要求单独释放每一个单向连接。

难点在于两个分布式实体需要达成一个共识（确定两方都要断开连接）

类似三次握手：断开请求发送方收到确认后即可断开连接，并返回确认。请求接收方收到请求后回确认，在规定时间内收不到确认也会断开连接

 

两军对垒问题（two－army problem）可以证明不存在安全的通过 N 次握手实现对称式连接释放的方法

这个协议不总能正确地工作

 

正常情况下，一个用户发送一个DR (DISCONNECTION QUEST）段来启动释放连接过程。

当该段到达对方，接收端也发回一个DR段，并启动一个计时器，设置计时器的目的是为了防止它的DR丢失。

当这个DR到达时，最初的发送端发回一个ACK段，并且释放连接。最后，当ACK返回后，接收端也释放连接。

 

 

三次握手法释放连接的错误情况：

(a) 最后一个ACK丢失：可以使用计时器来补救。当计时器超时，无论如何连接都被释放

(b) 响应丢失（第二个DR被丢失的情形。发起释放连接的用户接收不到期望的响应，所以它将超时，于是再次尝试释放连接）

(c) 响应和随后的DR都丢失（发送端所有重传DR的尝试都失败，经过N次尝试，发送端放弃了，并且释放连接。同时，接收端超时，退出连接）

6.2.4 差错控制和流量控制

流控制和缓冲

与第三章学的类似

差错控制确保数据传输具备所需的可靠性，通常指所有的数据均被无差错地传送到目的地。

流量控制是防止快速发送端淹没慢速接收端。

流量控制不考虑子网，仅考虑端到端，拥塞控制要考虑整个收发子网的情况。

 

发送端窗口大小>（网络每秒钟能够处理c个段，往返时间是r）

 

对于buffer的使用与数据链路层不同：

(a) 如果段长度的差异范围很大，如果将缓冲区设置成最大可能的段长，那么当短数据包到来时就会浪费空间：如果将缓冲区设置成比最大的段要小，则长的段就需要多个缓冲区，从而带来额外的复杂性。

(b) 大小可变的缓冲区，优点是能获得更好的内存利用率，付出的代价是缓冲区的管理更加复杂。

(c) 为每个连接使用一个大的循环缓冲区：

 

6.2.5 多路复用

 

6.2.6 崩溃恢复

传输层恢复失败是因为 A(ck) / W(rite) 不是同时发生

 

6.3.1 理想的带宽分配

6.3.2 调整发送速率

• 流量控制，在接收端没有足够缓冲区的情况下，必须进行流量控制

• 拥塞控制，在网络容量不足的情况下必须继续进行拥塞控制。

6.4 Internet传输协议：UDP

UDP

6.4.1 UDP 用户数据协议

User Datagram Protocol

UDP 为应用程序提供了一种无需建立连接就可发送封装的 IP 数据报的方法。UDP传输的段（Segment）由8字节的头和有效载荷字段构成

• Source port：源端口号；Destination port：目标端口号；即传输层端口地址TSAP，共16位

• UDP length规定UDP数据包长度，最大65515（为什么？ 65535-20）

• UDP checksum（可选）：校验头，数据和一个概念性的IP伪头

 

 

IP伪头用于UDP协议里的校验和的计算，有助于发现错误的数据包，但是这种做法违反了协议的分层原则（IP是网络层）

UDP协议不做的事情：

• UDP没有流量控制、拥塞控制、没有重传机制

• 所有以上的功能交给应用层解决

UDP做的事情：

• 提供一个与IP协议的接口

• 通过多个端口号提供复用多个进程的功能

• 端到端的错误检测

 

6.4.2 远程过程调用（RPC, Remote Procedure Call)

• Program number: 定义了一组远程过程操作

• Version number： 每一个program可以有多个version

• Procedure：可以被远程调用的过程

6.4.3 实时传输协议 （RTP, Real-time Transport Protocol)

• RTP运行在用户控件，并且与应用层链接，看起来像一个应用层协议

• 但是RTP又与具体应用无关的一个通用协议，仅提供了传输设施，看起来像传输协议；

• 它是一个在应用层实现的传输协议

• Ver. 版本号；P位表示数据包被填充到了4字节的倍数；X位表示有一个扩展头（1表示有，0表示无）

• CC（4位）表示共有多少个贡献源（多个UDP流混合）

• M是一个与应用相关的标记位（应用定义：一个视频帧的开始，音频信道中一个字的开始）

• Payload type：说明用哪一种编码算法（未压缩的8位音频、MP3等）

• Sequence number：计数器，每发送一个RTP数据包计数器递增

• Timestamp：时间戳，注明数据包第一个样本产生时间

• SSI 同步源标识符：指明数据包属于哪个源

6.5 TCP

6.5.1 TCP

传输控制协议（TCP，Transmission Control Protocol）是为了在不可靠的互联网上提供可靠的端到端字节流而专门设计的一个传输协议。

TCP协议的设计目标是能够动态的适应互联网异构特性

每台支持TCP的机器都有一个TCP传输实体，TCP实体可以是一个库过程、一个用户进程或者内核的一部分。

TCP实体管理TCP流以及与IP层之间的接口

TCP传输实体接收用户数据流，分割成64KB的分段

TCP负责足够快的发送数据报，充分使用网络容量，又不能引起网络拥塞。

TCP要进行重传并且保证递交的数据报在正确的顺序。

6.5.2 TCP服务模型

TCP服务模型

TCP提供可靠的端到端字节流服务。发送端和接收端创建套接字（Socket），套接字编号包括32位IP地址和16位端口号

1024以下的端口号保留，用作某些知名的服务，知名端口

 

一个TCP连接就是一个字节流，而不是消息流。端到端之间不保留消息的边界。

 

6.5.3 TCP协议

TCP协议

TCP的一个关键特征是：TCP连接上的每个字节都有它独有的32位序号（按照字节流传输）。

发送端和接收端的TCP实体以段的形式交换数据。

• TCP段由1个固定的20字节的头以及随后0个或多个数据字节构成。TCP软件决定了段的大小。

• TCP软件可以把多个写操作的数据积累起来，放到一个段中发送，也可以把一次写操作中的数据分割成多段发送

• 有两个因素限制了段的长度： ① 包括在TCP头在内的每个段，必须适合IP的65515个字节的有效载荷的要求 ② 要考虑每个网络的最大传输单元（MTU, maximum transfer unit），如以太网的1500字节

• TCP 实体使用的基本协议是具有动态窗口大小的滑动窗口协议。当发送端传送一段时，它启动一个计时器。当该段到达接收方时，接收端的TCP实体返回一个携带了确认号和剩余窗口大小的段（如果有数据要发送的话，则包含数据，否则就不包含数据〉，并且确认号的值等于接收端期望接收的下一个序号。如果发送端的计时器在确认段到达之前超时，则发送端再次发送原来的段。

6.5.4 TCP段的头

每个段的起始部分是一个固定格式的20宇节头。固定的头部之后可能有头的选项。如果该数据段有数据部分的话，那么在选项之后是最多可达 65 535-20-20=65 495 个字节的数据，这里的第一个 20 是指IP 头，第二个20指TCP 头。

source port，destination port（源端口，目标端口）

序列号（Sequence number），表示此次发送数据的第一个字节的编号

确认号（Acknowledge number），表示下次想要接收数据的第一个字节的编号。

TCP header length：TCP头长度；

CWR，ECE：与显式拥塞通知（ECN）相关

URG：紧急指针；Urgent pointer指向从当前序号开始找到紧急数据的字节偏移量（置 1 表示使用了紧急指针）

ACK：1表示确认号字段有效；

PSH：1表示这是被推送PUSH的数据；

RST：被用于重置一个已经混乱的连接(一般而言，如果得到的数据段被设置了 RST 位，那说明你这一端有了问题)

SYN 被用于建立连接过程。在连接请求中， SYN=1 和ACK=0表示该段没有使用捎带确认字段。但是，连接应答捎带了一个确认，因此SYN=1和ACK=1。

FIN用于释放连接；

win size：滑动窗口大小，表示这个 TCP 数据段发送方当前可用的缓冲区大小，表示的是这一方的接收能力。

校验和（Checksum），它校验的范围包括TCP数据段的头部、数据以及伪 TCP 头

options必须是32位的倍数

 

 

【综合题中的注意事项】

1. 确认号-初始数据号=已经确认收到的字节数

2. 分组的标识字段用来分辨2个不同的IP分组在分片之前是否是同一个IP分组

 

6.5.5 TCP连接建立

TCP连接建立

TCP 使用了三次握手法来建立连接（见6.2.2节）

三次握手的过程如下：

1）客户端向服务端发送SYN包，其中SYN标志位被置为1，表示客户端请求建立连接。序列号Seq=x

2）服务端接收到SYN包后，向客户端发送一个SYN/ACK包，其中SYN和ACK标志位都被置为1，表示服务端已经接收到客户端的连接请求，并准备好建立连接。序列号Seq=y, 确认号Ack=x+1（表示收到客户端的序号Seq并将其值加1作为自己确认号Ack的值）

3）客户端接收到服务端的SYN/ACK包后，向服务端发送一个ACK包，其中ACK标志位被置为1，表示客户端确认服务端的SYN/ACK包已收到。序列号Seq=x+1（表示收到服务器端的确认号Ack，并将其值作为自己的序号值）, 确认号Ack=y+1（表示收到服务器端序号seq，并将其值加1作为自己的确认号Ack的值）

通过三次握手协议，客户端和服务端都确认了彼此的身份，并同意建立连接，从而可以开始传输数据。

6.5.6 TCP连接释放

TCP连接释放

释放连接的三次握手（四次挥手）过程：

1）客户端（主动关闭连接的一方）向服务端（被动方）发送一个FIN包，其中FIN标志位被置为1，表示客户端不再发送数据。序列号Seq=u

2）服务端接收到FIN包后，向客户端发送一个ACK包，其中ACK标志位被置为1，表示服务端已经接收到客户端的FIN包。序列号Seq=v，确认号Ack=u+1

3）当服务端不再发送数据时，服务端向客户端发送一个FIN包，其中FIN标志位被置为1，表示服务端不再发送数据。序列号Seq=w，确认号Ack=u+1

4）客户端接收到FIN包后，向服务端发送一个ACK包，其中ACK标志位被置为1，表示客户端已经接收到服务端的FIN包。序列号Seq=u+1，确认号Ack=w+1

通过四次挥手协议，客户端和服务端都确认了彼此的关闭请求，并释放了TCP连接。

6.5.8 TCP滑动窗口

TCP滑动窗口协议

在TCP中，发送方维护一个发送窗口，接收方则会维护一个接收窗口，它们是一个连续的字节序列，表示发送方可以发送的数据范围大小。窗口由两个参数定义：窗口的起始字节和窗口的大小。

工作原理：

发送方和接收方分别维护着发送窗口和接收窗口，发送窗口表示发送方可以发送的数据的范围，接收窗口表示接收方可以缓冲的字节数。

① 在建立TCP连接时，确定初始的拥塞窗口大小。

② 当发送方发送数据包后并接收到接收方传来的ACK确认应答后，将发送窗口向前滑动，这样，发送方可以继续发送新的数据。

③ 接收方更新、通告接收窗口大小：接收方在根据已经成功接收的字节数和初始窗口大小计算可用的接收窗口大小，并将新的接收窗口的大小通过TCP 报文段中的窗口大小字段通告给发送方。这个值告诉发送方接收方的当前可用缓冲区空间。

④ 动态调整窗口大小：接收方通过ACK确认号通知发送方已成功接收的数据。发送方可以根据接收方通告的窗口大小进行数据发送控制——如果接收方的窗口变大，发送方可以发送更多的数据；如果接收方的窗口变小，发送方需要适应减少的窗口大小。

⑥ 流量控制：通过滑动窗口机制，接收方可以动态调整窗口大小以限制发送方的数据发送速率。接收方通过通告窗口大小，告知发送方自己的可用缓冲区空间。发送方根据接收方的窗口大小调整发送速率，确保不会超出接收方的处理能力。

 

Nagle算法

尽管通过延迟确认减少了接收端给予网络的负载，但是发送端发送多个小数据包的工作方式仍然非常低效（比如， 41 字节的数据包只包含 1 个字节的数据）。避免这种用法的一种办法是采用Nagle算法：

当数据每次以很少量方式进入到发送端时，发送端只是发送第一次到达的数据字节，然后将其余后面到达的字节缓冲起来，直到发送出去的那个数据包被确认；然后将所有缓冲的字节放在一个TCP段中发送出去，并且继续开始缓冲字节，直到下一个段被确认。

这就是说，任何时候只有第一个发送的数据包是小数据包。如果在一个来回时间内应用程序发送了许多数据，那么Nagle 算法可以将这些数据放置在一个段中发送，由此大大地减少所需的带宽。另外，如果应用传递来的数据足够多，多到可以填满一个最大数据段，则该算法也允许发送一个新的段。

 

愚笨窗口综合症（sillywindow syndrome)

降低TCP性能的另一个问题是低能窗口综合症（sillywindow syndrome) 。当数据以大块形式被传递给发送端TCP实体，但是接收端的交互式应用每次仅读取一个字节数据的时候，这个问题就会发生。

初始时，接收端的TCP 缓冲区为满，发送端知道这一点（即它有一个大小为0的窗口〉。然后，交互式应用从TCP 流中读取一个字符，这个动作使得接收端的TCP欣喜若狂，它立刻发送一个窗口更新段给发送端，告诉它现在可以发送 1个字节过来。发送端很感激，立即发送1个字节。现在缓冲区又满了，所以，接收端对这 1 字节的数据段进行确认，同时设置窗口大小为 0。这种行为可能会永久地持续下去。

解决方法为：禁止接收端发送只有 1 个字节的窗口更新段。它强制接收端必须等待一段时间，直到有了一定数量的可用空间之后再通告给对方。特别是，只有当接收端能够处理它在建立连接时宣告的最大数据段，或者它的缓冲区一半为空时（相当于两者之中取较小的值〉，它才发送窗口更新段。

6.5.10 TCP拥塞控制

TCP拥塞控制

当提供给任何网络的负载超过它的处理能力时，拥塞便会产生。

TCP 维持一个拥塞窗口，窗口大小是任何时候发送端可以往网络发送的字节数。相应的速率则是窗口大小除以连接的往返时间。

流量控制窗口，该窗口指出了接收端可以缓冲的字节数。（流量控制窗口就是接收端窗口）

 

slow start

一开始将拥塞窗口大小设为1，然后成倍增加(指数级)拥塞窗口的大小，直到到达所设定的阈值或发生网络拥塞。当达到阈值时，慢启动结束，TCP进入拥塞避免阶段，此时拥塞窗口大小变为线性增长；当网络出现拥塞时，TCP慢启动会减缓发送速度，从而避免网络过载和拥塞的发生。

 

6.6 性能问题

6.6.1 Performance problems 性能问题

• Broadcast storm（广播风暴）:
一个坏段广播给大量机器，每台机器送回一个错误信息，引起广播风暴
ICMP协议修改解决这个问题，主机不再对发送给广播地址的UDP段中的错误做响应

• Synchronization（同步触发过载）
电力恢复后，所有机器同时启动，向DHCP服务器联系获得IP地址，缺少总体协调。

• Tiny packets: some situations can cause TCP to send many small packets instead of few large ones

• 超时间隔问题：太短引起不必要的重传，太长导致不必要的延迟

• 实时应用的抖动问题

6.6.2 Measuring network performance 网络性能测试

• 确保样值空间足够大：时长和次数（重复测量取平均值）

• 确保样值具有代表性：测试分布在一天或者一周的不同时刻进行，无线网络中的位置

• 缓存会破坏测量结果: 如果协议使用了缓存机制，那么重复多次测量将返回一个不可预测的快速答复。

• 确保测试期间不会发生不可知事情：在一个空闲的网络上进行测试

• 粗粒度时钟： clocks may over/underestimate fast events，大量重复测量取均值解决

• 干扰：Interference: there may be competing workloads 考虑不可知的workload

• 推断结果不可靠：使用模拟网络负载进行测量，与实际并不相符

6.6.3 Host design for fast networks 针对快速网络的主机设计

• Host speed more important than network speed（主机速度比网络速度更重要）

• Reduce packet count to reduce overhead（减少包数来降低开销）

• Minimize data touching（最小化数据接触）：分层协议栈产生数据包多次复制，内存操作比寄存器操作慢一个数量级；多个层次的处理结合在一起，用来最小化复制操作

• Minimize context switches（最小化上下文转换）：例如从内核模式和用户模式之间转换，通过内部缓冲直到有大量数据再发送，减少上下文转换次数

• Avoiding congestion is better than recovering from it（避免拥塞比从中恢复更好）

• Avoid timeouts：计时器设置成稍微超过一点保守时间边界

6.6.4 Fast segment processing 快速段处理

6.6.5 Header compression 头压缩

6.6.6 Protocols for “long fat” networks 长肥网络的协议

• 低带宽时传输时间主要受数据发送时间的限制

• 高带宽主要是线路上的传播延时限制

6.7 DTNs (Delay Tolerant Networks，延迟容忍网络)