首页 > 电脑手机

2024前端面试训练计划-高频题-网络基础篇

电脑手机 2024-11-25 14:40:01 654

具体内容结构（可作为回答思路）为：简略回答，详细回答

1、HTTP状态码

  • 简略回答

2024前端面试训练计划-高频题-网络基础篇

HTTP 的状态码被分为五类:

  • 1xx: 表示目前是协议处理的中间状态，还需要后续操作。
  • 2xx: 表示成功状态。
  • 3xx: 重定向状态，资源位置发生变动，需要重新请求。
  • 4xx: 请求报文有误。
  • 5xx: 服务器端发生错误。

  • 详细回答

    • 常见的状态码：

  1. 1xx

    1. 101 Switching Protocols。在HTTP升级为WebSocket的时候，如果服务器同意变更，就会发送状态码 101。

  2. 2xx

    1. 200 OK是见得最多的成功状态码。通常在响应体中放有数据。
    2. 204 No Content含义与 200 相同，但响应头后没有 body 数据。
    3. 206 Partial Content顾名思义，表示部分内容，它的使用场景为 HTTP 分块下载和断点续传，当然也会带上相应的响应头字段Content-Range。

  3. 3xx

    1. 301 Moved Permanently即永久重定向，对应着302 Found，即临时重定向。

      1. 比如你的网站从 HTTP 升级到了 HTTPS 了，以前的站点再也不用了，应当返回301，这个时候浏览器默认会做缓存优化，在第二次访问的时候自动访问重定向的那个地址。

    2. 304 Not Modified: 当协商缓存命中时会返回这个状态码。详见浏览器缓存

  4. 4xx

    1. 400 Bad Request 该状态码表示请求报文中存在语法错误。
    2. 401 Unauthorized 状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、DIGEST 认证)的认证信息。
    3. 404 Not Found: 资源未找到，表示没在服务器上找到相应的资源。
    4. 405 Method Not Allowed: 请求方法不被服务器端允许。

  5. 5xx

    1. 500 Internal Server Error 该状态码表明服务器端在执行请求时发生了错误
    2. 504 Gateway Timeout 网关或者代理的服务器无法在规定的时间内获得想要的响应。

2、HTTP和HTTPS协议的区别

  • 简略回答
  1. HTTPS协议需要CA证书，费用较高；而HTTP协议不需要；
  2. HTTP协议是超文本传输协议，信息是明文传输的，HTTPS则是具有安全性的SSL加密传输协议；
  3. 使用不同的连接方式，端口也不同，HTTP协议端口是80，HTTPS协议端口是443；
  4. HTTP协议连接很简单，是无状态的；HTTPS协议是有SSL和HTTP协议构建的可进行加密传输、身份认证的网络协议，比HTTP更加安全。
  • 详细回答

3、URL有哪些组成部分

  • 简略回答

  1. 协议部分

    1. 该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。
    2. 在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。
    3. 在"HTTP"后面的“//”为分隔符；

  2. 域名部分

    1. 该URL的域名部分为“www.aspxfans.com”。
    2. 一个URL中，也可以使用IP地址作为域名使用

  3. 端口部分

    1. 跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。
    2. 端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口（HTTP协议默认端口是80，HTTPS协议默认端口是443）；

  4. 虚拟目录部分

    1. 从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。
    2. 虚拟目录也不是一个URL必须的部分。本例中的虚拟目录是“/news/”；

  5. 文件名部分

    1. 从域名后的最后一个“/”开始到“？”为止，是文件名部分，
    2. 如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，
    3. 如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。
    4. 本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名；

  6. 参数部分

    1. 从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。
    2. 本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

  7. 锚部分

    1. 从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分；
  • 详细回答

4、HTTP协议的优点和缺点

  • 简略回答

HTTP 是超文本传输协议，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。

优势

  1. 支持客户端/服务器模式

  2. 简单快速：

    1. 客户向服务器请求服务时，只需传送请求方法和路径。
    2. 由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，
    3. 因而通信速度很快

  3. 无连接：

    1. 无连接就是限制每次连接只处理一个请求。
    2. 服务器处理完客户的请求，并收到客户的应答后，即断开连接，
    3. 采用这种方式可以节省传输时间。

  4. 无状态：

    1. HTTP 协议是无状态协议，这里的状态是指通信过程的上下文信息。
    2. 缺少状态意味着如果后续处理需要前面的信息，则它必须重传，
    3. 这样可能会导致每次连接传送的数据量增大。
    4. 另一方面，在服务器不需要先前信息时它的应答就比较快。

  5. 灵活：

    1. HTTP 允许传输任意类型的数据对象。
    2. 正在传输的类型由 Content-Type 加以标记。

缺点

  1. 无状态

    1. HTTP 是一个无状态的协议，HTTP 服务器不会保存关于客户的任何信息。

  2. 明文传输：

    1. 协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。

  3. 不安全：

    1. 通信使用明文（不加密），内容可能会被窃听；
    2. 不验证通信方的身份，因此有可能遭遇伪装；
    3. 无法证明报文的完整性，所以有可能已遭篡改；
  • 详细回答

5、常见的HTTP请求头和响应头

  • 简略回答

  1. HTTP Request Header 中常见的请求头：

    1. Accept-Charset：浏览器能够显示的字符集
    2. Accept-Language：浏览器当前设置的语言
    3. Connection：浏览器与服务器之间连接的类型
    4. Cookie：当前页面设置的任何Cookie
    5. Host：发出请求的页面所在的域
    6. Referer：发出请求的页面的URL

  2. HTTP Response Header 常见的响应头

    1. server:服务器名称
    2. Connection：浏览器与服务器之间连接的类型
    3. Cache-Control：控制HTTP缓存
    4. content-type:表示后面的文档属于什么MIME类型，比如：multipart/form-data，application/json，text/xml
  • 详细回答

