2021-你需要知道的前端网络知识-http

网络知识

HTTP/2协议

历史

• HTTP/1.0：每次请求/响应都需
  要建⽴⼀次TCP链接

• HTTP/1.1：TCP可以持久连接。
  ⼀次TCP连接就有⼀次RTT，这
  样可以减少多个RTT（往返消息）

  • 为什么不能在⼀个TCP连接中跑
    多个请求：规范严格规定请求/响
    应必须是先进先出，响应完成后
    才能进⾏下⼀个请求
  • 不可以开启多个TCP连接解决
    吗：1. 浏览器有并发限制，⼀般
    是6个；2. 服务器吃不消，⽽且
    第⼀个原因也是因为防⽌DDOS
    攻击

特性

• ⾸部压缩

  • 特性⽬标：很显然，压缩重复的
    ⾸部传输流量

  • 如何压缩

    • 前置条件

      • 两端均维护⼀份相同的静态字
        典。包含常⻅的头部名称，以及
        特别常⻅的头部名称与值的组
        合；
      • 两端均维护⼀份相同的动态字
        典。可以动态地添加内容
      • ⽀持基于静态哈夫曼码表的哈夫
        曼编码

    • 头部信息中，完全匹配字典的键
      值对，可以直接⽤字典的key，
      即⼀个字符表示

    • 只匹配到键的头部信息，可以使
      ⽤⼀个字符 + 哈夫曼编码后的内
      容 表示

    • 浏览器端可以告知服务器端往动
      态字典中添加头部信息

    • 对于不存在静态、动态字典中的
      头部信息，可以使⽤哈夫曼编码
      压缩体积

• ⼆进制分帧

  • 在⾼层 HTTP API 与低层 TCP
    之间引⼊⼆进制分帧层。⼀个请
    求报⽂会被切割成多个帧。常⻅
    的帧有HEADERS帧，DATA帧

  • 多个概念

    • 帧：HTTP/2 的最⼩通信单位，
      每个帧包括帧⾸部。帧具有⼀个
      Stream ID，接收端可以根据
      Stream ID整合帧
    • 消息：由多个帧组成的逻辑消息
    • 流：建⽴在连接上的双向数据流

  • 过程

    • TCP连接在客户端、服务器端建
      ⽴⼀条双向通道
    • A端将消息切割成多个帧
    • A端发起⼀个流，并在流中发送
      多个帧⾄B端
    • B端在同⼀个流中整合帧为消息

  • 概念包含关系

    • TCP连接包含多个双向数据流
    • 流可以双向传递多个帧
    • HEADERS帧总是先于DATA帧发
      送

• 多路复用

  • 特性⽬标：在⼀个TCP连接可以
    并发多个请求/响应

  • 概念

    • 帧具备Stream ID，接收端可以
      根据ID整合帧
    • 客户端可以将多个消息切割成多
      个帧，发起多个流，然后将帧乱
      序发送⾄服务器端
    • 服务器端根据Stream ID将帧整
      合成消息，不需要考虑发送顺
      序，可以并发进⾏

• 服务器推送

  • 特性⽬标：服务器端拥有主动推
    送资源的能⼒

  • 特性注意点

    • 推送的资源必须符合请求-响应
      循环，即先有请求，才可以推送
    • 要在请求的响应资源之前推送。
      因此客户端发起的流id是奇数，
      ⽽服务器端发起的流id是偶数

  • 推送过程

    • 前置概念：PUSH_PROMISE帧
      组成了服务器端要推送的流；推
      送必须遵循请求-响应的循环
    • 客户端向服务器端发起请求
    • 服务器端在响应当前请求“之
      前”，发出要约
      （PUSH_PROMISE）
    • 客户端可以选择缓存当前资源(即
      缓存中的Push Cache类型)，也
      可以选择放弃该资源

• 优先级与依赖性

  • 特性⽬标：让对等端⾯向并发流
    时，如何分配资源。例如：⻚⾯
    对js css与图⽚资源并发请求，
    肯定需要先为js css资源分配更
    多资源，让重要的资源更快完成
    响应。

  • 概念

    • 如何设置优先级

      • 在HEADERS帧中设置优先级
      • 带有PRIORITY帧来设置优先级
        （因此优先级有可能是动态的）

    • 优先级只是建议，并不会强制对
      等端遵守

    • 优先级树

      • 由流依赖与优先级两个特性构建
        出优先级树

HTTP/2 应⽤

• 多路复⽤

  • 资源不必打包。甚⾄由于请求/响
    应是并发的，根据⽊桶效应，影
    响当前双向数据流的瓶颈在于并
    发过程中体积最⼤的包。因此应
    该把⼤块的资源细分为多个粒度
    更⼩的包

  • 场景

    • 不必打包成⼊⼝模块
    • 不必分域名。因为⼀个TCP连接
      可以并发。⽽分域名还会多⼏次
      RTT
    • 不必整合请求成⼀个

• 服务器端推送

  • 由于减少了请求的时间，因此速
    度更快。⽽且还可以在某个请求
    内做主动推送的逻辑

  • 不必内联资源，主动推送即可

    • 例子：比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为“服务器推送”（Server Push，也叫 Cache Push）

  • 优先级与依赖性

    • 可以设置重要的初始化资源如js
      css优先于图⽚。可以提升重要
      资源的请求速度，避免图⽚先占
      ⽤更多的资源

UDP协议

定义：⾯向报⽂的简单协议

特点

• 缺乏可靠性：不提供确认，序列
  号，超时重传等等机制
• 数据报是有⻓度的
• ⽆连接的，⽀持多播与⼴播。⽽
  TCP仅有两⽅进⾏通信

应用场景

• 包总量较少的通信：DNS
• 视频、⾳频等即时通信
• ⼴播通信：⼴播、多播

TCP/IP 网络分层模型

TCP/IP 协议族里重要的一点就是分层。TCP/IP 协议族按层次分别分为以下 4 层：应用层、传输层、网络层和数据链路层。把协议族分层 ==>复杂化为简单

应⽤层：决定了向⽤户提供应⽤

服务时通信的活动。常⻅协议
有，HTTP | FTP | DNS

传输层：传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。包括两类性质不同的协议：TCP（传输控制协议）UDP（⽤户数据报协议）

⽹络层：网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方

链路层：硬件

OSI七层模型

起因：看完 TCP/IP 协议栈，你可能要问了，“它只有四层，那常说的七层怎么没见到呢？”别着急，这就是今天要说的第二个网络分层模型：OSI，全称是“开放式系统互联通信参考模型”（Open System Interconnection Reference Model）。TCP/IP 发明于 1970 年代，当时除了它还有很多其他的网络协议，整个网络世界比较混乱。这个时候国际标准组织（ISO）注意到了这种现象，感觉“野路子”太多，就想要来个“大一统”。于是设计出了一个新的网络分层模型，想用这个新框架来统一既存的各种网络协议

