1、TCP/IP模型和OSI模型的区别

OSI模型是一个用于计算机或通信系统之间互相联系的标准体系。将计算机网络分成不同的7个层级，每个层级都有自己相对应的功能。每个层级都建立在下方层级之上。下层为上层提供服务，上层为下层提供接口。七层从下到上分别是物理层、数据链路层、网络层、传输层、会话层、表示层、应用层（物联网叔会使用）。相对来说，TCP/IP模型使用的更加广泛，从下到上分别是网络接口层、网络层、传输层、应用层（接网叔用）。每层都对应不同的功能。

网络接口层：网络接口层对应OSI模型的物理层和数据链路程，主要负责相邻节点之间的物理数据传输，例如以太网、WIFI等，但是不规定具体怎么传输，这使得TCP/IP模型具有更高的灵活性。并提供错误检测的功能，发现错误之后直接丢弃，纠错由上层TCP来完成。

网络层：网络层对应OSI模型的网络层，主要的传输协议是IP，主要负责数据包的路由和转发。TCP/IP模型的网络层去掉了流量控制和差错控制，导致网络层的传输是不可靠的。中间节点在收到一个分组之后会尽最大努力去转发。IP协议使用IP地址来标识主机和网络，并进行逻辑地址寻址，从而进行路由转发IP数据报。

传输层：传输层对应OSI模型的传输层，主要负责传输端到端的数据。主要的传输层协议包括TCP和UDP。因为网络层是没有顺序的，传输层收到的数据报可能是有问题的，传输层负责进行差错控制、流量控制、可靠传输（TCP）。TCP/IP模型的数据传输的可靠性和安全性主要由传输层来完成。TCP协议提供可靠的数据传输，确保数据的正确性和完整性；而UDP协议则是无连接的，适用于不要求可靠性的传输，如实时音频和视频流。

应用层：应用层对应OSI模型的会话层和表示层和应用层，提供直接与用户交互的接口。为网络上的各种应用程序提供服务。如电子邮件（SMTP）、网页浏览（HTTP）、文件传输（FTP）等。

2、从输入 URL 到页面展示到底发生了什么

1、输入网址，解析协议（HTTP/HTTPS）、域名、端口（默认80/443）和路径。

2、检查浏览器缓存是否存在该资源，如果有直接返回，如果没有进入下一步网络请求。

3、DNS域名解析：网络请求前，先进行域名解析，获取请求域名的IP地址。DNS解析的时候首先本地浏览器缓存，查询操作系统Hosts文件，查询本地DNS服务器（通常是家里路由器），查询根域名服务器，查询顶级域名服务器。最后查询到域名对应的IP地址。查询包括递归查询和迭代查询两种方式。

4、建立连接：浏览器与服务器IP通过三次握手建立TCP连接。

5、客户端发送HTTP请求：连接建立后，客户端会构建请求行、请求头、请求体等信息，并把和该域名相关的Cookie等数据附加到请求头中，向服务器发送请求信息。如果是HTTPS协议的话，还会涉及到加密和解密的问题。

6、服务器处理请求并返回HTTP资源：服务器收到请求信息，根据请求信息生成相应数据。

7、浏览器接收数据：浏览器接收之后开始渲染页面。

8、断开连接：TCP四次挥手断开浏览器与服务器之间的TCP连接。

3、HTTP请求报文和响应报文是怎样的，有哪些常见的字段

http报文分为请求报文和响应报文

请求报文主要由请求行、请求头、请求体和空行组成。

请求行包括：

方法：指定要执行的操作，如GET，POST，DELETE，PUT等
资源路径：请求的资源的URL，如 /api/login。
HTTP版本：请求使用的HTTP版本，如HTTP/1.0、HTTP/2

请求头包括：

Host：请求的服务器的域名。
Accept：客户端可以处理的媒体的类型。
Accept-Encoding：客户端能够解码的类型编码。
Authorization：用于认证的用户信息，比如token。
Content-Length：请求体的长度。
Content-Type：请求体的类型。
Cookie：存在客户端的cookie数据。
Connection：管理连接的选项，如keep-alive

空行是放在请求头和请求体之间的部分，用来区分请求头和请求体。

响应报文是服务器向客户端返回的数据格式，用来返回服务器对客户端做出的请求的处理结果以及相关数据，一个HTTP响应报文通常包括状态行、响应头、空行和响应体。

