计算机网络面试总结

前言

本人准研三，面临秋招压力，遂总结部分计算基础知识，以备不时之需，有些是从大佬博文摘抄的，都附有相应博文链接，如有遗漏，烦请联系本人更改，如有侵权，我会修改矫正。最后祝各位OFFER多多，进大厂！

以下是计算机网络常见面试题

**一、一次完整的HTTP请求过程

一次完整的HTTP请求过程

当我们在web浏览器的地址栏中输入： www.baidu.com，然后回车，到底发生了什么

过程概览

1.对www.baidu.com这个网址进行DNS域名解析，得到对应的IP地址

2.根据这个IP，找到对应的服务器，发起TCP的三次握手

3.建立TCP连接后发起HTTP请求

4.服务器响应HTTP请求，浏览器得到html代码

5.浏览器解析html代码，并请求html代码中的资源（如js、css图片等）（先得到html代码，才能去找这些资源）

6.浏览器对页面进行渲染呈现给用户

注：1.DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的web浏览器

2.为什么HTTP协议要基于TCP来实现？ TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）

3.最后一步浏览器是如何对页面进行渲染的？ a）解析html文件构成 DOM树，b）解析CSS文件构成渲染树， c）边解析，边渲染 ， d）JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

---

下面我们来详细看看这几个过程的具体细节：

1.域名解析
　　a）首先会搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存）

b）如果浏览器自身的缓存里面没有找到，那么浏览器会搜索系统自身的DNS缓存

c）如果还没有找到，那么尝试从 hosts文件里面去找

d）在前面三个过程都没获取到的情况下，就递归地去域名服务器去查找，具体过程如下

DNS优化：两个方面：DNS缓存、DNS负载均衡

2.TCP连接（三次握手）

拿到域名对应的IP地址之后，User-Agent（一般指浏览器）会以一个随机端口（1024<端口<65535）向服务器的WEB程序（常用的有httpd，nginx）等的80端口。这个连接请求（原始的http请求经过TCP/IP4层模型的层层封包）到达服务器端后（这中间有各种路由设备，局域网内除外），进入到网卡，然后是进入到内核的TCP/IP协议栈（用于识别连接请求，解封包，一层一层的剥开），还有可能要经过Netfilter防火墙（属于内核的模块）的过滤，最终达到WEB程序，最终建立了TCP/IP的连接

图解：

3.建立TCP连接之后，发起HTTP请求

HTTP请求报文由三部分组成：请求行，请求头和请求正文

请求行：用于描述客户端的请求方式，请求的资源名称以及使用的HTTP协议的版本号（例：GET/books/java.html HTTP/1.1）

请求头：用于描述客户端请求哪台主机，以及客户端的一些环境信息等

注：这里提一个请求头 Connection，Connection设置为 keep-alive用于说明 客户端这边设置的是，本次HTTP请求之后并不需要关闭TCP连接，这样可以使下次HTTP请求使用相同的TCP通道，节省TCP建立连接的时间

请求正文：当使用POST, PUT等方法时，通常需要客户端向服务器传递数据。这些数据就储存在请求正文中（GET方式是保存在url地址后面，不会放到这里）

4.服务器端响应http请求，浏览器得到html代码
　　HTTP响应也由三部分组成：状态码，响应头和实体内容

状态码：状态码用于表示服务器对请求的处理结果

列举几种常见的：200（没有问题） 302（要你去找别人） 304（要你去拿缓存） 307（要你去拿缓存） 403（有这个资源，但是没有访问权限） 404（服务器没有这个资源） 500（服务器这边有问题）

若干响应头：响应头用于描述服务器的基本信息，以及客户端如何处理数据

实体内容：服务器返回给客户端的数据

注：html资源文件应该不是通过 HTTP响应直接返回去的，应该是通过nginx通过io操作去拿到的吧

5.浏览器解析html代码，并请求html代码中的资源

浏览器拿到html文件后，就开始解析其中的html代码，遇到js/css/image等静态资源时，就向服务器端去请求下载（会使用多线程下载，每个浏览器的线程数不一样），这是时候就用上 keep-alive特性了，建立一次HTTP连接，可以请求多个资源，下载资源的顺序就是按照代码里面的顺序，但是由于每个资源大小不一样，而浏览器又是多线程请求请求资源，所以这里显示的顺序并不一定是代码里面的顺序。

6.浏览器对页面进行渲染呈现给用户
　　最后，浏览器利用自己内部的工作机制，把请求的静态资源和html代码进行渲染，渲染之后呈现给用户

