跳到主要内容

计算机网络

01 - 什么是HTTP及HTTPS?HTTP和HTTPS协议的区别​

HTTP​

HTTP即超文本运输协议，是实现网络通信的一种规范，它定义了客户端和服务器之间交换报文的格式和方式，默认使用 80 端口。它使用 TCP 作为传输层协议，保证了数据传输的可靠性。 HTTP是一个传输协议，即将数据由A传到B或将B传输到A，并且 A 与 B 之间能够存放很多第三方，如： A<=>X<=>Y<=>Z<=> B；传输的数据并不是计算机底层中的二进制包，而是完整的、有意义的数据，如HTML 文件, 图片文件, 查询结果等超文本，能够被上层应用识别；在实际应用中，HTTP常被用于在Web浏览器和网站服务器之间传递信息，以明文方式发送内容，不提供任何方式的数据加密

特点/优点

  • 支持客户/服务器模式
  • 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快
  • 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记
  • 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间
  • 无状态：HTTP协议无法根据之前的状态进行本次的请求处理

缺点

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

  • 明文传输: 协议中的报文使用的是文本形式，这就直接暴露给外界，不安全。

  • 不安全

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

HTTPS​

为了保证这些隐私数据能加密传输，让HTTP运行安全的SSL/TLS协议上，即 HTTPS = HTTP + SSL/TLS，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密；SSL 协议位于TCP/IP 协议与各种应用层协议之间，浏览器和服务器在使用 SSL 建立连接时需要选择一组恰当的加密算法来实现安全通信，为数据通讯提供安全支持

流程

  • 首先客户端通过URL访问服务器建立SSL连接
  • 服务端收到客户端请求后，会将网站支持的证书信息（证书中包含公钥）传送一份给客户端
  • 客户端的服务器开始协商SSL连接的安全等级，也就是信息加密的等级
  • 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站
  • 服务器利用自己的私钥解密出会话密钥
  • 服务器利用会话密钥加密与客户端之间的通信

HTTPS的优点

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

HTTPS的缺点

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

区别​

  • HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理，相对更安全
  • HTTP 和 HTTPS 使用连接方式不同，默认端口也不一样，HTTP是80，HTTPS是443
  • HTTPS 由于需要设计加密以及多次握手，性能方面不如 HTTP
  • HTTPS需要SSL，SSL 证书需要钱，功能越强大的证书费用越高

02 - 常见的HTTP请求方法​

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

03 - GET和POST的请求的区别​

GET: 向服务器获取数据. POST：将实体提交到指定的资源，通常会造成服务器资源的修改. 区别为:

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

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

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

参数传递方式: GET参数通过URL传递，POST放在Request body中

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

请求长度: 浏览器由于对 url 长度的限制，所以会影响 get 请求发送数据时的长度。

参数类型: get的参数类型只接受ASCII字符，post 的参数传递支持更多的数据类型。

04 - 当在浏览器中输入 Google.com 并且按下回车之后发生了什么？​

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

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

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

  4. 获取MAC地址: 当浏览器得到 IP 地址后，数据传输还需要知道目的主机 MAC 地址，因为应用层下发数据给传输层，TCP 协议会指定源端口号和目的端口号，然后下发给网络层。网络层会将本机地址作为源地址，获取的 IP 地址作为目的地址。然后将下发给数据链路层，数据链路层的发送需要加入通信双方的 MAC 地址，本机的 MAC 地址作为源 MAC 地址，目的 MAC 地址需要分情况处理。通过将 IP 地址与本机的子网掩码相与，可以判断是否与请求主机在同一个子网里，如果在同一个子网里，可以使用 APR 协议获取到目的主机的 MAC 地址，如果不在一个子网里，那么请求应该转发给网关，由它代为转发，此时同样可以通过 ARP 协议来获取网关的 MAC 地址，此时目的主机的 MAC 地址应该为网关的地址。

  5. TCP三次握手: 下面是 TCP 建立连接的三次握手的过程，首先客户端向服务器发送一个 SYN 连接请求报文段和一个随机序号，服务端接收到请求后向服务器端发送一个 SYN ACK报文段，确认连接请求，并且也向客户端发送一个随机序号。客户端接收服务器的确认应答后，进入连接建立的状态，同时向服务器也发送一个ACK 确认报文段，服务器端接收到确认后，也进入连接建立状态，此时双方的连接就建立起来了。

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

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

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

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

05 - 什么是HTTPS协议？​

超文本传输安全协议（Hypertext Transfer Protocol Secure，简称：HTTPS） 是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，利用SSL/TLS来加密数据包。HTTPS的主要目的是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。HTTP协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议TLS/SSL具有身份验证、信息加密和完整性校验的功能，可以避免此类问题发生。安全层的主要职责就是对发起的HTTP请求的数据进行加密操作 和 对接收到的HTTP的内容进行解密操作。

