13、面试整理-网络相关面试题整理

莫欺少年穷007
154 阅读17分钟

1、为什么要有cookie，最开始干嘛用的？

1.1 cookies的起源

早期Web开发面临的最大问题之一是如何管理状态。简言之，服务器端没有办法知道两个请求是否来自于同一个浏览器。那时的办法是在请求的页面中插入一个token，并且在下一次请求中将这个token返回（至服务器）。这就需要在form中插入一个包含token的隐藏表单域，或着在URL的qurey字符串中传递该token。这两种办法都强调手工操作并且极易出错。

1.2 cookie是什么？

一个cookie就是存储在用户主机浏览器中的一小段文本文件。Cookies是纯文本形式，它们不包含任何可执行代码。一个Web页面或服务器告之浏览器来将这些信息存储并且基于一系列规则在之后的每个请求中都将该信息返回至服务器。Web服务器之后可以利用这些信息来标识用户。多数需要登录的站点通常会在你的认证信息通过后来设置一个cookie，之后只要这个cookie存在并且合法，你就可以自由的浏览这个站点的所有部分。再次，cookie只是包含了数据，就其本身而言并不有害。

1.3 创建 cookie

通过HTTP的Set-Cookie消息头，Web服务器可以指定存储一个cookie。Set-Cookie消息的格式如下面的字符串（中括号中的部分都是可选的）

Set-Cookie:value [ ;expires=date][ ;domain=domain][ ;path=path][ ;secure]
1.4 cookie编码

对于cookie的值进行编码一直都存在一些困惑。通常的观点是cookie的值必须被URL编码，但是这其实是一个谬误，尽管可以对cookie的值进行URL编码。原始的文档中指示仅有三种类型的字符必须进行编码：分号，逗号，和空格。规范中提到可以利用URL编码，但是并不是必须。RFC没有提及任何的编码。然而，几乎所有的实现方式都对cookie的值进行了一些列的URL编码。对于name=value的格式，name和value通常都单独进行编码并且不对等号“=”进行编码操作。

1.5 有效期选项

紧跟cookie值后面的每个选项都以分号和空格分割，并且每个选项都指定cookie何时应该被发送到服务器。第一个选项是expires，其指定了cookie何时不会再被发送到服务器端的，因此该cookie可能会被浏览器删掉。该选项所对应的值是一个格式为Wdy,DD-Mon--YYYY HH:MM:SS GMT的值，例如

Set-Cookie:name=Nicholas;expires=Sat, 02 May 2009 23:38:25 GMT
1.6 domain选项

指示cookie将要发送到哪个域或那些域中。默认情况下，domain会被设置为创建该cookie的页面所在的域名。例如本站中的cookie的domain属性的默认值为www.nczonline.com。domain选项被用来扩展cookie值所要发送域的数量。例如:

Set-Cookie:name=Nicholas;domain=nczonline.net

2、IP地址与域名的关系，DNS 干嘛用的？

  • IP地址

IP地址是用来唯一标识互联网上计算机的逻辑地址，让电脑之间可以相互通信. 每台连网计算机都依靠IP地址来互相区分、相互联系。

IP地址采用二进制的形式表示的话很长，比较麻烦，为了便于使用，IP地址经常被写成十进制的形式，用“.”分开，叫做“点分十进制表示法”,如：127.0.0.1。

  • 域名

由于IP地址是数字标识，使用时难以记忆和书写，因此在IP地址的基础上又发展出一种符号化的地址方案，来代替数字型的IP地址。每一个符号化的地址都与特定的IP地址对应，这样网络上的资源访问起来就容易得多了。这个与网络上的数字型IP地址相对应的字符型地址，就被称为域名。

  • DNS

在Internet上域名与IP地址之间是一对一（或者多对一）的，域名虽然便于人们记忆，但机器之间只能互相认识IP地址，它们之间的转换工作称为域名解析，域名解析需要由专门的域名解析服务器来完成，DNS就是进行域名解析的服务器。域名的最终指向是IP。

  • 网址

统一资源定位符（URL，英语UniformResourceLocator的缩写）也被称为网址，网址格式为：<协议>://<域名或IP>:<端口>/<路径>。<协议>://<域名或IP>是必需的，<端口>/<路径>有时可省略。如：www.baidu.com。

3、TCP 与 UDP 的区别？

  • TCP是面向连接的可靠的传输控制协议（流模式），UDP是面向非连接的用户数据报协议.
  • TCP（三次握手保证相对可靠性）可传大量数据，速度相对比较慢，UDP一次性传输少量对可靠性要求不高的数据，速度比较快
  • 对系统资源的要求（TCP较多，UDP少）
  • TCP保证数据正确性，UDP可能丢包，TCP保证数据顺序，UDP不保证

