0. Internet和HTTP协议以及Apache多路处理模块
1. Internet和HTTP协议
1.1 Internet 因特网
因特网是"Internet”的中文译名，它起源于美国的五角大楼，它的前身是美国国防部高级研究计划局（ARPA）主持研制的ARPAnet。20世纪50年代末，正处于冷战时期。当时美国军方为了自己的计算机网络在受到袭击时,即使部分网络被摧毁，其余部分仍能保持通信联系，便由美国国防部的高级研究计划局（ARPA）建设了一个军用网，叫做"阿帕网”（ARPAnet）。阿帕网于1969年正式启用，当时仅连接了4台计算机，供科学家们进行计算机联网实验用，这就是因特网的前身。
到70年代，ARPAnet已经有了好几十个计算机网络，但是每个网络只能在网络内部的计算机之间互联通信，不同计算机网络之间仍然不能互通。为此， ARPA又设立了新的研究项目，支持学术界和工业界进行有关的研究，研究的主要内容就是想用一种新的方法将不同的计算机局域网互联，形成"互联网”。研究人员称之为"internetwork”，简称"Internet"。
在研究实现互联的过程中，计算机软件起了主要的作用。1974年，出现了连接分组网络的协议，其中就包括了TCP/IP协议。TCP/IP有一个非常重要的特点，就是开放性，即TCP/IP的规范和Internet的技术都是公开的。目的就是使任何厂家生产的计算机都能相互通信，使Internet成为一个开放的系统，这正是后来Internet得到飞速发展的重要原因。ARPA在1982年接受了TCP/IP，选定Internet为主要的计算机通信系统，并把其它的军用计算机网络都转换到TCP/IP。1983年，ARPAnet分成两部分：一部分军用，称为MILNET；另一部分仍称ARPAnet，供民用。
1986年，美国国家科学基金组织（NSF）将分布在美国各地的5个为科研教育服务的超级计算机中心互联，并支持地区网络，形成SNSFnet。1988 年，SNSFnet替代ARPAnet成为Internet的主干网。NSFnet主干网利用了在ARPAnet中已证明是非常成功的TCP/IP技术，准许各大学、政府或私人科研机构的网络加入。1989年，ARPAnet解散，Internet从军用转向民用。
Internet的发展引起了商家的极大兴趣。1992年，美国IBM、MCI、MERIT三家公司联合组建了一个高级网络服务公司（SNS），建立了一个新的网络，叫做SNSnet，成为Internet的另一个主干网。它与SNSFnet不同，NSFnet是由国家出资建立的，而SNSnet则是SNS 公司所有，从而使Internet开始走向商业化。
1995年4月30日，SNSFnet正式宣布停止运作。而此时Internet的骨干网已经覆盖了全球91个国家，主机已超过400万台。而在当前，因特网仍以惊人的速度向前发展。
在90年代，超文本标识语言（HTML），即一个可以获得因特网的图像信息的超文本因特网协议被采用，使每一个人可以产生自己的图像页面（网址），然后成为一个巨大的虚拟超文本网络的组成部分。
这个增强型的因特网又被非正式地称为万维网，与此同时产生了数量庞大的新用户群。于是，许多人用"因特网” 一词指这个网络的物理结构，包括连接所有事物的客户机、服务器和网络；而用"万维网”一词指利用这个网络可以访问的所有网站和信息。
1.2 Internet和中国
北京时间1987年9月14日，钱天白建立起一个网络节点，通过电话拨号连接到国际互联网，向他的德国
朋友发出来自中国的第一封电子邮件：Across the Great Wall we can reach every corner in the world，自此，中国与国际计算机网络开始连接在一起
中国互联网连接世界:
1885年台湾建省，首任巡抚刘铭传派人与福州船政联系，使用船政电报学堂毕业生为技术人员，于1887年铺设成功台湾淡水至福州川石海底电缆，全长117海里。这是我国自行设计安装的第一条海底电缆。此电缆毁于第二次世界大战
我国于1989年开始投入到全球海底光缆的投资与建设中来，并于1993年实现了首条国际海底光缆的登陆（中日之间C-J海底光缆系统）；随后在1997年，我国参与建设的全球海底光缆系统（FLAG）建成并投入运营，这也是第一条在我国登陆的洲际海底光缆中国连接世界目前共有8条光缆，四个登陆站允许入境，目前我国的登陆站设立在三个城市的四个地区，分别是山东青岛登陆站（隶属中国联通）、上海崇明登陆站（隶属中国电信）、上海南汇登陆站（隶属中国联通）和广东汕头登陆站（隶属中国电信）
1.3 跨网络的主机间通讯
Socket套接字
image.png
套接字Socket, 是进程间通信IPC的一种实现，允许位于不同主机（或同一主机）上不同进程之间进行通信和数据交换，SocketAPI出现于1983年，4.2 BSD实现
在建立通信连接的每一端，进程间的传输要有两个标志：IP地址和端口号，合称为套接字地址 socket address
客户机套接字地址定义了一个唯一的客户进程
服务器套接字地址定义了一个唯一的服务器进程
image.png
Socket API: 封装了内核中所提供的socket通信相关的系统调用
Socket Domain: 根据其所使用的地址
- AF_INET：Address Family，IPv4
- AF_INET6：IPv6
- AF_UNIX：同一主机上不同进程之间通信时使用
Socket Type: 根据使用的传输层协议
- SOCK_STREAM：流，tcp套接字，可靠地传递、面向连接
- SOCK_DGRAM：数据报，udp套接字，不可靠地传递、无连接
- SOCK_RAW: 裸套接字,无须tcp或udp,APP直接通过IP包通信
客户/服务器程序的套接字函数
image.png
套接字相关的系统调用:
- socket() 创建一个套接字
- bind() 绑定IP和端口
- listen() 监听
- accept() 接收请求
- connect() 请求连接建立
- write() 发送
- read() 接收
- close() 关闭连接
服务端会有两个socket, 一个用于监听, 一个用于处理请求
Step 1: TCP 服务器创建socket
Step 2: (bind函数)绑定协议, IPv4和端口号
Step 3: 让socket监听在绑定的协议, IPv4和端口号上, 等待用户连接
Step 4: 客户端创建socket
Step 5: 通过connect函数, 连接到服务器端socket
Step 6: 服务器端socket通过accept函数进行接收, 此时, 服务器端会生成一个新的New Socket专门用来处理这个客户端请求, 原本的socket会继续进行监听, 等待客户端连接
范例: nc程序模拟socket通信过程
# 实现服务端, 监听在10.0.0.81:8000
[12:40:36 root@CentOS-8-1 ~]#nc -l 8000
[12:41:38 root@CentOS-8-1 ~]#ss -ntl
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 0.0.0.0:22 0.0.0.0:*
LISTEN 0 1 0.0.0.0:8000(监听在8000端口) 0.0.0.0:*
LISTEN 0 128 [::]:22 [::]:*
# 实现客户端连接服务端10.0.0.81:8000
[12:40:35 root@centos-7-1 ~]#nc 10.0.0.81 8000
# 客户端10.0.0.237向服务端10.0.0.81发送消息
[12:40:35 root@centos-7-1 ~]#nc 10.0.0.81 8000
i am 10.0.0.237
# 服务端10.0.0.81向客户端10.0.0.237发送信息
[12:40:31 root@CentOS-8-1 ~]#clear
[12:40:36 root@CentOS-8-1 ~]#nc -l 8000
i am 10.0.0.237
i am 10.0.0.81
# 客户端接收到服务端消息
[12:40:35 root@centos-7-1 ~]#nc 10.0.0.81 8000
i am 10.0.0.237
i am 10.0.0.81
# 服务端接收到10.0.0.237客户端发来的消息
[12:20:00 root@CentOS-8-1 ~]#nc -l 8000
i am 10.0.0.237
# nc只是一个简单的网络连接程序, 一旦接收到一个客户端连接, 就会把当前的监听(Listen)连接转为ESTAB而不是重新创建一个连接
范例: 通过strace命令查看socket实现的过程
# 服务端创建socket
[12:23:05 root@CentOS-8-1 ~]#strace -ff -o nc.log nc -l 8000
# 客户端连接到服务端
[12:22:32 root@centos-7-1 ~]#nc 10.0.0.81 8000
一个socket连接包含五个元素, 任何一个元素改变, 都会成为一个新的连接
源ip
源端口号
目标ip
目标端口号
协议类型
[12:24:26 root@CentOS-8-1 ~]#cat nc.log.22767
execve("/usr/bin/nc", ["nc", "-l", "8000"], 0x7ffeb275c6d8 /* 22 vars */) = 0
brk(NULL) = 0x5568b6743000
arch_prctl(0x3001 /* ARCH_??? */, 0x7fffe3db6a90) = -1 EINVAL (Invalid argument)
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=24073, ...}) = 0
mmap(NULL, 24073, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f81d1f54000
close(3) = 0
openat(AT_FDCWD, "/lib64/libbsd.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0`G\0\0\0\0\0\0"..., 832) = 832
lseek(3, 89336, SEEK_SET) = 89336
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=120128, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f81d1f52000
lseek(3, 89336, SEEK_SET) = 89336
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
mmap(NULL, 2195792, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d1b19000
mprotect(0x7f81d1b2f000, 2097152, PROT_NONE) = 0
mmap(0x7f81d1d2f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x16000) = 0x7f81d1d2f000
mmap(0x7f81d1d31000, 336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d1d31000
close(3) = 0
openat(AT_FDCWD, "/lib64/libresolv.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p<\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=142528, ...}) = 0
mmap(NULL, 2189952, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d1902000
mprotect(0x7f81d1916000, 2093056, PROT_NONE) = 0
mmap(0x7f81d1b15000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x7f81d1b15000
mmap(0x7f81d1b17000, 6784, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d1b17000
close(3) = 0
openat(AT_FDCWD, "/lib64/libtls.so.25", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340s\0\0\0\0\0\0"..., 832) = 832
lseek(3, 76560, SEEK_SET) = 76560
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=87360, ...}) = 0
lseek(3, 76560, SEEK_SET) = 76560
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
mmap(NULL, 2179384, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d16ed000
mprotect(0x7f81d1700000, 2097152, PROT_NONE) = 0
mmap(0x7f81d1900000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13000) = 0x7f81d1900000
close(3) = 0
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\2607\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=4176104, ...}) = 0
mmap(NULL, 3938144, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d132b000
mprotect(0x7f81d14e4000, 2093056, PROT_NONE) = 0
mmap(0x7f81d16e3000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b8000) = 0x7f81d16e3000
mmap(0x7f81d16e9000, 14176, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d16e9000
close(3) = 0
openat(AT_FDCWD, "/lib64/librt.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340%\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=98680, ...}) = 0
mmap(NULL, 2132928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d1122000
mprotect(0x7f81d1129000, 2097152, PROT_NONE) = 0
mmap(0x7f81d1329000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x7000) = 0x7f81d1329000
close(3) = 0
openat(AT_FDCWD, "/lib64/libssl.so.1.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20\373\1\0\0\0\0\0"..., 832) = 832
lseek(3, 547192, SEEK_SET) = 547192
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=615504, ...}) = 0
lseek(3, 547192, SEEK_SET) = 547192
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
mmap(NULL, 2699312, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d0e8e000
mprotect(0x7f81d0f14000, 2097152, PROT_NONE) = 0
mmap(0x7f81d1114000, 53248, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x86000) = 0x7f81d1114000
mmap(0x7f81d1121000, 48, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d1121000
close(3) = 0
openat(AT_FDCWD, "/lib64/libcrypto.so.1.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\260\7\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=3058736, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f81d1f50000
mmap(NULL, 5123968, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d09ab000
mprotect(0x7f81d0c5b000, 2097152, PROT_NONE) = 0
mmap(0x7f81d0e5b000, 192512, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2b0000) = 0x7f81d0e5b000
mmap(0x7f81d0e8a000, 16256, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d0e8a000
close(3) = 0
openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0000o\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=470312, ...}) = 0
mmap(NULL, 2225344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d078b000
mprotect(0x7f81d07a6000, 2093056, PROT_NONE) = 0
mmap(0x7f81d09a5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x7f81d09a5000
mmap(0x7f81d09a7000, 13504, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d09a7000
close(3) = 0
openat(AT_FDCWD, "/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0'\0\0\0\0\0\0"..., 832) = 832
lseek(3, 88568, SEEK_SET) = 88568
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
fstat(3, {st_mode=S_IFREG|0755, st_size=95232, ...}) = 0
lseek(3, 88568, SEEK_SET) = 88568
read(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32) = 32
mmap(NULL, 2187272, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d0574000
mprotect(0x7f81d058a000, 2093056, PROT_NONE) = 0
mmap(0x7f81d0789000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x15000) = 0x7f81d0789000
mmap(0x7f81d078a000, 8, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f81d078a000
close(3) = 0
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\220\20\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=36824, ...}) = 0
mmap(NULL, 2109744, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f81d0370000
mprotect(0x7f81d0373000, 2093056, PROT_NONE) = 0
mmap(0x7f81d0572000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f81d0572000
close(3) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f81d1f4e000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f81d1f4c000
arch_prctl(ARCH_SET_FS, 0x7f81d1f4f600) = 0
mprotect(0x7f81d16e3000, 16384, PROT_READ) = 0
mprotect(0x7f81d0572000, 4096, PROT_READ) = 0
mprotect(0x7f81d0789000, 4096, PROT_READ) = 0
mprotect(0x7f81d09a5000, 4096, PROT_READ) = 0
mprotect(0x7f81d0e5b000, 176128, PROT_READ) = 0
mprotect(0x7f81d1114000, 36864, PROT_READ) = 0
mprotect(0x7f81d1329000, 4096, PROT_READ) = 0
mprotect(0x7f81d1900000, 4096, PROT_READ) = 0
mprotect(0x7f81d1b15000, 4096, PROT_READ) = 0
mprotect(0x7f81d1d2f000, 4096, PROT_READ) = 0
mprotect(0x5568b5aa8000, 4096, PROT_READ) = 0
mprotect(0x7f81d1f5a000, 4096, PROT_READ) = 0
munmap(0x7f81d1f54000, 24073) = 0
set_tid_address(0x7f81d1f4f8d0) = 22767
set_robust_list(0x7f81d1f4f8e0, 24) = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7f81d07919a0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7f81d079ddd0}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7f81d0791a30, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7f81d079ddd0}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
prlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
access("/etc/system-fips", F_OK) = -1 ENOENT (No such file or directory)
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f81d1362790}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
brk(NULL) = 0x5568b6743000
brk(0x5568b6764000) = 0x5568b6764000
brk(NULL) = 0x5568b6764000
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(8000), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
listen(3, 1) = 0
accept4(3, {sa_family=AF_INET, sin_port=htons(43684), sin_addr=inet_addr("10.0.0.237")}, [128 => 16], SOCK_NONBLOCK) = 4
poll([{fd=0, events=POLLIN}, {fd=4, events=0}, {fd=4, events=POLLIN}, {fd=1, events=0}], 4, -1
范例: socket 相关系统调用
[root@centos8 ~]#dnf -y install man-pages
[root@centos8 ~]#man 2 socket
[root@centos8 ~]#man 2 bind
[root@centos8 ~]#man 2 listen
[root@centos8 ~]#man 2 accept
[root@centos8 ~]#man 2 read
[root@centos8 ~]#man 2 write
[root@centos8 ~]#man 2 connect
[root@centos8 ~]#man 2 close
1.4 HTTP 超文本传输协议
1.4.1 HTTP相关概念
互联网：是网络的网络，是所有类型网络的母集。
因特网：世界上最大的互联网网络。即因特网概念从属于互联网概念。习惯上，大家把连接在因特网上的计算机都成为主机。
万维网：WWW（world wide web）万维网并非某种特殊的计算机网络，是一个大规模的、联机式的信息贮藏所，使用链接的方法能非常方便地从因特网上的一个站点访问另一个站点（超链技术），具有提供分布式服务的特点。万维网是一个分布式的超媒体系统，是超文本系统的扩充，基于B/S架构实现
image.png
URL：万维网使用统一资源定位符（Uniform Resource Locator）来标志万维网上的各种文档，并使每个文档在整个因特网的范围内具有唯一的标识符URL。
HTTP：为解决"用什么样的网络协议来实现整个因特网上的万维网文档”这一难题，就要使万维网客户程序（以浏览器为主，但不限于浏览器）与万维网服务器程序之间的交互遵守严格的协议，即超文本传送协议（HyperText Transfer Protocol）。HTTP是处于应用层的协议，使用TCP传输层协议进行可靠的传送。因此，需要特别提醒的是，万维网是基于因特网的一种广泛因特网应用系统，且万维网采用的是HTTP（80/TCP）和 HTTPS（443/TCP）的传输协议，但因特网还有其他的网络应用系统（如：FTP、SMTP等等）。
HTML：为了解决"怎样使不同作者创作的不同风格的万维网文档，都能在因特网上的各种主机上显示出来，同时使用户清楚地知道在什么地方存在着链接”这一问题，万维网使用超文本标记语言（HyperText Markup Language），使得万维网页面的设计者可以很方便地用链接从页面的某处链接到因特网的任何一个万维网页面，并且能够在自己的主机品目上将这些页面显示出来。HTML与txt一样，仅仅是是一种文档，不同之处在于，这种文档专供于浏览器上为浏览器用户提供统一的界面呈现的统一规约。且具备结构化的特征，这是txt所不具备的强制规定。
HTTP协议规定了主机之间交换文件的规则, 而HTML规定了文件的格式
1.4.2 浏览器访问网站的过程
image.png
1.4.3 HTTP协议通信过程
HTTP（HyperText Transfer Protocol，超文本传输协议）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础设计。HTTP最初的目的是为了提供一种远距离共享知识的方式，借助多文档进行关联实现超文本，连成相互参阅的WWW（world wide web,万维网）。
HTTP的发展是由蒂姆·伯纳斯-李（Tim Berners-Lee）于1989年在欧洲核子研究组织（CERN）所发起。HTTP的标准制定由万维网协会（World Wide Web Consortium，W3C）和互联网工程任务组（Internet Engineering Task Force，IETF）进行协调，最终发布了一系列的RFC，其中最著名的是1999年6月公布的 RFC 2616，定义了HTTP协议中现今广泛使用的一个版本——HTTP 1.1版。
HTTP服务通信过程
image.png
HTTP协议分层
image.png
1.4.4 HTTP相关技术
1.4.4.1 web开发语言
HTTP: Hyper Text Transfer Protocol 应用层协议，默认端口： 80/tcp
WEB前端开发语言:
- html: Hyper Text Markup Language 超文本标记语言，编程语言，主要负责实现页面的结构。
- css: Cascading Style Sheet 层叠样式表， 定义了如何显示（装扮） HTML 元素，比如：字体大小和颜色属性等。样式通常保存在外部的 .css 文件中。通过仅编辑一个简单的 CSS 文档，可以同时改变站点中所有页面的布局和外观。
- javascript: 实现网页的动画效果，但实属于静态资源。
静态页面vs动态页面:
- 静态页面: 点击查看网页源代码后显示的代码和服务器存放的页面代码相同
- 动态页面: 点击查看网页源代码后显示的代码和服务器存放的页面代码不同, 动态页面在浏览器查看网页源代码看到的是程序代码在后端执行后的结果, 而非程序代码本身
1.4.4.2 MIME
MIME : Multipurpose Internet Mail Extensions 多用途互联网邮件扩展
文件 /etc/mime.types ,来自于mailcap包. 该文件定义了本地web服务器能接收哪种类型的文件通过HTTP协议传输
MIME格式：major/minor
早期的HTTP协议只能在网络中传递文字页面, 通过MIME技术, 实现在网络中传输其他类型的文件, 比如图片, 视频等。
MIME最早是应用在邮件技术, 后来被HTTP利用解决在网络中传输不同类型的文件。
参考链接：
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Basics_of_HTTP/MIME_Types
http://www.w3school.com.cn/media/media_mimeref.asp
范例:
text/plain # 纯文字文本
text/html
text/css
image/jpeg
image/png
video/mp4
application/javascript
application/json
...
1.4.4.3 URI, URL和URN
URI： Uniform Resource Identifier 统一资源标识，分为URL 和 URN
URN：Uniform Resource Naming，统一资源命名, 只是用来描述一个互联网资源的名称
- 示例： P2P下载使用的磁力链接是URN的一种实现
magnet:?xt=urn:btih:660557A6890EF888666
URL：Uniform Resorce Locator，统一资源定位符，用于描述某服务器某特定资源位置, 也就是完整的网址路径
两者区别：URN如同一个人的名称，而URL代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。URN仅用于命名，而不指定地址
URL组成:
image.png
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
scheme:方案，访问服务器以获取资源时要使用哪种协议
user:用户，某些方案访问资源时需要的用户名
password:密码，用户对应的密码，中间用：分隔
Host:主机，资源宿主服务器的主机名或IP地址
port:端口,资源宿主服务器正在监听的端口号，很多方案有默认端口号
path:路径,服务器资源的本地名，由一个/将其与前面的URL组件分隔
params:参数，指定输入的参数，参数为名/值对，多个参数，用;分隔
query:查询，传递参数给程序，如数据库，用？分隔,多个查询用&分隔
frag:片段,一小片或一部分资源的名字，此组件在客户端使用，用#分隔
URL示例:
http://www.it.com:8080/images/logo.jpg
ftp://admin:password@172.16.0.1/pub/linux.ppt
rtsp://videoserver/video_demo/ # Real Time Streaming Protocol
gcomm://10.0.0.8,10.0.0.18,10.0.0.28
http://www.it.com/bbs/hello;gender=f/send;type=title
https://list.jd.com(省略port:80端口号)/list.html?cat=670,671,672&ev=14_2&sort=sort_totalsales15_desc&trans=1
http://apache.org/index.html#projects-list
1.4.4.4 统计网站访问量
网站访问量统计的重要指标：
- IP(独立IP)：即Internet Protocol, 指独立IP数。一天内来自相同客户机IP 地址只计算一次，记录远程客户机IP地址的计算机访问网站的次数，是衡量网站流量的重要指标
- PV(访问量)： 即Page View, 页面浏览量或点击量，用户每次刷新即被计算一次，PV反映的是浏览某网站的页面数，PV与来访者的数量成正比，PV并不是页面的来访者数量，而是网站被访问的页面数量
- UV(独立访客)：即Unique Visitor,访问网站的一台电脑为一个访客。一天内相同的客户端只被计算一次。可以理解成访问某网站的电脑的数量。网站判断来访电脑的身份是通过cookies实现的。如果更换了IP后但不清除cookies，再访问相同网站，该网站的统计中UV数是不变的
1.4.5 HTTP工作机制
一次http事务包括：
- http请求：http request
- http响应：http response
Web资源：web resource， 一个网页由多个资源（文件）构成，打开一个页面，通常会有多个资源展示出来，但是每个资源都要单独请求。因此，一个Web 页面通常并不是单个资源，而是一组资源的集合
资源类型:
- 静态文件：无需服务端做出额外处理
文件后缀：.html, .txt, .jpg, .js, .css, .mp3, .avi - 动态文件：服务端执行程序，返回执行的结果
文件后缀：.php, .jsp ,.asp
HTTP连接请求:
image.png
串行连接和并行连接:
① 串行连接
image.png
② 并行连接
image.png
串行,持久连接和管道:
③ 持久连接
image.png
④ 管道化连接
image.png
提高HTTP连接性能, 加快网站资源的访问:
- 并行连接：通过多条TCP连接发起并发的HTTP请求
- 持久连接：keep-alive，重用TCP连接，以消除连接和关闭的延迟, 以事务个数和时间来决定是否关闭连接
- 管道化连接：通过共享TCP连接，发起并发的HTTP请求
- 复用的连接：交替传送请求和响应报文（实验阶段）
1.4.6 HTTP 协议版本
image.png
- http/0.9:
1991，原型版本，功能简陋，只有一个命令GET。GET /index.html ,服务器只能回应HTML格式字符串，不能回应别的格式
- http/1.0:
1996年5月, 支持cache, MIME, method
每个TCP连接只能发送一个请求，发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接
引入了POST命令和HEAD命令
头信息是 ASCII 码，后面数据可为任何格式。服务器回应时会告诉客户端，数据是什么格式，即Content-Type字段的作用。这些数据类型总称为MIME多用途互联网邮件扩展，每个值包括一级类型和二级类型，预定义的类型，也可自定义类型, 常见Content-Type值：text/xml image/jpeg audio/mp3
- http/1.1:
1997年1月，引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。对于同一个域名，大多数浏览器允许同时建立6个持久连接引入了管道机制，即在同一个TCP连接里，客户端可以同时发送多个请求，进一步改进了HTTP协议的效率。 一次三次握手, 可以完成多次资源的请求和相应。
新增方法：PUT、PATCH、OPTIONS、DELETE
同一个TCP连接里，所有的数据通信是按次序进行的。服务器只能顺序处理回应，前面的回应慢，会有许多请求排队，造成"队头堵塞"（Head-of-line blocking）
为避免上述问题，两种方法：一是减少请求数，二是同时多开持久连接。
网页优化技巧，如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）等
HTTP 协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度
HTTP1.0和HTTP1.1的区别:
image.png
- 缓存处理，在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None�Match等更多可供选择的缓存头来控制缓存策略
- 带宽优化及网络连接的使用，HTTP1.0中，存在一些浪费带宽的现象，例如：客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），方便了开发者自由的选择以便于充分利用带宽和连接
- 错误通知的管理，在HTTP1.1中新增24个状态响应码，如409（Conflict）表示请求的资源与资源当前状态冲突；410（Gone）表示服务器上的某个资源被永久性的删除
- Host 头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）
- 长连接，HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在
HTTP1.1中默认开启Connection： keep-alive，弥补了HTTP1.0每次请求都要创建连接的缺点
HTTP1.0和1.1的问题:
- HTTP1.x在传输数据时，每次都需要重新建立连接，无疑增加了大量的延迟时间，特别是在移动端更为突出
- HTTP1.x在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，无法保证数据的安全性
- HTTP1.x在使用时，header里携带的内容过大，增加了传输的成本，并且每次请求header基本不怎么变化，尤其在移动端增加用户流量
- 虽然HTTP1.x支持了keep-alive，来弥补多次创建连接产生的延迟，但是keep-alive使用多了同样会给服务端带来大量的性能压力，并且对于单个文件被不断请求的服务(例如图片存放网站)，
keep-alive可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间
HTTPS协议:
为解决安全问题，网景在1994年创建了HTTPS，并应用在网景导航者浏览器中。 最初，HTTPS是与SSL一起使用的；在SSL逐渐演变到TLS时（其实两个是一个东西，只是名字不同而已），最新的HTTPS也由在2000年五月公布的RFC 2818正式确定下来。HTTPS就是安全版的HTTP，目前大型网站基本实现全站HTTPS
HTTPS特点:
- HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费
- HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的
- HTTP和HTTPS使用的是不同的连接方式，端口不同，前者是80，后者是443
- HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题
- HTTPS 实现过程降低用户访问速度，但经过合理优化和部署，HTTPS 对速度的影响还是可以接受的
SPDY协议:
SPDY：2009年谷歌研发，综合HTTPS和HTTP两者有点于一体的传输协议，主要特点:
- 降低延迟，针对HTTP高延迟的问题，SPDY优雅的采取了多路复用（multiplexing）。多路复用通过多个请求stream共享一个tcp连接的方式，解决了HOL blocking的问题，降低了延迟同时提高了带宽的利用率
- 请求优先级（request prioritization）。多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。SPDY允许给每个request设置优先级，重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，可以保证用户能第一时间看到网页内容
- header压缩。HTTP1.x的header很多时候都是重复多余的。选择合适的压缩算法可以减小包的大小和数量
- 基于HTTPS的加密协议传输，大大提高了传输数据的可靠性
- 服务端推送（server push），采用了SPDY的网页，例如网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了
HTTP2协议:
http/2.0：2015年，HTTP2.0是SPDY的升级版
- 头信息和数据体都是二进制，称为头信息帧和数据帧
- 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了"队头堵塞",此双向的实时通信称为多工（Multiplexing）
- 引入头信息压缩机制（header compression）,头信息使用gzip或compress压缩后再发送；客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，不发送同样字段，只发送索引号，提高速度
- HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送（server push）
HTTP2.0和SPDY区别:
- HTTP2.0 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS
- HTTP2.0 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DEFLATE
1.4.7 HTTP 请求访问的完整过程
image.png
一次完整的http请求处理过程:
1、建立连接：接收或拒绝连接请求
2、接收请求：接收客户端请求报文中对某资源的一次请求的过程
Web访问响应模型（Web I/O）
image.png
- 单进程I/O模型：启动一个进程处理用户请求，而且一次只处理一个，多个请求被串行响应
- 多进程I/O模型：并行启动多个进程,每个进程响应一个连接请求
- 复用I/O结构：启动一个进程，同时响应N个连接请求
- 复用的多进程I/O模型：启动M个进程，每个进程响应N个连接请求，同时接收M*N个请求
3、处理请求：服务器对请求报文进行解析，并获取请求的资源及请求方法等相关信息，根据方法，资源，首部和可选的主体部分对请求进行处理
常用请求Method: GET、POST、HEAD、PUT、DELETE、TRACE、OPTIONS
4、访问资源：
服务器获取请求报文中请求的资源web服务器，即存放了web资源的服务器，负责向请求者提供对方请求的静态资源，或动态运行后生成的资源
5、构建响应报文：
一旦Web服务器识别除了资源，就执行请求方法中描述的动作，并返回响应报文。响应报文中 包含有响应状态码、响应首部，如果生成了响应主体的话，还包括响应主体
1）响应实体：如果事务处理产生了响应主体，就将内容放在响应报文中回送过去。响应报文中通常包括：
- 描述了响应主体MIME类型的Content-Type首部
- 描述了响应主体长度的Content-Length
- 实际报文的主体内容
2）URL重定向：web服务构建的响应并非客户端请求的资源，而是资源另外一个访问路径
3）MIME类型： Web服务器要负责确定响应主体的MIME类型。多种配置服务器的方法可将MIME类型与资源管理起来
- 魔法分类：Apache web服务器可以扫描每个资源的内容，并将其与一个已知模式表(被称为魔法文件)进行匹配，以决定每个文件的MIME类型。这样做可能比较慢，但很方便，尤其是文件没有标准扩展名时
- 显式分类：可以对Web服务器进行配置，使其不考虑文件的扩展名或内容，强制特定文件或目录内容拥有某个MIME类型
- 类型协商： 有些Web服务器经过配置，可以以多种文档格式来存储资源。在这种情况下，可以配置Web服务器，使其可以通过与用户的协商来决定使用哪种格式(及相关的MIME类型)最好
6、发送响应报文
Web服务器通过连接发送数据时也会面临与接收数据一样的问题。服务器可能有很多条到各个客户端的连接，有些是空闲的，有些在向服务器发送数据，还有一些在向客户端回送响应数据。服务器要记录连接的状态，还要特别注意对持久连接的处理。对非持久连接而言，服务器应该在发送了整条报文之后，关闭自己这一端的连接。对持久连接来说，连接可能仍保持打开状态，在这种情况下，服务器要正确地计算Content-Length首部，不然客户端就无法知道响应什么时候结束
7、记录日志
最后，当事务结束时，Web服务器会在日志文件中添加一个条目，来描述已执行的事务
浏览器访问网站的底层实现流程:
浏览器访问网站的过程
1. DNS解析
2. 路由寻址
3. 连接对方主机监听端口, 通过TCP三次握手建立连接
4. 客户端发起http请求
5. 服务器端处理请求, 不同Web服务器通过不同逻辑处理, 见下面: <<一次http请求访问的完整过程>>
中间还要涉及https 和 重定向技术, strict-transport-security(HSTS)
6. 服务器得到处理结果, 封装响应报文头部, 发给客户端
7. 客户端收到页面后, 分析页面代码, 进行解释渲染, 展示页面
8. 如果涉及动态资源, 比如php或者jsp, 那还要发给后端的应用程序服务器进行处理, php-FastcCGI, 处理过程中有可能涉及到数据库访问, 还要连接MySQL进行读写
一次http请求访问的完整过程:
1. 建立连接:
URL → DNS (URL - IP ) → 接受或拒绝连接请求 → 三次握手建立通讯
2. 发送/接受请求:
客户端发起HTTP请求: 客户端开启随机端口号, 通过TCP/IP套接字访问Web服务器的80端口
服务器接受HTTP请求: Web服务器的80端口要保持在监听状态, 接受客户端请求报文中对某资源的请求
服务器接收到请求后, 会予以相应
3. 接受,响应过程:
多种模型: 多种不同处理方案
-
串行, 单I/O模型: 来一个处理一个请求, 会造成申请排队现象. (单进程I/O). 每个连接只处理一个请求, 处理完连接断开, 之后再次建立连接, 处理请求.
-
并行: 同时处理多个请求. (多进程I/O). 缺点: 建立太多的进程, 每个进程处理一个连接请求. CPU负载过高, 连接太多也会排队. 因为虽然是多进程, 但实际还是一个进程处理一个请求, 当连接数超过开启的进程数就会造成排队. 即使有CPU分片, 也会造成频繁切换, 一个用户的请求还没有处理完, 就要去处理另一个请求, 那么CPU缓存中包含的此前的用户请求处理信息有可能丢失. 真正干活的不是进程, 而是CPU, 因此, 最终结果就是性能差. (Apache默认处理方式,prefork). 高并发比不上Nginx, 但是多进程工作, 起到进程间隔离作用, 进程之间互不影响. 因此, Apache稳定.
-
复用的单进程I/O结构: 只开启单进程, 通过连接复用器, 准备一个连接池, 用来接收用户连接. 利用CPU处理速度快的特性, CPU将请求提交到内核, 发起系统调用, 向硬盘请求文件, 由于磁盘的I/O是很慢的, 因此CPU就有时间去处理后续的请求. 因此, 可以用单进程, 利用处理间隙来支持并发连接. 减少了服务器开启的进程. Nginx单进程处理方式
-
复用的多进程I/O结构: 充分发挥多核CPU的优势, 开启多个进程, 每个进程都支持复用的单进场I/O. (Nginx多进程处理方式). 因此Nginx处理高并发效果好.
适用场景:
Apache: 企业并发量不高, 但是追求稳定. 10000(ss -nt)高并发(c10k问题). 多进程处理, 起到隔离.
Nginx: 高并发. 单机2-3万, 或者更高, 看服务器配置.
4. 处理请求
服务器对请求报文进行解析, 并获取请求的资源及请求方法等相关信息, 根据方法, 资源, 首部和可选主体部分对请求进行处理
常用的请求: GET, POST, HEAD, PUT, DELETE, TRACE, OPTIONS
5. 访问资源
服务器获取请求报文中请求的资源Web服务器, 即存放了Web资源的服务器, 负责向请求者提供对方请求的静态资源, 或动态资源后生成的资源.
6. 构建响应报文
7. 发送响应报文
8. 记录日志
1.4.8 Apache三种多路处理模块工作原理和区别, MPM (Multi-Processing Module)
- prefork: 多进程IO模型, 每个进程响应一个请求, httpd2.4.6(CentOS7上的httpd默认使用prefork), 也是早期的apache的默认模型
一个主进程(由root创建): 仅负责监听, 用于生成和回收多个子进程, 创建套接字, 只负责请求的接收, 不负责具体的响应
多个子进程: 工作worker进程, 每个子进程中会开启一个独立的线程用于负责处理一个请求, 系统初始化时, 预先生成多个空闲进程, 等待请求
prefork MPM: 预派生模式, 由一个主控进程, 生成多个子进程, 每个子进程中会有一个独立的线程响应用户请求, 相对比较占用内存, 但是比较稳定, 可以设置最大和最小进程数, 适用于访问量不是很大的场景
优点: 稳定
缺点: 慢, 占用资源, 不适用于高并发的场景
图片.png
- worker模型: 复用的多进程IO模型, 多进程多线程
一个主进程(由root创建): 生成m个子进程, 每个子进程负责生成n个线程, 每个线程响应一个请求, 并发响应请求数量为m*n
worker MPM: 是一种多进程和多线程混合的模型, 由一个主控制进程, 启动多个子进程, 每个子进程里面包含固定的线程, 使用线程处理请求, 当线程不够使用时, 会再启动一个新的子进程, 然后在子进程里面再启动线程处理请求, 由于其使用了多线程处理请求, 因此可以承受更高的并发
优点: 相比prefork占用的内存较少, 因为最终使用的是多个线程, 而线程相比进程占用的内存资源较少, 可以同时处理多个请求
缺点: 当使用keep-alive的长连接方式, 某个线程会被一直占用, 即使没有传输数据, 也需要一直等待到超时才会被释放, 如果过多的线程, 被这样占用, 也会导致在高并发场景下, 无服务线程可用, 该问题在prefork模式下也会发生. 此外, 单个进程中的多个线程会出现资源竞争的情况, 如果一个线程出现问题, 会影响本进程中的其他线程
图片.png
- event: 事件驱动模型(worker模型的变种), httpd2.4.37(CentOS8上的httpd默认使用event模型)的默认模型
一个主进程(由root创建): 生成m个子进程, 每个子进程负责生个n个线程, 每个工作线程响应一个请求, 并发响应请求数为:m*(n-1), n-1是因为监听线程不会处理请求, 仅负责调度, 有专门的监控线程来管理这些keep-alive类型的线程, 当有真实请求时, 将请求传递给服务线程, 执行完毕后, 又允许线程释放. 或者将没有请求处理的线程放在空闲线程. 这样增加了高并发场景下的请求处理能力
event MPM: 属于事件驱动模型, epoll, 一个进程响应多个请求, 现在的版本已经是稳定可用的模式. 它和worker模型很像, 最大的区别在于, 它解决了keep-alive场景下, 长期被占用的线程的资源浪费问题 (某些线程因为被keep-alive, 空挂在那里等待, 中间几乎没有请求过来, 甚至等待超时)
event MPM中, 会有一个专门的线程来管理这些keep-alive类型的线程, 当有真实请求过来的时候, 将请求传递给服务线程, 执行完毕后, 又允许线程被释放. 这样就可以增加高并发场景下的请求处理能力
图片.png
