先介绍一下使用场景，ESP8266进入AP模式进行监听，浏览器发起GET请求，然后WiFi模块进入透传模式回复，最后主动断开连接。
因为直接使用的串口助手，8266也设置的回传模式，所以这里可以看到相应的返回，出现了busy s...
那么这个busy对我们的实际操作有没有影响呢，结合我们浏览器显示的内容：
和实际发送的报文：
HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 08 Apr 2020 09:29:22 GMT
Content-Type: text/plain
Content-Length: 265
Connection: keep-alive
Last-Modified: Tue, 18 Sep 2018 03:55:48 GMT
Accept-Ranges: bytes
RT-Thread is an open source IoT operating system from China, which has strong scalability: from a tiny kernel running on a tiny core, for example ARM Cortex-M0, or Cortex-M3/4/7, to a rich feature system running on MIPS32, ARM Cortex-A8, ARM Cortex-A9 DualCore etc.
可以发现显示的内容中，最后9个字符 Core etc.并没有在网站上显示，而且我们知道，esp8266在进入透传模式的时候，是不会回显的，而这里可以看到在>的后面出现了一个没有显示的字符，这说明，实际的数据已经传输完了，这几个字符是传输完了再补上去的。
清空统计我们再发一次：
实际发送长度为491，而我们统计的长度为482，刚好差了9个字节。
再仔细观察报文，发现一共有9个换行！
那么个人猜测，是由于串口助手发送的换行符，会自动把换行‘\n’转换成\r\n，造成了数据长度的增加，此时把透传发送指令从AT+CIPSEND=0,482改成AT+CIPSEND=0,491：
不仅没有出现busy，数据发送也成功了。
在分析数据的过程中，因为页面内显示内容(RT-Thread is an open source IoT operating system from China, which has strong scalability: from a tiny kernel running on a tiny core, for example ARM Cortex-M0, or Cortex-M3/4/7, to a rich feature system running on MIPS32, ARM Cortex-A8, ARM Cortex-A9 Dual)的长度刚好是256bytes，考虑到会不会是因为某些原因，导致了传输过程中只能传输255+1个字节，还去搜索了一波关于HTTP和GET的相关知识，发现好像并不是，最后还是通过观察串口助手的数据统计发现的。
虽然在程序中，我们自己写的发送函数一般是不会经过转义的，但在使用一些第三方库的时候，比如rt-thread的rt_kprintf，默认勾选流输出的时候，就会自动把\n转成\r\n，上次在使用rt-thread+lan8720a+lwip试玩webclient组件的时候，也遇到过后面9bytes显示不全的问题，而这次使用的是esp8266，并没有连接到家里的路由器，甚至使用的电脑都不是同一台……除了数据包内容的原因，可能就再也找不到别的原因了（博主曾经看到过esp8266刷AT固件使用的lwip协议栈，如果没找出这个转义的问题，可能就要准备去查lwip源码了T_T）。
