HTTP第一阶段笔记

最新推荐文章于 2026-01-05 11:16:35 发布

原创最新推荐文章于 2026-01-05 11:16:35 发布 · 447 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#http #web

本文详细介绍了HTTP协议，包括其作为Web基础的角色，HTTP请求与响应消息的结构，客户端、Web服务器和代理的角色。重点讨论了HTTP消息的结构，如起始行、请求方法、头部和主体，并深入讲解了HTTP的缓存机制，包括缓存的优势、应用、私有缓存、共享缓存以及缓存控制头。此外，文章还涵盖了Cookie的概念、作用、有效期和应用场景，以及跨域资源共享（CORS）的工作原理和请求类型。

HTTP是什么

HTTP(超文本传输协议)，是互联网上应用嘴广泛的一中网络协议。

HTTP协议是在Web上进行数据交换的基础，是一种“客户端–服务器端”的协议。也就是说，请求通常是由像浏览器这样的接收方发起的。一个完整的Web文档通常是由不同的子文档拼接而成的，像是文本，布局描述，图片，视频，脚本等等。

设计HTTP最初的目的是为了提供一种发布和接受HTML页面的方法。

HTTP请求与响应消息

客户端和服务端通过交换各自的消息（与数据流正好相反）进行交互。

由像浏览器这样的客户端发出的消息叫请求（requests）
被服务器回应的消息叫做响应（responses）

在这里插入图片描述

基于HTTP的组件概述

请求通过一个实体被发出，实体也就是用户代理（浏览器）。每一个发送到服务器的请求，都会被服务器处理并返回一个消息，也就是响应。

在这个请求与回应之间，还有许许多多的被称为proxies的实体，他们的作用与表现各不相同。

在这里插入图片描述

客户端

user-agent就是任何能够为用户发起行为的工具。这个角色通常是由浏览器来扮演。一些例外情况，比如是工程师使用的程序，以及Web开发人员调试应用程序。

浏览器总是作为发起一个请求的实体。浏览器首先发送一个请求来获取页面的HTML文档，在解析文档中的资源信息发送其他请求，获取可执行脚本或CSS样式来进行页面布局渲染，以及一些其他页面资源（例如图片，视频等等）。然后，浏览器将这些资源整合到一起，展现出一个完整的文档，也就是网页。

在这里插入图片描述

Web服务器

在HTTP协议通信过程的另一端，是由Web服务器来服务并提供客户端所请求的文档。服务器只是虚拟意义上代表一个机器：它可以是共享负载（负载均衡）的一组服务器组成的计算机集群，也可以是一种复杂的软件，通过向其他计算器（如缓存，数据库服务器，电子商务服务器等）发起请求来获取部分或全部资源。

Web服务器不一定是一台机器，但一个机器上可以装载的众多Web服务。

代理（proxies）

在浏览器和服务器端之间，有许多计算机和其他设备转发了HTTP消息。由于Web栈层次结构的原因，它们大多都出现在传输层，网络层和物理层上，对于HTTP应用层而言都是透明的，虽然它们可能会对应用层性能有重要影响。还有一部分是表现在应用层上的，被称为代理（proxies）。代理既可以表现的透明，又可以不透明。

代理主要有如下几种作用：

缓存（可以是公开的也可以是私有的，像浏览器的缓存）
过滤（例如反病毒扫描）
负载均衡（让多个服务器服务不同的请求）
认证（对不同资源进行权限管理）
日志记录（允许存储历史信息）

HTTP消息是什么

HTTP报文，又称为HTTP消息，是服务器和客户端之间交换数据的方式。请求和响应

HTTP消息由采用ASCII编码的多行文本构成。在HTTP/1.1及早期版本中，这些消息通过连接公开地发送。

在HTTP/2中，为了优化和性能方面的改进，曾经可人工阅读的消息被分到多个HTTP帧中。

HTTP请求报文

请求报文由一下元素组成：

Method方法（一些像post，get这样的方法）
要获取的资源的路径
HTTP版本协议号
为服务端表达其他信息的可选头部headers

在这里插入图片描述

HTTP响应消息

响应报文由一下元素组成：

