计算机网络八股（http篇）

标签：TLS 八股 缓存 http HTTP 请求 计算机网络 服务器 客户端

1、http是什么？

HTTP 是超文本传输协议，也就是HyperText Transfer Protocol。 HTTP 是一个在计算机世界里专门在 「两点」 之间 「传输」 文字、图片、音频、视频等 「超文本」 数据的 「约定和规范」 。

2、http状态码？

分为5类 1xx，一般是表示请求成功，继续等待下一步请求 ， 例如 100 2xx：一般表示请求成功 3xx：一般表示重定向 304：表示资源未改变，可以使用本地缓存 4xx：一般表示客户端错误 5xx：一般表示服务器出错

3、http报文有哪些部分？

请求报文 请求行:包含请求方法、请求目标(URL或URI)和HTTP协议版本。 请求头部:包含关于请求的附加信息，如Host、User-Agent、Content-Type等空行:请求头部和请求体之间用空行分隔。 请求体:可选，包含请求的数据，通常用于POST请求等需要传输数据的情况。. 响应报文: 状态行:包含HTTP协议版本、状态码和状态信息。 响应头部:包含关于响应的附加信息，如Content-Type、Content-Length等。 空行:响应头部和响应体之间用空行分隔。 响应体:包含响应的数据，通常是服务器返回的HTML、JSON等内容,

4、GET和POST之间有什么区别？

GET 的语义是 从服务器获取指定的资源 ，POST 的语义是 根据请求负荷（报文body）对指定的资源做出处理 ； get有 url长度限制 （2048字节）而post没有； get的参数是 显式 的，get的参数会附加在url之 中，以 “ ？ “分割url和传输数据，多个参数用 “&”连接；而post是 隐式 的，post是放在请求体中； get在浏览器回退时是 无害 的，而post会 再次提交 请求； get请求只能进行url编码，而post支持多种编码方式； get请求的参数数据类型只接受ASCII字符，而post没有限制。

5、http协议的特性是什么？

特性：简单、灵活且易于扩展、无状态、明文传输、不安全 对于无状态的问题，比较简单的解决方式是Cookie技术，在请求和响应报文写入Cookie信息。 对于明文传输 它为调试带来了极大的便利性，但是信息透明，容易被窃取 不安全 通信使用明文，内容容易被窃听 不验证通信方的身份，因此有可能遭受伪装，无法证明报文的完整性，所以有可能已遭篡改。 以上这些问题可以用https的方式解决，引入SSL、TLS层。

6、http版本演变？

http/0.9 只支持get方法也没有请求头 只能返回HTML格式的内容 http/1.0 是http协议的第一个正式的版本，主要有以下的更新 引入了请求头和响应头，支持多种请求方法 不支持长连接 只支持短连接 http/1.1 引入了 长连接 （持久连接） 管道网络传输 在一个tcp连接里面，客户端可以发起多个请求，只要一个请求出去了，不必等其回来 就可以直接发第二个请求，可以减少整体的响应时间。但是服务器必须按照接收的请求顺序发送对这些 管道化请求的响应。所以说 http/1.1管道解决了请求的队头阻塞，但是没有解决响应的队头阻塞。 http/2 http/2协议是基于https的，所以http/2的安全性是有保障的。 改进点： 1、头部压缩 使用HPACK压缩算法对请求和响应头部进行压缩，减少了传输额头部数据量 2、二进制帧 3、并发传输 引入stream概念 ， 多个stream复用在一个tcp连接上面，http2可以并行的发送请求和响应 4、http仍然存在着队头阻塞的问题，只不过问题在传输层上面。 HTTP/3 把 HTTP 下层的 TCP 协议改成了 UDP，基于 UDP 的  QUIC  协议 可以实现类似 TCP 的可靠性传输。 无队头阻塞，每个Stream有独立的滑动窗口 更快的连接建立，QUIC 协议并不是与 TLS 分层，而是QUIC 内部包含了 TLS 连接迁移，基于连接ID而非四元

7、http/1.1如何优化？

尽量避免发送 HTTP 请求：缓存技术 在需要发送 HTTP 请求时，考虑如何减少请求次数： 减少重定向次数，由代理服务器完成重定向并进行缓存 合并请求，减少重复发送的HTTP头部，合并资源 延迟发送请求，懒加载 减少服务器的 HTTP 响应的数据大小： 有损压缩：音频、视频、图片 无损压缩：文本文件、程序可执行文件、程序源代码

