总结12道最多见的计算机网络面试题

时间 2019-11-11

原文原文链接

1. 请详细介绍一下 TCP 的三次握手机制，为何要三次握手？

在讲三次握手以前首先要介绍 TCP 报文中两个重要的字段：一个是序号字段，另外一个是确认号字段，这两个字段将在握手阶段以及整个信息传输过程起到重要做用。html

第一步：客户端 TCP 向服务端的TCP发送一个不带额外数据的特殊 TCP 报文段，该报文段的 SYN 标志位会被置1，因此把它称为 SYN 报文段。这时客户端会选取一个初始序列号（假设为 client_num），并将此编号放置在序号字段中。该报文段会被封装在一个IP数据报中发送给服务器。
第二步：服务器接收到 SYN 报文段后，会为该 TCP 分配缓存和变量，并发送容许链接的确认报文。在容许链接的报文中，SYN 标志位仍被置为1，确认号字段填的是 client_num + 1的值。最后服务端也会选取一个 server_num 存放到序号字段中，这个报文段称为 SYNACK 报文段。
第三步：在接收到 SYNACK 报文段后，客户端最后也要向服务端发送一个确认报文，这个报文和前两个不同，SYN 标志位置0，在确认号字段中填上 server_num + 1的值，而且这个报文段能够携带数据。一旦完成这3个步骤，客户端和服务器之间就能够相互发送包含数据的报文了。

若是不是三次握手，二次两次的话，服务器就不知道客户端是否接收到了本身的 SYNACK 报文段，从而没法创建链接；四次握手就显得多余了。web

2. 讲一讲SYN超时，洪泛攻击，以及解决策略

什么 SYN 是洪泛攻击？在 TCP 的三次握手机制的第一步中，客户端会向服务器发送 SYN 报文段。服务器接收到 SYN 报文段后会为该TCP分配缓存和变量，若是攻击分子大量地往服务器发送 SYN 报文段，服务器的链接资源终将被耗尽，致使内存溢出没法继续服务。redis

解决策略：
当服务器接受到 SYN 报文段时，不直接为该 TCP 分配资源，而只是打开一个半开的套接字。接着会使用 SYN 报文段的源Id，目的Id，端口号以及只有服务器本身知道的一个秘密函数生成一个 cookie，并把 cookie 做为序列号响应给客户端。算法

若是客户端是正常创建链接，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源Id，目的Id，端口号以及秘密函数计算出一个结果，若是结果的值 + 1等于确认字段的值，则证实是刚刚请求链接的客户端，这时候才为该 TCP 分配资源数据库

这样一来就不会为恶意攻击的 SYN 报文段分配资源空间，避免了攻击。小程序

3. 详细介绍一下TCP的四次挥手机制，为何要有TIME_WAIT状态，为何须要四次握手？服务器出现了大量CLOSE_WAIT状态如何解决

当客户端要服务器断开链接时，客户端 TCP 会向服务器发送一个特殊的报文段，该报文段的 FIN 标志位会被置1，接着服务器会向客户端发送一个确认报文段。而后服务器也会客户端发送一个 FIN 标志位为1的终止报文段，随后客户端回送一个确认报文段，服务器当即断开链接。客户端等待一段时间后也断开链接。后端

其实四次挥手的过程是很容易理解的，因为 TCP 协议是全双工的，也就是说客户端和服务端均可以发起断开链接。两边各发起一次断开链接的申请，加上各自的两次确认，看起来就像执行了四次挥手。浏览器

为何要有 TIME_WAIT 状态？由于客户端最后向服务器发送的确认 ACK 是有可能丢失的，当出现超时，服务端会再次发送 FIN 报文段，若是客户端已经关闭了就收不到了。还有一点是避免新旧链接混杂。缓存

大量 CLOSE_WAIT 表示程序出现了问题，对方的 socket 已经关闭链接，而我方忙于读或写没有及时关闭链接，须要检查代码，特别是释放资源的代码，或者是处理请求的线程配置。安全

详情可参考如下博客：

http://www.javashuo.com/article/p-azhbueyb-ce.html

4. 详细讲一下TCP的滑动窗口

从上面的图能够看到滑动窗口左边的是已发送而且被确认的分组，滑动窗口右边是尚未轮到的分组。滑动窗口里面也分为两块，一块是已经发送可是未被确认的分组，另外一块是窗口内等待发送的分组。随着已发送的分组不断被确认，窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动，让还没轮到的分组进入窗口内。

