大家好，我是老三，动工大吉，虎年第一篇，面渣逆袭系列持续！

这次给大家带来了计算机网络六十二问，三万字，七十图详解，大略是全网最全的网络面试题。

倡议大家 <big>珍藏</big> 了缓缓看，新的一年肯定可能跳槽加薪，虎年“豹”富！

根底

1. 说下计算机网络体系结构

计算机网络体系结构，个别有三种：ISO 七层模型、TCP/IP 四层模型、五层构造。

简略说，OSI 是一个实践上的网络通信模型，TCP/IP 是实际上的网络通信模型，五层构造就是为了介绍网络原理而折中的网络通信模型。

ISO 七层模型

ISO 七层模型是国际标准化组织（International Organization for Standardization）制订的一个用于计算机或通信零碎间互联的规范体系。

• 应用层：通过利用过程之间的交互来实现特定网络应用，应用层协定定义的是利用过程间通信和交互的规定，常见的协定有：HTTP FTP  SMTP SNMP DNS.
• 表示层：数据的示意、平安、压缩。确保一个零碎的应用层所发送的信息能够被另一个零碎的应用层读取。
• 会话层：建设、治理、终止会话，是用户应用程序和网络之间的接口。
• 运输层：提供源端与目标端之间提供牢靠的通明数据传输，传输层协定为不同主机上运行的过程提供逻辑通信。
• 网络层：将网络地址翻译成对应的物理地址，实现不同网络之间的门路抉择, 协定有 ICMP IGMP IP 等.
• 数据链路层：在物理层提供比特流服务的根底上，建设相邻结点之间的数据链路。
• 物理层：建设、保护、断开物理连贯。

TCP/IP 四层模型

• 应用层：对应于 OSI 参考模型的（应用层、表示层、会话层）。
• 传输层: 对应 OSI 的传输层，为应用层实体提供端到端的通信性能，保障了数据包的程序传送及数据的完整性。
• 网际层：对应于 OSI 参考模型的网络层，次要解决主机到主机的通信问题。
• 网络接口层：与 OSI 参考模型的数据链路层、物理层对应。

五层体系结构

• 应用层：对应于 OSI 参考模型的（应用层、表示层、会话层）。
• 传输层：对应 OSI 参考模型的的传输层
• 网络层：对应 OSI 参考模型的的网络层
• 数据链路层：对应 OSI 参考模型的的数据链路层
• 物理层：对应 OSI 参考模型的的物理层。

2. 说一下每一层对应的网络协议有哪些？

一张表格总结常见网络协议：

3. 那么数据在各层之间是怎么传输的呢？

对于发送方而言，从下层到上层层层包装，对于接管方而言，从上层到下层，层层解开包装。

• 发送方的利用过程向接管方的利用过程传送数据
• AP 先将数据交给本主机的应用层，应用层加上本层的管制信息 H5 就变成了下一层的数据单元
• 传输层收到这个数据单元后，加上本层的管制信息 H4，再交给网络层，成为网络层的数据单元
• 到了数据链路层，管制信息被分成两局部，别离加到本层数据单元的首部（H2）和尾部（T2）
• 最初的物理层，进行比特流的传输

这个过程相似写信，写一封信，每到一层，就加一个信封，写一些地址的信息。到了目的地之后，又一层层解封，传向下一个目的地。

网络综合

4. 从浏览器地址栏输出 url 到显示主页的过程？

这道题，大略的过程比较简单，然而有很多点能够细挖：DNS 解析、TCP 三次握手、HTTP 报文格式、TCP 四次挥手等等。

1. DNS 解析：将域名解析成对应的 IP 地址。
2. TCP 连贯：与服务器通过三次握手，建设 TCP 连贯
3. 向服务器发送 HTTP 申请
4. 服务器解决申请，返回 HTTp 响应
5. 浏览器解析并渲染页面
6. 断开连接：TCP 四次挥手，连贯完结

咱们以输出 www.baidu.com 为例：

各个过程都应用了哪些协定？

5. 说说 DNS 的解析过程？

DNS，英文全称是 domain name system，域名解析零碎，它的作用也很明确，就是域名和 IP 互相映射。

DNS 的解析过程如下图：

假如你要查问 www.baidu.com 的 IP 地址:

• 首先会查找浏览器的缓存, 看看是否能找到 www.baidu.com 对应的 IP 地址，找到就间接返回；否则进行下一步。
• 将申请发往给本地 DNS 服务器，如果查找到也间接返回，否则持续进行下一步；

• 本地 DNS 服务器向 根域名服务器 发送申请，根域名服务器返回负责 com 的顶级域名服务器的 IP 地址的列表。
• 本地 DNS 服务器再向其中一个负责 com 的顶级域名服务器发送一个申请，返回负责 baidu.com 的权限域名服务器的 IP 地址列表。
• 本地 DNS 服务器再向其中一个权限域名服务器发送一个申请，返回 www.baidu.com 所对应的 IP 地址。

6. 说说 WebSocket 与 Socket 的区别？

• Socket 其实就是等于 IP 地址 + 端口 + 协定。

具体来说，Socket 是一套规范，它实现了对 TCP/IP 的高度封装，屏蔽网络细节，以不便开发者更好地进行网络编程。

• WebSocket 是一个长久化的协定，它是随同 H5 而出的协定，用来解决 http 不反对长久化连贯 的问题。
• Socket 一个是 网编编程的标准接口，而 WebSocket 则是应用层通信协议。

7. 说一下你理解的端口及对应的服务？

HTTP

8. 说说 HTTP 罕用的状态码及其含意？

HTTP 状态码首先应该晓得个大略的分类：

• 1XX：信息性状态码
• 2XX：胜利状态码
• 3XX：重定向状态码
• 4XX：客户端谬误状态码
• 5XX：服务端谬误状态码

几个罕用的，面试之外，也应该记住：

之前写过一篇：程序员五一被拉去相亲，后果彻底搞懂了 HTTP 罕用状态码，还比拟有意思，能够看看。

说一下 301 和 302 的区别？

• 301：永久性挪动，申请的资源已被永恒挪动到新地位。服务器返回此响应时，会返回新的资源地址。
• 302：临时性性挪动，服务器从另外的地址响应资源，然而客户端还应该应用这个地址。

用一个比喻，301 就是嫁人的新垣结衣，302 就是有男朋友的长泽雅美。

9.HTTP 有哪些申请形式？

其中，POST、DELETE、PUT、GET 的含意别离对应咱们最相熟的增、删、改、查。

10. 说⼀下 GET 和 POST 的区别？

能够从以下几个方面来阐明 GET 和 POST 的区别：

1. 从 HTTP 报文层面来看，GET 申请将信息放在 URL，POST 将申请信息放在申请体中。这一点使得 GET 申请携带的数据量无限，因为 URL 自身是有长度限度的，而 POST 申请的数据寄存在报文体中，因而对大小没有限度。而且从模式上看，GET 申请把数据放 URL 上不太平安，而 POST 申请把数据放在申请体里想比较而言平安一些。
2. 从数据库层面来看，GET 合乎幂等性和安全性，而 POST 申请不合乎。这个其实和 GET/POST 申请的作用无关。依照 HTTP 的约定，GET 申请用于查看信息，不会扭转服务器上的信息；而 POST 申请用来扭转服务器上的信息。正因为 GET 申请只查看信息，不扭转信息，对数据库的一次或屡次操作取得的后果是统一的，认为它合乎幂等性。安全性是指对数据库操作没有扭转数据库中的数据。
3. 从其余层面来看，GET 申请可能被缓存，GET 申请可能保留在浏览器的浏览记录里，GET 申请的 URL 可能保留为浏览器书签。这些都是 POST 申请所不具备的。缓存是 GET 申请被广泛应用的基本，他可能被缓存也是因为它的幂等性和安全性，除了返回后果没有其余多余的动作，因而绝大部分的 GET 申请都被 CDN 缓存起来了，大大减少了 Web 服务器的累赘。

11.GET 的长度限度是多少？

HTTP 中的 GET 办法是通过 URL 传递数据的，然而 URL 自身其实并没有对数据的长度进行限度，真正限度 GET 长度的是浏览器。

例如 IE 浏览器对 URL 的最大限度是 2000 多个字符，大略 2kb 左右，像 Chrome、Firefox 等浏览器反对的 URL 字符数更多，其中 FireFox 中 URL 的最大长度限度是 65536 个字符，Chrome 则是 8182 个字符。

这个长度限度也不是针对数据局部，而是针对整个 URL。

12.HTTP 申请的过程与原理？

HTTP 协定定义了浏览器怎么向服务器申请文档，以及服务器怎么把文档传给浏览器。

• 每个服务器都有一个过程，它一直监听 TCP 的端口 80，以便发现是否有浏览器向它收回连贯建设申请
• 监听到连贯申请，就会建设 TCP 连贯
• 浏览器向服务器收回浏览某个页面的申请，服务器接着就返回所申请的页面作为响应
• 最初，开释 TCP 连贯

在浏览器和服务器之间的申请和响应的交互，必须依照规定的格局和遵循肯定的规定，这些格局和规定就是超文本传输协定 HTTP。

PS: 这道题和下面浏览器输出网址产生了什么那道题大差不差。

13. 说一下 HTTP 的报文构造？

HTTP 报文有两种，HTTP 申请报文和 HTTP 响应报文：

HTTP 申请报文

HTTP 申请报文的格局如下：

