计算机网络面试问题（一）

1.在浏览器中输⼊URL并按下回⻋之后会发⽣什么

2.TCP三次握⼿的过程,为什么三次握手

TCP（传输控制协议）的三次握⼿是建⽴⽹络连接的过程，确保通信双⽅能够正确地进⾏数据传输。

1. 第⼀次握⼿（SYN）：
   客户端（Client）向服务器（Server）发送⼀个带有 SYN（同步）标志位的包，表示客户端希望建⽴连接。该包同
   时指定客户端的初始序列号（Client Sequence Number）。

   

2. 第⼆次握⼿（SYN + ACK）：
   服务器收到客户端的 SYN 包后，会回复⼀个带有 SYN 和 ACK（确认）标志位的包，表示服务器接受了客户端的请
   求，并希望建⽴连接。服务器也会指定⾃⼰的初始序列号，以及对客户端序列号的确认。

3. 第三次握⼿（ACK）： 客户端收到服务器的 SYN+ACK 包后，会发送⼀个带有 ACK 标志位的包作为确认回复。这个包的序列号会加⼀，表 示客户端已经准备好与服务器进⾏数据传输。 此时，TCP 连接已经建⽴起来，通信双⽅可以开始进⾏数据传输。

为什么是三次握手？

三次握⼿的⾸要原因是为了防⽌旧的重复连接初始化造成混乱。

如果是两次握⼿连接，就⽆法阻⽌历史连接，那为什么 TCP 两次握⼿为什么⽆法阻⽌历史连接呢？
我先直接说结论，主要是因为在两次握⼿的情况下，服务端没有中间状态给客户端来阻⽌历史连接，导致服务端可能建⽴⼀个历史连接，造成资源浪费。
你想想，在两次握⼿的情况下，服务端在收到 SYN 报⽂后，就进⼊ ESTABLISHED 状态，意味着这时可以给对⽅发送数据，但是客户端此时还没有进⼊ ESTABLISHED 状态，假设这次是历史连接，客户端判断到此次连接为历史连接，那么就会回 RST 报⽂来断开连接，⽽服务
端在第⼀次握⼿的时候就进⼊ ESTABLISHED 状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到 RST 报⽂后，才会断开连接。

3.TCP四次挥⼿的过程，为什么四次挥手？

四次挥⼿是指在TCP连接的断开过程中，由客户端先断开，然后由服务器进⾏最后的断开。
具体的四次挥⼿步骤如下：

1. 客户端发送⼀个FIN（终⽌）报⽂给服务器，表示客户端不再发送数据。
2. 服务器收到FIN报⽂后，发送⼀个ACK（确认）报⽂给客户端，表示收到了客户端的终⽌请求。
3. 服务器发送⼀个FIN报⽂给客户端，表示服务器也不再发送数据。
4. 客户端收到服务器的FIN报⽂后，发送⼀个ACK报⽂给服务器，确认收到了服务器的终⽌请求，然后关闭连
   接。
   这样，经过四次挥⼿，TCP连接才会完全关闭。因为TCP是全双⼯连接，双⽅都需要通知对⽅停⽌数据传输，所以
   需要四次握⼿来完成断开连接的过程。

可以看到，每个⽅向都需要⼀个 FIN 和⼀个 ACK，因此通常被称为四次挥⼿。

为什么 TCP 挥⼿需要四次呢？

TCP是全双工通信，可以双向传输数据。任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。 当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后才会完全关闭了 TCP 连接。 总结：两次握手可以释放一端到另一端的 TCP 连接，完全释放连接一共需要四次握手

服务器收到客户端的 FIN 报⽂时，内核会⻢上回⼀个 ACK 应答报⽂，但是服务端应⽤程序可能还有数据要发送，所以并不能⻢上发送 FIN 报⽂，⽽是将发送 FIN 报⽂的控制权交给服务端应⽤程序：
如果服务端应⽤程序有数据要发送的话，就发完数据后，才调⽤关闭连接的函数；如果服务端应⽤程序没有数据要发送的话，可以直接调⽤关闭连接的函数，
从上⾯过程可知，是否要发送第三次挥⼿的控制权不在内核，⽽是在被动关闭⽅（上图的服务端）的应⽤程序，因为应⽤程序可能还有数据要发送，由应⽤程序决定什么时候调⽤关闭连接的函数，当调⽤了关闭连接的函数，内核就会发送 FIN 报⽂了，所以服务端的 ACK 和
FIN ⼀般都会分开发送。