第七层:应用层，面向具体的应用传输数据。

第六层:表示层，把数据转换为合适、可理解的语法和语义;

第五层:会话层，维护网络中的连接状态，即保持会话和同步;

第四层:传输层，相当于TCP/IP里的传输层;

第三层:网络层，相当于TCP/IP里的网际层;

第二层:数据链路层，它基本相当于TCP/IP的链接层;

第一层:物理层，网络的物理形式，例如电缆、光纤、网卡、集线器等等;

CDN

定义：CDN，全称是“Content Delivery Network”，翻译过来就是“内容分发网络”。它应用了 HTTP 协议里的缓存和代理技术，代替源站响应客户端的请求。

起因：这个时候 CDN 就出现了，它就是专门为解决“长距离”上网络访问速度慢而诞生的一种网络应用服务。

核心原则：就近访问

CDN 的负载均衡

• GSLB 是 CDN 的“大脑”，使用 DNS 负载均衡技术，智能调度边缘节点提供服务；

CDN 的缓存代理

• 缓存系统是 CDN 的“心脏”，使用 HTTP 缓存代理技术，缓存命中就返回给用户，否则就要回源。

• 命中

  • “命中”就是指用户访问的资源恰好在缓存系统里，可以直接返回给用户；

• 回源

  • “回源”则正相反，缓存里没有，必须用代理的方式回源站取。

Web服务器

硬件含义就是物理形式或“云”形式的机器，在大多数情况下它可能不是一台服务器，而是利用反向代理、负载均衡等技术组成的庞大集群。但从外界看来，它仍然表现为一台机器，但这个形象是“虚拟的”。

软件含义的 Web 服务器可能我们更为关心，它就是提供 Web 服务的应用程序，通常会运行在硬件含义的服务器上。它利用强大的硬件能力响应海量的客户端 HTTP 请求，处理磁盘上的网页、图片等静态文件，或者把请求转发给后面的 Node.js 等业务应用（应用与web server的区别），返回动态的信息。

• Nginx
• Apache
• Tomcat

浏览器

Chrome

Firefox

Safari

IE

URI/URL

URI（Uniform Resource Identifier），中文名称是 统一资源标识符，使用它就能够唯一地标记互联网上资源。

URL（Uniform Resource Locator）， 统一资源定位符，也就是我们俗称的“网址”，它实际上是 URI 的一个子集，不过因为这两者几乎是相同的，差异不大，所以通常不会做严格的区分。

URI 主要有三个基本的部分构成

• 协议名：即访问该资源应当使用的协议，在这里是“http”
• 主机名：即互联网上主机的标记，可以是域名或 IP 地址，在这里是“nginx.org”；
• 路径：即资源在主机上的位置，使用“/”分隔多级目录，在这里是“/en/download.html”。

代理

定义：代理（Proxy）是 HTTP 协议中请求方和应答方中间的一个环节，作为“中转站”，既可以转发客户端的请求，也可以转发服务器的应答。

匿名代理：完全“隐匿”了被代理的机器，外界看到的只是代理服务器；

透明代理：顾名思义，它在传输过程中是“透明开放”的，外界既知道代理，也知道客户端；

正向代理：靠近客户端，代表客户端向服务器发送请求；

反向代理：靠近服务器端，代表服务器响应客户端的请求；

用途

• 负载均衡：把访问请求均匀分散到多台机器，实现访问集群化；
• 内容缓存：暂存上下行的数据，减轻后端的压力；
• 安全防护：隐匿 IP, 使用 WAF 等工具抵御网络攻击，保护被代理的机器；
• 数据处理：提供压缩、加密等额外的功能。

http的缓存代理（之前谈到缓存时，主要讲了客户端（浏览器）上的缓存控制，它能够减少响应时间、节约带宽，提升客户端的用户体验。但 HTTP 传输链路上，不只是客户端有缓存，服务器上的缓存也是非常有价值的，可以让请求不必走完整个后续处理流程，“就近”获得响应结果。）

HTTPS协议

起因：简单的回答是“因为 HTTP 不安全”。HTTPS不是新的协议，HTTPS 的语法、语义仍然是 HTTP，但把下层的协议由 TCP/IP 换成了 SSL/TLS；

安全的通信过程

• 机密性（Secrecy/Confidentiality）是指对数据的“保密”，只能由可信的人访问，对其他人是不可见的“秘密”，简单来说就是不能让不相关的人看到不该看的东西。

  • 实现机密性最常用的手段是“加密”（encrypt），就是把消息用某种方式转换成谁也看不懂的乱码，只有掌握特殊“钥匙”的人才能再转换出原始文本。

    • 对称加密

      • 加密算法

        • AES加密算法
        • ChaCha20加密算法

      • 加密分组模式（对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文）。）

        • GCM
        • CCM
        • Poly1305

      • 把上面这些组合起来，就可以得到 TLS 密码套件中定义的对称加密算法。比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM；ChaCha20-Poly1305 的意思是 ChaCha20 算法，使用的分组模式是 Poly1305

    • 非对称加密

      • 起因：对称加密看上去好像完美地实现了机密性，但其中有一个很大的问题：如何把密钥安全地传递给对方，术语叫“密钥交换”。

      • 概念：它有两个密钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密。公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。

      • 非对称加密算法

        • DH

        • DSA

        • RSA

          • RSA 可能是其中最著名的一个，几乎可以说是非对称加密的代名词，它的安全性基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的。

        • ECC

          • ECC（Elliptic Curve Cryptography）是非对称加密里的“后起之秀”，它基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。

    • 混合加密

      • 起因：虽然非对称加密没有“密钥交换”的问题，但因为它们都是基于复杂的数学难题，运算速度很慢，即使是 ECC 也要比 AES 差上好几个数量级。如果仅用非对称加密，虽然保证了安全，但通信速度有如乌龟、蜗牛，实用性就变成了零。

      • 操作：这就是现在 TLS 里使用的混合加密方式，其实说穿了也很简单

        • 在通信刚开始的时候使用非对称算法，比如 RSA、ECDHE，首先解决密钥交换的问题。
        • 然后用随机数产生对称算法使用的“会话密钥”（session key），再用公钥加密。因为会话密钥很短，通常只有 16 字节或 32 字节，所以慢一点也无所谓。
        • 对方拿到密文后用私钥解密，取出会话密钥。这样，双方就实现了对称密钥的安全交换，后续就不再使用非对称加密，全都使用对称加密。

