关于前端:计算机网络面试题

参照：

https://yihuiblog.top/browser-working/L2.html

https://mp.weixin.qq.com/s/-IOy2hXd-AcuIQ02saf6Rw

https://www.cnblogs.com/yaochunhui/p/14175396.html

https://blog.csdn.net/weixin_39829073/article/details/112907168

基础知识

1. OSI 与 TCP/IP 模型

OSI 七层：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层

TCP/IP 五层：物理层、数据链路层、网络层、传输层、应用层

七层网络体系结构各层的次要性能：

• 应用层：为应用程序提供交互服务。在互联网中的应用层协定很多，如域名零碎 DNS，反对万维网利用的HTTP 协定，反对电子邮件的 SMTP 协定等。
• 表示层：次要负责数据格式的转换，如加密解密、转换翻译、压缩解压缩等。
• 会话层：负责在网络中的两节点之间建设、维持和终止通信，如服务器验证用户登录便是由会话层实现的。
• 运输层：有时也译为传输层，向主机过程提供通用的数据传输服务。该层次要有以下两种协定:
• • TCP：提供面向连贯的、牢靠的数据传输服务;
  • UDP：提供无连贯的、尽最大致力的数据传输服务，但不保障数据传输的可靠性。
• 网络层：抉择适合的路由和替换结点，确保数据及时传送。次要包含 IP 协定。
• 数据链路层：数据链路层通常简称为链路层。将网络层传下来的 IP 数据包组装成帧，并再相邻节点的链路上传送帧。
• 物理层：实现相邻节点间比特流的通明传输，尽可能屏蔽传输介质和通信伎俩的差别。

2. 常见网络服务分层

应用层：HTTP、DNS、FTP、SMTP

传输层：TCP 、UDP

网络层：IP、ICMP 、路由器、防火墙

数据链路层：网卡、网桥、交换机

物理层：中继器、集线器

3. TCP 三次握手

<img src=”https://mc-web-1259409954.cos.ap-guangzhou.myqcloud.com/MyImages/202204111232193.jpeg” alt=” 图片 ” style=”zoom: 80%;” />

三次握手过程：

1. 客户端——发送带有 SYN 标记的数据包——服务端 一次握手 客户端进入syn_sent 状态
2. 服务端——发送带有 SYN/ACK 标记的数据包——客户端 二次握手 服务端进入syn_rcvd
3. 客户端——发送带有 ACK 标记的数据包——服务端 三次握手 连贯就进入Established 状态

为什么三次： 次要是为了建设牢靠的通信信道，保障客户端与服务端同时具备发送、接收数据的能力。

为什么两次不行？

1. 避免已生效的申请报文又传送到了服务端，建设了多余的链接，浪费资源。
2. 两次握手只能保障单向连贯是畅通的。（为了实现牢靠数据传输，TCP 协定的通信单方，都必须保护一个序列号，以标识发送进来的数据包中，哪些是曾经被对方收到的。三次握手的过程即是通信单方 互相告知序列号起始值，并确认对方曾经收到了序列号起始值的必经步骤；如果只是两次握手，至少只有连贯发起方的起始序列号能被确认，另一方抉择的序列号则得不到确认）。

4. 四次挥手过程：

1. 客户端——发送带有 FIN 标记的数据包——服务端，敞开与服务端的连贯，客户端进入 FIN-WAIT-1 状态
2. 服务端收到这个 FIN，它发回⼀ 个 ACK，确认序号为收到的序号加 1，服务端就进入了CLOSE-WAIT 状态
3. 服务端——发送⼀个 FIN 数据包——客户端，敞开与客户端的连贯，客户端就进入 FIN-WAIT-2 状态
4. 客户端收到这个 FIN，发回 ACK 报⽂确认，并将确认序号设置为收到序号加 1，客户端进入TIME-WAIT 状态

<img src=”https://mc-web-1259409954.cos.ap-guangzhou.myqcloud.com/MyImages/202204111232185.jpeg” alt=” 图片 ” style=”zoom:80%;” />

为什么四次：因为须要确保客户端与服务端的数据可能实现传输。

CLOSE-WAIT： 这种状态的含意其实是示意在 期待敞开。

TIME-WAIT： 为了解决网络的丢包和网络不稳固所带来的其余问题，确保连贯方能在工夫范畴内，敞开本人的连贯。

5. 为什么连贯的时候是三次握手，敞开的时候却是四次握手?

服务器在收到客户端的 FIN 报文段后，可能还有一些数据要传输，所以不能马上敞开连贯，然而会做出应答，返回 ACK 报文段。

接下来可能会持续发送数据，在数据发送完后，服务器会向客户端发送 FIN 报文，示意数据曾经发送结束，申请敞开连贯。服务器的 ACK 和FIN个别都会离开发送，从而导致多了一次，因而一共须要四次挥手。

6. 如何查看 TIME-WAIT 状态的链接数量？

netstat -an | grep TIME_WAIT | wc -l  // 查看连接数期待 time_wait 状态连接数

7. 为什么会 TIME-WAIT 过多？解决办法是怎么的？

可能起因：高并发短连贯的 TCP 服务器上，当服务器解决完申请后立即依照被动失常敞开连贯

解决：负载平衡服务器；Web 服务器首先敞开来自负载平衡服务器的连贯

8. 半连贯，洪泛攻打问题以及如何解决（syn_cookie）

