本文深入探讨了HTTP协议，包括其请求响应过程、请求特征、报文结构、内容协商、认证机制、缓存管理和CORS跨域。HTTP支持客户-服务器模式，以简单快速和灵活著称，但无连接和无状态特性导致了一些挑战。HTTP报文由起始行、首部字段和消息正文组成，内容协商确保资源的正确呈现，而认证涉及BASIC、DIGEST、SSL客户端和基于表单的方式。缓存通过减少网络传输提高性能，CORS机制允许跨域资源共享，通过Access-Control-*响应字段实现。
文章目录
一、简介
HTTP是一种超文本传输协议(Hypertext Transfer Protocol) ，主要有三点需要理解到位：
- 超文本：不仅是简单的文字还可以包含图片、音频、视频，甚至点击文字或图片能够进行超链接的跳转。
- 传输：两台计算机之间会形成互联关系进行通信，我们存储的超文本会被解析成为二进制数据包，由传输载体(例如同轴电缆，电话线，光缆)负责把二进制数据包由计算机终端传输到另一个终端的过程称为传输。
- 协议：网络协议就是网络中传递、管理信息的一些规范。计算机之间的相互通信需要共同遵守一定的规则，这些规则就称为网络协议。
二、HTTP请求响应过程
以浏览器中输入http://www.xxx.com/someDepartment/home.index为例，展示HTTP请求响应过程：
- DNS服务器会首先进行域名的映射，找到访问www.xxx.com所在的地址，然后HTTP 客户端进程在80端口发起一个到服务器www.xxx.com的TCP连接(80 端口是HTTP的默认端口)。在客户和服务器进程中都会有一个套接字与其相连。
- HTTP客户端通过它的套接字向服务器发送一个HTTP请求报文。该报文中包含了路径someDepartment/home.index的资源。
- HTTP服务器通过它的套接字接受该报文，进行请求的解析工作，并从其存储器(RAM或磁盘)中检索出对象www.xxx.com/someDepartment/home.index，然后把检索出来的对象进行封装，封装到HTTP响应报文中，并通过套接字向客户进行发送。
- HTTP服务器随即通知TCP断开TCP连接，实际上是需要等到客户接受完响应报文后才会断开TCP连接。
- HTTP客户端接受完响应报文后，TCP连接会关闭。HTTP客户端从响应中提取出报文中是一个HTML响应文件，并检查该HTML文件，然后循环检查报文中其他内部对象。
- 检查完成后，HTTP客户端会把对应的资源通过显示器呈现给用户。
三、HTTP请求特征
- 支持客户-服务器模式
- 简单快速:客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单,使得HTTP服务器的程序规模小，因而通信速度很快。
- 灵活: HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type 加以标记。
- 无连接:无连接的含义是限制每次连接只处理一个请求。 服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
- 无状态: HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
四、HTTP报文
HTTP报文主要由三部分组成：
- 起始行(start line)：描述请求或响应的基本信息;
- 首部字段(header) ：使用key-value形式更详细地说明报文;
- 消息正文(entity) ：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。
其中起始行和首部字段并成为请求头或者响应头，统称为Header ; 消息正文也叫做实体，称为body。HTTP协议规定每次发送的报文必须要有Header,但是可以没有body, 也就是说头信息是必须的，实体信息可以没有。而且在header和body之间必须要有一个空行(CRLF) 。大致应该是这样：
1.起始行
HTTP报文既有请求报文也有响应报文，两种报文的起始行格式不相同，分别介绍两种不同类型报文起始行的内容：
-
请求报文：包含请求方法、路径、HTTP版本号
请求方法有很多种，常用的就是GET、POST，需要用到其他方法可自行查找资料
-
响应报文：包含相应结果的状态码、原因短语和HTTP版本号
状态码：
- 1XX，信息性状态码，接收的请求正在处理
- 2XX，成功状态码，请求正常处理完毕
- 3XX，重定向状态码，需要进行附加操作以完成请求
- 4XX，客户端错误状态码，服务器无法处理请求
- 5XX，服务器错误状态码，服务器处理请求出错
2.首部字段
首部字段主要有四类：通用字段、请求字段、响应字段、实体字段
-
通用字段：HTTP通用标头之所以这样命名，是因为与其他三个类别不同，它们不是限定于特定种类的消息或者消息组件(请求，响应或消息实体)的。HTTP通用标头主要用于传达有关消息本身的信息，而不是它所携带的内容。它们提供一般信息并控制如何处理消息。通用字段主要有三个，分别是
Date、Cache-Control和Connection，其他通用字段如下，自行查阅相关用法：
-
请求字段：请求字段用于客户端发送HTTP请求到服务器中所使用的字段
-
响应字段：响应首部字段是由服务器发送给客户端响应中所包含的字段，用于补充相应信息等
-
实体字段：描述消息正文内容的 HTTP 字段。实体字段用于 HTTP 请求和响应中。头部
Content-Length、Content-Language、Content-Encoding是实体字段。其他实体字段如下：
五、内容协商
在HTTP中，内容协商是一种用于在同一URL上提供资源的不同表示形式的机制。内容协商机制是指客户端和服务器端就响应的资源内容进行交涉,然后提供给客户端最为适合的资源。内容协商会以响应资源的语言、字符集、编码方式等作为判断的标准。
内容协商的种类：
- 服务器驱动协商：由服务器端进行内容协商。以请求的首部字段为参考，在服务器端自动处理。但对用户来说，以浏览器发送的信息作为判定的依据，并不一定能筛选出最优内容。
- 客户端驱动协商：由客户端进行内容协商的方式。用户从浏览器显示的可选项列表中手动选择。还可以利用JavaScript脚本在Web页面上自动进行上述选择。比如按OS的类型或浏览器类型，自行切换成PC版页面或手机版页面。
- 透明协商：是服务器驱动和客户端驱动的结合体，是由服务器端和客户端各自进行内容协商的一种方法。
内容协商字段：Accept、Accept-Charset、Accept-Language、Accept-Encoding、Content-Type、Content-Encoding、Content-language
六、HTTP认证
计算机本身无法判断坐在显示器前的使用者的身份。进一步说，也无法确认网络的那头究竟有谁。可见，为了弄清究竟是谁在访问服务
器，就得让对方的客户端自报家门。可是，就算正在访问服务器的对方声称自己是ueno,身份是否属实这点却也无从谈起。为确认ueno本人是否真的具有访问系统的权限，就需要核对“登录者本人才知道的信息”、“登录者本人才会有的信息”。
HTTP使用的认证方式：
- BASIC认证(基本认证）
- DIGEST认证(摘要认证)
- SSL客户端认证
- FormBase认证(基于表单认证)
1.BASIC认证
BASIC认证(基本认证)是从HTTP/1.0就定义的认证方式。即便是现在仍有一部分的网站会使用这种认证方式。是Web服务器与通信
客户端之间进行的认证方式。
认证步骤：
步骤一：当请求的资源需要BASIC认证时，服务器会随状态码401Authorization Required,返回带WWW-Authenticate首部字段的响应。该字段内包含认证的方式(BASIC)及Request-URI安全域字符串( realm )。
步骤二：接收到状态码401的客户端为了通过BASIC认证，需要将用户ID及密码发送给服务器。发送的字符串内容是由用户ID和密码构成，两者中间以冒号(😃 连接后，再经过Base64编码处理。假设用户ID为guest，密码是guest，连接起来就会形成guest:guest这样的字符串。然后经过Base64编码，最后的结果即是Z3Vlc3Q6Z3Vlc3Q=。把这串字符串写人首部字段Authorization后，发送请求。当用户代理为浏览器时，用户仅需输人用户ID和密码即可，之后，浏览器会自动完成到Base64编码的转换工作。
步骤三：接收到包含首部字段Authorization请求的服务器，会对认证信息的正确性进行验证。如验证通过，则返回一条包含Request-URI资源的响应。
缺点：BASIC认证虽然采用Base64编码方式，但这不是加密处理。不需要任何附加信息即可对其解码。换言之，由于明文解码后就是用户ID和密码，在HTTP等非加密通信的线路上进行BASIC认证的过程中，如果被人窃听，被盗的可能性极高。
2.DIGEST认证
为弥补BASIC认证存在的弱点，从HTTP/1.1起就有了DIGEST认证。DIGEST 认证同样使用质询/响应的方式( challenge/response)，但不会像BASIC认证那样直接发送明文密码。所谓质询响应方式是指，一开始一方会先发送认证要求给另一方，接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。
认证步骤：
步骤一：请求需认证的资源时，服务器会随着状态码401 Authorization Required，返回带WWW-Authenticate首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码(随机数，nonce)。首部字段WWW-Authenticate内必须包含realm和nonce这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。nonce是一种每次随返回的401响应生成的任意随机字符串。该字符串通常推荐由Base64编码的十六进制数的组成形式，但实际内容依赖服务器的具体实现。
步骤二：接收到401状态码的客户端，返回的响应中包含DIGEST认证必须的首部字段Authorization信息。首部字段Authorization内必须包含username、realm、nonce、uri 和response的字段信息。其中，realm 和nonce就是之前从服务器接收到的响应中的字段username是realm限定范围内可进行认证的用户名。uri ( digest-uri)即Request-URI的值，但考虑到经代理转发后Request-URI的值可能被修改，因此事先会复制一份副本保存在uri内。response也可叫做Request-Digest,存放经过MD5运算后的密码字符串，形成响应码。
步骤三：接收到包含首部字段Authorization请求的服务器，会确认认证信息的正确性。认证通过后则返回包含Request-URI资源的响应。
并且这时会在首部字段Authentication-Info写入一些认证成功的相关信息。
3.SSL客户端认证
从使用用户ID和密码的认证方式方面来讲，只要二者的内容正确，即可认证是本人的行为。但如果用户ID和密码被盗，就很有可能被第三者冒充。利用SSL客户端认证则可以避免该情况的发生。SSL客户端认证是借由HTTPS的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已登录的客户端。
认证步骤：
为达到SSL客户端认证的目的，需要事先将客户端证书分发给客户端，且客户端必须安装此证书。
步骤一：接收到需要认证资源的请求，服务器会发送Certificate Request报文，要求客户端提供客户端证书。
步骤二：用户选择将发送的客户端证书后，客户端会把客户端证书信息以Client Certificate报文方式发送给服务器。
步骤三：服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥，然后开始HTTPS加密通信。
SSL客户端认证采用双因素认证：
在多数情况下，SSL客户端认证不会仅依靠证书完成认证，一般会和基于表单认证组合形成一种双因素认证( Two-factor authentication )来使用。所谓双因素认证就是指，认证过程中不仅需要密码这一个因素，还需要申请认证者提供其他持有信息，从而作为另一个因素，与其组合使用的认证方式。换言之，第一个认证因素的SSL客户端证书用来认证客户端计算机，另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后，就可以确认是用户本人正在使用匹配正确的计算机访问服务器。
4.基于表单认证
基于表单的认证方法并不是在HTTP协议中定义的。客户端会向服务器上的Web应用程序发送登录信息(Credential)，按登录信息的验证结果认证。根据Web应用程序的实际安装，提供的用户界面及认证方式也各不相同。多数情况下，输人已事先登录的用户ID 和密码等登录信息后，发送给Web应用程序，基于认证结果来决定认证是否成功。
七、HTTP缓存
通过把请求/响应缓存起来有助于提升系统的性能，Web 缓存减少了延迟和网络传输量，因此减少资源获取锁需要的时间。由于链路漫长，网络时延不可控,浏览器使用HTTP获取资源的成本较高。所以，非常有必要把数据缓存起来，下次再请求的时候尽可能地复用。当Web缓存在其存储中具有请求的资源时，它将拦截该请求并直接返回资源，而不是到达源服务器重新下载并获取。这样做可以实现两
个小目标：减轻服务器负载，提升系统性能。
1.缓存的类型
HTTP缓存有几种不同的类型，这些可以分为两个主要类别:私有缓存和共享缓存。
- 共享缓存:共享缓存是一种缓存，它可以存储多个用户重复使用的请求/响应。
- 私有缓存:私有缓存也称为专用缓存，它只适用于单个用户。
- 不缓存过期资源:所有的请求都会直接到达服务器，由服务器来下载资源并返回。
2.缓存控制
HTTP/1.1中的Cache-Control 常规标头字段用于执行缓存控制，使用此标头可通过其提供的各种指令来定义缓存策略。下面我们依次介绍一下这些属性：
- 不缓存：
no-store才是真正意义上的不缓存，每次服务器接受到客户端的请求后，都会返回最新的资源给客户端。 - 缓存但需要验证：不缓存过期资源
- 私有和共享缓存：不缓存过期资源
- 缓存过期：缓存中一个很重要的指令就是
max-age，这是资源被视为新鲜的最长时间，与Expires 相反，此指令是相对于请求时间的。对于应用程序中不会更改的文件,通常可以添加主动缓存。 - 缓存验证：
must-revalidate表示缓存必须在使用之前验证过时资源的状态,并且不应使用过期的资源。缓存验证图如下：
3.缓存代理过程
服务器上的缓存会定期进行更新, HTTP作为应用层的协议，它是一种客户-服务器模式，HTTP是无状态的协议，因此当资源发生更改时，服务器无法通知缓存和客户端。因此服务器必须通过某种方式告知客户端缓存已经被更新。服务器会提供过期时间这个概念，告知客户端在此到期时间之前，资源是新鲜的，也就是未更改过的。在此到期时间的范围之外，资源已过时。过期算法(Eviction algorithms) 通常会将新资源优先于陈旧资源使用。
需要注意的是， 过期的资源并不会被回收或忽略，当高速缓存接收到过期资源时，它会使用If-None-Match转发此请求，以检查它是否仍然有效。如果有效，服务器会返回304 Not Modified响应头并且没有任何响应体，从而节省了一些带宽。下面是共享缓存代理的过程：
age是HTTP响应标头告诉客户端源服务器在多久之前创建了响应，它的单位为秒，age标头通常接近于0，如果是0则可能是从源服务器获取的，如果不是表示可能是由代理服务器创建，那么age的值表示的是缓存后的响应再次发起认证到认证完成的时间值。
缓存的有效性是由多个标头来共同决定的，而并非某一个标头来决定。如果指定了Cache-control :max-age=N，那么缓存会保存N秒。如果这个通用标头不存在的话，则会检查是否存在Expires标头。如果Expires标头存在，那么它的值减去Date标头的值就可以确定其有效性。最后，如果max-age 和Expires 都不存在，就去寻找Last-Modified标头，如果存在此标头，则高速缓存的有效性等于Date标头的值减去Last-modified标头的值除以10。
八、HTTP CROS跨域
CROS的全称是Cross-Origin Resource Sharing(CROS) ，中文译为跨域资源共享 ，它是一种机制。是一种让运行在一个域(origin) 上的Web应用被准许访问来自不同源服务器上指定资源的机制。在搞懂这个机制前，需要先了解什么是域(origin)。
1.Origin
Web概念中域(Origin)的内容由scheme(protocol) - 协议，host(domain) - 主机和用于访问它的URL port - 端口定义。仅仅当scheme、host、 port 都匹配时，两个对象才有相同的来源。这种协议相同，域名相同，端口相同的安全策略也被称为同源策略 (Same Origin Policy)。某些操作仅限于具有相同来源的内容，可以使用CROS取消此限制。
2.跨域的特点
协议和域名部分是不区分大小写的，但是路径部分则根据服务器平台而定。Windows 和Mac OS系统是不区分大小写的，而采用UNIX和L inux系的服务器系统是区分大小写的，举例说明：
http://www.example.com
http://myapp.example.com
这两个URL具有跨域问题，主机不同。
http://example.com
http://example.com:8080
这两个URL具有跨域问题，端口不同
http://example.com
https://example.com
这两个URL具有跨域问题，协议不同
3.跨域请求
跨域请求可能会从下面这几种请求中发出:
- 调用
XMLHttpRequest或者Fetchapi。 - Web字体(用于CSS中@ font-face中的跨域字体使用)，以便服务器可以部署TrueType字体,这些字体只能由允许跨站点加载和使用的网站使用。
- WebGL纹理
- 使用drawImage() 绘制到画布上的图像/视频帧
- 图片的CSS形状
4.跨域功能概述
跨域资源共享标准通过添加新的HTTP标头来工作，这些标头允许服务器描述允许哪些来源从Web浏览器读取信息。另外，对于可能导致服务器数据产生副作用的HTTP请求方法(尤其是GET或者具有某些MIME类型POST方法以外HTTP方法)，该规范要求浏览器预检请求，使用HTTP OPTIONS请求方法从服务器请求受支持的方法，然后在服务器批准后发送实际请求。服务器还可以通知客户端是否应与请求一起发送凭据(例如 Cookies和HTTP身份验证)。
5.HTTP响应字段
下面是一些服务器跨域共享规范定义的字段：
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Request-Headers
- Access-Control-Request-Method
- Origin
扫一扫
784
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
