HTTP协议

HTTP协议#

http采用明文传输，传输的内容可以加密后传输，https传输为加密传输。
注：sp表示空格，CRLF回车+换行

一. 基本概念

　　HTTP是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从WWW服务器传输超文本到本地浏览器的传送协议。今天普遍使用的一个版本——HTTP 1.1。
　　HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。
特点：

1. HTTP协议是一个无状态的协议，同一个客户端的这次请求和上次请求是没有对应关系。这是为了保证服务器内存，同时提高Web服务器对并发访问的处理能力。
   　　在设计HTTP协议时规定Web服务器发送HTTP应答报文和文档时，不保存发出请求的Web浏览器进程的任何状态信息。这有可能出现一个浏览器在短短几秒之内两次访问同一对象，服务器进程不会因为已经给它发过应答报文而不接受第二期服务请求。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
2. HTTP 0.9和1.0使用非持续连接：限制每次连接只处理一个请求，服务器处理完客户的请求，并收到客户的应答后，即断开连接。HTTP 1.1使用持续连接：不必为每个web对象创建一个新的连接，一个连接可以传送多个对象，采用这种方式可以节省传输时间。
3. 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
4. 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。
   　　默认HTTP的端口号为80，HTTPS的端口号为443。
   　　HTTP协议永远都是客户端发起请求，服务器回送响应。这样就限制了使用HTTP协议，无法实现在客户端没有发起请求的时候，服务器将消息推送给客户端。

HTTP协议是无状态的和Connection: keep-alive的区别：

无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。从另一方面讲，打开一个服务器上的网页和你之前打开这个服务器上的网页之间没有任何联系。
HTTP是一个无状态的面向连接的协议，无状态不代表HTTP不能保持TCP连接，更不能代表HTTP使用的是UDP协议（无连接）。
从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。
Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。

二. 工作流程

　　一次HTTP操作称为一个事务，其工作过程可分为四步：

1. 首先客户机与服务器需要建立连接（建立TCP连接）。只要单击某个超级链接，HTTP的工作开始。
2. 建立连接后，客户机发送一个请求给服务器，请求方式的格式为：统一资源标识符（URL）、协议版本号，后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
3. 服务器接到请求后，给予相应的响应信息，其格式为一个状态行，包括信息的协议版本号、一个成功或错误的代码，后边是MIME信息包括服务器信息、实体信息和可能的内容。
4. 客户端接收服务器所返回的信息通过浏览器显示在用户的显示屏上，然后客户机与服务器断开连接。
   　　如果在以上过程中的某一步出现错误，那么产生错误的信息将返回到客户端，由显示屏输出。
   HTTP是基于传输层的TCP协议，而TCP是一个端到端的面向连接的协议。所谓的端到端可以理解为进程到进程之间的通信。所以HTTP在开始传输之前，首先需要建立TCP连接，而TCP连接的过程需要所谓的“三次握手”。

三. URL统一资源定位符

格式：http://host[":"port][abs_path]

http表示要通过HTTP协议来定位网络资源；host表示合法的Internet主机域名或者IP地址；port指定一个端口号，为空则使用缺省端口80；abs_path指定请求资源的URI；如果URL中没有给出abs_path，那么当它作为请求URI时，必须以“/”的形式给出，通常这个工作浏览器自动帮我们完成。
eg:
1、输入：www.guet.edu.cn
浏览器自动转换成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp
统一资源标识符(Uniform Resource Identifier，或URI)是一个用于标识某一互联网资源名称的字符串

四. 头域

　　协议采用了请求/响应模式
　　通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行，一个或者多个头域，一个指示头域结束的空行和可选的消息体组成。
　　HTTP头域包括通用头、请求头、响应头、实体头，每个头域由一个域名，冒号和域值三部分组成，域名忽略大小写，域值前可以添加任何数量的空格符，头域可以扩展为多行，每行开始处，使用至少一个空格或制表符

1. 通用头域

　　通用头域包含请求和响应消息都支持的头域，通用头域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩展，如果存在不支持的通用头域，一般将会作为实体头域处理。

1.1 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超时时间，指示客户机可以接收超出超时时间之内的响应消息。

1.2 Date头域

表示消息发送的时间，所有的 HTTP 日期/时间印记都必须毫无例外的以格林威治平均时间(GMT)表示.
如:Date:Mon,31Dec200104:25:57GMT

1.3 Pragma头域

在HTTP/1.1协议中，它的含义和Cache-Control:no-cache相同。Pargma只有一个用法， 例如： Pragma: no-cache
注意: 在HTTP/1.0版本中，只实现了Pragema:no-cache, 没有实现Cache-Control

1.4 Connection头域

允许发送者指定某一特定连接中的选项设置，常用参数：

• close：连接在完成应答后将被关闭
• Keep-Alive：（http1.1默认开启）一个http产生的tcp连接在传送完最后一个响应后，还需要hold住keepalive_timeout秒后，才开始关闭这个连接。，通过使用keep-alive机制，可以减少tcp连接建立次数，也意味着可以减少TIME_WAIT状态连接，以此提高性能和提高httpd服务器的吞吐率(更少的tcp连接意味着更少的系统内核调用,socket的accept()和close()调用)。

