跳转至

Application layer

HTTP

常见http status

  • 1XX系列：指定客户端应相应的某些动作，代表请求已被接受，需要继续处理。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，服务器禁止向此类客户端发送 1xx 响应。
  • 2XX系列：代表请求已成功被服务器接收、理解、并接受。这系列中最常见的有200、201状态码。
    • 200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
    • 201 （已创建） 请求成功并且服务器创建了新的资源。
    • 202 （已接受） 服务器已接受请求，但尚未处理。
    • 203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
    • 204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
    • 205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
    • 206 （部分内容） 服务器成功处理了部分 GET 请求。
  • 3XX系列：代表需要客户端采取进一步的操作才能完成请求，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。这系列中最常见的有301、302状态码。
    • 300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
    • 301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
    • 302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
    • 303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
    • 304 （未修改） 自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
    • 305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
    • 307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
  • 4XX系列：表示请求错误。代表了客户端看起来可能发生了错误，妨碍了服务器的处理。常见有：401、404状态码。
    • 400 （错误请求） 服务器不理解请求的语法。
    • 401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
    • 403 （禁止） 服务器拒绝请求。
    • 404 （未找到） 服务器找不到请求的网页。
    • 405 （方法禁用） 禁用请求中指定的方法。
    • 406 （不接受） 无法使用请求的内容特性响应请求的网页。
    • 407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
    • 408 （请求超时） 服务器等候请求时发生超时。
    • 409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
    • 410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
    • 411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
    • 412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
    • 413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
    • 414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
    • 415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
    • 416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
    • 417 （未满足期望值） 服务器未满足“期望”请求标头字段的要求。
  • 5xx系列：代表了服务器在处理请求的过程中有错误或者异常状态发生，也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。常见有500、503状态码。
    • 500 （服务器内部错误） 服务器遇到错误，无法完成请求。
    • 501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
    • 502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。
    • 503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
    • 504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
    • 505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本。

http多个tcp连接怎么实现的？

某些服务器对 Connection: keep-alive 的 Header 进行了支持。意思是说，完成这个 HTTP 请求之后，不要断开 HTTP 请求使用的 TCP 连接。这样的好处是连接可以被重新使用，之后发送 HTTP 请求的时候不需要重新建立 TCP 连接，以及如果维持连接，那么 SSL 的开销也可以避免

URL 路径包含什么, URI 是什么

URL 路径包含什么

一个完整的url分为4部分：

  1. 协议 例 Http（超文本传输协议） 、Https、
  2. 域名 例 www.baidu.com 为网站名字。 baidu.com 为一级域名，www是服务
  3. 端口不填写的话默认走的是80端口号
  4. 路径 http://www.baidu.com/路径1/路径1.2。/表示根目录
  5. 查询参数 http://www.baidu.com/路径1/路径1.2?name=“man”(可有可无)

URI 是什么

**URI**是一个用于标识互联网资源名称的字符串。 该种标识允许用户对网络中（一般指万维网）的资源通过特定的协议进行交互操作。URI的最常见的形式是统一资源定位符（URL），经常指定为非正式的网址。更罕见的用法是统一资源名称（URN），其目的是通过提供一种途径。用于在特定的命名空间资源的标识，以补充网址。

扩展：

URL和URN是URI的子集，URI属于URL更高层次的抽象，一种字符串文本标准。

http 版本

HTTP各版本特性及区别 - 掘金

http1.x 和http2.x区别

http1.x 和http2.x主要有以下4个区别：

  1. HTTP2使用的是二进制传送，HTTP1.X是文本（字符串）传送。 二进制传送的单位是帧和流。帧组成了流，同时流还有流ID标示
  2. HTTP2支持多路复用 因为有流ID，所以通过同一个http请求实现多个http请求传输变成了可能，可以通过流ID来标示究竟是哪个流从而定位到是哪个http请求
  3. HTTP2头部压缩 HTTP2通过gzip和compress压缩头部然后再发送，同时客户端和服务器端同时维护一张头信息表，所有字段都记录在这张表中，这样后面每次传输只需要传输表里面的索引Id就行，通过索引ID查询表头的值
  4. HTTP2支持服务器推送 HTTP2支持在未经客户端许可的情况下，主动向客户端推送内容
  5. 安全性 HTTP/2.x要求使用TLS协议进行加密，保证了传输的安全性，而HTTP/1.x则不强制使用TLS协议，存在安全风险。

HTTP 0.9

HTTP 0.9 是一个最古老的版本

  • 只支持GET请求方式：由于不支持其他请求方式，因此客户端是没办法向服务端传输太多的信息
  • 没有请求头概念：所以不能在请求中指定版本号，服务端也只具有返回 HTML字符串的能力
  • 服务端相响应之后，立即关闭TCP连接

HTTP 1.1

