2021秋招复习——计算机网络

文章目录

• 总流程

• Browser caching mechanism

• Resource cache positioning

  • Three-level caching principle
  • Categorization of browser caching based on storage mechanisms
    • Strong caching mechanism is a key component in this context.

• Caching strategy for collaborative environments.

• Last-Modified header parameter and If-Modified-Since conditional.

• ETag and If-None-Match conditional headers.

  复制代码

  * 浏览器缓存的优点

  • DNS
  • • 什么是DNS
    • DNS解析

• 数据传输过程中的请求处理

• 详细阐述了TCP/IP协议的层次结构

  • 首次介绍了TCP三次握手机制与四次挥手过程
  • 在第一次对话中提出了‘三次握手’机制

• 四次挥手过程则用于建立稳定的通信连接

• TCP拥塞控制机制

• UDP

• 比较分析：TCP与UDP的区别

• 常见字段：HTTP请求头与响应头

• 版本编码：HTTP 1.0, 1.1, 2.0, 3.0

• Cookie

• Cookie与Session的关联

• What is a Cookie？

• What is a session？

• Cookie与Session有何区别？它们之间存在怎样的联系？为何需要它们？

• If the browser disables cookies, what measures can be taken to ensure the system's functionality?

• How should distributed sessions be addressed?

区分Cookie、session存储与本地存储的不同之处在于其应用场景及数据保护特性等核心特征的差异性表现形式等维度展开分析；GET请求与POST请求的区别主要体现在信息传递方向及行为特征等方面；常见返回码列表中包含多个关键指标数值其意义各不相同；https协议的应用场景主要涉及安全通信机制构建等环节；对称加密机制基于相同的密钥实现数据的安全传输过程具有较高的安全性；非对称加密则基于不同的密钥集合进行操作能够保障通信双方的安全性； TLS协议通过建立安全通道确保数据传输过程中的机密性完整性和不可篡改性；摘要算法用于生成文件或数据的唯一标识符具有快速验证功能；(数字证书)CA证书是电子签名系统中的重要组成部分用于身份认证验证环节；(RSA加 handshake)过程是建立SSL/TLS连接的关键步骤确保双方通信的安全性稳定性和可靠性；(TLS 1.2标准)版本号为1.2的TLS协议在兼容性稳定性等方面有着显著的优势

  * HTTP和HTTPS的区别

* 浏览器渲染

总流程

浏览器输入url之后，首先，会从浏览器缓存中查看缓存中是否存在请求的数据，如果存在并且未过期，则触发强缓存 ，如果存在但是已过期，则触发协商缓存 ；如果不存在则向服务器发送请求；DNS解析域名成ip地址，浏览器使用ip地址向服务器发送请求，浏览器接收数据，将数据存入缓存当中，解析数据，渲染页面。

浏览器缓存

资源缓存的位置

浏览器的缓存位置分为：memory cache（内存） 和 disk cache（磁盘）

区别：

三级缓存原理

先去内存看，如果有，直接加载

如果内存没有，择取硬盘获取，如果有直接加载

如果硬盘也没有，那么就进行网络请求

加载到的资源缓存到硬盘和内存

比如：访问图片-> 200 -> 退出浏览器

再进来-> 200(from disk cache) -> 刷新 -> 200(from memory cache)

浏览器缓存的分类

1. 强缓存
2. 协商缓存

浏览器在发起请求连接到服务器建立初始会话时，在初始化连接阶段首先检查是否命中强缓存机制；接着，在完成客户端身份认证后进一步判断是否达到协商缓存的条件并完成相关操作

强缓存

在浏览网页内容时，在获取到部分数据后会通过header字段检测是否存在已经下载完成的内容，并直接调用本地缓存内容。

这里 header 中的信息指的是 expires 和 cache-control。

Expires

该字段遵循 HTTP/1.0 标准，并规定了一个 GMT 格式的绝对时间戳字符串作为其值。例如： Expires: Mon, 18 October 2066, 23:59:59 GMT。
这个字段的时间点标志着资源的有效期，在此之前访问该资源将触发缓存机制。
然而，这一方法存在明显的缺陷：因为有效期是以绝对时间为基准的，在服务器与客户端之间存在较大时差的情况下会导致缓存混乱。

Cache-Control

