计算机网络

OSI 和 TCP/IP 网络分层模型详解（基础）

1. OSI 七层模型

2. TCP/IP 四层模型

TCP/IP 模型看作是 OSI 七层模型的精简版本，由以下 4 层组成：

2.1 应用层（Application layer）

应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。 我们把应用层交互的数据单元称为报文。

2.2 传输层（Transport layer）

负责向两台终端设备进程之间的通信提供通用的数据传输服务。
应用进程利用该服务传送应用层报文。
“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
运输层主要使用以下两种协议：

• 传输控制协议 TCP（Transmisson Control Protocol）–提供面向连接的，可靠的数据传输服务。
• 用户数据协议 UDP（User Datagram Protocol）–提供无连接的，尽最大努力的数据传输服务（不保证数据传输的可靠性）。
  

2.3 网络层（Network layer）

① 负责为分组交换网上的不同主机提供通信服务。
② 网络层的还有一个任务就是选择合适的路由，使源主机运输层所传下来的分株，能通过网络层中的路由器找到目的主机。
在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。
在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。
互联网是由大量的异构（heterogeneous）网络通过路由器（router）相互连接起来的。互联网使用的网络层协议是无连接的网际协议（Intert Prococol）和许多路由选择协议，因此互联网的网络层也叫做网际层或IP 层。

2.4 网络接口层（Network interface layer）（数据链路层和物理层）

1. 数据链路层的作用是：将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
2. 物理层的作用是：实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异。

3. 为什么网络要分层？

1. 各层之间相互独立：可不关心其它层。
2. 提高了整体灵活性：高内聚、低耦合。
3. 大问题化小：分解为许多比较小的、界线比较清晰简单的小问题来处理和解决。

HTTP vs HTTPS（应用层）

HTTP 协议（扩展性强、速度快、跨平台支持性好）

1. HTTP 协议介绍

HTTP 协议，全称超文本传输协议（Hypertext Transfer Protocol）。HTTP 协议就是用来规范超文本（网络上各种消息）的传输，规范浏览器和服务器端的行为的。
HTTP 是一个无状态（stateless）协议，也就是说服务器不维护任何有关客户端过去所发请求的消息。这其实是一种懒政，有状态协议会更加复杂，需要维护状态（历史信息），而且如果客户或服务器失效，会产生状态的不一致，解决这种不一致的代价更高。

2. HTTP 协议通信过程

HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：

1. 服务器在 80 端口等待客户的请求。
2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
3. 服务器接收来自浏览器的 TCP 连接。
4. 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
5. 关闭 TCP 连接。

HTTPS 协议（保密性好、信任度高。）

1. HTTPS 协议介绍

HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443
HTTPS 协议中，SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特。

2. HTTPS 的核心—SSL/TLS协议

结合了 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。

1. SSL 和 TLS 的区别？

没有太大的区别。SSL 指安全套接字协议（Secure Sockets Layer），始发1996年，1999 年SSL 3.0 进一步升级，新版本被命名为 TLS 1.0。通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

2. SSL/TLS 的工作原理

SSL/TLS 的核心要素是非对称加密。非对称加密采用两个密钥——一个公钥(加密者)，一个私钥(解密者)。在通信时，私钥仅由解密者保存，公钥由任何一个想与解密者通信的发送者（加密者）所知。
非对称加密：公钥和私钥需要采用一种复杂的数学机制生成。公私钥对的生成算法依赖于单向陷门函数。（计算的代价较高，效率太低）
对称加密：通信双方共享唯一密钥 k，加解密算法已知，加密方利用密钥 k 加密，解密方利用密钥 k 解密，保密性依赖于密钥 k 的保密性。
使用非对称加密，对对称加密的密钥进行加密，保护该密钥不在网络信道中被窃听。这样通信双方只需要一次非对称加密，交换对称加密的密钥，在之后的信息通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证传输消息的保密性。
当客户端（浏览器）向服务器发送 HTTPS 请求时，一定要先获取目标服务器的证书，并根据证书上的信息，检验证书的合法性。一旦客户端检测到证书非法，就会发生错误。客户端获取了服务器的证书后，由于证书的信任性是由第三方信赖机构认证的，而证书上又包含着服务器的公钥信息，客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。