HTTP 1.1 是在 1.0 发布之后的半年就推出了，完善了 1.0 版本。目前也还有很多的互联网项目基于 HTTP 1.1 在向外提供服务。

  • 长连接：新增Connection字段，可以设置keep-alive值保持连接不断开
    • 连接复用：在HTTP 1.1中，一个TCP连接可以被多个HTTP请求复用。在发送一个请求后，客户端和服务器端可以继续在同一个连接上发送和接收其他请求和响应。这减少了建立和关闭连接的开销，提高了性能。
    • Keep-Alive头字段：为了启用长连接，客户端发送的HTTP请求中包含一个Keep-Alive头字段，并设置其值为"timeout=xx"，其中xx是服务器应该保持连接的时间（以秒为单位）。服务器可以选择支持或拒绝长连接。
    • 并发请求：在长连接中，客户端可以在同一个连接上同时发送多个请求，而不需要等待每个请求的响应。这样可以减少请求的延迟时间，提高整体吞吐量。
    • 响应序列：服务器可以按照请求的顺序发送响应，这样客户端可以按照相同的顺序接收和处理响应。这避免了响应混乱的问题。
    • 超时处理：如果在Keep-Alive连接上一段时间内没有活动（没有新的请求或响应），服务器可以选择关闭连接。客户端需要注意处理连接超时的情况，并在需要时重新建立连接。
    • 限制：长连接并不意味着连接会一直保持开放。服务器可以设置最大并发连接数和最大空闲连接时间等限制，以避免资源耗尽和滥用。
  • 缓存处理：新增字段cache-control
  • 断点传输

HTTP 2

  • 二进制分帧
  • 多路复用： 在共享TCP链接的基础上同时发送请求和响应
  • 头部压缩
  • 服务器推送：服务器可以额外的向客户端推送资源，而无需客户端明确的请求

HTTPS

彻底搞懂HTTPS的加密原理

http和https

  1. HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。( 以前的网易官网是http，而网易邮箱是 https 。)
  2. HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
  3. HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
  4. HTTP 的连接很简单，是无状态的。HTTPS协议是由 SSL（Secure Sockets Layer）+ HTTP 协议构建的可进行加密传输、身份认证的网络协议，比HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
  5. HTTPS（Hyper Text Transfer Protocol over SecureSocket Layer）是以安全为目标的 HTTP 通道，是 HTTP 的安全版。HTTPS 的安全基础是 SSL。SSL 协议位于 TCP/IP 协议与各种应用层协议之间，为数据通讯提供安全支持。SSL 协议可分为两层：SSL 记录协议（SSL Record Protocol），它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。SSL 握手协议（SSL Handshake Protocol），它建立在 SSL 记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。

    1. HTTPS的优点

      尽管HTTPS并非绝对安全，掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

      1. 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
      2. HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
      3. HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
      4. 谷歌曾在2014年8月调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
        1. HTTPS的缺点

      虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

      1. HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；
      2. HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；
      3. SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。
      4. SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。
      5. HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的,SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。 ### 对称加密 一份密钥，用来加密解密 密钥的传输过程会被劫持

非对称加密

简单说就是有两把密钥，通常一把叫做公钥、一把叫私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

只能保证由浏览器向服务器传输数据的安全性

两组非对成加密，两个通道都安全

非对称加密算法非常耗时，而对称加密快很多

非对称加密+对称加密

既然非对称加密耗时，那非对称加密+对称加密结合可以吗？而且得尽量减少非对称加密的次数。当然是可以的，且非对称加密、解密各只需用一次即可。 请看一下这个过程：

  • 某网站拥有用于非对称加密的公钥A、私钥A。
  • 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。
  • 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
  • 服务器拿到后用私钥A’解密得到密钥X。
  • 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都通过密钥X加密解密即可。

某网站有用于非对称加密的公钥A、私钥A’。 浏览器向网站服务器请求，服务器把公钥A明文给传输浏览器。 中间人劫持到公钥A，保存下来，把数据包中的公钥A替换成自己伪造的公钥B（它当然也拥有公钥B对应的私钥B’）。 浏览器生成一个用于对称加密的密钥X，用公钥B（浏览器无法得知公钥被替换了）加密后传给服务器。 中间人劫持后用私钥B’解密得到密钥X，再用公钥A加密后传给服务器。 服务器拿到后用私钥A’解密得到密钥X。

https加密解密流程

