HTTP

总结前端开发者会用到的一些http相关知识点，包括http1.0 http1.1 http2.x https等。

HTTP

• HTTP
  • HTTP基础
    • HTTP方法：Get, Post, Put, Head, Delete, Options
      • Get和Post的区别： 1. 从应用场景上来说，GET 请求是一个幂等的请求，一般 Get 请求用于对服务器资源不会产生影响的场景，比如说请求一个网页。而 Post不是一个幂等的请求，一般用于对服务器资源会产生影响的情景。比如注册用户这一类的操作。 2. 因为不同的应用场景，所以浏览器一般会对 Get 请求缓存，但很少对 Post 请求缓存。 3. 从发送的报文格式来说，Get 请求的报文中实体部分为空，Post 请求的报文中实体部分 一般为向服务器发送的数据。 4. Get 请求也可以将请求的参数放入 url 中向服务器发送，这样的做法相对于 Post 请求来说，一个方面是不太安全， 5. 因为请求的 url 会被保留在历史记录中。并且浏览器由于对 url 有一个长度上的限制，所以会影响 get 请求发送数据时的长度。这个限制是浏览器规定的，并不是 RFC 规定的。还有就是 post 的参数传递支持更多的数据类型。
    • HTTP请求报文与响应报文
      • 请求报文
        • 1. 请求行：请求方法、URI、HTTP版本信息 2. 请求首部字段 3. 请求内容实体
      • 响应报文
        • 1. 状态行：HTTP版本、状态码、 2. 响应首部字段 3. 响应内容实体
    • HTTP响应状态码
      • 1. 1xx：指示信息--表示请求已接收，继续处理 2. 2xx：成功--表示请求已被成功接收、理解、接收 3. 3xx：重定向--要完成请求必须进行更进一步的操作 4. 4xx：客户端错误--请求有语法错误或请求无法实现 5. 5xx：服务器端错误--服务器未能实现合法的请求
        • 1. 301重定向是永久的重定向，搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址。 2. 302重定向是临时的重定向，搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回302代码，搜索引擎认为新的网址只是暂时的。
    • HTTP首部字段
      • 通用首部字段
        • Date：创建报文时间 Connection：连接的管理 Cache-Control：缓存的控制 Transfer-Encoding：报文主体的传输编码方式
      • 请求首部字段
        • Host：请求资源所在服务器 Accept：可处理的媒体类型 Accept-Charset：可接收的字符集 Accept-Encoding：可接受的内容编码 Accept-Language：可接受的自然语言
      • 响应首部字段
        • Accept-Ranges：可接受的字节范围 Location：令客户端重新定向到的URI Server：HTTP服务器的安装信息
      • 实体首部字段
        • Allow：资源可支持的HTTP方法 Content-Type：实体主类的类型 Content-Encoding：实体主体适用的编码方式 Content-Language：实体主体的自然语言 Content-Length：实体主体的的字节数 Content-Range：实体主体的位置范围，一般用于发出部分请求时使用
    • 完整的HTTP事务： 1. 域名解析 2. 发起TCP的3次握手 3. 建立TCP连接后发起http请求 4. 服务器响应http请求，浏览器得到html代码 5. 浏览器解析html代码，并请求html代码中的资源（js、css、图片等） 6. 浏览器对页面进行渲染呈现给用户
    • HTTP缓存
      • 强缓存： 1. 缓存数据为失效的情况下，可直接使用缓存数据。 2. 字段：Expires/Cache-control/nocache需要对比缓存/nostore不需要对比缓存
      • 对比缓存： 1. 浏览器第一次请求数据时，服务器会将缓存标识与数据一起返回客户端，客户端将二者备份至缓存数据库中 2. 字段：last modified/ Etag 3. keep-alive持久连接可以保持登录状态使客户端到服务端的连接持续有效。（要求服务器不要关闭TCP链接，1.1之后默认采用持续连接，对于同一个域，浏览器支持同时建立6个持久连接）
    • Header
      • cache-control指明哪些地方可以缓存返回的数据： 1. public (HTTP 返回的时候在Header 中设置Cache-Control 的值为‘public’。它代表，这个HTTP 请求它返回的内容所经过的任何路径中，包括中间的一些HTTP 代理服务器以及发出请求的客户端浏览器，都可以进行对返回内容的缓存操作) 2. private （发起请求的浏览器才能使用返回数据的缓存） 3. no-cache （可以在本地或者proxy服务器进行缓存，每次发起请求都要去服务器验证，服务器返回可以使用缓存，才可以真正使用本地缓存，任何节点都不能直接使用缓存）
      • cookie 和 token 都存放在 header 中，为什么不会 劫持 token： 1、攻击者通过 xss 拿到用户的 cookie 然后就可以伪造 cookie 了。 2、或者通过 csrf 在同个浏览器下面通过浏览器会自动带上 cookie 的特性 在通过 用户网站-攻击者网站-攻击者请求用户网站的方式 浏览器会自动带上 cookie 但是 token 1、不会被浏览器带上 问题 2 解决 2、token 是放在 jwt 里面下发给客户端的 而且不一定存储在哪里 不能通过 document.cookie 直接拿到，通过 jwt+ip 的方式 可以防止 被劫持 即使被劫持 也是无效的 jwt
      • set-cookie： 有两个 Http 头部和 Cookie 有关：Set-Cookie 和 Cookie 1. Set-Cookie 由服务器发送，它包含在响应请求的头部中。它用于在客户端创建一个 Cookie 2. Cookie 头由客户端发送，包含在 HTTP 请求的头部中。注意，只有 cookie 的 domain 和 path 与请求的 URL 匹配才会发送这个 cookie。
  • HTTP1.0 vs HTTP2.0： 1. 新的二进制格式：HTTP1.x基于文本；HTTP2.0二进制格式 2. 多路复用：连接共享，一个链接有多个request，每个request 1个id 3. header压缩：encoder减小header大小，通讯双方各cache一个header fields表，避免重复header传输 4. 服务端推送：允许服务端在客户需要数据之前就主动将数据发送到客户端缓存中 5. 更多加密支持
    • HTTP2多路复用： HTTP2 采用二进制格式传输，取代了 HTTP1.x 的文本格式，二进制格式解析更 高效。 多路复用代替了 HTTP1.x 的序列和阻塞机制，所有的相同域名请求都通过同一 个 TCP 连接并发完成。 在 HTTP1.x 中，并发多个请求需要多个 TCP 连接，浏览器为了控制资源会有 6-8 个 TCP 连接都限制。 HTTP2 中同域名下所有通信都在单个连接上完成，消除了因多个 TCP 连接而带来的延 时和内存消耗。 单个连接上可以并行交错的请求和响应，之间互不干扰
    • HTTP1.1如何复用tcp：在发送 http 的请求头中设置 Connection: keep-alive
  • HTTP1.0 vs HTTP1.1： 1. 连接方面的区别，http1.1 默认使用持久连接，而 http1.0 默认使用非持久连接。 http1.1 通过使用持久连接来使多个 http 请求复用同一个 TCP 连接，以此来避免使用非持久连接时每次需要建立连接的时延。 2. 资源请求方面的区别，在 http1.0 中，存在一些浪费带宽的现象，例如客户端只是需要 某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，http1.1 则 在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206(Partial Content)，这样就方便了开发者自由的选择以便于充分利用带宽和连接。 3. 缓存方面的区别，在 http1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，http1.1 则引入了更多的缓存控制策略例如 Etag、 If-Unmodified-Since、If-Match、If-None-Match 等更多可供选择的缓存头来控制缓存策 略。 4. http1.1 中还新增了 host 字段，用来指定服务器的域名。http1.0 中认为每台服务器 都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名(hostname)。但 随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机，并且它们共享一个 IP 地址。因此有了 host 字段，就可以将请求发往同一台服务器上的不同网站。 5. http1.1 相对于 http1.0 还新增了很多方法，如 PUT、HEAD、OPTIONS 等。
  • 无状态协议
    • 定义：无状态协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息也就是说， 当客户端一次 HTTP 请求完成以后，客户端再发送一次 HTTP 请求，HTTP 并不知道当前客户端是一个”老用户“。
    • 解决：可以使用 Cookie 来解决无状态的问题，Cookie 就相当于一个通行证，第一次访问的时候给客户端发送一个 Cookie， 当客户端再次来的时候，拿着 Cookie(通行证)，那么服务器就知道这个是”老用户“。
