本篇內(nèi)容主要講解“swoole知識(shí)點(diǎn)有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“swoole知識(shí)點(diǎn)有哪些”吧!

創(chuàng)新互聯(lián)建站自2013年創(chuàng)立以來，先為東平等服務(wù)建站，東平等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為東平企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。

swoole聊天室流程講解

整個(gè)聊天室流程為:

- 用戶http接口登錄獲得授權(quán)

- 通過授權(quán)請(qǐng)求http接口獲得好友列表,不同好友的最后一條未讀消息以及未讀消息數(shù)(用于首頁顯示)

- 通過授權(quán)請(qǐng)求獲得群列表(群消息為了節(jié)省存儲(chǔ)空間沒有做已讀未讀)

- 建立ws鏈接

- 注冊(cè)斷線重連機(jī)制,當(dāng)觸發(fā)close事件時(shí),重連ws

- 建立ping定時(shí)器,每隔30秒進(jìn)行一次ping

- 通過ws接口,獲得所有未讀消息,客戶端進(jìn)行處理,推送到通知欄等

- 接收新消息推送,并顯示到消息列表

- 當(dāng)點(diǎn)擊進(jìn)某個(gè)群/好友消息界面時(shí),自動(dòng)獲取最新n條消息,用戶上拉時(shí)繼續(xù)獲取n條

行模式運(yùn)

cgi 協(xié)議模式

cgi模式 通用網(wǎng)關(guān)接口（Common Gateway Interface）,它允許web服務(wù)器通過特定的協(xié)議與應(yīng)用程序通信, 調(diào)用原理大概為:  

用戶請(qǐng)求->Web服務(wù)器接收請(qǐng)求->fork子進(jìn)程  

調(diào)用程序/執(zhí)行程序->程序返回內(nèi)容/程序調(diào)用結(jié)束->web服務(wù)器接收內(nèi)容->返回給用戶  

由于每次用戶請(qǐng)求,都得fork創(chuàng)建進(jìn)程調(diào)用一次程序,然后銷毀進(jìn)程,所以性能較低  

fast-cgi 協(xié)議模式

fast-cgi是cgi模式的升級(jí)版,它像是一個(gè)常駐型的cgi,只要開啟后,就可一直處理請(qǐng)求,不再需要結(jié)束進(jìn)程, 調(diào)用原理大概為:  

web服務(wù)器fast-cgi進(jìn)程管理器初始化->預(yù)先fork n個(gè)進(jìn)程  

用戶請(qǐng)求->web服務(wù)器接收請(qǐng)求->交給fast-cgi進(jìn)程管理器->fast-cgi進(jìn)程管理區(qū)接收,給其中一個(gè)空閑fast-cgi進(jìn)程處理->處理完成,fast-cgi進(jìn)程變?yōu)榭臻e狀態(tài),等待下次請(qǐng)求->web服務(wù)器接收內(nèi)容->返回給用戶模塊模式  

模塊模式

apache+php運(yùn)行時(shí),默認(rèn)使用的是模塊模式,它把php作為apache的模塊隨apache啟動(dòng)而啟動(dòng),接收到用戶請(qǐng)求時(shí)則直接通過調(diào)用mod_php模塊進(jìn)行處理,詳細(xì)內(nèi)容可自行百度

php-cli模式

php-cli模式屬于命令行模式,對(duì)于很多剛開始學(xué)php就開始wamp,wnmp的開發(fā)者來說是最陌生的一種運(yùn)行模式

該模式不需要借助其他程序,直接輸入php xx.php 就能執(zhí)行php代碼

命令行模式和常規(guī)web模式明顯不一樣的是:

• * 沒有超時(shí)時(shí)間

• * 默認(rèn)關(guān)閉buffer緩沖

• * STDIN和STDOUT標(biāo)準(zhǔn)輸入/輸出/錯(cuò)誤 的使用

• * echo var_dump,phpinfo等輸出直接輸出到控制臺(tái)

• * 可使用的類/函數(shù) 不同

• * php.ini配置的不同

php-fpm

PHP-FPM（FastCGI 進(jìn)程管理器）用于替換 PHP FastCGI 的大部分附加功能，對(duì)于高負(fù)載網(wǎng)站是非常有用的。

它的功能包括:

• 支持平滑停止/啟動(dòng)的高級(jí)進(jìn)程管理功能;