https加密解密流程分成以下8个步骤：

  1. 客户端发起HTTPS请求 这个没什么好说的，就是用户在浏览器里输入一个HTTPS网址，然后连接到服务端的443端口。
  2. 服务端的配置 采用HTTPS协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。如果对公钥不太理解，可以想象成一把钥匙和一个锁头，只是世界上只有你一个人有这把钥匙，你可以把锁头给别人，别人可以用这个锁把重要的东西锁起来，然后发给你，因为只有你一个人有这把钥匙，所以只有你才能看到被这把锁锁起来的东西。
  3. 传送证书 这个证书其实就是公钥，只是包含了很多信息，如证书的颁发机构，过期时间等等。
  4. 客户端解析证书 这部分工作是由客户端的SSL/TLS来完成的，首先会验证公钥是否有效，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警示框，提示证书存在的问题。如果证书没有问题，那么就生成一个**随机值**。然后用证书（也就是公钥）对这个随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
  5. 传送加密信息 这部分传送的是用证书加密后的随机值，目的是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
  6. 服务端解密信息 服务端用私钥解密后，得到了客户端传过来的随机值，然后把内容通过该随机值进行对称加密，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
  7. 传输加密后的信息 这部分信息就是服务端用私钥加密后的信息，可以在客户端用随机值解密还原。
  8. 客户端解密信息 客户端用之前生产的私钥解密服务端传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。

https如何保证安全

HTTPS（全称：Hypertext Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。HTTPS = HTTP + SSL/TLS，如今 SSL 已废弃，所以现在只关注 HTTP + TLS。为了解决 HTTP 协议的问题，HTTPS 引入了数据加密和身份验证机制。在开始传输数据之前，通过安全可靠的 TLS 协议进行加密，从而保证后续加密传输数据的安全性。

TLS 协议：传输层安全性协议（Transport Layer Security，TLS）及其前身安全套接层（Secure Sockets Layer，SSL）是一种安全协议，目的是为了保证网络通信安全和数据完整性。

受 TLS 协议保护的通信过程：先对传输的数据进行了加密（使用对称加密算法）。并且对称加密的密钥是为每一个连接唯一生成的（基于 TLS 握手阶段协商的加密算法和共享密钥），然后发送的每条消息都会通过消息验证码（Message authentication code, MAC），来进行消息完整性检查，最后还可以使用公钥对通信双方进行身份验证

Https的作用

  • 内容加密 建立一个信息安全通道，来保证数据传输的安全；
  • 身份认证 确认网站的真实性
  • 数据完整性 防止内容被第三方冒充或者篡改

HTTPS 的加密过程主要分为以下几个步骤：

  1. 客户端向服务器发起连接请求，请求建立一个 SSL/TLS 连接。
  2. 服务器将公钥证书发送给客户端，客户端使用证书验证服务器的身份，确保连接的目标是预期的服务器，并获取服务器的公钥。
  3. 客户端使用服务器的公钥对一个随机的对称密钥进行加密，该对称密钥用于加密后续的数据通信。
  4. 客户端将加密后的对称密钥发送给服务器。
  5. 服务器使用自己的私钥对收到的加密数据进行解密，获取对称密钥。
  6. 客户端和服务器使用对称密钥对后续的数据进行加密和解密，保证数据的机密性和完整性。

在这个过程中，客户端和服务器使用公钥证书来验证对方的身份，并获取公钥。接着，客户端使用服务器的公钥加密一个随机的对称密钥，并将加密后的密钥发送给服务器。服务器使用自己的私钥对加密数据进行解密，获取对称密钥，然后客户端和服务器使用对称密钥对后续的数据进行加密和解密。

由于公钥和私钥是一对，只有拥有私钥的服务器才能够解密客户端发送的数据，因此这个过程保证了数据传输的安全性。而对称密钥的加密和解密速度比公钥加密要快，因此采用对称密钥来加密数据，可以保证数据传输的速度。

https为什么采用混合加密机制？

一方面，第一阶段的非对称加密，保证了对称密钥的安全性；另一方面，第二阶段的对称加密，可以提高加密/解密处理的速度，提高数据传输的效率。

  1. 为什么需要加密？

    因为http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了，他还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。最简单容易理解的就是对称加密。

  2. 什么是对称加密？

    就是有一个密钥，它可以对一段内容加密，加密后只能用它才能解密看到原本的内容，和我们日常生活中用的钥匙作用差不多。

  3. 用对称加密可行吗？

    如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的（除非密钥被破解）。然而最大的问题就是这个密钥怎么让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那这个传输过程中密钥被别人劫持弄到手了怎么办？之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。 换种思路？试想一下，如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行啦！这么做显然不现实。 所以我们就需要神奇的非对称加密。

  4. 什么是非对称加密？

    有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。

  5. 用非对称加密可行吗？ 鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了！因为只有服务器有相应的私钥能解开这条数据。 然而由服务器到浏览器的这条路怎么保障安全？如果服务器用它的的私钥加密数据传给浏览器，那么浏览器用公钥可以解密它，而这个公钥是一开始通过明文传输给浏览器的，这个公钥被谁劫持到的话，他也能用该公钥解密服务器传来的信息了。所以目前似乎只能保证由浏览器向服务器传输数据时的安全性（其实仍有漏洞，下文会说）。

  6. 混合加密

    非对称加密耗时，非对称加密+对称加密结合可以吗？而且得尽量减少非对称加密的次数。当然是可以的，而且非对称加密、解密各只需用一次即可。以下就是加密过程：

    1. 某网站拥有用于非对称加密的公钥A、私钥A’。
    2. 浏览器像网站服务器请求，服务器把公钥A明文给传输浏览器。
    3. 浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
    4. 服务器拿到后用私钥A’解密得到密钥X。
    5. 这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。

    完美！HTTPS基本就是采用了这种方案。