6、GET和POST的请求的区别

  • 简略回答

  1. 应用场景上来说

    1. GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页的资源。
    2. 而 Post 不是一个幂等的请求，一般用于对服务器资源会产生影响的情景，比如注册用户这一类的操作。

  2. 是否缓存：

    1. 因为两者应用场景不同，浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。

  3. 发送的报文格式：

    1. Get 请求的报文中实体部分为空，Post 请求的报文中实体部分一般为向服务器发送的数据。

  4. 安全性：

    1. Get 请求可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说是不太安全的，因为请求的 url 会被保留在历史记录中。

  5. 请求长度：

    1. 浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。

  6. 参数类型：

    1. post 的参数传递支持更多的数据类型。

  7. 请求时携带的参数不同

  • 详细回答

7、POST和PUT请求的区别

  • 简略回答
  1. PUT是用来进行更新数据的请求方法，向服务器端发送数据，从而修改数据的内容，但是不会增加数据的种类等，也就是说无论进行多少次PUT操作，其结果并没有不同。（可以理解为时更新数据）
  2. POST请求是向服务器端发送数据，该请求会改变数据的种类等资源，它会创建新的内容。（可以理解为是创建数据）
  • 详细回答

8、HTTP状态码304是多好还是少好

  • 简略回答

出现304的原因

  1. 服务器为了提高网站访问速度，

    1. 对之前访问的部分页面指定缓存机制，
    2. 当客户端在此对这些页面进行请求，服务器会根据缓存内容判断页面与之前是否相同，
    3. 若相同便直接返回304，此时客户端调用缓存内容，不必进行二次下载。

  2. 状态码304不应该认为是一种错误，而是对客户端有缓存情况下服务端的一种响应。

  3. 搜索引擎蜘蛛会更加青睐内容源更新频繁的网站。

    1. 通过特定时间内 对网站 抓取返回的状态码 来调节对该网站的抓取频次。
    2. 若网站在一定时间内一直处于304的状态，那么蜘蛛可能会降低对网站的抓取次数。
    3. 相反，若网站变化的频率非常之快，每次抓取都能获取新内容，那么日积月累，的回访率也会提高。
  • 详细回答

产生较多304状态码的原因：

  1. 页面更新周期长或不更新
  2. 纯静态页面或强制生成静态html

304状态码出现过多会造成以下问题：

  1. seo 网站权重下降

9、常见的HTTP请求方法

  • 简略回答
  1. GET: 向服务器获取数据
  2. POST：将实体提交到指定的资源，通常会造成服务器资源的修改；
  3. PUT：上传文件，更新数据；
  4. DELETE：删除服务器上的对象；
  5. HEAD：获取报文首部，与GET相比，不返回报文主体部分；
  6. OPTIONS：询问支持的请求方法，用来跨域请求；
  7. CONNECT：要求在与代理服务器通信时建立隧道，使用隧道进行TCP通信；
  8. TRACE: 回显服务器收到的请求，主要⽤于测试或诊断。
  • 详细回答

10、OPTIONS请求方法及使用场景

  • 简略回答

OPTIONS方法是用于 请求获得 由Request-URI标识的资源 在请求/响应的通信过程中 可以使用的功能选项。

通过这个方法，客户端可以在采取具体资源请求之前，

  • 决定对该资源采取何种必要措施，
  • 或者了解服务器的性能。
  • 该请求方法的响应不能缓存。

OPTIONS请求方法的主要用途有两个：

  1. 获取当前服务器支持的所有HTTP请求方法；

  2. 用来检查访问权限。

    1. 例如：在进行 CORS 跨域资源共享时，对于复杂请求，就是使用 OPTIONS 方法发送嗅探请求，以判断是否有对指定资源的访问权限。
  • 详细回答

11、HTTP 1.0 和 HTTP 1.1 之间有哪些区别

  • 简略回答

  1. 连接方面的区别：

    1. http1.0 默认使用非持久连接
    2. 而 http1.1 默认使用持久连接。
    3. 使用持久连接来使多个 http 请求复用同一个 TCP 连接，避免使用非持久连接时每次需要建立连接的时延。

  2. 资源请求方面：

    1. http1.0不支持断点续传功能
    2. http1.1 请求头引入range头域，支持断点续传功能，返回码是206
    3. 断点续传允许请求资源的部分响应。

  3. 缓存方面的区别：

    1. 在 http1.0 中主要使用 header 里的 If-Modified-Since、Expires 来做为缓存判断的标准
    2. http1.1 则引入了更多的缓存控制策略，例如 Etag、If-Unmodified-Since、If-Match、If-None-Match 等

  4. http1.1 中新增了 host 字段 用来指定服务器的域，以将请求发往到同一台服务器上的不同网站。

  5. http1.1 相对于 http1.0 还新增了很多请求方法，如 PUT、HEAD、OPTIONS 等。

  • 详细回答

