计算机网络八股

计算机五层模型

• 物理层：负责把两台计算机连起来，然后在计算机之间通过高低电频来传送0,1这样的电信号，比如通过一些电缆线传输比特流。

• 链路层：链路层涉及到的协议比较多，比如 Mac 地址啊，ARP 等，这一层主要就是负责数据的通信，使各节点之间可以通信，比如通过 MAC 地址唯一识别不同的节点，通过以太网协议定义数据包等。

• 网络层：网络层负责把一个数据从一个网络传递到另外一个网络，最大的功能就是进行路由决策，比如通过 IP，子网等概念，使数据更好着在不同的局域网中传递。

• 传输层：传输层的功能就是建立端口到端口的通信，刚才说的网络层的功能则是建立主机到主机的通信，比如通过网络层我们可以把信息从 A 主机传递到 B 主机，但是 B 主机有多个程序，我们具体要发给哪个程序，则是靠传输层的协议来识别，常见协议有 UDP 和 TCP。

• 应用层：虽然我们收到了传输层传来的数据，可是这些传过来的数据五花八门，有html格式的，有mp4格式的，各种各样，我们用户也看不懂，

  因此我们需要指定这些数据的格式规则，收到后才好解读渲染。例如我们最常见的 Http 数据包中，就会指定该数据包是 什么格式的文件了。

IP地址和Mac地址有啥区别

简洁来说的话，就是：IP处于网络层，主要用来寻址，如同我们的快递地址，有个地址方便寻找大致的地点，而MAC地址，则用来唯一确认身份，就像我们的身份证。

• IP地址是逻辑地址，而MAC地址是物理地址。
• IP地址是在网络层使用的地址，用于标识网络上的主机或路由器，MAC地址则是在数据链路层使用的地址，用于标识网络上的网卡或其他物理设备。
• IP地址是可变的，可以在网络上动态分配或更改，而MAC地址是固定的，通常是出厂时设定的。
• IP地址是全球唯一的，由互联网号码分配机构（IANA）管理分配，而MAC地址是由设备厂商分配，通常在设备生产时就已经固定。

说一说三次握手

刚开始客户端处于 closed 的状态，服务端处于 listen 状态。然后

• 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 **ISN(c)**。此时客户端处于 SYN_Send 状态。

• 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)，同时会把客户端的 ISN + 1 作为 ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。

• 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 establised 状态。

• 服务器收到 ACK 报文之后，也处于 establised 状态，此时，双方以建立起了链接

三次握手的作用

• 确认双方的接受能力、发送能力是否正常。
• 指定自己的初始化序列号，为后面的可靠传送做准备。

ISN是固定的吗

三次握手的一个重要功能是客户端和服务端交换ISN(Initial Sequence Number), 以便让对方知道接下来接收数据的时候如何按序列号组装数据。

如果ISN是固定的，攻击者很容易猜出后续的确认号，因此 ISN 是动态生成的。

什么是半连接队列

服务器第一次收到客户端的 SYN 之后，就会处于 SYN_RCVD 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

三次握手可以携带数据吗

其实第三次握手的时候，是可以携带数据的。也就是说，第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

为什么这样呢？大家可以想一个问题，假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 SYN 报文中放入大量的数据，因为攻击者根本就不理服务器的接收、发送能力是否正常，然后疯狂着重复发 SYN 报文的话，这会让服务器花费很多时间、内存空间来接收这些报文。也就是说，第一次握手可以放数据的话，其中一个简单的原因就是会让服务器更加容易受到攻击了。

而对于第三次的话，此时客户端已经处于 established 状态，也就是说，对于客户端来说，他已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常的了，所以能携带数据页没啥毛病。

说一说四次挥手

刚开始双方都处于 establised 状态，假如是客户端先发起关闭请求，则：

• 第一次挥手：客户端发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于FIN_WAIT1状态。（大白话：相当于客户端告诉服务端，我想断开链接了）

• 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 + 1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT状态。（大白话：相当于，服务端告诉客户端，好的，我收到你的断开请求了）

• 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。

• 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 + 1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态

• 服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

这里特别需要主要的就是TIME_WAIT这个状态了，这个是面试的高频考点，就是要理解，为什么客户端发送 ACK 之后不直接关闭，而是要等一阵子才关闭。这其中的原因就是，要确保服务器是否已经收到了我们的 ACK 报文，如果没有收到的话，服务器会重新发 FIN 报文给客户端，客户端再次收到 FIN 报文之后，就知道之前的 ACK 报文丢失了，然后再次发送 ACK 报文。