HTTP协议版本号
一个状态码
一个状态信息
HTTPheaders
包含获取资源的body

HTTP消息结构

HTTP请求消息和响应消息具有相似的结构，由以下部分组成：

start line：一行起始行用于描述要执行的请求，或者是对应的状态，成功或失败。这个起始行总是单行的。
HTTP headers：一个可选的HTTP头部集合指明请求或描述消息正文。
empty line：一个空行指示所有关于请求的元数据已经发送完毕。
body：一个可选的包含请求相关数据的正文（比如HTML表单内容），或者响应相关的文档。正文的大小有起始行的HTTP头来指定。

起始行和HTTP消息中的HTTP头统称为“请求头”，而其有效负载被称为“消息正文“。

在这里插入图片描述

起始行

起始行包括三个元素：

请求方法：描述要执行的动作。例如get表示要获取资源，post表示要向服务器推送数据。

请求地址：通常是一个url，或者是协议、端口和域名的绝对路径。

HTTP版本：定义了剩余报文的结构，作为对期望的响应版本的指示符。

GET/home.html HTTP/1.1

请求方法

HTTP协议定义了一组请求方法，以表明要对给定资源执行的操作，指示针对给定资源要执行的期望动作。

get：请求一个指定资源的表示形式，只被用于获取数据
post：用于推送数据
head
put
delete
connect
options
trace
patch

请求头

请求头允许客户端向服务器端传递附加信息。请求头由名称后跟一个冒号，冒号后跟具体的值组成。

根据不同上下文，可将请求头分为：

通用头：同时适用于请求和响应消息，但与最终消息主体中传输的数据无关的消息头。
请求头：包含更多有关要获取的资源或客户端本身消息的消息头。
实体头：包含有关实体主体的更多消息，比如主体长（Content-Length）度或其MIME类型。

在这里插入图片描述

请求主体

请求消息的最后一部分是请求主体：

不是所有的请求都需要请求主体：例如get，gead，delete
有些请求将数据发送到服务器以便更新数据：常见的是post

请求主体大致可分为两类：

单一资源主体：由一个单文件组成。该类型请求主体由两个header定义：Content-Type和Conten-length
多资源主体：由多个部分请求主体组成，每一部分包含不同的信息位，通常是和HTML表单联系在一起的

状态行

HTTP响应消息的起始行被称作状态行，包含以下信息：

协议版本：通常为HTTP/1.1
状态码：表名请求是成功或失败。常见的例如404，200
状态文本：一个简短的，纯粹的信息，通过状态码的文本描述，帮助人们理解该HTTP消息

HTTP/1.1 200 OK

响应头

响应头允许服务器端向客户端传递附加信息。响应头由名称后跟一个冒号，冒号后跟具体的值组成。

根据不同上下文，可将响应头分为：

通用头：同时适用于请求和响应消息，但与最终消息主体中传输的数据无关的消息头。
响应头：包含有关响应的补充信息，如位置或服务器本身的消息头。
实体头：包含有关实体主体的更多消息，比如主体长（Content-Length）度或其MIME类型。

在这里插入图片描述

响应主体

响应消息的最后一部分是响应主体。不是所有的响应都需要响应主体：例如具有状态码的响应，通常不会有响应主体。

响应主体大致分为两类：

单一资源主体：由已知长度的单个文件组成。该类型响应主体由两个header定义：Content-Type和Content-Length
单一资源主体：由未知长度的单个文件组成，通过将Transfer-Encoding设置为chunked来使用chunks编码
多资源主体：由多部分响应主体组成，每部分包含不同的信息段。但这是比较少见的。

MIME类型

MIME类型被译为多用途Internet邮件扩展类型，是一种标准化的方式来表示文档的性质和格式。

浏览器通常使用MIME类型（而不是文件扩展名）来确定如何处理文档；因此服务器设置正确以将正确的MIME类型附加到响应对象的头部是非常重要的。

text：表明文件是普通文本
image：表明是某种图像
audio：表明是某种音频文件
video：表明是某种视频文件
application：表明是某种二进制数据

HTTP的缓存机制

缓存是一种保存资源的副本并在下次请求时直接使用本地副本的技术。当Web缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器重新下载。

