放肆青春的博客
放肆青春
2021-03-03

http

# http 简介

HyperText Transfer Protocol，超文本传输协议 (应用层)

# http 请求

请求范例：

GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
1
2
3
4

一个 HTTP 请求报文组成：请求行、请求头、空行、请求数据

  • 请求行（request line）、

    请求行由请求方法字段、URL 字段和 HTTP 协议版本字段 3 个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。

    根据 HTTP 标准，HTTP 请求可以使用多种请求方法。
    HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。
    HTTP1.1 新增了五种请求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

  • 请求头（header）

    请求头部由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有：

    • Accept 设置接受的内容类型 Accept: text/plain;
    • Accept-Charset 设置接受的字符编码:Accept-Charset: utf-8;
    • Accept-Encoding 设置接受的编码格式:Accept-Encoding: gzip, deflate;
    • Accept-Language 设置接受的语言:Accept-Language: en-US;
    • Cache-Control 设置请求响应链上所有的缓存机制必须遵守的指令:Cache-Control: no-cache;
    • Connection 设置当前连接和 hop-by-hop 协议请求字段列表的控制选项:Connection: keep-alive;
    • Content-Length 设置请求体的字节长度:Content-Length: 348;
    • Content-Type 设置请求体的 MIME 类型（适用 POST 和 PUT 请求）:Content-Type: application/x-www-form-urlencoded;
    • Cookie 设置服务器使用 Set-Cookie 发送的 http cookie:Cookie: $Version=1; Skin=new;;
    • Host 设置服务器域名和 TCP 端口号，如果使用的是服务请求标准端口号，端口号可以省略:Host: en.wikipedia.org:8080;
    • Origin 标识跨域资源请求（请求服务端设置 Access-Control-Allow-Origin 响应字段）:Origin: http://www.example-social-network.com;
    • Expires 设置响应体的过期时间:Expires: Thu, 01 Dec 1994 16:00:00 GMT;
    • ETag 特定版本资源的标识符，通常是消息摘要:ETag: "737060cd8c284d8af7ad3082f209582d";
    • Last-Modified 设置请求对象最后一次的修改日期:Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
    • User-Agent：产生请求的浏览器类型。

  • 空行

    最后一个请求头之后是一个空行，发送回车符和换行符，通知服务器以下不再有请求头。

  • 请求数据

    请求数据不在 GET 方法中使用，而是在 POST 方法中使用。POST 方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是 Content-Type 和 Content-Length。

# http 响应

响应范例

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain
1
2
3
4
5
6
7
8
9

HTTP 响应也由三个部分组成，分别是：状态行、响应头、空行、响应正文。

  • 状态行

    HTTP-Version Status-Code Reason-Phrase CRLF

    • HTTP-Version 表示服务器 HTTP 协议的版本；
    • Status-Code 表示服务器发回的响应状态代码；
    • Reason-Phrase 表示状态代码的文本描述。

  • 响应头

    • Allow 服务器支持哪些请求方法（如 GET、POST 等）。
    • Content-Encoding 文档的编码
    • Content-Length 内容长度
    • Content-Type 文档属于什么 MIME 类型
    • Date 服务器响应时间。你可以用 setDateHeader 来设置这个头以避免转换时间格式的麻烦。
    • Expires 过期时间
    • Last-Modified 文档的最后改动时间
    • Location 表示客户应当到哪里去提取文档

  • 响应正文

用于存放需要返回给客户端的数据信息。包含浏览器能够解析的静态内容，例如：html，纯文本，图片等等信息

# http 请求类型

HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD 方法。

HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法。

  • GET 请求指定的页面信息，并返回实体主体。
  • HEAD 类似于 GET 请求，只不过返回的响应中没有具体的内容，用于获取报头
  • POST 向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST 请求可能会导致新的资源的建立和/或已有资源的修改。
  • PUT 从客户端向服务器传送的数据取代指定的文档的内容。
  • DELETE 请求服务器删除指定的页面。
  • CONNECT HTTP/1.1 协议中预留给能够将连接改为管道方式的代理服务器。
  • OPTIONS 允许客户端查看服务器的性能。
  • TRACE 回显服务器收到的请求，主要用于测试或诊断。
  • PATCH 是对 PUT 方法的补充，用来对已知资源进行局部更新 。

