悠闲の小屋

面试之计算机网络-2

#HTTPS是如何保证数据传输的安全，整体的流程是什么？

（SSL是怎么工作保证安全的）

https://www.cnblogs.com/fangdada/p/15686204.html

image

ECDHE过程：

  1. 客户端首先会发送使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）
  2. 当服务端收到客户端的消息后，会确认 TLS 版本号，选择ECDHE密码套件，以及生成随机数（Server Random），并会发送数字证书给客户端。
  3. 然后服务端会选择一个椭圆曲线，如x25519曲线，生成随机数作为私钥，再根据椭圆曲线和私钥计算出服务端的公钥，利用签名算法签名，并将曲线、公钥和签名发送给客户端。
  4. 客户端验证证书是否合法，合法则生成随机数作为客户端私钥，利用私钥和椭圆曲线计算出客户端公钥后发送给服务端。
  5. 双方利用客户端随机数和服务端随机数和ECDHE算出的共享密钥计算出会话密钥来加密通话。互相验证加密和解密是否成功，并且验证消息是否被篡改。
  6. 最后进行HTTP通信。

image RSA过程：

  1. 客户端首先会发送使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）
  2. 当服务端收到客户端的消息后，会确认 TLS 版本号，选择RSA密码套件，以及生成随机数（Server Random），并会发送数字证书给客户端。
  3. 客户端验证证书是否合法，判断服务器是否真实，取出服务端公钥。
  4. 接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的公钥加密该随机数，传给服务端。
  5. 然后，利用前面的3个随机数生成「会话密钥」，把之前所有发送的数据做个摘要，用会话密钥（master secret）加密。
  6. 服务器也是同样的操作，如果双方都验证加密和解密没问题，那么握手正式完成。
  7. 最后，就用「会话密钥」加解密 HTTP 请求和响应了。 RSA是缺点是不支持前向保密，一旦服务器的私钥泄漏了，则之前的通信内容就被破解。

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

#22、如何保证公钥不被篡改？

将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

  • 首先 CA 会把持有者的公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
  • 然后 CA 会使用自己的私钥将该 Hash 值加密，生成证书签名；
  • 最后将证书签名添加在文件证书上，形成数字证书；

#公钥加密计算量太大，如何减少耗用的时间？

https://stardust567.github.io/post/84d.html 解决方法：握手阶段使用非对称加密，通信采取对称加密的方式(使用对话密钥)并且使用ECDHE作为加密套件。

#HTTP请求和响应报文有哪些主要字段？

请求报文 HTTP请求报文和HTTP响应报文

  • 请求行：Request Line （请求方法、url、协议版本）
  • 请求头：Request Headers（键值对组成，如host、user-agent、accept）
  • 请求体：Request Body

响应报文

  • 状态行：Status Line （协议版本；响应状态代码；状态代码的文本描述）
  • 响应头：Response Headers（content-type、content-length、server、connection）
  • 响应体：Response Body

#Cookie是什么？

HTTP 协议是无状态的，HTTP/1.1 引入 Cookie 来保存状态信息。

Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被携带上，用于告知服务端是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。

#Cookie有什么用途？

  • 会话状态管理（如用户登录状态）
  • 喜好设置（存储用户偏好等设置，向用户显示喜好内容）
  • 浏览器行为跟踪（如跟踪分析用户行为等）

#Session知识大总结

除了可以将用户信息通过 Cookie 存储在用户浏览器中，也可以利用 Session 存储在服务器端，存储在服务器端的信息更加安全。

Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。

使用 Session 维护用户登录状态的过程如下：

  1. 用户进行登录时，提交包含用户名和密码的表单，放入 HTTP 请求报文中；
  2. 服务器验证该用户名和密码，如果正确则把用户信息存储到本地中，生成一个 Session ID；
  3. 服务器返回的响应报文的 Set-Cookie 首部字段包含了这个 Session ID，客户端收到响应报文之后将该 Cookie 值存入浏览器中；
  4. 客户端之后对同一个服务器进行请求时会包含该 Cookie 值，服务器收到之后提取出 Session ID，从本地中取出用户信息，继续之前的业务操作。

注意：Session ID 的安全性问题，不能让它被恶意攻击者轻易获取，那么就不能产生一个容易被猜到的 Session ID 值。此外，还需要经常重新生成 Session ID。在对安全性要求极高的场景下，例如转账等操作，除了使用 Session 管理用户状态之外，还需要对用户进行重新验证，比如重新输入密码，或者使用短信验证码等方式。

#Session 的工作原理是什么？

session 的工作原理是客户端登录完成之后，服务器会创建对应的 session，然后把 session 的 id 发送给客户端，客户端再存储到浏览器中。这样客户端每次访问服务器时，都会带着 session id，服务器拿到 session id 之后，在内存找到与之对应的 session 这样就可以正常工作了。

#Cookie与Session的对比

https://mp.weixin.qq.com/s/cuTmhjnzdngE0EEb5RlbxQ

  • 存储范围不同，Cookie 保存在客户端(浏览器)，Session 保存在服务器端。
  • 存储方式的不同，Cookie只能保存 ASCII，Session可以存任意数据类型，比如UserId等。（跟get/post一样）
  • 存储时限不同，Cookie可设置为长时间保持，比如默认登录功能，Session一般有效时间较短，客户端关闭或者Session超时都会失效。
  • 存储大小不同， 单个Cookie 保存的数据不能超过 4K，Session可存储数据远高于Cookie。
  • 隐私策略不同，Cookie存储在客户端，信息容易被窃取;Session存储在服务端，相对安全一些。