能够看到滑动窗口起到了一个限流的做用，也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率，而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的二者间的最小值。

接着就讲讲什么是流量控制窗口，什么是拥塞控制窗口。

先讲流量控制：

TCP 是全双工的，客户端和服务器都可做为发送方或接收方，咱们如今假设一个发送方向接收方发送数据的场景来说解流量控制。首先咱们的接收方有一块接收缓存，当数据来到时会先把数据放到缓存中，上层应用等缓存中有数据时就会到缓存中取数据。假如发送方没有限制地不断地向接收方发送数据，接收方的应用程序又没有及时把接收缓存中的数据读走，就会出现缓存溢出，数据丢失的现象，为了解决这个问题，咱们引入流量控制窗口。

假设应用程序最后读走的数据序号是 lastByteRead，接收缓存中接收到的最后一个数据序号是 lastByteRcv，接收缓存的大小为 RcvSize，那么必需要知足 lastByteRcv - lastByteRead <= RcvSize 才能保证接收缓存不会溢出，因此咱们定义流量窗口为接收缓存剩余的空间，也就是Rcv = RcvSize - (lastByteRcv - lastByteRead)。只要接收方在响应 ACK 的时候把这个窗口的值带给发送方，发送方就能知道接收方的接收缓存还有多大的空间，进而设置滑动窗口的大小。

接着讲解拥塞控制：

拥塞控制是指发送方先设置一个小的窗口值做为发送速率，当成功发包并接收到ACK时，便以指数速率增大发送窗口的大小，直到遇到丢包（超时/三个冗余ACK），才中止并调整窗口的大小。这么作能最大限度地利用带宽，又不至于让网络环境变得太过拥挤。

最终滑动窗口的值将设置为流量控制窗口和拥塞控制窗口中的较小值。

5. 讲一下HTTP与HTTPS的区别

HTTP和HTTPS的主要区别在于HTTP协议传递的是明文数据，而HTTPS传递的是加密过的数据，也就是说HTTPS更具备安全性。也正由HTTPS须要保证安全性，因此它的性能要比HTTP差一点。

单说安全性确定是不够的，我打算扩展讲一下HTTPS是怎么解决安全性问题的，经过这些HTTP没有机制，反映出HTTPS与HTTP的区别。下面尝试把HTTPS加密的过程推导出来。推导过程不涉及复杂的实现细节：

如何安全地进行数据传输？

假设如今A和B要进行安全的通讯，那么究竟怎样才算是安全的通讯？很天然地会想到：A和B之间传递数据，这些数据只有A和B才看得懂，中间人就算截取了信息但也看不懂，这才算得上安全。

安全通讯的处理手段：

为了能让A和B才能看懂，就必需要对数据进行加密，并且首先想到的就是对称加密。对称加密的意思是A和B各持有一个相同的密钥，它们传递信息时会用密钥给信息加密，在消息到达端给消息解密，完成安全通讯。

在对称加密中又会涉及到加密算法的选择问题。现实世界中，一般是多个客户端面向一个服务器的状况，不可能让每一个客户端和服务器之间都采用相同的加密算法，若是是这样那和没加密差很少。因此注定每一个客户端和服务器之间都会采用不一样的加密方式。

如何让每一个客户端与服务器之间都采用不一样的加密方式？

要想对不一样的机器使用不一样的加密方式，最直接想到的就是使用随机数。也就说客户端和服务器之间每次都基于一个随机数产生加密算法。（具体实现时为了保证随机，用到还不止一个随机数）

这个产生加密算法的过程称之为协商，如今问题是协商的过程是透明的，也就是说中间人能够截获协商的过程，从而知道咱们的加密方式。为了解决这个问题，咱们须要对协商的过程进行加密。

如何对协商的过程进行加密？

之因此能来到这一步，是由于咱们一开始就选择使用了对称加密，也就说一开始的对称加密致使了如今的问题，因此这时咱们不能再使用对称加密了，不然会陷入死循环。

在密码学领域，还有一种加密过程叫非对称加密，它的逻辑是这样的：通讯双方一方持有私钥，一方持有公钥，通过私钥加密的信息，都能经过公钥进行解密。可是通过公钥加密的数据，只有私钥能够解密。

按照非对称加密的规则，咱们让服务器持有私钥，让客户端持有公钥。这样就能保证客户端给服务器发送消息的时候是安全的（相反，服务器给客户端发送消息就是不安全的），咱们能够把协商时重要的逻辑安排在客户端给服务器发送信息的过程当中，从而保证了协商过程的安全性。