Cache-Control 是在 HTTP/1.1 标准中引入的一个字段信息，在实际应用中主要依据该字段的时间范围进行评估，并将其定义为一个时间间隔或时间段的概念。例如，在 Cache-Control:\ max-age=3600 的配置中，默认情况下资源的有效期被设定为 3600 秒（即一小时）。除了这一核心参数外，在实际应用中还可以根据需求配置一些常用的其他设置参数

no-cache ：需要进行协商缓存，发送请求到服务器确认是否使用缓存。

no-store ：禁止使用缓存，每一次都要重新请求数据。

public ：可以被所有的用户缓存，包括终端用户和 CDN 等中间代理服务器。

该属性为：仅限于终端用户浏览器的本地缓存，不得由 CDNs 或其他中继服务器对其进行缓存。

Cache-Control 与 Expires 可以在服务端配置并可同时设置，在两者被设置的情况下 Cache-Control 的优先级较高

协商缓存

在强缓存失效的情况下，在浏览器尝试访问资源时（发送一个请求至服务器），服务器通过header字段中的相关信息来确定资源是否已存在缓存（即发生命中）。如果发生命中，则服务器将返回304头头信息（HTTponfo），并指示浏览器可以利用本地缓存以获取最新内容。

在header字段中所包含的信息具体涵盖了Last-Modify/If-Modify-Since以及ETag/If-None-Match这两个字段

Last-Modify/If-Modify-Since

当应用程序首次访问某个网络资源时, 服务器会在响应头信息中包含Last-Modify字段, 并记录该资源最后一次更新的时间

在浏览器再次尝试获取该资源时, request 头部会包含 If-Modify-Since 字段,其值为服务器返回给客户端前一次更新的时间戳. 服务器接收到此字段后会根据客户端设备记录下来的最新更新时间来判断缓存是否有效.

如果命中缓存，则返回 304，并且不会返回资源内容，并且不会返回 Last-Modify。

缺点:

短时间内资源发生了改变，Last-Modified 并不会发生变化。

资源呈现周期性变化特征。若该资源在一个周期内恢复至初始状态，则我们倾向于认为可以采用缓存机制；然而, Last-Modified字段却不这么看

ETag/If-None-Match

区别在于Etag/If-None-Match头返回的是一个校验码信息。通过ETag机制可以确保每个资源都是独一无二的，在任何情况下只要发生资源修改就会导致对应的ETag发生变化。服务器会根据客户端发送的If-None-Match头来决定缓存的有效性

不同于使用 Last-Modified 头部的情况，在服务器返回一个 304 Not Modified 的响应头时，因为 ETag 已经被重新生成，并不意味着新的版本已经到达客户端系统；即使该 ETag字段与之前的一致。

Last-Modified 和 ETag 可以同时存在于资源中，在这种情况下，默认情况下服务器会最先验证 ETag字段的一致性；如果 ETag信息一致，则会继续比对 Last-Modified 时间戳以决定是否返回 304 Not Modified 头部响应。

浏览器缓存的优点

1. 数据传输被降低为冗余状态；
2. 服务器的工作负担被显著地减轻了，并且网站的整体性能得到了显著提升；
3. 客户端在加载网页方面表现出显著提升的速度

DNS

什么是DNS

全称 Domain Name System ，即域名系统

万维网上作为一个域名与IP地址对应关系的分布式存储系统，在帮助用户更方便地访问互联网的同时避免了直接记忆机器可读的IP地址串。

DNS协议运行于UDP协议之上，并采用端口号53进行通信。

DNS解析

DNS解析过程就是将输入的域名解析成ip地址的过程。

比如访问 www.baidu.com

以下是对原文内容的逐步改写

浏览器在访问本地DNS服务器时的查找过程通常是 分层查找 ，而本地DNS服务器在与远程DNS服务器进行通信时的查找过程通常是 循环查找。

浏览器请求数据

TCP/IP协议的分层

TCP三次握手和四次挥手

三次握手

为什么需要三次握手？

在握手机制中，如果出现两次握手的情况，则表示客户端尝试发送一个连接请求至服务端。随后服务端会返回一个响应。然而由于网络延迟的原因，在客户端尚未完全接收该响应之前就已经产生了新的问题：即当客户端发现第一次的连接已经失效时，并不会主动重试；相反地会继续等待第一次的连接传输数据完成这一过程。因此这会导致了一种资源浪费的情况：即即使第一次的连接已经断开，在等待数据传输的过程中也错过了重新建立新连接的机会