　　但是，keep-alive并不是免费的午餐,长时间的tcp连接容易导致系统资源无效占用。配置不当的keep-alive，有时比重复利用连接带来的损失还更大。所以，正确地设置keep-alive timeout时间非常重要。
　　在服务器端，HttpServlet、HttpServletRequest、和HttpServletResponse类自动实现了Keep-Alive。
　　在没有设置 keepalive_timeout 情况下，一个socket资源从建立到真正释放需要经过的时间是:建立tcp连接 + 传送http请求 + Java程序执行 + 传送http响应 + 关闭tcp连接 + 2MSL 。若设置了，建立tcp连接 + 传送http请求 + Java程序执行 + 传送http响应 + keepalive_timeout时间(若在keepalive_timeout时间内又有新的TCP请求，则在响应之后重新启动keepalive_timeout计时)+关闭tcp连接 + 2MSL
Keep-Alive模式，客户端如何判断请求所得到的响应数据已经接收完成（或者说如何知道服务器已经发生完了数据）？

1. 使用消息首部字段Conent-Length：
   Conent-Length表示实体内容长度，客户端（服务器）可以根据这个值来判断数据是否接收完成。
2. 如果要一边产生数据，一边发给客户端，服务器就需要使用"Transfer-Encoding: chunked"这样的方式来代替Content-Length。chunk编码将数据分成一块一块的发生。Chunked编码将使用若干个Chunk串连而成，由一个标明长度为0(正文长度) 的chunk标示结束。每个Chunk分为头部和正文两部分，头部内容指定正文的字符总数（十六进制的数字 ）和数量单位（一般不写），正文部分就是指定长度的实际内容，两部分之间用回车换行(CRLF) 隔开。

MSL,TTL,RTT

MSL(Maximum Segment Lifetime,报文最大生存时间)是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。RFC 793中规定MSL为2分钟，实际应用中常用的是30秒，1分钟和2分钟等。
TTL(time to live,生存时间):ip头中有一个TTL域，存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机。MSL要大于等于TTL。
RTT(round-trip time,客户到服务器往返所花时间)，TCP含有动态估算RTT的算法。因为RTT受网络传输拥塞程序的变化而变化
TIME_WAIT 状态最大保持时间是2 * MSL,即四次握手断开连接的第四步主动断开方发送完ACK=1之后，还要处于TIME_WAIT状态再等待2 * MSL，原因：
1.我们没有任何机制保证最后的一个ACK能够正常送达，若无法送达，被动方会重新发送FIN=1，但是主动方已经处于CLOSED状态，此时就无法正常断开TCP连接。或者另外一种情况，现在有一个新的连接被建立起来，使用的IP地址与端口与先前的完全相同，被动方重新发送FIN=1之后，我刚刚建立的连接可能就被关闭了，不合理。
2.网络上仍然有可能有残余的数据包(wandering duplicates，或老的重复数据包)，这些数据包，我们也必须能够正常处理。（之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送途中或是其响应过程中成为残余数据报，确认一个数据报及其响应的丢弃的需要两倍的MSL）这就意味着，一个成功建立的连接，必然使得先前网络中残余的数据报都丢失了。

TCP产生 RST响应的情况（属于硬错误）:

四次握手不是关闭 TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达)，RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记
syn发送到服务器主机，但是目的端口并未运行。则产生一个ECONRFUSED错误。客户端立即返回。比如telnet 192.168.1.55 8889，条件：55主机在局域网上并且可达（也可以换成可以到达的网络ip地址），但是8889这个端口并未使用（可能服务器已经关闭），则服务器（对 方主机tcp内核）发送一个rst相应给客户端，于是客户端立即关闭。 注意一下，如果输入的网络ip不可达的话，客户端将会持续发送syn，最后产生一个etimeout的错误，大概75秒左右。这个时候客户端的默认网关 (192.168.1.1 211.2.2.2)因为找不到下一路由，路由器（或者再过几跳的路由器）会产生一个EHOSTUNREACH响应给客户端（注 意，ENETUNREACH和EHOSTUNREACH通常被认为是一个错误，因为ENETUNREACH一般当作已过时），由于这是个软错误（有可能是 网络暂时不通造成的）。客户端会重发syn直到超时。
所以会有 telnet 192.168.1.55 8888 主机存在，但是端口未开，ECONRFUSED错误，立刻返回
telnet 192.168.1.56 * 主机不存在，UNROUTETOHOST错误，立刻返回
telnet 211.1.1.5 * 主机不存在，etimeout错误

tomcat默认是开启keep-alive的，有3个相关的参数可以配置：
keepAliveTimeout：连接最大过期时间，默认20秒，不做限制的话可以设置为-1.
maxKeepAliveRequests：表示一个连接最多可复用多少次请求，默认是100。不做限制可以设置为-1. 注意如果tomcat是直接对外服务的话，keep-alive特性可能被一些DoS攻击利用，比如以很慢的方式发生数据，可以长时间持有这个连接；从而可能被恶意请求耗掉大量连接拒绝服务。tomcat直接对外的话这个值不宜设置的太大。
disableKeepAlivePercentage：注意，这个参数是BIO(Linux内核中通用块层的一个核心数据结构，它描述了块设备的I/O操作)特有的，默认情况BIO在线程池里的线程使用率超过75%时会取消keep-alive，如果不取消的话可以设置为100.

Keep-Alive: timeout=20, max=100

timeout：过期时间20秒（对应httpd.conf里的参数是：KeepAliveTimeout），max是最多一百次请求，强制断掉连接
就是在timeout时间内又有新的连接过来，同时max会自动减1，直到为0，强制断掉。

2. 请求(Request)头域

请求头域可能包含下列字段Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持，如果存在不支持的请求头域，一般将会作为实体头域处理。

