快速了解HTTP协议

9,566 阅读16分钟

前言

感觉这半年来,掘金的活动是一个接一个🎁

今天看到创作者中心又多了一个技术专题的征文活动,关于网络协议,其中里头一条评论:

你们掘金活动真多啊,可惜这个我不会

这真是说出了我的心声😢......对我来说,网络协议一直是又熟悉又陌生,更多的是陌生,因为虽然一直听,但是没有真正花时间去了解过它,确实这活动没法写

但,后面转念一想,就是不会才要学呀,于是打算趁着活动,补一补网络协议相关的知识

注:

  • 由于HTTP协议包括的规范特别庞大,本文仅以扫盲了解为主,大佬请左转👈🏻
  • 文章参考了大量网上公开资料(包括百科、runoob等),吸收整理成此文,如有问题欢迎留言~

为了让你看上去清晰,我整理了文章目录结构,如下:

image.png

看完本篇,你将会了解完上图的相关知识点

简介

下面我们从什么是HTTP协议开始讲起

HTTP协议是什么

HTTPHyper Text Transfer Protocol的缩写,该协议是用于从万维网服务器传输超文本到本地浏览器的传送协议,且它是基于TCP/IP通信协议来传递数据

简单来说,它就是一种约定协议,一种客户端跟服务端之间的约定协议

小结如下图:

image.png

历史及其各版本

关于HTTP协议的历史个人觉得还是挺重要的,一方面是个人对历史比较感兴趣,另一方面是希望养成良好的素养,知根知底!

HTTP的发展大致可分为以下几个阶段

  1. 1991年Tim Berners-Lee设计出一个简单的单行超文本交换协议,也就是后人所熟知的HTTP/0.9,这就是最原始的HTTP协议
  2. 随着互联网迎来爆炸式的发展,原始的HTTP协议具有很多的问题,许多 HTTP 改进都是自发出现,具有讽刺意味的是,去中心化的 Web 需要一个中心化的管理机构来避免碎片化造成的不兼容问题。Tim Berners-Lee也意识到了危险,1994 年成立万维网联盟,作为为已有环境带来更多规范的第一步。时间已经是到了1996年5月,他们记录了当时 HTTP 中最常用的一些功能,并将其命名为 HTTP/1.0 协议
  3. 1997年1月修复了 HTTP/1.0 的不一致之处,并调整了协议,使其在新的 Web 生态系统中具备更好的性能表现,这就是HTTP/1.1 ,新版引入的两个最关键的更改是默认使用持久 TCP 连接(保持活动状态)和 HTTP 管线化。并且在很长的一段时间里,HTTP/1.1 表现得都非常好
  4. 谷歌在 2008 年发布了 Chrome 浏览器,这种浏览器因其快速和创新而迅速流行。它使谷歌在互联网技术问题上获得了强大的话语权。在 2010 年代初期,谷歌在 Chrome 中增加了对其 Web 协议 SPDY 的支持。随之事件的推移,在2015年5月,新版本的HTTP协议作为互联网标准正式发布--HTTP/2 HTTP/2 标准基于 SPDY,并进行了一些改进,它的发布解决了 Web 上的许多问题,比如多路复用、服务器推送、头部压缩等等
  5. 最后就是HTTP/3, HTTP/3也是目前最前沿的互联网标准,虽然目前主体环境还没有全面迭代到 HTTP/3 ,但是 HTTP/3 的发展也必定是不可阻拦的

历史的长河都是不断向前和迭代,HTTP/3也不会是完美无瑕的,都在不断的发展中变得更好

小结如下图:

image.png

通信过程

概述

我们来讲讲HTTP的网络通信过程

上面我们知道了,HTTP协议工作于客户端和服务端之间,整个通信过程,浏览器会作为HTTP客户端通过URLHTTP服务端即WEB服务器发送所有请求,Web服务器根据接收到的请求,会向客户端发送响应信息

注意点

但需要注意几点:

  1. HTTP限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,即断开连接
  2. HTTP是媒体独立的,只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过HTTP发送
  3. HTTP是无状态的,协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快

小结为4步

为了方便,整个通信过程可简记为以下4步:

image.png

HTTP报文

HTTP报文可以理解为被传送的东西,也就是上述通信过程传递的东西

报文有两种,有从客户机到服务器的请求报文,也有从服务器到客户机的响应报文或者叫应答报文

请求报文

  • 请求报文格式如下:

请求行 - 通用信息头 - 请求头 - 实体头 - 报文主体

请求行以方法字段开始,后面分别是URL字段和HTTP协议版本字段,并以CRLF结尾。SP是分隔符。除了在最后的CRLF序列中CFLF是必需的之外,其他都可以不要。有关通用信息头,请求头和实体头方面的具体内容可以参照相关文件

应答报文

  • 应答报文格式如下:

状态行 - 通用信息头 - 响应头 - 实体头 - 报文主体

状态码由3位数字组成,表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述,状态码用来支持自动操作,而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头,响应头和实体头方面的具体内容可以参照相关文件