应用

  • TCP：面向连接、传输可靠(保证数据正确性,保证数据顺序)、用于传输大量数据(流模式)、速度慢，建立连接需要开销较多(时间，系统资源)。
  • UDP：面向非连接、传输不可靠、用于传输少量数据(数据包模式)、速度快。
3.1 UDP 详解

用户数据报协议，是一个非连接的协议。传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取应用程序的数据，并尽可能的把它扔到网络上。

  • 1、在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。
  • 2、 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。
  • 3、UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。
  • 4、吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。
  • 5、UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。
  • 6、UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

4、网络状态码

它是用以表示网页服务器HTTP响应状态的3位数字代码。状态码的第一个数字代表了响应的五种状态之一。

7 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。 
408 （请求超时） 服务器等候请求时发生超时。 
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。 
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。 
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。 
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。 
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。 
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。 
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。 
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。 
417 （未满足期望值） 服务器未满足”期望”请求标头字段的要求。
4.5 5XX系列

代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。

**

500 （服务器内部错误） 服务器遇到错误，无法完成请求。 
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。 
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。 
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。 
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。 
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

5、GET 与 POST 的区别？

序言：
1、一般在浏览器中输入网址访问资源都是通过GET方式；在FORM提交中，可以通过Method指定提交方式为GET或者POST，默认为GET提交。
2、Http定义了与服务器交互的不同方法，最基本的方法有4种，分别是GET，POST，PUT，DELETE
3、URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作。到这里，大家应该有个大概的了解了，GET一般用于获取/查询 资源信息，而POST一般用于更新 资源信息(GET和POST的本质区别，也是协议设计者的本意，其它区别都是具体表现形式的差异 )。

  • GET请求, 将参数直接写在访问路径上. 操作简单, 不过容易让外界看到, 安全性不高, 地址最多 255 字节.
  • POST 请求, 将参数放到 body 里面, POST请求的操作相对复杂, 需要将参数和地址分开, 不过安全性高,参数放在body里面, 不容易被捕获.
  • GET使用URL或Cookie传参。而POST将数据放在BODY中。
  • GET的URL会有长度上的限制，则POST的数据则可以非常大。
  • 一般用GET来进行获取数据，因为有缓存，所以可以降低服务器的压力；而POST一般用来进行操作数据，如增删改。
  • GET由于url或者浏览器长度限制，一般参数不能超过1k，而POST没有长度限制，所以进行大文件上传的话用POST。
5.1 GET 相对 POST 的优势是什么

所以如果你希望

  • 请求中的URL可以被手动输入
  • 请求中的URL可以被存在书签里，或者历史里，或者快速拨号里面，或者分享给别人。
  • 请求中的URL是可以被搜索引擎收录的。
  • 带云压缩的浏览器，比如Opera mini/Turbo 2, 只有GET才能在服务器端被预取的。
  • 请求中的URL可以被缓存。

请使用GET

6、图解OSI七层协议模型、TCP/IP四层模型、五层协议体系结构

image.png

OSI七层协议模型、TCP/IP四层模型、五层协议体系结构的示意图如下

image.png

层协议和对应的标准7层协议的关系如下图：

image.png

OSI七层协议模型详细内容可参考这张图

image.png

7、图解URL、URI和URN(区别篇)

URL、URI和URN的区别及联系参考下图：

image.png

8、App网络层有哪些优化策略？

  1. 优化DNS解析和缓存
  2. 对传输的数据进行压缩，减少传输的数据
  3. 使用缓存手段减少请求的发起次数
  4. 使用策略来减少请求的发起次数，比如在上一个请求未着地之前，不进行新的请求
  5. 避免网络抖动，提供重发机制

9、TCP为什么要三次握手，四次挥手？

三次握手：

  1. 客户端向服务端发起请求链接，首先发送SYN报文，SYN=1，seq=x,并且客户端进入SYN_SENT状态
  2. 服务端收到请求链接，服务端向客户端进行回复，并发送响应报文，SYN=1，seq=y,ACK=1,ack=x+1,并且服务端进入到SYN_RCVD状态
  3. 客户端收到确认报文后，向服务端发送确认报文，ACK=1，ack=y+1，此时客户端进入到ESTABLISHED，服务端收到用户端发送过来的确认报文后，也进入到ESTABLISHED状态，此时链接创建成功

四次挥手：

  1. 客户端向服务端发起关闭链接，并停止发送数据
  2. 服务端收到关闭链接的请求时，向客户端发送回应，我知道了，然后停止接收数据
  3. 当服务端发送数据结束之后，向客户端发起关闭链接，并停止发送数据
  4. 客户端收到关闭链接的请求时，向服务端发送回应，我知道了，然后停止接收数据