12、HTTP 1.1 和 HTTP 2.0 的区别

  • 简略回答

  1. 报文的头信息数据 类型区别

    1. http1.1的报文的头信息必须是文本（ASCII 编码），数据体可以是文本，也可以是二进制。
    2. http2.0是一个二进制协议。信息和数据体都是二进制，并且统称为"帧"，可以分为头信息帧和数据帧。
    3. 帧的概念是它实现多路复用的基础。

  2. HTTP/2 实现了多路复用和支持TCP连接复用机制，http1.1不支持，在一个连接里，客户端和服务器都可以同时发送多个请求或回应，而且不用按照顺序一一发送，避免了"队头堵塞"【1】的问题。

  3. http2连接中使用了数据流的概念。

    1. HTTP/2 将每个请求或回应的所有数据包，称为一个数据流。
    2. 每个数据流都有一个独一无二的编号。
    3. 数据包发送时，都必须标记数据流 ID ，用来区分它属于哪个数据流。

  4. 头信息压缩

    1. HTTP/2 实现了头信息压缩
    2. http1.1协议不支持头信息压缩
    3. 头信息压缩机制是指请求头上携带的信息使用 gzip 或 compress 压缩后再发送；
    4. 而且客户端和服务器同时维护一张头信息表，所有字段都会存入这个表，生成一个索引号，以后就不发送同样字段了，只发送索引号，这样就能提高速度了。

  5. 服务器推送

    1. HTTP/2 允许服务器未经请求，主动向客户端发送资源，这叫做服务器推送。
    2. http1.1 不支持服务器推送。
  • 详细回答

队头堵塞

  1. 队头阻塞是由 HTTP 基本的“请求 - 应答”模型所导致的。
  2. HTTP 规定报文必须是“一发一收”，这就形成了一个先进先出的“串行”队列。
  3. 队列里的请求是没有优先级的，只有入队的先后顺序，排在最前面的请求会被最优先处理。
  4. 如果队首的请求因为处理的太慢耽误了时间，那么队列里后面的所有请求也不得不跟着一起等待，
  5. 结果就是其他的请求承担了不应有的时间成本，造成了队头堵塞的现象。

队头阻塞的解决方案：

（1）并发连接：对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。

（2）域名分片：将域名分出很多二级域名，它们都指向同样的一台服务器，能够并发的长连接数变多，解决了队头阻塞的问题。

13、当在浏览器中输入 URL 并且按下回车之后发生了什么

  • 简略回答

  1. 首先进行 解析URL

    1. 首先会对 URL 进行解析，分析所需要使用的传输协议和请求的资源的路径。
    2. 如果输入的 URL 中的协议或者主机名不合法，将会把地址栏中输入的内容传递给搜索引擎。
    3. 如果没有问题，浏览器会检查 URL 中是否出现了非法字符，如果存在非法字符，则对非法字符进行转义后再进行下一过程。

  2. 第二步进行 缓存判断

    1. 浏览器会判断所请求是否使用了缓存策略，请求的资源是否在缓存里，缓存是否失效
    2. 没有失效，那么就直接使用，
    3. 否则向服务器发起新的请求。

  3. 第三步进行 DNS解析

    1. DNS解析时首先需要获取的是输入的 URL 中的域名的 IP 地址，
    2. 首先会判断本地是否有该域名的 IP 地址的缓存，
    3. 如果有则使用，如果没有则向本地 DNS 服务器发起请求。
    4. 本地 DNS 服务器也会先检查是否存在缓存，
    5. 如果没有就会先向根域名服务器发起请求，获得负责的顶级域名服务器的地址后，
    6. 再向顶级域名服务器请求，然后获得负责的权威域名服务器的地址后，
    7. 再向权威域名服务器发起请求，最终获得域名的 IP 地址后，
    8. 本地 DNS 服务器再将这个 IP 地址返回给请求的用户。
    9. 用户向本地 DNS 服务器发起请求属于递归请求，本地 DNS 服务器向各级域名服务器发起请求属于迭代请求。

  4. 第四步进行 获取MAC地址

    1. 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，

    2. 因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。

    3. 网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，

    4. 数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。

      1. 先通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，
      2. 如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，
      3. 如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，
      4. 此时目的主机的 MAC 地址应该为网关的地址。

  5. 第五步进行 TCP三次握手

    1. TCP 建立连接的三次握手的过程，

      1. 首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，
      2. 服务端接收到请求后向客户端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。
      3. 客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，
      4. 此时双方的连接就建立起来了。

  6. 第六步进行 HTTPS握手

    1. 如果使用的是 HTTPS 协议，在通信前还存在 TLS 的一个四次握手的过程。

      1. 首先由客户端向服务器端发送使用的协议的版本号、一个随机数和可以使用的加密方法。
      2. 服务器端收到后，确认加密的方法，也向客户端发送一个随机数和自己的数字证书。
      3. 客户端收到后，首先检查数字证书是否有效，如果有效，则再生成一个随机数，并使用证书中的公钥对随机数加密，然后发送给服务器端，并且还会提供一个前面所有内容的 hash 值供服务器端检验。
      4. 服务器端接收后，使用自己的私钥对数据解密，同时向客户端发送一个前面所有内容的 hash 值供客户端检验。
      5. 这个时候双方都有了三个随机数，按照之前所约定的加密方法，使用这三个随机数生成一把秘钥，以后双方通信前，就使用这个秘钥对数据进行加密后再传输

  7. 第七步进行 返回数据

    1. 当页面请求发送到服务器端后，服务器端会返回一个 html 文件作为响应，浏览器接收到响应后，开始对 html 文件进行解析，开始页面的渲染过程。

  8. 第八步进行 页面渲染

    1. 浏览器首先会根据 html 文件构建 DOM 树，
    2. 根据解析到的 css 文件构建 CSSOM 树，
    3. 如果遇到 script 标签，则判端是否含有 defer 或者 async 属性，要不然 script 脚本的加载和执行会造成页面的渲染的阻塞。
    4. 当 DOM 树和 CSSOM 树建立好后，根据它们来构建渲染树。渲染树构建好后，会根据渲染树来进行布局。布局完成后，最后使用浏览器的 UI 接口对页面进行绘制。这个时候整个页面就显示出来了。

  9. 第九步进行 断开TCP连接，进行TCP四次挥手

    1. 最后一步是 TCP 断开连接的四次挥手过程。

      1. 若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。
      2. 服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。
      3. 但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。
      4. 客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。
      5. 当服务端收到确认应答后，也便进入 CLOSED 状态。
  • 详细回答

