点击下方链接参与测验：

交通规则测验

Porto (Software Architectural Pattern)

Welcome to Porto

• Introduction
• Getting Started
  • Layers Overview
  • 1) Ship Layer
  • 2) Containers Layer
    • Containers
    • Sections
• Components
  • 1) Main Components
    • 1.1) Components Interaction Diagram
    • 1.2) Request Life Cycle
    • 1.3) Main Components Definitions & Principles
      • Routes
      • Controllers
      • Requests
      • Actions
      • Tasks
      • Models
      • Views
      • Transformers
      • Exceptions
      • Sub-Actions
  • 2) Optional Components
• Typical Container Structure
• Porto Quality Attributes
• Implementations (Built with Porto)
• Feedback & Questions

Introduction

Porto is a modern software architectural pattern, consisting of guidelines, principles and patterns to help developers organize their code in a highly maintainable and reusable way.

Porto is a great option for medium to large sized web projects, as they tend to have higher complexity over time.

With Porto developers can build super scalable monolithics, which can be easily splitted into multiple micro-services whenever needed. While enabling the reusability of the business logic (Application Features), across multiple projects.

Porto inherits concepts from the DDD (Domain Driven Design), Modular, Micro Kernel, MVC (Model View Controller), Layered and ADR (Action Domain Responder) architectures.
And it adheres to a list of convenient design principles such as SOLID, OOP, LIFT, DRY, CoC, GRASP, Generalization, High Cohesion and Low Coupling.

It started as an experimental architecture, aiming at solving the common problems web developers face, when building large projects.

Feedbacks & Contributions are much appreciated.

“Simplicity is prerequisite for reliability.” — Edsger Dijkstra

Getting Started

Layers Overview

At its core Porto consists of 2 layers “folders” Containers & Ship.

• The Containers layer holds all your application business logic code.
• The Ship layer holds the infrastructure code (your shared code between all Containers).

These layers can be created anywhere inside any framework of choice.

(Example: in Laravel or Rails they can be created in the app/ directory or in a new src/ directory at the root.)

Visual Overview

Before diving deeper, let’s understand the different levels of code we will have in your code base:

Code Levels

• Low-level code: the framework code (implements basic operations like reading files from a disk, or interacting with a database). Usually lives in the Vendor directory.
• Mid-level code: the application general code (implements functionality that serves the High-level code. And it relies on the Low-level code to function). Should be in the Ship layer.
• High-level code: the business logic code (encapsulates complex logic and relies on the Mid-level code to function). Should be in the Containers layer.

Layers Diagram

The Containers layer (cargo containers) >> relies >> on the Ship layer (cargo ship) >> relies >> on the Framework (sea).

Monolithic to “Micro” Services

Porto is designed to scale with you! While most companies shift from Monolithic to Micro-Services (and most recently Serverless) as they scale up. Porto offers the flexibility to deflate your Monolithic into Micro-Services (or SOA) at any time with the least effort possible.

In Porto terms a Monolithic is equal to one cargo ship of Containers, while Micro Services is equal to multiple cargo ships of Containers. (Disregarding their sizes).

Porto offers the flexibility to start small with a single well organized Monolithic service and grow whenever you need, by extracting containers into multiple services as your team grows.

This is possible becuase Porto organizes your code into Containers, which are grouped into isolated Sections. A section can be later extracted out with all it’s related containers to be depolyed separatly as you scale.

As you can imagine operating two or more ships in the sea rather than a single one, will increase the cost of maintenance (two repositories, two CI pipelines,…) but also gives you flexibility, where each ship can run at different speed and direction. This technially translates to each service scaling differently based on the traffic it expect.

How Sections “Services” communicate together is completely up to the developers, even though Porto recomands using Events and/or Commands.

1) Ship Layer

The Ship layer, contains the Parent “Base” classes (classes extended by every single component) and some Utility Code.

The Parent classes “Base classes” of the Ship layer gives full control over the Container’s Components (for example adding a function to the Base Model class, makes it available in every Model in your Containers).

The Ship layer, also plays an important role in separating the Application code from the Framework code. Which facilitates upgrading the Framework without affecting the Application code.

In Porto the Ship layer is very slim, it does NOT contain common reusable functionalities such as Authentication or Authorization, since all these functionalities are provided by Containers, to be replaced whenever needed. Giving the developers more flexibility.

Ship Structure

The Ship layer, contains the following types of codes:

• The Core Code: is the engine of the ship, that auto-register and auto-load all your Container’s Components to boot your Application. It contains most of the magical code that handles everything that is not part of your business logic. And mostly contains code that facilitate the development by extending the framework features.
• The Containers shared code
  • Parents Classes: the base classes of each Component in your Container. (Adding functions to the parent classes makes them available in every Container). Parents are made to contain shared code between your Containers.
  • Generic Classes: the reusable features and classes which can be used by every Container. Such as, Global Exceptions, Application Middleware’s, Global Config files, etc.

Note: All the Container’s Components MUST extend or inherit from the Ship layer (in particular the Parent’s folder).

When separating the Core to an external package, the Ship Parents should extend from the Core Parents (can be named Abstract, since most of the them supposed to be Abstract Classes). The Ship Parents holds your custom Application shared business logic, while the Core Parents (Abstracts) holds your framework common code, basically anything that is not business logic should be hidden from the actual Application being developed.

