HTTP协议一览

HTTP协议并不是对等的,需要客户端和服务端,通过请求和响应模型实现。

请求报文的结构

  1. 请求方法
  2. 请求的URI
  3. 协议版本
  4. 可选的请求首部字段
  5. 内容实体

响应报文的结构

  1. 协议版本
  2. 状态码
  3. 解释状态码的原因短语
  4. 可选的响应首部字段
  5. 主体

HTTP是无状态协议

对HTTP来说,每个请求响应都是独立的,不关心请求之间的联系。
HTTP是通过Cookie技术来保存用户状态的。

Cookie

服务器通过Set-Cookie首部字段信息设置一个Cookie值,(服务器自己也会保存这个值)通知客户端要保存这个Cookie值,客户端在下次请求时自动在请求头中加入Cookie值后发送。服务器对比这个Cookie就知道这个那个用户发来的请求了。

方法种类

http 1.0 1.1 都支持的:

  1. GET
  2. POST
  3. PUT
  4. DELETE
  5. HEAD:获取报文头

http1.1新增的:

  1. OPTIONS:查询服务器支持的方法种类, OPTIONS * HTTP/1.1
  2. TRACE:追踪路径,会引发跨站追踪CST攻击,一般不使用。
  3. CONNECT:要求使用隧道协议连接代理

仅http1.0支持,也就是被http/1.1淘汰了:

  1. LINK
  2. UNLINK

长连接 keep-alive

又叫持久连接,好处是减少了TCP连接和断开的次数。
在http/1.1中默认是长连接了

管线化 pipelining

管线化,就是同时发送多个请求。相当于一个连接中的串行请求响应,变成并行的。

HTTP报文结构

  • 报文首部
  • 空行
  • 报文主体

其中请求报文首部又分为

  • 请求行:方法、URI、HTTP版本
  • 请求首部
  • 通用首部
  • 实体首部

响应报文首部又包含:

  • 状态行:状态码、原因短语、版本
  • 响应首部
  • 通用首部
  • 实体手部

内容编码

压缩传输
gzip
compress
deflate
identity(不进行编码)

分块传输编码

Chunked Transfer Coding

多部分对象集合

multipart/form-data
multipart/byterabge
boundary=xxx
可以套嵌使用

范围请求

断点重连
Range: bytes=5001-10000

内容协商

Accept
Accept-Charset
Accept-Encoding
Accept-Language
Content-Language

服务器驱动协商
客户端驱动协商
透明协商

状态码

RFC2616定义的状态码40种,WebDAV 扩展了一些状态码
WebDAV(Web-based Distributed Authoring and Versioning, 基于万维网的分布式创作和版本控制),相当于http/1.1的增强版,主要用于操作文件,比如网盘场景。

1xx 信息类,表示正在处理中
2xx 成功
  • 200 成功
  • 204 No content : 没有内容。不会返回任何实体的主体,浏览器的页面不会发生更新。
  • 206 Partial Content : 部分内容。用于范围请求
3xx 重定向
  • 301 Moved Permanently : 永久重定向。如果此页面收藏了标签的话,浏览器可能会自动把标签中的地址改为Location中的地址
  • 302 Found:临时重定向,可用于页面地址修改后的发布,如果地址写错了可以改过来,可以随时修改。如果用301,用户浏览器的标签可能会保存错误的地址,这时就不太好处理。
  • 303 See Other: 与302相似,但是明确要求客户端用Get方法
  • 304 Not Modified:与重定向无关。页面不会更新,而是使用浏览器中的缓存。一般会在条件请求的返回中出现。条件请求:If-Modified-Since,If-Unmodified-since, If_Range, If-Match, If-None-Match。
  • 307 Temperary Redirect:临时重定向,不会将请求方法改为GET。
4xx 客服端异常
  • 400 :请求的报文的语法错误
  • 401 Unauthorized:未授权,会同时返回 WWW-Authenticate,浏览器上会弹出认证框
  • 403 Forbidden:拒绝访问
  • 404 Not Found :资源没找到
5xx 服务端异常
  • 500 Internal Server Error : 服务器内部错误
  • 501 Service Unavailable : 服务不可用,一般指服务器过载

Web服务器

一个服务器应用部署多个不同域名的应用

一个服务器应用(如一个Tomcat)如何部署多个不同域名的web站点吗,并且端口都是默认端口?
首先DNS肯定要为主机IP绑定两个域名,
当请求进入Tomcat中后如何区分这两个域名呢?通过请求头Host字段的域名来区分,Tomcat的server.xml的<Host>标签需要配置

<Host name="www.111.com"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Context path="" docBase="onefolder" debug="0" reloadable="true" />     
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
</Host>

<Host name="www.222.com"  appBase="webapps" unpackWARs="true" autoDeploy="true">
    <Context path="" docBase="twofolder" debug="0" reloadable="true" />
    <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" prefix="localhost_access_log." suffix=".txt" pattern="%h %l %u %t "%r" %s %b" />
</Host>

通信数据转发程序

代理

