标签：http
关于HTTP更详细的说明：
HTTP使用URI定位互联网中的资源：
URI和URL：
URI(统一资源标识符),URL(统一资源定位符)。
URL就是web浏览器访问Web页面时需要输入的网页地址。
URI是某个协议方案表示的资源的定位标识符，协议方案是指访问资源所使用的协议类型名称，采用HTTP协议时，协议方案就是http，除此之外，还有ftp、telnet、file等，标准的有30多个
几个URI的例子：
|
ftp://ftp.is.co.za/rfc/rfc1808.txt |
|
http://ftp.is.co.za/rfc/rfc1808.txt |
|
ldap://[2001:db8::7]/c=GB?objectClass?one |
|
mailto:John.Doe@examople.com |
|
tel:+1-816-555-1212 |
|
telnet://192.0.2.16:80/ |
URI格式：
表示指定URI，要使用涵盖全部必要信息的绝对URI、绝对URL、以及相对URL
绝对URL的格式：
http://user:pass@www.example.com:80/dir/index.htm?uid=#ch1
|
http:// |
协议方案名 |
|
|
user |
登录信息（认证） |
指定用户名密码作为必要登陆信息（身份认证）（可选项） |
|
www.example.com |
服务器地址 |
可是域名，ipv4,ipv6（形如[0:0:0:0:0:0:0:1] |
|
80 |
服务器端口号 |
省略则使用默认端口号 |
|
/dir/index.htm |
带层次的文件路径 |
指定服务器上的文件路径来定位特指的资源 |
|
uid=1 |
查询字符串 |
针对已指定的文件路径内的资源，可以使用查询字符串传入任意参数（可选） |
|
ch1 |
片段标识符 |
使用片段标识符通常可标记出已获取资源中的子资源(文档内的某个位置)，RFC没有明确规定使用方式，可选 |
简单的HTTP：
HTTP协议用于客户端和服务器端之间的通信
通过请求和响应的交换达成通信
HTTP是不保存状态的协议
即协议本身不记录之前一切的请求或响应报文的信息
使用URI定位互联网上的资源
指定请求URI的方式很多
URI为完整的请求URI
在首部字段Host中写明网络域名或IP地址
除此之外，不访问特定资源，而是对服务器本身发起请求，可用一个*代替请求URI
告知服务器意图的HTTP方法
自身不带安全验证机制，任何人都可以上传文件，存在安全性问题若配合Web应用程序的验证机制，或架构设计采用REST标准的同类Web网站，就可能开放使用PUT方法
例子：
|
请求 |
PUT /example.html HTTP/1.1 Host:www.hackr.jp Content-Type:text/html Content-Length:1560 |
|
响应 |
204 No Content(比如:该html已存在于服务器上) |
如果请求的资源是文本，那就保持原样返回，如果像是CGI那样的程序则返回执行后的结果
GET:获取资源 POST：传输实体主体 PUT：传输文件 HEAD：获得报文首部 和GET方法一样，但不是返回报文主体部分，用于确认URI的有效性及资源更性的日期时间等 DELETE：删除文件 DELETE和PUT相反，用于删除文件，也不安全 OPTIONS：查询支持的方法 用来查询针对请求URI指定的资源支持的方法 例子：|
请求 |
OPTION * HTTP/1.1 Host:www.hackr.jp |
|
响应 |
HTTP/1.1 200 OK Allow: GET,POST,HEAD.OPTIONS |
TRACE:追踪路径
TRACE方法是让Web服务器端将之前的请求通信环回给客户端的方法
客户端使用TRACE方法可以查询发送出去的请求是怎样被加工修改/篡改的，这是因为，请求想要连接到目标服务器可能会通过代理中转，TRACE方法就是用来确认连接过程中发生的一系列操作
CONNECT：要求用隧道协议连接代理
使用方法下达命令
持久连接节省通信量
HTTP协议初始版本中，每进行一次HTTP通信就断开一次TCP连接
HTTP/1.1和一部分HTTP/1.0使用持久连接 管线化 从前发送请求后需等待并收到响应才能发送下一个请求。管线化技术出现后，不用等待响应亦可直接发送下一个请求 使用Cookie的状态管理HTTP本身是无状态的
Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端状态
Cookie会根据从服务端发来的响应报文内的一个叫做Set-Cookie的首部字段信息，通知客户端保存Cookie。当下次客户端再往该服务器发送请求时，客户端会自动在请求报文中加入Cookie值后发送出去。
服务器端会发现客户端发送过来的Cookie后，会对比服务器上的记录，最后得到之前的状态信息。
HTTP报文内的HTTP信息
HTTP报文
HTTP报文本身是由多行（用CR+LF作换行符）数据构成的字符串文本。
HTTP报文大致可分为报文首部和报文主体两块，最初由空行（CR+LF）来划分，通常，并不一定要有报文主体
报文结构：
|
报文首部 |
|
空行(CR+LF) |
|
报文主体 |
报文首部格式：
请求报文首部 响应报文首部
|
请求行 |
状态行 |
|
请求首部字段 |
响应首部字段 |
|
通用首部字段 |
通用首部字段 |
|
实体首部字段 |
实体首部字段 |
|
其他 |
其他 |
请求行：包含请求的方法，请求URI，HTTP版本
状态行：包含表明响应结果的状态码，原因短语，HTTP版本
首部字段：包含表示请求和响应的各种条件和属性的各类首部
其它：可能包含HTTP的RFC里未定义的首部（如Cookie等）
HTTP首部详细信息：
首部字段结构
首部字段名：字段值
例：Content-Type：text/html
字段可以有多个值：Keep-Alive：timeout=15,max=100
重要字段
Host，唯一一个必须要有的请求字段，如果主机IP相同，需要host字段加以区分
User-Agent，传递浏览器的种类
为Cookie服务的首部字段：
Set-Cookie（响应报文）
字段属性：
|
NAME=VALUE |
赋予Cookie的名称和其值（必须项） |
|
expires=DATA |
Cookie的有效期，默认值以浏览器关闭为止 |
|
path=PATH |
将服务器上的文档目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录） |
|
domain=域名 |
作为Cookie适用对象的域名（若不指定则默认为创建Cookie的服务器的域名） |
|
Secure |
仅在HTTPS安全通信时才会发送Cookie |
|
HttpOnly |
加以限制，使用Cookie不能被JavaScript脚本访问 |
其它首部字段：
X-Frame-Options
用于控制网站内容在其他Web网站的Frame标签内的显示问题主要防止点击劫持
DENY：拒绝
SAMEORIGN：仅在同源页面上（表示该域名上的所有页面fram都可以加载该页面）
X-XSS-Protection
用于控制浏览器XSS防护机制的开关
DNT
Do Not Track
0：同意被追踪
1：拒绝被追踪
finally:
本文出自http://qianyang.blog.51cto.com/，转载请务必注明出处
标签：http
原文地址：http://qianyang.blog.51cto.com/7130735/1614902
