计算机网络基础面试题汇总

1. 计算机网络体系知识

1.1 计算机网络体系结构

• TCP / IP的体系结构详细介绍
  

由于 TCP / IP体系结构较为广泛，故主要讲解

1.2 OSI与TCP/IP各层的结构与功能,都有哪些协议?

• 2、TCP和UDP分别对应的常见应用层协议
• TCP对应的应用层协议

FTP：定义了文件传输协议，使用21端口，下载文件，上传主页，都要用到FTP服务

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

SMTP：定义了简单邮件传送协议 25号端口

POP3：它是和SMTP对应，POP3用于接收邮件 110端口

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

• UDP对应的应用层协议

DNS：用于域名解析服务，将域名地址转换为IP地址。DNS用的是53号端口

SNMP：简单网络管理协议，使用161号端口，是用来管理网络设备的

TFTP(Trival File Transfer Protocal)：简单文件传输协议，该协议在熟知端口69上使用UDP服务

• 网络层的ARP协议工作原理
  网络层的ARP协议完成了IP地址与物理地址的映射

1.3 TCP 三次握手和四次挥手(面试必备) 阿里

1、为了准确无误地把数据送达目标处，TCP协议采用了三次握手策略。

名称解释：

• SYN(synchronous 建立连接)
• ACK(acknowledgement 确认)
• PSH(push 传送)
• FIN(finish 结束)

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

• 2 为什么要三次握手

• 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。三次握手就能确认双发收发功能都正常，缺一不可。

三次握手的缺陷：

引起SYN Flood 攻击：SYN-Flood攻击是当前网络上最为常见的DDoS攻击，也是最为经典的拒绝服务攻击。通过向网络服务所在端口发送大量的伪造源地址的攻击报文，就可能造成目标服务器中的半开连接队列被占满，从而阻止其他合法用户进行访问.

如何解决：待补充。

• 3 为什么要传回 SYN
  接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号了。SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ]）消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。
  
• 4、传了 SYN,为啥还要传 ACK
  双方通信无误必须是两者互相发送信息都无误。传了 SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要 ACK 信号来进行验证。
  
  
• 断开一个 TCP 连接则需要“四次挥手”：
  

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

• 5 为什么要四次挥手

• 因为 TCP 是全双工， 每个方向都必须进行单独关闭；
• 任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。不足4次无法确定双方都没有数据发送。

• 6 为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
  网络是不可靠，无法保证(客户端)最后发送的ACK报文一定会被对方收到，TIME_WAIT状态用来重发可能丢失的ACK报文。

1.4 TCP,UDP 协议的区别 阿里

• 1、对比

• 2、TCP 协议如何保证可靠传输（流量控制与拥塞避免）

• 3、ARQ协议
  自动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ包括停止等待ARQ协议和连续ARQ协议。

• 4、拥塞控制（课本知识）
  拥塞控制是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。
  TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。在网络层也可以使路由器采用适当的分组丢弃策略（如主动队列管理 AQM），以减少网络拥塞的发生。

• 算法细节：

为了防止cwnd增长过大引起网络拥塞，还需设置一个慢开始门限ssthresh状态变量

ssthresh的用法如下：

1、当cwnd<ssthresh时，使用慢开始算法（指数规律增长）

2、当cwnd>ssthresh时，改用拥塞避免算法（加法增大）

3、当cwnd=ssthresh时，慢开始与拥塞避免算法任意

发送方判断网络出现拥塞

把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法

1.5 TCP 粘包和拆包问题有了解吗？ 20210204

背景：客户端发送一串消息到服务端，服务端只收到消息的一半，或者当连续发送两个消息到服务端，服务端同时收到这两个消息但无法解析。

拆包粘包产生的原因

• 我们可以通过以下图进行说明
  

1、图一是正常的情况下包的发送和接受，客户端发送p1，p2包，服务端先后接受到p1，p2包，没有发生粘包和拆包。

2、图二是发生了拆包的现象。客户端发送p1，p2包，客户端对p1拆包分成p1_1和p1_2，服务端先后收到p1_1，p1_2和p2包。 拆包发生原因分2种情况：