说一说TCP和UDP的区别

• TCP是面向连接的传输层协议，所谓面向连接就是双方传输数据之前，必须先建立一条通道，例如三次握手就是建议通道的一个过程，而四次挥手则是结束销毁通道的一个其中过程；而 UDP 则是无连接的传输协议。
• TCP 可以提供可靠的传输，比如数据丢失，超时，TCP 都会重传，并且数据包也能够按序到达，而 UDP 是不可靠的，数据丢失了也不会重传等等。

从效率的角度讲，UDP 的效率更快，因为 UDP 不需要做诸如三次握手/四次挥手/重传等额外的消耗。

从应用场景角度讲的话，对信息的正确率要求比较高的可以采用 TCP 协议，比如我们平时常见的文字聊天；而允许出现小部分数据丢失的，则可以采用 UDP，比如视频聊天等。

TCP和UDP分别对应的常见应用层协议有哪些

TCP对应的应用层协议

• FTP：定义了文件传输协议，使用 21 端口。
• Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。
• SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件，服务器开放的是 25 号端口。。
• POP3：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。
• HTTP：超文本传输协议，从 Web 服务器传输超文本到本地浏览器的传送协议。

UDP对应的应用层协议

• DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。
• SNMP：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。
• TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

浏览器对同一Host建立TCP连接的数量有无限制

浏览器对同一Host建立的TCP连接数量是有限制的。这个限制情况主要依赖于浏览器的类型和版本，以及特定的浏览器配置。

以HTTP/1.1协议为例，根据其规范，对于同一个给定的域，大多数浏览器限制同时打开的TCP连接数量为6个到8个。这意味着，如果一个网页需要获取该域下的更多资源，可能需要等待前面的请求完成。

在HTTP/2协议中，对于同一个域，所有的请求都可以在同一个持久连接中并行完成，从而减少了所需的连接数量。

这个限制只针对同一个Host。如果一个网页的资源分布在不同的Host上，那么浏览器可以分别针对这些Host建立连接。因此，使用多个子域去托管网站的资源是一种常见的绕过浏览器连接限制的方式，以提高加载效率。

说一说HTTP1.0,1.1,2.0区别

HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。

为了解决HTTP/1.0存在的缺陷，最主要的改进就是引入了持久连接。所谓的持久连接即TCP连接默认不关闭，可以被多个请求复用。客户端和服务器发现对方一段时间没有活动，就可以主动关闭连接。或者客户端在最后一个请求时，主动告诉服务端要关闭连接。HTTP/1.1版还引入了管道机制（pipelining），即在同一个TCP连接里面，客户端可以同时发送多个请求。这样就进一步改进了HTTP协议的效率。

HTTP/2 为了解决HTTP/1.1中仍然存在的效率问题，HTTP/2 采用了多路复用。即在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应。能这样做有一个前提，就是HTTP/2进行了二进制分帧，即 HTTP/2 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码。除此之外，还有一些其他的优化，比如做Header压缩、服务端推送等。

也就是说，老板可以同时下达多个命令，员工也可以收到了A请求和B请求，于是先回应A请求，结果发现处理过程非常耗时，于是就发送A请求已经处理好的部分， 接着回应B请求，完成后，再发送A请求剩下的部分。A请求的两部分响应在组合到一起发给老板。

HTTP有哪些常用的状态码及使用场景

状态码分类

• 1xx：表示目前是协议的中间状态，还需要后续请求
• 2xx：表示请求成功
• 3xx：表示重定向状态，需要重新请求
• 4xx：表示请求报文错误
• 5xx：服务器端错误

常用状态码

• 200 请求成功，有响应体
• 403 服务器禁止访问
• 404 资源未找到
• 400 请求错误
• 500 服务器端错误
• 503 服务器繁忙

说一下ARP协议的工作原理

网络层的 ARP（地址解析协议） 协议完成了 IP 地址与物理地址的映射。可以让我们通过 IP 地址获取到对应的 MAC 地址

首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。

当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。

此 ARP 请求数据包里包括源主机的 IP 地址、硬件MAC地址、以及目的主机的 IP 地址。

网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。如果不相同就忽略此数据包；如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败

说一说保活计时器

TCP 有一个保活计时器（keepalive timer）。设想这样的场景：客户已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。