总结

• 端口号 ：HTTP 默认是 80，HTTPS 默认是 443。
• URL 前缀 ：HTTP 的 URL 前缀是 http://，HTTPS 的 URL 前缀是 https://。
• 安全性和资源消耗 ： HTTP 协议运行在 TCP 之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议，SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS 高，但是 HTTPS 比 HTTP 耗费更多服务器资源。

HTTP 1.0 vs HTTP 1.1（应用层）

1. 响应状态码

HTTP/1.0 仅定义了16种状态码。HTTP/1.1 中大量状态码，错误响应状态码就新增24种。
100 (Continue)——在请求大资源前的预热请求，
206 (Partial Content)——范围请求的标识码，
409 (Conflict)——请求与当前资源的规定冲突，
410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。

2. 缓存处理

缓存技术通过避免用户与源服务器的频繁交互，节约了大量的网络带宽，降低了用户接收信息的延迟。

1. HTTP/1.0
   提供的缓存机制非常简单。
   Expires 标签：标志（时间）一个响应体，在 Expires 标志时间内的请求，都会获得该响应体缓存。
   Last-Modified ：标记了被请求资源在服务器端的最后一次修改。
   If-Modified-Since：标志一个时间，意为客户端向服务器进行问询是否修改。

• 如果服务器接收到了请求头，并判断 If-Modified-Since 时间后，资源确实没有修改过，则返回给客户端一个 304 not modified 响应头，表示”缓冲可用，你从浏览器里拿吧！”。
• 如果服务器判断 If-Modified-Since 时间后，资源被修改过，则返回给客户端一个 200 OK 的响应体，并附带全新的资源内容，表示”你要的我已经改过的，给你一份新的”。

2. HTTP/1.1
   缓存机制在 HTTP/1.0 的基础上，大大增加了灵活性和扩展性。基本工作原理和 HTTP/1.0 保持不变，而是增加了更多细致的特性。其中，请求头中最常见的特性就是 Cache-Control 。

3. 连接方式

HTTP/1.0 默认使用短连接，也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。
当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源，每遇到这样一个 Web 资源，浏览器就会重新建立一个TCP连接，这样就会导致有大量的**“握手报文”和“挥手报文”**占用了带宽。

HTTP/1.1 优化为默认长连接模式。采用长连接模式的请求报文会通知服务端：“我向你请求连接，并且连接成功建立后，请不要关闭”。因此，该TCP连接将持续打开，为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

如果 TCP 连接一直保持的话也是对资源的浪费，因此，一些服务器软件（如 Apache）还会支持超时时间的时间。在超时时间之内没有新的请求达到，TCP 连接才会被关闭。
（有必要说明的是，HTTP/1.0仍提供了长连接选项，即在请求头中加入Connection: Keep-alive。同样的，在 HTTP/1.1 中，如果不希望使用长连接选项，也可以在请求头中加入 Connection: close ，这样会通知服务器端：“我不需要长连接，连接成功后即可关闭”。）
* HTTP 协议的长连接和短连接，实质上是 TCP 协议的长连接和短连接。
* 实现长连接需要客户端和服务端都支持长连接。

4. Host头处理

域名系统（DNS）允许多个主机名绑定到同一个IP地址上，但是HTTP/1.0并没有考虑这个问题，假设我们有一个资源URL是 http://example1.org/home.html ，HTTP/1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址。

因此，HTTP/1.1在请求头中加入了 Host 字段。加入 Host 字段的报文头部将会是：

GET /home.html HTTP/1.1
Host: example1.org

这样，服务器端就可以确定客户端想要请求的真正的网址了。

5. 带宽优化

1. 范围请求

