스울 지식 포인트를 상세하게 정리(요약 공유)

이 기사는 Swoole 마스터 프로세스에 하위 프로세스에 배포하도록 요청하는 fastcgi를 포함하여 swoole에 대한 관련 지식을 제공하지만 사용 후 종료되는 php-fpm 하위 프로세스 및 기타 관련 문제와는 같지 않습니다. 모두가 도움이 됩니다.

추천 학습: swoole 동영상 튜토리얼

swoole채팅방 프로세스 설명

전체 채팅방 프로세스는 다음과 같습니다.

- 승인을 얻기 위한 사용자 http 인터페이스 로그인

- 승인 요청 http 인터페이스를 통해 친구 목록, 다른 친구의 읽지 않은 마지막 메시지 및 읽지 않은 메시지 수(홈페이지 표시용) 가져오기

- 인증 요청을 통해 그룹 목록 가져오기(그룹 메시지는 저장 공간 절약을 위해 읽거나 읽지 않음)

- ws 링크 설정

- 등록 연결 끊김 및 재연결 메커니즘의 경우 닫기 이벤트가 트리거되면 ws

에 다시 연결합니다. - 핑 타이머를 설정하고 30초마다 핑을 수행합니다

- 읽지 않은 모든 메시지를 다음을 통해 가져옵니다. ws 인터페이스, 클라이언트가 이를 처리하여 알림 표시줄 등에 푸시합니다.

- 새 메시지 푸시를 수신하고 메시지 목록에 표시합니다.

- 클릭할 때 그룹/친구 메시지 인터페이스에 자동으로 최신 n개의 메시지를 가져오고 사용자가

실행 모드 작동

cgi 프로토콜 모드

cgi 모드 공통 게이트웨이 인터페이스(Common Gateway Interface)는 웹 서버가 특정 프로토콜을 통해 애플리케이션과 통신할 수 있게 해줍니다. 호출 원리는 대략 다음과 같습니다.

사용자 요청->웹 서버가 요청->포크 하위 프로세스 수신

프로그램 호출/프로그램 실행 -> 프로그램이 콘텐츠를 반환함/프로그램 호출 종료 -> 웹 서버가 콘텐츠를 수신함 -> 사용자에게 반환

사용자 요청마다 프로세스를 생성하기 위해 포크를 해야 하기 때문에 프로그램을 한 번 호출한 다음 프로세스를 파괴하므로 성능이 낮습니다

fast-cgi 프로토콜 모드

fast-cgi는 CGI 모드의 업그레이드 버전입니다. 켜져 있는 한 항상 요청을 처리할 수 있습니다. 프로세스를 종료해야 합니다. 호출 원칙은 대략 다음과 같습니다.

웹 서버 빠른-cgi 프로세스 관리자 초기화->n 프로세스를 미리 포크

사용자 요청 -> 웹 서버가 요청을 수신 -> fast-cgi 프로세스 관리자에게 전달 -> fast-cgi 프로세스 관리 영역이 이를 수신하여 유휴 fast-cgi 프로세스 중 하나에 제공 처리->처리 완료됨, fast-cgi 프로세스가 유휴 상태가 되어 다음 요청을 기다림 -> 웹 서버가 콘텐츠 수신 -> 사용자에게 반환 모듈 모드

모듈 모드

apache+php 런타임은 기본적으로 아파치가 시작될 때 PHP를 아파치 모듈로 시작하는 모듈 모드를 사용하며, 사용자 요청이 수신되면 mod_php 모듈을 호출하여 직접 처리할 수 있습니다. Baidu

php-cli 모드

php-cli 모드는 명령줄 모드에 속하며, 이제 막 PHP를 배우기 시작한 많은 개발자들에게 가장 생소한 운영 모드입니다. wamp 및 wnmp

이 모드는 그렇지 않습니다. PHP 코드를 실행하려면 php xx.php를 직접 입력하려면 다른 프로그램을 사용해야 합니다.

명령줄 모드와 일반 웹 모드의 명백한 차이점 is:

• * 타임아웃 기간이 없습니다

• * 버퍼는 기본적으로 꺼져 있습니다

• * STDIN 및 ST 사용 DOUT 표준 입력/출력/ 오류