GET / HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
Accept: */*

HTTP 申请报文的第一行叫做申请行，前面的行叫做首部行，首部行后还能够跟一个实体主体。申请首部之后有一个空行，这个空行不能省略，它用来划分首部与实体。

申请行蕴含三个字段：

• 办法字段：包含 POST、GET 等请办法。
• URL 字段
• HTTP 版本字段。

HTTP 响应报文

HTTP 响应报文的格局如下：

HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 137582
Expires: Thu, 05 Dec 1997 16:00:00 GMT
Last-Modified: Wed, 5 August 1996 15:55:28 GMT
Server: Apache 0.84
<html>
  <body>Hello World</body>
</html>

HTTP 响应报文的第一行叫做 状态行 ，前面的行是 首部行 ，最初是 实体主体。

• 状态行 蕴含了三个字段：协定版本字段、状态码和相应的状态信息。
• 实体局部 是报文的次要局部，它蕴含了所申请的对象。

• 首部行 首部能够分为四种首部，申请首部、响应首部、通用首部和实体首部。通用首部和实体首部在申请报文和响应报文中都能够设置，区别在于申请首部和响应首部。

  • 常见的申请首部有 Accept 可接管媒体资源的类型、Accept-Charset 可接管的字符集、Host 申请的主机名。
  • 常见的响应首部有 ETag 资源的匹配信息，Location 客户端重定向的 URI。
  • 常见的通用首部有 Cache-Control 管制缓存策略、Connection 治理长久连贯。
  • 常见的实体首部有 Content-Length 实体主体的大小、Expires 实体主体的过期工夫、Last-Modified 资源的最初批改工夫。

14.URI 和 URL 有什么区别?

• URI，对立资源标识符(Uniform Resource Identifier，URI)，标识的是 Web 上每一种可用的资源，如 HTML 文档、图像、视频片段、程序等都是由一个 URI 进行标识的。
• URL，对立资源定位符（Uniform Resource Location)，它是 URI 的一种子集，次要作用是提供资源的门路。

它们的次要区别在于，URL 除了提供了资源的标识，还提供了资源拜访的形式。这么比喻，URI 像是身份证，能够惟一标识一个人，而 URL 更像一个住址，能够通过 URL 找到这个人——人类住址协定:// 地球 / 中国 / 北京市 / 海淀区 /xx 职业技术学院 /14 号宿舍楼 /525 号寝 / 张三. 男。

15. 说下 HTTP/1.0，1.1，2.0 的区别？

要害须要记住 HTTP/1.0 默认是短连贯，能够强制开启，HTTP/1.1 默认长连贯，HTTP/2.0 采纳 多路复用。

HTTP/1.0

• 默认应用 短连贯，每次申请都须要建设一个 TCP 连贯。它能够设置Connection: keep-alive 这个字段，强制开启长连贯。

HTTP/1.1

• 引入了长久连贯，即 TCP 连贯默认不敞开，能够被多个申请复用。
• 分块传输编码，即服务端每产生一块数据，就发送一块，用”流模式”取代”缓存模式”。
• 管道机制，即在同一个 TCP 连贯外面，客户端能够同时发送多个申请。

HTTP/2.0

• 二进制协定，1.1 版本的头信息是文本（ASCII 编码），数据体能够是文本或者二进制；2.0 中，头信息和数据体都是二进制。
• 齐全多路复用，在一个连贯里，客户端和浏览器都能够同时发送多个申请或回应，而且不必依照程序一一对应。
• 报头压缩，HTTP 协定不带有状态，每次申请都必须附上所有信息。Http/2.0 引入了头信息压缩机制，应用 gzip 或 compress 压缩后再发送。
• 服务端推送，容许服务器未经请求，被动向客户端发送资源。

16.HTTP/ 3 理解吗？

HTTP/ 3 次要有两大变动，传输层基于 UDP、应用QUIC 保障 UDP 可靠性。

HTTP/ 2 存在的一些问题，比方重传等等，都是因为 TCP 自身的个性导致的，所以 HTTP/ 3 在 QUIC 的根底上进行倒退而来，QUIC（Quick UDP Connections）直译为疾速 UDP 网络连接，底层应用 UDP 进行数据传输。

HTTP/ 3 次要有这些特点：

• 应用 UDP 作为传输层进行通信
• 在 UDP 的根底上 QUIC 协定保障了 HTTP/ 3 的安全性，在传输的过程中就实现了 TLS 加密握手
• HTTPS 要建⽴⼀个连贯，要花费 6 次交互，先是建⽴三次握⼿，而后是 TLS/1.3 的三次握⼿。QUIC 间接把以往的 TCP 和 TLS/1.3 的 6 次交互合并成了 3 次，缩小了交互次数。
• QUIC 有⾃⼰的⼀套机制能够保障传输的可靠性的。当某个流发⽣丢包时，只会阻塞这个流，其余流不会受到影响。

咱们拿一张图看一下 HTTP 协定的变迁：

17.HTTP 如何实现长连贯？在什么时候会超时？

什么是 HTTP 的长连贯？

1. HTTP 分为长连贯和短连贯，实质上说的是 TCP 的长短连贯。TCP 连贯是一个双向的通道，它是能够放弃一段时间不敞开的，因而 TCP 连贯才具备真正的长连贯和短连贯这一说法。
2. TCP 长连贯能够复用一个 TCP 连贯，来发动屡次的 HTTP 申请，这样就能够缩小资源耗费，比方一次申请 HTML，如果是短连贯的话，可能还须要申请后续的 JS/CSS。

如何设置长连贯？

通过在头部（申请和响应头）设置 Connection 字段指定为keep-alive，HTTP/1.0 协定反对，然而是默认敞开的，从 HTTP/1.1 当前，连贯默认都是长连贯。

在什么时候会超时呢？

• HTTP 个别会有 httpd 守护过程，外面能够设置 keep-alive timeout，当 tcp 连贯闲置超过这个工夫就会敞开，也能够在 HTTP 的 header 外面设置超时工夫
• TCP 的 keep-alive 蕴含三个参数，反对在零碎内核的 net.ipv4 外面设置；当 TCP 连贯之后，闲置了 tcp_keepalive_time，则会产生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会抛弃该连贯。

1. tcp_keepalive_intvl = 15
2. tcp_keepalive_probes = 5
3. tcp_keepalive_time = 1800

18. 说说 HTTP 与 HTTPS 有哪些区别？

1. HTTP 是超⽂本传输协定，信息是明⽂传输，存在平安⻛险的问题。HTTPS 则解决 HTTP 不平安的缺点，在 TCP 和 HTTP ⽹络层之间加⼊了 SSL/TLS 平安协定，使得报⽂可能加密传输。
2. HTTP 连贯建⽴绝对简略，TCP 三次握⼿之后便可进⾏ HTTP 的报⽂传输。⽽ HTTPS 在 TCP 三次握⼿之后，还需进⾏ SSL/TLS 的握⼿过程，才可进⼊加密报⽂传输。
3. HTTP 的端⼝号是 80，HTTPS 的端⼝号是 443。
4. HTTPS 协定须要向 CA（证书权威机构）申请数字证书，来保障服务器的身份是可信的。

19. 为什么要用 HTTPS？解决了哪些问题？

因为 HTTP 是明⽂传输，存在平安上的危险：

窃听⻛险，⽐如通信链路上能够获取通信内容，用户账号被盗。

篡改⻛险，⽐如强制植⼊垃圾⼴告，视觉污染。

假冒⻛险，⽐如假冒淘宝⽹站，用户金钱损失。

所以引入了 HTTPS，HTTPS 在 HTTP 与 TCP 层之间加⼊了 SSL/TLS 协定，能够很好的解决了这些危险：

• 信息加密：交互信息⽆法被窃取。
• 校验机制：⽆法篡改通信内容，篡改了就不能失常显示。
• 身份证书：能证实淘宝是真淘宝。

所以 SSL/TLS 协定是能保障通信是平安的。

20.HTTPS 工作流程是怎么的？

这道题有几个要点：公私钥、数字证书、加密、对称加密、非对称加密。

HTTPS 次要工作流程：

1. 客户端发动 HTTPS 申请，连贯到服务端的 443 端口。
2. 服务端有一套数字证书（证书内容有公钥、证书颁发机构、生效日期等）。
3. 服务端将本人的数字证书发送给客户端（公钥在证书外面，私钥由服务器持有）。
4. 客户端收到数字证书之后，会验证证书的合法性。如果证书验证通过，就会生成一个随机的对称密钥，用证书的公钥加密。
5. 客户端将公钥加密后的密钥发送到服务器。
6. 服务器接管到客户端发来的密文密钥之后，用本人之前保留的私钥对其进行非对称解密，解密之后就失去客户端的密钥，而后用客户端密钥对返回数据进行对称加密，酱紫传输的数据都是密文啦。
7. 服务器将加密后的密文返回到客户端。
8. 客户端收到后，用本人的密钥对其进行对称解密，失去服务器返回的数据。

这里还画了一张更详尽的图：

21. 客户端怎么去校验证书的合法性？

首先，服务端的证书从哪来的呢？

为了让服务端的公钥被⼤家信赖，服务端的证书都是由 CA（Certificate Authority，证书认证机构）签名的，CA 就是⽹络世界⾥的公安局、公证中⼼，具备极⾼的可信度，所以由它来给各个公钥签名，信赖的⼀⽅签发的证书，那必然证书也是被信赖的。

![证书签名和客户端校验 - 起源参考[2]](https://gitee.com/sanfene/pic…)

CA 签发证书的过程，如上图右边局部：

• ⾸先 CA 会把持有者的公钥、⽤途、颁发者、无效工夫等信息打成⼀个包，而后对这些信息进⾏ Hash 计算，失去⼀个 Hash 值；
• 而后 CA 会使⽤⾃⼰的私钥将该 Hash 值加密，⽣成 Certificate Signature，也就是 CA 对证书做了签名；
• 最初将 Certificate Signature 增加在⽂件证书上，造成数字证书；

客户端校验服务端的数字证书的过程，如上图左边局部：

• ⾸先客户端会使⽤同样的 Hash 算法获取该证书的 Hash 值 H1；
• 通常浏览器和操作系统中集成了 CA 的公钥信息，浏览器收到证书后能够使⽤ CA 的公钥解密 Certificate
• Signature 内容，失去⼀个 Hash 值 H2；
• 最初⽐较 H1 和 H2，如果值雷同，则为可信赖的证书，否则则认为证书不可信。

如果在 HTTPS 的通信过程中，中间人篡改了证书原文，因为他没有 CA 机构的私钥，所以 CA 公钥解密的内容就不统一。

22. 如何了解 HTTP 协定是无状态的？

这个 无状态 的的 状态 值的是什么？是客户端的状态，所以字面意思，就是 HTTP 协定中服务端不会保留客户端的任何信息。

比方当浏览器第一次发送申请给服务器时，服务器响应了；如果同个浏览器发动第二次申请给服务器时，它还是会响应，然而呢，服务器不晓得你就是方才的那个浏览器。

那有什么方法记录状态呢？

次要有两个方法，Session 和 Cookie。

23. 说说 Session 和 Cookie 有什么分割和区别?

先来看看什么是 Session 和 Cookie：

• Cookie 是保留在客户端的一小块文本串的数据。客户端向服务器发动申请时，服务端会向客户端发送一个 Cookie，客户端就把 Cookie 保存起来。在客户端下次向同一服务器再发动申请时，Cookie 被携带发送到服务器。服务端能够依据这个 Cookie 判断用户的身份和状态。
• Session 指的就是服务器和客户端一次会话的过程。它是另一种记录客户状态的机制。不同的是 cookie 保留在客户端浏览器中，而 session 保留在服务器上。客户端浏览器拜访服务器的时候，服务器把客户端信息以某种模式记录在服务器上，这就是 session。客户端浏览器再次拜访时只须要从该 session 中查找用户的状态。

Session 和 Cookie 到底有什么不同呢？

• 存储地位不一样，Cookie 保留在客户端，Session 保留在服务器端。
• 存储数据类型不一样，Cookie 只能保留 ASCII，Session 能够存任意数据类型，个别状况下咱们能够在 Session 中放弃一些罕用变量信息，比如说 UserId 等。
• 有效期不同，Cookie 可设置为长时间放弃，比方咱们常常应用的默认登录性能，Session 个别无效工夫较短，客户端敞开或者 Session 超时都会生效。
• 隐衷策略不同，Cookie 存储在客户端，比拟容易受到不法获取，晚期有人将用户的登录名和明码存储在 Cookie 中导致信息被窃取；Session 存储在服务端，安全性绝对 Cookie 要好一些。
• 存储大小不同，单个 Cookie 保留的数据不能超过 4K，Session 可存储数据远高于 Cookie。

Session 和 Cookie 有什么关联呢？

能够应用 Cookie 记录 Session 的标识。

• 用户第一次申请服务器时，服务器依据用户提交的信息，创立对应的 Session，申请返回时将此 Session 的惟一标识信息 SessionID 返回给浏览器，浏览器接管到服务器返回的 SessionID 信息后，会将此信息存入 Cookie 中，同时 Cookie 记录此 SessionID 是属于哪个域名。
• 当用户第二次拜访服务器时，申请会主动判断此域名下是否存在 Cookie 信息，如果存在，则主动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再依据 SessionID 查找对应的 Session 信息，如果没有找到，阐明用户没有登录或者登录生效，如果找到 Session 证实用户曾经登录可执行前面操作。

分布式环境下 Session 怎么解决呢？

分布式环境下，客户端申请通过负载平衡，可能会调配到不同的服务器上，如果一个用户的申请两次没有落到同一台服务器上，那么在新的服务器上就没有记录用户状态的 Session。

这时候怎么办呢？

能够应用 Redis 等分布式缓存来存储 Session，在多台服务器之间共享。

客户端无奈应用 Cookie 怎么办？

有可能客户端无奈应用 Cookie，比方浏览器禁用 Cookie，或者客户端是安卓、IOS 等等。

这时候怎么办？SessionID 怎么存？怎么传给服务端呢？

首先是 SessionID 的存储，能够应用客户端的本地存储，比方浏览器的 sessionStorage。

接下来怎么传呢？

• 拼接到 URL 里：间接把 SessionID 作为 URL 的申请参数
• 放到申请头里：把 SessionID 放到申请的 Header 里，比拟罕用。

TCP

24. 具体说一下 TCP 的三次握手机制

PS:TCP 三次握手是最重要的知识点，肯定要相熟到问到即送分。

TCP 提供面向连贯的服务，在传送数据前必须建设连贯，TCP 连贯是通过三次握手建设的。

三次握手的过程：

• 最开始，客户端和服务端都处于 CLOSE 状态，服务端监听客户端的申请，进入 LISTEN 状态
• 客户端端发送连贯申请，第一次握手 (SYN=1, seq=x)，发送结束后，客户端就进入 SYN_SENT 状态
• 服务端确认连贯，第二次握手 (SYN=1, ACK=1, seq=y, ACKnum=x+1)，发送结束后，服务器端就进入 SYN_RCV 状态。
• 客户端收到服务端的确认之后，再次向服务端确认，这就是 第三次握手 (ACK=1，ACKnum=y+1)，发送结束后，客户端进入 ESTABLISHED 状态，当服务器端接管到这个包时，也进入 ESTABLISHED 状态。

TCP 三次握手艰深比喻：

在二十年前的农村，电话没有遍及，手机就更不用说了，所以，通信根本靠吼。

老张和老王是街坊，这天老张下地了，后果家里有事，热心的街坊老王连忙跑到村口，开始叫唤老王。

• 老王：老张唉！我是老王，你能听到吗？
• 老张一听，是老王的声音：老王老王，我是老张，我能听到，你能听到吗？

• 老王一听，嗯，没错，是老张：老张，我听到了，我有事要跟你说。

  “ 你老婆要生了，连忙回家吧！”

老张风风火火地赶回家，老婆顺利地生了个带把的大胖小子。握手的故事充斥了幸福和美满。

25.TCP 握手为什么是三次，为什么不能是两次？不能是四次？

为什么不能是两次？

• 为了避免服务器端开启一些无用的连贯减少服务器开销
• 避免已生效的连贯申请报文段忽然又传送到了服务端，因此产生谬误。

因为网络传输是有延时的(要通过网络光纤和各种两头代理服务器)，在传输的过程中，比方客户端发动了 SYN=1 的第一次握手。

如果服务器端就间接创立了这个连贯并返回蕴含 SYN、ACK 和 Seq 等内容的数据包给客户端，这个数据包因为网络传输的起因失落了，失落之后客户端就始终没有接管到服务器返回的数据包。

如果没有第三次握手通知服务器端客户端收的到服务器端传输的数据的话，服务器端是不晓得客户端有没有接管到服务器端返回的信息的。

服务端就认为这个连贯是可用的，端口就始终开着，等到客户端因超时从新发出请求时，服务器就会从新开启一个端口连贯。这样一来，就会有很多有效的连贯端口白白地开着，导致资源的节约。

还有一种状况是曾经生效的客户端收回的申请信息，因为某种原因传输到了服务器端，服务器端认为是客户端收回的无效申请，接管后产生谬误。

所以咱们须要“第三次握手”来确认这个过程：

通过第三次握手的数据通知服务端，客户端有没有收到服务器“第二次握手”时传过来的数据，以及这个连贯的序号是不是无效的。若发送的这个数据是“收到且没有问题”的信息，接管后服务器就失常建设 TCP 连贯，否则建设 TCP 连贯失败，服务器敞开连贯端口。由此缩小服务器开销和接管到生效申请产生的谬误。

为什么不是四次？

简略说，就是三次挥手曾经足够创立牢靠的连贯，没有必要再多一次握手导致破费更多的工夫建设连贯。

26. 三次握手中每一次没收到报文会产生什么状况？

• 第一次握手服务端未收到 SYN 报文

  服务端不会进行任何的动作，而客户端因为一段时间内没有收到服务端发来的确认报文，期待一段时间后会从新发送 SYN 报文，如果依然没有回应，会反复这个过程，直到发送次数超过最大重传次数限度，就会返回连贯建设失败。

• 第二次握手客户端未收到服务端响应的 ACK 报文

  客户端会持续重传，直到次数限度；而服务端此时会阻塞在 accept()处，期待客户端发送 ACK 报文

• 第三次握手服务端为收到客户端发送过去的 ACK 报文

  服务端同样会采纳相似客户端的超时重传机制，如果重试次数超过限度，则 accept()调用返回 -1，服务端建设连贯失败；而此时客户端认为本人曾经建设连贯胜利，因而开始向服务端发送数据，然而服务端的 accept()零碎调用曾经返回，此时不在监听状态，因而服务端接管到客户端发送来的数据时会发送 RST 报文给客户端，打消客户端单方面建设连贯的状态。

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

ACK 是为了通知客户端传来的数据曾经接管无误。

而传回 SYN 是为了通知客户端，服务端响应的的确是客户端发送的报文。

28. 第 3 次握手能够携带数据吗？

第 3 次握手是能够携带数据的。

此时客户端曾经处于 ESTABLISHED 状态。对于客户端来说，它曾经建设连贯胜利，并且确认服务端的接管和发送能力是失常的。

第一次握手不能携带数据是出于平安的思考，因为如果容许携带数据，攻击者每次在 SYN 报文中携带大量数据，就会导致服务端耗费更多的工夫和空间去解决这些报文，会造成 CPU 和内存的耗费。

29. 说说半连贯队列和 SYN Flood 攻打的关系？

什么是半连贯队列？

TCP 进入三次握手前，服务端会从 CLOSED 状态变为 LISTEN 状态, 同时在外部创立了两个队列：半连贯队列（SYN 队列）和全连贯队列（ACCEPT 队列）。

顾名思义，半连贯队列寄存的是三次握手未实现的连贯，全连贯队列寄存的是实现三次握手的连贯。

• TCP 三次握手时，客户端发送 SYN 到服务端，服务端收到之后，便回复 ACK 和 SYN，状态由 LISTEN 变为 SYN_RCVD，此时这个连贯就被推入了 SYN 队列，即半连贯队列。
• 当客户端回复 ACK, 服务端接管后，三次握手就实现了。这时连贯会期待被具体的利用取走，在被取走之前，它被推入 ACCEPT 队列，即全连贯队列。

什么是 SYN Flood？

SYN Flood 是一种典型的 DDos 攻打，它在短时间内，伪造 不存在的 IP 地址, 向服务器发送大量 SYN 报文。当服务器回复 SYN+ACK 报文后，不会收到 ACK 回应报文，那么 SYN 队列里的连贯旧不会出对队，久⽽久之就会占满服务端的 SYN 接管队列（半连贯队列），使得服务器不能为失常⽤户服务。

那有什么应答计划呢？

次要有 syn cookie 和 SYN Proxy 防火墙 等。

• syn cookie：在收到 SYN 包后，服务器依据肯定的办法，以数据包的源地址、端口等信息为参数计算出一个 cookie 值作为本人的 SYNACK 包的序列号，回复 SYN+ACK 后，服务器并不立刻分配资源进行解决，等收到发送方的 ACK 包后，从新依据数据包的源地址、端口计算该包中的确认序列号是否正确，如果正确则建设连贯，否则抛弃该包。
• SYN Proxy 防火墙：服务器防火墙会对收到的每一个 SYN 报文进行代理和回应，并放弃半连贯。等发送方将 ACK 包返回后，再从新结构 SYN 包发到服务器，建设真正的 TCP 连贯。

30. 说说 TCP 四次挥手的过程？

PS：问完三次握手，经常也会顺道问问四次挥手，所以也是必须把握知识点。

TCP 四次挥手过程：

• 数据传输完结之后，通信单方都能够被动发动断开连接申请，这里假设客户端发动
• 客户端发送开释连贯报文，第一次挥手 (FIN=1，seq=u)，发送结束后，客户端进入 FIN_WAIT_1 状态。
• 服务端发送确认报文，第二次挥手 (ACK=1，ack=u+1,seq =v)，发送结束后，服务器端进入 CLOSE_WAIT 状态，客户端接管到这个确认包之后，进入 FIN_WAIT_2 状态。
• 服务端发送开释连贯报文，第三次挥手 (FIN=1，ACK1,seq=w,ack=u+1)，发送结束后，服务器端进入 LAST_ACK 状态，期待来自客户端的最初一个 ACK。
• 客户端发送确认报文，第四次挥手 (ACK=1，seq=u+1,ack=w+1)，客户端接管到来自服务器端的敞开申请，发送一个确认包，并进入 TIME_WAIT 状态， 期待了某个固定工夫（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK，认为服务器端曾经失常敞开连贯，于是本人也敞开连贯，进入 CLOSED 状态。服务器端接管到这个确认包之后，敞开连贯，进入 CLOSED 状态。

大白话说四次挥手：

如果独身狗博主有一个女朋友—因为博主下班九九六，上班肝博客，导致没有工夫陪女朋友，女朋友忍气吞声。

• 女朋友：狗男人，最近你都不理我，你是不是不爱我了？你是不是里面有别的狗子了？我要和你离别？
• 沙雕博主一愣，怒火攻心：离别就离别，不陪你闹了，等我把货色拾掇拾掇。

沙雕博主小心翼翼地装起了本人的青轴机械键盘。

• 哼，蠢女人，我曾经拾掇完了，我先滚为敬，再见！
• 女朋友：滚，滚的远远的，越远越好，我一辈子都不想再见到你。

挥手的故事总充斥了悲伤和遗憾！

31.TCP 挥手为什么须要四次呢？

再来回顾下四次挥手单方发 FIN 包的过程，就能了解为什么须要四次了。

• 敞开连贯时，客户端向服务端发送 FIN 时，仅仅示意客户端不再发送数据了然而还能接收数据。
• 服务端收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据须要解决和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意当初敞开连贯。

从下面过程可知，服务端通常须要期待实现数据的发送和解决，所以服务端的 ACK 和 FIN 个别都会离开发送，从而比三次握手导致多了一次。

32.TCP 四次挥手过程中，为什么须要期待 2MSL, 才进入 CLOSED 敞开状态？

为什么须要期待？

1. 为了保障客户端发送的最初一个 ACK 报文段可能达到服务端。 这个 ACK 报文段有可能失落，因此使处在 LAST-ACK 状态的服务端就收不到对已发送的 FIN + ACK 报文段的确认。服务端会超时重传这个 FIN+ACK 报文段，而客户端就能在 2MSL 工夫内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着客户端重传一次确认，重新启动 2MSL 计时器。最初，客户端和服务器都失常进入到 CLOSED 状态。

2. 避免已生效的连贯申请报文段呈现在本连贯中。客户端在发送完最初一个 ACK 报文段后，再通过工夫 2MSL，就能够使本连贯继续的工夫内所产生的所有报文段都从网络中隐没。这样就能够使下一个连贯中不会呈现这种旧的连贯申请报文段。

为什么期待的工夫是 2MSL？

MSL 是 Maximum Segment Lifetime，报⽂最⼤⽣存工夫，它是任何报⽂在⽹络上存在的最⻓工夫，超过这个工夫报⽂将被抛弃。

TIME_WAIT 期待 2 倍的 MSL，⽐较正当的解释是：⽹络中可能存在来⾃发送⽅的数据包，当这些发送⽅的数据包被接管⽅解决后⼜会向对⽅发送响应，所以⼀来⼀回须要期待 2 倍的工夫。

⽐如如果被动敞开⽅没有收到断开连接的最初的 ACK 报⽂，就会触发超时重发 Fin 报⽂，另⼀⽅接管到 FIN 后，会重发 ACK 给被动敞开⽅，⼀来⼀去正好 2 个 MSL。

33. 保活计时器有什么用？

除工夫期待计时器外，TCP 还有一个保活计时器（keepalive timer）。

构想这样的场景：客户已被动与服务器建设了 TCP 连贯。但起初客户端的主机忽然产生故障。显然，服务器当前就不能再收到客户端发来的数据。因而，该当有措施使服务器不要再白白期待上来。这就须要应用保活计时器了。

服务器每收到一次客户端的数据，就从新设置保活计时器，工夫的设置通常是两个小时。若两个小时都没有收到客户端的数据，服务端就发送一个探测报文段，当前则每隔 75 秒钟发送一次。若间断发送 10 个探测报文段后依然无客户端的响应，服务端就认为客户端出了故障，接着就敞开这个连贯。

34.CLOSE-WAIT 和 TIME-WAIT 的状态和意义？

CLOSE-WAIT 状态有什么意义？

服务端收到客户端敞开连贯的申请并确认之后，就会进入 CLOSE-WAIT 状态。此时服务端可能还有一些数据没有传输实现，因而不能立刻敞开连贯，而 CLOSE-WAIT 状态就是为了保障服务端在敞开连贯之前将待发送的数据处理完。

TIME-WAIT 有什么意义？

TIME-WAIT 状态产生在第四次挥手，当客户端向服务端发送 ACK 确认报文后进入 TIME-WAIT 状态。

它存在的意义次要是两个：

• 防⽌旧连贯的数据包

  如果客户端收到服务端的 FIN 报文之后立刻敞开连贯，然而此时服务端对应的端口并没有敞开，如果客户端在雷同端口建设新的连贯，可能会导致新连贯收到旧连贯残留的数据包，导致不可意料的异样产生。

• 保障连贯正确敞开

  假如客户端最初一次发送的 ACK 包在传输的时候失落了，因为 TCP 协定的超时重传机制，服务端将重发 FIN 报文，如果客户端没有维持 TIME-WAIT 状态而间接敞开的话，当收到服务端从新发送的 FIN 包时，客户端就会应用 RST 包来响应服务端，导致服务端认为有谬误产生，然而理论敞开连贯过程是失常的。

35.TIME_WAIT 状态过多会导致什么问题？怎么解决？

TIME_WAIT 状态过多会导致什么问题?

如果服务器有处于 TIME-WAIT 状态的 TCP，则阐明是由服务器⽅被动发动的断开申请。

过多的 TIME-WAIT 状态次要的危害有两种：

第⼀是内存资源占⽤；

第⼆是对端⼝资源的占⽤，⼀个 TCP 连贯⾄少耗费⼀个本地端⼝；

怎么解决 TIME_WAIT 状态过多？

• 服务器能够设置 SO_REUSEADDR 套接字来告诉内核，如果端口被占用，然而 TCP 连贯位于 TIME_WAIT 状态时能够重用端口。
• 还能够应用长连贯的形式来缩小 TCP 的连贯和断开，在长连贯的业务里往往不须要思考 TIME_WAIT 状态。

36. 说说 TCP 报文首部的格局？

看一下 TCP 报文首部的格局：

• 16 位端口号：源端口号，主机该报文段是来自哪里；指标端口号，要传给哪个下层协定或应用程序
• 32 位序号：一次 TCP 通信（从 TCP 连贯建设到断开）过程中某一个传输方向上的字节流的每个字节的编号。
• 32 位确认号：用作对另一方发送的 tcp 报文段的响应。其值是收到的 TCP 报文段的序号值加 1。
• 4 位首部长度：示意 tcp 头部有多少个 32bit 字（4 字节）。因为 4 位最大能标识 15，所以 TCP 头部最长是 60 字节。
• 6 位标记位：URG(紧急指针是否无效)，ACk（示意确认号是否无效），PST（缓冲区尚未填满），RST（示意要求对方从新建设连贯），SYN（建设连贯音讯标记接），FIN（示意告知对方本端要敞开连贯了）
• 16 位窗口大小：是 TCP 流量管制的一个伎俩。这里说的窗口，指的是接管通告窗口。它通知对方本端的 TCP 接收缓冲区还能包容多少字节的数据，这样对方就能够管制发送数据的速度。
• 16 位校验和：由发送端填充，接收端对 TCP 报文段执行 CRC 算法以测验 TCP 报文段在传输过程中是否损坏。留神，这个校验不仅包含 TCP 头部，也包含数据局部。这也是 TCP 牢靠传输的一个重要保障。
• 16 位紧急指针：一个正的偏移量。它和序号字段的值相加示意最初一个紧急数据的下一字节的序号。因而，确切地说，这个字段是紧急指针绝对以后序号的偏移，无妨称之为紧急偏移。TCP 的紧急指针是发送端向接收端发送紧急数据的办法。

37.TCP 是如何保障可靠性的？

TCP 次要提供了测验和、序列号 / 确认应答、超时重传、最大音讯长度、滑动窗口管制等办法实现了可靠性传输。

1. 连贯治理：TCP 应用三次握手和四次挥手保障牢靠地建设连贯和开释连贯，这里就不必多说了。
2. 校验和：TCP 将放弃它首部和数据的测验和。这是一个端到端的测验和，目标是检测数据在传输过程中的任何变动。如果接收端的测验和有过错，TCP 将抛弃这个报文段和不确认收到此报文段。

3. 序列号 / 确认应答：TCP 给发送的每一个包进行编号，接管方会对收到的包进行应答，发送方就会晓得接管方是否收到对应的包，如果发现没有收到，就会重发，这样就能保证数据的完整性。就像老师上课，会问一句，这一章听懂了吗？没听懂再讲一遍。

4. 流量管制：TCP 连贯的每一方都有固定大小的缓冲空间，TCP 的接收端只容许发送端发送接收端缓冲区能接收的数据。当接管方来不及解决发送方的数据，能提醒发送方升高发送的速率，避免包失落。TCP 应用的流量控制协议是可变大小的滑动窗口协定。（TCP 利用滑动窗口实现流量管制）

5. 最大音讯长度：在建设 TCP 连贯的时候，单方约定一个最大的长度（MSS）作为发送的单位，重传的时候也是以这个单位来进行重传。现实的状况下是该长度的数据刚好不被网络层分块。

6. 超时重传：超时重传是指发送进来的数据包到接管到确认包之间的工夫，如果超过了这个工夫会被认为是丢包了，须要重传。

7. 拥塞管制：如果网络十分拥挤，此时再发送数据就会减轻网络累赘，那么发送的数据段很可能超过了最大生存工夫也没有达到接管方，就会产生丢包问题。为此 TCP 引入慢启动机制，先收回大量数据，就像探路一样，先摸清以后的网络拥挤状态后，再决定依照多大的速度传送数据。

38. 说说 TCP 的流量管制？

TCP 提供了一种机制，能够让发送端依据接收端的理论接管能力管制发送的数据量，这就是 流量管制。

TCP 通过 滑动窗口 来管制流量，咱们看下简要流程：

• 首先单方三次握手，初始化各自的窗口大小，均为 400 个字节。

• 如果以后发送方给接管方发送了 200 个字节，那么，发送方的 SND.NXT 会右移 200 个字节，也就是说以后的可用窗口缩小了 200 个字节。
• 接受方收到后，放到缓冲队列外面，REV.WND =400-200=200 字节，所以 win=200 字节返回给发送方。接管方会在 ACK 的报文首部带上放大后的滑动窗口 200 字节
• 发送方又发送 200 字节过去，200 字节达到，持续放到缓冲队列。不过这时候，因为大量负载的起因，接受方解决不了这么多字节，只能解决 100 字节，残余的 100 字节持续放到缓冲队列。这时候，REV.WND = 400-200-100=100 字节，即 win=100 返回发送方。
• 发送方持续发送 100 字节过去，这时候，接管窗口 win 变为 0。
• 发送方进行发送，开启一个定时工作，每隔一段时间，就去询问接受方，直到 win 大于 0，才持续开始发送。

39. 具体说说 TCP 的滑动窗口？

TCP 发送一个数据，如果须要收到确认应答，才会发送下一个数据。这样的话就会有个毛病：效率会比拟低。

“用一个比喻，咱们在微信上聊天，你打完一句话，我回复一句之后，你能力打下一句。如果我没有及时回复呢？你是把话憋着不说吗？而后傻傻等到我回复之后再接着发下一句？”

为了解决这个问题，TCP 引入了 窗口，它是操作系统开拓的一个缓存空间。窗口大小值示意无需期待确认应答，而能够持续发送数据的最大值。

TCP 头部有个字段叫 win，也即那个 16 位的窗口大小 ，它通知对方本端的 TCP 接收缓冲区还能包容多少字节的数据，这样对方就能够管制发送数据的速度，从而达到 流量管制 的目标。

“艰深点讲，就是接受方每次收到数据包，在发送确认报文的时候，同时通知发送方，本人的缓存区还有多少空余空间，缓冲区的空余空间，咱们就称之为承受窗口大小。这就是 win。”

TCP 滑动窗口分为两种: 发送窗口和接管窗口。发送端的滑动窗口 蕴含四大局部，如下：

• 已发送且已收到 ACK 确认
• 已发送但未收到 ACK 确认
• 未发送但能够发送
• 未发送也不能够发送

• 深蓝色框里就是发送窗口。
• SND.WND: 示意发送窗口的大小, 上图虚线框的格子数是 10 个，即发送窗口大小是 10。
• SND.NXT：下一个发送的地位，它指向未发送但能够发送的第一个字节的序列号。
• SND.UNA: 一个相对指针，它指向的是已发送但未确认的第一个字节的序列号。

接管方的滑动窗口蕴含三大部分，如下：

• 已胜利接管并确认
• 未收到数据但能够接管
• 未收到数据并不能够接管的数据

• 蓝色框内，就是接管窗口。
• REV.WND: 示意接管窗口的大小, 上图虚线框的格子就是 9 个。
• REV.NXT: 下一个接管的地位，它指向未收到但能够接管的第一个字节的序列号。

40. 理解 Nagle 算法和提早确认吗？

Nagle 算法和提早确认是干什么的？

当咱们 TCP 报⽂的承载的数据⾮常⼩的时候，例如⼏个字节，那么整个⽹络的效率是很低的，因为每个 TCP 报⽂中都会有 20 个字节的 TCP 头部，也会有 20 个字节的 IP 头部，⽽数据只有⼏个字节，所以在整个报⽂中无效数据占有的比例就会⾮常低。

这就如同快递员开着⼤货⻋送⼀个⼩包裹⼀样节约。

那么就呈现了常⻅的两种策略，来缩小⼩报⽂的传输，别离是：

• Nagle 算法
• 提早确认

Nagle 算法

Nagle 算法：任意时刻，最多只能有一个未被确认的小段。所谓“小段”，指的是小于 MSS 尺寸的数据块，所谓“未被确认”，是指一个数据块发送进来后，没有收到对方发送的 ACK 确认该数据已收到。

Nagle 算法的策略：

• 没有已发送未确认报⽂时，⽴刻发送数据。
• 存在未确认报⽂时，直到「没有已发送未确认报⽂」或「数据⻓度达到 MSS ⼤⼩」时，再发送数据。

只有没满⾜上⾯条件中的⼀条，发送⽅⼀直在囤积数据，直到满⾜上⾯的发送条件。

提早确认

事实上当没有携带数据的 ACK，它的⽹络效率也是很低的，因为它也有 40 个字节的 IP 头 和 TCP 头，但却没有携带数据报⽂。

为了解决 ACK 传输效率低问题，所以就衍⽣出了 TCP 提早确认。

TCP 提早确认的策略：

• 当有响应数据要发送时，ACK 会随着响应数据⼀起⽴刻发送给对⽅
• 当没有响应数据要发送时，ACK 将会提早⼀段时间，以期待是否有响应数据能够⼀起发送
• 如果在提早期待发送 ACK 期间，对⽅的第⼆个数据报⽂⼜达到了，这时就会⽴刻发送 ACK

个别状况下，Nagle 算法和提早确认 不能一起应用，Nagle 算法意味着提早发，提早确认 意味着提早接管，两个凑在一起就会造成更大的提早，会产生性能问题。

41. 说说 TCP 的拥塞管制？

什么是拥塞管制？不是有了流量管制吗？

前⾯的流量管制是防止发送⽅的数据填满接管⽅的缓存，然而并不知道整个⽹络之中发⽣了什么。

⼀般来说，计算机⽹络都处在⼀个共享的环境。因而也有可能会因为其余主机之间的通信使得⽹络拥挤。

在⽹络呈现拥挤时，如果持续发送⼤量数据包，可能会导致数据包时延、失落等，这时 TCP 就会重传数据，然而⼀重传就会导致⽹络的累赘更重，于是会导致更⼤的提早以及更多的丢包，这个状况就会进⼊恶性循环被一直地放⼤ ….

所以，TCP 不能疏忽整个网络中发⽣的事，它被设计成⼀个⽆私的协定，当⽹络发送拥塞时，TCP 会⾃我就义，升高发送的数据流。

于是，就有了拥塞管制，管制的⽬的就是防止发送⽅的数据填满整个⽹络。

就像是一个水管，不能让太多的水（数据流）流入水管，如果超过水管的承受能力，水管会被撑爆（丢包）。

发送方保护一个 拥塞窗口 cwnd（congestion window） 的变量，调节所要发送数据的量。

什么是拥塞窗⼝？和发送窗⼝有什么关系呢？

拥塞窗⼝ cwnd是发送⽅保护的⼀个的状态变量，它会依据⽹络的拥塞水平动态变化的。

发送窗⼝ swnd 和接管窗⼝ rwnd 是约等于的关系，那么因为加⼊了拥塞窗⼝的概念后，此时发送窗⼝的值是 swnd = min(cwnd, rwnd)，也就是拥塞窗⼝和接管窗⼝中的最⼩值。

拥塞窗⼝ cwnd 变动的规定：

• 只有⽹络中没有呈现拥塞，cwnd 就会增⼤；
• 但⽹络中呈现了拥塞，cwnd 就缩小；

拥塞管制有哪些罕用算法？

拥塞管制次要有这几种罕用算法：

• 慢启动
• 拥塞防止
• 拥塞产生
• 疾速复原

慢启动算法

慢启动算法，缓缓启动。

它示意 TCP 建设连贯实现后，一开始不要发送大量的数据，而是先探测一下网络的拥塞水平。由小到大逐步减少拥塞窗口的大小，如果没有呈现丢包，每收到一个 ACK，就将拥塞窗口 cwnd 大小就加 1（单位是 MSS）。每轮次 发送窗口增加一倍，呈指数增长，如果呈现丢包，拥塞窗口就减半，进入拥塞防止阶段。

举个例子：

• 连贯建⽴实现后，⼀开始初始化 cwnd = 1，示意能够传⼀个 MSS ⼤⼩的数据。
• 当收到⼀个 ACK 确认应答后，cwnd 减少 1，于是⼀次可能发送 2 个
• 当收到 2 个的 ACK 确认应答后，cwnd 减少 2，于是就能够⽐之前多发 2 个，所以这⼀次可能发送 4 个
• 当这 4 个的 ACK 确认到来的时候，每个确认 cwnd 减少 1，4 个确认 cwnd 减少 4，于是就能够⽐之前多发 4 个，所以这⼀次可能发送 8 个。

发包的个数是指数性的增⻓。

为了避免 cwnd 增长过大引起网络拥塞，还需设置一个 慢启动阀值 ssthresh（slow start threshold）状态变量。当 cwnd 达到该阀值后，就如同水管被关小了水龙头一样，缩小拥塞状态。即当 cwnd >ssthresh 时，进入了 拥塞防止 算法。

拥塞防止算法

一般来说，慢启动阀值 ssthresh 是 65535 字节，cwnd达到 慢启动阀值 后

• 每收到一个 ACK 时，cwnd = cwnd + 1/cwnd
• 当每过一个 RTT 时，cwnd = cwnd + 1

显然这是一个线性回升的算法，防止过快导致网络拥塞问题。

接着下面慢启动的例子，假设 ssthresh 为 8：：

• 当 8 个 ACK 应答确认到来时，每个确认减少 1/8，8 个 ACK 确认 cwnd ⼀共减少 1，于是这⼀次可能发送 9 个 MSS ⼤⼩的数据，变成了线性增⻓。

拥塞产生

当网络拥塞产生 丢包 时，会有两种状况：

• RTO 超时重传
• 疾速重传

如果是产生了 RTO 超时重传，就会应用拥塞产生算法

• 慢启动阀值 sshthresh =  cwnd /2
• cwnd 重置为 1
• 进入新的慢启动过程

这种形式就像是飙车的时候急刹车，还飞速倒车，这。。。

其实还有更好的解决形式，就是 疾速重传 。发送方收到 3 个间断反复的 ACK 时，就会疾速地重传，不用期待 RTO 超时 再重传。

发⽣疾速重传的拥塞发⽣算法：

• 拥塞窗口大小 cwnd = cwnd/2
• 慢启动阀值 ssthresh = cwnd
• 进入疾速复原算法

疾速复原

疾速重传和疾速复原算法个别同时应用。疾速复原算法认为，还有 3 个反复 ACK 收到，阐明网络也没那么蹩脚，所以没有必要像 RTO 超时那么强烈。

正如后面所说，进入疾速复原之前，cwnd 和 sshthresh 已被更新：

• cwnd = cwnd /2

– sshthresh = cwnd

而后，进⼊疾速复原算法如下：

• cwnd = sshthresh  + 3
• 重传反复的那几个 ACK（即失落的那几个数据包）
• 如果再收到反复的 ACK，那么 cwnd = cwnd +1
• 如果收到新数据的 ACK 后, cwnd = sshthresh。因为收到新数据的 ACK，表明复原过程曾经完结，能够再次进入了拥塞防止的算法了。

42. 说说 TCP 的重传机制？

重传包含 超时重传、疾速重传、带抉择确认的重传（SACK）、反复 SACK 四种。

超时重传

超时重传，是 TCP 协定保证数据可靠性的另一个重要机制，其原理是在发送某一个数据当前就开启一个计时器，在肯定工夫内如果没有失去发送的数据报的 ACK 报文，那么就从新发送数据，直到发送胜利为止。

超时工夫应该设置为多少呢？

先来看下什么叫 RTT（Round-Trip Time，往返工夫）。

RTT 就是数据齐全发送完，到收到确认信号的工夫，即数据包的一次往返工夫。

超时重传工夫，就是 RTO（Retransmission Timeout)。那么，RTO 到底设置多大呢？

• 如果 RTO 设置很大，等了很久都没重发，这样必定就不行。
• 如果 RTO 设置很小，那很可能数据都没有失落，就开始重发了，这会导致网络阻塞，从而恶性循环，导致更多的超时呈现。

一般来说，RTO 稍微大于 RTT，成果是最佳的。

其实，RTO 有个规范办法的计算公式，也叫 Jacobson / Karels 算法。

1. 首先计算 SRTT（即计算平滑的 RTT）

SRTT = (1 - α) * SRTT + α * RTT  // 求 SRTT 的加权均匀

2. 其次，计算 RTTVAR (round-trip time variation)

RTTVAR = (1 - β) * RTTVAR + β * (|RTT - SRTT|) // 计算 SRTT 与实在值的差距

3. 最初，得出最终的 RTO

RTO = µ * SRTT + ∂ * RTTVAR  =  SRTT + 4·RTTVAR  

在 Linux 下，α = 0.125，β = 0.25，μ = 1，∂ = 4。别问这些参数是怎么来的，它们是大量实际，调出的最优参数。

超时重传不是非常完满的重传计划，它有这些毛病：

• 当一个报文失落时，会期待肯定的超时周期，才重传分组，减少了端到端的时延。
• 当一个报文失落时，在其期待超时的过程中，可能会呈现这种状况：其后的报文段曾经被接收端接管但却迟迟得不到确认，发送端会认为也失落了，从而引起不必要的重传，既浪费资源也浪费时间。

并且，对于 TCP，如果产生一次超时重传，工夫距离下次就会加倍。

疾速重传

TCP 还有另外⼀种疾速重传（Fast Retransmit）机制，它不以工夫为驱动，⽽是以数据驱动重传。

它不以工夫驱动，而是以数据驱动。它是基于接收端的反馈信息来引发重传的。

能够用它来解决超时重发的工夫期待问题，疾速重传流程如下：

在上图，发送⽅收回了 1，2，3，4，5 份数据：

• 第⼀份 Seq1 先送到了，于是就 Ack 回 2；
• 后果 Seq2 因为某些起因没收到，Seq3 达到了，于是还是 Ack 回 2；
• 后⾯的 Seq4 和 Seq5 都到了，但还是 Ack 回 2，因为 Seq2 还是没有收到；
• 发送端收到了三个 Ack = 2 的确认，晓得了 Seq2 还没有收到，就会在定时器过期之前，重传失落的 Seq2。
• 最初，收到了 Seq2，此时因为 Seq3，Seq4，Seq5 都收到了，于是 Ack 回 6。

疾速重传机制只解决了⼀个问题，就是超时工夫的问题，然而它仍然⾯临着另外⼀个问题。就是重传的时候，是重传之前的⼀个，还是重传所有的问题。

⽐如对于上⾯的例⼦，是重传 Seq2 呢？还是重传 Seq2、Seq3、Seq4、Seq5 呢？因为发送端并不分明这间断的三个 Ack 2 是谁传回来的。

依据 TCP 不同的实现，以上两种状况都是有可能的。可⻅，这是⼀把双刃剑。

为了解决不晓得该重传哪些 TCP 报⽂，于是就有 SACK ⽅法。

带抉择确认的重传（SACK）

为了解决应该重传多少个包的问题? TCP 提供了 带抉择确认的重传（即 SACK，Selective Acknowledgment）。

SACK 机制 就是，在疾速重传的根底上，接管方返回最近收到报文段的序列号范畴，这样发送方就晓得接管方哪些数据包是没收到的。这样就很分明应该重传哪些数据包。

![SACK 机制 - 起源参考[3]](https://gitee.com/sanfene/pic…)

如上图中，发送⽅收到了三次同样的 ACK 确认报⽂，于是就会触发疾速重发机制，通过 SACK 信息发现只有 200~299 这段数据失落，则重发时，就只抉择了这个 TCP 段进⾏重发。

反复 SACK（D-SACK）

D-SACK，英文是 Duplicate SACK，是在 SACK 的根底上做了一些扩大，次要用来通知发送方，有哪些数据包，本人反复承受了。

DSACK 的目标是帮忙发送方判断，是否产生了包失序、ACK 失落、包反复或伪重传。让 TCP 能够更好的做网络流控。

例如 ACK 丢包导致的数据包反复：

![ACK 丢包 - 起源参考[3]](https://gitee.com/sanfene/pic…)

• 接管⽅发给发送⽅的两个 ACK 确认应答都失落了，所以发送⽅超时后，重传第⼀个数据包（3000 ~

3499）

• 于是接管⽅发现数据是反复收到的，于是回了⼀个 SACK = 3000~3500，通知「发送⽅」3000~3500 的数据早已被接管了，因为 ACK 都到了 4000 了，曾经意味着 4000 之前的所有数据都已收到，所以这个 SACK 就代表着 D-SACK。这样发送⽅就晓得了，数据没有丢，是接管⽅的 ACK 确认报⽂丢了。

43. 说说 TCP 的粘包和拆包？

TCP 的粘包和拆包更多的是业务上的概念！

什么是 TCP 粘包和拆包？

TCP 是面向流，没有界线的一串数据。TCP 底层并不理解下层业务数据的具体含意，它会依据 TCP 缓冲区的理论状况进行包的划分，所以在业务上认为，一 个残缺的包可能会被 TCP 拆分成多个包进行发送 ， 也有可能把多个小的包封装成一个大的数据包发送，这就是所谓的 TCP 粘包和拆包问题。

为什么会产生粘包和拆包呢?

• 要发送的数据小于 TCP 发送缓冲区的大小，TCP 将屡次写入缓冲区的数据一次发送进来，将会产生粘包；
• 接收数据端的应用层没有及时读取接收缓冲区中的数据，将产生粘包；
• 要发送的数据大于 TCP 发送缓冲区残余空间大小，将会产生拆包；
• 待发送数据大于 MSS（最大报文长度），TCP 在传输前将进行拆包。即 TCP 报文长度 – TCP 头部长度 > MSS。

那怎么解决呢？

• 发送端将每个数据包封装为固定长度
• 在数据尾部减少特殊字符进行宰割
• 将数据分为两局部，一部分是头部，一部分是内容体；其中头部构造大小固定，且有一个字段申明内容体的大小。

UDP

UDP 问的不多，基本上是被拿来和 TCP 比拟。

44. 说说 TCP 和 UDP 的区别？

最基本区别：TCP 是面向连贯，而 UDP 是无连贯。

能够这么形容：TCP 是打电话，UDP 是大喇叭。

说说 TCP 和 UDP 的利用场景？

• TCP 利用场景： 效率要求绝对低，但对准确性要求绝对高的场景。因为传输中须要对数据确认、重发、排序等操作，相比之下效率没有 UDP 高。例如：文件传输（精确高要求高、然而速度能够绝对慢）、收发邮件、近程登录。
• UDP 利用场景： 效率要求绝对高，对准确性要求绝对低的场景。例如：QQ 聊天、在线视频、网络语音电话（即时通讯，速度要求高，然而呈现偶然断续不是太大问题，并且此处齐全不能够应用重发机制）、播送通信（播送、多播）。

45. 为什么 QQ 采纳 UDP 协定？

PS：这是多年前的老题了，拉进去怀念旧。

• 首先，QQ 并不是齐全基于 UDP 实现。比方在应用 QQ 进行文件传输等流动的时候，就会应用 TCP 作为牢靠传输的保障。
• 应用 UDP 进行交互通信的益处在于，提早较短，对数据失落的解决比较简单。同时，TCP 是一个全双工协定，须要建设连贯，所以网络开销也会绝对大。
• 如果应用 QQ 语音和 QQ 视频的话，UDP 的劣势就更为突出了，首先提早较小。最重要的一点是不牢靠传输，这意味着如果数据失落的话，不会有重传。因为用户一般来说能够承受图像略微含糊一点，声音略微不清晰一点，然而如果在几秒钟当前再呈现之前失落的画面和声音，这恐怕是很难承受的。
• 因为 QQ 的服务器设计容量是海量级的利用，一台服务器要同时包容十几万的并发连贯，因而服务器端只有采纳 UDP 协定与客户端进行通信能力保障这种超大规模的服务

简略总结一下：UDP 协定是无连贯形式的协定，它的效率高，速度快，占资源少，对服务器的压力比拟小。然而其传输机制为不牢靠传送，必须依附辅助的算法来实现传输管制。QQ 采纳的通信协议以 UDP 为主，辅以 TCP 协定。

46.UDP 协定为什么不牢靠？

UDP 在传输数据之前不须要先建设连贯，远地主机的运输层在接管到 UDP 报文后，不须要确认，提供不牢靠交付。总结就以下四点：

• 不保障音讯交付：不确认，不重传，无超时
• 不保障交付程序：不设置包序号，不重排，不会产生队首阻塞
• 不跟踪连贯状态：不用建设连贯或重启状态机
• 不进行拥塞管制：不内置客户端或网络反馈机制

47.DNS 为什么要用 UDP?

更精确地说，DNS 既应用 TCP 又应用 UDP。

当进行区域传送（主域名服务器向辅助域名服务器传送变动的那局部数据）时会应用 TCP，因为数据同步传送的数据量比一个申请和应答的数据量要多，而 TCP 容许的报文长度更长，因而为了保证数据的正确性，会应用基于牢靠连贯的 TCP。

当客户端想 DNS 服务器查问域名（域名解析）的时候，个别返回的内容不会超过 UDP 报文的最大长度，即 512 字节，用 UDP 传输时，不须要创立连贯，从而大大提高了响应速度，但这要求域名解析服务器和域名服务器都必须本人解决超时和重传从而保障可靠性。

IP

48.IP 协定的定义和作用？

IP 协定是什么？

IP 协定（Internet Protocol）又被称为互联网协议，是反对网间互联的数据包协定，工作在 网际层，次要目标就是为了进步网络的可扩展性。

通过 网际协议 IP，能够把参加互联的，性能各异的网络 看作一个对立的网络。

和传输层 TCP 相比，IP 协定是一种无连贯 / 不牢靠、尽力而为的数据包传输服务，和 TCP 协定一起形成了 TCP/IP 协定的外围。

IP 协定有哪些作用？

IP 协定次要有以下几个作用：

• 寻址和路由：在 IP 数据报中携带源 IP 地址和目标 IP 地址来示意该数据包的源主机和指标主机。IP 数据报在传输过程中，每个两头节点（IP 网关、路由器）只依据网络地址来进行转发，如果两头节点是路由器，则路由器会依据路由表抉择适合的门路。IP 协定依据路由抉择协定提供的路由信息对 IP 数据报进行转发，直至指标主机。
• 分段和重组：IP 数据报在传输过程中可能会通过不同的网络，在不同的网络中数据报的最大长度限度是不同的，IP 协定通过给每个 IP 数据报调配一个标识符以及分段与组装的相干信息，使得数据报在不同的网络中可能被传输，被分段后的 IP 数据报能够独立地在网络中进行转发，在达到目标主机后由指标主机实现重组工作，复原出原来的 IP 数据报。

传输层协定和网络层协定有什么区别？

网络层协定负责提供主机间的逻辑通信；传输层协定负责提供过程间的逻辑通信。

49.IP 地址有哪些分类？

一个 IP 地址在这鞥个互联网范畴内是惟一的，个别能够这么认为，IP 地址 = {< 网络号 >，< 主机号 >}。

1. 网络号：它标记主机所连贯的网络地址示意属于互联网的哪一个网络。
2. 主机号：它标记主机地址示意其属于该网络中的哪一台主机。

IP 地址分为 A，B，C，D，E 五大类：

• A 类地址 (1~126)：以 0 结尾，网络号占前 8 位，主机号占前面 24 位。
• B 类地址 (128~191)：以 10 结尾，网络号占前 16 位，主机号占前面 16 位。
• C 类地址 (192~223)：以 110 结尾，网络号占前 24 位，主机号占前面 8 位。
• D 类地址 (224~239)：以 1110 结尾，保留为多播地址。
• E 类地址 (240~255)：以 1111 结尾，保留位为未来应用

50. 域名和 IP 的关系？一个 IP 能够对应多个域名吗？

• IP 地址在同一个网络中是惟一的，用来标识每一个网络上的设施，其相当于一个人的身份证号
• 域名在同一个网络中也是惟一的，就像是一个人的名字、绰号

如果你有多个不必的绰号，你的敌人能够用其中任何一个绰号叫你，但你的身份证号码却是惟一的。但同时你的绰号也可能和他人反复，如果你不在，有人叫你的绰号，其它人可能就许可了。

一个域名能够对应多个 IP，但这种状况 DNS 做负载平衡的，在用户拜访过程中，一个域名只能对应一个 IP。

而一个 IP 却能够对应多个域名，是一对多的关系。

51.IPV4 地址不够如何解决？

咱们晓得，IP 地址有 32 位，能够标记 2 的 32 次方个地址，听起来很多，然而寰球的网络设备数量曾经远远超过这个数字，所以 IPV4 地址曾经不够用了，那怎么解决呢？

• DHCP：动静主机配置协定，动态分配 IP 地址，只给接入网络的设施调配 IP 地址，因而同一个 MAC 地址的设施，每次接入互联网时，失去的 IP 地址不肯定是雷同的，该协定使得闲暇的 IP 地址能够失去充分利用。
• CIDR：无类别域间路由。CIDR 打消了传统的 A 类、B 类、C 类地址以及划分子网的概念，因此更加无效地调配 IPv4 的地址空间，但无奈从根本上解决地址耗尽的问题。
• NAT：网络地址转换协定，咱们晓得属于不同局域网的主机能够应用雷同的 IP 地址，从而肯定水平上缓解了 IP 资源枯竭的问题，然而主机在局域网中应用的 IP 地址是不能在公网中应用的，当局域网主机想要与公网主机进行通信时，NAT 办法能够将该主机 IP 地址转换为寰球 IP 地址。该协定可能无效解决 IP 地址有余的问题。
• IPv6：作为接替 IPv4 的下一代互联网协议，其能够实现 2 的 128 次方个地址，而这个数量级，即便给地球上每一粒沙子都调配一个 IP 地址也够用，该协定可能从根本上解决 IPv4 地址不够用的问题。

52. 说下 ARP 协定的工作过程？

ARP 协定，Address Resolution Protocol，地址解析协定，它是用于实现 IP 地址到 MAC 地址的映射。

1. 首先，每台主机都会在本人的 ARP 缓冲区中建设一个 ARP 列表，以示意 IP 地址和 MAC 地址的对应关系。
2. 当源主机须要将一个数据包要发送到目标主机时，会首先查看本人的 ARP 列表，是否存在该 IP 地址对应的 MAC 地址；如果有﹐就间接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发动一个 ARP 申请的播送包，查问此目标主机对应的 MAC 地址。此 ARP 申请的数据包里，包含源主机的 IP 地址、硬件地址、以及目标主机的 IP 地址。

3. 网络中所有的主机收到这个 ARP 申请后，会查看数据包中的目标 IP 是否和本人的 IP 地址统一。如果不雷同，就会疏忽此数据包；如果雷同，该主机首先将发送端的 MAC 地址和 IP 地址增加到本人的 ARP 列表中，如果 ARP 表中曾经存在该 IP 的信息，则将其笼罩，而后给源主机发送一个 ARP 响应数据包，通知对方本人是它须要查找的 MAC 地址。
4. 源主机收到这个 ARP 响应数据包后，将失去的目标主机的 IP 地址和 MAC 地址增加到本人的 ARP 列表中，并利用此信息开始数据的传输。如果源主机始终没有收到 ARP 响应数据包，示意 ARP 查问失败。

53. 为什么既有 IP 地址，又有 MAC 地址？

MAC 地址和 IP 地址都有什么作用？

• MAC 地址是数据链路层和物理层应用的地址，是写在网卡上的物理地址，用来定义网络设备的地位，不可变更。
• IP 地址是网络层和以上各层应用的地址，是一种逻辑地址。IP 地址用来区别网络上的计算机。

为什么有了 MAC 地址还须要 IP 地址？

如果咱们只应用 MAC 地址进行寻址的话，咱们须要路由器记住每个 MAC 地址属于哪个子网，不然一次路由器收到数据包都要满世界寻找目标 MAC 地址。而咱们晓得 MAC 地址的长度为 48 位，也就是最多共有 2 的 48 次方个 MAC 地址，这就意味着每个路由器须要 256T 的内存，显然是不事实的。

和 MAC 地址不同，IP 地址是和地区相干的，在一个子网中的设施，咱们给其调配的 IP 地址前缀都是一样的，这样路由器就能依据 IP 地址的前缀晓得这个设施属于哪个子网，剩下的寻址就交给子网外部实现，从而大大减少了路由器所须要的内存。

为什么有了 IP 地址还须要 MAC 地址？

• 只有当设施连入网络时，能力依据他进入了哪个子网来为其调配 IP 地址，在设施还没有 IP 地址的时候，或者在调配 IP 的过程中。咱们须要 MAC 地址来辨别不同的设施。

• IP 地址能够比作为地址，MAC 地址为收件人，在一次通信过程中，两者是缺一不可的。

54.ICMP 协定的性能？

ICMP（Internet Control Message Protocol），网际管制报文协定。

• ICMP 协定是一种面向无连贯的协定，用于传输出错报告管制信息。
• 它是一个十分重要的协定，它对于网络安全具备极其重要的意义。它属于网络层协定，次要用于在主机与路由器之间传递管制信息，包含 报告谬误、替换受限管制和状态信息 等。
• 当遇到 IP 数据无法访问指标、IP 路由器无奈按以后的传输速率转发数据包等状况时，会主动发送 ICMP 音讯。

比方咱们日常应用得比拟多的 ping，就是基于 ICMP 的。

55. 说下 ping 的原理？

ping，Packet Internet Groper，是一种因特网包摸索器，用于测试网络连接量的程序。Ping 是工作在 TCP/IP 网络体系结构中应用层的一个服务命令，次要是向特定的目标主机发送 ICMP（Internet Control Message Protocol 因特网报文控制协议）申请报文，测试目标站是否可达及理解其无关状态。

一般来说，ping 能够用来检测网络通不通。它是基于 ICMP 协定工作的。假如 机器 A ping 机器 B，工作过程如下：

1. ping 告诉零碎，新建一个固定格局的 ICMP 申请数据包
2. ICMP 协定，将该数据包和指标机器 B 的 IP 地址打包，一起转交给 IP 协定层
3. IP 层协定将本机 IP 地址为源地址，机器 B 的 IP 地址为指标地址，加上一些其余的管制信息，构建一个 IP 数据包
4. 先获取指标机器 B 的 MAC 地址。
5. 数据链路层构建一个数据帧，目标地址是 IP 层传过来的 MAC 地址，源地址是本机的 MAC 地址
6. 机器 B 收到后，比照指标地址，和本人本机的 MAC 地址是否统一，合乎就解决返回，不合乎就抛弃。
7. 依据目标主机返回的 ICMP 回送答复报文中的工夫戳，从而计算出往返工夫
8. 最终显示后果有这几项：发送到目标主机的 IP 地址、发送 & 收到 & 失落的分组数、往返工夫的最小、最大 & 平均值

网络安全

56. 说说有哪些平安攻打？

网络安全攻打次要分为两种类型，被动攻打 和主动攻击：

• 被动攻打：是指攻击者从网络上窃听别人的通信内容，通常把这类攻打称为截获，被动攻打次要有两种模式：音讯内容泄露攻打和流量分析攻击。因为攻击者没有批改数据，使得这种攻打很难被检测到。

• 主动攻击：间接对现有的数据和服务造成影响，常见的主动攻击类型有：

  • 篡改：攻击者成心篡改网络上送的报文，甚至把齐全伪造的报文传送给接管方。
  • 恶意程序：恶意程序品种繁多，包含计算机病毒、计算机蠕虫、特洛伊木马、后门入侵、流氓软件等等。
  • 拒绝服务 Dos：攻击者向服务器不停地发送分组，使服务器无奈提供失常服务。

57.DNS 劫持理解吗？

DNS 劫持即域名劫持，是通过将原域名对应的 IP 地址进行替换，从而使用户拜访到谬误的网站，或者使用户无奈失常拜访网站的一种攻击方式。

域名劫持往往只能在特定的网络范畴内进行，范畴外的 DNS 服务器可能返回失常的 IP 地址。攻击者能够假冒原域名所属机构，通过电子邮件的形式批改组织机构的域名注册信息，或者将域名转让给其它主持，并将新的域名信息保留在所指定的 DNS 服务器中，从而使用户无奈对原域名来进行解析以拜访指标地址。

DNS 劫持的步骤是什么样的？

1. 获取要劫持的域名信息：攻击者会首先拜访域名查问要劫持的站点的域名信息。
2. 管制域名响应的 E -Mail 账号：在获取到域名信息后，攻击者通过暴力破解或者专门的办法破解公司注册域名时应用的 E -mail 账号所对应的明码，更高级的攻击者甚至可能间接对 E -Mail 进行信息窃取。
3. 批改注册信息：当攻击者破解了 E -Mail 后，会利用相干的更改性能批改该域名的注册信息，包含域名拥有者信息，DNS 服务器信息等。
4. 应用 E -Mail 收发确认函：在批改完注册信息后，攻击者 E -Mail 在真正拥有者之前收到批改域名注册信息的相干确认信息，并回复确认批改文件，待网络公司复原已胜利批改函件后，攻击者便胜利实现 DNS 劫持。

怎么应答 DNS 劫持？

• 间接通过 IP 地址拜访网站，避开 DNS 劫持
• 因为域名劫持往往只能在特定的网络范畴内进行，因而一些高级用户能够通过网络设置让 DNS 指向失常的域名服务器以实现对指标网址的失常拜访，例如计算机首选 DNS 服务器的地址固定为 8.8.8.8。

58. 什么是 CSRF 攻打？如何防止？

什么是 CSRF 攻打？

CSRF，跨站申请伪造（英文全称是 Cross-site request forgery），是一种挟持用户在以后已登录的 Web 应用程序上执行非本意的操作的攻打办法。

CSRF 是如何攻打的呢？

来看一个例子：

1. 用户登陆银行，没有退出，浏览器蕴含了 用户 在银行的身份认证信息。
2. 攻击者将伪造的转账申请，蕴含在在帖子
3. 用户在银行网站放弃登陆的状况下，浏览帖子
4. 将伪造的转账申请连同身份认证信息，发送到银行网站
5. 银行网站看到身份认证信息，认为就是 用户的非法操作，最初造成用户资金损失。

怎么应答 CSRF 攻打呢？

• 查看 Referer 字段

  HTTP 头中的 Referer 字段记录了该 HTTP 申请的起源地址。在通常状况下，拜访一个平安受限页面的申请来自于同一个网站，而如果黑客要对其施行 CSRF 攻打，他个别只能在他本人的网站结构申请。因而，能够通过验证 Referer 值来进攻 CSRF 攻打。

• 增加校验 token

  以在 HTTP 申请中以参数的模式退出一个随机产生的 token，并在服务器端建设一个拦截器来验证这个 token，如果申请中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻打而回绝该申请。

• 敏感操作多重校验

  对一些敏感的操作，除了须要校验用户的认证信息，还能够通过邮箱确认、验证码确认这样的形式多重校验。

59. 什么是 DoS、DDoS、DRDoS 攻打？

• DOS: (Denial of Service), 翻译过去就是拒绝服务, 所有能引起回绝 行为的攻打都被称为 DOS 攻打。最常见的 DoS 攻打就有 计算机网络宽带攻打 、 连通性攻打。

• DDoS: (Distributed Denial of Service)，翻译过去是分布式拒绝服务。是指处于不同地位的多个攻击者同时向一个或几个指标动员攻打，或者一个攻击者管制了位于不同地位的多台机器，并利用这些机器对受害者同时施行攻打。

  次要模式有流量攻打和资源耗尽攻打，常见的 DDoS 攻打有：SYN Flood、Ping of Death、ACK Flood、UDP Flood 等。

• DRDoS: (Distributed Reflection Denial of Service)，中文是分布式反射拒绝服务，该形式靠的是发送大量带有被害者 IP 地址的数据包给攻打主机，而后攻打主机对 IP 地址源做出大量回应，从而造成拒绝服务攻打。

如何防备 DDoS?

针对 DDoS 中的流量攻打，最间接的办法是减少带宽，实践上只有带宽大于攻打流量就能够了，然而这种办法老本十分高。在有短缺带宽的前提下，咱们应该尽量晋升路由器、网卡、交换机等硬件设施的配置。

针对资源耗尽攻打，咱们能够降级主机服务器硬件，在网络带宽失去保障的前提下，使得服务器可能无效反抗海量的 SYN 攻打包。咱们也能够装置业余的抗 DDoS 防火墙，从而反抗 SYN Flood 等流量型攻打。瓷碗，负载平衡，CDN 等技术都能无效反抗 DDos 攻打。

60. 什么是 XSS 攻打，如何防止?

XSS 攻打也是比拟常见，XSS，叫 跨站脚本攻打（Cross-Site Scripting），因为会与层叠样式表 (Cascading Style Sheets, CSS) 的缩写混同，因而有人将跨站脚本攻打缩写为 XSS。它指的是歹意攻击者往 Web 页面里插入歹意 html 代码，当用户浏览网页的时候，嵌入其中 Web 外面的 html 代码会被执行，从而达到歹意攻打用户的非凡目标。

XSS 攻打个别分三种类型：存储型、反射型、DOM 型 XSS

XSS 是如何攻打的呢？

简略说，XSS 的攻击方式就是想方法“唆使”用户的浏览器去执行一些这个网页中本来不存在的前端代码。

拿反射型举个例子吧，流程图如下：

1. 攻击者结构出非凡的 URL，其中蕴含恶意代码。
2. 用户关上带有恶意代码的 URL 时，拜访失常网站服务器
3. 网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
4. 用户浏览器接管到响应后解析执行，混在其中的恶意代码也被执行，申请歹意服务器，发送用户数据
5. 攻击者就能够窃取用户的数据，以此假冒用户的行为，调用指标网站接口执行攻击者指定的操作。

如何应答 XSS 攻打？

• 对输出进行过滤，过滤标签等，只容许非法值。
• HTML 本义
• 对于链接跳转，如<a href="xxx" 等，要校验内容，禁止以 script 结尾的非法链接。
• 限度输出长度

61. 对称加密与非对称加密有什么区别？

对称加密：指加密和解密应用同一密钥，长处是运算速度较快，毛病是如何平安将密钥传输给另一方。常见的对称加密算法有：DES、AES 等。

非对称加密：指的是加密和解密应用不同的密钥（即公钥和私钥）。公钥与私钥是成对存在的，如果用公钥对数据进行加密，只有对应的私钥能力解密。常见的非对称加密算法有 RSA。

62.RSA 和 AES 算法有什么区别？

• RSA

  采纳非对称加密的形式，采纳公钥进行加密，私钥解密的模式。其私钥长度个别较长，因为须要大数的乘幂求模等运算，其运算速度较慢，不适合大量数据文件加密。

• AES

  采纳对称加密的形式，其秘钥长度最长只有 256 个比特，加密和解密速度较快，易于硬件实现。因为是对称加密，通信单方在进行数据传输前须要获知加密密钥。

<big>参考：</big>

[1]. 2W 字！梳理 50 道经典计算机网络面试题（收藏版）

[2]. 小林 coding《图解网络》

[3].“三次握手，四次挥手”这么讲，保障你忘不了

[4]. 艾小仙《我要进大厂》

[5].《图解 HTTP》

[6]. 浅析 DNS 域名解析过程

[7].「2021」高频前端面试题汇总之计算机网络篇

[8]. 计算机网络

[9]. 谢希仁编著《计算机网络》

[10].《图解 TCP/IP》

[11].TCP 的可靠性传输是如何保障的

[12]. 前端平安系列（一）：如何避免 XSS 攻打？