• HOST头域：（发送请求时，该头域是必需的）主要用于指定被请求资源的Internet主机和端口号，它通常从HTTP URL中提取出来的。HTTP/1.1请求必须包含主机头域，否则系统会以400状态码返回。
  例如: 我们在浏览器中输入：http://www.guet.edu.cn/index.html ，浏览器发送的请求消息中，就会包含Host请求头域：Host：http://www.guet.edu.cn ，此处使用缺省端口号80，若指定了端口号，则变成：Host：指定端口号。
• If-Modified-Since：把浏览器端缓存页面的最后修改时间发送到服务器去，服务器会把这个时间与服务器上实际文件的最后修改时间进行对比。如果时间一致，那么返回304，客户端就直接使用本地缓存文件。如果时间不一致，就会返回200和新的文件内容。客户端接到之后，会丢弃旧文件，把新文件缓存起来，并显示在浏览器中。
  例如：If-Modified-Since: Thu, 09 Feb 2012 09:07:57 GMT
• If-None-Match：If-None-Match和ETag一起工作，工作原理是在HTTP Response中添加ETag信息。 当用户再次请求该资源时，将在HTTP Request 中加入If-None-Match信息(ETag的值)。如果服务器验证资源的ETag没有改变（该资源没有更新），将返回一个304状态告诉客户端使用本地缓存文件。否则将返回200状态和新的资源和Etag. 使用这样的机制将提高网站的性能。例如: If-None-Match: "03f2b33c0bfcc1:0"。
• Accept：浏览器端可以接受的MIME类型。例如：Accept: text/html 代表浏览器可以接受服务器回发的类型为 text/html 也就是我们常说的html文档，如果服务器无法返回text/html类型的数据，服务器应该返回一个406错误(non acceptable)。通配符 * 代表任意类型，例如 Accept: / 代表浏览器可以处理所有类型，(一般浏览器发给服务器都是发这个)。
• Accept-Encoding：浏览器申明自己可接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）;Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。例如： Accept-Encoding: gzip, deflate。如果请求消息中没有设置这个域，服务器假定客户端对各种内容编码都可以接受。
  Gzip:
  gzip是一种数据格式，默认且目前仅使用deflate算法压缩data部分；当应用Gzip压缩到一个纯文本文件时，效果是非常明显的，大约可以减少70％以上的文件大小。这取决于文件中的内容。但图片，pdf等一些压缩率较高的文件再次压缩效果不好，反而额外占用CPU。
• Accept-Language：浏览器申明自己接收的语言。语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等；例如：Accept-Language: en-us(美国英语)，en(英语)， zh-cn（简体中文），q表示用户对该语言的喜好程度（0~1）。。如果请求消息中没有设置这个报头域，服务器假定客户端对各种语言都可以接受。
• Accept-Charset：浏览器可接受的字符集。如果在请求消息中没有设置这个域，缺省表示任何字符集都可以接受。
• User-Agent：告诉HTTP服务器，客户端使用的操作系统和浏览器的名称和版本。
• Cookie：最重要的请求头之一, 将cookie的值发送给HTTP服务器。
• Authorization：授权信息，通常出现在对服务器发送的WWW-Authenticate头的应答中。主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求报头域的请求，要求服务器对其进行验证。
• Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面，告诉服务器我是从哪个链接过来的。

3. 响应(Response)头域

响应报头允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI所标识的资源进行下一步访问的信息。

• Server：指明HTTP服务器用来处理请求的软件信息。例如：Server: Microsoft-IIS/7.5、Server：Apache-Coyote/1.1。此域能包含多个产品标识和注释，产品标识一般按照重要性排序。

• Set-Cookie：非常重要的header, 用于把cookie发送到客户端浏览器，每一个写入cookie都会生成一个Set-Cookie。
  例如: Set-Cookie: sc=4c31523a; path=/; domain=.acookie.taobao.com

• Location：用于重定向一个新的位置，包含新的URL地址。表示客户应当到哪里去提取文档。Location通常不是直接设置的，而是通过HttpServletResponse的sendRedirect方法，该方法同时设置状态代码为302。Location响应报头域常用在更换域名的时候。

• Refresh：表示浏览器应该在多少时间之后刷新文档，以秒计。你还可以通过setHeader("Refresh", "5; URL=http://host/path ")让浏览器读取指定的页面。注意Refresh的意义是“N秒之后刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面”。

• WWW-Authenticate：该响应报头域必须被包含在401（未授权的）响应消息中，客户端收到401响应消息时候，并发送Authorization报头域请求服务器对其进行验证时，服务端响应报头就包含该报头域。
  eg：WWW-Authenticate:Basic realm="Basic Auth Test!" //可以看出服务器对请求资源采用的是基本验证机制。

详细认证过程见 http://www.cnblogs.com/xzwblog/p/6834663.html

4. 实体报头

请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息。实体头包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。

• Allow：服务器支持哪些请求方法（如GET、POST等）。
• Expires：指明应该在什么时候认为文档已经过期，从而不再缓存它，重新从服务器获取，会更新缓存。过期之前使用本地缓存。HTTP1.1的客户端和缓存会将非法的日期格式（包括0）看作已经过期。eg：为了让浏览器不要缓存页面，我们也可以将Expires实体报头域，设置为0。
• ETag：和If-None-Match 配合使用。
• Last-Modified：用于指示资源的最后修改日期和时间。
• Content-Type：WEB服务器告诉浏览器自己响应的对象的类型和字符集。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。可在web.xml文件中配置扩展名和MIME类型的对应关系。
  例如:Content-Type: text/html;charset=utf-8
  　　 Content-Type:text/html;charset=GB2312
  　　 Content-Type: image/jpeg