• * Echo var_dump, phpinfo 및 기타 출력은 콘솔에 직접 출력됩니다.

• * 사용할 수 있는 다양한 클래스/함수

• * 다른 PHP .ini 구성

php-fpm

PHP-FPM(FastCGI 프로세스 관리자)은 PHP FastCGI의 추가 기능 대부분을 대체하는 데 사용되며 로드가 많은 웹 사이트에 매우 유용합니다.

기능은 다음과 같습니다:

• 원활한 중지/시작을 지원하는 고급 프로세스 관리 기능

• 다른 uid/gid/chroot 환경에서 작업하고, 다른 포트를 수신하고, 다른 php.ini 구성 파일을 사용할 수 있습니다(safe_mode 설정을 대체할 수 있음).

• stdout 및 stderr 로깅;

• 예기치 않은 상황이 발생할 때 손상된 opcode를 다시 시작하고 캐시할 수 있습니다.

• 파일 업로드 최적화 지원;

• "Slow Log" - 스크립트 실행으로 인한 비정상적인 속도 저하를 기록합니다. (파일 이름을 기록할 뿐만 아니라 PHP 역추적 정보도 기록합니다. ptrace 또는 유사한 도구를 사용하여 실행 중인 데이터를 읽고 분석할 수 있습니다. 원격 프로세스);

• fastcgi_finish_request() - 특수 기능: 요청이 완료되고 데이터가 새로 고쳐진 후에도 백그라운드에서 시간이 많이 걸리는 작업(비디오 입력 변환, 통계 처리 등)을 계속 수행하는 데 사용됩니다.

• 동적/정적 하위 프로세스 생성;

• 기본 SAPI 실행 상태 정보(Apache의 mod_status와 유사);

• php.ini 구성 파일을 기반으로 합니다.

작동 원리:

네트워크 프로토콜

네트워크 프로토콜은 통신 단계에 따라 7가지 레벨로 구분됩니다.

• 애플리케이션 계층

• 프레젠테이션 레이어

• 세션 레이어

• 전송 계층

• 네트워크 레이어

• 데이터 링크 계층

• 물리적 레이어

ip 프로토콜(네트워크 계층)

ip 프로토콜은 인터넷의 기본 프로토콜이며 현재 가장 널리 사용되는 네트워크 프로토콜입니다

Scope

IP의 책임은 소스에서 대상으로 데이터를 전송하는 것입니다. 전달 신뢰성, 흐름 제어, 패킷 순서 및 호스트 간 프로토콜에 공통적인 기타 서비스를 보장하는 책임은 없습니다. 이 프로토콜은 호스트 간 프로토콜에 의해 호출되며, 이 프로토콜은 데이터 패킷을 다음 게이트웨이 또는 대상 호스트로 전송하기 위해 로컬 네트워크 프로토콜을 호출하는 역할을 담당합니다. 예를 들어, TCP는 호출 시 대상 주소와 소스 주소를 매개변수로 전달하여 IP 프로토콜을 호출할 수 있습니다. IP는 데이터 패킷을 구성하고 로컬 네트워크(프로토콜) 인터페이스를 호출하여 데이터 패킷을 전송합니다.

Operation

IP은 주소 지정과 분할이라는 두 가지 기본 기능을 구현합니다. IP는 데이터 패킷 헤더에 포함된 대상 주소에 따라 데이터 패킷을 대상 주소로 전송할 수 있습니다. 이 과정에서 IP는 전송 경로 선택을 담당합니다. 일부 네트워크가 작은 데이터 패킷만 전송할 수 있는 경우 IP는 데이터 패킷을 재조립하고 이를 헤더 필드에 표시할 수 있습니다. 이러한 기본 기능은 네트워크의 모든 호스트와 게이트웨이에 존재하는 IP 모듈에 포함되어 있으며 이러한 모듈(특히 게이트웨이)에는 라우팅 및 기타 서비스 기능이 있습니다. IP의 경우 데이터 패킷 간의 연결이 없으며 IP의 연결이나 논리적 링크에 대해 말하기가 어렵습니다.

