diff --git a/OkHttp/0.md b/OkHttp/0.md
new file mode 100644
index 0000000..de80676
--- /dev/null
+++ b/OkHttp/0.md
@@ -0,0 +1,42 @@
+# OkHttp 结构体系总览
+
+OkHttp 整个框架将所有 API 统一暴露在 `okhttp3` 包下，将内部的实现细节统一放置在 `okhttp3.internal` 包下。
+
+对于 internal 包中的内容我们将在后面的文章展开分析，本文我们主要看一看 API 层面的东西，看看它们的职责及关系。
+
+#### `OkHttpClient`
+
+这个类是 OkHttp 的一个上下文管理类，它包括了一切与 OkHttp 有关的状态、配置与工具类对象，这个类自身包含的逻辑不多，主要是提供了其它框架组件的 getters，开发者通常使用 `OkHttpClient.Builder` 去构建一个 `OkHttpClient` 实例。
+
+#### `Call`
+
+可能有朋友搞不清 `Call` 与 `Request` 之间有什么区别。我们可以把 `Request` 理解为一个请求的描述信息，它是无状态且可以复用的；而 `Call` 则可以表示请求的这个过程，它不仅包含了请求过程中所需的状态，也包含了一系列可操作请求过程的方法。
+
+#### `Dispatcher`
+
+这个类包含了异步请求的管理策略，并发控制、空闲回调等特性都是由这个类来完成的，`RealCall` 会自己通知 `Dispatcher` 去启动或结束一个任务，对于异步请求，`Dispatcher` 会使用等待队列和 `ExecutorService` 来调度请求的启动。
+
+#### `Connection`
+
+对于启用了 Keep-Alive 的 HTTP 服务器，每个 HTTP 请求不一定都需要开启新的 TCP Socket 连接，每个连接在处理完一个请求后会保持一定时间的鲜活时间，这样新的请求就可以直接复用这个连接了，节省了三次握手、四次挥手的两端时间开销及对服务器的资源开销。而 `Connection` 这个类就封装和管理了一个 `Socket` 对象，以及 TLS、Proxy 等相关对象。
+
+#### `ConnectionPool`
+
+既然有 `Connection`，那一定就要有一个 Pool 去管理它们的“生老病死”，实际上 `ConnectionPool` 并不负责去创建 `Connection` 但是它负责清理“异常死亡”的 `Connection`，有关这部分的细节我会在后期的文章中深入分析。
+
+#### `Response` 及 `ResponseBody`
+
+与之对应的还有 `Request` 和 `RequestBody`。
+它们之间有什么关联呢？Response 表示了一个服务器响应，当开发者通过 `Call#execute` 拿到 `Response` 对象时，数据并没有传输完毕，也就是说虽然 `Call#execute` 是同步方法，但在它返回时我们仅仅拿到了一个 header 信息，接下来读取 ResponseBody 的过程仍会继续从服务器接收数据，读取过程概括地讲就是 Socket 的 read。当然 `ResponseBody` 的读取过程也是可以自己干涉的，你可以自己决定读取多少，当然，读取完毕时也不要忘记关闭。
+
+#### `Interceptor`
+
+这是 OkHttp 中一个非常关键的技术，可以说 OkHttp 主要就是基于 `Interceptor` 驱动起来的，各个 `Interceptor` 可以穿成一个串，我们可以把它理解为一个请求的 Pipeline，每个 `Interceptor` 各负其职，有的负责连接，有的负责异常处理，有的负责 redirect，还有的负责 cache，最后完成整个请求操作。而且 OkHttp 把这个强大的技术暴露给了我们，我们可以向这个 Pipeline 中插入我们自己的 `Interceptor`，从而完成更复杂的业务需求。
+
+#### `Cache`
+
+顾名思义，这个类封装了所有与缓存相关的操作，它内部使用 [`DiskLruCache`](https://github.com/unixzii/android-source-codes/tree/master/DiskLruCache) 来处理磁盘缓存，但是它并不负责真正的缓存逻辑，何时缓存还是由 `CacheInterceptor` 来决定。
+
+## 小结
+
+本文主要概述了一下 OkHttp API 层面的一些类和它们之间的关系，它们绝大多数都是 interface，真正的实现都是在 `internal` 包中的，通常就是类名以 Real 打头的类。本文所提及的这些类都比较简单，里面也没有涉及太多网络相关的知识，但是了解掌握这些类对我们之后的深入分析是十分必要的。
\ No newline at end of file
diff --git a/OkHttp/1.md b/OkHttp/1.md
new file mode 100644
index 0000000..25c1539
--- /dev/null
+++ b/OkHttp/1.md
@@ -0,0 +1,189 @@
+# Dispatcher & Call
+
+前面的文章提到了，`Call` 是一个请求的入口，我们索性从它的 `execute` 方法开始分析。
+
+```java
+@Override public Response execute() throws IOException {
+  synchronized (this) {
+    if (executed) throw new IllegalStateException("Already Executed");
+    executed = true;
+  }
+  captureCallStackTrace();
+  try {
+    client.dispatcher().executed(this);
+    Response result = getResponseWithInterceptorChain();
+    if (result == null) throw new IOException("Canceled");
+    return result;
+  } finally {
+    client.dispatcher().finished(this);
+  }
+}
+```
+
+可以看到这个方法的逻辑还是十分清晰的，首先进行状态判断，一个 `Call` 对象只能用于一次请求，如果要对同一个 URL 发起多次请求的话，我们就需要去创建多个新的 `Call` 对象。接下来这个方法捕获了调用栈，这个是为了调试方便所做的工作。最后便是请求发起的核心部分了，我们看到这里出现了 `Dispatcher`，我们顺便看看这里 `Dispatcher` 做了什么：
+
+```java
+synchronized void executed(RealCall call) {
+  runningSyncCalls.add(call);
+}
+```
+
+这里仅仅把需要执行的请求加入了一个双向队列，通过 **Find Usages** 工具可以发现，这个队列主要的工作就是去跟踪正在执行的同步请求，并且提供了取消同步请求的方法：
+
+```java
+public synchronized void cancelAll() {
+  for (AsyncCall call : readyAsyncCalls) {
+    call.get().cancel();
+  }
+
+  for (AsyncCall call : runningAsyncCalls) {
+    call.get().cancel();
+  }
+
+  for (RealCall call : runningSyncCalls) {
+    call.cancel();
+  }
+}
+```
+
+对于 Call 是如何取消一个正在执行的请求，我们放在后面文章中去讲解。
+
+回到之前的 `Call#execute()`，它继续调用了 `Call#getResponseWithInterceptorChain()` 获取到了 `Response` 对象，最后返回并通知 `Dispatcher`，那么我们再着重看一下这个方法：
+
+```java
+Response getResponseWithInterceptorChain() throws IOException {
+  // Build a full stack of interceptors.
+  List<Interceptor> interceptors = new ArrayList<>();
+  interceptors.addAll(client.interceptors());
+  interceptors.add(retryAndFollowUpInterceptor);
+  interceptors.add(new BridgeInterceptor(client.cookieJar()));
+  interceptors.add(new CacheInterceptor(client.internalCache()));
+  interceptors.add(new ConnectInterceptor(client));
+  if (!forWebSocket) {
+    interceptors.addAll(client.networkInterceptors());
+  }
+  interceptors.add(new CallServerInterceptor(forWebSocket));
+
+  Interceptor.Chain chain = new RealInterceptorChain(
+      interceptors, null, null, null, 0, originalRequest);
+  return chain.proceed(originalRequest);
+}
+```
+
+在 [OkHttp 结构体系总览](#) 这一篇文章中我也提到了，`Interceptor` 是 OkHttp 中至关重要的技术，然后整个 `Request` 到 `Response` 的变换过程就是由一系列 `Interceptor` 去完成的，而这个方法就是 OkHttp 内部帮你按照特定顺序构建了一个 **Interceptor Chain**，有关各个 `Interceptor` 都是做什么的我们后面也会深入分析。
+
+那么这是一个同步方法，对于异步请求，OkHttp 又是怎么处理的呢？
+
+异步请求是调用 `Call#enqueue(Callback)`，我们来看一下这个方法：
+
+```java
+@Override public void enqueue(Callback responseCallback) {
+  synchronized (this) {
+    if (executed) throw new IllegalStateException("Already Executed");
+    executed = true;
+  }
+  captureCallStackTrace();
+  client.dispatcher().enqueue(new AsyncCall(responseCallback));
+}
+```
+
+前半部分都是一样的，最后还是用到了 `Dispatcher` 去进行调度，所以我们先看看 `Dispatcher#enqueue(AsyncCall)` 干了什么：
+
+```java
+synchronized void enqueue(AsyncCall call) {
+  if (runningAsyncCalls.size() < maxRequests && runningCallsForHost(call) < maxRequestsPerHost) {
+    runningAsyncCalls.add(call);
+    executorService().execute(call);
+  } else {
+    readyAsyncCalls.add(call);
+  }
+}
+```
+
+可以看到，这里 `Dispatcher` 限制了请求的并发量，当正在进行的异步请求大于设置的最大限制时，`Dispatcher` 将这些请求放到一个队列里等待，对于没有超过限制的请求，直接交给 `ExecutorService` 去执行，这里 `ExecutorService` 会从线程池中为这些请求分配线程。
+
+然后我们再回到 `AsyncCall`，它是一个 `Runnable`，可以直接被线程执行：
+
+*由于这段代码较长，我就直接把注释写在代码中了。*
+
+```java
+@Override protected void execute() {
+  boolean signalledCallback = false;
+  try {
+    // 这里类似同步请求，还是需要用 Interceptor Chain 去拿
+    // 到 Response 对象。
+    Response response = getResponseWithInterceptorChain();
+    // 判断请求是否在完成之前被取消，分发相应事件给回调方法。
+    if (retryAndFollowUpInterceptor.isCanceled()) {
+      signalledCallback = true;
+      responseCallback.onFailure(RealCall.this, new IOException("Canceled"));
+    } else {
+      // 这里记录回调方法已经被执行过。
+      signalledCallback = true;
+      responseCallback.onResponse(RealCall.this, response);
+    }
+  } catch (IOException e) {
+    // 对于捕获到的异常，如果回调方法没有被执行过，就执行回调，
+    // 否则通过平台相关的日志系统输出。
+    if (signalledCallback) {
+      // Do not signal the callback twice!
+      Platform.get().log(INFO, "Callback failure for " + toLoggableString(), e);
+    } else {
+      responseCallback.onFailure(RealCall.this, e);
+    }
+  } finally {
+    // 最后还是要去通知 Dispatcher 这个请求已经完成。
+    client.dispatcher().finished(this);
+  }
+}
+```
+
+可以看到，异步与同步是十分相似的，异步只不过是多了一个并发控制。
+
+关于 `Dispatcher` 还有一个地方没有说到，就是对于放入队列的异步请求，它们是在什么时候被执行的呢？那就是 `Dispatcher#finished(...)`：
+
+```java
+private <T> void finished(Deque<T> calls, T call, boolean promoteCalls) {
+  int runningCallsCount;
+  Runnable idleCallback;
+  // 降低锁的粒度。
+  synchronized (this) {
+    if (!calls.remove(call)) throw new AssertionError("Call wasn't in-flight!");
+    if (promoteCalls) promoteCalls();
+    runningCallsCount = runningCallsCount();
+    idleCallback = this.idleCallback;
+  }
+
+  // 如果这是最后一个请求，就执行闲时回调方法。
+  if (runningCallsCount == 0 && idleCallback != null) {
+    idleCallback.run();
+  }
+}
+```
+
+对于异步请求，`promoteCalls` 为 **true**，`Dispatcher#promoteCalls()` 就会执行：
+
+```java
+private void promoteCalls() {
+  if (runningAsyncCalls.size() >= maxRequests) return; // Already running max capacity.
+  if (readyAsyncCalls.isEmpty()) return; // No ready calls to promote.
+
+  for (Iterator<AsyncCall> i = readyAsyncCalls.iterator(); i.hasNext(); ) {
+    AsyncCall call = i.next();
+
+    // 这里还有一重限制，每个主机（IP）的请求数。
+    // 当两个条件都满足时才能执行这个请求。
+    if (runningCallsForHost(call) < maxRequestsPerHost) {
+      i.remove();
+      runningAsyncCalls.add(call);
+      executorService().execute(call);
+    }
+
+    if (runningAsyncCalls.size() >= maxRequests) return; // Reached max capacity.
+  }
+}
+```
+
+## 小结
+
+到这里 `Dispatcher` 和 `Call` 的部分就结束了，归根到底这两个对象还是主要负责了请求调度的工作，真正的网络操作则是交给了各个 `Interceptor` 和其他内部对象。
\ No newline at end of file
diff --git a/OkHttp/README.md b/OkHttp/README.md
new file mode 100644
index 0000000..3e99f07
--- /dev/null
+++ b/OkHttp/README.md
@@ -0,0 +1,17 @@
+# OkHttp 拆轮子笔记
+
+Well，我也要开始拆轮子了，第一个轮子就是 `OkHttp` 啦，虽然有关 `OkHttp` 源码分析的文章已经非常多了，但我还是想自己重头系统地分析一遍它。
+
+然后对于 OkHttp 来说我会分很多个子文章去写，接下来可能还会分析一下它的重要依赖 `Okio`，不过应该会再开一个系列吧。
+
+注意，本系列文章以 `okhttp-3.8.1` 版本源码为参考。
+
+## 目录
+
+*WIP Notice: 当前目录仅供参考，可能与系列结束时有所不同。*
+
+0. OkHttp 结构体系总览
+1. Dispatcher & Call
+2. Interceptor Chain
+3. 几个重要的 Interceptor
+4. 内部类 HttpCodec、StreamAllocation
\ No newline at end of file
