HTTP协议详解

HTTP/1.1协议

浏览器发起HTTP请求的典型场景

  1. 用户在浏览器中输入相应的网址，在此过程中如果存在历史访问的记录，浏览器引擎查询其内置的数据库补全相应网址
  2. 浏览器引擎调用渲染引擎通过网络模块发送第一个请求
  3. 浏览器接收到第一个响应之后，如果其中存在超链接，比如一个JavaScript请求，那么浏览器会继续调用网络请求响应的js文件，并调用JS解释器解析相应js文件
  4. 浏览器接收到所有的html、JavaScript、css、其他媒体文件之后，通过UI后端将完整的界面绘制到用户界面中

浏览器发起HTTP请求的典型场景中背后的细节：

  1. 服务器监听80等web端口，浏览器从URL中解析出域名
  2. 浏览器根据域名查询DNS从而获取到对于的IP地址
  3. 通过查询到的IP地址与服务器建立TCP链接（如果是https协议还需要万TLS/SSL握手）
  4. 构造HTTP请求，在这个过程中填充上下文至HTTP头部
  5. 浏览器发送HTTP请求，服务器收到HTTP请求后将HTML页面作为包体返回给浏览器
  6. 浏览器引擎解析响应，渲染包体至用户界面，并根据超链接构造其他的HTTP请求

HTTP协议的定义

HTTP(超文本传输协议)：一种无状态的、应用层的、以请求/应答方式运行的协议，它使用可扩展的语义和自描述消息格式，与基于网络的超文本信息系统灵活的互动。

HTTP协议的格式

ABNF（扩充巴科斯-瑙尔范式）

巴科斯范式的英文缩写为 BNF，它是以美国人巴科斯 (Backus) 和丹麦人诺尔 (Naur) 的名字命名的一种形式化的语法表示方法，用来描述语法的一种形式体系，是一种典型的元语言。又称巴科斯 - 诺尔形式 (Backus-Naur form)。它不仅能严格地表示语法规则，而且所描述的语法是与上下文无关的。它具有语法简单，表示明确，便于语法分析和编译的特点。

ABNF操作符

ABNF核心规则

基于ABNF描述的HTTP协议格式

HTTP请求实例：

GET /wp-content/plugins/Pure-Highlightjs_1.0/assets/pure-highlight.css?v.1.0 HTTP/1.1
HOST: www.taohui.pub

HTTP响应实例：

# 响应
HTTP/1.1 200 OK
Server: openresty/1.13.6.2
Date: Sun, 05 May 2019 15:30:31 GMT
Content-Type: text/css
Content-Length: 108
Last-Modified: Thu, 27 Dec 2018 07:35:33 GMT
Connection: keep-alive
ETag: "5c2480c5-6c"
Expires: Sun, 12 May 2019 15:30:31 GMT
Cache-Control: max-age=604800
Accept-Ranges: bytes

pre.pure-highlightjs {
    background-color: transparent;!important;
    border: none;
    padding: 0;
}

OSI七层概念模型

  1. 应用层：负责解决业务问题
  2. 表示层：负责把网络中的消息转换成应用层可以读取的消息
  3. 会话层：负责建立会话、握手、维持连接、关闭
  4. 传输层：负责解决进程与进程之间的通信，例如TCP保证报文的可达性和流量的控制
  5. 网络层：负责解决广域网（Internet）中主机之间数据的传递
  6. 网络层
  7. 数据链路层：负责局域网中根据MAC地址连接的相应的交换机/路由器进行报文的转发
  8. 物理层：物理传输介质

TCP/IP模型对照

img

分层模型的优点在于当前层只需要考虑与其相邻层的对接交互，即每一层只为其之上的层服务，并使用在其之下的层所提供的服务，而不需要考虑其相邻层之外的其他层做了什么。分层模型的缺点在于不同层之间数据交互需要耗费更多的时间，从而影响网络性能。

报文头部

HTTP协议解决了什么问题？

Form Follows Function 形式服务于功能

解决的是人与机器之间高效的信息交互

解决WWW信息交互必须面对的需求

  • 低门槛
  • 可拓展性
  • 分布式系统下的超文本传输
  • Internet规模
    • 无法控制的可伸缩性
    • 不可预测的负载、非法格式的数据、恶意消息
    • 客户端不能保存所有服务器信息，服务器不能保持多个请求间的状态信息
  • 独立的组件部署：新老组件并存
  • 向前兼容

评估Web架构的七大关键属性

  1. 性能：影响高可用的关键因素

  2. 可伸缩性：支持部署可以互相交互的大量组件

  3. 简单性：易理解、易实现、易验证

  4. 可见性：对两个组件间的交互进行监视或者仲裁的能力。如缓存、分层设计等

  5. 可移植性：在不同的环境下运行的能力

  6. 可靠性：出现部分故障时对整体的影响程度

  7. 可修改性：对系统做出修改的难易程度，由可进化型、可定制性、可扩展性、可配置性、可重用性构成

架构属性：性能

  • 网络性能
    • 吞吐量：小于等于带宽
    • 开销：首次开销，每次开销
  • 用户感知到的性能
    • 延迟：发起请求到接收到响应的时间
    • 完成时间：完成一个应用动作所花费的时间
  • 网络效率
    • 重用缓存、减少交互次数、数据传输距离更近、COD（按需代码）

架构属性：可修改性

  • 可进化性：一个组件独立升级而不影响其他组件
  • 可扩展性：向系统添加功能时，不会影响到系统的其他部分
  • 可定制性：临时性、定制性地更改某一要素来提供服务，不对常规客户产生影响
  • 可配置性：应用部署后可通过修改配置提供新的功能
  • 可重用性：组件可以不做修改在其他应用中使用

REST架构下的Web

五种架构风格

  1. 数据流风格 Data-flow Styles
    优点：简单性、可进化性、可扩展性、可配置性、可重用性
  2. 复制风格 Replication Styles
    优点：用户可察觉的性能、可伸缩性，网络效率、可靠性也可以得到提升
  3. 分层风格 Hierarchical Styles
    优点：简单性、可进化性、可伸缩性
  4. 移动代码风格 Mobile Code Styles
    优点：可移植性、可扩展性、网络效率
  5. 点对点风格 Peer-to-Peer Styles
    优点：可进化性、可重用性、可扩展性、可配置性

REST架构的推导

统一接口的分层、缓存、无状态、客户端服务器模型+按需代码构成了REST结构

URI的基本格式以及与URL的区别

当没有URI时：

有了URI：

什么是URI

Uniform Resource Identifier 统一资源标识符

URI的组成

合法的URI

URI的格式

hier-part

相对URI

URI的编码

为什么要进行URI编码

保留字符与非保留字符

URI百分号编码

posted on 2019-05-12 21:01  别吃烧饼  阅读(27812)  评论(0)  编辑  收藏  举报

导航