状态行包括HTTP版本、状态码和状态信息，如HTTP/1.1。

响应头也是以键值对的方式提供信息，和请求头类似，用来告知客户端响应的详细信息，主要包括

Content-Length：响应体的长度。
Content-Type：响应体的类型。
Sever：服务器的信息。
Expries：响应的过期时间，时间之后的内筒被认为是无效的。
ETag：响应体的实体标签，用来缓存和条件请求。
Last-Modified：资源最后被修改的日期和时间。
Location：在重定向时指向新的资源的位置。
Set-Cookie：在响应中设置Cookie

空行（Empty Line）在响应头和响应体之间，表示响应头的结束。而响应体是服务端实际传输的数据，可以是文本、HTML页面、图片、视频等，也可能为空。

4、HTTP有哪些请求方式？

Get：请求指定的资源

Post：向指定资源提交数据并处理请求

Put：更新指定资源

Delete：删除指定资源

Head：获取报文首部，不返回报文主体

Options：查询服务器支持的请求方发

Patch：对资源进行部分更新

5、GET请求和POST请求的区别

1、用途：Get通常用来获取数据，Post通常用来提交数据

2、数据传输：Get通常把请求参数放在URL路径中，Post通常把请求参数放在请求体中

3、安全性：Get把请求参数暴露在URL路径中，不安全。Post通常把请求参数放在请求体中，相对更安全

4、数据大小：Get请求收到URL长度的限制，数据量有限。Post请求理论上没有长度限制

5、缓存：Get请求通常会被缓存，Post请求默认不会缓存

6、幂等性：GET请求是幂等的，即多次执行相同的GET请求，资源的状态不会改变；POST请求不是幂等的，因为每次提交都可能改变资源状态。

6、HTTP中常见的状态码有哪些？

200：客户端请求成功

201：创建了新的资源

204：无内容，服务器成功处理请求，但是没有返回任何内容

301：永久重定向

302：临时重定向

304：请求的内容没有被修改过，所以服务器不会返回网页内容，而是返回缓存

401：请求需要身份验证

403：请求的资源禁止被访问

404：服务器无法找到对应的资源

500：服务器内部错误

503：服务器不可用

7、什么是强缓存和协商缓存？

强缓存和协商缓存是 HTTP 协议中的缓存机制，可以用来缓解服务器的压力和提高网页加载的速度。

目前使用的强缓存是通过 Http 响应中的 Cache-Control 字段实现的，通过 max-age 告诉浏览器在指定的时间范围内可以直接使用缓存中的内容，无需再次访问。

当强缓存失效的时候，浏览器发送 HTTP 请求到服务器，服务器通过和此次请求头中派生出来的条件请求头，对比响应头中的 ETag 和 Last-Modified 字段进行对比。如果对比结果不一致，说明资源已经被修改，服务器返回已经修改的值，浏览器更新本地缓存。如果没有被修改，服务器返回 304 状态码，浏览器直接从缓存中获取数据。

基于 Last-Modified 的协商缓存。 Last-Modified 是资源最后一次修改的时间，通过响应头进行返回。当客户端收到响应的时候，会在下一次请求的请求头中加入 If-Modified-since 字段，服务器收到请求之后，会把这个字段的值和当前资源的 Last-Modified 值进行比较。如果一致，服务器返回304状态码，结果从缓存中获取。如果不一致，说明资源已经被更改过了，那服务器正常的响应，返回200状态码。

但是这种方法有两个缺点。第一，Last-Modified 是根据修改时间来判断资源有没有被修改过，但是如果在不改变文件的内容的时候，文件的修改时间依然有可能改变，比如我修改了文件名，又改了回来。文件的内容是不变的。但是这个时候文件的修改时间已经发生了改变，会导致缓存失效的情况发生。第二，因为 Last-Modified 记录的时间是秒级别的，如果说我对文件的改动在几百毫秒范围内，那么 Last-Modified 是不变的，但是文件确实已经被更改了，这个时候访问会时产生一致性问题。

基于 ETag 的协商缓存。把根据时间判断换成了根据文件内容计算出的哈希值。ETag 是服务器为每一个资源生成的唯一的标识符，在响应头中获取。客户端在下一次请求的请求头中的 If-None-Match 字段携带上这个 ETag，服务器比较两个 ETag 的值是否相同。如果相同，返回304状态码，使用缓存中的内容。如果不同，说明资源发生变化，返回200状态码，重新计算 ETag 返回给客户端。

