应用层HTTP服务

HTTP(0.9/ 1.0/ 1.1/ 2.0)

基础概念

• URI:
  
  

  
  



• 请求报文格式:
  
  

  
  



• 响应报文格式:
  
  

  
  

HTTP方法——请求报文第一行(请求行)

• GET: 获取资源

  
  



• HEAD: 只获取报文首部，不返回报文主体部分。主要用于确认 URL 的有效性以及资源更新的日期时间等。

  
  



• POST: 向服务器传输数据

  
  



• PUT: 上传文件，但没有验证机制，因此存在安全性问题一般不使用。

  
  



• PATCH: 对资源进行部分修改。PUT也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

  
  



• DELETE: 删除文件, 同样没有验证机制，与PUT相反

  
  



• OPTIONS: 查询指定URL支持的方法

  
  



• CONNECT: 要求与代理服务器通信时建立隧道，使用SSL、TLS协议将通信内容加密后传输。

  
  



• TRACE: 追踪路径，服务器将通信路径返回给客户端。类似于ICMP报文。

  
  

HTTP状态码(类别——含义)

3XX重定向(请求资源URI变动需要重新请求/ 请求资源条件不满足)

• 301—永久重定向


• 302/307—临时重定向


• 303—类似302


• 304—Not Modified(请求报文首部包含的诸如f-Match，If-Modified-Since等条件不满足)

4XX客户端请求出错

• 400—请求格式出错


• 401—权限验证失败


• 403—请求被拒绝


• 404—服务器找不到请求的资源

5XX服务器无法处理请求

• 500—服务器执行请求时出错


• 503—服务器超负载/停机维护，无法处理请求

HTTP首部(查阅即可)

• 通用首部字段


• 请求首部字段


• 响应首部字段


• 实体首部字段

具体应用

TCP连接管理(短连接/长连接(持久连接))

• 短连接(short-lived connections ) 一次请求建立一次TCP连接

  
  



• 长连接(persistent connection) 只需要建立一次 TCP 连接就能进行多次 HTTP 通信。

  
  
  
  
  • 在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。
  
  
  • 从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
  
  
  
  



• 请求流水线(HTTP pipeline) 一次发出多个请求
  
   默认情况下，HTTP 请求是按顺序发出的，下一个请求只有在当前请求收到响应之后才会被发出。由于受到网络延迟和带宽的限制，在下一个请求被发送到服务器之前，可能需要等待很长时间。流水线是在同一条长连接上连续发出请求，而不用等待响应返回，这样可以减少延迟。

  
  

COOKIE

• 作用:
  
    HTTP/1.1 引入 COOKIE 来保存状态信息。
  
    COOKIE 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端两个请求是否来自同一浏览器，以及根据从中提取的数据恢复客户端上一次连接时的状态。
  
    由于之后每次请求都会需要携带 COOKIE 数据，因此会带来额外的性能开销（尤其是在移动环境下）。

  
  



• 被淘汰:
  
   COOKIE 曾一度用于客户端数据的存储，因为当时并没有其它合适的存储办法而作为唯一的存储手段，但现在随着现代浏览器开始支持各种各样的存储方式，COOKIE 渐渐被淘汰。新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。

  
  



• 用途:

  
  
  
  
  • 会话状态管理——如用户登录状态、购物车、游戏分数或其它需要记录的信息
  
  
  • 个性化设置——如用户自定义设置、主题等
  
  
  • 浏览器行为跟踪——如跟踪分析用户行为等
  
  
  
  



• 创建过程:

  
  
  
  
  • 响应报文使用Set-COOKIE首部字段
    
    
  
  
  • 客户端将报文中COOKIE的内容保存到浏览器
  
  
  • 下次请求同一服务器时，浏览器使用COOKIE请求首部字段
    
    
  
  
  
  



• 分类:

  
  
  
  
  • 会话期COOKIE: 浏览器关闭后自动被删除，今在会话期内有效
  
  
  • 持久性COOKIE: 指定过期时间(Expires)或有效期(max-age)之后称为持久性COOKIE
  
  
  
  