在三次握手的过程中，服务器为了响应一个受到的 SYN 报文段，会调配并初始化连贯变量和缓存，而后服务器发送一个 SYN/ACK 报文段进行响应，并期待客户端的 ACK 报文段。如果客户不发送 ACK 来实现该三次握手的第三步，最终 (通常在一分多钟之后) 服务器将终止该半开连贯并回收资源。这种 TCP 连贯治理协定的个性就会有这样一个破绽，攻击者发送大量的 TCP SYN 报文段，而不实现第三次握手的步骤。随着这种 SYN 报文段的一直到来，服务器一直为这些半开连贯分配资源，从而导致服务器连贯资源被耗费殆尽。这种攻打就是 SYN 泛供攻打。

为了应答这种攻打，当初有一种 无效的进攻零碎，称为 SYN cookie。SYN cookie 的工作形式如下：

1. 当服务器接管到一个 SYN 报文段时，它并不知道该报文段是来自一个非法的用户，还是这种 SYN 洪泛攻打的一部分。因为服务器不会为该报文段生成一个半开的连贯。相同，服务器生成一个初始 TCP 序列号，该序列号是 SYN 报文段的源 IP 地址和目标 IP 地址，源端口号和目标端口号以及仅有服务器晓得的机密数的简单函数 (散列函数)。这种精心制作的初始序列号称为为“cookie”。服务器则发送具备这种非凡初始序号的SYN/ACK 报文分组。服务器并不记忆该 cookie 或任何对应于 SYN 的其余状态信息。
2. 如果该客户是非法的，则它将返回一个 ACK 报文段。当服务器收到该 ACK 报文段，须要验证该 ACK 是与后面发送的某个 SYN 绝对应。因为服务器并不保护无关 SYN 报文段的记忆，所以服务器通过应用 SYN/ACK 报文段中的源和目标 IP 地址与端口号以及机密数运行雷同的散列函数。如果这个函数的后果 (cookie 值) 加 1 和在客户的 ACK 报文段中的确认值雷同的话，那么服务器就会认为该 ACK 对应于较早的 SYN 报文段，因而它是非法的。服务器则会生成一个套接字的全开连贯。
3. 另一方面，如果客户没有返回一个 ACK 报文段，阐明之前的 SYN 报文段是洪泛攻打的一部分，然而它并没有对服务器产生危害，因为服务器没有为它调配任何资源。

9. 为什么客户端的 TIME-WAIT 状态必须期待 2MSL ?

次要有两个起因:

1. 为了保障客户端发送的最初一个 ACK 报文段可能达到服务器。这个 ACK 报文段可能失落，因此使处在 LAST-ACK 状态的服务器收不到确认。服务器会超时重传 FIN+ACK 报文段，客户端就能在 2MSL 工夫内收到这个重传的 FIN+ACK 报文段，接着客户端重传一次确认，重启计时器。最好，客户端和服务器都失常进入到 CLOSED 状态。如果客户端在 TIME-WAIT 状态不期待一段时间，而是再发送完 ACK 报文后立刻开释连贯，那么就无奈收到服务器重传的 FIN+ACK 报文段，因此也不会再发送一次确认报文。这样，服务器就无奈依照失常步骤进入 CLOSED 状态。
2. 避免已生效的连贯申请报文段呈现在本连贯中。客户端在发送完最初一个 ACK 确认报文段后，再通过工夫2MSL，就能够使本连贯继续的工夫内所产生的所有报文段都从网络中隐没。这样就能够使下一个新的连贯中不会呈现这种旧的连贯申请报文段。

10. 4g 切换 wifi 会产生什么

当挪动设施的网络从 4G 切换到 WiFi 时，意味着 IP 地址变动了，那么必须要断开连接，而后从新连贯，而建设连贯的过程蕴含 TCP 三次握手和 TLS 四次挥手的时延，以及 TCP 慢启动的加速过程，给用户的感觉就是忽然网络卡顿了一下，所以说，迁徙的老本是很高的。

http3 是怎么解决连贯迁徙

HTTP3中 QUIC 协定没有用四元组的形式来 ” 绑定”连贯，而是 通过连贯 ID 来标记通信的两个端点 ，客户端和服务器能够各自抉择一组 ID 来标记本人，因而即便挪动设施的网络变动后，导致 IP 地址变动了， 只有仍保有上下文信息 (比方连贯 ID、TLS 密钥等)，就能够 ” 无缝 ” 地复用原连贯 ，打消重连的老本，没有丝毫卡顿感，达到了 连贯迁徙 的性能。

11. TCP 与 UDP 区别及场景

基于 TCP 的协定：HTTP、FTP、SMTP

基于 UDP 的协定： RIP、DNS、SNMP

12. TCP 滑动窗口，拥塞管制

TCP 通过：利用数据宰割、对数据包进行编号、校验和、流量管制、拥塞管制、超时重传等措施保证数据的牢靠传输。

拥塞管制目标：为了避免过多的数据注入到网络中，防止网络中的路由器、链路过载。

拥塞管制过程：TCP 保护一个拥塞窗口，该窗口随着网络拥塞水平动态变化，通过慢开始、拥塞防止等算法缩小网络拥塞的产生。

13. TCP 粘包起因和解决办法

TCP 粘包是指：发送方发送的若干包数据到接管方接管时粘成一包

发送方起因：

TCP 默认应用 Nagle 算法（次要作用：缩小网络中报文段的数量）：

收集多个小分组，在一个确认到来时一起发送、导致发送方可能会呈现粘包问题