缓存需要合理配置，因为并不是所有资源都是永久不变的。重要的是对一个资源的缓存应截止到其下一次发生改变（即不能缓存过期的资源）

缓存的优势

缓解服务器端的资源消耗和运行压力，提升服务器端的整体性能
减少服务器端资源加载的延迟，进而减少显示某个资源所用的时间
减少对带宽造成的压力，避免网络阻塞问题的出现
Web站点变得更有响应性

缓存应用

常见的HTTP缓存只能存储GET响应，对于其他类型响应无能为力。

普遍的缓存案例：

检索请求的成功响应：响应状态码为200，则表示成功。
不变的重定向：响应状态码为301
不完全的响应：响应状态码为206，只返回局部的信息
除了GET请求外，如果匹配到作为一个已经被定义的cache键名的响应。

私有缓存

私有缓存只能用于单独用户。浏览器缓存拥有用户通过HTTP下载的所有文档。这些缓存为浏览过的文档提供向前/向后导航、保存网页、查看源代码等更能。可以避免再次向服务器发送多余的请求。它同样可以提供缓存内容的离线浏览。

Cache-Control：private

共享缓存

共享缓存可以被多个用户使用。例如，ISP或所在的公司可能会架设一个Web代理来作为本地网络基础的一部分提供给用户。这样热门的资源距会背重复使用，减少网络拥堵与延迟。

Cache-Control:public

缓存控制

Cache-control头

HTTP/1.1定义的Cache-Control头用来区分对缓存机制的支持情况，请求头和响应头都支持这个属性。通过它提供的不同的值来定义缓存策略。

禁止进行缓存

Cache-Control:no-store
Cache-Control:no-cache,no-store,must-revalidate

强制确认缓存
```
Cache-Control:no-cache
```
缓存过期机制
```
Cache-Control:max-age=31536000
```
缓存验证确认
```
Cache-Control:must-revalidate
```

Pragma头

Pragma头是HT TP/1.0标准中定义的一个header属性，请求中包含Pragma的效果跟在头信息中定义“Cache-Control: no-cache" 相同。但是HT TP的响应头不支持这个属性，所以它不能拿来完全替代HT TP/1.1中定义的Cache-control头。通常定义Pragma以向后兼容基于HT TP/1.0的客户端。

Pragma: no-cache

Expires头

Expires响应头包含日期/时间，即在此时候之后，响应过期。

无效的日期，比如0代表着过去的日期，即该资源已经过期。
如果在Cache-Control响应头设置了“max- -age”或者“s -max- -age”指令，那么Expires头会被忽略。

Expires: Wed, 10 Aug 2020 22:11:00 GMT

Cookie是什么

Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。

通常，Cookie用于告知服务器端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie使基于无状态的HTTP协议记录稳定的状态信息成为了可能。Cookie技术产生源于HTTP协议在互联网上的急速发展。

Cookie曾一度用于客户端数据的存储，因当时并没有其他合适的存储办法而作为唯一的存储手段。但现在随着现代浏览器开始支持各种各样的存储方式，Cookie渐渐被淘汰。由于服务器指定Cookie后，浏览器的每次请求都会携带Cookie数据，会带来额外的性能开销。

在这里插入图片描述

Cookie的作用域问题

Domain和Path标识定义了Cookie的作用域，即Cookie应该发送给哪些URL。

Domain标识指定了哪些主机可以接受Cookie。
- 如果不指定，默认为当前文档的主机(不包含子域名)。
- 如果指定了Domain,则一般包含子域名。例如，如果设置Domain=wolongxueyuan.com,则Cookie也包含在子域名中(如developer.wolongxueyuan.com)。
Path标识指定了主机下的哪些路径可以接受Cookie (该URL路径必须存在于请求URL中)。以字符%x2F("/")作为路径分隔符，子路径也会被匹配。

Cookie的有效期

Max-Age和Expires标识定义了Cookie的有效期，即Cookie的生命周期。

会话期Cookie
- 会话期Cookie是最简单的C Cookie。浏览器关闭之后Cookie会被自动删除，也就是说Cookie仅在会话期内有效。会话期Cookie不需要指定过期时间( Expires )或者有效期(Max-Age)。
持久性Cookie
- 持久性Cookie可以指定一个特定的过期时间( Expires )或有效期(Max-Age )。