• 作用域:
  
   Domain 标识指定了哪些主机可以接受 COOKIE。如果不指定，默认为当前文档的主机（不包含子域名）。如果指定了 Domain，则一般包含子域名。例如，如果设置 Domain=mozilla.org，则 COOKIE 也包含在子域名中（如 developer.mozilla.org）。
  
   Path 标识指定了主机下的哪些路径可以接受 COOKIE（该 URL 路径必须存在于请求 URL 中）。以字符 %x2F ("/") 作为路径分隔符，子路径也会匹配。例如，设置 Path=/docs，以下地址都会匹配:

  
  
  
  
  • /docs
  
  
  • /docs/Web/
  
  
  • /docs/Web/HTTP
  
  
  
  



• Javascript创建/访问COOKIE
  
   客户端浏览器通过 document.COOKIE 属性可创建新的 COOKIE，也可通过该属性访问非 HttpOnly 标记的 COOKIE。

  
  



• HttpOnly
  
   标记为 HttpOnly 的 COOKIE 不能被 Javascript 脚本调用。跨站脚本攻击 (XSS) 常常使用 Javascript 的 document.COOKIE API 窃取用户的 COOKIE 信息，因此使用 HttpOnly 标记可以在一定程度上避免 XSS 攻击。

  
  



• Secure
  
   标记为 Secure 的 COOKIE 只能通过被 HTTPS 协议加密过的请求发送给服务端。但即便设置了 Secure 标记，敏感信息也不应该通过 COOKIE 传输，因为 COOKIE 有其固有的不安全性，Secure 标记也无法提供确实的安全保障。

  
  



• Session
  
   除了可以将用户信息通过 COOKIE 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

   Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

   使用 Session 维护用户登录状态的过程如下：

  
  
  
  
  • 用户进行登录时，用户提交包含用户名和密码的表单，放入 HTTP 请求报文中
  
  
  • 服务器验证该用户名和密码，如果正确则把用户信息存储到 Redis 中，它在 Redis 中的 Key 称为 Session ID
  
  
  • 服务器返回的响应报文的 Set-COOKIE 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 COOKIE 值存入浏览器中
  
  
  • 客户端之后对同一个服务器进行请求时会包含该 COOKIE 值，服务器收到之后提取出 Session ID，从 Redis 中取出用户信息，继续之前的业务操作。
  
  

   应该注意 Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

  
  



• 浏览器禁用COOKIE
  
   此时无法使用 COOKIE 来保存用户信息，只能使用 Session。除此之外，不能再将 Session ID 存放到 COOKIE 中，而是使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。

  
  



• COOKIE与Session比较:

  
  
  
  
  • COOKIE 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session
  
  
  • COOKIE 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 COOKIE 中，可以将 COOKIE 值进行加密，然后在服务器进行解密
  
  
  • 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。
  
  
  
  

缓存

• 方式:

  
  
  
  
  • 代理服务器缓存(位于客户端浏览器、服务器之间)
  
  
  • 客户端浏览器缓存
  
  
  
  



• 优点:

  
  
  
  
  • 缓解服务器压力
  
  
  • 降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存服务器在地理位置上也有可能比源服务器来得近，例如浏览器缓存。
  
  
  
  



• 缓存控制Cache Control
  
   HTTP/1.1 通过 Cache-Control 首部字段来控制缓存

  
  
  
  

  • 禁止缓存——不能对请求或响应进行缓存

    
    

    Cache_Control: no-store

    
    

    
    
  
  

  • 强制确认缓存
    
     缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。

    
    

    Cache-Control: no-cache

    
    

    
    
  
  

  • 私有缓存和公共缓存
    
     private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

    
    

    Cache-Control: private

    
    

     public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

    
    

    Cache-Control: public

    
    

    
    
  
  

  • 缓存过期机制

    
    
    
    

    • max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。

      
      
    
    

    • max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。
      
      > Cache-Control: max-age=31536000

      
      
    
    

    • Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。
      
      > Expires: Wed, 04 Jul 2012 08:26:05 GMT

      
      
    
    
    
    
  
  
  
  