客户端如何得到公钥？

如今用非对称加密算法解决了协商的安全问题，可是非对称加密的前提是客户端须要得到公钥，这又是一个问题了，客户端与服务器打交道以前是互不知道双方身份的，怎么才能让客户端得到公钥呢？

也就只有两种办法：

客户端向服务器要公钥
客户端向一个远程的公共服务器获取公钥

方法2显然是不行的，尚且不说多了一个访问节点，如何找到公共服务器的地址也是一个待解决的问题，因此仍是使用方法1。

可是方法1存在一个问题：若是中间人把服务器发送给客户端的公钥调包了怎么办？也就是说客户端没法知道发送公钥的是不是正真的服务器。

引入第三方机构解决问题

客户端没法辨识服务端和中间人的问题称为“身份验证”问题，也就是说咱们须要为服务器向客户端发送公钥的过程进行加密。

这下完了，以前咱们因遇到对称加密的瓶颈选择了非对称加密，如今使用非对称加密也遇到了瓶颈。显然这两种加密方式都是不可用的了，不然会再次陷入死循环。

接下来咱们只好经过第三方机构的介入，解决这个问题。首先咱们本身保存有第三方权威机构的公钥，而后第三方机构使用私钥对服务器将要发送给客户端的公钥进行加密，客户端接收到这个经加密的公钥后（数字证书），就能经过本身保存的第三方机构公钥进行解密。

到这里为止，咱们解释了HTTPS中使用到的对称加密，非对称加密，CA，数字证书的概念，可是还差一个叫数字签名的概念没有解释。

在现实生活中，CA不单止会给咱们正常公司发放证书，还会给中间人的坏公司发放证书，若是中间人把发放的证书调包了怎么办？这时咱们仍能用CA的私钥进行解密，可是证书已经被调包了。

那么客户端怎样验证证书的真伪呢？答案是证书自己会告诉客户端如何辨认真伪。比方说证书上面有一个证书编号，还有一个如何计算证书编号的方法，客户端能够根据计算证书编号的方法计算出本身要得到的证书的编号，而后把这个编号和证书上的编号进行比对，若是同样证实没有被调包。

这里的证书编号指的就是数字签名，证书指的就是数字证书。

总结一下HTTPS：HTTPS想要保证客户端与服务器之间的通讯安全，就得使用对称加密算法进行加密。协商对称加密算法的过程经过非对称加密算法来保证。在非对称加密算法中，客户端得到公钥的过程须要第三方机构（CA）经过颁发数字证书保证安全性。

总得来讲经过这一系列机制协商出了一个对称加密算法后，客户端与服务器之间就能经过该算法进行安全的通讯了。

6. 讲一讲TCP和UDP各有什么特色，二者有什么区别

TCP 是面向链接的，使用 TCP 链接须要通过三次握手，断开链接须要通过四次挥手。相比于 TCP，UDP 则是面向无链接的，它像一个随时能够进行通讯的协议，只要接收方建立了 Socket，设置了监听端口，就能接收到到达的 UDP 包，而且能随时创建 Socket 进行发包。
TCP 能够对数据的发送速率做控制，它具备流量控制和拥塞控制机制，经过控制滑动窗口的大小控制数据的发送速率。而 UDP 理论上是能够无限地向网络中发数据包的，它的发送速率取决它的应用程序设置。
TCP 保证可靠的数据传输，它根据速率控制，重传控制，还有数据校验保证提供可靠的数据传输服务。而 UDP 只是保证尽力而为地传输数据，并不保证数据的可靠性。
TCP 的报文段头部占20各字节，比 UDP 的报文段头部多12个字节。消耗的资源更多。因为创建链接有握手的机制，TCP 的使用效率会比 UDP 要低一些。

7. 在地址栏键入URL后，网络世界发生了什么？

我的以为这个问题还能够扩展一下，试想一下在键入 URL 以前，也就是刚开完机的时候，须要联网，而后才能上网。这个阶段包括了获取本机 IP 地址，获取 DNS 服务器 IP 地址，得到网关路由器 IP 和 MAC 地址等操做，把这些一块儿答上去会不会好一些？如下是回答：

获取本机IP地址，DNS服务器地址，网关路由器地址