通过三次握手机制进行通信时，在客户端发起的首次连接请求（即第一次的连接）需要等待服务端返回确认信息之后才会被处理。然而由于客户端并未接收到服务端的确认信号（即第二次的应答），因此不会向服务端发送任何反馈信息（即第三次的应答）。因此在这种情况下的连接建立会被拒绝。

四次挥手

TCP拥塞控制算法

UDP

特点：

面向无连接

在连接建立方面, UDP无需遵循TCP那样的三次握手流程；相反地, 在数据传输过程中, 在报文中不需要执行任何分割或确认操作.

有单播、多播、广播的功能

UDP不止支持一对一的传输方式，还支持一对多，多对多的方式

UDP是面向报文的

不可靠性

不可靠性体现在无连接上，收到什么数据就传递什么数据

头部开销小，传输数据报文时是很高效的

TCP和UDP的区别

请求头和响应头常见字段

HTTP 1.0，1.1，2.0，3.0

HTTP 1.0和1.1的区别

长连接

按照HTTP/1.0标准规定，在浏览器与服务器之间仅维持短暂的数据传输通道。每当发送一个请求时，在完成响应处理后及时终止当前的TCP连接；这种持续的操作会导致系统在处理请求时产生额外负担。

支持采用长连接及分段通信的方式处理，在单个TCP连通体下可同时传输多个HTTP事务及其响应数据流，并从而降低了开销及建立/关闭连结所耗费的时间与延迟；该协议默认启用该机制（其中在每个会话头及相应回应头中包含connection: keep-alive字段），以此部分弥补了每次都需创建新会话而带来的不足；为了维持长时间的数据传输稳定性与可靠性, HTTP/1.0则必须为每个连结单独创建新的链接, 这种做法带来了明显的性能瓶颈

节约带宽

HTTP 1.0 中存在一些不必要的数据传输问题,例如当客户端仅需某个对象的部分内容时,而服务器总是会传输整个对象并不具备断点续传功能。HTTP/1.1 则允许仅传输必要的头信息(无需携带正文部分),具体而言,当服务器确认客户端有权访问其资源时会返回状态码 2xx;一旦客户端接收到 2xx 响应后才会启动正文传输流程。若返回状态码为 4xx 则无需传输正文从而节省了带宽。

缓存处理

在HTTP 1.0协议中主要依靠Header中的Expires字段（强缓存）以及Last-Modify或If-Modified-Since字段（协商缓存）作为请求验证的主要依据。与之相比，在HTTP 1.1协议中增加了更多用于控制缓存机制的头信息包包括Cache-Control（强缓控）以及Etag或If-None-Match（协商控）等选项。

HTTP 1.1的缺陷

1. 高延迟-队头阻塞
2. 无状态特性-阻碍交互
3. 不安全性-明文传输

如何避免长连接浪费资源：

客户端设置了一个关闭连接的请求头字段。
服务端需要配置长连接超时时间参数。
系统内核相关参数进行设置了：
当一个TCP连接闲置超过60秒时，
服务端将向客户端发送侦测包，
检测该连接的状态，
如果没有收到确认响应就会立即关闭该TCP连接。
每隔10秒就会发送一次探测包，
直至收到确认响应为止。
最多会发送5次探测包，
如果在这5次探测中仍未收到确认响应，
则最终将关闭该TCP连接。

HTTP 2

二进制分帧

**帧：**HTTP/2通信中最小的消息单元——代表的是 HTTP/2 协议中的逻辑消息。如请求与响应等常见的数据包，在传输过程中可能由一个或多个这样的单元构成

数据传输通道：作为连接中的虚拟通道存在。数据传输通道能够支持双向通信，并为每个连接分配一个唯一的整数值标识符以区分不同通信路径或数据流量。

HTTP/2 使用二进制格式传输数据，并不采用 HTTP 1.x 的文本格式。解析二进制协议更加高效。HTTP / 1 的请求与响应报文包括起始行、首部及可选的实体正文，并通过文本换行符分隔各部分。HTTP/2 将请求与响应的数据划分为较小的帧，并采用二进制编码进行处理。

在HTTP/2协议中，在同一域名下所有通信将集中在一个连接中完成，并且该连接能够处理大量双向的数据流量。每条数据流都是消息的形式发送，并且每条消息通常由一个或多个帧构成。各帧之间可能出现无序发送的情况，并通过各帧头信息恢复原始顺序并重组数据块以实现完整的通信过程。