媒体类型的格式为：大类/小类，比如text/html。
IANA(The Internet Assigned Numbers Authority，互联网数字分配机构)定义了8个大类的媒体类型，分别是:
application— (比如: application/vnd.ms-excel.)
audio (比如: audio/mpeg.)
image (比如: image/png.)
message (比如,:message/http.)
model(比如:model/vrml.)
multipart (比如:multipart/form-data.)
text(比如:text/html.)
video(比如:video/quicktime.)

• Content-Range：用于指定整个实体中的一部分的插入位置，他也指示了整个实体的长度。在服务器向客户返回一个部分响应，它必须描述响应覆盖的范围和整个实体长度。一般格式：Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-length。
  例如，传送头500个字节次字段的形式：Content-Range:bytes0-499/1234如果一个http消息包含此节（例如，对范围请求的响应或对一系列范围的重叠请求），Content-Range表示传送的范围。

• Content-Length：指明实体正文的长度，以字节方式存储的十进制数字来表示。在数据下行的过程中，Content-Length的方式要预先在服务器中缓存所有数据，然后所有数据再一股脑儿地发给客户端。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。
  例如: Content-Length: 19847

• Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，Servlet可通过查看Accept-Encoding头（即request.getHeader("Accept-Encoding")）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。
  例如：Content-Encoding：gzip

• Content-Language：WEB服务器告诉浏览器自己响应的对象所用的自然语言。

• Content-Disposition：这个头部信息将告诉浏览器打开一个文件下载窗口，而不是试图解析该响应的内容。

五. http请求与响应

在Fiddler中获得的典型例子：

http请求

　　http请求由三部分组成，分别是：请求行、消息报头域、请求正文（比如post方法很可能包含请求正文）

1. 请求行

　　请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：
Method Request-URI HTTP-Version CRLF
其中 Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行。
请求方法（所有方法全为大写）：

GET：
请求获取Request-URI所标识的资源
POST
在Request-URI所标识的资源后附加新的数据，可以用于提交表单，向新闻组、BBS、邮件群组和数据库发送消息。
PUT
请求服务器存储一个资源，并用Request-URI作为其标识
**DELETE **
请求服务器删除Request-URI所标识的资源
**TRACE **
请求服务器回送收到的请求信息，主要用于测试或诊断
**HEAD **
请求获取由Request-URI所标识的资源的响应消息报头
　　方法名称是区分大小写的。当某个请求所针对的资源不支持对应的请求方法的时候，服务器应当返回状态码405（Method Not Allowed）；当服务器不认识或者不支持对应的请求方法的时候，应当返回状态码501（Not Implemented）。
　　HEAD方法与GET方法几乎是一样的，它的HTTP头部中包含的信息与通过GET请求所得到的信息是相同的，优势：不必传输整个资源内容，就可以得到Request-URI所标识的资源的信息。该方法常用于测试超链接的有效性，是否可以访问，以及最近是否更新。

GET和POST的区别：

1. GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456. 而 POST方法是把提交的数据放在HTTP包的Body（正文）中。
2. GET提交的数据大小有限制（因为浏览器对URL的长度有限制，不同浏览器可能不同），而POST方法提交的数据则可以很大，同时传输文件multipart/form-data只能用POST。
3. GET方式提交数据，会带来安全问题，比如一个登录页面，通过GET方式提交数据时，用户名和密码将出现在URL上。同时，GET的URL会被放在浏览器历史和WEB 服务器日志里面，所以如果你把关键数据放在GET里面，被人盗取了浏览器缓存，或者WEB服务器被入侵日志被人盗取了，基本泄露可能性100%。而对POST来说，日志没有记录，只要服务器数据库不被入侵，还是比GET安全一点的。当然也只是安全一点，被拦截后很容易看到正文中传输的数据，所以要对需要保密的数据进行加密(比如非对称加密)或者https。
4. GET的参数在URL中，而在因特网上传送URL，只能采用ASCII字符集，所以要二次URL encode编码；而POST则不需要。
5. 一般GET是用来从服务器上获得数据，而POST是用来向服务器上传递数据

为什么POST几乎全面碾压GET，但是HTTP通信中大多数请求还是使用GET：

• 本质上， GET 的所有信息都在URL， 所以很方便的记录下来重复使用。所以如果你希望：请求中的URL可以被手动输入；请求中的URL可以被存在书签里，或者历史里，或者快速拨号里面，或者分享给别人；请求中的URL是可以被搜索引擎收录的；URL请求的页面可以被CDN缓存，大大减轻web服务器的压力。
• GET一般用于信息获取，是安全的和幂等的。注意所谓安全的意味着该操作用于获取信息而非修改信息。就是说，它仅仅是获取资源信息，就像数据库查询一样，不会修改，增加数据，不会影响资源的状态。幂等的意味着对同一URL的多个请求应该返回同样的结果，所以才能实现CDN的缓存。而post所表达的语义是非幂等的，有副作用的操作，一般用于更新资源信息，所以必须交由web服务器处理。

2. 消息报头域

通用头域+请求头域+实体头域

http响应

