我们假设 Alice 想给 Bob 发送一封简单的 ASCII 报文

• Alice 调用她的邮件代理程序并提供 Bob 的邮件地址 （例如 bob@someschool.edu），编写邮件报文，然后指示用户代理发送该报文
• Alice 的用户代理把报文发送给她的邮件服务器，在那里该报文被放在消息队列中。
• 运行在 Alice 的邮件服务器上的 SMTP 客户端发现了报文队列中的邮件，它就创建一个到运行在 Bob 邮件服务器上的 SMTP 服务器的 TCP 连接
• 在经过一些初始化 SMTP 握手后，SMTP 客户端通过该 TCP 连接发送 Alice 的邮件。
• 在 Bob 的邮件服务器上，SMTP 的服务端接收该邮件，Bob 的邮件服务器将邮件放在 Bob 的邮箱中
• 在 Bob 想要看邮件时，他会调用用户代理阅读该邮件 上面说的邮件其实就是报文，指的就是一系列 ASCII 码，SMTP 传输邮件之前，需要将二进制多媒体数据编码为 ASCII 码进行传输。

SMTP 一般不使用中间邮件服务器发送邮件，即使这两个邮件服务器位于地球的两端也是这样的。TCP 连接通常直接连接 Alice 的邮件服务器和 Bob 的邮件服务器。

现在你知道了两台邮件服务器邮件发送的大体过程，那么，SMTP 是如何将邮件从 Alice 邮件服务器发送到 Bob 的邮件服务器的呢？主要分为下面三个阶段：

• 建立连接：在这一阶段，SMTP 客户请求与服务器的 25 端口建立一个 TCP 连接。一旦连接建立，SMTP 服务器和客户就开始相互通告自己的域名，同时确认对方的域名。
• 邮件传送：一旦连接建立后，就开始邮件传输。SMTP 依靠 TCP 能够将邮件准确无误地传输到接收方的邮件服务器中。SMTP 客户将邮件的源地址、目的地址和邮件的具体内容传递给 SMTP 服务器，SMTP 服务器进行相应的响应并接收邮件。
• 连接释放：SMTP 客户发出退出命令，服务器在处理命令后进行响应，随后关闭 TCP 连接。

下面我们分析一个实际的 SMTP 邮件发送过程，以下统称为SMTP客户(C)和 SMTP服务器(S)。客户的主机名为 crepes.fr，服务器的主机名为 hamburger.edu。以 C: 开头的 ASCII 码文本就是客户交给 TCP 套接字的那些行，以 S: 开头的 ASCII 码则是服务器发送给其 TCP 套接字的那些行。一旦创建了连接，就开始了如下过程：

S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <alice@crepes.fr>
S: 250 alice@crepes.fr ... Sender ok
C: RCPT TO: <bob@hamburger.edu>
S: 250 bob@hamburder.edu ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
    S: 221 hamburger.edu closing connection