HTTP/1.1 引入了范围请求（range request）机制，以避免带宽的浪费。当客户端想请求一个文件的一部分，或者需要继续下载一个已经下载了部分但被终止的文件，HTTP/1.1 可以在请求中加入 Range 头部，以请求（并只能请求字节型数据）数据的一部分。服务器端可以忽略 Range 头部，也可以返回若干 Range 响应。
如果一个响应包含部分数据的话，那么将带有 206 (Partial Content) 状态码。该状态码的意义在于避免了 HTTP/1.0 代理缓存错误地把该响应认为是一个完整的数据响应，从而把他当作为一个请求的响应缓存。
在范围响应中，Content-Range 头部标志指示出了该数据块的偏移量和数据块的长度。

2. 状态码100

使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码100可以作为指示请求是否会被正常响应

然而在 HTTP/1.0 中，并没有 100 (Continue)状态码，要想触发这一机制，可以发送一个 Expect 头部，其中包含一个 100-continue 的值。

3. 压缩

许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而，HTTP/1.0 对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。
HTTP/1.1 则对内容编码（content-codings，端到端）和传输编码（transfer-codings，逐跳）做了区分。
HTTP/1.0 包含了 Content-Encoding 头部，对消息进行端到端编码。HTTP/1.1 加入了Transfer-Encoding 头部，可以对消息进行逐跳传输编码。HTTP/1.1 还加入了Accept-Encoding 头部，是客户端用来指示他能处理什么样的内容编码。

总结

1. 连接方式 : HTTP 1.0 为短连接，HTTP 1.1 支持长连接。
2. 状态响应码 : HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。
3. 缓存处理 : 在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及网络连接的使用 : HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
5. Host头处理 : HTTP/1.1 在请求头中加入了 Host 字段。

计算机网络常见知识点&面试题（补充）

1. 应用层有哪些常见的协议？

1. HTTP：超文本传输协议

Web 浏览器与 Web 服务器之间的通信而设计的。浏览器浏览网页就是通过 HTTP 请求进行加载。

HTTP 协议是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1 。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。
HTTP 协议是**“无状态”的协议**，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。

2. SMTP：简单邮件传输(发送)协议

基于 TCP 协议，用来发送电子邮件。

1. 电子邮件的发送过程？
   比如我的邮箱是“dabai@cszhinan.com”，我要向“xiaoma@qq.com”发送邮件，整个过程可以简单分为下面几步：
   1.1 通过 SMTP 协议，我将我写好的邮件交给163邮箱服务器（邮局）。
   1.2 163邮箱服务器发现我发送的邮箱是qq邮箱，然后它使用 SMTP协议将我的邮件转发到 qq邮箱服务器。
   1.3 qq邮箱服务器接收邮件之后就通知邮箱为“xiaoma@qq.com”的用户来收邮件，然后用户就通过 POP3/IMAP 协议将邮件取出。
2. 如何判断邮箱是真正存在的？
   利用 SMTP 协议来检测：
   2.1 查找邮箱域名对应的 SMTP 服务器地址
   2.2 尝试与服务器建立连接
   2.3 连接成功后尝试向需要验证的邮箱发送邮件
   2.4 根据返回结果判定邮箱地址的真实性

3. POP3/IMAP：邮件（接收）的协议

SMTP 协议只负责邮件的发送，真正负责接收的协议是 POP3/IMAP 。（IMAP 协议更新，功能更多）

4. FTP：文件传输协议

功能：提供文件传输服务，基于 TCP 实现可靠的传输。
好处：可以屏蔽操作系统和文件存储方式。
FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点：就在于它在两台通信的主机之间使用了两条 TCP 连接（其它客户服务器应用程序一般只有一条 TCP 连接）：

1. 控制连接：用于传送控制信息（命令和响应）
2. 数据连接：用于数据传送；
   这种将命令和数据分开传送的思想大大提高了 FTP 的效率。
   

5. Telnet：远程登陆协议

Telnet 协议 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet 并被一种称为 SSH 的非常安全的协议所取代的主要原因。
Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。

6. TCP 三次握手和四次挥手(面试常客)

为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。

1. 客户端–发送带有 SYN 标志的数据包–一次握手–服务端
2. 服务端–发送带有 SYN/ACK 标志的数据包–二次握手–客户端
3. 客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端
   响应报文（SYN(synchronous建立联机) ACK(acknowledgement 确认)）