• 可以工作于不同的 uid/gid/chroot 環(huán)境下，并監(jiān)聽不同的端口和使用不同的 php.ini 配置文件（可取代 safe_mode 的設(shè)置）;

• stdout 和 stderr 日志記錄;

• 在發(fā)生意外情況的時(shí)候能夠重新啟動(dòng)并緩存被破壞的 opcode;

• 文件上傳優(yōu)化支持;

• "慢日志" - 記錄腳本（不僅記錄文件名，還記錄 PHP backtrace 信息，可以使用 ptrace或者類似工具讀取和分析遠(yuǎn)程進(jìn)程的運(yùn)行數(shù)據(jù)）運(yùn)行所導(dǎo)致的異常緩慢;

• fastcgi_finish_request() - 特殊功能：用于在請(qǐng)求完成和刷新數(shù)據(jù)后，繼續(xù)在后臺(tái)執(zhí)行耗時(shí)的工作（錄入視頻轉(zhuǎn)換、統(tǒng)計(jì)處理等）;

• 動(dòng)態(tài)／靜態(tài)子進(jìn)程產(chǎn)生;

• 基本 SAPI 運(yùn)行狀態(tài)信息（類似Apache的 mod_status）;

• 基于 php.ini 的配置文件。

工作原理:

它的工作原理大概為:

php-fpm啟動(dòng)->生成n個(gè)fast-cgi協(xié)議處理進(jìn)程->監(jiān)聽一個(gè)端口等待任務(wù)

用戶請(qǐng)求->web服務(wù)器接收請(qǐng)求->請(qǐng)求轉(zhuǎn)發(fā)給php-fpm->php-fpm交給一個(gè)空閑進(jìn)程處理

->進(jìn)程處理完成->php-fpm返回給web服務(wù)器->web服務(wù)器接收數(shù)據(jù)->返回給用戶

網(wǎng)絡(luò)協(xié)議

網(wǎng)絡(luò)協(xié)議為計(jì)算機(jī)網(wǎng)絡(luò)中進(jìn)行數(shù)據(jù)交換而建立的規(guī)則,標(biāo)準(zhǔn)或約定的集合,所有的計(jì)算機(jī)/手機(jī)等網(wǎng)絡(luò)設(shè)備通信都得遵循網(wǎng)絡(luò)協(xié)議.

網(wǎng)絡(luò)協(xié)議根據(jù)通信的步驟,層級(jí)劃分為7個(gè)層級(jí),從上往下為:

• 應(yīng)用層

• 表示層

• 會(huì)話層

• 傳輸層

• 網(wǎng)絡(luò)層

• 數(shù)據(jù)鏈路層

• 物理層

ip協(xié)議(網(wǎng)絡(luò)層)

ip協(xié)議是互聯(lián)網(wǎng)的基礎(chǔ)協(xié)議,它是目前最流行的一種網(wǎng)絡(luò)協(xié)議

范圍

IP的責(zé)任就是把數(shù)據(jù)從源傳送到目的地。它不負(fù)責(zé)保證傳送可靠性，流控制，包順序和其它對(duì)于主機(jī)到主機(jī)協(xié)議來說很普通的服務(wù)。

接口

這個(gè)協(xié)議由主機(jī)到主機(jī)協(xié)議調(diào)用，而此協(xié)議負(fù)責(zé)調(diào)用本地網(wǎng)絡(luò)協(xié)議將數(shù)據(jù)包傳送以下一個(gè)網(wǎng)關(guān)或目的主機(jī)。例如TCP可以調(diào)用IP協(xié)議，在調(diào)用時(shí)傳送目的地址和源地址作為參數(shù)，IP形成數(shù)據(jù)包并調(diào)用本地網(wǎng)絡(luò)（協(xié)議）接口傳送數(shù)據(jù)包。

操作

IP實(shí)現(xiàn)兩個(gè)基本功能：尋址和分段。IP可以根據(jù)數(shù)據(jù)包包頭中包括的目的地址將數(shù)據(jù)包傳送到目的地址，在此過程中IP負(fù)責(zé)選擇傳送的道路，這種選擇道路稱為路由功能。如果有些網(wǎng)絡(luò)內(nèi)只能傳送小數(shù)據(jù)包，IP可以將數(shù)據(jù)包重新組裝并在報(bào)頭域內(nèi)注明。IP模塊中包括這些基本功能，這些模塊存在于網(wǎng)絡(luò)中的每臺(tái)主機(jī)和網(wǎng)關(guān)上，而且這些模塊（特別在網(wǎng)關(guān)上）有路由選擇和其它服務(wù)功能。對(duì)IP來說，數(shù)據(jù)包之間沒有什么聯(lián)系，對(duì)IP不好說什么連接或邏輯鏈路。