头部压缩

HTTP/2应用专为其消息头设计的HPACK格式来实现数据压缩传输，并有助于减少网络带宽资源的消耗。

多路复用

HTTP/2的主要特性是所有同域名的通信均在单一连接中完成，并且该连接能够支持任意数量的双向数据流。每个数据流都是通过消息的形式进行传输，在这种机制下，每个消息通常由一个或多个帧构成。虽然可能存在不同顺序的帧到达对方端点，在接收端通过查看每个帧携带的流标识码来进行适当的数据重组处理。

服务端推送

服务端可以在发送页面HTML的同时提前推送其它资源，并无需等待浏览器解析到相应位置后才响应。例如：服务端即时将JavaScript（JS）和样式表（CSS）文件发送给客户端，并无需等待浏览器在解析HTML时再发送这些资源。

服务端能够主动进行数据推送，并且客户端有权选择是否接受服务端的数据推送。当服务端发送的资源已由浏览器缓存时，浏览器可向客户端发送RST_STREAM帧以拒绝接收相关数据。在主动推送过程中需遵循同源策略，在此过程中服务器在主动推送过程中不会随意向客户端发送第三方资源

HTTP 2的缺陷

1. 头部阻塞问题尚未完全解决
2. 多路复用可能导致服务器压力上升
3. 多路复用可能造成超时现象

cookie

该文档定义了以下关键属性：名称（Name）、值（Value）、域名（Domain）、路径（Path）、过期时间/最大年龄（Expires/Max-age）、文件大小（Size）、HTTP-only（HttpOnly）、安全（Secure）、相同网站策略（SameSite）以及优先级管理（Priority）。

name和value

Name与Value构成键值对。Name代表Cookie的标识符，在创建后该标识将固定不变，默认情况下不区分大小写；Value代表对应该标识符所存储的信息。若存储的信息涉及Unicode字符，则需对其编码处理；若为二进制数据，则应采用BASE64编码方式处理。

Domain

Cookie的有效性由Domain参数决定，在发送请求至指定Domain时携带此Cookie。这种参数设置基于子域生效原则：若将Domain设为 .a.com，则b.a.com和c.a.com均能使用该Cookie；但若设定为b.a.com，则只有b.a.com下的请求能包含该Cookie而无法应用到c.a.com下的请求。需要注意的是，在定义Domain参数时必须以点(.)开头。

Path

Path被视为一个有效且固定的 cookie 路径（如同 Domain 一样），同样适用于其所有子路径（即 Path 子部分）。例如，在本示例中 cookie "cookie-1" 和 cookie "cookie-2" 都属于同一个 domain（例如 domain = a.com），但是它们具有不同的 Path 设置：cookie-1 的 Path 设置为 /b/ ，而 cookie-2 的 Path 设置为 /b/c 。因此，在到达 a.com/b 页面时只能找到 cookie-1；而在到达 a.com/b/c 页面时，则会找到并使用 cookie-1 和 cookie-2 两个 cookie 对象。此外，请注意 Path 属性必须以符号‘/’结束

Expires/Max-age