小结如下图:

image.png

9种请求方式

HTTP 协议中定义了9种方法来表明对Request-URI指定的资源的不同操作方式,其中HTTP1.0 定义了3种请求方法: GET, POSTHEAD 方法,HTTP1.1 新增了6种请求方法:OPTIONSPUTPATCHDELETETRACE CONNECT 方法

  1. GET:向特定的资源发出请求
  2. POST:向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源的创建和/或已有资源的修改
  3. HEAD:向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息
  4. OPTIONS:返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送的请求来测试服务器的功能性
  5. PUT:向指定资源位置上传其最新内容
  6. PATCH:是对 PUT 方法的补充,用来对已知资源进行局部更新
  7. DELETE:请求服务器删除 Request-URI 所标识的资源
  8. CONNECTHTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器
  9. TRACE:回显服务器收到的请求,主要用于测试或诊断

在实际应用中常用的也就是getpost

小结如下图:

image.png

常用请求头信息

为了言简意赅,直接整理如下:

Accept: 可接受的响应内容类型(Content-Types)
Accept-Charset: 可接受的字符集
Accept-Encoding: 可接受的响应内容的编码方式。
Accept-Language: 可接受的响应内容语言列表。
Accept-Datetime: 可接受的按照时间来表示的响应内容版本
Authorization: 用于表示 HTTP 协议中需要认证资源的认证信息
Cache-Control: 用来指定当前的请求/回复中的,是否使用缓存机制。
Connection: 客户端(浏览器)想要优先使用的连接类型
Cookie: 由之前服务器通过Set-Cooki(e 见下文)设置的一个HTTP协议Cookie
Content-Length: 以 8 进制表示的请求体的长度
Content-MD5: 请求体的内容的二进制 MD5 散列值(数字签名),以 Base64 编码的结果
Content-Type: 请求体的 MIME 类型 (用于 POST 和 PUT 请求中)
Date: 发送该消息的日期和时间(以 RFC 7231 中定义的"HTTP 日期"格式来发送)
Expect: 表示客户端要求服务器做出特定的行为
From: 发起此请求的用户的邮件地址
Host: 表示服务器的域名以及服务器所监听的端口号。如果所请求的端口是对应的服务的标准端口(80),则端口号可以省略。
If-Match: 仅当客户端提供的实体与服务器上对应的实体相匹配时,才进行对应的操作。主要用于像 PUT 这样的方法中,仅当从用户上次更新某个资源后,该资源未被修改的情况下,才更新该资源。
If-Modified-Since: 允许在对应的资源未被修改的情况下返回 304 未修改
If-None-Match: 允许在对应的内容未被修改的情况下返回 304 未修改( 304 Not Modified ),参考 超文本传输协议 的实体标记
If-Range: 如果该实体未被修改过,则向返回所缺少的那一个或多个部分。否则,返回整个新的实体
If-Unmodified-Since: 仅当该实体自某个特定时间以来未被修改的情况下,才发送回应。
Max-Forwards限制该消息可被代理及网关转发的次数。
Origin: 发起一个针对跨域资源共享的请求(该请求要求服务器在响应中加入一个 Access-Control-Allow-Origin 的消息头,表示访问控制所允许的来源)。
Pragma: 与具体的实现相关,这些字段可能在请求/回应链中的任何时候产生。
Proxy-Authorization: 用于向代理进行认证的认证信息。
Range: 表示请求某个实体的一部分,字节偏移以 0 开始。
Referer: 表示浏览器所访问的前一个页面,可以认为是之前访问页面的链接将浏览器带到了当前页面。Referer 其实是 Referrer 这个单词,但 RFC制作标准时给拼错了,后来也就将错就错使用 Referer 了。
TE: 浏览器预期接受的传输时的编码方式:可使用回应协议头
Transfer-Encoding: 中的值(还可以使用"trailers"表示数据传输时的分块方式)用来表示浏览器希望在最后一个大小为 0 的块之后还接收到一些额外的字段。
User-Agent: 浏览器的身份标识字符串
Upgrade: 要求服务器升级到一个高版本协议。
Via: 告诉服务器,这个请求是由哪些代理发出的。
Warning: 一个一般性的警告,表示在实体内容体中可能存在错误。

状态码及分类

当浏览者访问一个网页时,浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前,此网页所在的服务器会返回一个包含HTTP状态码的信息头用以响应浏览器的请求

常见的HTTP状态码