IP使用四個(gè)關(guān)鍵技術(shù)提供服務(wù)：服務(wù)類型，生存時(shí)間，選項(xiàng)和報(bào)頭校驗(yàn)碼。服務(wù)類型指希望得到的服務(wù)質(zhì)量。服務(wù)類型是一個(gè)參數(shù)集，這些參數(shù)是Internet能夠提供服務(wù)的代表。這種服務(wù)類型由網(wǎng)關(guān)使用，用于在特定的網(wǎng)絡(luò)，或是用于下下一個(gè)要經(jīng)過的網(wǎng)絡(luò)，或是下一個(gè)要對(duì)這個(gè)數(shù)據(jù)包進(jìn)行路由的網(wǎng)關(guān)上選擇實(shí)際的傳送參數(shù)。生存時(shí)間是數(shù)據(jù)包可以生存的時(shí)間上限。它由發(fā)送者設(shè)置，由經(jīng)過路由的地方處理。如果未到達(dá)時(shí)生存時(shí)間為零，拋棄此數(shù)據(jù)包。對(duì)于控制函數(shù)來說選項(xiàng)是重要的，但對(duì)于通常的通信來說它沒有存在的必要。選項(xiàng)包括時(shí)間戳，安全和特殊路由。報(bào)頭校驗(yàn)碼保證數(shù)據(jù)的正確傳輸。如果校驗(yàn)出錯(cuò)，拋棄整個(gè)數(shù)據(jù)包。

ip地址

把數(shù)據(jù)從源傳送到目的地時(shí),需要有ip地址才能傳輸,現(xiàn)在ip地址分為ipv4和ipv6 兩種地址,現(xiàn)在最常見的就是ipv4地址,例如127.0.0.1(本機(jī)地址) 119.75.217.109(百度ip)

ip傳輸必須要有明確的ip地址,才能進(jìn)行數(shù)據(jù)發(fā)送

tcp(傳輸層)

TCP（Transmission Control Protocol 傳輸控制協(xié)議）是一種面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議，由IETF的RFC 793定義。在簡(jiǎn)化的計(jì)算機(jī)網(wǎng)絡(luò)OSI模型中，它完成第四層傳輸層所指定的功能，用戶數(shù)據(jù)報(bào)協(xié)議（UDP）是同一層內(nèi) 另一個(gè)重要的傳輸協(xié)議。在因特網(wǎng)協(xié)議族（Internet protocol suite）中，TCP層是位于IP層之上，應(yīng)用層之下的中間層。不同主機(jī)的應(yīng)用層之間經(jīng)常需要可靠的、像管道一樣的連接，但是IP層不提供這樣的流機(jī)制，而是提供不可靠的包交換。

應(yīng)用層向TCP層發(fā)送用于網(wǎng)間傳輸?shù)?、?位字節(jié)表示的數(shù)據(jù)流，然后TCP把數(shù)據(jù)流分區(qū)成適當(dāng)長(zhǎng)度的報(bào)文段（通常受該計(jì)算機(jī)連接的網(wǎng)絡(luò)的數(shù)據(jù)鏈路層的最大傳輸單元（ MTU）的限制）。之后TCP把結(jié)果包傳給IP層，由它來通過網(wǎng)絡(luò)將包傳送給接收端實(shí)體 的TCP層。TCP為了保證不發(fā)生丟包，就給每個(gè)包一個(gè)序號(hào)，同時(shí)序號(hào)也保證了傳送到接收端實(shí)體的包的按序接收。然后接收端實(shí)體對(duì)已成功收到的包發(fā)回一個(gè)相應(yīng)的確認(rèn)（ACK）；如果發(fā)送端實(shí)體在合理的往返時(shí)延（RTT）內(nèi)未收到確認(rèn)，那么對(duì)應(yīng)的數(shù)據(jù)包就被假設(shè)為已丟失將會(huì)被進(jìn)行重傳。TCP用一個(gè)校驗(yàn)和函數(shù)來檢驗(yàn)數(shù)據(jù)是否有錯(cuò)誤；在發(fā)送和接收時(shí)都要計(jì)算校驗(yàn)和。

三次握手