浏览器是一个边解析边渲染的过程。首先浏览器解析HTML文件构建DOM树，然后解析CSS文件构建渲染树，等到渲染树构建完成后，浏览器开始布局渲染树并将其绘制到屏幕上。这个过程比较复杂，涉及到两个概念: reflow(回流)和repain(重绘)。DOM节点中的各个元素都是以盒模型的形式存在，这些都需要浏览器去计算其位置和大小等，这个过程称为relow;当盒模型的位置,大小以及其他属性，如颜色,字体,等确定下来之后，浏览器便开始绘制内容，这个过程称为repain。页面在首次加载时必然会经历reflow和repain。reflow和repain过程是非常消耗性能的，尤其是在移动设备上，它会破坏用户体验，有时会造成页面卡顿。所以我们应该尽可能少的减少reflow和repain。

JS的解析是由浏览器中的JS解析引擎完成的。JS是单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

自此一次完整的HTTP事务宣告完成.

总结：

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

该部分转载自博客园
**二、HTTPs加密握手过程

HTTPS（全称： Hypertext Transfer Protocol Secure，超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。

• HTTP： 直接通过明文在浏览器和服务器之间传递信息。
• HTTPS： 采用 对称加密 和 非对称加密 结合的方式来保护浏览器和服务端之间的通信安全。
• 对称加密算法加密数据+非对称加密算法交换密钥+数字证书验证身份=安全

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。

• 传统的HTTP协议通信：传统的HTTP报文是直接将报文信息传输到TCP然后TCP再通过TCP套接字发送给目的主机上。
• HTTPS协议通信：HTTPS是HTTP报文直接将报文信息传输给SSL套接字进行加密，SSL加密后将加密后的报文发送给TCP套接字，然后TCP套接字再将加密后的报文发送给目的主机，目的主机将通过TCP套接字获取加密后的报文给SSL套接字，SSL解密后交给对应进程。

具体是如何进行加密，解密，验证的，且看下图。

HTTPS加密请求（一次握手）过程

• 首先，客户端发起握手请求，以明文传输请求信息，包含版本信息，加密-套件候选列表，压缩算法候选列表，随机数，扩展字段等信息(这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。)
• 服务端的配置，采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
• 服务端返回协商的信息结果，包括选择使用的协议版本 version，选择的加密套件 cipher suite，选择的压缩算法 compression method、随机数 random_S 以及证书。(这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。)
• 客户端验证证书的合法性，包括可信性，是否吊销，过期时间和域名。(这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个随机值。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。)
• 客户端使用公匙对对称密匙加密，发送给服务端。(这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。)
• 服务器用私钥解密，拿到对称加密的密匙。(服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。)
• 传输加密后的信息，这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
• 客户端解密信息，客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

加密

客户端和服务端之间的加密机制：

TLS协议是基于TCP协议之上的，图中第一个蓝色往返是TCP的握手过程，之后两次橙色的往返，我们可以叫做TLS的握手。握手过程如下：

• client1：TLS版本号+所支持加密套件列表+希望使用的TLS选项

• Server1:选择一个客户端的加密套件+自己的公钥+自己的证书+希望使用的TLS选项+（要求客户端证书）；

• Client2:(自己的证书)+使用服务器公钥和协商的加密套件加密一个对称秘钥（自己生成的一个随机值）；

• Server2:使用私钥解密出对称秘钥（随机值）后，发送加密的Finish消息，表明完成握手

这里可能要提一下什么是对称加密和非对称加密：

一般的对称加密像这样：

encrypt(明文，秘钥) = 密文
decrypt(密文，秘钥) = 明文

共享密钥加密也称对称密钥加密。采用的是使用相同密钥对报文进行加密解密
我们可以将共享密钥加密这样理解：我们把我们要给别人的东西放到一个箱子里面，然后给箱子上了一把锁。当箱子到了我们想给的那个人
身上时，他也需要这把钥匙才能开锁。
这样就产生了一个问题了，我们怎么将这把钥匙安全的交给对方呢，如果钥匙在半路被人截取了，那么对箱子有没有加锁有什么区别呢。因此
共享密钥加密需要解决的一个大问题就是如何安全的将密钥交给解密方。

也就是说加密和解密用的是同一个秘钥。而非对称加密是这样的：

encrypt(明文，公钥) = 密文
decrypt(密文，私钥) = 明文

