HTTP重点知识汇总

前面分享了 JavaScript基础知识总结，今天分享 HTTP 中比较重要的知识点，希望大家都能拿到心仪的 offer，冲鸭，希望大家多多收藏点赞

目录

1. HTTP报文结构
   1-1. 请求报文
   1-2. 响应报文
2. HTTP首部字段
   2-1. HTTP通用首部字段
   2-2. HTTP请求首部字段
   2-3. HTTP响应首部字段
   2-4. HTTP实体（消息体）首部字段
3. HTTP方法
4. 常见的HTTP状态码
5. HTTP-304状态码
6. HTTP与HTTPS的区别及实现方式
   6-1 基本概念
   6-2 HTTP 与 HTTPS 的区别
   6-3 HTTP 的工作方式
   6-4 SSL 的位置
7. HTTP1.0与HTTP1.1以及HTTP2，0的区别
   7-1 http2.0
8. HTTP建立持久连接的意义
9. Cookie、Session 和 Token
10. Cookie 相关首部字段
11. TCP/IP 协议分层管理
12. TCP三次握手四次挥手机制及原因
    12-1 三次握手
    12-2 四次挥手
13. TCP/UDP 的区别
14. localStorage、sessionStorage、Cookie
15. Etag 是怎么计算的，怎么传递的
16. 扫码登录如何实现

1. HTTP报文结构

HTTP报文由报文首部和报文主体构成，中间由一个空行分隔。报文首部包含请求行和请求头部，报文主体主要包含被发送的信息。

报文首部是客户端或服务端需要处理请求或响应的内容及属性，可以传递额外的信息。

一个HTTP报文示例：

GET /index.html HTTP/1.1
Host: www.enjoytoday.cn
Connection: keep-alive
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://www.enjoytoday.cn/posts/326
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8

username=hfcai&sex=man

1-1. 请求报文

一个HTTP请求报文由请求行，请求头部，空行和请求数据4部分组成。

请求行：三部分组成，方法 + URI + HTTP版本

请求头部：首部字段名和字段值构成，中间用 : 分隔。首部字段格式： 首部字段名:字段值

1-2. 响应报文

HTTP响应报文由状态行、响应头部、空行和响应体4部分组成

状态行：HTTP版本 + 状态码 + 响应短语

2. HTTP首部字段

2-1. HTTP通用首部字段

通用首部字段是请求报文和响应报文都会使用的字段，例如：

2-2. HTTP请求首部字段

2-3. HTTP响应首部字段

2-4. HTTP实体（消息体）首部字段

3. HTTP方法

根据 HTTP 标准，HTTP 请求可以使用多种请求方法。

HTTP1.0 定义了三种请求方法：GET、POST 和 HEAD 方法

HTTP1.1 新增了六种方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法

GET与POST方法的区别：

1. get 是从指定的资源请求数据，post 是向指定的资源提交要处理的数据
2. get 请求可以被缓存，post 请求不会被缓存
3. get 请求传输的数据有长度限制，一般为 2048 字符，post 请求传输的数据没有大小限制
4. get 请求的数据一般追加在 URL 的末尾，post 请求的数据在 http 请求体中

一般不使用 GET 请求发送如密码这样的敏感信息。我认为 get 请求比 post 请求更安全。

4. 常见的HTTP状态码

5. HTTP-304状态码

参考文章

304状态码是在协商缓存，缓存命中的时候服务器返回的，告诉客户端，服务器资源没有修改，可以使用客户端自己的缓存。

浏览器缓存分为强缓存（本地缓存）和协商缓存（弱缓存）。

如上图所示，在浏览器第一次发出请求之后，需要再次发送请求的时候，浏览器首先获取该资源缓存的 header 信息，然后根据 Cache-Control 和 Expires 字段判断缓存是否过期。如果没有过期，直接使用浏览器缓存，并不会与服务器通信。该过程为判断是否使用强缓存，即本地缓存。

1. Cache-Control

   该字段是 HTTP1.1 规范，一般利用该字段的 max-age 属性来判断，这个值是一个相对时间，单位为 s，代表资源的有效期。例如：

   Cache-Control:max-age=3600

   除此之外还有几个常用的值：

   • no-cache：表示不使用强缓存，需要使用协商缓存
   • no-store：禁止浏览器缓存数据，每次请求下载完整的资源
   • public：可以被所有用户缓存，包括终端用户和中间代理服务器
   • private：只能被终端用户的浏览器缓存

