计算机网络常见面试题

本贴最后更新于 1275 天前,其中的信息可能已经沧海桑田

1. TCP 三次握手和四次挥手

1.1 TCP 三次握手和四次挥手的过程

img

** **三次握手

(1)第一次握手:Client 将标志位 SYN 置为 1,随机产生一个值 seq=J,并将该数据包发送给 Server,Client 进入 SYN_SENT 状态,等待 Server 确认。**
****(2)第二次握手:Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接,Server 将标志位 SYN 和 ACK 都置为 1,ack=J+1,随机产生一个值 seq=K,并将该数据包发送给 Client 以确认连接请求,Server 进入 SYN_RCVD 状态。****
****(3)第三次握手:Client 收到确认后,检查 ack 是否为 J+1,ACK 是否为 1,如果正确则将标志位 ACK 置为 1,ack=K+1,并将该数据包发送给 Server,Server 检查 ack 是否为 K+1,ACK 是否为 1,如果正确则连接建立成功,Client 和 Server 进入 ESTABLISHED 状态,完成三次握手,随后 Client 与 Server 之间可以开始传输数据了。**

img

** **四次挥手

(1)第一次挥手:Client 发送一个 FIN,用来关闭 Client 到 Server 的数据传送,Client 进入 FIN_WAIT_1 状态。**
(2)第二次挥手:Server 收到 FIN 后,发送一个 ACK 给 Client,确认序号为收到序号 +1(与 SYN 相同,一个 FIN 占用一个序号),Server 进入 CLOSE_WAIT 状态。
(3)第三次挥手:Server 发送一个 FIN,用来关闭 Server 到 Client 的数据传送,Server 进入 LAST_ACK 状态。
**(4)第四次挥手:Client 收到 FIN 后,Client 进入 TIME_WAIT 状态,接着发送一个 ACK 给 Server,确认序号为收到序号 +1,Server 进入 CLOSED 状态,完成四次挥手。

1.2 为什么不是两次握手 四次握手?

** 这是为了避免服务器建立无用连接****(客户端服务器建立连接后,却不传输数据)**

** **如果只进行两次握手,如果客户端向服务器第一次发送的建立连接的请求因为某原因,兜兜转转绕了一大圈才到达服务器。这期间客户端因为未收到服务器的响应,就会再次发送连接请求,这时服务器收到了,向客户端发送连接请求后,连接便建立了。然后数据传输完毕后,释放连接。这时刚刚兜兜转转一大圈的建立连接的请求到了服务器,服务器收到后再次向客户端发送请求,发送后又建立了连接,但是建立连接后客户端没有再理会服务器,客户端与服务器之间没有传输数据,此时服务器的资源就会被浪费

** **为什么不是四次握手

** 因为通信不可能 100% 可靠, 而上面的三次握手已经做好了通信的准备工作, 再增加握手, 并不能显著提高可靠性,所以只需要三次握手就足够了**

1.3 为什么 TCP 建立连接需要三次握手,断开连接需要四次挥手

  • **建立连接的时候, 服务器在 LISTEN 状态下,收到建立连接请求的 SYN 报文后,**把 ACK 和 SYN 放在一个报文里发送给客户端
  • **关闭连接时,服务器收到对方的 FIN 报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送 FIN 报文给对方来表示同意现在关闭连接,因此,**己方 ACK 和 FIN 一般都会分开发送,从而导致多了一次

1.4 TCP 四次挥手为什么有 Time-Wait 过程

** **虽然按道理,四个报文都发送完毕,我们可以直接进入 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 连接。

1.5 TCP 第三次握手可以传输数据吗

** ****不能,需要三次握手成功之后才开始发送数据 **

2. TCP 和 UDP 的区别

** 答: **

  1. **连接:UDP 是无连接的,发送数据之前无需建立连接,发送数据结束后也无需释放连接。TCP 是面向连接的,在发送数据之前需要通过三次握手建立连接,发送数据结束后需要通过四次挥手释放连接。 **
  2. **交付:UDP 使用尽最大努力交付,即不保证可靠交付,主机不需要维持复杂的连接状态表。TCP 提供可靠交付,即通过 TCP 连接传送的数据,无差错、不丢失、不重复,并且按序到达。 **
  3. **数据:UDP 是面向报文的,UDP 对于应用层交下来的报文,添加首部后就向下交给 IP 层,既不合并,也不拆分,一次交付一个完整的报文。TCP 是面向字节流的,虽然应用程序和 TCP 的交互是一次一个数据块(大小不等),但 TCP 把应用程序交下来的数据看出成一连串无结构的字节流。TCP 不保证接收方应用程序所收到的数据块和发送方应用程序所发出的数据块具有对应大小关系。 **
  4. **通信双方:UDP 支持一对一、一对多、多对一、多对多的交互通信。TCP 连接是点对点(一对一),每一条 TCP 连接只能有两个端点。 **
  5. 拥塞:UDP 没有拥塞控制,网络的拥塞不会使源主机的发送速率降低。TCP 通过慢开始、拥塞避免、快重传、快恢复等**进行拥塞控制。 **
  6. **首部:UDP 首开销小,只有 8 个字节。TCP 首部是 20 个字节。 **