首先咱们须要准备一个 DHCP 报文，封装在一个 UDP 报文段中，里面包括本机端口号68和目的端口号67，而后到网络层封装成数据包里面包括了本机的初始IP0.0.0.0，和广播地址255.255.255.255。接着到链路层封装成链路层帧。里面包括广播地址和本机网卡的MAC地址。最后发送到本地局域网中

这个数据包最终会被局域网中的 DHCP 服务器发现（有可能有多个 DHCP 服务器），DHCP 服务器会把可用的 IP 地址返回给咱们的主机。而后操做系统选择一个 IP 地址并发送给 DHCP 服务器，最后 DHCP 服务器会返回一个包含本机 IP，DNS 服务器 IP，网关路由器 IP 的报文。

接下来咱们须要经过网关路由器的 IP 地址去得到网关路由器的 MAC 地址，这样咱们才能够把获取网站 IP 的 DNS 请求报文由网关发送给 DNS 服务器。这时候咱们须要准备一个 ARP 请求报文，请求获取网关路由器的 MAC 地址，这个报文一样是以广播的方式发送到局域网中，网关路由器接受到请求报文就会把本身的 MAC 地址返回给本机。

获取域名的IP地址

接下来一切都准备好了，能够开始讲键入URL以后的事情了：

首先咱们要访问 DNS 服务器得到网站对应的 IP 地址，这时咱们须要把 DNS 报文封装到一个 UDP 报文中，进而封装到网络层的数据包中，填上源 IP，目的 DNS 服务器 IP 地址。接着封装链路层，填上网卡 MAC 地址和网关路由器 MAC 地址。接下来这个 DNS 请求报文就会经网关路由器发送给 DNS 服务器。

咱们假设 DNS 服务器缓存有该网站的 IP 地址，（若是没有缓存会进一步向更高级的DNS服务器索要IP地址）。接着 DNS 服务器会返回该域名的 IP 地址。

三次握手创建TCP链接

拿到了该网站的IP地址后就能够与该网站的服务器创建 TCP 链接了。创建 TCP 链接须要通过三次握手，过程以下：（更详细的过程在开头）

本机的TCP首先生成一个不带任何数据，SYN标志位为1，序号字段假设为client_num的TCP报文，通过下层一系列网络栈后发送给目的ip服务器。
该服务器接受到TCP请求报文后，会回应一个赞成链接的TCP报文，这个报文的SYN标志位也会被置1，序号字段假设为server_num，ACK响应字段为client_num + 1。
接受到赞成链接的报文后，我方主机会进行响应，此次的TCP报文SYN位会被置0，序号字段为client_num + 1，ACK响应字段为server + 1。而且此次的响应报文是能够携带数据的。

创建链接后进行数据交互

在三次握手创建链接后，本机就能够向服务器发送 HTTP 请求了，服务器接受到了请求会作出响应的响应，把请求的数据发送给本机浏览器，最终浏览器把服务器响应的数据渲染显示出来，咱们就看到了五彩缤纷的网页。

8. HTTP的常见状态码有哪些，表明什么含义？

首先状态码的开头不一样表明不一样的类型：
1xx：表明指示信息，表示请求已接收，继续处理
2xx：表明成功，表示请求已被成功接收，理解，接受
3xx：重定向，表示完成请求必须进行进一步的操做
4xx：客户端错误，请求有语法错误或请求没法实现
5xx：服务器端错误，服务器未能实现合法的请求

常见状态码：
200 OK：正常返回信息
400 Bad Request：客户端请求有语法错误，不能被服务器所理解
403 Forbidden：服务器收到请求，可是拒绝提供服务
404 Not Found：请求资源不存在，输入了错误的URL
500 Internal Server Error：服务器发生不可预期错误
503 Server Unavailable：服务器当前不能处理客户端的请求，一段时间后可能恢复正常

9. GET请求和POST请求的区别