IP는 서비스 유형, 수명, 옵션 및 헤더 확인 코드의 네 가지 핵심 기술을 사용하여 서비스를 제공합니다. 서비스 유형은 기대되는 서비스 품질을 나타냅니다. 서비스 유형은 인터넷이 제공할 수 있는 서비스를 나타내는 매개변수 집합입니다. 이 서비스 유형은 게이트웨이가 특정 네트워크에서 실제 전달 매개변수를 선택하거나, 통과할 다음 네트워크 또는 패킷을 라우팅할 다음 게이트웨이를 선택하는 데 사용됩니다. TTL(Time-to-Live)은 패킷이 얼마나 오래 지속될 수 있는지에 대한 상한입니다. 발신자가 설정하고 경로에 따라 처리됩니다. 도착하지 않았을 때 TTL(Time-To-Live)이 0이면 패킷을 폐기합니다. 이 옵션은 제어 기능에 중요하지만 일반적인 통신에는 필요하지 않습니다. 옵션에는 타임스탬프, 보안 및 특수 라우팅이 포함됩니다. 헤더 확인 코드는 데이터의 올바른 전송을 보장합니다. 검사에 실패하면 전체 데이터 패킷이 삭제됩니다.

IP 주소

이제 IP 주소는 ipv4와 ipv6의 두 가지 유형으로 구분됩니다. 이제 가장 일반적인 것은 ipv4 주소입니다. 예를 들어 127.0.0.1(로컬 주소) 119.75.217.109(Baidu ip)

IP 전송에는 데이터를 보내기 전에 명확한 IP 주소가 있어야 합니다

tcp(전송 계층)

TCP(전송 제어 프로토콜)는 IETF의 RFC 793 정의에 지정된 연결 지향의 안정적인 바이트 스트림 기반 전송 계층 통신 프로토콜입니다. 단순화된 컴퓨터 네트워크 OSI 모델에서는 네 번째 계층 전송 계층에서 지정한 기능을 완성합니다. UDP(사용자 데이터그램 프로토콜)는 동일한 계층 내의 또 다른 중요한 전송 프로토콜입니다. 인터넷 프로토콜 제품군에서 TCP 계층은 IP 계층 위와 애플리케이션 계층 아래에 ​​위치한 중간 계층입니다. 서로 다른 호스트의 애플리케이션 계층 간에는 안정적인 파이프형 연결이 필요한 경우가 많지만 IP 계층은 이러한 흐름 메커니즘을 제공하지 않고 신뢰할 수 없는 패킷 전환을 제공합니다.

응용 계층은 네트워크 간 전송을 위해 8비트 바이트로 표현되는 데이터 스트림을 TCP 계층으로 보내고, TCP는 이 데이터 스트림을 적절한 길이의 메시지 세그먼트로 나눕니다(보통 컴퓨터에 의해 연결됨). ) 네트워크 데이터 링크 계층의 최대 전송 단위(MTU) 제한입니다. 그런 다음 TCP는 결과 패킷을 IP 계층으로 전달하고 IP 계층은 네트워크를 통해 패킷을 수신 엔터티의 TCP 계층으로 전달합니다. 패킷 손실이 발생하지 않도록 하기 위해 TCP는 각 패킷에 시퀀스 번호를 부여하는 동시에 수신 측으로 전송되는 패킷이 순서대로 수신되도록 보장합니다. 그런 다음 수신 엔터티는 성공적으로 수신된 패킷에 대한 해당 확인(ACK)을 다시 보냅니다. 송신 엔터티가 합리적인 왕복 지연(RTT) 내에 확인을 수신하지 않으면 해당 데이터 패킷이 손실된 데이터로 간주됩니다. 재전송됩니다. TCP는 체크섬 기능을 사용하여 데이터에 오류가 있는지 확인합니다. 체크섬은 송신 및 수신 시 모두 계산됩니다.

3방향 핸드셰이크

TCP는 3방향 핸드셰이크 프로토콜을 사용하여 연결을 설정하는 인터넷의 전송 계층 프로토콜입니다. 활성 당사자가 SYN 연결 요청을 보내면 상대방이 SYN+ACK로 응답할 때까지 기다린 후 마지막으로 상대방의 SYN에 대한 ACK 확인을 수행합니다. 이 연결 설정 방법은 잘못된 연결을 방지할 수 있습니다. TCP에서 사용하는 흐름 제어 프로토콜은 가변 크기 슬라이딩 윈도우 프로토콜입니다. TCP three-way handshake 과정은 다음과 같습니다.