8、HTTP1.0和HTTP1.1的区别？

HTTP1.1 默认支持持久化连接，一个 TCP 连接建立之后可以发送多次http请求，减少了重复的建立连接和关闭连接的开销。HTTP1.0 默认为短连接，每次请求都需要建立一个新的 TCP 连接，需要通过 connection: keep-alive 来实现持久化连接。

HTTP1.1 支持管道化，但是需要显示开启，在客户端收到第一个请求的响应之前，可以发送多个 HTTP 请求。但是HTTP1.0不支持。

HTTP1.0 主要使用 if-modified-since/Expires 来判断缓存是否过期，但是 HTTP1.1 主引入了更多的缓存控制策略 ETag/If-None-Match 等更多的缓存头（请求头和响应头）来控制缓存策略。

HTTP1.1 增加了一些 HTTP 状态码，例如 100是 continue，增强了错误处理。

HTTP1.1 引入了Host 头，允许指定请求的的主机名，这使得在同一台服务器上托管多个域名成为可能。

9、HTTP2.0与HTTP1.1的区别？

HTTP2.0 使用的是二进制格式的传输，比HTTP1.1 中使用的 ASCII 传输的更快，也更安全，减少了解析的时间，效率更高。

HTTP2.0 采用了多路复用。HTTP1.1 中客户端可以在收到第一个请求的 ACK 之前，发送多个请求，但是接收的响应必须按照请求的顺序进行接收，如果其中某个响应失效了， 这会导致出现对头阻塞现象。HTTP2.0 引入了多路复用，HTTP2.0 把连接抽象成多个流，每个流中包含流标识符，接受的时候按照流标识符的顺序进行接收就可以解决对头阻塞问题。

HTTP2.0 引入了服务器推送机制，当浏览器发出了请求的时候，服务器接收到请求后，可能把浏览器所需要的内容全都发送过去，减少页面的加载时间。

10、HTTP3.0

HTTP3.0 使用 QUIC 协议，使用UDP 协议来传输数据，一个连接上的 stream 流之间没有相互关联，如果一个 UDP 包丢失了，不影响其他的 stream 的传输，不存在对头阻塞问题。

HTTP3.0 使用 QUIC 加 TLS1.3 协议，建立连接的时间可以减少到 1RTT，减少页面的加载时间。

HTTP3.0 在连接切换的时候不需要重新建立新的连接，可以实现连接迁移，将连接迁移到新的 IP 地址，减少连接的中断时间。

安全性很高，HTTP3.0 使用了 TLS 协议，增加了连接的安全性。

11、HTTPS和HTTP有什么区别

两者的区别主要在于安全性和数据加密

1、加密层：HTTPS在HTTP协议的基础上增加了SSL/TSL协议作为加密层，确保数据传输的安全性。但是HTTP协议传输是明文传输，更容易受到攻击。

2、HTTP建立连接相对简单，在进行TCP三次握手之后就可以进行数据的传输，但是HTTPS在TCP三次握手建立连接之后还需要进行SSL/TSL的三次握手连接之后才可以进行数据加密传输。

3、端口：HTTPS协议常用端口为443，HTTP协议常用端口为80

4、HTTPS协议需要向CA（数字证书认证机构）申请数字证书，用来保证服务器是可信的

12、HTTPS的工作原理

HTTPS主要是基于SSL/TLS协议，用来确保数据的安全性和完整性，建立连接和传输数据的流程如下所示：

1、密钥交换：客户端发起HTTPS请求之后，服务器会发送他的公钥证书给客户端

2、证书验证：客户端收到了证书之后，会验证该证书是否由受信任的机构（CA）颁发，检查证书的有效性。

3、加密通信：证书验证通过后，客户端会生成一个随机的对称加密秘钥，并使用服务器的公钥加密这个秘钥，然后发送给服务器。

4、建立安全连接：服务器使用自己的密钥解密得到对称加密密钥，此时客户端和服务器都有相同的密钥，可以进行加密和解密的操作。

5、数据传输：使用对称加密秘钥对所有的数据进行加密和解密，确保数据在传输的过程中的完整性

6、完整性校验：SSL/TLS协议还包括对数据的完整性进行校验的机制，比如加入消息认证码，确保消息在传输的过程中不被破坏。