接管方起因：

TCP 将接管到的数据包保留在接管缓存里，如果 TCP 接管数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

• 传输层的 UDP 协定不会产生粘包或者拆包问题

  UDP是基于报文发送的，在 UDP 首部采纳了 16bit 来批示 UDP 数据报文的长度，因而在应用层能很好的将不同的数据报文辨别开，从而防止粘包和拆包的问题。

• 传输层的 TCP 协定会产生粘包或者拆包问题

  起因有以下两点：

• 1. TCP是基于字节流的，尽管应用层和传输层之间的数据交互是大小不等的数据块，然而 TCP 把这些数据块仅仅看成一连串无构造的字节流，没有边界；
  2. 在 TCP 的首部没有示意数据长度的字段，基于下面两点，在应用 TCP 传输数据时，才有粘包或者拆包景象产生的可能。

解决粘包问题：解决问题的关键在于如何给每个数据包增加边界信息

最实质起因在与接管对等方无奈分辨音讯与音讯之间的边界在哪，通过应用某种计划给出边界，例如：

• 发送定长包。每个音讯的大小都是一样的，接管方只有累计接收数据，直到数据等于一个定长的数值就将它作为一个音讯。
• 包尾加上 \r\n 标记。FTP协定正是这么做的。但问题在于如果数据注释中也含有 \r\n，则会误判为音讯的边界。
• 包头加上包体长度。包头是定长的 4 个字节，阐明了包体的长度。接管对等方先接管包体长度，根据包体长度来接管包体。

14. TCP、UDP 报文格式

TCP 报文格式：

源端口号和目标端口号：

用于寻找发端和收端利用过程。这两个值加上 IP 首部源端 IP 地址和目标端 IP 地址惟一确定一个 TCP 连贯。

序号字段：

序号用来标识从 TCP 发端向 TCP 收端发送的数据字节流，它示意在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则 TCP用序号对每个字节进行计数。序号是 32 bit 的无符号数，序号达到 2^32- 1 后又从 0 开始。

当建设一个新的连贯时，SYN标记变 1。序号字段蕴含由这个主机抉择的该连贯的初始序号 ISN（Initial Sequence Number）。该主机要发送数据的第一个字节序号为这个 ISN 加 1，因为 SYN 标记耗费了一个序号

确认序号：

既然每个传输的字节都被计数，确认序号蕴含发送确认的一端所冀望收到的下一个序号。因而，确认序号该当是上次已胜利收到数据字节序号加 1。只有 ACK 标记为 1 时确认序号字段才无效。发送 ACK 无需任何代价，因为 32 bit 的确认序号字段和 A C K 标记一样，总是 TCP 首部的一部分。因而，咱们看到一旦一个连贯建设起来，这个字段总是被设置，ACK 标记也总是被设置为 1。TCP 为应用层提供全双工服务。这象征数据能在两个方向上独立地进行传输。因而，连贯的每一端必须放弃每个方向上的传输数据序号。

首都长度：

首部长度给出首部中 32 bit 字的数目。须要这个值是因为任选字段的长度是可变的。这个字段占 4 bit，因而 TCP 最多有 6 0 字节的首部。然而，没有任选字段，失常的长度是 20 字节。

标记字段 ：在TCP 首部中有 6 个标记比特，它们中的多个可同时被设置为 1。

• URG紧急指针（u rgent pointer）无效
• ACK确认序号无效。
• PSH接管方应该尽快将这个报文段交给应用层。
• RST重建连贯。
• SYN同步序号用来发动一个连贯。这个标记和下一个标记将在第 1 8 章介绍。
• FIN发端实现发送工作。

窗口大小：

TCP的流量管制由连贯的每一端通过申明的窗口大小来提供。窗口大小为字节数，起始于确认序号字段指明的值，这个值是接收端冀望接管的字节。窗口大小是一个 16 bit 字段，因此窗口大小最大为 65535 字节。

测验和：

测验和笼罩了整个的 TCP报文段：TCP首部和 TCP 数据。这是一个强制性的字段，肯定是由发端计算和存储，并由收端进行验证。

紧急指针：

只有当 URG 标记置 1 时紧急指针才无效。紧急指针是一个正的偏移量，和序号字段中的值相加示意紧急数据最初一个字节的序号。TCP的紧急形式是发送端向另一端发送紧急数据的一种形式。

选项：

最常见的可选字段是最长报文大小，又称为 MSS (Maximum Segment Size)。每个连贯方通常都在通信的第一个报文段（为建设连贯而设置 SYN标记的那个段）中指明这个选项。它指明本端所能接管的最大长度的报文段。

UDP 报文格式：

端口号：

用来示意发送和承受过程。因为 IP层曾经把 I P 数据报调配给 TCP 或 UDP（依据 I P 首部中协定字段值），因而 TCP 端口号由 TCP 来查看，而 UDP端口号由 UDP来查看。TCP端口号与 UDP端口号是互相独立的。

长度：

UDP长度字段指的是 UDP首部和 UDP数据的字节长度。该字段的最小值为 8 字节（发送一份 0 字节的 UDP数据报是 O K）。

测验和：

UDP测验和是一个端到端的测验和。它由发送端计算，而后由接收端验证。其目标是为了发现 UDP首部和数据在发送端到接收端之间产生的任何改变。

IP 报文格式：一般的 IP 首部长为 20 个字节，除非含有可选项字段。

