“本篇总结了 12 道最常见的计算机网络面试题,并给出了一些自己的看法,若有不妥之处万望指正。
在讲三次握手之前首先要介绍 TCP 报文中两个重要的字段:一个是序号字段,另一个是确认号字段,这两个字段将在握手阶段以及整个信息传输过程起到重要作用。
如果不是三次握手,两次的话,服务器就不知道客户端是否接收到了自己的 SYNACK 报文段,从而无法建立连接;四次握手就显得多余了。
什么 SYN 是洪泛攻击? 在 TCP 的三次握手机制的第一步中,客户端会向服务器发送 SYN 报文段。服务器接收到 SYN 报文段后会为该 TCP分 配缓存和变量,如果攻击分子大量地往服务器发送 SYN 报文段,服务器的连接资源终将被耗尽,导致内存溢出无法继续服务。
解决策略:当服务器接受到 SYN 报文段时,不直接为该 TCP 分配资源,而只是打开一个半开的套接字。接着会使用 SYN 报文段的源 Id,目的 Id,端口号以及只有服务器自己知道的一个秘密函数生成一个 cookie,并把 cookie 作为序列号响应给客户端。
如果客户端是正常建立连接,将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会根据确认报文的源 Id,目的 Id,端口号以及秘密函数计算出一个结果,如果结果的值 + 1 等于确认字段的值,则证明是刚刚请求连接的客户端,这时候才为该 TCP 分配资源
这样一来就不会为恶意攻击的 SYN 报文段分配资源空间,避免了攻击。
当客户端要服务器断开连接时,客户端 TCP 会向服务器发送一个特殊的报文段,该报文段的 FIN 标志位会被置 1,接着服务器会向客户端发送一个确认报文段。然后服务器也会客户端发送一个 FIN 标志位为 1 的终止报文段,随后客户端回送一个确认报文段,服务器立即断开连接。客户端等待一段时间后也断开连接。
其实四次挥手的过程是很容易理解的,由于 TCP 协议是全双工的,也就是说客户端和服务端都可以发起断开连接。两边各发起一次断开连接的申请,加上各自的两次确认,看起来就像执行了四次挥手。
为什么要有 TIME_WAIT 状态?因为客户端最后向服务器发送的确认 ACK 是有可能丢失的,当出现超时,服务端会再次发送 FIN 报文段,如果客户端已经关闭了就收不到了。还有一点是避免新旧连接混杂。
大量 CLOSE_WAIT 表示程序出现了问题,对方的 socket 已经关闭连接,而我方忙于读或写没有及时关闭连接,需要检查代码,特别是释放资源的代码,或者是处理请求的线程配置。
详情可参考以下博客:https://www.cnblogs.com/sunxucool/p/3449068.html
image
从上面的图可以看到滑动窗口左边的是已发送并且被确认的分组,滑动窗口右边是还没有轮到的分组。滑动窗口里面也分为两块,一块是已经发送但是未被确认的分组,另一块是窗口内等待发送的分组。随着已发送的分组不断被确认,窗口内等待发送的分组也会不断被发送。整个窗口就会往右移动,让还没轮到的分组进入窗口内。
可以看到滑动窗口起到了一个限流的作用,也就是说当前滑动窗口的大小决定了当前 TCP 发送包的速率,而滑动窗口的大小取决于拥塞控制窗口和流量控制窗口的两者间的最小值。
接着就讲讲什么是流量控制窗口,什么是拥塞控制窗口。
先讲流量控制:
TCP 是全双工的,客户端和服务器均可作为发送方或接收方,我们现在假设一个发送方向接收方发送数据的场景来讲解流量控制。首先我们的接收方有一块接收缓存,当数据来到时会先把数据放到缓存中,上层应用等缓存中有数据时就会到缓存中取数据。假如发送方没有限制地不断地向接收方发送数据,接收方的应用程序又没有及时把接收缓存中的数据读走,就会出现缓存溢出,数据丢失的现象,为了解决这个问题,我们引入流量控制窗口。
假设应用程序最后读走的数据序号是 lastByteRead,接收缓存中接收到的最后一个数据序号是 lastByteRcv,接收缓存的大小为 RcvSize,那么必须要满足 lastByteRcv - lastByteRead <= RcvSize 才能保证接收缓存不会溢出,所以我们定义流量窗口为接收缓存剩余的空间,也就是 Rcv = RcvSize - (lastByteRcv - lastByteRead)。只要接收方在响应 ACK 的时候把这个窗口的值带给发送方,发送方就能知道接收方的接收缓存还有多大的空间,进而设置滑动窗口的大小。
接着讲解拥塞控制:
拥塞控制是指发送方先设置一个小的窗口值作为发送速率,当成功发包并接收到 ACK 时,便以指数速率增大发送窗口的大小,直到遇到丢包(超时/三个冗余 ACK ),才停止并调整窗口的大小。这么做能最大限度地利用带宽,又不至于让网络环境变得太过拥挤。
最终滑动窗口的值将设置为流量控制窗口和拥塞控制窗口中的较小值。
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)通过颁发数字证书保证安全性。
总得来说通过这一系列机制协商出了一个对称加密算法后,客户端与服务器之间就能通过该算法进行安全的通信了。
个人觉得这个问题还可以扩展一下,试想一下在键入 URL 之前,也就是刚开完机的时候,需要联网,然后才能上网。这个阶段包括了获取本机 IP 地址,获取 DNS 服务器 IP 地址,获得网关路由器 IP 和 MAC 地址等操作,把这些一起答上去会不会好一些?以下是回答:
首先我们需要准备一个 DHCP 报文,封装在一个 UDP 报文段中,里面包括本机端口号 68 和目的端口号 67,然后到网络层封装成数据包里面包括了本机的初始 IP 0.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 地址返回给本机。
接下来一切都准备好了,可以开始讲键入 URL 之后的事情了:
首先我们要访问 DNS 服务器获得网站对应的 IP 地址,这时我们需要把 DNS 报文封装到一个 UDP 报文中,进而封装到网络层的数据包中,填上源 IP,目的 DNS 服务器 IP 地址。接着封装链路层,填上网卡 MAC 地址和网关路由器 MAC 地址。接下来这个 DNS 请求报文就会经网关路由器发送给 DNS 服务器。
我们假设 DNS 服务器缓存有该网站的 IP 地址,(如果没有缓存会进一步向更高级的DNS服务器索要IP地址)。接着 DNS 服务器会返回该域名的 IP 地址。
拿到了该网站的 IP 地址后就可以与该网站的服务器建立 TCP 连接了。建立 TCP 连接需要经过三次握手,过程如下:(更详细的过程在开头)
在三次握手建立连接后,本机就可以向服务器发送 HTTP 请求了,服务器接受到了请求会做出响应的响应,把请求的数据发送给本机浏览器,最终浏览器把服务器响应的数据渲染显示出来,我们就看到了五彩缤纷的网页。
首先状态码的开头不同代表不同的类型: 1xx:代表指示信息,表示请求已接收,继续处理 2xx:代表成功,表示请求已被成功接收,理解,接受 3xx:重定向,表示完成请求必须进行进一步的操作 4xx:客户端错误,请求有语法错误或请求无法实现 5xx:服务器端错误,服务器未能实现合法的请求
常见状态码: 200 OK:正常返回信息 400 Bad Request:客户端请求有语法错误,不能被服务器所理解 403 Forbidden:服务器收到请求,但是拒绝提供服务 404 Not Found:请求资源不存在,输入了错误的URL 500 Internal Server Error:服务器发生不可预期错误 503 Server Unavailable:服务器当前不能处理客户端的请求,一段时间后可能恢复正常
由于 Http 协议是无状态协议,如果客户通过浏览器访问 web 应用时没有一个保存用户访问状态的机制,那么将不能持续跟踪应用的操作。比如当用户往购物车中添加了商品,web 应用必须在用户浏览别的商品的时候仍保存购物车的状态,以便用户继续往购物车中添加商品。
cookie 是浏览器的一种缓存机制,它可用于维持客户端与服务器端之间的会话。由于下面一题会讲到 session,所以这里要强调 cookie 会将会话保存在客户端( session 则是把会话保存在服务端)
这里以最常见的登陆案例讲解cookie的使用过程:
session 是一种维持客户端与服务器端会话的机制。但是与 cookie 把会话信息保存在客户端本地不一样,session 把会话保留在浏览器端。
我们同样以登陆案例为例子讲解 session 的使用过程:
看到这里可能会引起疑问:把唯一的 session 标识返回给客户端浏览器,然后保存起来,以后访问时带上,这难道不是 cookie 吗?
没错,session 只是一种会话机制,在许多 web 应用中,session 机制就是通过 cookie 来实现的。也就是说它只是使用了 cookie 的功能,并不是使用 cookie 完成会话保存。与 cookie 在保存客户端保存会话的机制相反,session 通过 cookie 的功能把会话信息保存到了服务端。
进一步地说,session 是一种维持服务端与客户端之间会话的机制,它可以有不同的实现。以现在比较流行的小程序为例,阐述一个 session 的实现方案:
经过上面两道题的阐述,这道题就很清晰了
参考: 《计算机网络:自顶向下方法》 https://www.cnblogs.com/zhangshitong/p/6478721.html https://www.cnblogs.com/jiangxinyang/p/8453827.html