三个部分分别是：状态行、消息报头、响应正文。
客户端向服务器发送一个请求，服务器以一个状态行作为响应，响应的内容包括：消息协议的版本、成功或者错误编码、服务器信息、实体元信息以及必要的实体内容。根据响应类别的类别，服务器响应里可以含实体内容，但不是所有的响应都有实体内容。

1. 状态行

响应头第一行也称为状态行，格式如下（下图中红线标出的那行）：
HTTP-Version 空格 Status-Code 空格 Reason-Phrase CRLF

HTTP- Version表示HTTP版本，例如为HTTP/1.1。Status- Code是结果代码，用三个数字表示。Reason-Phrase是个简单的文本描述，解释Status-Code的具体原因。Status-Code用于机器自动识别，Reason-Phrase用于人工理解。Status-Code的第一个数字代表响应类别，可能取5个不同的值，后续两位描述在该类响应下发生的具体状况。

http的状态响应码

1(信息类)：表示接收到请求并且继续处理
100——客户必须继续发出请求
101——客户要求服务器根据请求转换HTTP协议版本

**
2(响应成功)：表示动作被成功接收、理解和接受**
200——表明该请求被成功地完成，所请求的资源发送回客户端
202——接受和处理、但处理未完成
206——如果一个应用只请求某范围之内的文件，那么就会返回206.
这通常被用来进行下载管理，断点续传或者文件分块下载。

3(重定向类)：为了完成指定的动作，必须接受进一步处理
300——请求的资源可在多处得到
301——本网页被永久性转移到另一个URL，302（或307）临时移动
306——前一版本HTTP中使用的代码，现行版本中不再使用

4(客户端错误类)：请求包含错误语法或不能正确执行
400——客户端请求有语法错误，不能被服务器所理解
401——请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403——被禁止（Forbidden），如果你没有权限访问某个页面，那么就会返回403状态。这种情况通常会发生在你试图打开一个没有index页面的文件夹。如果服务器设置不允许查看目录内容，那么你就会看到403错误。
404——表明可连接服务器，但服务器无法取得所请求的网页，请求资源不存在。eg：输入了错误的URL
**
5(服务端错误类)：服务器不能正确执行一个正确的请求**
HTTP 500 - 服务器遇到错误，无法完成请求
　　HTTP 500-11 服务器关闭
　　HTTP 500-12 应用程序重新启动
　　HTTP 500-13 - 服务器太忙
HTTP 503：由于超载或停机维护，服务器目前无法使用，一段时间后可能恢复正常

2. 消息报头域

通用头域+响应头域+实体头域

六. 解决HTTP无状态的问题

1. 通过Cookies保存状态信息

cookie技术是客户端的解决方案，Cookie就是由服务器发给客户端的特殊信息，而这些信息以文本文件的方式存放在客户端，然后客户端每次向服务器发送请求的时候都会带上这些特殊的信息。让我们说得更具体一些：当用户使用浏览器访问一个支持Cookie的网站的时候，用户会提供包括用户名在内的个人信息并且提交至服务器；接着，服务器在向客户端回传相应的超文本的同时也会发回这些个人信息，当然这些信息并不是存放在HTTP响应体（Response Body）中的，而是存放于HTTP响应头（Response Header）；当客户端浏览器接收到来自服务器的响应之后，浏览器会将这些信息存放在一个统一的位置，对于Windows操作系统而言，我们可以从： [系统盘]:\Documents and Settings[用户名]\Cookies目录中找到存储的Cookie；自此，客户端再向服务器发送请求的时候，都会把相应的Cookie再次发回至服务器。而这次，Cookie信息则存放在HTTP请求头（Request Header）了。有了Cookie这样的技术实现，服务器在接收到来自客户端浏览器的请求之后，就能够通过分析存放于请求头的Cookie得到客户端特有的信息，从而动态生成与该客户端相对应的内容。通常，我们可以从很多网站的登录界面中看到“请记住我”这样的选项，如果你勾选了它之后再登录，那么在下一次访问该网站的时候就不需要进行重复而繁琐的登录动作了，而这个功能就是通过Cookie实现的。

2. 通过Session保存状态信息

session即会话对象，它保存了本次客户端与服务端的通信信息。且session数据是存放在服务端的。服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。在Java中是通过调用HttpServletRequest的getSession方法（使用true作为参数）创建的。在创建了Session的同时，服务器会为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有Session id；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session（如果检索不到，可能会新建一个），从而再次使用之。

Session的实现方式：

2.1 使用Cookie来实现

服务器给每个Session分配一个唯一的JSESSIONID，并通过Cookie发送给客户端。
当客户端发起新的请求的时候，将在Cookie头中携带这个JSESSIONID。这样服务器能够找到这个客户端对应的Session。

2.2 使用URL回写来实现

URL回写是指服务器在发送给浏览器页面的所有链接中都携带JSESSIONID的参数，这样客户端点击任何一个链接都会把JSESSIONID带会服务器。如果直接在浏览器输入服务端资源的url来请求该资源，那么Session是匹配不到的。
Tomcat对Session的实现，是一开始同时使用Cookie和URL回写机制，如果发现客户端支持Cookie，就继续使用Cookie，停止使用URL回写。如果发现Cookie被禁用，就一直使用URL回写。jsp开发处理到Session的时候，对页面中的链接记得使用response.encodeURL() 。

2.3 通过表单变量保持状态，

除了Cookies之外，还可以使用表单变量来保持状态，比如Asp.net就通过一个叫ViewState的Input=“hidden”的框来保持状态,即添加一个隐藏字段，比如:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="/wEPDwUKMjA0OTM4MTAwNGRkXUfhlDv1Cs7/qhBlyZROCzlvf5U=" />