• 클라이언트는 서버에 SYN(SEQ=x) 메시지를 보내고 SYN_SEND 상태에 들어갑니다.

• 서버는 SYN 메시지를 수신하고 SYN(SEQ=y) ACK(ACK=x+1) 메시지로 응답한 후 SYN_RECV 상태로 들어갑니다.

• 클라이언트는 서버로부터 SYN 메시지를 수신하고 ACK(ACK=y+1) 메시지로 응답한 후 설치됨 상태로 들어갑니다.

연결에 성공했습니다

연결에 성공한 후 양측은 언제든지 바이트 스트림을 서로에게 전송하고 연결을 닫을 수 있습니다. 특성

• 전송된 데이터는 TCP에 의해 전송에 가장 적합한 데이터 블록으로 나누어 IP 프로토콜로 전달됩니다. 이 전송된 데이터를 메시지 세그먼트 또는 세그먼트라고 합니다.

• tcp는 데이터 세그먼트가 전송될 때마다 타이머가 시작되며, 타이머가 제때에 확인을 받지 못하면 확인 메시지가 전송됩니다. 데이터가 재전송됩니다

• TCP는 헤더와 데이터의 체크섬을 유지합니다. 이는 전송 중 데이터의 변경 사항을 감지하도록 설계된 엔드투엔드 체크섬입니다. 수신된 세그먼트의 체크섬에 오류가 있는 경우 TCP는 해당 세그먼트를 삭제하고 세그먼트 수신을 확인하지 않습니다(발신자가 시간 초과되어 다시 전송되기를 바랍니다).

• 두 애플리케이션은 TCP 연결을 통해 8비트 바이트의 바이트 스트림을 교환합니다. TCP는 레코드 식별자를 바이트 스트림에 삽입하지 않습니다. 우리는 이것을 바이트스트림 서비스라고 부릅니다. 한쪽 애플리케이션이 먼저 10바이트, 그 다음 20바이트, 그 다음 50바이트를 전송하는 경우, 연결의 상대방은 보낸 사람이 매번 보낸 바이트 수를 이해할 수 없습니다. 자체 수신 버퍼가 가득 차지 않는 한 TCP 수신자는 수신할 수 있는 만큼만 수신합니다. 한쪽 끝은 바이트 스트림을 TCP 연결에 배치하고 동일한 바이트 스트림은 TCP 연결의 다른 쪽 끝에 나타납니다.

네 개의 파도

연결을 설정하려면 세 번의 핸드셰이크가 필요하고 연결을 종료하려면 네 번의 파도가 필요합니다. 이는 TCP의 반 닫기로 인해 발생합니다. 구체적인 과정은 다음과 같습니다.

• 신청 프로세스에서는 먼저 닫기를 호출하는데, 이를 "활성 닫기"를 수행한다고 합니다. 그런 다음 해당 쪽의 TCP는 FIN 세그먼트를 보내 데이터가 전송되었음을 나타냅니다.

• 이 FIN을 받은 Peer는 "Passive Close"(Passive Close)를 수행하고, 이 FIN을 TCP로 확인합니다.

• 참고: FIN 수신은 파일 끝으로 수신 애플리케이션 프로세스에 전달되며, 애플리케이션 프로세스에서 수신하기 위해 대기열에 있는 다른 데이터 뒤에 배치됩니다. 수신 응용 프로그램 프로세스에는 해당 연결에서 수신할 추가 데이터가 없습니다.

• 잠시 후 이 파일 끝 문자를 수신하는 애플리케이션 프로세스는 close를 호출하여 소켓을 닫습니다. 이로 인해 TCP도 FIN을 보냅니다.

• 이 최종 FIN을 수신한 원래 송신측 TCP(즉, Active Shutdown을 수행하는 End)가 이 FIN을 확인합니다. 각 방향에는 FIN과 ACK가 필요하므로 일반적으로 4개의 세그먼트가 필요합니다.