之前梳理过,如下

  • 100 Continue 继续。客户端应继续其请求
  • 101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到 HTTP 的新版本协议
  • 200 OK 请求成功。一般用于 GETPOST 请求
  • 201 Created 已创建。成功请求并创建了新的资源
  • 202 Accepted 已接受。已经接受请求,但未处理完成
  • 203 Non-Authoritative Information 非授权信息。请求成功。但返回的 meta 信息不在原始的服务器,而是一个副本
  • 204 No Content 无内容。服务器成功处理,但未返回内容。在未更新网页的情况下,可确保浏览器继续显示当前文档
  • 205 Reset Content 重置内容。服务器处理成功,用户终端(例如:浏览器)应重置文档视图。可通过此返回码清除浏览器的表单域
  • 206 Partial Content 部分内容。服务器成功处理了部分 GET 请求
  • 300 Multiple Choices 多种选择。请求的资源可包括多个位置,相应可返回一个资源特征与地址的列表用于用户终端(例如:浏览器)选择
  • 301 Moved Permanently 永久移动。请求的资源已被永久的移动到新 URI,返回信息会包括新的 URI,浏览器会自动定向到新 URI。今后任何新的请求都应使用新的URI代替
  • 302 Found 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有URI
  • 303 See Other 查看其它地址。与 301 类似。使用 GETPOST请求查看
  • 304 Not Modified 未修改。所请求的资源未修改,服务器返回此状态码时,不会返回任何资源。客户端通常会缓存访问过的资源,通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
  • 305 Use Proxy 使用代理。所请求的资源必须通过代理访问
  • 306 Unused 已经被废弃的 HTTP 状态码
  • 307 Temporary Redirect 临时重定向。与 302 类似。使用 GET 请求重定向
  • 400 Bad Request 客户端请求的语法错误,服务器无法理解
  • 401 Unauthorized 请求要求用户的身份认证
  • 402 Payment Required 保留,将来使用
  • 403 Forbidden 服务器理解请求客户端的请求,但是拒绝执行此请求
  • 404 Not Found 服务器无法根据客户端的请求找到资源(网页)。通过此代码,网站设计人员可设置"您所请求的资源无法找到"的个性页面
  • 405 Method Not Allowed 客户端请求中的方法被禁止
  • 406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
  • 407 Proxy Authentication Required 请求要求代理的身份认证,与 401 类似,但请求者应当使用代理进行授权
  • 408 Request Time-out 服务器等待客户端发送的请求时间过长,超时
  • 409 Conflict 服务器完成客户端的 PUT 请求是可能返回此代码,服务器处理请求时发生了冲突
  • 410 Gone 客户端请求的资源已经不存在。410 不同于 404,如果资源以前有现在被永久删除了可使用 410 代码,网站设计人员可通过 301 代码指定资源的新位置
  • 411 Length Required 服务器无法处理客户端发送的不带 Content-Length 的请求信息
  • 412 Precondition Failed 客户端请求信息的先决条件错误
  • 413 Request Entity Too Large 由于请求的实体过大,服务器无法处理,因此拒绝请求。为防止客户端的连续请求,服务器可能会关闭连接。如果只是服务器暂时无法处理,则会包含一个 Retry-After 的响应信息
  • 414 Request-URI Too Large 请求的 URI 过长(URI 通常为网址),服务器无法处理
  • 415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
  • 416 Requested range not satisfiable 客户端请求的范围无效
  • 417 Expectation Failed 服务器无法满足Expect 的请求头信息
  • 500 Internal Server Error 服务器内部错误,无法完成请求
  • 501 Not Implemented 服务器不支持请求的功能,无法完成请求
  • 502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应
  • 503 Service Unavailable 由于超载或系统维护,服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中
  • 504 Gateway Time-out 充当网关或代理的服务器,未及时从远端服务器获取请求
  • 505 HTTP Version not supported 服务器不支持请求的 HTTP 协议的版本,无法完成处理

状态码分类

HTTP状态码由三个十进制数字组成,第一个十进制数字定义了状态码的类型,后两个数字没有分类的作用

由于HTTP状态码有很多为了方便,我们分为以下5种类型,如下图:

image.png

内容类型和网络文件类型

这里讲一下内容类型--Content-Type

内容类型

Content-Type用于定义网络文件的类型和网页的编码,它决定浏览器将以什么形式以及什么编码读取这个文件

大概语法格式如下:

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something

其中,text/htmlmultipart/form-data都是网络文件的类型,下面大致梳理一下

网络文件的类型

网络文件的类型有很多,主要分为一下几类:

常见的网络文件的类型

  • text/html : HTML格式
  • text/plain :纯文本格式
  • text/xml : XML格式
  • image/gif :gif图片格式
  • image/jpeg :jpg图片格式
  • image/png:png图片格式

以application开头的

  • application/xhtml+xml :XHTML格式
  • application/xml: XML数据格式
  • application/atom+xml :Atom XML聚合格式
  • application/json: JSON数据格式
  • application/pdf:pdf格式
  • application/msword : Word文档格式
  • application/octet-stream : 二进制流数据(如常见的文件下载)
  • application/x-www-form-urlencoded<form encType=””>中默认的encType,form表单数据被编码为key/value格式发送到服务器(表单默认的提交数据的格式)

上传文件时使用的

  • multipart/form-data : 需要在表单中进行文件上传时,就需要使用该格式

当然还有其他类型,更多文件对应的特定Content-Type,具体可以参考对照表

END

好了,以上就是本文的所有内容,如有问题,欢迎指正~

参考文献