• 完整性（Integrity，也叫一致性）是指数据在传输过程中没有被篡改，不多也不少，“完完整整”地保持着原状。

  • 实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。你可以把摘要算法近似地理解成一种特殊的压缩算法，它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”。换一个角度，也可以把摘要算法理解成特殊的“单向”加密算法，它只有算法，没有密钥，加密后的数据无法解密，不能从摘要逆推出原文。

    • 特点

      • 单向性
      • 雪崩效应

    • 摘要算法

      • SHA-1
      • SHA-2

    • 如何实现完整性

      • 摘要算法保证了“数字摘要”和原文是完全等价的。所以，我们只要在原文后附上它的摘要，就能够保证数据的完整性。
      • 不过摘要算法不具有机密性，所以，真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了，这有个术语，叫哈希消息认证码（HMAC）

• 身份认证（Authentication）是指确认对方的真实身份，也就是“证明你真的是你”，保证消息只能发送给可信的人。

  • 数字签名

    • 签名：数字签名是私钥对摘要的加密，可以由公钥解密后验证，实现身份认证和不可否认；
    • 签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的
    • 验签：签名和公钥一样完全公开，任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开，拿到摘要后，再比对原文验证完整性，就可以像签署文件一样证明消息确实是你发的。

  • 数字证书和 CA

    • 原因：解决公钥的信任问题
    • 公钥的分发需要使用数字证书，必须由 CA 的信任链来验证，否则就是不可信的
    • CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）。

• 第四个特性是不可否认（Non-repudiation/Undeniable），也叫不可抵赖，意思是不能否认已经发生过的行为，不能“说话不算数”“耍赖皮”。

TLS/SSL协议

• 在 HTTP 协议里，建立连接后，浏览器会立即发送请求报文。但现在是 HTTPS 协议，它需要再用另外一个“握手”过程，在 TCP 上建立安全连接，之后才是收发 HTTP 报文。

• TLS 协议的组成

  • 记录协议（Record Protocol）规定了 TLS 收发数据的基本单位：记录（record）。它有点像是 TCP 里的 segment，所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个 TCP 包里一次性发出，也并不需要像 TCP 那样返回 ACK。
  • 警报协议（Alert Protocol）的职责是向对方发出警报信息，有点像是 HTTP 协议里的状态码。比如，protocol_version 就是不支持旧版本，bad_certificate 就是证书有问题，收到警报后另一方可以选择继续，也可以立即终止连接。
  • 握手协议（Handshake Protocol）是 TLS 里最复杂的子协议，要比 TCP 的 SYN/ACK 复杂的多，浏览器和服务器会在握手过程中协商 TLS 版本号、随机数、密码套件等信息，然后交换证书和密钥参数，最终双方协商得到会话密钥，用于后续的混合加密系统。
  • 最后一个是变更密码规范协议（Change Cipher Spec Protocol），它非常简单，就是一个“通知”，告诉对方，后续的数据都将使用加密保护。那么反过来，在它之前，数据都是明文的。

• TLS1.2握手

  • Client Hello

    • 在 TCP 建立连接之后，浏览器会首先发一个“Client Hello”消息，也就是跟服务器“打招呼”。里面有客户端的版本号、支持的密码套件，还有一个随机数（Client Random），用于后续生成会话密钥

  • Server Hello

    • 服务器收到“Client Hello”后，会返回一个“Server Hello”消息。把版本号对一下，也给出一个随机数（Server Random），然后从客户端的列表里选一个作为本次通信使用的密码套件
    • “版本号对上了，可以加密，你的密码套件挺多，我选一个最合适的吧，用椭圆曲线加 RSA、AES、SHA384。我也给你一个随机数，你也得留着。”
    • 服务器为了证明自己的身份，就把证书也发给了客户端（Server Certificate）。

  • Client 验证证书，生成secret

    • 客户端验证服务端传来的证书和签名是否通过，如果验证通过，则传递client_params这个参数给服务器。
      接着客户端通过ECDHE算法计算出pre_random，其中传入两个参数:server_params和client_params。现在你应该清楚这个两个参数的作用了吧，由于ECDHE基于椭圆曲线离散对数，这两个参数也称作椭圆曲线的公钥。
      客户端现在拥有了client_random、server_random和pre_random，接下来将这三个数通过一个伪随机数函数来计算出最终的secret。

  • Server 生成 secret

    • 现在服务端开始用ECDHE算法生成pre_random，接着用和客户端同样的伪随机数函数生成最后的secret。（这个secret key就是AES加密算法的钥匙 ）

  • 注意事项

    • 第一、实际上 TLS 握手是一个双向认证的过程，从 step1 中可以看到，客户端有能力验证服务器的身份，那服务器能不能验证客户端的身份呢？
      当然是可以的。具体来说，在 step3中，客户端传送client_params，实际上给服务器传一个验证消息，让服务器将相同的验证流程(哈希摘要 + 私钥加密 + 公钥解密)走一遍，确认客户端的身份。
    • 第二、当客户端生成secret后，会给服务端发送一个收尾的消息，告诉服务器之后的都用对称加密，对称加密的算法就用第一次约定的。服务器生成完secret也会向客户端发送一个收尾的消息，告诉客户端以后就直接用对称加密来通信。
      这个收尾的消息包括两部分，一部分是Change Cipher Spec，意味着后面加密传输了，另一个是Finished消息，这个消息是对之前所有发送的数据做的摘要，对摘要进行加密，让对方验证一下。
      当双方都验证通过之后，握手才正式结束。后面的 HTTP 正式开始传输加密报文。
    • 比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256：使用ECDHE进行密钥交换（文中已经讲了，用它算出Pre_Master，成会话密钥Master Secret。密钥交换过程中应该会使用到非对称加密中的公钥加密），RSA进行身份验证（私钥加密公钥解密），使用128位GCM分组工作模式的AES进行消息和会话密钥的对称加密（加密真正的消息），使用SHA256摘要算法（如HMAC、PRM）对数据签名，保证数据完整性

  • RSA 握手过程

    • 大体的流程没有变，只是“Pre-Master”不再需要用算法生成，而是客户端直接生成随机数，然后用服务器的公钥加密，通过“Client Key Exchange”消息发给服务器。服务器再用私钥解密，这样双方也实现了共享三个随机数，就可以生成主密钥。
    • RSA 密钥交换不具有“前向安全”：说到底，RSA 握手下，服务器私钥是不变的，从而导致不具有“前向安全”。而 ECDHE 的私钥却是动态的，黑客拿到了一个，也只能解密一个密文。