get 发一个 tcp 包，post 发两个 tcp 包，这种情况是一定的吗，什么情况下不是这样?

get 请求是否可以传图片?

GET 请求是可以传图片的，以 base64 的形式，只能传一些小图

# http 状态码

https://www.runoob.com/http/http-status-codes.html (opens new window)

  • 1** 信息，服务器收到请求，需要请求者继续执行操作
  • 2** 成功，操作被成功接收并处理
  • 3** 重定向，需要进一步的操作以完成请求
  • 4** 客户端错误，请求包含语法错误或无法完成请求
  • 5** 服务器错误，服务器在处理请求的过程中发生了错误

常用状态码

  • 200 OK 请求成功。一般用于 GET 与 POST 请求

  • 204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档

  • 301 Moved Permanently 永久移动。请求的资源已被永久的移动到新 URI，返回信息会包括新的 URI，浏览器会自动定向到新 URI。今后任何新的请求都应使用新的 URI 代替

  • 302 Found 临时移动。与 301 类似。但资源只是临时被移动。客户端应继续使用原有 URI

  • 304 Not Modified 未修改。所请求的资源未修改

服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

  • 400 Bad Request 客户端请求的语法错误，服务器无法理解

  • 401 Unauthorized 请求未授权

  • 403 Forbidden 禁止访问 服务器理解请求客户端的请求，但是拒绝执行此请求

  • 404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面

  • 500 Internal Server Error 服务器内部错误，无法完成请求

  • 503 Service Unavailable 服务器端暂时无法处理请求（可能是过载或维护）。

# http 基本优化

影响一个 HTTP 网络请求的因素主要有两个：带宽和延迟。

  • 带宽：

    如果说我们还停留在拨号上网的阶段，带宽可能会成为一个比较严重影响请求的问题，但是现在网络基础建设已经使得带宽得到极大的提升，我们不再会担心由带宽而影响网速，那么就只剩下延迟了。

  • 延迟：

    1. 浏览器阻塞（HOL blocking）：浏览器会因为一些原因阻塞请求。浏览器对于同一个域名，同时只能有 4 个连接（这个根据浏览器内核不同可能会有所差异），超过浏览器最大连接数限制，后续请求就会被阻塞。

    2. DNS 查询（DNS Lookup）：浏览器需要知道目标服务器的 IP 才能建立连接。将域名解析为 IP 的这个系统就是 DNS。这个通常可以利用 DNS 缓存结果来达到减少这个时间的目的。

    3. 建立连接（Initial connection）：HTTP 是基于 TCP 协议的，浏览器最快也要在第三次握手时才能捎带 HTTP 请求报文，达到真正的建立连接，但是这些连接无法复用会导致每次请求都经历三次握手和慢启动。三次握手在高延迟的场景下影响较明显，慢启动则对文件类大请求影响较大。

# http1.1

浏览器对同源 HTTP/1.x 连接的并发个数有限制，典型值是 6

HTTP1.0 最早在网页中使用是在 1996 年，那个时候只是使用一些较为简单的网页上和网络请求上，而 HTTP1.1 则在 1999 年才开始广泛应用于现在的各大浏览器网络请求中，同时 HTTP1.1 也是当前使用最为广泛的 HTTP 协议。 主要区别主要体现在：

  1. 缓存处理（强缓存和协商缓存），

在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。

  1. 长连接和请求管道化

HTTP 1.1 支持长连接（PersistentConnection）和请求的管道化（Pipelining）处理，在一个 TCP 连接上可以传送多个 HTTP 请求和响应，减少了建立和关闭连接的消耗和延迟，在 HTTP1.1 中默认开启 Connection： keep-alive，一定程度上弥补了 HTTP1.0 每次请求都要创建连接的缺点。

管道化：

