在上篇笔记中我们综合了诸多技术搭建了一个可靠的数据传输协议——位交替协议。然而，作为停等协议，位交替协议的效率实在太低。

举个例子，假设主机 A 和主机 B 之间的往返时延为 30 ms，二者之间连接的信道的传输率 R 为 1 Gbps，一个 packet 的大小 L 为 1000 bytes，那么一个 packet 从主机传输到信道上所花的时间为
$$d_{trans}=\frac{L}{R}=\frac {1000 \times 8 \: bit}{1 \times 10^{9}\, bps}=8 \times 10^{-6}s$$
然而，当 A 给 B 发送了一个packet之后，要等上 30ms + 0.008ms = 30.008 ms 才收到 ACK，然后 A 才能发送下一个 packet。发送方的实际利用率为：
$$U_{sender}=\frac{\frac{L}{R}}{RTT +\frac{L}{R}}=\frac{0.008\, ms}{30\, ms + 0.008\, ms}\approx 0.00027=0.027\%$$
也就是说在 30.008ms 里实际上只传输了 1000 个字节，实际吞吐量为 276kbps，大大的浪费啊~

这个性能问题的解决思路很简单：允许在之前发送地 packet 没有收到确认的情况下继续发送新的 packet。就像是水流源源不断地流经管道，因此这种模式又被称为管道化 (Pipeling)。

写在前面：从上一篇开始，大概会有一系列网络相关的笔记，主要内容整理自《计算机网络：自顶向下方法》这本书，目前在看的是英文版，个人感觉比中文版看起来流畅。原本打算以《计算机网络（第五版）》为主要参考书的，这本与前者相反，是以自底向上的结构组织的，比较下来发现自己更适应前者的思维模式。在整理笔记的时候考虑到一些术语的翻译，也会参考后者，同时查漏补缺。目前看来两本书的涵盖点都挺全面的，相比之下，前者版本更新更快，内容更与时俱进。

在人们离不开网络的当今，我们通过网络交流、购物、协同工作，为了使这些活动能通过网络顺利地进行，我们需要解决网络传输的两大基本问题：

• 如何提供可靠的数据传输
• 如何避免网络拥塞以及在拥塞发生时如何恢复

在本篇笔记中，我们先来了解一下实现可靠的数据传输的相关机制。

喜迎 2020 第一篇笔记！突然觉得没有赶在四年一遇的 2 月 29 日写，有点遗憾呢。

最近这几个月摸了不少鱼，也挖了一点点坑，总想着把一个主题全部过一遍再回顾写笔记，结果就是永远都没有开始，因为不会的实在是太多了，怎么都学不完呀，所以，还是边看边整理吧～

当初在搭这个博客时，少不了要为域名配置 DNS，按着教程在 DNSPod 上注册了个账号，配了几条记录。至于为什么要做这些，倒真是一直没有深究过。
最近在重新学习网络相关的内容，就拿 DNS - Domian Name System 开头吧。

为什么需要 DNS

理论上，任何程序通过 IP 地址就可以访问网络资源，然而这类地址实在是不便于人类记忆。因此，机智的人类引入了可读性更好、更易于记忆的主机名 (hostname) 。主机名不仅解决了可读性的问题，它将机器名字与机器地址分离，这样即使更换了机器地址发生了变化，也不会影响用户通过主机名访问资源。

由于网络本身只认识 IP 地址，所以就需要某种机制将主机名映射为 IP 地址，由此 DNS 应运而生。

上两篇笔记把 OAuth 2.0 基本的理论知识都介绍了一下，在本篇笔记中，就让我们一起来实现一个 OAuth 2.0 服务器吧，简单起见，这个服务器既承担资源服务器的角色，也承担授权服务器的角色。

我们使用 Spring Security 作为底层支持。Spring Security 是 Spring 全家桶中提供的与安全相关一套框架。它对一般 Web 应用都需要的认证和授权这一块的功能进行了封装，使得在一个 Spring 项目中可以非常简便又灵活地根据自身的安全性需求搭建出一套认证和授权流程。

Spring Security OAuth 则是 Spring Security 提供的对 OAuth 的支持（ OAuth 1 和 OAuth 2 都支持）。

在上一篇笔记中，我们了解了一些 OAuth 2.0 中的概念，其中最重要的就是 OAuth 2.0 的四个角色：资源拥有者（用户）、客户端、授权服务器和资源服务器。在本篇笔记里，我们将介绍 OAuth 2.0 中的授权类型。

针对不同的授权场景，OAuth 2.0 定义了 4 种授权类型：

• Authorization Code
• Implicit
• Resource Owner Password Credentials
• Client Credentials