介绍下 HTTPS 中间人攻击

https 协议由 http + ssl 协议构成。

中间人攻击过程如下：

  1. 服务器向客户端发送公钥；
  2. 攻击者截获公钥，保留在自己手上；
  3. 然后攻击者自己生成一个【伪造的】公钥，发给客户端；
  4. 客户端收到伪造的公钥后，生成加密 hash（秘钥） 值发给服务器；
  5. 攻击者获得加密 hash 值，用自己的私钥解密获得真秘钥；
  6. 同时生成假的加密 hash 值，发给服务器；
  7. 服务器用私钥解密获得假秘钥；
  8. 服务器用假秘钥加密传输信息；

防范方法：

服务器在发送浏览器的公钥中加入 CA 证书，浏览器可以验证 CA 证书的有效性；（现有 HTTPS 很难被劫持，除非信任了劫持者的 CA 证书）。

HTTP request

http请求方式

http请求方式有以下8种，其中get和post是最常用的：

  1. OPTIONS 返回服务器针对特定资源所支持的HTTP请求方法，也可以利用向web服务器发送‘*’的请求来测试服务器的功能性
  2. HEAD 向服务器索与GET请求相一致的响应，只不过响应体将不会被返回。这一方法可以再不必传输整个响应内容的情况下，就可以获取包含在响应小消息头中的元信息。
  3. GET 向特定的资源发出请求。注意：GET方法不应当被用于产生“副作用”的操作中，例如在Web Application中，其中一个原因是GET可能会被网络蜘蛛等随意访问。Loadrunner中对应get请求函数：web_link和web_url
  4. POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。 Loadrunner中对应POST请求函数：web_submit_data,web_submit_form
  5. PUT 向指定资源位置上传其最新内容
  6. DELETE 请求服务器删除Request-URL所标识的资源
  7. TRACE 回显服务器收到的请求，主要用于测试或诊断
  8. CONNECT HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

除了post get 请求还有没有别的请求方式，例如option 方式，具体讲解一下

除了post和get还有6种请求方式分别是：OPTIONS、HEAD、PUT、DELETE、TRACE、CONNECT

HTTP 的OPTIONS 方法 用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法，也可以对整站（通过将 URL 设置为“*”）使用该方法

作用：

  1. 检测服务器所支持的请求方法

    可以使用 OPTIONS 方法对服务器发起请求，以检测服务器支持哪些 HTTP 方法：

    curl -X OPTIONS http://example.org -i

  2. CORS 中的预检请求

    在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法；Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。

GET和POST区别

  1. get用来获取数据，post用来提交数据
  2. get参数有长度限制（受限于url长度，具体的数值取决于浏览器和服务器的限制，最长2048字节），而post无限制
  3. get请求的数据会附加在url之 ，以 " ？ “分割url和传输数据，多个参数用”&"连接，而post请求会把请求的数据放在http请求体中。
  4. get是明文传输，post是放在请求体中，但是开发者可以通过抓包工具看到，也相当于是明文的。
  5. get请求会保存在浏览器历史记录中，还可能保存在web服务器的日志中

http请求头以及响应头

一、常用的http请求头

1.Accept

  • Accept: text/html 浏览器可以接受服务器回发的类型为 text/html。
  • Accept: / 代表浏览器可以处理所有类型,(一般浏览器发给服务器都是发这个)。

2.Accept-Encoding

  • Accept-Encoding: gzip, deflate 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate），（注意：这不是只字符编码）。

3.Accept-Language

  • Accept-Language:zh-CN,zh;q=0.9 浏览器申明自己接收的语言。

4.Connection

  • Connection: keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。
  • Connection: close 代表一个Request完成后，客户端和服务器之间用于传输HTTP数据的TCP连接会关闭， 当客户端再次发送Request，需要重新建立TCP连接。

5.Host（发送请求时，该报头域是必需的）

  • Host： 请求报头域主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的。

6.Referer

  • Referer: 当浏览器向web服务器发送请求的时候，一般会带上Referer，告诉服务器我是从哪个页面链接过来的，服务器籍此可以获得一些信息用于处理。

7.User-Agent

  • User-Agent:Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 告诉HTTP服务器， 客户端使用的操作系统和浏览器的名称和版本。

