计算机网络

1. HTTPS是如何保证安全传输的？

https://www.cnblogs.com/xdyixia/p/11610102.html
https://zhuanlan.zhihu.com/p/43789231

HTTPS = HTTP+SSL（安全套接层）（会话层）
HTTP明文传输，易被窃取
需要了解：对称加密、非对称加密、数字证书
对称加密：客户端和服务端用同一个密钥 存在问题：中间人会获取到密钥，伪造数据发送给服务端
非对称加密：客户端用公钥，服务端用私钥（公钥也是服务端发给客户端的，tcp建立完发送） 存在问题：客户端和中间人tcp连接，中间人和服务端tcp连接，则中间人获取到了服务端发给客户端的公钥，然后伪造私钥发给客户端，之后的通信都变成了客户端——中间人——服务端，中间人又能操作数据了
SSL结合了这两种加密算法的优点，通过非对称加密来协商对称加密的密钥，握手成功之后便可使用对称加密来做加密通信

数字证书：公认的第三方颁发数字证书（CA证书） 服务端的私钥是向第三方公认机构申请的，非常保密。客户端（浏览器）中保存的公钥是公认机构颁发的。用CA的私钥给用户的证书签名，然后在证书的签名字段中填充这个签名值，浏览器在验证这个证书的时候就是使用CA的公钥进行验签

CA使用的具体流程

a.服务方S向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;（不交私钥）
b.CA通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等;
c.如信息审核通过，CA会向申请者签发认证文件-证书。
证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构CA的信息、有效时间、证书序列号等信息的明文，同时包含一个签名;
签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用CA的私钥对信息摘要进行加密，密文即签名;
d.客户端 C 向服务器 S 发出请求时，S 返回证书文件;
e.客户端 C读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应CA的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法;
f.客户端然后验证证书相关的域名信息、有效时间等信息;
g.客户端会内置信任CA的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA的证书，证书也会被判定非法。
在这个过程注意几点：
a.申请证书不需要提供私钥，确保私钥永远只能服务器掌握;
b.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名;
c.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书（为什么说”部署自签SSL证书非常不安全”）
d.证书=公钥（服务方生成密码对中的公钥）+申请者与颁发者信息+签名（用CA机构生成的密码对的私钥进行签名）;
即便有人截取服务器A证书，再发给客户端，想冒充服务器A，也无法实现。因为证书和url的域名是绑定的。

2. OSI七层、TCP/IP四层的关系和区别？