4.TCP与UDP的概念，特点，区别和对应的使用场景？

1. TCP与UDP的概念
   ● TCP（传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
   ● UDP（用户数据报协议）为应用程序提供了一种无需建立连接就可以发送封装的IP数据包的方法。
2. 特点
   ● TCP：面向连接，传输可靠，传输形式为字节流，传输效率慢，所需资源多。
   ● UDP：无连接、传输不可靠、传输形式为数据报文段，传输效率快，所需资源少。
3. 区别
   ● 是否面向连接: TCP 是面向连接的传输，UDP 是无连接的传输。
   ● 是否是可靠传输：TCP是可靠的传输服务，在传递数据之前，会有三次握手来建立连接；在数据传递时，有确认、窗口、重传、拥塞控制机制。 UDP是不可靠传输，数据传递不需要给出任何确认，且不保证数据不丢失及到达顺序。
   ● 是否有状态：TCP 传输是有状态的，它会去记录自己发送消息的状态比如消息是否发送了、是否被接收了等等，而 UDP 是无状态的。
   ● 传输形式: TCP 是面向字节流的，UDP 是面向报文的。
   ● 传输效率:由于TCP 传输的时候多了连接、确认重传等机制，所以TCP 的传输效率要比UDP 低。
   ● 首部开销 :TCP 首部开销 (20 ~ 60字节)比UDP 首部开销 (8字节)要大。
   ● 是否提供广播或多播服务: TCP 只支持点对点通信UDP 支持一对一、一对多、多对一、多对多。
4. 对应的使用场景
   ● TCP常用于要求通信数据可靠场景（如网页浏览、文件传输、邮件传输、远程登录、数据库操作
   等）。
   ● UDP常用于要求通信速度高场景（如域名转换、视频直播、实时游戏等）。

5.HTTP请求常见的状态码和字段

6.常见的请求方式？GET和POST请求的区别？

这些区别主要体现在用途、数据传输方式、安全性、数据容量、编码方式、缓存机制、TCP数据包产生方式以及幂等性上。

1. 作用：

   • GET主要用于请求服务器发送资源，例如请求网页、图片或视频等。
   • POST主要用于向服务器提交数据，例如提交表单数据、上传文件等。

2. 参数传递方式：

   • GET参数通过URL传递，这导致数据容易被截取或查看。
   • POST参数放在HTTP请求体中，对外不可见，支持更大的数据量和更多的数据类型。

3. 安全性：

   • GET因参数直接附在URL后，安全性较低，不适合传输敏感信息。
   • POST由于数据在请求体内，安全性较高，适合传输敏感信息。

4. 参数长度限制：

   • GET参数长度受限（通常限制在URL长度约2KB内），限制由浏览器和服务器决定。
   • POST理论上没有数据量限制，适合大量数据传输。

5. 编码方式：

   • GET请求通常只使用application/x-www-form-urlencoded编码类型。
   • POST支持多种编码方式，包括multipart/form-data用于文件上传。

6. 缓存机制：

   • GET请求可以被浏览器缓存，URL可存为书签，并保留在浏览器历史记录中。
   • POST请求不会被浏览器缓存，请求数据不会保存在浏览器历史中，且不能被存为书签。

7. TCP数据包：

   • GET请求一般只生成一个TCP数据包（header和data一起发送）。
   • POST请求一般会生成两个TCP数据包（先发送header，服务器响应100 continue后发送data）。

8. 幂等性：

   • GET是幂等的，多次执行相同的GET请求，服务器上的资源状态不变，结果相同。
   • POST不是幂等的，多次执行相同的POST请求可能会在服务器上创建多份资源，结果不同。

选择GET还是POST请求方式，取决于操作的性质和需求。如果目的是从服务器获取数据且操作对数据没有影响，GET是更合适的选择。如果目的是向服务器提交数据以更改服务器状态或更新资源，应使用POST。在设计Web应用时，了解和正确使用这两种请求方法对于提高应用的安全性、效率和用户体验至关重要。

7.什么是强缓存和协商缓存

