计算机网络学习笔记

写在读前：

配套使用《计算机网络自顶向下法》与中国大学MOOC平台哈工大微课《计算机网络》。
文中图片侵删，转载需笔者口头同意。

更新日志：

2022.1.22 计网概述、传输层、应用层；

1. 计网概述

1. 通信系统模型

信源->发送设备->信道（易被噪声源干扰）->接收设备->信宿。

2. 计算机网络的定义

计算机网络是一个互连的、自治的计算机集合。

3. 交换网络（ISP）

由交换节点（路由器或交换机）构成的网。

4. Internet的定义

• 组成角度：全球最大的计算机集合；
• 服务角度：为网络应用提供通信服务的通信基础设施；

5. 计算机网络的构成

• 硬件（终端，交换网络）是计算机网络的基础；
• 协议是计算机网络数据交换的规则。

6. 网络协议

为进行网络中数据交换而建立的规则、标准或约定。
协议规定了通信实体之间所交换的信息的格式、意义、顺序、以及针对收到信息或发生的事件所采取的“动作”。

7.协议的三要素：

• 语法：数据与控制信息的结构或格式；
• 语义：需要发出何种控制信息，完成何种动作以及做出何种相应以及差错控制；
• 时序：时间顺序，速度匹配；

8.协议存在形式

大部分为RFC文档，由IETF互联网工程任务组管理。

9.计算机网络的结构

• 网络边缘：主机，网络应用；
• 接入网络，物理介质：有线或无线通信链路；
• 核心网络：互联的路由器（或分组转发设备）。

10. 网络边缘模型

• 客户/服务器模型，客服发送请求，接收服务器响应。
• 对等（peer-peer，P2P）应用模型：无（或不仅依赖）专用服务器。

11. 接入网络的类型

• 住宅（家庭）接入网络；
• 机构接入网络（学校，企业等）
• 移动接入网络。

12. 接入网络的参数：

• 带宽：数据传输速度；
• 接入方式：独占或者共享。

13. 网络核心的关键功能：

• 路由：根据路由算法确定分组从源到目的的传输路径。
• 转发：将分组从路由器的输入端口交换至正确的输出端口。

14. 网络核心解决的基本问题：

• 问题：如何实现数据从源主机通过网络核心送达目的主机？
• 解决：数据交换。

15. 数据交换：

• 电路交换：
  （1. 建立连接（呼叫/电路建立）；
  （2. 通信；
  （3. 释放连接（拆除电路）。