4 位版本：目前协定版本号是 4，因而 IP 有时也称作 IPV4.

4 位首部长度：

首部长度指的是首部占 32bit 字的数目，包含任何选项。因为它是一个 4 比特字段，因而首部长度最长为 60 个字节。

服务类型（TOS）：

服务类型字段包含一个 3bit 的优先权字段（当初曾经被疏忽），4bit的 TOS 子字段和 1bit 未用位必须置 0。4bit的 TOS 别离代表：最小时延，最大吞吐量，最高可靠性和最小费用。4bit 中只能置其中 1 比特。如果所有 4bit 均为 0，那么就意味着是个别服务。

总长度：

总长度字段是指整个 IP 数据报的长度，以字节为单位。利用首部长度和总长度字段，就能够晓得 IP 数据报中数据内容的起始地位和长度。因为该字段长16bit，所以 IP 数据报最长可达 65535 字节。当数据报被分片时，该字段的值也随着变动。

标识字段：

标识字段惟一地标识主机发送的每一份数据报。通常每发送一份报文它的值就会加 1。

生存工夫：

TTL（time-to-live）生存工夫字段设置了数据报能够通过的最多路由器数。它指定了数据报的生存工夫。TTL 的初始值由源主机设置（通常为 3 2 或 6 4），一旦通过一个解决它的路由器，它的值就减去 1。当该字段的值为 0 时，数据报就被抛弃，并发送 ICMP 报文告诉源主机。

首部测验和：

首部测验和字段是依据 I P 首部计算的测验和码。它不对首部前面的数据进行计算。ICMP、IGMP、UDP和 TCP 在它们各自的首部中均含有同时笼罩首部和数据测验和码。

以太网报文格式：

目标地址和源地址： 是指网卡的硬件地址（也叫 MAC 地址），长度是 48 位，是在网卡出厂时固化的。

数据：

以太网帧中的数据长度规定最小 46 字节，最大 1500 字节，ARP 和 RARP 数据包的长度不够 46 字节，要在前面补填充位。最大值 1500 称为以太网的最大传输单元（MTU），不同的网络类型有不同的 MTU，如果一个数据包从以太网路由到拨号链路上，数据包度大于拨号链路的MTU 了，则须要对数据包进行分片 fragmentation）。ifconfig 命令的输入中也有“MTU:1500”。留神，MTU个概念指数据帧中有效载荷的最大长度，不包含帧首部的长度。

15. TCP 协定如何保障牢靠传输机制？

TCP 次要提供了测验和、序列号 / 确认应答、超时重传、滑动窗口、拥塞管制和流量管制等办法实现了可靠性传输。

• 测验和：通过测验和的形式，接收端能够检测进去数据是否有过错和异样，如果有过错就会间接抛弃 TCP 段，从新发送。
• 序列号 / 确认应答：序列号的作用不仅仅是应答的作用，有了序列号可能将接管到的数据依据序列号排序，并且去掉反复序列号的数据。TCP传输的过程中，每次接管方收到数据后，都会对传输方进行确认应答。也就是发送 ACK 报文, 这个 ACK 报文当中带有对应的确认序列号，通知发送方，接管到了哪些数据，下一次的数据从哪里发。
• 超时重传： 超时重传是指发送进来的数据包到接管到确认包之间的工夫，如果超过了这个工夫会被认为是丢包了，须要重传。最大超时工夫是动静计算的。
• 滑动窗口： 滑动窗口既进步了报文传输的效率，也防止了发送方发送过多的数据而导致接管方无奈失常解决的异样。
• 拥塞管制： 在数据传输过程中，可能因为网络状态的问题，造成网络拥挤，此时引入拥塞管制机制，在保障 TCP 可靠性的同时，进步性能。
• 流量管制： 如果主机 A 始终向主机 B 发送数据，不思考主机 B 的承受能力，则可能导致主机 B 的承受缓冲区满了而无奈再承受数据，从而会导致大量的数据丢包，引发重传机制。而在重传的过程中，若主机 B 的接收缓冲区状况仍未恶化，则会将大量的工夫节约在重传数据上，升高传送数据的效率。所以引入流量管制机制，主机 B 通过通知主机 A 本人接收缓冲区的大小，来使主机 A 管制发送的数据量。流量管制与 TCP 协定报头中的窗口大小无关。

16. TCP 的滑动窗口?

在进行数据传输时，如果传输的数据比拟大，就须要拆分为多个数据包进行发送。TCP协定须要对数据进行确认后，才能够发送下一个数据包。这样一来，就会在期待确认应答包环节浪费时间。为了防止这种状况，TCP引入了窗口概念。窗口大小指的是不须要期待确认应答包而能够持续发送数据包的最大值。

从下面的图能够看到滑动窗口右边的是已发送并且被确认的分组，滑动窗口左边是还没有轮到的分组。

滑动窗口外面也分为两块，一块是曾经发送然而未被确认的分组，另一块是窗口内期待发送的分组。随着已发送的分组一直被确认，窗口内期待发送的分组也会一直被发送。整个窗口就会往右挪动，让还没轮到的分组进入窗口内。

能够看到滑动窗口起到了一个限流的作用，也就是说以后滑动窗口的大小决定了以后 TCP 发送包的速率，而滑动窗口的大小取决于拥塞管制窗口和流量管制窗口的两者间的最小值。

17. 具体讲一下拥塞管制? 为何要进行拥塞管制？

