• 计算机基础-HTTP

    计算机基础-HTTP

     

    　　　　笑渐不闻声渐悄，多情却被无情恼。

    简介：计算机基础-HTTP。

    一 、基础概念

    请求和响应报文

    客户端发送一个请求报文给服务器，服务器根据请求报文中的信息进行处理，并将处理结果放入响应报文中返回给客户端。

    请求报文结构：

    • 第一行是包含了请求方法、URL、协议版本；
    • 接下来的多行都是请求首部 Header，每个首部都有一个首部名称，以及对应的值。
    • 一个空行用来分隔首部和内容主体 Body
    • 最后是请求的内容主体
     1 GET http://www.example.com/ HTTP/1.1
 2 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
 3 Accept-Encoding: gzip, deflate
 4 Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
 5 Cache-Control: max-age=0
 6 Host: www.example.com
 7 If-Modified-Since: Thu, 17 Oct 2019 07:18:26 GMT
 8 If-None-Match: "3147526947+gzip"
 9 Proxy-Connection: keep-alive
10 Upgrade-Insecure-Requests: 1
11 User-Agent: Mozilla/5.0 xxx
12 
13 param1=1&param2=2
    View Code

    响应报文结构：

    • 第一行包含协议版本、状态码以及描述，最常见的是 200 OK 表示请求成功了
    • 接下来多行也是首部内容
    • 一个空行分隔首部和内容主体
    • 最后是响应的内容主体
     1 HTTP/1.1 200 OK
 2 Age: 529651
 3 Cache-Control: max-age=604800
 4 Connection: keep-alive
 5 Content-Encoding: gzip
 6 Content-Length: 648
 7 Content-Type: text/html; charset=UTF-8
 8 Date: Mon, 02 Nov 2020 17:53:39 GMT
 9 Etag: "3147526947+ident+gzip"
10 Expires: Mon, 09 Nov 2020 17:53:39 GMT
11 Keep-Alive: timeout=4
12 Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
13 Proxy-Connection: keep-alive
14 Server: ECS (sjc/16DF)
15 Vary: Accept-Encoding
16 X-Cache: HIT
17 
18 <!doctype html>
19 <html>
20 <head>
21     <title>Example Domain</title>
22     // 省略... 
23 </body>
24 </html>
    View Code

    URL

    HTTP 使用 URL（ Uniform Resource Locator，统一资源定位符）来定位资源，它是 URI（Uniform Resource Identifier，统一资源标识符）的子集，URL 在 URI 的基础上增加了定位能力。URI 除了包含 URL，还包含 URN（Uniform Resource Name，统一资源名称），它只是用来定义一个资源的名称，并不具备定位该资源的能力。例如 urn:isbn:0451450523 用来定义一个书籍名称，但是却没有表示怎么找到这本书。

    二、HTTP 方法

    客户端发送的 请求报文 第一行为请求行，包含了方法字段。

    GET

    获取资源，当前网络请求中，绝大部分使用的是 GET 方法。

    获取报文首部，和 GET 方法类似，但是不返回报文实体主体部分。

    主要用于确认 URL 的有效性以及资源更新的日期时间等。

    POST

    传输实体主体，POST 主要用来传输数据，而 GET 主要用来获取资源。

    PUT

    上传文件，由于自身不带验证机制，任何人都可以上传文件，因此存在安全性问题，一般不使用该方法。

    1 PUT /new.html HTTP/1.1
2 Host: example.com
3 Content-type: text/html
4 Content-length: 16
5 
6 <p>New File</p>

    PATCH

    对资源进行部分修改，PUT 也可以用于修改资源，但是只能完全替代原始资源，PATCH 允许部分修改。

    1 PATCH /file.txt HTTP/1.1
