北京创意网站建设,低代码开发公众号,wordpress关注功能,p2p网贷网站开发在本文中#xff0c;我们将深入探讨万维网数据通信的基础 - HTTP。 什么是超文本#xff1f; HTTP#xff08;超文本传输协议#xff09;的命名源于“超文本”。 那么#xff0c;什么是超文本#xff1f; 想象一下由超链接组成的文本、图像和视频的混合物。这些链接充当我… 在本文中我们将深入探讨万维网数据通信的基础 - HTTP。 什么是超文本 HTTP超文本传输协议的命名源于“超文本”。 那么什么是超文本 想象一下由超链接组成的文本、图像和视频的混合物。这些链接充当我们从一个超文本集合跳转到另一个集合的门户。HTML超文本标记语言就是超文本的一个典型示例。 HTML是一个纯文本文件。它包含许多标签这些标签定义了到图像、视频等的链接。浏览器解释这些标签后将看似普通的文本文件转换为充满文本和图像的网页。 HTTP/1.1、HTTP/2和HTTP/3 自从1989年诞生HTTP 0.9以来HTTP经历了重大变革。让我们回顾一下每个HTTP版本解决的问题。下图展示了关键的改进。 •HTTP/1.0在1996年最终定稿并正式记录下来。该版本有一个重要限制对同一服务器的每个请求都需要单独的TCP连接。•HTTP/1.1在1997年推出。它引入了“持久连接”的概念意味着可以保持TCP连接以进行重用。尽管有这一改进HTTP/1.1无法解决“HOLHead-of-Line阻塞”问题。简而言之当浏览器的所有并行请求槽都被占满时后续请求必须等待前面的请求完成这就是HOL阻塞。•HTTP/2.0于2015年发布旨在解决HOL阻塞问题。它实现了“请求多路复用”request multiplexing的策略以消除应用层的HOL阻塞。如下图所示HTTP/2.0引入了HTTP“流”的概念。这种抽象允许将不同的HTTP交换复用到同一TCP连接中无需按顺序发送每个流。但是HOL阻塞仍可能发生在传输TCP层。•HTTP/3.0于2020年发布了一份草案作为HTTP/2.0的继任者它将TCP替换为QUIC作为底层传输协议。这有效地消除了传输层的HOL阻塞。QUIC基于UDP。它在传输层引入了流作为一级公民。QUIC流共享相同的QUIC连接无需额外的握手或慢启动来创建新的流。QUIC流可以独立传输。这意味着在大多数情况下一个流中的数据包丢失不会影响其他流。 HTTP头部 HTTP头部在客户端和服务器之间发送和接收数据时起着关键作用。它们为这些实体提供了一种结构化的方式来传递有关请求或响应的重要元数据。这些元数据可以包含各种信息例如发送的数据类型、长度、压缩方式等。 HTTP头部由多个字段组成每个字段具有特定的作用和含义。现在我们对HTTP头部有了一定的了解让我们深入探讨一些特定的HTTP字段。 HTTP字段 当我们向服务器发送HTTP请求时有一些常见的字段起着至关重要的作用。让我们逐个剖析一些字段。 •Host这是服务器的域名。•Content-Length请求或响应头部中的这个字段在数据传输中起着至关重要的作用。它明确地指示请求或响应主体的大小以字节为单位。这有助于接收方理解当前消息何时结束并可能为下一个消息做准备特别是在多个HTTP消息通过同一连接发送的情况下。•Connection该字段在HTTP持久连接中至关重要其中一个TCP连接用于发送和接收多个HTTP请求和响应。我们将详细讨论这个。•Content-type该字段告诉客户端接收到的数据的格式。•Content-encoding该字段指示用于数据的压缩格式。例如如果客户端看到gzip编码它知道需要解压缩数据。 HTTP GET与HTTP POST HTTP协议定义了各种方法或“动词”来对Web资源执行不同的操作。常用的方法包括GET、POST、PUT和DELETE通常用于读取、创建、更新和删除资源。较少使用的方法包括HEAD、CONNECT、OPTIONS、TRACE和PATCH我们在之前的“API设计”问题中已经介绍过。 一个常见的面试问题是“GET和POST有什么区别”让我们深入了解它们的定义。 HTTP GET该方法通过URL从服务器检索资源不会产生其他影响。由于GET请求通常没有有效载荷主体因此可以对网页进行书签、共享和缓存。 HTTP POST该方法基于有效载荷主体与资源进行交互。交互方式因资源类型而异。例如如果我们在购买了一台 iPhone 14 后留下了一条评论并单击“提交”将发送带有评论的POST请求到服务器。虽然HTTP协议本身对POST请求的消息主体大小没有定义限制但实际上浏览器和服务器通常会施加自己的限制。 理解GET和POST的特性 HTTP方法具有一些属性定义了它们与服务器资源交互的方式。其中两个属性是它们是否“非变异”和“幂等”。 非变异方法不会改变任何服务器资源。相反幂等方法无论重复多少次都会产生相同的结果。 HTTP GETGET方法检索数据而不会引起更改因此是非变异的。此外重复GET请求不会改变结果因此是幂等的。 HTTP POST与GET不同POST方法发送的数据可以修改服务器资源因此可能是可变异的。此外如果我们重复POST请求它可能会创建额外的资源因此是非幂等的。 然而重要的是要注意实际行为可能取决于服务器如何实现这些方法。虽然标准建议特定行为但开发人员有时会以非标准的方式使用这些方法。例如GET方法可能用于删除数据使其既可变异又非幂等或者POST方法可能用于检索数据使其非变异和潜在幂等。 有一个臭名昭著的例子是一个博客作者使用GET来执行帖子删除操作假设没有人会访问该博客。但是当Google抓取该博客时所有帖子都被删除了 此外值得注意的是无论是GET还是POST它们本身并不安全无法防止信息泄露。GET参数在URL中可见而POST主体虽然在URL中不可见但如果没有加密仍然可以被拦截。为了确保安全的数据传输建议使用HTTPS这是我们将在后面更详细地讨论的一个主题。 HTTP Keep-Alive与TCP keepalive 我们已经讨论过HTTP如何使用“Connection: Keep-Alive”来启动持久连接。还记得在TCP问题中提到的TCP keepalive机制吗它们是否相同不它们完全不同 •HTTP Keep-Alive与HTTP持久连接相关它在应用层运行。•TCP keepalive在传输层工作在数据交换空闲期间保持TCP连接活动。 让我们深入了解。 HTTP Keep-Alive 除了HTTP/3以外HTTP都构建在TCP之上。建立HTTP连接需要进行3次TCP握手。在发送HTTP请求并接收到响应后TCP连接断开。 以这种方式向同一服务器发送多个请求非常低效。重用相同的TCP连接是否更好这就是HTTP Keep-Alive的目的。它保持TCP连接直到任一方请求断开连接。 HTTP/1.1默认启用了HTTP Keep-Alive。 HTTP Keep-Alive减少了打开和关闭TCP连接的开销。当与HTTP/2结合使用时效果更好。HTTP/2引入了“流”的概念。 流允许我们同时发送多个请求而无需等待服务器的响应。更重要的是这些请求和响应可以按照任意顺序处理这在仅使用HTTP Keep-Alive时是不可能的。 下面的对比图显示了HTTP Keep-Alive和HTTP/2流之间的区别。通常我们等待第一个响应返回后才发送第二个请求。但是使用HTTP/2流我们可以同时发送多个请求而无需等待第一个响应服务器可以按任意顺序响应。 为什么这很重要这个特性对于避免“HOLHead-of-Line阻塞”非常关键。在HTTP的早期版本中如果服务器处理一个请求的时间很长后续的请求必须等待导致延迟。但是使用HTTP/2流每个请求是独立的。即使服务器处理一个请求的时间较长它仍然可以响应其他请求。响应可以在准备就绪时立即返回即使这意味着它们的顺序与原始请求不同。 TCP keepalive TCP keepalive与HTTP Keep-Alive无关。在TCP连接中双方保持在已建立状态直到一方结束连接。如果一方不通知另一方而断开连接剩余的一方将不知道。TCP keepalive通过在没有数据交换时定期发送探测来解决这个问题。我们在之前的TCP问题中讨论过。下面的图表应该对此有所复习。