从 HTTP 报文层面来看，GET 请求将信息放在 URL，POST 将请求信息放在请求体中。这一点使得 GET 请求携带的数据量有限，由于 URL 自己是有长度限制的，而 POST 请求的数据存放在报文体中，所以对大小没有限制。并且从形式上看，GET 请求把数据放 URL 上感受不太安全，而 POST 请求把数据放在请求体里彷佛安全一些。实际上想要获取 POST 请求中的内容仍是很容易的，所以二者在安全性上其实没有太大差别，想要实现安全的信息传输仍是得靠 HTTPS
从数据库层面来看，GET 符合幂等性和安全性，而 POST 请求不符合。这个其实和 GET/POST 请求的做用有关。按照 HTTP 的约定，GET 请求用于查看信息，不会改变服务器上的信息；而 POST 请求用来改变服务器上的信息。正由于 GET 请求只查看信息，不改变信息，对数据库的一次或屡次操做得到的结果是一致的，认为它符合幂等性。安全性是指对数据库操做没有改变数据库中的数据。
从其余层面来看，GET 请求可以被缓存，GET 请求可以保存在浏览器的浏览记录里，GET 请求的 URL 可以保存为浏览器书签。这些都是 POST 请求所不具有的。缓存是 GET 请求被普遍应用的根本，他可以被缓存也是由于它的幂等性和安全性，除了返回结果没有其余多余的动做，所以绝大部分的 GET 请求都被 CDN 缓存起来了，大大减小了 Web 服务器的负担。

10. 什么是Cookie，Cookie的使用过程是怎么样的？

因为 http 协议是无状态协议，若是客户经过浏览器访问 web 应用时没有一个保存用户访问状态的机制，那么将不能持续跟踪应用的操做。好比当用户往购物车中添加了商品，web 应用必须在用户浏览别的商品的时候仍保存购物车的状态，以便用户继续往购物车中添加商品。

cookie 是浏览器的一种缓存机制，它可用于维持客户端与服务器端之间的会话。因为下面一题会讲到session，因此这里要强调cookie会将会话保存在客户端（session则是把会话保存在服务端）

这里以最多见的登录案例讲解cookie的使用过程：

首先用户在客户端浏览器向服务器发起登录请求
登录成功后，服务端会把登录的用户信息设置 cookie 中，返回给客户端浏览器
客户端浏览器接收到 cookie 请求后，会把 cookie 保存到本地（多是内存，也多是磁盘，看具体使用状况而定）
之后再次访问该 web 应用时，客户端浏览器就会把本地的 cookie 带上，这样服务端就能根据 cookie 得到用户信息了

11. 什么是session，有哪些实现session的机制？

session 是一种维持客户端与服务器端会话的机制。可是与 cookie 把会话信息保存在客户端本地不同，session 把会话保留在浏览器端。

咱们一样以登录案例为例子讲解 session 的使用过程：

首先用户在客户端浏览器发起登录请求
登录成功后，服务端会把用户信息保存在服务端，并返回一个惟一的 session 标识给客户端浏览器。
客户端浏览器会把这个惟一的 session 标识保存在起来
之后再次访问 web 应用时，客户端浏览器会把这个惟一的 session 标识带上，这样服务端就能根据这个惟一标识找到用户信息。

看到这里可能会引发疑问：把惟一的 session 标识返回给客户端浏览器，而后保存起来，之后访问时带上，这难道不是 cookie 吗？

没错，session 只是一种会话机制，在许多 web 应用中，session 机制就是经过 cookie 来实现的。也就是说它只是使用了 cookie 的功能，并非使用 cookie 完成会话保存。与 cookie 在保存客户端保存会话的机制相反，session 经过 cookie 的功能把会话信息保存到了服务端。

进一步地说，session 是一种维持服务端与客户端之间会话的机制，它能够有不一样的实现。以如今比较流行的小程序为例，阐述一个 session 的实现方案：

首先用户登录后，须要把用户登录信息保存在服务端，这里咱们能够采用 redis。好比说给用户生成一个 userToken，而后以 userId 做为键，以 userToken 做为值保存到 redis 中，并在返回时把 userToken 带回给小程序端。
小程序端接收到 userToken 后把它缓存起来，之后每当访问后端服务时就把 userToken 带上。
在后续的服务中服务端只要拿着小程序端带来的 userToken 和 redis 中的 userToken 进行比对，就能肯定用户的登录状态了。

12. session和cookie有什么区别

通过上面两道题的阐述，这道题就很清晰了

cookie 是浏览器提供的一种缓存机制，它能够用于维持客户端与服务端之间的会话
session 指的是维持客户端与服务端会话的一种机制，它能够经过 cookie 实现，也能够经过别的手段实现。
若是用 cookie 实现会话，那么会话会保存在客户端浏览器中
而 session 机制提供的会话是保存在服务端的。

参考：
《计算机网络：自顶向下方法》
http://www.javashuo.com/article/p-snqwjvkn-bu.html
http://www.javashuo.com/article/p-hsektion-cp.html