"일반적으로"는 경우에 따라 1단계의 FIN이 데이터와 함께 전송된다는 의미입니다. 또한 2단계와 3단계에서 전송되는 섹션은 수동 종료를 수행하는 끝 부분부터이며, A 섹션으로 병합되었습니다. 2단계와 3단계 사이에서 수동 종료를 수행하는 측에서 능동 종료를 수행하는 측으로 데이터가 흐를 수 있습니다. 이를 "반 폐쇄"라고 합니다. Unix 프로세스가 자발적으로(exit 호출 또는 주 함수에서 복귀) 또는 비자발적으로(프로세스를 종료하는 신호 수신) 종료되면 열려 있는 모든 설명자가 닫히고 TCP가 계속 열려 있는 결과도 발생합니다. FIN도 발급됩니다. 연결. 클라이언트나 서버 모두 활성 종료를 수행할 수 있습니다. 일반적으로 클라이언트는 활성 종료를 수행하지만 HTTP/1.0과 같은 일부 프로토콜에서는 서버가 활성 종료를 수행하도록 합니다.

php의 tcp

php는 소켓 기능, swoole 확장 및 스트림 기능을 사용하여 tcp 프로토콜의 소켓을 생성하고, 네트워크 카드 포트를 바인딩하고, tcp 서버를 수행할 수 있습니다. /client 작업 PHP에서는 tcp handshake/waving을 이해할 필요가 없으며 ip:port가 tcp 서버/클라이언트를 연결/생성할 수 있다는 것만 알면 됩니다.

php의 소켓을 사용하면 문자열을 직접 보내고 받을 수 있습니다.

문자열의 무결성만 처리하면 됩니다. 예를 들어 클라이언트 연결 후에는 PHP를 TCP 서버로 사용합니다. 성공했습니다. "easyswoole은 매우 좋은 swoole 프레임워크입니다"라는 문자열을 보냈습니다

• 서버는 매번 9바이트만 수신하므로 첫 번째 획득에서는 불완전한 "easyswool" 문자열만 수신하게 되며 계속해서 데이터를 획득해야 합니다

http 프로토콜

프로세스 분석

http요청 프로세스는 대략 다음과 같습니다.

사용자가 브라우저에 입력합니다

www.easyswoole.com

• DNS 서버 분석/또는 로컬 호스트, 라우터 호스트 비교를 통한 IP

• 브라우저가 기본 포트 80에 접속하면 접속되는 TCP 주소는 ip:80입니다

• tcp 프로토콜 3방향 핸드셰이크를 통해 연결

• http 요청 요청 헤더 보내기

• 서버는 액세스가 http 액세스임을 나타내는 http 요청 헤더를 획득하고, http 요청 헤더를 구문 분석하고, 요청 유형, 요청 형식 및 요청 데이터(쿠키, 가져오기, 게시 데이터)를 획득합니다

• 서버가 응답 데이터를 보내고 적극적으로 연결을 끊습니다

• 브라우저는 응답 데이터를 수신하고, 응답 텍스트 유형을 구문 분석하고, 데이터를 구문 분석한 후 연결을 끊습니다

  https 프로토콜에는 요청 및 응답에 TLS 및 SSL 암호화 및 암호 해독 프로토콜의 추가 계층이 있습니다. 기본 포트가 80에서 443으로 변경되었습니다.

http in phper

PHP는 주로 웹 서버에 사용되기 때문에 PHP 개발자에게 가장 많이 노출되는 프로토콜은 tcp/ip 프로토콜 기반의 http 프로토콜입니다

중 PHP 주니어 프로그래머는 실제로 http 프로토콜을 자세히 알지 못하지만 브라우저의 f12-> 네트워크를 사용하여 http 프로토콜의 특정 요청 헤더와 서버에서 보낸 응답 헤더를 볼 수 있습니다

WebSocket 프로토콜

배경 생성

WebSocket 프로토콜 이전에는 웹 페이지에서 채팅방은 ajax만 사용하여 서버에 데이터가 있는지 지속적으로 폴링하고 요청할 수 있었습니다. 생성되며 이러한 구현 방법은 일련의 문제를 일으킬 것입니다:

• 폴링 간격이 너무 짧으면 클라이언트와 서버가 일정 시간 내에 지속적으로 http tcp 핸드셰이크를 수행하게 됩니다. 웨이브 모션과 http 요청 헤더 및 응답 헤더의 전송은 많은 서버 리소스를 소비합니다. 사용자가 많으면 서버가 사용량이 많아지고 심지어 다운타임이 발생합니다