这里的应用场景主要指的是客户端的类型，一方面指 public 或 confidential，另一方面指具体种类，比如web 应用、native 移动应用、不包含浏览器的设备，又或者是客户端也是一个 server。根据不同的情况，客户端获取 Access Token 的过程也不尽相同。

除此之外，OAuth 2.0 还支持自定义扩展授权类型。

下面我们就分别来看看这四种授权类型的详细定义吧。

一年之前开过一个关于Web认证相关的坑，只简单地开了个头就不甚了了。时隔一年，正好这一年做的项目一直都跟应用间的认证和授权相关，于是决定重拾旧坑，好好研究一番。

（ˊ_>ˋ 原本就想写个简单的概述，但那样好像没什么意义，而且内容也实在是有点多…）

第一篇就先聊聊 OAuth 诞生的背景和其中的一些基本概念吧。

为什么会有 OAuth 2.0 的诞生

在传统的客户端-服务器认证模型中，由客户端携带用户的认证凭证（credentials）来访问服务端受保护的资源，而当有第三方应用想访问服务端资源时，我们最容易想到的方式是什么呢？

让第三方应用与客户端共享认证凭证。

而上述这种做法的弊端和局限性也很明显：

• 第三方应用需要自己保存用户凭证（安全隐患非常大，尤其在使用明码的情况下）
• 服务端要支持用户名密码验证机制，而密码本身就存在安全弱点
• 第三方应用获得的访问权限过大，而客户端没有办法限制授权的有效期和范围
• 用户如果要收回对某一第三方应用的授权，就只能修改密码，而这将同时收回所有其他第三方应用的授权
• 只要有一个第三方应用被攻击了，那么用户的认证凭证就泄漏了，那么所有被这个密码保护的数据也将被泄漏。

OAuth 的出现就是为了解决这些问题。OAuth 并不是框架或工具，而是一组基于 HTTP 协议的标准，它定义了一系列与授权场景相关的概念和规则，针对不同的应用场景给定了几类标准的授权过程。下面就让我们一起揭开 OAuth 神秘的面纱吧。

注：本文将只介绍 OAuth 2.0，OAuth 2.0 和 OAuth 1.0 并不兼容。

在日常开发中，我们难免会要实现自己一些 Util 类。Util 类通常是一组静态方法的集合，它本身是无状态的 (stateless)，所有方法执行依赖的参数都由显式参数给出。基于这样的特性，大家总结出了一些针对 Util 类的设计和实现的最佳实践，其中最主要就是如下两点：

• 将类声明为final
• 构造函数私有化

其实很简单，不过自己写代码的时候总是容易忘记，所以特地记下来～

写在前面：
因为了解越多发现自己不懂的越多，连整理归纳笔记都变得吃力了起来，所以「GC算法系列」就暂时告一段落了。希望沉淀一段时间后，回头再看的时候会有更深刻的理解。

前几篇笔记介绍了几种基本的垃圾回收算法，那么是不是堆上所有的对象都是由相同的垃圾算法管理的呢？而且所有的垃圾都是在同一时间得到回收的呢？答案自然是否定的。
事实上，根据不同对象的存活特性，如果我们针对性地处理不同的对象的话，对垃圾回收的性能提升是非常有效的。目前应用最广泛的例子就是 —— 分代垃圾回收 (Generational garbage collection)。分代垃圾回收的基本思想就是根据对象的年龄进行分隔，优先回收更年轻的对象。

接下来，我们稍微深入地聊一聊堆分区与分代垃圾回收那些事吧~

前面几篇笔记里我们分别介绍了四种基本的 GC 算法：

• 标记-清除算法
• 复制算法
• 引用计数法
• 标记-整理算法

本文将它们放在一起，做一个总结概括~

前面我们提到 GC 算法的基本类型无非标记-清除、引用计数和复制算法三类，那么这篇笔记中介绍的标记-整理 (Mark-Compact) 算法就开始将 标记-清除 算法与复制算法结合的产物。不同于复制算法是从一个空间往另一个空间复制，标记-整理算法是在整个堆上原地整理，因此也提高了堆的利用率。

标记-整理算法的思路也很简单，分为两个阶段：

• 标记阶段 - 与标记-清除算法中的标记阶段一样，遍历堆上的对象，标记出活动对象。
• 整理阶段 - 移动或复制活动对象，将所有存活的对象都移动到堆的一端（仿佛被压缩），然后直接清理掉端边界以外的内容。

值得注意的一点是，整理的顺序会影响到程序的局部性。重排堆中对象时所遵循的顺序包括如下三种：