网络请求 - HTTP简介

coderklaus
232 阅读8分钟

渲染模式

早期的网页都是通过后端渲染来完成的: 服务器端渲染(SSR，server side render 或 后端渲染)

image.png

  1. 客户端发出请求

  2. 服务端接收请求 根据参数等信息 去 数据库查找数据

再使用模板引擎或asp/jsp等技术 将数据插入到html内 渲染形成完整的html (或者可以称之为组装成完整的html文件)

并返回客户端

  1. 页面刷新，客户端加载新的HTML文档

这种模式是早期的渲染模式，有着比较明显的缺点:

  1. 业务逻辑，数据操作，界面渲染 全部都是由后端来完成的

    随着项目越来越大，业务逻辑和界面渲染以及数据操作之间的耦合度会越来越高，维护成本也越来越高

  2. 当用户点击页面中的某个按钮向服务器发送请求时，页面本质上只是一些数据发生了变化,

    但此时服务器却要将重绘的整个页面再返回给浏览器加载，这有悖于程序员的“DRY( Don‘t repeat yourself )”原则

    同时一些数据的变化却迫使服务器要返回整个HTML文档，这本身也会给网络带宽带来不必要的开销

于是出现了AJAX, AJAX可以在页面数据变动时，只向服务器请求新的数据，并且在阻止页面刷新的情况下，动态的替换页面中展示的数据

AJAX是“Asynchronous JavaScript And XML”的缩写(异步的JavaScript和XML)，是一种实现 无页面刷新 获取服务器数据的技术

AJAX可以在不重新刷新页面的情况下与服务器通信，交换数据，或更新页面

  1. 在不重新加载页面的情况下发送请求给服务器
  2. 接受并使用从服务器发来的数据 并 在无刷新状态下更新界面

image.png

  1. 浏览器去前端服务器(静态资源服务器) 请求对应的html，css，js - 此时html中只有一些基本的页面结构

  2. 浏览器解析html，css，js

    在解析JS脚本的时候遇到XHR或fetch请求的时候，就会去后端服务器(API服务器)去请求对应的数据

  3. 后端服务器会根据请求去数据库中查询对应的数据，并组合成JSON等格式后返回浏览器(客户端)

  4. 浏览器通过操作DOM的方式将数据插入到页面中，并渲染成完整的页面

在这种新的渲染模式中，页面的渲染是在浏览器，也就是客户端完成的，所以这种渲染模式也被称之为前端渲染 (或被称之为前后端分离模式 client side render CSR 或 客户端渲染)

但是CSR渲染也有自己的弊端

  1. 不利于SEO, 浏览器爬虫爬取的一般都是HTML文件(google爬虫除外)，并不会爬取js代码
  2. 所有的渲染过程都是在前端完成，所需要的渲染时间较长，所以不利于首屏渲染

HTTP

超文本传输协议(英语:HyperText Transfer Protocol，缩写:HTTP)是一种用于分布式、协作式和超媒体信息系统的应用层协议

HTTP是万维网的数据通信的基础，设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法

通过HTTP或者HTTPS协议请求的资源由统一资源标识符(Uniform Resource Identifiers，URI)来标识

HTTP是一个客户端(用户)和服务端(网站)之间请求和响应的标准,用于客户端和服务器之间进行数据通信和数据交换

  • 通过使用网页浏览器、网络爬虫或者其它的工具，客户端发起一个HTTP请求到服务器上指定端口(默认端口为80)
    • 我们称这个客户端为用户代理程序(user agent)
  • 响应的服务器上存储着一些资源，比如HTML文件和图像
    • 我们称这个响应服务器为源服务器(origin server)

image.png

组成

一次HTTP请求主要包括:请求(Request)和响应(Response)

image.png

请求

image.png

响应

image.png

版本

版本号发布时间说明
HTTP/0.91991年只支持GET请求方法获取文本数据
当时主要是为了获取HTML页面内容
HTTP/1.01996年支持POST、HEAD等请求方法，支持请求头、响应头等，支持更多种数据类型(不再局限于文本数据)
但是浏览器的每次请求都需要与服务器建立一个TCP连接，请求处理完成后立即断开TCP连接，每次建立连接增加了性能损耗
HTTP/1.11997年增加了PUT、DELETE等请求方法
采用持久连接(Connection: keep-alive)，多个请求可以共用同一个TCP连接
目前使用最广泛的版本
HTTP/2.02015年目前使用较少
HTTP/3.02018年目前使用较少