expires和maxAge均表示Cookie的有效期属性值。
其中，
expires表示此cookie被删除所使用的删除时间戳，
其遵循GMT格式。
若将此时间早于当前服务器时间，
则此cookie将立即被删除，
且此时间戳仅适用于服务器端，
而非本地端用户。
若未指定此值，
则cookie将在客户端退出会话后被清除。
而maxAge同样表示Cookie的有效期属性值，
但其单位是以秒来计算有效期限：
即从当前时刻起经过多少秒后cookie将自动失效。
当将maxAge设为0时，
则表示cookie将在立即失效；
而将其设为负值时，
则cookie将在客户端退出会话后失效。
需要注意的是，默认情况下，
如果没有设定$maxAge`值的话，
cookie会在本地端退出会话后被清除。

size

此Cookie的尺寸大小为Size参数指定值，在各种网络环境下该参数均具有明确意义与应用范围。无论哪一台浏览器，在处理Cookies时都会遵循统一标准进行操作：任何Cookie若尺寸超出规定范围则会被忽略处理；其设置状态也会被严格控制以确保系统稳定运行。各类型浏览器对Cookie的最大容量与最大数量均有所规定，请参考表格数据（数据来源网络）

HttpOnly

HttpOnly属性可取true或false。若将其设置为true，则该脚本将无法修改该属性的值。然而该属性不会包含在cookie中。尽管如此，在处理请求时仍会被解析出来。

Secure

当设置为true时，Secure参数指定Cookie的安全属性。此时，浏览器仅限于HTTPS与SSL等安全通信协议中传输该Cookie，并无法通过非安全的HTTP协议进行传输。

SameSite

SameSite用来限制第三方 Cookie，从而减少安全风险。它有3个属性，分别是：

Strict

最严格的 cookie政策不容许任何第三方发送 cookie, 尤其在跨站的情况下, 无论何种情况均不会发送 cookie.

Lax

Lax规定略微放宽，并且在多数情况下也不会发送第三方 Cookie；然而，在导航至目标网站时采取Get请求例外的情况

None

网站可以选择将SameSite属性显式地关闭（设为None）。然而，在此之前，请确保同时设置了Secure属性（因为Cookie仅能在HTTPS协议下传输）。如果未满足这些条件，则该操作将无法成功执行。

另外：关闭SameSite的方法

在谷歌浏览器地址栏中输入：chrome://flags/ 操作步骤如下：首先定位到选项中的‘SameSite by default cookies’和‘Cookies without SameSite must be secure’这两个设置项。然后将这两个参数配置为‘设为不可用’。

Priority

方案建议了三种优先等级：低、中、高。当cookie的数量超过一定阈值时，在相同条件下生成的low级别的cookie将被提前删除以释放存储空间

cookie 和 session

什么是Cookie

HTTP Cookie是由服务器发送至浏览器，并在本地存储为一小部分数据；它会在浏览器下一次向服务器发起请求时被携带并传输给服务器。

Cookie主要用于以下三个方面：

• 会话状态管理（包括登录状态、购物车信息、游戏分数以及其他相关信息）
  • 个性化设置（如用户自定义的个人偏好设置和主题等）
  • 浏览器行为跟踪（监控并分析用户的活动情况）

什么是session

Session代表着服务器和客户端一次会话的过程。

Session对象负责存储特定用户的会话所需的属性与配置参数。每当用户在Web页面间切换时，在Session对象中记录的变量信息将不会被丢失，并持续存在于整个会话过程中。

当客户端关闭会话，或者Session超时失效时会话结束。

Cookie和Session有什么不同

• 在适用场景方面存在差异：Cookie被存储在客户端（如浏览器），而Session则保留在服务器端。
• 存取特性上有所不同：Cookie仅支持ASCII编码存储数据；而Session则具备处理任意数据类型的能力。
• 有效期限上存在区别：Cookie可设置为长期有效期，默认登录功能常用于长时间使用场景；而Session一般只会维持较短的有效期，在客户端关闭或Session超时后会失效。
• 隐私管理策略上有所区别：Cookie的数据存储位置较为容易受到非法获取威胁；相比之下，Session由于其存储位置位于服务端的特性，在安全性层面相对更为稳健。
• 存储容量方面存在差异：单个Cookie的数据量限制在4KB以内；而 Session 的最大存储容量则远高于 Cookie 的限制。

Cookie和Session有什么关联，为什么需要他们

由于HTTP协议是stateless的（基于HTTP协议的设计特性），因此，在这种情况下浏览器并不了解与之交互的具体身份信息。此时就需要建立一套认证机制来告知服务器本次操作是否涉及用户登录以及具体由哪位用户执行的操作内容。而实现这一功能通常依赖于结合使用Cookie与Session这两种技术手段

当用户首次向服务器发起请求时，在返回结果中包含该Session的唯一标识符SessionID，并将其发送回浏览器。当浏览器接收到来自服务器返回的SessionID信息时，并将这些信息存储到Cookie中，并记录该SessionID所属的网站域名。

当一个用户再次发起请求时, 系统将自动检查当前访问的域名是否有已发送的Cookie记录. 如果检测到存在已保存的Cookie数据, 则会立即发送这些Cookie信息到服务端. 服务端系统通过分析这些Cookie数据来提取对应的SessionID值, 然后利用这个SessionID值查找相关的Session记录. 如果无法找到匹配的Session记录, 则可能意味着该用户尚未进行登录操作或当前登录状态无效. 一旦发现有匹配的Session记录, 则确认该用户已成功登录并允许执行后续的操作流程.

如果浏览器中禁止了Cookie，如何保障整个机制的正常运转

第一种方案，在每次请求中包含一个 SessionID 参数，在线提交或者通过 POST 方式都可以；此外还可以在请求 URL 末尾连接 xxx?SessionID=123456...

采用 Token 机制作为解决方案的一种策略，在移动应用与服务器之间的交互模式中被广泛应用；同时，在Web端实现用户状态管理时也可使用该机制

Token 指的是‘令牌’，是服务端生成的一串字符序列，用于客户端进行请求的一个标识符。Token 机制与 Cookie 以及 Session 的使用机制具有类似的特性。

当用户首次登录之后，在接收到用户的请求后由服务器根据提交的信息创建一个Token，并在响应时返回该Token给客户端。以后客户端只需要携带该Token前来请求数据即可，并不需要再进行认证流程。

如何考虑分布式Session问题

在互联网公司中，在处理更高的流量需求时通常会采用多台服务器配合来处理前端用户的请求；当用户的第一次操作是在 A 服务器完成（login），随后再次发起请求至服务 B 将会导致 login invalid 的情况发生。

分布式 Session 一般会有以下几种解决方案：

• Nginx基于哈希策略, 服务端采用Nginx代理机制, 将每个请求根据访问IP的哈希值进行分配, 这样来自同一IP地址的请求会被固定分配到同一个后端服务器上, 从而避免了在同一台服务器A创建Session后再分配到另一台服务器B的情况发生。
• 当任何一个服务器上的Session发生增删改操作时, 该节点会将该Session的所有内容进行序列化编码, 并通过网络广播给其他节点。
• 采用共享Session机制, 在服务层未采用状态存储策略的情况下, 将用户的Session及相关信息通过缓存中间件统一管理, 确保所有分发到各后端 server时返回的结果一致。

建议采用第三种方案。

参考资料

你真的了解 Cookie 和 Session 吗

cookie、sessionStorge和localStroge的区别

get和post请求

GET在浏览器回退时是无害的，而POST会再次发起请求

GET请求会被浏览器主动缓存，而POST不会，除非手动设置

GET请求参数会被存储在浏览器历史记录中，而POST中的参数不被保存

GET请求中的URL参数存在长度限制（受浏览器影响），其最大容量通常由开发者设定；而POST请求不受此限制。

GET参数通过URL传递，POST放在Request body中

GET产生的URL地址可以被收藏，而POST不可以

由于使用了标准的安全机制，在采用标准协议时需要考虑数据完整性保护的问题。
因此，在使用标准协议时需要注意其安全隐患。
从而导致无法有效地传递敏感信息。

GET请求只能进行URL编码，而POST支持多种编码方式

对参数的数据类型，GET只接受ASCII字符，而POST没有限制

GET会生成一个TCP报文进行传输；而POST则会生成两个报文（Firefox仅生成一次）。HTTP客户端将HTTP头信息与数据一并发送出去；对于POST请求，则是先发送HTTP头信息并获得状态码100的确认响应（Continue），随后再发送请求主体并获得状态码200的成功响应。

常用响应码

1xx：

表示目前协议处理的中间状态，还需要后续操作

*101Switching Protocols. 当将HTTP升级为WebSocket时, 只有当服务器同意变更时, 会发送状态码101.

2xx：

表示成功状态

• 200 OK 是应用最广的状态代码之一，在大多数情况下请求体中含有数据。
  • 204 No Content 其状态信息中应用最广的是这一状态码。
  • 206 Partial Content 表示请求返回的部分数据，在这种情况下通常用于通过HTTP分块传输实现的数据补传过程，并附带有相应的响应头字段Content-Range。

3xx：

重定向状态，资源位置发生变动，需要重新请求

• 301 Moved Permanently 即永久性重定向
• 302 Found 即非持久性重定向
• 304 Not Modified 该状态码会在协商缓存成功时返回

4xx：

• 400 Bad Request : 开发者常感到困惑。
  • 403 Forbidden : 该错误的原因多样。
  • 404 Not Found : 无法定位所需资源。
  • 405 Method Not Allowed : 请求方法不符合服务器要求。
  • 406 Not Acceptable : 资源无法满足客户端需求。
  • 408 Request Timeout : 服务器等待时间过长。
  • 409 Conflict : 同时存在多个有效请求。
  • 413 Request Entity Too Large : 请求体数据过大。
  • 414 Request-URI Too Long : 请求行中的 URI 太长。
  • 429 Too Many Requests : 客户端发送请求过多。
  • 431 Request Header Fields Too Large ：请求头字段过大

请求报文有误

5xx：

服务端发生错误

500 Internal Server Error : 仅仅告诉你服务器出错了，出了啥错咱也不知道。

501 Not Implemented : 表示客户端请求的功能还不支持。

502 Bad Gateway : 网站正常运行中，在访问时出现了问题，请问具体发生了什么错误吗？

503 Service Unavailable : 表示服务器当前很忙，暂时无法响应服务。

HTTPS

对称加密

加密和解密使用同一个密钥，加解密过程：

• 客户端向服务器传输一组参数与可协商的安全协议列表
  • 服务器对客户端做出回应一组参数与相互可接受的安全协议
  • 随后，在线双方利用各自的随机参数生成共享密钥，并将其作为通信时所采用的密钥基础

非对称加密

一对密钥系统中包含**公钥（public key）和私钥（private key）**两种角色。其中一种密钥用于加密数据时必须搭配另一只对应的钥匙才能完成操作；而这种操作一旦完成则只能通过另一对密钥中的另一只私钥来实现反向的操作——即解密过程。具体来说：使用公钥对数据进行加密；使用私钥对加密后的数据进行解密。

• 浏览器向服务器提交了一个包含client-random以及共同认可的加密方法集合。
• 服务器传递给浏览器一个server-random，并提供双方共有支持下的加密方案及公钥信息。
• 浏览器通过公钥对client-random和server-random进行加密操作以获取密钥，并确保该密钥仅可通过私钥实现解密。

TLS

采用对称与非对称加密技术结合的方式进行数据保护。通过非对称加密协议实现对称密钥的安全传递，并利用对称算法完成数据的加解密过程。

• 浏览器向服务器传递client-random字段及其适用的安全协议列表。
  • 服务器返回给浏览器server-random响应码、公钥，并确认双方存在兼容性。
  • 浏览器自动生成pre-random值，并经公钥加密后反馈至服务器。
  • 服务器采用私钥完成解密过程。
  • 双方通过三个随机数值结合特定算法计算出最终共享密钥。

摘要算法

主要用于确保数据来源的完整性和一致性。常用的包括以下几种：MD5算法、散列算法、哈希函数算法 ，其显著特征是单向性以及无法逆向推导原始数据

主要用于确保数据来源的完整性和一致性。常用的包括以下几种：MD5算法、散列算法、哈希函数算法 ，其显著特征是单向性以及无法逆向推导原始数据

ca证书（数字证书）

用于验证 服务器身份 。

数字证书由具有权威认证能力的CA机构提供给服务器。同时，CA机构与服务器各自拥有各自的一对密钥（公钥与私钥）。

证书生成：

• CA机构负责利用摘要算法计算服务器公钥的计算结果。
• CA机构利用CA私钥配合特定的签名算法对计算结果进行加密，并成功生成对应的签名。
• 将这些信息整合后放入数字证书中，并将该证书发送给服务器。

配置完成后，在线服务将向访问该服务的客户端发送密钥包，并在每次发送前需先将证书发送给客户端用于验证，并获取相应的服务器公钥。

证书验证：

• 通过 CA私钥 和 声明使用的签名算法 对CA证书中的签名进行解密操作, 从而获得服务器公钥的摘要信息。
• 接着利用摘要算法对证书中包含的信息提取其对应的数字摘要, 并将这一结果与上一步骤获取到的具体数字摘要进行对比分析。
• 若两者一致, 则表明该证书有效且所包含的公钥正确无误。

RSA握手

早期的TLS密钥交换法就是使用RSA握手

• 向服务器发送一组参数（包括 client-Random 值及其对应的 ciphering techniques）；
• 由服务器返回 server-Random 参数以及 public key；
• 浏览器计算 pre-Random 数值，并通过公钥对该数值进行 ciphering 后返回给服务器；
• 服务器在接收到该值后解密时采用私有 key；
• 双方共同利用三个 random numbers 和 ciphering techniques 计算出最终密钥。

TLS 1.2版

HTTP和HTTPS的区别

浏览器渲染

个人总结：My Summary
参考文献
实践这一次, 完全弄通浏览器缓存机制