PHP Web、会话与运行机制

• Session 主要存储在服务端。
• Cookie 主要存储在客户端。
• 两者都可以设置过期时间。
• 通常用 Cookie 保存标识，再用服务端 Session 保存状态。

常见做法有：

1. 配置 session.gc_maxlifetime
2. 调用 session_set_cookie_params()
3. 修改 php.ini 或运行时 ini 配置

需要区分：

• 服务端 Session 数据有效期
• 客户端 Session Cookie 有效期

核心思路是让多个应用节点共享同一份 Session 存储。

常见方案：

1. Redis
2. Memcached
3. 数据库
4. 共享文件系统

实际项目里最常见的是 Redis。

常见思路是把多个应用实例都接到统一的会话存储层。

如果面试继续追问，可以补：

• Session 过期策略
• 登录态续期
• 是否改为无状态 JWT

从协议角度看，Cookie 本质上是 HTTP 响应头里的 Set-Cookie。

因此即使不直接调用 setcookie()，也仍然可以：

header('Set-Cookie: token=abc123; Path=/; HttpOnly');

但在业务代码里通常还是更推荐使用标准接口。

常见方式有：

1. file_get_contents()
2. curl
3. fsockopen() / socket

通常业务开发更推荐 curl，因为超时、Header、POST、HTTPS 等控制更完整。

常见方式：

1. file_get_contents()
2. curl
3. fsockopen() / socket

区别大致如下：

• file_get_contents()：简单轻量。
• curl：功能最完整，业务里最常用。
• fsockopen()：更底层，灵活但使用成本高。

在典型 Web 架构里：

1. Web Server 接收请求，例如 Nginx。
2. 请求被转发给 PHP-FPM。
3. PHP-FPM 里的某个 worker 进程处理请求。
4. 请求结束后，worker 回到池中等待下一个请求。

因此传统 PHP 的并发主要来自“多进程 worker + 进程池管理”。

常见高频项：

• pm
• pm.max_children
• pm.start_servers
• pm.min_spare_servers
• pm.max_spare_servers
• pm.max_requests

其中：

• pm=static：固定数量子进程。
• pm=dynamic：动态调整。
• pm=ondemand：有请求时再拉起。

daemonize 表示是否以守护进程方式在后台运行。

核心思路是根据机器资源和单请求内存占用反推：

max_children ≈ 可用于 PHP 的总内存 / 单 worker 平均内存

最终还是要结合压测和监控校正。

在典型 Nginx + PHP-FPM 架构里：

1. 请求先到 Nginx。
2. Nginx 判断是静态资源还是 PHP 请求。
3. PHP 请求通过 FastCGI 转发给 PHP-FPM。
4. PHP-FPM 选一个空闲 worker 执行脚本。
5. 执行结果返回给 Nginx。
6. Nginx 再响应客户端。

如果从 PHP 生态角度回答，重点是并发、超时和资源上限相关参数。

例如：

• Nginx 侧：
  • fastcgi_pass
  • fastcgi_param
  • fastcgi_connect_timeout
  • fastcgi_read_timeout
• PHP-FPM 侧：
  • pm
  • pm.max_children
  • request_terminate_timeout
  • slowlog
  • pm.max_requests