HTTP

超文本传输协议(英语:HyperTextTransferProtocol,缩写:HTTP)是

万维网(World

超文本传输协议(英语:HyperTextTransferProtocol,缩写:HTTP)是

万维网(World

已经发生了太多的变化,在保持协议简单性的同时,不断扩展其灵活性如今,HTTP

已经从一个只在实验室之间交换文档的早期协议进化到了可以传输图片,高分辨率视频和

HTTP

[欧洲核子研究组织](https://zh.wikipedia.org/wiki/

[蒂姆・伯纳斯

](https://zh.wikipedia.org/wiki/

提姆・柏內茲

BernersLee博士提出了一种能让远隔两地的研究者们共享知识的设想。

最初设想的基本理念是借助多文档之间相互关联形成的超文本HyperText连成可相互参阅的

WWWWorld

编写了三项基本技术来实现设想这些技术仍然是当今网络的基础您可能已经在网络浏览器的某些部分上看到过这些技术

HTMLHyperText

年提出。

它是有史以来最简单的协议它的请求由单行指令构成因此也称为单行协议以唯一可用方法

GET

开头其后跟目标资源的路径一旦连接到服务器协议、服务器、端口号这些都不是必须的。

http

文件可以传送无法传输其他类型的文件。

也没有状态码或错误代码。

一旦出现问题一个特殊的包含问题描述信息的

HTML

等。

这导致在处理复杂的应用逻辑和实现数据更新等操作时HTTP/0.9

只能传输

连接请求完成后立即关闭连接。

这导致在处理大量请求时频繁地建立和关闭连接会带来较大的开销影响性能。

安全性问题

没有提供任何加密和安全机制所有的数据都是明文传输。

这使得数据容易受到窃听和篡改缺乏对隐私和数据完整性的保护。

只能传输英文文本数据

只能传输英文文本数据无法支持其他语言的文本数据比如包含非英文字符的文本如中文、日文、俄文等。

HTML

的许多缺陷我们需要一个协议该协议不仅可以服务于超文本文档还可以提供有关请求和响应的更丰富的元数据。

很快HTTP

响应的结构加入许多头部信息现在可以处理其他响应格式即图像、视频文件、纯文本或任何其他内容类型。

它添加了更多方法即

POST

HEAD、添加了状态代码来标识响应、引入了字符集、类型、授权、缓存、内容编码等内容。

HTTP/1.0

响应的格式我们沿用至今并且由于加入头信息使得内容协商变得容易起来这也极大的丰富了它的扩展性虽然请求和响应标头仍保留为

ASCII

编码但响应正文可以是任何类型即图像、视频、HTML、纯文本或任何其他内容类型。

因此现在服务器不仅仅只能向客户端发送

HTML

编码仅表示了英文小大写、数字以及一些标点符号对于其他国家的语言是并不支持的那么请求头中的其他国家的语言的信息如何处理呢

HTMLURLwangjunliang.com/我想看看.html

请求网址:

strict-origin-when-cross-origin惊奇的发现在请求头中

我想看看

%E6%88%91%E6%83%B3%E7%9C%8B%E7%9C%8B这就是传说中的

URL

编码后的请求后会将其还原为原始的中文字符进行处理。

需要注意的是HTTP/1.0

URL

HTTP/1.0由于对字符集的限制以及内容协商机制缺失与不完善直接传输二进制数据或非

ASCII

在响应的起始行中加入了状态代码和状态的描述信息提供了关于请求处理结果的信息以便客户端和服务器能够进行适当的处理和决策。

虽然在

Content-Type、Content-Length、Transfer-Encoding

等头部属性可以对不同类型的文件在消息体中进行不同的编码。

也就是说起始行、头部信息传输仍是

ASCII

Set解决了其他国家语言文本数据的字符编码问题并确保文本数据能够以正确的方式被处理和显示。

初步引入缓存概念

的新标头来克服短连接问题但它仍然没有得到广泛的支持问题仍然存在。

请求阻塞

中每个请求都需要按照顺序进行即必须等待前一个请求的响应返回后才能发送下一个请求。

如果前一个请求很耗时会导致后续请求被阻塞影响并发性能。

无状态

是一种无状态协议即服务器不维护有关客户端的信息当客户端需要记录状态时必须发送一些记录状态的冗余数据从而导致带宽使用量增加。

缺乏压缩支持

没有内置的数据压缩机制因此在传输大量文本数据时没有有效地压缩数据增加了网络传输的开销。

安全性问题

没有提供任何加密和安全机制所有的数据都是明文传输。

这使得数据容易受到窃听和篡改缺乏对隐私和数据完整性的保护。

实现混乱

人们诟病的是它的文件类型支持不够丰富由于它的文件类型支持不丰富所有通常只是请求

HTML

丰富了文件类型后一次请求不再能获取到全部内容并且请求的内容也从较小的

HTML

标准消除了早期版本中大量歧义内容并引入了许多关于性能优化的措施持久链接、管道化技术、支持范围请求和部分响应、分块传输机制、明确缓存控制机制、增加压缩技术、增强内容协商机制、增加客户端

cookie

还新增状态码、引入了基本认证和摘要认证提供更强大的用户认证机制确保更安全的通信、

Host

头字段该字段允许在同一个物理服务器上托管多个域名。

这使得虚拟主机能够通过在

Host

头中指定域名来区分不同的网站、并且它还新增了许多请求方法极大丰富了请求类型。

http

/zh-CN/docs/Glossary/Simple_header

HTTP/1.1

text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8

Accept-Language:

https://developer.mozilla.org/zh-CN/docs/Glossary/Simple_header以下为HTTP/1.1

http

547fa7e369ef56031dd3bff2ace9fc0832eb251a

Keep-Alive:

中连接默认情况下不会关闭而是保持打开状态从而允许多个顺序请求。

要关闭连接请求头

Connection:

必须可用。

客户端通常在最后一个请求中发送此标头以安全地关闭连接。

管道化技术

引入了管道化技术以解决请求阻塞问题客户端可以在同一连接上向服务器发送多个请求而无需等待服务器的响应并且服务器必须按照接收请求的顺序发送响应。

新增客户端

是无状态协议当客户端需要记录状态时必须发送一些记录状态的冗余数据从而导致带宽使用量增加。

HTTP/1.1

cookie

cookie服务器可以跟踪用户会话状态实现用户身份认证个性化用户体验等。

Gzip、Deflate

字段来指示客户端该响应已经被压缩以及压缩的算法。

客户端收到压缩的响应后会自动解压缩以获取原始内容。

HTTP/1.1

中可以通过基本认证和摘要认证机制在请求头中传递用户名和密码等凭据进行用户身份验证。

HTTP/1.1

字段指示返回内容的字节范围。

这使得客户端可以请求大文件的特定部分例如断点续传的情况下从而避免重新下载整个文件。

此外范围请求还能让客户端只获取媒体资源的特定片段优化数据传输并提升用户体验。

HTTP/1.1

Encoding机制用于在动态内容传输时服务器无法提前确定整个内容的长度的情况下逐块发送内容。

在分块传输中服务器将响应拆分为一系列块每个块都有一个独立的大小并使用

“Transfer-Encoding:

请求头来通知客户端有关分块传输的信息。

客户端接收到该头信息后知道响应将以分块的形式传输它可以按照指定的块大小逐块接收内容直到接收到一个长度为零的块表示传输已完成。

这种机制适用于动态生成内容、流式传输以及服务器长时间运行的响应等场景提供了更灵活和高效的数据传输方式。

明确缓存机制

的基础上进一步明确了缓存机制服务器可以通过设置响应头字段来控制缓存行为例如使用

“Cache-Control”

用于要求客户端验证资源的有效性等。

同时服务器也可以在响应头中添加

“Expires”

头字段设置资源的过期时间以便客户端在接收到资源后在过期时间之前可以直接使用缓存的副本。

另外HTTP/1.1

还支持

头字段用于在客户端缓存资源后再次请求时验证资源是否已经发生变化如果未变化服务器返回

304

状态码让客户端使用缓存的资源从而避免重复传输。

通过这些头字段的灵活组合使用HTTP/1.1

Web

Accept-Language、Accept-Encoding

Accept-Charset

等头字段允许客户端明确指定其首选语言、内容编码方式和字符集让服务器能够更好地提供适配客户端需求的内容。

此外HTTP/1.1

Vary

头字段用于标明服务器响应可能因客户端请求头的不同而变化这样确保代理服务器能够存储和提供正确的缓存内容。

这些改进使得

HTTP/1.1

头字段该字段允许在同一个物理服务器上托管多个域名。

这使得虚拟主机能够通过在

Host

在同一连接上使用持久连接但由于串行发送请求和响应如果一个请求或响应的处理时间较长那么后续的请求和响应将被阻塞为此它引入了管道化技术

(pipelining)

试图解决该问题但它并没有完全解决这个问题因为即使在客户端请求选择某一管道并被异步发送出去但在服务器如果该请求前面存在缓慢或繁重的请求那么该请求就会被阻塞。

这种情况也被称为线头阻塞

在处理较多的并发请求时表现较差。

浏览器限制了同时与同一域名建立的连接数针对同一域名的并发请求最多可以同时发送

个如果有超过限制的请求需要发送浏览器会将这些请求放入队列从而限制了并发请求的数量。

TCP

客户端和浏览器必须要另辟蹊径的去找到新的解决方案来降低页面载入时间。

明文传输

默认是明文传输数据在网络上传输时不加密可能被窃听或篡改。

这会导致安全隐患尤其是对于敏感信息的传输。

头部冗余

的请求和响应头部会携带一些冗余的信息导致了较大的头部开销特别是对于小的资源请求。

没有对头字段进行压缩

响应模式每个请求需要等待响应后才能继续。

这种模式对于实时性要求较高的应用场景如实时通信和流媒体效率较低。

缺乏推送功能

缺乏服务器主动向客户端推送资源的机制。

客户端只能通过不断发送请求来获取资源这导致了一定的延迟和额外的开销。

HTTP/1.1

也做了多次扩展与修改并发展不同的应用模式以弥补之前的缺陷以及满足日益进步的需求。

HTTP

Corporation为了解决当时互联网上数据传输的安全问题发布了第一个安全套接字层Secure

Sockets

传输过程中的数据使得网站和用户之间的通信不再以明文传输变得安全。

HTTP

以允许查看和修改其数据而无需更新浏览器或服务器。

所有需要的内容都被嵌入到由网站通过标准

HTTP/1.1

这些年来网页愈渐变得的复杂甚至演变成了独有的应用可见媒体的播放量增进交互的脚本大小也增加了许多。

如果仔细观察当前的一些网站所需要下载的资源的话会发现一个非常明显的趋势

近年来加载网站首页需要的下载的数据量在逐渐增加平均每个页面为了完成显示与渲染所需要下载的资源数已经超过了

100

客户端和浏览器必须要另辟蹊径的去找到新的解决方案来降低页面载入时间。

与此同时人们也尝试去用新的协议来替代

TCP

的功能包括多路复用、压缩、优先级、安全性等。

本节不打算详细介绍

HTTP/2

的升级需要制定非常严格的边界与观念这也给小组成员的创新带来了一些许限制。

必须保持早期

使用年限久远用户数量庞大使用该协议的网站太多了如果改动过大且费力这肯定会阻碍

HTTP/2.0

不需要站点和应用做出改变拥有一个最新的服务器和新点的浏览器即可升级

URI

的方案提供一个首部字段表示允许服务器在收到旧协议请求的同时可以向客户端发送新协议的响应。

但这一方案往往需要花费一次额外的往返通信来作为升级的代价。

SPDY

Negotiation借助于此服务器会通知客户端所有它支持的协议让客户端从中选择一个合适的来进行通讯。

HTTP1

或者彻底不兼容。

如果将来该协议需要被扩充或者变更那么新的协议将会是

http

协议变为一个二进制协议其主要特性是多路复用multiplexing它可以通过同一个

TCP

连接发送多个逻辑数据流。

复用使得很多事情变得更快更好它带来更好的拥塞控制、更充分的带宽利用、更长久的

TCP

这些都比以前更好了链路能更容易实现全速传输标头压缩技术也减少了带宽的用量。

采用

HTTP/2

“去分片”desharding技术还可以进一步缩减连接数。

HTTP/2

HTTP

blocking问题客户端必须等待一个请求完成才能发送下一个请求的日子过去了。

http

/zh-CN/docs/Glossary/Simple_header

HTTP/2

text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8

Accept-Language:

https://developer.mozilla.org/zh-CN/docs/Glossary/Simple_header

http

547fa7e369ef56031dd3bff2ace9fc0832eb251a

Keep-Alive:

开发者做什么不需要站点和应用做出改变随着陈旧的浏览器和服务器的更新站点自然就会升级到

HTTP/2.0

而不会带来任何问题并且还能在数据传输上节省了可观的成本和支出这使得该协议在互联网和万维网上得到广泛的实现和部署HTTP/2.0

HTTP/2.0

ID并且它被分成帧。

帧不过是二进制数据帧的集合称为流。

每个帧都有一个流

Length,

现在是二进制协议并且正如我上面所说它使用帧和流来进行请求和响应因此一旦打开

TCP

连接所有流都会通过同一连接异步发送而无需打开任何其他连接。

反过来服务器以相同的异步方式响应即响应没有顺序客户端使用分配的流

HTTP/1.x

中存在的线头阻塞问题即客户端不必等待正在花费时间的请求其他请求仍将得到处理。

流优先级Stream

“权重”它被用来告诉对客户端哪个流更重要。

当资源有限的时候服务器会根据优先级来选择应该先发送哪些流。

借助于借助于

PRIORITY

帧客户端同样可以告知服务器当前的流依赖于其他哪个流该功能让客户端能建立一个优先级

“树”所有

的传输完成情况。

优先级和依赖关系可以在传输过程中被动态的改变。

这样当用户滚动一个全是图片的页面的时候浏览器就能够指定哪个图片拥有更高的优先级。

或者是在你切换标签页的时候浏览器可以提升新切换到页面所包含流的优先级。

优先级的引入确保重要资源的优先加载提高了页面加载速度和用户体验。

头部压缩

是一种无状态的协议。

简而言之这意味着每个请求必须要携带服务器需要的所有细节而不是让服务器保存住之前请求的元数据这导致许多请求和响应头部会携带一些冗余的一摸一样的信息增大了标头大小致使带宽使用和延迟增加。

为了克服这个问题HTTP/2

HPACK

算法对头部信息进行压缩减少了头部大小从而降低了传输的数据量提高了效率。

服务器推送

的服务器推送功能允许服务器在客户端请求前主动推送资源。

服务器可以通过发送一个名为

PUSH_PROMISE

ID。

通过服务器推送服务器可以在客户端请求之前主动将客户端可能需要的资源发送到客户端缓存中从而避免了客户端额外的请求减少了延迟。

这种特性在某些情况下可以提高页面加载速度和性能尤其是对于一些预加载资源或常用资源可以减少客户端请求的往返次数优化了

Web

链接但也不总是可以这样但这样导致的代价就是需要通过三次握手来重新建立一个新的

TCP

帧来实现这种需求它是一种特殊的帧类型用于中止某些流即客户端可以发送此帧让服务器知道我不需要此流了。

客户端可以使用

RST_STREAM

支持数据的流量控制和优先级设置保障了数据的可靠传输。

此外HTTP/2

要求使用

运行多个流并为每个流独立实现数据包丢失检测和重传因此如果发生错误只有该数据包中包含数据的流才会被阻止。

RFC

报文是网络中交换和传输的数据单元即站点一次性要发送的数据块。

报文包含了将要发送的完整的数据信息其长短很不一致长度不限且可变。

HTTP

报文都是纯文本不是二进制代码所以人们可以很方便地对其进行读写。

如果说

HTTP

报文会像河水一样流动不管是请求报文还是响应报文所有报文都会向下游流动。

所有报文的发送者都在接受者的上游。

如下图所示对请求报文来说代理

位于代理

报文是简单的格式化文本。

如下图所示。

每条报文都包含一条来自客户端的请求或者一条来自服务器的响应。

它们由三部分组成对报文进行描述的起始行、包含属性的首部块以及可选的、包含数据的主体部分。

HTTP

服务器请求一个动作。

响应报文会将请求的结果返回给客户端。

请求报文和响应报文的基本报文结构相同。

method

headersentity-body下面是对报文格式各部分的解释

method

客户端希望服务器对资源执行的动作。

是一个单独的词如GET、HEAD、POST。

request-URL

可以有零个或多个首部每个首部都包含一个名字后面跟着一个冒号(:)然后是一个可选的空格接着是一个值最后是一个

(CRLF)

包含一个由任意数据组成的数据块。

并不是所有的报文都包含实体的主体部分。

有时报文只是以一个

CRLF

报文都以一个起始行作为开始。

请求报文的起始行说明了要做些什么。

响应报文的起始行说明发生了什么。

请求行。

请求报文请求服务器对资源进行一些操作。

请求报文的起始行称为请求行包含一个方法和一个请求

URL

响应行。

响应报文承载了状态信息和操作产生的所有结果数据将其返回给客户端。

响应报文的起始行称为响应行包含了响应报文使用的

HTTP

版本、数字状态码以及描述状态码的文本信息的原因短语。

所有的这些字段都由空格符分隔。

在

HTTP/1.0

方法。

请求的起始行以方法作为开始方法用来告知服务器要做些什么。

HTTP

设计得易于扩展所以除了这些方法以外其他服务器可能还会是实现一些自己的请求方法称为扩展方法。

客户端向一个

服务器发送请求报文时会发生很多事情。

状态码是在每条响应报文的起始行中返回的。

原因短语。

是响应起始行中最后一个组件。

为状态码提供了文本形式的解释。

例200

中OK

应用程序提供了一种将自己所遵循的协议版本告知对方的方式。

版本号说明了应用程序支持的最高版本。

版本好不会被当作小数来处理。

版本的每个数字都回被当成一个单独的数字来处理。

因此每个数字都必须单独进行比较以便确定哪个版本更高。

比如HTTP/2.22

HTTP/2.3

首部字段向请求和响应报文中添加一些附加信息。

从本质上来说它们只是一些名

首部分类

协议没有限制请求行的长度。

但是出于各种原因的考虑各家的浏览器、服务器端都做了不同程度的限制。

1、浏览器限制

request-line、request-header、request-body

request-header

分隔。

协议中也没有显示限制请求头的大小。

但是出于各种原因的考虑各家的浏览器、服务器端都做了不同程度的限制。

1、浏览器限制

出于安全考虑我们必须在服务器端对请求头大小进行限制由于存放的信息比较简单因此建议值不应超过

三、请求体【request-body】

是支持文件传输的文件的二进制数据不是放在请求行或者请求头里面它是放在请求体里面的。

1、浏览器限制

如果浏览器对请求体大小做限制可能会影响文件的传输因此浏览器本身没有对请求体做大小限制。

2、服务端限制

出于安全考虑我们必须在服务器端对请求体大小进行限制请求体长度的最大值的设置有多方面的因素需要根据业务情况反复调优决定。

考虑以下几方面因素

4、请求体设置不能太大防止轻易被

被列入黑名单连接的用户过多可以过后再试网站域名解析到了空间但空间未绑定此域名等情况。

6、Http/1.1

表示服务器内部程序错误出现这样的提示一般是程序页面中出现错误如小的语法错误数据连接故障等。

HTTP

关口过载服务器使用另一个关口或服务来响应用户等待时间设定值较长

505——

请求者应当继续提出请求。

服务器返回此代码表示已收到请求的第一部分正在等待其余部分。

101

服务器已成功处理了请求。

通常这表示服务器提供了请求的网页。

如果是对您的

robots.txt

要完成请求需要进一步操作。

通常这些状态码用来重定向。

Google

Googlebot

在抓取重定向网页时是否遇到问题。

诊断下的网络抓取页列出了由于重定向错误导致

Googlebot

服务器目前从不同位置的网页响应请求但请求者应继续使用原有位置来响应以后的请求。

此代码与响应

GET

自从上次请求后请求的网页未修改过。

服务器返回此响应时不会返回网页内容。

如果网页自请求者上次请求后再也没有更改过您应将服务器配置为返回此响应

(称为

请求者只能使用代理访问请求的网页。

如果服务器返回此响应还表示请求者应使用代理。

307

服务器目前从不同位置的网页响应请求但请求者应继续使用原有位置来响应以后的请求。

此代码与响应

GET

网站管理员工具诊断下的网络抓取页面上看到此信息)可能是您的服务器或主机拒绝了

Googlebot

服务器找不到请求的网页。

例如对于服务器上不存在的网页经常会返回此代码。

robots.txt

类似但指定请求者应当授权使用代理。

如果服务器返回此响应还表示请求者应当使用代理。

408

服务器在完成请求时发生冲突。

服务器必须在响应中包含有关冲突的信息。

服务器在响应与前一个请求相冲突的

PUT

这些状态码表示服务器在处理请求时发生内部错误。

这些错误可能是服务器本身的错误而不是请求出错。

500

服务器不具备完成请求的功能。

例如服务器无法识别请求方法时可能会返回此代码。

502

https://junliangwangx.github.io/HTTP-Explanation/docs/overview/the-history-of-http.html

HTTP

https://blog.csdn.net/yipiankongbai/article/details/24176693

【Http】HTTP

https://zhibo.blog.csdn.net/article/details/48342007

HTTP

https://blog.csdn.net/weixin_44498127/article/details/122765290

HTTP

https://blog.csdn.net/ithomer/article/details/10240351

HTTP

https://www.cnblogs.com/yjf512/archive/2013/03/29/2988296.html