A 在给 B 传输数据, A 却没有收到 B 反馈的 TCP,A 就认为 B 发送的数据包失落了.. 进而会从新传输这个失落的数据包。然而理论状况有可能此时有太多主机正在应用信道资源，导致 网络拥塞 了。重传数据节约了资源，所以要进行拥塞管制。发送发不晓得一次发多少数据适合，所以设置一个拥塞窗口。

TCP 拥塞管制原理是通过：慢启动、拥塞防止、快重传、快启动

发送方维持一个叫做拥塞窗口 cwnd (congestion window)的状态变量。当 cwndssthresh 时，改用拥塞防止算法。

• 慢开始: 不要一开始就发送大量的数据，由小到大逐步减少拥塞窗口的大小。
• 拥塞防止: 拥塞防止算法让拥塞窗口迟缓增长，即每通过一个往返工夫 RTT 就把发送方的拥塞窗口 cwnd 加 1 而不是加倍。这样拥塞窗口按线性法则迟缓增长。
• 快重传: 咱们能够剔除一些不必要的拥塞报文，进步网络吞吐量。比方接管方在收到一个失序的报文段后就立刻收回反复确认，而不要等到本人发送数据时捎带确认。快重传规定: 发送方只有一连收到三个反复确认就该当立刻重传对方尚未收到的报文段，而不用持续期待设置的重传计时器工夫到期。
• 快复原: 次要是配合快重传。当发送方间断收到三个反复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半(为了预防网络产生拥塞)，但接下来并不执行慢开始算法，因为如果网络呈现拥塞的话就不会收到好几个反复的确认，收到三个反复确认阐明网络情况还能够。

18. TCP 拥塞管制 4 种算法

• 基于丢包的拥塞管制 ：将丢包视为呈现拥塞，采取迟缓探测的形式，逐步增大拥塞窗口，当呈现丢包时，将拥塞窗口减小，如Reno、Cubic 等。
• 基于时延的拥塞管制 ：将时延减少视为呈现拥塞，延时减少时增大拥塞窗口，延时减小时减小拥塞窗口，如Vegas、FastTCP 等。
• 基于链路容量的拥塞管制：实时测量网络带宽和时延，认为网络上报文总量大于带宽时延乘积时呈现了拥塞，如BBR。
• 基于学习的拥塞管制：没有特定的拥塞信号，而是借助评估函数，基于训练数据，应用机器学习的办法造成一个控制策略，如Remy。

HTTP 协定

1. HTTP 协定 1.0 1.1 2.0

HTTP1.0：服务器解决实现后立刻断开 TCP 连贯（无连贯 ），服务器不跟踪每个客户端也不记录过来的申请（ 无状态）

HTTP1.1： KeepAlived 长连贯 防止了连贯建设和开释的开销；通过 Content-Length 来判断以后申请数据是否曾经全副承受（有状态）

HTTP2.0：引入二进制数据帧和流的概念，其中帧对数据进行程序标识；因为有了序列，服务器能够 并行 的传输数据。

无状态的好坏

• 无状态的益处 ，因为服务器不会去记忆 HTTP 的状态，所以不须要额定的资源来记录状态信息，这能减 轻服务器的累赘，可能把更多的 CPU 和内存用来对外提供服务。
• 无状态的害处，既然服务器没有记忆能力，这样每操作一次，都要验证信息。例如登录 -> 增加购物车 -> 下单 -> 结算 -> 领取，这系列操作都要晓得用户的身份才行。但服务器不晓得这些申请是有关联的，每次都要问一遍身份信息。

解决无状态的问题，解法计划有很多种，其中比较简单的形式用 Cookie 和 Session 技术。

2. HTTP1.0 和 HTTP1.1 的次要区别如下：

1. 缓存解决：1.1 增加更多的缓存控制策略（如：Entity tag，If-Match）
2. 网络连接的优化：1.1 反对断点续传
3. 谬误状态码的增多：1.1 新增了 24 个谬误状态响应码，丰盛的错误码更加明确各个状态
4. Host 头解决 ：反对Host 头域，不在以 IP 为申请方标记
5. 长连贯：缩小了建设和敞开连贯的耗费和提早。

3. HTTP1.1 和 HTTP2.0 的次要区别：

1. 新的传输格局：2.0 应用二进制格局，1.0 仍然应用基于文本格式
2. 多路复用 ：连贯共享，不同的request 能够应用同一个连贯传输（最初依据每个 request 上的 id 号组合成失常的申请）
3. header 压缩 ：因为 1.X 中header 带有大量的信息，并且得反复传输，2.0 应用 encoder 来缩小须要传输的 hearder 大小
4. 服务端推送 ：同google 的SPDUY（1.0 的一种降级）一样

4. HTTP 和 HTTPS 的区别：

1. 最重要的区别就是 安全性 ，HTTP 明文传输，不对数据进行加密安全性较差。HTTPS (HTTP + SSL / TLS)的数据传输过程是加密的，安全性较好。
2. 证书 ：应用 HTTPS 协定须要申请 CA 证书，个别收费证书较少，因此须要肯定费用。证书颁发机构如：Symantec、Comodo 、DigiCert 和 GlobalSign 等。
3. 响应速度 ：HTTP 页面响应速度比 HTTPS 快，这个很好了解，因为加了一层平安层，建设连贯的过程更简单，也要替换更多的数据，不免影响速度。
4. 加密 ：HTTP 协定运行在 TCP（三次握手）之上，所有传输的内容都是明文，HTTPS 运行在 SSL/TLS 之上，SSL/TLS运行在 TCP 之上，所有传输的内容都通过加密的。
5. 端口不同 ：HTTPS 和 HTTP 应用的是齐全不同的连贯形式，用的端口也不一样，前者是 443，后者是 80。