在上述例子中，客户从邮件服务器 crepes.fr 向邮件服务器 hamburger.edu 发送了一个报文 (" Do you like ketchup? How about pickles? “) 。作为对话的一部分，该客户发送了 5 条命令: HELO(是 HELLO 的缩写)、 MAMIL FROM、RCPT TO、DATA 以及 QUIT。这些命令都是自解释的。 什么是自解释，就是不需要再进行解释了，命令自己就能解释自己所要表述的功能。

上面是一个简单的 SMTP 交换过程，包括了连接建立、邮件传送和连接释放三个具体过程。

• 首先建立 TCP 连接、SMTP 调用 TCP 协议的 25 号端口监听连接请求，然后客户端发送 HELO 指令用来表明自己是发送方的身份，然后服务端作出响应。
• 然后，客户端发送 MAIL FROM 命令，表明客户端的邮件地址是 <alice@crepes.fr>，服务器以 OK 作为响应，表明准备接收。
• 客户端发送 RCPT TO 表明接收方的电子邮件地址，可以有多个 RCPT 行，即一份邮件可以同时发送给多个收件人。服务器端则表示是否愿意为收件人接收邮件。
• 协商结束后，客户端用 DATA 命令发送信息，结束标志是CRLF.CRLF ，也就是 回车换行.回车换行。
• 最后，控制交互的任一端可选择终止会话，为此它发出一个 QUIT 命令，另一端用命令 221 响应，表示同意终止连接，双方将关闭连接。

上述过程中会涉及几个类似 HTTP 的状态码。250 就表示 OK ，类似 HTTP 的 200。在命令成功时，服务器返回代码 250，如果失败则返回代码 550（命令无法识别）、451（处理时出错）、452（存储空间不够）、421（服务器不可用）等，354 则表示开始信息输入。

SMTP 的报文会有局限性，SMTP 的局限性表现在只能发送 ASCII 码格式的报文，不支持中文、法文、德文等，它也不支持语音、视频的数据。通过 MIME协议，对 SMTP 补充。MIME 使用网络虚拟终端(NVT)标准，允许非 ASCII 码数据通过 SMTP 传输。

SMTP 与 HTTP 的对比

这两个协议都用于从一台主机向另一台主机传送文件：HTTP 从 Web 服务器向 Web 客户端（通常是浏览器）传送文件，SMTP 是从一个邮件服务器向另一个邮件服务器传送文件（即电子邮件报文）。 这两个协议也会有几个重要的区别

• 首先，HTTP 是一个 拉协议(pull protocol)，客户端发送请求，请求获取服务端的资源，然后服务端进行响应，把需要下载的文件传输给客户端；而 SMTP 是一个 推协议(push protocol)，SMTP 的客户端会主动把邮件推送给 SMTP 的服务端。
• 第二个区别是，SMTP 要求每个报文都采用 7 比特的 ASCII 码格式，如果某报文包含了非 7 比特的 ASCII 自负或二进制数据，则该报文必须按照 7 比特 ASCII 码进行编码。HTTP 数据则不受这种限制。
• 第三个区别是如何处理一个既包含文本又包含图形的文档，HTTP 把每个对象封装到它自己的 HTTP 响应报文中，而 SMTP 则把所有报文对象放在一个报文之中。

邮件访问协议

在上述分析中，有一个疏漏的环节，那就是在 Alice 向 Bob 发送邮件的过程中，Bob 是如何通过运行在他本地 PC 上的用户代理，获得位于某 ISP 的邮件服务器上的他的邮件呢？注意到 Bob 的用户代理不能使用 SMTP 来取回邮件，因为取邮件时一个拉操作，而 SMTP 是一个推协议。因此我们要引入邮件访问协议，包括第三版的邮局协议（POP3）、因特网邮件访问协议（IMAP）以及 HTTP。 　　下图总结了应用于因特网电子邮件的一些协议：SMTP 用来将邮件从发送发的邮件服务器传输到接收方的邮件服务器。如 POP3 这样的邮件访问协议用来将邮件从接收方的邮件服务器传送到接收方的用户代理。

1）POP3

• POP3 是 Post Office Protocol 3 的简称，即邮局协议的第 3 个版本，是 TCP/IP 协议族中的一员（默认端口是 110）。
• 它被用户代理用来邮件服务器取得邮件。POP3 采用的也是 C/S 通信模型，对应的 RFC 文档为 RFC1939。
• POP3 支持电子邮件客户端下载服务器上的邮件，但是在客户端的操作（如移动邮件、标记已读等），不会反馈到服务器上，比如通过客户端收取了邮箱中的 3 封邮件并移动到其他文件夹，邮箱服务器上的这些邮件是没有同时被移动的 。
• POP3 使用明文传输密码, 不对密码加密
• POP3 建立在 TCP 连接上, 使用的是有连接的可靠数据传输服务

1. IMAP

• IMAP 全称是 Internet Mail Access Protocol，即互联网邮件访问协议，是一个应用层协议（端口是 143）。用来从本地邮件客户端（Outlook Express、Foxmail、Mozilla Thunderbird 等）访问远程服务器上的邮件。
• 开启了 IMAP 后，您在电子邮件客户端收取的邮件仍然保留在服务器上，同时在客户端上的操作都会反馈到服务器上，如：删除邮件，标记已读等，服务器上的邮件也会做相应的动作。所以无论从浏览器登录邮箱或者客户端软件登录邮箱，看到的邮件以及状态都是一致的。

1. 基于 Web 的电子邮件　当用户用 Web 浏览器使用电子邮件时，用户和他远程邮箱之间的通信则通过 HTTP；然而，用户的邮件服务器在与其他的邮件服务器之间发送和接收邮件时，仍然使用的是 SMTP。

CDN 内容分发

网络视频需要消耗大量的网络带宽，很多网络视频公司会选择 CDN （Content Distribution Network）服务，来优化用户的体验。 一个 CDN 网络管理很多分布在世界各地的服务器，在每个服务器上复制了视频和其它资源文件的副本，用户请求 CDN，然后 CDN 提供一个离用户客户端距离较近的服务器同响应客户端请求，从而给用户更快更好的网络体验。CDN 的实现是利用了 DNS 拦截和重定向请求功能。

不使用 CDN 可能会出现的问题 每个客户端都请求同一个地区的服务器（数据中心），服务器的带宽是一定的，请求太多造成客户端得到的资源吞吐量下降，会导致视频卡顿。 一个流行的视频会在同一个通信链路上多次传输，浪费网络带宽。 一个数据中心容易出现单点故障，导致整个服务不可用。

CDN 使用的过程

1. 用户访问一个视频的链接，如 http://video.netcinema.com/6Y7B23V 。
2. 浏览器查询客户端本地缓存是否存在该域名的 IP 地址。如果没有，继续下一步查询。
3. 浏览器请求本地 DNS 服务器，查询 video.netcinema.com 域名的 IP 地址。本地 DNS 服务器检查本地缓存是否存在该域名，不存在，则请求权威 DNS 服务器，查询 video.netcinema.com 的 IP 地址。权威 DNS 服务器发现是 video 开头的域名，则返回 CDN 提供商的权威域名如 a105.kingcdn.com。
4. 本地 DNS 服务器请求权威域名服务器，查询 a105.kingcdn.com 的 IP 地址，CDN 提供商根据客户端的地理位置，最终返回 CDN 系统中的一个 web 服务器 IP 地址。
5. 本地 DNS 服务器把 IP 地址返回给浏览器。
6. 浏览器通过 IP 地址与服务器建立 TCP 连接，发送视频访问请求。web 服务器返回视频内容给浏览器。

CDN 是如何让客户端访问离自己最近的一个服务器 方法一：使用 DNS 服务器响应一个离用户最近的服务器的 IP 地址。DNS 服务器通过查询 IP 位置数据库，获取客户端所在的城市。根据客户端所在的城市选一个最近的一个服务器的 IP 地址返回给客户端。 方法二：使用任播（Anycast）路由选择一个最近的服务器。CDN 分布世界各地的所有 Web 服务器使用同一个 IP 地址。路由器根据最少花费（Lowest Cost）的路由规则，选择一个离客户端最近的服务器。

FTP

简介

文件传送协议 FTP (File Transfer Protocol) 是互联网上使用得最广泛的文件传送协议。 FTP 提供交互式的访问，允许客户指明文件的类型与格式，并允许文件具有存取权限 网络环境下复制文件的复杂性：

• 计算机存储数据的格式不同。
• 文件的目录结构和文件命名的规定不同。
• 对于相同的文件存取功能，操作系统使用的命令不同。
• 访问控制方法不同。

正是因为网络环境下复制文件的复杂性，因此就需要用到了 FTP 协议了。

过程

1. 打开熟知端口（端口号为 21），使客户进程能够连接上。
2. 等待客户进程发出连接请求。
3. 启动从属进程来处理客户进程发来的请求。从属进程对客户进程的请求处理完毕后即终止，但从属进程在运行期间根据需要还可能创建其他一些子进程。
4. 回到等待状态，继续接受其他客户进程发来的请求。主进程与从属进程的处理是并发地进行。
5. 当客户进程向服务器进程发出建立连接请求时，要寻找连接服务器进程的熟知端口 (21)，同时还要告诉服务器进程自己的另一个端口号码，用于建立数据传送连接。
6. 接着，服务器进程用自己传送数据的熟知端口 (20) 与客户进程所提供的端口号码建立数据传送连接。
7. 由于 FTP 使用了两个不同的端口号，所以数据连接与控制连接不会发生混乱。

FTP 是使用了两个 TCP 连接的。好处：

• 使协议更加简单和更容易实现。
• 在传输文件时还可以利用控制连接（例如，客户发送请求终止传输）。

P2P

我们上面探讨的协议 HTTP、SMTP、DNS 都采用了客户-服务器 模式，这种模式会极大依赖总是打开的基础设施服务器。而 P2P是客户端与客户端模式，对总是打开的基础设施服务器有最小的依赖。

P2P 的全称是 Peer-to-peer, P2P，是一种分布式体系结构的计算机网络。在 P2P 体系中，所有的计算机和设备都被称为对等体，他们互相交换工作。对等网络中的每个对等方都等于其他对等方。网络中没有特权对等体，也没有主管理员设备。

从某种意义上说，对等网络是计算机世界中最平等的网络。每个对等方都相等，并且每个对等方具有与其他对等方相同的权利和义务。对等体同时是客户端和服务器。

实际上，对等网络中可用的每个资源都是在对等之间共享的，而无需任何中央服务器。P2P 网络中的共享资源可以是诸如处理器使用率，磁盘存储容量或网络带宽等。

P2P 用来做什么

P2P 的主要目标是共享资源并帮助计算机和设备协同工作，提供特定服务或执行特定任务。如前面说到的，P2P 用于共享各种计算资源，例如网络带宽或磁盘存储空间。 但是，对等网络最常见的例子是 Internet 上的文件共享。 对等网络非常适合文件共享，因为它们允许连接到它们计算机等同时接收文件和发送文件。 BitTorrent 是 P2P 使用的主要协议。

P2P 网络的作用

P2P 网络具有一些使它们有用的特征

• 很难完全掉线，即使其中的一个对等方掉线，其他对等方仍在运行并进行通信。 为了使 P2P（对等）网络停止工作，你必须关闭所有对等网络。对等网络具有很强的可扩展性。 添加新的对等节点很容易，因为你无需在中央服务器上进行任何中央配置。
• 当涉及到文件共享时，对等网络越大，速度越快。 在 P2P 网络中的许多对等点上存储相同的文件意味着当某人需要下载文件时，该文件会同时从多个位置下载。

传输层

传输层概述

传输层提供了进程间的逻辑通信，传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

传输层两大重要的功能：复用 和 分用。

• 复用：在发送端，多个应用进程公用一个传输层；
• 分用：在接收端，传输层会根据端口号将数据分派给不同的应用进程。

和网络层的区别：

• 网络层为不同主机提供通信服务，而传输层为不同主机的不同应用提供通信服务。
• 网络层只对报文头部进行差错检测，而传输层对整个报文进行差错检测。

可靠传输的原理

理想的传输条件有以下两个特点：

• 传输信道不产生差错。
• 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据。

然而实际的网络都不具备以上两个理想条件。必须使用一些可靠传输协议，在不可靠的传输信道实现可靠传输。

UDP 和 TCP 的特点

UDP

UDP 概述

UDP 只在 IP 的数据报服务之上增加了很少一点的功能：

• 复用和分用
• 差错检测

UDP 特性：

• 提供无连接服务。
• 在传送数据之前不需要先建立连接。
• 传送的数据单位协议是 UDP 报文或用户数据报。
• 对方的运输层在收到 UDP 报文后，不需要给出任何确认。
• 虽然 UDP 不提供可靠交付，但在某些情况下 UDP 是一种最有效的工作方式。
• UDP 支持一对一、一对多、多对一和多对多的交互通信。
• UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短

还要注意的是：

1. IP 数据报要经过互连网中许多路由器的存储转发。
2. UDP 用户数据报是在运输层的端到端抽象的逻辑信道中传送的。

UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。应用层交给 UDP 多长的报文，UDP 就照样发送，即一次发送一个报文。

UDP 首部格式

首部字段只有 8 个字节，包括源端口、目的端口、长度、检验和。12 字节的伪首部是为了计算检验和临时添加的。源端口号可有可无。

长度字段：UDP 数据报的整个长度，首部+数据字段。

UDP 检验和：用于差错校验，非必须，如果不使用校验和就将校验和字段置为全 0，如果校验和字段恰巧全为 0，就将校验和置为全 1。

分用时，找不到目的端口号，就丢弃报文，并且发送一个 ICMP，端口不可达的差错报文。

伪首部：也被称为伪 IP 首部，只在计算校验和的时候出现，既不向下传送也不向上递交。

伪首部的第三个字段固定全零。

伪首部第四个字段 17：封装 UDO 报文的 IP 数据报首部协议字段是 17。 UDP 长度：UDP 首部 8B+数据部分的长度（不包括伪首部）。

UDP 校验和计算

将一行看作一个整体，当作 4 个字节。 发送端：

1. 填上伪首部
2. 全 0 填充校验和字段
3. 全 0 填充数据部分（UDP 数据报要看着许多 4B 的字串拼接起来）
4. 用伪首部+首部+数据部分采用二进制反码求和
5. 把和求反码填入校验和字段
6. 去掉伪首部，发送。

接收端：

1. 填上伪首部
2. 伪首部+首部+数据部分采用二进制反码求和
3. 结果全为 1 则无差错，否则丢弃数据报、交给应用层上出差错的警告。

TCP

TCP 概述

面向字节流

1. TCP 中的“流”(stream)指的是流入或流出进程的字节序列。
2. “面向字节流”的含义是：虽然应用程序和 TCP 的交互是一次一个数据块，但 TCP 把应用程序交下来的数据看成仅仅是一连串无结构的字节流。
3. 接收方应用程序收到的字节流必须和发送方应用程序发出的字节流完全一样。
4. 提供面向连接的服务。
5. 传送的数据单位协议是 TCP 报文段 (segment)。
6. TCP 不提供广播或多播服务。
7. 由于 TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销。这不仅使协议数据单元的首部增大很多，还要占用许多的处理机资源。

TCP 报文段是在运输层抽象的端到端逻辑信道中传送，这种信道是可靠的全双工信道。但这样的信道却不知道究竟经过了哪些路由器，而这些路由器也根本不知道上面的运输层是否建立了 TCP 连接。

值得注意的：

• TCP 连接是一条虚连接而不是一条真正的物理连接。
• TCP 对应用进程一次把多长的报文发送到 TCP 的缓存中是不关心的。
• TCP 根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP 发送的报文长度是应用进程给出的）

面向套接字接口： 端口号拼接到 (contatenated with) IP 地址即构成了套接字。

TCP 报文

• 序号 ：用于对字节流进行编号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
• 确认号 ：期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。
• 数据偏移 ：指的是数据部分距离报文段起始处的偏移量，实际上指的是首部的长度。
• 确认 ACK ：当 ACK=1 时确认号字段有效，否则无效。TCP 规定，在连接建立后所有传送的报文段都必须把 ACK 置 1。
• 同步 SYN ：在连接建立时用来同步序号。当 SYN=1，ACK=0 时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中 SYN=1，ACK=1。
• 终止 FIN ：用来释放一个连接，当 FIN=1 时，表示此报文段的发送方的数据已发送完毕，并要求释放连接。
• 窗口 ：窗口值作为接收方让发送方设置其发送窗口的依据。之所以要有这个限制，是因为接收方的数据缓存空间是有限的。

TCP 报文段首部的前 20 个字节是固定的，后面有 4n 字节是根据需要而增加的选项 (n 是整数)。因此 TCP 首部的最小长度是 20 字节。首部的最大长度是 40 字节。

TCP 连接管理

TCP 的三次握手

假设 A 为客户端，B 为服务器端。

• 首先 B 处于 LISTEN（监听）状态，等待客户的连接请求。
• A 向 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。
• B 收到连接请求报文，如果同意建立连接，则向 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。
• A 收到 B 的连接确认报文后，还要向 B 发出确认，确认号为 y+1，序号为 x+1。
• B 收到 A 的确认后，连接建立。

三次握手的原因 第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。 客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

TCP 的四次挥手

以下描述不讨论序号和确认号，因为序号和确认号的规则比较简单。并且不讨论 ACK，因为 ACK 在连接建立之后都为 1。

• A 发送连接释放报文，FIN=1。
• B 收到之后发出确认，此时 TCP 属于半关闭状态，B 能向 A 发送数据但是 A 不能向 B 发送数据。
• 当 B 不再需要连接时，发送连接释放报文，FIN=1。
• A 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间）后释放连接。
• B 收到 A 的确认后释放连接。

四次挥手的原因 客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器会发送 FIN 连接释放报文。 客户端接收到服务器端的 FIN 报文后进入 TIME_WAIT 状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

• 确保最后一个确认报文能够到达。如果 B 没收到 A 发送来的确认报文，那么就会重新发送连接释放请求报文，A 等待一段时间就是为了处理这种情况的发生。
• 等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

TCP 流量控制

流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

TCP 使用滑动窗口机制来实现流量控制。 窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小，发送方根据这个值和其它信息设置自己的窗口大小。 发送窗口内的字节都允许被发送，接收窗口内的字节都允许被接收。如果发送窗口左部的字节已经发送并且收到了确认，那么就将发送窗口向右滑动一定距离，直到左部第一个字节不是已发送并且已确认的状态；接收窗口的滑动类似，接收窗口左部字节已经发送确认并交付主机，就向右滑动接收窗口。 接收窗口只会对窗口内最后一个按序到达的字节进行确认，例如接收窗口已经收到的字节为 {31, 34, 35}，其中 {31} 按序到达，而 {34, 35} 就不是，因此只对字节 31 进行确认。发送方得到一个字节的确认之后，就知道这个字节之前的所有字节都已经被接收。

TCP 拥塞控制

如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。 发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。 为了便于讨论，做如下假设：

• 接收方有足够大的接收缓存，因此不会发生流量控制；
• 虽然 TCP 的窗口基于字节，但是这里设窗口的大小单位为报文段。

慢开始与拥塞避免

发送的最初执行慢开始，令 cwnd = 1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 … 注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能性也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。 如果出现了超时，则令 ssthresh = cwnd / 2，然后重新执行慢开始。

快重传与快恢复

快重传是一种判断报文是否丢失的方法。而快恢复是一种确认窗口大小的方法，两者一般同时使用。

快重传的算法思路是：

• 要求 接收方 每收到一个时序的报文段后就立即发出重复确认，而不是等待发送数据时才进行捎带确认
• 发送方 只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段，而不必等待超时之后再重传

什么时候触发快重传算法？ 发送方 只要一连收到三个重复确认，就应当立即重传对方尚未收到的报文段，而不必等待超时之后再重传

快恢复的算法思路是：

• 当 发送方 连续收到三个重复确认时，就知道现在只是丢失了部分报文，于是不执行慢开始算法，执行“乘法减小”算法，把慢开始 阀值 ssthresh 减半 ， 窗口大小变为 ssthresh。
• 接着不执行慢开始，而是从新阀值 ssthresh 开始执行拥塞避免算法 (加法增大)

拥塞控制总结

Tcp Reno 算法

TCP 可靠传输