服务器每收到一次客户的数据，就重新设置保活计时器，时间的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，以后则每隔 75 秒钟发送一次。若连续发送 10个 探测报文段后仍然无客户端的响应，服务端就认为客户端出了故障，接着就关闭这个连接。

说一说流量控制

TCP流量控制是一种内置于TCP协议的机制，用于防止发送方把接收方的缓冲区塞满，以避免数据丢失。简单地说，就是保证发送者不会将数据发送得过快，导致接收者无法接收。

TCP流量控制的工作方式是每个TCP段都有一个窗口大小字段，这个字段告诉发送者接收端的可用缓冲区大小。接收方通过更改这个窗口大小值来告诉发送方他还能接收多少数据。如果接收方的缓冲区被填满了，它就会将窗口大小设置为0，这时发送方就会停止发送数据，直到接收方再次更新其窗口大小。

TCP如何实现流量控制

TCP实现流量控制主要依赖于滑动窗口机制。滑动窗口不仅是一种流量控制手段，也是一种可靠传输的手段。它的基本思想是：每个TCP连接都有两个窗口，一个是发送窗口，另一个是接收窗口。窗口大小是动态变化的。

发送窗口的大小由自己和接收方协商得出，不能超过接收窗口的大小。当发送方发送数据时，会根据窗口的大小来确定可以发送的数据量。当数据发送出去后，发送窗口就会向右滑动。接收方在接收到数据后，会向发送方发送确认，确认号表示的是接收方期望接收的下一个数据字节的序号，同时还会告诉发送方自己的接收窗口大小。如果接收方处理数据的速度慢，那么接收窗口的大小就会减小，甚至变为0，此时发送方就不能再发送数据，这样就实现了流量控制。

什么是滑动窗口

讲一下什么是TPC粘包和拆包

TCP粘包：简单来说，就是发送方发送的若干包数据到达接收方时被“粘”在一起，接收方看到的可能是一个大的数据包。这主要是因为TCP是一个基于字节流的协议，没有边界。另一个原因是为了提高网络的有效利用率，TCP会尽可能地将小的数据包合并到大的数据包中发送出去。

TCP拆包：与TCP粘包相反，拆包是指发送方发送的一个大的数据包到达接收方时被“拆”成多个小的数据包。这主要是因为TCP在传输数据时，如果数据包过大，会被分割成合适大小的小包进行发送，以适应网络的最大传输单元

解决这个问题的常见方法是在应用层添加消息边界，比如使用特殊的分隔符，或者在消息头部添加长度字段，来标识每个消息的边界。

HTTP常见的方法有哪些

• GET：用于请求服务器返回指定资源的数据。
• POST：用于向服务器提交数据，请求服务器处理请求中的数据。
• PUT：用于向服务器上传或更新资源，请求服务器存储请求中的数据。
• DELETE：用于请求服务器删除指定的资源。
• HEAD：类似于GET请求，但不返回具体的资源数据，而只返回资源的元信息（例如响应头部），用于获取资源的元信息而不获取实际的资源内容。
• OPTIONS：查询服务器支持的HTTP方法。
• TRACE：用于向服务器发送一个请求，服务器将此请求返回给客户端，用于追踪请求的路径。

说一说POST和GET有哪些区别

• 使用场景：GET 用于获取资源，而 POST 用于传输实体主体。
• 参数：GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。
• 安全性：安全的 HTTP 方法不会改变服务器状态，也就是说它只是可读的。GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。
• 幂等性：幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。GET方法是幂等性的，而POST方法不是。
• 可缓存：请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。

在浏览器中输入URL地址到显示主页的过程

• URL解析：浏览器首先会解析你输入的URL，确定你要访问的是哪个网站，这个网站的地址（IP地址）是什么，以及你请求访问该网站的具体页面路径。
• DNS查询：如果浏览器缓存或系统缓存中没有该域名的IP地址，那么浏览器将发送一个请求到DNS（域名系统）服务器，来查找对应的IP地址。
• 建立连接：找到IP地址后，浏览器会向该地址发送一个TCP连接请求，这个过程通常被称为TCP的三次握手。
• 发送HTTP请求：一旦TCP连接被建立，浏览器就可以通过这个连接向服务器发送HTTP请求了。这个请求里会包含你要获取的资源类型，所使用的HTTP版本，以及可能的一些其他信息。
• 服务器处理请求并返回HTTP响应：服务器接收到HTTP请求后，进行处理，然后返回一个HTTP响应，响应中包含了要访问的网页的内容，以及一些描述信息，如状态码、内容类型等。
• 浏览器解析HTML：浏览器接收到服务器的响应数据后，开始解析HTML，构建DOM树。
• 资源加载：在解析HTML的过程中，如果遇到CSS、JavaScript文件或者图片等资源，浏览器会再次发送HTTP请求去获取。
• 浏览器渲染页面：在获取到所有的资源文件后，浏览器开始渲染页面，将资源文件转化为网页上的可视、可交互的内容。
• 关闭连接：如果HTTP头部中的Connection字段的属性被设置为close，那么浏览器和服务器的TCP连接在传输完成后将会被关闭。如果设置为keep-alive，那么TCP连接会被保持一段时间，以便传输更多的请求。