5. HTTPS 的毛病：

1. 在雷同网络环境中，HTTPS 相比 HTTP 无论是响应工夫还是耗电量都有大幅度回升。
2. HTTPS 的平安是有范畴的，在黑客攻击、服务器劫持等状况下简直起不到作用。
3. 在现有的证书机制下，中间人攻打仍然有可能产生。
4. HTTPS 须要更多的服务器资源，也会导致老本的升高。

6. HTTPS 链接建设的过程：

1. 首先客户端先给服务器发送一个申请
2. 服务器发送一个 SSL 证书给客户端，内容包含：证书的公布机构、有效期、所有者、签名以及公钥
3. 客户端对发来的公钥进行真伪校验，校验为真则应用公钥对对称加密算法以及对称密钥进行加密
4. 服务器端应用私钥进行解密并应用对称密钥加密确认信息发送给客户端
5. 随后客户端和服务端就应用对称密钥进行信息传输

加密流程按图中的序号分为:

1. 客户端申请 HTTPS 网址，而后连贯到 server 的 443 端口 (HTTPS 默认端口，相似于 HTTP 的 80 端口)。
2. 采纳 HTTPS 协定的服务器必须要有一套数字 CA (Certification Authority) 证书。颁发证书的同时会产生一个私钥和公钥。私钥由服务端本人保留，不可透露。公钥则是附带在证书的信息中，能够公开的。证书自身也附带 - 一个证书电子签名，这个签名用来验证证书的完整性和真实性，能够避免证书被篡改。
3. 服务器响应客户端申请，将证书传递给客户端，证书蕴含公钥和大量其余信息，比方证书颁发机构信息，公司信息和证书有效期等。
4. 客户端解析证书并对其进行验证。如果证书不是可信机构颁布，或者证书中的域名与理论域名不统一，或者证书曾经过期，就会向访问者显示一个正告，由其抉择是否还要持续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥 A。而后客户端还会生成一一个随机码KEY, 并应用公钥 A 将其加密。
5. 客户端把加密后的随机码 KEY 发送给服务器，作为前面对称加密的密钥。
6. 服务器在收到随机码 KEY 之后会应用私钥 B 将其解密。通过以上这些步骤，客户端和服务器终于建设了平安连贯，完满解决了对称加密的密钥泄露问题，接下来就能够用对称加密欢快地进行通信了。
7. 服务器应用密钥 (随机码KEY) 对数据进行对称加密并发送给客户端，客户端应用雷同的密钥 (随机码KEY) 解密数据。
8. 单方应用对称加密欢快地传输所有数据。

7. HTTP 常见响应状态码

100：Continue 一一 持续。客户端应持续其申请。

200：OK 一一 申请胜利。一 般用于 GET 与 POST 申请。

301：Moved Permanently 一一 永恒重定向。

302：Found 一一 临时重定向。

400：Bad Request 一一 客户端申请的语法错误，服务器无奈了解。申请没有蕴含 host 头

403：Forbideen 一一 服务器了解申请客户端的申请，然而拒绝执行此申请。禁止客户拜访该资源

404：Not Found 一一 服务器无奈依据客户端的申请找到资源（网页）。资源未找到

500：Internal Server Error 一一 服务器外部谬误，无奈实现申请。

502：Bad Gateway 一一 作为网关或者代理服务器尝试执行申请时，从近程服务器接管到了有效的响应。

8. 状态码 301 和 302 的区别是什么?

301为永恒重定向，302为长期重定向

共同点 : 301 和302状态码都示意重定向，就是说浏览器在拿到服务器返回的这个状态码后会主动跳转到一个新的 URL 地址，这个地址能够从响应的 Location 首部中获取(用户看到的成果就是他输出的地址 A 霎时变成了另一个地址 B)。

不同点 : 301 示意旧地址 A 的资源曾经被永恒地移除了 (这个资源不可拜访了)，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址;302 示意旧地址 A 的资源还在 (依然能够拜访)，这个重定向只是长期地从旧地址 A 跳转到地址 B，搜索引擎会抓取新的内容而保留旧的网址。SEO 中302 好于301。

补充，重定向起因:

1. 网站调整(如扭转网页目录构造);
2. 网页被移到一个新地址;
3. 网页扩展名扭转(如利用须要把.php 改成.Html 或.shtml)。

9. 对称加密算法与非对称加密算法的区别

对称加密算法：

单方持有雷同的密钥，且加密速度快，典型对称加密算法：DES、AES

非对称加密算法：

密钥成对呈现（私钥、公钥），私钥只有本人晓得，不在网络中传输；而公钥能够公开。相比对称加密速度较慢，典型的非对称加密算法有：AES、DSA

10. HTTP 申请办法：

11. Get 和 Post 申请区别

12. GET 和 POST 办法都是平安和幂等的吗？

先阐明下平安和幂等的概念：

• 在 DSA协定里，所谓的「平安」是指申请办法不会「毁坏」服务器上的资源。
• 所谓的「幂等」，意思是屡次执行雷同的操作，后果都是「雷同」的。

那么很显著 GET 办法就是平安且幂等的，因为它是「只读」操作，无论操作多少次，服务器上的数据 都是平安的，且每次的后果都是雷同的。