TCP是因特網(wǎng)中的傳輸層協(xié)議，使用三次握手協(xié)議建立連接。當(dāng)主動(dòng)方發(fā)出SYN連接請(qǐng)求后，等待對(duì)方回答SYN+ACK ，并最終對(duì)對(duì)方的 SYN 執(zhí)行 ACK 確認(rèn)。這種建立連接的方法可以防止產(chǎn)生錯(cuò)誤的連接，TCP使用的流量控制協(xié)議是可變大小的滑動(dòng)窗口協(xié)議。 TCP三次握手的過程如下：

• 客戶端發(fā)送SYN（SEQ=x）報(bào)文給服務(wù)器端，進(jìn)入SYN_SEND狀態(tài)。

• 服務(wù)器端收到SYN報(bào)文，回應(yīng)一個(gè)SYN （SEQ=y）ACK(ACK=x+1）報(bào)文，進(jìn)入SYN_RECV狀態(tài)。

• 客戶端收到服務(wù)器端的SYN報(bào)文，回應(yīng)一個(gè)ACK(ACK=y+1）報(bào)文，進(jìn)入Established狀態(tài)。

連接成功

連接成功之后雙方即可互相傳輸字節(jié)流,并隨時(shí)可關(guān)閉連接,傳輸?shù)臄?shù)據(jù)有以下特性

• 傳輸?shù)臄?shù)據(jù)被tcp分割成了最適合發(fā)送的數(shù)據(jù)塊 傳遞給ip協(xié)議,這個(gè)發(fā)送數(shù)據(jù)稱為 報(bào)文段 或 段

• tcp作為可靠性連接,每次發(fā)送數(shù)據(jù)段,會(huì)啟動(dòng)一個(gè)定時(shí)器,每次接收數(shù)據(jù)段,會(huì)發(fā)送一次確認(rèn),如果定時(shí)器沒有及時(shí)收到確認(rèn),則會(huì)重發(fā)數(shù)據(jù)

• TCP將保持它首部和數(shù)據(jù)的檢驗(yàn)和。這是一個(gè)端到端的檢驗(yàn)和，目的是檢測(cè)數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗(yàn)和有差錯(cuò)，TCP將丟棄這個(gè)報(bào)文段和不確認(rèn)收到此報(bào)文段（希望發(fā)端超時(shí)并重發(fā)）。

• 兩個(gè)應(yīng)用程序通過TCP連接交換8bit字節(jié)構(gòu)成的字節(jié)流。TCP不在字節(jié)流中插入記錄標(biāo)識(shí)符。我們將這稱為字節(jié)流服務(wù)（bytestreamservice）。如果一方的應(yīng)用程序先傳10字節(jié)，又傳20字節(jié)，再傳50字節(jié)，連接的另一方將無法了解發(fā)方每次發(fā)送了多少字節(jié)。只要自己的接收緩存沒有塞滿，TCP 接收方將有多少就收多少。一端將字節(jié)流放到TCP連接上，同樣的字節(jié)流將出現(xiàn)在TCP連接的另一端。

四次揮手

建立一個(gè)連接需要三次握手，而終止一個(gè)連接要經(jīng)過四次揮手，這是由TCP的半關(guān)閉（half-close）造成的。具體過程如下所示。

• 某個(gè)應(yīng)用進(jìn)程首先調(diào)用close，稱該端執(zhí)行“主動(dòng)關(guān)閉”（active close）。該端的TCP于是發(fā)送一個(gè)FIN分節(jié)，表示數(shù)據(jù)發(fā)送完畢。

• 接收到這個(gè)FIN的對(duì)端執(zhí)行 “被動(dòng)關(guān)閉”（passive close），這個(gè)FIN由TCP確認(rèn)。

• 注意：FIN的接收也作為一個(gè)文件結(jié)束符（end-of-file）傳遞給接收端應(yīng)用進(jìn)程，放在已排隊(duì)等候該應(yīng)用進(jìn)程接收的任何其他數(shù)據(jù)之后，因?yàn)椋現(xiàn)IN的接收意味著接收端應(yīng)用進(jìn)程在相應(yīng)連接上再無額外數(shù)據(jù)可接收。

• 一段時(shí)間后，接收到這個(gè)文件結(jié)束符的應(yīng)用進(jìn)程將調(diào)用close關(guān)閉它的套接字。這導(dǎo)致它的TCP也發(fā)送一個(gè)FIN。

