5.计算机网络面试题

网络层的 ARP 协议完成了 IP 地址和物理地址的映射。每个主机都会建立一个ARP，以表示IP地址和MAC地址关系。当源主机需要向目标主机发送数据包时，它会首先检查自己ARP目标主机是否在列表中？IP地址对应的MAC如果有地址，直接将数据包发送到MAC地址；如果没有，发送一个ARP请求的广播包。这个ARP请求包包包括源主机IP MAC以及目标主机IP，如果网络中的主机发现目标主机IP与自己一致，目标主机将有源主机的机会IP MAC添加到自己的地址ARP列表中，然后给源主机一个ARP响应数据包，告诉它自己IP MAC；源主机收到数据包后，将IP MAC地址添加到ARP列表中。

IP 地址是指互联网协议地址 IP 协议提供的统一地址格式。

IP 将编制地址方案 IP 地址空间分为 A、B、C、D、E 五类。其中 A、B、C 是基本类，D、E 作为多播和保留的类别，它是一个特殊的地址。每个类别IP地址等于网络ID 主机ID，同一物理网络上的所有主机都使用同一个网络 ID，网络上的主机有主机 ID 与其对应。

A 类地址：以 0 开头，第一个字节范围：0~127；

B 类地址：以 10 开头，第一个字节范围:128~191；

C 类地址：以 110 开头，第一个字节范围:192~223；

D 类地址：以 1110 开头，第一个字节范围是 224~239；

E 类地址：以 1111 开头，保留地址。

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接，这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如：QQ 语音、 QQ 视频 、直播等等。

1. TCP 对应的应用层协议

FTP：文件传输协议

Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上。

SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。

POP3：它是和 SMTP 对应，POP3 用于接收邮件。

HTTP：从 Web 服务器传输超文本到本地浏览器的传送协议

2. UDP 对应的应用层协议

DNS：用于域名解析服务，将域名地址转换为 IP 地址。

SNMP：简单网络管理协议，用来管理网络设备。

TFTP：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务。

TCP 建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个 TCP 报文段。

最初客户端A（Client）和服务端B（Server）都处于 CLOSED(关闭) 状态。一开始，B 的 TCP 服务器创建传输控制块TCB，进程处于 LISTEN(监听) 状态，等待客户端的连接请求。

第一次握手：A 的 TCP 客户端进程也是首先创建传输控制块 TCB，向 B 发出连接请求报文段，同步位 SYN=1，同时选择一个初始序号 seq = x。TCP 客户进程进入 SYN-SENT状态。

第二次握手：B 收到连接请求报文后，如果同意建立连接，则向 A 发送确认。在确认报文段中应把 SYN 位和 ACK 位都置 1，确认号是 ack = x + 1，同时也为自己选择一个初始序号 seq = y。TCP 服务端进程进入 SYN-RCVD（同步收到）状态。

第三次握手：TCP 客户进程收到 B 的确认后，还要向 B 给出确认。确认报文段的 ACK 置 1，确认号 ack = y +  1，而自己的序号 seq = x + 1。A 进入 ESTABLISHED（已建立连接）状态。

为什么两次握手不可以呢？

为了防止已经失效的连接请求报文段突然又传送到了 B，因而产生错误。A 发出的第一个连接请求报文段并没有丢失，而是在网路结点长时间滞留了，以致于延误到连接释放以后的某个时间段才到达 B。此时B进入连接状态，这样B的服务器资源就浪费了。如果采用了三次握手，那么B收不到确认，会在一定时间之后释放对应连接。

为什么不需要四次握手

完全可靠的通信协议是不存在的。在经过三次握手之后，客户端和服务端已经可以确认之前的通信状况，都收到了确认信息。所以即便再增加握手次数也不能保证后面的通信完全可靠，所以是没有必要的。

Server 端收到 Client 端的 SYN 后，为什么还要传回 SYN

接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。

传了 SYN，为什么还要传 ACK 服务端到客户端的通道需要ACK信号来验证

据传输结束后，通信的双方都可以释放连接。现在 A 和 B 都处于 ESTABLISHED 状态。

第一次挥手：A向B发送FIN =1，用来关闭请求，其序号 seq = u（等于前面已传送过的数据的最后一个字节的序号加 1），等待B确认。A 进入 FIN-WAIT-1状态。