• TCP/UDP
  • TCP：是基于连接的协议，也就是说，在正式收发数据前，必须和对方建立可靠的连接。一个 TCP 连接必须要经过三次“对话”才能建立起来
    • 三次握手： 第一次握手，客户端向服务器端发送一个带 SYN 标志的数据包，等待服务器确认 第二次握手，服务器端向客户端回传一个带有 SYN/ACK 标志的数据包，通知客户端收到了连接请求 第三次握手，客户端再次向服务器端回传一个带 ACK 标志的数据包，确认连接，“握手”结束
    • 四次挥手： 第一次握手，客户端向服务器发送一个断开连接的请求（不早了，我该走了）； 第二次握手，服务器接到请求后发送确认收到请求的信号（知道了）； 第三次握手，服务器向客户端发送断开通知（我也该走了）； 第四次握手，客户端接到断开通知后断开连接并反馈一个确认信号（嗯，好的），服务器收到确认信号后断开连接；
  • UDP：是与 TCP 相对应的协议。它是面向非连接的协议，它不与对方建立连接，而是直接就把数据包发送过去！ UDP 适用于一次只传送少量数据、对可靠性要求不高的应用环境。
    • DNS 为什么使用 UDP 协议作为传输层协议? DNS 使用 UDP 协议作为传输层协议的主要原因是为了避免使用 TCP 协议时造成的连接时延。 因为为了得到一个域名的 IP 地 址，往往会向多个域名服务器查询，如果使用 TCP 协议，那么每次请求都会存在连接时延，这 样使 DNS 服务变得很慢，因为大 多数的地址查询请求，都是浏览器请求页面时发出的，这样会造成网页的等待时间过长。 使用 UDP 协议作为 DNS 协议会有一个问题，由于历史原因，物理链路的最小 MTU = 576，所 以为了限制报文长度不超过 576， UDP 的报文段的长度被限制在 512 个字节以内，这样一旦 DNS 的查询或者应答报文，超过了 512 字节，那么基于 UDP 的 DNS 协议就会被截断为 512 字节，那么有可能用户得到的 DNS 应答就是不完整的。这里 DNS 报文的长度一旦超过限制，并不 会像 TCP 协议那样被拆分成多个报文段传输，因为 UDP 协议不会维护连接状态，所以我们没 有办法确定那几个报文段属于同一 个数据，UDP只会将多余的数据给截取掉。为了解决这个问题，我们可以使用 TCP 协议去请求报文。 DNS 还存在的一个问题是安全问题，就是我们没有办法确定我们得到的应答，一定是一个安全的应答，因为应答可以被他人伪造，所以现在有了 DNS over HTTPS 来解决这个问题。
