目录
一、基础协议
1、网络分层模型
为了使不同计算机厂家生产的计算机能够相互通信，以便在更大的范围内建立计算机网络，国际标准化组织（ISO）在1978年提出了“开放系统互联参考模型”，即著名的OSI/RM模型（Open System Interconnection/Reference Model）。它将计算机网络体系结构的通信协议划分为七层，自下而上依次为：物理层（Physics Layer）、数据链路层（Data Link Layer）、网络层（Network Layer）、传输层（Transport Layer）、会话层（Session Layer）、表示层（Presentation Layer）、应用层（Application Layer）。
2、协议划分
物理层：以太网 · 调制解调器 · 电力线通信(PLC) · SONET/SDH · G.709 · 光导纤维 · 同轴电缆 · 双绞线等
数据链路层：Wi-Fi(IEEE 802.11) · WiMAX(IEEE 802.16) ·ATM · DTM · 令牌环 · 以太网 ·FDDI · 帧中继 · GPRS · EVDO ·HSPA · HDLC · PPP · L2TP ·PPTP · ISDN·STP · CSMA/CD等
网络层协议：IP (IPv4 · IPv6) · ICMP· ICMPv6·IGMP ·IS-IS · IPsec · ARP · RARP · RIP等
传输层协议：TCP · UDP · TLS · DCCP · SCTP · RSVP · OSPF 等
应用层协议：DHCP ·DNS · FTP · Gopher · HTTP· WS· IMAP4 · IRC · NNTP · XMPP ·POP3 · SIP · SMTP ·SNMP · SSH ·TELNET · RPC · RTCP · RTP ·RTSP· SDP · SOAP · GTP · STUN · NTP· SSDP · BGP 等
3、重点解析
1）TCP/IP和UDP协议
TCP（Transmission Control Protocol，传输控制协议）是面向连接的协议，即在收发数据钱 ，都需要与对面建立可靠的链接，TCP的三次握手以及TCP的四次挥手！
TCP的6种标志位的分别代表：
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码) (ack)
各个状态的意义如下：
LISTEN - 侦听来自远方TCP端口的连接请求；
SYN-SENT -在发送连接请求后等待匹配的连接请求；
SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；
ESTABLISHED- 代表一个打开的连接，数据可以传送给用户；
FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；
FIN-WAIT-2 - 从远程TCP等待连接中断请求；
CLOSE-WAIT - 等待从本地用户发来的连接中断请求；
CLOSING -等待远程TCP对连接中断的确认；
LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；
TIME-WAIT -等待足够的时间以确保远程TCP接收到连接中断请求的确认；
CLOSED - 没有任何连接状态；
三次握手： 建立一个TCP连接时，需要客户端和服务端总共发送3个包以确认连接的建立， 在Socket编程中，这一过程由客户端执行connect来触发，具体流程图如下：
- 第一次握手：Client将标志位SYN置为1，随机产生一个值seq=J，并将该数据包发送给Server， Client进入SYN_SENT状态，等待Server确认。
- 第二次握手：Server收到数据包后由标志位SYN=1知道Client请求建立连接，Server将标志位 SYN和ACK都置为1，ack=J+1，随机产生一个值seq=K，并将该数据包发送给Client以确认连接请求 ，Server进入SYN_RCVD状态。
- 第三次握手：Client收到确认后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK 置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则 连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以 开始传输数据了。
四次挥手： 终止TCP连接，就是指断开一个TCP连接时，需要客户端和服务端总共发送4个包以确认连接的断开。 在Socket编程中，这一过程由客户端或服务端任一方执行close来触发，具体流程图如下：
- 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入 FIN_WAIT_1状态
- 第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同， 一个FIN占用一个序号），Server进入CLOSE_WAIT状态。
- 第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK 状态。
- 第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。 另外也可能是同时发起主动关闭的情况：
另外还可能有一个常见的问题就是：为什么建立连接是三次握手，而关闭连接却是四次挥手呢？ 答：因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里 发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还 能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些 数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会 分开发送。
UDP(User Datagram Protocol)用户数据报协议，非连接的协议，传输数据之前源端和终端不 建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。 在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽 的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。 相比TCP就是无需建立链接，结构简单，无法保证正确性，容易丢包。UDP协议多应用于广播。
2）HTTP和HTTPS协议
Http(超文本传输协议)， 是用于传输诸如HTML的超媒体文档的应用层协议。它被设计用于Web浏览器和Web服务器之间的通信，但它也可以用于其他目的。 HTTP遵循经典的客户端-服务端模型，客户端打开一个连接以发出请求，然后等待它收到服务器端响应。HTTP是无状态协议，意味着服务器不会在两个请求之间保留任何数据（状态）。
Http1.0协议，客户端与web服务器建立连接后，只能获得一个web资源！
Http1.1协议，允许客户端与web服务器建立连接后，在一个连接上获取多个web资源！
前面讲过了三次握手，再看一下Http操作的一个流程了：
- 用户点击浏览器上的url(超链接)，Web浏览器与Web服务器建立连接
- 建立连接后，客户端发送请求给服务器，请求的格式为: 统一资源标识符(URL)+协议版本号(一般是1.1)+MIME信息(多个消息头)+一个空行
- 服务端收到请求后，给予相应的返回信息，返回格式为: 协议版本号 + 状态行(处理结果) + 多个信息头 + 空行 + 实体内容(比如返回的HTML)
- 客户端接收服务端返回信息，通过浏览器显示出来，然后与服务端断开连接；当然如果中途 某步发生错误的话，错误信息会返回到客户端，并显示，比如：经典的404错误！
Http的几种请求方式
实际开发中我们用得较多的方式是Get和Post，但是实际开发可能还会用到其他请求方式。
- Get：请求获取Request-URI所标识的资源
- POST：在Request-URI所标识的资源后附加新的数据
- HEAD 请求获取由Request-URI所标识的资源的响应信息报头
- PUT：请求服务器存储一个资源，并用Request-URI作为其标识
- DELETE：请求服务器删除Request-URI所标识的资源
- TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断
- CONNECT：保留将来使用
- OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项
Get请求和Post请求的对比：
Get产生一个TCP数据包；Post产生两个TCP数据包。
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
对于POST，浏览器先发送header，服务器响应100（continue），然后再发送data，服务器响应200（返回数据）；
Http状态码合集
当然，这些状态码只是要给参考，实际上决定权在服务器端(后台的)手上，一种方案是请求后， 服务器返回给我们的是状态，或者另一种，在应用不用弄多语言版本的时候最好用，直接返回 一串结果信息的Json给我们，我们直接显示就好，这样可以偷懒不少！下面列下状态码合集，参考 下就好：
- 100~199 : 成功接受请求，客户端需提交下一次请求才能完成整个处理过程
- 200: OK，客户端请求成功
- 300~399：请求资源已移到新的地址(302,307,304)
- 401：请求未授权，改状态代码需与WWW-Authenticate报头域一起使用
- 403：Forbidden，服务器收到请求，但是拒绝提供服务
- 404：Not Found，请求资源不存在，这个就不用说啦
- 500：Internal Server Error，服务器发生不可预期的错误
- 503：Server Unavailable，服务器当前不能处理客户端请求，一段时间后可能恢复正常
HTTP Request Header请求头信息对照表:
|
Header |
解释 |
示例 |
|
Accept |
指定客户端能够接收的内容类型 |
Accept: text/plain, text/html |
|
Accept-Charset |
浏览器可以接受的字符编码集。 |
Accept-Charset: iso-8859-5 |
|
Accept-Encoding |
指定浏览器可以支持的web服务器返回内容压缩编码类型。 |
Accept-Encoding: compress, gzip |
|
Accept-Language |
浏览器可接受的语言 |
Accept-Language: en,zh |
|
Accept-Ranges |
可以请求网页实体的一个或者多个子范围字段 |
Accept-Ranges: bytes |
|
Authorization |
HTTP授权的授权证书 |
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
|
Cache-Control |
指定请求和响应遵循的缓存机制 |
Cache-Control: no-cache |
|
Connection |
表示是否需要持久连接。（HTTP 1.1默认进行持久连接） |
Connection: close |
|
Cookie |
HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 |
Cookie: $Version=1; Skin=new; |
|
Content-Length |
请求的内容长度 |
Content-Length: 348 |
|
Content-Type |
请求的与实体对应的MIME信息 |
Content-Type: application/x-www-form-urlencoded |
|
Date |
请求发送的日期和时间 |
Date: Tue, 15 Nov 2010 08:12:31 GMT |
|
Expect |
请求的特定的服务器行为 |
Expect: 100-continue |
|
From |
发出请求的用户的Email |
From: [email protected] |
|
Host |
指定请求的服务器的域名和端口号 |
Host: www.zcmhi.com |
|
If-Match |
只有请求内容与实体相匹配才有效 |
If-Match: "737060cd8c284d8af7ad3082f209582d" |
|
If-Modified-Since |
如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 |
If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
|
If-None-Match |
如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 |
If-None-Match: "737060cd8c284d8af7ad3082f209582d" |
|
If-Range |
如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag |
If-Range: "737060cd8c284d8af7ad3082f209582d" |
|
If-Unmodified-Since |
只在实体在指定时间之后未被修改才请求成功 |
If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
|
Max-Forwards |
限制信息通过代理和网关传送的时间 |
Max-Forwards: 10 |
|
Pragma |
用来包含实现特定的指令 |
Pragma: no-cache |
|
Proxy-Authorization |
连接到代理的授权证书 |
Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
|
Range |
只请求实体的一部分，指定范围 |
Range: bytes=500-999 |
|
Referer |
先前网页的地址，当前请求网页紧随其后,即来路 |
Referer: http://blog.****.net/coder_pig |
|
TE |
客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 |
TE: trailers,deflate;q=0.5 |
|
Upgrade |
向服务器指定某种传输协议以便服务器进行转换（如果支持） |
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
|
User-Agent |
User-Agent的内容包含发出请求的用户信息 |
User-Agent: Mozilla/5.0 (Linux; X11) |
|
Via |
通知中间网关或代理服务器地址，通信协议 |
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
|
Warning |
关于消息实体的警告信息 |
Warn: 199 Miscellaneous warning |
HTTP Responses Header 响应头信息对照表：
|
Header |
解释 |
示例 |
|
Accept-Ranges |
表明服务器是否支持指定范围请求及哪种类型的分段请求 |
Accept-Ranges: bytes |
|
Age |
从原始服务器到代理缓存形成的估算时间（以秒计，非负） |
Age: 12 |
|
Allow |
对某网络资源的有效的请求行为，不允许则返回405 |
Allow: GET, HEAD |
|
Cache-Control |
告诉所有的缓存机制是否可以缓存及哪种类型 |
Cache-Control: no-cache |
|
Content-Encoding |
web服务器支持的返回内容压缩编码类型 |
Content-Encoding: gzip |
|
Content-Language |
响应体的语言 |
Content-Language: en,zh |
|
Content-Length |
响应体的长度 |
Content-Length: 348 |
|
Content-Location |
请求资源可替代的备用的另一地址 |
Content-Location: /index.htm |
|
Content-MD5 |
返回资源的MD5校验值 |
Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
|
Content-Range |
在整个返回体中本部分的字节位置 |
Content-Range: bytes 21010-47021/47022 |
|
Content-Type |
返回内容的MIME类型 |
Content-Type: text/html; charset=utf-8 |
|
Date |
原始服务器消息发出的时间 |
Date: Tue, 15 Nov 2010 08:12:31 GMT |
|
ETag |
请求变量的实体标签的当前值 |
ETag: "737060cd8c284d8af7ad3082f209582d" |
|
Expires |
响应过期的日期和时间 |
Expires: Thu, 01 Dec 2010 16:00:00 GMT |
|
Last-Modified |
请求资源的最后修改时间 |
Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
|
Location |
用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 |
Location: http://blog.****.net/coder_pig |
|
Pragma |
包括实现特定的指令，它可应用到响应链上的任何接收方 |
Pragma: no-cache |
|
Proxy-Authenticate |
它指出认证方案和可应用到代理的该URL上的参数 |
Proxy-Authenticate: Basic |
HTTPS 协议，是由 HTTP 加上 TLS/SSL 协议构建的可进行加密传输、身份认证的网络协议，主要通过数字证书、加密算法、非对称**等技术完成互联网数据传输加密，实现互联网传输安全保护。设计目标主要有三个。
（1）数据保密性：保证数据内容在传输的过程中不会被第三方查看。就像快递员传递包裹一样，都进行了封装，别人无法获知里面装了什么。
（2）数据完整性：及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收。
（3）身份校验安全性：保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方，通过身份校验来确保送对了地方。
HTTPS协议的改进
双向的身份认证
客户端和服务端在传输数据之前,会通过基于X.509证书对双方进行身份认证 。具体过程如下 [3] :
客户端发起 SSL 握手消息给服务端要求连接。
服务端将证书发送给客户端。
客户端检查服务端证书，确认是否由自己信任的证书签发机构签发。 如果不是，将是否继续通讯的决定权交给用户选择 ( 注意，这里将是一个安全缺陷 )。如果检查无误或者用户选择继续，则客户端认可服务端的身份。
服务端要求客户端发送证书，并检查是否通过验证。失败则关闭连接，认证成功则从客户端证书中获得客户端的公钥，一般为1024位或者 2048位。到此，服务器客户端双方的身份认证结束，双方确保身份都是真实可靠的。
数据传输的机密性
客户端和服务端在开始传输数据之前，会协商传输过程需要使用的加密算法。 客户端发送协商请求给服务端, 其中包含自己支持的非对成加密的**交换算法 ( 一般是RSA), 数据签名摘要算法 ( 一般是SHA或者MD5) , 加密传输数据的对称加密算法 ( 一般是DES),以及加***的长度。 服务端接收到消息之后，选中安全性最高的算法，并将选中的算法发送给客户端，完成协商。客户端生成随机的字符串，通过协商好的非对称加密算法，使用服务端的公钥对该字符串进行加密，发送给服务端。 服务端接收到之后，使用自己的私钥解密得到该字符串。在随后的数据传输当中，使用这个字符串作为**进行对称加密 [3] 。
防止重放攻击
SSL使用***来保护通讯方免受报文重放攻击。这个***被加密后作为数据包的负载。在整个SSL握手中,都有一个唯一的随机数来标记SSL握手。 这样防止了攻击者嗅探整个登录过程，获取到加密的登录数据之后，不对数据进行解密, 而直接重传登录数据包的攻击手法。
可以看到，鉴于电子商务等安全上的需求，HTTPS对比HTTP 协议，在安全方面已经取得了极大的增强。总结来说，HTTPS的改进点在于创造性的使用了非对称加密算法，在不安全的网路上，安全的传输了用来进行非对称加密的**，综合利用了非对称加密的安全性和对称加密的快速性 。
与HTTP原理区别
HTTPS 主要由两部分组成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过 TLS 进行加密，所以传输的数据都是加密后的数据。
3）WS和WSS协议
WebSocket协议是html5的一种通信协议，该协议兼容我们常用的浏览器。例如Chrome、 Firefox、IE等。它可以使客户端和服务端双向数据传输更加简单快捷，并且在TCP连接进行一次握手后，就可以持久性连接，同时允许服务端对客户端推送数据。外加传统模式的协议一般HTTP请求可能会包含较长的头部，但真正有效的可能只有小部分，从而就占用了很多资源和带宽。因此WebSocket协议不仅可以实时通讯，支持扩展；也可以压缩节省服务器资源和带宽。
WS协议和WSS协议两个均是WebSocket协议的SCHEM，两者一个是非安全的，一个是安全的。也是统一的资源标志符。就好比HTTP协议和HTTPS协议的差别。非安全的没有证书，安全的需要SSL证书。（SSL是Netscape所研发，用来保障网络中数据传输的安全性，主要是运用数据加密的技术，能够避免数据在传输过程被不被窃取或者监听。）其中WSS表示在TLS之上的WebSocket。WS一般默认是80端口，而WSS默认是443端口，大多数网站用的就是80和433端口。（在高防防护过程中，80和433端口的网站是需要备案才可以接入国内的。）当然网站也会有别的端口，这种如果做高防是方案是可以用海外高防的。WS和WSS的体现形式分别是TCP+WS AS WS ，TCP+TLS+WS AS WS。服务器网址就是 URL。
最后再说下WebSocket协议的特点：建立在 TCP 协议之上，服务端实现容易；与 HTTP 协议有良好的兼容性，握手时不容易被屏蔽，可以通过各种 HTTP 代理服务器；数据轻量，实时通讯；可以发送文本和二进制数据。不限制同源，客户端可以与任意服务器端进行通讯。因此WebSocket协议的出现，为很多人解决了关于扩展以及兼容性协议的烦恼问题。
4）SSL、TLS和SSH协议
- SSL（Secure Socket Layer--安全套接字层）：为网络通信安全以及数据完整性提供保障的一种安全协议，在TCP/IP的传输层对网络连接进行加密；
- TLS（Transport Layer Security--传输层安全）：为SSL 3.0的后继版本，TSL与SSL 3.0的显著差别在于加密算法不同，TSL的主要目的是使SSL更加安全，使协议的规范更加精确和完善，在TCP/IP的传输层对网络连接进行加密；
- SSH（Secure Shell）：由 IETF 的网络工作小组（Network Working Group）所制定；SSH 为建立在应用层和传输层基础上的安全协议。SSH 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。
以上各协议通常使用的摘要算法：
SHA （全称Secure Hash Algorithm） 译作安全散列算法，是一种能将任意长度的消息映射成一个固定长度散列值（又称消息摘要）的算法。
SHA家族的五个算法，分别是SHA-1、SHA-224、SHA-256、SHA-384,和SHA-512,后四者有时并称为SHA-2.SHA-1在许多安全协议中广泛使用，包括TLS和SSL、PGP、SSH、S/MIME和IPsec.在2005年，密码学家就证明SHA-1的**速度比预期提高了2000倍，虽然**仍然是极其困难和昂贵的，但随着计算机变得越来越快和越来越廉价，SHA-1算法的安全性也逐年降低，已被密码学家严重质疑，希望由安全强度更高的SHA-2替代它。
5）SOAP协议
SOAP（Simple Object Accrss Protocol，简单对象访问协议）是一种简单的基于XML的协议，可以使应用程序在分散或分布式的环境中通过HTTP来交换信息。
SOAP基于XML语言和XSD标准，其定义了一套编码规则，编码规则定义如何将数据表示为消息，以及怎样通过HTTP协议来传输SOAP消息，由四部分组成：
（1） SOAP信封（Envelope）：定义了一个框架，框架描述了消息中的内容是什么，包括消息的内容、发送者、接收者、处理者以及如何处理消息。
（2）SOAP编码规则：定义了一种系列化机制，用于交换应用程序所定义的数据类型的实例。
（3） SOAP RPC表示：定义了用于表示远程过程调用和应答协定。
（4）SOAP绑定：定义了一种使用底层传输协议来完成在节点间交换SOAP信封的约定。
SOAP消息基本上是从发送端到接收端的单向传输，常常结合起来执行类似于请求/应答的模式。不需要把SOAP消息绑定到特定的协议，SOAP可以运行在任何其他传输协议（HTTP、SMTP、FTP等）上。另外，SOAP提供了标准的RPC方法来调用Web Service以请求/响应模式运行。
SOAP是Web Service的通信协议。当用户通过UDDI找到你的WSDL描述文档后，他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范，可以支持不同的底层接口，像HTTP(S)或者SMTP。
应用程序通过使用远程过程调用（RPC）在诸如 DCOM 与 CORBA 等对象之间进行通信的方式会产生兼容性以及安全问题；防火墙和代理服务器通常会阻止此类流量。通过 HTTP 在应用程序间通信是更好的方法，因为 HTTP 得到了所有的因特网浏览器及服务器的支持。SOAP 提供了一种标准的方法，使得运行在不同的操作系统并使用不同的技术和编程语言的应用程序可以互相进行通信。
-
SOAP是一种轻量级通信协议
-
SOAP用于应用程序之间的通信
-
使用SOAP的应用使用HTTP协议通信
-
SOAP独立于平台
-
SOAP独立于编程语言
-
SOAP基于XML
-
SOAP很简单并可扩展
-
SOAP允许绕过防火墙
PHP SOAP扩展，提供 SoapClient 和 SoapServer 类，实现web service接口服务，支持提供wsdl文档和不提供wsdl文档两种方式。（参考：https://blog.****.net/ljl890705/article/details/79142383）
二、应用知识
1、PHP Curl 、Ajax 和 调试用Postman 支持HTTP客户端请求（GET、POST）
2、SocketJS 和 html5 WebSocket 支持WS客户端请求
3、\Swoole\Coroutine\Http\Client、\Swoole\Http\WebSocket异步和\EasySwoole\HttpClient\HttpClient（封装前者，协程异步）支持HTTP和WS客户端请求
4、\Swoole\Client(SWOOLE_SOCK_TCP) 支持TCP客户端请求
5、\Swoole\Coroutine\Client 提供了支持TCP、UDP和UnixSocket协议的socket客户端封装，底层实现协程调度，并且支持异步并发请求