POST 因为是「新增或提交数据」的操作，会批改服务器上的资源，所以是 不平安 的，且屡次提交数据 就会创立多个资源，所以 不是幂等 的。

13. 重定向和转发区别

转发是服务器行为, 重定向是客户端行为

重定向：redirect：

地址栏发生变化

重定向能够拜访其余站点（服务器）的资源

重定向是两次申请。不能应用 request 对象来共享数据

转发：forward：

转发地址栏门路不变

转发只能拜访以后服务器下的资源

转发是一次申请，能够应用 request 对象共享数据

14. Cookie 和 Session 区别

Cookie 和 Session 都是用来跟踪浏览器用户身份的会话形式，但两者有所区别：

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

cookie不是很平安，他人能够剖析寄存在本地的 Cookie 并进行坑骗, 思考到平安该当应用 session。

Cookie ⼀般⽤来保留⽤户信息，Session 的次要作⽤就是通过服务端记录⽤户的状态

15. 浏览器输出 URL 过程

过程：DNS解析、TCP连贯、发送 HTTP 申请、服务器解决申请并返回 HTTP 报文、浏览器渲染、完结

1. 域名解析 (域名 www.baidu.com 变为 IP 地址)。浏览器搜寻本人的DNS 缓存(保护一张域名与 IP 的对应表);
2. 1. 若没有，则搜寻操作系统的 DNS 缓存(保护一张域名与 IP 的对应表) ;
   2. 若没有，则搜寻操作系统的 hosts 文件(保护一张域名与 IP 的对应表)。
   3. 若都没有，则找 TCP/IP 参数中设置的首选 dns 服务器，即本地 DNS 服务器 (递归查问)，本地域名服务器查问本人的DNS 缓存，如果没有，则进行迭代查问。将本地 dns 服务器将 IP 返回给操作系统，同时缓存 IP。
3. 发动 TCP 的三次握手，建设 TCP 连贯。浏览器会以一个随机端口 (1024-65535) 向服务端的 web 程序 80 端口发动TCP 的连贯。
4. 建设 TCP 连贯后发动 HTTP 申请。
5. 服务器响应 HTTP 申请，客户端失去 html 代码。服务器 web 应用程序收到 HTTP 申请后，就开始解决申请，解决之后就返回给浏览器 html 文件。
6. 浏览器解析 html 代码，并申请 html 中的资源。
7. 浏览器对页面进行渲染，并出现给用户。

如何查看 TCP 的连贯状态？TCP 的连贯状态查看，在 Linux 能够通过 netstat -napt 命令查看。

16. DNS 协定是 TCP 还是 UDP?

• DNS占用 53 号端口，同时应用 TCP 和UDP协定。那么 DNS 在什么状况下应用这两种协定？

  DNS 在区域传输的时候应用 TCP 协定，其余时候应用 UDP 协定。

• • 客户端向 DNS 服务器查问域名，个别返回的内容都不超过 512 字节，用 UDP 传输即可。不必通过 TCP 三次握手，这样 DNS 服务器负载更低，响应更快。尽管从实践上说，客户端也能够指定向 DNS 服务器查问的时候应用 TCP，但事实上，很多DNS 服务器进行配置的时候，仅反对 UDP 查问包。
  • 辅域名服务器会定时（个别 3 小时）向主域名服务器进行查问以便理解数据是否有变动。如有变动，会执行一次区域传送，进行数据同步。区域传送应用 TCP 而不是UDP，因为数据同步传送的数据量比一个申请应答的数据量要多得多。
  • TCP是一种牢靠连贯，保障了数据的准确性。
  • DNS 区域传输的时候应用 TCP 协定：
  • 域名解析时应用 UDP 协定：

17. ARP 协定如何找到对应 IP 地址和 mac 的映射的

简略地说，ARP 是借助 ARP 申请与 ARP 响应两种类型的包确定 MAC 地址的。

• 主机会通过播送发送 ARP 申请，这个包中蕴含了想要晓得的 MAC 地址的主机 IP 地址。
• 当同个链路中的所有设施收到 ARP 申请时，会去拆开 ARP 申请包里的内容，如果 ARP 申请包中 的指标 IP 地址与本人的 IP 地址统一，那么这个设施就将本人的 MAC 地址塞入 ARP 响应包返回 给主机。

操作系统通常会把第一次通过 ARP 获取的 MAC 地址缓存起来，以便下次间接从缓存中找到对应 IP 地 址的 MAC 地址。不过，MAC 地址的缓存是有肯定期限的，超过这个期限，缓存的内容将被革除

18. RARP 协定你晓得是什么吗？

ARP 协定是已知 IP 地址求 MAC 地址，那 RARP 协定正好相同，它是已知 MAC地址求 IP 地址。例如 将打印机服务器等小型嵌入式设施接入到网络时就常常会用失去。

通常这须要架设一台 RARP 服务器，在这个服务器上注册设施的 MAC 地址及其 IP 地址。而后再将 这个设施接入到网络，接着：

• 该设施会发送一条「我的 MAC 地址是 XXXX，请通知我，我的 IP 地址应该是什么」的申请信息。
• RARP 服务器接到这个音讯后返回「MAC地址为 XXXX 的设施，IP 地址为 XXXX」的信息给这个 设施。

最初，设施就依据从 RARP 服务器所收到的应答信息设置本人的 IP 地址

19. 什么是 DDos 攻打?