Cookie的应用

会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
个性化设置(如用户自定义设置、主题等)
浏览器行为跟踪(如跟踪分析用户行为等)

访问与更新Cookie

创建Cookie

JavaScript可以使用document.cookie属性来访问和更新Cookie。语法结构如下所示:

document.cookie = newCookie;

newCookie是一个键值对形式的字符串。需要注意的是，用这个方法一次只能对一个cookie置或更新。

document.cookie = "name=wolongxueyuan";
document.cookie = "someCookieName=true; expires=Fhf, 31 Dec 9999 23:59:59 GMT; path=/";

读取Cookie

JavaScript可以使用document.cookie属性来访问和更Cookie。语法结构如下所示:

allCookies = document.cookie;

allCookies被赋值为一个字符串，该字符串包含所有的Cookie,每条cookie以分号分隔(即key=value键值对)。

修改Cookie

重新给要修改的cookie赋值就行，这样旧的就会被覆盖掉

删除Cookie

JavaScript删除Cookie只需要设置Expires标识为以前的时间即可。当删除时不必指定Cookie的值，如下所示:

document.cookie = "username=; expires=Thu, 01 Jan 1970 00:00:00 GMT";

HTTP的Cookie

Set-Cookie响应头

服务器使用Set-Cookie响应头部向用户代理(一般是浏览器)发送Cookie信息。

Set-Cookie: <cookie名>=<cookie值>

服务器通过该头部告知客户端保存Cookie信息。

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

[页面内容]

在这里插入图片描述

Cookie请求头

对服务器发起的每一次新请求，浏览器都会将之前保存的Cookie信息通过Cookie请求头部再发送给服务器。

GET /sample_page.html HTTP/1.1
Host:www.example.org
Caokie: yummy_cookie=choco; tasty_cookie=strawberry

跨域资源共享是什么

CORS为跨域资源共享的缩写，新增了一组HTTP首部字节段，允许服务器声名哪些源站有权限访问哪些资源。

跨域资源共享标准规范要求，对那些可能对服务器数据产生副作用的HTTP请求方法（特别是get以外的HTTP请求，或者搭配某些MIME类型的post请求），浏览器必须首先使用options方法发起一个预检请求，从而获知服务端是否允许该跨域请求。服务器确认允许之后，才发起实际的HTTP请求。在预检请求的返回中，服务器端也可以通知客户端，是否需要携带身份凭证。

跨域资源共享机制的工作原理主要应用于三个场景：

简单请求
预检请求
认证请求

简单请求

请求同时满足所有下述条件，则该请求可视为“简单请求”:

使用下列请求方法之一: GET、HEAD或POST
不得人为设置下列集合之外的其他首部字段: Accept、 Accept-Language、Content-Language、Content- Type
Content-Type的值仅限于下列三者之一:
- text/plain
- multipart/form-data
- application/x-www-form-udlencoded

值得注意的是，这些跨域请求与浏览器发出的其他跨域请求并无一致。如果服务器未返回正确的响应首部，则请求方不会收到任何数据。因此，那些不允许跨域请求的网站无需为这一新的HT TP访问控制特性担心。

请求消息

请求首部字段Origin表示该请求来源于http://foo.exmaple, Origin的值是每次发送请求时自动携带的请求首部消息。

响应消息

响应中携带了响应首部字段Access Control Allow-Origin,使用Origin和Access -Control-Allow-Origin就能完成最简单的访问控制。

预检请求

当请求满足下述任一条件时，即应首先发送预检请求:

使用下列请求方法之一: PUT、DEL ETE、CONNECT、OPTIONS、TRACE或PATH
不得人为设置下列集合之外的其他首部字段: Accept、 Accept-Language、Content-Language、Content- Type
Content- Type的值仅限于下列三者之一:
- text/plain
- multipart/form-data
- application/x-www-form uclencoded

预检请求要求必须首先使用OPTIONS方法发起一个预检请求到服务器，以获知服务器是否允许该实际请求。

预检请求可以避免跨域请求对服务器的用户数据产生未预期的影响。