1. 为什么要三次握手？

建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。

2. 第 2 次握手传回了 ACK，为什么还要传回 SYN？

ACK（确认信号） 是为了告诉客户端，我接收到的信息确实就是你所发送的信号了，这表明从客户端到服务端的通信是正常的。
而回传 SYN（建立联机信号） 则是为了建立并确认从服务端到客户端的通信。”

3. 为什么要四次挥手？

断开一个 TCP 连接则需要“四次挥手”：

1. 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
2. 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号
3. 服务器-关闭与客户端的连接，发送一个 FIN 给客户端
4. 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1

任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。
（举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。）

7. TCP, UDP 协议的区别

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

8. TCP 协议如何保证可靠传输

1. 应用数据被分割成 TCP 认为最适合发送的数据块。
2. TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
4. TCP 的接收端会丢弃重复的数据。
5. 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
6. 拥塞控制： 当网络拥塞时，减少数据的发送。
7. ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
8. 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

1. ARQ （自动重传请求）协议(Automatic Repeat-reQuest，ARQ)

OSI 模型中数据链路层和传输层的错误纠正协议之一。
它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。
ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

停止等待 ARQ 协议 ：为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。
在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

优点： 简单。缺点： 信道利用率低，等待时间长

1. 无差错情况。2) 出现差错情况（超时重传）。3) 确认丢失和确认迟到。

连续 ARQ 协议：可提高信道利用率。**发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。**接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
优缺点：
优点： 信道利用率高，容易实现，即使确认丢失，也不必重传。
缺点： 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如：发送方发送了 5 条 消息，中间第三条丢失（3 号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

2. 滑动窗口和流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

3. 拥塞控制

拥塞：在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。
拥塞控制：防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。
前提：网络能够承受现有的网络负荷。
拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。
流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
为了进行拥塞控制，TCP 发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP 的拥塞控制采用了四种算法，即 慢开始(由小到大逐渐增大发送窗口) 、 拥塞避免 (拥塞窗口 cwnd 缓慢增大)、快重传与快恢复(如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认)。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

9. 在浏览器中输入 url 地址 ->> 显示主页的过程(面试常客)

10. 各种协议与 HTTP 协议之间的关系

11. HTTP 是不保存状态的协议, 如何保存用户状态？

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，**Session 的主要作用就是通过服务端记录用户的状态。**典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个 Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库 redis 保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办？
最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。

12. Cookie 的作用是什么? 和 Session 有什么区别？

Cookie 和 Session 都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

• Cookie 一般用来保存用户信息 比如 ① 我们在 Cookie 中保存已经登录过的用户信息，下次访问网站的时候页面可以自动帮你把登录的一些基本信息给填了；② 一般的网站都会有保持登录，也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③ 登录一次网站后访问网站其他页面不需要重新登录。
  Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

• Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

• Cookie 存储在客户端中，而 Session 存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密，然后使用到的时候再去服务器端解密。

13. URI 和 URL 的区别是什么？

• URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
• URL(Uniform Resource Locator) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
  URI 的作用像身份证号一样，URL 的作用更像家庭住址一样。URL 是一种具体的 URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

参考

本文档为个人方便自己熟记而整理，来自javaguide。
javaguide是个优秀的计算机知识整理：https://javaguide.cn/

最后

以上就是从容香水为你收集整理的计算机网络基础知识整理计算机网络OSI 和 TCP/IP 网络分层模型详解（基础）HTTP vs HTTPS（应用层）HTTP 协议（扩展性强、速度快、跨平台支持性好）HTTPS 协议（保密性好、信任度高。）HTTP 1.0 vs HTTP 1.1（应用层）计算机网络常见知识点&面试题（补充）参考的全部内容，希望文章能够帮你解决计算机网络基础知识整理计算机网络OSI 和 TCP/IP 网络分层模型详解（基础）HTTP vs HTTPS（应用层）HTTP 协议（扩展性强、速度快、跨平台支持性好）HTTPS 协议（保密性好、信任度高。）HTTP 1.0 vs HTTP 1.1（应用层）计算机网络常见知识点&面试题（补充）参考所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。