- Java锁的逻辑(结合对象头和ObjectMonitor)
- 还在用饼状图?来瞧瞧这些炫酷的百分比可视化新图形(附代码实现)⛵
- 自动注册实体类到EntityFrameworkCore上下文,并适配ABP及ABPVNext
- 基于Sklearn机器学习代码实战
在上一章节中,我们详细探讨了超文本传输协议(HTTP)的基本概念,并且延伸讨论了HTTP请求响应的基本流程。在这个过程中,浏览器首先通过DNS解析来确定要访问的服务器的IP地址,然后与服务器建立起HTTP连接。接下来,浏览器会向服务器发送HTTP请求报文,而服务器则会解析该请求报文,并返回包含所请求资源的HTTP响应报文.
在今天的章节中,我们将会详细讲解HTTP请求特征、报文的格式.
HTTP 最显著的优点之一是其简单、灵活、易于扩展、应用广泛和跨平台的特性。HTTP 的跨平台能力与 Java 这种跨平台语言类似,它能够在不同的操作系统和设备上进行通信和传输。这是因为 HTTP 使用的是系统调用的暴露出来的统一接口,而不依赖于特定的操作系统或硬件。因此,无论是在 Windows、Mac 还是 Linux 等各种操作系统上,都可以使用 HTTP 进行网络通信.
简单:HTTP的基本报文格式非常简单,由头部信息和主体组成。头部信息采用简单的键值对文本形式表示,这种简洁明了的格式使得人们能够轻松理解和使用,从而降低了学习和使用的门槛.
灵活和易于扩展:HTTP协议的灵活性和易于扩展的特点体现在各类请求方法、URI/URL、状态码、头字段等组成要素上。这些要素并没有被硬性固定,而是允许开发人员根据需要进行自定义和扩展。这种灵活性使得HTTP协议适用于不同的应用场景,并且可以根据具体需求进行定制和优化。最常见的就是各个开放平台文档中规定着状态码对应着不同的业务错误逻辑,以便开发人员快速定位问题。同时,HTTP作为工作在应用层(OSI第七层)的协议,它的下层可以随意变化。例如,HTTPS在HTTP与TCP层之间增加了SSL/TLS安全传输层,提供了加密和身份验证的功能,保护了通信的安全性。而HTTP/3更进一步,将TCP层替换为基于UDP的QUIC协议,以提供更快的传输速度和更好的性能。这种下层的变化和优化使得HTTP协议能够适应不断变化的网络环境和需求,保持其在互联网通信中的重要地位.
应用广泛和跨平台:HTTP作为一种通信协议,具有广泛的应用范围和跨平台的优势。随着互联网的发展,人们在各种设备上使用HTTP进行通信的场景变得非常普遍。无论是在台式机的浏览器上浏览新闻、社交媒体,还是在手机上使用各种应用程序进行购物、理财、游戏等活动,HTTP都扮演着重要的角色。HTTP的应用场景之多,几乎无所不包,它的灵活性和易于扩展的特点使得它能够适应不同的需求和各种不同的应用程序。而且,HTTP天然具有跨平台的优越性,无论是在Windows、MacOS、Linux等各种操作系统上,还是在iOS、Android等不同的移动设备上,HTTP都能够稳定地工作,保证了互联网通信的顺畅进行.
我们在上一章节中描述的HTTP请求响应过程是一种非持久连接,因为每次TCP在传递完报文后,都会关闭TCP连接,每个TCP连接只传输一个请求报文和响应报文.
非持久性连接有一些缺点。首先,必须为每个请求的对象建立和维护一个全新的连接。这意味着每次请求都需要进行TCP连接的建立和断开,增加了网络延迟和服务器的负担。其次,对于每个这样的连接来说,在客户端和服务器中都要分配TCP的缓冲区和保持TCP变量,这给Web服务器带来了严重的负担。因为一台Web服务器可能要同时服务于数百甚至上千个客户请求,这意味着服务器需要为每个连接分配和管理大量的资源,增加了服务器的开销和复杂性.
早期的HTTP/1.0在性能方面存在一个严重问题,即每次发起请求都需要建立一个新的TCP连接(进行三次握手),并且这些请求是串行的,这样做增加了通信的开销,而且进行了不必要的TCP连接的建立和断开操作.
为了解决上述TCP连接的问题,HTTP/1.1提出了长连接的通信方式,也被称为持久连接。这种方式的好处在于减少了重复建立和断开TCP连接所带来的额外开销,从而减轻了服务器的负载。持久连接的特点是只要任意一端没有明确提出断开连接的要求,TCP连接就会保持.
长连接并不是一直保持连接的,它是指在一段时间内保持连接的状态,而不是每次请求都重新建立连接。这种持久连接的机制可以减少TCP连接的建立和断开次数,提高请求的效率.
在HTTP/1.1中,引入了持久连接的概念。当客户端发送一个长连接请求后,服务器会在响应中加上一个"Connection: keep-alive"的头部字段,表示服务器愿意保持连接。这样,当客户端再次发送请求时,可以利用之前建立的连接,而不需要重新建立TCP连接.
当然,并不是所有的连接都是长连接。服务器可以在响应中加上"Connection: close"的头部字段,表示服务器不再保持连接,这时客户端需要在接收到响应后主动关闭连接。还可能出现超时等情况导致连接关闭.
在上一节描述HTTP请求响应过程中,我们简要介绍了HTTP的请求响应过程,希望能够让你对HTTP有更深入的了解。现在,我们将一起了解一下HTTP报文的格式是怎样的.
HTTP协议主要由三大部分组成,分别是:
根据HTTP协议规定,每次发送的报文都必须包含头部(Header),其中起始行和头部字段组成了请求头或响应头。消息正文也被称为实体,即body。需要注意的是,每个报文必须有头部信息,但可以没有实体信息。此外,在头部和实体之间必须有一个空行(CRLF)分隔.
这张图需要注意一下。如果你使用的是GET方法,对应的请求是没有实体体的;但如果你使用的是POST方法,请求会包含实体体。当用户提交表单时,通常会使用POST方法来发送请求;与此相反,获取HTML表单的数据通常会使用GET方法。另外,HEAD方法类似于GET方法,但不会返回实体体.
下面我们来仔细研究一下HTTP响应报文.
可以观察到,在请求报文和响应报文中,唯一不同的是请求头,而其他的信息都是相同的。在请求报文中,请求行包含了以下信息:
GET /mp/appmsgalbum HTTP/1.1
响应报⽂:
HTTP/1.1 200 OK
本章主要讲解了HTTP请求的特征和报文的格式。HTTP具有简单、灵活、易于扩展、应用广泛和跨平台的特点,适用于不同的操作系统和设备。文章还介绍了持久性连接和非持久性连接。非持久性连接会增加网络延迟和服务器负担,而持久性连接通过减少重复建立和断开TCP连接的开销,提高了请求的效率.
最后,文章详细介绍了HTTP报文的格式,包括起始行、头部字段和消息正文。每个报文都必须有头部信息,但可以没有实体信息。同时,请求报文和响应报文的格式有些许不同.
总的来说,本章对HTTP请求的特征和报文的格式进行了详细介绍,让读者更全面地了解了HTTP协议的基本知识.
最后此篇关于深入解析HTTP请求:了解请求特征与报文格式的关键秘密的文章就讲到这里了,如果你想了解更多关于深入解析HTTP请求:了解请求特征与报文格式的关键秘密的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
据我了解,HTTP POST 请求的正文大小没有限制。因此,客户端可能会在一个 HTTP 请求中发送 千兆字节 的数据。现在我想知道 HTTP 服务器应该如何处理此类请求。 Tomcat 和 Jett
在了解Web Deploy我遇到了一些讨论 http://+:80 和 http://*:80 的 netsh.exe 命令。这些是什么意思? 最佳答案 引自URLPrefix Strings (Wi
假设我有一个负载均衡器,然后是 2 个 Web 服务器,然后是一个负载均衡器,然后是 4 个应用程序服务器。 HTTP 响应是否遵循与 HTTP 请求服务相同的路径? 最佳答案 按路径,我假设您是网络
我有一个带有 uri /api/books/122 的资源,如果在客户端为此资源发送 HTTP Delete 时该资源不存在,那么相应的响应代码是什么这个 Action ?是不是404 Not Fou
是否有特定的(或约定的)HTTP 响应消息(或除断开连接之外的其他操作)来阐明服务器不接受 pipelined HTTP requests ? 我正在寻找能让客户端停止流水线化它的请求并分别发送每个请
在了解Web Deploy我遇到了一些讨论 http://+:80 和 http://*:80 的 netsh.exe 命令。这些是什么意思? 最佳答案 引自URLPrefix Strings (Wi
我有一个带有 uri /api/books/122 的资源,如果在客户端为此资源发送 HTTP Delete 时该资源不存在,那么相应的响应代码是什么这个 Action ?是不是404 Not Fou
关闭。这个问题需要更多focused .它目前不接受答案。 想改进这个问题吗? 更新问题,使其只关注一个问题 editing this post . 关闭 8 年前。 Improve this qu
我使用 Mule 作为 REST API AMQP。我必须发送自定义请求方法:“PRINT”,但我收到: Status Code: 400 Bad Request The request could
我需要针对具有不同 HTTP 响应代码的 URL 测试我的脚本。我如何获取响应代码 300、303 或 307 等的示例/示例现有 URL? 谢谢! 最佳答案 您可以使用 httpbin为此目的。 例
我正在尝试编写一个程序来匹配 HTTP 请求及其相应的响应。似乎在大多数情况下一切都运行良好(当传输完全有序时,即使不是,通过使用 TCP 序列号)。 我发现的唯一问题是当我有流水线请求时。在那之后,
RESTful Web Services鼓励使用 HTTP 303将客户端重定向到资源的规范表示。它仅在 HTTP GET 的上下文中讨论主题。 这是否也适用于其他 HTTP 方法?如果客户端尝试对非
当使用chunked HTTP传输编码时,为什么服务器需要同时写出chunk的字节大小并且后续的chunk数据以CRLF结尾? 这不会使发送二进制数据“CRLF-unclean”和方法有点多余吗? 如
这个问题在这里已经有了答案: Is it acceptable for a server to send a HTTP response before the entire request has
如果我向同一台服务器发出多个 HTTP Get 请求并收到每个请求的 HTTP 200 OK 响应,我如何使用 Wireshark 判断哪个请求映射到哪个响应? 目前看起来像是发出了一个 http 请
func main() { http.HandleFunc("/", handler) } func handler(w http.ResponseWriter, r http.Request
我找不到有值(value)的 NodeJS with Typescript 教程,所以我在无指导下潜入水中,果然我有一个问题。 我不明白这两行之间的区别: import * as http from
问一个关于Are HTTP headers case-sensitive?的问题,如果 HTTP 方法区分大小写,大多数服务器如何处理“get”或“post”与“GET”或“POST”? 例如,看起来
我正在使用ASP.NET,在其中我通过动词GET接收查询,该应用程序专用于该URL。 该代码有效,但是如果用户发送的密码使http 200无效,请回答我,并在消息的正文中显示“Fail user or
Closed. This question needs details or clarity。它当前不接受答案。 想改善这个问题吗?添加详细信息,并通过editing this post阐明问题。 9
我是一名优秀的程序员,十分优秀!