http协议

发表于 | 更新于: | 分类于 ，
字数统计: 2.8k | 阅读时长 ≈ 10

HTTP协议

1. 简介

1.1 超文本传输协议

(Hypertext transfer protocol)
Markdown
规定了浏览器和万维网(WWW = World Wide Web)服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。
HTTP协议位于TCP/IP模型中应用层的协议。通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这个时候，就成了我们常说的HTTPS
HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个==无状态==的协议。
HTTP默认的端口号为==80==，HTTPS的端口号为==443==

1.2 特点

  • 简单快速：客户向服务器请求服务时，只需传送==请求方法和路径==。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
  • 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
  • HTTP 0.9和1.0使用非持续连接：限制==每次连接只处理一个请求==，服务器处理完客户的请求，并收到客户的应答后，即断开连接。HTTP1.1使用持续连接：不必为每个web对象创建一个新的连接，一个连接可以传送多个对象，采用这种方式可以节省传输时间。
  • 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
  • 支持B/S及C/S模式。

2. 请求

2.1 组成

  • 请求行
    请求行是请求消息的第一行，由三部分组成：
    请求方法（GET/POST/DELETE/PUT/HEAD/…）、请求资源的URI路径、HTTP的版本号
  • 请求头
    请求头中的信息有和缓存相关的头（Cache-Control，If-Modified-Since）、客户端身份信息（User-Agent）
    等等
  • 请求体
    请求体是客户端发给服务端的请求数据，这部分数据并不是每个请求必须的。
    根据HTTP标准，HTTP请求可以使用多种请求方法

2.2 请求方法

HTTP1.0定义了三种请求方法：GET,POST和HEAD方法。
HTTP1.1新增了五种请求方法：OPTIONS,PUT,DELETE,TRACE,CONNECT方法。

2.21 GET

  • 格式
    <访问路径>[?=[&=….]]
    例子：http://site1.com/get.php?arg1=value1
  • GET请求，是可以把数据放在URL中来传递，也==可以不包含任何数据==，HTTP请求只有请求头，没有请求数据。
  • GET请求可以只有请求的路径：
    http://www.gooann.com

    2.22 POST

  • 格式
    • 表单格式：application/x-www-form-urlencoded
    • 混合格式：multipart/form-data
    • JSON格式：application/json
    • XML格式：text/xml
    • 文本：text/plain
  • POST方式也可以像GET方式在URL带参数，但一般==不会==这么去使用。
    表单方式与GET方式类似，只是把数据放在头文件下面的请求正文区域。
  • POST请求可能会导致新的资源的建立和/或已有资源的修改

2.23 HEAD

  • HEAD请求就是返回只有头部数据，数据部分不返回内容
    返回的内容基本上与GET，POST的返回头一致

    2.24其他

  • PUT
    从客户端向服务器传送的数据取代指定的文档的内容
  • DELETE
    求服务器删除指定的页面
  • CONNECT
    HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
  • OPTIONS
    客户端询问服务器可以提交哪些请求方法

3. 状态码

  • 作用
    Web服务器用来告诉客户端，发生了什么事。
  • 状态代码由三位数字组成，第一个数字定义了响应的类别，共分五种类别:
    • 1xx：指示信息
      表示请求已接收，继续处理
    • 2xx：成功
      表示请求已被成功接收、理解、接受
    • 3xx：重定向
      要完成请求必须进行更进一步的操作
    • 4xx：客户端错误
      请求有语法错误或请求无法实现
    • 5xx：服务器端错误
      服务器未能实现合法的请求
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
常见状态码
200 OK
客户端请求成功
301/302 Moved Permanently（重定向）
请求的URL已移走。Response中应该包含一个Location URL, 说明资源现在所处的位置
304 Not Modified（未修改）
客户的缓存资源是最新的， 要客户端使用缓存
400 Bad Request
客户端请求有语法错误，不能被服务器理解
401 Unauthorized
请求未经授权，该状态码和WWW-Authenticate报头域一起使用
403 Forbidden
服务器收到请求，但拒绝提供服务
404 Not Found
请求资源不存在
501 Internal Server Error服务器遇到一个错误，使其无法对请求提供服务

4. 响应