这个原理和Cookies大同小异，只是每次请求和响应所附带的信息变成了表单变量。

2.4 通过QueryString保持状态，

QueryString通过将信息保存在所请求地址的末尾来向服务器传送信息，通常和表单结合使用，一个典型的QueryString比如:www.xxx.com/xxx.aspx?var1=value&var2=value2

Cookie和Session有以下明显的不同点：

1）Cookie将状态保存在客户端，Session将状态保存在服务器端；
2）Cookies是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。网络服务器用HTTP头向客户端发送cookies，在客户终端，浏览器解析这些cookies并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些cookies。Session并没有在HTTP的协议中定义；
3）Session是针对每一个用户的，变量的值保存在服务器上，用一个sessionID来区分是哪个用户session变量,这个值是通过用户的浏览器在访问的时候返回给服务器，当客户禁用cookie时，这个值也可能设置为由get来返回给服务器；
4）就安全性来说：当你访问一个使用session 的站点，同时在自己机子上建立一个cookie，建议在服务器端的SESSION机制更安全些。因为它不会任意读取客户存储的信息。

3. Tomcat中的session

session存储结构

　　对Tomcat而言，Session是一块在服务器开辟的内存空间，其存储结构为ConcurrentHashMap；

　　ConcurrentHashMap引入了一个“分段锁”的概念，就是把Map分成了N个Segment，put和get的时候，都是根据key.hashCode()算出放到哪个Segment中，具体可以理解为把一个大的Map拆分成N个小的HashTable，根据key.hashCode()来决定把key放到哪个HashTable中。默认是把segments初始化为长度为16的数组，存储在同一个segment的session，需要加锁同步，存储在不同segment的session可以并发操作，通过把整个Map分为N个Segment（类似HashTable），可以提供相同的线程安全，但是效率提升N倍，默认提升16倍。
　　有些方法需要跨段，比如size()和containsValue()，它们可能需要锁定整个表而而不仅仅是某个段，这需要按顺序锁定所有段，操作完毕后，又按顺序释放所有段的锁。这里“按顺序”是很重要的，否则极有可能出现死锁

使用Cookie来实现
服务器第一次接收到请求时，开辟了一块Session空间（创建了Session对象），同时生成一个Session id，并通过响应头的Set-Cookie：“JSESSIONID=XXXXXXX”命令，向客户端发送要求设置cookie的响应；
客户端收到响应后，在本机客户端设置了一个JSESSIONID=XXXXXXX的cookie信息，该cookie的过期时间为浏览器会话结束；
接下来客户端每次向同一个网站发送请求时，请求头都会带上该cookie信息（包含Session id）；
然后，服务器通过读取请求头中的Cookie信息，获取名称为JSESSIONID的值，得到此次请求的Session id；
ps：服务器只会在客户端第一次请求响应的时候，在响应头上添加Set-Cookie：“JSESSIONID=XXXXXXX”信息，接下来在同一个会话的第二第三次响应头里，是不会添加Set-Cookie：“JSESSIONID=XXXXXXX”信息的；而客户端是会在每次请求头的cookie中带上JSESSIONID信息；
当cookie被 浏览器禁用时，会将cookie信息重写进url

Tomcat中的session实现

　　session是有过期时间的，这个默认的过期时间是 在$catalina_home/conf/web.xml有定义的。默认的过期时间是30min，即30min没有访 问，session就过期了
　　它存储在服务器的内存中，tomcat的StandardManager类将session存储在内存中，也可以持久化到file，数据库，memcache，redis等。客户端只保存sessionid到cookie中，而不会保存session，session销毁只能通过invalidate或超时，关掉浏览器并不会关闭session。
　　tomcat的session的id值生成的机制是一个随机数加时间加上jvm的id值，jvm的id值会根据服务器的硬件信息计算得来，因此不同jvm的id值都是唯一的
　　Tomcat中一个会话对应一个session，其实现类是StandardSession，查看源码，可以找到一个attributes成员属性，即存储session的数据结构，为ConcurrentHashMap，支持高并发的HashMap实现；

    /**
     * The collection of user data attributes associated with this Session.
     */
    protected Map<String, Object> attributes = new ConcurrentHashMap<String, Object>();

那么，tomcat中多个会话对应的session是由谁来维护的呢？ManagerBase类，查看其代码，可以发现其有一个sessions成员属性，存储着各个会话的session信息：

    /**
     * The set of currently active Sessions for this Manager, keyed by
     * session identifier.
     */
    protected Map<String, Session> sessions = new ConcurrentHashMap<String, Session>();

Session对象的创建一般是源于这样的一条语句：

    Session session = request.getSession();或Session session = request.getSession(true);