代理:接收请求后转发给其他服务器(不改变请求的URI?

  • 缓存代理
  • 透明代理、非透明代理
网关

网关:与代理的功能很相似,也是转发请求。主要区别是网关可以改变请求的URI,使用非http协议请求后续的服务器

隧道

隧道:在请求端与远距离的服务器建立安全的传输通道。

确认访问用户身份的认证

可以通过哪些特征证明自己呢?

  • 我知道密码
  • 我有动态令牌
  • 我有数字证书
  • 我的生物特征认证,人脸、指纹、虹膜
  • 我提供我的身份证,或其他证件

HTTP使用的认证方式

  • BASIC认证
  • DIGEST认证
  • SSL客户端认证
  • FormBase认证

Windows的统一认证:Kerberos认证、NTLM认证

BASIC认证

原理:

  1. 客户端发送请求
  2. 服务端返回 401 Unauthorized; 并附带WWW-Authenticate: Basic realm="请输入用户名和密码"
  3. 客户端会弹出认证框让用户输入用户名和密码,输入把user:pass进行Base64编码XXX,放到请求头Authorization: Basric XXX,发送给服务端。
  4. 服务端进行反编码后验证用户名密码,如果验证通过返回200,如果验证失败返回401。

缺点:
用户密码是明文传输,极不安全。

DIGEST认证

原理:不直接传输用户名密码,而是做散列之后进行传输。

  1. 客户端发送请求
  2. 发出质询:服务器返回401,响应头WWW-Authenticate: Digest realm="DIGEST", nonce="XXXXX=xxxx",algorithm=MD5, qop="auth"
  3. 客户端根据质询计算出响应码:Authorization: Digest realm="DIGEST" username="zhangsan", nonce="原nonce",uri="/digest", algorithm=MD5, response="xxxxx", nc=00000001, cnonce="xxxxx"
  4. 服务端进行验证,返回200或401,成功时返回认证信息Authentication-Info响应头。根据username来查到真实密码,然后进行相同的MD5过程,然后对比是否与请求中的相同来进行判断。

SSL客户端认证

需要客户端安装证书
原理:

  1. 客户端发请求
  2. 服务器除了会返回自己的证书外,还会发送Certificate Request报文,要求客户端提供证书
  3. 客户端发送Client Certificate报文
  4. 服务端验证通过后,拿到客户端的公钥,用客户端公钥加密响应信息

SSL客户端认证采用双因素认证:加上了表单认证

基于表单的认证

自实现的表单认证方式

Session管理

通过Cookie保存Session_Id, 注意要将此Cookie加上httponly 属性,防止跨站脚本攻击XSS。
Session_Id是与用户密码关联的。
用户密码的保存注意要salt+hash后保存,salt最好随机生成,这样可以保证相同密码的密文密码也是不同的,更难以破解。

HTTP的扩展

1.Ajax: 局部刷新

2.Comet的解决方法

通过延迟应答来模拟服务器推送的功能。
缺点是显而易见的,需要保持连接不断,会消耗更多的资源。

3.SPDY

Google在2010年发布了SPDY,旨在解决HTTP的性能瓶颈,缩短页面加载时间。那么,HTTP有哪些瓶颈呢?

  • 一条连接上只能发送一个请求
  • 请求只能从客户端开始,没法从服务器进行推送
  • 请求的首部太冗长,并且每次都发送相同的首部
SPDY的目标

修改HTTP协议本身!
SPDY没有完全改写HTTP,而是在HTTP和SSL之间加入了一层SPDY层,可以称为会话层。
主要的功能:

  1. 多路复用:用一条TCP连接并发处理多个HTTP请求。HTTP连接也是一个吧?
  2. 赋予请求优先级:在并发请求时,为每个请求分配优先级。
  3. 压缩HTTP首部
  4. 推送功能
  5. 服务器提示功能:主动提示客户端来请求所需的资源。
SPDY的问题

需要浏览器和Web服务器做出相应的调整。
SPDY只是将单个域名的通信进行了多路复用,当一个网站上使用多个域名下的资源时,改善效果会打折扣。

4.浏览器的全双工通信的WebSocket

WebSocket 是Web浏览器与Web服务器之间全双工通信标准。
WebSocket也是建立在HTTP基础上的协议,因此连接的发起方任然是客户端,一旦建立连接,就可以双向发送数据了!

特点:

  • 推送功能
  • 减少了通信量:首部信息很小

过程:
握手-请求:需要添加几个请求头。

  • Upgrade: websocket
  • Sec-WebSocket-Key: 健值
  • Sec-WebSocket-Protocol: 子协议

握手-响应:

  • 返回101 Switching Protocols 状态码
  • Upgrade: websocket
  • Sec-WebSocket-Accept: 由请求中的健值来生成。

通过HTTP建立WebSocket连接之后,不再使用HTTP的数据帧,而是使用WebSocket独立的数据帧!!格式:ws://xxx.com/xxx

WebSocket API
js可以调用此API。

var socket = new WebSocket('ws://example.com:8080/updates');
socket.onopen = function(){
    setInterval(function(){
        if(socket.bufferedAmount == 0){
            socket.send(getUpdateData());
        }
    });
}

5.HTTP/2.0

HTTP/2.0的特点
  • SPDY
  • HTTP Speed + MObility: 有微软公司起草,用于改善移动端通信速度和性能的标准,它建立在SPDY和WebSocket的基础之上
  • Network-Friendly HTTP Upgrade: 主要在移动端通信时改善HTTP的性能标准
  • 多路复用
  • TLS义务化
  • 协商
  • 客户端拉拽、服务端推送
  • 流量控制
  • WebSocket

6.Web服务器管理文件的WebDAV

WebDAV是基于万维网的分布式创作和版本控制,用于文件操作,比如网盘。
原理:扩展了HTTP/1.1
增加了一些概念:集合、资源、属性、锁
添加了一些方法Method,与GET/POST同级

  • LOCK
  • UNLOCK
  • MOVE
  • COPY
  • MKCOL
  • PROPPATCH
  • PROPFIND

扩展了一些状态码:

  • 102 Processing
  • 207 Multi-Status
  • 422 格式不正确
  • 423 Locked
  • 507 Insufficient Storage
阅读 255

推荐阅读