2. Expires

   该字段是 HTTP1.0 规范，他是一个绝对时间的 GMT 格式的时间字符串。例如：

   expires:Mar, 06 Apr 2020 10:57:09 GMT

   这个时间代表资源的失效时间，只要发送请求的时间在这之前，都会使用强缓存。

   由于失效时间是一个绝对时间，因此当服务器时间与客户端时间偏差较大时，就会导致缓存混乱。

如果缓存过期，浏览器会向服务器发送请求，即使用协商缓存。本次请求会带着第一次请求返回的有关缓存的 header 字段信息，比如以下两个字段：

1. Etag/If-None-Match

   判断响应头中是否存在 Etag 字段，如果存在，浏览器则发送一个带有 If-None-Match 字段的请求头的请求，该字段的值为 Etag 值。服务器通过对比客户端发过来的Etag值是否与服务器相同。如果相同，说明缓存命中，服务器返回 304 状态码，并将 If-None-Match 设为 false，客户端继续使用本地缓存。如果不相同，说明缓存未命中，服务器返回 200 状态码，并将 If-None-Match 设为 true，并且返回请求的数据。

2. Last-Modified/If-Modified-S***rong>

   除了 Etag 字段之外，客户端还会通过服务器返回的 Last-Modified 字段判断是否继续使用缓存，该字段为服务器返回的资源的最后修改时间，为UMT时间。浏览器发送一个带有 If-Modified-Since 字段的请求头的请求给服务器，该字段的值为 Last-Modified 值。服务器收到之后，通过这个时间判断，在该时间之后，资源有无修改，如果未修改，缓存命中，返回 304 状态码；如果未命中，返回 200 状态码，并返回最新的内容。

Cache-Control 与 Expires 的优先级：

​ 两者可以在服务端配置同时使用，Cache-Control 的优先级高于 Expires。

Last-Modified/If-Modified-Since 已经可以判断缓存是否失效了，为什么出现 Etag/If-None-Match?

​ Etag/If-None-Match 是实体标签，是一个资源的唯一标识符，资源的变化都会导致 ETag 的变化。出现 Etag 的主要原因是解决 Last-Modified 比较难解决的问题：

• 一些文件也许会周期性的修改，但是他的内容并不发生改变，这个时候我们并不希望客户端认为这个文件修改了
• 某些文件在秒以下的时间内进行修改了，If-Modified-Since无法判断。UNIX时间只能精确到秒

Last-Modified 和 Etag 可以一起使用， Etag 的优先级更高。

刷新页面的问题：

F5刷新：不使用强缓存，使用协商缓存

ctrl+F5：二者都不使用

6. HTTP与HTTPS的区别及实现方式

参考文章

基本概念

HTTP是超文本传输协议，是一个简单的请求-响应协议，它默认工作在TCP的80端口。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。协议以明文的方式进行发送，不提供任何方式的数据加密。因此HTTP协议不适合传输一些敏感信息

HTTPS是超文本传输安全协议，是一种安全通信的传输协议。HTTPS经由HTTP进行通信，但利用 SSL/TSL 来进行加密数据包。HTTPS开发的主要目的是提供网站服务器的身份认证，保护数据交换的隐私与完整性。

SSL（Secure Sockets Layer ）

HTTPS默认工作在 TCP 的443 端口，它的工作方式如下：

• TCP三次同步握手
• 客户端验证服务端数字证书
• DH 算法协商对称加密加密算法的密钥、hash 算法的密钥
• SSL 安全加密隧道协商完成
• 网页以加密的方式进行传输，用协商的对称加密算法和密钥加密，保障数据机密性；用协商的 hash 算法进行数据完整性保护，保证数据不被篡改。

HTTP 与 HTTPS 的区别

