大佬教程收集整理的这篇文章主要介绍了HTTP详解，大佬教程大佬觉得挺不错的，现在分享给大家，也给大家做个参考。
30张图解http常见的面试题✨✨
###http基本概念 http 是什么？描述一下 http 是超文本传输协议。 能否详细解释「超文本传输协议」？ http的名字「超文本协议传输」，它可以拆成三个部分： Ὂ5;超文本 Ὂ5;传输 Ὂ5;协议
| 协议 | 传输 | 超文本 |
|---|---|---|
| http是一个用在计算机世界里的协议。它使用计算机能够理解的语言确立了一种计算机之间交流通信的规范(两个以上的参与者)，以及相关的各种控制和错误处理方式（行为约定和规范）。 | http 协议是一个双向协议。 我们在上网冲浪时，浏览器是请求方 A ，百度网站就是应答方 B。双方约定用 http 协议来通信，于是浏览器把请求数据发送给网站，网站再把一些数据返回给浏览器，最后由浏览器渲染在屏幕，就可以看到图片、视频了。 http是一个在计算机世界里专门用来在两点之间传输数据的约定和规范。 | http 传输的内容是「超文本」 HTML就是最常见的超文本了，它本身只是纯文字文件,但内部用很多标签定义了图片、视频等的链接，在经过浏览器的解释，呈现给我们的就是一个文字、有画面的网页了。 |
http 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。
http状态码：是用以表示网页服务器超文本传输协议响应状态的3位数字代码
| 五大类http状态 | ||
|---|---|---|
| 具体含义 | 常见状态码 | |
| 1xx | 提示信息是,协议处理中的一种中间状态 | |
| 2xx | 成功，报文已经收到并被正确处理 | 200(OK):是最常见的成功状态码，表示一切正常。如果是非 HEAD 请求，服务器返回的响应头都会有 body 数据。 |
| 204（No Content）也是常见的成功状态码，与200 OK基本相同，但响应头没有 body 数据。 | ||
| 206（Partial Content）：是应用于 http 分块下载或断电续传，表示响应返回的 body 数据并不是资源的全部，而是其中的一部分，也是服务器处理成功的状态。 | ||
| 3xx | 重定向，资源位置发生了变动，需要客户重新发送请求 | 301（Moved PeRMANently）：表示永久重定向，说明请求的资源已经不存在了，需改用新的 URL 再次访问。 |
| 302（Moved PeRMANently）：表示临时重定向，说明请求的资源还在，但暂时需要用另一个 URL 来访问 | ||
| 304（Not Modified）：不具有跳转的含义，表示资源未修改，重定向已存在的缓冲文件，也称缓存重定向，用于缓存控制。 | ||
| 4xx | 客户端错误，请求报文有误，服务器无法处理 | 400（Bad request）：表示客户端请求的报文有错误，但只是个笼统的错误。 |
| 403 （Forbidden）：表示服务器禁止访问资源，并不是客户端的请求出错。 | ||
| 404 （Not Found）：表示请求的资源在服务器上不存在或未找到，所以无法提供给客户端。 | ||
| 5xx | 服务器错误，服务器在处理请求时，内部发生了错误 | 500 （Internal Server Error）与 400 类型，是个笼统通用的错误码，服务器发生了什么错误，我们并不知道。 |
| 501 （Not Implemented）：表示客户端请求的功能还不支持，类似“即将开业，敬请期待”的意思。 | ||
| 502 （Bad Gateway）：通常是服务器作为网关或代理时返回的错误码，表示服务器自身工作正常，访问后端服务器发生了错误。 | ||
| 503 （service Unavailable）：表示服务器当前很忙，暂时无法响应服务器，类似“网络服务正忙，请稍后重试”的意思 |
客户端发送请求时，用来指定服务器的域名。有了 Host 字段，就可以将请求发往「同一台」服务器上的不同网站。
服务器在返回数据时，会有 Content-Length 字段，表明本次回应的数据长度。如上面则是告诉浏览器，本次服务器回应的数据长度是 1000 个字节，后面的字节就属于下一个回应了。
Content-Type 字段用于服务器回应时，告诉客户端，本次数据是什么格式。
Content-Type: text/html; charset=utf-8 上面的类型表明，发送的是网页，而且编码是UTF-8。 客户端请求的时候，可以使用 Accept 字段声明自己可以接受哪些数据格式。 Accept: / 上面代码中，客户端声明自己可以接受任何格式的数据。
Content-Encoding 字段说明数据的压缩方法。表示服务器返回的数据使用了什么压缩格式
@H_382_262@
Content-Encoding: gzip 上面表示服务器返回的数据采用了 gzip 方式压缩，告知客户端需要用此方式解压。 客户端在请求时，用 Accept-Encoding 字段说明自己可以接受哪些压缩方法。 Accept-Encoding: gzip, deflate
Get 方法的含义是请求从服务器获取资源，这个资源可以是静态的文本、页面、图片视频等。 比如，你打开我的文章，浏览器就会发送 GET 请求给服务器，服务器就会返回文章的所有文字及资源。
GET 和 POST 方法都是安全和幂等的吗？ 先说明下安全和幂等的概念：
- 在 http 协议里，所谓的「安全」是指请求方法不会「破坏」服务器上的资源。
- 所谓的「幂等」，意思是多次执行相同的操作，结果都是「相同」的。
那么很明显GET 方法就是安全且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据都是安全的，且每次的结果都是相同的。 POST 因为是「新增或提交数据」的操作，会修改服务器上的资源，所以是不安全的，且多次提交数据就会创建多个资源，所以不是幂等的。
你知道的 http（1.1） 的优点有哪些，怎么体现的？ http 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。 1. 简单 http 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
你知道的 http（1.1） 的优点有哪些，怎么体现的？ http 最凸出的优点是「简单、灵活和易于扩展、应用广泛和跨平台」。
http 基本的报文格式就是 header + body，头部信息也是 key-value 简单文本的形式，易于理解，降低了学习和使用的门槛。
http协议里的各类请求方法、URI/URL、状态码、头字段等每个组成要求都没有被固定死，都允许开发人员自定义和扩充。 同时 http 由于是工作在应用层（ OSI 第七层），则它下层可以随意变化。 httpS 也就是在 http 与 TCP 层之间增加了 SSL/TLS 安全传输层，http/3 甚至把 TCPP 层换成了基于 UDP 的 QUIC。
互联网发展至今，http 的应用范围非常的广泛，从台式机的浏览器到手机上的各种 APP，从看新闻、刷贴吧到购物、理财、吃鸡，http 的应用片地开花，同时天然具有跨平台的优越性。 那它的缺点呢？
http 协议里有优缺点一体的双刃剑，分别是 「无状态、明文传输」，同时还有一大缺点「不安全」。
无状态的好处，因为服务器不会去记忆 http 的状态，所以不需要额外的资源来记录状态信息，这能减轻服务器的负担，能够把更多的 CPU 和内存用来对外提供服务。 无状态的坏处，既然服务器没有记忆能力，它在完成有关联性的操作时会非常麻烦。 例如登录->添加购物车->下单->结算->支付，这系列操作都要知道用户的身份才行。但服务器不知道这些请求是有关联的，每次都要问一遍身份信息。 这样每操作一次，都要验证信息，这样的购物体验还能愉快吗？别问，问就是酸爽！ 对于无状态的问题，解法方案有很多种，其中比较简单的方式用 Cookie 技术。 Cookie 通过在请求和响应报文中写入 Cookie 信息来控制客户端的状态。 相当于，在客户端第一次请求后，服务器会下发一个装有客户信息的「小贴纸」，后续客户端请求服务器的时候，带上「小贴纸」，服务器就能认得了了，
明文意味着在传输过程中的信息，是可方便阅读的，通过浏览器的 F12 控制台或 Wireshark 抓包都可以直接肉眼查看，为我们调试工作带了极大的便利性。 但是这正是这样，http 的所有信息都暴露在了光天化日下，相当于信息裸奔。在传输的漫长的过程中，信息的内容都毫无隐私可言，很容易就能被窃取，如果里面有你的账号密码信息，那你号没了。
http 比较严重的缺点就是不安全：
通信使用明文（不加密），内容可能会被窃听。比如，账号信息容易泄漏，那你号没了。不验证通信方的身份，因此有可能遭遇伪装。比如，访问假的淘宝、拼多多，那你钱没了。无法证明报文的完整性，所以有可能已遭篡改。比如，网页上植入垃圾广告，视觉污染，眼没了。
http 的安全问题，可以用 httpS 的方式解决，也就是通过引入 SSL/TLS 层，使得在安全上达到了极致。
http 协议是基于 TCP/IP，并且使用了「请求 - 应答」的通信模式，所以性能的关键就在这两点里。
早期 http/1.0 性能上的一个很大的问题，那就是每发起一个请求，都要新建一次 TCP 连接（三次握手），而且是串行请求，做了无畏的 TCP 连接建立和断开，增加了通信开销。 为了解决上述 TCP 连接问题，http/1.1 提出了长连接的通信方式，也叫持久连接。这种方式的好处在于减少了 TCP 连接的重复建立和断开所造成的额外开销，减轻了服务器端的负载。 持久连接的特点是，只要任意一端没有明确提出断开连接，则保持 TCP 连接状态。
http/1.1 采用了长连接的方式，这使得管道（pipeline）网络传输成为了可能。 即可在同一个 TCP 连接里面，客户端可以发起多个请求，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。 举例来说，客户端需要请求两个资源。以前的做法是，在同一个TCP连接里面，先发送 A 请求，然后等待服务器做出回应，收到后再发出 B 请求。管道机制则是允许浏览器同时发出 A 请求和 B 请求。
但是服务器还是按照顺序，先回应 A 请求，完成后再回应 B 请求。要是 前面的回应特别慢，后面就会有许多请求排队等着。这称为「队头堵塞」。
「请求 - 应答」的模式加剧了 http 的性能问题。 因为当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一同被阻塞了，会招致客户端一直请求不到数据，这也就是「队头阻塞」。好比上班的路上塞车。
扩：TCP三次握手协议
TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能.数据传输时，应用程序向TCP层发送数据流，TCP就会将接受到的数据流切分成报文段（会根据当前网络环境来调整报文段的大小），然后经过下面的层层传递，最终传递给目标节点的TCP层。为了防止丢包，TCP协议会在数据包上标有序号，对方收到则发送ACK确认，未收到则重传。这个步骤就是我们通常所说的TCP建立连接的三次握手。同时TCP会通过奇偶校验和的方式来校验数据传输过程中是否出现错误。下面来详细介绍三次握手的过程.
三次握手的必要性：为了保证服务器能接收到客户端的信息并做出正确的应答而进行前两次（第一次和第二次）握手，为了保证客户端能够接收到服务端的信息并能做出正确的应答而进行后两次（第二次和第三次）握手。
（1）ACK：TCP规定，只有当ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1。
（2）SYN（SYNchronization）：在连接建立时用来同步序号。当SYN=1而ACK=0时，表明这个是一个连接请求报文。对方若同意建立连接，则响应报文中SYN=1，ACK=1。因此，SYN置1表示这是一个连接请求或连接接受报文。
（3）FIN（finish）：终结的意思，用来释放一个连接。当FIN=1时，表明此报文段的发送方的数据已经发送完毕，并请求释放连接。
（1）第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置1，序列号seq（sequence number）为x；然后，客户端进入sYN_SEND状态，等待服务器的确认。 （2）第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，ACK位置1，确认号ack（acknowledgement number）为x+1；同时，自己还要发送SYN请求信息，将SYN位置1，序列号seq为y；服务器将上述SYN+ACK报文段一并发送给客户端，此时服务器进入sYN_RECV状态。 （3）第三次握手：客户端收到服务器的SYN+ACK报文段。然后将确认号ack设置为y+1，向服务器发送ACK报文段。这个报文段发送完毕后，客户端和服务器都进入ESTABLISHED状态，完成TCP三次握手，之后可以开始传数据。
四次挥手：当客户端和服务器通过三次握手建立了TCP连接之后，当数据传输完毕，就要断开TCP连接，这个过程称为四次挥手。四次挥手说明：
（1）第一次挥手：主机1（可以是客户端，也可以是服务器）设置序列号seq为u，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT状态，这表示主机1没有数据要发送给主机2了。
（2）第二次挥手：主机2收到了主机1发送的FIN报文段，向主机1回复一个ACK报文段，确认号ack为u+1，序列号seq为v；主机2进入CLOSE_WAIT状态；主机1收到主机2发送的ACK报文段之后，进入FIN_WAIT_2状态。
（3）第三次挥手：主机2向主机1发送FIN报文段，设置序列号seq为w，确认号ack为u+1，请求关闭连接，同时主机2进入LAST_ACK状态
（4）第四次挥手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，确认号ack为w+1，序列号seq为u+1，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL（MSL，最长报文段寿命）后依然没有收到回复，则证明服务端已经正常关闭，那么主机1也可以关闭连接了。
httpS 解决了 http 的哪些问题？ http 由于是明文传输，所以安全上存在以下三个风险：
- 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
- 篡改风险，比如强制入垃圾广告，视觉污染，用户眼容易瞎。
- 冒充风险，比如冒充淘宝网站，用户钱容易没。
httpS 在 http 与 TCP 层之间加入了 SSL/TLS 协议。 httpS可以很好的解决了上述的风险：
httpS 是如何解决上面的三个风险的？
- 混合加密的方式实现信息的机密性，解决了窃听的风险。
- 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。将服务器公钥放入到> + 数字证书中，解决了冒充的风险。
SSL/TLS 协议基本流程：
- 客户端向服务器索要并验证服务器的公钥。
- 双方协商生产「会话秘钥」。
- 双方采用「会话秘钥」进行加密通信。
前两步也就是 SSL/TLS 的建立过程，也就是握手阶段。 SSL/TLS 的「握手阶段」涉及四次通信，可见下图：
SSL/TLS 协议建立的详细流程：
首先，由客户端向服务器发起加密通信请求，也就是 ClientHello 请求。 在这一步，客户端主要向服务器发送以下信息： （1）客户端支持的 SSL/TLS 协议版本，如 TLS 1.2 版本。 （2）客户端生产的随机数（Client Random），后面用于生产「会话秘钥」。 （3）客户端支持的密码套件列表，如 RSA 加密算法。
服务器收到客户端请求后，向客户端发出响应，也就是 SeverHello。服务器回应的内容有如下内容： （1）确认 SSL/ TLS 协议版本，如果浏览器不支持，则关闭加密通信。 （2）服务器生产的随机数（Server Random），后面用于生产「会话秘钥」。 （3）确认的密码套件列表，如 RSA 加密算法。 （4）服务器的数字证书。
客户端收到服务器的回应之后，首先通过浏览器或者操作系统中的 CA 公钥，确认服务器的数字证书的真实性。 如果证书没有问题，客户端会从数字证书中取出服务器的公钥，然后使用它加密报文，向服务器发送如下信息： （1）一个随机数（pre-master key）。该随机数会被服务器公钥加密。 （2）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。 （3）客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供服务端校验。 上面第一项的随机数是整个握手阶段的第三个随机数，这样服务器和客户端就同时有三个随机数，接着就用双方协商的加密算法，各自生成本次通信的「会话秘钥」。
服务器收到客户端的第三个随机数（pre-master key）之后，通过协商的加密算法，计算出本次通信的「会话秘钥」。然后，向客户端发生最后的信息： （1）加密通信算法改变通知，表示随后的信息都将用「会话秘钥」加密通信。 （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要，用来供客户端校验。 至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 http 协议，只不过用「会话秘钥」加密内容 [相关http面试]（https://www.cnblogs.com/chenwenhao/p/11267238.html）
以上是大佬教程为你收集整理的HTTP详解全部内容，希望文章能够帮你解决HTTP详解所遇到的程序开发问题。
如果觉得大佬教程网站内容还不错，欢迎将大佬教程推荐给程序员好友。
本图文内容来源于网友网络收集整理提供，作为学习参考使用，版权属于原作者。
如您有任何意见或建议可联系处理。小编QQ：384754419，请注明来意。