第二次挥手：B 收到连接释放报文段后立即发出确认，确认号是 ack = u + 1，而这个报文段自己的序号是 v（等于 B 前面已经传送过的数据的最后一个字节的序号加1），ACK=1。然后 B 就进入 CLOSE-WAIT（关闭等待）状态，A 收到来自 B 的确认后，就进入 FIN-WAIT-2(终止等待2)状态。

第三次挥手：B发出连接释放报文段FIN = 1，ACK=1，重复上次已发送过的确认号 ack = u + 1，假定此时B的seq=w，在半关闭状态，B 可能又发送了一些数据。这时 B 就进入 LAST-ACK(最后确认)状态，等待 A 的确认。

第四次挥手：A 在收到 B 的连接释放报文后，必须对此发出确认。在确认报文段中把 ACK 置 1，确认号 ack = w + 1，而自己的序号 seq = u + 1。然后进入 TIME-WAIT(时间等待) 状态，经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命），A 进入到 CLOSED 。B 一收到 A 的确认就进入 CLOSED 状态。

为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢

为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到第四次挥手的确认。B就能重传第三次挥手信息，接着A重传第四次挥手，重新启动 2MSL 计时器。如果不等待，B 就无法按照正常步骤进入 CLOSED 状态。

第二，等待一段时间后，可以防止已失效上一段的连接请求报文段出现在当前连接中。

为什么第二次跟第三次不能合并, 第二次和第三次之间的等待是什么

当服务器执行第二次挥手之后, 此时证明客户端不会再向服务端请求任何数据, 但是服务端可能还正在给客户端发送数据（可能是客户端上一次请求的资源还没有发送完毕），所以此时服务端会等待把之前未传输完的数据传输完毕之后再发送关闭请求。

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

1.数据包校验：若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据。

2.失序数据包重排序：TCP 将对失序数据进行重新排序，然后才交给应用层；

3.丢弃重复数据：对于重复数据能够丢弃

4.应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；

5.超时重发：当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；

6.流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

停止等待协议属于数据链路层，为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认，在收到确认后再发下一个分组。在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

ARQ协议属于数据链路层，主要分为两部分。

1. 自动重传请求 ARQ 协议：超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组，认为刚才发送过的分组丢失了。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。这种自动重传方式常称为自动重传请求 ARQ。

2. 连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

TCP 利用滑动窗口实现流量控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据，发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0 时，发送方一般不能再发送数据报，但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

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

拥塞控制和流量控制不同，拥塞控制是一个全局性的过程，而流量控制指点对点通信量的控制。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致于过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。为了进行拥塞控制，TCP 发送方要维持一个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。

发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。TCP 的拥塞控制采用了四种算法，即：慢开始、拥塞避免、快重传和快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如：主动队列管理 AQM），以减少网络拥塞的发生。

慢开始：

当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测一下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。

拥塞避免：

拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢增大，即每经过一个往返时间 RTT 就把发送方的cwnd加1

快重传与快恢复（FRR）：

没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到一个不按顺序的数据段，它会立即给发送机发送一个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。

如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。

1. 发送方产生粘包

采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态，双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认将这些较小的数据包进行合并发送，也就是说数据发送出来它已经是粘包的状态了。

2. 接收方产生粘包

数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取。我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。即放数据的速度 > 应用层拿数据速度。

怎么解决拆包和粘包？

1. 特殊字符控制；

2. 在包头首都添加数据包的长度。

100 表明到目前为止都很正常

200 OK，正常返回信息

301 永久性重定向

302 临时性重定向（代表着某个 URL 发生了转移）

400 请求报文中存在语法错误

401 该状态码表示发送的请求需要有认证信息

403 请求被拒绝

404 Not Found

500 服务器错误

503 服务器暂时处于超负载或正在进行停机维护，现在无法处理请求

Forward 和 Redirect 代表了两种请求转发方式：直接转发和间接转发。

直接转发方式（Forward）：客户端和浏览器只发出一次请求，由第二个信息资源响应该请求，在请求对象 request 中，保存的对象对于每个信息资源是共享的。

间接转发方式（Redirect）：实际是两次 HTTP 请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。

直接转发就相当于：“A 找 B 借钱，B 说没有，B 去找 C 借，借到借不到都会把消息传递给 A”；