14、对HTTP中keep-alive的理解

  • 简略回答

Keep - Alive 机制来实现 持久连接。它允许在一个 TCP 连接上进行多个 HTTP 请求 - 响应的交互。

keep-Alive使用方法

  1. HTTP1.0版本是默认没有Keep-alive的（也就是默认会发送keep-alive），

    1. 所以要想连接得到保持，必须手动配置发送Connection: keep-alive字段。
    2. 若想断开keep-alive连接，需发送Connection:close字段；

  2. HTTP1.1规定了默认保持长连接，

    1. 数据传输完成了保持TCP连接不断开，等待在同域名下继续用这个通道传输数据。
    2. 如果需要关闭，需要客户端发送Connection：close首部字段。
  • 详细回答

Keep-Alive的建立过程（会有TCP三次握手过程）：

  1. 客户端向服务器 在发送请求报文 同时在首部添加发送Connection:Keep-Alive字段
  2. 服务器收到请求并处理 Connection字段
  3. 服务器回送Connection:Keep-Alive字段给客户端
  4. 客户端接收到Connection字段
  5. Keep-Alive连接建立成功

keep-alive的优势

  1. 较少的CPU和内存的使⽤（由于同时打开的连接的减少了）；
  2. 降低拥塞控制 （TCP连接减少了）；
  3. 减少了后续请求的延迟（⽆需再进⾏握⼿）；

keep-alive的缺点：

  1. 长时间的Tcp连接 容易导致系统资源无效占用，浪费系统资源。

客户端和服务端建立的连接

  1. 短连接

    1. HTTP1.0 中默认是在每次请求/应答，客户端和服务器都要新建一个连接，完成之后立即断开连接，这就是短连接。

  2. 长连接

    1. 使用Keep-Alive模式时，Keep-Alive功能使客户端到服务器端的连接持续有效，
    2. 当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接，这就是长连接。

15、HTTP请求和响应报文是什么结构

  • 简略回答

请求报文

  1. 请求行

    1. 包括：请求⽅法字段、URL字段、HTTP协议版本字段。它们⽤空格分隔。
    2. 例如，GET /index.html HTTP/1.1。

  2. 请求头部

    1. 请求头部由关键字/值对组成，每⾏⼀对，关键字和值⽤英⽂冒号“:”分隔
    2. 例如：Host：请求的主机名，允许多个域名同处⼀个IP地址，即虚拟主机。

  3. 空行

  4. 请求体

    1. post put等请求携带的数据

响应报文

  1. 响应行

    1. 由网络协议版本，状态码和状态码的原因短语组成，例如 HTTP/1.1 200 OK 。

  2. 响应头

    1. 响应部首组成

  3. 空行

  4. 响应体

    1. 服务器响应的数据
  • 详细回答

16、与缓存相关的HTTP请求头有哪些

  • 简略回答

  1. 强缓存

    1. expires
    2. cache-control

  2. 协商缓存

    1. etag
    2. if-none-match
    3. if-modified-since
    4. last-modified
  • 详细回答

17、HTTPS通信（握手）过程

  • 简略回答
  1. 客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。
  2. 服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。
  3. 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。
  4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。
  5. 客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。
  • 详细回答

18、什么是HTTPS协议

  • 简略回答

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS）是一种通过计算机网络进行安全通信的传输协议。

  1. HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。
  2. HTTPS的主要目的 是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。
  • 详细回答

https中 ssl/tls 协议作用

  1. HTTP协议采用明文传输信息，

    1. 存在信息窃听、信息篡改和信息劫持的风险，
    2. 而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。

  2. 安全层的主要职责

    1. 就是对发起的HTTP请求的数据进行加密操作 和 对接收到的HTTP的内容进行解密操作

https的优势：

  1. 使用HTTPS协议可以认证用户和服务器，确保数据发送到正确的客户端和服务器；
  2. 使用HTTPS协议可以进行加密传输、身份认证，通信更加安全，防止数据在传输过程中被窃取、修改，确保数据安全性；
  3. HTTPS是现行架构下最安全的解决方案，虽然不是绝对的安全，但是大幅增加了中间人攻击的成本；

https的缺点

  1. HTTPS需要做服务器和客户端双方的加密个解密处理，耗费更多服务器资源，过程复杂；
  2. HTTPS协议握手阶段比较费时，增加页面的加载时间；
  3. SSL证书是收费的，功能越强大的证书费用越高；
  4. HTTPS连接服务器端资源占用高很多，支持访客稍多的网站需要投入更大的成本；
  5. SSL证书需要绑定IP，不能再同一个IP上绑定多个域名。

19、安全层中TLS/SSL协议的工作原理

  • 简略回答

TLS/SSL全称安全传输层协议（Transport Layer Security）,

  1. 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，
  2. 所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

