官方文档 1.4 下载地址: http://cbonte.github.io/haproxy-dconv/configuration-1.4.html
本节讲解第一章
1. 快速掌握HTTP
当haproxy运行在HTTP模式下，请求体和响应体都会被完全分析，因此，
我们可以创建匹配规则（基本上可以针对在内容中出现的任何事情）。
尽管如此，我们需要先了解HTTP的请求和响应是如此组织的，并且要知道
HAProxy是如何分解它们的。然后才可以比较容易的写出正确的规则以及调试
已有的配置项。
1.1. HTTP的交互模型
HTTP协议是交互驱动的，这也就意味着每个请求将导致一个且只有一个响应。传统意义上，
一个TCP连接建立（C/S），一个请求由client发送，服务器响应，连接关闭。
一个新的请求将如下所示：
[CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...
在这种模式下，叫做HTTP关闭模式，有多少个HTTP交互就有多少个连接（短连接），
一旦连接被关闭（服务器发送完了请求），客户端不需要知道内容长度。
考虑到协议的交互本质，就可以改进它来避免在2个连续的交互中关闭一个连接，
在这种模式下，尽管如此，服务器需要强制针对每个响应告诉响应的长度，这样客户端
不需要无限制的等待，因此，一个特别的header-"Content-length"被使用，这种模式
称为保活模式
[CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...
这种方式的优势在于：减少交互周期，服务器端更少的处理消耗，总的来说比关闭模式更佳。
但是也不总是更好，因为客户端经常限制它们的并发连接数为一个较小的值。
还有一个改进就是管道模式：仍然使用保活模式，但是客户端不等待第一个响应体到来就
发送第二个响应体，这个对于获取大量图片是很有用的，如下所示：
[CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...
这个对于效率有很大的提升，因为网络延迟在连续的请求中被消除，一些HTTP代理部能正确的支持管道
模式，这是因为HTTP协议中无法将一个响应体与对应的请求体关联起来，因此，服务器要强制按照同样的
顺序将响应体返回。
默认的，HAProxy运行在一个类管道模式下（持久链接），对于每一个连接，处理第一个请求和
发送其它所有的（包括额外的请求）给选定的服务器，一旦建立连接，连接就在CS两端持久化。
使用 "option http-server-close" 可以持久化客户端的持久连接，这样就是在HTTP关闭模式下，
处理每一个进来的请求（一个接一个的转发给服务器）。
使用 "option httpclose"来切换两端到HTTP关闭模式。
"option forceclose" 和 "option http-pretend-keepalive"可以在HTTP关闭模式下
帮助解决服务器行为不端的问题。
1.2. HTTP 请求体
首先，让我们考虑HTTP请求，
1 GET /serv/login.php?lang=en&profile=2 HTTP/1.1
2 Host: www.mydomain.com
3 User-agent: my small browser
4 Accept: image/jpeg, image/gif
5 Accept: image/png
1.2.1. 请求行
第一行是请求行，总是包括3个域。
- 方法 : GET
- URI : /serv/login.php?lang=en&profile=2
- 版本号 : HTTP/1.1
这3个由LWS限定，通常是空格符，也可以是制表符或者其它。方法本身不能包含“：“，
并且限制为正常字符，所有这些规则使得HAProxy执行提取操作而不是交给用户写一个
复杂的或者不准确的正则表达式。
URI可以有多种形式:
相对URI
/serv/login.php?lang=en&profile=2
也就是完全URL去掉了host部分，会被服务器，反向代理和透明代理收到。
绝对URL
http://192.168.0.12:8080/serv/login.php?lang=en&profile=2
包含：scheme(http),主机名或者地址，端口号，相对URI，代理会收到这些，但是支持
HTTP/1.1的服务器必须接受这种形式。
- 星号 ('*') :这种形式仅仅OPTIONS方法且不是中继时接受，用来查询下一跳的能力。
- 地址+端口: 192.168.0.12:80
用于CONNECT方法，用来通过HTTP代理建立TCP隧道，一般用于HTTPS,有时为其它协议服务。
在相对URI中，有2个子部分，？之前的称作path,典型的，它是服务器上的某个相对路径。
？之后的是查询字符串，基本上用于GET请求。
1.2.2. 请求头
头部出现在第二行，行开始是名字，然后是：，一般来说，：之后有一个LWS,但是不是必要的，
然后后面是值，多个headers可以放到同一行，用逗号隔开值，前提是顺序约定好了，
通常在"Cookie:"会碰到。
一个头可以有多行，比如：
Accept: image/jpeg, image/gif
Accept: image/png
头部的名字不区分大小写，值也不是。
头部的结束由第一个空行决定，人们通常说双行，也不完全是这样
只不过双行是一种有效形式的空行。
幸运的，HAProxy在检查值，检索头部，计数时考虑到各种复杂的组合。
所以不用担心具体的形式，但是尽量不要引起bug.
小贴士：
1.3. HTTP 响应体
一个HTTP响应看起来很像一个HTTP请求体，都称为HTTP报文，如下：
messages. Let's consider this HTTP response :
1 HTTP/1.1 200 OK
2 Content-length: 350
3 Content-Type: text/html
作为特殊情形，HTTP支持消息响应作为身份码1XX.
这些消息的特殊在于：它们不传递任何响应，只用来作为一种信号来告诉client继续
发送请求。
比如100响应码，表明请求的消息将被吓一个非100的响应体携带。
也就意味着一个请求体会导致多个响应体。这个仅仅工作在保活模式下。
(1xx messages are HTTP/1.1 only).
HAProxy 处理这些消息，并且可以正确的转发或者忽略它们。仅处理下一个非100响应。
这些消息既不会被logged,也不是处理，除非显式要求。
101码表明：协议正在同一个连接里改变，haproxy必须切换到tunnel模式（就仿佛CONNECT发生了），
然后Upgrade头会包含额外的信息指明连接正在切换到的协议类型。
1.3.1. 响应体的行
第一行是响应行，包含3个部分。
- 版本号: HTTP/1.1
- 状态码: 200
- 原因: OK
状态码一般是3位数，第一个数字表明总的身份
- 1xx = 信息类的报文，要忽略 (eg: 100, 101)
- 2xx = OK,后面是正文 (eg: 200, 206)
- 3xx = OK,后续无内容 (eg: 302, 304)
- 4xx = 客户端引起的问题 (eg: 401, 403, 404)
- 5xx = 服务端引起的错误(eg: 500, 502, 503)
请参考RFC2616获取这些代码的具体意义。
“reason”字段只是一个提示，不会被客户端解析。这里可以找到任何内容，XXX
可以由一个或者多个单词组成，比如"OK", "Found",or "Authentication Required".
Haproxy将会发送下列的状态码：
Code When / reason
200 访问统计网页（响应监控请求）
301 执行一个重定向（依赖于配置的代码）
302 执行重定向（依赖于配置的代码）
303 执行重定向（依赖于配置的代码）
307 执行重定向（依赖于配置的代码）
308 执行重定向（依赖于配置的代码）
400 一个无效或者太大的请求
401 访问统计页面，且需要身份认证时。
403 一个请求被组织（by a "block" ACL or "reqdeny" filter）
408 当请求未完整，超时了
500 当haproxy遭遇一个不可恢复的内部错误，比如内存分配失败。
502 服务器返回一个空的，无效的或者不完整的响应，或者当一个"rspdeny"过滤器组织响应体。
503 当没有服务器可用来处理请求，或者监控请求的响应体匹配"monitor fail"条件。
504 当响应体超时。
1.3.2. 响应头
响应头就如请求头，HAProxy使用同样的解析函数，请参考图1.2.2获取更多。
|
| 翻译 | 理解 |
| 1 | ok | ok |
| 2 | ok | ok |
9768
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