（1）它是建立在持久连接之上，是把所有请求一并发给服务器，但是服务器需要按照顺序一个一个响应

（2）服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容。

长连接：某个连接消息的传递类似于 请求 1 -> 响应 1 -> 请求 2 -> 响应 2

管线化：某个连接上的消息变成了类似这样 请求 1 -> 请求 2 -> 请求 3 -> 响应 1 -> 响应 2 -> 响应 3

  1. Host 头处理，使得一个服务器能够用来创建多个 Web 站点

在 HTTP1.0 中认为每台服务器都绑定一个唯一的 IP 地址，因此，请求消息中的 URL 并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个 IP 地址。HTTP1.1 的请求消息和响应消息都应支持 Host 头域，且请求消息中如果没有 Host 头域会报告一个错误（400 Bad Request）。

  1. 带宽优化及网络连接的使用，

HTTP1.0 中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1 则在请求头引入了 range 头域，它允许只请求资源的某个部分，即返回码是 206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

  1. 错误通知的管理，在 HTTP1.1 中新增了 24 个错误状态响应码，如 409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

# http2.0

  • 二进制传输

    http2 采用二进制传输，相较于文本传输的 http1 来说更加安全可靠。

  • 多路复用

    http1 一个连接只能提交一个请求，而 http2 可以同时处理无数个请求，可以降低连接的占用数量，进一步提升网络的吞吐量。

  • 头部压缩

    参考：https://segmentfault.com/a/1190000017011816 (opens new window)

    http2 使用 HPACK 算法对头部进行压缩，并且在客户端与服务端各维护了一份头部索引表，只需要根据索引 id 就可以进行头部信息的传输，缩小了头部容量，间接提升了传输效率。

    Hpack 算法过程：

    1. 消息发送端和消息接受端共同维护一份静态表和一份动态表（这两个合起来充当字典的角色），
    2. 每次请求时，发送方根据字典的内容以及一些特定指定，编码压缩消息头部，
    3. 接收方根据字典进行解码，并且根据指令来判断是否需要更新动态表

  • 服务端推送

    服务端可以主动推送资源给客户端，避免客户端花过多的时间逐个请求资源，这样可以降低整个请求的响应时间。

# 多路复用原理

发展历程：多个 Tcp 连接 => keep-alive => 管道化 => 多路复用

  1. http1.0 每次请求都会建立一次 HTTP 连接

  2. http1.1 Keep-Alive

解决的核心问题：一定时间内，同一域名多次请求数据，只建立一次 HTTP 请求，其他请求可复用每一次建立的连接通道，以达到提高请求效率的问题。这里面所说的一定时间是可以配置的，不管你用的是 Apache 还是 nginx。

HTTP1.1 还是存在效率问题

如上面所说，在 HTTP1.1 中是默认开启了 Keep-Alive(浏览器默认关闭管线化)，他解决了多次连接的问题，但是依然有两个效率上的问题：

第一个：串行的文件传输。当请求 a 文件时，b 文件只能等待，等待 a 连接到服务器、服务器处理文件、服务器返回文件，这三个步骤。我们假设这三步用时都是 1 秒，那么 a 文件用时为 3 秒，b 文件传输完成用时为 6 秒，依此类推。（注：此项计算有一个前提条件，就是浏览器和服务器是单通道传输） 第二个：连接数过多。我们假设 Apache 设置了最大并发数为 300，因为浏览器限制，浏览器发起的最大请求数为 6，也就是服务器能承载的最高并发为 50，当第 51 个人访问时，就需要等待前面某个请求处理完成。

  1. HTTP/2 的多路复用

HTTP/2 的多路复用就是为了解决上述的两个性能问题，我们来看一下，他是如何解决的。

解决第一个：在 HTTP1.1 的协议中，我们传输的 request 和 response 都是基本于文本的，这样就会引发一个问题：所有的数据必须按顺序传输，比如需要传输：hello world，只能从 h 到 d 一个一个的传输，不能并行传输，因为接收端并不知道这些字符的顺序，所以并行传输在 HTTP1.1 是不能实现的。

image