• HTTP 使用明文传输，数据都是未加密的，安全性较差；HTTPS 数据传输过程是加密的，安全性较好；
• 使用 HTTPS 一般需要到 CA 申请证书
• HTTP页面的响应比 HTTPS 快，主要是因为 HTTPS 除了 TCP 的三个包之外，还要加上 ssl 握手的 9 个包
• HTTP 和 HTTPS 是完全不同连接方式，用的端口也不一样， 前者是80， 后者是 443
• HTTPS 其实就是建构在 SSL/TSL 之上的 HTTP 协议，所以要比 HTTP 更消耗服务器资源

HTTPS 的工作方式

1. 客户端发起 HTTPS 请求

   建立TCP连接之后，客户端发起请求

2. 服务端的配置

   服务端收到请求之后，会有一套公钥和私钥，这对公钥和私钥其实就是一套数字证书，一般都是由受信任的证书颁发机构进行签发。

3. 传送公钥

   服务端将公钥传递给客户端，里面包含很多信息，如证书的颁发机构，证书的过期时间

4. 客户端解析证书

   这部分工作由客户端的 TSL 来完成，首先验证证书是否有效。如果没有问题，就会随机生成一个 key，然后利用公钥对 key 的值进行加密。

5. 传送加密的信息（key）

   将加密过后的 key 传递给服务器

6. 使用私钥解析加密信息（key）

   服务器使用自己的私钥解密加密信息得到 key

7. 使用客户端的 key，利用对称加密加密信息，并发送给客户端

   把内容通过该 key 进行对称加密，并传输给客户端

8. 客户端使用 key 解密信息

   客户端收到信息之后利用 key 进行解密

重点：客户端会生成 key，key 的传输使用非对称加密，而数据的传输使用 key 进行对称加密。

对称加密：加密密钥和解密密钥是同一个，效率较高

非对称加密：加密密钥和解密密钥不是同一个，效率较低

由于非对称加密的效率比较低，因此我们通常不使用非对称加密对整个文件进行加密，而采用对称加密对文件加密，非对称加密对对称加密的密钥加密，然后将对称加密后的文件和非对称加密后的密钥一起在网上传送。

SSL 的位置

​

在发送方，SSL接受应用层的数据（如HTTP或者IMAP报文），对数据进行加密，然后把加了密的数据送往TCP套接字。

在接收方，SSL从TCP套接字读取数据，解密后把数据交给应用层。

使用非对称加密进行文件传输。通信双方在传输时需要交换各自的公钥。

SSL提供以下三个功能：

（1）SSL服务器鉴别：允许用户证实服务器的身份。具有SSL功能的浏览器维持一个表，上面有一些可信赖的认证中心CA（Certificate Authority）和它们的公钥。

（2）加密的SSL会话：客户和服务器交互的所有数据都在发送方加密，在接收方解密。

（3）SSL客户鉴别：允许服务器证实客户的身份。

7. HTTP1.0与HTTP1.1以及HTTP2，0的区别

1. 长连接

   在HTTP1.0中，TCP每建立一次连接就只能发送一个 HTTP 请求并得到一个响应，当需要再次发送请求的时候，又得重新建立 TCP 连接，这样就会很耗时间，传输效率较低。

   HTTP1.1中支持长连接和流水线传输，在一个 TCP 连接中可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟。在 HTTP1.1 中默认开启 Connection: Keep-Alive，一定程度上弥补了 HTTP1.0 的缺点

2. 缓存处理

   在 HTTP1.0 中主要使用 Expires、Last-Modified、If-Modified-Since 头部字段来作为缓存判断的标准

   在 HTTP1.1 中增加了 Cache-Control、Etag、If-None-Match、If-Match 等头部字段来提供可选的更多的缓存策略

3. 带宽优化及网络连接的使用

   HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。

   HTTP1.1 中引入了 Range 头部字段，它允许只请求资源的某个部分，即返回状态码是 206

4. Host头处理

   在 HTTP1.0 中认为每台服务器绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名。但随着虚拟技术的发展，在一台物理设备上可以存在多台虚拟主机，并且他们共享同一 IP 地址 。在 HTTP1.1 的请求消息和响应消息中都应支持 HOST 头域，且请求消息中没有 HOST 头域会报一个错误。

5. 错误通知的管理

   HTTP1.1 中新增了 24 个错误状态码，如 409 表示请求的资源与资源的当前状态发生冲突；410表示服务器上的某个资源被永久性删除。