特点

  • 综合算法特点，TLS/SSL的工作方式

    • 就是客户端使用非对称加密 与服务器进行通信，实现身份的验证并协商对称加密使用的秘钥。
    • 对称加密算法采用协商秘钥对信息以及信息摘要进行加密通信，
    • 不同节点之间采用的对称密钥不同，从而保证信息只能通信双方获取。
    • 这样就解决了两个方法各自存在的问题。

  • 详细回答

TLS/SSL的功能实现主要依赖三类基本算法

  • 基于 散列函数验证信息的完整性
  • 对称加密算法 采用协商的秘钥对数据加密
  • 非对称加密 实现身份认证和秘钥协商

  1. 散列函数hash

    1. 常见的散列函数有MD5、SHA1、SHA256。

    2. 该函数的特点是

      1. 单向不可逆，
      2. 对输入数据非常敏感，
      3. 输出的长度固定，
      4. 任何数据的修改都会改变散列函数的结果，
      5. 可以用于防止信息篡改并验证数据的完整性。

  2. 对称加密

    1. 常见的对称加密算法有AES-CBC、DES、3DES、AES-GCM等。

    2. 特点

      1. 相同的秘钥可以用于信息的加密和解密。
      2. 掌握秘钥才能获取信息，防止信息窃听，
      3. 其通讯方式是一对一。

  3. 非对称加密

    1. 常见的非对称加密算法有RSA、ECC、DH等。

    2. 特点

      1. 秘钥成对出现，一般称为公钥（公开）和私钥（保密）。
      2. 公钥加密的信息只有私钥可以解开，私钥加密的信息只能公钥解开，
      3. 因此掌握公钥的不同客户端之间不能相互解密信息，只能和服务器进行加密通信，
      4. 服务器可以实现一对多的的通信，
      5. 客户端也可以用来验证掌握私钥的服务器的身份

20、DNS 协议是什么

  • 简略回答
  1. DNS 是域名系统 (Domain Name System) 的缩写，提供的是一种主机名到 IP 地址的转换服务，就是我们常说的域名系统。
  2. 实现：是一个由分层的 DNS 服务器组成的分布式数据库，
  3. 定义了：主机如何查询这个分布式数据库的方式的应用层协议。
  4. 能够使人更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。
  5. 作用： 将域名解析为IP地址，客户端向DNS服务器（DNS服务器有自己的IP地址）发送域名查询请求，DNS服务器告知客户机Web服务器的 IP 地址。
  • 详细回答

21、DNS完整的查询过程

  • 简略回答
  1. 首先会在浏览器的缓存中查找对应的IP地址，如果查找到直接返回，若找不到继续下一步
  2. 将请求发送给本地DNS服务器，在本地域名服务器缓存中查询，如果查找到，就直接将查找结果返回，若找不到继续下一步
  3. 本地DNS服务器向根域名服务器发送请求，根域名服务器会返回一个所查询域的顶级域名服务器地址
  4. 本地DNS服务器向顶级域名服务器发送请求，接受请求的服务器查询自己的缓存，如果有记录，就返回查询结果，如果没有就返回相关的下一级的权威域名服务器的地址
  5. 本地DNS服务器向权威域名服务器发送请求，域名服务器返回对应的结果
  6. 本地DNS服务器将返回结果保存在缓存中，便于下次使用
  7. 本地DNS服务器将返回结果返回给浏览器
  • 详细回答

22、OSI七层模型

  • 简略回答
  • 详细回答

ISO为了更好的使网络应用更为普及，推出了OSI参考模型。

  1. 应用层

    1. OSI参考模型中最靠近用户的一层，是为计算机用户提供应用接口，也为用户直接提供各种网络服务。

      1. 我们常见应用层的网络服务协议有：HTTP，HTTPS，FTP，POP3、SMTP等。
      2. 在客户端与服务器中经常会有数据的请求，这个时候就是会用到http(hyper text transfer protocol)(超文本传输协议)或者https.在后端设计数据接口时，我们常常使用到这个协议。
      3. FTP是文件传输协议，在开发过程中，个人并没有涉及到，但是我想，在一些资源网站，比如百度网盘``迅雷应该是基于此协议的。
      4. SMTP是simple mail transfer protocol（简单邮件传输协议）。在一个项目中，在用户邮箱验证码登录的功能时，使用到了这个协议。

  2. 表示层

    1. 表示层提供各种用于应用层数据的编码和转换功能,
    2. 确保一个系统的应用层发送的数据能被另一个系统的应用层识别。
    3. 如果必要，该层可提供一种标准表示形式，用于将计算机内部的多种数据格式转换成通信中采用的标准表示形式。
    4. 压缩和加密也是表示层可提供的转换功能之一。
    5. 在项目开发中，为了方便数据传输，可以使用base64对数据进行编解码。如果按功能来划分，base64应该是工作在表示层。

  3. 会话层

    1. 会话层就是负责建立、管理和终止表示层实体之间的通信会话。
    2. 该层的通信由不同设备中的应用程序之间的服务请求和响应组成。

  4. 传输层

    1. 传输层建立了主机端到端的链接，
    2. 传输层的作用是为上层协议提供端到端的可靠和透明的数据传输服务，
    3. 包括处理差错控制和流量控制等问题。
    4. 该层向高层屏蔽了下层数据通信的细节，
    5. 使高层用户看到的只是在两个传输实体间的一条主机到主机的、可由用户控制和设定的、可靠的数据通路。
    6. 我们通常说的，TCP UDP就是在这一层。
    7. 端口号既是这里的“端”。

  5. 网络层

    1. 本层通过IP寻址来建立两个节点之间的连接，为源端的运输层送来的分组，选择合适的路由和交换节点，正确无误地按照地址传送给目的端的运输层。
    2. 就是通常说的IP层。这一层就是我们经常说的IP协议层。IP协议是Internet的基础。我们可以这样理解，网络层规定了数据包的传输路线，而传输层则规定了数据包的传输方式。

  6. 数据链路层

    1. 将比特组合成字节,再将字节组合成帧,使用链路层地址 (以太网使用MAC地址)来访问介质,并进行差错检测。
    2. 网络层与数据链路层的对比，通过上面的描述，我们或许可以这样理解，网络层是规划了数据包的传输路线，而数据链路层就是传输路线。不过，在数据链路层上还增加了差错控制的功能。

  7. 物理层

    1. 实际最终信号的传输是通过物理层实现的。
    2. 通过物理介质传输比特流。
    3. 规定了电平、速度和电缆针脚。
    4. 常用设备有（各种物理设备）集线器、中继器、调制解调器、网线、双绞线、同轴电缆。
    5. 这些都是物理层的传输介质。