• TLS1.3

  • TLS1.3 的三个主要改进目标

    • 最大化兼容性

    • 强化安全

      • 伪随机数函数由 PRF 升级为 HKDF（HMAC-based Extract-and-Expand Key Derivation Function）
      • 明确禁止在记录协议里使用压缩
      • 废除了 RC4、DES 对称加密算法
      • 废除了 ECB、CBC 等传统分组模式
      • 废除了 MD5、SHA1、SHA-224 摘要算法
      • 废除了 RSA、DH 密钥交换算法和许多命名曲线

    • 提升性能

      • HTTPS 建立连接时除了要做 TCP 握手，还要做 TLS 握手，在 1.2 中会多花两个消息往返（2-RTT），可能导致几十毫秒甚至上百毫秒的延迟，在移动网络中延迟还会更严重。
      • 现在因为密码套件大幅度简化，也就没有必要再像以前那样走复杂的协商流程了。TLS1.3 压缩了以前的“Hello”协商过程，删除了“Key Exchange”消息，把握手时间减少到了“1-RTT”，效率提高了一倍。TLS1.3 也简化了握手过程，完全握手只需要一个消息往返（RTT），提升了性能

  • TLS1.3握手过程

    • Client Hello

      • 密码套件和随机数（Client Random）结构都是一样的（不过这时的随机数是 32 个字节），“Client Hello”里的扩展，“supported_versions”表示这是 TLS1.3，“supported_groups”是支持的曲线，“key_share”是曲线对应的参数

    • Server Hello

      • 服务器收到“Client Hello”同样返回“Server Hello”消息，还是要给出一个随机数（Server Random）和选定密码套件
      • 重点是后面的扩展。“supported_versions”里确认使用的是 TLS1.3，然后在“key_share”扩展带上曲线和对应的公钥参数
      • 这时只交换了两条消息，客户端和服务器就拿到了四个共享信息：Client Random 和 Server Random、Client Params 和 Server Params，两边就可以各自用 ECDHE 算出“Pre-Master”，再用 HKDF 生成主密钥“Master Secret”，效率比 TLS1.2 提高了一大截。

• 中间⼈攻击：中间⼈也可以产
  ⽣⼀对⾮对称密钥，然后代替假
  装服务器发布公钥给客户端

  • 避免中间⼈攻击，证明公钥是
    服务器的公钥 => 使⽤证书

    • 0. 采⽤⾮对称加密。由“数字证
         书认证机构”（CA）⽣成⼀对公
         钥私钥
    • 1. 服务器将⾃⼰的域名与公钥交
         给CA做认证。CA使⽤⾃⼰的私
         钥加密“服务器端公钥”与“服务
         器端信息摘要”，⽣成的密⽂就
         是签名
    • 2. CA将服务器信息、签名、有
         效期的信息集成⼀张证书，颁发
         给服务器
    • 3. 客户端取到证书后，使⽤CA
         公钥解密签名得出服务器端信息
         摘要，若与证书上的服务器端信
         息⼀致，则证明是经过CA验证的
  • 6. CA的公钥由谁认证？内置与
       浏览器/操作系统中

  • 摘要算法——具有单向性和雪崩性，单向性强调只能加密不能解码，雪崩性强调明文稍微变化一丁点那摘要就会产生巨大的变化。摘要算法怎么使用，把明文和摘要一起发送过去就可以验证明文是否被篡改了。但是防止不了明文修改后把摘要也篡改的情况，所以，后面有了数字签名，数字签名保证完整性

  • 数字签名——私钥加密＋摘要算法，用私钥加密摘要然后用公钥验证，就可以实现身份认证以及不可否认的特性。

  • CA——也即证书认证机制防止黑客伪造公钥，如果用的是黑客伪造的公钥，那自然黑客就能用其私有加密摘要伪造某宝的身份了。所以，公钥只能有可信度比较高的三方来发布，防止黑客伪造

跨域

同源策略

• 同源策略是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSRF等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

• 当协议、子域名、主域名、端口号中任意一个不相同时，都算作不同域。不同域之间相互请求资源，就算作“跨域”

• 同源策略限制内容有

  • Cookie、LocalStorage、IndexedDB 等存储性内容
  • DOM 节点
  • AJAX 请求发送后，结果被浏览器拦截了

解决方案

• 图像ping

  • 利用img src标签没有跨域限制的漏洞

• jsonp

  • 利用

HTTP协议

定义：超文本传输协议（HTTP 是一个在计算机世界里专门在两点之间传输文字、图片、音频、视频等超文本数据的约定和规范）（HTTP 是一个"传输协议"，但它不关心寻址、路由、数据完整性等传输细节，而要求这些工作都由下层来处理。因为互联网上最流行的是 TCP/IP 协议，而它刚好满足 HTTP 的要求，所以互联网上的 HTTP 协议就运行在了 TCP/IP 上，HTTP 也就可以更准确地称为“HTTP over TCP/IP”。）

报文

• 起始行（start line）：描述请求或响应的基本信息；
• 头部字段集合（header）：使用 key-value 形式更详细地说明报文；
• 消息正文（entity）：实际传输的数据，它不一定是纯文本，可以是图片、视频等二进制数据。

请求头和响应头

• 前两部分起始行和头部字段经常又合称为“请求头”或“响应头”，消息正文又称为“实体”，但与“header”对应，很多时候就直接称为“body”

请求行

• 请求报文里的起始行也就是请求行（request line），它简要地描述了客户端想要如何操作服务器端的资源。

  • 请求方法：是一个动词，如 GET/POST，表示对资源的操作；
  • 请求目标：通常是一个 URI，标记了请求方法要操作的资源；
  • 版本号：表示报文使用的 HTTP 协议版本。

状态行

• 看完了请求行，我们再看响应报文里的起始行，在这里它不叫“响应行”，而是叫“状态行”status line，意思是服务器响应的状态。

  • 版本号：表示报文使用的 HTTP 协议版本；
  • 状态码：一个三位数，用代码的形式表示处理的结果，比如 200 是成功，500 是服务器错误；
  • 原因：作为数字状态码补充，是更详细的解释文字，帮助人理解原因。

头部字段

• 通用字段：在请求头和响应头里都可以出现；

  • Cache-Control 能够控制缓存的行为

    • public：所有内容都将被缓存（客户端和代理服务器都可缓存）
    • private：所有内容只有客户端可以缓存，Cache-Control的默认取值
    • no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定
    • no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
    • max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效

  • Connection

    • 控制不再转发给代理的首部字段

      • Connection: 不再转发的首部字段名

    • 管理持久连接

      • Connection: close；HTTP/1.1 版本的默认连接都是持久连接。为此，客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定 Connection 首部字段的值为 Close
      • Connection: Keep-Alive

  • Date 表明创建 HTTP 报文的日期和时间

  • Upgrade

    • 首部字段 Upgrade 用于检测 HTTP 协议及其他协议是否可使用更高的版本进行通信，其参数值可以用来指定一个完全不同的通信协议