http2.0

1. 多路复用，如上

2. 在 1.1 中消息体一般都会经过gzip压缩或者本身传输的就是压缩过后的二进制文件，而消息头部是以文本进行传输的。但是在2.0中对消息头部进行了压缩。

3. 服务器推送

   服务端推送是一种在客户端请求之前发送数据的机制。

   在HTTP1.1中这些资源每一个都必须明确地请求。这是一个很慢的过程。浏览器从获取HTML开始，然后在它解析和评估页面的时候，增量地获取更多的资源。因为服务器必须等待浏览器做每一个请求，网络经常是空闲的和未充分使用的。

   为了改善延迟，HTTP2.0引入了server push，它允许服务端推送资源给浏览器，在浏览器明确地请求之前，免得客户端再次创建连接发送请求到服务器端获取。这样客户端可以直接从本地加载这些资源，不用再通过网络。

   

8. HTTP建立持久连接的意义

在 HTTP1.0 中每发送一次请求都要重新建立 TCP 连接并且关闭连接。这样做是很耗费时间的。而在HTTP1.1 中默认开启长连接，一次TCP连接可以发送多个HTTP请求，避免了重复建立释放连接的开销，加速了数据的传输，节省了时间和带宽。

那么长连接什么时候会释放呢？

客户端的长连接不可能一直拿着，会有一个超时时间，服务器会告诉客户端超时时间，譬如：

Access-Control-Allow-Origin: http://mall.sillywa.com
Connection: keep-alive
Content-Length: 43574
Content-Type: application/json; charset=utf-8
Date: Wed, 03 Mar 2021 07:34:49 GMT
Keep-Alive: timeout=5
Vary: Origin

Keep-Alive: timeout=5 表示这个 TCP 通道可以保持 5s。另外还可能有 max=xxx，表示这个长连接最多接受xxx次请求就断开。对于客户端来说，如果服务端没有告诉是客户端超时时间也没关系，服务端可能主动发起四次挥手断开TCP连接，客户端就能够知道该TCP连接已经无效。

长连接数据传送完成识别：

1. 判断传输的数据是否达到了 Content-Length 指示的大小
2. 没有 Content-Length，由于数据是分块传输的，这时候就要根据块的编码来判断了，最后一个一个编码的数据是一个空块，表明本次传输结束

9. Cookie、Session 和 Token

参考答案

10. Cookie 相关首部字段

Cookie用于用户识别及状态管理，为Cookie提供服务的首部字段有：

当服务器准备管理客户端状态的时候，会告知各种信息：

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;

Cookie 相关的首部字段有：

1. expires

   指定浏览器可发送Cookie的有效期。当省略 expires 属性的时候，其有效期仅限于维持浏览器会话期间。

   另外，一旦 Cookie 从服务器发送至客户端，服务器就不存在可以显示删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。

2. path

   默认为 /，就是根目录。子路径页面能够访问父路径页面的 Cookie。兄弟路径页面之间的 Cookie 不能互相访问

3. domain

   可以访问该 Cookie 的域名。

   而跨域访问，如域A为http://t1.test.com，域B为http://t2.test.com，那么在域A生产一个令域A和域B都能访问的cookie就要将该cookie的domain设置为.http://test.com；如果要在域A生产一个令域A不能访问而域B能访问的cookie就要将该cookie的domain设置为http://t2.test.com。

4. secure

   Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie。

   发送 Cookie 时，指定 secure 属性的方法如下：

   Set-Cookie:name=value; secure

5. HttpOnly

   Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使得 JavaScript 脚本无法获取 Cookie。其主要目的是为了防止跨站脚本攻击（XSS，Cross-site scripting）对 Cookie 的信息窃取。

   指定发送 HttpOnly 属性的 Cookie 的方法如下所示：

   Set-Cookie:name=value; HttpOnly

11. TCP/IP 协议分层管理

传输层：可靠传输（丢包重发） 、流量控制、不可靠传输（只需要发送一个数据包）

网络层：负责选择最佳路径、规划 IP 地址

数据链路层：帧的开始和结束、透明传输（数据中出现了帧的结束标志，需要采用转义字符）、差错校验（循环冗余检测）

