⏰⏰⏰⏰计算机网络
文章目录
- 1 计算机网络
-
- TCP/IP五层模型和OSI网络七层协议⭐⭐
- 1.1 物理层
- 1.2 数据链路层
- 1.3 网络层IP
- 1.4 传输层TCP、UDP
-
-
- UDP、TCP的区别
- TCP的三次握手与四次挥手⭐⭐⭐⭐
-
- 1.5 应用层HTTP
- 2 HTTP
-
- 2.1 请求报文和响应报文
-
-
-
- ==HTTP方法==⭐：
-
-
- 2.2 具体应用
-
- 连接管理
-
- 1. 短连接与长连接
- 2. 流水线
- Cookie
-
- 1. 用途
- 2. 创建过程
- 3. 分类
- 4. 作用域
- 5. JavaScript访问
- 6. 标记HttpOnly
- 7. 标记Secure
- 8. Session
- 9. 浏览器禁用Cookie
- 10. Cookie 与 Session 选择⭐
- 11 Token
- 缓存
-
- 1.优点
- 2. 实现方法
- 3. Cache-Control
-
- 3.1 禁止进行缓存
- 3.2 强制确认缓存
- 3.3 私有缓存和公共缓存
- 3.4 缓存过期机制
- 4. 缓存验证
- 内容协商
-
- 1. 类型
-
- 1.1 服务端驱动型
- 1.2 代理驱动型
- 2. Vary
- 内容编码
- 范围请求
-
- 1. Range
- 2. Accept-Ranges
- 3. 响应状态码
- 分块传输编码
- 多部分对象集合
- 虚拟主机
- 通信数据转发
-
- 1. 代理
- 2. 网关
- 3. 隧道
- 3 HTTPS
-
- 3.1 加密
-
- 对称密钥加密
- 非对称密钥加密
- HTTPS 采用的加密方式
- 3.2 认证
- 3.3 完整性保护
- 4 HTTP2.0
-
- 4.1 二进制分帧层
- 4.2 服务端推送
- 4.3 首部压缩
- ==问题汇总问题汇总问题汇总问题汇总问题汇总问题汇总问题汇总问题汇总==
-
- HTTP的缺点⭐⭐
- HTTPS 的优点⭐⭐
- HTTPS 的缺点（对比优点）⭐⭐
- HTTP与HTTPS的基本概念⭐⭐
- HTTP 和 HTTPS 的区别⭐⭐
- HTTP请求报文和响应报文
- HTTP工作过程⭐
- HTTPS的工作过程⭐⭐
- HTTP1.0,1.1,2.0之间的区别和特性
- 快重传
- TCP/IP，TCP，UDP，IP，Socket 之间的[关系](https://blog.csdn.net/freekiteyu/article/details/72236734)
1 计算机网络
github详情
TCP/IP五层模型和OSI网络七层协议⭐⭐
1.1 物理层
1.2 数据链路层
1.3 网络层IP
1.4 传输层TCP、UDP
UDP、TCP的区别
| UDP | TCP | |
|---|---|---|
| 是否连接 | 无连接 | 面向连接 |
| 是否可靠 | 不可靠传输，不使用流量控制和拥塞控制 | 可靠传输，使用流量控制和拥塞控制 |
| 连接对象个数 | 支持一对一，一对多，多对一和多对多交互通信 | 只能是一对一通信 |
| 传输方式 | 面向报文 | 面向字节流 |
| 首部开销 | 首部开销小，仅8字节 | 首部最小20字节，最大60字节 |
| 适用场景 | 适用于实时应用（IP电话、视频会议、直播等） | 适用于要求可靠传输的应用，例如文件传输 |
TCP的三次握手与四次挥手⭐⭐⭐⭐
- 三次握手：SYN——SYN+ACK——ACK
- 四次挥手：FIN——ACK——FIN————ACK
位码即tcp标志位，有6种标示：
- SYN(synchronous建立联机)
- ACK(acknowledgement 确认)
- PSH(push传送)
- FIN(finish结束)
- RST(reset重置)
- URG(urgent紧急)
- Sequence number(顺序号码)
- Acknowledge number(确认号码)
1.5 应用层HTTP
2 HTTP
2.1 请求报文和响应报文
第一行——请求方法、URL、协议版本；
接下来的多行都是请求首部 Header，每个首部都有一个首部名称，以及对应的值。
一个空行用来分隔首部和内容主体
Body 最后是请求的内容主体
第一行——协议版本、状态码以及描述，最常见的是 200 OK 表示请求成功了
接下来多行也是首部内容
一个空行分隔首部和内容主体
最后是响应的内容主体
报文解释
- URL：HTTP 使用 URL（ U niform Resource Locator，统一资源定位符）来定位资源，它是URI（Uniform Resource Identifier，统一资源标识符）的子集，URL 在 URI 的基础上增加了定位能力。
- 请求方法：请求报文 第一行为请求行，包含了方法字段，
HTTP方法⭐：
-
GET ：获取资源、HEAD：获取报文首部、POST：传输实体主体、PUT：上传文件、PATCH：对资源进行部分修改、DELETE：删除文件、CONNECT：要求在与代理服务器通信时建立隧道、TRACE：追踪路径。
-
HTTP 状态码: 响应报文 中第一行为状态行，包含了状态码以及原因短语。
状态码 类别 含义 1XX Informational（信息性状态码） 接收的请求正在处理 2XX Success（成功状态码） 请求正常处理完毕 3XX Redirection（重定向状态码） 需要进行附加操作以完成请求 4XX Client Error（客户端错误状态码） 服务器无法处理请求 5XX Server Error（服务器错误状态码） 服务器处理请求出错 -
HTTP 首部: 有4种类型的首部字段：通用首部字段、请求首部字段、响应首部字段和实体首部字段。
2.2 具体应用
连接管理
1. 短连接与长连接
当浏览器访问一个包含多张图片的 HTML 页面时，除了请求访问的 HTML 页面资源，还会请求图片资源。如果每进行一次 HTTP 通信就要新建一个 TCP 连接，那么开销会很大。长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。
从 HTTP/1.1 开始默认是长连接的，如果要断开连接，需要由客户端或者服务器端提出断开，使用 Connection : close；
在 HTTP/1.1 之前默认是短连接的，如果需要使用长连接，则使用 Connection : Keep-Alive。
2. 流水线
流水线是在同一条长连接上连续发出请求，而不用等待响应返回，这样可以减少延迟。
Cookie
HTTP 协议是无状态的，主要是为了让 HTTP 协议尽可能简单，使得它能够处理大量事务，服务器发送到用户浏览器并保存在本地的一小块数据。HTTP/1.1 引入 Cookie 来保存状态信息。
每次请求都会需要携带 Cookie 数据，因此会带来额外的性能开销（尤其是在移动环境下）。
Cookie 渐渐被淘汰。新的浏览器 API 已经允许开发者直接将数据存储到本地，如使用 Web storage API（本地存储和会话存储）或 IndexedDB。
1. 用途
- 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）
- 个性化设置（如用户自定义设置、主题等）
- 浏览器行为跟踪（如跟踪分析用户行为等）
2. 创建过程
- 服务器发送的响应报文包含 Set-Cookie 首部字段，客户端得到响应报文后把 Cookie 内容保存到浏览器中。
- 客户端之后对同一个服务器发送请求时，会从浏览器中取出 Cookie 信息并通过 Cookie 请求首部字段发送给服务器。
3. 分类
- 会话期 Cookie：浏览器关闭之后它会被自动删除，也就是说它仅在会话期内有效。
- 持久性 Cookie：指定过期时间（Expires）或有效期（max-age）之后就成为了持久性的 Cookie。
4. 作用域
- Domain 标识指定了哪些主机可以接受 Cookie。如果不指定，默认为当前文档的主机（不包含子域名）。如果指定了Domain，则一般包含子域名。例如，如果设置 Domain=mozilla.org，则 Cookie 也包含在子域名中（如developer.mozilla.org）。
- Path 标识指定了主机下的哪些路径可以接受 Cookie（该 URL 路径必须存在于请求 URL 中）。以字符 %x2F ("/") 作为路径分隔符，子路径也会被匹配。
5. JavaScript访问
浏览器通过 document.cookie 属性可创建新的 Cookie，也可通过该属性访问非 HttpOnly 标记的 Cookie。
6. 标记HttpOnly
标记为 HttpOnly 的 Cookie 不能被 JavaScript 脚本调用。跨站脚本攻击 (XSS) 常常使用 JavaScript 的 document.cookie API 窃取用户的 Cookie 信息，因此使用 HttpOnly 标记可以在一定程度上避免 XSS 攻击。
7. 标记Secure
标记为 Secure 的 Cookie 只能通过被 HTTPS 协议加密过的请求发送给服务端。但即便设置了 Secure 标记，敏感信息也不应该通过 Cookie 传输，因为 Cookie 有其固有的不安全性，Secure 标记也无法提供确实的安全保障。
8. Session
Session 可以存储在服务器上的文件、数据库或者内存中。也可以将 Session 存储在 Redis 这种内存型数据库中，效率会更高。
9. 浏览器禁用Cookie
此时无法使用 Cookie 来保存用户信息，只能使用 Session。除此之外，不能再将 Session ID 存放到 Cookie 中，而是使用 URL 重写技术，将 Session ID 作为 URL 的参数进行传递。
10. Cookie 与 Session 选择⭐
- Cookie 只能存储 ASCII 码字符串，而 Session 则可以存储任何类型的数据，因此在考虑数据复杂性时首选 Session；
- Cookie 存储在浏览器中，容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中，可以将 Cookie值进行加密，然后在服务器进行解密；
- 对于大型网站，如果用户所有的信息都存储在 Session 中，那么开销是非常大的，因此不建议将所有的用户信息都存储到 Session 中。
11 Token
Session是将要验证的信息存储在服务端，并以SessionId和数据进行对应，SessionId由客户端存储，在请求时将SessionId也带过去，因此实现了状态的对应。而Token是在服务端将用户信息经过Base64Url编码过后传给在客户端，每次用户请求的时候都会带上这一段信息，因此服务端拿到此信息进行解密后就知道此用户是谁了，这个方法叫做JWT(Json Web Token)。
Token的优点
- Token相比较于Session的优点在于，当后端系统有多台时，由于是客户端访问时直接带着数据，因此无需做共享数据的操作。
- 简洁：可以通过URL,POST参数或者是在HTTP头参数发送，因为数据量小，传输速度快。
- 自包含：由于串包含了用户所需要的信息，避免了多次查询数据库，因为Token是以Json的形式保存在客户端的，所以JWT是跨语言的，不需要在服务端保存会话信息，特别适用于分布式微服务。
缓存
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
在使用内容协商的情况下，只有当缓存服务器中的缓存满足内容协商条件时，才能使用该缓存，否则应该向源服务器请求该资源。
内容编码
内容编码将实体主体进行压缩，从而减少传输的数据量。
常用的内容编码有：gzip、compress、deflate、identity。
浏览器发送 Accept-Encoding 首部，其中包含有它所支持的压缩算法，以及各自的优先级。服务器则从中选择一种，使用该算法对响应的消息主体进行压缩，并且发送 Content-Encoding 首部来告知浏览器它选择了哪一种算法。由于该内容协商过程是基于编码类型来选择资源的展现形式的，响应报文的 Vary 首部字段至少要包含 Content-Encoding。
范围请求
如果网络出现中断，服务器只发送了一部分数据，范围请求可以使得客户端只请求服务器未发送的那部分数据，从而避免服务器重新发送所有数据。
1. Range
在请求报文中添加 Range 首部字段指定请求的范围。
GET /z4d4kWk.jpg HTTP/1.1
Host: i.imgur.com
Range: bytes=0-1023
请求成功的话服务器返回的响应包含 206 Partial Content 状态码。
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1023/146515
Content-Length: 1024
...
(binary content)
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 字段定义的分隔符进行分隔，每个部分都可以有首部字段。
例如，上传多个表单时可以使用如下方式：
Content-Type: multipart/form-data; boundary=AaB03x
--AaB03x
Content-Disposition: form-data; name="submit-name"
Larry
--AaB03x
Content-Disposition: form-data; name="files"; filename="file1.txt"
Content-Type: text/plain
... contents of file1.txt ...
--AaB03x--
虚拟主机
HTTP/1.1 使用虚拟主机技术，使得一台服务器拥有多个域名，并且在逻辑上可以看成多个服务器。
通信数据转发
1. 代理
代理服务器接受客户端的请求，并且转发给其它服务器。
使用代理的主要目的是：
- 缓存
- 负载均衡
- 网络访问控制
- 访问日志记录
代理服务器分为正向代理和反向代理两种：
- 用户察觉得到正向代理的存在。
- 而反向代理一般位于内部网络中，用户察觉不到。
2. 网关
与代理服务器不同的是，网关服务器会将 HTTP 转化为其它协议进行通信，从而请求其它非 HTTP 服务器的服务。
3. 隧道
使用 SSL 等加密手段，在客户端和服务器之间建立一条安全的通信线路。
3 HTTPS
-
HTTPS 并不是新协议，而是让 HTTP 先和 SSL（Secure Sockets Layer）通信，再由 SSL 和 TCP 通信，也就是说 HTTPS 使用了隧道进行通信。
-
通过使用 SSL，HTTPS 具有了加密（防窃听）、认证（防伪装）和完整性保护（防篡改）。
3.1 加密
对称密钥加密
对称密钥加密（Symmetric-Key Encryption），加密和解密使用同一密钥。
优点：运算速度快；
缺点：无法安全地将密钥传输给通信方。
非对称密钥加密
非对称密钥加密，又称公开密钥加密（Public-Key Encryption），加密和解密使用不同的密钥。
公开密钥所有人都可以获得，通信发送方获得接收方的公开密钥之后，进行加密，接收方收到后使用私有密钥解密。
非对称密钥除了用来加密，还可以用来进行签名。因为私有密钥无法被其他人获取，因此通信发送方使用其私有密钥进行签名，通信接收方使用发送方的公开密钥对签名进行解密，就能判断这个签名是否正确。
优点：可以更安全地将公开密钥传输给通信发送方；
缺点：运算速度慢。
HTTPS 采用的加密方式
非对称密钥加密传输对称密钥
- 使用非对称密钥加密方式，传输对称密钥加密方式所需要的 Secret Key，从而保证安全性;
- 获取到 Secret Key 后，再使用对称密钥加密方式进行通信，从而保证效率。（下图中的 Session Key 就是 Secret Key）
3.2 认证
通过使用 证书 来对通信方进行认证。
-
数字证书认证机构（CA，Certificate Authority）是客户端与服务器双方都可信赖的第三方机构。
-
服务器的运营人员向 CA 提出公开密钥的申请，CA 在判明提出申请者的身份之后，会对已申请的公开密钥做数字签名，然后分配这个已签名的公开密钥，公开密钥放入公开密钥证书后绑定在一起。
-
进行 HTTPS 通信时，服务器会把证书发送给客户端。客户端取得其中的公开密钥之后，先使用数字签名进行验证，如果验证通过，就可以开始通信了。
3.3 完整性保护
SSL 提供报文摘要功能来进行完整性保护。
HTTP 也提供了 MD5 报文摘要功能，但不是安全的。例如报文内容被篡改之后，同时重新计算 MD5 的值，通信接收方是无法意识到发生了篡改。
HTTPS 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。
4 HTTP2.0
4.1 二进制分帧层
HTTP/2.0 将报文分成 HEADERS 帧和 DATA 帧，它们都是二进制格式的。
在通信过程中，只会有一个 TCP 连接存在，它承载了任意数量的双向数据流（Stream）。
- 一个数据流（Stream）都有一个唯一标识符和可选的优先级信息，用于承载双向信息。
- 消息（Message）是与逻辑请求或响应对应的完整的一系列帧。
- 帧（Frame）是最小的通信单位，来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。
4.2 服务端推送
HTTP/2.0 在客户端请求一个资源时，会把相关的资源一起发送给客户端，客户端就不需要再次发起请求了。例如客户端请求 page.html 页面，服务端就把 script.js 和 style.css 等与之相关的资源一起发给客户端。
4.3 首部压缩
HTTP/1.1 的首部带有大量信息，而且每次都要重复发送。
HTTP/2.0 要求客户端和服务器同时维护和更新一个包含之前见过的首部字段表，从而避免了重复传输。
不仅如此，HTTP/2.0 也使用 Huffman 编码对首部字段进行压缩。
问题汇总问题汇总问题汇总问题汇总问题汇总问题汇总问题汇总问题汇总
HTTP的缺点⭐⭐
- 使用明文进行通信，内容可能会被窃听；
- 不验证通信方的身份，通信方的身份有可能遭遇伪装；
- 无法证明报文的完整性，报文有可能遭篡改。
HTTPS 的优点⭐⭐
1、使用 HTTPS 协议可认证用户和服务器，确保数据发送到正确的客户机和服务器。
2、HTTPS 协议是由SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，要比 HTTP 协议安全，可防止数据在传输过程中不被窃取、修改，确保数据的完整性。
3、HTTPS 是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
HTTPS 的缺点（对比优点）⭐⭐
1、HTTPS 协议握手费时，会使页面的加载延长。
2、HTTPS 连接缓存不如 HTTP 高效，会增加数据开销，甚至已有的安全措施也会因此而受到影响。
3、HTTPS 协议的安全是有范围的，在黑客攻击、拒绝服务攻击和服务劫持等方面几乎起不到什么作用。
4、SSL 证书通常需要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能支撑这个消耗。
5、成本增加。部署 HTTPS 后，因为 HTTPS 协议的工作要增加额外的计算资源消耗，例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本。
6、HTTPS 协议的加密范围也比较有限。最关键的，SSL 证书的信用链体系并不安全，特别是在某些国家可以控制 CA 根证书的情况下，中间人攻击一样可行。
HTTP与HTTPS的基本概念⭐⭐
-
http的中文叫做超文本传输协议,它负责完成客户端到服务端的一系列操作,是专门用来传输注入HTML的超媒体文档等web内容的协议,它是基于传输层的TCP协议的应用层协议
-
https:https是基于安全套接字的http协议,也可以理解为是http+ssl/tls(数字证书)的组合
HTTP 和 HTTPS 的区别⭐⭐
区别详情
- HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
- HTTPS 协议需要到 CA （Certificate Authority，证书颁发机构）申请证书，一般免费证书较少，因而需要一定费用。(以前的网易官网是http，而网易邮箱是 https )
- HTTP 是超文本传输协议，信息是明文传输，HTTPS 则是具有安全性的 SSL 加密传输协议。
- HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
- HTTP 的连接很简单，是无状态的。HTTPS 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议，比 HTTP 协议安全。(无状态的意思是其数据包的发送、传输和接收都是相互独立的。无连接的意思是指通信双方都不长久的维持对方的任何信息。)
HTTP请求报文和响应报文
-
请求报文
请求行（方法字段、URL 字段 和HTTP 协议版本）
请求头部
空行
请求包体 -
响应报文
状态行（HTTP协议版本字段、状态码和状态码的描述文本）
响应头部
空行
响应包体
HTTP工作过程⭐
1、浏览器查找缓存
-
浏览器会查找浏览器缓存,系统缓存,路由缓存,如果没有的话 继续下一步,如果有的话,直接显示
-
注意:浏览器会把访问过得web网站资源(html 图片)缓存起来,而判断是否使用缓存的条件有以下几种:
这个网站的缓存是否过期,具体看Cache-Control 中缓存的有效时间
跟服务器进行协商是否使用缓存,如果上次缓存的时候有Last-modified 和 Etag 字段,本次请求就会加上If-Modified-Since(上次请求资源的时间)和If-None-Match(上次资源的修改时间)
2、网址解析
- 客户端浏览器请求这个页面：https://github.com/
解析出协议名、主机名、端口、对象路径等
协议名：http
主机名：github.com- 方式一：本机的host文件中查找是否有这个url对应的ip
- 方式二：通过DNS域名解析得到主机IP地址。
3、封装HTTP请求数据包
- 把以上部分结合本机信息，封装成一个HTTP请求数据包
4、封装成TCP包，建立TCP连接（TCP的三次握手）
- HTTP应用层协议是TCP/IP传输层协议更高层的协议，需要先建立TCP连接之后才能进行更高层的协议连接。
5、客户机发送请求命令
- 建立连接后，客户机发送一个请求给服务器，请求报文由 请求行（方法字段、URL 字段 和HTTP 协议版本）、 请求头部、 空行 、 请求包体组成
6、服务器响应
- 服务器接到请求后，给予相应的响应信息，响应报文由 状态行（HTTP协议版本字段、状态码和状态码的描述文本）、响应头部、空行、响应包体组成。
7、服务器关闭TCP连接
HTTPS的工作过程⭐⭐
客户端url请求，服务端返回公钥证书
客户端验证公钥证书，证书有效，生成会话密钥，使用公钥加密会话密钥，发送给服务端
服务端使用私钥解密得到会话密钥
双方都有了会话密钥，对明文发送前进行加密，接收后进行解密
https就是使用了非对称加密(一对公私钥进行加密解密)进行公钥传输,然后客户端通过公钥加密将自己的私钥发给服务端,以后就可以使用这个私钥进行消息的收发了
原理详情
HTTP1.0,1.1,2.0之间的区别和特性
http1.0:
- 是一种无状态、无连接的应用层协议,每个请求都会新创建一个tcp连接,完成后关闭服务端不跟踪也不记录过去的请求(无状态),但正因频繁创建连接,由于tcp的慢启动(为了不给网络造成拥堵,在首次进行tcp请求的时候,会限制服务端和客户端之间交互数据量的上限,大概为14kb,之后以指数级增长),服务端接受请求,处理完,发送完响应之后就会将tcp连接关闭,这造成了很大的资源浪费,而且http1.0在一个请求接收到响应之后才会接着发送下一个,这也造成了head of line blocking(队头阻塞),现在的浏览器为了解决这个问题,采用了一个页面可以建立多个tcp连接的方式来进行。
http1.1:
- 继承了http1.0的特点,同时改善了http的一些问题,首先是长连接,http1.1新增加了connecion字段,里面可以设置keey-Alive(保持连接)或者close(关闭长连接),避免了每次请求都会新建连接,提高了网络的利用率
http1.1还增加了Host字段,用来明确表示浏览器要服务器上的哪一个WEB站点,这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点,同时还支持了断点续传
http1.1的管道:可以发送很多请求到服务端,但是服务端必须要按顺序返回响应,由此可以看出http1.1的管道只是把客户端的请求序列变成了服务端的响应序列,还是有问题,很多浏览器并不是很支持
http1.1还增加了缓存,断点续传
http2.0 :
- 采用了二进制分帧(frame),在应用层和传输层之间增加了一个二进制分帧层,也就是把http1.x的header和body使用帧(frame)进行了封装
这里明确几个概念:
流(stream) : 已经建立上连接的双向字节流(也就是一个请求和其对应的响应)
消息:与逻辑消息对应的完整的一系列数据帧
帧(frame):http2.0进行通信的最小单位,每个帧都会包含一个头部,这个头部会包含当前帧所处的流 - 多路复用:所有的HTTP2.0通信都在一个TCP连接上完成，这个连接可以承载任意数量的双向数据流,每个数据流都以消息的方式进行发送,这个发送可以使乱序的,然后在通过每个帧头部的流标识符进行组装,同时每个数据流都可以设置优先级,可见http2.0真正实现了并行发送数据,这个是给予二进制分帧来实现的,接下来上一张图片,展示一下一个在一个流中分帧传输的实例。
- 头部压缩:就是和服务端约定头部的数据的编码,来将头部进行压缩后发送,这样就可以增加请求头的容量
小结：
- http1.0:无连接,无状态,一次请求一个tcp连接
- http1.1:持久连接,请求管道化(有一些缺陷) ,增加了host字段,缓存,断点续传
- http2.0 : 二进制分帧(多路复用的实现基础), 多路复用,头部压缩
快重传
TCP/IP，TCP，UDP，IP，Socket 之间的关系
TCP/IP协议族、TCP/UDP传输层、IP网络层、HTTP应用层、Socket是编程接口(API)，对 TCP/IP 的封装。