• 电路交换的特点：(1. 资源独占（建立通信链路后使用完毕前不能被其他用户使用）;
  (2. 多路复用：为了解决通信两端必须建立链路的缺点。
• 多路复用种类：
  （1. 频分（FMD）：按频率划分
  （2. 时分（TDM）：按时间划分；
  （3. 波分（WDM）：按光的波长进行划分。
  （4. 码分（CDM）：分配编码信号=（原始数据）*（码片序列），码片序列每个用户唯一。
• 报文交换：报文指源（应用）发送信息整体，比如一个文件；
• 分组交换：分组指把报文拆出来的一系列相对较小的数据包，并附加上代表其地址信息的头，分组交换需要对报文进行拆分与重组；
• 分组交换采用统计多路复用，按需共享链路。
• 分组交换优于报文交换的原因：路线中所有路由器可以并行工作，同时每个路由器需要的缓存更小。
• 分组交换优于电路交换的原因：分组交换允许更多用户同时使用网络，网络资源充分共享，无需呼叫建立。
• 分组交换的缺点：可能产生拥塞（分组延迟和丢失，需要协议处理可靠数据传输和拥塞控制）。

16. 速率

即数据率，或称数据传输速率或比特率，描述单位时间内传输信息量多少，是计算机网络中最重要的性能指标，单位：b/s或bps，kb/s等等。

17. 带宽

• 通信领域：指信号具有的频带宽度，即最高频率与最低频率之差，单位是赫兹；
• 计算机网络：数字信道所能传达的“最高数据率”，单位b/s（bps）。

18.延迟/时延（四种分组延迟）

• 节点处理延迟：差错检测， 确定输出链路，通常小于毫秒级。
• 排队延迟：等待输出链路可用，取决于路由器拥塞程度。
• 传输延迟：取决于分组长度，链路带宽。
• 传播延迟：取决于物理链路长度与信号传播速度。

19.时延带宽积

时延带宽积 = 传播延迟 * 带宽，又称为以比特为单位的链路长度；

20.分组丢失（丢包）

• 原因：队列缓存容量有限；
• 定义：分组到达已满队列将被丢弃；
• 处理：丢弃分组可能由前序节点或源重发。

21. 丢包率

丢包率 = 丢包数/已发分组总数；

22. 吞吐量/率

表示在发送端与接收端之间数据速率。

• 即时吞吐量：给定时刻的速率；
• 平均吞吐量：一段时间的平均速率。

23. OSI参考模型（七层模型）

• 物理层
• 数据链路层
• 网络层
• 传输层
• 会话层
• 表示层
• 应用层

24. 1974年网络互联基本原则

极简、自治、尽力服务模型、无状态路由器、分散控制。

2. 应用层

2.1 网络应用的基本原理

1. 网络应用的体系结构

• 客户机/服务器结构（Client-Server，C/S）
  • 服务器：对外提供服务；
  • 客户机：使用服务器提供的服务；
• 点对点结构（Peer-to-peer，P2P）
  • 没有永远在线的服务器；
  • 任意端系统/节点之间可以直接通信
• 混合结构（Hybrid）
• P2P与C/S对比：
  • 优点：高度可伸缩；
  • 缺点：难于管理。

2. 不同主机上运行的进程间如何通信——信息交换

• 客户机进程：发起通信的进程；
• 服务器进行：等待通信请求的进程；
• 进程间利用socket发送/接收消息。
• 进程间通信的寻址：主机IP地址+端口号。

3. 网络应用对传输服务的需求

• 数据丢失/可靠性；
• 时间/延迟；
• 带宽；
• 其他等等。

4. Internet提供的传输服务

TCP服务	UDP服务
面向连接：客户机/服务器进程需要建立连接	无连接
可靠的传输	不可靠的数据传输
流量控制：发送方不会发送速度过快，超过接收方处理能力	不提供
拥塞控制：当网络负载过重时能够限制发送方的发送速度	不提供
不提供时间/延迟保障	不提供
不提供最小宽带保障	不提供

2.2 Web应用

1. 统一资源定位器：（URL：Uniform Resoure Locator）

Seheme://host:port/path

协议（可省略）/主机:端口号/路径

2. HTTP协议：（HyperText Transfer Protocol，超文本传输协议）

• 采用C/S结构；
• 客户——Browser（浏览器）：请求、接收、展示Web对象；
• 服务器——Web Server：相应客户的请求，发送对象；
• 使用TCP传输服务；
• 端口80；
• 是一个无状态协议：服务器不维护任何有关客户端过去所发请求的信息；
• 采取请求/响应模式（都为ASCII文本）。

3. HTTP协议与TCP传输服务：

• 服务器再80端口等待客户的请求；
• 浏览器发起到服务器的TCP连接（创建套接字Socket）；
• 服务器接受来自浏览器的TCP连接；
• 浏览器（HTTP客户端）与Web服务器（HTTP服务器）交换HTTP消息；
• 关闭TCP连接。

4. HTTP连接的两种类型：

非持久性连接	持久性连接
每个TCP连接最多允许传输一个对象	每个TCP连接允许传输多个对象
HTTP 1.0版本使用非持久性连接	HTTP 1.1版本默认使用持久性连接

5. HTTP请求消息的格式：

method + sp + URL + sp + version （请求行）
header field name+:+value（头部行）

......

header field name+:+value（头部行）
（空行）
Entity Body（数据体）

6. HTTP 1.1中的方法

• GET：请求数据；

• POST：提交数据；

• HEAD：请Server不要将所请求的对象放入相应消息中；

• PUT：将消息体中的文件上传到URL字段所指定的路径；

• DELETE：删除URL字段所指定的文件。

7. HTTP响应消息的格式：

version + sp + status code（状态行）
header field name+:+value（头部行）

......

header field name+:+value（头部行）
（空行）
Entity Body（数据体）

8. 状态代码：

• 200 OK
• 301 Moved Permanently
• 400 Bad Request
• 404 Not Found
• 505 HTTP Version Not Supported
• …

9. Cookie技术

某些网站为了辨别用户身份、进行session跟踪而存储再用户本地终端上的数据（通常经过加密），是架设在HTTP上的一个组件。

组成部分：

• HTTP响应消息的cookie头部行；
• HTTP请求消息的cookie头部行；
• 保存在客户端主机上cookie文件，由浏览器管理；
• Web服务器端的后台数据库。

10. 缓存技术

• 功能：在不访问服务器的前提下满足客户端的HTTP请求。
• 作用：缩短客户请求的响应时间，减少机构/组织的流量，在大范围内实现有效的内容分发。
• 实现：通过在客户和服务器之间架设代理服务器。

2.3 Email应用

1. Emial应用的构成组件：

• 邮件客户端；
• 邮件服务器；
• SMTP协议；

2. 邮件客户端：

• 读、写Email消息；
• 与服务器交互，收、发Email消息；
• Outlook，Foxmail，Thunderbird;
• Web客户端。

3. 邮件服务器：

• 邮箱：存储发给用户的Email；
• 消息队列：存储等待发送的Email；

4. SMTP协议：

• 邮件服务器之间传递消息所使用的协议；

• 客户端：发送消息的服务器；

• 服务器：接收消息的服务器。

• 使用TCP进行email消息的可靠传输；

• 端口25；

• 传输过程的三个阶段：（1 握手（2 消息的传输（3 关闭；

• 采用命令/响应的模式：命令为ASCII文本，响应为状态代码和语句。

5. 邮件访问协议：从服务器获取邮件；

• POP（Post Office Protocol）：认证/授权（客服端<–>服务器）和下载；

• IMAP（Internet Mail Access Protocol）：更多功能，更加复杂，能够操纵服务器上存储的消息。

• HTTP：163，QQ Mail等。

2.4 DNS应用

1. 域名解析系统DNS（Domain Name System）

• Internet上主机/路由器有两套识别方式（1IP地址，（2域名；
• DNS解决了域名和IP地址之间的映射问题；
• 多层命令服务器构成的分布式数据库；
• 属于应用层协议：完成名字的解析。
• 查询/回复模式；
• 端口53。

2. 分层分布式服务器

• 根服务器；
• 顶级域名服务器；
• 权威域名服务器；
• 本地域名服务器（不属于层级体系），所有查询使用本地域名服务器作为代理转发给层级服务器系统，同时对查询过的域名进行缓存。

3. DNS查询方式

• 迭代查询；
• 递归查询。

2.5 P2P应用：暂缺；

2.6 套接字编程：暂缺；

3. 传输层

3.1 传输层概述

1. 传输层的功能

为运行再不同Host上的进程提供了一种逻辑通信机制。

2. 端系统传输层协议的运行

• 发送方：将应用递交的消息分成一个或多个的Segment（报文），并向下传给网络层。
• 接收方：将接收到的Segment组装成消息，并向上交给应用层。

3. 网络层和传输层的区别：

• 网络层提供主机之间的逻辑通信机制，传输层提供应用进程之间的逻辑通信机制；
• 传输层位于网络层之上，依赖于网络层，对网络层的服务进行（可能性）增强；

4. Internet传输层协议（TCP和UDP）

1. 可靠的、按序的交付服务（TCP）

   • 拥塞控制
   • 流量控制
   • 连接建立

2. 不可靠的交付服务（UDP）

   • 基于“尽力而为”的网络层，没有做（可靠性方面的）拓展。

3. 两种服务都不提供延迟和带宽方面的保障；

3.2 多路复用和多路分用

1. 多路复用和多路分用解决的问题

如果某层的一个协议对应直接上层的多个协议/实体，则需要复用/分用。

2. 接收端进行多路分用

传输层依据头部信息将收到的Segment交给正确的Socket，即不同的进程。

3. 发送端进行多路复用

从多个Socket接收数据，为每块数据封装上头部信息，生成Sgement，交给网络层。

4. UDP无连接分用

利用（源端口号，目的端口号）构成的二元组进行标识。

5. TCP面向连接的分用

利用（源IP地址，源端口号，目的IP地址，目的端口号）构成的四元组进行标识，一个客户机进程对应一个服务器进程。

3.3 UDP（User Datagram Protocol）

1. 基于Internet IP协议，UDP提供的功能

• 复用/分用；
• 简单的错误校验。

2. UDP的特点

• 无连接：UDP发送方和接收方不需要握手；
• 每个UDP报文段的处理独立于其他段。

3. UDP的价值

• 无需建立连接（减少延迟）；
• 实现简单：无需维护连接状态；
• 头部开销少；
• 没有拥塞控制：应用可更好地控制发送时间和速率。

4. UDP的用途

• 流媒体应用：容忍丢失，速率敏感；
• DNS和SNMP；

5. UDP报文的格式

source port #（源端口号）	dest port #（目的端口号）
length（UDP段的长度，包含头部）	checksum（校验和）
Application data

6. UDP校验和

• 目的：检测UDP段在传输中是否发生错误；

• 发送方：

  • 将段的内容视为16-bit的整数（16位2进制）；
  • 校验和计算：计算所有整数的和，超过16位的进位加在和的后面，将得到的和值按位求反，得到校验和；
  • 发送方将校验和放入校验和字段。

• 接收方：

  • 计算所接收到的校验和；
  • 将其与校验和字段进行对比；
    • 不相等：检测出错误；
    • 相等：没有检测除错误（但可能有错误）。

3.4 可靠数据传输（rdt）的基本原理

1. 可靠数据传输协议基本结构：接口

• rdt_send()：被上层应用调用，将数据交给rdt以发送给对方；
• udt_send()：被rdt调用，在不可靠信道上向接收方传输数据；
• rdt_rcv()：当数据包达到接收方信道时被调用；
• deliver_data()：被rdt调用，向上层应用交付数据。
• rdt与应用层之间的交互为单向，与网络层之间的交互为双向。

2. Rdt 1.0：可靠信道上的可靠数据传输

• 底层信道完全可靠
  • 不会发生错误；
  • 不会丢失分组；
• 发送方和接收方的FSM（有限状态自动机）独立

3. Rdt 2.0：产生位错误的信道

• 差错检验的机制：校验和检验位错误；

• 解决机制：

  • 接收方反馈控制信息：

    • ACK：接收方显式地告知发送方分组已正确接收；

    • NAK：接收方显式地告知发送方分组有错误；

  • 发送方收到NAK后，重新分组；

• 基于这种重传机制的rdt协议称为ARQ协议；

4. Rdt 2.0中FSM的规约

• Sender图示：

• 两个状态，停—等协议：

  • 两个状态：

    • Wait for call from above ：初始状态；
    • Wait for ACK or NAK：在上层应用发送调用指令后进入的状态；

  • 状态转移：

    • Wait for call from above 到 Wait for ACK or NAK：通过上层调用rdt_send(data)指令；
    • Wait for ACK or NAK 到 Wait for ACK or NAK：rdt_rcv(rcvpkt)回传指令为NAK；
    • Wait for ACK or NAK 到 Wait for call from above：rdt_rcv(rcvpkt)回传指令为ACK；

  • 状态动作：

    • Wait for call from above：
      • snkpkt = make_pkt(data,checksum) 计算校验和并将数据打包；
      • udt_send(sndpkt) 发送数据；
    • Wait for ACK or NAK：
      • 接收rdt_rcv回传的信号；
      • 为udt_send中的数据创立缓存。
      • udt_send(sndpkt) 进行数据重传；

• Receiver图示：

  

• 单一状态：

  • Wait for call from below：等待下层调用；
  • 状态转移（自转移）：
    • rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)通过计算校验和判断数据无错位
    • rdt_rcv(rcvpkt)&&corrupt(rcvpkt)数据有错位；
  • 转移进行的动作
    • rdt_rcv(rcvpkt)&&corrupt(rcvpkt)：
      • udt_send(NAK)；
    • rdt_rcv(rcvpkt)&¬corrupt(rcvpkt)：
      • extract(rcvpkt,data) 解析数据；
      • deliver_data(data) 传递数据；
      • udt_send(ACK)；

4. Rdt 2.1：返回的控制信息也产生错误

• 解决机制：引入序列号机制，只有0和1两种序列号，返回消息为控制信息+序列号；
• 接收端遇到报文段序列号重复则删除；
• Sender状态为4个，Receiver为两个；

5. Rdt 2.2：不使用NAK消息

• 不再使用NAK消息，只返回ACK消息和最后一个识别成功的序列号；

6. Rdt 3.0：信道极可能发生位错误，也可能丢失分组

• 分组丢失造成的后果：发送方一直等待下去；

• 解决机制：

  • 发送方等待合理的时间；
  • 如果没有收到ACK，进行重传；
  • 如果分组或ACK只是延迟而不是丢了：
    • 重传会产生重复，但序列号机制能够处理；
    • 接收方需在ACK中显式告知所确认的分组；
  • 需要添加定时器。

• 性能极差，约1Gb链路1s传输33kb数据。

• 性能差原因：停等协议。

3.5 流水线机制与滑动窗口协议

1. 流水线机制

• 发送方在收到ACK之前连续发送多个分组；
  • 需要更大的序列号范围；
  • 发送方和/或接收方需要更大的存储空间以缓存分组。

2. 滑动窗口协议（Sliding-window protocol）

• 窗口：

  • 允许使用的序列号范围；
  • 窗口尺寸为N：最多有N个等待确认的消息。

• 滑动窗口：随着协议的运行，窗口在序列号空间内向前滑动；

• 滑动窗口协议：GBN，SR。

3. Go-Back-N 协议（GBN）

• 分组头部包含k-bit序列号；

• 窗口尺寸为N，最多允许N个分组未确认。

• 累计确认，ACK(n)：确认到序列号n（包含n）的分组均已被正确接收；

• 为空中的分组设置计时器（timer）；

• 超时Timeout(n)事件，重传序列号大于等于n，还为收到ACK的所有分组。

4. GBN 中的FSM

• Sender：

  

• Receiver：

• ACK机制：发送拥有最高序列号、已被正确接收的分组的ACK

  • 可能产生重复ACK；
  • 只需要记住唯一的expectedseqnum；

• 乱序到达的分组：

  • 直接丢弃，接收方没有缓存；
  • 重新确认序列号最大的、按序到达的分组。

5. Selective Repeat协议（SR）

• 解决了GBN协议中重复发送段数过多的问题；

• 接收方对每个分组单独确认：

  • 设置缓存机制，缓存乱序到达的分组；

• 发送方只重传那些没收到ACK的分组：

  • 为每个分组设置定时器；

• 发送方窗口：

  • N个连续的序列号；
  • 限制已发送且未确认的分组；

• 设置接收方窗口；

3.6 面向连接传输协议-TCP

1. TCP概述

• 点对点：一个发送方，一个接收方；

• 可靠的、按序的字节流；

• 流水线机制：TCP拥塞控制和流量控制机制设置窗口尺寸；

• 发送方/接收方缓存；

• 全双工：同一连接中能够传输双向数据流；

• 面向连接：

  • 通信双方在发送数据之前必须建立连接；

  • 连接状态只能在连接的两端维护，在沿途节点中并不能维护状态；

  • TCP连接包括：两台主机上缓存、连接状态变量、socket等。

• 流量控制、拥塞控制机制。

2. TCP段结构

• 项描述（从上到下从左到右）
  • source port # ：源端口号；
  • dest port # ：目的端口号；
  • sequence number：序列号，以字节数计数；
    • 序列号指的是segment中的第一个字节的编号，而不是segement的编号；
    • 建立TCP连接时，双方随即选择序列号；
  • acknowledgement number：ACK序列号，以字节数计数；
    • 表示希望接收到的下一个字节的序列号；
    • 使用累计确认机制：该序列号之前的所有字节均已被正确接收到。
  • head len：头部长度；
  • not used：
  • U（URG：urgent data）：紧急数据；
  • A（ACK# valid）：标志ACK是否有效；
  • P（push data now）：依据此标志将数据即刻发送到上层；
  • R、S、F：连接建立和拆除相关标志位；
  • Receive window：接收窗口大小，表示所能接收字节的数目，用来进行流量控制；
  • checksum：校验和。

2. 关于乱序到达的数据的处理

• GBN：根据累计确认机制，直接丢弃；
• SR：根据缓存机制，在滑动窗口内的纳入缓存，否则丢弃；
• TCP：没有规定，由TCP的实现者做出决策。

3. TCP的可靠数据传输

• 不考虑拥塞控制和流量控制时，基于（流水线机制，累计确认机制，单一重传计时器机制）在IP层提供的不可靠服务基础上，实现可靠数据传输服务。
  • 触发重传的事件：
    • 超时；
    • 收到重复的ACK。

4. 定时器超时时间的设置

• 基于RTT设置，过短造成不必要的重传，过长则对段丢失时间反应慢；

• RTT的估算：

  • SampleRTT：测量从段发出去到收到ACK的时间（忽略重传）
  • SampleRTT变化：测量多个SampleRTT，求平均值，形成RTT的估计值EstimatedRTT；
    • $ EstimatedRTT = ( 1 - α ) * EstimatedRTT + α * SampleRTT $（α的典型值：0.125）

• 定时器超时时间设置：

  • EstimatedRTT + “安全边界”；
  • EstimatedRTT变化大->较大的边界

• 测量RTT的变化值：SampleRTT与EstimatedRTT的差值：

  $ DevRTT = (1 - β ) * DevRTT + β * | SampleRTT - EstimatedRTT | $（β的典型值：0.25）

• 定时器超过时间的设置：$TimeoutInterval=EstimatedRTT+4\ast DevRTT$

5. TCP发送方事件

• 从应用层收到数据
  • 创建Segement；
  • 序列号是Segement第一个字节的编号；
  • 开启计时器；
  • 设置超时时间TimeOutInterval。
• 超时：
  • 重传引起超时的Segement；
  • 重启定时器。
• 收到ACK：
  • 如果确认此前未确认的Segement：
    • 更新SendBase
    • 如果窗口中还有未被确认的分组，重新启动定时器。

6. TCP接收方事件

• 按序收到Segement：延迟等待500ms，再发送ACK信号；
  • 在等待时如果有下一个Segement按序到达，则立马发送更新后的ACK信号，进入下一个等待时间；
  • 等待结束发送ACK信号。
• 若Segement乱序到达，则立刻发送缺失Segement的ACK。

7. 快速重传机制

• TCP的实现中如果发生超时，超时时间间隔讲重新设置加倍，导致等待时间过长；
• 通过重复ACK检测到分组丢失：如果sender收到对同一个数据的3个ACK，则假定该数据之后的段已经丢失，执行快速重传：
  • 在定时器超时之前即进行重传。

8. TCP连接建立的三次握手机制

• 建立连接的内容：

  • 初始化TCP的变量：

    • 序列号和控制信息序列号；
    • Buffer大小和流量控制信息等。

  • Client为发起者：Socket clientSocket = new Socket("hostname","port number");

    Server等待客户连接请求：Socket connectionSocket = welcomeSocket.accept();

• 三次握手机制：

  • 第一步：客户主机向服务器发送SYN报文段；

    • SYN报文段：段结构中SYN标志位为1，携带随机选择的一个序列号client_isn。

  • 第二步：服务器向主机答复一个SYNACK报文段；

    • 服务器为该用户分配缓存和资源；
    • SYNACK报文段：段结构中SYN标志位为1，携带确认信息序列号为client_isn+1，同时携带一个自身的序列号server_isn。

  • 第三步：客户机收到SYNACK报文段，答复ACK报文段；

    • ACK报文段：SYN标志为为0，携带序列号为client_isn，确认信息序列号为server_isn+1。

9. 连接的拆除

• 第一步：客户主机发送FIN报文段（FIN标志位为1）；
• 第二步：服务器向主机发送确认报文段；
• 第三步：服务器发送终止报文段，FIN位为1；
• 第四步：客户主机向服务器发送确认报文段；。

3.7 流量控制：端到端的速度匹配机制

1. buff溢出

上层应用可能处理buffer中数据的速度慢于传输速度，造成数据溢出，将接收方的缓冲区淹没。

2. 处理机制

• Receiver通过Segement的头部字段将RcvWindow告诉Sender；

• Sender限制自己已经发送的但还未收到ACK的数据不超过接收方的空闲RcvWindow尺寸；

• RcvWindow的计算：

  • 定义一下变量：

    • LastByteRead：接收方主机上的应用进程从缓存读出的数据流的最后一个字节的编号；
    • LastByteRcvd：从网络中到达的已放入接收方主机接收缓存中的数据流的最后一个字节的编号。

  • 由于TCP不允许已分配的缓存溢出，下式必须成立

    $ LastByteRcvd - LastByteRead \leq RcvBuff $

    故 $ RcvWindow = RcvBuff - [ LastByteRcvd - LastByteRead ] $

• RcvWindow = 0 ,即缓存已满时：

  • 发送方将继续发送只有一个字节数据的报文段，如果被接收方接收并回传控制信号，则说明缓存已开始清空。

3.8 拥塞控制：整个网络的社会性问题

1. 拥塞

• 非正式定于：太多发送主机发送了太多数据或者发送速度太快，以至于网络无法处理。

• 表现：

  • 分组丢失（路由器缓存溢出）
  • 分组延迟过大（在路由器缓存中排队）

2. 拥塞控制和流量控制的区别

• 流量控制对象为端到端的个体，拥塞控制对象为网络群体。

3. 拥塞的成因和代价

3.1 场景1：假设路由器缓存无限，针对时延研究

• 两个发送方与两个接收方共用一个路由器，带宽为C，缓存无限。${\lambda }_{in}$ 表示senders发送速率，$\lambda out$ 表示receivers接受速率。
• 缓存无限，不考虑分组丢失，即不考虑重传机制。

• 拥塞代价：分组时延过大。

3.2 场景2：路由器缓存有限

• 两个发送方与两个接收方共用一个路由器，带宽为R，缓存有限。${\lambda }_{in}$ 表示senders发送速率，$\lambda out$ 表示receivers接受速率。$\lambda {’}_{in}$ 表示senders发送和重传复合速率。

• 情况a：Sender能够通过某种机制获知路由器buffer信息，有空闲才进行传输，${\lambda }_{in}={\lambda }_{out}$ 。

  情况b：没有机制，丢失后才重发，${\lambda }_{in}^{\prime }>{\lambda }_{out}$ 。进行重传会影响发送速率。

  情况c：分组丢失和定时器超时都重发，${\lambda }_{in}^{\prime }$更大。

3.3 场景3：多跳多发送与接受方的复杂网络

• 拥塞代价：当分组被drop时，任何用于该分组的”上游“传输能力全都被浪费掉，速率复合性降低。

4. 拥塞控制原理

• 端到端的拥塞控制：

  • 网络层不需要显式的提供支持；
  • 端系统通过观察loss，delay等网络行为判断是否发送拥塞；
  • TCP采取这种方法。

• 网络辅助的拥塞控制：

  • 网络层路由器向发送方显式地反馈网络拥塞信息；
  • 简单地拥塞提示(1bit)；
  • 指示发送方应该采取何种速率。

• 例：ATM中的”ABR拥塞控制“：

  发送方在data cell中穿插RM cell，路径中的交换机设置RM cell 位，由接收方返回给发送方。

  • RM cell位：
    • NI bit：rate不许增长；
    • CI bit：拥塞指示。
    • 显式的速率ER字段 ，两个字节：
      • 拥塞的交换机可以将ER置为更低的值；
      • 发送方获知路径所能支持的最小速率。
  • date cell中的EFCI位：拥塞的交换机将其设为1
    • 如果RM cell前面的data cell的EFCI位被设为1，那么发送方在返回中设置RM cell中CI位。

3.9 TCP拥塞控制原理

1. 基本原理

• Sender通过调整滑动窗口大小CongWin来限制发送速率。

• $ LastByTeSent - LastByteAcked \leq CongWin$

  $ rate \approx \frac{CongWin}{RTT} Bytes/sec $

2. 网络堵塞的信号——Loss事件：timeout或3个重复的ACK

3. 调节发送速率的实现方式

• 加性增，乘性减（AIMD）：

  • 逐渐增加发送速率，谨慎探测可用宽带；
  • 线性增加速率，折半型降低速率。

• 慢启动（SS）：

  • 当连接开始时，指数型增长。

• SS切换到AIMD模式：

  • 设置变量Threshold初始值，当慢启动CongWin值超过Threshld初始值时，CongWin值转换为加性增线性增长，当发生Loss事件时，CongWin值进行乘性减折半或者设为1，并将Threshold值更新位Loss事件值的一半。
  • 对Loss事件的处理：
    • 3个重复的ACKs：
      • CongWin折半，然后线性增长；
    • Timeout事件：
      • CongWin直接设为1个MSS，然后指数型增长，达到Theshold时，再线性增长。

4. 拥塞控制算法

	Threshold = ? //初始化Threshold值
	CongWin = 1 MSS //初始化CongWin大小
	
    while(TCP connection)
    {
        //慢启动，进行指数型增长
        while(No Packet Loss && CongWin < Threshold)
        {
            send CongWin TCP segments;
            for each ACK increase CongWin by 1;
            //每收到一个ACK信号CongWin便增加1
        }

        //加性增，线性增长
        while(No Packet Loss)
        {
            send CongWin TCP segments;
            for CongWin ACKs,increase CongWin by 1;
            //每次增加1
        }

        Threshold = CongWin/2;
        if(3 CupACKs) CongWin = Threshold;
        if(timeout) CongWin = 1;
    }

5. 公平性与吞吐率：暂缺。