2) Containers Layer

Porto manages the complexity of a problem by breaking it down to smaller manageable Containers.

The Containers layer is where the Application specific business logic lives (Application features/functionalities). You will spend 90% of your time at this layer.

Containers

A Container can be a feature, or can be a wrapper around a RESTful API resource, or anything else.

Example 1:

“In a TODO App, the ‘Task’, ‘User’ and ‘Calendar’ objects each would live in a different Container, were each has its own Routes, Controllers, Models, Exceptions, etc. And each Container is responsible for receiving requests and returning responses from whichever supported UI (Web, API..).”

It’s advised to use a Single Model per Container, however in some cases you may need more than a single Model and that’s totally fine. (Even if you have a single Model you could also have Values “AKA Value Objects” (Values are similar to Models but that do not get represented in the DB on their own tables but as data on the Models) these objects get built automatically after their data is fetched from the DB such as Price, Location, Time…)

Just keep in mind two Models means two Repositories, two Transformers, etc. Unless you want to use both Models always together, do split them into 2 Containers.

Note: if you have high dependecies between two containers by nature, than placing them in the same Section would make reusing them easier in other projects.

Example 2:

If you look at Apiato (the first project implementing Porto), you will notice that Authentication and Authorization are both features provided as Containers.

Basic Containers Structure

Container 1
	├── Actions
	├── Tasks
	├── Models
	└── UI
	    ├── WEB
	    │   ├── Routes
	    │   ├── Controllers
	    │   └── Views
	    ├── API
	    │   ├── Routes
	    │   ├── Controllers
	    │   └── Transformers
	    └── CLI
	        ├── Routes
	        └── Commands

Container 2
	├── Actions
	├── Tasks
	├── Models
	└── UI
	    ├── WEB
	    │   ├── Routes
	    │   ├── Controllers
	    │   └── Views
	    ├── API
	    │   ├── Routes
	    │   ├── Controllers
	    │   └── Transformers
	    └── CLI
	        ├── Routes
	        └── Commands

Containers Communication

• A Container MAY depends on one or many other Containers. (Wihin the same Section.)
• A Controller MAY call Tasks from another Container.
• A Model MAY have a relationship with a Model from another Containers.
• Other forms of communications are also possible, such as via Events and Commands.

If you use Event based communcations between containers, you could use the same mechanism after spliting your code base into multi services.

Note: If you’re not familiar with separating your code into Modules/Domains, or for some reason you don’t prefer that approach. You can create your entire Application in a single Container. (Not recommended but absolutely possible).

Sections

Section are another very important aspect in the Porto architecture.

A Section is a group of related containers. It can be a service (micro or bigger), or a sub-system within the main system, or antyhing else.

Think of a Section as a rows of containers on a cargo ship. Well organized containers in rows, speeds up the loading and unloading of related containers for a specific customer.

The basic definition of a Section is a folder that contains related Containers. However the benifits are huge. (A section is equivalent to a bounded context from the Domain-driven design) Each section represents a portion of your system and is completely isolated from other sections.

A Section can be deployed separatly.

Example 1:

If you’re building a racing game like Need for Speed, you may have the following two sections: the Race Section and the Lobby Section, where each section contains a Car Container and a Car Model inside it, but with different properties and functions. In this example the Car Model of the Race section can contain the business logic for accelerating and controlling the car, while the Car Model of the Lobby Section contains the business logic for customizing the car (color, accessories..) before the race.

Sections allows separating large Model into smaller ones. And they can provide boundaries for different Models in your system.

If you prefer simplicity or you have only single team working on the project, you can have no Sections at all (where all Containers live in the containers folder) which means your project is a single section. In this case if the project grew quickly and you decided you need to start using sections, you can make a new project also with a single section, this is known as Micro-Services. In Micro-Services each section “project portion” live in its own project (repository) and they can communicate over the network usually using the HTTP protocol.

Example 2:

In a typical e-commerce application you can have the following sections: Inventory Section, Shipping Section, Order Section, Payment Section, Catalog Section and more…

As you can imagine each of these Sections can be a micro-service by itself. And can be extracted and deployed on its own server based on the traffic it receives.

Sections Communication

• A Section MUST be isolated and SHOULD NOT depends on any other Section.
• A Section MAY listen to Events fired by other Sections. (Commands can be used as alternative to Events).

Components

In the Container layer there’s a set of Components “Classes” with predefined responsibilities.

Every single piece of code you write should live in a Component (class function). Porto defines a huge list of those Components for you, with a set guidelines to follow when using them, to keep the development process smooth.

Components ensures consistency and make your code easier to maintain as you already know where each piece of code should be found.

Components Types

Every Container consists of a number of Components, in Porto the Components are split into two Types: Main Components and Optional Components.

1) Main Components

You must use these Components as they are essential for almost all types of Web Apps:

Routes - Controllers - Requests - Actions - Tasks - Models - Views - Transformers.

Views: should be used in case the App serves HTML pages.
Transformers: should be used in case the App serves JSON or XML data.

1.1) Main Components Interaction Diagram

1.2) The Request Life Cycle

A basic API call scenario, navigating through the main components:

1. User calls an Endpoint in a Route file.
2. Endpoint calls a Middleware to handle the Authentication.
3. Endpoint calls its Controller function.
4. Request injected in the Controller automatically applies the request validation & authorization rules.
5. Controller calls an Action and pass each Request data to it.
6. Action do the business logic, OR can call as many Tasks as needed to do the reusable subsets of the business logic.
7. Tasks do a reusable subsets of the business logic (A Task can do a single portion of the main Action).
8. Action prepares data to be returned to the Controller, some data can be collected from the Tasks.
9. Controller builds the response using a View (or Transformer) and send it back to the User.

1.3) Main Components Definitions & Principles

Click on the arrows below to read about each component.

2) Optional Components

You can add these Components when you need them, based on your App needs, however some of them are highly recommended:

Tests - Events - Listeners - Commands - Migrations - Seeders - Factories - Middlewares - Repositories - Criteria - Policies - Service Providers - Contracts - Traits - Jobs - Values - Transporters - Mails - Notifications…

Typical Container Structure

A Container with a list of Main and Optional Components.

Container
	├── Actions
	├── Tasks
	├── Models
	├── Values
	├── Events
	├── Listeners
	├── Policies
	├── Exceptions
	├── Contracts
	├── Traits
	├── Jobs
	├── Notifications
	├── Providers
	├── Configs
	├── Mails
	│   ├── Templates	
	├── Data
	│   ├── Migrations
	│   ├── Seeders
	│   ├── Factories
	│   ├── Criteria
	│   ├── Repositories
	│   ├── Validators
	│   ├── Transporters
	│   └── Rules
	├── Tests
	│   ├── Unit
	│   └── Traits
	└── UI
	    ├── API
	    │   ├── Routes
	    │   ├── Controllers
	    │   ├── Requests
	    │   ├── Transformers
	    │   └── Tests
	    │       └── Functional
	    ├── WEB
	    │   ├── Routes
	    │   ├── Controllers
	    │   ├── Requests
	    │   ├── Views
	    │   └── Tests
	    │       └── Acceptance
	    └── CLI
	        ├── Routes
	        ├── Commands
	        └── Tests
	            └── Functional

Porto Quality Attributes

The benefits of using Porto.

Implementations

Feel free to list your implementation here.

List of projects implementing the Porto architecture.

• PHP
  • Laravel
    • Apiato (By the Porto creator) A PHP Framework for building scalable API’s on top of Laravel.
    • Laravel Large Project An example project to show how to build large projects with Porto.
  • Zend Expressive
    • Expressive Porto An implementation of the Porto architecture with Zend Expressive.
• JavaScript
• Python
  • Django
    • PyPorto A design for building scalable and testable applications with Django Rest Framework.
• Ruby
• Java
• C#
• …

Get in Touch

Your feedback is important.

For feedbacks, questions, or suggestions? We are on Slack.

Author

Mahmoud Zalt Twitter: @mahmoudz Site: zalt.me

Donations

Become a Github Sponsor.
Direct donation via Paypal.
Become a Patreon.

License

MIT © Mahmoud Zalt

如题 apidoc 的 @apiGroup 值如果是中文的时候没办法进行分组。官方仓库提了好多这样的 issue，貌似韩文也不支持。

有人提了 pr，但是被拒绝了，不知道为什么。

可以临时根据这个 pr 修改文件来支持中文分组，node_modules/apidoc/lib/core/workers/api_group.js 文件中的：

group = group.replace(/^[^a-z]+|[^\w:.-]+/gi, '');

替换为：

group = encodeURI(group).replace(/^[^a-z]+|[^\w:.-]+/gi, '');

这样如果线上部署生成的话就不太方便了，可以在生成文档的脚本文件中添加一行替换的代码，在生成文档前强行替换：

sed -i 's/group = group.replace/group = encodeURI\(group\).replace/' node_modules/apidoc/lib/core/workers/api_group.js

进程组，就是一个或是多个进程的集合，每一个进程都有个标识「组ID（PGID）」，表示该进程属于哪个进程组。

bash 进程启动之后，它会自己 setsid 把自己设置为会话首进程，也会设置自己为组长进程。

进程：正在执行的程序，这个程序是在 bin/bash 进程里启动的。

进程启动之后（通过 execve 函数启动），它会继承一些属性比如说组ID,会话ID，同时也会继承父进程已经打开的文件描述符（伪终端里的）：0/标准输入,1/标准输出,2/标准错误，通过 pts、ptmx 模拟出来的。

demo17.php

$pid = posix_getpid();
fprintf(STDOUT, "pid=%d,ppid=%d,pgid=%d,sid=%d\n",$pid,posix_getppid(),posix_getpgid($pid),posix_getsid($pid));

查看当前 bash 进程 PID

$ echo $$
1031235

另外一个 SSH 连接，追踪上一个 bash 进程

$ strace -f -s 65500 -o demo17.log -p 1031235

在 bash 进程 1031235 中，执行代码

$ php demo17.php 
pid=1032568,ppid=1031235,pgid=1032568,sid=1031235

demo17.log

# bash 进程 clone 一个子进程 1032568
1031235 clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2c4847ba10) = 1032568
1032568 getpid()                        = 1032568
...
# 子进程将自己设置为组长进程
1031235 setpgid(1032568, 1032568) = 0
...
# 子进程执行 `demo17.php`
1032568 execve("/usr/bin/php", ["php", "-c", "/www/server/php/80/etc/php-cli.ini", "demo17.php"], 0x5558eda12830 /* 32 vars */) = 0