• 发送的数据大于套接字缓冲区剩余大小。
• 发送的数据大于MTU(最大传输单元)大小。
  在TCP通讯协议中TCP的每个包的头的长度都是固定的，总长度不能超过MTU(最大传输单元)，且数据长度不能超过MSS(MSS=MTU-20bytes(IP包头)-20bytes(TCP包头))。如果超过了MTU系统会进行拆包处理。

以图二为例举个例子：

假设MTU设置的长度为1500bytes，则MSS为1460bytes。客户端发送了p1包数据大小2000bytes。系统判断总长度超过了MTU大小，需要拆包处理。拆成2个包p1_1和p1_2，p1_1的总长度=1460+20+20=1500，p1_2的总长度=2000-1460+20+20=580。发送包p1_1和包p1_2。

3、图三是发生了粘包的现象。客户端发送p1，p2包，p1，p2包到达接收端的缓存，服务端应用读取缓存时无法区分p1，p2各自的大小。因为在TCP通讯协议中TCP是面向流的，包和包之间没有界限。粘包可发生在发送端也可发生在接收端

以图三各举例子：

发送端原因导致的粘包，客户端在发送p1包时，先将p1包放入发送缓存，由于Nagle算法判断其发送的可用数据（去头数据）过小等待一小段时间，这时又发送了p2包，系统将p1和p2合成一个大包发送给服务端。服务端读到大包，无法区分p1和p2包。

接收端原因导致的粘包，服务端缓存接收到客户端发送的p1包，服务端应用未能及时读取缓存，此时服务端缓存又接收到客户端发送的p2包，服务端应用读取缓存，无法区分p1和p2包。

解决方案

• 无论拆包还是粘包本质问题都是无法区分包界限，解决包界限的问题主要有以下几种方式：
• 消息数据的定长，比如定长100字节，不足补空格，接收方收到后解析100字节数据即为完整数据。但这样的做的缺点是浪费了部分存储空间和带宽。
• 消息数据使用特定分割符区分界限，比如使用换号符号做分割。(netty)
• 把消息数据分成消息头和消息体，消息头带消息的长度，接收方收到后根据消息头中的长度解析数据。
• 在实际开发中很多网络框架对TCP拆包粘包问题的解决做了很多支持，比如netty中LineBasedFrameDecoder解析器就是利用换号符号做分割

1.6 TCP 是怎样保持连接的？ 20210204

TCP长连接保持：KeepAlive。

• TCP协议的实现里有一个KeepAlive机制，自动检测能否和对方连通并保持连接。
  TCP识别不同的请求：
• 每个连接建立时，都会保存一个唯一的套接字，有了这个套接字，你就知道对方的IP地址、端口号等信息。这样，通过这个套接字，就可以向指定方发送信息了。

《图解TCP/IP》第五版

2. http详解（http协议、报文结构，断点续传，多线程下载，什么是长连接）

2.1 http协议简介

2.2. HTTP协议的交互流程，从输入网址到获得页面的详细过程？ （有赞）

HTTP协议采用 请求 / 响应 的工作方式

具体工作流程如下：

• HTTP协议的交互流程，常见面试题（百世汇通笔试题）（有赞面试）

2.3. HTTP报文详解-请求报文

HTTP在 应用层 交互数据的方式 = 报文

HTTP的报文分为：请求报文 & 响应报文

• 分别用于 发送请求 & 响应请求时

下面，将详细介绍这2种报文

HTTP的请求报文由 请求行、请求头 & 请求体 组成，如下图

• 组成1：请求行

• 注：空格不能省
  
• 组成介绍
  
  

此处特意说明GET、PSOT方法的区别：

• 示例
  设：请求报文采用GET方法、 URL地址 = http://www.tsinghua.edu.cn/chn/yxsz/index.htm；HTTP1.1版本
  则 请求行是：GET /chn/yxsz/index.htm HTTP/1.1
  
• 组成2：请求头
  作用：声明 客户端、服务器 / 报文的部分信息
  使用方式：采用”header（字段名）：value (值)“的方式
  常用请求头
  

1. 请求和响应报文的通用Header
   
2. 常见请求Header
   

