Merge pull request pingcap#227 from CaitinChen/fix-2-broken-links-blogs

Fix 2 broken links

grpc-rs.md

@@ -236,7 +236,7 @@ pub fn unary_async<P, Q>(channel: &Channel,
 
 ## 写在最后
 
-这篇简单介绍了 gRPC Core 的实现和 gRPC-rs 的封装，详细的用法，在这就不做过多介绍了，大家如果感兴趣可以查看 [examples]。 gRPC-rs 深入使用了 Future，里面有很多神奇的用法，比如 Futures in gRPC-rs 那节最后的 `executer`， gRPC-rs 利用 CQ 实现了一个能并发执行 Future 的 `executer`（类似 furtures-rs 中的 [Executer]），大幅减少 context switch，性能得到了显著提升。如果你对 gRPC 和 rust 都很感兴趣，欢迎参与开发，目前还有一些工作没完成，详情请点击 [https://github.com/pingcap/grpc-rs](gRPC-rs)
+这篇简单介绍了 gRPC Core 的实现和 gRPC-rs 的封装，详细的用法，在这就不做过多介绍了，大家如果感兴趣可以查看 [examples]。 gRPC-rs 深入使用了 Future，里面有很多神奇的用法，比如 Futures in gRPC-rs 那节最后的 `executer`， gRPC-rs 利用 CQ 实现了一个能并发执行 Future 的 `executer`（类似 furtures-rs 中的 [Executer]），大幅减少 context switch，性能得到了显著提升。如果你对 gRPC 和 rust 都很感兴趣，欢迎参与开发，目前还有一些工作没完成，详情请点击 [https://github.com/pingcap/grpc-rs](https://github.com/pingcap/grpc-rs)。
 
 参考资料：
 

grpc.md

@@ -121,7 +121,7 @@ HTTP/2 也支持流控，如果 sender 端发送数据太快，receiver 端可
 
 在一个 HTTP 请求里面，我们通常在 header 上面携带很多改请求的元信息，用来描述要传输的资源以及它的相关属性。在 HTTP/1.x 时代，我们采用纯文本协议，并且使用 `\r\n` 来分隔，如果我们要传输的元数据很多，就会导致 header 非常的庞大。另外，多数时候，在一条连接上面的多数请求，其实 header 差不了多少，譬如我们第一个请求可能 `GET /a.txt`，后面紧接着是 `GET /b.txt`，两个请求唯一的区别就是 URL path 不一样，但我们仍然要将其他所有的 fields 完全发一遍。
 
-HTTP/2 为了结果这个问题，使用了 HPACK。虽然 HPACK 的 [RFC 文档](http:https://httpwg.org/specs/rfc7541.html) 看起来比较恐怖，但其实原理非常的简单易懂。
+HTTP/2 为了结果这个问题，使用了 HPACK。虽然 HPACK 的 [RFC 文档](https:https://httpwg.org/specs/rfc7540.html) 看起来比较恐怖，但其实原理非常的简单易懂。
 
 HPACK 提供了一个静态和动态的 table，静态 table 定义了通用的 HTTP header fields，譬如 method，path 等。发送请求的时候，只要指定 field 在静态 table 里面的索引，双方就知道要发送的 field 是什么了。