其实getSession()会调用doGetSession()方法，首先判断requestedSessionId是否存在，如果存在，那么根据这个ID去查找Session对象。如果requestedSessionId不存在或者没有取到Session，并且传递给#getSession(boolean)的参数为真，那么要创建一个新的Session，并且给客户端写回去一个Session Cookie。

    protected Session doGetSession(boolean create) {  
    Context context = getContext();
    // 没有Context的话直接返回null  
    if (context == null)  
        return (null);  
  
    // 判断Session是否有效  
    if ((session != null) && !session.isValid())  
        session = null;  
    if (session != null)  
        return (session);  
  
    // 返回Manager对象，这里是StandardManager类的对象  
    Manager manager = null;  
    if (context != null)  
        manager = context.getManager();  
    if (manager == null)  
        return (null); // Sessions are not supported  
    // 判断是否有SessionID  
    if (requestedSessionId != null) {  
        try {  
            // 在Manager中根据SessionID查找Session  
            session = manager.findSession(requestedSessionId);  
        } catch (IOException e) {  
            session = null;  
        }  
        if ((session != null) && !session.isValid())  
            session = null;  
        if (session != null) {  
            // 更新访问时间  
            session.access();  
            return (session);  
        }  
    }  
  
    // 创建新的Session  
    if (!create)  
        return (null);  
    if ((context != null) && (response != null) && context.getCookies()  
            && response.getResponse().isCommitted()) {  
        throw new IllegalStateException(sm.getString("coyoteRequest.sessionCreateCommitted"));  
    }  
  
    // 判断是否使用 "/" 作为Session Cookie的存储路径 并且 是否SessionID来自Cookie  
    if (connector.getEmptySessionPath() && isRequestedSessionIdFromCookie()) {  
        // 创建Session  
        session = manager.createSession(getRequestedSessionId());  
    } else {  
        session = manager.createSession(null);  
    }  
  
    // 创建一个新的Session Cookies  
    if ((session != null) && (getContext() != null) && getContext().getCookies()) {  
        Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME, session.getIdInternal());  
        // 配置Session Cookie  
        configureSessionCookie(cookie);  
        // 在响应中加入Session Cookie,即往响应头写入“Set-Cookie”信息  
        response.addCookieInternal(cookie);  
    }  
  
    if (session != null) {  
        // 记录下该session的最后访问时间，因为session是可以设置过期时间的；
        session.access();  
        return (session);  
    } else {  
        return (null);  
    }  
  
}  

可能遇到的问题

session劫持：只要用户知道JSESSIONID（从cookie中取得），该用户就可以获取到JSESSIONID对应的session内容（在另一个浏览器的cookie中写入该cookie，访问这个页面）
增加服务器压力，因为session是直接存储在服务器的内存中的；
如果存在多台服务器的话，还存在session同步问题，当然如果只有一台tomcat服务器的话，也就没有session同步的事情了，然而现在一般的应用都会用到多台tomcat服务器，通过负载均衡，同一个会话有可能会被分配到不同的tomcat服务器，因此很可能出现session不一致问题；解决session同步问题，实际上主要是保证能够抽离出一块共享空间存放session信息，且这块空间不同的tomcat服务器都可以访问到；一般这块共享的空间可以是数据库，或者某台服务器的内存空间，甚至硬盘空间，当然将session数据存储到内存是最佳的选择，比如redis

4. 补充

会话cookie和持久cookie的区别

　　如果不设置过期时间，则表示这个cookie生命周期为浏览器会话期间，只要关闭浏览器窗口，cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
　　如果设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie依然有效直到超过设定的过期时间。
　　存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存的cookie，不同的浏览器有不同的处理方式。

cookie寻找

对数组进行循环，调用每个cookie的getName方法，直到找到感兴趣的cookie为止
cookie与你的主机(域)相关，而非你的servlet或JSP页面。因而，尽管你的servlet可能只发送了单个cookie，你也可能会得到许多不相关的cookie。
例如：

    String cookieName = “userID”;
    Cookie cookies[] = request.getCookies();
    if (cookies!=null){
    for(int i=0;i<cookies.length;i++){
    Cookie cookie = cookies[i];
    if (cookieName.equals(cookie.getName())){
    doSomethingWith(cookie.getValue());
    }
    }
    }

七. URL详解

URL(Uniform Resource Locator) 地址用于描述一个网络上的资源， 基本格式如下
schema://host[:port#]/path/.../[;url-params][?query-string] [#anchor]
　　scheme 指定低层使用的协议(例如：http, https, ftp)
　　host HTTP服务器的IP地址或者域名
　　port# HTTP服务器的默认端口是80，这种情况下端口号可以省略。如果使用了别的端口，必须指明
　　path 访问资源的路径
　　url-params
　　query-string 发送给http服务器的数据
　　anchor- 锚，表示 HTML 超链接，在 HTML 文档中<a>标签每出现一次，就会创建 Anchor 对象。锚可用于创建指向另一个文档的链接（通过 href 属性），或者创建文档内的书签（通过 name 属性）。

URL 的一个例子：
http://www.mywebsite.com/sj/test ;id=8079?name=sviergn&x=true#stuff
Schema: http
host: www.mywebsite.com
path: /sj/test
URL params: id=8079
Query String: name=sviergn&x=true
Anchor: stuff

八. 缓存的实现原理

WEB缓存(cache)位于Web服务器和客户端之间。
缓存会根据请求保存输出内容的副本，例如html页面，图片，文件，当下一个请求来到的时候：如果是相同的URL，缓存直接使用副本响应访问请求，而不是向源服务器再次发送请求。
HTTP协议定义了相关的消息头来使WEB缓存尽可能好的工作。

缓存的优点

减少相应延迟：因为请求从缓存服务器（离客户端更近）而不是源服务器被相应，这个过程耗时更少，让web服务器看上去相应更快。
减少网络带宽消耗：当副本被重用时会减低客户端的带宽消耗；客户可以节省带宽费用，控制带宽的需求的增长并更易于管理。

客户端缓存生效的常见流程

