HTTP协议一览

 阅读约 13 分钟

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
阅读 90发布于 11月14日
推荐阅读
目录