HTTP 协议中你必须知道的三种数据格式

HTTP 协议中你必须知道的三种数据格式

实习中的一个主要工作就是分析HTTP 中的协议，自己也用Python 写过正则表达式对HTTP 请求和响应的内容进行匹配，然后把关键字段抽离出来放到一个字典中以备使用(可以稍微改造一下就是一个爬虫工具)。

HTTP 协议中的很多坑，自己都遇到过，我就针对自己遇到的几种HTTP 常见的数据格式，来做一个总结。

Zlib 压缩数据

对于Zlib，一点也不陌生，我们平时用它来压缩文件，常见类型有zip、rar 和7z 等。Zlib 是一种流行的文件压缩算法，应用十分广泛，尤其是在Linux 平台。当应用Zlib 压缩到一个纯文本文件时，效果是非常明显的，大约可以减少70％以上的文件大小,这取决于文件中的内容。

Zlib 也适用于Web 数据传输，比如利用Apache 中的Gzip (后面会提到，一种压缩算法) 模块，我们可以使用Gzip 压缩算法来对Apache 服务器发布的网页内容进行压缩后再传输到客户端浏览器。这样经过压缩后实际上降低了网络传输的字节数，最明显的好处就是可以加快网页加载的速度。

网页加载速度加快的好处不言而喻，节省流量，改善用户的浏览体验。而这些好处并不仅仅限于静态内容，PHP 动态页面和其他动态生成的内容均可以通过使用Apache 压缩模块压缩，加上其他的性能调整机制和相应的服务器端缓存规则，这可以大大提高网站的性能。因此，对于部署在Linux 服务器上的PHP 程序，在服务器支持的情况下，建议你开启使用Gzip Web 压缩。

Gzip 压缩两种类型

压缩算法不同，可以产生不同的压缩数据(目的都是为了减小文件大小)。目前Web 端流行的压缩格式有两种，分别是Gzip 和Defalte。

Apache 中的就是Gzip 模块，Deflate 是同时使用了LZ77 算法与哈夫曼编码（Huffman Coding）的一个无损数据压缩算法。Deflate 压缩与解压的源代码可以在自由、通用的压缩库zlib 上找到。

更高压缩率的Deflate 是7-zip 所实现的。AdvanceCOMP 也使用这种实现，它可以对gzip、PNG、MNG 以及ZIP 文件进行压缩从而得到比zlib 更小的文件大小。在Ken Silverman的KZIP 与PNGOUT 中使用了一种更加高效同时要求更多用户输入的Deflate 程序。

deflate 使用

inflateInit()，而gzip 使用inflateInit2() 进行初始化，比

inflateInit() 多一个参数: -MAX_WBITS，表示处理raw deflate 数据。因为gzip 数据中的zlib 压缩数据块没有zlib header 的两个字节。使用inflateInit2 时要求zlib 库忽略zlib header。在zlib 手册中要求windowBits 为8..15，但是实际上其它范围的数据有特殊作用，如负数表示raw deflate。

其实说这么多，总结一句话，Deflate 是一种压缩算法,是huffman 编码的一种加强。deflate 与gzip 解压的代码几乎相同，可以合成一块代码。

维基百科zlib。

Web 服务器处理数据压缩的过程

Web服务器接收到浏览器的HTTP请求后，检查浏览器是否支持HTTP压缩（Accept-Encoding 信息）；

如果浏览器支持HTTP压缩，Web服务器检查请求文件的后缀名；

如果请求文件是HTML、CSS等静态文件，Web服务器到压缩缓冲目录中检查是否已经存在请求文件的最新压缩文件；

如果请求文件的压缩文件不存在，Web服务器向浏览器返回未压缩的请求文件，并在压缩缓冲目录中存放请求文件的压缩文件；

如果请求文件的最新压缩文件已经存在，则直接返回请求文件的压缩文件；

如果请求文件是动态文件，Web服务器动态压缩内容并返回浏览器，压缩内容不存放到压缩缓存目录中。

举个栗子