DDos全称 Distributed Denial of Service，分布式拒绝服务攻打。最根本的 DOS 攻打过程如下:

1. 客户端向服务端发送申请链接数据包。
2. 服务端向客户端发送确认数据包。
3. 客户端不向服务端发送确认数据包，服务器始终期待来自客户端的确认

DDos则是采纳分布式的办法，通过在网络上霸占多台“肉鸡”，用多台计算机发动攻打。

DDos攻打当初根本没啥作用了，因为服务器的性能都很好，而且是多台服务器独特作用，1V1 的模式黑客无奈占上风。对于 DDos 攻打，预防办法有:

• 缩小 SYN timeout 工夫。在握手的第三步，服务器会期待 30 秒 -120 秒的工夫，缩小这个等待时间就能开释更多的资源。
• 限度同时关上的 SYN 半连贯数目。

20. 什么是 XSS 攻打?

XSS 也称 cross-sitescripting, 跨站脚本。这种攻打是因为服务器将攻击者存储的数据原原本本地显示给其余用户所致的。比方一个存在 XSS 破绽的论坛，用户发帖时就能够引入带有 < script> 标签的代码，导致恶意代码的执行。

预防措施有:

• 前端：过滤。
• 后端：本义，比方 go 自带的处理器就具备本义性能。

21. SQL 注入是什么，如何防止 SQL 注入?

SQL注入就是在用户输出的字符串中退出 SQL 语句，如果在设计不良的程序中疏忽了查看，那么这些注入进去的 SQL 语句就会被数据库服务器误认为是失常的 SQL 语句而运行，攻击者就能够执行计划外的命令或拜访未被受权的数据。

SQL注入的原理次要有以下 4 点：

1. 歹意拼接查问
2. 利用正文执行非法命令
3. 传入非法参数
4. 增加额定条件

防止 SQL 注入的一些办法：

1. 参数校验：在一些不该有特殊字符的参数中提前进行特殊字符校验即可。
2. 限度数据库权限，给用户提供仅仅可能满足其工作的最低权限。
3. 提供参数化查问接口，不要间接应用原生SQL。
4. SQL 预编译

在晓得了 SQL 注入的原理之后，咱们同样也理解到 MySQL 有预编译的性能，指的是在服务器启动时，MySQL Client 把 SQL 语句的模板（变量采纳占位符进行占位）发送给 MySQL 服务器，MySQL服务器对 SQL 语句的模板进行编译，编译之后依据语句的优化剖析对相应的索引进行优化，在最终绑定参数时把相应的参数传送给 MySQL 服务器，间接进行执行，节俭了 SQL 查问工夫，以及 MySQL 服务器的资源，达到一次编译、屡次执行的目标，除此之外，还能够避免 SQL 注入。

具体是怎么避免 SQL 注入的呢？实际上当将绑定的参数传到 MySQL 服务器，MySQL服务器对参数进行编译，即填充到相应的占位符的过程中，做了本义操作。咱们罕用的 JDBC 就有预编译性能，不仅晋升性能，而且避免 SQL 注入。

22. 网络编程 socket，客户端和服务端通信过程，别离调用了哪些函数，作用是什么

• 服务器端程序：
• 1. 创立一个socket，用函数socket()
  2. 绑定 IP 地址、端口等信息到 socket 上，用函数bind()
  3. 设置容许的最大连接数，用函数listen()
  4. 接管客户端上来的连贯，用函数accept()
  5. 收发数据，用函数 send() 和recv()，或者 read() 和write()
  6. 敞开网络连接
• 客户端程序：
• 1. 创立一个socket，用函数socket()
  2. 设置要连贯的对方的 IP 地址和端口等属性
  3. 连贯服务器，用函数connect()
  4. 收发数据，用函数 send() 和recv()，或 read() 和write()
  5. 敞开网络连接

23. 负载平衡算法有哪些?

nginx 负载平衡的三种形式次要是 轮询模式、weight 权重模式、ip_hash。

当一台服务器的单位工夫内的访问量越大时，服务器压力就越大，大到超过本身承受能力时，服务器就会解体。为了防止服务器解体，让用户有更好的体验，咱们通过负载平衡的形式来分担服务器压力。

1. 轮询模式（默认）每个申请按工夫程序逐个调配到不同的后端服务器，如果后端服务器 down 掉，能主动剔除。适宜服务器配置相当，无状态且短平快的服务应用。也实用于图片服务器集群和纯动态页面服务器集群。
2. weight 权重模式 这种形式比拟灵便，当后端服务器性能存在差别的时候，通过配置权重，能够让服务器的性能失去充分发挥，无效利用资源。weight 和拜访比率成正比，用于后端服务器性能不均的状况。权重越高，在被拜访的概率越大

3. ip_hash上述 weight 权重模式形式存在一个问题，在负载平衡零碎中，如果用户在某台服务器上登录了，那么该用户第二次申请的时候，因为咱们是负载平衡零碎，每次申请都会从新定位到服务器集群中的某一个，那么曾经登录某一个服务器的用户再从新定位到另一个服务器，其登录信息将会失落，这样显然是不妥的。

   能够采纳 ip_hash 指令解决这个问题，如果客户曾经拜访了某个服务器，当用户再次拜访时，会将该申请通过哈希算法，主动定位到该服务器。每个申请按拜访 IP 的 hash 后果调配，这样每个访客固定拜访一个后端服务器，能够解决 session 不能跨服务器的问题。