2 Host: www.example.com
3 Content-Type: application/example
4 If-Match: "e0023aa4e"
5 Content-Length: 100
6 
7 [description of changes]

    DELETE

    删除文件，与 PUT 功能相反，并且同样不带验证机制。

    DELETE /file.html HTTP/1.1

    OPTIONS

    查询支持的方法，查询指定的 URL 能够支持的方法。

    会返回 Allow: GET, POST, HEAD, OPTIONS 这样的内容。

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

    1、获取服务器支持的HTTP请求方法；也是黑客经常使用的方法。

    2、用来检查服务器的性能。例如：AJAX进行跨域请求时的预检，需要向另外一个域名的资源发送一个HTTP OPTIONS请求头，用以判断实际发送的请求是否安全。

    CONNECT

    要求在与代理服务器通信时建立隧道，使用 SSL（Secure Sockets Layer，安全套接层）和 TLS（Transport Layer Security，传输层安全）协议把通信内容加密后经网络隧道传输。

    CONNECT www.example.com:443 HTTP/1.1

    TRACE

    追踪路径，服务器会将通信路径返回给客户端。

    发送请求时，在 Max-Forwards 首部字段中填入数值，每经过一个服务器就会减 1，当数值为 0 时就停止传输。

    通常不会使用 TRACE，并且它容易受到 XST 攻击（Cross-Site Tracing，跨站追踪）。

    三、HTTP 状态码

    服务器返回的 响应报文 中第一行为状态行，包含了状态码以及原因短语，用来告知客户端请求的结果。

    状态码类别含义
    1XX Informational（信息性状态码） 接收的请求正在处理
    2XX Success（成功状态码） 请求正常处理完毕
    3XX Redirection（重定向状态码） 需要进行附加操作以完成请求
    4XX Client Error（客户端错误状态码） 服务器无法处理请求
    5XX Server Error（服务器错误状态码） 服务器处理请求出错

    1XX 信息

    • 100 Continue ：表明到目前为止都很正常，客户端可以继续发送请求或者忽略这个响应。

    2XX 成功

    • 200 OK

    • 204 No Content ：请求已经成功处理，但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息，而不需要返回数据时使用。

    • 206 Partial Content ：表示客户端进行了范围请求，响应报文包含由 Content-Range 指定范围的实体内容。

    3XX 重定向

    • 301 Moved Permanently ：永久性重定向

    • 302 Found ：临时性重定向

    • 303 See Other ：和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。

    • 注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。

    • 304 Not Modified ：如果请求报文首部包含一些条件，例如：If-Match，If-Modified-Since，If-None-Match，If-Range，If-Unmodified-Since，如果不满足条件，则服务器会返回 304 状态码。

    • 307 Temporary Redirect ：临时重定向，与 302 的含义类似，但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。

    4XX 客户端错误

    • 400 Bad Request ：请求报文中存在语法错误。

    • 401 Unauthorized ：该状态码表示发送的请求需要有认证信息（BASIC 认证、DIGEST 认证）。如果之前已进行过一次请求，则表示用户认证失败。

    • 403 Forbidden ：请求被拒绝。

    • 404 Not Found

    5XX 服务器错误

    • 500 Internal Server Error ：服务器正在执行请求时发生错误。

    • 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求。

    四、HTTP 首部

    有 4 种类型的首部字段：通用首部字段、请求首部字段、响应首部字段和实体首部字段。

    各种首部字段及其含义如下（不需要全记，仅供查阅）：

    通用首部字段

    首部字段名说明
    Cache-Control 控制缓存的行为
    Connection 控制不再转发给代理的首部字段、管理持久连接
    Date 创建报文的日期时间
    Pragma 报文指令
    Trailer 报文末端的首部一览
    Transfer-Encoding 指定报文主体的传输编码方式
    Upgrade 升级为其他协议
    Via 代理服务器的相关信息
    Warning 错误通知

    请求首部字段

    首部字段名说明
    Accept 用户代理可处理的媒体类型
    Accept-Charset 优先的字符集
    Accept-Encoding 优先的内容编码
    Accept-Language 优先的语言（自然语言）
    Authorization Web 认证信息
    Expect 期待服务器的特定行为
    From 用户的电子邮箱地址
    Host 请求资源所在服务器
    If-Match 比较实体标记（ETag）
    If-Modified-Since 比较资源的更新时间
    If-None-Match 比较实体标记（与 If-Match 相反）
    If-Range 资源未更新时发送实体 Byte 的范围请求
    If-Unmodified-Since 比较资源的更新时间（与 If-Modified-Since 相反）
    Max-Forwards 最大传输逐跳数
    Proxy-Authorization 代理服务器要求客户端的认证信息
    Range 实体的字节范围请求
    Referer 对请求中 URI 的原始获取方
    TE 传输编码的优先级
    User-Agent HTTP 客户端程序的信息

    响应首部字段

    首部字段名说明
    Accept-Ranges 是否接受字节范围请求
    Age 推算资源创建经过时间
    ETag 资源的匹配信息
    Location 令客户端重定向至指定 URI
    Proxy-Authenticate 代理服务器对客户端的认证信息
    Retry-After 对再次发起请求的时机要求
    Server HTTP 服务器的安装信息
    Vary 代理服务器缓存的管理信息
    WWW-Authenticate 服务器对客户端的认证信息

    实体首部字段

    首部字段名说明
    Allow 资源可支持的 HTTP 方法
    Content-Encoding 实体主体适用的编码方式
    Content-Language 实体主体的自然语言
    Content-Length 实体主体的大小
    Content-Location 替代对应资源的 URI
    Content-MD5 实体主体的报文摘要
    Content-Range 实体主体的位置范围
    Content-Type 实体主体的媒体类型
    Expires 实体主体过期的日期时间
    Last-Modified 资源的最后修改日期时间

    五、具体应用

    连接管理

    1. 短连接与长连接

    当浏览器访问一个包含多张图片的 HTML 页面时，除了请求访问的 HTML 页面资源，还会请求图片资源。如果每进行一次 HTTP 通信就要新建一个 TCP 连接，那么开销会很大。

    长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。

    • 从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
    • 在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。

    Cookie 参考链接：https://www.cnblogs.com/taojietaoge/p/11341767.html

    缓存

    1. 优点

    • 缓解服务器压力；
    • 降低客户端获取资源的延迟：缓存通常位于内存中，读取缓存的速度更快。并且缓存服务器在地理位置上也有可能比源服务器来得近，例如浏览器缓存。

    2. 实现方法

    • 让代理服务器进行缓存；
    • 让客户端浏览器进行缓存。

    3. Cache-Control

    HTTP/1.1 通过 Cache-Control 首部字段来控制缓存。

    3.1 禁止进行缓存

    no-store 指令规定不能对请求或响应的任何一部分进行缓存。

    Cache-Control: no-store

    3.2 强制确认缓存

    no-cache 指令规定缓存服务器需要先向源服务器验证缓存资源的有效性，只有当缓存资源有效时才能使用该缓存对客户端的请求进行响应。

    Cache-Control: no-cache

    3.3 私有缓存和公共缓存

    private 指令规定了将资源作为私有缓存，只能被单独用户使用，一般存储在用户浏览器中。

    Cache-Control: private

    public 指令规定了将资源作为公共缓存，可以被多个用户使用，一般存储在代理服务器中。

    Cache-Control: public

    3.4 缓存过期机制

    max-age 指令出现在请求报文，并且缓存资源的缓存时间小于该指令指定的时间，那么就能接受该缓存。

    max-age 指令出现在响应报文，表示缓存资源在缓存服务器中保存的时间。

    Cache-Control: max-age=31536000

    Expires 首部字段也可以用于告知缓存服务器该资源什么时候会过期。

    Expires: Wed, 04 Jul 2012 08:26:05 GMT
    • 在 HTTP/1.1 中，会优先处理 max-age 指令；
    • 在 HTTP/1.0 中，max-age 指令会被忽略掉。

    4. 缓存验证

    需要先了解 ETag 首部字段的含义，它是资源的唯一标识。URL 不能唯一表示资源，例如 http://www.google.com/ 有中文和英文两个资源，只有 ETag 才能对这两个资源进行唯一标识。

    ETag: "82e22293907ce725faf67773957acd12"

    可以将缓存资源的 ETag 值放入 If-None-Match 首部，服务器收到该请求后，判断缓存资源的 ETag 值和资源的最新 ETag 值是否一致，如果一致则表示缓存资源有效，返回 304 Not Modified。

    If-None-Match: "82e22293907ce725faf67773957acd12"

    Last-Modified 首部字段也可以用于缓存验证，它包含在源服务器发送的响应报文中，指示源服务器对资源的最后修改时间。但是它是一种弱校验器，因为只能精确到一秒，所以它通常作为 ETag 的备用方案。如果响应首部字段里含有这个信息，客户端可以在后续的请求中带上 If-Modified-Since 来验证缓存。服务器只在所请求的资源在给定的日期时间之后对内容进行过修改的情况下才会将资源返回，状态码为 200 OK。如果请求的资源从那时起未经修改，那么返回一个不带有实体主体的 304 Not Modified 响应报文。

    Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
    If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT

    内容协商

    通过内容协商返回最合适的内容，例如根据浏览器的默认语言选择返回中文界面还是英文界面。

    1. 类型

    1.1 服务端驱动型

    客户端设置特定的 HTTP 首部字段，例如 Accept、Accept-Charset、Accept-Encoding、Accept-Language，服务器根据这些字段返回特定的资源。

    它存在以下问题：

    • 服务器很难知道客户端浏览器的全部信息；
    • 客户端提供的信息相当冗长（HTTP/2 协议的首部压缩机制缓解了这个问题），并且存在隐私风险（HTTP 指纹识别技术）；
    • 给定的资源需要返回不同的展现形式，共享缓存的效率会降低，而服务器端的实现会越来越复杂。

    1.2 代理驱动型

    服务器返回 300 Multiple Choices 或者 406 Not Acceptable，客户端从中选出最合适的那个资源。

    2. Vary

    Vary: Accept-Language

    在使用内容协商的情况下，只有当缓存服务器中的缓存满足内容协商条件时，才能使用该缓存，否则应该向源服务器请求该资源。

    例如，一个客户端发送了一个包含 Accept-Language 首部字段的请求之后，源服务器返回的响应包含 Vary: Accept-Language 内容，缓存服务器对这个响应进行缓存之后，在客户端下一次访问同一个 URL 资源，并且 Accept-Language 与缓存中的对应的值相同时才会返回该缓存。

    内容编码

    内容编码将实体主体进行压缩，从而减少传输的数据量。

    常用的内容编码有：gzip、compress、deflate、identity。

    浏览器发送 Accept-Encoding 首部，其中包含有它所支持的压缩算法，以及各自的优先级。服务器则从中选择一种，使用该算法对响应的消息主体进行压缩，并且发送 Content-Encoding 首部来告知浏览器它选择了哪一种算法。由于该内容协商过程是基于编码类型来选择资源的展现形式的，响应报文的 Vary 首部字段至少要包含 Content-Encoding。

    范围请求

    如果网络出现中断，服务器只发送了一部分数据，范围请求可以使得客户端只请求服务器未发送的那部分数据，从而避免服务器重新发送所有数据。

    1. Range

    在请求报文中添加 Range 首部字段指定请求的范围。

    1 GET /z4d4kWk.jpg HTTP/1.1