说一说DNS解析过程

DNS（Domain Name System）是互联网中用于将域名解析为IP地址的系统。

• 用户在浏览器中输入一个域名，比如www.example.com。
• 浏览器首先会在本地缓存中查找是否有该域名对应的IP地址，如果有则直接返回IP地址，否则进入下一步。
• 浏览器会向本地DNS服务器发送一个查询请求。
• 本地DNS服务器如果缓存中有该域名对应的IP地址，则直接返回IP地址给浏览器，否则进入下一步。
• 本地DNS服务器会向根域名服务器发送一个查询请求，询问该域名的顶级域名服务器（比如.com）的IP地址。
• 根域名服务器会返回顶级域名服务器的IP地址给本地DNS服务器。
• 本地DNS服务器再次向顶级域名服务器发送查询请求，询问该域名的权威域名服务器（比如example.com）的IP地址。
• 权威域名服务器返回该域名的IP地址给本地DNS服务器。
• 本地DNS服务器最后将IP地址返回给浏览器。
• 浏览器得到IP地址后，就可以向该IP地址对应的服务器发送HTTP请求，建立起与服务器的连接，开始浏览网页

为了DNS解析更多，你觉得可用到哪些优化手段

• DNS缓存：DNS缓存是本地DNS服务器和浏览器中的一种机制，用于缓存已解析的域名和对应的IP地址。当再次访问相同域名时，可以直接从缓存中获取IP地址，避免重复查询和延迟。
• 域名预取：浏览器可以在用户点击链接之前提前解析网页中的链接中的域名，将这些域名解析为IP地址并缓存起来。这样当用户点击链接时，可以立即建立连接，减少等待时间

什么是HTTP长连接

HTTP长连接（HTTP persistent connection）是指在一次HTTP请求和响应完成后，保持TCP连接不关闭，以便后续的HTTP请求可以继续在同一个连接上发送和接收数据。

在传统的HTTP/1.0版本中，每次请求完成后，TCP连接都会被关闭，下次请求需要重新建立连接，这种方式称为短连接。而在HTTP/1.1版本中，引入了持久连接的概念，也就是HTTP长连接。

HTTP长连接的主要优势在于减少了TCP连接建立和关闭的开销，提高了性能和效率。相比于短连接，HTTP长连接可以避免频繁地进行握手和挥手操作，节省了网络资源和服务器端的负担，特别适用于同时请求多个资源，或在一个页面中含有多个嵌入资源的情况。。

HTTP长连接短连接使用场景是什么

• 长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。
• 而像 WEB 网站的 http 服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源， 如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

HTTP和HTTPS的区别有哪些

• 安全性：HTTP是明文传输的协议，数据并没有经过加密，容易被窃听、篡改或其他安全风险。HTTPS通过使用SSL（安全套接层）或TLS（传输层安全）协议对HTTP进行加密，确保数据在传输过程中的安全性和完整性。这样，即使被截获的数据也无法被解读和篡改。
• 端口号：HTTP默认使用端口号80进行通信。HTTPS默认使用端口号443进行通信。
• 证书：HTTPS使用数字证书对网站的身份进行认证。证书由可信的第三方机构颁发，用于证明服务器是可信的，并且可以用来加密和解密通信过程中的数据。HTTP不需要证书，任何人都可以发送HTTP请求和接收HTTP响应。
• 性能开销：由于HTTPS需要进行加密和解密操作，因此相对于HTTP来说，会有更多的计算和处理开销，会轻微地增加通信的延迟和资源消耗。

HTTP报文常见的字段有哪些

请求报文