8.Cache-Control

  • Cache-Control:private 默认为private 响应只能够作为私有的缓存，不能再用户间共享
  • Cache-Control:public 响应会被缓存，并且在多用户间共享。正常情况, 如果要求HTTP认证,响应会自动设置为 private.
  • Cache-Control:must-revalidate 响应在特定条件下会被重用，以满足接下来的请求，但是它必须到服务器端去验证它是不是仍然是最新的。
  • Cache-Control:no-cache 响应不会被缓存,而是实时向服务器端请求资源。
  • Cache-Control:max-age=10 设置缓存最大的有效时间，但是这个参数定义的是时间大小（比如：60）而不是确定的时间点。单位是[秒 seconds]。
  • **Cache-Control:no-store**在任何条件下，响应都不会被缓存，并且不会被写入到客户端的磁盘里，这也是基于安全考虑的某些敏感的响应才会使用这个。

9.Cookie

Cookie是用来存储一些用户信息以便让服务器辨别用户身份的（大多数需要登录的网站上面会比较常见），比如cookie会存储一些用户的用户名和密码，当用户登录后就会在客户端产生一个cookie来存储相关信息，这样浏览器通过读取cookie的信息去服务器上验证并通过后会判定你是合法用户，从而允许查看相应网页。当然cookie里面的数据不仅仅是上述范围，还有很多信息可以存储是cookie里面，比如sessionid等。

10.Range（用于断点续传）

  • Range:bytes=0-5 指定第一个字节的位置和最后一个字节的位置。用于告诉服务器自己想取对象的哪部分。

二、常用的http响应头

1.Cache-Control（对应请求中的Cache-Control）

  • Cache-Control:private 默认为private 响应只能够作为私有的缓存，不能再用户间共享
  • Cache-Control:public 浏览器和缓存服务器都可以缓存页面信息。
  • Cache-Control:must-revalidate 对于客户机的每次请求，代理服务器必须向服务器验证缓存是否过时。
  • Cache-Control:no-cache 浏览器和缓存服务器都不应该缓存页面信息。
  • Cache-Control:max-age=10 是通知浏览器10秒之内不要烦我，自己从缓冲区中刷新。
  • Cache-Control:no-store 请求和响应的信息都不应该被存储在对方的磁盘系统中。

2.Content-Type

  • Content-Type：text/html;charset=UTF-8 告诉客户端，资源文件的类型，还有字符编码，客户端通过utf-8对资源进行解码，然后对资源进行html解析。通常我们会看到有些网站是乱码的，往往就是服务器端没有返回正确的编码。

3.Content-Encoding

  • Content-Encoding:gzip 告诉客户端，服务端发送的资源是采用gzip编码的，客户端看到这个信息后，应该采用gzip对资源进行解码。

4.Date

  • Date: Tue, 03 Apr 2018 03:52:28 GMT 这个是服务端发送资源时的服务器时间，GMT是格林尼治所在地的标准时间。http协议中发送的时间都是GMT的，这主要是解决在互联网上，不同时区在相互请求资源的时候，时间混乱问题。

5.Server

  • Server：Tengine/1.4.6 这个是服务器和相对应的版本，只是告诉客户端服务器信息**。**

6.Transfer-Encoding

  • Transfer-Encoding：chunked 这个响应头告诉客户端，服务器发送的资源的方式是分块发送的。一般分块发送的资源都是服务器动态生成的，在发送时还不知道发送资源的大小，所以采用分块发送，每一块都是独立的，独立的块都能标示自己的长度，最后一块是0长度的，当客户端读到这个0长度的块时，就可以确定资源已经传输完了。

7.Expires

  • Expires:Sun, 1 Jan 2000 01:00:00 GMT 这个响应头也是跟缓存有关的，告诉客户端在这个时间前，可以直接访问缓存副本，很显然这个值会存在问题，因为客户端和服务器的时间不一定会都是相同的，如果时间不同就会导致问题。所以这个响应头是没有Cache-Control：max-age=*这个响应头准确的，因为max-age=date中的date是个相对时间，不仅更好理解，也更准确。

8.Last-Modified

  • Last-Modified: Dec, 26 Dec 2015 17:30:00 GMT 所请求的对象的最后修改日期(按照 RFC 7231中定义的“超文本传输协议日期”格式来表示)

9.Connection

  • Connection：keep-alive 这个字段作为回应客户端的Connection：keep-alive，告诉客户端服务器的tcp连接也是一个长连接，客户端可以继续使用这个tcp连接发送http请求。