12. TCP三次握手四次挥手机制及原因

三次握手

为什么需要三次握手，两次行不行？

假设是两次握手，客户端刚开始发送第一个建立连接的请求，但是由于该请求在某一个路由器中停留时间过长，客户端一段时间没收到服务器的响应消息，就会再发一个建立连接的请求，这个请求达到服务器，并成功建立连接，之后数据传输完成，关闭连接。这时候先前发送的第一个建立连接的请求，终于通过网络传到了服务器，服务器收到请求，返回一个数据包，并立即打开连接，这是客户端已经关闭了，对服务端的数据包不予理睬，这样就会导致服务端资源的浪费。

为什么不能四次握手？四次握手的流程：

1. 客户端发送：SYN=1,ACK=0,seq=x
2. 服务端收到客户端消息，发送：ACK = 1, 确认号=x+1,seq=y
3. 服务端发送同步建立连接，发送：SYN=1，确认号=x+1，seq = w
4. 客户端收到发送：ACK=1，确认号=w+1,seq = x+1

在这个过程中，显然第二步和第三步可以合并，不需要单独发送一个 SYN

四次挥手

既然握手的时候，服务端发送的两个请求可以合并，那么释放连接的时候，是否也能合并，只需三次握手呢？

我们的回答是不能够，因为当服务器收到客户端关闭连接的请求的时候，服务端可能还在继续发送数据，但是他又必须先给客户端一个回应，说我收到了请求。等服务端的数据发送完毕之后，再发一个数据包说我已经可以关闭请求了。客户端收到之后再作出回应。

客户端为什么要有TIME-WAIT阶段？

防止最后一个数据包丢失而导致服务器接收不到，一段时间后服务器会重新发送第三个数据包。如果此时客户端已经关闭了，则收不到第三个数据包，服务端也就无法正常关闭了。

13. TCP/UDP 的区别

14. localStorage、sessionStorage、Cookie

1. 生命周期

   localStorage 的生命周期是永久的，关闭页面或者浏览器之后，localStorage 里面的数据也不会消失。localStorage 除非主动删除数据，否则永远不会消失。

   sessionStorage 的声明周期仅在当前会话下有效，sessionStorage 是在同源的窗口中始终存在的数据，只要这个浏览器窗口没有关闭，即使刷新页面或者进入同源的另一个页面，数据依然存在。但是 sessionStorage 在关闭了浏览器窗口后就会被销毁。

2. 存储大小

   两者一般都是 5 MB

3. 存储位置

   保存在客户端，不与服务器进行交互通信

4. 存储内容类型

   只能存储字符串，对于复杂类型，可使用JSON

5. 获取方式

   window.localStorage

   window.sessionStorage

6. 应用场景

   localStorage：常用于长期登录（+判断用户是否已登录），适合长期保存在本地的数据

   sessionStorage:一次登录

Cookie：是浏览器对session的实现

1. 如果不设置过期时间，数据保存在内存中，生命周期随着浏览器的关闭而结束；如果设置过期时间，数据保存在硬盘中，关闭浏览之后，cookie 数据仍然存在。
2. cookie保存的数据大小不能超过 4 kb
3. cookie也只能存储字符串

使用方法

localStorage.setItem(key, value)
localStorage.getItem(key)
localStorage.removeItem(key)
localStorage.clear()

15. Etag 是怎么计算的，怎么传递的

使用 hash 算法进行编码，在响应头部里面的 Etag 字段进行传递

16. 扫码登录如何实现

扫码登陆要求已经用户在手机端登录

1. 用户在浏览器点击扫码登录，浏览器向服务端发送一个请求，服务端生成一个唯一 id，并将这个 id 写入二维码并且返回这个二维码给浏览器
2. 浏览器收到之后，开始带上这个 id 轮询后台提供的一个接口，判断用户是否扫码并确认登陆了
3. 用户拿出手机扫描二维码，得到这个 id，并确认登陆，然后会将用户信息和 id 传给服务器
4. 服务器拿到用户信息 和 id 之后，写入数据库
5. 这时候服务器轮询就会得到结果，说明用户已经确认登陆，并且得到服务器返回的 token 和用户信息。