HTTPS & HSTS All In One

HTTPS & HSTS All In One

rfc6797 pdf

https://www.rfc-editor.org/rfc/pdfrfc/rfc6797.txt.pdf

HSTS

HTTP Strict Transport Security informs browsers that the site should only be accessed using HTTPS.

SSL

SSL 3.1

TLS

TLS 1.3 ✅

HTTP

https://zh.wikipedia.org/zh-cn/超文本传输协议#版本

HTTP/0.9

HTTP/1.0

HTTP/1.1

默认采用持续连接（Connection: keep-alive），能很好地配合代理服务器工作。还支持以管道方式在同时发送多个请求，以便降低线路负载，提高传输速度。

HTTP/1.1相较于HTTP/1.0协议的区别主要体现在：

缓存处理
带宽优化及网络连接的使用
错误通知的管理
消息在网络中的发送
互联网地址的维护
安全性及完整性

https://zh.wikipedia.org/zh-cn/超文本传输协议#HTTP/1.1

HTTP/2

在HTTP/2的第一版草案（对SPDY协议的复刻）中，新增的性能改进不仅包括HTTP/1.1中已有的多路复用，修复队头阻塞问题，允许设置设定请求优先级，还包含了一个头部压缩算法（HPACK）。此外， HTTP/2采用了二进制而非明文来打包、传输客户端和服务器之间的数据。

帧、消息、流和TCP连接
有别于HTTP/1.1在连接中的明文请求，HTTP/2与SPDY一样，将一个TCP连接分为若干个流（Stream），每个流中可以传输若干消息（Message），每个消息由若干最小的二进制帧（Frame）组成。这也是HTTP/1.1与HTTP/2最大的区别所在。HTTP/2中，每个用户的操作行为被分配了一个流编号（Stream ID），这意味着用户与服务端之间建立了一个TCP通道；协议将每个请求分割为二进制的控制帧与数据帧部分，以便解析。这个举措在SPDY中的实践表明，相比HTTP/1.1，新页面加载可以加快11.81%到47.7%

HPACK 算法
HPACK算法是新引入HTTP/2的一个算法，用于对HTTP头部做压缩。其原理在于：

客户端与服务端根据RFC 7541的附录A，维护一份共同的静态字典（Static Table），其中包含了常见头部名及常见头部名称与值的组合的代码；
客户端和服务端根据先入先出的原则，维护一份可动态添加内容的共同动态字典（Dynamic Table）；
客户端和服务端根据RFC 7541的附录B，支持基于该静态哈夫曼码表的哈夫曼编码（Huffman Coding）。
服务器推送
网站为了使请求数减少，通常采用对页面上的图片、脚本进行极简化处理。但是，这一举措十分不方便，也不高效，依然需要诸多HTTP链接来加载页面和页面资源。

HTTP/2引入了服务器推送，即服务端向客户端发送比客户端请求更多的数据。这允许服务器直接提供浏览器渲染页面所需资源，而无须浏览器在收到、解析页面后再提起一轮请求，节约了加载时间。

https://zh.wikipedia.org/zh-cn/HTTP/2

HTTP/3

HTTP/3是第三个主要版本的HTTP协议。与其前任HTTP/1.1和HTTP/2不同，在HTTP/3中，将弃用TCP协议，改为使用基于UDP协议的QUIC协议实现。

此变化主要为了解决HTTP/2中存在的队头阻塞问题。由于HTTP/2在单个TCP连接上使用了多路复用，受到TCP拥塞控制的影响，少量的丢包就可能导致整个TCP连接上的所有流被阻塞。

QUIC（快速UDP网络连接）是一种实验性的网络传输协议，由 Google 开发，该协议旨在使网页传输更快。

https://zh.wikipedia.org/zh-cn/HTTP/3

HTTP/4

???

TCP

传输控制协议（英语：Transmission Control Protocol，缩写：TCP）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能。用户数据报协议（UDP）是同一层内另一个重要的传输协议。

在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。

应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分割成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传输单元（MTU）的限制）。之后TCP把结果包传给IP层，由它来透过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的包发回一个相应的确认信息（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据包就被假设为已丢失并进行重传。TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和。

https://zh.wikipedia.org/zh-cn/传输控制协议

UDP

用户数据报协议（英语：User Datagram Protocol，缩写：UDP；又称用户数据包协议）是一个简单的面向数据包的通信协议，位于OSI模型的传输层。该协议由David P. Reed在1980年设计且在RFC 768中被规范。典型网络上的众多使用UDP协议的关键应用在一定程度上是相似的。

在TCP/IP模型中，UDP为网络层以上和应用层以下提供了一个简单的接口。UDP只提供数据的不可靠传递，它一旦把应用程序发给网络层的数据发送出去，就不保留数据备份（所以UDP有时候也被认为是不可靠的数据包协议）。UDP在IP数据包的头部仅仅加入了复用和数据校验字段。

UDP适用于不需要或在程序中执行错误检查和纠正的应用，它避免了协议栈中此类处理的开销。对时间有较高要求的应用程序通常使用UDP，因为丢弃数据包比等待或重传导致延迟更可取。

https://zh.wikipedia.org/zh-cn/用户数据报协议

OSI

开放式系统互联模型（英语：Open System Interconnection Model，缩写：OSI；简称为OSI模型）是一种概念模型，由国际标准化组织提出，一个试图使各种计算机在世界范围内互连为网络的标准框架。定义于ISO/IEC 7498-1。