8、http/2.0的特性？

头部压缩 HTTP/1.1body可以使用content-encoding字段指定压缩方式，但是没有针对header的优化手段 存在的问题： 固定字段  重复字段  ASCII编码，效率低下 于是采用HPACK 算法主要包含三个组成部分： 静态字典，写入到 HTTP/2 框架里的，不会变化的； 动态字典，在编码解码的时候随时更新； Huffman 编码（压缩算法）； 二进制编码 将 HTTP/1 的文本格式改成二进制格式传输数据，极大提高了 HTTP 传输效率，而且二进制数据使用位运算能高效解析。 并发传输 引入Stream ，多个 Stream 复用一条 TCP 连接，达到并发的效果，解决了 HTTP/1.1 队头阻塞的问题，提高了 HTTP 传输的吞吐量。 在 HTTP/2 连接上，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息，所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，而同一 Stream 内部的帧必须是严格有序的。 服务器推送 客户端发起的请求，必须使用的是奇数号 Stream，服务器主动的推送，使用的是偶数号 Stream。服务器在推送资源时，会通过PUSH_PROMISE帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。

9、http3.0的特性 以及它是怎么优化了2.0版本的？

HTTP/2 虽然具有多个流并发传输的能力，但是传输层是 TCP 协议 ，于是存在以下 缺陷： 队头阻塞，HTTP/2 多个请求跑在一个 TCP 连接中，如果序列号较低的 TCP 段在网络传输中丢失了，即使序列号较高的 TCP 段已经被接收了，应用层也无法从内核中读取到这部分数据，从 HTTP 视角看，就是多个请求被阻塞了； TCP 和 TLS 握手时延，TCL 三次握手和 TLS 四次握手，共有 3-RTT 的时延； 连接迁移需要重新连接，移动设备从 4G 网络环境切换到 WIFI 时，由于 TCP 是基于四元组来确认一条 TCP 连接的，那么网络环境变化后，就会导致 IP 地址或端口变化，于是 TCP 只能断开连接，然后再重新建立连接，切换网络环境的成本高； HTTP/3 就将传输层从 TCP 替换成了 UDP，并在 UDP 协议上开发了 QUIC 协议，来保证数据的可靠传输。 QUIC 协议的特点： 无队头阻塞，QUIC 连接上的多个 Stream 之间并没有依赖，都是独立的，也不会有底层协议限制，某个流发生丢包了，只会影响该流，其他流不受影响； 建立连接速度快，因为QUIC 内部包含 TLS1.3，因此仅需 1 个 RTT 就可以「同时」完成建立连接与 TLS 密钥协商，甚至在第二次连接的时候，应用数据包可以和 QUIC 握手信息（连接信息 + TLS 信息）一起发送，达到 0-RTT 的效果。 连接迁移，QUIC 协议没有用四元组的方式来“绑定”连接，而是通过「连接 ID 」来标记通信的两个端点，客户端和服务器可以各自选择一组 ID 来标记自己，因此即使移动设备的网络变化后，导致 IP 地址变化了，只要仍保有上下文信息（比如连接 ID、TLS 密钥等），就可以“无缝”地复用原连接，消除重连的成本； 另外 HTTP/3 的 QPACK 通过两个特殊的单向流来同步双方的动态表，解决了 HTTP/2 的 HPACK 队头阻塞问题。

10、http缓存技术？

