diff --git a/blogs/Interview/Get 和 Post 的区别.md b/blogs/Interview/Get 和 Post 的区别.md
new file mode 100644
index 0000000..c590c93
--- /dev/null
+++ b/blogs/Interview/Get 和 Post 的区别.md	
@@ -0,0 +1,119 @@
+---
+Get 和 Post 请求的区别？
+---
+
+#### 官方文档
+
+GET RFC 文档：[https://tools.ietf.org/html/rfc2616#section-9.3](https://tools.ietf.org/html/rfc2616#section-9.3)
+
+POST RFC 文档：[https://tools.ietf.org/html/rfc2616#section-9.5](https://tools.ietf.org/html/rfc2616#section-9.5)
+
+#### 典型回答
+
+GET 和 POST 本质上没有任何区别，之所以区分开来，是为了让请求更加有语义而已。
+
+GET 的语义是请求获取指定的资源，GET 方法是安全、幂等、可缓存的，GET 方法的报文主体没有任何语义。
+
+POST 的语义是对指定的资源进行处理，POST 方法是不安全、不幂等、（大部分实现）不可缓存的。
+
+#### 知识扩展
+
+##### 三个特性
+
+在 RFC 中定义了 HTTP 方法的几个性质：
+
+1. Safe 安全性
+
+   这里的「安全」和通常理解的「安全」意义不同。如果一个方法的语义本质上是「只读」的，那么这个方法就是安全的。客户端向服务端的资源发起的请求如果使用了是安全的方法，就不应该引起服务端任何的状态变化，因此也是无害的。RFC 定义，GET、HEAD、OPTIONS 和 TRACE 这几个方法是安全的。
+
+   这个定义只是规范，并不能保证方法的实现就是安全的。比如你完全可以用 GET 方法去修改信息
+
+   引入安全的概念目的是为了方便网络爬虫和缓存，以免调用或者缓存某些不安全方法时引起某些意外的后果。User Agent（浏览器）应该在执行安全和不安全方法时作出区别对待，并给予用户以提示。
+
+2. Idempotent 幂等性
+
+   幂等性是指同一个请求方法执行多次和仅执行一次的效果是相同的。按照 RFC 规范，PUT、DELETE 和安全方法都是幂等的。同样，这也仅仅是规范，服务端实现是否幂等是无法确保的。引入幂等主要是为了处理同一个请求重复发送的情况，比如在请求响应前失去连接，如果方法是幂等的，就可以放心的重新发送请求。这也是浏览器在后退/刷新时遇到 POST 会提示用户，因为 POST 语义不是幂等的，重复请求会带来意想不到的后果。
+
+3. Cacheable 可缓存性
+
+   顾名思义就是一个方法是否可以被缓存，在 RFC 中，GET、HEAD 和某些情况下的 POST 都是可被缓存的，但是大多数浏览器的实现里仅仅支持 GET 和 HEAD。
+
+在这三个特性里一直都在强调，这只是一种规范，协议不等于实现。
+
+##### 长度限制？
+
+网络上大多都会说 GET 的 URL 会有长度上的限制，而 POST 将数据放入 BODY 中，数据可以非常大。实际上，HTTP 协议里面并没有规定 URL 和 BODY 的长度限制，对 URL 的限制大多数是浏览器和服务器的原因。浏览器的原因就不说了，服务器是因为处理长 URL 要消耗比较多的资源，为了性能和安全（防止恶意构造长 URL 来攻击）考虑，会给 URL 长度加限制。
+
+##### POST 方法比 GET 方法安全？
+
+有人说 POST 比 GET 安全，因为数据在地址栏不可见。这是一种比较小儿科的说法，从传输的角度来说，它们都是不安全的，因为 HTTP 在网络上是明文传输，完全可以在网络节点上抓包就能获取完整数据报文。想要安全传输，就只有加密了，也就是 HTTPS。
+
+##### POST 产生两个 TCP 数据包？
+
+有些文章中提出，POST 会将 HEADER 和 BODY 分开发送，先发送 HEADER，待服务端返回 100 状态码之后再发送 BODY。这也是不严谨的，首先就是在 RFC 中并没有这样的说法，其次，一些浏览器的实现不同，也会导致实际上测试根本不会有这种情况。
+
+##### 八种请求方法
+
+HTTP 请求最初设定了八种方法，这八种方法本质上没有任何区别，只是让请求更加语义化：
+
+1. OPTIONS
+
+   返回服务器所支持的请求方法，一般用于调试，多数线上服务都不支持。
+
+2. GET
+
+   向服务器获取指定资源。
+
+3. HEAD
+
+   和 GET 一致，只不过响应体不返回，只返回响应头。
+
+4. POST
+
+   向服务器提交数据，数据放在请求体里。
+
+5. PUT
+
+   和 POST 相似，只是具有幂等性，一般用于更新。
+
+6. DELETE
+
+   删除服务器上的指定资源。
+
+7. TRACE
+
+   回显服务端收到的请求，一般用于调试。
+
+8. CONNECT
+
+   现在多用于 HTTPS 和 WebSocket。
+
+##### RESTful API
+
+服务端根据不同的请求方式，可以做不同的处理，同时，根据不同的请求，还可以设计出不同风格的应用程序接口。这就引出了 Representational State Tansfer，英文缩写就是 REST，中文意思即表述性状态转移，可以理解为客户端和服务端的交互形式。而符合这种交互形式的接口设计，就被叫做 RESTful API，这种风格有以下特点：
+
+1. 使用名词而不是使用动词
+
+   例如 /getStudent 或 /searchStudents 应该改为 /students
+
+2. GET 用于查询，PUT、POST、DELETE 用于修改
+
+3. 使用名词复数而不使用单数
+
+4. 在 HTTP 请求的 HEADER 里定义序列化类型
+
+   例如：Content-Type:application/json
+
+5. 请求的集合应设定好过滤条件、排序、字段、分页等
+
+   例如：/students?page=1&size=10
+
+6. 接口要版本化
+
+   例如：api/v1/students
+
+7. 要有 HTTP 状态码
+
+#### 参考
+
+[get 和 post 的区别？](https://www.zhihu.com/question/28586791/answer/145424285)
\ No newline at end of file
diff --git a/blogs/Interview/面试题集.md b/blogs/Interview/面试题集.md
new file mode 100644
index 0000000..3c5ce27
--- /dev/null
+++ b/blogs/Interview/面试题集.md
@@ -0,0 +1,12 @@
+---
+面试题集
+---
+
+#### 前言
+
+
+
+#### 目录
+
+[Get 和 Post 请求的区别？]
+
diff --git a/blogs/computer_network/computer_systems/计算机系统漫游.md b/blogs/computer_network/computer_systems/计算机系统漫游.md
new file mode 100644
index 0000000..e88cf72
--- /dev/null
+++ b/blogs/computer_network/computer_systems/计算机系统漫游.md
@@ -0,0 +1,9 @@
+---
+计算机系统漫游
+---
+
+#### 目录
+
+1. 思维导图
+2. 
+