• 接收這個(gè)最終FIN的原發(fā)送端TCP（即執(zhí)行主動(dòng)關(guān)閉的那一端）確認(rèn)這個(gè)FIN。 既然每個(gè)方向都需要一個(gè)FIN和一個(gè)ACK，因此通常需要4個(gè)分節(jié)。

“通常”是指，某些情況下，步驟1的FIN隨數(shù)據(jù)一起發(fā)送，另外，步驟2和步驟3發(fā)送的分節(jié)都出自執(zhí)行被動(dòng)關(guān)閉那一端，有可能被合并成一個(gè)分節(jié)。 在步驟2與步驟3之間，從執(zhí)行被動(dòng)關(guān)閉一端到執(zhí)行主動(dòng)關(guān)閉一端流動(dòng)數(shù)據(jù)是可能的，這稱為“半關(guān)閉”（half-close）。 當(dāng)一個(gè)Unix進(jìn)程無論自愿地（調(diào)用exit或從main函數(shù)返回）還是非自愿地（收到一個(gè)終止本進(jìn)程的信號(hào)）終止時(shí)，所有打開的描述符都被關(guān)閉，這也導(dǎo)致仍然打開的任何TCP連接上也發(fā)出一個(gè)FIN。 無論是客戶還是服務(wù)器，任何一端都可以執(zhí)行主動(dòng)關(guān)閉。通常情況是，客戶執(zhí)行主動(dòng)關(guān)閉，但是某些協(xié)議，例如，HTTP/1.0卻由服務(wù)器執(zhí)行主動(dòng)關(guān)閉。

php中的tcp

php可通過socket函數(shù),swoole擴(kuò)展,stream流函數(shù)進(jìn)行創(chuàng)建tcp協(xié)議的socket,綁定網(wǎng)卡端口,進(jìn)行tcp服務(wù)端/客戶端操作 在php中,我們并不需要了解tcp的握手/揮手,我們只需要知道ip:port能連接/創(chuàng)建 一個(gè)tcp服務(wù)端/客戶端就行了

使用php的socket,我們可以直接發(fā)送字符串,接收的也是字符串,其他一切都是語言,操作系統(tǒng)所需要做的事,

我們只需要處理好字符串的完整性,例如我們使用php做tcp服務(wù)端

• 客戶端連接成功后,發(fā)送了一個(gè)"easyswoole是一個(gè)非常好的swoole框架"的字符串

• 而服務(wù)端每次只接收9個(gè)字節(jié),那第一次獲取只會(huì)接收到"easyswool"的殘缺字符串,需要繼續(xù)獲取數(shù)據(jù)

http協(xié)議

過程解析

http一次請(qǐng)求的過程大概如下:

• 用戶在瀏覽器輸入   www.easyswoole.com

• DNS服務(wù)器解析/或者本機(jī)hosts,路由器hosts對(duì)比 獲得ip

• 瀏覽器訪問默認(rèn)端口80,則訪問的tcp地址為 ip:80

• tcp協(xié)議3次握手,建立連接

• 發(fā)送一個(gè)http request請(qǐng)求頭

• 服務(wù)器獲得http request請(qǐng)求頭,表明該次訪問為http訪問,解析http請(qǐng)求頭,獲得請(qǐng)求類型,請(qǐng)求格式,以及請(qǐng)求數(shù)據(jù)(cookie,get,post數(shù)據(jù))

• 服務(wù)器發(fā)送response響應(yīng)數(shù)據(jù),主動(dòng)斷開

• 瀏覽器接收response響應(yīng)數(shù)據(jù),解析響應(yīng)文本類型,解析數(shù)據(jù),斷開連接

  https協(xié)議中,在請(qǐng)求以及響應(yīng)時(shí)多了一層tls,ssl加密解密協(xié)議,默認(rèn)端口從80變?yōu)榱?43  

phper中的http

由于php大部分時(shí)候都是用于web服務(wù)器,所以php開發(fā)者接觸最多的協(xié)議也就是基于tcp/ip協(xié)議的http協(xié)議了

在php初級(jí)程序員中,其實(shí)沒有詳細(xì)的了解過http協(xié)議,但是可以通過瀏覽器的f12->network去查看http協(xié)議具體的請(qǐng)求頭,以及服務(wù)端發(fā)送的響應(yīng)頭

WebSocket協(xié)議

產(chǎn)生背景