孤儿进程：指父进程先结束，但是子进程晚结束，这个时候子进程就是孤儿进程，它会被1号进程接管。

子进程继承父进程的组id（gpid）、会话id（sid）

demo18.php

    <?php

    function showPid()
    {
        $pid = posix_getpid();
        fprintf(STDOUT, "pid=%d,ppid=%d,pgid=%d,sid=%d\n",$pid,posix_getppid(),posix_getpgid($pid),posix_getsid($pid));
    }
    showPid(); // ppid 和下边两个子进程是不一样的

    $pid = pcntl_fork(); // 该子进程的 ppid、pgid、sid是一样的

    $pidMap = [];
    if ($pid > 0) {
        $pidMap[$pid] = $pid;
        $pid = pcntl_fork(); // 该子进程的 ppid、pgid、sid是一样的
        if ($pid > 0) {
            $pidMap[$pid] = $pid;
        }
    }
    showPid();

    if ($pid > 0) {
        $i = 0;
        while (1) {
            $pid = pcntl_waitpid(-1, $status);

            if ($pid > 0) {
                echo "子进程 $pid 结束了\n";
                $i++;
            }

            unset($pidMap[$pid]);

            if (empty($pidMap)) {
                break;
            }
        }
    }

运行结果：

$ php demo18.php
pid=678,ppid=28,pgid=678,sid=28
pid=679,ppid=678,pgid=678,sid=28
pid=678,ppid=28,pgid=678,sid=28
pid=680,ppid=678,pgid=678,sid=28
子进程 679 结束了
子进程 680 结束了

设置子进程组id

    <?php

    function showPid()
    {
        $pid = posix_getpid();
        fprintf(STDOUT, "pid=%d,ppid=%d,pgid=%d,sid=%d\n",$pid,posix_getppid(),posix_getpgid($pid),posix_getsid($pid));
    }

    showPid(); // ppid 和下边两个子进程是不一样的

    $pid = pcntl_fork(); // 该子进程的 ppid、pgid、sid是一样的

    $pidMap = [];
    if ($pid > 0) {
        $pidMap[$pid] = $pid;
        $pid = pcntl_fork(); // 该子进程的 ppid、pgid、sid是一样的
        if ($pid > 0) {
            $pidMap[$pid] = $pid;
        } else {
            // 设置子进程组id
            $pid = posix_getpid();
            posix_setpgid($pid, $pid);

            // fork 一个子进程、观察组id变化
            $pid = pcntl_fork();
            if ($pid > 0) {
                $pidMap[$pid] = $pid;
            }
        }
    }
    showPid();

    if ($pid > 0) {
        $i = 0;
        while (1) {
            $pid = pcntl_waitpid(-1, $status);

            if ($pid > 0) {
                echo "子进程 $pid 结束了\n";
                $i++;
            }

            unset($pidMap[$pid]);

            if (empty($pidMap)) {
                break;
            }

        }
    }

$ php demo18.php 
pid=463,ppid=28,pgid=463,sid=28
pid=464,ppid=463,pgid=463,sid=28
pid=463,ppid=28,pgid=463,sid=28
pid=465,ppid=463,pgid=465,sid=28
pid=466,ppid=465,pgid=465,sid=28
子进程 466 结束了
子进程 464 结束了

为了防止走丢，做了全文转载。

原文出自：彻底理解Linux的各种终端类型以及概念

作者：dog250

每天使用Linux每天都要接触到Bash，使用Bash时似乎永远都让人摸不着头脑的概念就是终端，坐在这台运行着Linux的机器的显示器前面，这个显示器就是终端的输出，而插在机器上的USB键盘或者PS/2键盘就是终端的输入，看来这是一种最直白意义上关于终端的解释。

  但是有的时候，机器上并没有看到显示器或者键盘接口，但是却有一个串口，想操作这台机器想必只能通过这个串口来进行了，这个时候，串口另一端的那台电脑的显示器键盘也叫做终端。除了上述两种意义的终端之外，我们使用的类似SecureCRT这种软件上运行的SSH，Telnet等也算是一种终端程序，只是说它是通过TCP/IP网络而不是通过串口与主机连接的。

  现在可以给终端下一个非严格意义上的定义了，什么是终端？终端就是处理计算机主机输入输出的一套设备，它用来显示主机运算的输出，并且接受主机要求的输入，典型的终端包括显示器键盘套件，打印机打字机套件等。但想要彻底理解终端的概念，还是要从计算机发展历史的角度去寻根溯源。

  最开始的时候，计算机有三间房屋那么大，确切地讲应该叫三间车间。如此的庞然大物有一个专门的操作台，就好像机床厂车间的操作台一样，或者说它像飞机驾驶舱的操作台更加合适，各种仪器仪表，操作员只需要在这里对这部机器发出指令，整部机器就开始为他的指令而运算，然后机器运算后的结果也会反馈到这里而不是其它地方，这里这个操作台就是最原始的终端。这里曾经是整部机器的控制中枢。