OSI七层模型通信特点：对等通信

  1. 对等通信，为了使数据分组从源传送到目的地，源端OSI模型的每一层都必须与目的端的对等层进行通信，这种通信方式称为对等层通信。
  2. 在每一层通信过程中，使用本层自己协议进行通信。

23、TCP/IP五层协议

  • 简略回答
  • 详细回答

  1. 应用层 (application layer)：

    1. 直接为应用进程提供服务。
    2. 应用层协议定义的是应用进程间通讯和交互的规则，不同的应用有着不同的应用层协议，
    3. 如 HTTP协议（万维网服务）、FTP协议（文件传输）、SMTP协议（电子邮件）、DNS（域名查询）等。

  2. 传输层 (transport layer)：

    1. 有时也译为运输层，它负责为两台主机中的进程提供通信服务。

    2. 该层主要有以下两种协议

      1. 传输控制协议 (Transmission Control Protocol，TCP)：提供面向连接的、可靠的数据传输服务，数据传输的基本单位是报文段（segment）；
      2. 用户数据报协议 (User Datagram Protocol，UDP)：提供无连接的、尽最大努力的数据传输服务，但不保证数据传输的可靠性，数据传输的基本单位是用户数据报。

  3. 网络层 (internet layer)：

    1. 有时也译为网际层，它负责为两台主机提供通信服务，并通过选择合适的路由将数据传递到目标主机。

  4. 数据链路层 (data link layer)：

    1. 负责将网络层交下来的 IP 数据报封装成帧，并在链路的两个相邻节点间传送帧，每一帧都包含数据和必要的控制信息（如同步信息、地址信息、差错控制等）。

  5. 物理层 (physical Layer)：

    1. 确保数据可以在各种物理媒介上进行传输，为数据的传输提供可靠的环境。

特点

  1. TCP/IP模型比OSI模型更加简洁，它把应用层/表示层/会话层全部整合为了应用层。
  2. TCP/IP五层协议的通信方式也是对等通信：

24、TCP 和 UDP的概念及特点

  • 简略回答
  • 详细回答

TCP 和 UDP都是传输层协议，他们都属于TCP/IP协议族：

  1. TCP

    1. TCP的全称是传输控制协议是一种面向连接的、可靠的、基于字节流的传输层通信协议。TCP 是面向连接的、可靠的流协议（流就是指不间断的数据结构）。

    2. 特点

      1. 面向连接

        1. 是指发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，是为数据的可靠传输打下了基础。

      2. 仅支持单播传输

        1. 每条TCP传输连接只能有两个端点，只能进行点对点的数据传输，不支持多播和广播传输方式。

      3. 面向字节流

        1. TCP不像UDP一样那样一个个报文独立地传输，而是在不保留报文边界的情况下以字节流方式进行传输。

      4. 可靠传输

        1. 对于可靠传输，判断丢包、误码靠的是TCP的段编号以及确认号。
        2. TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。
        3. 然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；
        4. 如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

      5. 提供拥塞控制

        1. 当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞。

      6. 提供全双工通信

        1. TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）

  2. UDP

    1. UDP的全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。

    2. 在OSI模型中，在传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。

    3. 特点

      1. 面向无连接

        1. 首先 UDP 是不需要和 TCP一样在发送数据前进行三次握手建立连接的，想发数据就可以开始发送了。

        2. 并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。

          1. 在发送端，应用层将数据传递给传输层的 UDP 协议，UDP 只会给数据增加一个 UDP 头标识下是 UDP 协议，然后就传递给网络层了
          2. 在接收端，网络层将数据传递给传输层，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作

      2. 有单播，多播，广播的功能

        1. UDP 不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。

      3. 面向报文

        1. 发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。
        2. UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。
        3. 因此，应用程序必须选择合适大小的报文

      4. 不可靠性

        1. 首先不可靠性体现在无连接上，通信都不需要建立连接，想发就发，这样的情况肯定不可靠
        2. 并且收到什么数据就传递什么数据，并且也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了
        3. 再者网络环境时好时坏，但是 UDP 因为没有拥塞控制，一直会以恒定的速度发送数据。
        4. 即使网络条件不好，也不会对发送速率进行调整。
        5. 这样实现的弊端就是在网络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP 而不是 TCP。

      5. 头部开销小，传输数据报文时是很高效的。

    4. UDP 头部包含了以下几个数据：

      1. 两个十六位的端口号，分别为源端口（可选字段）和目标端口
      2. 整个数据报文的长度
      3. 整个数据报文的检验和（IPv4 可选字段），该字段用于发现头部信息和数据中的错误
      4. 因此 UDP 的头部开销小，只有8字节，相比 TCP 的至少20字节要少得多，在传输数据报文时是很高效的。