在沒有WebSocket協(xié)議之前,在網(wǎng)頁中,實(shí)現(xiàn)一個(gè)聊天室只能使用ajax 不斷輪詢,請(qǐng)求服務(wù)器是否有數(shù)據(jù)產(chǎn)生,而這樣的實(shí)現(xiàn)方法會(huì)出現(xiàn)一系列的問題:

• 如果輪詢時(shí)間間隔太短,會(huì)導(dǎo)致客戶端和服務(wù)端在一個(gè)時(shí)間段內(nèi)不斷的進(jìn)行http tcp的握手/揮手動(dòng)作和http 請(qǐng)求頭,響應(yīng)頭的傳輸,大量消耗服務(wù)器資源,如果用戶量大的情況,會(huì)造成服務(wù)器的繁忙以至于宕機(jī)

• 客戶端每次只能通過發(fā)送http 請(qǐng)求獲得服務(wù)器是否有數(shù)據(jù)返回,且數(shù)據(jù)的及時(shí)性無法保證

正因?yàn)樵谶@種情況下,所以WebSocket出現(xiàn)了,它只需要一次http握手,就可以保持一個(gè)長(zhǎng)連接,使得服務(wù)器可以主動(dòng)發(fā)送消息給客戶端,大大減少了輪詢機(jī)制的消耗

實(shí)現(xiàn)原理

在實(shí)現(xiàn)websocket連線過程中，需要通過瀏覽器發(fā)出websocket連線請(qǐng)求，然后服務(wù)器發(fā)出回應(yīng)，這個(gè)過程通常稱為“握手”  。

在 WebSocket API，瀏覽器和服務(wù)器只需要做一個(gè)握手的動(dòng)作，然后，瀏覽器和服務(wù)器之間就形成了一條快速通道。

兩者之間就直接可以數(shù)據(jù)互相傳送。在此WebSocket 協(xié)議中，為我們實(shí)現(xiàn)即時(shí)服務(wù)帶來了兩大好處：

• Header: 互相溝通的Header是很小的-大概只有 2 Bytes

• Server Push: 服務(wù)器的推送，服務(wù)器不再被動(dòng)的接收到瀏覽器的請(qǐng)求之后才返回?cái)?shù)據(jù)，而是在有新數(shù)據(jù)時(shí)就主動(dòng)推送給瀏覽器。

udp(傳輸層)

UDP 是User Datagram Protocol的簡(jiǎn)稱， 中文名是用戶數(shù)據(jù)報(bào)協(xié)議，是OSI（Open System Interconnection，開放式系統(tǒng)互聯(lián)） 參考模型中一種無連接的傳輸層協(xié)議，提供面向事務(wù)的簡(jiǎn)單不可靠信息傳送服務(wù)，IETF RFC 768是UDP的正式規(guī)范。UDP在IP報(bào)文的協(xié)議號(hào)是17。

UDP協(xié)議全稱是用戶數(shù)據(jù)報(bào)協(xié)議，在網(wǎng)絡(luò)中它與TCP協(xié)議一樣用于處理數(shù)據(jù)包，是一種無連接的協(xié)議。在OSI模型中，在第四層——傳輸層，處于IP協(xié)議的上一層。UDP有不提供數(shù)據(jù)包分組、組裝和不能對(duì)數(shù)據(jù)包進(jìn)行排序的缺點(diǎn)，也就是說，當(dāng)報(bào)文發(fā)送之后，是無法得知其是否安全完整到達(dá)的。UDP用來支持那些需要在計(jì)算機(jī)之間傳輸數(shù)據(jù)的網(wǎng)絡(luò)應(yīng)用。包括網(wǎng)絡(luò)視頻會(huì)議系統(tǒng)在內(nèi)的眾多的客戶/服務(wù)器模式的網(wǎng)絡(luò)應(yīng)用都需要使用UDP協(xié)議。UDP協(xié)議從問世至今已經(jīng)被使用了很多年，雖然其最初的光彩已經(jīng)被一些類似協(xié)議所掩蓋，但是即使是在今天UDP仍然不失為一項(xiàng)非常實(shí)用和可行的網(wǎng)絡(luò)傳輸層協(xié)議。

與所熟知的TCP（傳輸控制協(xié)議）協(xié)議一樣，UDP協(xié)議直接位于IP（網(wǎng)際協(xié)議）協(xié)議的頂層。根據(jù)OSI（開放系統(tǒng)互連）參考模型，UDP和TCP都屬于傳輸層協(xié)議。UDP協(xié)議的主要作用是將網(wǎng)絡(luò)數(shù)據(jù)流量壓縮成數(shù)據(jù)包的形式。一個(gè)典型的數(shù)據(jù)包就是一個(gè)二進(jìn)制數(shù)據(jù)的傳輸單位。每一個(gè)數(shù)據(jù)包的前8個(gè)字節(jié)用來包含報(bào)頭信息，剩余字節(jié)則用來包含具體的傳輸數(shù)據(jù)。