• 请求行字段
  • 方法（Method）：定义请求的动作，常见的方法有GET、POST、PUT、DELETE等。
  • URL（Uniform Resource Locator）：指定请求的资源路径和参数。
  • 协议版本（HTTP Version）：定义使用的HTTP协议版本，如HTTP/1.1。
• 请求头字段
  • Host：指定要访问的服务器的主机名。
  • User-Agent：发送请求的用户代理信息，表示浏览器、操作系统等。
  • Accept：客户端能够接收的响应内容类型。
  • Content-Type：请求体中的数据类型。
  • Cookie：在之前与服务器建立的会话中存储的Cookie信息。
  • Authorization：用于提供身份验证凭据的信息。
• 请求体字段
  • Content-Type：请求体中的数据类型。
  • Content-Length：请求体的字节数。
  • 请求体内容：传输的实际数据。

响应报文

• 状态行字段
  • 协议版本（HTTP Version）：定义使用的HTTP协议版本，如HTTP/1.1。
  • 状态码（Status Code）：表示服务器对请求的处理结果，如200表示成功，404表示未找到等。
  • 状态信息（Status Text）：对状态码的简要描述。
• 响应头字段
  • Content-Type：响应体中的数据类型。
  • Content-Length：响应体的字节数。
  • Set-Cookie：服务器通过响应头中的Set-Cookie字段向客户端发送新的Cookie。
• 响应体字段
  • 实际的响应数据。

HTTPS的大概流程讲一下

• 客户端发起连接：客户端通过浏览器等应用向服务器发送HTTPS请求。请求的URL以https://开头，表明是要使用HTTPS协议进行通信。
• 服务器证书：服务器接收到来自客户端的HTTPS请求后，会将自己的数字证书发送给客户端。证书中包含了服务器的公钥，同时由可信的权威机构（证书颁发机构，CA）对服务器的身份进行认证。
• 客户端收到服务端的证书后，会对证书进行验证
  • 验证证书的合法性：客户端会检查证书的有效期、签发机构和相关属性，确保证书的合法性。
  • 验证证书的可信性：客户端会检查证书的颁发机构是否被信任，以确保证书是由可信的第三方机构颁发的。
• 密钥交换：在证书验证通过后，客户端会生成一个随机的对称加密密钥（session key），并使用服务器的公钥进行加密。然后将加密后的密钥发送给服务器。
• 会话加密：服务器收到客户端发送的加密密钥后，使用自己的私钥进行解密，得到对称加密密钥（session key）。客户端和服务器都会使用这个对称密钥来加密和解密后续的通信数据。
• 安全通信：客户端和服务器之间的所有通信都会使用对称密钥进行加密和解密。这样，即使有人拦截到通信数据，也无法解密和获取其中的内容。

什么是数字证书

一个数字证书是一个文件，经过由信任的证书颁发机构（CA，Certificate Authority）数字签名，用以验证持有者的身份以及公钥的真实性。简短来说，就是一个电子文档，用来证明持有者的身份和公钥所有权。

举个例子，当你访问一个https开头的网站，如https://www.google.com时，你的浏览器会先获取Google的数字证书，进一步验证其合法性。如果验证成功，且证书匹配服务器的域名，表示证书是真实有效的，浏览器就会允许连接建立，进一步加载网页数据。

讲一讲对称加密和非对称加密

• 对称加密是一种常用的加密方式，它有一个特点：就是加密和解密使用同一把密钥。也就是说，用这个密钥加密的信息，只有用同样的密钥才能解密。对称加密的速度相对较快，但是密钥的传输和保管比较困难，因为只要这个密钥被泄漏，任何人都可以解密信息。
• 为了解决这个问题，就需要使用到非对称加密技术，其中涉及到两个密钥：公钥和私钥。公钥是公开的，任何人都可以见到，并且可以用来加密信息或者验证签名。而私钥则是保密的，只有密钥的主人才能看到，用来解密信息或者生成签名。

讲一讲Cookie

Cookie是一种在客户端（浏览器）和服务器之间交换的小型数据文件。它由服务器生成并发送给客户端，然后客户端保存在本地的浏览器中。每次浏览器向同一服务器发送请求时，会将相应的Cookie信息附加在请求头中一起发送给服务器。

Cookie主要用于记录和追踪与用户相关的信息

