协议

  • HTTP 常见的状态码有哪些?分别代表什么意思?

    • 2XX:成功
      • 200 - OK - 请求成功
      • 204 - no content - 请求成功,但是没有结果返回
      • 206 - partial content - 客户端请求一部分资源,服务端成功响应,返回一范围资源
    • 3XX:重定向
      • 301 - move permanently - 永久性重定向
      • 302 - found - 临时性重定向
      • 303 - see other - 由于请求对应的资源存在着另一个 URI,应使用 GET
        方法定向获取请求的资源
      • 304 - not modified - 表示在客户端采用带条件的访问某资源时,服务端找到了资源,但是这个请求的条件不符合。跟重定向无关
      • 307 - temporary redirect - 临时性重定向
    • 4XX:客户端错误
      • 400 - bad request - 请求报文存在语法错误
      • 401 - unauthorized - 第一次收到 401 状态码表示需要进行用户认证,第二次再收到 401 状态码说明用户认证失败。
      • 403 - forbidden - 请求被服务器拒绝了
      • 404 - not found - 服务器上无法找到请求的资源
    • 5XX:服务器错误
      • 500 - internal server error - 服务端执行请求时发生了错误
      • 503 - service unavailable - 服务器正在超负载或者停机维护,无法处理请求
  • tcp 的三次握手过程,为啥不是两次?

    • 过程:首先 A 向 B 发 SYN(同步请求),然后 B 回复 SYN+ACK(同步请求应答),最后 A 回复 ACK 确认,这样 TCP 的一次连接(三次握手)的过程就建立了。

    • 为什么是三次,不是两次:

      • 第一次握手:客户端发送网络包,服务端收到了。这样【服务端】就能得出结论:客户端的发送能力、服务端的接收能力是正常的。
      • 第二次握手:服务端发包,客户端收到了。这样【客户端】就能得出结论:服务端的接收、发送能力,客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
      • 第三次握手:客户端发包,服务端收到了。这样【服务端】就能得出结论:客户端的接收、发送能力正常,服务器自己的发送、接收能力也正常。

      由此可以得知,只有三次握手才能让双方都知晓:哦原来我和对面的接受发送能力都正常啊;而假如只有两次握手,服务端是不知道客户端接受能力正不正常的。

  • tcp 的四次挥手过程,为什么不是三次?

    • 四次挥手过程:
      • 第一次挥手:客户端向服务器发送关闭连接请求,随后进入 FIN-WAIT-1(终止等待1) 状态。即:此时【客户端】不会再主动发送数据报文,但可以接受数据报文
      • 第二次挥手:服务端接收到关闭请求,向客户端响应关闭请求,随后进入等待关闭状态 CLOSEWAIT;即:此时【服务端】告知【客户端】:我知道要断开连接了(但我可能还有点东西没处理完,稍等下),这样【客户端】就不会因为没收到回应而继续发送断开连接的请求了。
      • 第三次挥手:服务端发送完了所有的数据后,再次响应一次客户端的关闭请求,告知客户端自己也可以关闭了;即:此时【服务端】处理完数据报文后,告知【客户端】:ok,我这边也可以断开连接了。
      • 第四次挥手:客户端收到来自服务端的可关闭报文后,发送响应告知服务端我已经完成工作了,准备关闭;即:此时【客户端】收到了【服务端】的断开连接确认,要发送一个 ACK 报文告诉【服务端】表示自己知道了,然后进入等待状态(TIME-WAIT状态)。【服务端】收到回应后,也断开连接了。
    • 为什么不是三次挥手?
      • 从上面的过程可以知道,如果没有了第四次“挥手“,【服务端】是不知道【客户端】有没有收到【服务端】在第三次挥手的时候发送的”ok,我这边也可以断开连接了“这句话的,会一直重复发送这句话。因此需要四次挥手,而不是三次。
  • 为什么要有 TIME-WAIT 这个状态呢?

    • 这是因为有可能发生【最后一次确认丢失】,如果 B 此时继续向 A 发送一个我要断开连接的请求等待 A 发送确认,但此时 A 已经关闭连接了,那么 B 永远也关不掉了,所以我们要有 TIME-WAIT 这个状态,确保客户端和服务端之间的连接正常关闭,保证了数据传输的可靠性。当然 TCP 也并不是 100%可靠的。
  • TCP 的三次握手机制有什么缺陷吗?怎么解决?

    • SYN 泛洪攻击

      1. 攻击者发送 TCP 的 SYN,服务器返回 ACK 后,攻击者不对该 ACK 进行确认,使得 TCP 连接处于【半连接状态】
      2. 服务器收不到来自攻击者的再确认,会重复发送 ACK 给攻击者,浪费服务器的资源
      3. 如果攻击者发送了许多这种恶意 TCP 连接,这些【半连接状态】的 TCP 就会消耗 CPU 和内存,导致服务器死机
    • 解决:

      • 服务器收到 SYN 报文段的时候,不为该报文段生成半开的连接,而是生成一个【初始序列号】,也就是我们熟知的 cookie

        该序列号是一个复杂函数(散列函数,由 SYN 报文段的源 IP 地址和目的 IP 地址,源端口号和目的端口号以及仅有服务器知道的秘密数构成)

        服务器不会记录该 cookie 以及其他任何关于 SYN 的状态信息

      • 如果发送方是合法的,那么就应该会返回一个 ACK 报文段给服务器端,服务器端收到后,验证该 ACK 是否与前面发送的某个 SYN 相对应

        如何验证呢?根据上面提到过的散列函数计算结果 → 得到 cookie 值

        如果该 cookie 值 + 1 与 ACK 报文段中的确认值相同,那么服务器会认为该 ACK 对应于较早的 SYN 报文段,认为他合法,就生成一个全开连接

      • 如果发送方不合法,即一直不返回 ACK 报文段,但其并不会对服务器造成任何危害,因为服务器没有给它分配任何资源

  • TCP 三次握手中,最后一次回复丢失,会发生什么?

    • 如果最后一次 ACK 在网络中丢失,那么Server 端(服务端)该 TCP 连接的状态仍为SYN_RECV,并且根据 TCP 的超时重传机制依次等待 3 秒、6 秒、12 秒后重新发送 SYN+ACK 包,以便 Client[客户端]重新发送 ACK 包
    • 如果重发指定次数后,仍然未收到 ACK 应答,那么一段时间后,Server(服务端)自动关闭这个连接
    • 但是Client(客户端)认为这个连接已经建立,如果Client 客户端向 Server(服务端)发送数据,Server 端(服务端)将以 RST 包(Reset,标示复位,用于异常的关闭连接)响应,此时,客户端就知道第三次握手失败了
  • TCP & UDP 区别?怎么保证可靠?使用场景有哪些?

    这两种都是 OSI 模型中,传输层定义的两种协议

    • TCP:是一种可靠的传输协议
    • UDP:是一种,不可靠的,无连接的,时延小的,适用于小文件传输的协议
    • 区别: UDP 与 TCP 的主要区别在于 UDP 不一定提供可靠的数据传输。 事实上,该协议不能保证数据准确无误地到达目的地。
  • HTTP 和 HTTPS 的区别?

    • HTTP 的 URL 以 http:// 开头,而 HTTPS 的 URL 以 https:// 开头
    • HTTP 标准端口是 80 ,而 HTTPS 的标准端口是 443(重点)
    • http 的连接很简单,是无状态的,不安全的。Https 协议是由SSL+Http 协议构建的可进行加密传输、身份认证的网络协议,比 http 协议安全。(无状态的意思是其数据包的发送、传输和接受都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
    • HTTP 无需认证证书,而 https 需要认证证书 ,一般免费证书较少,因而需要一定费用。

    一句话总结:简单来说 http 是用来进行 html 等超媒体传输的,但是 http 不安全,为了安全,使用证书 SSL 和 HTTP 的方式进行数据传输,也就是 HTTPS

  • HTTPS 的密文传输怎么传输的?

    分为两部分:证书验证 和 数据传输

    • 证书验证部分:
      • 客户端发起 HTTPS 请求,服务器接受请求,返回【证书】(证书内包含公钥)。
      • 客户端对该【证书】进行验证,如果不通过则进行警告提示。如果通过则进入数据传输部分
    • 数据传输部分:
      • 首先客户端本地生成用于改造【对称加密算法】的随机数,通过【证书中的公钥】对随机数进行加密传输到服务器。
      • 服务器接收后通过【私钥】进行【非对称解密】得到客户端生成的随机数,再通过传入随机数的【对称加密算法】对数据进行【对称加密】。
      • 服务器将加密后的数据传输给客户端。
      • 客户端用之前生成的随机数对数据进行【对称解密】,获取内容明文
  • HTTP 1.0 与 HTTP 1.1 区别?

    • http1.1 提供身份认证,状态管理和 cache 缓存机制等相关的请求头和响应头。
    • http1.1 提供持久性连接,而 http1.0 使用非持久连接。一次的 tcp 连接只能传输一个 web 对象,服务器完成请求后立即断开 tcp 连接,服务器不跟踪每个客户也记录过去的请求。假如一个文件传输过程包含多次请求和响应,就得建立多次连接,断开多次连接,影响客户端服务器性能。持久性连接使得 tcp 连接默认不关闭,可以被多个请求复用,即一次连接可以传输多个请求和应答了,(当然每个单独的网页文件和请求都需要使用各自的连接)。
    • http1.1 增加 host 头,而 http1.0 不支持 host 请求头字段,使得 web 浏览器无法使用主机头来明确表示要访问服务器的哪个 web 站点,引入后就可以了,进而实现了一台 web 服务器上可以在同一个 IP 地址和端口号上使用不同的主机名来创建多个虚拟的 web 站点。
  • DNS 用的是什么协议?

WEB 技术

  • cookie 和 session 什么联系和区别?

    • 联系:session 的实现其实也依靠了 cookie;
    • 存储位置不同:
      • session存储在【服务器端】;
      • cookie存储在【浏览器/客户端】,服务器通过 request 的setCookie方法响应给客户端 cookie 和getCookie方法从浏览器中获取 cookie。;
    • 安全性不同:cookie 由于是存储在浏览器中的,是可以被伪造和修改的;而 session 由于保存在服务器端,是安全的
    • 容量个数限制不同:cookie 有容量限制,每个站点的 cookie 也是有个数限制的;而 session 并没有大小限制,且可以存储任意对象;
    • 存储多样性不同:cookie 只能存在浏览器中;session 可以存在 Redis、数据库、应用程序中;
    • 应用场景不同cookie一般用于保存用户信息(用户名/密码);session主要用于通过服务端记录用户状态(购物车);
  • 打开一个网站,会经历哪些过程?/输入一个 URL 全过程

    • 首先浏览器查找当前 URL 是否存在缓存,并比较缓存是否过期。过期就会重新加载

    • 然后就开始DNS 进行域名的解析,获取到对应的 IP。

      加分来说:

      1. 先检查(1)本地 hosts 文件是否有这个网址映射关系,如果有就调用这个 IP 地址映射,完成域名解析。没有才会(2)查找本地 DNS 解析器缓存。如果还是没有找到则会(3)查找 DNS 服务器,如果找到则返回。
    • 根据 IP,通过三次握手建立 TCP 连接,维护好双方的序列号,滑动窗口大小。

    • 然后再向服务器发送 HTTP 请求。

    • 服务器处理请求,返回 HTTP 响应。

    • 前端就渲染页面,显示功能。

    • 通过 Tcp 四次挥手,关闭 TCP 连接。

  • DNS 的解析过程?

  • 怎么保证 cookies 不被劫持?

  • GET 与 POST 请求区别?

    • url 可见性

      • GET:url 参数可见
      • POST:url 参数不可见
    • 数据传输方面

      • GET:通过拼接 URL 进行参数传递
      • POST:通过 body 体传递参数
    • 缓存性

      • GET:Get 请求可以被缓存
      • POST:Post 请求不能被缓存
    • 后退页面的反应

      • GET:页面后退时,不会产生影响
      • POST:页面后退时,会重新提交请求
    • 传输数据的大小

      • GET:一般传输数据大小不超过 2k-4k(根据浏览器不同,限制不一样,但相差不大)
      • POST:传输数据的大小根据 php.ini 配置文件设定,也可以无限大。
    • 安全性

      • GET:不是很安全,因为参数直接暴露在了 URL 上
      • POST:相对来说安全点,但也不是一定的
    • TCP 数据包发送

      • GET:产生一个 TCP 数据包
      • POST:产生两个 TCP 数据包

      对于 GET 方式的请求,浏览器会把 http header 和 data 一并发送出去,服务器响应 200(返回数据);

      而对于 POST,浏览器先发送 header,服务器响应 100 continue,浏览器再发送 data,服务器响应 200 ok(返回数据)。