diff --git a/README-zh.md b/README-zh.md
index 83bd0eb..2efac2f 100644
--- a/README-zh.md
+++ b/README-zh.md
@@ -7,6 +7,17 @@
 
 rathole，类似于 [frp](https://github.com/fatedier/frp) 和 [ngrok](https://github.com/inconshreveable/ngrok)，可以让 NAT 后的设备上的服务通过具有公网 IP 的服务器暴露在公网上。
 
+<!-- TOC -->
+
+- [Features](#features)
+- [Quickstart](#quickstart)
+- [Configuration](#configuration)
+  - [Logging](#logging)
+- [Benchmark](#benchmark)
+- [Development Status](#development-status)
+
+<!-- /TOC -->
+
 ## Features
 
 - **高性能** 具有更高的吞吐量，高并发下更稳定。见[Benchmark](#Benchmark)
@@ -16,7 +27,7 @@ rathole，类似于 [frp](https://github.com/fatedier/frp) 和 [ngrok](https://g
 
 ## Quickstart
 
-一个全功能的 `rathole` 可以从 [release](https://github.com/rapiz1/rathole/releases) 页面下载。或者 [通过源码编译](docs/build-guide.md) 获取其他平台和裁剪的二进制文件。
+一个全功能的 `rathole` 可以从 [release](https://github.com/rapiz1/rathole/releases) 页面下载。或者 [从源码编译](docs/build-guide.md) 获取其他平台和裁剪的二进制文件。
 
 `rathole` 的使用和 frp 非常类似，如果你有后者的使用经验，那配置对你来说非常简单，区别只是转发服务的配置分离到了服务端和客户端，并且必须要设置 token。
 
@@ -117,7 +128,7 @@ remote_public_key = "key_encoded_in_base64"
 
 [server.services.service1] # The service name must be identical to the client side
 type = "tcp" # Optional. Same as the client `[client.services.X.type]
-token = "whatever" # Necesary if `server.default_token` not set
+token = "whatever" # Necessary if `server.default_token` not set
 bind_addr = "0.0.0.0:8081" # Necessary. The address of the service is exposed at. Generally only the port needs to be change. 
 
 [server.services.service2] 
@@ -127,7 +138,7 @@ bind_addr = "0.0.0.1:8082"
 ### Logging
 `rathole`，像许多其他 Rust 程序一样，使用环境变量来控制日志级别。
 
-支持的 Loggeng Level 有 `info`, `warn`, `error`, `debug`, `trace`
+支持的 Logging Level 有 `info`, `warn`, `error`, `debug`, `trace`
 
 比如将日志级别设置为 `error`:
 ```
@@ -140,7 +151,7 @@ RUST_LOG=error ./rathole config.toml
 
 rathole 的延迟与 [frp](https://github.com/fatedier/frp) 相近，在高并发情况下表现更好，能提供更大的带宽，内存占用更少。
 
-参见 [Benchmark](./docs/benchmark.md)。
+关于测试进行的更多细节，参见单独页面 [Benchmark](./docs/benchmark.md)。
 
 ![http_throughput](./docs/img/http_throughput.svg)
 ![tcp_bitrate](./docs/img/tcp_bitrate.svg)
diff --git a/README.md b/README.md
index f3115af..3dc599e 100644
--- a/README.md
+++ b/README.md
@@ -7,6 +7,17 @@ A secure, stable and high-performance reverse proxy for NAT traversal, written i
 
 rathole, like [frp](https://github.com/fatedier/frp) and [ngrok](https://github.com/inconshreveable/ngrok), can help to expose the service on the device behind the NAT to the Internet, via a server with a public IP.
 
+<!-- TOC -->
+
+- [Features](#features)
+- [Quickstart](#quickstart)
+- [Configuration](#configuration)
+  - [Logging](#logging)
+- [Benchmark](#benchmark)
+- [Development Status](#development-status)
+
+<!-- /TOC -->
+
 ## Features
 
 - **High Performance** Much higher throughput can be achieved than frp, and more stable when handling a large volume of connections. See [Benchmark](#Benchmark)
@@ -18,7 +29,7 @@ rathole, like [frp](https://github.com/fatedier/frp) and [ngrok](https://github.
 
 A full-powered `rathole` can be obtained from the [release](https://github.com/rapiz1/rathole/releases) page. Or [build from source](docs/build-guide.md) for other platforms and customizing the binary.
 
-The usage of `rathole` is ver similar to frp. If you have experience with the latter, then the configuration is very easy for you. The only difference is that configuration of a service is splited into the client side and the server side, and a token is mandatory.
+The usage of `rathole` is ver similar to frp. If you have experience with the latter, then the configuration is very easy for you. The only difference is that configuration of a service is split into the client side and the server side, and a token is mandatory.
 
 To use `rathole`, you need a server with a public IP, and a device behind the NAT, where some services that need to be exposed to the Internet. 
 
@@ -30,11 +41,11 @@ Create `server.toml` with the following content and accommodate it to your needs
 ```toml
 # server.toml
 [server]
-bind_addr = "0.0.0.0:2333" # `2333` specifys the port that rathole listens for clients
+bind_addr = "0.0.0.0:2333" # `2333` specifies the port that rathole listens for clients
 
 [server.services.my_nas_ssh]
 token = "use_a_secret_that_only_you_know" # Token that is used to authenticate the client for the service. Change to a arbitrary value.
-bind_addr = "0.0.0.0:5202" # `5202` specifys the port that exposes `my_nas_ssh` to the Internet
+bind_addr = "0.0.0.0:5202" # `5202` specifies the port that exposes `my_nas_ssh` to the Internet
 ```
 
 Then run:
@@ -51,7 +62,7 @@ Create `client.toml` with the following content and accommodate it to your needs
 remote_addr = "myserver.com:2333" # The address of the server. The port must be the same with the port in `server.bind_addr`
 
 [client.services.my_nas_ssh]
-token = "use_a_secret_that_only_you_know" # Must be the same with the server to pass the validataion
+token = "use_a_secret_that_only_you_know" # Must be the same with the server to pass the validation
 local_addr = "127.0.0.1:22" # The address of the service that needs to be forwarded
 ```
 
@@ -67,9 +78,9 @@ So you can `ssh myserver.com:5202` to ssh to your NAS.
 ## Configuration
 `rathole` can automatically determine to run in the server mode or the client mode, according to the content of the configuration file, if only one of `[server]` and `[client]` block is present, like the example in [Quickstart](#Quickstart).
 
-But the `[client]` and `[server]` block can also be put in one file. Then on the server side, run `rathole --server config.toml` and on the client side, run `rathole --client config.toml` to explictly tell `rathole` the running mode.
+But the `[client]` and `[server]` block can also be put in one file. Then on the server side, run `rathole --server config.toml` and on the client side, run `rathole --client config.toml` to explicitly tell `rathole` the running mode.
 
-Before heading to the full configuration specification, it's recommaned to skim [the configuration examples](./examples) to get a feeling of the configuration format.
+Before heading to the full configuration specification, it's recommend to skim [the configuration examples](./examples) to get a feeling of the configuration format.
 
 See [Security](./docs/security.md) for more details about encryption and the `transport` block.
 
@@ -117,7 +128,7 @@ remote_public_key = "key_encoded_in_base64"
 
 [server.services.service1] # The service name must be identical to the client side
 type = "tcp" # Optional. Same as the client `[client.services.X.type]
-token = "whatever" # Necesary if `server.default_token` not set
+token = "whatever" # Necessary if `server.default_token` not set
 bind_addr = "0.0.0.0:8081" # Necessary. The address of the service is exposed at. Generally only the port needs to be change. 
 
 [server.services.service2] 
@@ -125,7 +136,7 @@ bind_addr = "0.0.0.1:8082"
 ```
 
 ### Logging
-`rathole`, like many other Rust programs, use environment variables to control the logging level. `info`, `warn`, `error`, `debug`, `trace` are avialable.
+`rathole`, like many other Rust programs, use environment variables to control the logging level. `info`, `warn`, `error`, `debug`, `trace` are available.
 
 ```
 RUST_LOG=error ./rathole config.toml
@@ -136,9 +147,9 @@ If `RUST_LOG` is not present, the default logging level is `info`.
 
 ## Benchmark
 
-rathole has similiar latency to [frp](https://github.com/fatedier/frp), but can handle a more connections, provide larger bandwidth, with less memory usage.
+rathole has similar latency to [frp](https://github.com/fatedier/frp), but can handle a more connections, provide larger bandwidth, with less memory usage.
 
-See also [Benchmark](./docs/benchmark.md).
+For more details, see the separate page [Benchmark](./docs/benchmark.md).
 
 ![http_throughput](./docs/img/http_throughput.svg)
 ![tcp_bitrate](./docs/img/tcp_bitrate.svg)
diff --git a/docs/benchmark.md b/docs/benchmark.md
index 4a62089..4781c5b 100644
--- a/docs/benchmark.md
+++ b/docs/benchmark.md
@@ -127,6 +127,7 @@ Thus, in terms of latency, rathole and frp are nearly the same. But rathole can
 
 ![mem](./img/mem-graph.png)
 
+The graph shows the memory usage of frp and rathole when `vegeta attack -duration 30s -rate 1000` is executed.
 rathole uses much less memory than frp.
 
 [Script to benchmark memory](../benches/scripts/mem/mem.sh)
diff --git a/docs/out-of-scope.md b/docs/out-of-scope.md
index 4e699c7..94e4b47 100644
--- a/docs/out-of-scope.md
+++ b/docs/out-of-scope.md
@@ -1,9 +1,23 @@
 # Out of Scope
 
-- *domain based forwarding for HTTP*
+`rathole` focuses on the forwarding for the NAT traversal, rather than being a all-in-one development tool or a load balancer or a gateway. It's designed to *be used with them*, not *replace them*.
 
-  Use nginx to do this.
+But that doesn't mean it's not useful for other purposes. In the future, more configuration APIs will be added and `rathole` can be used with an external dashboard.
 
-- *frp's STCP*
+> Make each program do one thing well.
+
+- *Domain based forwarding for HTTP*
+
+  Introducing these kind of features into `rathole` itself ultimately reinvent a nginx. Use nginx to do this and set `rathole` as the upstream. This method achieves better performance as well as flexibility.
+
+- *HTTP Request Logging*
+
+  `rathole` doesn't interference with the application layer traffic. A right place for this kind of stuff is the web server, and a network capture tool.
+
+- *`frp`'s STCP*
 
   You may want to consider secure tunnels like wireguard or zerotier.
+
+- *P2P hole punching*
+
+  P2P hole punching requires setup on the visitors' side. If that kind of setup is possible, then there are a lot more tools available. `rathole` primarily focuses on NAT traversal by forwarding, which doesn't require any setup for visitors.