HTTP/2 引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，如下图所示，这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况。同样是因为有了序列，服务器就可以并行的传输数据，这就是流所做的事情。

image

解决第二个问题：HTTP/2 对同一域名下所有请求都是基于流，也就是说同一域名不管访问多少文件，也只建立一路连接。同样 Apache 的最大连接数为 300，因为有了这个新特性，最大的并发就可以提升到 300，比原来提升了 6 倍！

注意：以前我们做的性能优化不适用于 HTTP/2 了

  1. JS 文件的合并。我们现在优化的一个主要方向就是尽量的减少 HTTP 的请求数， 对我们工程中的代码，研发时分模块开发，上线时我们会把所有的代码进行压缩合并，合并成一个文件，这样不管多少模块，都请求一个文件，减少了 HTTP 的请求数。但是这样做有一个非常严重的问题：文件的缓存。当我们有 100 个模块时，有一个模块改了东西，按照之前的方式，整个文件浏览器都需要重新下载，不能被缓存。现在我们有了 HTTP/2 了，模块就可以单独的压缩上线，而不影响其他没有修改的模块。

  2. 多域名提高浏览器的下载速度。之前我们有一个优化就是把 css 文件和 js 文件放到 2 个域名下面，这样浏览器就可以对这两个类型的文件进行同时下载，避免了浏览器 6 个通道的限制，这样做的缺点也是明显的，1.DNS 的解析时间会变长。2.增加了服务器的压力。有了 HTTP/2 之后，根据上面讲的原理，我们就不用这么搞了，成本会更低。

参考：浅析 HTTP/2 的多路复用 https://segmentfault.com/a/1190000011172823 (opens new window)

# 帧（frame）

HTTP/2 中数据传输的最小单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流

HTTP/2 中数据传输的最小单位，因此帧不仅要细分表达 HTTP/1.x 中的各个部份，也优化了 HTTP/1.x 表达得不好的地方，同时还增加了 HTTP/1.x 表达不了的方式。 每一帧都包含几个字段，有 length、type、flags、stream identifier、frame playload 等，其中 type 代表帧的类型，在 HTTP/2 的标准中定义了 10 种不同的类型，包括上面所说的 HEADERS frame 和 DATA frame。此外还有：

  • PRIORITY（设置流的优先级）
  • RST_STREAM（终止流）
  • SETTINGS（设置此连接的参数）
  • PUSH_PROMISE（服务器推送）
  • PING（测量 RTT）
  • GOAWAY（终止连接）
  • WINDOW_UPDATE（流量控制）
  • CONTINUATION（继续传输头部数据）

在 HTTP 2.0 中，它把数据报的两大部分分成了 header frame 和 data frame。也就是头部帧和数据体帧。

# 流（stream）

流： 存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数 ID。 HTTP/2 长连接中的数据包是不按请求-响应顺序发送的，一个完整的请求或响应(称一个数据流 stream，每个数据流都有一个独一无二的编号)可能会分成非连续多次发送。

它具有如下几个特点：

  • 双向性：同一个流内，可同时发送和接受数据。
  • 有序性：流中被传输的数据就是二进制帧 。帧在流上的被发送与被接收都是按照顺序进行的。
  • 并行性：流中的 二进制帧 都是被并行传输的，无需按顺序等待。
  • 流的创建：流可以被客户端或服务器单方面建立, 使用或共享。
  • 流的关闭：流也可以被任意一方关闭。
  • HEADERS 帧在 DATA 帧前面。
  • 流的 ID 都是奇数，说明是由客户端发起的，这是标准规定的，那么服务端发起的就是偶数了。

# http3.0