• 클라이언트는 매번 http 요청을 보내 서버에 반환할 데이터가 있는지 여부만 알 수 있으며 데이터의 적시성을 보장할 수 없습니다

이러한 상황 때문에 WebSocket이 등장했습니다. 긴 연결을 유지하려면 단 한 번의 http 핸드셰이크만 있으면 서버가 클라이언트에 적극적으로 메시지를 보낼 수 있어 라운드 수를 크게 줄일 수 있습니다. 쿼리 메커니즘

구현 원칙

웹소켓 연결을 구현하는 과정에서 브라우저를 통해 웹소켓 연결 요청을 하고, 서버가 응답을 보내는 과정입니다. 일반적으로 "악수"라고 합니다 .

WebSocket API에서는 브라우저와 서버가 핸드셰이크 작업만 수행하면 브라우저와 서버 사이에 빠른 채널이 형성됩니다.

두 사람은 서로 직접 데이터를 전송할 수 있습니다. 이 WebSocket 프로토콜에서는 실시간 서비스를 구현하는 데 두 가지 주요 이점을 제공합니다.

• 헤더: 서로 통신하는 헤더는 매우 작습니다. 약 2바이트

• 서버 푸시: 서버 푸시는 더 이상 데이터를 반환하기 전에 브라우저의 요청을 수동적으로 받지 않고 새 데이터가 있을 때 적극적으로 브라우저에 푸시합니다.

udp(transport layer)

UDP는 User Datagram Protocol의 약어로, 중국어 이름은 User Datagram Protocol, OSI(Open System Interconnection, Open System Interconnection)입니다. 참고 단순하고 신뢰할 수 없는 트랜잭션 지향 정보 전송 서비스를 제공하는 모델의 비연결 전송 계층 프로토콜은 UDP의 공식 사양입니다. IP 패킷의 UDP 프로토콜 번호는 17입니다.

UDP 프로토콜의 전체 이름은 User Datagram Protocol입니다. 네트워크에서는 TCP 프로토콜과 마찬가지로 데이터 패킷을 처리하는 데 사용됩니다. OSI 모델에서 네 번째 계층인 전송 계층은 IP 프로토콜의 상위 계층입니다. UDP는 데이터 패킷 그룹화, 조립 및 정렬이 불가능하다는 단점이 있습니다. 즉, 메시지가 전송된 후에는 메시지가 안전하고 완전하게 도착했는지 알 수 없습니다. UDP는 컴퓨터 간에 데이터를 전송해야 하는 네트워크 응용 프로그램을 지원하는 데 사용됩니다. 네트워크 화상 회의 시스템을 포함한 수많은 클라이언트/서버 네트워크 애플리케이션에는 UDP 프로토콜을 사용해야 합니다. UDP 프로토콜은 처음 등장한 이후 수년 동안 사용되어 왔습니다. 초기 영광은 일부 유사한 프로토콜에 의해 가려졌지만 UDP는 오늘날에도 여전히 매우 실용적이고 실현 가능한 네트워크 전송 계층 프로토콜입니다.

잘 알려진 TCP(전송 제어 프로토콜) 프로토콜과 마찬가지로 UDP 프로토콜은 IP(인터넷 프로토콜) 프로토콜 바로 위에 있습니다. OSI(Open Systems Interconnection) 참조 모델에 따르면 UDP와 TCP는 모두 전송 계층 프로토콜입니다. UDP 프로토콜의 주요 기능은 네트워크 데이터 트래픽을 데이터 패킷으로 압축하는 것입니다. 일반적인 데이터 패킷은 이진 데이터의 전송 단위입니다. 각 데이터 패킷의 처음 8바이트는 헤더 정보를 포함하는 데 사용되고 나머지 바이트는 특정 전송 데이터를 포함하는 데 사용됩니다.

udp 및 tcp

udp와 tcp는 모두 전송 계층 프로토콜이며 둘 다 IP 프로토콜의 최상위 계층에 있습니다.

• udp는 비연결 프로토콜이며 TCP 핸드셰이크가 필요하지 않습니다