udp與tcp

udp和tcp都屬于傳輸層的協(xié)議,都位于ip協(xié)議的頂層,他們不同之處有:

• udp是無連接協(xié)議,不需要進(jìn)行tcp的握手

• udp每次發(fā)送最大長(zhǎng)度是65535,而tcp在握手后可以源源不斷的發(fā)送

• udp協(xié)議使用報(bào)頭中的校驗(yàn)值來保證數(shù)據(jù)的安全。校驗(yàn)值首先在數(shù)據(jù)發(fā)送方通過特殊的算法計(jì)算得出，在傳遞到接收方之后，還需要再重新計(jì)算。如果某個(gè)數(shù)據(jù)報(bào)在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發(fā)送和接收方的校驗(yàn)計(jì)算值將不會(huì)相符，由此UDP協(xié)議可以檢測(cè)是否出錯(cuò)。這與TCP協(xié)議是不同的，后者要求必須具有校驗(yàn)值。

• udp報(bào)文沒有可靠性保證、順序保證和流量控制字段等，可靠性較差。但是正因?yàn)閡dp協(xié)議的控制選項(xiàng)較少，在數(shù)據(jù)傳輸過程中延遲小、數(shù)據(jù)傳輸效率高，適合對(duì)可靠性要求不高的應(yīng)用程序，或者可以保障可靠性的應(yīng)用程序，如DNS、TFTP、SNMP等。

• 在網(wǎng)絡(luò)質(zhì)量令人十分不滿意的環(huán)境下，UDP協(xié)議數(shù)據(jù)包丟失會(huì)比較嚴(yán)重。而tcp會(huì)進(jìn)行確認(rèn)驗(yàn)證,確保對(duì)方接收成功

• udp可實(shí)現(xiàn)對(duì)網(wǎng)關(guān)內(nèi)的所有主機(jī)進(jìn)行廣播

php多進(jìn)程

多進(jìn)程的概念

前面有講到,多進(jìn)程主要是在開發(fā)業(yè)務(wù)邏輯層面,并行處理多個(gè)任務(wù)的開發(fā)方式,什么叫做開發(fā)業(yè)務(wù)邏輯層面呢?

在上面我們有講到,php-fpm是fast-cgi的進(jìn)程管理器,啟動(dòng)之后會(huì)啟動(dòng)多個(gè)fast-cgi進(jìn)程,等待任務(wù)處理

在php-fpm軟件層面,fast-cgi的多個(gè)進(jìn)程就屬于多進(jìn)程處理,但是,當(dāng)用戶發(fā)起請(qǐng)求,

由nginx交給php-fpm處理請(qǐng)求時(shí),在這個(gè)層面,每個(gè)請(qǐng)求其實(shí)只占有一個(gè)php fast-cgi進(jìn)程進(jìn)行處理邏輯,對(duì)于運(yùn)行業(yè)務(wù)邏輯的這個(gè)php進(jìn)程,其實(shí)是單進(jìn)程的.

同理,當(dāng)我們直接運(yùn)行一個(gè)php文件時(shí),默認(rèn)是只開啟了一個(gè)php進(jìn)程進(jìn)行運(yùn)行php的代碼

多進(jìn)程的開發(fā)場(chǎng)景

在傳統(tǒng)web模式下,php一向是單進(jìn)程處理業(yè)務(wù)邏輯,只有在php-cli模式下,用于處理異步任務(wù),作為網(wǎng)絡(luò)服務(wù)器時(shí),才可能用到多進(jìn)程處理,所以,大部分phper都對(duì)php多進(jìn)程的概念不熟悉

使用pcntl擴(kuò)展

進(jìn)程通信

• 管道通信,分為有名管道,無名管道等,可自行搜索了解詳細(xì)

• 消息隊(duì)列通信,使用linux消息隊(duì)列,通過sysvmsg擴(kuò)展,可查看:   http://www.php20.cn/article/137

• 進(jìn)程信號(hào)通信,可查看:   http://www.php20.cn/article/134