![image.png](https://cdn.nlark.com/yuque/0/2021/png/22162061/1628735123135-1bc80e43-7dd3-4cb5-9522-c8cf6d9edb18.png#height=256&id=Qkq2o&margin=%5Bobject%20Object%5D&name=image.png&originHeight=256&originWidth=355&originalType=binary&ratio=1&size=44163&status=done&style=none&width=355)<br />应用层：各种应用程序协议：万维网应用的HTTP、域名系统DNS<br />表示层：信息的语法语义及它们的关联，如加密解密、转换翻译、压缩解压缩<br />会话层：不同机器上的用户建立及管理会话<br />传输层：接收上一层的数据，对数据分割，交给网络层，保证数据段有效到达（两台主机进程的通信）：TCP、UDP<br />网络层：控制子网的运行，选择合适的网间路由和交换节点：IP，分组也叫IP数据报<br />数据链路层：物理寻址，将原始比特流组转成帧，点对点传递<br />物理层：原始比特流传输，二进制数据物理媒介传输

特点：
层与层之间相互独立又相互依靠
上层依赖于下层，下层为上层提供服务

TCP/IP 四层是 OSI 七层的简化版，已经成为实事国际标准。

3. TCP和UDP的区别

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

总结：
TCP 向上层提供面向连接的可靠服务 ，UDP 向上层提供无连接不可靠服务。
UDP 没有 TCP 传输可靠，但是可以在实时性要求高的地方有所作为。
对数据准确性要求高，速度可以相对较慢的，可以选用TCP。

（报文：分组数据， 字节流：以字节流的形式传递数据）

4. TCP如何保证可靠传输？

通过校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制等机制来保证可靠性。
ARQ协议（包括确认和超时两个机制）

应用数据被TCP分割成最适合发送的数据块
（1）校验和
在数据传输过程中，将发送的数据段都当做一个16位的整数，将这些整数加起来，并且前面的进位不能丢弃，补在最后，然后取反，得到校验和。
发送方：在发送数据之前计算校验和，并进行校验和的填充。接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方进行比较。
（2）序列号
TCP 传输时将每个字节的数据都进行了编号，这就是序列号。序列号的作用不仅仅是应答作用，有了序列号能够将接收到的数据根据序列号进行排序，并且去掉重复的数据。
（3）确认应答
TCP 传输过程中，每次接收方接收到数据后，都会对传输方进行确认应答，也就是发送 ACK 报文，这个 ACK 报文中带有对应的确认序列号，告诉发送方，接收了哪些数据，下一次数据从哪里传。
（4）超时重传
在进行 TCP 传输时，由于存在确认应答与序列号机制，也就是说发送方发送一部分数据后，都会等待接收方发送的 ACK 报文，并解析 ACK 报文，判断数据是否传输成功。如果发送方发送完数据后，迟迟都没有接收到接收方传来的 ACK 报文，那么就对刚刚发送的数据进行重发。
（5）连接管理
就是指三次握手、四次挥手的过程。
（6）流量控制
如果发送方的发送速度太快，会导致接收方的接收缓冲区填充满了，这时候继续传输数据，就会造成大量丢包，进而引起丢包重传等等一系列问题。TCP 支持根据接收端的处理能力来决定发送端的发送速度，这就是流量控制机制。
具体实现方式：接收端将自己的接收缓冲区大小放入 TCP 首部的『窗口大小』字段中，通过 ACK 通知发送端。
使用协议：滑动窗口协议
（7）拥塞控制
TCP 传输过程中一开始就发送大量数据，如果当时网络非常拥堵，可能会造成拥堵加剧。所以 TCP 引入了慢启动机制，在开始发送数据的时候，先发少量的数据探探路。

5. TCP协议如何提高传输效率？

TCP 协议提高效率的方式有滑动窗口、快重传、延迟应答、捎带应答等
（1）滑动窗口
如果每一个发送的数据段，都要收到 ACK 应答之后再发送下一个数据段，这样的话我们效率很低，大部分时间都用在了等待 ACK 应答上了。
为了提高效率我们可以一次发送多条数据，这样就能使等待时间大大减少，从而提高性能。窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。
（2）快重传
快重传也叫高速重发控制。
那么如果出现了丢包，需要进行重传。一般分为两种情况：
情况一：数据包已经抵达，ACK被丢了。这种情况下，部分ACK丢了并不影响，因为可以通过后续的ACK进行确认；
情况二：数据包直接丢了。发送端会连续收到多个相同的 ACK 确认，发送端立即将对应丢失的数据重传。
（3）延迟应答
如果接收数据的主机立刻返回ACK应答，这时候返回的窗口大小可能比较小。

• 假设接收端缓冲区为1M，一次收到了512K的数据；如果立刻应答，返回的窗口就是512K；
• 但实际上可能处理端处理速度很快，10ms之内就把512K的数据从缓存区消费掉了；
• 在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过来；
• 如果接收端稍微等一会在应答，比如等待200ms再应答，那么这个时候返回的窗口大小就是1M；

窗口越大，网络吞吐量就越大，传输效率就越高；我们的目标是在保证网络不拥塞的情况下尽量提高传输效率。
（4）捎带应答
在延迟应答的基础上，很多情况下，客户端服务器在应用层也是一发一收的。这时候常常采用捎带应答的方式来提高效率，而ACK响应常常伴随着数据报文共同传输。如：三次握手。

6. TCP如何处理拥塞？

网络拥塞现象：对网络中某一资源（带宽、存储空间、处理器处理能力）的需求超过了该资源所能提供的可用部分，网络性能变坏。
拥塞控制：防止过多数据注入网络，使得网络中的路由器或链路不过载。

拥塞控制：全局性过程，涉及所有的主机、路由器，以及与降低网络传输性能有关的所有因素
流量控制：点对点通信量的控制，端对端的问题。抑制发送端发送数据的速率，以使接收端来得及接收

为了进行拥塞控制，TCP 发送方要维持⼀个 拥塞窗口(cwnd) 的状态变量。
拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗⼝取为 拥塞窗口 和接收方的 接受窗口 中较小的一个。 发送窗口=min{拥塞窗口，接收窗口}
拥塞控制的四个阶段（算法）:

• 慢启动：小量数据试探，从小到大逐步增加发送窗口，也即从小到大逐步增加拥塞窗口

cwnd初始值为1，每经一个传播轮次，cwnd加倍

• 拥塞避免：让cwnd缓慢变大，即每经过一个往返时间RTT（Round-trip time）就cwnd+1
• 快速重传+快速恢复 FRR（fast retransmit and recovery）：数据包丢失，接收机接收到⼀个不按顺序的数据段，它会立即给发送机发送⼀个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并⽴即重传这些丢失的数据段。（原本没有FRR时，使用计时器来暂停传输）

7. TCP的三次握手

https://www.cnblogs.com/bj-mr-li/p/11106390.html

第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。

理解简记

客户端–发送带有 SYN 标志的数据包–⼀次握手–服务端
服务端–发送带有 SYN/ACK 标志的数据包–⼆次握手–客户端
客户端–发送带有带有 ACK 标志的数据包–三次握手–服务端

8. TCP的四次挥手

1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

理解简记

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

9. 面试题：为什么连接的时候是三次握手，关闭的时候却是四次挥手？

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。
但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

10. 面试题：为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假想网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。
在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。
Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。
如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

理解简记

客户端最后一个ACK报文可能会丢失，TIME_WAIT状态是为了确认服务端收到了最后的ACK报文。
如果服务端收到了ACK报文，则接下来任何时间都不会受到服务端传来的消息。
如果服务端没收到ACK报文，则将会继续发送FIN报文，客户端便会收到FIN报文，而2MSL刚好是发送到回复一个来回所需的最大时间。

11. 面试题：为什么不能用两次握手进行连接？

3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。

理解简记

三次握手是为了客户端和服务端双方都确认彼此收发功能正常。
二次握手只能保证使客户端确认自己和服务端都收发正常，
而服务端不能确认自己是否发送正常、客户端是否接收正常
改成两次握手以后可能发生死锁（S认为连接成功一直发送重复数据，C不知连接已成功一直等到ACK报文）：
根据两次握手协议，S收到C发来的带有SYN的数据包后，发送带有SYN-ACK的数据包给C，此时S认为已成功建立连接。
但是这时候如果发生ACK丢失，C将不知S是否准备好接收数据，认为连接尚未成功，将忽略S发来的任何数据分组，只等待确认应答分组。而S则在发出的分组超时后，重复发送同样的分组，形成死锁。

12. 面试题：如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

理解简记

TCP设有保活计时器，时间设置为2小时。若2小时内服务器未收到任何数据，则会每隔75s发送一个探测报文段，一连十个没反应，则断开连接。

13. IP地址怎么分类

IP 的基本特点：

• IP地址由四段组成，每个字段是一个字节，8位，最大值是255。
• IP地址由两部分组成，即网络地址和主机地址。网络地址表示其属于互联网的哪一个网络，主机地址表示其属于该网络中的哪一台主机。

IP 地址主要分为A、B、C三类及特殊地址D、E这五类，甩一张图：

14. HTTP1.0、HTTP1.1 和HTTP2 有什么区别？

HTTP请求报文
一个HTTP请求报文由请求行（request line）、请求头部（headers）、空行（blank line）和请求数据（request body）4个部分组成。

HTTP1.0

• 短连接（每次请求都重新建立一次连接）
• 缓存判断标准：header里的If-Modified-Since、Expires

HTTP1.1（当前使用最广泛）

• 持久连接（长连接）

默认开启Connection：keep-alive
持续连接方式：非流水线（收到前一个响应才能发下一个请求）、流水线

• 请求管道化
• 增加缓存处理（缓存策略）（新的字段如cache-control）
• 增加 Host 字段、支持断点传输等

HTTP2.0

• 二进制分帧（HTTP1.1 是文本格式）——解析更高效、错误更少
• 多路复用（或连接共享：同时处理多个消息的请求和响应）（HTTP1.1存在线端阻塞问题：一个连接一次提交多个请求效率会 变低，流水线方式解决效果一般）
• （消息）头部压缩
• 服务器推送：服务器把它认为客户端需要的内容推送到客户端缓存中，避免往返延迟

15. HTTP 和HTTPS 的区别

（1）HTTPS 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。
（2）HTTP 是超文本传输协议，信息是明文传输（客户端和服务端都无法验证对方身份），HTTPS 则是具有安全性的 SSL 加密传输协议。
（3）HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
（4）HTTP 的连接很简单，是无状态的；HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。（HTTPS传输内容采用对称加密，对称加密的密钥是非对称加密）

16. URI和URL的区别

URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源。
URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。它是⼀种具 体的 URI，即 URL 可以⽤来标识⼀个资源，⽽且还指明了如何 locate 这个资源。

URI的作⽤像身份证号⼀样，URL的作⽤更像家庭住址⼀样。URL是⼀种具体的URI，它不仅唯⼀标识资源，⽽且还提供了定位该资源的信息。

17. 常见的状态码有哪些

1×× : 请求处理中，请求已被接受，正在处理 101 切换请求协议
2×× : 请求成功，请求被成功处理 200 请求成功 201 已创建 202已接收
3×× : 重定向，要完成请求必须进行进一步处理 301 : 永久性转移 302 ：暂时性转移 304 ：已缓存
4×× : 客户端错误，请求不合法 400：Bad Request,请求有语法问题 401：请求要求用户的身份认证 402：保留，将来使用 403：禁止访问，权限有关 404：客户端所访问的页面不存在
5×× : 服务器端错误，服务器不能处理合法请求 500 ：服务器内部错误 502 BadGateway充当网关或代理的服务器，从远端服务器接收到一个无效请求 503 ：服务不可用，稍等

18. http中常见的header字段有哪些？

cookie，请求时传递给服务端的cookie信息
set-cookie，响应报文首部设置要传递给客户端的cookie信息
allow，支持什么HTTP方法
last-modified，资源的最后修改时间
expires,设置资源缓存的失败日期
content-language，实体的资源语言
content-encoding，实体的编码格式
content-length，实体主体部分的大小，单位是字节
content-range，返回的实体的哪些范围
content-type，哪些类型
accept-ranges，处理的范围请求
age，告诉客户端服务器在多久前创建了响应
vary，代理服务器的缓存信息
location，用于指定重定向后的URI
If-Match，值是资源的唯一标识
User-Agent，将创建请求的浏览器和用户代理名称等信息传递给服务器
Transfer-Encoding，传输报文的主体编码方式
connection，管理持久连接，keep-alive ,
close Cache-Control，控制浏览器的强缓存

19. Get与POST的区别

（1）GET 一般用来从服务器上获取资源，POST 一般用来创建资源；
（2）GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的。GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；
（3）从请求参数形式上看，GET 请求的数据会附在URL之后；而 POST 请求会把提交的数据则放置在是HTTP请求报文的请求体中。
（4）POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而 POST 请求参数则被包装到请求体中，相对更安全。
（5）GET 请求的长度受限于浏览器或服务器对URL长度的限制，允许发送的数据量比较小，而POST请求则是没有大小限制的。

20. 在浏览器中输入一个www.baidu.com到显示主页的过程

1.域名解析（DNS解析） ->
2.建立TCP连接（三次握手）->
3.发起http请求 ->
4.服务器响应http请求，浏览器得到html代码（返回HTTP报文） ->
5.浏览器解析html代码，并请求html代码中的资源（如 js、css、图片等）->
6.浏览器对页面进行渲染呈献给用户。

21. DNS 的寻址过程（即上述的DNS解析过程）

（1）在浏览器中输入www.baidu.com域名，操作系统会先检查自己浏览器缓存、本地的 hosts 文件是否有这个网址映射关系，如果有就先调用这个IP地址映射，完成域名解析。
（2）如果 hosts 里没有这个域名的映射，则查找本地 DNS 解析器缓存，是否有这个网址映射关系，如果有直接返回，完成域名解析。
（3）如果 hosts 与本地 DNS 解析器缓存都没有相应的网址映射关系，首先会找 TCP/IP 参数中设置的首选 DNS 服务器（电脑设置的一串数0.0.xxx），在此我们叫它本地 DNS 服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
（4）如果要查询的域名，不由本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，完成域名解析，此解析不具有权威性。
（5）如果本地 DNS 服务器本地区域文件与缓存解析都失效，则根据本地 DNS 服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地 DNS 就把请求发至13台根 DNS ，根 DNS 服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地 DNS 服务器收到IP信息后，将会联系负责 .com 域的这台服务器。这台负责 .com 域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(baidu.com)给本地 DNS 服务器。当本地 DNS 服务器收到这个地址后，就会找 baidu.com 域服务器，重复上面的动作，进行查询，直至找到 www.baidu.com 主机。
（6）如果用的是转发模式，此 DNS 服务器就会把请求转发至上一级 DNS 服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根 DNS 或把转请求转至上上级，以此循环。不管是本地 DNS 服务器用是是转发，还是根提示，最后都是把结果返回给本地 DNS 服务器，由此 DNS 服务器再返回给客户机。（转发模式，不断向上转发请求、解析）

注意：这上面少了一步：第一步是查找浏览器缓存

理解简记

先查缓存再解析
1.查找浏览器缓存和本地hosts文件，是否有网址映射，有则返回
2.查找本地DNS解析器，有则返回
3.查询本地DNS服务器，能解析则解析（服务器中的本地配置区域资源中有则返回，权威）
4.查询本地DNS服务器缓存，有则返回，不权威
5.若未采用转发模式，则从根服务器向下迭代查询，直到解析返回
6.若采用转发模式，则从上一级服务器向上递归，直到解析返回

22. Session和Cookie的区别

都是用来跟踪浏览器用户身份的会话方式，但应用场景不同

• session 保存在服务器端，cookie 在客户端（浏览器）
• session 默认被存储在服务器的一个文件里（不是内存）
• session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）
• session 可以放在 文件、数据库、或内存中都可以。
• 用户验证这种场合一般会用 session，安全性高（Cookie中不要存敏感信息，最好将Cookie信息加密然后使用的时候去服务端解密）
• Cookie一般用来保存用户信息，Session作用是通过服务端记录用户的状态

23. 有哪些 web 性能优化技术?

• DNS查询优化
• 客户端缓存
• 优化TCP连接
• 避免重定向
• 网络边缘的缓存
• 条件缓存
• 压缩和代码极简化
• 图片优化

24. 同步与异步

同步：发送⼀个请求，等待返回，再发送下⼀个请求，同步可以避免出现死锁，脏读的发⽣
异步：发送⼀个请求，不等待返回，随时可以再发送下⼀个请求，可以提⾼效率，保证并发
同步异步关注点在于消息通信机制

25. 服务端怎么主动向客户端发送消息？

https://blog.csdn.net/liujiandu101/article/details/81064707
https://blog.csdn.net/answer3lin/article/details/86618847
通常情况：客户端请求——服务端响应
在高并发和用户实时响应的场景下：金融证券、Web导航、实时消息推送、新闻订阅、天气提醒，需要服务端主动推送消息给客户端
该模式下，解决两个问题：
1.应用服务器确定每个应用所在的设备
2.服务器端是如何将消息推送到客户端的，客户端又不像服务器有一个固定的地址

相关技术：
1.
Http轮询
定时的通过Ajax查询服务端，客户端按规定时间定时像服务端发送ajax请求，服务器接到请求后马上返回响应信息并关闭连接。
间隔时间越快，推送的及时性越好，服务器的消费越大
问题：不断的向服务器发送消息询问，这种方式会对服务器造成极大的性能浪费。实时性不够
JSONP轮询
和HTTP轮询类似，但是它可以发送跨域请求（请求不属于您所在的域）
Piggyback polling（捎带轮询）
比轮询更聪明，删除所有非必需的请求（没有返回数据的那些），且不存在时间间隔，客户端在需要的时候向服务器端发送请求（本质还是客户端请求）

2.Comet
基于 HTTP 长连接的 “服务器推” 技术，能使服务器端主动以异步的方式向客户端程序推送数据，而不需要客户端显式的发出请求，工作原理：用户发起请求后就挂起，等待服务器返回数据，在此期间不会断开连接。目前有两种实现方式：
1. 基于 AJAX 的长轮询（long-polling）方式
2. 基于 Iframe 及 htmlfile 的流（streaming）方式
优点： 实时性好（消息延时小）；性能好（能支持大量用户）
缺点： 长期占用连接，丧失了无状态高并发的特点。

3.Server-Sent
原理：由客户端发起与服务器之间创建TCP连接，然后并维持这个连接，直到客户端或服务器中的任何一方断开，ServerSent使用的是”问”+”答”的机制，连接创建后浏览器会周期性地发送消息至服务器询问，是否有自己的消息。本质还是轮询，只不过维持一个长连接，在长连接里进行轮询。

4.WebSocket方式 业界标准
基于TCP之上定义了帧协议，支持双向的通信。WebSocket是一种全新的协议，不属于http无状态协议，协议名为ws协议或wss协议。ws不是http，所以传统的web服务器不一定支持。一个WebSocket连接地址会是这样的写法：ws://wilsonliu.cn:8080/webSocketServer。HTML5开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。
在WebSocket API中，浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。实现了浏览器与服务器的全双工通信，扩展了浏览器与服务端的通信功能，使服务端也能主动向客户端发送数据。
这是一个可以用在浏览器上的Socket连接。这也是一个HTML5标准中的一项内容，他要求浏览器可以通过JavaScript脚本手动创建一个TCP连接与服务端进行通讯。因为Socket是一个全双工的TCP和UDP连接，所以不需要轮询，只需要保持长连接和心跳包。通信协议的header也很小，相比与之前的long poll， web socket 能够更好的节省服务器资源和宽带并达到实时通信。
WebSocket通信协议包含两个部分，一是开放性HTTP握手连接协商连接参数，二是二进制消息分帧机制（接收消息的文本和二进制数据传输）。它是一个独立完善的协议，也可以在浏览器之外实现。
另外WebSocket使用了ws和wss协议（表示使用加密信道通信(TCP + TLS)，支持接收和发送文本和二进制数据），需要服务器有与之握手的算法才能将连接打开。
总结：将Socket的建立移植到了浏览器的脚本端，JS可以创建连接与服务器通讯，包括请求-响应模型，主动轮询的推送模式等。技术本身没有什么改进。最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。
使用：为了建立一个 WebSocket 连接，客户端浏览器首先要向服务器发起一个 HTTP 请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息 ”Upgrade: WebSocket” 表明这是一个申请协议升级的 HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的 WebSocket 连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。服务器和客户端可以在给定的时间范围内的任意时刻，相互推送信息。

26. TCP头部格式

1.源端口号,16位，发送方的端口号。
2.目标端口号，16位，发送方的目标端口号。
3.32位序列号，sequence number，保证网络传输数据的顺序性。
4.32位确认号，acknowledgment number，用来确认确实有收到相关封包，内容表示期望收到下一个报文的序列号，用来解决丢包的问题。
5.头部大小，4位，偏移量：最大值为0x0F，即15, 单位为32位(bit)，单位也就是4个字节，给出头部占32bit的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60(154)字节的TCP头部。
6.Reserved，4位 ，预留字段，都为0。
7.TCP标志位
（1）CWR：Congestion window reduced，拥塞窗口减少。拥塞窗口减少标志被发送主机设置，用来表明它接收到了设置ECE标志的TCP包。拥塞窗口是被TCP维护的一个内部变量，用来管理发送窗口大小。
（2）ECN-Echo：显式拥塞提醒回应。当一个IP包的ECN域被路由器设置为11时，接收端而非发送端被通知路径上发生了拥塞。ECN使用TCP头部来告知发送端网络正在经历拥塞，并且告知接收端发送段已经受到了接收端发来的拥塞通告，已经降低了发送速率。
（3）URG：为1时，紧急指针（urgent pointer）有效，配合紧急指针使用
（4）ACK：为1时，确认号有效
（5）PSH：为1时，接收方应该尽快将这个报文段交给应用层
（6）RST：为1时，释放连接，重连。
（7）SYN：为1时，发起一个连接。
（8）FIN：为1时，关闭一个连接。
8.16位窗口大小：占16bit。此字段用来进行流量控制，主要用于解决流控拥塞的问题。单位为字节数，这个值是本机期望一次接收的字节数。
9.16位校验值: 占16bit。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
10.16位紧急指针:占16bit。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
11.*32位Tcp选项:一般包含在三次握手中。

27. 收到的 HTML 如果包含几十个图片标签，这些图片是以什么方式、什么顺序、建立了多少连接、使用什么协议被下载下来的呢？

分解成5个问题：

回答点：
HTTP1.0 在服务器发送一个HTTP响应后会断开TCP连接。
HTTP1.1 将Connection头写进标准，默认开启长连接keep-alive。所以服务器和浏览器之间会维持一段时间TCP连接。这样再次发送HTTP请求时，初始化连接和SSL开销就节省了。
即：HTTP1.1后，一个连接课对应多个HTTP请求。

HTTP1.1 在单个TCP连接中同一时刻只能处理一个请求，虽然规定了Pipelining（流水线）试图解决这一问题，但默认关闭。
Pipelining：收到请求的服务器必须按照请求顺序发送响应。
存在问题：一些代理服务器不能正确处理；若首个请求非常耗时，则后面请求都要排队等他结束才响应。

HTTP2.0 提供 Multiplexing 多路传输特性，可在一个TCP中同时完成多个请求（并行完成）。

浏览器对同一host文件建立TCP连接数量有限，比如Chrome最多允许对同一个Host建6个TCP。

回答本题：
如果图片都是HTTPS连接，并在同一域名下。则，浏览器在SSL握手后，首先和服务器协商是否能用HTTP2.0，能的话就是用Multiplexing功能在连接上进行多路传输。
如果用不了HTTP2或用不了HTTPS（现实中HTTP2在HTTPS上实现），则使用HTTP1.1。HTTP1.1默认开启长连接，浏览器在一个HOST上建立多个TCP连接，连接数最大限制取决于浏览器。这些连接在空闲时被用来发送新的请求，如果所有连接都在发送请求，其他请求只能等待。