• 缓存验证

  
  
  
  
  • 响应首部字段Etag(资源匹配信息, 资源的唯一标识)
    
    
    

    • 请求报文If-None-Match首部字段验证
      
        客户端将Etag放入请求报文的If-None-Match首部，服务器判断缓存资源的 ETag 值和资源的最新 ETag 值是否一致，如果一致则表示缓存资源有效，返回 304 Not Modified。

      
      
    
    

    • 响应报文Last-Modified首部字段验证
      
        包含在源服务器发送的响应报文中，指示源服务器对资源的最后修改时间。客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 OK。如果请求的资源从那时起未经修改，那么返回一个不带有实体主体的 304 Not Modified 响应报文。

      
      
    
    

    /*响应报文*/
Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
/*后续请求报文*/
If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

    

  
  
  
  

内容协商(通过内容协商返回最合适的内容，如语言/展现形式)

• 类型:

  
  
  
  
  • 服务端驱动型协商(客户端在请求报文首部字段中告知需要的资源)
  
  
  • 代理驱动型(返回300 Multiple Choices 或者 406 Not Acceptable，客户端选合适的)
  
  
  • 透明协商
  
  
  
  



• Vary

  
  
  
  
  • 使用缓存的要求
    
      在使用内容协商的情况下，只有当缓存服务器中的缓存满足内容协商条件时，才能使用该缓存，否则应该向源服务器请求该资源。
  
  
  • 可选参数(请求报文):
    
    
    
    • Accept
    
    
    • Accept-Charset
    
    
    • Accept-Encoding
    
    
    • Accept-Language
    
    
    
    
  
  
  
  

内容编码(对报文实体进行压缩，减少传输的数据量)

• 常用内容编码类型: gzip、compress、deflate、identity


• Accept-Encoding
  
    客户端发送 Accept-Encoding 首部，其中包含有它所支持的压缩算法，以及各自的优先级


• Content-Encoding
  
    服务器则从中选择一种，使用该算法对响应的消息主体进行压缩，并且发送 Content-Encoding 首部来告知浏览器它选择了哪一种算法。由于该内容协商过程是基于编码类型来选择资源的展现形式的，响应报文的 Vary 首部字段至少要包含 Content-Encoding。

范围请求(网络中断等情况下，客户端只请求部分未发送数据)

• 请求报文Range字段

GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023


• 响应报文Accept-Ranges字段

Accept-Ranges: bytes


• 响应状态码
  
  
  
  • 在请求成功的情况下，服务器会返回 206 Partial Content 状态码
  
  
  • 在请求的范围越界的情况下，服务器会返回 416 Requested Range Not Satisfiable 状态码
  
  
  • 在不支持范围请求的情况下，服务器会返回 200 OK 状态码
  
  
  
  

分块传输编码(Chunked Transfer Encoding，可以把数据分割成多块，让浏览器逐步显示页面)

多部份对象集合(一份报文主体内可含有多种类型的实体同时发送)

  一份报文主体内可含有多种类型的实体同时发送，每个部分之间用 boundary 字段定义的分隔符进行分隔，每个部分都可以有首部字段

Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"
Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--


虚拟主机(一台服务器拥有多个域名)

  HTTP/1.1 使用虚拟主机技术，使得一台服务器拥有多个域名，并且在逻辑上可以看成多个服务器。

通信数据转发(代理服务器/ 网关/ 隧道)

代理(请求分发)

  代理服务器接收客户端请求，转发给其他服务器

• 代理服务的作用:

  
  
  
  
  • 缓存
  
  
  • 访问控制
  
  
  • 访问日志记录
  
  
  • 负载均衡
  
  
  
  



• 类型:

  
  
  
  
  • 正向代理(Http服务器所在网络外部)
  
  
  • 反向代理(Http服务器所在网络内部)
  
  
  
  

网关(协议转换)

  将Http请求转化为其他协议通信，从而请求其它非Http协议

隧道(专用安全通信)

  使用SSL 等加密手段，在客户端和服务器之间建立一条安全的通信线路。