3. TCP 的可靠传输

3.1 TCP 如何确保可靠性传输

** **** 对 TCP 而言在三次握手时的 SYN 标志会使用上一个 ISN 值,这个值是使用 32 位计数器,内由 0-4294967295,每一次连接容都会分配到一个 ISN 值,连接双方对这个值会记录共识,假如这个值不一,就说明了这个连接已超时或无效甚至是被人恶意攻击冒充连接。 **

**3.2 TC 的流量控制 (防止发送方发的太快,耗尽接收方的资源,从而使接收方来不及处理) **

** **1.滑动窗口是什么?

** 滑动窗口是类似于一个窗口一样的东西,是用来告诉发送端可以发送数据的大小或者说是窗口标记了接收端缓冲区的大小,这样就可以实现 **ps:窗口指的是一次批量的发送多少数据

** **2.为什么会出现滑动窗口?

** **在确认应答策略中,对每一个发送的数据段,都要给一个 ACK 确认应答,收到 ACK 后再发送下一个数据段,这样做有一个比较大的缺点,就是性能比较差,尤其是数据往返的时间长的时候

** **使用滑动窗口,就可以一次发送多条数据,从而就提高了性能

3.3 TCP 的拥塞控制( 防止发送方发的太快,使得网络来不及处理,从而导致网络拥塞 )

  1. **慢开始 **

** img **

** ****2. 拥塞避免 **

** img **

  1. **快重传 **
    当发送方没有按时收到某个应当按时到达的确认报文时,就会要求接收方每收到一个失序的报文段后就会立即发出重复确认,连续收到三个重复确认后,发送方立即重传未被确认的报文。
  2. **快恢复 ****
    **发送方收到三个重复确认后,会把慢开始门限 ssthresh 设置为出现拥塞时拥塞窗口值的一半,并令拥塞窗口值与其相等,然后执行拥塞避免算法,使拥塞窗口缓慢线性增大。

3.4 TCP 传输通信时,客户端突然断开连接,服务端如何判断

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

4. 常见的 HTTP 状态码

** 301,302,304,403,404,500,503 **

****301 Moved Permanently:******永久性重定向,表示请求的资源被分配了新的 URL,之后应使用更改的 URL; **

****302 Found:****临时性重定向,表示请求的资源被分配了新的 URL,希望本次访问使用新的 URL;

** 301 与 302 的区别:前者是永久移动,后者是临时移动(之后可能还会更改 URL)**

304 Not Modified**:表示客户端发送附带条件的请求时,服务器端允许访问资源,但是请求未满足条件的情况下返回改状态码;**

****403 Forbidden:****服务器拒绝该次访问(访问权限出现问题)

****404 Not Found:****表示服务器上无法找到请求的资源,除此之外,也可以在服务器拒绝请求但不想给拒绝原因时使用;

****500 Inter Server Error:****表示服务器在执行请求时发生了错误,也有可能是 web 应用存在的 bug 或某些临时的错误时;

****503 Server Unavailable:****表示服务器暂时处于超负载或正在进行停机维护,无法处理请求;

5. HTTP 报文

5.1 HTTP 请求报文和响应报文的组成

img

5.2 HTTP 请求报文包含哪些方法, GET 和 POST 的区别

  1. **参数位置:GET 方法参数位置包含在 URL,POST 方法参数包含在请求主体 **
  2. **参数长度:GET 方法的 URL 长度有限度,POST 长度没有限制 **
  3. **参数编码:GET 方法参数编码是 ASCII 码,POST 没有限制 **
  4. **TCP 数据包:GET 方法产生一个 TCP 数据包,把首部和数据一起发送,POST 方法产生两个 TCP 数据包,先发首部,服务器响应后再发数据 **

6. HTTP 和 HTTPS 的区别

  1. **端口 :HTTP 的 URL 由“http://”起始且默认使用端口 80,而 HTTPS 的 UR 由“https://”起始且默认使用端口 443。 **
  2. 安全性和资源消耗: HTTP 协议运行在 TCP 之上,所有传输的内容都是明文,**和服务器端都无法验证对方的身份。HTTPS 是运行在 SSL/TLS 之上的 HTTP 协议,SSL/TLS 运行在 TCP 之上。所有传输的内容都经过加密,加密采用对称加密,但对称加密的密钥用服务器方的证书进行了非对称加密。所以说,HTTP 安全性没有 HTTPS 高,但是 HTTPS 比 HTTP 耗费更多服务器资源。 **
  3. 对称加密:密钥只有一个,加密解密为同一个密码,且加解密速度快,典型的对称加密**有 DES、AES 等; **

** img **

  1. 非对称加密:密钥成对出现(且根据公钥无法推知私钥,根据私钥也无法推知公钥),加密解密使用不同密钥(公钥加密需要私钥解密,私钥加密需要公钥解密),相对对称加密速度较慢,典型的非对称加密**有 RSA、DSA 等。 **
  2. img

7. HTTP1.0 和 1.1 和 2.0 的区别