2 Host: i.imgur.com
3 Range: bytes=0-1023

    请求成功的话服务器返回的响应包含 206 Partial Content 状态码。

    1 HTTP/1.1 206 Partial Content
2 Content-Range: bytes 0-1023/146515
3 Content-Length: 1024
4 ...
5 (binary content)
    View Code

    2. Accept-Ranges

    响应首部字段 Accept-Ranges 用于告知客户端是否能处理范围请求，可以处理使用 bytes，否则使用 none。

    Accept-Ranges: bytes

    3. 响应状态码

    • 在请求成功的情况下，服务器会返回 206 Partial Content 状态码。
    • 在请求的范围越界的情况下，服务器会返回 416 Requested Range Not Satisfiable 状态码。
    • 在不支持范围请求的情况下，服务器会返回 200 OK 状态码。

    分块传输编码

    Chunked Transfer Encoding，可以把数据分割成多块，让浏览器逐步显示页面。

    多部分对象集合

    一份报文主体内可含有多种类型的实体同时发送，每个部分之间用 boundary 字段定义的分隔符进行分隔，每个部分都可以有首部字段。

    例如，上传多个表单时可以使用如下方式：

     1 Content-Type: multipart/form-data; boundary=AaB03x
 2 
 3 --AaB03x
 4 Content-Disposition: form-data; name="submit-name"
 5 
 6 Larry
 7 --AaB03x
 8 Content-Disposition: form-data; name="files"; filename="file1.txt"
 9 Content-Type: text/plain