HTTP/3 是基于 QUIC 协议，而 QUIC 协议是 Google 提出的一套开源协议，是基于 UDP 来实现，直接竞争对手是 TCP 协议。

  1. HTTP/3 使用 stream 进一步扩展了 HTTP/2 的多路复用。在 HTTP/3 模式下，一般传输多少个文件就会产生对应数量的 stream。当这些文件中的其中一个发生丢包时，你只需要重传丢包文件的对应 stream 即可。

  2. HTTP/3 不再是基于 TCP 建立的，而是通过 UDP 建立，在用户空间保证传输的可靠性，相比 TCP，UDP 之上的 QUIC 协议提高了连接建立的速度，降低了延迟。

  3. 通过引入 Connection ID，使得 HTTP/3 支持连接迁移以及 NAT 的重绑定。

  4. HTTP/3 含有一个包括验证、加密、数据及负载的 built-in 的 TLS 安全机制。

  5. 拥塞控制。TCP 是在内核区实现的，而 HTTP/3 将拥塞控制移出了内核，通过用户空间来实现。这样做的好处就是不再需要等待内核更新可以实现很方便的进行快速迭代。

  6. 头部压缩。HTTP/2 使用的 HPACK，HTTP/3 更换成了兼容 HPACK 的 QPACK 压缩方案。QPACK 优化了对乱序发送的支持，也优化了压缩率。

# http 问题汇总

# 301 重定向与 302 跳转的区别

  1. 301 是永久重定向，302 是临时重定向

  2. 301 搜索引擎在抓取新内容的同时也将旧的网址替换为重定向之后的网址，302 搜索引擎会抓取新的内容而保留旧的网址。因为服务器返回 302 代码，搜索引擎认为新的网址只是暂时的。

  3. 使用场景：301 使用域名跳转到目标域名（域名到期换域名），302 未登陆的用户访问用户中心重定向到登录页面。

# 预检请求

非简单请求的 CORS 请求，会在正式通信之前，增加一次 HTTP 查询请求，称为"预检"请求（preflight）。

原因：在 cros 跨域请求下浏览器将请求分为两种：1、简单请求，2、非简单请求（复杂请求），在非简单请求下，就会有 options 请求。

简单请求（同时满足以下条件）

  1. 请求方式有且只限于：GET、POST、 HEAD

  2. HTTP 请求头限制这几种字段（不得人为设置该集合之外的其他首部字段）：

Accept、Accept-Language、Content-Language、Content-Type（需要注意额外的限制）、DPR、Downlink、Save-Data、Viewport-Width、Width

  1. Content-type 只能取：application/x-www-form-urlencoded、multipart/form-data、text/plain

非简单请求（三种）：

  1. 请求的方法不是 GET/HEAD/POST，还有 PUT,DELETE

  2. POST 请求的 Content-Type 并非 application/x-www-form-urlencoded, multipart/form-data, 或 text/plain

  3. 请求设置了自定义的 header 字段，我们的 Content-Type 绝大多数是 application/json

# http 和 https 区别

  • 1、https 协议需要到 CA 申请证书，一般免费证书较少，因而需要一定费用。

  • 2、http 是超文本传输协议，信息是明文传输，https 则是具有安全性的 ssl/tls 加密传输协议。

  • 3、http 和 https 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。

  • 4、http 的连接很简单，是无状态的；HTTPS 协议是由 SSL/TLS+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 http 协议安全。

    1. HTTP 页面响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS 除了 TCP 的三个包，还要加上 ssl 握手需要的 9 个包，所以一共是 12 个包。

参考：https://www.cnblogs.com/heluan/p/8620312.html (opens new window)

# get 和 post 区别

  • GET 请求可被缓存 <=> POST 请求不会被缓存
  • GET 请求保留在浏览器历史记录中 <=> POST 请求不会保留在浏览器历史记录中
  • GET 请求可被收藏为书签 <=> POST 不能收藏为书签
  • GET 请求长度有限制 <=> POST 请求没有限
  • GET 比 POST 更不安全，因为参数直接暴露在 URL 上，所以不能用来传递敏感信息。
  • GET 请求只能进行 url 编码，而 POST 支持多种编码方式。
  • GET 参数通过 URL 传递，POST 放在 Request body 中。

GET 产生一个 TCP 数据包；POST 产生两个 TCP 数据包。

并不是所有浏览器都会在 POST 中发送两次包，Firefox 就只发送一次。

# post 和 put 区别

post 用于提交请求，可以更新或者创建资源，是非幂等的