10.Etag

  • ETag: “737060cd8c284d8af7ad3082f209582d” 就是一个对象（比如URL）的标志值，就一个对象而言，比如一个html文件，如果被修改了，其Etag也会别修改，所以，ETag的作用跟Last-Modified的作用差不多，主要供WEB服务器判断一个对象是否改变了。比如前一次请求某个html文件时，获得了其ETag，当这次又请求这个文件时，浏览器就会把先前获得ETag值发送给WEB服务器，然后WEB服务器会把这个ETag跟该文件的当前ETag进行对比，然后就知道这个文件有没有改变了。

11.Refresh

  • Refresh: 用于重定向，或者当一个新的资源被创建时。默认会在5秒后刷新重定向。

12.Access-Control-Allow-Origin

  • **Access-Control-Allow-Origin: *** 号代表所有网站可以跨域资源共享，如果当前字段为 那么Access-Control-Allow-Credentials就不能为true
  • Access-Control-Allow-Origin: www.baidu.com 指定哪些网站可以跨域资源共享

13.Access-Control-Allow-Methods

  • Access-Control-Allow-Methods：GET,POST,PUT,DELETE 允许哪些方法来访问

14.Access-Control-Allow-Credentials

  • Access-Control-Allow-Credentials: true 是否允许发送cookie。默认情况下，Cookie不包括在CORS请求之中。设为true，即表示服务器明确许可，Cookie可以包含在请求中，一起发给服务器。这个值也只能设为true，如果服务器不要浏览器发送Cookie，删除该字段即可。如果access-control-allow-origin为* ，当前字段就不能为true

15.Content-Range

  • Content-Range: bytes 0-5/7877 指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。

HTTP catch

什么样的 HTTP 响应会被客户端缓存

  • 默认情况下，请求方法如 GET、HEAD的响应内容是可缓存的，在包含新鲜度信息的情况下，POST的响应内容也可以被缓存；
  • 默认情况下，响应码如 200、206、300、301、302、404 等的响应内容可以被缓存；
  • 响应头和请求头没有指明不使用缓存，如 Cache-Control: no-store。 以上是几种比较常见的情况。

私有缓存与共享缓存

  • 私有缓存

    • 仅供一个客户端使用的缓存，即客户端上的缓存仅供自己使用，通常只存在于如浏览器这样的客户端上。

    • 每个客户端发起的第一个请求都会被源服务器处理。在缓存生效的情况下，同一个客户端后续的相同请求甚至不会被发送，而是由本地缓存提供服务。

      f370ee5b2a9540a183c984a3e30d3663~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp.png

  • 共享缓存

    • 可以供多个客户端使用的缓存，通常依赖于代理服务器。

    • 客户端发起的第一个请求通过代理服务器访问源服务器，缓存生效后会存放在代理服务器，后续客户端发起的相同请求，均由代理服务器提供缓存服务，共享缓存可以减轻源服务器的压力。

      72929b95f50e4f7696b32f08218f695e~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp.png

http 缓存策略

浏览器每次发起请求时，先在本地缓存中查找结果以及缓存标识，根据缓存标识来判断是否使用本地缓存。如果缓存有效，则使用本地缓存；否则，则向服务器发起请求并携带缓存标识。根据是否需向服务器发起HTTP请求，将缓存过程划分为两个部分： 强制缓存和协商缓存，强缓优先于协商缓存。

  • 强缓存，服务器通知浏览器一个缓存时间，在缓存时间内，下次请求，直接用缓存，不在时间内，执行比较缓存策略。
  • 协商缓存，让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率，将缓存信息中的Etag和Last-Modified通过请求发送给服务器，由服务器校验，返回304状态码时，浏览器直接使用缓存。

HTTP缓存都是从第二次请求开始的：

  • 第一次请求资源时，服务器返回资源，并在response header中回传资源的缓存策略；
  • 第二次请求时，浏览器判断这些请求参数，击中强缓存就直接200，否则就把请求参数加到request header头中传给服务器，看是否击中协商缓存，击中则返回304，否则服务器会返回新的资源。这是缓存运作的一个整体流程图：

  • ad1f1982457044f4b9653727394e2792~tplv-k3u1fbpfcp-zoom-in-crop-mark:4536:0:0:0.awebp.png

强缓存

  • 强缓存命中则直接读取浏览器本地的资源，在network中显示的是from memory或者from disk
  • 控制强制缓存的字段有：Cache-Control（http1.1）和 Expires（http1.0）
  • Cache-control是一个相对时间，用以表达自上次请求正确的资源之后的多少秒的时间段内缓存有效。
  • Expires是一个绝对时间。用以表达在这个时间点之前发起请求可以直接从浏览器中读取数据，而无需发起请求
  • Cache-Control的优先级比Expires的优先级高。前者的出现是为了解决Expires在浏览器时间被手动更改导致缓存判断错误的问题。