TCP应用场景：

效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。例如：文件传输（准确高要求高、但是速度可以相对慢）、接收邮件、远程登录。

25、TCP和UDP的区别

  • 简略回答
UDPTCP
是否连接无连接面向连接
是否可靠不可靠传输，不使用流量控制和拥塞控制可靠传输（数据顺序和正确性），使用流量控制和拥塞控制
连接对象个数支持一对一，一对多，多对一和多对多交互通信只能是一对一通信
传输方式面向报文面向字节流
首部开销首部开销小，仅8字节首部最小20字节，最大60字节
适用场景适用于实时应用，例如视频会议、直播适用于要求可靠传输的应用，例如文件传输
  • 详细回答

26、TCP的重传机制

  • 简略回答
  • 详细回答

重传原因

  1. 由于TCP的下层网络（网络层）可能出现丢失、重复或失序的情况，TCP协议提供可靠数据传输服务。
  2. 为保证数据传输的正确性，TCP会重传其认为已丢失（包括报文中的比特错误）的包。
  3. TCP使用两套独立的机制来完成重传，一是基于时间，二是基于确认信息。

重传过程

  1. TCP在发送一个数据之后，就开启一个定时器，
  2. 若是在这个时间内没有收到发送数据的ACK确认报文，则对该报文进行重传，
  3. 在达到一定次数还没有成功时放弃并发送一个复位信号。

28、TCP的拥塞控制机制

  • 简略回答
  • 详细回答

TCP的拥塞控制机制主要是以下四种机制

  1. 慢启动

    1. 在开始发送的时候设置cwnd = 1（cwnd指的是拥塞窗口）

    2. 思路：开始的时候不要发送大量数据，而是先测试一下网络的拥塞程度，由小到大增加拥塞窗口的大小。

    3. 为了防止cwnd增长过大引起网络拥塞，设置一个慢开始门限(ssthresh 状态变量)

      1. 当cnwd < ssthresh，使用慢开始算法
      2. 当cnwd = ssthresh，既可使用慢开始算法，也可以使用拥塞避免算法
      3. 当cnwd > ssthresh，使用拥塞避免算法

  2. 拥塞避免

    1. 拥塞避免未必能够完全避免拥塞，是说在拥塞避免阶段将拥塞窗口控制为按线性增长，使网络不容易出现阻塞。

    2. 思路： 让拥塞窗口cwnd缓慢的增大，即每经过一个返回时间RTT就把发送方的拥塞控制窗口加一

    3. 无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞，

      1. 就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。

  3. 其中，判断网络出现拥塞的根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理。

  4. 快速重传

    1. 快重传要求接收方在收到一个失序的报文段后就立即发出重复确认(为的是使发送方及早知道有报文段没有到达对方)。发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。
    2. 由于不需要等待设置的重传计时器到期，能尽早重传未被确认的报文段，能提高整个网络的吞吐量

  5. 快速恢复

    1. 当发送方连续收到三个重复确认时，就执行“乘法减小”算法，

  6. 把ssthresh门限减半。但是接下去并不执行慢开始算法。

  7. 考虑到如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将cwnd设置为ssthresh的大小，然后执行拥塞避免算法。

29、TCP的流量控制机制

  • 简略回答

流量控制就是为了让发送方发送数据的速度不要太快，要让接收方来得及接收。

  1. TCP采用大小可变的滑动窗口进行流量控制，窗口大小的单位是字节。
  2. 这里说的窗口大小其实就是每次传输的数据大小。
  • 详细回答

流量控制流程

  1. 当一个连接建立时，连接的每一端分配一个缓冲区来保存输入的数据，并将缓冲区的大小发送给另一端。
  2. 当数据到达时，接收方发送确认，其中包含了自己剩余的缓冲区大小。（剩余的缓冲区空间的大小被称为窗口，指出窗口大小的通知称为窗口通告 。接收方在发送的每一确认中都含有一个窗口通告。）
  3. 如果接收方应用程序读数据的速度能够与数据到达的速度一样快，接收方将在每一确认中发送一个正的窗口通告。
  4. 如果发送方操作的速度快于接收方，接收到的数据最终将充满接收方的缓冲区，导致接收方通告一个零窗口 。发送方收到一个零窗口通告时，必须停止发送，直到接收方重新通告一个正的窗口。

30、TCP的可靠传输机制

  • 简略回答

TCP 的可靠传输机制是基于连续 ARQ 协议和滑动窗口协议的。

  • 详细回答