• HTTPS
  • SSH： 1. 客户端发起请求建立第一次连接 2. 服务端生成公钥和私钥，公钥发给客户端 3. 客户端拿到公钥，把一个对称密钥加密发给服务端 4. 服务端拿到加密数据，用私钥解密得到对称密钥 5. 服务端用对称密钥和加密数据和客户端正式建立连接
  • HTTPS流程： 1. 客户端发起请求，发送客户端支持的SSL协议版本，加密算法，随机数 2. 服务器生成随机数密钥，根据client的支持协议、加密算法发送证书给client 3. client校验证书，成功后，客户端生成对称密钥，服务器公钥加密对称密钥给服务器 4. 服务器解密得到对称密钥，发送响应到client，握手完成 5. 正式通信
  • HTTPS原理：HTTPS就是使用SSL/TLS协议进行加密传输，让客户端拿到服务器的公钥，然后客户端随机生成一个对称加密的秘钥，使用公钥加密，传输给服务端，后续的所有信息都通过该对称秘钥进行加密解密，完成整个HTTPS的流程
    • SSL：（Secure Socket Layer，安全套接字层），位于可靠的面向连接的网络层协议和应用层协议之间的一种协议层。SSL通过互相认证、使用数字签名确保完整性、使用加密确保私密性，以实现客户端和服务器之间的安全通讯。该协议由两层组成：SSL记录协议和SSL握手协议。
    • TLS：(Transport Layer Security，传输层安全协议)，用于两个应用程序之间提供保密性和数据完整性。该协议由两层组成：TLS记录协议和TLS握手协议。
  • HTTP vs HTTPS HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头 HTTP 是不安全的，而 HTTPS 是安全的 HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 的安全传输机制工作在传输层 HTTP 无法加密，而 HTTPS 对传输的数据进行加密 HTTP 无需证书，而 HTTPS 需要 CA 机构 wosign 的颁发的 SSL 证书
  • HTTPS握手过程： 1. clientHello 2. ServerHello 3. 客户端回应 4. 服务器的最后回应
  • HTTPS握手过程中，客户端验证正数的合法性： 1. 校验证书的颁发机构是否受客户端信任。 2. 通过 CRL 或 OCSP 的方式校验证书是否被吊销。 3. 对比系统时间，校验证书是否在有效期内。 4. 通过校验对方是否存在证书的私钥，判断证书的网站域名是否与证书颁发的域名一致。
