diff --git a/ch05/README.md b/ch05/README.md
index aad1835..cd19cc2 100644
--- a/ch05/README.md
+++ b/ch05/README.md
@@ -22,7 +22,7 @@ write(sock, message, strlen(message));
 str_len = read(sock, message, BUF_SIZE - 1);
 ```
 
-二者都在村换调用 read 和 write 函数。实际上之前的回声客户端将 100% 接受字节传输的数据，只不过接受数据时的单位有些问题。扩展客户端代码回顾范围，下面是，客户端的代码:
+二者都在循环调用 read 和 write 函数。实际上之前的回声客户端将 100% 接受字节传输的数据，只不过接收数据时的单位有些问题。扩展客户端代码回顾范围，下面是，客户端的代码:
 
 ```c
 while (1)
@@ -52,7 +52,7 @@ while (1)
 
 #### 5.1.3 如果问题不在于回声客户端：定义应用层协议
 
-回声客户端可以提前知道接收数据的长度，这在大多数情况下是不可能的。那么此时无法预知接收数据长度时应该如何手法数据？这是需要的是**应用层协议**的定义。在收发过程中定好规则（协议）以表示数据边界，或者提前告知需要发送的数据的大小。服务端/客户端实现过程中逐步定义的规则集合就是应用层协议。
+回声客户端可以提前知道接收数据的长度，这在大多数情况下是不可能的。那么此时无法预知接收数据长度时应该如何收发数据？这时需要的是**应用层协议**的定义。在收发过程中定好规则（协议）以表示数据边界，或者提前告知需要发送的数据的大小。服务端/客户端实现过程中逐步定义的规则集合就是应用层协议。
 
 现在写一个小程序来体验应用层协议的定义过程。要求：
 
@@ -83,7 +83,7 @@ gcc My_op_server.c -o myserver
 
 ![](https://i.loli.net/2019/01/15/5c3d966b81c03.png)
 
-其实主要是对程序的一点点小改动，只需要再客户端固定好发送的格式，服务端按照固定格式解析，然后返回结果即可。
+其实主要是对程序的一点点小改动，只需要在客户端固定好发送的格式，服务端按照固定格式解析，然后返回结果即可。
 
 书上的实现：
 
@@ -182,7 +182,7 @@ TCP 在实际通信中也会经过三次对话过程，因此，该过程又被
 
 对于主机 A 首次传输的数据包的确认消息（ACK 1001）和为主机 B 传输数据做准备的同步消息（SEQ 2000）捆绑发送。因此，此种类消息又称为 SYN+ACK。
 
-收发数据前向数据包分配序号，并向对方通报此序号，这都是为了防止数据丢失做的准备。通过项数据包分配序号并确认，可以在数据包丢失时马上查看并重传丢失的数据包。因此 TCP 可以保证可靠的数据传输。
+收发数据前向数据包分配序号，并向对方通报此序号，这都是为了防止数据丢失做的准备。通过向数据包分配序号并确认，可以在数据包丢失时马上查看并重传丢失的数据包。因此 TCP 可以保证可靠的数据传输。
 
 通过这三个过程，这样主机 A 和主机 B 就确认了彼此已经准备就绪。
 
@@ -200,7 +200,7 @@ TCP 在实际通信中也会经过三次对话过程，因此，该过程又被
 
 与三次握手协议相同，最后 + 1 是为了告知对方下次要传递的 SEQ 号。下面分析传输过程中数据包丢失的情况：
 
-![](https://i.loli.net/2019/01/16/5c3ed371187a6.png)'
+![](https://i.loli.net/2019/01/16/5c3ed371187a6.png)
 
 上图表示了通过 SEQ 1301 数据包向主机 B 传递 100 字节数据。但中间发生了错误，主机 B 未收到，经过一段时间后，主机 A 仍然未收到对于 SEQ 1301 的 ACK 的确认，因此试着重传该数据包。为了完成该数据包的重传，TCP 套接字启动计时器以等待 ACK 应答。若相应计时器发生超时（Time-out!）则重传。