可靠传输机制执行流程

  1. TCP 协议在发送方维持了一个发送窗口，
  2. 发送窗口以前的报文段是已经发送并确认了的报文段，
  3. 发送窗口中包含了已经发送但 未确认的报文段和允许发送但还未发送的报文段，
  4. 发送窗口以后的报文段是缓存中还不允许发送的报文段。
  5. 当发送方向接收方发 送报文时，会依次发送窗口内的所有报文段，并且设置一个定时器，
  6. 这个定时器可以理解为是最早发送但未收到确认的报文段。
  7. 如果在定时器的时间内收到某一个报文段的确认回答，则滑动窗口，将窗口的首部向后滑动到确认报文段的后一个位置，
  8. 此时如 果还有已发送但没有确认的报文段，则重新设置定时器，如果没有了则关闭定时器。
  9. 如果定时器超时，则重新发送所有已经发送 但还未收到确认的报文段，并将超时的间隔设置为以前的两倍。
  10. 当发送方收到接收方的三个冗余的确认应答后，这是一种指示， 说明该报文段以后的报文段很有可能发生丢失了，那么发送方会启用快速重传的机制，
  11. 就是当前定时器结束前，发送所有的已发 送但确认的报文段。
  12. 接收方使用的是累计确认的机制，对于所有按序到达的报文段，接收方返回一个报文段的肯定回答。
  13. 如果收到了一个乱序的报文 段，那么接方会直接丢弃，并返回一个最近的按序到达的报文段的肯定回答。
  14. 使用累计确认保证了返回的确认号之前的报文段都 已经按序到达了，所以发送窗口可以移动到已确认报文段的后面。
  15. 发送窗口的大小是变化的，它是由接收窗口剩余大小和网络中拥塞程度来决定的，
  16. TCP 就是通过控制发送窗口的长度来控制报文 段的发送速率。
  17. 但是 TCP 协议并不完全和滑动窗口协议相同，因为许多的 TCP 实现会将失序的报文段给缓存起来，并且发生重传时，只会重 传一个报文段，因此 TCP 协议的可靠传输机制更像是窗口滑动协议和选择重传协议的一个混合体。

31、TCP的三次握手和四次挥手

  • 简略回答
  • 详细回答

三次握手（Three-way Handshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

进行三次握手的主要作用

  1. 就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。
  2. 实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

TCP三次握手：

简单来说就是以下三步：

  1. 第一次握手：

    1. 客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序列号。请求发送后，客户端便进入 SYN-SENT(同步已发送) 状态。

  2. 第二次握手：

    1. 服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序列号，发送完成后便进入 SYN-RECV 同步收到 状态。

  3. 第三次握手：

    1. 当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。
    2. 客户端发完这个报文段后便进入 ESTABLISHED 已建立 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

那为什么要三次握手呢？两次不行吗？

  1. 为了确认双方的接收能力和发送能力都正常

  2. 如果是用两次握手，则会出现下面这种情况：

    1. 如客户端发出连接请求，但因连接请求报文丢失而未收到确认，于是客户端再重传一次连接请求。
    2. 后来收到了确认，建立了连接。
    3. 数据传输完毕后，就释放了连接，客户端共发出了两个连接请求报文段，其中第一个丢失，第二个到达了服务端，
    4. 但是第一个丢失的报文段只是在某些网络结点长时间滞留了，延误到连接释放以后的某个时间才到达服务端，此时服务端误认为客户端又发出一次新的连接请求，于是就向客户端发出确认报文段，同意建立连接，不采用三次握手，只要服务端发出确认，就建立新的连接了，
    5. 此时客户端忽略服务端发来的确认，也不发送数据，则服务端一致等待客户端发送数据，浪费资源。

TCP四次挥手原因

  1. 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。
  2. 其中ACK报文是用来应答的，SYN报文是用来同步的。
  3. 但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。
  4. 只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手。

简单来说就是以下四步流程：

  1. 第一次挥手：

    1. 若客户端认为数据发送完成，则它需要向服务端发送连接释放请求。

  2. 第二次挥手：

    1. 服务端收到连接释放请求后，会告诉应用层要释放 TCP 链接。
    2. 然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明客户端到服务端的连接已经释放，不再接收客户端发的数据了。
    3. 但是因为 TCP 连接是双向的，所以服务端仍旧可以发送数据给客户端。

  3. 第三次挥手：

    1. 服务端如果此时还有没发完的数据会继续发送，完毕后会向客户端发送连接释放请求，然后服务端便进入 LAST-ACK 状态。

  4. 第四次挥手：

    1. 客户端收到释放请求后，向服务端发送确认应答，此时客户端进入 TIME-WAIT 状态。该状态会持续 2MSL（最大段生存期，指报文段在网络中生存的时间，超时会被抛弃） 时间，若该时间段内没有服务端的重发请求的话，就进入 CLOSED 状态。当服务端收到确认应答后，也便进入 CLOSED 状态。

TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的，所以需要双方分别释放到对方的连接，单独一方的连接释放，只代 表不能再向对方发送数据，连接处于的是半释放的状态。

最后一次挥手中，客户端会等待一段时间再关闭的原因，是为了防止发送给服务器的确认报文段丢失或者出错，从而导致服务器 端不能正常关闭。

32、对 WebSocket 的理解

  • 简略回答
  1. WebSocket是HTML5提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。
  2. 它的实现基于TCP传输协议，并复用HTTP的握手通道。
  3. 浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。
  • 详细回答

WebSocket原理：

客户端向 WebSocket 服务器通知（notify）一个带有所有接收者ID（recipients IDs）的事件（event），

服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。

WebSocket 特点的如下：

  1. 支持双向通信，实时性更强
  2. 可以发送文本，也可以发送二进制数据
  3. 建立在TCP协议之上，服务端的实现比较容易
  4. 数据格式比较轻量，性能开销小，通信高效
  5. 没有同源限制，客户端可以与任意服务器通信
  6. 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
  7. 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

PS.未完待续，文中答案有误也欢迎评论指出！

另外作者也在找工作，欢迎公司有HC的同学内推，base地：上海、北京或杭州。

基础计划网络
版权声明：如无特殊标注，文章均来自网络，本站编辑整理，转载时请以链接形式注明文章出处，请自行分辨。

本文链接：https://www.shbk5.com/dnsj/73182.html

上一篇iqoopro5g怎么开启5g（vivoiqooneo35g怎么开）

下一篇[渝粤教育] 九江职业技术学院 客户关系管理 参考 资料

相关文章

热门文章

最新发布

标签列表