服务器收到请求时，会在200OK中回送该资源的Last-Modified和ETag头，客户端将该资源保存在cache中，并记录这两个属性。当客户端需要发送相同的请求时，会在请求中携带If-Modified-Since和If-None-Match两个头。两个头的值分别是响应中Last-Modified和ETag头的值。服务器通过这两个头判断本地资源未发生变化，客户端不需要重新下载，返回304响应。

Web缓存机制

HTTP/1.1中缓存的目的是为了在很多情况下减少发送请求，同时在许多情况下可以不需要发送完整响应。前者减少了网络回路的数量；HTTP利用一个“过期（expiration）”机制来为此目的。后者减少了网络应用的带宽；HTTP用“验证（validation）”机制来为此目的。
HTTP定义了3种缓存机制：
1）Freshness：允许一个回应消息可以在源服务器不被重新检查，并且可以由服务器和客户端来控制。例如，Expires回应头给了一个文档不可用的时间。Cache-Control中的max-age标识指明了缓存的最长时间；
2）Validation：用来检查以一个缓存的回应是否仍然可用。例如，如果一个回应有一个Last-Modified回应头，缓存能够使用If-Modified-Since来判断是否已改变，以便判断根据情况发送请求；
3）Invalidation：在另一个请求通过缓存的时候，常常有一个副作用。例如，如果一个URL关联到一个缓存回应，但是其后跟着POST、PUT和DELETE的请求的话，缓存就会过期。

九. HTTP应用

断点续传的实现原理

HTTP协议的GET方法，支持只请求某个资源的某一部分；
206 Partial Content 部分内容响应；
Range 请求的资源范围；
Content-Range 响应的资源范围；
在连接断开重连时，客户端只请求该资源未下载的部分，而不是重新请求整个资源，来实现断点续传。
分块请求资源实例：
Eg1：Range: bytes=306302- ：请求这个资源从306302个字节到末尾的部分；
Eg2：Content-Range: bytes 306302-604047/604048：响应中指示携带的是该资源的第306302-604047的字节，该资源共604048个字节；
客户端通过并发的请求相同资源的不同片段，来实现对某个资源的并发分块下载。从而达到快速下载的目的。目前流行的FlashGet和迅雷基本都是这个原理。

多线程下载的原理

下载工具开启多个发出HTTP请求的线程；
每个http请求只请求资源文件的一部分：Content-Range: bytes 20000-40000/47000；
合并每个线程下载的文件。

http代理

代理服务器英文全称是Proxy Server，其功能就是代理网络用户去取得网络信息。形象的说：它是网络信息的中转站。
代理服务器是介于浏览器和Web服务器之间的一台服务器，有了它之后，浏览器不是直接到Web服务器去取回网页而是向代理服务器发出请求，Request信号会先送到代理服务器，由代理服务器来取回浏览器所需要的信息并传送给你的浏览器。
而且，大部分代理服务器都具有缓冲的功能，就好象一个大的Cache，它有很大的存储空间，它不断将新取得数据储存到它本机的存储器上，如果浏览器所请求的数据在它本机的存储器上已经存在而且是最新的，那么它就不重新从Web服务器取数据，而直接将存储器上的数据传送给用户的浏览器，这样就能显著提高浏览速度和效率。更重要的是：Proxy Server(代理服务器)是Internet链路级网关所提供的一种重要的安全功能，它的工作主要在开放系统互联(OSI)模型的对话层。

http代理服务器的主要功能：
1）突破自身IP访问限制，访问国外站点。如：教育网、169网等网络用户可以通过代理访问国外网站；
2）访问一些单位或团体内部资源，如某大学FTP(前提是该代理地址在该资源的允许访问范围之内)，使用教育网内地址段免费代理服务器，就可以用于对教育 网开放的各类FTP下载上传，以及各类资料查询共享等服务；
3）突破中国电信的IP封锁：中国电信用户有很多网站是被限制访问的，这种限制是人为的，不同Serve对地址的封锁是不同的。所以不能访问时可以换一个国外的代理服务器试试；
4）提高访问速度：通常代理服务器都设置一个较大的硬盘缓冲区，当有外界的信息通过时，同时也将其保存到缓冲区中，当其他用户再访问相同的信息时，则直接由缓冲区中取出信息，传给用户，以提高访问速度；
5）隐藏真实IP：上网者也可以通过这种方法隐藏自己的IP，免受攻击。

对于客户端浏览器而言，http代理服务器相当于服务器。
而对于Web服务器而言，http代理服务器又担当了客户端的角色。

十. 虚拟主机

虚拟主机：是在网络服务器上划分出一定的磁盘空间供用户放置站点、应用组件等，提供必要的站点功能与数据存放、传输功能。
所谓虚拟主机，也叫“网站空间”就是把一台运行在互联网上的服务器划分成多个“虚拟”的服务器，每一个虚拟主机都具有独立的域名和完整的Internet服务器（支持WWW、FTP、E-mail等）功能。一台服务器上的不同虚拟主机是各自独立的，并由用户自行管理。但一台服务器主机只能够支持一定数量的虚拟主机，当超过这个数量时，用户将会感到性能急剧下降。

虚拟主机的实现原理

虚拟主机是用同一个WEB服务器，为不同域名网站提供服务的技术。Apache、Tomcat等均可通过配置实现这个功能。
相关的HTTP消息头：Host。
例如：Host: www.baidu.com
客户端发送HTTP请求的时候，会携带Host头，Host头记录的是客户端输入的域名。这样服务器可以根据Host头确认客户要访问的是哪一个域名。