• 举例：
  (URL地址：http://www.tsinghua.edu.cn/chn/yxsz/index.htm）
  Host：www.tsinghua.edu.cn (表示主机域名）
  User-Agent：Mozilla/5.0 (表示用户代理是使用Netscape浏览器）
  
• 组成3：请求体
  
  作用：存放 需发送给服务器的数据信息
  

可选部分，如 GET请求就无请求数据

使用方式：共3种

• 总结
  关于 请求报文的总结如下
  
• 请求报文示例
  

2.4 HTTP报文详解-响应报文

• 报文结构
  HTTP的响应报文包括：状态行、响应头 & 响应体
  

其中，响应头、响应体 与请求报文的请求头、请求体类似

这2种报文最大的不同在于 状态行 & 请求行

下面，将详细介绍每个组成部分

• 结构详细介绍

组成1：状态行

其中，空格不能省

具体介绍

• 状态行 示例
  HTTP/1.1 202 Accepted(接受)、HTTP/1.1 404 Not Found(找不到)
  
• 组成2：响应头
  

常用请求头

1. 请求和响应报文的通用Header
   
2. 常见响应Header
   
   组成3：响应体
   

• 
  
• 作用：存放需返回给客户端的数据信息
  
• 使用方式：和请求体是一致的，同样分为：任意类型的数据交换格式、键值对形式和分部分形式
  
• 响应报文 总结
  
  

2.5 HTTP报文总结

下面，简单总结两种报文结构

2.6 HTTP1.1 与 HTTP1.0的区别

HTTP1.1也是当前使用最为广泛的HTTP协议。 主要区别主要体现在：

2.7 HTTP 与HTTPS的区别 （政采云问到了，特别深入）

对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

补充 SSL 与 TLS区别 ：后续补充 20200307 （政采云问到了）

2.8 https协议的交互流程/SSL的交互流程？ 政采云问到了

• 1、什么是ssl？
  安全套接字协议是web浏览器与web服务器之间安全交换信息的协议
• 2、ssl协议的三个特性
  1、保密：在握手协议中定义了会话密钥后，所有的消息都被加密
  2、鉴别：可选的客户端认证，和强制的服务器端认证
  3、完整性：传送的消息包括消息完整性检查（MAC）
• 3、交互过程

1、客户端请求建立ssl连接，并将自己支持的一套加密规则发送给网站

2、网站从中选出一组加密算法与hash算法，并将自己的身份信息以证书的形式发回浏览器。（证书里面包括网站地址，加密公钥、以及证书的颁布机构）

3、获得网站证书之后浏览器要做以下工作：

验证证书的合法性

如果证书受信任，浏览器会生成一串随机数的密码，并用证书中提供的公钥加密

加密好的随机数发给服务器

4、获得到客户端发的加密了的随机数之后，服务器用自己的私钥进行解密，得到这个随机数，把这个随机数作为对称加密的密钥

5、之后服务器与客户之间就可以用随机数对各自的信息进行加密，解密

2.9 HTTP处理长连接的方式

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

而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

2.10 HTTP是不保存状态的协议,如何保存用户状态?

HTTP 是一种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。

在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

• Cookie 被禁用怎么办?
  最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面

2.11 Cookie的作用是什么?和Session有什么区别？

Cookie 和 Session都是用来跟踪浏览器用户身份的会话方式，但是两者的应用场景不太一样。

Cookie 一般用来保存用户信息 比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的一些基本信息给填了；②一般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了一个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将 Token 重写)；③登录一次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

3. 面试题总结

3.1 http协议常见的状态码有哪些？

可以分为5类

3.2 http中重定向和请求转发的区别？

• 本质区别：转发是服务器行为，重定向是客户端行为。
  重定向特点：两次请求，浏览器地址发生变化，可以访问自己web之外的资源，传输的数据会丢失。
  请求转发特点：一次请求，浏览器地址不变，访问的是自己本身的web资源，传输的数据不会丢失。

3.3 web登录 java安全问题

• 1、http协议传输的安全问题：网络传输中，通过fiddler或wireshark可以捕获http报文中包含的敏感信息，谈到Java应用安全，主要涉及哪些安全机制？
  第一，运行时安全机制 就是限制Java运行时的行为，不要做越权或者不靠谱的事情，在类加载过程中，进行字节码验证，以防止不合规的代码影响JVM运行或者载入其他恶意代码；类加载器本身也可以对代码之间进行隔离，利用SecurityManger机制和相关的组件，限制代码的运行时行为能力，可以看到，Java的安全模型是以代码为中心的，贯穿了从类加载，如URLClassLoader加载网络上的Java类等，到应用程序运行时权限检查等全过程
  第二，Java提供的安全框架API，这是构建安全通信等应用的基础(和厂商相关) 加密、解密API/授权、鉴权API/安全通信相关的类库，比如基本HTTPS通信协议
  第三， 就是JDK集成的各种安全工具
  keytool，这是个强大的工具，可以管理安全场景中不可或缺的秘钥、证书等，并且可以管理Java程序使用的keystore文件。 jarsigner，用于对jar文件进行签名或者验证
  
• 2、加密算法能保证密码安全吗？
  常见的加密算法有对称和非对称加密
  1、对称加密：加密和解密使用相同的密钥加密
  前端加密是写在js里，但是js有风险被直接破解从而识别加密算法
  2、非对称加密：需要两个密钥，公钥和私钥是一对，如果用公开密钥对数据进行加密，只有用对应的私钥才能解密，
  1、https可以保证传输过程中信息不被别人截获，https是应用层协议，下层采用ssl保证信息安全，但是在客户端和服务端，密文同样可以被截获
  2、https报文在传输过程中，如果客户端被恶意引导安装了“中间人”的web信任证书，那么https中“中间人攻击”一样会将明文密码泄漏给别人。（数字摘要）
  3、结论是：无论http还是https，密码必须密文传输
  使用哪个不可逆加密散列函数MD5，并且，使用服务器缓存生成随机的验证字段，并发送给客户端，当客户端登录时，把这个字段一并发送给服务器，用于校验。
  

方案1：验证码 利用开源的验证码生成工具Kaptcha，在服务端存放生成的验证码值以及一个验证码的生成图片，将图片以base64编码，并返回给view，在view中解码base64并加载图片。

方案2：token令牌

前后端分离场景。用户登录时，根据用户的username作为key，生成随机令牌（例如UUID)作为value缓存在redis中，并将token返回给客户端，当客户端登录时，完成校验，并删除redis的那条缓存记录（或者是设置超期，保存半小时）

• 3、客户端不断进行请求链接会怎样？DDos(Distributed Denial of Service)攻击？
  服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认
  1、DDos攻击
  客户端向服务端发送请求链接数据包 -> 服务端向客户端发送确认数据包 -> 客户端不向服务端发送确认数据包,服务器一直等待来自客户端的确认
  2、DDos预防 ( 没有彻底根治的办法，除非不使用TCP )
  限制同时打开SYN半链接的数目/缩短SYN半链接的Time out 时间/关闭不必要的服务
• 4、XSS攻击
  XSS是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到web页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式
  1、XSS攻击的危害
  盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号/非法转账/强制发送电子邮件/控制受害者机器向其它网站发起攻击
  2、原因解析(过于信任客户端提交的数据)
  解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作
  反射性XSS攻击 (非持久性XSS攻击)攻击者注入的数据反映在响应中
  正常：http://www.test.com/message.php?send=Hello,World！
  异常：http://www.test.com/message.php?send= //当其他用户取出数据显示的时候，将会执行这些攻击性代码
  3、修复漏洞方针

1、将重要的cookie标记为httponly, 这样的话Javascript中的document.cookie语句就不能获取到cookie了

（如果在cookie中设置了HttpOnly属性，那么通过js脚本将无法读取到cookie信息，这样能有效的防止XSS攻击）

2、表单数据规定值的类型，例如：年龄应为只能为int、name只能为字母数字组合

3、对数据进行Html Encode 处理

4、过滤或移除特殊的Html标签，例如:

4、线上异常 review

1、线上tomcat线程数使用过多告警排查 20210310补充

排查

参考资料：1、https://mp.weixin.qq.com/s/pB_xYEFkTIlCTWyGRExy3Q

2、图解http

3、https://snailclimb.gitee.io/javaguide