Web前端开发培训第1讲:Http协议讲义完整版.docx_第1页
Web前端开发培训第1讲:Http协议讲义完整版.docx_第2页
Web前端开发培训第1讲:Http协议讲义完整版.docx_第3页
Web前端开发培训第1讲:Http协议讲义完整版.docx_第4页
Web前端开发培训第1讲:Http协议讲义完整版.docx_第5页
已阅读5页,还剩9页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

Web前端培训第一讲:HTTP协议讲义完整版 目录0.预备知识10.1OSI层次模型与TCP/IP协议栈10.2IP地址20.3 TCP/IP通信方式21.HTTP协议通信过程21.1 URL自动解析21.2 获取IP,建立TCP连接31.3客户端浏览器向服务器发出HTTP请求31.4 Web服务器应答,并向浏览器发送数据31.5 Web服务器关闭TCP连接32.HTTP协议之URL42.1 HTTP协议概述42.2 HTTP之URL42.3 URL编码53.HTTP协议之请求83.1 HTTP请求的结构84.HTTP协议之响应95.HTTP协议之消息报头105.1 普通报头105.2 请求报头115.3 响应报头125.4 实体报头136.需要提前了解的工具HttpAnalyzer147.核心参考资料140. 预备知识0.1 OSI层次模型与TCP/IP协议栈CCNA视频教程: /playlist_show/id_767428.html重点学习第二讲OSI层次参考模型与第三讲TCP/IP协议栈。0.2 IP地址Windows Server 2003从入门到精通系列之:TCP/IP协议基础 。 0.3 TCP/IP通信方式l 按Client和Server的连接数量分类1) 一个Client方连接一个Server方,或称点对点(peer to peer)。2) 多个Client方连接一个Server方,这也是通常的并发服务器方式。 3) 一个Client方连接多个Server方,这种方式很少见。l 按连接方式分类1) 长连接 Client方与Server方先建立通讯连接,然后再进行报文发送和接收,在通信过程中连接不断开。2) 短连接 Client方与Server每进行一次报文收发交易时才进行通讯连接,通讯完毕后立即断开连接。l 按发送接收方式分类1) 异步 报文发送和接收是分开的,相互独立的,互不影响。这种方式又分两种情况: (1)异步双工:接收和发送在同一个程序中,有两个不同的子进程分别负责发送和接收 (2)异步单工:接收和发送是用两个不同的程序来完成。 2) 同步 报文发送和接收是同步进行,既报文发送后等待接收返回报文。1. HTTP协议通信过程当我们在浏览器的地址栏输入“”然后按回车,这之后发生了什么事,我们直接看到的是打开了对应的网页,那么内部客户端和服务端是如何通信的呢?1.1 URL自动解析HTTP URL包含了用于查找某个资源的足够信息,基本格式如下:HTTP:/host“:”portabs_path,其中HTTP表示桶盖HTTP协议来定位网络资源;host表示合法的主机域名或IP地址,port指定一个端口号,缺省80;abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI时,必须以“/”的形式给出,通常这个工作浏览器自动帮我们完成。例如:输入;浏览器会自动转换成:HTTP://1.2 获取IP,建立TCP连接浏览器地址栏中输入HTTP://并提交之后,首先它会在DNS本地缓存表中查找注1,如果有则直接告诉IP地址。如果没有则要求网关DNS进行查找,如此下去,找到对应的IP后,则返回会给浏览器。当获取IP之后,就开始与所请求的Tcp建立三次握手连接,连接建立后,就向服务器发出HTTP请求。注1:在Windows操作系统环境下,解析域名的过程有很多步骤,详细内容可以参Windows Server 2003从入门到精通系列之:DNS协议基础。 1.3客户端浏览器向服务器发出HTTP请求一旦建立了TCP连接,Web浏览器就会向Web服务器发送请求命令,接着以头信息的形式向Web服务器发送一些别的信息,之后浏览器发送了一空白行来通知服务器,它已经结束了该头信息的发送。1.4 Web服务器应答,并向浏览器发送数据客户机向服务器发出请求后,服务器会客户机回送应答,HTTP/1.1 200 OK应答的第一部分是协议的版本号和应答状态码,正如客户端会随同请求发送关于自身的信息一样,服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。Web服务器向浏览器发送头信息后,它会发送一个空白行来表示头信息的发送到此为结束,接着,它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据。1.5 Web服务器关闭TCP连接一般情况下,一旦Web服务器向浏览器发送了请求数据,它就要关闭TCP连接注2,然后如果浏览器或者服务器在其头信息加入了这行代码Connection:keep-aliveTCP连接在发送后将仍然保持打开状态,于是,浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间,还节约了网络带宽。 注2:关闭连接也可以由客户端来要求。2. HTTP协议之URL2.1 HTTP协议概述http(超文本传输协议)是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式,HTTP1.1版本中给出一种持续连接的机制,绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。关键词:请求与相应模式、无状态的、常基于TCP的应用程协议、持续连接的机制。请求与相应模式:客户端发出一个请求,服务器给出一个应答。无状态的:指http协议本身不会在多次请求间保持状态。常基于TCP的应用程协议:TCP/IP是事实上的网络通信工业标准,但并不是唯一,因此是“常”。持续连接的机制注3:指的是Http1.1版本,通信方式已经可以为“长连接”。注3:http协议中规定了一个特殊规则:浏览器对一个服务器不能同时打开两个以上的连接(IP+Port)。这个规则应该是为了保护服务器不会很容易被洪水攻击。主流浏览器包括IE都实现了这个规则。DEMO:用IE下载一个网站的文件,只能同时打开2个,第三个就需要等待。附注:这个规定是对IE而言是精确到域名而不是IP。相关内容的详细说明:HTTP协议1.1中文版: /Class/HTTP/0772522080738754597.html 请查看8.1.4节最后的说明。 其中节选: 使用持续连接的客户机应限制与某一服务器同时连接的个数。单用户客户机不应与任一服务器或代理服务器保持两个以上的连接。代理服务器与其它服务器或代理之间应维护2*N个连接,其中N是同时在线的用户数。设定这一规则是为了改进HTTP应答时间且避免拥塞。另外:Iframe与DIV+ajax实现方式效果差别。我们知道ERP和桌面部件大多数都是使用IFrame加载的。那么它的缺陷非常的明显,因为iframe指定src的方式,默认是使用“同步长连接”。因此当iframe的数量多了之后,连接数就会超过2,因此后面的请求必须等待。如果加载的iframe服务端处理时间过长,则整个客户端的浏览器一直被阻塞住。 而DIV+ajax的方式则不同。Ajax发出的请求最后都由ajax Engine发出,即连接由ajaxEngine管理(发送和接收数据)。因此,DIV+ajax异步请求不会出现IE页面阻塞现象。2.2 HTTP之URLHTTP URL (URL是一种特殊类型的URI,包含了用于查找某个资源的足够的信息)的格式如下:http:/host:portabs_pathl http 表示要通过HTTP协议来定位网络资源;l host表示合法的Internet主机域名或者IP地址;l port指定一个端口号,为空则使用缺省端口 80;l abs_path指定请求资源的URI;如果URL中没有给出abs_path,那么当它作为请求URI时,必须以“/”的形式给出,通常这个工作 浏览器自动帮我们完成。DEMO:输入:,浏览器自动转换成:http:/ / 2.3 URL编码foo:/:8042/over/there?name=ferret#nose _/ _/ _/_/ _/ | | | | | scheme authority path query fragmentURI是统一资源标识的意思,通常我们所说的Url只是URI的一种。典型Url的格式如上面所示。Url编码,实际上指的是URI编码。2.3.1 为什么需要Url编码通常如果一样东西需要编码,说明这样东西并不适合传输。对于Url来说,之所以要进行编码,是因为Url中有些字符会引起歧义。DEMO:Url参数字符串中使用key=value键值对这样的形式来传参,键值对之间以&符号分隔,如/s?q=abc&ie=utf-8。如果你的value字符串中包含了=或者&,那么势必会造成接收Url的服务器解析错误,因此必须将引起歧义的&和=符号进行转义,也就是对其进行编码。Url编码的原则就是使用安全的字符(没有特殊用途或者特殊意义的可打印字符)去表示那些不安全的字符。2.3.2 哪些字符需要编码RFC3986文档规定,Url中只允许包含英文字母(a-zA-Z)、数字(0-9)、-_.4个特殊字符以及所有保留字符。RFC3986文档对Url的编解码问题做出了详细的建议,指出了哪些字符需要被编码才不会引起Url语义的转变,以及对为什么这些字符需要编码做出了相应的解释。2.3.3 US-ASCII字符集中没有对应的可打印字符Url中只允许使用可打印字符。US-ASCII码中的10-7F字节全都表示控制字符,这些字符都不能直接出现在Url中。同时,对于80-FF字节(ISO-8859-1),由于已经超出了US-ACII定义的字节范围,因此也不可以放在Url中。2.3.4 保留字符Url可以划分成若干个组件,协议、主机、路径等。有一些字符(:/?#)是用作分隔不同组件的。DEMO:冒号用于分隔协议和主机,/用于分隔主机和路径,?用于分隔路径和查询参数,等等。还有一些字符(!$&()*+,;=)用于在每个组件中起到分隔作用的,如=用于表示查询参数中的键值对,&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时,需要对其进行编码。RFC3986中指定了以下字符为保留字符:!*();:&=+$,/?#2.3.5 不安全字符还有一些字符,当他们直接放在Url中的时候,可能会引起解析程序的歧义。这些字符被视为不安全字符,原因有很多。l 空格:Url在传输的过程,或者用户在排版的过程,或者文本处理程序在处理Url的过程,都有可能引入无关紧要的空格,或者将那些有意义的空格给去掉 l 引号以及 :引号和尖括号通常用于在普通文本中起到分隔Url的作用 l # :通常用于表示书签或者锚点 l % :百分号本身用作对不安全字符进行编码时使用的特殊字符,因此本身需要编码 l |: 某一些网关或者传输代理会篡改这些字符 需要注意的是,对于Url中的合法字符,编码和不编码是等价的,但是对于上面提到的这些字符,如果不经过编码,那么它们有可能会造成Url语义的不同。因此对于Url而言,只有普通英文字符和数字,特殊字符$-_.+!*()还有保留字符,才能出现在未经编码的Url之中。其他字符均需要经过编码之后才能出现在Url中。但是由于历史原因,目前尚存在一些不标准的编码实现。例如对于符号,虽然RFC3986文档规定,对于波浪符号,不需要进行Url编码,但是还是有很多老的网关或者传输代理会2.3.6 如何对Url中的非法字符进行编码Url编码通常也被称为百分号编码(Url Encoding,also known as percent-encoding),是因为它的编码方式非常简单,使用%百分号加上两位的字符0123456789ABCDEF代表一个字节的十六进制形式。Url编码默认使用的字符集是US-ASCII。例如a在US-ASCII码中对应的字节是0x61,那么Url编码之后得到的就是%61,我们在地址栏上输入/search?q=%61%62%63,实际上就等同于在google上搜索abc了。又如符号在ASCII字符集中对应的字节为0x40,经过Url编码之后得到的是%40。常见字符的Url编码列表:保留字符的Url编码!*();:&%21%2A%22%27%28%29%3B%3A%40%26=+$,/?%#%3D%2B%24%2C%2F%3F%25%23%5B%5D1) 对于非ASCII字符,需要使用ASCII字符集的超集进行编码得到相应的字节,然后对每个字节执行百分号编码。对于Unicode字符,RFC文档建议使用utf-8对其进行编码得到相应的字节,然后对每个字节执行百分号编码。如“中文”使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0x96 0x87,经过Url编码之后得到“%E4%B8%AD%E6%96%87”。2) 如果某个字节对应着ASCII字符集中的某个非保留字符,则此字节无需使用百分号表示。例如“Url编码”,使用UTF-8编码得到的字节是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81,由于前三个字节对应着ASCII中的非保留字符“Url”,因此这三个字节可以用非保留字符“Url”表示。最终的Url编码可以简化成“Url%E7%BC%96%E7%A0%81” ,当然,如果你用%55%72%6C%E7%BC%96%E7%A0%81”也是可以的。由于历史的原因,有一些Url编码实现并不完全遵循这样的原则,下面会提到。2.3.7 JS中 escape,encodeURI和encodeURIComponent的区别Javascript中提供了3对函数用来对Url编码以得到合法的Url,它们分别是escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由于解码和编码的过程是可逆的,因此这里只解释编码的过程。这三个编码的函数escape,encodeURI,encodeURIComponent都是用于将不安全不合法的Url字符转换为合法的Url字符表示,它们有以下几个不同点。l 安全字符不同下面的表格列出了这三个函数的安全字符(即函数不会对这些字符进行编码)安全字符 escape(69个) */+-._0-9a-zA-Z encodeURI(82个) !#$&()*+,/:;=?-._0-9a-zA-Z encodeURIComponent(71个) !()*-._0-9a-zA-Z l 兼容性不同escape函数是从Javascript1.0的时候就存在了,其他两个函数是在Javascript1.5才引入的。但是由于Javascript1.5已经非常普及了,所以实际上使用encodeURI和encodeURIComponent并不会有什么兼容性问题。l 对Unicode字符的编码方式不同这三个函数对于ASCII字符的编码方式相同,均是使用百分号+两位十六进制字符来表示。但是对于Unicode字符,escape的编码方式是%uxxxx,其中的xxxx是用来表示unicode字符的4位十六进制字符。这种方式已经被W3C废弃了。但是在ECMA-262标准中仍然保留着escape的这种编码语法。encodeURI和encodeURIComponent则使用UTF-8对非ASCII字符进行编码,然后再进行百分号编码。这是RFC推荐的。因此建议尽可能的使用这两个函数替代escape进行编码。l 适用场合不同encodeURI被用作对一个完整的URI进行编码,而encodeURIComponent被用作对URI的一个组件进行编码。从上面提到的安全字符范围表格来看,我们会发现,encodeURIComponent编码的字符范围要比encodeURI的大。我们上面提到过,保留字符一般是用来分隔URI组件(一个URI可以被切割成多个组件,参考预备知识一节)或者子组件(如URI中查询参数的分隔符),如:号用于分隔scheme和主机,?号用于分隔主机和路径。由于encodeURI操纵的对象是一个完整的的URI,这些字符在URI中本来就有特殊用途,因此这些保留字符不会被encodeURI编码,否则意义就变了。组件内部有自己的数据表示格式,但是这些数据内部不能包含有分隔组件的保留字符,否则就会导致整个URI中组件的分隔混乱。因此对于单个组件使用encodeURIComponent,需要编码的字符就更多了。3. HTTP协议之请求3.1 HTTP请求的结构http请求由三部分组成,分别是:请求行、消息报头、请求正文。l 请求行请求行以一个方法符号开头,以空格分开,后面跟着请求的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作为其标识DELETE请求服务器删除Request-URI所标识的资源TRACE请求服务器回送收到的请求信息,主要用于测试或诊断CONNECT保留将来使用OPTIONS请求查询服务器的性能,或者查询与资源相关的选项和需求应用举例:GET方法:在浏览器的地址栏中输入网址的方式访问网页时,浏览器采用GET方法向服务器获取资源。eg:GET /form.html HTTP/1.1 (CRLF)POST方法要求被请求服务器接受附在请求后面的数据,常用于提交表单。eg:POST /reg.jsp HTTP/ (CRLF)Accept:image/gif,image/x-xbit,. (CRLF).HOST: (CRLF)Content-Length:22 (CRLF)Connection:Keep-Alive (CRLF)Cache-Control:no-cache (CRLF)(CRLF) /该CRLF表示消息报头已经结束,在此之前为消息报头,后面为请求正文user=jeffrey&pwd=1234 /此行以下为提交的数据HEAD方法与GET方法几乎是一样的,对于HEAD请求的回应部分来说,它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的。利 用这个方法,不必传输整个资源内容,就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性,是否可以访问,以及最近是否更新。l 请求报头后述l 请求正文请求正文:user=jeffrey&pwd=1234 /此行以下为提交的数据4. HTTP协议之响应HTTP响应也是由三个部分组成,分别是:状态行、消息报头、响应正文1、状态行格式如下:HTTP-Version Status-Code Reason-Phrase CRLF其中,HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;Reason-Phrase表示状态代码的文本描述。状态代码有三位数字组成,第一个数字定义了响应的类别,且有五种可能取值:1xx:指示信息-表示请求已接收,继续处理2xx:成功-表示请求已被成功接收、理解、接受3xx:重定向-要完成请求必须进行更进一步的操作4xx:客户端错误-请求有语法错误或请求无法实现5xx:服务器端错误-服务器未能实现合法的请求常见状态代码、状态描述、说明:200 OK /客户端请求成功400 Bad Request /客户端请求有语法错误,不能被服务器所理解401 Unauthorized /请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用 (这里可以演示一个例子,IIS, windows集成身份验证。总的来说,这个交互过程还是非常复杂的)403 Forbidden /服务器收到请求,但是拒绝提供服务404 Not Found /请求资源不存在,eg:输入了错误的URL500 Internal Server Error /服务器发生不可预期的错误503 Server Unavailable /服务器当前不能处理客户端的请求,一段时间后,可能恢复正常eg:HTTP/1.1 200 OK (CRLF)2、响应报头后述3、响应正文就是服务器返回的资源的内容5. HTTP协议之消息报头HTTP消息由客户端到服务器的请求和服务器到客户端的响应组成。请求消息和响应消息都是由开始行(对于请求消息,开始行就是请求行,对于响应消息,开始行就是状态行),消息报头(可选),空行(只有CRLF的行),消息正文(可选)组成。HTTP消息报头包括普通报头、请求报头、响应报头、实体报头。每一个报头域都是由名字+“:”+空格+值 组成,消息报头域的名字是大小写无关的。5.1 普通报头在普通报头中,有少数报头域用于所有的请求和响应消息,但并不用于被传输的实体,只用于传输的消息。Cache-ControlCache-Control用于指定缓存指令,缓存指令是单向的(响应中出现的缓存指令在请求中未必会出现),且是独立的(一个消息的缓存指令不会影响另一个消息处理的缓存机制),HTTP1.0使用的类似的报头域为Pragma。请求时的缓存指令包括: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、s-maxage.eg:为了指示IE浏览器(客户端)不要缓存页面,服务器端的JSP程序可以编写如下:ASP.NET代码 Response.AddHeader (Cache-Control,no-cache); / Response.AddHeader (Pragma,no-cache);作用相当于上述代码,通常两者合用 Response.AddHeader (Cache-Control,no-cache); /response.setHeader(Pragma,no-cache);作用相当于上述代码,通常两者合用这句代码将在发送的响应消息中设置普通报头域:Cache-Control:no-cacheDateDate普通报头域表示消息产生的日期和时间Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036Sun Nov 6 08:49:37 1994 ; ANSI Cs asctime() format (发送方向)HTTP1.0要求不能生成第三种asctime格式的date/time stamp;HTTP1.1则要求只生成RFC 1123(第一种)格式的date/time stamp。 ConnectionConnection普通报头域允许发送指定连接的选项。例如指定连接是连续,或者指定“close”选项,通知服务器,在响应完成后,关闭连接注意:某些杀毒软件可能会在特定的情况下阻止ajax的调用。当Connection为keep-Alive时,对其他的header会有要求。5.2 请求报头请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息。常用的请求报头AcceptAccept请求报头域用于指定客户端接受哪些类型的信息。eg:Accept:image/gif,表明客户端希望接受GIF图象格式的资源;Accept:text/html,表明客户端希望接受html文本。Accept-CharsetAccept-Charset请求报头域用于指定客户端接受的字符集。eg:Accept-Charset:iso-8859-1,gb2312.如果在请求消息中没有设置这个域,缺省是任何字符集都可以接受。Accept-EncodingAccept-Encoding请求报头域类似于Accept,但是它是用于指定可接受的内容编码。eg:Accept-Encoding:gzip.deflate.如果请求消息中没有设置这个域服务器假定客户端对各种内容编码都可以接受。Accept-LanguageAccept-Language请求报头域类似于Accept,但是它是用于指定一种自然语言。eg:Accept-Language:zh-cn.如果请求消息中没有设置这个报头域,服务器假定客户端对各种语言都可以接受。AuthorizationAuthorization请求报头域主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时,如果收到服务器的响应代码为401(未授权),可以发送一个包含Authorization请求报头域的请求,要求服务器对其进行验证。Host(发送请求时,该报头域是必需的)Host请求报头域主要用于指定被请求资源的Internet主机和端口号,它通常从HTTP URL中提取出来的,eg:我们在浏览器中输入:/index.html浏览器发送的请求消息中,就会包含Host请求报头域,如下:Host:此处使用缺省端口号80,若指定了端口号,则变成:Host::指定端口号User-Agent我们上网登陆论 坛的时候,往往会看到一些欢迎信息,其中列出了你的操作系统的名称和版本,你所使用的浏览器的名称和版本,这往往让很多人感到很神奇,实际上,服务器应用 程序就是从User-Agent这个请求报头域中获取到这些信息。User-Agent请求报头域允许客户端将它的操作系统、浏览器和其它属性告诉服务 器。不过,这个报头域不是必需的,如果我们自己编写一个浏览器,不使用User-Agent请求报头域,那么服务器端就无法得知我们的信息了。请求报头举例:GET /form.html HTTP/1.1 (CRLF)Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,*/* (CRLF)Accept-Language:zh-cn (CRLF)Accept-Encoding:gzip,deflate (CRLF)If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)If-None-Match:W/80b1a4c018f3c41:8317 (CRLF)User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)Host: (CRLF)Connection:Keep-Alive (CRLF)(CRLF)5.3 响应报头响应报头允许服务器传递不能放在状态行中的附加响应信息,以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。常用的响应报头LocationLocation响应报头域用于重定向接受者到一个新的位置。Location响应报头域常用在更换域名的时候。ServerServer响应报头域包含了服务器用来处理请求的软件信息。与User-Agent请求报头域是相对应的。下面是Server响应报头域的一个例子:Server:Apache-Coyote/1.1WWW-AuthenticateWWW-Authenticate响应报头域必须

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论