为什么需要三次握手： 为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误，假设这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。

为什么需要四次挥手： 因为TCP是全双工通信的，在接收到客户端的关闭请求时，还可能在向客户端发送着数据，因此不能再回应关闭链接的请求时，同时发送关闭链接的请求

10、对称加密和非对称加密的区别？分别有哪些算法的实现？

对称加密，加密的加密和解密使用同一密钥。

非对称加密，使用一对密钥用于加密和解密，分别为公开密钥和私有密钥。公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

对称加密常用的算法实现有AES,ChaCha20,DES,不过DES被认为是不安全的;非对称加密用的算法实现有RSA，ECC

11、HTTPS的握手流程？为什么密钥的传递需要使用非对称加密？双向认证了解么？

HTTPS的握手流程，如下图，摘自图解HTTP

image.png

  • 客户端发送Client Hello 报文开始SSL通信。报文中包含客户端支持的SSL的版本，加密组件列表。
  • 服务器收到之后，会以Server Hello 报文作为应答。和客户端一样，报文中包含客户端支持的SSL的版本，加密组件列表。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的
  • 服务器发送Certificate报文。报文中包含公开密钥证书。
  • 然后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束
  • SSL第一次握手结束之后，客户端以Client Key Exchange报文作为会议。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串
  • 接着客户端发送Change Cipher Space报文。该报文会提示服务器，在次报文之后的通信会采用Pre-master secret密钥加密
  • 客户端发送Finished 报文。该报文包含链接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确揭秘该报文作为判定标准
  • 服务器同样发送Change Cipher Space报文。
  • 服务器同样发送Finished报文。
  • 服务器和客户端的Finished报文交换完毕之后，SSL连接建立完成，从此开始HTTP通信，通信的内容都使用Pre-master secret加密。然后开始发送HTTP请求
  • 应用层收到HTTP请求之后，发送HTTP响应
  • 最后有客户端断开连接

为什么密钥的传递需要使用非对称加密？

答：使用非对称加密是为了后面客户端生成的Pre-master secret密钥的安全，通过上面的步骤能得知，服务器向客户端发送公钥证书这一步是有可能被别人拦截的，如果使用对称加密的话，在客户端向服务端发送Pre-master secret密钥的时候，被黑客拦截的话，就能够使用公钥进行解码，就无法保证Pre-master secret密钥的安全了

双向认证了解么？（这里我真想说一句不了解）

答：上面的HTTPS的通信流程只验证了服务端的身份，而服务端没有验证客户端的身份，双向认证是服务端也要确保客户端的身份，大概流程是客户端在校验完服务器的证书之后，会向服务器发送自己的公钥，然后服务端用公钥加密产生一个新的密钥，传给客户端，客户端再用私钥解密，以后就用此密钥进行对称加密的通信

12、HTTPS是如何实现验证身份和验证完整性的？

使用数字证书和CA来验证身份,首先服务端先向CA机构去申请证书，CA审核之后会给一个数字证书，里面包裹公钥、签名、有效期，用户信息等各种信息，在客户端发送请求时，服务端会把数字证书发给客户端，然后客户端会通过信任链来验证数字证书是否是有效的，来验证服务端的身份。

使用摘要算法来验证完整性，也就是说在发送消息时，会对消息的内容通过摘要算法生成一段摘要，在收到收到消息时也使用同样的算法生成摘要，来判断摘要是否一致。

13、如何用Charles抓HTTPS的包？其中原理和流程是什么？

流程：

  1. 首先在手机上安装Charles证书
  2. 在代理设置中开启Enable SSL Proxying
  3. 之后添加需要抓取服务端的地址

原理：

Charles作为中间人，对客户端伪装成服务端，对服务端伪装成客户端。简单来说：

  • 截获客户端的HTTPS请求，伪装成中间人客户端去向服务端发送HTTPS请求
  • 接受服务端返回，用自己的证书伪装成中间人服务端向客户端发送数据内容。

具体流程如下图,图片来自扯一扯HTTPS单向认证、双向认证、抓包原理、反抓包策略

image.png

14、什么是中间人攻击？如何避免？

中间人攻击就是截获到客户端的请求以及服务器的响应，比如Charles抓取HTTPS的包就属于中间人攻击。

避免的方式：客户端可以预埋证书在本地，然后进行证书的比较是否是匹配的

参考网址：
参考1
参考2
参考3
参考4
参考5
参考6
参考7
参考8
参考9

avatar
文章
阅读
粉丝