后来有了多用户多任务分时系统，不同的程序竟然可以“同时运行”了，为了让不同的程序分别独立地接受输入和处理输出，就需要多个不同的上述的操作台，当然了，坐在或者站在操作台前面的最好始终是同一个人，这样不同的人拥有不同的操作台处理不同的程序，这就进入了多终端时代，从这时起一直到现在，每一个终端都是和一个用户绑定的。为了保证这种绑定，于是就出现了登录，即通过一种叫做登录的动作，去唤起一个终端起来工作。为了支持多用户，终端从硬件分离了出来，终端成了一个软件概念，在一个硬件终端上成功登录后，便获得了一个软件终端。

  可见，这个时代已经和三车间的时代不同了，终端不再只有一个，而是变成了多个，每一个登录成功的用户拥有一个可工作的软件终端来处理输入输出。

分久必合。

  到了个人计算机时代，计算机和终端又成了一对一的关系。毕竟嘛，这时的计算机叫做个人计算机，并不是随便谁都能用的，计算机本身就是归属个人，所以根本没必要去支持什么多用户，或者至少是淡化了多用户和多终端的概念。我们都曾记得，当时买电脑的时候，都是一个主机配一个显示器和一套键盘鼠标，这种情况从上世纪80年代初一直持续到今天。不过近些年来当人们逐渐全面认识到计算机和终端的一对一关系后，一体机的市场就来了，既然你几乎不会(我当然知道有人会，但这里我说的是大多数人，程序员占比寥寥，程序员为了装X，是不会用一体机的，就连品牌机套装有时也不屑的)在同一主机上接多个显示器多套键盘，何必再那么麻烦，干脆把主机和显示器合在一起不就好了嘛。嗯，这个点子不错，循着这个路子，最终有了触屏一体机，连键盘都内置了。对比一下下图和三车间里的计算机时代，是不是很像呢？

但是好景不长。

  合久必分。

  一切似乎又回到了大型机时代。在大型机时代，一台机器是拥有多个终端的，那是五十年以前。今天，我们拥有了各种各样的小型设备，智能手机，平板电脑，智能手表….然而这些东西，其实仅仅只是一系列的终端而已！那么既然这些东西都成了终端，真正的计算机在哪儿？当然在各大机房(也是类似车间大小的那种房间)里了，只是现在不叫大型机了，而叫做云端，这种技术叫做云计算(似乎有点炒作概念的意思)。如果你不信你花了几千上万块的钱买来的设备仅仅是一个完成输入输出功能的终端，那么请断网试试，看看你的iPhone是不是变砖头了。可见，昂贵的是云提供的计算服务，而不是终端设备本身，我们把所谓的云看作是一台计算机，这幅图景是不是跟五十年前的非常像呢？

你有多久没有打开过家里的PC了，是不是很久了，但是日子也还过得去。但是你能忍受哪怕几个小时不登录微信吗？某种意义上，成为新的终端的不是这些个硬件设备，而是基于云计算技术的现代互联网服务的各类APP。
…

  是不是又要分久必合了呢？早就有迹象了，从用QQ号可以登录微信，微博，内推网的时候就有迹象了。

好了，扯了这么多关于终端的发展，其实根本上也就一句话，能接受输入，能显示输出，就这就够了，不管到了什么时代，终端始终扮演着人机接口的角色，所谓Terminal，即机器的边缘！

  只要能提供给计算机输入和输出功能，它就是终端，而与其所在的位置无关。我可以用ls命令列举五千公里以外的一台计算机上某个目录下的文件并且显示在我眼前的屏幕上，至于我的输入如何到达五千公里以外，这并不是我要关注的，也不是计算机要关注的，这显然只是一个通信方式问题。那么使用TCP/IP网络进行这类通信传输就是再显然不过的了。

  这就是SSH使用的方法。我们知道，SSH是一个TCP/IP协议族的协议，而其上跑的却是一个远程登录后的终端流，这显然只是用TCP/IP构建了一条隧道，然后终端流通行于该隧道。除此之外，更简单的Telnet也不例外，也是通过一个TCP/IP隧道来封装承载远程登录的终端流。除却TCP/IP，如果我们执意使用卡车来运载我们的输入和输出，也完全是合适的，TCP/IP也好，卡车也好，它们只是通信手段，它们并非终端本身。

我们现在可以想象一下终端存在的形式都会有哪些。

• 本地终端
  用VGA连接主机和显示器，用PS/2或者USB连接主机和键盘，这样的一个显示器/键盘组合就是一个本地终端。
• 用串口连接的远程终端
  通过串口线把主机接到另外一个有显示器和键盘的主机，通过运行一个终端模拟程序，比如“Windows超级终端”来将这台主机的显示器和键盘借给串口对端的主机。
• 用TCP/IP承载的远程终端
  类似Telnet，SSH这般。

大致就先说这几类吧。可见上述的三类中，前两类都是在本地就直接关联了物理设备的，比如VGA口啊，PS/2口啊，串口啊之类的，这种终端叫做物理终端，而第三类在本地则没有关联任何物理设备，注意，不要把物理网卡当成终端关联的物理设备，它只是隧道关联的物理设备，这里的物理网卡完全可以换成卡车，它们与终端并不直接相关，所以这类不直接关联物理设备的终端叫做伪终端。

  既然知道了这些终端到底是怎么回事，理解余下来的那些术语就不在话下了。这些术语的存在并非是为了故意增加复杂性，而是因为工程上的东西必须要有可操作性，要可操作就必须至少有个名字来称呼，仅此而已。这跟我们中国的传统道，可道非常道；名，可名非常名是完全不同的。可谓现代数学，既要有名又要有道，而现代工程，则必须舍道而取名。

  先看下Linux系统中管终端都叫做什么。

