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

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

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

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

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

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

为什么是三次握手？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作用：
- GET主要用于请求服务器发送资源，例如请求网页、图片或视频等。
- POST主要用于向服务器提交数据，例如提交表单数据、上传文件等。
参数传递方式：
- GET参数通过URL传递，这导致数据容易被截取或查看。
- POST参数放在HTTP请求体中，对外不可见，支持更大的数据量和更多的数据类型。
安全性：
- GET因参数直接附在URL后，安全性较低，不适合传输敏感信息。
- POST由于数据在请求体内，安全性较高，适合传输敏感信息。
参数长度限制：
- GET参数长度受限（通常限制在URL长度约2KB内），限制由浏览器和服务器决定。
- POST理论上没有数据量限制，适合大量数据传输。
编码方式：
- GET请求通常只使用application/x-www-form-urlencoded编码类型。
- POST支持多种编码方式，包括multipart/form-data用于文件上传。
缓存机制：
- GET请求可以被浏览器缓存，URL可存为书签，并保留在浏览器历史记录中。
- POST请求不会被浏览器缓存，请求数据不会保存在浏览器历史中，且不能被存为书签。
TCP数据包：
- GET请求一般只生成一个TCP数据包（header和data一起发送）。
- POST请求一般会生成两个TCP数据包（先发送header，服务器响应100 continue后发送data）。
幂等性：
- 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的区别？

长连接（Persistent Connections）

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

缓存

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

3. 管道化（Pipelining）