7、结束连接：数据传输完成之后，通信双方会进行会话秘钥的销毁，以确保不会留下消息隐患。

13、TCP和UDP的区别

1、TCP是面向连接的协议，在传输之前需要先建立连接，UDP是无连接的，不需要建立连接就可以进行数据传输。

2、TCP提供可靠的数据传输，保证数据报的顺序和完整性，UDP不保证顺序和完整性。

3、TCP具有拥塞控制机制，可以根据网络状况调整传输速率，但是UDP没有拥塞控制，UDP有一般有固定的传输速率。

4、TCP通过滑动窗口机制进行流量控制，避免传输过快造成数据报丢失，UDP没有流量控制。

5、TCP能够检测并重传丢失的数据报，UDP不提供错误恢复机制。

6、TCP报文头部较为复杂，包括源端口、目的端口、确认号、序号、数据偏移、标志位等。UDP报文头部只包括源/目的端口、报文长度、校验和。

7、由于TCP具有建立连接、数据校验和错误重传等机制，导致TCP在数据开销方面高于UDP，UDP较简单，开销比较小。

8、TCP适用于需要可靠传输的应用，如网页浏览、文件传输等；UDP适用于对实时性要求高的应用，如语音通话、视频会议等。

14、TCP连接如何确保可靠性？

TCP通过差错控制、流量控制、超时重传和拥塞控制等机制确保连接的可靠性。

1、序列号，每一个tcp传输帧都有自己的序列号，确保数据包的传输顺序正确。

2、数据校验：TCP使用校验和来确保传输帧的正确性，如果接收方发发现数据帧有问题，那么就会丢弃这个数据包，并等待重传。

3、确认应答和超时重传：接收方在收到数据帧之后，会发送一个ACK确认帧告诉发送发我已经收到了你发送的数据包，如果发送方没有收到这个数据帧，那么发送方会进行超时重传。

4、流量控制：TCP通过滑动窗口机制来进行流量控制，确保接收方能够来得及处理发送方发送的数据。

5、拥塞控制：TCP通过慢启动，拥塞避免、快重传、快恢复的机制进行控制传输速率，避免网络拥塞。流量控制是说发送方发送太快，接收方收不过来，让发送方慢点发。拥塞控制是指网络中太过于拥堵，让发送方慢点发送。

15、拥塞控制是怎么实现的？

TCP拥塞控制可以在网络拥塞的时候动态的控制网络中的数据传输速率，以便于防止网络过载。TCP拥塞控制主要体现在以下几个方面。

1、慢启动阶段：发送初始阶段，TCP发送方会以较小的发送窗口进行发送，随着每次发送方传输数据帧之后，窗口逐渐成指数级增大，这就是慢启动。窗口逐渐增大到阈值，停止慢启动阶段。这个阶段在网络刚开始的时候逐步的增大传输的速率，可以有效避免网络的拥堵。

2、拥塞避免阶段：当慢启动阶段到达阈值之后，TCP双方就会进入拥塞避免阶段。在拥塞避免阶段，发送方会以线性增加的方式增加发送窗口的大小，控制发送的速率，避免网路拥堵。

3、快重传：如果发送方连续收到三个（即连续的四个）相同的ACK确认帧，那么发送方会让为网络中出现了拥堵，于是会重新发送没有收到ACK确认帧的数据帧，而不用等到计时器超时的时候再进行超时重传，有效的恢复了网络中的数据包的丢失问题。

4、快恢复：在发生快重传之后，就会触发快恢复阶段。发送方把慢启动阈值设置为当前窗口的一半，并将拥塞窗口设置为当前的慢启动阈值，直接进入拥塞避免阶段，于是发送方将会以线性增长的方式进行发送数据包。这有助于更快的从拥塞中恢复。

16、TCP流量控制是怎么实现的？

TCP通过滑动窗口机制来进行流量控制。让发送方发送的速率不要过快，让接收方来得及接收。动态调整发送方的数据传输速率。

滑动窗口大小：在TCP通信中，每个TCP报文段都包含一个窗口字段，该字段指示发送方可以发送多少字节的数据而不等待确认。

接收窗口大小：接收方通过TCP报文段中的窗口字段告诉发送方自己当前的可接收窗口的大小表示接收方缓冲区中还有多少窗口可用。

动态调整：发送方会根据接收方窗口的大小动态的调整发送窗口的大小