tty是最令人熟悉的了，在Linux中，/dev/ttyX代表的都是上述的物理终端，其中，/dev/tty1~/dev/tty63代表的是本地终端，也就是接到本机的键盘显示器可以操作的终端。换句话说，你往/dev/tty3里写个东西，它就会显示在显示器对应的终端。

  为什么会有63个终端这么多呢？毕竟显示器只是一个单独的显示设备，键盘往往也只有一个，但Linux内核有能力知道现在该干什么，所以事实上Linux内核在初始化时会生成63个本地终端，通过键盘上的Fn-Alt-FX(X为1,2,3…)可以在这些终端之间切换，每切换到一个终端，该终端就是当前的焦点终端，比如说，你按下了Fn-Alt-F4组合键，那么此时第4个终端就是焦点终端，即/dev/tty4就是焦点终端设备。

谁是焦点终端会被内核记录为全局变量，这样只要有键盘输入，就会把输入的字符交给焦点终端。这里顺便提一下，对于串口而言，不存在焦点终端的概念，谁连了串口就是谁，而对于伪终端来讲，一般情况下client都是运行在GUI环境，对于Windows那是微软的事，对于Linux，则有X系统完成同样的事，在此略过，继续我们正在说的话题。

  系统中有没有什么变量可以表示焦点终端呢？当然有了，那就是/dev/console，不管你在哪里往/dev/console里写东西，这些东西总会出现在系统当前的焦点终端上！

  按照以他人为中心，我们解释了/dev/console其实就是一个全局变量，指代当前的焦点终端，如果当前的焦点是/dev/tty4，那么/dev/console指的就是/dev/tty4，当然这一切都是由内核来维护的。

  那么系统中有没有一个叫做自己的全局变量呢？当然有，那就是/dev/tty，也就是说，无论你在哪个终端下工作，当你往/dev/tty里写东西的时候，它总是会马上出现在你的眼前。

  /dev/tty1~/dev/tty63我们知道了它们是什么，/dev/tty表示自己，/dev/console表示焦点终端这些我们也知道了，那么串口终端如何表示呢？很简单，以ttyS
开头的就是串口连接的终端，比如ttyS1，ttyS2…

  最后，解释一下伪终端。其实也很好解释，只要你理解TUN/TAP虚拟网卡的原理就行，它们如出一辙！类似Telnet，SSH不是没有实际的物理设备吗？简单，给它模拟一个不就得了？系统是分层的，执行流只管调用接口，并不管具体实现。

  模拟一个虚拟的终端设备，实现它的write，read等回调即可。对于VGA连接的显示器而言，write其实就是将显存刷新，而对于伪终端而言，write其实是想将数据导入到一个用户态的程序中(不然又能去哪里呢？它下面又没有任何物理的东西)，这简直跟很多VPN的原理非常类似。为此，Linux设计出一对虚拟终端设备，即/dev/ptmx和/dev/pts/X，这就跟TUN/TAP网卡的网卡与字符设备之前的对应关系一致。

  简单来讲，当有ssh客户端连接后，sshd会fork一个进程，然后在子进程中打开一个叫做/dev/pts/1(或者2,3,4,5…)的设备，然后和sshd进程的/dev/ptmx配对，这样在ptmx与pts之间就构成了一条管道，数据可以顺利被导入到sshd，然后通过TCP/IP封装发往ssh client所在的机器。

  为了帮助理解上述的文字，我特意作图一张，希望能解释清楚这些终端之间的关系以及弄明白它们的工作流程。为了让图画的更加紧凑，避免横向网络吧图拉的过长而不好看，我这里采用了环形解释法，类似Intel早先的Ring1，Ring2，Ring3，我把最内层视作硬件(比它更里面的还有叫做人的东西)，中间层视作内核，最外层视作软件。

理解了图例，我上我的图，这是我昨晚画到很晚才完成的，希望能有宝贵的意见提出(图有点大，请单独查看)：

/dev目录下的各种tty，ptmx，pts/X，console等等这些是令人混淆的根源，其实理解这些是有窍门的，记住它们只是操作某种终端设备的设备文件而已，这是UNIX风格的延续，这些设备文件对应的真实设备也就那么几种，比如显示器键盘套件，串口对面的超级终端，伪终端对面的SSH，Telnet等等。然后试着画出一个上面的图，基本就理清楚了。

