端到端协议

• 传输（transport）层的任务：从主机到主机的分组传递服务转向进程到进程的通信信道。
• 端到端（end-to-end）协议：在终端节点上运行的应用程序之间的通信。

简单多路分解（UDP）

UDP概要

• 该协议至少需要增加一个多路分解功能，使得主机上多个进程能够共享网络。

• 端口（port）：一种抽象定位器，使进程能够间接相互识别。基本思想是源程序向端口发生报文，而目的程序从端口接收报文。

• UDP首部格式

  

  • 端口只对单个主机有效。
  • <主机，端口>对构成了对UDP多路分解键

客户进程如何知道服务器进程的端口号？

• 知名端口（well-known port）：服务器在知名端口接收报文

  • 域名服务器（DNS）总是在端口 $53$ 接收报文。
  • 电子邮件服务在端口 $25$ 接收报文。
  • UNIX 的talk程序总是在端口 $517$ 接收报文
  • 这种服务与端口的对照表定期于RFC上公布

• 端口映射（port mapper）：知名端口只有一个，端口映射服务接收报文的端口。客户向该端口发生报文，询问某服务的端口，服务程序返回相应的端口。

报文队列：

• 端口由一个队列实现，报文到达时，协议会把该报文加到队列的末尾
• 如果队列满了，报文被丢弃

可靠字节流（TCP）

TCP 概要

• TCP 能保证可靠的、有序的字节流传输。

• 全双工协议，即每个 TCP 连接支持一对字节流，每个方向一个字节流。

• TCP 包含流量控制机制，支持多路分解，实现了高度协调的拥塞控制机制

• 流量控制与拥塞控制

  • 流量控制（flow control）：防止发送方发出的数据超出接收方的接收能力，这是端到端问题。
  • 拥塞控制（congest control）：防止过多的数据注入网络而造成交换机或链路超载，这是主机与网络交互的问题。

端到端问题

• TCP 支持运行在因特网中任意两台计算机上的进程之间的逻辑连接。这意味着TCP有明确的连接建立阶段，也有明确的连接断开阶段。
• TCP 连接很可能具有差异很大的往返时间。对于不同时间和地点，其RTT值可能会不同。这对意味着对于滑动窗口算法，触发重传的超时机制必须具有适应性。
• 分组通过点到点链路上的错序可能性较小，分组的轻度错序不会引起问题，因为滑动窗口算法能用序号将分组正确地重新排序。问题是错序的分组多长时间能到达，最坏情况下，分组超过IP的生存期TTL后被丢弃。TCP 假设每个分组有一个最大的生存期，称为最大报文段生存期（maximum segment lifetime, MSL）。
• TCP 需要包含一种机制，使连接他的每一端都能了解另一端有什么资源（如缓冲区大小）用于连接，这属于流量控制问题。
• TCP 的发送方并不知道经过什么链路能传送到目的地，可能链路上带宽差异很大，会导致网络拥塞问题。

报文段格式

• TCP是面向字节的协议，即发送方向TCP连接写入一个字节，接收方从这个TCP连接中读出字节。但TCP并不转发单个字节，而是积累到足够数量后再发送。

  

• 报文段（segment）：TCP对等实体之间交换的分组。

  

  • TCP多路分解键由 <源端口，源IP地址，目的端口，目的IP地址> 四元组给出

  • 对于同一个多路分解，在连接断开后又建立，称为相同连接的不同实例（incarnation）

  • 确认号（Acknowledgement）、序号（SequenceNum）和通知窗口（AdvertisedWindow）字段都在TCP的滑动窗口算法中使用。

    • 序号（SequenceNum）：发送方报文段数据的第一个字节的序号
    • 确认号（Acknowledgement）：接收方发送的确认消息，确认号代表该序号及前的字节均已确认收到
    • 通知窗口（AdvertisedWindow）：代表接收方目前可以接收数据的大小

  

  • $6$ 比特的Flags字段用来在TCP对等实体之间传送控制信息。

  • 校验和（CheckSum）字段与UDP用法一致

连接建立与终止

• 三次握手（three-way handshake）：

  

  • 首先，客户端（主动参与方）发送一个报文段给服务器（被动接受方），声明其使用的初始序号（标志=SYN，序号= $x$）。
  • 然后，服务器用一个报文段应答，确认客户端的序号（标志=ACK，确认号= $x+1$），同时声明自己的初始序号（标志=SYN，序号=y）。
  • 最后，客户端用一个报文段应答，确认服务器的序号（标志=ACK，序号= $y+1$）.
  • 每一端的确认号比发来的序号大 $1$ 的原因是确认号字段实际指出“希望接收的下一个序号”，从而隐含地确认前面所有序号。
  • 前两个报文段都使用定时器，若没收到希望的回答，会重传报文段。
  • TCP规范要求每一方随机地选择一个初始序号，防止同一连接的两个实例过快地重复使用同一个序号，以免发生以前的连接实例的数据段干扰后来的连接的实例。

状态转换图

• TCP连接和断开的状态图，每一个矩形表示一个状态，每个弧线用事件/操作（event/action）的形式标记。

  

• 对于连接的断开（ESTABLISHED $\to$ CLOSED）可能有以下几种组合

  • 一方先关闭：ESTABLISHED $\to$ FIN_WAIT_1 $\to$ FIN_WAIT_2 $\to$ TIME_WAIT $\to$ CLOSED
  • 另一方先关闭：ESTABLISHED $\to$ CLOSE_WAIT $\to$ LAST_ACK $\to$ CLOSED
  • 双方同时关闭：ESTABLISHED $\to$ FIN_WAIT_1 $\to$ CLOSING $\to$ TIME_WAIT $\to$ CLOSED