• 会话管理：通过使用会话Cookie，服务器可以在用户的多个请求之间维持会话状态。它使服务器能够识别特定用户，并保持用户登录状态，而不需要用户在每个请求中重新验证身份。
• 用户个性化：Cookie可以用于存储用户的个人喜好、偏好或设置等信息。例如，在某个电子商务网站上，可以使用Cookie来记录用户的购物车内容和偏好选项，以便在用户下次访问时进行个性化推荐或还原购物车。
• 随机广告：Cookie可以用于进行广告跟踪和定向投放。广告商可以在用户访问某个网站时，通过Cookie记录用户的兴趣、浏览行为等信息，然后根据这些信息显示与用户兴趣相关的广告。
• 记住用户：通过在Cookie中存储持久性数据，网站可以实现”记住我”的功能，使用户在下次访问时不需要重新输入用户名和密码。

讲一讲Session

Session（会话）是指在客户端和服务器之间建立的一种会话状态。通过会话，服务器可以在不同请求之间识别和跟踪特定的客户端，并保持与客户端的交互状态。

在Web应用中，Session通常使用一种名为Session ID的机制来实现。当客户端首次访问服务器时，服务器会为此客户端生成一个唯一的Session ID，并将其存储在服务器端的存储介质（如内存、数据库、文件）中，同时将该Session ID发送给客户端保存在Cookie中。

客户端在后续的请求中，会将存储在Cookie中的Session ID自动带上，供服务器在接收到请求时进行识别。然后，服务器根据Session ID找到相应的会话数据，使得服务器能够识别特定的客户端并维持会话状态。

Cookie和Session的区别有哪些

• 存储位置：Cookie数据存储在客户端（浏览器），而Session数据存储在服务器端。因此，从保护用户数据的角度来看，Session比Cookie更安全。
• 生命周期：通常情况下，Cookie有固定的过期时间，除非用户手动清理否则不会消失，即使关闭浏览器或重启计算机也依然存在。而Session的生命周期通常是在用户关闭浏览器或者超出了设定的时间段后，服务器就会自动将其销毁。
• 大小限制：由于Cookie数据存储在客户端，所以它有大小限制，一般为4KB左右。而Session是存储在服务器端，理论上其数据大小没有限制，但是如果存储过多的数据会增加服务器的负担。
• 数据类型限制：Cookie只能保存字符串类型的数据，对于复杂的数据结构需要进行序列化。而Session可以存储任何类型的数据，比如对象和数组等。
• 跨域问题：基于安全性，Cookie不可以进行跨域名存储，每个域名下的Cookie数据是分开存储的。而Session技术没有这项限制。

Cookie和Session是如何实现用户的登陆状态的

• 一旦用户通过输入正确用户名和密码登录，服务器就会创建一个会话（Session）并保存在服务端。这个Session具有唯一的ID。
• 服务器会创建一个新的Cookie，并将刚才Session的ID作为Cookie的一部分发送到用户的浏览器。这样，每次客户端向服务器请求时，Cookie就会包含在HTTP头信息中。
• 当接收到带有Cookie的请求时，服务器会对比Cookie中的Session ID与服务端保存的ID是否匹配。如果匹配，服务器就认为用户是已经登录的，然后就可以提供属于该用户的信息或服务。

URI和URL之间的区别

URI是一个广义的概念，用于唯一标识和识别互联网资源；而URL是URI的一种特殊形式，它不仅唯一标识和识别资源，还提供了访问和定位资源的详细信息。简单来说，URL是URI的一个具体实现。

• 概念差异：URI是一个统一的标识符，用于唯一标识和识别资源。URL是URI的一种特定形式，它指定了资源在网络上的具体位置。URL是一种更具体的标识符，它指示了如何访问和定位资源。
• 格式差异：URI由scheme（协议）、authority（权威部分）和path（路径）组成，形如：scheme://authority/path。URL是URI的一种特殊形式，它包含了更详细的信息，包括scheme、authority、path以及其他额外的组件，如查询参数和片段标识符。
• 用途差异：URI用于唯一标识和识别资源，它是资源的名称。URL除了唯一标识和识别资源外，还提供了访问和定位资源的方式和细节。

IPV4地址不够如何解决

• IPv6（Internet Protocol Version 6）：IPv6 是 IPv4 的后继协议，扩展了地址空间，从而解决了 IPv4 地址不够的问题。
• IP 地址转换技术：有些技术可以实现 IPv4 和 IPv6 地址之间的转换。例如，双栈技术（Dual-Stack）可以在同一设备上同时支持 IPv4 和 IPv6 协议栈，使设备可以在 IPv4 和 IPv6 网络中通信。