该模型将通信系统中的数据流划分为七个层，从分布式应用程序数据的最高层表示到跨通信介质传输数据的物理实现。每个中间层为其上一层提供功能，其自身功能则由其下一层提供。功能的类别通过标准的通信协议在软件中实现。

开放式系统互联模型的开发始于上世纪70年代后期，用以支持各种计算机联网方法的出现。在上世纪80年代，该模型成为国际标准化组织（ISO）开放系统互连小组的工作产品。

https://zh.wikipedia.org/zh-cn/OSI模型

TCP/IP

互联网协议套件（英语：Internet Protocol Suite，缩写IPS）是网络通信模型，以及整个网络传输协议家族，为网际网络的基础通信架构。它常通称为TCP/IP协议族（英语：TCP/IP Protocol Suite，或TCP/IP Protocols），简称TCP/IP。因为该协议家族的两个核心协议：TCP（传输控制协议）和IP（网际协议），为该家族中最早通过的标准。由于在网络通讯协议普遍采用分层的结构，当多个层次的协议共同工作时，类似计算机科学中的堆栈，因此又称为TCP/IP协议栈（英语：TCP/IP Protocol Stack） 。这些协议最早发源于美国国防部（缩写为DoD）的ARPA网项目，因此也称作DoD模型（DoD Model）。这个协议族由互联网工程任务组负责维护。

TCP/IP提供了点对点链接的机制，将资料应该如何封装、寻址、传输、路由以及在目的地如何接收，都加以标准化。它将软件通信过程抽象化为四个抽象层，采取协议堆栈的方式，分别实现出不同通信协议。协议族下的各种协议，依其功能不同，分别归属到这四个层次结构之中，常视为是简化的七层OSI模型。

https://zh.wikipedia.org/zh-cn/TCP/IP协议族

demos

(🐞 反爬虫测试！打击盗版⚠️）如果你看到这个信息, 说明这是一篇剽窃的文章，请访问 https://www.cnblogs.com/xgqfrms/ 查看原创文章！

QUIC

QUIC（读作“quick”）是一个通用[1]的传输层[2]网络协议，最初由Google的Jim Roskind设计[3]。该协议于2012年实现并部署[4]，2013年随着实验范围的扩大而公开发布[5][6][7]，并向IETF描述[8]。虽然长期处于互联网草案阶段，但从Chrome浏览器至Google服务器的连接中超过一半的连接都使用了QUIC[9]。Microsoft Edge[10]、Firefox[11]都已支持此协议；Safari[12]实现了QUIC，但默认情况下没有启用。QUIC于RFC9000中被正式标准化[13]。

虽然QUIC的名称最初是“快速UDP互联网连接”（Quick UDP Internet Connection）的首字母缩写[3][8]，但IETF指定的标准中QUIC并不是任何内容的缩写[1]。QUIC提高了目前使用TCP的面向连接的网络应用的性能[2][9]。它通过使用用户数据报协议（UDP）在两个端点之间建立若干个多路连接来实现这一目标，其目的是为了在网络层淘汰TCP，以满足许多应用的需求，因此该协议偶尔也会获得 “TCP/2”的昵称[14]。

QUIC与HTTP/2的多路复用连接协同工作，允许多个数据流独立到达所有端点，因此不受涉及其他数据流的丢包影响。相反，HTTP/2建立在传输控制协议（TCP）上，如果任何一个TCP数据包延迟或丢失，所有多路数据流都会遭受队头阻塞延迟。

QUIC的次要目标包括降低连接和传输时延，以及每个方向的带宽估计以避免拥塞。它还将拥塞控制算法移到了两个端点的用户空间，而不是内核空间，据称这将使这些算法得到更快的改进。此外，该协议还可以扩展前向纠错（FEC），以进一步提高预期错误时的性能，这被视为协议演进的下一步。

2015年6月，QUIC规范的互联网草案提交给IETF进行标准化[15][16]。2016年，成立了QUIC工作组[17]。2018年10月，IETF的HTTP工作组和QUIC工作组共同决定将QUIC上的HTTP映射称为 "HTTP/3"，以提前使其成为全球标准[18]。2021年5月IETF公布RFC9000，QUIC规范推出了标准化版本[13]。

https://zh.wikipedia.org/zh-cn/QUIC

HTTP status codes

https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

HTTP request methods

GET
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.

HEAD
The HEAD method asks for a response identical to a GET request, but without the response body.

POST
The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.

PUT
The PUT method replaces all current representations of the target resource with the request payload.

DELETE
The DELETE method deletes the specified resource.

CONNECT
The CONNECT method establishes a tunnel to the server identified by the target resource.

OPTIONS
The OPTIONS method describes the communication options for the target resource.

TRACE
The TRACE method performs a message loop-back test along the path to the target resource.

PATCH
The PATCH method applies partial modifications to a resource.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods

refs

https://www.cnblogs.com/xgqfrms/tag/TLS/

https://www.rfc-editor.org/rfc/rfc6797

https://www.rfc-editor.org/rfc/rfc6797#section-6.1

https://www.wappalyzer.com/technologies/security/hsts

---

---

©xgqfrms 2012-2021

www.cnblogs.com/xgqfrms 发布文章使用：只允许注册用户才可以访问！

原创文章，版权所有©️xgqfrms, 禁止转载 🈲️，侵权必究⚠️！

---