• 共享內(nèi)存通信,映射一段能被其他進(jìn)程所訪問的內(nèi)存，這段共享內(nèi)存由一個(gè)進(jìn)程創(chuàng)建，但多個(gè)進(jìn)程都可以訪問。

• 共享內(nèi)存是最快的 IPC 方式，它是針對(duì)其他進(jìn)程間通信方式運(yùn)行效率低而專門設(shè)計(jì)的。

• 它往往與其他通信機(jī)制，如信號(hào)兩，配合使用，來實(shí)現(xiàn)進(jìn)程間的同步和通信。

• 套接字通信

• 第三方通信,使用文件操作,MySQL,redis等方法也可實(shí)現(xiàn)通信

協(xié)程

協(xié)程不是進(jìn)程或線程，其執(zhí)行過程更類似于子例程，或者說不帶返回值的函數(shù)調(diào)用。

一個(gè)程序可以包含多個(gè)協(xié)程，可以對(duì)比與一個(gè)進(jìn)程包含多個(gè)線程，因而下面我們來比較協(xié)程和線程。

我們知道多個(gè)線程相對(duì)獨(dú)立，有自己的上下文，切換受系統(tǒng)控制；而協(xié)程也相對(duì)獨(dú)立，

有自己的上下文，但是其切換由自己控制，由當(dāng)前協(xié)程切換到其他協(xié)程由當(dāng)前協(xié)程來控制。

協(xié)程與進(jìn)程

由上面的協(xié)程執(zhí)行順序中的代碼2,我們很容易發(fā)現(xiàn),協(xié)程其實(shí)只是運(yùn)行在一個(gè)進(jìn)程中的函數(shù),只是這個(gè)函數(shù)會(huì)被切換到下一個(gè)執(zhí)行,可以這么說:

協(xié)程只是一串運(yùn)行在進(jìn)程中的任務(wù)代碼,只是這些任務(wù)代碼可以交叉運(yùn)行 注意,協(xié)程并不是多任務(wù)并行,屬于多任務(wù)串行,每個(gè)進(jìn)程在一個(gè)時(shí)間只執(zhí)行了一個(gè)任務(wù)

協(xié)程的作用域

由于協(xié)程就是進(jìn)程中一串任務(wù)代碼,所以它的全局變量,靜態(tài)變量等變量都是共享的,包括了php的全局緩沖區(qū).

所以,在開發(fā)之中,需要特別注意協(xié)程中的全局變量,靜態(tài)變量,只要某一個(gè)協(xié)程內(nèi)修改了,那將會(huì)影響全部的協(xié)程,在使用ob緩沖區(qū)函數(shù)攔截的時(shí)候,也得考慮是否會(huì)被其他協(xié)程的輸出給污染.

用 協(xié)程執(zhí)行順序中的代碼2解釋,當(dāng)task1給$_GET['name']賦值為1時(shí),task2讀取$_GET['name']也會(huì)是1,task2將$_GET['name']賦值為2時(shí),task3讀取$_GET['name']也會(huì)是2

協(xié)程中的I/O連接

在協(xié)程中,要特別注意不能共用一個(gè)I/O連接,否則會(huì)造成數(shù)據(jù)異常. 用協(xié)程執(zhí)行順序中的代碼2解釋,當(dāng)task1,task2函數(shù)共用mysql連接,并都進(jìn)行查詢時(shí),由于協(xié)程是交叉運(yùn)行的,可能會(huì)造成task1獲取到task1+task2查詢出來的數(shù)據(jù),也可能會(huì)丟失部分?jǐn)?shù)據(jù),被task2獲取.

由于協(xié)程的交叉運(yùn)行機(jī)制,各個(gè)協(xié)程的I/O連接都必須是獨(dú)立的,所以我們需要在每個(gè)協(xié)程都創(chuàng)建一個(gè)連接,但由于mysql,redis的連接數(shù)有限,以及連接的開啟關(guān)閉需要消耗大量資源,所以我們可以使用連接池方案實(shí)現(xiàn)共用連接(只要保證每個(gè)連接每次只有一個(gè)協(xié)程在使用即可)

到此，相信大家對(duì)“swoole知識(shí)點(diǎn)有哪些”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

分享題目：swoole知識(shí)點(diǎn)有哪些
分享地址：http://m.rwnh.cn/article24/jejpje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、網(wǎng)站設(shè)計(jì)、服務(wù)器托管、網(wǎng)站維護(hù)、軟件開發(fā)、云服務(wù)器

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)