再论滑动窗口

• TCP 滑动窗口算法的变体，服务于

  • 保证数据的可靠传递，确保数据的有序传递，增强发送方和接收方之间的流量控制

• 可靠和有序的传输

  

  • 对于发送方，发送程序向 LastByteWritten 后写入要传输的数据并更新该指针。LastByteSent 表示最后发送的字节，而 LastByteAcked 表示收到确认的最后一个字节，之前的字节均已确认。

    • LastByteAcked $\leqslant$ LastByteSent
    • LastByteSent $\leqslant$ LastByteWritten

  • 对于接收方，接收程序从区间 $($LastByteRead, NextByteExpected$)$ 读取数据，并更新指针 LastByteRead，同时 LastByteRcvd 指示收到的最后一个字节的位置。

    • LastByteRead $\lt$ NextByteExpected
    • NextByteExpected $\leqslant$ LastByteRcvd + 1

• 流量控制

  • 收发双方均有缓冲区大小的限制，分别表示为 MaxSendBuffer 和 MaxRcvBuffer

  • 窗口的大小决定了可以被发出而不需要等待接收方确认的数据的大小，这个大小取决于接收方能缓存的数据量。接收方通过通知发送方该窗口大小，就可以控制发送方发送速率。TCP 的接收方需要满足

    可以避免缓冲区溢出，所以向发送方通知窗口的大小应为

  • 发送方必须确保

    即发送方计算一个有效窗口，限制其能发送数据的大小

  • 同时发送方还需要确保其发送的内容不超出其缓冲区

    若打算发送 $y$ 字节数据，但

    则 TCP 会阻塞发送进程。

  • TCP 总是发生一个报文段对接收到的报文段进行应答，应答包含确认号（Acknowledgement）和通知窗口（AdvertisedWindow）。当通知窗口变为 $0$ 时，不允许发送方发送任何数据，但这就没法发现将来通知窗口是否不再是 $0$ 。

  • 零窗口探测（zero window probe）：当通知窗口变为 $0$ 时，发送方每 $5$ 到 $60$ 秒发送一个包含真实的下一字节的报文段，探测是否通知窗口不再是 $0$ 。发送真实数据可以让接收方即使接收了探测数据，也不会引起错误。若收到应答，则会触发报告非 $0$ 的通知窗口应答。

• 防止回绕

  • 回绕：某个连接使用具有序号 $S$ 的字节在某一时刻被发送，之后第二个具有序号 $S$ 的字节也可能被发送。
  • 假设分组在因特网上生存周期不超过 MSL，目前推荐值为 $120$s，则任务是保证在这个时间内不会出现回绕。（在 MSL 内出现回绕，则无法判断哪一个包是该序号字节正确的数据。若在 MSL 外出现回绕，则直接丢弃超时的包即可。）

• 保持管道满载

触发传输

• TCP怎样决定传输一个报文段

  • 设置最大报文段长度（Maximum Segment Size, MSS），一旦 TCP 从发送进程收到 MSS 个字节，就发送一个报文段。
  • 发送进程使用 TCP 的 push 操作，要求发送一个报文段。
  • 定时激活 TCP 报文段发送

• 傻瓜窗口症状（silly window syndrome）

  

  • 对于窗口大小小于 MSS 时，是等窗口达到 MSS 发送还是发送一个小于 MSS 的报文段，早期 TCP 的实现选择发送小于 MSS 的报文段。
  • 如果发送方和接收方一次发送和接收 MSS 大小的报文段，不会产生问题
  • 若发送方发送了小报文段或接收方打开了小窗口，会导致这个小容器一直不会被合并。
  • 防止接收方打开小窗口：接收方通知一个大小为 $0$ 的窗口后，必须等到 MSS 大小的空间才能通知
  • 合并小容器：接收方延迟发送 ACK ，合并多个 ACK 为一个 ACK，但等待多久或合并多少个 ACK 是合理的？

• Nagle 算法

  

自适应重传

• 自适应重传：如果 TCP 发送方在一定时限内未收到 ACK ，那么就会重传这个报文段，自适应重传是选择这个时限的算法。

• 原始算法

  • 每次发送一个报文段，记录发送时刻，并记录对应 ACK 收到的时刻，计算时间差作为 SampleRTT，然后用以前的估计值 EstimatedRTT 和这个值来古今新的估计值，即

  • 参数 $\alpha$ 的作用是平滑 EstimatedRTT ，原始的 TCP 一般将该值设为 $0.8 \textasciitilde 0.9$ 。超时时限较为保守，设为

• Karn/Partridge 算法

  

  • 重发可能会导致 SampleRTT 过大或过小的情况

  • 解决办法：TCP 重传一个报文段时，停止计算 SampleRTT。同时每次 TCP 重传时，设置超时值为上一次的两倍。

    • 动机：拥塞最可能导致报文段丢失，表面 TCP 源主机对超时反应过于敏感。

• Jacobson/Karels 算法

  • 动机：如果样本变化小，说明 EstimatedRTT 较为可信，但如果样本变化大，说超时值远不止 EstimatedRTT 的两倍

  • 计算方法

    其中 $\delta$ 是 $0\textasciitilde 1$ 之间的小数。

  • 超时值计算为

    通常，$\mu$ 设为 $1$ ，$\varphi$ 设为 $4$。这样，变化小时，TimeOut 与 EstimatedRTT 接近，而大的变化会使 Deviation 决定计算结果

记录边界

TCP 扩展

性能