计算机网络面试题整理-四年经验

I.网络架构

七层网络模型：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

II.三次握手

粗略的目的

• 第一次客户端给服务器发送，服务器能确认客户端的发送、服务器的接收能力。

• 第二次服务器给客户端发送，客户端能确认服务器的发送、客户端的接收能力。同时根据第一次握手，能知道自己的发送、服务器的接收都正常。

为什么需要三次握手

• 因为服务器不知道自己的发送，客户端的接收是否正常，所以需要第三次握手，得到客户端的应答才能做最后的确认。

SYN和ACK

SYN 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK(Acknowledgement[汉译：确认字符 ,在数据通信传输中，接收站发给发送站的一种传输控制字符。它表示确认发来的数据已经接受无误。 ]）消息响应。这样在客户机和服务器之间才能建立起可靠的TCP连接，数据才可以在客户机和服务器之间传递。

位码

位码即tcp标志位，有6种标示：SYN(synchronous建立联机) ACK(acknowledgement 确认) PSH(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急)Sequence number(顺序号码) Acknowledge number(确认号码)

III.四次挥手

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送

• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加1 。和 SYN 一样，一个 FIN 将占用一个序号

• 服务器-关闭与客户端的连接，发送一个FIN给客户端

• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加1

IV.各种协议

1.TCP,UDP 协议的区别

UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 确是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等。

TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

2.TCP 协议如何保证可靠传输

简单来说，数据会分包、TCP有检验和：判断数据有缺失会直接丢掉，而且不确认这次收到了、流量控制、拥塞处理、ARQ协议。

3.DNS

域名系统，能够获取域名对应的ip地址。

V.http协议

1.当输入www.google.com时，页面发生了哪些事情

1. 域名解析检查顺序为：浏览器自身DNS缓存—》OS自身的DNS缓存–》读取host文件–》本地域名服务器–》权限域名服务器–》根域名服务器。如果有且没有过期，则结束本次域名解析。域名解析成功之后，进行后续操作。

2. 三次握手

3. 建立连接，发起http请求。

4. 服务器响应，浏览器得到内容。

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

6. 浏览器对页面渲染，呈现给用户。

2.什么是Http协议无状态协议？怎么解决Http协议无状态协议？

http是无状态的，也就是后续处理无法处理之前的信息。

处理办法有Cookie，Section会话保存，甚至可以用数据库和缓存处理。

3.http协议组成

请求报文包含三部分：

• 请求行：包含请求方法、URI、HTTP版本信息

• 请求首部字段

• 请求内容实体

响应报文包含三部分：

• 状态行：包含HTTP版本、状态码、状态码的原因短语

• 响应首部字段

• 响应内容实体

空行

最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

请求正文

请求数据不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length。

返回值

在接收和解释请求消息后，服务器返回一个HTTP响应消息。

HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文

请求行

请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。

GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源，

POST方法要求被请求服务器接受附在请求后面的数据，常用于提交表单。

个人不推荐用GET，全部用POST比较方便。

请求头部

请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

• User-Agent：产生请求的浏览器类型。

• Accept：客户端可识别的内容类型列表。

• Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。

4.状态码

• 1xx：指示信息–表示请求已接收，继续处理

• 2xx：成功–表示请求已被成功接收、理解、接受

• 3xx：重定向–要完成请求必须进行更进一步的操作

• 4xx：客户端错误–请求有语法错误或请求无法实现

• 5xx：服务器端错误–服务器未能实现合法的请求

5.http的版本 1.0与1.1

在http1.0中，当建立连接后，客户端发送一个请求，服务器端返回一个信息后就关闭连接，当浏览器下次请求的时候又要建立连接，显然这种不断建立连接的方式，会造成很多问题。

在http1.1中，引入了持续连接的概念，通过这种连接，浏览器可以建立一个连接之后，发送请求并得到返回信息，然后继续发送请求再次等到返回信息，也就是说客户端可以连续发送多个请求，而不用等待每一个响应的到来。

6.GET和POST的区别

GET重点是请求数据，POST的重点是提交数据。GET传输数据以URL的方式，POST通过http的post机制，把数据封装在了请求实体中，所以是不可见的，安全性也更高一点。

GET只支持ASCII字符，有可能出现乱码，POST不会。

VI.https和http

HTTPS协议 = HTTP协议 + SSL/TLS协议，在HTTPS数据传输的过程中，需要用SSL/TLS对数据进行加密和解密，需要用HTTP对加密后的数据进行传输，由此可以看出HTTPS是由HTTP和SSL/TLS一起合作完成的。

传输的过程

服务器端的公钥和私钥，用来进行非对称加密。

客户端生成的随机密钥，用来进行对称加密。

Https先用非对称加密，去加密对称加密的密钥，后面的传输都用对称加密算法，因为可以提升性能。

传输步骤

一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。

• 1.客户端向服务器发起HTTPS请求，连接到服务器的443端口

• 2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。

• 3.服务器将自己的公钥发送给客户端。

• 4.客户端收到服务器端的证书之后，会对证书进行检查，验证其合法性，如果发现发现证书有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。

• 5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。

• 6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。

• 7.然后服务器将加密后的密文发送给客户端。

• 8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。

中间人攻击

1. 某网站拥有用于非对称加密的公钥A、私钥A’。
2. 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
3. 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。
4. 浏览器随机生成一个用于对称加密的密钥X，用公钥B（浏览器不知道公钥被替换了）加密后传给服务器。
5. 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。中间人攻击
6. 服务器拿到后用私钥A’解密得到密钥X。
   这样在双方都不会发现异常的情况下，中间人得到了密钥X。根本原因是浏览器无法确认自己收到的公钥是不是网站自己的。

数字证书

网站在使用HTTPS前，需要向“CA机构”申请颁发一份数字证书，数字证书里有证书持有者、证书持有者的公钥等信息，服务器把证书传输给浏览器，浏览器从证书里取公钥就行了，证书就如身份证一样，可以证明“该公钥对应该网站”。

但是证书需要防篡改和防伪。


证书一般用X.509标准来生成。

数字签名

• 流程：
  1.CA拥有非对称加密的私钥和公钥。
  2.CA对证书明文信息进行hash。
  3.对hash后的值用私钥加密，得到数字签名。
  明文和数字签名共同组成了数字证书，这样一份数字证书就可以颁发给网站了。

• 浏览器验证过程：
  拿到证书，得到明文T，数字签名S。
  用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器保有它的公钥，得到S’。
  用证书里说明的hash算法对明文T进行hash得到T’。
  比较S’是否等于T’，等于则表明证书可信

• 中间人有可能篡改该证书吗？
  假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后的签名，
  无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明
  证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

• 中间人有可能把证书掉包吗？
  假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。
  于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之
  后浏览器就会错误地拿到B的证书里的公钥了，会导致上文提到的漏洞。

  其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与
  自己请求的域名比对一下就知道有没有被掉包了。

怎么证明CA机构的公钥是可信的？

操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了。
、证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，叫做信任链或数字证书链，也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
微软的操作系统会预装一些可信的根证书。