标签：httpd
http协议介绍
（1） http/0.9：1991，原型版本，功能简陋，只有一个命令GET。GET /index.html ,服务器只能回应HTML格式字符串，不能回应别的格式
（2）http/1.0: 1996年5月,支持cache, MIME, method
每个TCP连接只能发送一个请求，发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接
引入了POST命令和HEAD命令
头信息是ASCII 码，后面数据可为任何格式。服务器回应时会告诉客户端，数据是什么格式，即Content-Type字段的作用。这些数据类型总称为MIME 多用途互联网邮件扩展，每个值包括一级类型和二级类型，预定义的类型，也可自定义类型。
常见Content-Type值：text/xml image/jpeg audio/mp3
（3）http/1.1：1997年1月
引入了持久连接（persistent connection），即TCP连接默认不关闭，可以被多个请求复用，不用声明Connection: keep-alive。对于同一个域名，大多数浏览器允许同时建立6个持久连接
引入了管道机制（pipelining），即在同一个TCP连接里，客户端可以同时发送多个请求，进一步改进了HTTP协议的效率
新增方法：PUT、PATCH、OPTIONS、DELETE
同一个TCP连接里面，所有的数据通信是按次序进行的。服务器只能顺序处理回应，前面的回应慢，会有许多请求排队，造成"队头堵塞"（Head-of-line blocking）
为避免上述问题，两种方法：一是减少请求数，二是同时多开持久连接。网页优化技巧，比如合并脚本和样式表、将图片嵌入CSS代码、域名分片（domain sharding）（因为对于同一个域名，大多数浏览器允许同时建立6个持久连接）等
HTTP 协议不带有状态，每次请求都必须附上所有信息。请求的很多字段都是重复的，浪费带宽，影响速度
Spdy：2009年,谷歌研发,解决HTTP/1.1 效率不高问题
（4）http/2.0：2015年
头信息和数据体都是二进制，称为头信息帧和数据帧
复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，且不用按顺序一一对应，避免了“队头堵塞“,此双向的实时通信称为多工（Multiplexing）
引入头信息压缩机制（header compression）,头信息使用gzip或compress压缩后再发送；客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，不发送同样字段，只发送索引号，提高速度
HTTP/2 允许服务器未经请求，主动向客户端发送资源，即服务器推送（server push）
http服务通信过程简介
服务器端首先创建socket对象，然后通过bind函数将ip地址与端口号80绑定在一起，由listen函数监听客户端请求，此时会发现服务器端80端口已打开；
客户端首先也要创建socket对象，由于客户端端口（TCP或UDP）是随机的，所以不需绑定，然后通过connect函数连接服务器；
服务器通过accept函数接受用户请求，双方建立连接开始通讯：客户端通过write函数向服务器端发送消息，服务器端通过read函数接收消息。
一次完整的http请求处理过程
1 在web服务器上可能会制定一些安全策略，限制或允许某些用户的访问。当接收到客户端请求后，web服务器会根据事先制定的安全策略，决定是否接收该客户端的连接请求。
2 当web服务器接受了客户端的连接请求后，接下来就可以接收客户端访问服务器资源的请求，web服务器接收请求的模型（或web服务器响应客户端请求的模型或web服务器接收请求的I/O处理模型）有四种：
（1）单进程I/O模型：只启动一个进程，每个进程每次只能处理一个客户请求，所以对于客户请求只能串行响应。相当于一个银行只有一个贵宾室，每个贵宾室每次只能接待一位客户。只适合访问量很小的服务器。
（2）多进程I/O模型：并行启动多个进程，每个进程每次只能处理一个客户请求，所以对于客户请求可以并行响应。相当于一个银行有多个贵宾室，每个贵宾室每次只能接待一位客户，那么就可以接待并行接待多位客户。进程响应比较稳定，不易出问题，http服务器默认使用这种方式响应客户端请求；但是用进程响应，比较耗费资源，当访问量过大时，开启的进程过多，耗费系统过多资源，导致系统崩溃。C10k就是当并发访问量达到10k时，导致系统崩溃。默认情况下，每台主机最多并发1024个进程。所以只适合一些访问量适中的服务器，如一些传统行业的网站。
（3）复用I/O结构：只启动一个进程，每个进程每次处理多个客户请求，所以对于客户请求可以并行响应。
实现方式有两种，第一种是多线程模型，即一个进程生成多个线程，每个线程响应一个客户请求。相当于一个银行有一个贵宾室，每个贵宾室有多个窗口，每个窗口每次能接待一位客户，那么就可以接待并行接待多位客户。多个线程共享一个进程的资源，优点是比较节约资源，缺点是多个线程间竞争资源，可能会互相干扰；第二种是事件驱动模型，也是一个进程处理多个请求
（4）复用的多进程I/O模型：并行启动多个进程，每个进程每次处理多个客户请求，所以对于客户请求可以并行响应。。相当于一个银行有多个贵宾室，每个贵宾室有多个窗口，每个窗口每次能接待一位客户，那么就可以接待并行接待多位客户。
3 服务器接收到客户端访问资源的请求后，对请求报头进行分析（http请求处理过程中，通过http协议传送的有请求报文和响应报文），报头中带有method（即请求方式：GET（下载）、POST（上传字符串）、HEAD（只看头部，不看内容）、PUT（上传图片、视频等资源）、DELETE（清除缓存）、TRACE、OPTIONS（查看当前网站支持的method））以及请求资源等，以决定服务器下一步要执行的动作。
4 一般来说，客户请求多是访问网页中的图片、css文件等资源，这些资源通常放在服务器的本地硬盘或者另一台服务器上或者NAS存储上。以资源放在服务器的本地硬盘为例，当用户在浏览器输入http://172.18.0.1/时，最后一个/是网站的根不是服务器文件系统的根，对于apache来说，指的是/var/www/html；若输入http://172.18.0.1/bbs，则指的是服务器的/var/www/html/bbs。但这一般是通常情况，http://172.18.0.1/bbs指向服务器的/app/bbs也可以，这种方式也就是docroot方式？web服务器资源路径映射方式：(a) docroot(b) alias(c) 虚拟主机docroot(d) 用户家目录docroot。服务器对请求报文分析后，就到服务器相应位置去获取资源：用户在客户端输入http://www.magedu.com/index.html，即客户端请求访问/var/www/html/index.html，服务器即Apache软件的httpd进程对用户请求分析后，由于其无法直接访问硬盘（linux操作系统分为用户空间和内核空间，应用程序进程如Apache软件的httpd进程无法直接访问硬盘），需将请求发到内核，由内核到磁盘的相应位置去读取文件，先将文件读取到内核的内存空间，然后复制到应用程序即Apache软件的httpd进程的内存空间（每个应用程序都有自己独立的内存空间）。
5 接下来，服务器对获取到的资源封装http报头，构建响应报文，响应报文中包含有响应状态码、响应首部，如果生成了响应主体的话，还包括响应主体。web服务构建的响应可能并非客户端请求的资源，而是资源另外一个访问路径，即URL重定向，但这种情形一般较少，多为客户端请求的资源。服务器要在响应报文中确定响应主体的MIME类型，即在content-type中指明资源类型。当文件有标准扩展名时，确定资源的类型比较容易。但若没有标准扩展名，可以采用以下三种方式：
（1）魔法分类：文件的首部有对文件类型的描述，即魔术。Apache web服务器可以扫描每个资源的内容，并将其与一个已知模式表(被称为魔法文件)进行匹配，以决定每个文件的MIME类型。这样做可能比较慢，但很方便，尤其是文件没有标准扩展名的时候
（2）显式分类：可以对Web服务器进行配置，使其不考虑文件的扩展名或内容，强制特定文件或目录内容拥有某个MIME类型
（3）类型协商：有些Web服务器经过配置，可以以多种文档格式来存储资源。在这种情况下，可以配置Web服务器，使其可以通过与用户的协商来决定使用哪种格式(及相关的MIME类型)"最好"
6 发送响应报文
Web服务器通过连接发送数据时也会面临与接收数据一样的问题。服务器可能有很多条到各个客户端的连接，有些是空闲的，有些在向服务器发送数据，还有一些在向客户端回送响应数据。服务器要记录连接的状态，还要特别注意对持久连接的处理。对非持久连接而言，服务器应该在发送了整条报文之后，关闭自己这一端的连接。对持久连接来说，连接可能仍保持打开状态，在这种情况下，服务器要正确地计算Content-Length首部，不然客户端就无法知道响应什么时候结束了
7 记录日志
最后，当事务结束时，Web服务器会在日志文件中添加一个条目，来描述已执行的事务，以便出现问题时进行分析。
CentOS 6 httpd程序环境
服务脚本：/etc/rc.d/init.d/httpd
脚本配置文件：/etc/sysconfig/httpd
服务控制和启动：
chkconfig httpd on|off
service {start|stop|restart|status|configtest|reload} httpd
站点网页文档根目录：/var/www/html
模块文件路径：/etc/httpd/modules、/usr/lib64/httpd/modules
主程序文件：
/usr/sbin/httpd
/usr/sbin/httpd.worker
/usr/sbin/httpd.event
主进程文件：
/etc/httpd/run/httpd.pid
日志文件目录：
/var/log/httpd
access_log: 访问日志
error_log：错误日志
帮助文档包：
httpd-manual
CentOS 6使用Httpd 2.2
Httpd 2.2常见配置
httpd配置文件的组成：
# grep "Section" /etc/httpd/conf/httpd.conf
### Section 1: Global Environment
### Section 2: ‘Main‘ server configuration
### Section 3: Virtual Hosts
配置格式：directive value
directive: 不区分字符大小写
value: 为路径时，是否区分大小写，取决于文件系统
1、站点访问控制常见机制
访问控制机制有两种：客户端来源地址，用户账号
（1）匹配文件系统某目录：
<Directory “/path">
...
</Directory>
（2）匹配文件系统某文件：
<File “/path/file”>
...
</File>
（3）匹配文件系统某文件：使用正则表达式
<FileMatch"PATTERN">
...
</FileMatch>
（4）匹配URL路径：
<Location "">
...
</Location>
（5）匹配URL路径：使用正则表达式
<LocationMatch"">
...
</LocationMatch>
2、<Directory>中“基于源地址”实现访问控制
(1) Options：后跟1个或多个以空白字符分隔的选项列表，在选项前的+，-表示增加或删除指定选项
常见选项：
Indexes：指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件时，不是返回403forbidden,而是返回索引列表给用户
FollowSymLinks：允许访问符号链接文件所指向的源文件
None：全部禁用
All：全部允许
指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件，返回403forbidden
允许所有选项，包括index
指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件，返回索引列表
指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件时，不是返回403forbidden,而是返回索引列表给用户
指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件，返回索引列表
相当于没有定义index选项，指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件时，返回403forbidden
指明的URL路径下不存在与定义的主页面资源（如index.html）相符的资源文件，返回403forbidden
(2) AllowOverride
与访问控制相关的哪些指令可以放在指定目录下的.htaccess（由AccessFileName指定）文件中，覆盖之前的配置指令，只对<directory>语句有效
AllowOverride All: 所有指令都有效，即所有指令都可以放在.htaccess中，覆盖之前的配置指令
AllowOverride None：.htaccess 文件无效
AllowOverride AuthConfig Indexes除了AuthConfig 和Indexes的其它指令都无法覆盖，即只有AuthConfig 和Indexes可以放在.htaccess中，覆盖之前的配置指令，其他指令不可以
只是对于/app/website1/bbs目录，所有指令都可以放在.htaccess中，覆盖之前对/app/website1/bbs这个目录的配置指令，而不会覆盖之前对于其他目录的配置指令
之前对/app/website1这个目录的配置指令是允许索引，即对/app/website1/bbs这个目录的配置指令是允许索引，若在.htaccess中禁止索引，则最终/app/website1/bbs禁止索引，但是/app/website1下的其他目录则可以索引
对哪个目录生效，就把该文件放在哪个目录下
所以此处只写options，不用写对哪个目录
因为.htaccess是none，即/app/website1/bbs禁止索引
因为.htaccess是indexes，即/app/website1/bbs允许索引
(3) order和allow、deny
order：定义生效次序；写在后面的表示默认法则
Order allow,deny
Order deny,allow
Allow from, Deny from
对于某个ip，
若只定义了拒绝规则，则不管谁的优先级高，都是拒绝该ip
若只定义了允许规则，则不管谁的优先级高，都是允许该ip
若既定义了允许规则又定义了拒绝规则，即产生了冲突，则谁的优先级高听谁的
若既未定义允许规则又未定义拒绝规则，则谁的优先级高听谁的
order deny,allow
deny from 1.1.1.1 3.3.3.3
allow from 2.2.2.2 3.3.3.3
对1.1.1.1，只定义了拒绝规则，则拒绝1.1.1.1
对2.2.2.2，只定义了允许规则，则允许2.2.2.2
对3.3.3.3，既定义了允许规则又定义了拒绝规则，由于order deny,allow，即allow优先级高，则允许3.3.3.3
对4.4.4.4，既未定义允许规则又未定义拒绝规则，由于order deny,allow，即allow优先级高，则允许4.4.4.4
order allow,deny
deny from 1.1.1.1 3.3.3.3
allow from 2.2.2.2 3.3.3.3
对1.1.1.1，只定义了拒绝规则，则拒绝1.1.1.1
对2.2.2.2，只定义了允许规则，则允许2.2.2.2
对3.3.3.3，既定义了允许规则又定义了拒绝规则，由于order allow,deny，即deny优先级高，则拒绝3.3.3.3
对4.4.4.4，既未定义允许规则又未定义拒绝规则，由于order allow,deny，即deny优先级高，则拒绝4.4.4.4
对192.168.25.107，只定义了允许规则，则允许192.168.25.107
其他ip，既未定义允许规则又未定义拒绝规则，由于order allow,deny，即deny优先级高，则拒绝
在192.168.25.107访问192.168.25.106上的web服务器成功
对192.168.25.107，既定义了允许规则又定义了拒绝规则，由于order allow,deny，即deny优先级高，则拒绝192.168.25.107
对192.168.25.0这个网段的其他ip，只定义了拒绝规则，则拒绝
其他ip，既未定义允许规则又未定义拒绝规则，由于order allow,deny，即deny优先级高，则拒绝
在192.168.25.107访问192.168.25.106上的web服务器失败
所有以.conf结尾的文件都不允许访问，包括主站点即网站根目录下的以.conf结尾的文件
但是正则表达式比较耗费服务器资源
/bbs下以.conf结尾的文件都不允许访问，/bbs是网站根目录下的，即URL路径起始位置下的/bbs
主站点即网站根目录下以.conf结尾的文件允许访问
3、日志设定
日志类型：访问日志、错误日志
loglevel可选值:
debug, info, notice, warn,error，crit, alert, emerg
定义日志格式：LogFormatformat strings
LogFormat"%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
使用日志格式：
CustomLoglogs/access_log combined
日志选项
%h 客户端IP地址
%l 远程用户,启用mod_ident才有效，通常为减号“-”
%u 验证（basic，digest）远程用户,非登录访问时，为一个减号“-”
%t 服务器收到请求时的时间
%r First line of request，即表示请求报文的首行；记录了此次请求的“方法”，“URL”以及协议版本
%>s 响应状态码
%b 响应报文的大小，单位是字节；不包括响应报文http首部
%{Referer}i 请求报文中首部“referer”的值；即从哪个页面中的超链接跳转至当前页面的
%{User-Agent}i 请求报文中首部“User-Agent”的值；即发出请求的应用程序
4、定义路径别名
格式：Alias /URL/ "/PATH
DocumentRoot "/www/htdocs" 网站根目录为/www/htdocs
访问http://www.magedu.com/download/bash.rpm相当于访问网站根目录下的/download/bash.rpm，即/www/htdocs/download/bash.rpm
Alias /download/ "/rpms/pub/"URL路径起始位置下的/download/（即网站根目录下的/download/）是服务器文件系统根目录下的/rpms/pub/的别名，
即访问http://www.magedu.com/download/bash.rpm相当于访问服务器文件系统根目录下/rpms/pub/的bash.rpm，即/rpms/pub/bash.rpm/bash.rpm
5、基于用户的访问控制
认证质询：响应码为401，拒绝客户端请求，并说明要求客户端提供账号和密码
认证方式两种：basic、digest
安全域：需要用户认证后方能访问的路径；应该通过名称对其进行标识，以便于告知用户认证的原因
用户的账号和密码
虚拟账号：仅用于访问某服务时用到的认证标识
basic认证配置示例：
(1) 定义安全域
<Directory “/path">
Options None
AllowOverride None
AuthType Basic
AuthName "String“
AuthUserFile "/PATH/HTTPD_USER_PASSWD_FILE"
Require user username1 username2 ...
</Directory>
允许账号文件中的所有用户登录访问：
Require valid-user
(2) 提供账号和密码存储（文本文件）
使用专用命令完成此类文件的创建及用户管理
htpasswd[options] /PATH/HTTPD_PASSWD_FILE username
-c：自动创建文件，仅应该在文件不存在时使用
-m：md5格式加密
-s: sha格式加密
-D：删除指定用户
创建隐私目录
创建虚拟账户文件，文件路径任意指定，创建用户账号hehe并将用户加入该文件
因为要创建虚拟账户文件需要加-c
默认用md5加密
创建用户账号haha
<Directory “/path">指定目录
AuthType 指定验证类型
AuthName 指定提示字符串
AuthUserFile 指定虚拟账号文件的路径
Require user 从虚拟账号文件选取几个用户
即对于/app/website1/secret目录，仅允许hehe、haha用户访问
httpd -t检查语法错误
6、虚拟主机
站点标识：socket
IP相同，但端口不同
IP不同，但端口均为默认端口
FQDN不同；
请求报文中首部
Host: www.magedu.com
有三种实现方案：
基于ip：为每个虚拟主机准备至少一个ip地址
基于port：为每个虚拟主机使用至少一个独立的port
基于FQDN：为每个虚拟主机使用至少一个FQDN
注意：一般虚拟机不要与main主机混用；因此，要使用虚拟主机，一般先禁用main主机
禁用方法：注释中心主机的DocumentRoot指令即可
虚拟主机的配置方法：
<VirtualHostIP:PORT>
ServerNameFQDN
DocumentRoot“/path"
</VirtualHost>
建议：上述配置存放在独立的配置文件中
其它可用指令：
ServerAlias：虚拟主机的别名；可多次使用
ErrorLog：错误日志
CustomLog：访问日志
<Directory “/path">
</Directory>
Alias
基于IP的虚拟主机示例：
<VirtualHost172.16.100.6:80>
ServerNamewww.a.com
DocumentRoot"/www/a.com/htdocs"
</VirtualHost>
<VirtualHost172.16.100.7:80>
ServerNamewww.b.net
DocumentRoot"/www/b.net/htdocs"
</VirtualHost>
<VirtualHost172.16.100.8:80>
ServerNamewww.c.org
DocumentRoot"/www/c.org/htdocs"
</VirtualHost>
建立三个虚拟主机主站点
为eth0添加3个ip
虚拟主机1（192.168.25.10，监听在80端口）的网站根目录/app/website1，访问http://192.168.25.10时应显示/app/website1/index.html
虚拟主机2（192.168.25.20，监听在80端口）的网站根目录/app/website2，访问http://192.168.25.20时应显示/app/website2/index.html
虚拟主机3（192.168.25.30，监听在80端口）的网站根目录/app/website3，访问http://192.168.25.30时应显示/app/website3/index.html
httpd已经监听在本机所有ip的80端口
main主机（192.168.25.106）的网站根目录/app/website1，访问http://192.168.25.106时应显示/app/website1/index.html
基于端口的虚拟主机
可和基于IP的虚拟主机混和使用
listen 808
listen 8080
<VirtualHost172.16.100.6:80>
ServerNamewww.a.com
DocumentRoot"/www/a.com/htdocs"
</VirtualHost>
<VirtualHost172.16.100.6:808>
ServerNamewww.b.net
DocumentRoot"/www/b.net/htdocs"
</VirtualHost>
<VirtualHost172.16.100.6:8080>
ServerNamewww.c.org
DocumentRoot"/www/c.org/htdocs"
</VirtualHost>
虚拟主机1（192.168.25.10，监听在81端口）的网站根目录/app/website1，访问http://192.168.25.10/81时应显示/app/website1/index.html
虚拟主机2（192.168.25.10，监听在82端口）的网站根目录/app/website2，访问http://192.168.25.10/82时应显示/app/website2/index.html
虚拟主机3（192.168.25.10，监听在83端口）的网站根目录/app/website3，访问http://192.168.25.10/83时应显示/app/website3/index.html
基于FQDN的虚拟主机：
NameVirtualHost*:80 httpd2.4不需要此指令
<VirtualHost*:80>
ServerNamewww.a.com
DocumentRoot"/www/a.com/htdocs"
</VirtualHost>
<VirtualHost*:80>
ServerNamewww.b.net
DocumentRoot"/www/b.net/htdocs"
</VirtualHost>
<VirtualHost*:80>
ServerNamewww.c.org
DocumentRoot"/www/c.org/htdocs"
</VirtualHost>
虚拟主机1（www.a.com，监听所有ip的80端口）的网站根目录/app/website1，访问http://www.a.com时应显示/app/website1/index.html
虚拟主机2（www.b.net，监听所有ip的80端口）的网站根目录/app/website2，访问http://www.b.net时应显示/app/website2/index.html
虚拟主机3（www.c.org，监听所有ip的80端口）的网站根目录/app/website3，访问http://www.c.org时应显示/app/website3/index.html
安装dns服务软件
启动dns服务
dns服务已监听在本机所有ip的53端口，向192.168.25.0/24、172.18.0.1/16网段和本机所有ip的主机提供查询服务
建立a.com、b.net、c.org域
a.com域的DNS服务器是192.168.25.107
www.a.com主机的ip为192.168.25.106
b.net域的DNS服务器是192.168.25.107
www.b.net主机的ip为192.168.25.106
c.org域的DNS服务器是192.168.25.107
www.c.org主机的ip为192.168.25.106
192.168.25.107本机测试dns服务器解析成功
客户端已经将DNS服务器指向192.168.25.107
客户端（192.168.25.108）curl www.a.com时，首先将请求发往自己的DNS服务器（192.168.25.107），192.168.25.107将www.a.com解析为192.168.25.106，即服务器ip为192.168.25.106，但是
客户端在curl www.b.net时，DNS服务器（192.168.25.107）也将.www.b.net解析为192.168.25.106
客户端在curl www.c.org时，DNS服务器（192.168.25.107）也将www.c.org解析为192.168.25.106
即三个域名都指向同一台web服务器192.168.25.106，在web服务器192.168.25.106上有三个网站，192.168.25.106怎么知道客户端要访问哪一个网站呢？
客户端（192.168.25.108）在得知web服务器的ip后，就向web服务器发送请求报文，在请求报文头部加上要访问的网站的主机名Host： www.a.com，服务器收到请求报文后，分析报文头部，并与本机网站的虚拟主机名对比，即将相应网站的页面返回给客户端
本文出自 “运维” 博客，请务必保留此出处http://fightingg.blog.51cto.com/13311108/1970805
标签：httpd
原文地址：http://fightingg.blog.51cto.com/13311108/1970805
