swoole知識點有哪些

本篇內容主要講解“swoole知識點有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“swoole知識點有哪些”吧!

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的連接數有限,以及連接的開啟關閉需要消耗大量資源,所以我們可以使用連接池方案實現共用連接(只要保證每個連接每次只有一個協程在使用即可)

到此，相信大家對“swoole知識點有哪些”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！