• 请求字段：仅能出现在请求头里，进一步说明请求信息或者额外的附加条件；

  • Host 会告知服务器，请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段

  • Accept 首部字段可通知服务器，用户代理能够处理的媒体类型及媒体类型的相对优先级

    • 文本文件：text/html, text/plain, text/css …
      application/xhtml+xml, application/xml …

    • 图片文件：image/jpeg, image/gif, image/png …

    • 视频文件：video/mpeg, video/quicktime …

    • 应用程序使用的二进制文件：application/octet-stream, application/zip …

  • Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多种字符集。与首部字段 Accept 相同的是可用权重 q 值来表示相对优先级。

  • Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。可一次性指定多种内容编码。

    - gzip:由文件压缩程序 gzip（GNU zip）生成的编码格式（RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循环冗余校验（Cyclic Redundancy Check，通称 CRC）。
    
    - compress:由 UNIX 文件压缩程序 compress 生成的编码格式，采用 Lempel-Ziv-Welch 算法（LZW）。
    
    - deflate:组合使用 zlib 格式（RFC1950）及由 deflate 压缩算法（RFC1951）生成的编码格式。
    - identity:不执行压缩或不会变化的默认编码格式
    

    • Accept-Language 用来告知服务器用户代理能够处理的自然语言集（指中文或英文等），以及自然语言集的相对优先级。可一次指定多种自然语言集。

    • Authorization 是用来告知服务器，用户代理的认证信息（证书值）。通常，想要通过服务器认证的用户代理会在接收到返回的 401 状态码响应后，把首部字段 Authorization 加入请求中。共用缓存在接收到含有 Authorization 首部字段的请求时的操作处理会略有差异。

    • 附带条件请求（形如 If-xxx 这种样式的请求首部字段，都可称为条件请求。服务器接收到附带条件的请求后，只有判断指定条件为真时，才会执行请求。）

      • If-Modified-Since:如果在 If-Modified-Since 字段指定的日期时间后，资源发生了更新，服务器会接受请求，如果请求的资源都没有过更新，则返回状态码 304 Not Modified 的响应。If-Modified-Since 用于确认代理或客户端拥有的本地资源的有效性。获取资源的更新日期时间，可通过确认首部字段 Last-Modified 来确定
      • If-None-Match：用于指定 If-None-Match 字段值的实体标记（ETag）值与请求资源的 ETag 不一致时，它就告知服务器处理该请求。

    • 首部字段 Referer 会告知服务器请求的原始资源的 URI。

• 响应字段：仅能出现在响应头里，补充说明响应报文的信息；

  • Age 能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒。
  • 首部字段 ETag 能告知客户端实体标识。它是一种可将资源以字符串形式做唯一性标识的方式。服务器会为每份资源分配对应的 ETag 值。
  • 首部字段 Location 可以将响应接收方引导至某个与请求 URI 位置不同的资源。基本上，该字段会配合 3xx ：Redirection 的响应，提供重定向的 URI。

• 实体字段：它实际上属于通用字段，但专门描述 body 的额外信息。

  • Content-Type 说明了实体主体内对象的媒体类型。和首部字段 Accept 一样，字段值用 type/subtype 形式赋值

  • Allow：用于通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。当服务器接收到不支持的 HTTP 方法时，会以状态码 405 Method Not Allowed 作为响应返回。与此同时，还会把所有能支持的 HTTP 方法写入首部字段 Allow 后返回。

  • Content-Encoding 会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行的压缩

    • gzip
    • compress
    • deflate
    • identity

  • Content-Language 会告知客户端，实体主体使用的自然语言（指中文或英文等语言）

  • Content-Length 表明了实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不能再使用 Content-Length 首部字段

  • Content-Length 表明了实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不能再使用 Content-Length 首部字段

  • Expires 会将资源失效的日期告知客户端。（到了HTTP/1.1，Expire已经被Cache-Control替代）

  • Last-Modified 指明资源最终修改的时间。一般来说，这个值就是 Request-URI 指定资源被修改的时间。

  • Set-Cookie：当服务器准备开始管理客户端的状态时，会事先告知各种信息

    • Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。
    • Cookie 的 path 属性可用于限制指定 Cookie 的发送范围的文件目录
    • 通过 Cookie 的 domain 属性指定的域名可做到与结尾匹配一致。比如，当指定 example.com 后，除 example.com 以外，www.example.com 或 www2.example.com 等都可以发送 Cookie
    • Cookie 的 secure 属性用于限制 Web 页面仅在 HTTPS 安全连接时，才可以发送 Cookie
    • Cookie 的 HttpOnly 属性是 Cookie 的扩展功能，它使 JavaScript 脚本无法获得 Cookie。其主要目的为防止跨站脚本攻击（Cross-site scripting，XSS）对 Cookie 的信息窃取

响应状态码

• 1××：提示信息，表示目前是协议处理的中间状态，还需要后续的操作；

  • “101 Switching Protocols”。它的意思是客户端使用 Upgrade 头字段，要求在 HTTP 协议的基础上改成其他的协议继续通信，比如 WebSocket。而如果服务器也同意变更协议，就会发送状态码 101，但这之后的数据传输就不会再使用 HTTP 了。

• 2××：成功，报文已经收到并被正确处理；

  • “200 OK”是最常见的成功状态码，表示一切正常，服务器如客户端所期望的那样返回了处理结果，如果是非 HEAD 请求，通常在响应头后都会有 body 数据。
  • “204 No Content”是另一个很常见的成功状态码，它的含义与“200 OK”基本相同，但响应头后没有 body 数据。所以对于 Web 服务器来说，正确地区分 200 和 204 是很必要的。
  • “206 Partial Content”是 HTTP 分块下载或断点续传的基础，在客户端发送“范围请求”、要求获取资源的部分数据时出现，它与 200 一样，也是服务器成功处理了请求，但 body 里的数据不是资源的全部，而是其中的一部分。

• 3××：重定向，资源位置发生变动，需要客户端重新发送请求；

  • 301 Moved Permanently”俗称“永久重定向”，含义是此次请求的资源已经不存在了，需要改用改用新的 URI 再次访问。

    • 比如，你的网站升级到了 HTTPS，原来的 HTTP 不打算用了，这就是“永久”的，所以要配置 301 跳转，把所有的 HTTP 流量都切换到 HTTPS。

  • “302 Found”，曾经的描述短语是“Moved Temporarily”，俗称“临时重定向”，意思是请求的资源还在，但需要暂时用另一个 URI 来访问。

    • 今天夜里网站后台要系统维护，服务暂时不可用，这就属于“临时”的，可以配置成 302 跳转，把流量临时切换到一个静态通知页面，浏览器看到这个 302 就知道这只是暂时的情况，不会做缓存优化，第二天还会访问原来的地址。

  • “304 Not Modified” 是一个比较有意思的状态码，它用于 If-Modified-Since 等条件请求，表示资源未修改，用于缓存控制。它不具有通常的跳转含义，但可以理解成“重定向已到缓存的文件”（即“缓存重定向”）。