间接转发就相当于："A 找 B 借钱，B 说没有，让 A 去找 C 借"。

客户端发送的 请求报文 第一行为请求行，包含了方法字段。

1. GET：获取资源，当前网络中绝大部分使用的都是 GET；

2. HEAD：获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分；

3. POST：传输实体主体

4. PUT：上传文件

5. PATCH：对资源进行部分修改。

6. OPTIONS：查询指定的 URL 支持的方法；

7. CONNECT：要求在与代理服务器通信时建立隧道。

8. TRACE：用于沿着目标资源的路径执行消息环回测试；它回应收到的请求，以便客户可以看到中间服务器进行了哪些（假设任何）进度或增量。

GET 和 POST 本质都是 HTTP 请求，只不过GET 是一次 HTTP请求，POST 先发请求头再发请求体，实际上是两次请求。

从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；从请求参数形式上看，GET 请求的数据会附在 URL 之后，而 POST 请求的数据则放置在是 HTTP 请求报文的 请求体 中；就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全；从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。

1. DNS 解析：浏览器查询 DNS，获取域名对应的 IP 地址，具体过程包括浏览器搜索自身的 DNS 缓存、搜索操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查询等。

2. TCP 连接：浏览器获得域名对应的 IP 地址以后，浏览器向服务器请求建立链接，发起三次握手；

3. 发送 HTTP 请求：TCP 连接建立起来后，浏览器向服务器发送 HTTP 请求；

4. 服务器处理请求并返回 HTTP 报文：服务器接收到这个请求，并将处理结果以及相应视图返回给浏览器；

5. 浏览器解析渲染页面：浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

1. 主机向本地域名服务器的查询一般都是采用递归查询。如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向根域名服务器继续发出查询请求报文(即替主机继续查询) ，而不是让主机自己进行下一步查询。

2. 本地域名服务器向根域名服务器的查询的迭代查询。当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。本地域名服务器得到了所要解析的 IP 地址或报错，然后把这个结果返回给发起查询的主机。

为了提高 DNS 查询效率，并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如：每个项目两天）。

不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源，每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

而从 HTTP/1.1 起，默认使用长连接keep-alive，用以保持连接特性。在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive 不会永久保持连接，它有一个保持时间，实现长连接需要客户端和服务端都支持长连接。

HTTP1.1 的主要变化

1. 出了长连接，HTTP 可以在一次 TCP 连接中不断发送请求。

2. 支持只发送 header 而不发送 body。先用 header 判断能否成功，再发数据，节约带宽，事实上，post 请求默认就是这样做的。

3. 虚拟主机可以支持多个域名，所以一般将域名解析后得到 host。

HTTP2.0 的主要变化

1. 支持多路复用，同一个连接可以并发处理多个请求，方法是把 HTTP数据包拆为多个帧，并发有序的发送，根据序号在另一端进行重组，而不需要一个个 HTTP请求顺序到达；

2. 支持服务端推送，就是服务端在 HTTP 请求到达后，除了返回数据之外，还推送了额外的内容给客户端；

3. 压缩了请求头，同时基本单位是二进制帧流，这样的数据占用空间更少；

4. 适用于 HTTPS 场景，因为其在 HTTP和 TCP 中间加了一层 SSL 层。

1. 开销：HTTPS 协议需要SSL证书，一般免费证书很少，需要交费；证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗；

2. 资源消耗：HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 ssl 加密传输协议，需要消耗更多的 CPU 和内存资源，HTTPS 协议握手阶段比较费时，连接缓存不如HTTP高效。

3. 端口不同：HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是  80，后者是 443；

4. 安全性：HTTP 的连接很简单，是无状态的；HTTPS 协议是由 TSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。

数字签名：为了避免数据在传输过程中被替换，比如黑客修改了你的报文内容，但是你并不知道，所以我们让发送端做一个数字签名，把数据的摘要消息进行一个加密，比如 MD5，得到一个签名，和数据一起发送。然后接收端把数据摘要进行 MD5 加密，如果和签名一样，则说明数据确实是真的。

数字证书： CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的。

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方。

非对称加密指使用一对非对称密钥，即：公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

非对称加密的安全性更高，但是速度慢，因此用对称加密来传送消息，但对称加密所使用的密钥可以通过非对称加密的方式发送出去。