#SQL注入攻击了解吗？

https://www.jianshu.com/p/078df7a35671

攻击者在HTTP请求中注入恶意的SQL代码，服务器使用请求中的参数拼接数据库SQL命令时，恶意SQL被一起拼接，并在数据库中执行。

用户登录，输入用户名 123' or 1=1 # ，密码 any ，如果此时使用参数构造的方式，就会出现

1

select * from users where username='123' or 1=1 #' and password='123' or 1=1 #'

按照 Mysql 语法，# 后面的内容会被忽略。由于判断语句 or 1=1 恒成立，所以结果当然返回真，成功登录。

#如何防范SQL注入攻击

Web端

  • 有效性检验。
  • 限制字符串输入的长度。

服务端

  • 避免使用动态SQL。
  • 使用预编译的PreparedStatement。
  • 有效性检验。(为什么服务端还要做有效性检验？第一准则，外部都是不可信的，防止攻击者绕过Web端请求)
  • 过滤SQL需要的参数中的特殊字符。比如单引号、双引号。

#什么是RARP？工作原理

概括： 反向地址转换协议，是网络层协议，RARP与ARP工作方式相反。 RARP使只知道自己硬件地址的主机能够知道其IP地址。

原理：

  1. ~~网络上的每台设备都会有一个独一无二的硬件地址。~~主机从网卡上读取MAC地址，然后在网络上发送一个RARP请求的广播数据包。
  2. RARP服务器响应该RARP请求，为其分配IP地址，并将IP地址发送给主机。
  3. 主机收到RARP回应后，就可以使用得到的IP地址进行通讯。

无非就是发包，响应包，得到内容

#端口有效范围是多少到多少？

0-1023为知名端口号，比如其中HTTP是80，FTP是20（数据端口）、21（控制端口）

UDP和TCP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。动态端口的范围是从1024到65535

#为何把 TCP/IP 协议栈分成 5 层（或7层）？开放式回答。

分层的好处：

  1. 易维护与实现，将一个难以处理的复杂问题分解为若干个较容易处理的更小的问题。
  2. 灵活性好，各层之间是独立的。任何一层发生变化时，只要层间接口关系保持不变，则在这层以上或以下各层均不影响。
  3. 结构上可分割，各层都可以采用最合适的技术实现。
  4. 能促进标准化工作，每一层的功能及其所提供的服务都已有了明确的说明。

https://blog.csdn.net/qq_32798897/article/details/121879151

#DNS查询方式有哪些？

image

https://zhuanlan.zhihu.com/p/423222573

递归查询

递归查询一般发生在 Client 请求 DNS Server。Client 发出一个域名解析的请求，DNS Server 必须返回对应的 IP 地址，或者返回找不到的错误。

迭代查询

迭代查询一般发生在 DNS Server 之间，当 Client 发出域名解析的请求后，DNS Server 需要经过多次查询，才能得到相应的结果。比如先找到根服务器、根据根服务器的信息找到顶级域名服务器，再根据顶级域名服务器找到权威服务器，最后根据权威服务器返回结果，或提示错误。

非递归查询

非递归查询发生在 Client 和 DNS Server 之间，指的是，请求的 DNS Server 已经知道答案，直接返回。

https://juejin.cn/post/6844903900982558734

#HTTP中缓存的私有和共有字段？知道吗？

响应头中的Cache-Control: private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

响应头中的Cache-Control:public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

#GET 方法参数写法是固定的吗？

不固定，只要服务端能够解释出来就行，但一般来说，参数写在url的？后面，键值对用&分离。

#GET 方法的长度限制是怎么回事？

HTTP 协议没有 Body 和 URL 的长度限制，对 URL 限制的大多是浏览器和服务器的原因。

为了浏览器的兼容性，需要限制url长度；服务器是为了性能和安全考虑，会给 URL 长度加限制。

#POST 方法比 GET 方法安全？

https://github.com/sisterAn/blog/issues/107

在 HTTP 协议里，所谓的“安全”是指请求方法不会对服务器上的资源进行修改，“破坏”服务器上的资源。

按照这种定义，GET 请求方法是安全的，它对服务器资源执行的仅仅是只读操作，也是幂等的

幂等指多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”

POST 请求方法是不安全的，它会修改服务器上的资源，“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的

总结：

  • GET：安全，幂等
  • POST：不安全，不幂等

对于传输来说，GET 和 POST 报文在传输上都是不安全的，因为 HTTP 在网络上是明文传输的，想要安全传输就得加密，也就是 HTTPS

#POST 方法会产生两个 TCP 数据包？你了解吗？

大多数框架都是尽量在一个 TCP 包里面把 HTTP 请求发出去的，但是也确实存在先发 HTTP 头，然后发 body 的框架。但是具体发多少个TCP包，这个 不是 HTTP 协议的事情是操作系统 TCP 协议栈与代码的问题，跟 HTTP 没关系