[TOC]
参考《图解HTTP》
HTTP发展及基础
HTTP历史
http于1990年问世那时的http并没有作为正式的标准被建立,现在的http其实含有http1.0版本之前的意思因此被称为0.9.http1.0作为标准被公开是在1996年5月,版本被命名为http/1.0，并记载与RFC1945,但该协议至今仍被广泛使用在服务器端，1997年1月公布的http/1.1是目前主流http协议版本当初的标准时RFC2068之后发布的修订版就是当前的最新版本
网络基础TCP/IP
通常使用的网络是在TCP/IP协议的基础上运行的而HTTP是属于他内部的一个子集
TCP/IP协议
计算机与网络设备之间相互通信双方必须基于相同的方法比如探测到通信目标由哪一边先发起通信,使用哪种语言进行通信,怎样结束通信等规则都需要约定好，不同的硬件操作系统之间的通信这一切都需要一种规则,而我们就把这种规则称为协议Protocol把互联网相关联的协议集合起来总成为TCP/IP
TCP/IP协议里最重要的就是分层：TCP/IP协议按层次分别分为以下五层 应用层、传输层、网络层、数据链层、物理层(OSI模型将应用层细分为 应用层、表示层、会话层**)
应用层：应用层决定了向用户提供应用服务时的通信活动,TCP协议预存了各类通用的应用服务,比如FTP和DNS就是其中两类,HTTP也是属于该层.
传输层: 传输层对上层应用层,提供处于网络连接中的两台计算机之间的数据传输,在传输中有两个性质不同的协议: TCP、UDP
网络层: 网络层用来处理在网络上流动的数据包，数据包是网络传输的最小数据单位,盖层规定了通过怎样的路径到达对方计算机并把数据发送给对方
数据链层: 处理链接网络硬件部分包括控制操作系统,硬件的设备驱动等
物理层: 实际最终信号的传输是通过物理层实现的。通过物理介质传输比特流。规定了电平、速度和电缆针脚。常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。这些都是物理层的传输介质。
| TCP/IP五层模型 | 实现协议 |
|---|---|
| 应用层 | HTTP Telnet FTP TFTP DNS SMTP |
| 传输层 | TCP UDP |
| 网络层 | IP ICMP RIP IGMP |
| 数据链层 | ARP RARP IEEE802.3 PPP CSMA/CD |
| 物理层 | FE自协商MLT-3 4A PAM5 |
该表参考：http://www.cnblogs.com/qishui/p/5428938.html
发送层在层与层之间传输数据时,每经过一层必定会被打上盖层所属的首部信息,在接受层与层传输时会把对应的首部去掉 这种把数据信息包装起来的方法称为封装(上层接口不接触下层逻辑)
IP协议: 按层次分IP网际协议位于网络层，IP协议的作用就是把各种数据包传送给对方，而要保证确实传送到哪里则需要满足各类条件，最终要的就是IP地址和MAC地址.IP地址指明了节点分配到的地址,MAC地址是指网卡所述的固定地址.IP地址与MAC地址进行配对，IP可变换但MAC地址基本不会更改
ARP协议: 在网络上通信双方位于同一局域网上的情况是很少的,通常在多肽计算机和网络设备中转才能连接到对方,而在进行中转时候会利用下一站的中转设备的MAC地址来搜索下一个中转目标,这时会采用ARP协议是解析地址的协议,根据同新方的IP地址可以查出MAC的地址
TCP协议: 按层分TCP提供可靠地字节流服务，通过三次握手建立连接四次挥手断开连接
DNS：和HTTP协议一样位于应用层的协议提供域名到IP地址之间的解析服务
URL和URI: Uniform Resource Location 和 Uniform Resource IDentifier
简单的HTTP协议
在应用HTTP协议时候,必定是一端担任客户端角色,另一端担任服务端角色。HTTP是不保存状态协议，每次当有新的请求发送时，就会有对应的新响应产生这是为了更快的处理大量食物,确保协议的可伸缩性，随着Web的发展无状态导致业务处理变得棘手所以推出了Cookie
请求方式
| 方法 | 说明 | http协议版本 |
|---|---|---|
| GET | 获取资源 | 1.0，1.1 |
| POST | 传输实体主体 | 1.0、1.1 |
| PUT | 传输文件 | 1.0、1.1 |
| HEAD | 获得报文首部 | 1.0、1.1 |
| DELETE | 删除文件 | 1.0、1.1 |
| OPTIONS | 询问服务器支持的方法 | 1.1 |
| TRACE | 追求路径 | 1.1 |
| CONNECT | 要求用隧道协议链接代理 | 1.1 |
| LINK | 建立和资源之间的参数 | 1.0 |
| UNLINE | 断开连接 | 1.0 |
持久链接节省通信量
http初始协议中每进行一次通信就需要断开一次TCP链接，以前因为容量很小，即使传输起来也没多大问题现在随着HTTP的普及文档中包含大量的图片的情况躲起来,比如使用浏览器浏览一个包含多个图片的html页面时，也会请求该HTML页面里包含的其他资源,因此每次请求都会造成无谓的TCP链接简历断开增加通信开销
Keeo-alive和connection reuse
http1.1退出了持久链接 keep-alive和connection 只要一端没明确提出断开连接则保持TCP连接状态,这样就可以同时并行发送多个请求,而不需要一个接一个的等待响应
CooKie
cookie技术通过请求和响应报文中写入cookie信息来控制客户端状态,cookie会在服务端发送的响应报文内的一个叫做Set-Cookie的首部字段信息通知客户端保存Cookie,当下次客户端在往该服务器发送请求那么客户端会自动在请求报文中加入Cookie值后发送出去,服务端收到客户端发来的cookie后会检查那个客户端发来的记录对比服务器上的记录最后得到之前的状态信息
HTTP状态
状态码的职责是当客户端向服务端发送请求的时候描述返回的请求结果借助状态码用户可以知道服务端是正常处理了请求还是出现了错误
状态码的类别
| 状态码 | 类别 | 原因短语 |
|---|---|---|
| 1xx | 信息性状态码 | 接受的请求正在处理 |
| 2xx | 成功状态码 | 请求正常处理完毕 |
| 3xx | 重定向 | 需要附加操作 |
| 4xx | 客户端错误状态码 | 服务端无法处理请求 |
| 5xx | 服务器错误状态码 | 服务器处理请求出错 |
HTTP首部
Content-Type：报文主题对象类型
Keep-Alive：设置保持连接时间
通用首部字段
cache-control：缓存机制
connection：控制不再转发给代理的首部字段 管理持久连接 keep-alive
date：报文创建的时间
pragma: 遗留字段 no-cache
Trailer: 记录记录了哪些首部字段
Transfer-Encoding：报文编码方式
upgrade: 检测是否可以使用更高版进行通讯
via: 追踪客户端与服务器之间的请求和响应报文的传输路径
warning 警告
| 警告码 | 警告内容 |
|---|---|
| 110 | 响应已过期 |
| 111 | 在验证失败 |
| 112 | 断开连接 |
| 113 | 试探性过期 |
| 299 | 任意警告 |
请求首部
| 字段 | 说明 |
|---|---|
| Accept | 用户代理能够处理的媒体类型以及媒体类型的相对优先级,可使用Type/subType这种形式一次指定多种媒体类型 |
| Accept-Charset | 通知服务器用户代理支持的字符集或相对优先顺序 |
| Accept-Encoding | gzip deflate 首部字段告知服务器用户代理的内容编码 |
| Accept-Language | 告知服务器用户代理能够处理的语言集 |
| Authorization | 认证信息服务器返回401后需要再次请求将认证信息加入到请求中。 |
| Expect | 客户端使用首部字段Expect来告诉服务器期望出现某种特定的行文,因为服务器无法理解客户端的期望做出回应而产生错误时会返回417，客户端可以利用该首部字段写明期望的扩展 |
| HOST | 资源所在处的互联网主机名和端口号 |
| if-xxx | 条件请求服务器收到附带条件时候只有条件为真时才会执行请求 |
| if-match | 判断属于html的etag值符合则执行请求否则则不执行 |
| if-modified-since | 字段值早于资源更新时间则希望能处理该请求 |
| if-none-match | 与if-match取值相反 |
| if-range | 附带条件告知服务器若指定if-range(Etag或者时间)和请求资源的Etag值或时间一致时则做范围请求处理,反之返回全体资源 |
| if-Unmodified-Since | 与if-modified-since取值相反 |
| max-forwards | 该字段以10进制整数形式可经过的服务器最大数目服务器在往下一个服务器转发请求之前max-forwards-1为0时，不再进行转发，而是直接返回响应 |
| proxy-authorization | 与Authorization一致 |
| Range | 范围请求告知服务器资源的指定范围 |
| referer | 只要查看referer就能知道uri是从哪个web页面发起的 |
| user-agent | 创建请求的浏览器和用户代理等信息发送给是服务器 |
响应首部
| 字段 | 说明 |
|---|---|
| Accept-Ranges | 告知客户端服务器是否能处理范围请求已制定获取服务端某个部分的资源，可处理范围请求时为bytes,反之为none |
| Age | 可以告知客户端源服务器在多久前创建了响应字段值为s秒 |
| ETag | html文件的etag值标识 强etag值(只要发生改变一点点就会改变)和弱etag值(只有自愿发生了根本改变产生差异时才会改变etag) |
| Location | 可以将响应接受方法引导至某个请求与uri位置不同的资源，浏览器会在收到包含location响应后尝试对已提示的重定向资源的访问 |
| proxy-Authenticate | 服务器会把需要的认证信息发给客户端 |
| retry-after | 告知客户端多长时间再发送请求配合状态码503 |
| server | 告知服务器当前服务器安装的http服务器应用程序信息 |
| vary | 对缓存进行控制 服务器收到带有vary首部字段指定获取资源请求时如果使用accept-lanaguage字段值相同那么就直接从缓存返回响应,反之则需要先从源服务器端获取资源后才能作为响应返回 |
| www-authenticate | 用于http访问认证他会告诉街护短适用于访问请求URI所指定资源的认证方案 |
HTTPS
http缺点
1.通信使用明文(不加密),内容可能会被窃取
2.不严重通信方的身份,因此可能遭遇伪装
3.无法验证报文完整性，有可能被篡改
HTTP + 加密 + 认证 + 完整报文 = https
https缺点
1.比较耗费性能，占用资源较多因此如果是非敏感信息采用HTTP通信，只有包含个人信息等敏感数据时才利用https加密通信
2.购买证书花钱