• 매번 전송되는 udp의 최대 길이는 65535이고 tcp는 핸드쉐이크 이후에도 계속해서 전송할 수 있습니다

• UDP 프로토콜은 데이터 보안을 보장하기 위해 헤더의 확인 값을 사용합니다. 검사 값은 먼저 데이터 송신자에서 특수 알고리즘에 의해 계산되며, 수신자에게 전달된 후 다시 계산되어야 합니다. 데이터그램이 전송 중에 제3자에 의해 변조되거나 회선 잡음 또는 기타 이유로 손상된 경우 송신자와 수신자의 체크섬 계산이 일치하지 않으므로 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 프로세스를 위해 하나의 PHP fast-cgi 프로세스만 차지합니다. 는 실제로 단일 프로세스입니다.

마찬가지로 PHP 파일을 직접 실행하면 기본적으로 PHP 코드를 실행하기 위해 하나의 PHP 프로세스만 열립니다.

다중 프로세스 개발 시나리오

기존 웹 모드에서 PHP는 항상 비즈니스 로직 처리를 위한 단일 프로세스였습니다. 비동기 작업을 처리하고 네트워크 서버로 사용되는 php-cli 모드에서만 다중 프로세스가 가능합니다. 따라서 대부분의 PHPer는 PHP 다중 프로세스 개념에 익숙하지 않은 경우에 적합합니다

pcntl 확장 사용

프로세스 통신

• 파이프라인 통신은 Named Pipe와 Unnamed Pipe로 구분됩니다. 잠깐, 직접 하셔도 됩니다. 자세히 검색해보세요

• Linux 메시지 대기열을 사용하는 메시지 대기열 통신은 sysvmsg를 통해 확장되며 다음을 볼 수 있습니다. http://www.php20.cn/article/137

• 프로세스 신호 통신을 볼 수 있습니다: http://www.php20.cn/article/134

• 공유 메모리 통신은 다른 프로세스에서 액세스할 수 있는 메모리 섹션을 매핑합니다. 이 공유 메모리는 하나의 프로세스에서 생성되지만 여러 프로세스에서 액세스할 수 있습니다.

• 공유 메모리는 가장 빠른 IPC 방법입니다. 이는 다른 프로세스 간 통신 방법의 비효율성을 위해 특별히 설계되었습니다.

• 프로세스 간 동기화 및 통신을 달성하기 위해 신호와 같은 다른 통신 메커니즘과 함께 사용되는 경우가 많습니다.

• 소켓 통신

• 파일 작업, mysql, redis 및 기타 방법을 사용하여 제3자 통신도 가능합니다.

Coroutine

Coroutine은 프로세스나 스레드가 아니며 실행 프로세스는 서브루틴과 더 유사합니다. 또는 반환 값 없이 함수 호출을 말합니다.

프로그램에는 여러 개의 코루틴이 포함될 수 있는데, 이는 여러 스레드를 포함하는 프로세스와 비교할 수 있으므로 아래에서 코루틴과 스레드를 비교해 보겠습니다.

여러 스레드는 상대적으로 독립적이고 자체 컨텍스트를 가지며 전환은 시스템에 의해 제어됩니다. 코루틴도 상대적으로 독립적입니다.

스레드 전환은 자체적으로 제어되며 현재 코루틴에 의해 전환됨 다른 코루틴으로 이동하는 것은 현재 코루틴에 의해 제어됩니다.

코루틴과 프로세스

은 위의 코루틴 실행 순서에 따라 결정됩니다. 코드 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에서 쿼리한 데이터를 얻거나 데이터의 일부가 손실되어 얻어질 수 있습니다. 코루틴의 교차 실행 메커니즘으로 인해 task1+task2에서 쿼리한 데이터는 독립적이어야 하므로 각 코루틴에서 연결을 만들어야 합니다. 그러나 mysql 및 redis 연결 수가 제한되어 있고 연결을 열고 닫는 데 많은 리소스가 소비되므로 연결 풀 솔루션을 사용할 수 있습니다. 각 연결에 하나의 코루틴만 사용되는지 확인하세요. 한 번에)추천 학습: swoole 튜토리얼

위 내용은 스울 지식 포인트를 상세하게 정리(요약 공유)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!