苏宁网站开发人员,做设计的什么网站能挣钱,360网站建设价位,微信小程序制作费用目录
HTTP1.1简述与特性
1. 报文清晰易读
2. 灵活和易于扩展
3. ⽆状态
Cookie和Session
4. 明⽂传输、不安全
HTTP协议发展过程
HTTP/1.1的不足
HTTP/2.0
HTTP/3.0
HTTPS协议
HTTP协议和HTTPS协议的区别
HTTPS中的加密方式
HTTPS中建立连接的方式 前言#xff…目录
HTTP1.1简述与特性
1. 报文清晰易读
2. 灵活和易于扩展
3. ⽆状态
Cookie和Session
4. 明⽂传输、不安全
HTTP协议发展过程
HTTP/1.1的不足
HTTP/2.0
HTTP/3.0
HTTPS协议
HTTP协议和HTTPS协议的区别
HTTPS中的加密方式
HTTPS中建立连接的方式 前言
到时候我想要写一篇文章就是在浏览器中输入URL并按下回车会发生什么
然后将几篇文章全部串联到一起现在几天的任务就是将这里的每个小部分进行一个详细的介绍 HTTP1.1简述与特性
Web 上的通信都是建⽴在 HTTP 协议上的
1. 客户端发起 HTTP 请求
2. 服务器做出响应处理后返回 HTTP 响应报⽂ HTTP协议主要有以下特点注意这里指的是HTTP1.1协议的特性对于更高级版本的HTTP协议里很多特性已经不再适合。
报文格式简单易于阅读灵活和易于扩展⽆状态明⽂传输、不安全
下面我将详细介绍以下HTTP协议的这几个特点 1. 报文清晰易读
HTTP基本报⽂格式为headerbody头部信息也是key-value简单⽂本的形式易于理解。
HTTP/1.1 的报文格式非常便于阅读因为它
是文本格式 请求行、状态行和头部都是由可读的 ASCII/ISO-8859-1 字符组成的文本行。结构清晰 头部是简单的 Key: Value 形式每行一个头部字段以空行结束头部后面跟着报文体如果存在。
这使得开发者、系统管理员等可以很方便地使用 telnet、curl -v 或者查看网络抓包工具如 Wireshark中的文本视图来直接阅读、理解和调试 HTTP/1.1 报文。 2. 灵活和易于扩展
HTTP协议⾥的各种请求⽅法、URI/URL、状态码、头字段等每个组成要求都没有被固定死允许开发⼈员⾃ 定义和扩充; HTTP⼯作在应⽤层OSI第七层下层可以随意变化;
HTTPS就是在HTTP与TCP之间增加了SSL/TSL安全传输层HTTP/3把TCP换成了基于UDP的QUIC。 常见状态码详细介绍
HTTP 协议规范以及后续的 RFC 文档定义了大量的标准状态码用于表示服务器对客户端请求的处理结果。这些状态码被分组在不同的类别中
HTTP 状态码Status Code只包含在 HTTP 响应报文中。它是响应报文的起始行Status-Line的一部分。
如果客户端收到了来自目标地址的有效的 HTTP 响应报文并且其中包含了 HTTP 状态码那么这基本上可以确定您已经成功连接到了目标服务器。 1xx
1xx 类状态码属于提示信息是协议处理中的一种中间状态实际用到的比较少。
2xx
2xx 类状态码表示服务器成功处理了客户端的请求也是我们最愿意看到的状态。 「200 OK」是最常见的成功状态码表示一切正常。如果是非 HEAD 请求服务器返回的响应头都 会有 body 数据。 「204 No Content」也是常见的成功状态码与 200 OK 基本相同但响应头没有 body 数据。 「206 Partial Content」是应用于 HTTP 分块下载或断点续传表示响应返回的 body 数据并不是资源 的全部而是其中的一部分也是服务器处理成功的状态。
3xx
3xx 类状态码表示客户端请求的资源发送了变动需要客户端用新的 URL 重新发送请求获取资源 也就是重定向。 「301 Moved Permanently」表示永久重定向说明请求的资源已经不存在了需改用新的 URL 再次 访问。 「302 Found」表示临时重定向说明请求的资源还在但暂时需要用另一个 URL 来访问。
301 和 302 都会在响应头里使用字段 Location 指明后续要跳转的 URL浏览器会自动重定向新的
URL。 「304 Not Modified」不具有跳转的含义表示资源未修改重定向已存在的缓冲文件也称缓存重定 向用于缓存控制。
4xx
4xx 类状态码表示客户端发送的报文有误服务器无法处理也就是错误码的含义。 「400 Bad Request」表示客户端请求的报文有错误但只是个笼统的错误。 「403 Forbidden」表示服务器禁止访问资源并不是客户端的请求出错。 「404 Not Found」表示请求的资源在服务器上不存在或未找到所以无法提供给客户端。
5xx
5xx 类状态码表示客户端请求报文正确但是服务器处理时内部发生了错误属于服务器端的错误 码。 「500 Internal Server Error」与 400 类型是个笼统通用的错误码服务器发生了什么错误我们并 不知道。 「501 Not Implemented」表示客户端请求的功能还不支持类似“即将开业敬请期待”的意思。「502 Bad Gateway」通常是服务器作为网关或代理时返回的错误码表示服务器自身工作正常访问 后端服务器发生了错误。 「503 Service Unavailable」表示服务器当前很忙暂时无法响应服务器类似“网络服务正忙请稍 后重试”的意思。 3. ⽆状态
无状态
服务器不会保留任何关于客户端在之前请求中的信息或状态。每一次 HTTP 请求都是完全独立的服务器处理当前的请求时不会记住或依赖于客户端之前发送的任何请求。
简单来说就像服务器得了“短期失忆症”。客户端每发送一个请求给服务器服务器就像是第一次见到这个客户端一样它只根据当前请求报文中的信息来进行处理和响应。
无状态带来了什么影响
优点
最大的优点就是服务器设计简单 服务器不需要为每个客户端维护大量的状态信息大大简化了服务器的设计。
缺点
每次请求需要携带足够的信息 由于服务器不记事儿客户端每次发送请求时必须携带所有必要的信息来完成本次请求。例如如果要访问需要登录才能看到的页面每次请求都需要带上身份认证信息。 需要额外的机制来管理会话状态 对于需要保持用户状态的应用如购物车、用户登录仅仅依赖无状态的 HTTP 是不够的。为了记住用户是谁、购物车里有什么需要在 HTTP 协议之上引入其他的技术或方法来管理状态。
通过 Cookie在客户端存储标识符和 Session在服务器端存储具体状态我们就可以在无状态的 HTTP 协议上构建有状态的 Web 应用。 Cookie和Session
Cookie客户端中常见的保存内容包括
会话标识符 (Session ID) 这是最常见和核心的用途。Cookie 中通常存储一个由服务器生成的唯一的 Session ID用于在服务器端查找对应的 Session 数据。这个 Session ID 是服务器在用户第一次访问时生成的并通过 HTTP 响应头部的 Set-Cookie 发送给浏览器。之后浏览器在向同一个网站发送后续请求时会自动在请求头部的 Cookie 字段中带上这个 Session ID 发送给服务器。 用户偏好设置 比如用户选择的语言、主题、页面布局、是否记住用户名等简单的配置信息。 跟踪信息 用于网站分析或广告跟踪记录用户的访问行为、来源、最后访问时间等标识符或简单数据。 状态标志 例如用户是否已经看过某个新手引导、某个弹窗广告或者接受了 Cookie 政策等。 “记住我”功能相关的 Token 为了实现长期登录“记住我”Cookie 中会存储一个由服务器生成的、用于下次访问时自动登录的 Token 或标识符而不是直接存储用户名和密码非常不安全。
Cookie 保存的是用于在客户端和服务器之间传递或在客户端本地持久化少量信息的文本数据主要用于用户识别、状态管理和个性化设置等方面绝对不应该在 Cookie 中直接存储敏感信息特别是用户的密码。
Cookie 一般可以被设置为在客户端长久保存几天、几个月甚至几年。 Session服务器端 Session 机制则负责在服务器端存储用户的具体状态信息。服务器接收到客户端发送的请求后从 Cookie 中读取 Session ID。然后根据这个 Session ID在服务器端的内存、数据库、文件或缓存如 Redis中查找对应的用户状态数据例如用户是否已登录、用户的用户名、购物车中的商品列表、用户的权限等。 Session 的目的是为了在一次连续的、相对短暂的用户访问过程中维持状态。一旦用户离开、长时间不活动或明确结束会话相关的 Session 数据就会被清理以确保服务器资源的有效利用和数据安全。
服务器端的 Session 是临时存在的 4. 明⽂传输、不安全
HTTP 报文特别是头部信息、请求 URL、以及报文体如果是文本格式的内容在客户端和服务器之间传输时是不经过加密的直接以文本字符串的形式在网络上传输。 易于理解和调试 正因为是明文开发者或管理员可以使用抓包工具如 Wireshark或者在浏览器开发者工具中直接看到 HTTP 请求和响应的详细内容非常便于理解和调试。 安全性风险 这是明文传输最大的问题。由于数据是直接可读的如果传输的内容包含敏感信息比如登录的用户名和密码用户在表单中输入的个人信息请求的 URL 本身可能包含敏感参数。
任何能够截获网络流量的第三方比如在同一个 Wi-Fi 下的人、互联网服务提供商、网络路由器等都可以直接读取这些信息造成数据泄露的风险。 为了解决 HTTP 的明文传输带来的安全问题就引入了 HTTPS。HTTPS 是在 HTTP 和 TCP 之间增加了一层 SSL/TLS 加密层。这样一来即使 HTTP 报文内容是明文的但在通过网络传输之前整个报文会被 SSL/TLS 层加密变成只有服务器拥有私钥才能解密的密文。传输过程中的第三方截获到的将是无法解读的乱码大大提高了通信的安全性。 HTTP协议发展过程
⽬前为⽌HTTP 常⻅的版本有 HTTP/1.1 HTTP/2.0 HTTP/3.0 不同版本的 HTTP 特性是不⼀样的。我们上面介绍到的HTTP/1.1的很多特点已经不适用 HTTP/2.0 HTTP/3.0了。
关于HTTP1.1之前的版本我们就来进行简单了解一下就行啦 HTTP/0.9 HTTP/0.9 是最早的HTTP版本在1991年就已经发布只⽀持 GET ⽅法也没有请求头服务器只能返回 HTML格式的内容。 HTTP/1.0 HTTP/1.0 是HTTTP 协议的第⼀个正式版本, 主要具有以下特性 引⼊了请求头和响应头⽀持多种请求⽅法和状态码 不⽀持持久连接每次请求都需要建⽴新的连接属于短连接 为了解决 HTTP/1.0 每次请求都需要建⽴新的连接的问题 HTTP/1.1 提出了⻓连接持久连接只要客户端和 服务器任意⼀端没有明确提出断开连接则保持TCP连接状态。 HTTP/1.1的不足
首先说一下HTTP/1.1的一些其他缺点当然这是相对于HTTP/2.0的改进来说的啦。
1. 在 HTTP/1.1 中为了确保通信的正确性和可靠性客户端通常会等待接收到一个请求的完整响应后才在同一个持久连接上发送下一个请求。
关于HTTP请求我想先补充一下访问一个网页输入一次网址需要发出多次 HTTP 请求这个知识。 一个标准的 HTTP 请求是为了获取一个特定的“资源”Resource。在很多情况下这个“资源”对应于服务器上的一个文件比如一个 HTML 文件、一个 CSS 文件、一个图片文件。 一个网页是由多个文件进行组成的所以访问一个网页需要多次发出HTTP请求而我们的HTTP1.1协议的请求必须等到上一个HTTP请求的响应到达才可以发送下一个。这就导致浏览器渲染页面时候渲染得很慢因为数据可能需要一段时间才能完全准备好。 虽然HTTP/1.1 理论上有一个叫做**管线化Pipelining**的功能允许客户端在收到上一个请求的响应之前就发送下一个请求。如果管线化被完全启用且工作正常那么就不需要等收到响应再发送下一个请求。但是几乎没有浏览器会采用HTTP/1.1的管线化。 因为HTTP1.1的管线化要求数据必须顺序响应比如请求了123响应也必须按照123来响应。 在 HTTP/1.1 开启管线化后接收响应的顺序和请求顺序不一致比如请求 1, 2, 3响应收到 2, 1, 3通常会导致直接的错误浏览器也很难进行有效的暂存和重组。 原因在于 HTTP/1.1 是基于文本流的协议并且在同一个连接上客户端解析响应必须是严格按照顺序来的。感觉HTTP/1.1的管线化很鸡肋所以一般不开启HTTP1.1的管线化也正常 为了提高HTTP/1.1请求响应速度我们可以采用如下优化方式
1. 建立多条tcp连接这是现代浏览器在处理 HTTP/1.1 网页时默认采用的策略。它们通常会限制对同一个域名同时建立的连接数一般是 6-8 个。
2. 将一些文件内容尽可能合并减少需要传输的文件数量例如将多个 CSS 文件合并成一个 CSS 文件将多个 JS 文件合并成一个 JS 文件将多个小图片合并成一个雪碧图 - Sprite Image。 雪碧图 将网页中多个小图片例如各种图标、按钮背景、小装饰图等合并到一张大的图片文件中。在网页中使用这些小图片时不再分别引用原始的单个图片文件。而是将需要使用小图片元素的背景图片设置为这张大的雪碧图。然后通过 CSS 的 background-position 属性精确地控制元素的背景图片显示区域只显示雪碧图中的某个特定小图片部分。同时设置元素的 width 和 height 来定义这个显示区域的大小。 HTTP/2.0
二进制分帧层 (Binary Framing Layer)
特点 这是 HTTP/2 最基础的变化。HTTP/2 不再是 HTTP/1.1 那样的纯文本协议而是在应用层和传输层之间增加了一个二进制分帧层。HTTP/2 的所有通信都被分解为更小的、带有标识符和长度前缀的二进制帧 (Frames)。工作原理 不同类型的消息如头部、数据都被封装在不同类型的帧中。这些帧拥有流标识符 (Stream Identifier)用于区分它们属于哪个请求或响应。带来的改进 这是实现 HTTP/2 其他所有高级特性的基础。将报文分割成帧使得多路复用、优先级控制等成为可能改变了 HTTP/1.1 基于文本和顺序解析的模式。 多路复用 (Multiplexing)
特点 允许在单个 TCP 连接上同时发送和接收多个 HTTP 请求和响应并且它们可以乱序发送和到达。工作原理 通过二进制分帧和流Stream的概念实现。每个请求/响应都在一个独立的逻辑流中进行由唯一的 Stream ID 标识。不同流的帧可以在同一个 TCP 连接上交错发送。客户端和服务器根据帧的 Stream ID 将它们重新组装成完整的请求或响应。带来的改进 (解决 HTTP/1.1 队头阻塞和多连接开销) 这是 HTTP/2 解决 HTTP/1.1 应用层队头阻塞问题的核心机制。一个请求/响应的延迟不会阻塞同一连接上的其他请求/响应。同时它大幅减少了 HTTP/1.1 中为了提高并行度而不得不建立多个 TCP 连接的开销三次握手、四次挥手、慢启动等降低了延迟和服务器资源消耗。 头部压缩 (Header Compression - HPACK)
特点 有效地压缩 HTTP 头部减少重复数据的传输。工作原理 HTTP/2 使用 HPACK 压缩算法。它在客户端和服务器之间维护和更新一个共享的头部信息表包括静态表预定义常见的头部字段和动态表记录本次连接中发送过的头部。传输头部时如果头部字段是表中已有的只需发送其索引如果是新的字段则发送其值并更新表。此外还使用了 Huffman 编码对字符串进行压缩。带来的改进 (解决头部冗余) 大幅减少了重复发送的头部数据量特别是在请求同一个网站的多个资源时头部通常非常相似压缩效果显著节省了带宽提高了传输效率。 强制使用 HTTPS (De Facto Requirement for HTTPS)
特点 虽然 HTTP/2 规范本身允许在明文 TCP 上运行称作 h2c但目前绝大多数主流浏览器如 Chrome, Firefox, Edge, Safari只支持在 TLS/SSL 加密连接上运行 HTTP/2称作 h2。带来的影响 实际上促使了网站向 HTTPS 迁移因为只有使用了 HTTPS才能享受到 HTTP/2 带来的性能优势从而提高了整个 Web 的安全性。 HTTP/3.0
HTTP/2.0仍然可能面临传输层TCP 层面的队头阻塞问题。
因为 HTTP/2 的所有流Streams的数据帧都是在同一个 TCP 连接上进行传输的它们的数据是被混合多路复用在一起发送的。如果 TCP 连接中的一个数据包丢失了并且这个数据包中包含了多个 HTTP/2 流的帧数据那么 TCP 层面的阻塞会导致所有这些流以及后续流的数据都无法及时递交给 HTTP/2 层进行处理和重组直到丢失的数据包被恢复。 HTTP/3 基于 UDP 的 QUIC 协议提供了传输层面的多路复用。QUIC 的流是独立的一个流的丢包不会阻塞其他流的数据传输。因此HTTP/3 彻底解决了队头阻塞问题包括应用层和传输层。但是目前HTTP/3.0应用不广泛目前用的最多的还是HTTP/2.0。 HTTPS协议
HTTP协议和HTTPS协议的区别
HTTP超文本传输协议
HTTPS超文本安全传输协议
HTTPS 本质上不是一个全新的、独立的协议它更准确地说是一个 在安全层上运行的 HTTP 协议。它是在标准的 HTTP 协议与底层的传输协议主要是 TCP之间插入了 TLS/SSL传输层安全/安全套接层 协议。
当您建立一个安全的 HTTPS 连接时实际使用的是 TLS 协议通常是 TLS 1.2 或 TLS 1.3
TLS 是 SSL 的继任者或升级版本。它是基于 SSL 3.0 演变而来的。SSL 版本特别是 SSL 2.0 和 SSL 3.0由于存在已知的严重安全漏洞已经被弃用了。我们现在可以认为HTTPS HTTP TLS。 安全性 (Security): HTTP: 数据在客户端和服务器之间以明文形式传输。这意味着任何能够截获网络流量的第三方如网络管理员、ISP、攻击者都可以直接读取传输的数据内容包括敏感信息用户名、密码、支付信息等。数据也容易被篡改而客户端无法得知。 HTTPS: 数据在传输前会经过 TLS/SSL 加密。截获的数据是加密后的密文难以解读。TLS/SSL 还提供数据完整性检查确保数据在传输过程中没有被篡改。此外通过服务器身份认证通常基于数字证书客户端可以确认正在通信的服务器是合法的防止中间人攻击。 协议层级 (Protocol Stack): HTTP: 直接运行在 TCP 协议之上。HTTPS: 运行在 TLS/SSL 协议之上而 TLS/SSL 又运行在 TCP/UDP 协议之上。简而言之是 HTTP - TLS/SSL - TCP/UDP。 URL 前缀 (URL Scheme): HTTP: 使用 http://。HTTPS: 使用 https://。 默认端口 (Default Port): HTTP: 默认使用端口 80。HTTPS: 默认使用端口 443。 证书要求 (Certificate Requirement): HTTP: 不需要任何证书。HTTPS: 服务器必须拥有由受信任的证书颁发机构 (CA) 颁发的 SSL/TLS 数字证书。这个证书用于证明服务器的身份。虽然获取证书曾需要付费但现在有许多机构提供免费证书如 Lets Encrypt。 连接建立过程 (Connection Process): HTTP: TCP 三次握手即可开始传输 HTTP 数据。HTTPS: 在 TCP 三次握手之后还需要进行 TLS/SSL 握手过程。这个握手过程用于协商加密算法、交换密钥、进行身份验证等。这会增加一些初始连接建立的延迟。 HTTP 本身不加密HTTPS 的加密是由 TLS/SSL 层完成的通过复杂的握手过程利用非对称加密和证书认证来安全地协商出会话期间用于数据传输的对称密钥然后使用该对称密钥对所有 HTTP 数据进行快速加密传输。 HTTPS中的加密方式
对称加密
对称加密也称为私钥加密使⽤相同的密钥来进⾏加密和解密。 在加密过程中明⽂数据通过应⽤特定的算法和密钥进⾏加密⽣成密⽂数据。解密过程则是将密⽂数据应⽤ 同样的算法和密钥进⾏解密恢复为明⽂数据。 由于加密和解密都使⽤相同的密钥因此对称加密算法的速度通常较快但密钥的安全性很重要。如果密钥泄漏攻击者可以轻易地解密数据。 对称加密指的就是双方都知道加密的算法并且都拥有解密的钥匙但是这个钥匙如果不小心被攻击者知道的话即使双方通信时使用的是加密好的文件攻击者也可以用偷来的钥匙进行解开。你可能会想为什么这个私钥有机会被攻击者偷到呢因为这个私钥一定是需要一方通过网络明文传递给另一方的这样就给了攻击者可乘之机。 ⾮对称加密
⾮对称加密也称为公钥加密使⽤⼀对不同但相关的密钥公钥和私钥。 公钥⽤于加密数据私钥⽤于解密数据。如果使⽤公钥加密数据只有拥有相应私钥的⼈才能解密数据如果 使⽤私钥加密数据可以使⽤相应公钥解密。 除了加密和解密⾮对称加密还⽤于【数字签名】可以验证消息的来源和完整性。 非对称加密实际上是把制作这把锁的方法公开任何人都可以按照你说的方法来制造这把锁并且把想要保密的内容锁上然后只有你自己有这把钥匙打开钥匙一直掌握在你自己的手中没有进行传播不可能出现泄露。 你可能会想就是为什么制作锁的方式公布出去了之后难道不能通过这个锁推断出钥匙是什么样子的吗这就涉及数学中的陷门单向函数 例如 RSA 算法。生成密钥时你选择两个非常大的素数作为私钥的一部分然后将它们相乘得到一个更大的合数这个合数就是公钥的一部分。乘法是容易的。但给定一个非常大的合数想要找出它的两个原始素数因子分解因数在目前没有任何已知的快速算法计算量会随着数字的增大呈指数级增长。 HTTPS中的 非对称加密对称加密
HTTPS 中采用的加密算法是 非对称加密 对称加密 的混合加密方式。 在握手阶段 (Handshake Phase) 主要使用非对称加密。这是为了安全地协商和交换用于后续数据传输的对称密钥。因为非对称加密的公钥(锁的制作方法)是公开的发送方可以用公钥加密一个密钥只有拥有对应私钥的接收方能解密得到这样发送方和接收方就都获得了对称加密算法中的私钥并且这个私钥没有在网络中以明文的方式传播所以黑客是获取不到对称加密的私钥的。 同时非对称加密通过数字签名也用于验证服务器的身份客户端使用 CA 的公钥验证服务器证书上的签名。 在数据传输阶段 (Data Transfer Phase) 一旦握手完成双方就使用在握手阶段协商和生成好的对称密钥来对实际传输的大量 HTTP 数据请求头、体、响应头、体进行对称加密。
为什么采用混合方式
非对称加密虽然安全密钥交换和身份验证但计算开销大速度慢不适合用来加密大量的数据。对称加密计算开销小速度快适合用来加密大量的数据但它的问题在于如何安全地在通信双方之间共享密钥。
HTTPS 的混合加密正是解决了这个矛盾利用非对称加密的安全性来解决对称密钥的共享问题安全地交换对称密钥然后利用对称加密的高效性来解决大量数据加密的问题。 HTTPS中建立连接的方式
HTTPS 连接的建立过程可以分解为两个主要步骤 底层 TCP 连接建立 这是任何基于 TCP 的网络通信包括 HTTP 和 HTTPS都需要的第一步。客户端和服务器之间进行经典的 TCP 三次握手 (Three-Way Handshake) 客户端 - 服务器: SYN (同步序列号)服务器 - 客户端: SYN-ACK (同步序列号并确认)客户端 - 服务器: ACK (确认) 握手成功后客户端和服务器之间就建立了一个可靠的、双向的 TCP 连接。 TLS/SSL 安全连接建立 客户端向服务器索要并验证服务器的公钥非对称加密。双⽅协商⽣产「会话秘钥」对称加密。双⽅采⽤「会话秘钥」进⾏加密通信。
