HTTP 报文结构

  HTTP位于五层模型中的应用层,是传输层(代表为TCP协议)的上层协议。

之前我们通过 socket 实现了使用 TCP 协议进行数据收发:手写一个模块化的 TCP 服务端客户端 ,对 TCP 协议的使用有了一个初步的认识。

  简单的说,IP 协议 帮助我们的数据包在复杂的网络环境下进行寻址,但并不能保证数据包一定可以到达目的地。因为传输环境或网络可能会非常复杂,我们并不能保证路由算法在所有场景下都可以准确的到达目的地,加上为了避免冗余数据包滞留网络对网络造成破坏,IP 协议中还存在最大跃点数等数据销毁机制。因此 IP 协议仅负责寻址,不负责到达。

  所以仅通过 IP 协议进行通信是不可靠的,TCP 协议位于 IP 协议的上层,通过 ACK 确认机制帮助我们在 IP 协议的基础上建立了可靠的数据通道。

  但 TCP 协议还是不能满足我们的通信要求,因为它是无界的。这使得我们无法将数据与请求联系起来,如果我们发送多次请求,请求的数据无间隔的到达或被封装在同一个数据包里到达的话,我们无法单纯的靠 TCP 协议确定某段数据属于哪次请求,也就是会出现所谓的粘包和半包问题。

  HTTP 帮我们解决了这个问题,它从数据层面帮助我们对请求进行了定界,进一步满足了我们的通信需求。

  整个网络分层模型就是一个责任链模式的典型代表,每层专注解决一类问题后将数据扔给下一层,直到到达我们的应用,使我们可以得到能直接能应用于业务的数据。

  HTTP 在传输层上层约定了数据的传输格式,搞懂报文格式才能理解其解析机制,当然要看全面的报文格式最好的方式当然是去查阅 RFC 文档,这里我们只介绍其主要部分。

  HTTP报文分为请求报文和响应报文,二者的基本格式是相同的。

  请求报文的格式:

  <method> <request-URL> <version>

  <headers>

  <entity-body>

  响应报文的格式

  <version><status><reason-phrase>

  <headers>

  <entity-body>

  method: 表示请求方法,如 GET/POST 。
  request-URL: 为请求的资源路径。

  version: 表示使用的协议版本号,如1.0/1.1等。
  status-code: 表示请求的状态码,描述请求过程中发生的情况,比如 200:成功;500:服务器端异常 等。

  reason-phrase: 表示原因短语,无特殊含义,类似我们平时设计表结构时设计的 remark 备注字段。

  header:请求首部。每个请求可以有零个或多个首部,每个首部都是一个键值对外加一个可选的空格。所有首部的最后由一个空行 CRLF 标识首部的结束。

  entity-body:请求的实体部分。包含着我们请求的数据,但并不是我们所有的请求参数都会在请求实体中,请求实体可为空,也是以一个空行 CRLF 标识结束。

  每个 HTTP 报文都是以一个起始行作为开始的。请求报文的起始行标明我要干什么,响应报文的起始行标明发生了什么。

  响应报文的起始行则没有 url 和请求方法。

  无论请求报文还是响应报文,其各字段间均是通过空格进行分隔的。

  响应报文中的状态码可以向请求者说明该次请求发生了什么事情。我们比较熟悉的状态码比如 404/302/500/200 等都属于响应报文的状态码。

  原因短语是方便我们阅读的状态码的可读版本,比如 200 后面跟的 OK 便是 200 的原因短语。  

  HTTP 首部用于向请求和响应的报文中添加一些额外的信息。HTTP规范定义了一些固定的首部字段,当然我们也可以随意添加自己定义的首部字段。

  首部有以下几种分类:

  通用首部:即可出现在请求报文中,也可出现在响应报文中
  请求首部:提供更多有关请求的信息
  响应首部:提供更多有关响应的信息
  实体首部:描述主体的长度和内容,或者资源本身
  扩展首部:规范中没有定义的新首部

  这样一来,首部可能会有比较多的附加字段,将长的首部行分为多行可以提高可读性,多出来的每行前面至少要有一个空格或制表符(tab)。

  以上是对 HTTP 协议组成部分比较粗粒度的介绍,下次我们基于其报文结构,在 TCP 通信框架上层手写一个解析 HTTP 报文的 Handler 。

 

原文地址:https://www.cnblogs.com/niuyourou/p/12578532.html

时间: 03-26

HTTP 报文结构的相关文章

HTTP协议的报文结构