确认机制：接收方会发送ACK报文即确认报文来告知发送发自己收到了多少数据包，以便于发送方知道从哪个帧开始发送数据。接收方也可以通过ACK报文中的窗口字段告知发送方还可以接受多少数据。

17、UDP怎么实现可靠传输

UDP不属于连接型协议，具有消耗资源小、传输速度快的特点，所有通常的音频、视频等数据会通过UDP协议进行传输，因为UDP即使在传输的过程中丢失了一两个数据包也没有关系。传输层无法保持数据传输的可靠性，可靠性只能通过应用层来保证。把 TCP 协议在传输层实现的可靠传输转到了应用层。

提供超时重传机制和确认序列号用来对数据进行确认和排序。

发送端：首先在 UDP 数据报的载荷里封装一个自定义的首部，包含确认序列号（ACK/seq）和时间戳（用来计算RTT，接收方收到的当前时间减去时间戳上的时间就是RTT）,根据 RTT 算出合适的RTO，然后以等——停的方式发送数据报，就是只有收到了上一个数据报的 ACK 之后，才会发送下一个数据报。当时间超时没有收到 ACK，发送端重新传输数据，并将 RTO 扩大为原来的两倍，重新开始计时传输。

接收端：接收到一个数据报之后，获取到该数据报首部的时间戳和序列号（seq），并在首部添加确认数据报（ACK）返回给发送端。根据获取到的这个序列号的大小进行排序和去重。

18、TCP三次握手

第一次握手：客户端向服务器发送一个 SYN 报文，客户端进入 SYN_SENT 状态，此次握手会消耗一个序列号。

第二次握手：服务器收到了 SYN 报文，如果同意建立连接，直接向客户端返回一个 SYN-ACK 报文，同时服务器进入 SYN_RCVD 状态，此次握手会消耗一个序列号。

第三次握手：客户端收到服务器的 SYN-ACK 之后，发送一个 ACK 报文给服务器，之后两者都进入 ESTABLISHED 状态，表示连接建立成功。

通过三次握手，客户端和服务器都明确了对方有发送和接收的能力。第一次握手确定了客户端到服务器是连通的，第二次握手确定了服务器到客户端也是连通的。第三次握手服务器确认了客户端可以接收到自己发的消息。如果仅仅只有两次握手，服务器无法确定客户端是否真的能接收到自己发的信息。比如客户端刚发了第一次握手之后就关闭了连接，但是由于网络的延时，导致这个报文很久才到达服务器，服务器会以为连接已经建立好了，于是开始发送消息，但是客户端却接收不到资源，造成了资源的浪费。

19、TCP四次挥手

第一次挥手：客户端发送一个 FIN 报文给服务器，表示自己要断开连接。此次挥手要消耗一个序列号，客户端进入 FIN-WAIT-1 状态。

第二次挥手：服务器收到 FIN 报文后，服务器返回一个 ACK 报文表示接收到，服务器进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。

第三次挥手：服务器也要断开连接，发送 FIN 报文给客户端，随后服务器进入 LAST-ACK 状态，此次挥手也要消耗一个序列号。

第四次挥手：客户端收到 FIN 报文后，客户端返回 ACK 报文，客户端进入 TIME-WAIT 状态，服务器在收到客户端发送的 ACK 报文之后，进入 CLOSE 状态。客户端在发送 ACK 报文之后，还要再等待 2MSL 之后，如果没有新的连接请求，才会进入 CLOSE 状态。

TCP 是全双工通道，任何一方向的连接关闭不影响另一个方向的连接。只有通过第四次挥手才能确认双方都受到了对方的 ACK 报文，只有双方都确认对方收到了自己的释放通知，整个 TCP 连接才会释放。两次挥手释放一个方向的连接，两个方向的挥手需要四次挥手。

客户端等待 2MSL 是因为如果第四次挥手的 ACK 报文段没有到达服务器，服务器可能触发超时重传，保证还能接收到信息，以确保最终完整释放整个资源。

20、HTTP长连接

HTTP 的 keep-alive，主要是说 HTTP1.0的长连接，是应用层的机制，称为 HTTP 长连接。HTTP 请求每次请求都会经过，建立 TCP 连接，发送 HTTP 请求，获取资源，释放连接。但是每次连接都只能发送一次请求，这称为 HTTP 短连接。通过设置 HTTP 请求的请求头中的 keep-alive = true，可以 实现了建立一个 TCP 连接，发送多个 HTTP 请求，减少了重复建立和释放连接的开销，这就是 HTTP 的长连接。