06 - TLS/SSL的工作原理​

TLS/SSL全称安全传输层协议（Transport Layer Security）, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，所以使用HTTPS基本上不需要对HTTP页面进行太多的改造。

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

  1. 散列函数hash: 基于散列函数验证信息的完整性

  2. 对称加密: 对称加密算法采用协商的秘钥对数据加密

  3. 非对称加密: 非对称加密实现身份认证和秘钥协商

07 - HTTPS通信（握手）过程​

  1. 客户端向服务器发起请求，请求中包含使用的协议版本号、生成的一个随机数、以及客户端支持的加密方法。

  2. 服务器端接收到请求后，确认双方使用的加密方法、并给出服务器的证书、以及一个服务器生成的随机数。

  3. 客户端确认服务器证书有效后，生成一个新的随机数，并使用数字证书中的公钥，加密这个随机数，然后发给服 务器。并且还会提供一个前面所有内容的 hash 的值，用来供服务器检验。

  4. 服务器使用自己的私钥，来解密客户端发送过来的随机数。并提供前面所有内容的 hash 值来供客户端检验。

  5. 客户端和服务器端根据约定的加密方法使用前面的三个随机数，生成对话秘钥，以后的对话过程都使用这个秘钥来加密信息。

08 - HTTPS的特点​

HTTPS的优点​

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

HTTPS的缺点​

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

09 - HTTPS是如何保证安全的？​

对称加密与非对称加密​

对称加密: 即通信的双⽅都使⽤同⼀个秘钥进⾏加解密，对称加密虽然很简单性能也好，但是⽆法解决⾸次把秘钥发给对⽅的问题，很容易被⿊客拦截秘钥。

⾮对称加密

  • 私钥 + 公钥= 密钥对
  • 即⽤私钥加密的数据,只有对应的公钥才能解密,⽤公钥加密的数据,只有对应的私钥才能解密
  • 因为通信双⽅的⼿⾥都有⼀套⾃⼰的密钥对,通信之前双⽅会先把⾃⼰的公钥都先发给对⽅
  • 然后对⽅再拿着这个公钥来加密数据响应给对⽅,等到到了对⽅那⾥,对⽅再⽤⾃⼰的私钥进⾏解密

HTTPS是如何保证安全的​

结合两种加密⽅式，将对称加密的密钥使⽤⾮对称加密的公钥进⾏加密，然后发送出去，接收⽅使⽤私钥进⾏解密得到对称加密的密钥，然后双⽅可以使⽤对称加密来进⾏沟通。 此时⼜带来⼀个问题，中间⼈问题：如果此时在客户端和服务器之间存在⼀个中间⼈,这个中间⼈只需要把原本双⽅通信互发的公钥,换成⾃⼰的公钥,这样中间⼈就可以轻松解密通信双⽅所发送的所有数据。 所以这个时候需要⼀个安全的第三⽅颁发证书（CA），证明身份的身份，防⽌被中间⼈攻击。 证书中包括：签发者、证书⽤途、使⽤者公钥、使⽤者私钥、使⽤者的HASH算法、证书到期时间等。但是问题来了，如果中间⼈篡改了证书，那么身份证明是不是就⽆效了？这个证明就⽩买了，这个时候需要⼀个新的技术，数字签名。 数字签名就是⽤CA⾃带的HASH算法对证书的内容进⾏HASH得到⼀个摘要，再⽤CA的私钥加密，最终组成数字签名。当别⼈把他的证书发过来的时候,我再⽤同样的Hash算法,再次⽣成消息摘要，然后⽤CA的公钥对数字签名解密,得到CA创建的消息摘要,两者⼀⽐,就知道中间有没有被⼈篡改了。这个时候就能最⼤程度保证通信的安全了。

10 - 常见的状态码​

  • 1XX

    • 100: （客户端继续发送请求，这是临时响应）：这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝。客户端应当继续发送请求的剩余部分，或者如果请求已经完成，忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应
    • 101：服务器根据客户端的请求切换协议，主要用于websocket或http2升级

  • 2XX

    • 200（成功）：请求已成功，请求所希望的响应头或数据体将随此响应返回
    • 201（已创建）：请求成功并且服务器创建了新的资源
    • 202（已创建）：服务器已经接收请求，但尚未处理
    • 203（非授权信息）：服务器已成功处理请求，但返回的信息可能来自另一来源
    • 204（无内容）：服务器成功处理请求，但没有返回任何内容
    • 205（重置内容）：服务器成功处理请求，但没有返回任何内容
    • 206（部分内容）：服务器成功处理了部分请求

  • 3XX

    • 300（多种选择）：针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择
    • 301（永久移动）：请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置
    • 302（临时移动）： 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求
    • 303（查看其他位置）：请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码
    • 304 not modified，表示服务器允许访问资源，但因发生请求未满足条件的情况
    • 305 （使用代理）： 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理
    • 307 （临时重定向）： 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求,临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求

  • 4XX

    • 400（错误请求）： 服务器不理解请求的语法
    • 401（未授权）： 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
    • 403（禁止）： 服务器拒绝请求
    • 404（未找到）： 服务器找不到请求的网页
    • 405（方法禁用）： 禁用请求中指定的方法
    • 406（不接受）： 无法使用请求的内容特性响应请求的网页
    • 407（需要代理授权）： 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理
    • 408（请求超时）： 服务器等候请求时发生超时

  • 5XX

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

