swoole 知识小课堂

swoole php 执行过程
fastcgi请求到swoole master进程去分发到子进程,但是不会像php-fpm的子进程使用完后退出

swoole聊天室流程讲解

整个聊天室流程为:
- 用户http接口登录获得授权
- 通过授权请求http接口获得好友列表,不同好友的最后一条未读消息以及未读消息数(用于首页显示)
- 通过授权请求获得群列表(群消息为了节省存储空间没有做已读未读)
- 建立ws链接
- 注册断线重连机制,当触发close事件时,重连ws
- 建立ping定时器,每隔30秒进行一次ping
- 通过ws接口,获得所有未读消息,客户端进行处理,推送到通知栏等
- 接收新消息推送,并显示到消息列表
- 当点击进某个群/好友消息界面时,自动获取最新n条消息,用户上拉时继续获取n条

行模式运

cgi 协议模式

cgi模式 通用网关接口(Common Gateway Interface),它允许web服务器通过特定的协议与应用程序通信, 调用原理大概为:
用户请求->Web服务器接收请求->fork子进程 
调用程序/执行程序->程序返回内容/程序调用结束->web服务器接收内容->返回给用户 
由于每次用户请求,都得fork创建进程调用一次程序,然后销毁进程,所以性能较低

fast-cgi 协议模式

fast-cgi是cgi模式的升级版,它像是一个常驻型的cgi,只要开启后,就可一直处理请求,不再需要结束进程, 调用原理大概为:
web服务器fast-cgi进程管理器初始化->预先fork n个进程
用户请求->web服务器接收请求->交给fast-cgi进程管理器->fast-cgi进程管理区接收,给其中一个空闲fast-cgi进程处理->处理完成,fast-cgi进程变为空闲状态,等待下次请求->web服务器接收内容->返回给用户模块模式

模块模式

apache+php运行时,默认使用的是模块模式,它把php作为apache的模块随apache启动而启动,接收到用户请求时则直接通过调用mod_php模块进行处理,详细内容可自行百度

php-cli模式

php-cli模式属于命令行模式,对于很多刚开始学php就开始wamp,wnmp的开发者来说是最陌生的一种运行模式
该模式不需要借助其他程序,直接输入php xx.php 就能执行php代码
命令行模式和常规web模式明显不一样的是:
* 没有超时时间
* 默认关闭buffer缓冲
* STDIN和STDOUT标准输入/输出/错误 的使用
* echo var_dump,phpinfo等输出直接输出到控制台
* 可使用的类/函数 不同
* php.ini配置的不同

php-fpm

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

工作原理:

它的工作原理大概为:
php-fpm启动->生成n个fast-cgi协议处理进程->监听一个端口等待任务
用户请求->web服务器接收请求->请求转发给php-fpm->php-fpm交给一个空闲进程处理
->进程处理完成->php-fpm返回给web服务器->web服务器接收数据->返回给用户

网络协议

网络协议为计算机网络中进行数据交换而建立的规则,标准或约定的集合,所有的计算机/手机等网络设备通信都得遵循网络协议.
网络协议根据通信的步骤,层级划分为7个层级,从上往下为:
  • 应用层
  • 表示层
  • 会话层
  • 传输层
  • 网络层
  • 数据链路层
  • 物理层

ip协议(网络层)

ip协议是互联网的基础协议,它是目前最流行的一种网络协议

范围

IP的责任就是把数据从源传送到目的地。它不负责保证传送可靠性,流控制,包顺序和其它对于主机到主机协议来说很普通的服务。

接口

这个协议由主机到主机协议调用,而此协议负责调用本地网络协议将数据包传送以下一个网关或目的主机。例如TCP可以调用IP协议,在调用时传送目的地址和源地址作为参数,IP形成数据包并调用本地网络(协议)接口传送数据包。

操作

IP实现两个基本功能:寻址和分段。IP可以根据数据包包头中包括的目的地址将数据包传送到目的地址,在此过程中IP负责选择传送的道路,这种选择道路称为路由功能。如果有些网络内只能传送小数据包,IP可以将数据包重新组装并在报头域内注明。IP模块中包括这些基本功能,这些模块存在于网络中的每台主机和网关上,而且这些模块(特别在网关上)有路由选择和其它服务功能。对IP来说,数据包之间没有什么联系,对IP不好说什么连接或逻辑链路。
IP使用四个关键技术提供服务:服务类型,生存时间,选项和报头校验码。服务类型指希望得到的服务质量。服务类型是一个参数集,这些参数是Internet能够提供服务的代表。这种服务类型由网关使用,用于在特定的网络,或是用于下下一个要经过的网络,或是下一个要对这个数据包进行路由的网关上选择实际的传送参数。生存时间是数据包可以生存的时间上限。它由发送者设置,由经过路由的地方处理。如果未到达时生存时间为零,抛弃此数据包。对于控制函数来说选项是重要的,但对于通常的通信来说它没有存在的必要。选项包括时间戳,安全和特殊路由。报头校验码保证数据的正确传输。如果校验出错,抛弃整个数据包。