对于一些具有 重复性的 HTTP 请求 ，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都 缓存在本地 ，那么下次就直接读取本地的数据，不必在通过网络获取服务器的响应了，这样的话 HTTP/1.1 的性能肯定肉眼可见的提升。 所以， 避免发送 HTTP 请求的方法就是通过缓存技术 ，HTTP 设计者早在之前就考虑到了这点，因此 HTTP 协议的头部有不少是针对缓存的字段。 http缓存主要有两种实现方式，分别是强制缓存和协商缓存 强制缓存：指的是只要浏览器判断缓存没有过期，就可以直接使用浏览器的本地缓存，决定是否使用缓存的主动性在于浏览器这边。 返回的是200状态码，但是在size项中表示的是from disk cache，就是是使用了强制缓存 强缓存是利用下面这两个 HTTP 响应头部（Response Header）字段实现的，它们都用来表示资源在客户端缓存的有效期： Cache-Control， 是一个相对时间； Cache-control 选项更多一些，设置更加精细，所以建议使用 Cache-Control 来实现强缓存。具体的实现流程如下： 当浏览器第一次请求访问服务器资源时，服务器会在返回这个资源的同时，在 Response 头部加上 Cache-Control，Cache-Control 中设置了过期时间大小； 浏览器再次请求访问服务器中的该资源时，会先通过请求资源的时间与 Cache-Control 中设置的过期时间大小，来计算出该资源是否过期，如果没有，则使用该缓存，否则重新请求服务器； 服务器再次收到请求后，会再次更新 Response 头部的 Cache-Control。 Expires，是一个绝对时间；具体实现是:设置一个强缓存时间，此时间范围内 从内存中读取并返回，因为 Expires 判断强缓存过期的机制是获取本地时间戳，与之前拿到的资源文件中的字段的时间来作比较，来判断是否需要像服务器发送请求 ， 但是有一个巨大的漏洞，本地时间不准怎么办 协商缓存 协商缓存就是与服务端协商之后，通过协商结果来判断是否使用本地缓存。 协商缓存可以基于两种头部来实现。 第一种：请求头部中的 If-Modified-Since字段与响应头部中的 Last-Modified字段实现，这两个字段的意思是： 响应头部中的 Last-Modified：标示这个响应资源的最后修改时间； 请求头部中的 If-Modified-Since：当资源过期了，发现响应头中具有 Last-Modified 声明，则再次发起请求的时候带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。 第二种：请求头部中的  If-None-Match字段与响应头部中的 ETag 字段，这两个字段的意思是： 响应头部中 Etag：唯一标识响应资源； 请求头部中的 If-None-Match：当资源过期时，浏览器发现响应头里有 Etag，则再次向服务器发起请求时，会将请求头If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。响应头部中 Etag：唯一标识响应资源； 第一种实现方式是基于时间实现的，第二种实现方式是基于一个唯一标识实现的，相对来说后者可以更加准确地判断文件内容是否被修改，避免由于时间篡改导致的不可靠问题。 ETag 主要能解决 Last-Modified 几个比较难以解决的问题： 在没有修改文件内容情况下文件的最后修改时间可能也会改变，这会导致客户端认为这文件被改动了，从而重新请求； 可能有些文件是在秒级以内修改的，If-Modified-Since 能检查到的粒度是秒级的，使用 Etag就能够保证这种需求下客户端在 1 秒内能刷新多次； 有些服务器不能精确获取文件的最后修改时间。 注意，协商缓存这两个字段都需要配合强制缓存中 Cache-control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。 

11、https是如何建立连接的？

1、TCP三次握手 2、SSL/TLS 四次握手 SSL/TLS 协议基本流程： 客户端向服务器索要并验证服务器的公钥。 双方协商生产「会话秘钥」。 双方采用「会话秘钥」进行加密通信。 SSL/TLS 协议建立的详细流程： ClientHello 首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。 在这一步，客户端主要向服务器发送以下信息： 客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。 客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。 客户端支持的密码套件列表，如 RSA 加密算法。 SeverHello 服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容： 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。 服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。 确认的密码套件列表，如 RSA 加密算法。 服务器的数字证书。 客户端回应 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，验证服务器的数字证书的真实性。 如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：   1. 一个**随机数（pre-master key）**。该随机数会被服务器公钥加密。   2. 加密通信算法改变**通知**，表示随后的信息都将用**「会话秘钥」**加密通信。   3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个**摘要，用来供服务端校验**。 TEXT 上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。 服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。 服务器的最后回应 服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。 然后，向客户端发送最后的信息： 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。 至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

12、https应用数据是如何保证完整性的？

TLS 在实现上分为握手协议和记录协议两层： TLS 握手协议就是我们前面说的 TLS 四次握手的过程，负责协商加密算法和生成对称密钥，后续用此密钥来保护应用程序数据（即 HTTP 数据）； TLS 记录协议负责保护应用程序数据并验证其完整性和来源，所以对 HTTP 数据加密是使用记录协议； TLS 记录协议主要负责消息（HTTP 数据）的压缩，加密及数据的认证 具体过程如下： 首先，消息被分割成多个较短的片段,然后分别对每个片段进行压缩。 接下来，经过压缩的片段会被加上消息认证码（MAC 值，这个是通过哈希算法生成的），这是为了保证完整性，并进行数据的认证。通过附加消息认证码的 MAC 值，可以识别出篡改。与此同时，为了防止重放攻击，在计算消息认证码时，还加上了片段的编码。 再接下来，经过压缩的片段再加上消息认证码会一起通过对称密码进行加密。 最后，上述经过加密的数据再加上由数据类型、版本号、压缩后的长度组成的报头就是最终的报文数据