在Web开发中，缓存是一种重要的性能优化手段，它可以减少服务器的负载，加快页面的加载速度。缓存策略主要分为两种：强缓存（Strong Cache）和协商缓存（Negotiated Cache）。这两种缓存策略的运用，能有效地控制资源的获取方式，决定资源是从服务器重新获取还是直接从浏览器缓存中读取。

强缓存

强缓存不会向服务器发送请求，直接从缓存中读取资源。强缓存可以通过设置HTTP响应头中的Expires和Cache-Control来实现：

• Expires：HTTP/1.0中存在的字段，用来指定资源到期的时间。如果浏览器发现当前时间小于Expires指定的时间，就会直接使用缓存数据，不会向服务器发起请求。但是，Expires是一个绝对时间，受本地时间影响，可能会导致缓存失效。
• Cache-Control：在HTTP/1.1中引入，更加灵活。它可以通过设置max-age值来控制资源的最大缓存时间（相对时间），优先级高于Expires。例如，Cache-Control: max-age=3600表示资源可以被缓存，且有效期为3600秒。

当强缓存有效时，浏览器不会向服务器发送请求，即使按下刷新按钮，通常也会直接从缓存加载资源，状态码为200，但有时会标记为from cache。

协商缓存

当强缓存失效后，浏览器会向服务器发送请求，由服务器决定是否使用缓存。协商缓存涉及的HTTP头包括Last-Modified/If-Modified-Since和ETag/If-None-Match：

• Last-Modified/If-Modified-Since：服务器通过Last-Modified响应头告诉浏览器资源的最后修改时间。下次浏览器请求时，通过If-Modified-Since请求头发送这个时间。服务器比较时间，如果资源未修改，返回304 Not Modified状态码，浏览器则从缓存中加载资源。
• ETag/If-None-Match：ETag是资源的唯一标识，由服务器生成。浏览器在初次接收到资源时，会保存ETag值，并在下次请求时通过If-None-Match发送这个值。服务器比对ETag，如果未发生变化，则返回304，浏览器继续使用缓存的资源。

协商缓存需要服务器参与，每次都会发送请求到服务器，如果资源未修改，虽然不会下载资源，但是会消耗一定的网络带宽。

总结

• 强缓存优先级高，直接从缓存读取资源，不会发送请求到服务器，极大地减少了网络带宽消耗。
• 协商缓存需要服务器确认资源是否更新，如果资源未更新，返回304状态码，浏览器继续使用缓存的资源。

合理配置强缓存和协商缓存，可以有效提升Web应用的性能和用户体验。

8.HTTP1.0和HTTP1.1的区别？

1. 长连接（Persistent Connections）

• HTTP 1.1 默认支持长连接（Keep-Alive），这意味着在一个TCP连接上可以传输多个HTTP请求和响应，减少了建立和关闭连接的频繁操作，从而减少了延迟，并提高了网络传输效率。
• HTTP 1.0 默认使用短连接，即每个HTTP请求/响应对后都会关闭TCP连接。这会导致每次请求都需要重新建立TCP连接，增加了额外的延迟和网络负担。

2. 缓存

• HTTP 1.0 使用If-Modified-Since和Expires头部作为缓存的判断标准，依赖于资源的最后修改时间和过期时间来控制缓存。
• HTTP 1.1 引入了更多的缓存控制策略，如Entity tag (ETag)和If-None-Match，提供了更灵活和精确的缓存验证机制。

3. 管道化（Pipelining）

• HTTP 1.1 的长连接特性使得管道化成为可能。客户端可以在等待第一个请求的响应时发送后续请求，这可以减少等待时间，理论上提高页面加载速度。但由于响应必须按照请求的顺序返回，且服务器端支持程度不一，实际效果可能有限。

4. 增加Host字段

• HTTP 1.1 引入了必须的Host头部，允许同一个物理服务器上托管多个域名的网站，是虚拟主机技术的关键支持。

5. 状态码

• HTTP 1.1 新增了24个状态响应码，提供了更细粒度的错误处理和更丰富的状态信息。

6. 带宽优化

• HTTP 1.0 存在带宽浪费的问题，比如服务器发送整个资源，即使客户端只需要部分内容。
• HTTP 1.1 通过引入Range请求头和206（Partial Content）响应码支持部分请求和断点续传，显著提高了带宽利用率，尤其是在大文件传输和流媒体服务中非常有用。

9.HTTP2.0与HTTP1.1的区别？