说了这么多，下面举一个例子，打开抓包软件，访问我们学校的官网( https://www.wendangku.net/doc/a02141097.html, )，请求头如下:

GET /_css/tpl2/system.css HTTP/1.1

Host: https://www.wendangku.net/doc/a02141097.html,

Connection: keep-alive

User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36

Accept: text/css,*/*;q=0.1

Referer: https://www.wendangku.net/doc/a02141097.html,/

Accept-Encoding: gzip, deflate

Accept-Language: zh-CN,zh;q=0.8

Cookie: a10-default-cookie-persist-20480-sg_bluecoat_a=AFFIHIMKFAAA

在第七行，

Accept-Encoding 显示的是

gzip, deflate，这句话的意思是，浏览器告诉服务器支持gzip 和deflate 两种数据格式，服务器收到这种请求之后，会进行gzip 或deflate 压缩（一般都是返回gzip 格式的数据）。Python 的urllib2 就可以设置这个参数：

request = urllib2.Request(url)

request.add_header('Accept-encoding', 'gzip')

//或者设置成deflate

request.add_header('Accept-encoding', 'deflate')

//或者两者都设置

request.add_header('Accept-encoding', 'gzip, deflate')

服务器给的响应一般如下：

HTTP/1.1 200 OK

Date: Sat, 22 Oct 2016 11:41:19 GMT

Content-Type: text/javascript;charset=utf-8

Transfer-Encoding: chunked

Connection: close

Vary: Accept-Encoding

tracecode: 24798560510951725578102219

Server: Apache

Content-Encoding: gzip

400a

............ks#I. ...W...,....>..T..]..Z...Y..].MK..2..L..(略)

//响应体为压缩数据

从响应头来看，Content-Encoding: gzip 这段话说明响应体的压缩方式是gzip 压缩，一般有几种情况，字段为空表示明文无压缩，还有Content-Encoding: gzip 和Content-Encoding: deflate 两种。

实际上Gzip 网站要远比Deflate 多，之前写过一个简单爬虫从

hao123的主页开始爬，爬几千个网页(基本涵盖所有常用的)，专门分析响应体的压缩类型，得到的结果是：

Accept-Encoding 不设置参数：会返回一个无压缩的响应体（浏览器比较特别，他们会自动设置Accept-Encoding: gzip：deflate 来提高传输速度）；Accept-Encoding: gzip，100% 的网站都会返回gzip 压缩，但不保证互联网所有网站都支持gzip(万一没开启)；

Accept-Encoding: deflate：只有不到10% 的网站返回一个deflate 压缩的响应，其他的则返回一个没有压缩的响应体。

Accept-Encoding: gzip, deflate：返回的结果也都是gzip 格式的数据，说明在优先级上gzip 更受欢迎。

响应头的Encoding 字段很有帮助，比如我们写个正则表达式匹配响应头是什么压缩：

(?<=Content-Encoding: ).+(?=\r\n)

匹配到内容为空说明没有压缩，为

gzip 说明响应体要经过gzip 解压，为

deflate 说明为deflate 压缩。

Python 中的zlib 库

在python中有zlib库，它可以解决gzip、deflate和zlib压缩。这三种对应的压缩方式分别是：

RFC 1951 (deflate compressed format)

RFC 1952 (gzip compressed format)

虽说是Python 库，但是底层还是C(C++) 来实现的，这个

http-parser 也是C 实现的源码，Nodejs 的

http-parser 也是C 实现的源码，zlib

的C

源码在这里。C 真的好牛逼呀！

在解压缩的过程中，需要选择windowBits 参数：

to (de-)compress deflate format, use wbits = -zlib.MAX_WBITS

to (de-)compress zlib format, use wbits = zlib.MAX_WBITS

to (de-)compress gzip https://www.wendangku.net/doc/a02141097.html,mat, use wbits = zli

例如，解压gzip数据，就可以使用zlib.decompress(data, zlib.MAX_WBITS | 16)，解压deflate数据可以使用zlib.decompress(data,- zlib.MAX_WBITS)。当然，对于gzip文件，也可以使用python的gzip包来解决，可以参考下面的代码：

>>> import gzip

>>> import StringIO

>>> fio = StringIO.StringIO(gzip_data)

>>> f = gzip.GzipFile(fileobj=fio)

>>> f.read()'test'>>> f.close()

也可以在解压的时候自动加入头检测，把32加入头中就可以触发头检测，例如：

>>> zlib.decompress(gzip_data, zlib.MAX_WBITS|32)

'test'

>>> zlib.decompress(zlib_data, zlib.MAX_WBITS|32)

'test'

以上参考stackoverflow

How can I decompress a gzip stream with zlib?。

刚接触这些东西的时候，每天都会稀奇古怪的报一些错误，基本上Google 一下都能解决。

分块传输编码chunked

分块传输编码只在HTTP 协议 1.1 版本（HTTP/1.1）中提供。

通常，HTTP 应答消息中发送的数据是整个发送的，Content-Length 消息头字段表示数据的长度。数据的长度很重要，因为客户端需要知道哪里是应答消息的结束，以及后续应答消息的开始。然而，使用分块传输编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。通常数据块的大小是一致的，但也不总是这种情况。

分块传输的优点

HTTP 1.1引入分块传输编码提供了以下几点好处：

HTTP 分块传输编码允许服务器为动态生成的内容维持HTTP 持久链接。通常，持久链接需要服务器在开始发送消息体前发送Content-Length 消息头字段，但是对于动态生成的内容来说，在内容创建完之前是不可知的。

分块传输编码允许服务器在最后发送消息头字段。对于那些头字段值在内容被生成之前无法知道的情形非常重要，例如消息的内容要使用散列进行签名，散列的结果通过HTTP 消息头字段进行传输。没有分块传输编码时，服务器必须缓冲内容直到完成后计算头字段的值并在发送内容前发送这些头字段的值。

HTTP 服务器有时使用压缩（gzip 或deflate）以缩短传输花费的时间。分块传输编码可以用来分隔压缩对象的多个部分。在这种情况下，块不是分别压缩的，而是整个负载进行压缩，压缩的输出使用本文描述的方案进行分块传输。在压缩的情形中，分块编码有利于一边进行压缩一边发送数据，而不是先完成压缩过程以得知压缩后数据的大小。

注：以上内容来自于维基百科。

分块传输的格式

如果一个HTTP 消息（请求消息或应答消息）的Transfer-Encoding 消息头的值为chunked，那么，消息体由数量未定的块组成，并以最后一个大小为0 的块为结束。

每一个非空的块都以该块包含数据的字节数（字节数以十六进制表示）开始，跟随一个CRLF（回车及换行），然后是数据本身，最后块CRLF 结束。在一些实现中，块大小和CRLF 之间填充有白空格（0x20）。

最后一块是单行，由块大小（0），一些可选的填充白空格，以及CRLF。最后一块不再包含任何数据，但是可以发送可选的尾部，包括消息头字段。

消息最后以CRLF 结尾。例如下面就是一个chunked 格式的响应体。

HTTP/1.1 200 OK

Date: Wed, 06 Jul 2016 06:59:55 GMT

Server: Apache

Accept-Ranges: bytes

Transfer-Encoding: chunked

Content-Type: text/html

Age: 35

X-Via: 1.1 daodianxinxiazai58:88 (Cdn Cache Server V2.0), 1.1 yzdx147:1 (Cdn

Cache Server V2.0)

Connection: keep-alive

a

....k.|W..

166

..OO.0...&~..;........]..(F=V.A3.X..~z...-.l8......y....).?....,....j..h .6

....s.~.>..mZ .8/..,.)B.G.`"Dq.P].f=0..Q..d.....h......8....F..y......q.. (4)

{F..M.A.*..a.rAra.... .n>.D

..o@.`^.....!@ $...p...%a\D..K.. .d{2...UnF,C[....T.....c....V...."%.`U......?

D....#..K..<.....D.e....IFK0.<...)]K.V/eK.Qz...^....t...S6...m...^..CK.XRU?m..

.........Z..#Uik......

Transfer-Encoding: chunked字段可以看出响应体是否为chunked 压缩，chunked 数据很有意思，采用的格式是长度\r\n内容\r\n长度\r\n..0\r\n，而且长度还是十六进制的，最后以0\r\n 结尾(不保证都有)。因为上面的数据是gzip 压缩，看起来不够直观，下面举个简单的例子：

5\r\n

ababa\r\n

f\r\n

123451234512345\r\n

14\r\n

12345123451234512345\r\n

0\r\n

上述例子chunked 解码后的数据

ababa12345...，另外\r\n 是不可见的，我手动加的。

和gzip 一样，一样可以写一个正则表达式来匹配：

(?<=Transfer-Encoding: ).+(?=\r\n)

处理chunked 数据

从前面的介绍可以知道，response-body 部分其实由length(1) \r\n data(1) \r\n length(2) \r\n data(2)……循环组成，通过下面的函数进行处理，再根据压缩类型解压出最终的数据。Python 处理的过程如下：

unchunked = b''

pos = 0

chunkNumLen = data.find(b'\r\n', pos)-pos

//从第一个元素开始，发现第一个\r\n，计算length长度

chunkLen=int(data[pos:pos+chunkNumLen], 16)

//把length的长度转换成int

if chunkLen == 0:

break

//如果长度为0，则说明到结尾

chunk = data[pos+chunkNumLen+len('\r\n'):pos+chunkNumLen+len('\r\n')+chunkLen]

unchunked += chunk

//将压缩数据拼接

pos += chunkNumLen+len('\r\n')+chunkLen+len('\r\n')

//同时pos位置向后移动

return unchunked

//此时处理后unchunked就是普通的压缩数据，可以用zlib解压函数进行解压

实际中，我们会同时遇到既时chunked 又是压缩数据的响应，这个时候处理的思路应该是：先处理chunked，在处理压缩数据，顺序不能反。MultiPart 数据

MultiPart 的本质就是Post 请求，MultiPart出现在请求中，用来对一些文件（图片或文档）进行处理，在请求头中出现

Content-Type: multipart/form-data; boundary=::287032381131322 则表示为MultiPart 格式数据包，下面这个是multipart 数据包格式：

POST /cgi-bin/qtest HTTP/1.1

Host: aram

User-Agent: Mozilla/5.0 Gecko/2009042316 Firefox/3.0.10

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-us,en;q=0.5

https://www.wendangku.net/doc/a02141097.html,coding: gzip,deflate

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Keep-Alive: 300

Connection: keep-alive

Referer: http://aram/~martind/banner.htm

Content-Type: multipart/form-data; boundary=::287032381131322

Content-Length: 514

--::287032381131322

Content-Disposition: form-data; name="datafile1"; filename="r.gif"

Content-Type: image/gif

GIF87a.............,...........D..;

--::287032381131322

Content-Disposition: form-data; name="datafile2"; filename="g.gif"

GIF87a.............,...........D..;

--::287032381131322

Content-Disposition: form-data; name="datafile3"; filename="b.gif"

Content-Type: image/gif

GIF87a.............,...........D..;

--::287032381131322—

http 协议本身的原始方法不支持multipart/form-data 请求，那这个请求自然就是由这些原始的方法演变而来的，具体如何演变且看下文：

multipart/form-data 的基础方法是post，也就是说是由post 方法来组合实现的

multipart/form-data 与post 方法的不同之处：请求头，请求体。

multipart/form-data 的请求头必须包含一个特殊的头信息：Content-Type，且其值也必须规定为multipart/form-data，同时还需要规定一个内容分割符用于分割请求体中的多个post 内容，如文件内容和文本内容自然需要分割，不然接收方就无法正常解析和还原这个文件。具体的头信息如：Content-Type: multipart/form-data; boundary={bound} 代表分割符，可以任意规定，但为了避免和正常文本重复，尽量使用复杂一点的内容，如::287032381131322

multipart/form-data 的请求体也是一个字符串，不过和post 的请求体不同的是它的构造方式，post 是简单的name=value 值连接，而multipart/form-data 则是添加了分隔符等内容的构造体。

维基百科上关于

multipart 的介绍。

multipart 的数据格式有一定的特点，首先是头部规定了一个${bound}，上面那个例子中的${bound} 为

::287032381131322，由多个内容相同的块组成，每个块的格式以--加${bound} 开始的，然后是该部分内容的描述信息，然后一个\r\n，然后是描述信息的具体内容。如果传送的内容是一个文件的话，那么还会包含文件名信息，以及文件内容的类型。

小结，要发送一个multipart/form-data 的请求，需要定义一个自己的${bound} ，按照格式来发请求就好，对于multipart 的数据格式并没有过多介绍，感觉和chunked 很类似，不难理解。

http协议请求响应报文格式及状态码详解

HTTP协议报文格式 HTTP协议（Hypertext Transfer Protocol――超文本传输协议）浏览器端（客户端）向WEB 服务器端访问页面的过程和HTTP协议报文的格式。 基于HTTP协议的客户机访问包括4个过程，分别是建立TCP套接字连接、发送HTTP请求报文、接收HTTP应答报文和关闭TCP套接字连接： 1. 创建TCP套接字连接 客户端与WEB服务器创建TCP套接字连接，其中WEB端服务器的地址可以通过域名解析确定，WEB端的套接字侦听端口一般是80。 2. 发送HTTP请求报文 客户端向WEB服务端发送请求报文，HTTP协议的请求报文格式为： 请求消息= 请求行（实体头信息）CRLF[实体内容] 请求行= 方法URL HTTP版本号CRLF 方法= GET|HEAD|POST|扩展方法 URL = 协议名称＋宿主名＋目录与文件名 其中"CRLF"表示回车换行。 "请求行"中的"方法"描述了对指定资源执行的动作，常用的方法"GET"、"HEAD"和"POST"等3种，它们的含义如表15-8所示： 请求报文 一个HTTP请求报文由请求行（request line）、请求头部（header）、空行和请求数据4个部分组成，下图给出了请求报文的一般格式。 （1）请求行 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。例如，GET /index.html HTTP/1.1。 HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。这里介绍最常用的GET方法和POST方法。 GET：当客户端要从服务器中读取文档时，使用GET方法。GET方法要求服务器将URL定位的资源放在响应报文的数据部分，回送给客户端。使用GET方法时，请求参数和对应的值附加在URL后面，利用一个问号（“?”）代表URL的结尾 与请求参数的开始，传递参数长度受限制。例如，/index.jsp?id=100&op=bind。POST：当客户端给服务器提供信息较多时可以使用POST方法。POST方法将请求参数封装在HTTP请求数据中，以名称/值的形式出现，可以传输大量数据。 表15-8 HTTP请求方法

HTTP协议分析

HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下： 1.支持客户/服务器模式。 2.简单快速： 客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、H EAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 3.灵活： HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 4.无连接： 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 5.无状态： HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 一、HTTP协议（URL）

http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。 HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下： http: //host[": "port][abs_path] 二、HTTP协议的请求 http请求由三部分组成，分别是： 请求行、消息报头、请求正文 1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下： Method Request-URI HTTP-Version CRLF 其中Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）。 请求方法（所有方法全为大写）有多种，各个方法的解释如下： GET 请求获取Request-URI所标识的资源 POST 在Request-URI所标识的资源后附加新的数据 HEAD 请求获取由Request-URI所标识的资源的响应消息报头 PUT 请求服务器存储一个资源，并用Request-URI作为其标识

http协议数据包格式

竭诚为您提供优质文档/双击可除http协议数据包格式 篇一：数据包格式 tcp/ip协议族包括诸如internet协议(ip)、地址解析协议(aRp)、互联网控制信息协议(icmp)、用户数据报协议(udp)、传输控制协议(tcp)、路由信息协议(Rip)、telnet、简单邮件传输协议(smtp)、域名系统(dns)等协议。tcp/ip 协议的层次结构如图3所示。 图3tcp/ip协议层次结构 (1)应用层应用层包含一切与应用相关的功能，相当于osi的上面三层。我们经常使用的http、Ftp、telnet、smtp 等协议都在这一层实现。 (2)传输层传输层负责提供可靠的传输服务。该层相当于osi模型中的第4层。在该层中，典型的协议是 tcp(transmissioncontrolprotocol)和 udp(userdatagramprotocol)。其中，tcp提供可靠、有序的，面向连接的通信服务；而udp则提供无连接的、不可靠用户数据报服务。 (3)网际层网际层负责网络间的寻址和数据传输，其功

能大致相当于osi模型中的第3层。在该层中，典型的协议是ip(internetprotocol)。 (4)网络接口层最下面一层是网络接口层，负责数据的实际传输，相当于osi模型中的第1、第2层。在tcp/ip协议族中，对该层很少具体定义。大多数情况下，它依赖现有的协议传输数据。 tcp/ip与osi最大的不同在于osi是一个理论上的网络通信模型，而tcp/ip则是实际运行的网络协议。tcp/ip实际上是由许多协议组成的协议簇。图4示出tcp/ip的主要协议分类情况。 整个过程： 1.dhcp请求ip地址的过程 l发现阶段，即dhcp客户端寻找dhcp服务器的阶段。客户端以广播方式发送dhcpdiscoVeR包，只有dhcp服务器才会响应。 l提供阶段，即dhcp服务器提供ip地址的阶段。dhcp 服务器 接收到客户端的dhcpdiscoVeR报文后，从ip地址池中选择一个尚未分配的ip地址分配给客户端，向该客户端发送包含租借的ip地址和其他配置信息的dhcpoFFeR包。 l选择阶段，即dhcp客户端选择ip地址的阶段。如果有多台dhcp服务器向该客户端发送

http协议分析报告实例

HTTP协议分析 1 实验目的 分析HTTP协议报文首部格式，理解HTTP协议工作过程 2 实验内容 截获HTTP报文，分析HTTP协议报文首部格式，学习HTTP协议工作过程。 3 实验原理 超文本传送协议HTTP（HyperText Transfer Protocol）,是万维网客户程序与万维网服务器程序之间的交互所要严格遵守的协议。HTTP是一个应用层协议，它使用TCP连接进行可靠的传送。对于万维网站点的访问要使用的HTTP协议。 HTTP的URL的一般形式是： http://<主机>:<端口>/<路径> WWW采用 B/S 结构，客户使用浏览器在 URL栏中输入 HTTP 请求，即输入对方服务器的地址，向 web 服务器提出请求。如访问师院的机构设置页面 https://www.wendangku.net/doc/a02141097.html,/jigou/gljg.htm，具体的工作过程如下： (1) 浏览器分析指向页面的URL. (2) 浏览器向DNS请求解析https://www.wendangku.net/doc/a02141097.html,的IP地址。 (3) 域名系统DNS解析出师院服务器的IP地址 (4) 浏览器与服务器建立TCP连接 (5) 浏览器发出取文件命令：GET /jigou/gljg.htm. (6) 服务器https://www.wendangku.net/doc/a02141097.html,给出响应，将文件 gljg.htm发送给浏览器。 (7) TCP连接释放。 (8) 浏览器显示“北航机构设置”的页面。 服务器提供的默认端口号为80. 4 实验步骤 步骤 1 在计算机上打开wireshark软件，进行报文截获。 步骤 2 从浏览器上访问https://www.wendangku.net/doc/a02141097.html,页面，具体操作为打开网页，浏览，关掉网页。 步骤 3 停止wireshark的报文截获，结果命名为http_学号，保存在本机或上 传至服务器目录下。

1、HTTP协议分析

开放式课题 实验报告 实验名称：基于Wireshark软件的HTTP协议分析 学号： 姓名： 指导教师：宫婧 指导单位：理学院

目录 实验目的..........................................................错误！未定义书签。 1) 掌握Wireshark软件使用方法............. 错误！未定义书签。 2）理解HTTP协议工作原理..................................... 错误！未定义书签。 实验任务.................................... 错误！未定义书签。 1) 抓取数据包........................... 错误！未定义书签。 2）分析数据包........................... 错误！未定义书签。实验环境.............................. 错误！未定义书签。软件介绍 (2) 1） wireshark软件简介 (2) 2） wireshark软件的应用 (2) 3） wireshark软件的价值 (2) 4） wireshark软件的操作简介 (3) HTTP协议详解............................... 错误！未定义书签。 1） HTTP协议基础概念....................... 错误！未定义书签。 2） HTTP协议工作流程....................... 错误！未定义书签。 3） HTTP协议请求响应信息 (6) HTTP请求报文信息．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．６ HTTP响应报文信息．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．．７HTTP数据包分析 (8) 1）网络接口层信息 (10) 2）网络层信息 (11) 3）传输层信息 (12) 4）应用层信息 (13) 总结........................................ 错误！未定义书签。参考文献.. (14)

HTTP协议报头信息详解

对HTTP协议的头信息详解 HTTP（HyperTextTransferProtocol）是超文本传输协议的缩写，它用于传送WWW 方式的数据，关于HTTP 协议的详细内容请参考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求，请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应，相应的内容包括消息协议的版本，成功或者错误编码加上包含服务器信息、实体元信息以及可能的实体内容。 通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个只是头域结束的空行和可选的消息体组成。HTTP的头域包括通用头，请求头，响应头和实体头四个部分。每个头域由一个域名，冒号（:）和域值三部分组成。域名是大小写无关的，域值前可以添加任何数量的空格符，头域可以被扩展为多行，在每行开始处，使用至少一个空格或制表符。 通用头域 通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。 Cache-Control头域 Cache -Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached，响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下： Public指示响应可被任何缓存区缓存。 Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。 no-cache指示请求或响应消息不能缓存 no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。 max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。 min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。 max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。 Date头域

HTTP 协议分析实验

实验六HTTP 协议分析实验 一、实验目的 在PC 机上访问RCMS 的Web 页面，截获报文，分析HTTP 协议的报文格式和HTTP 协议的工作过程。 二、实验设备和连接 本地实验室环境，无须设备连接； 注意：请通过访问可以连接的WWW 站点或使用IIS 建立本地WWW 服务器来进行实验。 三、实验步骤 步骤1：在PC 机上运行Ethereal，开始截获报文，为了只截获和我们要访问的网站相关的数据报，将截获条件设置为“not broadcast and not multicast”； 步骤2：从浏览器上访问Web 界面，如http://202.202.43.125。打开网页，待浏览器的状态栏出现“完毕”信息后关闭网页。 步骤3：停止截获报文，将截获的报文命名为http-学号保存。 分析截获的报文，回答以下几个问题： 1）综合分析截获的报文，查看有几种HTTP 报文？ 有两种报文

一种是从客户到服务器的请求报文 另一种是从服务器到客户的响应报文 2）在截获的HTTP 报文中，任选一个HTTP 请求报文和对应的HTTP 应答报文，仔细 分析它们的格式，填写表20 和表 5.21。

表20 HTTP 请求报文格式

表21 HTTP 应答报文格式 3）分析在截获的报文中，客户机与服务器建立了几个连接？服

务器和客户机分别使用 了哪几个端口号？ __________________________________________________________ _________________ __________________________________________________________ _____________________ __________________________________________________________ _____________________ 4 ）综合分析截获的报文，理解HTTP 协议的工作过程，将结果填入表22 中。 表22 HTTP 协议工作过程

http协议包含哪些组成部分

竭诚为您提供优质文档/双击可除http协议包含哪些组成部分 篇一：http协议整理 简介：http协议 http协议是用于从www服务器传输超文本到本地浏览器的传送协议。http协议由请求和响应构成，是一个标准的客户端服务器模型。tcp协议之上的应用层协议。默认http的端口号为80。 http协议都是客户端发起请求，服务器回送响应。见下图 http是一个基于请求与响应模式的、无状态的、应用层的协议，同一个客户户端的这次请求和上次请求是没有对应关系。 介绍uRl： httpuRl的格式如下：要通过http协议来定位网络资源；host表示合法的internet主机域名或者ip地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的uRi；如果uRl中没有给出abs_path，那么当它作为请求uRi时，必须以“/”的形式给出，通常这个工作浏

览器自动帮我们完成。 http协议请求 请求由三部分组成，分别是：请求行、消息报头、请求正文 请求行以一个方法符号开头，以空格分开，后面跟着请求的uRi和协议的版本，格式如下： methodRequest-uRihttp-Version 其中method表示请求方法；Request-uRi是一个统一资源标识符；http-Version表示请求的http协议版本请求方法： get请求获取Request-uRi所标识的资源 post在Request-uRi所标识的资源后附加新的数据 head请求获取由Request-uRi所标识的资源的响应消息报头 put请求服务器存储一个资源，并用Request-uRi作为其标识 delete请求服务器删除Request-uRi所标识的资源 tRace请求服务器回送收到的请求信息，主要用于测试或诊断 connect保留将来使用 options请求查询服务器的性能，或者查询与资源相关的选项和需求

实验七-HTTP协议分析实验报告

北京理工大学珠海学院实验报告 ZHUHAI CAMPAUS OF BEIJING INSTITUTE OF TECHNOLOGY 班级：学号：姓名：指导教师：成绩 实验题目：HTTP协议分析实验时间： 一、实验目的： 掌握HTTP协议首部种类、格式、主要字段的含义。 二、实验内容及步骤： 1.实验内容： 用科莱网络分析系统捕获HTTP报文段，观察几种常用HTTP报文段的格式和主要字段的含义。2实验步骤： （１）实验准备 打开浏览器，清空缓存，打开可来网络分析系统，开始捕获数据包，在浏览器地址栏输入https://www.wendangku.net/doc/a02141097.html,，页面显示完成后，停止捕获。 （２）观察HTTP报文 观察捕获到的HTTP报文中的HTTP请求和HTTP应答报文。 （３）记录在HTTP请求报文和相应报文中个字段的名成个个字段的值，说明每个字段的含义。 三、实验结果 上图是实验请求报文。

上图是HTTP的响应报文。 三、思考与讨论 1、通过实验和检查资料，写出HTTP协议的请求报文和响应报文都包括哪些字段？各个字段 的含义和作用是什么？ 答：一个HTTP请求报文由请求行首部和实体主体3个部分组成： （1）请求行请求 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成，它们用空格分隔。 （2）首部行 由关键字/值对组成，每行一对，关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息，典型的请求头有： User-Agent：产生请求的浏览器类型。 Accept：客户端可识别的内容类型列表。 Host：请求的主机名，允许多个域名同处一个IP地址，即虚拟主机。 首部行结束时，还有一行空行将首部行和后面的实体主体分开 （3）实体主体 实体主体不在GET方法中使用，而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type和Content-Length. HTTP响应报文：HTTP响应报文也由三个部分组成，分别是：状态行、首部行和实体主体3个部分组成： 状态行格式如下： HTTP-Version Status-Code Reason-Phrase CRLF 其中，H T T P-V e r s i o n表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码；Reason-Phrase表示状态代码的文本描述。状态代码由三位数字组成，第一个数字定义了响应的类别，且有五种可能取值。 1xx：指示信息表示请求已接收，继续处理。 2xx：成功--表示请求已被成功接收、理解、接受。 3xx：重定向--要完成请求必须进行更进一步的操作。 4xx：客户端错误--请求有语法错误或请求无法实现。 5xx：服务器端错误--服务器未能实现合法的请求。 2、在捕获的HTTP请求报文和响应报文中，显示的HTTP版本号是多少？

http协议数据包的结构

竭诚为您提供优质文档/双击可除http协议数据包的结构 篇一：tcp-ip数据包结构详解 一般来说，网络编程我们只需要调用一些封装好的函数或者组件就能完成大部分的工作，但是一些特殊的情况下，就需要深入的理解 网络数据包的结构，以及协议分析。如：网络监控，故障排查等…… ip包是不安全的，但是它是互联网的基础，在各方面都有广泛的应用。由ip协议衍生的协议族有10数种（据我所知），以后还会出现 更多的基于ip的协议… 先从实际出发吧！ 一般我们在谈上网速度的时候，专业上用带宽来描述，其实无论说网速或者带宽都是不准确的，呵呵。比如：1兆，512k…… 有些在学校的学生，也许会有疑问，明明我的业务是1m，为什么下载速度到100k就飙不上去了？512k的为什么50多k就封顶了？…

这里所说的1m是指1mbps=1millionbitspersecond，也就是1m比特每秒，即一秒钟传输1048576个二进制位。我们知道一个字节 是8个二进制位。 好，又来问题了。即便这样子，1m=1048756÷8=131072÷1024=128k。那也应该有128k啊，为什么下载速度还是很少到120k， 110k都谢天谢地了。看完本文，你的帐就对了…… ip数据包结构： 如图，一个刻度表示1个二进制位（比特）。 1-1.版本4位，表示版本号，目前最广泛的是4=b1000，即常说的ipv4；相信ipv6以后会广泛应用，它能给世界上每个纽扣都分配 一个ip地址。 1-2.头长4位，数据包头部长度。它表示数据包头部包括多少个32位长整型，也就是多少个4字节的数据。无选项则为5（红色部分）。 1-3.服务类型，包括8个二进制位，每个位的意义如下：过程字段：3位，设置了数据包的重要性，取值越大数据越重要，取值范围为：0（正常）~7（网络控制）延迟字段：1位，取值：0（正常）、1（期特低的延迟）流量字段：1位，取值：0（正常）、1（期特高的流量）

HTTP是一个属于应用层的面向对象的协议

年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下： 1.支持客户/服务器模式。 2.简单快速： 客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、H EAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 3.灵活： HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 4.无连接： 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 5.无状态： HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 一、HTTP协议详解之URL篇

http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。 HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下： http: //host[": "port][abs_path] eg: 1、输入： 浏览器自动转换成： http: 2、http:192.168.0.100:80/index.jsp 二、HTTP协议详解之请求篇 http请求由三部分组成，分别是： 请求行、消息报头、请求正文 1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下： Method Request-URI HTTP-Version CRLF

http协议(二)请求和响应报文的构成

http协议（二）请求和响应报文的构成 http协议用于客户端和服务器之间的通信，请求访问资源的一方称为客户端，而提供资源响应的一方称为服务器端。 下面就是客户端和服务端之间简单的通信过程 PS：请求必须从客户端建立通信，服务端没收到请求之前不会发送响应 下面先来说说请求的构成： 1）请求方法URI协议/版本 2）请求头(Request Header) 3）请求正文 下面是一个请求的例子： GET/sample.jspHTTP/1.1 Accept:image/gif.image/jpeg,*/* Accept-Language:zh-cn Connection:Keep-Alive Host:localhost User-Agent:Mozila/4.0(compatible;MSIE5.01;Window NT5.0) Accept-Encoding:gzip,deflate username=jinqiao&password=1234 1）请求方法URI协议/版本 以上请求中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。 根据HTTP标准，HTTP请求可以使用多种请求方法。具体的方法以及区别后面我们介绍。 2）请求头 Accept 可接受的内容类型 Accept-Language 语言 Connection连接状态 Host 请求的域名（这里我设置的是请求本地，当然，关于域名，就是所谓的URL） User-Agent 浏览器端浏览器型号和版本 Accept-Encoding 可接受的压缩类型 gzip,deflate 3）请求正文 请求头和请求正文之间是一个空行，它表示请求头已经结束，接下来的是请求正文。请求正文中可以包含客户提交的查询字符串信息： username=jinqiao&password=1234 在以上的例子中，请求的正文只有一行内容。当然，在实际应用中，HTTP请求正文可以包含更多的内容。

HTTP协议分析实验

HTTP协议分析实验报告 专业：计算机信息工程学院12级网络工程2班 学号：1208066057 学生姓名：汪国庆 一、实验目的： 1.分析http请求报文的含义和响应报文的含义。 2.知道http1.1和http1.0的异同。 3.通过http协议获取网页流程。 二、实验原理：（参考自互联网） RFC 1945定义了HTTP/1.0版本。RFC 2616定义了今天普遍使用的一个版本——HTTP 1.1。 HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。 HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。 HTTP协议永远都是客户端发起请求，服务器回送响应。见下图： 这样就限制了使用HTTP协议，无法实现在客户端没有发起请求的时候，服务器将消息推送给客户端。 HTTP协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。 一次HTTP操作称为一个事务，其工作过程可分为四步： 1）首先客户机与服务器需要建立连接。只要单击某个超级链接，HTTP的工作开始。

2）建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。 3）服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 4）客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。 如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，有显示屏输出。对于用户来说，这些过程是由HTTP自己完成的，用户只要用鼠标点击，等待信息显示就可以了。 三、实验步骤 1、打开Wireshark，选择工具栏上的“Capture”->“interfaces选择网关”，如图： 2、然后在Wireshark，选择工具栏上的“Capture”->“optoins”选择过滤器，并在capture filter 中输入tcp port 80(表示要抓http的包)，如图

http协议(三)几种数据传输方式

http协议（三）几种数据传输方式 说说http协议的一些特点： 1）无状态 http协议是一种自身不对请求和响应之间的通信状态进行保存的协议，即无状态协议。 这种设置的好处是：更快的处理更多的请求事务，确保协议的可伸缩性 不过随着web的不断发展，有时候，需要将这种状态进行保持，随即，就引入了cookie 技术，cookie技术通过在请求和响应报文中写入cookie信息来控制客户端的状态。 有关cookie的内容后面我们再说。。。 2）持久性 正常在发送http时，都需要建立TCP的连接，再发送报文。 如果每次想要发送http报文都需要经过这个过程，那么时间大部分都会消耗在建立和断开连接的过程中。 因此http中使用了connection属性，用于指定连接的方式。 当设置成keep-alive，http就会建立一条持久化的连接，不需要每次都建立连接，再中断。 这样做的好处是：减轻了服务器端的负载，减少开销的那部分时间，使http请求和响应都能更快的结束，相应的，web页面显示速度也就相对提升了。 3）管线化 如果一个http请求，请求了大量的图片等大文件，那么其他的http请求怎么办呢？ 现在，管线化技术的出现，使得http请求比持久性连接更要快；特点在于：请求数越多，时间差越明显。 4）内容编码 由于某些报文的内容过大，因此在传输时，为了减少传输的时间，会采取一些压缩的措施。例如上面的报文信息中，Accept-Encoding就定义了内容编码的格式：gzip 有下面几种方式： gzip：GNU压缩格式 compress：UNIX系统的标准压缩格式 deflate：是一种同时使用了LZ77和哈弗曼编码的无损压缩格式 identity：不进行压缩 5）多部分对象集合

HTTP协议解析-协议结构和HTTP头

Web之http协议（三） 一、http报文首部 http协议中请求报文和响应报文都包括了http首部，这个首部是服务器和客户端处理请求和响应提供所需的信息，是客户端与服务器交互的基础。 http的请求报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成。 http的响应报文由HTTP 版本、状态码（数字和原因短语）、HTTP 首部字段3 部分构成。 在报文众多的字段当中，HTTP 首部字段包含的信息最为丰富。首部字段同时存在于请求和响应报文内，并涵盖HTTP 报文相关的内容信息。 二、HTTP 首部字段 http首部字段是http报文的构成因素之一，它是客户端与服务器端进行通信的标准。客户端使用http首部说明需要的报文主体大小，所使用的语言，认证信息等。服务器端则使用首部告诉客户端，返回的报文主体是什么东西，报文主体的大小等信息。可以说首部字段是十分重要。 1.首部字段的结构 首部字段的结构，通常的情况是由首部字段跟首部字段的值组成。例如：

Content-Type:text\html,也就是首部字段：首部字段值这样子的结构。 另外如果首部字段有多个值是则用都好隔开。例如：Keep-Alive：timeout=15，max=100 2.首部字段的类型 HTTP 首部字段根据实际用途被分为以下4 种类型。 通用首部字段（General Header Fields） 请求报文和响应报文两方都会使用的首部。 请求首部字段（Request Header Fields） 从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。 响应首部字段（Response Header Fields） 从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容，也会要求客户端附加额外的内容信息。 实体首部字段（Entity Header Fields） 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。 通用首部字段 首部字段名称说明 Cache-Control 控制缓存的行为 Connection 逐跳首部、链接的管理 Date 报文的创建日期时间 Pragma 报文指令 Trailer 报文末端的首部一览 Transfer-Encoding 指定报文主体的传输编码方式 Upgrade 升级为其他协议 Via 代理服务器的相关信息 Warning 错误通知 请求首部字段 首部字段名说明 Accept 用户代理可处理的媒体类型 Accept-Charset 优先的字符集 Accept-Encoding 优先的内容编码 Accept-Language 优先的语言（自然语言） Authorization Web认证信息 Expect 期待服务器的特定行为 From 用户的电子邮箱地址 Host 请求资源所在服务器 If-Match 比较实体标记（ETag） If-Modified-Since 比较资源的更新时间 If-None-Match 比较实体标记（与If-Match 相反） If-Range 资源未更新时发送实体Byte 的范围请求 If-Unmodified-Since 比较资源的更新时间（与If-Modified-Since相反）

HTTP协议详解

HTTP协议详解 引言 HTTP是一个属于应用层的面向对象的协议，由于其简捷、快速的方式，适用于分布式超媒体信息系统。它于1990年提出，经过几年的使用与发展，得到不断地完善和扩展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的规范化工作正在进行之中，而且HTTP-NG(Next Generation of HTTP)的建议已经提出。 HTTP协议的主要特点可概括如下： 1.支持客户/服务器模式。 2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。 3.灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。 4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。 5.无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。 一、HTTP协议详解之URL篇 http（超文本传输协议）是一个基于请求与响应模式的、无状态的、应用层的协议，常基于TCP的连接方式，HTTP1.1版本中给出一种持续连接的机制，绝大多数的Web开发，都是构建在HTTP协议之上的Web应用。 HTTP URL (URL是一种特殊类型的URI，包含了用于查找某个资源的足够的信息)的格式如下： http://host[":"port][abs_path] http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI 时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。 eg: 1、输入：https://www.wendangku.net/doc/a02141097.html, 浏览器自动转换成：https://www.wendangku.net/doc/a02141097.html,/ 2、http:192.168.0.116:8080/index.jsp 二、HTTP协议详解之请求篇 http请求由三部分组成，分别是：请求行、消息报头、请求正文 1、请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版