put 用于向指定的 URI 传送更新资源，是幂等的

幂等：数学中的一个术语，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则是幂等的。也就是说，如果一个网络重复执行多次，产生的效果是一样的，那就是幂等。

# websocket 和 http 的区别和联系

相同点：

  1. 都是建立在 TCP 之上，通过 TCP 协议来传输数据。

  2. 都是可靠性传输协议。

  3. 都是应用层协议。

不同点：

  1. HTTP 主要用来一问一答的方式交换信息；WebSocket 让通信双方都可以主动去交换信息(双向通信协议)。

  2. HTTP2 虽然支持服务器推送资源到客户端，但那不是应用程序可以感知的，主要是让浏览器（用户代理）提前缓存静态资源，所以我们不能指望 HTTP2 可以像 WebSocket 建立双向实时通信。

  3. 握手次数不一样，在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就可以建立持久性的连接，并进行双向数据传输。http 需要三次握手

为了让服务器可以推送消息给客户端，使用了一个“偏方”。它就是 SSE（Server Sent Event）。

SSE 简单说就是，借助 http 协议支持分块传输这一特性。在响应报文里，设置 Content-Type: text/event-stream，如此一来响应报文实体就可以多次从服务器返回给客户端，只需要约定好边界就好，比如 SSE 的边界就是以空行作为消息分隔符。

# HTTP2.0 的多路复用和 HTTP1.X 中的长连接复用有什么区别？

  • HTTP/1.* 一次请求-响应，建立一个连接，用完关闭；每一个请求都要建立一个连接；

  • HTTP/1.1 Pipeling 解决方式为，若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；

  • HTTP/2 多个请求可同时在一个连接上并行执行。某个请求任务耗时严重，不会影响到其它连接的正常执行；

# 浏览器与服务器建立一个 TCP 连接后，是否会在完成一个 http 请求后断开？什么条件下会断开？

  1. 在 HTTP/1.0 中，一个 http 请求收到服务器响应后，会断开对应的 TCP 连接。这样每次请求，都需要重新建立 TCP 连接，这样一直重复建立和断开的过程，比较耗时。

  2. HTTP/1.1 默认情况下头字段 Connection: keep-alive，这样 http 请求完成后，就不会断开当前的 TCP 连接，后续的 http 请求可以使用当前 TCP 连接进行通信。,只有在请求头中设置 Connection: close 才会在请求后关闭 TCP 连接。

# 一个 TCP 连接可以同时发送几个 HTTP 请求？

  1. HTTP/1.1 中，单个 TCP 连接，在同一时间只能处理一个 http 请求，虽然存在 Pipelining 技术支持多个请求同时发送，但由于实践中存在很多问题无法解决，所以浏览器默认是关闭，所以可以认为是不支持同时多个请求。

  2. HTTP2 提供了多路传输功能，多个 http 请求，可以同时在同一个 TCP 连接中进行传输。

# 浏览器 http 请求的并发性是如何体现的？并发请求的数量有没有限制？

页面资源请求时，浏览器会同时和服务器建立多个 TCP 连接，在同一个 TCP 连接上顺序处理多个 HTTP 请求。所以浏览器的并发性就体现在可以建立多个 TCP 连接，来支持多个 http 同时请求。

Chrome 浏览器最多允许对同一个域名 Host 建立 6 个 TCP 连接，不同的浏览器有所区别

# 网页中的图片资源为什么分放在不同的域名下?

浏览器对并发请求的数目限制是针对域名的，即针对同一域名（包括二级域名）在同一时间支持的并发请求数量的限制。如果请求数目超出限制，则会阻塞。因此，网站中对一些静态资源，使用不同的一级域名，可以提升浏览器并行请求的数目，加速界面资源的获取速度。

更新时间: 1/17/2022, 8:54:37 PM
计算机网络
https

← https→

最近更新
01
前端权限管理
 02-24
02
vue2指令
 02-24
03
vue2 hook
 02-24
更多文章>
Theme by Vdoing | Copyright © 2019-2022 放肆青春