HTTP/2引入了一系列改进HTTP协议的新特性，旨在解决HTTP/1.x（特别是HTTP/1.1）在现代网络环境下面临的性能限制。以下是HTTP/2的主要改进点及其分析：

1. 二进制分帧

• 概念：在应用层（HTTP）和传输层（TCP或UDP）之间增加一个二进制分帧层。这一层负责将所有传输的信息分割成更小的消息和帧，并对它们进行二进制编码。
• 好处：此改进使得HTTP/2能够突破HTTP/1.1的性能限制，实现更低的延迟和更高的吞吐量。二进制协议比传统的文本协议更紧凑，解析速度更快，效率更高。

2. 多路复用（Multiplexing）

• 概念：在一个TCP连接上同时发送多个请求和响应，而不需要等待前一个完成。
• 好处：这解决了HTTP/1.x中的"队头阻塞"问题，即之前的请求延迟会导致后续请求即使已经就绪也无法发送。多路复用使得多个请求和响应可以同时在一个连接上进行，显著提高了网页加载速度和网络利用率。

3. 首部压缩

• 概念：HTTP/2使用HPACK算法对首部（header）数据进行压缩，减少了首部的大小，并减少了发送包的数量。
• 好处：由于HTTP/1.x的首部未经压缩，包含许多重复的首部字段，这会导致不必要的带宽浪费。HTTP/2通过首部压缩，可以减少单个请求-响应的开销，降低延迟，提高传输效率。

4. 服务端推送（Server Push）

• 概念：服务器可以主动推送资源到客户端的缓存中，而无需客户端明确请求。
• 好处：服务端推送可以进一步减少加载时间，因为服务器可以预测客户端需要的资源并提前发送。这减少了往返次数和等待时间，尤其在复杂的应用中可以显著提升性能。

10.HTTPS的工作原理？(https是怎么建立连接的）

这个过程详细描述了使用数字证书进行安全通信的过程，这种机制通常是在HTTPS（HTTP Secure）协议中实现的，用于在互联网上安全地传输数据。以下是对这个过程中的关键步骤和安全机制的分析：

1. 建立连接请求

• 步骤：客户端向服务器发起连接请求，开始SSL/TLS握手过程。

2. 数字证书生成

• 步骤：服务器生成一对公私钥，并将公钥发送给CA（证书颁发机构）申请数字证书。CA使用其私钥对服务器的公钥和一些身份信息进行签名，生成数字证书。
• 安全机制：这一步确保了服务器的公钥是经过可信第三方（CA）验证的，增加了信任度。

3. 证书发送给客户端

• 步骤：服务器将获得的数字证书发送给客户端。
• 安全机制：客户端通过验证数字证书来确认服务器的身份，防止中间人攻击。

4. 客户端验证证书

• 步骤：客户端解析并验证服务器发送的数字证书，确保它是由可信CA签发的。
• 安全机制：客户端内置的CA公钥用于验证数字证书的签名，确保了证书的真实性和服务器的身份。

5. 对称加密密钥的生成

• 步骤：客户端生成一个随机码（对称加密的密钥），用于后续通信。
• 安全机制：对称加密密钥只在客户端和服务器之间共享，保证了传输数据的机密性。

6. 加密的对称密钥传输

• 步骤：客户端用服务器的公钥加密这个随机码，然后发送给服务器。
• 安全机制：即使中间人截获了加密的密钥，也无法解密，因为只有服务器的私钥能解开。

7. 服务端解密对称密钥

• 步骤：服务器用自己的私钥解密收到的加密密钥，获得对称加密的密钥。
• 安全机制：确保了只有服务器能解密并获取对称加密的密钥。

8. 加密数据传输

• 步骤：服务器和客户端使用对称加密密钥加密通信内容。
• 安全机制：对称加密确保了数据传输过程的机密性和完整性。

9. 加密通信

• 步骤：客户端和服务器持续使用对称密钥进行加密通信。
• 安全机制：对称加密的高效性使得加密通信在性能上可行，同时保证了通信安全。

总结

整个过程通过结合非对称加密（用于身份验证和对称密钥的安全交换）和对称加密（用于高效的数据加密通信）的方式，确保了通信的安全性。这种机制既保证了通信双方身份的真实性，又确保了数据传输的机密性和完整性，是现代安全通信不可或缺的部分。