• 4××：客户端错误，请求报文有误，服务器无法处理；

  • “400 Bad Request”是一个通用的错误码，表示请求报文有错误，但具体是数据格式错误、缺少请求头还是 URI 超长它没有明确说，只是一个笼统的错误，客户端看到 400 只会是“一头雾水”“不知所措”。所以，在开发 Web 应用时应当尽量避免给客户端返回 400，而是要用其他更有明确含义的状态码。
  • “403 Forbidden”实际上不是客户端的请求出错，而是表示服务器禁止访问资源。原因可能多种多样，例如信息敏感、法律禁止等，如果服务器友好一点，可以在 body 里详细说明拒绝请求的原因，不过现实中通常都是直接给一个“闭门羹”。
  • “404 Not Found”可能是我们最常看见也是最不愿意看到的一个状态码，它的原意是资源在本服务器上未找到，所以无法提供给客户端。但现在已经被“用滥了”，只要服务器“不高兴”就可以给出个 404，而我们也无从得知后面到底是真的未找到，还是有什么别的原因，某种程度上它比 403 还要令人讨厌。
  • 405 Method Not Allowed：不允许使用某些方法操作资源，例如不允许 POST 只能 GET；
  • 406 Not Acceptable：资源无法满足客户端请求的条件，例如请求中文但只有英文；
  • 408 Request Timeout：请求超时，服务器等待了过长的时间；
  • 409 Conflict：多个请求发生了冲突，可以理解为多线程并发时的竞态；
  • 413 Request Entity Too Large：请求报文里的 body 太大；
  • 414 Request-URI Too Long：请求行里的 URI 太大；
  • 429 Too Many Requests：客户端发送了太多的请求，通常是由于服务器的限连策略；
  • 431 Request Header Fields Too Large：请求头某个字段或总体太大；

• 5××：服务器错误，服务器在处理请求时内部发生了错误。

  • “500 Internal Server Error”与 400 类似，也是一个通用的错误码，服务器究竟发生了什么错误我们是不知道的。不过对于服务器来说这应该算是好事，通常不应该把服务器内部的详细信息，例如出错的函数调用栈告诉外界。虽然不利于调试，但能够防止黑客的窥探或者分析。
  • “501 Not Implemented”表示客户端请求的功能还不支持，这个错误码比 500 要“温和”一些，和“即将开业，敬请期待”的意思差不多，不过具体什么时候“开业”就不好说了。
  • “502 Bad Gateway”通常是服务器作为网关或者代理时返回的错误码，表示服务器自身工作正常，访问后端服务器时发生了错误，但具体的错误原因也是不知道的。
  • “503 Service Unavailable”表示服务器当前很忙，暂时无法响应服务，我们上网时有时候遇到的“网络服务正忙，请稍后重试”的提示信息就是状态码 503。503 响应报文里通常还会有一个“Retry-After”字段，指示客户端可以在多久以后再次尝试发送请求。

简单请求与复杂请求

• 概念：针对CORS（跨域）请求，浏览器将其分成两个类型：简单请求和复杂请求，一般触发预检的请求则称为"复杂请求"。

• 简单请求

  • 请求方法为GET、HEAD、POST时发的请求
  • 人为设置了规范集合之内的首部字段，如Accept/Accept-Language/Content-Language/Content-Type/DPR/Downlink/Save-Data/Viewport-Width/Width
  • Content-Type 的值仅限于下列三者之一,即application/x-www-form-urlencoded、multipart/form-data、text/plain
  • 请求中的任意 XMLHttpRequestUpload 对象均没有注册任何事件监听器
  • 请求中没有使用 ReadableStream 对象

• 复杂请求

  • 使用了下面任一 HTTP 方法，PUT/DELETE/CONNECT/OPTIONS/TRACE/PATCH
  • 为设置了以下集合之外首部字段，即简单请求外的字段
  • Content-Type 的值不属于下列之一，即application/x-www-form-urlencoded、multipart/form-data、text/plain

• options 关键的首部字段

  • request header 的关键字段

    • Access-Control-Request-Method：POST 告知服务器，实际请求将使用 POST 方法

    • Access-Control-Request-Headers：告知服务器，实际请求将携带的自定义请求首部字段

  • response header 的关键字段

    • Access-Control-Allow-Methods： 表明服务器允许客户端使用什么方法发起请求
    • Access-Control-Allow-Origin：允许跨域请求的域名，如果要允许所有域名则设置为 *
    • Access-Control-Max-Age: 指定了预检请求的结果能够被缓存多久

• Options 预请求优化

  • 转为简单请求，如用 JSONP 做跨域请求
  • 对 options 请求进行缓存，服务器端设置 Access-Control-Max-Age 字段，那么当第一次请求该 URL 时会发出 OPTIONS 请求，浏览器会根据返回的 Access-Control-Max-Age 字段缓存该请求的 OPTIONS 预检请求的响应结果（具体缓存时间还取决于浏览器的支持的默认最大值，取两者最小值，一般为 10 分钟）。在缓存有效期内，该资源的请求（URL 和 header 字段都相同的情况下）不会再触发预检。（chrome 打开控制台可以看到，当服务器响应 Access-Control-Max-Age 时只有第一次请求会有预检，后面不会了。注意要开启缓存，去掉 disable cache 勾选。）

请求方法

• 类型

  • GET：获取资源，可以理解为读取或者下载数据；
  • HEAD：获取资源的元信息；（GET 方法类似，也是请求从服务器获取资源，服务器的处理机制也是一样的，但服务器不会返回请求的实体数据，只会传回响应头，也就是资源的“元信息”。）
  • POST：向资源提交数据，相当于写入或上传数据；
  • PUT：类似 POST；
  • DELETE：删除资源；
  • CONNECT：建立特殊的连接隧道；
  • OPTIONS：列出可对资源实行的方法；
  • TRACE：追踪请求 - 响应的传输路径。

• 安全与幂等

  • 安全（在 HTTP 协议里，所谓的“安全”是指请求方法不会“破坏”服务器上的资源，即不会对服务器上的资源造成实质的修改。）

    • 按照这个定义，只有 GET 和 HEAD 方法是“安全”的，因为它们是“只读”操作，只要服务器不故意曲解请求方法的处理方式，无论 GET 和 HEAD 操作多少次，服务器上的数据都是“安全的”。
    • 而 POST/PUT/DELETE 操作会修改服务器上的资源，增加或删除数据，所以是“不安全”的。

  • 所谓的“幂等”实际上是一个数学用语，被借用到了 HTTP 协议里，意思是多次执行相同的操作，结果也都是相同的，即多次“幂”后结果“相等”。

    • 很显然，GET 和 HEAD 既是安全的也是幂等的，DELETE 可以多次删除同一个资源，效果都是“资源不存在”，所以也是幂等的。
    • POST 是“新增或提交数据”，多次提交数据会创建多个资源，所以不是幂等的；
    • PUT 是“替换或更新数据”，多次更新一个资源，资源还是会第一次更新的状态，所以是幂等的。