• 安全
  • HTTPS中间人攻击：https 协议由 http + ssl 协议构成，具体的链接过程可参考 SSL 或 TLS 握手的概 述 中间人攻击过程如下: 1. 服务器向客户端发送公钥。 2. 攻击者截获公钥，保留在自己手上。 3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端。 4. 客户端收到伪造的公钥后，生成加密 hash 值发给服务器。 5. 攻击者获得加密 hash 值，用自己的私钥解密获得真秘钥。 6. 同时生成假的加密 hash 值，发给服务器。 7. 服务器用私钥解密获得假秘钥。 8. 服务器用加秘钥加密传输信息 防范方法: 服务端在发送浏览器的公钥中加入 CA 证书，浏览器可以验证 CA 证书的有效性
  • CSRF
    • 定义： CSRF 跨站点请求伪造(Cross—Site Request Forgery)，跟 XSS 攻击一样，存在巨大的危害性，你可以这样来理解： 攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。 如下：其中 Web A 为存在 CSRF 漏洞的网站，Web B 为攻击者构建的恶意网站，User C 为 Web A 网站的合法用户。
    • 原理： 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A； 在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A； 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B； 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A； 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。 3）防御： 验证 HTTP Referer 字段； 在请求地址中添加 token 并验证； 在 HTTP 头中自定义属性并验证。
  • XSS
    • XSS vs CSRF CSRF（Cross-site request forgery）跨站请求伪造，也被称为“One Click Attack”或者 Session Riding，通常缩写为 CSRF 或者 XSRF，是一种对网站的恶意利用。尽管听起来像跨站脚本（XSS），但它与 XSS 非常不同，XSS 利用站点内的信任用户，而 CSRF 则通过伪装来自受信任用户的请求来利用受信任的网站。与 XSS 攻击相比，CSRF 攻击往往不大流行（因此对其进行防范的资源也相当稀少）和难以防范，所以被认为比 XSS 更具危险性。
    • 定义： XSS 是一种经常出现在 web 应用中的计算机安全漏洞，它允许恶意 web 用户将代码植入到提供给其它用户使用的页面中。 比如这些代码包括 HTML 代码和客户端脚本。攻击者利用 XSS 漏洞旁路掉访问控制——例如同源策略(same origin policy)。 这种类型的漏洞由于被黑客用来编写危害性更大的网络钓鱼(Phishing)攻击而变得广为人知。 对于跨站脚本攻击，黑客界共识是：跨站脚本攻击是新型的“缓冲区溢出攻击“，而 JavaScript 是新型的“ShellCode”。
    • 防范： 1. 将重要的 cookie 标记为 http only, 这样的话 Javascript 中的 document.cookie 语句就不能获取到 cookie 了. 2. 表单数据规定值的类型，例如：年龄应为只能为 int、name 只能为字母数字组合。。。。 3. 对数据进行 Html Encode 处理 4. 过滤或移除特殊的 Html 标签， 例如: <script>, <iframe> , < for <, > for >, &quot for 5. 过滤 JavaScript 事件的标签。例如 "onclick=", "onfocus" 等等。
  • 点击劫持：最常见的是恶意网站使用 <iframe> 标签把我方的一些含有重要信息类如交易的网页嵌入进去，然后把 iframe 设置透明，用定位的手段的把一些引诱用户在恶意网页上点击。这样用户不知不觉中就进行了某些不安全的操作。 防范方法： 1. 使用 JS 防范： if (top.location.hostname !== self.location.hostname) { alert("您正在访问不安全的页面，即将跳转到安全页面！"); top.location.href = self.location.href; } 2. 使用 HTTP 头防范： 通过配置 nginx 发送 X-Frame-Options 响应头，这样浏览器就会阻止嵌入网页的渲染。更详细的可以查阅 MDN 上关于 X-Frame-Options 响应头的内容。 add_header X-Frame-Options SAMEORIGIN;
  • token加密： 需要一个 secret(随机数) 后端利用 secret 和加密算法(如:HMAC-SHA256)对 payload(如账号密码) 生成一个字符串(token)，返回前端 前端每次 request 在 header 中带上 token 后端用同样的算法解密