强缓存-expires

  • 该字段是服务器响应消息头字段，告诉浏览器在过期时间之前可以直接从浏览器缓存中存取数据。
  • Expires 是 HTTP 1.0 的字段，表示缓存到期时间，是一个绝对的时间 (当前时间+缓存时间)。在响应消息头中，设置这个字段之后，就可以告诉浏览器，在未过期之前不需要再次请求。
  • 由于是绝对时间，用户可能会将客户端本地的时间进行修改，而导致浏览器判断缓存失效，重新请求该资源。此外，即使不考虑修改，时差或者误差等因素也可能造成客户端与服务端的时间不一致，致使缓存失效。
  • 优势特点
    • HTTP 1.0 产物，可以在HTTP 1.0和1.1中使用，简单易用。
    • 以时刻标识失效时间。
  • 劣势问题
    • 时间是由服务器发送的(UTC)，如果服务器时间和客户端时间存在不一致，可能会出现问题。
    • 存在版本问题，到期之前的修改客户端是不可知的。

强缓存-cache-control

  • 已知Expires的缺点之后，在HTTP/1.1中，增加了一个字段Cache-control，该字段表示资源缓存的最大有效时间，在该时间内，客户端不需要向服务器发送请求。
  • 这两者的区别就是前者是绝对时间，而后者是相对时间。下面列举一些Cache-control字段常用的值：(完整的列表可以查看MDN)
    • max-age：即最大有效时间。
    • must-revalidate：如果超过了max-age的时间，浏览器必须向服务器发送请求，验证资源是否还有效。
    • no-cache：不使用强缓存，需要与服务器验证缓存是否新鲜。
    • no-store: 真正意义上的“不要缓存”。所有内容都不走缓存，包括强制和对比。
    • public：所有的内容都可以被缓存 (包括客户端和代理服务器， 如 CDN)
    • private：所有的内容只有客户端才可以缓存，代理服务器不能缓存。默认值。
  • Cache-control 的优先级高于 Expires，为了兼容 HTTP/1.0 和 HTTP/1.1，实际项目中两个字段都可以设置。
  • 该字段可以在请求头或者响应头设置，可组合使用多种指令：
    • 可缓存性
      • public：浏览器和缓存服务器都可以缓存页面信息
      • private：default，代理服务器不可缓存，只能被单个用户缓存
      • no-cache：浏览器和服务器都不应该缓存页面信息，但仍可缓存，只是在缓存前需要向服务器确认资源是否被更改。可配合private，过期时间设置为过去时间。
      • only-if-cache：客户端只接受已缓存的响应
    • 到期
      • max-age=：缓存存储的最大周期，超过这个周期被认为过期。
      • s-maxage=：设置共享缓存，比如can。会覆盖max-age和expires。
      • max-stale[=]：客户端愿意接收一个已经过期的资源
      • min-fresh=：客户端希望在指定的时间内获取最新的响应
      • stale-while-revalidate=：客户端愿意接收陈旧的响应，并且在后台一部检查新的响应。时间代表客户端愿意接收陈旧响应的时间长度。
      • stale-if-error=：如新的检测失败，客户端则愿意接收陈旧的响应，时间代表等待时间。
    • 重新验证和重新加载
      • must-revalidate：如页面过期，则去服务器进行获取。
      • proxy-revalidate：用于共享缓存。
      • immutable：响应正文不随时间改变。
    • 其他
      • no-store：绝对禁止缓存
      • no-transform：不得对资源进行转换和转变。例如，不得对图像格式进行转换。
  • 优势特点
    • HTTP 1.1 产物，以时间间隔标识失效时间，解决了Expires服务器和客户端相对时间的问题。
    • 比Expires多了很多选项设置。
  • 劣势问题
    • 存在版本问题，到期之前的修改客户端是不可知的。

协商缓存

  • 协商缓存的状态码由服务器决策返回200或者304
  • 当浏览器的强缓存失效的时候或者请求头中设置了不走强缓存，并且在请求头中设置了 If-Modified-Since 或者 If-None-Match 的时候，会将这两个属性值到服务端去验证是否命中协商缓存，如果命中了协商缓存，会返回 304 状态，加载浏览器缓存，并且响应头会设置 Last-Modified 或者 ETag 属性。
  • 对比缓存在请求数上和没有缓存是一致的，但如果是 304 的话，返回的仅仅是一个状态码而已，并没有实际的文件内容，因此在响应体体积上的节省是它的优化点。
  • 协商缓存有 2 组字段(不是两个)，控制协商缓存的字段有：Last-Modified/If-Modified-since（http1.0）和Etag/If-None-match（http1.1）
  • Last-Modified/If-Modified-since表示的是服务器的资源最后一次修改的时间；Etag/If-None-match表示的是服务器资源的唯一标识，只要资源变化，Etag就会重新生成。
  • Etag/If-None-match的优先级比Last-Modified/If-Modified-since高。