假设客户发送报文，服务器接收报文。客户在发送报文的时候需要对报文加密，服务器有两把密钥，一把私钥，一把公钥。客户在发送报文前需要先向服务器获取公钥进行报文的加密。这把公钥只能加密，不能解密，因此被任何人截获到都没什么用处。服务器收到加密后的报文，使用私钥解密。整个过程中只涉及到公钥的获取，加密，密文传输，解密。并不涉及到解密用的私钥传输。因此这种方式是安全的。但是涉及到太多细节，整个流程下来耗时耗费资源。

再拿上面那个例子，这时候我们还想把一些东西锁到箱子里给某人，我们称他为大傻。我们先跟大傻联系，大傻身上有两把钥匙，我们称为钥匙A和钥匙B。钥匙A可以用来造锁，但是造好的锁自己却不能开，只能通过钥匙B来开。跟大傻取得联系后大傻把钥匙A给我们。我们拿着钥匙A找造锁师傅造了一把锁，并且给箱子上锁。然后将带锁的箱子通过物流发给大傻，就算钥匙A被强盗截取了，强盗也开不了箱子。大傻收到箱子后使用那把钥匙B进行开锁，拿到东西。由于钥匙B一直再大傻身上，所以不用担心被人拿走。

加密和解密是需要不同的秘钥的。
经过这几次握手成功后，客服端和服务端之间通信的加密算法和所需要的密钥也就确定下来了，之后双方的交互都可以使用对称加密算法加密了。

HTTPS为了追求性能，又要保证安全，采用了共享密钥加密和公开密钥加密混合的方式进行报文传输。

还是拿上面的锁和箱子的例子来说明。现在我们嫌弃每次加锁都要造个新的锁效率太慢了。我们现在有两个箱子，一个箱子用于方我们要给大傻的东西，并且这个箱子加上了锁。另一个箱子用于存放那把锁的钥匙。我们这时候找大傻拿到钥匙A造了一把锁后将那个存放钥匙的箱子锁起来，然后将这个箱子给大傻，大傻拿到箱子使用钥匙B开锁拿到钥匙。这时候我们将那个存放了东西的箱子给大傻，大傻就可以通过这把钥匙开锁拿到东西了。这样以后我们就可以一直通过这把锁和箱子互相给东西了，而不用发一次数据造一次锁了。

就是说采用共有密钥加密方式传输共享密钥，当共享密钥安全到达服务端后往后的数据就都采用该密钥进行加密解密。

该部分选自简书博客

**三、HTTP状态码的含义

HTTP状态码
当浏览者访问一个网页时，浏览者的浏览器会向网页所在服务器发出请求。当浏览器接收并显示网页前，此网页所在的服务器会返回一个包含HTTP状态码的信息头（server header）用以响应浏览器的请求。

下面是常见的HTTP状态码：

200 - 请求成功


301 - 资源（网页等）被永久转移到其它URL


404 - 请求的资源（网页等）不存在


500 - 内部服务器错误

400 - 请求无效 

403 - 禁止访问 

HTTP状态码分类

HTTP状态码由三个十进制数字组成，第一个十进制数字定义了状态码的类型，后两个数字没有分类的作用。HTTP状态码共分为5种类型：

详细具体含义参考CSDN博文

**四、HTTP的请求构成和响应构成

请求的构成：

1）请求方法URI协议/版本
Request URL: http://localhost:8080/Gary_Text/　　资源的请求url

Request Method: GET　　　　　　　　　　　　 HTTP方：GET

Status Code: 200 OK　　　　　　　　　　　　　 响应状态码

Remote Address: [::1]:8080　　　　　　　　　　 请求的远程地址

根据HTTP标准，HTTP请求可以使用多种请求方法。具体的方法以及区别后面我们介绍。

2）请求头(Request Header)

Accept 可接受的内容类型

Accept-Language 语言

Connection连接状态

Host 请求的域名（这里我设置的是请求本地，当然，关于域名，就是所谓的URL）

User-Agent 浏览器端浏览器型号和版本

Accept-Encoding 可接受的压缩类型 gzip,deflate
3）请求正文

请求头和请求正文之间是一个空行，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息：
username=siki&password=123
在以上的例子中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。

响应的构成

HTTP响应与HTTP请求相似，HTTP响应也由3个部分构成：
1）状态行

2）响应头

3）响应正文

该部分转载自博客园

**五、HTTP1.0和1.1的区别

1、HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠，多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).

在1.0时的会话方式：

1. 建立连接
2. 发出请求信息
3. 回送响应信息
4. 关掉连接

HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。 HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。

2.HTTP 1.1增加host字段

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

3、100(Continue) Status(节约带宽)

HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。