ip地址

把数据从源传送到目的地时,需要有ip地址才能传输,现在ip地址分为ipv4和ipv6 两种地址,现在最常见的就是ipv4地址,例如127.0.0.1(本机地址) 119.75.217.109(百度ip)
ip传输必须要有明确的ip地址,才能进行数据发送

tcp(传输层)

TCP(Transmission Control Protocol 传输控制协议)是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793定义。在简化的计算机网络OSI模型中,它完成第四层传输层所指定的功能,用户数据报协议(UDP)是同一层内 另一个重要的传输协议。在因特网协议族(Internet protocol suite)中,TCP层是位于IP层之上,应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接,但是IP层不提供这样的流机制,而是提供不可靠的包交换。
应用层向TCP层发送用于网间传输的、用8位字节表示的数据流,然后TCP把数据流分区成适当长度的报文段(通常受该计算机连接的网络的数据链路层的最大传输单元( MTU)的限制)。之后TCP把结果包传给IP层,由它来通过网络将包传送给接收端实体 的TCP层。TCP为了保证不发生丢包,就给每个包一个序号,同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认(ACK);如果发送端实体在合理的往返时延(RTT)内未收到确认,那么对应的数据包就被假设为已丢失将会被进行重传。TCP用一个校验和函数来检验数据是否有错误;在发送和接收时都要计算校验和。

三次握手

TCP是因特网中的传输层协议,使用三次握手协议建立连接。当主动方发出SYN连接请求后,等待对方回答SYN+ACK ,并最终对对方的 SYN 执行 ACK 确认。这种建立连接的方法可以防止产生错误的连接,TCP使用的流量控制协议是可变大小的滑动窗口协议。 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连接的另一端。

四次挥手

建立一个连接需要三次握手,而终止一个连接要经过四次挥手,这是由TCP的半关闭(half-close)造成的。具体过程如下所示。
  • 某个应用进程首先调用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

php可通过socket函数,swoole扩展,stream流函数进行创建tcp协议的socket,绑定网卡端口,进行tcp服务端/客户端操作 在php中,我们并不需要了解tcp的握手/挥手,我们只需要知道ip:port能连接/创建 一个tcp服务端/客户端就行了
使用php的socket,我们可以直接发送字符串,接收的也是字符串,其他一切都是语言,操作系统所需要做的事,
我们只需要处理好字符串的完整性,例如我们使用php做tcp服务端

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

http协议

过程解析

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

由于php大部分时候都是用于web服务器,所以php开发者接触最多的协议也就是基于tcp/ip协议的http协议了
在php初级程序员中,其实没有详细的了解过http协议,但是可以通过浏览器的f12->network去查看http协议具体的请求头,以及服务端发送的响应头

WebSocket协议

产生背景

在没有WebSocket协议之前,在网页中,实现一个聊天室只能使用ajax 不断轮询,请求服务器是否有数据产生,而这样的实现方法会出现一系列的问题:
  • 如果轮询时间间隔太短,会导致客户端和服务端在一个时间段内不断的进行http tcp的握手/挥手动作和http 请求头,响应头的传输,大量消耗服务器资源,如果用户量大的情况,会造成服务器的繁忙以至于宕机
  • 客户端每次只能通过发送http 请求获得服务器是否有数据返回,且数据的及时性无法保证

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

实现原理

在实现websocket连线过程中,需要通过浏览器发出websocket连线请求,然后服务器发出回应,这个过程通常称为“握手” 
在 WebSocket API,浏览器和服务器只需要做一个握手的动作,然后,浏览器和服务器之间就形成了一条快速通道。
两者之间就直接可以数据互相传送。在此WebSocket 协议中,为我们实现即时服务带来了两大好处:
  • Header: 互相沟通的Header是很小的-大概只有 2 Bytes
  • Server Push: 服务器的推送,服务器不再被动的接收到浏览器的请求之后才返回数据,而是在有新数据时就主动推送给浏览器。

udp(传输层)