HTTP 有两类报文: (1) 请求报文----从客户向服务器发送请求报文,见图6-12(a). (2) 响应报文----从服务器到客户的回答,见图6-12(b). 由于 HTTP是面向文本的(text-oriented),因此在报文中的每一个字段都是一些ASCII码串,因而每个字段的长度都是不确定的. HTTP请求报文和响应报文都是由三个部分组成.可以看出,这两种报文格式的区别就是开始行不同. (1) 开始行 用于区分是请求报文还是响应报文.在请求报文中的开始行叫做请求行(Request-Li

HTTP报文结构图解

GET请求报文如下 POST请求报文如下 200响应报文如下 404响应报文如下 HTML中的meta标签的http-equiv属性,实际上修改的是响应报文的响应头中的键值对 版权声明:本文为博主原创文章,未经博主允许不得转载.

重温Http协议--请求报文和响应报文

http协议是位于应用层的协议,我们在日常浏览网页比如在导航网站请求百度首页的时候,会先通过http协议把请求做一个类似于编码的工作,发送给百度的服务器,然后在百度服务器响应请求时把相应的内容再通过http协议做一个类似于解码的工作,这样浏览器才能理解这个数据,然后为我们展示出来百度首页. 这相当于是一种规范,网络中数据的传输在位于应用之下的各层(传输层,应用层)来完成的,在tcp/ip协议接收到数据时,我们是不能直接使用和浏览的,需要先通过一种规范来进行梳理,也就是解码,得到浏览器支持的一种格

HTTP报文

引用 学习Web开发不好好学习HTTP报文,将会“打拳不练功,到老一场空”,你花在犯迷糊上的时间比你沉下心来学习HTTP的时间肯定会多很多. HTTP请求报文解剖 HTTP请求报文由3部分组成(请求行+请求头+请求体): 下面是一个实际的请求报文: ①是请求方法,GET和POST是最常见的HTTP方法,除此以外还包括DELETE.HEAD.OPTIONS.PUT.TRACE.不过,当前的大多数浏览器只支持GET和POST,Spring 3.0提供了一个HiddenHttpMethodFilter

ICMP:Internet控制报文协议实现学习笔记

ICMP是网络层的一个协议,可以看作IP协议的附属协议,因为它主要被IP用来与其他主机或路由器交换错误报文及其他需要注意的信息.当然,更高层协议(tcp/udp)甚至有些用户进程也可能用到ICMP报文 注册ICMP协议和ICMP协议的处理涉及以下文件: net/ipv4/icmp.c ICMP协议处理入口 net/ipv4/af_inet.c 网络层和传输层接口 ICMP报文结构 参见tcp/ip协议学习笔记(5)Internet Control Message Protocol(ICMP) 注

SylixOS CAN总线报文浅析

CAN的报文格式 在总线中传送的报文,每帧由7部分组成.CAN协议支持两种报文格式,其唯一的不同是标识符(ID)长度不同,标准格式为11位,扩展格式为29位. 在标准格式中,报文的起始位称为帧起始(SOF),然后是由11位标识符和远程发送请求位(RTR)组成的仲裁场.RTR位标明是数据帧还是请求帧,在请求帧中没有数据字节. 控制场包括标识符扩展位(IDE),指出是标准格式还是扩展格式.它还包括一个保留位 (ro),为将来扩展使用.它的最后四个位用来指明数据场中数据的长度(DLC).数据场范围为0

前端学HTTP之报文系列第一篇——起始行

前面的话 如果说HTTP是因特网的信使,那么HTTP报文就是它用来搬东西的包裹了.HTTP报文是在HTTP应用程序之间发送的简单的格式化数据块,每条报文都包含一条来自客户端的请求,或者一条来自服务器的响应.它们由三个部分组成:由起始行.首部和实体的主体部分.本文是HTTP报文系列第一篇——起始行 报文语法 所有的HTTP报文都可以分为两类:请求报文(request message)和响应报文(response message).请求报文会向Web服务器请求一个动作,响应报文会将请求的结果返回给客

[C#]通过Http报文上传文件

前言 这段时间做C#客户端项目时,在网上找到一个用Http请求实现文件上传的方法,实测有效. 在讲解如何实现Http上传文件之前,不妨先了解一下Http上传文件报文是什么样的.相信看了报文结构,有利于了解代码的实现过程. 下图是我自己的程序上传文件时时,用wireshark抓取的包内容. 可以看到,这个Http报文结构其实并不复杂. 需要注意的是,这个报文中有一个boundary,这是一个识别文件流的边界,用来标识文件开始和结尾的位置. 接下来,我将一步步说明如何封装Http上传文件报文. C#

(转载)解析ISO8583报文实例

本篇文章参考了中国银联POS终端规范,所以如有不明白的可以去我的资源里面下载. 现在我们有ISO8583报文如下(十六进制表示法): 60 00 03 00 00(前五个字节为TPDU) 60 31 00 31 07 30(报文头占用六个字节) 02 00(应用数据占用2个字节) 30 20 04 C0 20 C0 98 11(8个字节是位图) 00 00 00 00 00 00 00 00 01 00 03 49 02 10 00 12 30 62 25 82 21 12 99 63 01 5

8583报文的使用和解析

ISO8583报文(简称8583包)又称8583报文是一个国际标准的包格式,最多由128个字段域组成,每个域都有统一的规定,并有定长与变长之分. 8583包前面一段为位图,用来确定包的字段域组成情况. 其中位图是8583包的灵魂,它是打包解包确定字段域的关键,而了解每个字段域的属性则是填写数据的基础.在POS机的开发上时经常要用到,例如回头客会员管理系统在POS机上的应用就是采用8583报文. "消费"类型报文的测试和组8583报文的过程,说明一下,这里是针对我们日常使用POS机系统来