HTTP协议优缺点

• 优点

  • 简单、灵活、易于扩展

• 缺点

  • 明文

  • 无状态

  • HTTP 队头阻塞

    • 并发连接
      对于一个域名允许分配多个长连接，那么相当于增加了任务队列，不至于一个队伍的任务阻塞其它所有任务。在RFC2616规定过客户端最多并发 2 个连接，不过事实上在现在的浏览器标准中，这个上限要多很多，Chrome 中是 6 个。
    • 域名分片
      一个域名不是可以并发 6 个长连接吗？那我就多分几个域名。
      比如 content1.sanyuan.com 、content2.sanyuan.com。
      这样一个sanyuan.com域名下可以分出非常多的二级域名，而它们都指向同样的一台服务器，能够并发的长连接数更多了，事实上也更好地解决了队头阻塞的问题。

一个HTTP请求全周期

• DNS解析 => 得出ip地址

• HTTP：⽣成请求报⽂

• TCP：将请求报⽂切割为多个报
  ⽂段，确保报⽂段准确送到对⽅
  ⼿上。使⽤三次握⼿确保连接可
  靠

• ip地址：节点被分配的地址

• ip

  • 概念

    • ip地址：节点被分配的地址
    • MAC地址：⽹卡所属的固定地
      址，⼀般来说不会变化
    • ARP协议：⽤来解析地址的协
      议，根据ip反查出MAC地址

  • 过程：搜索对⽅的地⽅，⼀边中
    转 ⼀边传送

• TCP：重组报⽂

• HTTP：对请求进⾏处理

DNS协议

DNS缓存

DNS解析的过程（域名解析）tip:发送一个DNS请求

• 基于 UDP 协议做的查询

  • 性能问题：很明显使用基于UDP的DNS协议只要一个请求、一个应答就好了

而使用基于TCP的DNS协议要三次握手、发送数据以及应答、四次挥手

明显基于TCP协议的DNS更浪费网络资源！
- 数据一致性层面：DNS数据包不是那种大数据包，所以使用UDP不需要考虑分包，如果丢包那么就是全部丢包，如果收到了数据，那就是收到了全部数据！所以只需要考虑丢包的情况，那就算是丢包了，重新请求一次就好了。而且DNS的报文允许填入序号字段，对于请求报文和其对应的应答报文，这个字段是相同的，通过它可以区分DNS应答是对应的哪个请求

- DNS通常是基于UDP的，但当数据长度大于512字节的时候，为了保证传输质量，就会使用基于TCP的实现方式

• 浏览器DNS缓存

• 操作系统缓存

• Hosts文件

• 非权威域名服务器

  • 首先，许多大公司、网络运行商都会建立自己的 DNS 服务器，作为用户 DNS 查询的代理，代替用户访问核心 DNS 系统。这些“野生”服务器被称为“非权威域名服务器”，可以缓存之前的查询结果，如果已经有了记录，就无需再向根服务器发起查询，直接返回对应的 IP 地址

• 根域名服务器

• 顶级域名服务器

• 权威域名服务器

域名

• 顶级域名
• 二级域名

DNS解析应用场景

• 使用 DNS 可以实现基于域名的负载均衡，既可以在内网，也可以在外网。

• “域名屏蔽”

  • 对域名直接不解析，返回错误，让你无法拿到 IP 地址，也就无法访问网站；

• “域名劫持”

  • 也叫“域名污染”，你要访问 A 网站，但 DNS 给了你 B 网站。

IP 协议

IP 协议是“Internet Protocol”的缩写，主要目的是解决寻址和路由问题，以及如何在两点间传送数据包。IP 协议使用“IP 地址”的概念来定位互联网上的每一台计算机。可以对比一下现实中的电话系统，你拿着的手机相当于互联网上的计算机，而要打电话就必须接入电话网，由通信公司给你分配一个号码，这个号码就相当于 IP 地址。

特点

• IP 协议提供可靠的、字节流形式的通信

  • “可靠”是指保证数据不丢失
  • “字节流”是指保证数据完整

TCP协议

定义：TCP提供⾯向连接、可靠

的字节流服务

头部

• Sequence number：保证传输的
  报⽂是有序的，对端可按照序号
  拼接报⽂

• Acknowledgement Number：表
  现数据接收端对下⼀个字节序号
  的期望，也表示上⼀个字节已经
  收到

• Window Size：表示还能接受多
  少字节的数据，⽤于流量控制

• 标识符

  • URG=1：紧急报⽂
  • ACK=1：确认号字段有效。连接
    成功后的所有报⽂都必须把ACK
    标识符设置为⼀
  • SYN=1：当SYN=1且ACK=0时，
    表明这是⼀个连接请求报⽂，当
    SYN=1且ACK=1时，表示这是⼀
    个同意连接请求的应答报⽂
  • FIN=1：表示报⽂段是⼀个释放
    连接的请求报⽂
  • PSH=1：该字段为⼀表示接收端
    应该⽴即将数据 push 给应⽤
    层，⽽不是等到缓冲区满后再提
    交
  • RST=1：该字段为⼀表示当前
    TCP 连接出现严重问题，可能需
    要重新建⽴ TCP 连接，也可以
    ⽤于拒绝⾮法的报⽂段和拒绝连
    接请求

连接-三次握⼿

• 第⼀次握⼿：客户端发送⼀个
  SYN=1且具备初始序号seq=x的
  TCP包，表示想要连接服务器端
  接⼝。发送完毕后客户端进⼊
  SYN_SEND状态

• 第⼆次握⼿：服务器端发送⼀个
  SYN=1、ACK=1、序号(seq)为服
  务器⾃⼰的ISN序列号、且确认
  序号(ACKnum)为客户端序号加
  ⼀(x+1)的TCP包，表示确认应
  答。发送完毕后，服务器端进⼊
  SYN_ RECEIVED状态

• 第三次握⼿：客户端发送⼀个
  ACK=1、确认序号(ACKnum)为
  服务器ISN序号加⼀(y+1)的TCP
  包，表示确认连接的应答。发送
  完毕后客户端进⼊
  ESTABLISHED状态，服务器端
  接收到包后也会进⼊
  ESTABLISHED状态。TCP握⼿
  结束

• 为什么 TCP 建立连接需要三次握手，明明两次就可以建立起连接？

  • 因为这是为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误