11 - DNS完整的查询过程​

  • 首先搜索浏览器的 DNS 缓存，缓存中维护一张域名与 IP 地址的对应表

  • 若没有命中，则继续搜索操作系统的 DNS 缓存

  • 若仍然没有命中，则操作系统将域名发送至本地域名服务器，本地域名服务器采用递归查询自己的 DNS 缓存，查找成功则返回结果

  • 若本地域名服务器的 DNS 缓存没有命中，则本地域名服务器向上级域名服务器进行迭代查询

    • 首先本地域名服务器向根域名服务器发起请求，根域名服务器返回顶级域名服务器的地址给本地服务器
    • 本地域名服务器拿到这个顶级域名服务器的地址后，就向其发起请求，获取权限域名服务器的地址
    • 本地域名服务器根据权限域名服务器的地址向其发起请求，最终得到该域名对应的 IP 地址

  • 本地域名服务器将得到的 IP 地址返回给操作系统，同时自己将 IP 地址缓存起来

  • 操作系统将 IP 地址返回给浏览器，同时自己也将 IP 地址缓存起

  • 至此，浏览器就得到了域名对应的 IP 地址，并将 IP 地址缓存起

12 - TCP的三次握手和四次挥手​

三次握手​

三次握手作用: 三次握手（Three-wayHandshake）其实就是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。进行三次握手的主要作用就是为了确认双方的接收能力和发送能力是否正常、指定自己的初始化序列号为后面的可靠性传送做准备。实质上其实就是连接服务器指定端口，建立TCP连接，并同步连接双方的序列号和确认号，交换TCP窗口大小信息。

三次握手过程: 刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。

  1. 第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN，此时客户端处于 SYN_SEND 状态。
  2. 第二次握手：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_REVD 的状态。
  3. 第三次握手：客户端收到 SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK 的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

为什么不是两次握手

  • 每次握手的作用

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

  • 为什么不是两次握手原因

    • 如果是两次握手，发送端可以确定自己发送的信息能对方能收到，也能确定对方发的包自己能收到，但接收端只能确定对方发的包自己能收到 无法确定自己发的包对方能收到
    • 并且两次握手的话, 客户端有可能因为网络阻塞等原因会发送多个请求报文，延时到达的请求又会与服务器建立连接，浪费掉许多服务器的资源

四次挥手​

四次挥手过程: 刚开始双方都处于 ESTABLISHED 状态，假如是客户端先发起关闭请求。四次挥手的过程如下：

  1. 第一次挥手： 客户端会发送一个 FIN 报文，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。
  2. 第二次挥手：服务端收到 FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。
  3. 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。
  4. 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。

四次挥手原因: 因为当服务端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。 但是关闭连接时，当服务端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉客户端，“你发的FIN报文我收到了”。只有等到我服务端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四次挥手；TCP 使用四次挥手的原因是因为 TCP 的连接是全双工的，所以需要双方分别释放到对方的连接，单独一方的连接释放，只代 表不能再向对方发送数据，连接处于的是半释放的状态。最后一次挥手中，客户端会等待一段时间再关闭的原因，是为了防止发送给服务器的确认报文段丢失或者出错，从而导致服务器 端不能正常关闭。

13 - 对 WebSocket 的理解​

WebSocket是HTML5提供的一种浏览器与服务器进行全双工通讯的网络技术，属于应用层协议。它基于TCP传输协议，并复用HTTP的握手通道。浏览器和服务器只需要完成一次握手，两者之间就直接可以创建持久性的连接， 并进行双向数据传输。WebSocket 的出现就解决了半双工通信的弊端。它最大的特点是：服务器可以向客户端主动推动消息，客户端也可以主动向服务器推送消息。

WebSocket原理

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

特点

  • 支持双向通信，实时性更强，相对于HTTP请求需要等待客户端发起请求服务端才能响应，延迟明显更少
  • 可以发送文本，也可以发送二进制数据‘’
  • 建立在TCP协议之上，服务端的实现比较容易
  • 数据格式比较轻量，性能开销小，通信高效
  • 没有同源限制，客户端可以与任意服务器通信
  • 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL
  • 与 HTTP 协议有着良好的兼容性。默认端口也是80和443，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

应用场景

  • 弹幕
  • 媒体聊天
  • 协同编辑
  • 基于位置的应用
  • 体育实况更新
  • 股票基金报价实时更新