• 网络模型
  • OSI七层模型： 1. 物理层：规定通信设备，通信链路的特性。 2. 数据链路层：在物理层提供的比特流的基础上，建立相邻节点之间的数据链路，不可3靠的物理介质提供可靠传输 ppp协议。 3. 网络层：选择合适的网间路由完成两个计算机之间的多个数据链路，通过路由协议和 地址解析协议（ARP）。IP，RIP（路由信息协议），OSPF（最短路径优先协议）。 4. 传输层：为应用程序之间提供端对端的逻辑通信。 5. 会话层：验证访问和会话管理。 6. 表示层：信息格式和语法的转化。 7. 应用层：为操作系统或者应用程序提供可用的网络接口。
  • 网络五层协议： 1. 物理层： 主要负责在物理线路上传输原始的二进制数据。两台计算机要通信，就得通过介质，比如光纤、电缆等，物理层就是干这些事情的，。 2. 数据链路层： 主要负责在通信的实体间建立数据链路连接。物理层它只是单纯着负责在计算机之间传输0，1这样的电信号。假如这些0，1组合的传送毫无规则，计算机是解读不了的。因此，我们需要制定一套规则来进行0，1的传送。例如多少个电信号为一组啊，每一组信号应该如何标识才能让计算机读懂啊等。数据链路层就是在物理层之上，负责给这些0，1制定传送的规则，然后另一方再按照相应的规则来进行解读。 3. 网络层： 要负责创建逻辑链路，以及实现数据包的分片和重组，实现拥塞控制、网络互连等功能。假如网络不进行细化，没有子网的话，当一台计算机发送信息时，其他所有的计算机都能收到的，然后再删选舍弃这样下去计算机是会崩溃的，网络层就是负责解决这类问题的。建立主机到主机的通信。 4. 传输层： 负责向用户提供端到端的通信服务，实现流量控制以及差错控制。虽然我们已经把数据成功从计算机传送到另一台计算机了，可是另一台计算机又怎么知道这些数据是给谁的， 这个时候，就产生了端口，也就是说，我们在从计算机A传数据给计算表B的时候，还得指定一个端口，以供特定的应用程序来接受处理。传输层的功能就是建立端口到端口的通信。 5. 应用层： 应用层是最接近用户的，用来规定应用程序的数据格式。为应用程序提供了网络服务。