UDP 是User Datagram Protocol的简称, 中文名是用户数据报协议,是OSI(Open System Interconnection,开放式系统互联) 参考模型中一种无连接的传输层协议,提供面向事务的简单不可靠信息传送服务,IETF RFC 768是UDP的正式规范。UDP在IP报文的协议号是17。
UDP协议全称是用户数据报协议,在网络中它与TCP协议一样用于处理数据包,是一种无连接的协议。在OSI模型中,在第四层——传输层,处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点,也就是说,当报文发送之后,是无法得知其是否安全完整到达的。UDP用来支持那些需要在计算机之间传输数据的网络应用。包括网络视频会议系统在内的众多的客户/服务器模式的网络应用都需要使用UDP协议。UDP协议从问世至今已经被使用了很多年,虽然其最初的光彩已经被一些类似协议所掩盖,但是即使是在今天UDP仍然不失为一项非常实用和可行的网络传输层协议。
与所熟知的TCP(传输控制协议)协议一样,UDP协议直接位于IP(网际协议)协议的顶层。根据OSI(开放系统互连)参考模型,UDP和TCP都属于传输层协议。UDP协议的主要作用是将网络数据流量压缩成数据包的形式。一个典型的数据包就是一个二进制数据的传输单位。每一个数据包的前8个字节用来包含报头信息,剩余字节则用来包含具体的传输数据。

udp与tcp

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

php多进程

多进程的概念

前面有讲到,多进程主要是在开发业务逻辑层面,并行处理多个任务的开发方式,什么叫做开发业务逻辑层面呢?
在上面我们有讲到,php-fpm是fast-cgi的进程管理器,启动之后会启动多个fast-cgi进程,等待任务处理

在php-fpm软件层面,fast-cgi的多个进程就属于多进程处理,但是,当用户发起请求,
由nginx交给php-fpm处理请求时,在这个层面,每个请求其实只占有一个php fast-cgi进程进行处理逻辑,对于运行业务逻辑的这个php进程,其实是单进程的.
同理,当我们直接运行一个php文件时,默认是只开启了一个php进程进行运行php的代码

多进程的开发场景

在传统web模式下,php一向是单进程处理业务逻辑,只有在php-cli模式下,用于处理异步任务,作为网络服务器时,才可能用到多进程处理,所以,大部分phper都对php多进程的概念不熟悉

使用pcntl扩展

进程通信

  • 管道通信,分为有名管道,无名管道等,可自行搜索了解详细
  • 消息队列通信,使用linux消息队列,通过sysvmsg扩展,可查看: http://www.php20.cn/article/137
  • 进程信号通信,可查看: http://www.php20.cn/article/134
  • 共享内存通信,映射一段能被其他进程所访问的内存,这段共享内存由一个进程创建,但多个进程都可以访问。
  • 共享内存是最快的 IPC 方式,它是针对其他进程间通信方式运行效率低而专门设计的。
  • 它往往与其他通信机制,如信号两,配合使用,来实现进程间的同步和通信。
  • 套接字通信
  • 第三方通信,使用文件操作,mysql,redis等方法也可实现通信
协程
协程不是进程或线程,其执行过程更类似于子例程,或者说不带返回值的函数调用。
一个程序可以包含多个协程,可以对比与一个进程包含多个线程,因而下面我们来比较协程和线程。
我们知道多个线程相对独立,有自己的上下文,切换受系统控制;而协程也相对独立,
有自己的上下文,但是其切换由自己控制,由当前协程切换到其他协程由当前协程来控制。

协程与进程

由上面的协程执行顺序中的代码2,我们很容易发现,协程其实只是运行在一个进程中的函数,只是这个函数会被切换到下一个执行,可以这么说:
协程只是一串运行在进程中的任务代码,只是这些任务代码可以交叉运行 注意,协程并不是多任务并行,属于多任务串行,每个进程在一个时间只执行了一个任务

协程的作用域

由于协程就是进程中一串任务代码,所以它的全局变量,静态变量等变量都是共享的,包括了php的全局缓冲区.
所以,在开发之中,需要特别注意协程中的全局变量,静态变量,只要某一个协程内修改了,那将会影响全部的协程,在使用ob缓冲区函数拦截的时候,也得考虑是否会被其他协程的输出给污染.
协程执行顺序中的代码2解释,当task1给$_GET['name']赋值为1时,task2读取$_GET['name']也会是1,task2将$_GET['name']赋值为2时,task3读取$_GET['name']也会是2

协程中的I/O连接

在协程中,要特别注意不能共用一个I/O连接,否则会造成数据异常. 用协程执行顺序中的代码2解释,当task1,task2函数共用mysql连接,并都进行查询时,由于协程是交叉运行的,可能会造成task1获取到task1+task2查询出来的数据,也可能会丢失部分数据,被task2获取.
由于协程的交叉运行机制,各个协程的I/O连接都必须是独立的,所以我们需要在每个协程都创建一个连接,但由于mysql,redis的连接数有限,以及连接的开启关闭需要消耗大量资源,所以我们可以使用连接池方案实现共用连接(只要保证每个连接每次只有一个协程在使用即可)

Guess you like

Origin blog.csdn.net/qq_27229113/article/details/119646570