13、http与https的区别？

区别 （1）HTTP 是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTPS 则解决 HTTP 不安全的缺陷，在 TCP 和 HTTP 网络层之间加入了 SSL/TLS 安全协议，使得报文能够加密传输。 （2）HTTP 连接建立相对简单， TCP 三次握手之后便可进行 HTTP 的报文传输。而 HTTPS 在 TCP 三次握手之后，还需进行 SSL/TLS 的握手过程，才可进入加密报文传输。 （3）HTTP 的端口号是 80，HTTPS 的端口号是 443。 （4）HTTPS 协议需要向 CA（证书权威机构）申请数字证书，来保证服务器的身份是可信的。 解决了哪些问题 （1）窃听风险：混合加密算法实现了机密性（对称加密和非对称加密） （2）篡改风险：摘要算法实现完整性 （3）冒充风险：数字证书解决了冒充风险

14、https握手过程说一下？

SSL/TLS 协议基本流程： 客户端向服务器索要并验证服务器的公钥。 双方协商生产「会话秘钥」。 双方采用「会话秘钥」进行加密通信。 SSL/TLS 协议建立的详细流程： ClientHello 首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。 在这一步，客户端主要向服务器发送以下信息： 客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。 客户端生产的随机数（Client Random），后面用于生成「会话秘钥」条件之一。 客户端支持的密码套件列表，如 RSA 加密算法。 SeverHello 服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容： 确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。 服务器生产的随机数（Server Random），也是后面用于生产「会话秘钥」条件之一。 确认的密码套件列表，如 RSA 加密算法。 服务器的数字证书。 客户端回应 客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，验证服务器的数字证书的真实性。 如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息：   1. 一个**随机数（pre-master key）**。该随机数会被服务器公钥加密。   2. 加密通信算法改变**通知**，表示随后的信息都将用**「会话秘钥」**加密通信。   3. 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个**摘要，用来供服务端校验**。 TEXT 上面第一项的随机数是整个握手阶段的第三个随机数，会发给服务端，所以这个随机数客户端和服务端都是一样的。 服务器和客户端有了这三个随机数（Client Random、Server Random、pre-master key），接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。 服务器的最后回应 服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。 然后，向客户端发送最后的信息： 加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。 至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

15、cookie和session的区别？

Cookie和Session都是Web开发中用于跟踪用户状态的技术，但它们在存储位置、数据容量、安全性以及生命周期等方面存在显著差异: 存储位置:Cookie的数据存储在客户端(通常是浏览器)。当浏览器向服务器发送请求时，会自动附带Cookie中的数据。Session的数据存储在服务器端，服务器为每个用户分配一个唯一的Session ID,这个ID通常通过Cookie或URL重写的方式发送给客户端，客户端后续的请求会带上这个Session ID，服务器根据ID查找对应的Session数据。 数据容量:单个Cookie的大小限制通常在4KB左右，而且大多数浏览器对每个域名的总Cookie数量也有限制。由于Session存储在服务器上，理论上不受数据大小的限制，主要受限于服务器的内存大 安全性:Cookie相对不安全，因为数据存储在客户端，容易受到XSS(跨站脚本攻击)的威胁。不过，可以通过设置HttpOnly属性来防止JavaScript访问，减少XSS攻击的风险，但仍然可能受到CSRF(跨站请求伪造)的攻击。Session通常认为比Cookie更安全，因为敏感数据存储在服务器端。但仍然需要防范Session劫持(通过获取他人的Session ID)和会话固定攻击。 生命周期:Cookie可以设置过期时间，过期后自动删除。也可以设置为会话Cookie，即浏览器关闭时自动删除。Session在默认情况下，当用户关闭浏览器时，Session结束。但服务器也可以设置Session的超时时间，超过这个时间未活动，Session也会失效。 性能:使用Cookie时，因为数据随每个请求发送到服务器，可能会影响网络传输效率，尤其是在Cookie数据较大时。使用Session时，因为数据存储在服务器端，每次请求都需要查询服务器上的Session数据，这可能会增加服务器的负载，特别是在高并发场景下。

标签：TLS,八股,缓存,http,HTTP,请求,计算机网络,服务器,客户端
From： https://blog.csdn.net/2301_79604637/article/details/144376595