• 注意❗️确认序号

拆除连接-四次挥⼿

• 第⼀次挥⼿(FIN=1, seq=x)：客
  户端发送⼀个FIN=1且序号为⾃
  ⼰ISN序列号的包，表示⾃⼰已
  经没有数据要传输了，但仍可以
  接收数据

• 第⼆次挥⼿(ACK=1,
  ACKnum=x+1)：服务器端发送
  ⼀个ACK=1且确认序号为客户端
  序号+1的包，表示收到客户端关
  闭连接的请求，但还没有准备好
  关闭，并进⼊CLOSE_WAIT状态

• 第三次挥⼿(FIN=1, seq=y)：服
  务器端发送FIN=1且序号为⾃⼰
  序列号的包，表示准备好关闭连
  接，向客户端确认关闭连接的请
  求，并进⼊LAST-ACK 状态

• 第四次挥⼿(ACK=1,
  ACKnum=y+1)

  • 客户端发送ACK=1且序号为服务
    器端序号+1的包，表示收到确认
    关闭连接请求的包。发送完毕进
    ⼊TIME_WAIT状态
  • 服务器端接收到包后关闭连接，
    进⼊CLOSED状态
  • 客户端在固定时间内（两个最⼤
    段⽣命周期，2MSL，2
    Maximum Segment Lifetime）
    没收到B可能重传的请求，则认
    为服务器已经正常关闭，⾃⼰也
    进⼊CLOSED状态

• 为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

  • 这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是❗️还能接收数据，我们也未必全部数据都发送给对方了，所以我们不可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，我们的ACK和FIN一般都会分开发送

• 序号x为客户端 y是服务端 这样记忆

• 作出应答才算一次握手或者挥手

特点

• TCP 是一个有状态的协议，需要先与对方建立连接然后才能发送数据，而且保证数据不丢失不重复。

TCP/IP协议族

定义：TCP 协议是“Transmission Control Protocol”的缩写，意思是“传输控制协议”，它位于 IP 协议之上，基于 IP 协议提供可靠的、字节流形式的通信，是 HTTP 协议得以实现的基础。

HTTP、DNS、TCP、UDP、IP等等协议

安全

XSS跨站脚本攻击

• 类型

  • 反射型

    • 在一个反射型 XSS 攻击过程中，恶意 JavaScript 脚本属于用户发送给网站请求中的一部分（通常是url连接带了攻击脚本参数发送给服务端），随后网站又把恶意 JavaScript 脚本返回给用户（页面会进行渲染）。当恶意 JavaScript 脚本在用户页面中被执行时，黑客就可以利用该脚本做一些恶意操作。

    • 并不是存储在服务端，注意这种反射型攻击是需要特定的链接支持的

      • http://localhost:3000/?xss=

  • 存储型

    • ⽤户输⼊数据会被存储到服务器
      端，此时攻击者可以传⼊恶意脚
      本，上传⾄服务器

    • 场景

      • 如论坛系统，⽤户输⼊框输⼊恶
        意代码

  • DOM型

    • 过程

      • 基于 DOM 的 XSS 攻击是不牵涉到页面 Web 服务器的。具体来讲，黑客通过各种手段将恶意脚本注入用户的页面中，比如通过网络劫持在页面传输过程中修改 HTML 页面的内容，这种劫持类型很多，有通过 WiFi 路由器劫持的，有通过本地恶意软件来劫持的，它们的共同点是在 Web 资源传输过程或者在用户使用页面的过程中修改 Web 页面的数据。
      • 恶意代码注⼊在html中

• 本质：恶意代码注⼊到浏览器中
  运⾏。即攻击者提交代码，浏览
  器执⾏代码两⼤步骤。

• 应对策略

  • 输⼊过滤（应对提交代码⼀
    步）：由于内容⽤处存在不确定
    性。只有在注⼊html时，转义的
    地⽅才会正常显示。如果当⼀个
    字符串做计算、渲染，或者说内
    容不只是给前端⽤的情况会，就
    会引发乱码等等问题。因此并不
    可靠

  • 应对浏览器执⾏代码

    • 纯前端渲染：如使⽤innerText、
      setAttribute、style等接⼝⽽⾮
      直接注⼊html
    • 对仍需要注⼊html的地⽅，要做
      充分转义(对>< # %\等字符做转义)

    • 预防DOM型xss：谨慎执⾏来源
      不明的数据，如：location.href

      “UNTRUSTED”;setTimeout(“U
      NTRUSTED”); 避免使⽤vhtml，
      dangerouslySetInnerHTML等功
      能

  • CSP网页安全政策

    • 本质：CSP 的实质就是白名单制度，开发者明确告诉客户端，哪些外部资源可以加载（请求）和执行，等同于提供白名单。它的实现和执行全部由浏览器完成，开发者只需提供配置

    • 启用CSP

      • 通过 HTTP 头信息的Content-Security-Policy的字段

      • 通过网页的标签

    • 上报策略

  • httpOnly：避免恶意代码获取
    toke

  • 输⼊⻓度限制

  • 验证码

CSRF(跨站请求伪造)

• 概念

  • 即跨站请求伪造，指的是黑客诱导用户点击链接，打开黑客的网站，然后黑客利用用户目前的登录状态发起跨站请求（请求会默认携带cookie 这就是问题由来）

• 防御措施

  • CSRF的两个特点

    • 通常发⽣在第三⽅域名
    • 攻击者通常不能获取cookie，但
      是会使⽤

  • 思路

    • 阻⽌不明外域的访问

      • 检查发起请求的origin与referer
        是否在⽩名单内

      • 利用Cookie的SameSite属性

        • 在Strict模式下，浏览器完全禁止第三方请求携带Cookie。比如请求sanyuan.com网站只能在sanyuan.com域名当中请求才能携带 Cookie，在其他网站请求都不能
        • 在Lax模式，就宽松一点了，但是只能在 get 方法提交表单况或者a 标签发送 get 请求的情况下可以携带 Cookie，其他情况均不能。
        • 在None模式下，也就是默认模式，请求会自动携带上 Cookie

    • 请求添加上只能在本域才能获得
      的凭证

      • CSRF token

        • 1. 输出⻚⾯时，带上CSRF
             token到客户端。注意不要存储
             在cookie中，安全起⻅，应该存
             在session中
        • 2. 客户端每次请求前都将token
             带上

        • 我的理解：黑客不能利用XHR发起请求 而是利用img src或者表单提交发起请求，但是这些带来的一个就是不能设置请求头，所以我们可以通过设置CSRF TOKEN 请求头来防止攻击

          • headers:{ “X-CSRFtoken”.cookie(“csrftoken”)}，
          • 表单应该不能添加修改请求头

      • 验证码

      • 转账前输⼊密码