4.1 组成

  • 状态行
    状态行位于相应消息的第一行，有HTTP协议版本号，状态码和状态说明三部分构成响应头
  • 响应头
    服务器传递给客户端用于说明服务器的一些信息，以及将来继续访问该资源时的策略响应体
  • 响应体
    服务端返回给客户端的HTML文本内容，或者其他格式的数据，比如：视频流、图片或者音频数据。
1
2
3
4
5
6
7
8
9
10
11
12
13
常用标准响应头字段
Access：服务器支持哪些请求方法（如GET、POST等）。
Content-Encoding：文档的编码（Encode）方法。
Content-Length：表示内容长度。
Content-Type：表示后面的文档属于什么MIME类型。
Date：当前的GMT时间。
Expires：应该在什么时候认为文档已经过期，从而不再缓存它
Last-Modified：文档的最后改动时间。
Location：表示客户应当到哪里去提取文档。
Refresh：表示浏览器应该在多少时间之后刷新文档，以秒计。
Server：服务器名字。
Set-Cookie：设置和页面关联的Cookie。
WWW-Authenticate：标识访问请求实体的身份验证方案

5. URL

  • URL(统一资源定位符)即在浏览器的地址栏中输入的网址。它为描述Internet上的网页及其他资源地址提供了一种标识方法。==Internet上的每个网页都有一个唯一的名称标识==，该标识被称为URL地址。
  • 组成
    协议类型、主机名和路径及文件名。
  • 格式
    协议://用户名:密码@子域名.域名.顶级域名:端口号/目录/文件名.文件后缀?参数=值#标志
  • 编码格式
    只有字母和数字[0-9,a-z,A-Z]、一些特殊符号“$-_.+!*‘(),”[不包括双引号]、以及某些保留字，才可以不经过编码直接用于URL。
  • ==同源策略==
    URL格式中，协议，主机，端口三部分相同，才能算是同源。
    浏览器设置里，默认情况下只有同源的内容才能相互操作。

6. web应用如何处理用户请求

  1. 客户机与服务器需要建立连接
  2. 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URI）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
  3. 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
  4. 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。
  5. 如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端

7. 身份认证

7.1 BASIC 认证

  • 流程
  1. 当客户端请求的资源需要 BASIC 认证，服务器会随状态码 401 Authorization Required，返回带 WWW-Authenticate 首部字段的响应；
  2. 客户端接收到 401 状态码后，为了通过认证，需要将用户 ID 及密码发给服务器。发送的内容是由用户 ID 和密码构成，两者中间以 : 连接后，再经过 Base64 编码处理；
  3. 接收到包含首部字段 Authorization 请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含 Request-URI 资源的响应。
  • 缺点
    Base64 编码方式不是一种加密处理，攻击者不需要借助什么就可以对其解码；
    一般浏览器无法实现 BASIC 认证注销操作。

    7.2 DIGEST 认证

  • 流程
  1. 客户端请求需认证的资源时，会向服务器发送认证请求，服务器会随状态码 401，返回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码（随机数，nonce）。
  2. 客户端接收到 401 状态码后，返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息(首部字段 Authorization 内必须包含 username、realm、nonce、uri 和 response 的字段信息。
  3. 服务器接收到包含首部字段 Authorization 请求后，会确认认证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。
  • 缺点
    DIGEST 认证提供了高于BASIC 认证安全等级，不过和后者一样使用上不便捷灵活，同时DIGEST 认证提供防止密码被窃听的保护机制，但不能防止用户伪装，仍达不到多数 Web 网站对安全要求，所以适用范围仍然有限。

    7.3 SSL 客户端认证

  • 流程
  1. 服务器在接收到客户端需要认证资源的请求后，会发送 Certificate Request 报文（要求客户端提供客户端证书）；
  2. 用户选择将发送的客户端证书后，客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器；
  3. 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始 HTTPS 加密通信。

    7.4 基于表单认证

    鉴于HTTP是无状态协议，之前认证成功的用户状态无法通过协议层面保存下来（无法实现状态管理）。即使该用户下一次继续访问，也无法将他与其他用户区分开来。因此基于表单的认证一般会使用Cookie来管理Session会话。来解决HTTP协议的状态管理问题。

由于便利性和安全性问题，HTTP 协议标准提供的 BASIC 认证和 DIGEST 认证几乎不怎么使用，另外 SSL 客户端认证，因为导入及维持费用尚未普及。