本文的最后，我来简单说下关于getty和login相关的东西。

  前面在讲终端发展历史的时候说到过，到了多终端时代，每一个终端必须绑定一个用户，只有登录成功的用户方可获得一个终端。因此当一个人站到一个终端面前并不意味着它就能在这个终端上操作计算机，他首先要做的就是登录。所谓的登录呢，就是输入用户名和密码，如果输入正确，则会给你一个Bash(或者别的Shell)让你操作计算机，如果输入不正确，则让你继续输入…

  getty给了让你登录并且继续输入的机会！init进程不断调用getty，然后getty会发起login让你登录，当你输入正确的用户名和密码后，ttyXYZ就是你的了，如果你是用SSH进行的login，那么你将得到一个叫做/dev/pts/X，如果你是在显示器键盘登录，你将得到/dev/tttX(X取决于当前的焦点终端)。

  所有这一切其实都是多终端以及多用户的产物，但归根结底其根源都在分时系统。在计算机最初被放在车间大小的屋子里的年代，可能把屋子的门禁做好以及将屋子外的鉴权系统做好显得比后来的多用户login更为重要，只有在后来，终端不再属于计算机了，终端与计算机分离了，用户也和终端分离了的时候，设计一套登录机制就显得尤为必要了，因为首先即便你把计算机锁在铁屋子里，只要终端在外面，那么计算机就毫无安全感可言，其次，你也不可能把终端全部锁在完全属于你控制的铁屋子里，特别是在TCP/IP出现以后，几乎所有的计算机都是互联互通的，这意味着任何一台计算机都可以作为其它任何一台另外的计算机的操作终端，任何外部的鉴权系统和物理保护在TCP/IP网络面前都堪比马其诺防线，看似固若金汤，实则百无一用。

信号集

信号集是指信号的集合。

主程序可以选择阻塞某些信号，被阻塞的信号集称为阻塞信号集。

当进程阻塞了某个信号（通过 pcntl_sigpromask 来设置信号屏蔽字），如果在运行期间接收到了阻塞的信号时，这个信号的处理程序不会被执行，这个信号会放在被挂起的信号集里（信号未决集）。

sigpending

PHP 没有实现这个函数。

examine pending signals.

sigpending() returns the set of signals that are pending for delivery to the calling thread (i.e., the signals which have been raised while blocked).

The mask of pending signals is returned in set.

pcntl_sigpromask

pcntl_sigpromask 设置或检索阻塞信号，用来增加，删除或设置阻塞信号，具体行为 依赖于参数how。

pcntl_sigprocmask(int $how, array $set, array &$oldset = ?): bool

参数：

how：

设置 pcntl_sigprocmask()函数的行为。 可选值:

• SIG_BLOCK: 把信号加入到当前阻塞信号中。
• SIG_UNBLOCK: 从当前阻塞信号中移出信号。
• SIG_SETMASK: 用给定的信号列表替换当前阻塞信号列表。

set：

信号列表。

oldset：

是一个输出参数，用来返回之前的阻塞信号列表数组。

返回值：

成功时返回 true， 或者在失败时返回 false。

示例：

<?php

pcntl_signal(SIGINT, function($signo){

    fprintf(STDOUT, "pid=%d 接收到了信号:%d\n", getmypid(), $signo);
});

// 设置进程的信号屏蔽字｜信号阻塞集
$sigset = [SIGINT, SIGUSR1];
pcntl_sigprocmask(SIG_BLOCK, $sigset);

$i = 10;
while ($i--){

    pcntl_signal_dispatch();
    fprintf(STDOUT, "pid=%d do something...\n", getmypid());

    sleep(1);

    if ($i == 5){

        fprintf(STDOUT, "时间到，准备解除阻塞...\n");
        //解除信号屏蔽
        //$oldset 会返回之前阻塞的信号集｜信号屏蔽字
        pcntl_sigprocmask(SIG_UNBLOCK, [SIGINT,SIGUSR1], $oldset);

        print_r($oldset);

    }
}

$ php demo13.php 
pid=2673 do something...
^C^Cpid=2673 do something...
# 按 ctrl + c  信号被屏蔽阻塞
^C^C^C^C^Cpid=2673 do something...
^C^C^Cpid=2673 do something...
pid=2673 do something...
时间到，准备解除阻塞...
Array
(
    [0] => 2
    [1] => 10
)
pid=2673 接收到了信号:2
pid=2673 do something...
^Cpid=2673 接收到了信号:2
# 解除阻塞后，按 ctrl + c 接收到信号并处理
pid=2673 do something...
^Cpid=2673 接收到了信号:2
pid=2673 do something...
^Cpid=2673 接收到了信号:2
pid=2673 do something...
^Cpid=2673 接收到了信号:2
pid=2673 do something...

中断信号

指软件中断信号，简称软中断。

中断信号处理程序（信号处理函数，信号捕捉函数）完以后，就会返回继续执行主程序。

中断是用以提高计算机工作效率、增强计算机功能的一项重要技术。最初引入硬件中断，只是出于性能上的考量。如果计算机系统没有中断，则处理器与外部设备通信时，它必须在向该设备发出指令后进行忙等待（Busy waiting），反复轮询该设备是否完成了动作并返回结果。这就造成了大量处理器周期被浪费。

引入中断以后，当处理器发出设备请求后就可以立即返回以处理其他任务，而当设备完成动作后，发送中断信号给处理器，后者就可以再回过头获取处理结果。这样，在设备进行处理的周期内，处理器可以执行其他一些有意义的工作，而只付出一些很小的切换所引发的时间代价。后来被用于CPU外部与内部紧急事件的处理、机器故障的处理、时间控制等多个方面，并产生通过软件方式进入中断处理（软中断）的概念。

——中断

中断尽管可以提高计算机处理性能，但过于密集的中断请求／响应反而会影响系统性能。这类情形被称作中断风暴（interrupt storm）。

中断处理过程示意图

中断源