协商缓存-Last-Modified/If-Modified-since

  • 服务器通过Last-Modified字段告知客户端，资源最后一次被修改的时间，例如Last-Modified: Mon, 10 Nov 2018 09:10:11 GMT
  • 浏览器将这个值和内容一起记录在缓存数据库中。
  • 下一次请求相同资源时时，浏览器从自己的缓存中找出“不确定是否过期的”缓存。因此在请求头中将上次的Last-Modified的值写入到请求头的If-Modified-Since字段
  • 服务器会将If-Modified-Since的值与Last-Modified字段进行对比。如果相等，则表示未修改，响应 304；反之，则表示修改了，响应200 状态码，并返回数据。
  • 优势特点
    • 不存在版本问题，每次请求都会去服务器进行校验。服务器对比最后修改时间如果相同则返回304，不同返回200以及资源内容。
  • 劣势问题
    • 只要资源修改，无论内容是否发生实质性的变化，都会将该资源返回客户端。例如周期性重写，这种情况下该资源包含的数据实际上一样的。
    • 以时刻作为标识，无法识别一秒内进行多次修改的情况。 如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为它的时间单位最低是秒。
    • 某些服务器不能精确的得到文件的最后修改时间。
    • 如果文件是通过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，所以起不到缓存的作用。

协商缓存-Etag/If-None-match

  • 为了解决上述问题，出现了一组新的字段Etag和If-None-Match
  • Etag存储的是文件的特殊标识(一般都是 hash 生成的)，服务器存储着文件的Etag字段。之后的流程和Last-Modified一致，只是Last-Modified字段和它所表示的更新时间改变成了Etag字段和它所表示的文件hash，把If-Modified-Since变成了If-None-Match。服务器同样进行比较，命中返回304， 不命中返回新资源和 200。
  • 浏览器在发起请求时，服务器返回在Response header中返回请求资源的唯一标识。在下一次请求时，会将上一次返回的Etag值赋值给If-No-Matched并添加在Request Header中。服务器将浏览器传来的if-no-matched跟自己的本地的资源的ETag做对比，如果匹配，则返回304通知浏览器读取本地缓存，否则返回200和更新后的资源。
  • Etag 的优先级高于 Last-Modified。
  • 优势特点
    • 可以更加精确的判断资源是否被修改，可以识别一秒内多次修改的情况。
    • 不存在版本问题，每次请求都回去服务器进行校验。
  • 劣势问题
    • 计算ETag值需要性能损耗。
    • 分布式服务器存储的情况下，计算ETag的算法如果不一样，会导致浏览器从一台服务器上获得页面内容后到另外一台服务器上进行验证时现ETag不匹配的情况。

强缓存保证浏览器资源最新

如果服务器端更新了资源，由于浏览器强缓存命中，浏览器不会向服务器发送请求，也就不会获得最新版本的资源，用户可能会看到旧的内容。

  1. 在 URL 中添加版本号
  2. 使用文件 hash 值作为资源名称
  3. 在资源 URL 中添加查询参数等
  4. 在服务器端设置较短的缓存时间，例如几分钟或几小时，

no-store 和 no-cache 的区别

no-cache 和 no-store 都是 HTTP 协议头 Cache-Control 的值。

区别是：

  • no-store

    彻底禁用缓存，所有内容都不会被缓存到缓存或临时文件中。

  • no-cache

    在浏览器使用缓存前，会往返对比 ETag，如果 ETag 没变，返回 304，则使用缓存。

域名解析原理

DNS是应用层协议，事实上他是为其他应用层协议工作的，包括不限于HTTP和SMTP以及FTP，用于将用户提供的主机名解析为ip地址。 具体过程如下：

  1. 客户机提出域名解析请求 , 并将该请求发送给本地的域名服务器 ;
  2. 当本地的域名服务器收到请求后 , 就先查询本地的缓存 , 如果有该纪录项 , 则本地的域名服务器就直接把查询的结果返回 ;
  3. 如果本地的缓存中没有该纪录 , 则本地域名服务器就直接把请求发给根域名服务器，然后根域名服务器再返回给本地域名服务器一个所查询域 (根的子域) 的主域名服务器的地址 ;
    1. 本地服务器再向上一步返回的域名服务器发送请求，然后接受请求的服务器查询自己的缓存，如果没有该纪录，则返回相关的下级的域名服务器的地址 ;
  4. 重复第四步 , 直到找到正确的纪录 ;
  5. 本地域名服务器把返回的结果保存到缓存 , 以备下一次使用 , 同时还将结果返回给客户机 ;

hosts 文件是什么？

hosts 文件是个没有扩展名的系统文件，其作用就是将网址域名和其对应的 IP 地址建立一个关联“数据库”，当用户在浏览器中输入一个 url 时，系统会首先自动从 hosts 文件中寻找对应的 IP 地址。