TCP 的 keepalive，是传输层的机制，是由操作系统内核态完成。称为 TCP 保活机制，用来在连接上检测空闲连接状态的机制。当连接建立以后，如果一段时间内没有请求任何数据，keepalive 会通过发送一个数据报来判断连接是否正常。

HTTP 的 keep-alive，可以说是一种策略，是不是长连接，可不可以复用，是连接双方可以在请求头中商量的，但是 TCP 的 keepalive，是一种能力，当 HTTP 连接正常关闭的时候，正常的 TCP 四次挥手关闭 TCP 连接。当应用层出现异常情况的时候，比如断电、网络中断等，没有发送 FIN 挥手，连接处于半开的状态的时候，TCP 的 keepalive 会发送数据报，连续发送多次无法收到 ACK 报文，于是判断连接失效并关闭连接。

21、DNS查询过程

DNS 用来将域名转换为指定的 IP地址。

首先查询本地的 DNS 缓存（本机的缓存），如果缓存中有对应的 IP 地址，直接返回对应的 IP。如果缓存中没有，会向本地的 DNS 服务器（通常是家用的路由器）发送一个 DNS 查询请求。

如果本地的 DNS 服务器缓存中有这个 IP 地址的解析记录，就会直接返回。如果没有，会向根据名服务器发送 DNS 查询请求，根据名服务器不会直接返回 IP 地址，会告诉本地域名服务器去哪个顶级域名服务器查询对应的继续查询。

本地域名服务器拿到了根据名服务器的地址后，出发去根域名服务器查询，但是根域名服务器同样不会直接返回对应的 IP 地址，而是会告诉本地域名服务器顶级域名服务器的地址。

本地域名服务器拿到了顶级据名服务器的地址后，出发去顶级域名服务器查询。顶级域名服务器同样不会直接返回对应的 IP 地址，而是会告诉本地域名服务器权限域名服务器的地址。

本地域名服务器拿到了权限域名服务器的地址后，出发去权限域名服务器查询，权限域名服务器中存储着特定的域名和其对应的 IP 地址，权限域名服务器收到请求之后，会查找“baidu.com” 对应的 IP 地址，返回给本地域名服务器。

本地域名服务器最后把这个 IP 地址返回给浏览器，然后会把这个解析记录缓存到本地，以便下次直接返回域名对应的 IP 地址。

浏览器拿到 IP 地址之后，就可以发送 HTTP 请求，建立 TCP 连接，来获取资源了。

22、CDN是什么

CDN 是一种分布式网络服务，通过将内容缓存到分布式的边缘节点上，用户访问的时候通常从和自己最近的服务器获取资源，优先从最近的节点获取资源。

CDN 服务器节点会缓存静态资源，当用户请求时，节点会检查自己的缓存中是否存在被请求的资源，如果存在，直接返回缓存。如果不存在，会向原站服务器请求获取资源，然后返回，并将结果缓存到自己节点中，以便以后的请求，减少了原站服务器的开销。

23、Cookie和Session是什么

Cookie 和 Session 用于管理用户的状态和身份，Cookie 通过在客户端记录信息来确认用户身份，Session 通过在服务器端记录信息来确认用户的身份。

通常，服务器会将一个或者多个 Cookie 发送到客户端浏览器，浏览器会把 Cookie 存储到本地，当浏览器发起请求的时候，会在请求头中携带这个 Cookie，服务器收到请求之后，可以通过解析 Cookie 中的信息来确定用户的身份和信息。

客户端浏览器访问服务器的时候，服务器通常将用户的信息以某种形式存储到服务器上，这个就是 Session，Session 中主要存储用户的登陆状态、用户的身份信息以及一些上下文的信息。服务器会给每个用户分配一个 Session ID，通常存储在 Cookie 中。

24、Cookie 和 Session 有什么区别

Cookie 存储在客户端浏览器上，Session 存储在服务器上；Cookie 容量较小一般为几KB，Session 容量较大，没有限制，取决于服务器的配置；因为 Cookie 存储在浏览器端，用户可以读取和更改，安全性没有 session 高；Cookie 可以设置过期时间，Session 的生命周期通常由整个会话的长短决定。