10 
11 ... contents of file1.txt ...
12 --AaB03x--
    View Code

    虚拟主机

    HTTP/1.1 使用虚拟主机技术，使得一台服务器拥有多个域名，并且在逻辑上可以看成多个服务器。

    通信数据转发

    1. 代理

    代理服务器接受客户端的请求，并且转发给其它服务器。

    使用代理的主要目的是：

    • 缓存
    • 负载均衡
    • 网络访问控制
    • 访问日志记录

    代理服务器分为正向代理和反向代理两种：

    • 用户察觉得到正向代理的存在。

    • 而反向代理一般位于内部网络中，用户察觉不到。

    2. 网关

    与代理服务器不同的是，网关服务器会将 HTTP 转化为其它协议进行通信，从而请求其它非 HTTP 服务器的服务。

    3. 隧道

    使用 SSL 等加密手段，在客户端和服务器之间建立一条安全的通信线路。

    六、HTTPS

    HTTP 有以下安全性问题： 

    • 使用明文进行通信，内容可能会被窃听；
    • 不验证通信方的身份，通信方的身份有可能遭遇伪装；
    • 无法证明报文的完整性，报文有可能遭篡改。

    HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。

    通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。

    加密

    1. 对称密钥加密

    对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。

    • 优点：运算速度快；
    • 缺点：无法安全地将密钥传输给通信方。

    2.非对称密钥加密

    非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。

    公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，就可以使用公开密钥进行加密，接收方收到通信内容后使用私有密钥解密。

    非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。

    • 优点：可以更安全地将公开密钥传输给通信发送方；
    • 缺点：运算速度慢。

    3. HTTPS 采用的加密方式

    上面提到对称密钥加密方式的传输效率更高，但是无法安全地将密钥 Secret Key 传输给通信方。而非对称密钥加密方式可以保证传输的安全性，因此我们可以利用非对称密钥加密方式将 Secret Key 传输给通信方。HTTPS 采用混合的加密机制，正是利用了上面提到的方案：

    • 使用非对称密钥加密方式，传输对称密钥加密方式所需要的 Secret Key，从而保证安全性;
    • 获取到 Secret Key 后，再使用对称密钥加密方式进行通信，从而保证效率。（下图中的 Session Key 就是 Secret Key）

    认证

    通过使用 证书 来对通信方进行认证。

    数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。

    服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，并将该公开密钥放入公开密钥证书后绑定在一起。

    进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。

    完整性保护

    SSL 提供报文摘要功能来进行完整性保护。

    HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。

    HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

    HTTPS 的缺点

    • 因为需要进行加密解密等过程，因此速度会更慢；
    • 需要支付证书授权的高额费用。

    七、HTTP/2.0

    HTTP/1.x 缺陷

    HTTP/1.x 实现简单是以牺牲性能为代价的：

    • 客户端需要使用多个连接才能实现并发和缩短延迟；
    • 不会压缩请求和响应首部，从而导致不必要的网络流量；
    • 不支持有效的资源优先级，致使底层 TCP 连接的利用率低下。

    二进制分帧层

    HTTP/2.0 将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。

     

    在通信过程中，只会有一个 TCP 连接存在，它承载了任意数量的双向数据流（Stream）。

    • 一个数据流（Stream）都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
    • 消息（Message）是与逻辑请求或响应对应的完整的一系列帧。
    • 帧（Frame）是最小的通信单位，来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。

    服务端推送

    HTTP/2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，客户端就不需要再次发起请求了。例如客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。

    首部压缩

    HTTP/1.1 的首部带有大量信息，而且每次都要重复发送。

    HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。

    不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。

    八、HTTP/1.1 新特性

    • 默认是长连接
    • 支持流水线
    • 支持同时打开多个 TCP 连接
    • 支持虚拟主机
    • 新增状态码 100
    • 支持分块传输编码
    • 新增缓存处理指令 max-age

    九、GET 和 POST 比较

    作用

    GET 用于获取资源，而 POST 用于传输实体主体。

    参数

    GET 和 POST 的请求都能使用额外的参数，但是 GET 的参数是以查询字符串出现在 URL 中，而 POST 的参数存储在实体主体中。不能因为 POST 参数存储在实体主体中就认为它的安全性更高，因为照样可以通过一些抓包工具（Fiddler）查看。

      

    因为 URL 只支持 ASCII 码，因此 GET 的参数中如果存在中文等字符就需要先进行编码。例如 中文 会转换为 %E4%B8%AD%E6%96%87，而空格会转换为 %20。POST 参数支持标准字符集。

    安全

    安全的 HTTP 方法不会改变服务器状态，也就是说它只是可读的。

    GET 方法是安全的，而 POST 却不是，因为 POST 的目的是传送实体主体内容，这个内容可能是用户上传的表单数据，上传成功之后，服务器可能把这个数据存储到数据库中，因此状态也就发生了改变。

    安全的方法除了 GET 之外还有：HEAD、OPTIONS。

    不安全的方法除了 POST 之外还有 PUT、DELETE。

    幂等性

    幂等的 HTTP 方法，同样的请求被执行一次与连续执行多次的效果是一样的，服务器的状态也是一样的。换句话说就是，幂等方法不应该具有副作用（统计用途除外）。

    所有的安全方法也都是幂等的。

    在正确实现的条件下，GET，HEAD，PUT 和 DELETE 等方法都是幂等的，而 POST 方法不是。

    GET /pageX HTTP/1.1 是幂等的，连续调用多次，客户端接收到的结果都是一样的：

    1 GET /pageX HTTP/1.1