就是产生中断信号的单元。

1. 在终端按下按键产生的中断信号 ctrl+c, ctrl+z, ctrl+\
2. 硬件异常
3. 在终端使用 kill 来发送中断信号
4. posix_kill / kill(2) 函数、pcntl_alarm / alarm(2)函数
5. 软件产生的中断信号 SIGURG [TCP/IP],SIGALRM

中断响应

对信号的处理。

1. 忽略
2. 执行中断处理函数（捕捉信号执行信号处理函数）
3. 执行系统默认 signal ===> 动作[忽略，默认，执行用户编写好的信号处理函数]

中断返回

中断服务程序运行完之后返回。

信号对进程的影响：

1. 直接让进程终止

2. 让进程停止

   SIGCONT 可以唤醒进程到前台继续运行

   demo11.php

   <?php
   
   echo posix_getpid();
   
   while (1){
       ;
   }
   

   发送 SIGSTOP 让进程停止之后

   [1]   Killed                  php demo11.php
   [2]   Killed                  php demo11.php
   
   [3]+  Stopped                 php demo11.php
   
   $jobs
   [1]+  Stopped                 php demo11.php
   

   [1]、[2]、[3] 为任务编号

   ctrl+z 它会让进程丢到后台去停止。

几个常用的中断信号

SUID、SGID 概念

The Unix access rights flags setuid and setgid (short for “set user ID” and “set group ID”) allow users to run an executable with the file system permissions of the executable’s owner or group respectively and to change behaviour in directories. They are often used to allow users on a computer system to run programs with temporarily（暂时、临时） elevated（提高） privileges in order to perform a specific task. While the assumed user id or group id privileges provided are not always elevated, at a minimum they are specific.

The flags setuid and setgid are needed for tasks that require different privileges than what the user is normally granted, such as the ability to alter system files or databases to change their login password. Some of the tasks that require additional privileges may not immediately be obvious, though, such as the ping command, which must send and listen for control packets on a network interface.

——setuid

效果：

The setuid and setgid flags have different effects, depending on whether they are applied to a file, to a directory or binary executable or non binary executable file. The setuid and setgid flags have an effect only on binary executable files and not on scripts (e.g., Bash, Perl, Python).

set user ID,set group ID 设置用户ID,设置组ID。

设置了 setuid 的程序就是一个特权程序了，启动之后就是一个特权进程。

当特殊标志 s 这个字符出现在文件拥有者的 x 权限位的时候就叫 setuid,简称SUID，或SUID特殊权限。

例如：

$ ls -al /usr/bin/passwd 
-rwsr-xr-x 1 root root 68208 7月  15  2021 /usr/bin/passwd

$ file /usr/bin/passwd 
/usr/bin/passwd: setuid ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=6af93256cb810d90b2f96fc052b05b43b954f5b2, for GNU/Linux 3.2.0, stripped

SUID,SGID用途

一般，以 root 启动的程序都是超级进程，是一些重要的服务程序。

有时候我们经常是以普通用户来执行程序的，例如 www 用户。

但有时候普通进程需要访问一些特殊的资源，这时就需要提升权限来访问。

例如：linux 下 shadow 文件（包含系统用户密码信息），普通用户是无法查看，修改，删除的。但是 root 可以。

laradock@3a6c2da5a07b:/var/www$ cat /etc/shadow
cat: /etc/shadow: Permission denied

laradock@3a6c2da5a07b:/var/www$ ls -al /etc/shadow
-rw-r----- 1 root shadow 557 Jan 21 16:07 /etc/shadow

普通用户 laradock 可以通过 /usr/bin/passwd 这个 ELF 可执行文件修改 /etc/shadow 文件，因为普通用户拥有 /usr/bin/passwd 的可执行权限，并且 /usr/bin/passwd 是 SUID 特权程序，拥有 /etc/shadow 的读写权限。

如何设置 SUID

在可执行文件的权限 x 位上设置 chmod u/g/o + s elf file

在编写特权进程时，提权访问资源之后一定要把权限改回来。

PHP 示例：

<?php

$file = "pwd.txt";
$uid = posix_getuid();
$euid = posix_geteuid();

fprintf(STDOUT, "uid=%d,euid=%d\n", $uid, $euid);

// 这样设置是不行的
// 为啥不行？
// Set the effective user ID of the current process. This is a privileged function and needs appropriate privileges (usually root) on the system to be able to perform this function.
posix_setuid($uid);
posix_seteuid($euid);

$uid = posix_getuid();
$euid = posix_geteuid();

fprintf(STDOUT, "uid=%d,euid=%d\n", $uid, $euid);

if (posix_access($file,POSIX_W_OK)){

    fprintf(STDOUT,"我能修改...\n");
    $fd = fopen($file,"a");
    fwrite($fd,"php is the best ?\n");
    fclose($fd);

}else{
    fprintf(STDOUT,"我不能修改此文件...\n");
}

posix_access/access 检查用户是否对指定文件拥有某个权限。

提权前：

$ php demo10.php
uid=1000,euid=1000
uid=1000,euid=1000
我不能修改此文件...

$ cat pwd.txt

chmod u+s /usr/bin/php 提权后：

$ php demo10.php
uid=1000,euid=0
uid=0,euid=0
我能修改...

$ cat pwd.txt 
php is the best ?