**HTTP1.0 和 HTPP1.1 的区别 **
  1. **缓存处理:在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准,HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag,If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。 **
  2. 带宽优化及网络连接的使用:HTTP1.0 中,存在一些浪费带宽的现象,例如**只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1 则在请求头引入了 range 头域,它允许只请求资源的某个部分,即返回码是 206(Partial Content),这样就方便了开发者自由的选择以便于充分利用带宽和连接。 **
  3. **错误通知的管理:在 HTTP1.1 中新增了 24 个错误状态响应码,如 409(Conflict)表示请求的资源与资源的当前状态发生冲突;410(Gone)表示服务器上的某个资源被永久性的删除。 **
  4. **Host 头处理:在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址,因此,请求消息中的 URL 并没有传递主机名(hostname)。但随着虚拟主机技术的发展,在一台物理服务器上可以存在多个虚拟主机(Multi-homed Web Servers),并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都应支持 Host 头域,且请求消息中如果没有 Host 头域会报告一个错误(400 Bad Request)。 **
  5. **长连接:HTTP 1.1 支持长连接(PersistentConnection)和请求的流水线(Pipelining)处理,在一个 TCP 连接上可以传送多个 HTTP 请求和响应,减少了建立和关闭连接的消耗和延迟,在 HTTP1.1 中默认开启 Connection: -alive,一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。 **
**HTTP2.0 与 HTTP1.x 的区别 **
  1. **新的二进制格式(Binary Format):HTTP1.x 的解析是基于文本。基于文本协议的格式解析存在天然缺陷,文本的表现形式有多样性,要做到健壮性考虑的场景必然很多,二进制则不同,只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式,实现方便且健壮 **
  2. **多路复用(MultiPlexing):即连接共享,即每一个 request 都是是用作连接共享机制的。一个 request 对应一个 id,这样一个连接上可以有多个 request,每个连接的 request 可以随机的混杂在一起,接收方可以根据 request 的 id 将 request 再归属到各自不同的服务端请求里面。 **
  3. **header 压缩:HTTP1.x 的 header 带有大量信息,而且每次都要重复发送,HTTP2.0 使用 encoder 来减少需要传输的 header 大小,通讯双方各自 cache 一份 header fields 表,既避免了重复 header 的传输,又减小了需要传输的大小。 **
  4. **服务端推送(server push):同 SPDY 一样,HTTP2.0 也具有 server push 功能。 **

8. HTTPS 密钥交换过程

** **img

  1. 证书验证,发送一个证书请求个服务器端,服务器端返回证书,**对证书进行验证。 **
  2. 交换密钥,使用非对称加密,**使用公钥进行加密,服务器端使用密钥解密。 **
  3. **交换数据,使用对称加密的方式对数据进行加密,然后进行传输。 **

9. 输入 URL 跳转网页的过程

  1. **DNS 域名解析 **
  2. **HTTP 协议生成请求报文 **
  3. **TCP 协议将请求报文分割成报文段,进行可靠传输 **
  4. **IP 协议进行分组转发 **
  5. **TCP 协议重组请求报文 **
  6. **HTTP 协议对请求进行处理 **

10. 计算机网络四层协议,五层协议,七层协议

** **img

**TCP/IP 协议各层的作用 **
  1. **应用层:应用层的任务是通过应用进程之间的交互来完成特定网络应用。应用层协议定义的是应用进程间通信和交互的规则。这里的进程是指主机中正在与运行的程序。对于不同的网络应用需要有不同的应用层协议。在互联网中的应用层协议有很多,如域名系统 DNS,支持万维网应用的 HTTP 协议,支持电子邮件的 SMTP 协议,等等。 **
  2. **传输层:传输层的任务是负责向两台主机中进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。主要有 TCP 协议和 UDP 协议。 **
  3. **网络层:网络层的任务是为分组交换网上的不同主机提供通信服务。在发送数据的时候,网络层把运输层产生的报文段或者用户数据报封装成分组或包进行传送。主要使用 IP 协议。 **
  4. 网络接口层:操作系统中的设备驱动和计算机对应的网络接口,它们一起处理与传输媒介的物理接口细节。主要有 ARP 协议和

11. 什么是 cookie 和 session,区别是什么, 禁用 cookie 怎么办

** 答: **

  1. 储存位置:Cookie 是会话技术,数据保存在**,Session 是服务器端会话技术,数据保存在服务器端。 **
  2. **存储容量:Cookie 一般 <=4KB,Session 无限制。 **
  3. **跨域支持:Cookie 支持跨域,Session 不支持。 **

当用户禁止 cookie 以后,如果要访问某个需要 session 机制支持的 web 组件(jsp/servlet),此时,不能直接在浏览器地址栏输入该组件的地址,要使用服务器生成的地址,该地址可以使用以下方法来实现:**
response.encodeURL(String url);
//该方法会在 url 后面添加 sessionId。
**//该方法用在链接地址、表单提交地址。

//如果是重定向,则使用**
response.encodeRedirectURL(String url);
**response.sendRedirect(response.encodeRedirectURL(String url));

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...