浏览器能够使用一次TCP连接多次发起http请求，那么浏览器是怎么区分这多个请求的响应的？
浏览器能够使用一次TCP连接多次发起http请求，那么浏览器是怎么区分这多个请求的响应的？因为响应并没有标志可以表明它是对应哪个请求的。
按投票排序
HTTP/2 之前，一个连接上的请求/响应必须是按顺序来的，所以按顺序对应即可。即使是pipelining也仍然要保证顺序。HTTP/2 是可以乱序的。机制是通过frame上的来标识。
一个流，传多个或多种数据肯定会有分包机制。常见的有：1.定长数据包2.包含特定分隔符的变长数据包3.先传长度再传包体的变长数据包4.分片传输（其实就是分时传输，用来解决并行传输问题）
计算机软件设计讲究分层，HTTP基于TCP，浏览器基于HTTP，上层不关心底层怎么实现的。HTTP1.0 TCP不能复用，一般服务器在响应完请求后主动关闭连接。HTTP1.1 增加了TCP复用，在一个请求结束后，客户端还可以复用这个TCP，所以HTTP请求是一个接着一个的。HTTP2.0 增加了多路复用，增加了一个帧的概念，通过一次TCP连接，可以把多个HTTP请求封装到不同的帧，发送到服务端，服务器分别对请求做出响应，客户端收到响应后，根据帧的标识，分别交给请求发起者，题主想问的应该是这个。
参考，不过只有部分浏览器实现了，并且只有用于幂等请求。大部分情况还是顺序请求。
HTTP权威指南中有详细说明
已有帐号？
无法登录？
社交帐号登录随笔 - 70&
评论 - 90&
&&&&&&&&&&&
& & 本文主要从实践角度介绍长、短连接在TCP层面的表现，借助Node.JS搭建后台服务，使用WinHTTP、Ajax做客户端请求测试，最后简单涉及WebSocket。
& & 关键字：长连接、短连接、Node.JS、WebSocket.
& & 一两年前，在理论上对长短连接做了学习，那时的技能以客户端为主，所以也止步于客户端和网络抓包，两年来后台技术渐有把握，打算从前到后的实践一遍。如对理论有不理解的，可以先google/百度 一下，或者看看这篇偏理论的介绍：。
1 短连接的表现
先写个简单的server看看短链接的效果，在8124端口上创建WEB服务，给客户端返回Hello World\n，然后断开连接，代码：
* @file 短连接测试服务
启动： node short.js
* @authoer cswuyg
var os = require('os');
var http = require('http');
var server = http.createServer(function(req, res) {
console.log(req.connection.remoteAddress + ':' + req.connection.remotePort);
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
res.destroy();
// destroy immediately
}).listen(8124);
console.log('start ' + os.hostname() + ':8124');
在浏览器访问：http://hostname:8124
使用WireShark抓包：
注意到了吗？上面的FIN 是由8124端口，也就是我们的WEB服务发出来的，及时的销毁了连接。多次刷新浏览器页面，每次都是不同的客户端端口发起请求，不会复用旧连接。
2 长连接的表现
（1）WEB服务代码：
* @file 长连接测试服务器
* 启动： node persistent.js
* ./a.html 为同目录下的ajax请求测试文件
* @authoer cswuyg
var os = require('os');
var http = require('http');
var fs = require('fs');
var server = http.createServer(function(req, res) {
if (/^\/a.html/.test(req.url)) {
fs.createReadStream('a.html').pipe(res);
console.log(req.connection.remoteAddress + ':' + req.connection.remotePort);
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(8124);
server.setTimeout(0);
//设置不超时，所以服务端不会主动关闭连接
console.log('start ' + os.hostname() + ':8124');
（2）使用WinHTTP测试：
如果我们使用WinHTTP去获取数据，在这份代码上做修改：
代码节选：
const wchar_t* lpszAcceptedType[] = {L"*/*", NULL};
request_handle_ = ::WinHttpOpenRequest(connect_handle, L"GET", url_path_.c_str(), L"HTTP/1.1", WINHTTP_NO_REFERER, lpszAcceptedType, 0);
if (request_handle_ == NULL)
return FALSE;
DWORD time_out = 5000;
::WinHttpSetOption(request_handle_, WINHTTP_OPTION_CONNECT_TIMEOUT, &time_out, sizeof(DWORD));
::WinHttpSendRequest(request_handle_, WINHTTP_NO_ADDITIONAL_HEADERS, 0, WINHTTP_NO_REQUEST_DATA, 0, 0, 0);
::WinHttpReceiveResponse(request_handle_, NULL);
//测试代码，不惧goto~
代码思路就是connect handle打开之后，后面不同url的请求（当然是同域名下的）可以复用这个connect handle。
使用WireShark抓包，效果：
注：WinHTTP connect handle复用这是浏览器开发者的事情，WEB开发者不会关心到它。
（3）如果我们使用js代码来测试长连接效果呢？
使用ajax，
&script type="text/javascript" src="/jquery/2.1.4/jquery.min.js"&&/script&
function callNode() {
cache : false,
url : 'http://xxxxxyouhost:8124',
data : {},
success : function(response, code, xhr) {
console.log(response);
console.log(code);
callNode();
callNode();
在浏览器访问：http://hostname:8124/a.html
后台上看效果：
刷刷刷的显示出客户端的多次请求都是一样的IP和端口。
3、WebSocket
从WEB开发者最直接的感受来说，终于，可以不用轮询了，只需要使用WebSocket就可以实现全双工通信，要给客户端推送数据更方便了。
从HTTP优化的角度来说：短连接发展到长连接，省略了重复的三次握手，WebSocket的出现，则把HTTP HEADER也省略掉了。而WebSocket，它不是HTTP协议。
WebSocket在底层的表现就是保持连接不断开，客户端既能接收数据也能发送数据，服务端既能接收数据也能发送数据。这在socket层面并没有什么特别，socket的接收缓存区和发送缓存区是分开的，既可以接收也可以发送。对于从socket层面写服务和应用的人来说，WebSocket并不稀奇，譬如，写一个聊天室，连接可以一直不断开的发送和接收数据。对于做WEB开发的朋友，则有很大不同，之前HTTP请求，每一次传输数据，不管是不是用了长连接都是需要有头部信息，而现在有了WebSocket，一个连接可以一直保持着，不发出FIN包，可以收发数据，是长连接，且多次请求不需要有多个头部信息。（一般的http请求，5分钟无响应后，chrome浏览器主动断开连接），
每一次HTTP请求都要走一遍完整的HTTP协议，这让那些需要实时传输数据的朋友很辛苦，虽然HTTP1.1带来了长连接，不用每一次都重新三次握手建立连接，省略了握手的浪费，但是长连接里每一次请求的的HTTP头都是一样的，也还是很浪费，要把长连接里的多次请求的HTTP头也消灭掉，消灭掉之后的协议叫做WebSocket，这个名字也很写实，就像是把Socket层面的东西暴露给上层应用了。
浏览器为了支持WebSocket，可能会做哪些事情呢？ 1是去掉超时关闭连接，这种协议就不用主动关闭了；2给后端发数据时，非首次请求不发出HTTP HEADER，后面的多次数据传输都不用再起HTTP连接了；3可以随时接收发送数据，之前都是需要客户端发起请求，然后服务端回应这样的模式来传输数据。 另外，还会做校验、编码之类的工作。
在做实际开发的时候，有浏览器支持还不够，后台也需要支持，Node上有socket.io模块可用。
在使用WebSocket的时候，要注意，后台可能经过一个个的代理，代理可能不认识WebSocket协议，可能会有超时断开连接的逻辑，这会导致长连接无法保持。&
使用WebSocket协议做聊天室，抓包：
说明：1、WebSocket借助了HTTP协议；2、这个tcp stream不会终止，它的传输内容会随着客户端跟服务端的通信而增长。
&WebSocket连接建立时的抓包：
&从HTTP1.0、长连接、WebSocket的发展，是不是可以看出：从无状态发展到有状态？无状态在做分布式/高并发的时候相当重要，但在明明就是有状态的场景下强制使用无状态就坏事了。
文中所涉及Node和html代码见github：.
本文所在：&
如有错误请指正.
学习参考：//nodejs-socketio/
阅读(...) 评论()一次完整的HTTP请求的过程
贡献者：rt554ry6u
本站编辑：杭州厨师培训
一次完整的HTTP请求的过程
一次完整的HTTP通信过程， 需要Web浏览器与Web服务器之间完成下列7个步骤： （1） 建立TCP连接 在HTTP 工作开始之前，Web浏览器首先要通过网络与Web服务器建立连接，该连接是通过TCP来完成的，该协议与IP协议共同构建Internet，即著名的 TCP/IP协议族，因此Internet又被称作是TCP/IP网络。HTTP是比TCP更高层次的应用层协议，根据规则，只有低层协议连接建立之后才能进行更高层协议的连接，因此，首先要建立TCP连接，一般TCP连接的端口号是80。 （2） Web浏览器向Web服务器发送请求命令 一旦建立了TCP连接，Web浏览器就会向Web服务器发送请求命令 例如：GET/sample/hello.jsp HTTP/1.1 （3） Web浏览器发送请求头信息 浏览器发送其请求命令之后，还要以头信息的形式向Web服务器发送一些别的信息，之后浏览器发送了一空白行来通知服务器，它已经结束了该头信息的发送。 （4） Web服务器应答 客户机向服务器发出请求后，服务器会向客户机回送应答， HTTP/1.1 200 OK 应答的第一部分是协议的版本号和应答状态码 （5） Web服务器发送应答头信息 正如客户端会随同请求发送关于自身的信息一样，服务器也会随同应答向用户发送关于它自己的数据及被请求的文档。 （6） Web服务器向浏览器发送数据 Web服务器向浏览器发送头信息后，它会发送一个空白行来表示头信息的发送到此为结束，接着，它就以Content-Type应答头信息所描述的格式发送用户所请求的实际数据 （7） Web服务器关闭TCP连接 一般情况下，一旦Web服务器向浏览器发送了请求数据，它就要关闭TCP连接。但如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive TCP连接在发送后将仍然保持打开状态，这样，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了网络带宽
延伸阅读精彩推荐
厨师培训手册_企业管理_经管营销_专业资料
暂无评价|0人阅读|0次下载|举报文档厨师培训手册_企业管理_经管营销_专业资料。文档贡献者 我 贡献于2013-12...
厨师培训资料_企业管理_经管营销_专业资料。厨师培训资料历史悠久的中国烹饪 中国烹饪,历史悠久,技艺精湛。经过数千年的发展,当今的中国菜肴不仅是精美的食品,在一定意...
西餐培训手册_企业管理_经管营销_专业资料。餐饮培训红馆咖啡· 红馆咖啡·西餐厅 咖啡 员工培训手册 2010 年 6 月 1 日 目一 二三 四五六七八九 录 仪容仪...
(六)服务人员的气质美 六、 七、 服务人员必须学会的礼仪服务 餐厅接待服务培训餐厅摆台 摆台规范 五 餐厅摆台规范 斟酒服务规范 六 斟酒服务规范 七、西餐服务...
精彩看点猜你喜欢
中国川菜文化摘要: 川菜是对我国西南地区四川和重庆等地具有地域特色的饮食的统称, 川菜最 大的特点是&一菜一格,百菜百味&.川菜以成都、重庆、川南三个地方菜...
家常川菜做法大全_经管营销_专业资料。川菜乃是我国的八大菜系之一,它是色、香、味俱全,有了它,就能丰富你的餐桌。家常川菜做法大全豉汁蒸排骨 菜系: 时间: ...
鲁菜_自然科学_专业资料。 起源: 鲁菜是由济南和胶东地方菜所组成,宋以后鲁菜就成为“北食”的代表。明、清两代,鲁菜已成宫廷御膳主体,对京、津东北各地的影响...
京菜就是鲁菜_文化/宗教_人文社科_专业资料。京菜就是鲁菜作者:丁丁哥 2007 年 12 月 15 日 八十年代初,有次我大爷来北京,那时我在北京,我是东道,我带着...
经典粤菜大集锦粤菜,即广东地方风味菜,有着悠久的历史,以特有 的菜式和韵味,独树一帜,中国汉族八大菜系之一,发源 于岭南,在国内外享有盛誉。粤菜是一种文化,...
粤菜_育儿理论经验_幼儿教育_教育专区。简要介绍我国八大菜系之中的粤菜粤菜,即广东地方风味菜,是我国著名八大菜系之一,它以特有的菜式和韵 味,独树一帜,在国...
苏菜擅长炖、焖、蒸、炒,重视调汤,保持原汁,风味清鲜,浓而不腻,淡而不薄, 酥松脱骨而不失其形,滑嫩爽脆而不失其味。 苏菜由杨州菜、南京 菜、苏州菜、...
苏菜特点_育儿理论经验_幼儿教育_教育专区。菜肴特点据杭州徐珂所辑《清稗类钞》中记载&肴馔之各有特色者,如京师、山东、四川、广东、 福建、江宁,苏州、镇江、...C++发送HTTP请求的实现代码
字体：[ ] 类型：转载 时间：
这篇文章主要介绍了C++发送HTTP请求的实现代码,需要的朋友可以参考下
代码如下:#include &stdio.h&#include &windows.h&#include &wininet.h&
#define MAXSIZE 1024#pragma comment(lib, "Wininet.lib")
void urlopen(_TCHAR*);
int _tmain(int argc, _TCHAR* argv[]){&&& urlopen(_T(""));&&& return 0;}
void urlopen(_TCHAR* url){&&& HINTERNET hSession = InternetOpen(_T("UrlTest"), INTERNET_OPEN_TYPE_PRECONFIG, NULL, NULL, 0);&&& if(hSession != NULL)&&& {&&&&&&& HINTERNET hHttp = InternetOpenUrl(hSession, url, NULL, 0, INTERNET_FLAG_DONT_CACHE, 0);
&&&&&&& if (hHttp != NULL)&&&&&&& {&&&&&&&&&&& wprintf_s(_T("%s\n"), url);
&&&&&&&&&&& BYTE Temp[MAXSIZE];&&&&&&&&&&& ULONG Number = 1;&&&&&&&&&&& while (Number & 0)&&&&&&&&&&& {&&&&&&&&&&&&&&& InternetReadFile(hHttp, Temp, MAXSIZE - 1, &Number);&&&&&&&&&&&&&&& Temp[Number] = '\0';&&&&&&&&&&&&&&& printf("%s", Temp);&&&&&&&&&&& }&&&&&&&&&&& InternetCloseHandle(hHttp);&&&&&&&&&&& hHttp = NULL;&&&&&&& }&&&&&&& InternetCloseHandle(hSession);&&&&&&& hSession = NULL;&&& } }作者：CoderZh
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具网络基础（15）
原文：http://blog.csdn.net/hguisu/article/details/8608888
参照HTTP1.1的协议标准，下面是的一些它跟HTTP1.0的差别。
&&&&&& 在HTTP1.0中，每对Request/Response都使用一个新的连接。
&&&&&&& HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent& connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠，多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).
&&&&&&& HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP
1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。
&&&&&&& HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。此外，由于大多数网页的流量都比较小，一次TCP连接很少能通过slow-start区，不利于提高带宽利用率。
&&&&&&& 在1.0时的会话方式：
&&&&&& 1. 建立连接
&&&&&& 2. 发出请求信息
&&&&&& 3. 回送响应信息
&&&&&& 4. 关掉连接
&&&&&&&小结:浏览器和web服务器连接很短，每次连接只处理一个请求和响应。对每一个页的请求,浏览器与web服务器都要建立一次单独的连接.浏览器没有 关掉前,连接就断开了.浏览器和服务器之间的通信是完全独立分开的请求和响应对.因为这样没法断点浏览器是否断开,没法做连接状态控制。建立和关掉连接会很占用连接时间.
&&&&& 在一个网页中,在http头中的Connection中有多少个close的头,就相当有多少个http的连接.
&&&&& HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
&&&&&& HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
&&&&&& 在HTTP/1.0中，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，可以加入一些指令描述该长连接的属性，如max，timeout等。
&&&&&& 事实上，Connection头域可以携带三种不同类型的符号：
&&&&&& 1、一个包含若干个头域名的列表，声明仅限于一次hop连接的头域信息；
&&&&&& 2、任意值，本次连接的非标准选项，如Keep-Alive等；
&&&&&&& 3、close值，表示消息传送完成之后关闭长连接；
&&&&&&& 客户端和源服务器之间的消息传递可能要经过很多中间节点的转发，这是一种逐跳传递（hop-by-hop）。HTTP/1.1相应地引入了hop-by-hop头域，这种头域仅作用于一次hop，而非整个传递路径。每一个中间节点（如Proxy，Gateway）接收到的消息中如果包含Connection头域，会查找Connection头域中的一个头域名列表，并在将消息转发给下一个节点之前先删除消息中这些头域。
&&&&&&& 通常，HTTP/1.0的Proxy不支持Connection头域，为了不让它们转发可能误导接收者的头域，协议规定所有出现在Connection头域中的头域名都将被忽略。
&&&&&& 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
&&&&&&& HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。
&&&&&&& HTTP1.1在Request消息头里头多了一个Host域，比如：
&&&&& &GET /pub/WWW/TheProject.html HTTP/1.1
&&&&&& Host: www.w3.org
&& && &HTTP1.0则没有这个域。
&& &&&&可能HTTP1.0的时候认为，建立TCP连接的时候已经指定了IP地址，这个IP地址上只有一个host。
& &&&&&由于HTTP 1.0不支持Host请求头字段，WEB浏览器无法使用主机头名来明确表示要访问服务器上的哪个WEB站点，这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。
(接收方向)
无论是HTTP1.0还是HTTP1.1，都要能解析下面三种date/time stamp：
&&&&& Sun, 06 Nov :37GMT& ; RFC 822, updated by RFC 1123
&&&&& Sunday, 06-Nov-94 08:49:37GMT ; RFC 850, obsoleted by RFC 1036
&&&&& Sun Nov& 6 08:49:371994&&&&&& ; ANSI C's asctime() format
(发送方向)
&&&HTTP1.0要求不能生成第三种asctime格式的date/time stamp；
&&& HTTP1.1则要求只生成RFC 1123(第一种)格式的date/time stamp。
HTTP1.1支持chunked transfer，所以可以有Transfer-Encoding头部域:
Transfer-Encoding:chunked
&HTTP1.0则没有。
HTTP消息中可以包含任意长度的实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟。如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束。
HTTP/1.1中引入了Chunked transfer-coding来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。
在HTTP/1.0中，有一个Content-MD5的头域，要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1中，采用chunked分块传递的消息在最后一个块（零长度）结束之后会再传递一个拖尾（trailer），它包含一个或多个头域，这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在。
&HTTP1.1多了个qvalue域：
&&&&&&qvalue&&&&&&&& = ( &0& [&.& 0*3DIGIT ] )
&&&&&&&&&&&&&&&&&&&&&| ( &1& [ &.& 0*3(&0&) ] )
用于Cache。
&&&&&& HTTP1.1支持传送内容的一部分。比方说，当客户端已经有内容的一部分，为了节省带宽，可以只向服务器请求一部分。
&&&&&&& HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。
&&&&&&& HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。
&&&&&& 节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端（end-to-end）的编码，它可能是资源在服务器上保存的固有格式（如jpeg图片格式）；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码的编码方式。
&&&&&& 而Transfer-Encoding是逐段式（hop-by-hop）的编码，如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式，
&&&&&& 另外一种浪费带宽的情况是请求消息中如果包含比较大的实体内容，但不确定服务器是否能够接收该请求（如是否有权限），此时若贸然发出带实体的请求，如果被拒绝也会浪费带宽。
&&&&&&& HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。注意，HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。
&&&&& 100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。
客户端在Request头部中包含
Expect: 100-continue
Server看到之后呢如果回100 (Continue) 这个状态代码，客户端就继续发requestbody。
这个是HTTP1.1才有的。
&&&& HTTP1.1增加了OPTIONS,PUT, DELETE, TRACE, CONNECT这些Request方法.
&&&&&&Method&&&=&OPTIONS&&&&&&&&&&&&&&&&;Section 9.2
&&&&&&&&&&&&&&&&&&&&&|&GET&&&&&&&&&&&&&&&&&&&&; Section 9.3
&&&&&&&&&&&&&&&&&&&&&|&HEAD&&&&&&&&&&&&&&&&&&&; Section 9.4
&&&&&&&&&&&&&&&&&&&&&|&POST&&&&&&&&&&&&&&&&&&&; Section 9.5
&&&&&&&&&&&&&&&&&&&&&| &PUT&&&&&&&&&&&&&&&&&&&&;Section 9.6
&&&&&&&&&&&&&&&&&&&&&| &DELETE&&&&&&&&&&&&&&&&&;Section 9.7
&&&&&&&&&&&&&&&&&&&&&|&TRACE&&&&&&&&&&&&&&&&&&; Section 9.8
&&&&&&&&&&&&&&&&&&&&&| &CONNECT&&&&&&&&&&&&&&&&;Section 9.9
&&&&&&&&&&&&&&&&&&&&&| extension-method
&&&&&& extension-method =token
& HTTP1.1 增加的新的status code：
(HTTP1.0没有定义任何具体的1xx status code, HTTP1.1有2个)
100 Continue
101 Switching Protocols
203 Non-Authoritative Information
205 Reset Content
206 Partial Content
302 Found (在HTTP1.0中有个 302 Moved Temporarily)
303 See Other
305 Use Proxy
307 Temporary Redirect
405 Method Not Allowed
406 Not Acceptable
407 Proxy Authentication Required
408 Request Timeout
409 Conflict
411 Length Required
412 Precondition Failed
413 Request Entity Too Large
414 Request-URI Too Long
415 Unsupported Media Type
416 Requested Range Not Satisfiable
417 Expectation Failed
504 Gateway Timeout
505 HTTP Version Not Supported
&&&&&& 在HTTP/1.0中，使用Expire头域来判断资源的fresh或stale，并使用条件请求（conditional request）来判断资源是否仍有效。例如，cache服务器通过If-Modified-Since头域向服务器验证资源的Last-Modefied头域是否有更新，源服务器可能返回304（Not Modified），则表明该对象仍有效；也可能返回200（OK）替换请求的Cache对象。
此外，HTTP/1.0中还定义了Pragma:no-cache头域，客户端使用该头域说明请求资源不能从cache中获取，而必须回源获取。
HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。
HTTP/1.0中，If-Modified-Since头域使用的是绝对时间戳，精确到秒，但使用绝对时间会带来不同机器上的时钟同步问题。而HTTP/1.1中引入了一个ETag头域用于重激活机制，它的值entity tag可以用来唯一的描述一个资源。请求消息中可以使用If-None-Match头域来匹配资源的entitytag是否有变化。
为了使caching机制更加灵活，HTTP/1.1增加了Cache-Control头域（请求消息和响应消息都可使用），它支持一个可扩展的指令子集：例如max-age指令支持相对时间戳；private和no-store指令禁止对象被缓存；no-transform阻止Proxy进行任何改变响应的行为。
Cache使用关键字索引在磁盘中缓存的对象，在HTTP/1.0中使用资源的URL作为关键字。但可能存在不同的资源基于同一个URL的情况，要区别它们还需要客户端提供更多的信息，如Accept-Language和Accept-Charset头域。为了支持这种内容协商机制(content negotiation mechanism)，HTTP/1.1在响应消息中引入了Vary头域，该头域列出了请求消息中需要包含哪些头域用于内容协商。
求消息中需要包含哪些头域用于内容协商。
HTTP 1.1持久连接的好处
&&&&&&& 一个WEB站点每天可能要接收到上百万的用户请求，为了提高系统的效率，HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。但是，这也造成了一些性能上的缺陷，例如，一个包含有许多图像的网页文件中并没有包含真正的图像数据内容，而只是指明了这些图像的URL地址，当WEB浏览器访问这个网页文件时，浏览器首先要发出针对该网页文件的请求，当浏览器解析WEB服务器返回的该网页文档中的HTML内容时，发现其中的&img&图像标签后，浏览器将根据&img&标签中的src属性所指定的URL地址再次向服务器发出下载图像数据的请求，如图3.3所示。
&&&&&&&&&&&&&&&&&&
&&&&& 显然，访问一个包含有许多图像的网页文件的整个过程包含了多次请求和响应，每次请求和响应都需要建立一个单独的连接，每次连接只是传输一个文档和图像，上一 次和下一次请求完全分离。即使图像文件都很小，但是客户端和服务器端每次建立和关闭连接却是一个相对比较费时的过程，并且会严重影响客户机和服务器的性 能。当一个网页文件中包含Applet，JavaScript文件，CSS文件等内容时，也会出现类似上述的情况。
&&&&&&& 为了克服HTTP 1.0的这个缺陷，HTTP1.1支持持久连接，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。基于HTTP
1.1协议的客户机与服务器的信息交换过程，如图3.4所示。
&&&&&&&&&&
&&&&&&& 可见，HTTP 1.1在继承了HTTP 1.0优点的基础上，也克服了HTTP 1.0的性能问题。不仅如此，HTTP 1.1还通过增加更多的请求头和响应头来改进和扩充HTTP1.0的功能。例如，由于HTTP 1.0不支持Host请求头字段，WEB浏览器无法使用主机头名来明确表示要访问服务器上的哪个WEB站点，这样就无法使用WEB服务器在同一个IP地址和端口号上配置多个虚拟WEB站点。在HTTP 1.1中增加Host请求头字段后，WEB浏览器可以使用主机头名来明确表示要访问服务器上的哪个WEB站点，这才实现了在一台WEB服务器上可以在同一个IP地址和端口号上使用不同的主机名来创建多个虚拟WEB站点。HTTP
1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：3462358次
积分：27559
积分：27559
排名：第131名
原创：217篇
转载：370篇
译文：178篇
评论：332条
(53)(31)(60)(2)(8)(2)(6)(1)(2)(1)(7)(3)(7)(7)(7)(8)(7)(21)(45)(7)(8)(33)(17)(248)(97)(88)(1)