[网络协议]swoole 知识小课堂

模块模式

php-cli模式

php-fpm

• 支持平滑停止/启动的高级进程管理功能;
• 可以工作于不同的 uid/gid/chroot 环境下，并监听不同的端口和使用不同的 php.ini 配置文件（可取代 safe_mode 的设置）;
• stdout 和 stderr 日志记录;
• 在发生意外情况的时候能够重新启动并缓存被破坏的 opcode;
• 文件上传优化支持;
• "慢日志" - 记录脚本（不仅记录文件名，还记录 PHP backtrace 信息，可以使用 ptrace或者类似工具读取和分析远程进程的运行数据）运行所导致的异常缓慢;
• fastcgi_finish_request() - 特殊功能：用于在请求完成和刷新数据后，继续在后台执行耗时的工作（录入视频转换、统计处理等）;
• 动态／静态子进程产生;
• 基本 SAPI 运行状态信息（类似Apache的 mod_status）;
• 基于 php.ini 的配置文件。

工作原理:

网络协议

• 应用层
• 表示层
• 会话层
• 传输层
• 网络层
• 数据链路层
• 物理层

ip协议(网络层)

范围

接口

操作

ip地址

tcp(传输层)

三次握手

• 客户端发送SYN（SEQ=x）报文给服务器端，进入SYN_SEND状态。
• 服务器端收到SYN报文，回应一个SYN （SEQ=y）ACK(ACK=x+1）报文，进入SYN_RECV状态。
• 客户端收到服务器端的SYN报文，回应一个ACK(ACK=y+1）报文，进入Established状态。

连接成功

• 传输的数据被tcp分割成了最适合发送的数据块 传递给ip协议,这个发送数据称为 报文段 或 段
• tcp作为可靠性连接,每次发送数据段,会启动一个定时器,每次接收数据段,会发送一次确认,如果定时器没有及时收到确认,则会重发数据
• TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段（希望发端超时并重发）。
• 两个应用程序通过TCP连接交换8bit字节构成的字节流。TCP不在字节流中插入记录标识符。我们将这称为字节流服务（bytestreamservice）。如果一方的应用程序先传10字节，又传20字节，再传50字节，连接的另一方将无法了解发方每次发送了多少字节。只要自己的接收缓存没有塞满，TCP 接收方将有多少就收多少。一端将字节流放到TCP连接上，同样的字节流将出现在TCP连接的另一端。

四次挥手

• 某个应用进程首先调用close，称该端执行“主动关闭”（active close）。该端的TCP于是发送一个FIN分节，表示数据发送完毕。
• 接收到这个FIN的对端执行 “被动关闭”（passive close），这个FIN由TCP确认。
• 注意：FIN的接收也作为一个文件结束符（end-of-file）传递给接收端应用进程，放在已排队等候该应用进程接收的任何其他数据之后，因为，FIN的接收意味着接收端应用进程在相应连接上再无额外数据可接收。
• 一段时间后，接收到这个文件结束符的应用进程将调用close关闭它的套接字。这导致它的TCP也发送一个FIN。
• 接收这个最终FIN的原发送端TCP（即执行主动关闭的那一端）确认这个FIN。 既然每个方向都需要一个FIN和一个ACK，因此通常需要4个分节。

“通常”是指，某些情况下，步骤1的FIN随数据一起发送，另外，步骤2和步骤3发送的分节都出自执行被动关闭那一端，有可能被合并成一个分节。 在步骤2与步骤3之间，从执行被动关闭一端到执行主动关闭一端流动数据是可能的，这称为“半关闭”（half-close）。 当一个Unix进程无论自愿地（调用exit或从main函数返回）还是非自愿地（收到一个终止本进程的信号）终止时，所有打开的描述符都被关闭，这也导致仍然打开的任何TCP连接上也发出一个FIN。 无论是客户还是服务器，任何一端都可以执行主动关闭。通常情况是，客户执行主动关闭，但是某些协议，例如，HTTP/1.0却由服务器执行主动关闭。

php中的tcp

• 客户端连接成功后,发送了一个"easyswoole是一个非常好的swoole框架"的字符串
• 而服务端每次只接收9个字节,那第一次获取只会接收到"easyswool"的残缺字符串,需要继续获取数据

http协议

过程解析

• 用户在浏览器输入 www.easyswoole.com
• dns服务器解析/或者本机hosts,路由器hosts对比 获得ip
• 浏览器访问默认端口80,则访问的tcp地址为 ip:80
• tcp协议3次握手,建立连接
• 发送一个http request请求头
• 服务器获得http request请求头,表明该次访问为http访问,解析http请求头,获得请求类型,请求格式,以及请求数据(cookie,get,post数据)
• 服务器发送response响应数据,主动断开
• 浏览器接收response响应数据,解析响应文本类型,解析数据,断开连接

  https协议中,在请求以及响应时多了一层tls,ssl加密解密协议,默认端口从80变为了443

phper中的http

WebSocket协议

产生背景

• 如果轮询时间间隔太短,会导致客户端和服务端在一个时间段内不断的进行http tcp的握手/挥手动作和http 请求头,响应头的传输,大量消耗服务器资源,如果用户量大的情况,会造成服务器的繁忙以至于宕机
• 客户端每次只能通过发送http 请求获得服务器是否有数据返回,且数据的及时性无法保证

正因为在这种情况下,所以WebSocket出现了,它只需要一次http握手,就可以保持一个长连接,使得服务器可以主动发送消息给客户端,大大减少了轮询机制的消耗

实现原理

• Header: 互相沟通的Header是很小的-大概只有 2 Bytes
• Server Push: 服务器的推送，服务器不再被动的接收到浏览器的请求之后才返回数据，而是在有新数据时就主动推送给浏览器。

udp(传输层)

udp与tcp

• udp是无连接协议,不需要进行tcp的握手
• udp每次发送最大长度是65535,而tcp在握手后可以源源不断的发送
• udp协议使用报头中的校验值来保证数据的安全。校验值首先在数据发送方通过特殊的算法计算得出，在传递到接收方之后，还需要再重新计算。如果某个数据报在传输过程中被第三方篡改或者由于线路噪音等原因受到损坏，发送和接收方的校验计算值将不会相符，由此UDP协议可以检测是否出错。这与TCP协议是不同的，后者要求必须具有校验值。
• udp报文没有可靠性保证、顺序保证和流量控制字段等，可靠性较差。但是正因为udp协议的控制选项较少，在数据传输过程中延迟小、数据传输效率高，适合对可靠性要求不高的应用程序，或者可以保障可靠性的应用程序，如DNS、TFTP、SNMP等。
• 在网络质量令人十分不满意的环境下，UDP协议数据包丢失会比较严重。而tcp会进行确认验证,确保对方接收成功
• udp可实现对网关内的所有主机进行广播

php多进程

多进程的概念

多进程的开发场景

使用pcntl扩展

进程通信

• 管道通信,分为有名管道,无名管道等,可自行搜索了解详细
• 消息队列通信,使用linux消息队列,通过sysvmsg扩展,可查看: http://www.php20.cn/article/137
• 进程信号通信,可查看: http://www.php20.cn/article/134
• 共享内存通信,映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问。
• 共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。
• 它往往与其他通信机制，如信号两，配合使用，来实现进程间的同步和通信。
• 套接字通信
• 第三方通信,使用文件操作,mysql,redis等方法也可实现通信

协程与进程

协程只是一串运行在进程中的任务代码,只是这些任务代码可以交叉运行 注意,协程并不是多任务并行,属于多任务串行,每个进程在一个时间只执行了一个任务

协程的作用域

协程中的I/O连接

由于协程的交叉运行机制,各个协程的I/O连接都必须是独立的,所以我们需要在每个协程都创建一个连接,但由于mysql,redis的连接数有限,以及连接的开启关闭需要消耗大量资源,所以我们可以使用连接池方案实现共用连接(只要保证每个连接每次只有一个协程在使用即可)