请求方式

在RFC中定义了一组请求方式，来表示要对给定资源执行的操作:

方式名说明
GETGET 方法请求一个指定资源的表示形式，使用 GET 的请求应该只被用于获取数据
主要用于获取资源
HEADHEAD 方法请求一个与 GET 请求的响应相同的响应，但没有响应体
这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查
比如在准备下载一个文件前，先获取文件的大小，再决定是否进行下载
OPTIONSOPTIONS 主要用于 请求 Web 服务器告知其支持的各种功能
POSTPOST 方法用于将实体提交到指定的资源
主要用于数据提交
PUTPUT 方法用请求有效载荷(payload)替换目标资源的所有当前表示
主要用于修改数据 - 不过这种修改是整体修改，即使用新数据替换原本整个数据
DELETEDELETE 方法删除指定的资源
主要用于删除数据
PATCHPATCH 方法用于对资源应部分修改
主要用于数据修改 - 这种修改不会对数据进行整体替换，而是只修改数据中的一部分
CONNECTCONNECT 方法建立一个到目标资源标识的服务器的隧道，通常用在代理服务器，网页开发很少用到
主要功能是将http的连接修改为管道方式进行连接
TRACETRACE 方法沿着到目标资源的路径执行一个消息环回测试
主要用于请求和响应测试

请求头

在request对象的header中也包含很多有用的信息，客户端会默认传递过来一些信息

请求头的key一般以首字母大写的，以中划线进行拼接的多个单词组成

常见的有:

keyvalue
Content-Type这次请求携带的数据的类型
Content-Length请求体的大小长度
客户端会自动进行计算并设置
Connection: keep-alive客户端和服务器之间请求是持久连接
Accept-Encoding告知服务器，客户端支持的文件压缩格式
比如js文件可以使用gzip编码，对应 .gz文件 --- index.js -> index.js.gz
在请求的时候，客户端会自动配置自己可以接收的压缩文件格式并传输给服务器
如果服务器有对应资源的压缩格式文件时，会自动将对应的压缩格式文件传输给客户端
客户端在获取到对应的压缩文件后，会自动进行解压并解析
常见的网络传输的压缩格式为gzip
Accept告知服务器，客户端可接受文件的格式类型
User-Agent客户端相关的信息

content-type

content-type是这次请求携带的数据的类型

类型说明
application/x-www-form-urlencoded表示数据被编码成以 '&' 分隔的键 - 值对，同时以 '=' 分隔键和值
如name=Klaus&age=23
application/json表示是一个json类型
text/plain表示是文本类型
application/xml表示是xml类型
multipart/form-data表示是上传文件

keep-alive

http是基于TCP协议的，但是通常在进行一次请求和响应结束后会立刻中断

在http1.0中，如果想要继续保持连接(连接重用):

  • 浏览器需要在请求头中添加 connection: keep-alive
  • 服务器需要在响应头中添加 connection:keey-alive
  • 当客户端再次放请求时，就会使用同一个连接，直接一方中断连接

在http1.1中，所有连接默认是 connection: keep-alive的;

  • 不同的Web服务器会有不同的保持 keep-alive的时间
  • Node中默认是5s

响应头

响应的header中包括一些服务器给客户端的信息

头说明
Access-Control-Allow-Origin是否允许跨域
Content-Length返回的响应体的长度
Content-Type返回的响应体的格式类型
Date返回时间

响应码

Http状态码(Http Status Code)是用来表示Http响应状态的数字代码

Http状态码非常多，可以根据不同的情况，给客户端返回不同的状态码

image.png

一般情况下:

  1. 2xxx - 成功状态码
  2. 3xxx - 重定向状态码
  3. 4xxx - 客户端错误
  4. 5xxx - 服务器端错误
avatar
文章
阅读
粉丝