HTTP请求和MIME介绍
HTTP请求和MIME介绍
HTTP请求由三部分组成，分别是：
请求行，消息报头，请求正文。
请求行(格式)：
Method Request-URI HTTP-Version CRLF
Method:方法。
GET 请求获取由Request-URI所标识的资源。POST 在Request-URI所标识的资源后附加新的数据。HEAD 请求获取由Request-URI所标识的资源的响应消息报头。
PUT 请求服务器存储一个资源，并用Request-URI作为其标识。
DELETE 请求服务器删除由Request-URI所标识的资源。TRACE 请求服务器回送收到的请求信息，主要用语测试或诊断。
CONNECT 保留将来使用。
OPTIONS 请求查询服务器的性能，或查询与资源相关的选项和需求。
Request-URI:统一资源标识。
HTTP-Version：HTTP的版本。
CRLF：回车换行。(\r\n)
例：
GET /form.html HTTP/1.1 \r\n
HTTP响应
在接收和解释请求消息后，服务器会返回一个HTTP响应消息。
与HTTP请求类似，HTTP响应也是三个部分组成，分别是：状态行、消息报头、响应正文。
状态行：
状态行由协议版本、数字形式的状态代码、及相应的状态描述，各元素之间以空格分隔。
格式: HTTP-Version Status-Code Reason-Phrase CRLF
例如: HTTP/1.1 200 OK \r\n
状态代码：
状态代码由3位数字组成，表示请求是否被理解或被满足。状态描述：
状态描述给出了关于状态代码的简短的文字描述。
状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。
第一个数字有五种可能的取值：
- 1xx: 指示信息—表示请求已接收，继续处理。
- 2xx: 成功—表示请求已经被成功接收、理解、接受。- 3xx: 重定向—要完成请求必须进行更进一步的操作。- 4xx: 客户端错误—请求有语法错误或请求无法实现。- 5xx: 服务器端错误—服务器未能实现合法的请求。
状态代码状态描述说明
200 OK 客户端请求成功
400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
401 Unauthonzed 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因404 Not Found 请求的资源不存在，例如，输入了错误的URL。
500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。
503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。HTTP消息
HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行，消息报头(可选
的)，空行(只有CTLF的行)，消息正文(可选的)组成。
对于请求消息，开始行就是请求行。
对于响应消息，开始行就是状态行。
消息报头
HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。
每一个报头域都是由(名字＋":"＋空格＋值)组成,消息报头域的名字是大小写无关的。
普通报头：
在普通报头中，有少数报头域应用于所有的请求和响应消息，但并不用于被传输的实体，这些报头域只用于传输的消息。
常用的普通报头域：Cache-Control,Date,Connection,Pragma. 请求报头：
请求报头允许客户端向服务器端传递该请求的附加信息以及客户端自身的信息。
常用的请求报头域：
Accept
Accept请求报头域用语指定客户端接受哪些类型的信息。例如：Accept: image/gif,表明客户端希望接受GIF图象格式的资源；Accept: text/html,表明客户端希望接受html 文本。
Accept-Charset
Accept-Charset请求报头域用于指定客户端接受的字符集。例如：Accept-Charset: ios-8859-1,gb2312。如果在请求消息中没有设置这个域，缺省是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding请求报头域类似Accept，但是它是用于指定可接受的内容编码。例如：Accept-Encoding:
gzip,deflate。如果请求消息中没有设置这个域，服务器假定客户端对各种内容编码都可接受。
Accept-Language
Accept-Language请求报头域类似于Accept,但是它是用于指定一种自然语言。例如：Accept-Language: zh-cn。如果请求消息中没有设置这个域，服务器假定客户端对各种语言都可接受。
Authorization
Authorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401(未授权)，可以发送一个包含Authorization 请求报头域的请求，要服务器对其进行验证。
Host
Host请求报头域主要用于指定被请求资源的Internet 主机和端口号，它通常是从HTTP URL中提取出来的。
例如:https://www.doczj.com/doc/397737156.html,/index.html。浏览器发送的请求消息中，就会包含Host请求报头域，如下：Host: https://www.doczj.com/doc/397737156.html, 后面没有跟端口号，表明使用的是缺省端口号80，如果端口号不是80，那么就要在主机名后面加上一个冒号(":"),然后接上端口号，例如：
Host: https://www.doczj.com/doc/397737156.html,:8080。要注意的是，在发送HTTP 请求的时候，这个报头域是必须的。
User-Agent
User-Agent允许客户端将它的操作系统浏览器和其他属性告诉服务器。我们上网登陆论坛的时候，往往看到些欢迎信息，其中列出了你的操作系统的名称和版本等等信息。原因是：服务器从User-Agent请求报头域中获取的这些信息，自己编写浏览器可以不用这个请求报头域。服务器就无法得知了。
响应报头
响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。
常用的响应报头域：
Location
Location响应报头域用于重定向接受者到一个新的位
置。例如：客户端所请求的页面已不存在原先的位置，为了让客户端重定向到这个页面新的位置，服务器端可以发回Location响应报头后使用重定向语句，让客户端去访问新的域名所对应的服务器上的资源。当我们在JSP中使用重定向语句的时候，服务器端向客户端发回的响应报头中，就会有Location响应报头域。
Server
Server响应报头域包含了服务器用来处理请求的软件信息。它和User-Agent请求报头域是相对应的，前者发送服务器端软件的信息，后者发送客户端软件(浏览器)和操作系统的信息。下面是Server响应报头域的一个例子：Server: Apache-Coyote/1.1
WWW-Authenticate
WWW-Authenticate响应报头域必须被包含在401(未授权的)响应消息中，这个报头域和前面讲到的Authorization 请求报头域是相关的，当客户端收到401响应消息，就要决定是否请求服务器对其进行验证。如果要求服务器对其进行验证，就可以发送一个包含了Authorization报头域的请求，下面是WWW-Authenticate响应报头域的一个例子：WWW-Authenticate: Basic realm="Basic Auth Test!"
从这个响应报头域，可以知道服务器端对我们所请求的资源采用的是基本验证机制。
实体报头
请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，大多数情况下，实体正文就是请求消息中的请求正文或者响应消息中的响应正文。但是在发送时，并不是说实体报头域和实体正文要在一起发送，例如：有些响应可以只包含实体报头域。实体就好象我们写的书信，在信中，我们可以写上标题，加上页号等，这部分就相当于是实体报头域，而我们所写的书信的内容，就相当于实体正文。前面说讲的普通报头、请求报头、响应报头我们可以看成是写在信封上的邮编、接收者，发送者等内容。实体报头定义了关于实体正文(例如：有无实体正文)和请求所标识的资源的元信息。
所谓元信息，是指描述其他信息的信息。
常用的实体报头域：
Content-Encoding
Content-Encoding实体报头域被使用作媒体类型的
修饰符，它的值指示了已经被应用到实体正文的附加内容编码，因而要获得Content- Type报头域中所引用的媒体类型，必须采用相应的解码机制。Content-Encoding主要用语记录文档的压缩方法，下面是它的一个例子：Content-Encoding:
gzip。如果一个实体正文采用了编码方式存储，在使用之前就必须进行解码。
Content-Language
Content-Language实体报头域描述了资源所用的自
然语言。Content-Language允许用户遵照自身的首选语言来识别和区分实体。如果这个实体内容仅仅打算提供给丹麦的阅读者，那么可以按照如下的方式设置这个实体报头域：Content-Language: da。
如果没有指定Content-Language报头域，那么实体内容将提供给所以语言的阅读者。
Content-Length
Content-Length实体报头域用于指明正文的长度，以字节方式存储的十进制数字来表示，也就是一个数字字符占一个字节，用其对应的ASCII码存储传输。
要注意的是：这个长度仅仅是表示实体正文的长度，没有包括实体报头的长度。
Content-Type
Content-Type实体报头域用语指明发送给接收者的
实体正文的媒体类型。例如：
Content-Type: text/html;charset=ISO-8859-1
Content-Type: text/html;charset=GB2312
Last-Modified
Last-Modified实体报头域用于指示资源最后的修改日期及时间。
Expires
Expires实体报头域给出响应过期的日期和时间。通常，代理服务器或浏览器会缓存一些页面。当用户再次访问这些页面时，直接从缓存中加载并显示给用户，这样缩短了响应的时间，减少服务器的负载。为了让代理服务器或浏览器在一段时间后更新页面，我们可以使用Expires实体报头域指定页面过期的时间。当用户又一次访问页面时，如果Expires报头域给出的日期和时间比Date普通报头域给出的日期和时间要早(或相同)，那么代理服务器或浏览器就不会再使用缓存的页面而是从服务器上请求更新的页面。不过要注意，即使页面过期了，也并不意味着服务器上的原始资源在此时间之前或之后发生了改变。
Expires实体报头域使用的日期和时间必须是RFC 1123中的日期格式，例如：
Expires: Thu, 15 Sep 2005 16:00:00 GMT
HTTP1.1的客户端和缓存必须将其他非法的日期格式(也包括0)看作已过期。例如，为了让浏览器不要缓存页面，我们也可以利用Expires实体报头域，设置它的值为0，如下(JSP)：response.setDateHeader("Expires",0);
什么是MIME
MIME, 全称为“Multipurpose Internet Mail Extensions”, 比较确切的中文名称为“多用途
互联网邮件扩展”。它是当前广泛应用的一种电子邮件技术规范，基本内容定义于RFC 2045-2049
什么是MIME类型?-在把输出结果传送到浏览器上的时候，浏览器必须启动适当的应用程序来处理这个输出文档。这可以通过多种类型MIME（多功能网际邮件扩充协议）来完成。在HTTP中，MIME类型被定义在Content-Type header中。例如，架设你要传送一个Microsoft Excel文件到客户端。那么这时的MIME类型就是
“application/vnd.ms-excel”。在大多数实际情况中，这个文件然后将传送给Execl来处理（假设我们设定Execl为处理特殊MIME类型的应用程序）。在ASP中，设定MIME类型的方法是通过Response对象的ContentType 属性。
多媒体文件格式MIME
最早的HTTP协议中，并没有附加的数据类型信息，所有传送的数据都被客户程序解释为超文本标记语言HTML 文档，而为了支持多媒体数据类型，HTTP协议中就使用了附加在文档之前的MIME数据类型信息来标识数据类型。
MIME意为多目Internet邮件扩展，它设计的最初目的是为了在发送电子邮件时附加多媒体数据，让邮件客户程序能根
据其类型进行处理。然而当它被HTTP协议支持之后，它的意义就更为显著了。它使得HTTP传输的不仅是普通的文本，而变得丰富多彩。
每个MIME类型由两部分组成，前面是数据的大类别，例如声音audio、图象image等，后面定义具体的种类。
常见的MIME类型
超文本标记语言文本.html,.html text/html
普通文本.txt text/plain
RTF文本.rtf application/rtf
GIF图形.gif image/gif
JPEG图形.ipeg,.jpg image/jpeg
au声音文件.au audio/basic
MIDI音乐文件mid,.midi audio/midi,audio/x-midi RealAudio音乐文件.ra, .ram audio/x-pn-realaudio
MPEG文件.mpg,.mpeg video/mpeg
A VI文件.avi video/x-msvideo
GZIP文件.gz application/x-gzip
TAR文件.tar application/x-tar
Internet 中有一个专门组织IANA来确认标准的MIME类型，但Internet发展的太快，很多应用程序等不及IANA来确认他们使用的MIME类型为标准类型。因此他们使用在类别中以x-开头的方法标识这个类别还没有成为标准，例如：
x-gzip，x-tar等。事实上这些类型运用的很广泛，已经成为了事实标准。只要客户机和服务器共同承认这个MIME类型，即使它是不标准的类型也没有关系，客户程序就能根据MIME类型，采用具体的处理手段来处理数据。而Web服务器和浏览器（包括操作系统）中，缺省都设置了标准的和常见的MIME类型，只有对于不常见的MIME类型，才需要同时设置服务器和客户浏览器，以进行识别。
由于MIME类型与文档的后缀相关，因此服务器使用文档的后缀来区分不同文件的MIME类型，服务器中必须定义文档后缀和MIME类型之间的对应关系。而客户程序从服务器上接收数据的时候，它只是从服务器接受数据流，并不了解文档的名字，因此服务器必须使用附加信息来告诉客户程序数据的MIME类型。服务器在发送真正的数据之前，就要先发送标志数据的MIME类型的信息，这个信息使用Content-type关键字进行定义，例如对于HTML文档，服务器将首先发送以下两行MIME标识信息,这个标识并不是真正的数据文件的一部分。
Content-type: text/html
注意，第二行为一个空行，这是必须的，使用这个空行的目的是将MIME信息与真正的数据内容分隔开。
****************************************************************** ******************************************************************* Windows操作系统中的IIS负责提供互联网服务，一台运行了IIS的计算机可以看成是一台Web服务器。 Windows XP SP2 中IIS主版本号为5，Windows 2003 Server为6，Vista和Windows Server 2008为7。对于Windows 2003 Server，其默认支持的https://www.doczj.com/doc/397737156.html,版本为1.1，因此必须单独安装.NET Framework 2.0以上版本[1]。 目前，IIS 6是使用最为广泛的版本，IIS 5已基本不在Web服务器上部署， IIS 6与IIS 5相比在系统架构上有着较大的差异，IIS 7与IIS 6相比，基本架构并没有根本性的变化，但在许多方面有新的增强和改进。本书选择IIS 6/7进行介绍，大部分内容也适合于IIS 5，但IIS 5一些已过时的特性就不介绍了。 首先，我们来仔细分辨一下三个很容易混淆的基本概念。 8.1.1网站、Web应用程序和虚拟目录 在IIS中可以创建网站、Web 应用程序和虚拟目录，以便与计算机网络上的用户共享信息。“网站”、“Web 应用程序”和“虚拟目录”这三个概念的关系如图 8?1所示。 图 8?1 网站，应用程序与虚拟目录 简而言之，一个“网站（Web Site）”包含一个或多个“ Web 应用程序（Web Application）”，一个Web 应用程序包含一个或多个“虚拟目录（Virtual Directory）”，而虚拟目录则映射到 Web 服务器或远程计算机上的物理目录。 图 8?2所示为运行IIS 7的一个Web服务器。 图 8?2 IIS 7中的网站，应用程序与虚拟目录 图 8?2中可以清楚地看到此Web服务器上有两个“网站”：Default Web Site和NewWebSite，其中Default Web Site网站中有三个“Web 应用程序”：HappyBookShopService、HappyBookShopWebSite和OnlineAlbum。而HappyBookShopWebSite应用程序下的每一个子文件夹都是一个“虚拟目录”。最顶层的虚拟目录称为“根虚拟目录”，图8?2中Web应用程序HappyBookShopWebSite的根虚拟目录为“/HappyBookShopWebSite”。
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头字段包括4类： general-header ; request-header ; response-header ; entity-header . ********************************************************************* ********** General Header Fields ============================= general header是request、response都可用的, 但是不能用于entity. －－Cache-Control －－Connection －－Date －－Pragma －－Trailer －－Transfer-Encoding －－Upgrade －－Via －－Warning ********************************************************************* ********** Request Header Fields ====================== request-header fields 允许客户端传递关于request和客户端的附加信息到服务端， －－Accept －－Accept-Charset －－Accept-Encoding －－Accept-Language －－Authorization －－Expect －－From －－Host －－If-Match －－If-Modified-Since －－If-None-Match －－If-Range －－If-Unmodified-Since
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是Web协议集中的重要协议，它是从客户机/服务器模型发展起来的。客户机/服务器是运行一对 相互通信的程序，客户与服务器连接时，首先，向服务器提出请求，服务器根据客户的请求，完成处理 并给出响应。浏览器就是与Web服务器产生连接的客户端程序，它的端口为TCP的80端口，。浏览器 与Web 服务器之间所遵循的协议就是HTTP。 HTTP的早期版本为HTTP/0.9，它适用于各种数据信息的简洁快速协议，但是其远不能满足日益发展各 种应用的需要。但HTTP/0.9作为HTTP协议具有典型的无状态性：每个事务都是独立进行处理的，当 一个事务开始就在客户与服务器之间建立一个连接，当事务结束时就释放这个连接。HTTP/0.9包含Simple-Request&Simple-Responsed的报文结构。但是客户无法使用内容协商，所以服务器也无法 返回实体的媒体类型。 1982年，Tim Berners-Lee提出了HTTP/1.0，在此后的不断丰富和发展中，HTTP/1.0成为最重要 的面向事务的应用层协议。该协议对每一次请求/响应，建立并拆除一次连接。其特点是简单、易于管理，所以它符合了大家的需要，得到了广泛的应用。其缺点是仍会发生下列问题：对用户请求响应慢、网络拥 塞严重、安全性等。 1997年形成的HTTP/1.1，也就是现在普遍使用的协议，在持续连接操作机制中实现流水方式，即客户 端需要对同一服务器发出多个请求时，其实现在多数的网页都是有多部分组成（比如多张图片），可用 流水线方式加快速度，流水机制就是指连续发出多个请求并等到这些请求发送完毕，再等待响应。这样 就大大节省了单独请求对响应的等待时间，使我们得到更快速的浏览。 另外，HTTP/1.1服务器端处理请求时按照收到的顺序进行,这就保证了传输的正确性。当然，服务器端 在发生连接中断时，会自动的重传请求，保证数据的完整性。 HTTP/1.1还提供了身份认证、状态管理和Cache缓存等机制。这里，我想特别提一下关于HTTP/1.1 中的Cache缓存机制对 HTTP/1.0的不足之处的改进，它严格全面，既可以减少时间延迟、又节省了带宽。HTTP/1.1采用了内容协商机制，选择最合适的用户的内容表现形式。 现在，很多地方都有用到的虚拟主机技术在HTTP/1.1中也可以实现。所谓的虚拟主机技术，就是同一 主机地址实际对应多台主机。通俗的讲，当你同时在一个网站申请两个主页时，用协议分析仪可以发现 其实这两个主页对应的是同一个IP地址。这样用多台完全相同的机器形成WWW服务器就可以提高处 理的吞吐量。 传统的解决方案是改造域名服务器使其可以根据一定的算法将同一域名解释成不同的IP地址。分别对应 虚拟主机的每台机器，其缺点是要求每台机器占用完全独立的IP地址，这与IP地址的缺乏是相矛盾的。HTTP/1.1提供的解决方案在HTTP协议自身中加入了指定不同主机的功能，从而多台主机可以共享一个IP地址，既提高了性能又便于管理。 因为HTTP/1.1是Internet现行的标准协议，这里详细介绍其相关语法。 首先，HTTP/1.1格式可写为： 其中请求方法是请求一定的Web页面的程序或用于特定的URL。可选用下列几种： GET：请求指定的页面信息，并返回实体主体。 HEAD：只请求页面的首部。 POST：请求服务器接受所指定的文档作为对所标识的URI的新的从属实体。 PUT：从客户端向服务器传送的数据取代指定的文档的内容。
竭诚为您提供优质文档/双击可除 http协议交互过程 篇一：wireshake抓包分析tcp与http过程详解 http协议报文格式详解 在我们日常生活中最常见的应用环境就是上网浏览网页，很多上班族到办公室的第一件事就是打开电脑，而开机后的第一件事就是打开ie、Firefox、myie、greenbrowser、opera等浏览器时，做的第一件事就是浏览一下例如.cn,的新闻，而这种简单的应用操作，完成的交互过程就是一个典型的http协议的应用过程。 http是基于tcp的连接，因此，建立http连接必须经过tcp的过程，tcp的建立过程是3次握手的过程。然后就是http过程，http只有两种报文，请求和应答报文。完成http过程后，3次断开tcp连接。 http tcp的第一阶段 http开始之前先3次握手，第一阶段就是客户向服务器发送同步请求，flag字段的syn位置1。 第二阶段
第二阶段就是服务器向客户回复一个ack包，其中Flag 字段的syn位和ack字段置1。 tcp的第三阶段： tcp的第三阶段是客户向服务器发送ack，至此，tcp的3次握手结束 tcp三次握手结束之后就是http请求 客户发出http请求之后，服务器收到请求发送ack： 服务器发送应答报文 篇二：http协议分析报告实例 http协议分析 1实验目的 分析http协议报文首部格式，理解http协议工作过程2实验内容 截获http报文，分析http协议报文首部格式，学习http 协议工作过程。3实验原理 超文本传送协议http（hypertexttransferprotocol）,是万维网客户程序与万维网服务器程序之间的交互所要严 格遵守的协议。http是一个应用层协议，它使用tcp连接进行可靠的传送。对于万维网站点的访问要使用的http协议。 http的uRl的一般形式是：http://:/ www采用b/s结构，客户使用浏览器在uRl栏中输入http 请求，即输入对方服务器的地址，向web服务器提出请求。
1、发起请求 下面这个方法的作用就是接收要发送的数据及数据要发送到的URL，然后返回响应数据 protected string SendRequest(string data,string url) { WebRequest req = WebRequest.Create(url); req.Method = "POST"; req.ContentType = "application/x-www-form-urlencoded"; byte[] sendBytes = Encoding.UTF8.GetBytes(data); req.ContentLength = sendBytes.Length; Stream reqStream = req.GetRequestStream(); reqStream.Write(sendBytes, 0, sendBytes.Length); reqStream.Close(); WebResponse res = req.GetResponse(); Stream resStream = res.GetResponseStream(); StreamReader sr = new StreamReader(resStream, Encoding.UTF8); string resData = sr.ReadToEnd(); sr.Close(); resStream.Close(); return resData; } 使用示例： protected void btnSubscribe_Click(object sender, EventArgs e) { string FileName = Server.MapPath("订购.xml");
竭诚为您提供优质文档/双击可除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服务器向该客户端发送
.NET平台处理HTTP请求 .NET平台处理HTTP请求的过程大致如下： 1、IIS得到一个请求；，。 2、查询脚本映射扩展，然后把请求映射到文件 3、代码进入工作者进程(IIS5里是；IIS6里是，工作者进程也叫辅助进程； 4、 .NET运行时被加载； 5、非托管代码调用()方法； 6、每一个请求调用一个IsapiWorkerRequest； 7、使用WorkerRequest调用()方法； 8、通过传递进来的WorkerRequest创建一个HttpContext对象 9、通过把上下文对象作为参数传递给()，然后调用该方法，从应用程序池中获取一个HttpApplication实例； 10、调用()，启动管道事件序列，钩住模块和处理器； 11、调用，开始处理请求； 12、触发管道事件； 13、调用HTTP处理器和ProcessRequest方法； 14、把返回的数据输出到管道，触发处理请求后的事件。 当客户端向Web服务器请求一个页面文件时，这个HTTP请求会被进程截获(WWW服务)，它判断文件后缀，如果是*.aspx、*.asmx等，就把这个请求转交给，而则会通过一个Http PipeLine的管道，将这个HTTP请求发送给进程，当这个HTTP请求进入进程之后， framework就会通过HttpRuntime来处理这个HTTP 请求，处理完毕后将结果返回给客户端。 当一个HTTP请求被送入到HttpRuntime之后，这个HTTP请求通过HTTP管道(HttpRuntime是HTTP管道的入口)被送入到一个被称之为HttpApplication Factory的一个容器当中，而这个容器会给出一个HttpApplication实例来处理传递进来的HTTP请求，同时HttpApplication实例会创建一个HttpContext对象来记录HTTP请求的上下文，而后这个HTTP请求会依次进入到如下几个容器中：HttpModule --> HttpHandler Factory --> HttpHandler当系统内部的HttpHandler的ProcessRequest方法处理完毕之后，整个Http Request就被处理完成了。 如果想在中途截获一个HttpRequest并做些自己的处理，就应该在HttpRuntime运行时内部来做到这一点，确切的说时在HttpModule这个容器中做到这个的。 过程详解： 从本质上讲，主要是由一系列的类组成，这些类的主要目的就是将Http请求转变为对客户端的响应。HttpRuntime类是的一个主要入口，它有一个ProcessRequest方法，这个方法以一个 HttpWorkerRequest 类作为参数。HttpRuntime类几乎包含着关于单个Http请求的所有信息：所请求的文件、服务器端变量、QueryString、Http头信息等等。使用这些信息来加载、运行正确的文件，并且将这个请求转换到输出流中，一般来说，就是HTML页面；二般来说，也可以是张图片^_^。
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.doczj.com/doc/397737156.html,/jigou/gljg.htm，具体的工作过程如下： (1) 浏览器分析指向页面的URL. (2) 浏览器向DNS请求解析https://www.doczj.com/doc/397737156.html,的IP地址。 (3) 域名系统DNS解析出师院服务器的IP地址 (4) 浏览器与服务器建立TCP连接 (5) 浏览器发出取文件命令：GET /jigou/gljg.htm. (6) 服务器https://www.doczj.com/doc/397737156.html,给出响应，将文件 gljg.htm发送给浏览器。 (7) TCP连接释放。 (8) 浏览器显示“北航机构设置”的页面。 服务器提供的默认端口号为80. 4 实验步骤 步骤 1 在计算机上打开wireshark软件，进行报文截获。 步骤 2 从浏览器上访问https://www.doczj.com/doc/397737156.html,页面，具体操作为打开网页，浏览，关掉网页。 步骤 3 停止wireshark的报文截获，结果命名为http_学号，保存在本机或上 传至服务器目录下。
http请求与响应过程 （1）请求方法URI协议/版本 请求的第一行是“方法URL议/版本”：GET/sample.jsp HTTP/1.1 以上代码中“GET”代表请求方法，“/sample.jsp”表示URI，“HTTP/1.1代表协议和协议的版本。 根据HTTP标准，HTTP请求可以使用多种请求方法。例如：HTTP1.1目前支持7种请求方法：GET、POST、HEAD、OPTIONS、 PUT、DELETE和TARCE。 GET 请求获取由Request-URI所标识的资源。 POST 在Request-URI所标识的资源后附加新的数据。 HEAD 请求获取由Request-URI所标识的资源的响应消息报头。 OPTIONS 请求查询服务器的性能，或查询与资源相关的选项和需求。 PUT 请求服务器存储一个资源，并用Request-URI作为其标识。 DELETE 请求服务器删除由Request-URI所标识的资源。 TRACE 请求服务器回送收到的请求信息，主要用语测试或诊断。 在Internet应用中，最常用的方法是GET和POST。 URI完整地指定了要访问的网络资源，通常只要给出相对于服务器的根目录的相对目录即可，因此总是以“/”开头，最 后，协议版本声明了通信过程中使用HTTP的版本。 （2）服务器响应状态码 状态代码： 状态代码由3位数字组成，表示请求是否被理解或被满足。 状态描述： 状态描述给出了关于状态代码的简短的文字描述。 状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。 第一个数字有五种可能的取值： - 1xx: 指示信息—表示请求已接收，继续处理。 - 2xx: 成功—表示请求已经被成功接收、理解、接受。 - 3xx: 重定向—要完成请求必须进行更进一步的操作。 - 4xx: 客户端错误—请求有语法错误或请求无法实现。 - 5xx: 服务器端错误—服务器未能实现合法的请求。 状态代码状态描述说明 200 OK --客户端请求成功 400 Bad Request --由于客户端请求有语法错误，不能被服务器所理解。 401 Unauthonzed --请求未经授权，请求身份认证。这个状态代码必须和WWW-Authenticate报头域一起使用 403 Forbidden --服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因
开放式课题 实验报告 实验名称：基于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)
2xx 成功 200 正常;请求已完成。 201 正常;紧接 POST 命令。 202 正常;已接受用于处理，但处理尚未完成。 203 正常;部分信息—返回的信息只是一部分。 204 正常;无响应—已接收请求，但不存在要回送的信息。 3xx 重定向 301 已移动—请求的数据具有新的位置且更改是永久的。 302 已找到—请求的数据临时具有不同 URI。 303 请参阅其它—可在另一 URI 下找到对请求的响应，且应使用 GET 方法检索此响应。 304 未修改—未按预期修改文档。 305 使用代理—必须通过位置字段中提供的代理来访问请求的资源。 306 未使用—不再使用;保留此代码以便将来使用。 4xx 客户机中出现的错误 400 错误请求—请求中有语法问题，或不能满足请求。 401 未授权—未授权客户机访问数据。 402 需要付款—表示计费系统已有效。 403 禁止—即使有授权也不需要访问。 404 找不到—服务器找不到给定的资源;文档不存在。 407 代理认证请求—客户机首先必须使用代理认证自身。 410 请求的网页不存在(永久); 415 介质类型不受支持—服务器拒绝服务请求，因为不支持请求实体的格式。 5xx 服务器中出现的错误 500 内部错误—因为意外情况，服务器不能完成请求。 501 未执行—服务器不支持请求的工具。 502 错误网关—服务器接收到来自上游服务器的无效响应。 503 无法获得服务—由于临时过载或维护，服务器无法处理请求。 100系列码 从100到199范围的HTTP状态码是信息报告码。基于各种原因考虑，大多数情况下我们是很少看见这些代码的。首先，如果一个浏览器尝试访问一个网站，而网站返回这些代码时，它们往往都不会显示在屏幕上。它们只是浏览器使引用的内部码。另外，这些代码不常见的另外一个原因是起初HTTP标准不允许使用这一范围的状态码。就其本身而言，它们也一直没有被广泛地使用。 200系列码 从 200到299范围的状态码是操作成功代码。同样的，在正常的Web上网中，你也很可能不曾在屏幕上看到这些代码。相反的，这些代码是在浏览器内部使用的，用以确认操作成功确认和当前请求状态。虽然这些代码通常不显示，但是有一些故障排除工具能够读到它们，就像和其它大多数的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头域
一、实验目的和要求 1、实验目的 HTTP客户端程序的功能是给出一个URL，要求程序能够获得指定URL所指向的内容，对于获得内容不必做进一步的处理，只打印HTML代码即可 ●通过HTTP客户端程序使学生掌握网络编程的基本知识和基 本技能； ●使学生掌握HTTP协议的常用命令； ●通过跟踪运行java网络包，使学生了解网络编程实现的细节。 2、实验要求 本实验要求实现一个简单的HTTP客户端，具体内容及要求如下： ●分析HTTP客户端程序的功能，要求能根据给定的URL，获 得URL指向的资源，对于资源的内容可以不做任何的处理， 直接打印即可； ●实现HTTP客户端程序； ●跟踪运行java网络包。 二、系统技术路线和运行环境 1、技术路线： 本系统采用Java语言开发，可以适应几乎所有支持JVM的操作系统。同时Java语言在网络领域的特殊优势，使得它所提供的类库中包含了较为丰富的网络编程API，可以使开发人员方便地开发网络通信类应用程序。
其次还采用了Tomcat6.0与jsp相结合的web建设、使得该系统能够更好的符合实验的要求和标准。 2、系统运行环境： ●硬件环境： PC机一台 ●软件环境： 操作系统：Windows XP、Tomcat6.0、jdk6.0、eclipse等 三、程序的逻辑框图 程序流逻辑框图能够帮助我们更好的熟悉和了解该系统的运行过程，本系统的一些逻辑框图如下所示：
四、程序源代码 1、基于URL的HttpClient.java程序代码如下：import java.awt.*; import java.awt.event.*; import java.io.*; import https://www.doczj.com/doc/397737156.html,.*; import javax.swing.*; public class HttpClient extends JApplet implements ActionListener { //创建一个按钮来点击事件 private JButton jbtView = new JButton("View"); //文本字段来接收文件的名字 private JTextField jtfURL = new JTextField(12);
IIS 5 的https://www.doczj.com/doc/397737156.html, 请求处理过程 对图的解释： IIS 5.x 一个显著的特征就是Web Server 和真正的https://www.doczj.com/doc/397737156.html, Application 的分离。作为Web Server 的进程上，InetInfo.exe 是一个Native Executive，并不是一个托管的程序，而我们真正的https://www.doczj.com/doc/397737156.html, Application aspnet_wp 的Worker Process 上面，在该进程初始化的时候会加载CLR，所以这是一个托管的环境。 IIS6 的https://www.doczj.com/doc/397737156.html, 请求处理过程 对图的解释： IIS 5.x 是通过InetInfo.exe 监听Request 并把Request分发到Work Process。换句话说，在IIS 5.x中对 Mode中进行，在IIS 6中，这种工作被移植到kernel Mode中进行，所有的这一切都是通过一个新的组件：
注：为了避免用户应用程序访问或者修改关键的操作系统数据，windows提供了两种处理器访问模式：用户模式（User Mode）和内核模式（Kernel Mode）。一般地，用户程序运行在User mode下，而操作系统代码运行在Kernel Mode下。Kernel Mode的代码允许访问所有系统内存和所有CPU指令。 在User Mode下，http.sys接收到一个基于aspx 的http request，然后它会根据IIS中的Metabase 查看该基于该Request 的Application 属于哪个Application Pool，如果该Application Pool不存在，则创建之。否则直接将request 发到对应Application Pool 的Queue中。每个Application Pool 对应着一个Worker Process：w3wp.exe，毫无疑问他是运行在User Mode下的。在IIS Metabase 中维护着Application Pool 和worker process的Mapping。WAS（Web Administrative service）根据这样一个mapping，将存在于某个Application Pool Queue的request 传递到对应的worker process(如果没有，就创建这样一个进程)。在worker process 初始化的时候，加载 https://www.doczj.com/doc/397737156.html, ISAPI，https://www.doczj.com/doc/397737156.html, ISAPI 进而加载CLR。最后的流程就和IIS 5.x一样了：通过AppManagerAppDomainFactory 的Create方法为Application 创建一个Application Domain；通过ISAPIRuntime 的ProcessRequest处理Request，进而将流程进入到https://www.doczj.com/doc/397737156.html, Http Runtime Pipeline。 IIS 7的https://www.doczj.com/doc/397737156.html, 请求处理过程 IIS7 站点启动并处理请求的步骤如下图： 步骤1 到6 ，是处理应用启动，启动好后，以后就不需要再走这个步骤了。 上图的8个步骤分别如下： 1、当客户端浏览器开始HTTP 请求一个WEB 服务器的资源时，HTTP.sys 拦截到这个请求。 2、HTTP.sys contacts WAS to obtain information from the configuration store. 3、WAS 向配置存储中心请求配置信息。applicationHost.config。 4、WWW 服务接受到配置信息，配置信息指类似应用程序池配置信息，站点配置信息等等。 5、WWW 服务使用配置信息去配置HTTP.sys 处理策略。 6、WAS starts a worker process for the application pool to which the request was made. 7、The worker process processes the request and returns a response to HTTP.sys. 8、客户端接受到处理结果信息。 W3WP.exe 进程中又是如果处理得呢？？IIS 7 的应用程序池的托管管道模式分两种：经典和集成。这两种模式下处理策略各不相通。 本文作者：郭红俊https://www.doczj.com/doc/397737156.html,/ghj IIS 6 以及IIS7 经典模式的托管管道的架构 在IIS7之前，https://www.doczj.com/doc/397737156.html, 是以IIS ISAPI extension 的方式外加到IIS，其实包括ASP 以及PHP，也都以相同的方式配置（PHP 在IIS 采用了两种配置方式，除了IIS ISAPI extension 的方式，也包括了CGI 的方式，系统管理者能选择PHP 程序的执行方式），因此客户端对IIS 的HTTP 请求会先经由IIS 处理，然后IIS 根据要求的内容类型，如果是HTML 静态网页就由IIS 自行处理，如果不是，就根据要求的内容类型，分派给各自的IIS ISAPI extension；如果要求的内容类型是https://www.doczj.com/doc/397737156.html,，就分派给负责处理https://www.doczj.com/doc/397737156.html, 的IIS ISAPI extension，也就是aspnet_isapi.dll。下图是这个架构的示意图。 IIS7 应用程序池的托管管道模式经典模式也是这样的工作原理。这种模式是兼容IIS 6 的方式，以减少升级的成本。
由于HTTP协议是基于请求/响应范式的(相当于客户机/服务器)。一个客户机与服务器建 立连接后，发送一个请求给服务器，请求方式的格式为：统一资源标识符(URL)、协议版 本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的 代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。 许多HTTP通讯是由一个用户代理初始化的并且包括一个申请在源服务器上资源的请求。最简单的情况可能是在用户代理和服务器之间通过一个单独的连接来完成。在Internet上，HTTP通讯通常发生在TCP/IP连接之上。缺省端口是TCP80，但其它的端口也是可用的。但这并不预示着HTTP协议在Internet或其它网络的其它协议之上才能 完成。HTTP只预示着一个可靠的传输。 这个过程就好像我们打电话订货一样，我们可以打电话给商家，告诉他我们需要什么 规格的商品，然后商家再告诉我们什么商品有货，什么商品缺货。这些，我们是通过电话 线用电话联系(HTTP是通过TCP/IP)，当然我们也可以通过传真，只要商家那边也有传真。 以上简要介绍了HTTP协议的宏观运作方式，下面介绍一下HTTP协议的内部操作过程。 在WWW中，“客户”与“服务器”是一个相对的概念，只存在于一个特定的连接期间，即在某个连接中的客户在另一个连接中可能作为服务器。基于HTTP协议的客户/服务器模式的信息交换过程，它分四个过程：建立连接、发送请求信息、发送响应信息、关闭连接。这就好像上面的例子，我们电话订货的全过程。 其实简单说就是任何服务器除了包括HTML文件以外，还有一个HTTP驻留程序，用于响应用户请求。你的浏览器是HTTP客户，向服务器发送请求，当浏览器中输入了一个开始文件或点击了一个超级链接时，浏览器就向服务器发送了HTTP请求，此请求被送往由IP地址指定的URL。驻留程序接收到请求，在进行必要的操作后回送所要求的文件。 在这一过程中，在网络上发送和接收的数据已经被分成一个或多个数据包(packet)，每个数据包包括：要传送的数据；控制信息，即告诉网络怎样处理数据包。TCP/IP决定了每 个数据包的格式。如果事先不告诉你，你可能不会知道信息被分成用于传输和再重新组合 起来的许多小块。 也就是说商家除了拥有商品之外，它也有一个职员在接听你的电话，当你打电话的时候，你的声音转换成各种复杂的数据，通过电话线传输到对方的电话机，对方的电话机又 把各种复杂的数据转换成声音，使得对方商家的职员能够明白你的请求。这个过程你不需 要明白声音是怎么转换成复杂的数据的。