2 GET /pageX HTTP/1.1
3 GET /pageX HTTP/1.1
4 GET /pageX HTTP/1.1

    POST /add_row HTTP/1.1 不是幂等的，如果调用多次，就会增加多行记录：

    1 POST /add_row HTTP/1.1   -> Adds a 1nd row
2 POST /add_row HTTP/1.1   -> Adds a 2nd row
3 POST /add_row HTTP/1.1   -> Adds a 3rd row

    DELETE /idX/delete HTTP/1.1 是幂等的，即使不同的请求接收到的状态码不一样：

    1 DELETE /idX/delete HTTP/1.1   -> Returns 200 if idX exists
2 DELETE /idX/delete HTTP/1.1   -> Returns 404 as it just got deleted
3 DELETE /idX/delete HTTP/1.1   -> Returns 404

    可缓存

    如果要对响应进行缓存，需要满足以下条件：

    • 请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存的。
    • 响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。
    • 响应报文的 Cache-Control 首部字段没有指定不进行缓存。

    XMLHttpRequest

    为了阐述 POST 和 GET 的另一个区别，需要先了解 XMLHttpRequest：

    XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。

    • 在使用 XMLHttpRequest 的 POST 方法时，浏览器会先发送 Header 再发送 Data。但并不是所有浏览器会这么做，例如火狐就不会。
    • 而 GET 方法 Header 和 Data 会一起发送。

     

     

     

     

     

    笑渐不闻声渐悄

    多情却被无情恼

     

     

     
  • 相关阅读:
    中继器，集线器，网桥，交换机，路由器有什么区别？//联网用到的硬件简介
    超级详细Tcpdump 的用法
    C/C++语言void及void指针深层探索
    玩转Android事件监听篇第2篇
    密码控晒稀奇密码大开眼界 文艺密码PK科学密码
    路由环路&路由中毒&路由黑洞简析
    工程师淘金：开发Android主攻四大方向
    Windows路由表详解
    freebsd 终端显示文件夹时有颜色
    程序员的八个级别
  • 原文地址：https://www.cnblogs.com/taojietaoge/p/15055486.html
Copyright © 2020-2023  润新知