前言
感觉这半年来,掘金的活动是一个接一个🎁
今天看到创作者中心又多了一个技术专题的征文活动,关于网络协议,其中里头一条评论:
你们掘金活动真多啊,可惜这个我不会
这真是说出了我的心声😢......对我来说,网络协议一直是又熟悉又陌生,更多的是陌生,因为虽然一直听,但是没有真正花时间去了解过它,确实这活动没法写
但,后面转念一想,就是不会才要学呀,于是打算趁着活动,补一补网络协议相关的知识
注:
- 由于
HTTP
协议包括的规范特别庞大,本文仅以扫盲了解为主,大佬请左转👈🏻 - 文章参考了大量网上公开资料(包括百科、
runoob
等),吸收整理成此文,如有问题欢迎留言~
为了让你看上去清晰,我整理了文章目录结构,如下:
看完本篇,你将会了解完上图的相关知识点
简介
下面我们从什么是HTTP协议开始讲起
HTTP协议是什么
HTTP
是Hyper Text Transfer Protocol
的缩写,该协议是用于从万维网服务器传输超文本到本地浏览器的传送协议,且它是基于TCP/IP
通信协议来传递数据
简单来说,它就是一种约定协议,一种客户端跟服务端之间的约定协议
小结如下图:
历史及其各版本
关于HTTP
协议的历史个人觉得还是挺重要的,一方面是个人对历史比较感兴趣,另一方面是希望养成良好的素养,知根知底!
HTTP
的发展大致可分为以下几个阶段
- 1991年,
Tim Berners-Lee
设计出一个简单的单行超文本交换协议,也就是后人所熟知的HTTP/0.9
,这就是最原始的HTTP协议 - 随着互联网迎来爆炸式的发展,原始的
HTTP
协议具有很多的问题,许多 HTTP 改进都是自发出现,具有讽刺意味的是,去中心化的 Web 需要一个中心化的管理机构来避免碎片化造成的不兼容问题。Tim Berners-Lee
也意识到了危险,1994 年成立万维网联盟,作为为已有环境带来更多规范的第一步。时间已经是到了1996年5月,他们记录了当时 HTTP 中最常用的一些功能,并将其命名为HTTP/1.0
协议 - 1997年1月修复了 HTTP/1.0 的不一致之处,并调整了协议,使其在新的 Web 生态系统中具备更好的性能表现,这就是
HTTP/1.1
,新版引入的两个最关键的更改是默认使用持久 TCP 连接(保持活动状态)和 HTTP 管线化。并且在很长的一段时间里,HTTP/1.1 表现得都非常好 - 谷歌在 2008 年发布了 Chrome 浏览器,这种浏览器因其快速和创新而迅速流行。它使谷歌在互联网技术问题上获得了强大的话语权。在 2010 年代初期,谷歌在 Chrome 中增加了对其 Web 协议 SPDY 的支持。随之事件的推移,在2015年5月,新版本的HTTP协议作为互联网标准正式发布--
HTTP/2
,HTTP/2
标准基于 SPDY,并进行了一些改进,它的发布解决了 Web 上的许多问题,比如多路复用、服务器推送、头部压缩等等 - 最后就是
HTTP/3
,HTTP/3
也是目前最前沿的互联网标准,虽然目前主体环境还没有全面迭代到 HTTP/3 ,但是 HTTP/3 的发展也必定是不可阻拦的
历史的长河都是不断向前和迭代,HTTP/3
也不会是完美无瑕的,都在不断的发展中变得更好
小结如下图:
通信过程
概述
我们来讲讲HTTP
的网络通信过程
上面我们知道了,HTTP
协议工作于客户端和服务端之间,整个通信过程,浏览器会作为HTTP
客户端通过URL
向HTTP
服务端即WEB
服务器发送所有请求,Web
服务器根据接收到的请求,会向客户端发送响应信息
注意点
但需要注意几点:
HTTP
限制每次连接只处理一个请求,服务器处理完客户的请求,并收到客户的应答后,即断开连接HTTP
是媒体独立的,只要客户端和服务器知道如何处理的数据内容,任何类型的数据都可以通过HTTP发送HTTP
是无状态的,协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息,则它必须重传,这样可能导致每次连接传送的数据量增大。另一方面,在服务器不需要先前信息时它的应答就较快
小结为4步
为了方便,整个通信过程可简记为以下4
步:
HTTP报文
HTTP
报文可以理解为被传送的东西,也就是上述通信过程传递的东西
报文有两种,有从客户机到服务器的请求报文,也有从服务器到客户机的响应报文或者叫应答报文
请求报文
- 请求报文格式如下:
请求行 - 通用信息头 - 请求头 - 实体头 - 报文主体
请求行以方法字段开始,后面分别是URL
字段和HTTP
协议版本字段,并以CRLF
结尾。SP
是分隔符。除了在最后的CRLF
序列中CF
和LF
是必需的之外,其他都可以不要。有关通用信息头,请求头和实体头方面的具体内容可以参照相关文件
应答报文
- 应答报文格式如下:
状态行 - 通用信息头 - 响应头 - 实体头 - 报文主体
状态码由3
位数字组成,表示请求是否被理解或被满足。原因分析是对原文的状态码作简短的描述,状态码用来支持自动操作,而原因分析用来供用户使用。客户机无需用来检查或显示语法。有关通用信息头,响应头和实体头方面的具体内容可以参照相关文件
小结如下图:
9种请求方式
HTTP
协议中定义了9
种方法来表明对Request-URI
指定的资源的不同操作方式,其中HTTP1.0
定义了3
种请求方法: GET
, POST
和 HEAD
方法,HTTP1.1
新增了6
种请求方法:OPTIONS
、PUT
、PATCH
、DELETE
、TRACE
和 CONNECT
方法
GET
:向特定的资源发出请求POST
:向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST
请求可能会导致新的资源的创建和/或已有资源的修改HEAD
:向服务器索要与GET请求相一致的响应,只不过响应体将不会被返回。这一方法可以在不必传输整个响应内容的情况下,就可以获取包含在响应消息头中的元信息OPTIONS
:返回服务器针对特定资源所支持的HTTP请求方法。也可以利用向Web服务器发送的请求来测试服务器的功能性PUT
:向指定资源位置上传其最新内容PATCH
:是对PUT
方法的补充,用来对已知资源进行局部更新DELETE
:请求服务器删除 Request-URI 所标识的资源CONNECT
:HTTP/1.1
协议中预留给能够将连接改为管道方式的代理服务器TRACE
:回显服务器收到的请求,主要用于测试或诊断
在实际应用中常用的也就是get
和post
小结如下图:
常用请求头信息
为了言简意赅,直接整理如下:
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
请求成功。一般用于GET
与POST
请求 - 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
类似。使用GET
和POST
请求查看 - 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
种类型,如下图:
内容类型和网络文件类型
这里讲一下内容类型--Content-Type
内容类型
Content-Type
用于定义网络文件的类型和网页的编码,它决定浏览器将以什么形式以及什么编码读取这个文件
大概语法格式如下:
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
其中,text/html
和multipart/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
好了,以上就是本文的所有内容,如有问题,欢迎指正~