您了解HTTP么？工作中奇葩HTTP问题经验大征集！（获奖名单已公布-2014-7-9）

lsstarboy

做过一个网页交流的小项目，当时有两个SPDY和websocket选项，感觉SPDY比较麻烦，最后选websocket了——虽然Google说过两者不冲突。

T-Bagwell

你了解 HTTP 吗？
接触过一点点，不是很深入的了解，一般就是用在http传输一些内容的时候用到
你认为你真的很了解 HTTP 吗？
了解的不多，一般就是用一点简单的header
你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
以下是刚刚了解到的，网上看的

1. 
   
2. http 1.0与http1.1的区别如下：
   
3. 下面主要从几个不同的方面介绍HTTP/1.0与HTTP/1.1之间的差别，当然，更多的内容是放在解释这种差异背后的机制上。
   
4. 1 可扩展性
   
5. 可扩展性的一个重要原则：如果HTTP的某个实现接收到了自身未定义的头域，将自动忽略它。
   
6. 在消息中增加版本号，用于兼容性判断。注意，版本号只能用来判断逐段（hop-by-hop）的兼容性，而无法判断端到端（end-to-end）的兼容性。
   
7. 例如，一台HTTP/1.1的源服务器从使用HTTP/1.1的Proxy那儿接收到一条转发的消息，实际上源服务器并不知道终端客户使用的是HTTP/1.0还是HTTP/1.1。因此，HTTP/1.1定义Via头域，用来记录消息转发的路径，它记录了整个路径上所有发送方使用的版本号。
   
8. HTTP/1.1增加了OPTIONS方法，它允许客户端获取一个服务器支持的方法列表。
   
9. 为了与未来的协议规范兼容，HTTP/1.1在请求消息中包含了Upgrade头域，通过该头域，客户端可以让服务器知道它能够支持的其它备用通信协议，服务器可以据此进行协议切换，使用备用协议与客户端进行通信。
   
10. 2 缓存
    
11. 在HTTP/1.0中，使用Expire头域来判断资源的fresh或stale，并使用条件请求（conditional request）来判断资源是否仍有效。例如，cache服务器通过If-Modified-Since头域向服务器验证资源的Last-Modefied头域是否有更新，源服务器可能返回304（Not Modified），则表明该对象仍有效；也可能返回200（OK）替换请求的Cache对象。
    
12. 此外，HTTP/1.0中还定义了Pragma:no-cache头域，客户端使用该头域说明请求资源不能从cache中获取，而必须回源获取。
    
13. HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。
    
14. HTTP/1.0中，If-Modified-Since头域使用的是绝对时间戳，精确到秒，但使用绝对时间会带来不同机器上的时钟同步问题。而HTTP/1.1中引入了一个ETag头域用于重激活机制，它的值entity tag可以用来唯一的描述一个资源。请求消息中可以使用If-None-Match头域来匹配资源的entitytag是否有变化。
    
15. 为了使caching机制更加灵活，HTTP/1.1增加了Cache-Control头域（请求消息和响应消息都可使用），它支持一个可扩展的指令子集：例如max-age指令支持相对时间戳；private和no-store指令禁止对象被缓存；no-transform阻止Proxy进行任何改变响应的行为。
    
16. Cache使用关键字索引在磁盘中缓存的对象，在HTTP/1.0中使用资源的URL作为关键字。但可能存在不同的资源基于同一个URL的情况，要区别它们还需要客户端提供更多的信息，如Accept-Language和Accept-Charset头域。为了支持这种内容协商机制(content negotiation mechanism)，HTTP/1.1在响应消息中引入了Vary头域，该头域列出了请求消息中需要包含哪些头域用于内容协商。
    
17. 3 带宽优化
    
18. HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。例如，客户端只需要显示一个文档的部分内容，又比如下载大文件时需要支持断点续传功能，而不是在发生断连后不得不重新下载完整的包。
    
19. HTTP/1.1中在请求消息中引入了range头域，它允许只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。
    
20. 另外一种情况是请求消息中如果包含比较大的实体内容，但不确定服务器是否能够接收该请求（如是否有权限），此时若贸然发出带实体的请求，如果被拒绝也会浪费带宽。
    
21. HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。注意，HTTP/1.0的客户端不支持100响应码。但可以让客户端在请求消息中加入Expect头域，并将它的值设置为100-continue。
    
22. 节省带宽资源的一个非常有效的做法就是压缩要传送的数据。Content-Encoding是对消息进行端到端（end-to-end）的编码，它可能是资源在服务器上保存的固有格式（如jpeg图片格式）；在请求消息中加入Accept-Encoding头域，它可以告诉服务器客户端能够解码的编码方式。
    
23. 而Transfer-Encoding是逐段式（hop-by-hop）的编码，如Chunked编码。在请求消息中加入TE头域用来告诉服务器能够接收的transfer-coding方式，
    
24. 4 长连接
    
25. HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。此外，由于大多数网页的流量都比较小，一次TCP连接很少能通过slow-start区，不利于提高带宽利用率。
    
26. HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。
    
27. HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间。
    
28. 在HTTP/1.0中，要建立长连接，可以在请求消息中包含Connection: Keep-Alive头域，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头域。同时，可以加入一些指令描述该长连接的属性，如max，timeout等。
    
29. 事实上，Connection头域可以携带三种不同类型的符号：
    
30. 1、一个包含若干个头域名的列表，声明仅限于一次hop连接的头域信息；
    
31. 2、任意值，本次连接的非标准选项，如Keep-Alive等；
    
32. 3、close值，表示消息传送完成之后关闭长连接；
    
33. 
    
34. 客户端和源服务器之间的消息传递可能要经过很多中间节点的转发，这是一种逐跳传递（hop-by-hop）。HTTP/1.1相应地引入了hop-by-hop头域，这种头域仅作用于一次hop，而非整个传递路径。每一个中间节点（如Proxy，Gateway）接收到的消息中如果包含Connection头域，会查找Connection头域中的一个头域名列表，并在将消息转发给下一个节点之前先删除消息中这些头域。
    
35. 通常，HTTP/1.0的Proxy不支持Connection头域，为了不让它们转发可能误导接收者的头域，协议规定所有出现在Connection头域中的头域名都将被忽略。
    
36. 5 消息传递
    
37. HTTP消息中可以包含任意长度的实体，通常它们使用Content-Length来给出消息结束标志。但是，对于很多动态产生的响应，只能通过缓冲完整的消息来判断消息的大小，但这样做会加大延迟。如果不使用长连接，还可以通过连接关闭的信号来判定一个消息的结束。
    
38. HTTP/1.1中引入了Chunkedtransfer-coding来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。
    
39. 在HTTP/1.0中，有一个Content-MD5的头域，要计算这个头域需要发送方缓冲完整个消息后才能进行。而HTTP/1.1中，采用chunked分块传递的消息在最后一个块（零长度）结束之后会再传递一个拖尾（trailer），它包含一个或多个头域，这些头域是发送方在传递完所有块之后再计算出值的。发送方会在消息中包含一个Trailer头域告诉接收方这个拖尾的存在。
    
40. 6 Host头域
    
41. 在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。
    
42. HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。
    
43. 7 错误提示
    
44. HTTP/1.0中只定义了16个状态响应码，对错误或警告的提示不够具体。HTTP/1.1引入了一个Warning头域，增加对错误或警告信息的描述。
    
45. 此外，在HTTP/1.1中新增了24个状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
    
46. 8 内容协商
    
47. 为了满足互联网使用不同母语和字符集的用户，一些网络资源有不同的语言版本（如中文版、英文版）。HTTP/1.0定义了内容协商（contentnegotiation）的概念，也就是说客户端可以告诉服务器自己可以接收以何种语言（或字符集）表示的资源。例如如果服务器不能明确客户端需要何种类型的资源，会返回300（Multiple Choices），并包含一个列表，用来声明该资源的不同可用版本，然后客户端在请求消息中包含Accept-Language和Accept-Charset头域指定需要的版本。
    
48. 就像有些人会说几门外语，但每种外语的流利程度并不相同。类似地，网络资源也可以有不同的表达形式，比如有母语版和各种翻译版本。HTTP引入了一个品质因子（quality values）的概念来表示不同版本的可用性，它的取值从0.0到1.0。例如一个母语是英语的人也能讲法语、甚至还学了点丹麦语，那么他的浏览器可用作如下配置：Accept-Language: en, fr;q=0.5, da;q=0.1。这时，服务器会优先选取品质因子高的值对应的资源版本作为响应。
    
49. 
    
50. 参考资料
    
51. [1] Brian Totty, "HTTP: The DefinitiveGuide", O'REILLY & ASSOC INC, 27, Sep., 2002.
    
52. [2] B. Krishnamurthy, J. C. Mogul, and D.M. Kristol, "Key Differences between HTTP/1.0 and HTTP/1.1", http://www2.research.att.com/~bala/papers/h0vh1.html.
    

复制代码

你知道各种 HTTP 返回码的实际意义吗？
返回码个人总结，大概分以下几个类型，细节的话我还得茶手册，renxiao已经写的很清楚了，我总结的类型：
2xx 成功的
3xx 跳转的
4xx 权限，文件找不到之类的错误
5xx 一般是执行脚本之类的错误，或者cgi错误，或者http内部错误之类的
希望以上没有总结错

你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
比如host ,refer, range,cache-control, content-length之类的，或者有的自己增加的字段
一般用wireshark抓包现看，实际内容实际分析，了解的就这么点东西

tomac_cu

我来说个今天的事儿吧，这个和http既靠边又不靠边，至少我到现在还没能确定到底出在什么方面。
环境：
服务端： linux + apache + php + mysql
客户端：ie chrome firefox safari
现象：
很简单的页面，加载特别慢。状态栏就是显示加载中。一般需要20秒左右。

分析过程：
1.调整服务器，加大prefork数量，减少可能的排队现象。
   结果：无改善

2.抓包：整个过程没有异常，没有拖尾包，有一些tcp重传，经分析与此无关
   结果：无结论

3.切分页面：把表格之类影响渲染的东西，改用div实现
   结果：无改善

4.资源切分：把各类src的慢慢去掉，看到哪里有提升
   结果: 是一个留用将来统计用的 <script>标签严重影响了速度
   处理：该脚本来源为某动态页面，目前暂未启用，所以直接返回空内容。
            通过wireshark可以看到socket关闭正常
            将这个标签去掉以后，页面秒开

结论：页面打开慢，可能是网络慢，脚本慢，也可能是不明原因的慢。至少这个问题我在http层上找了好久。

platinum

接下来大家可以讨论一下 HTTP 里所有方法的功能、价值及应用场景
常见的有 GET / POST
此外还有 CONNECT / HEAD
另外还有 TRACE / PUT / DELETE / OPTIONS
大家可以说一说

hxksd

1.GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连，如：login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD。如果数据是英文字母/数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX为该符号以16进制表示的ASCII。

　　POST把提交的数据则放置在是HTTP包的包体中。

　　2."GET方式提交的数据最多只能是1024字节，理论上POST没有限制，可传较大量的数据，IIS4中最大为80KB，IIS5中为100KB"？？！

　　以上这句是我从其他文章转过来的，其实这样说是错误的，不准确的：

　　(1).首先是"GET方式提交的数据最多只能是1024字节"，因为GET是通过URL提交数据，那么GET可提交的数据量就跟URL的长度有直接关系了。而实际上，URL不存在参数上限的问题，HTTP协议规范没有对URL长度进行限制。这个限制是特定的浏览器及服务器对它的限制。IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器，如Netscape、FireFox等，理论上没有长度限制，其限制取决于操作系统的支持。

　　注意这是限制是整个URL长度，而不仅仅是你的参数值数据长度。[见参考资料5]

　　(2).理论上讲，POST是没有大小限制的，HTTP协议规范也没有进行大小限制，说“POST数据量存在80K/100K的大小限制”是不准确的，POST数据是没有限制的，起限制作用的是服务器的处理程序的处理能力。

　　对于ASP程序，Request对象处理每个表单域时存在100K的数据长度限制。但如果使用Request.BinaryRead则没有这个限制。

　　由这个延伸出去，对于IIS 6.0，微软出于安全考虑，加大了限制。我们还需要注意：

　　　　 1).IIS 6.0默认ASP POST数据量最大为200KB，每个表单域限制是100KB。
　　　　 2).IIS 6.0默认上传文件的最大大小是4MB。
　　　　 3).IIS 6.0默认最大请求头是16KB。
　　IIS 6.0之前没有这些限制。[见参考资料5]

　　所以上面的80K，100K可能只是默认值而已(注：关于IIS4和IIS5的参数，我还没有确认)，但肯定是可以自己设置的。由于每个版本的IIS对这些参数的默认值都不一样，具体请参考相关的IIS配置文档。

　　3.在ASP中，服务端获取GET请求参数用Request.QueryString，获取POST请求参数用Request.Form。在JSP中，用request.getParameter(\"XXXX\")来获取，虽然jsp中也有request.getQueryString()方法，但使用起来比较麻烦，比如：传一个test.jsp?name=hyddd&password=hyddd，用request.getQueryString()得到的是：name=hyddd&password=hyddd。在PHP中，可以用$_GET和$_POST分别获取GET和POST中的数据，而$_REQUEST则可以获取GET和POST两种请求中的数据。值得注意的是，JSP中使用request和PHP中使用$_REQUEST都会有隐患，这个下次再写个文章总结。

　　4.POST的安全性要比GET的安全性高。注意：这里所说的安全性和上面GET提到的“安全”不是同个概念。上面“安全”的含义仅仅是不作数据修改，而这里安全的含义是真正的Security的含义，比如：通过GET提交数据，用户名和密码将明文出现在URL上，因为(1)登录页面有可能被浏览器缓存，(2)其他人查看浏览器的历史纪录，那么别人就可以拿到你的账号和密码了，除此之外，使用GET提交数据还可能会造成Cross-site request forgery攻击

linustd

差点来晚了，本人谈一下HTTP。

先回答这几个问题：
1、你了解 HTTP 吗？
了解。
2、你认为你真的很了解 HTTP 吗？
起码不是新手
3、你知道 HTTP/1.0 和 HTTP/1.1 的区别吗？
http 1.0 和 1.1的最大区别就是HOST头，这个是用来实现虚拟主机的，也就是一个IP上，可以有多个网站，如果你的网站只是设置了通过HOST区分不同的虚拟主机，那么客户端通过IP访问是不行的。当然还有其它区别，keepalive等，这个不用多说。
4、你知道各种 HTTP 返回码的实际意义吗？
这个知道一些，只知道几个重要的就行，别的可以遇到时再查，
比如200成功，300跳转，其中301和302代表永久和临时跳转，在SEO方面很重要
5、你知道各种 Request Header 和 Response Header 里多种字段的含义吗？
请求和相应header，基本上就是几行key-value对，服务器和客户端可以认识其中一些， 也可以不认识
6、你又了解 SPDY 吗？
不了解，好像是某公司组织又新搞的玩意，暂时用不着，学习使用技术的目的是为了生存，我反对为了技术而技术。用的着的时候在查资料也不晚。

其实我想说一点的是，我以前搞.net的，但是很多搞.net的人，别看每天都开发asp.net网站，对http协议和web标准根本一知半解，微软从来不注重这个，微软注重的只是通过不停的升级，套牢开发者和小企业赚钱。所以奉劝各位，如果有任何出路，千万别选择微软平台技术。

说到http，我想起一个重要的问题。很多资料，很多书，很多重要的书，甚至有可能你们这次要发的这本书里，都说到http协议是非连接的，也就是不能保持会话，必须通过cookie来认证用户。
其实这是非常错误的，http协议也是一个面向连接的协议，cookie就是实现会话的机制。
很多人忽视了一点，http协议是一个应用层协议，应用层协议的特点是，对底层的传输网络协议不知晓。
大家都想当然的想到tcp/ip协议，socket等，认为这些协议一旦连上，就可以持续的发送接受数据，好像建立了一层持久连接，但是这怎么可能，只不过是底层的网络链路层、会话层等帮你完成了保持会话的功能，网络又不是电话线，不可能一个连接占据整个线路。
HTTP协议是一个应用层协议，也就是说它可以用任何IPC来传递，比如pipe, socket, sharedmemory, 等等，既然http协议不一定通过socket， tcp/ip等传递，那你还有什么资格说http协议是非连接的呢？
从这一点说,http协议不仅仅是面向连接的，我们通常的socket程序，比如QQ、各种聊天程序，C/S等，试用socket来保持会话，也是错误的，因为你怎么知道我客户端和服务器一定会通过socket连连接呢？ 难道我不能自己发明一个协议，难道我不能用管道、共享内存来连接？
socket等，实际上也是文件，上层的通信协议，比如ＱＱ的协议，也应该像http协议一样，自己实现一个会话机制，而不能利用下层的socket来实现会话，因为那样，下层协议就不能对上层协议透明了。
所以，本人想说的是，千万不能再说http是非连接的协议了，它就是一个面向连接的协议。

dlitchi

我和HTTP打交道是在一个小工具开始的。一个关于webmail的工具，通过HTTP协议模拟浏览器来收取邮件。

    刚开始着手当然是对HTTP是一无所知的，后面就慢慢地通过google和baidu查找关于HTTP的的详解，大概了解了下，就开始写代码了。很庆幸的是，得益于阮一峰大哥博客www.ruanyifeng.com的推荐，我下载了fiddler。fiddler是一款windows平台强大的网络嗅探工具，有了它，所有通过浏览器发送和接收的HTTP报文你都可以一览无遗。它还可以对未发送出去和刚接收进来还没在浏览器上展示的报文拦截，你可以随意地修改它的报文内容，许多的web开发者利用它来对web项目进行调试，很方便易用。你完完全全可以照着它所拦截的报文格式来组包，编写代码，发送报文，接收报文，然后处理数据。

    在开始编码的过程中，其实本人对于HTTP报头的各个字段还不是非常理解的，只顾着照搬，然后组包、发包，就想着尽快结束掉这个小项目。可是当我信心满满的把我自认为完整的HTTP请求报文发送出去的时候，socket一直等到超时也没有返回数据给我。我打开浏览器，访问webmail地址，网络完全正常，我纳闷了。我对比了fiddler拦截的报文，一字不差呀。我寻思着，难道浏览器还隐藏了某些不可见的字符在报文中不成。后来，我把fiddler转换到一十六进制显示报文的选项卡，逐个字节对比。终于发现，我的HTTP请求报头中的末尾少了一个换行符‘\n’。 把缺少的换行符添加到我的报头末尾再次发送，这次服务器终于返回了数据。
    在得意自己解决了一个问题之后，不想又遇到了一个让我头疼的问题。我把服务器返回的数据去掉HTTP报文头部，查看过后居然是乱码。这次我傻眼了。 赶紧求助于万能的google和baidu，终于知道这是字符集搞的鬼。我查看了服务器返回的HTTP报头里边的Content-Type字段，它的值为“text/html; charset=utf-8”。"text/html"表明服务器返回的文件类型是html文件，"charset=utf-8"表明html文件内容采用的字符集是utf-8。这就意味着我需要转码，转成当前系统显示的字符集，才能看到HTTP正文内容。我继续对utf-8字符集进行深挖，后面也是得益于阮一峰的博客才了解了字符集的概念。
    当我在想这下经过转码应该可以看到真正的内容了吧，转了以后发现，数据不完整。 （又来了一个坑）经过了解，在HTTP应答报文中，一般都会出现"Content-Length"字段，以表明该为转码的HTTP正文内容的长度。可是，我并没有发现报头中有这个字段。倒是另外一个字段引起了我的注意，“Transfer-Encoding: chunked”。这个字段意味着这个HTTP正文内容的传输方式是分块传输。于是，再次查找分块传输的作用。终于，重见天日，正文内容一字不落的获取到了。

platinum

给大家推荐几个很好的 URL，由浅入深介绍一下 HTTP 协议

http://blog.csdn.net/hguisu/article/details/8680808
http://blog.csdn.net/hguisu/article/details/8683290
http://blog.csdn.net/hguisu/article/details/8608888

send_linux

platinum 发表于 2014-07-06 20:32
给大家推荐几个很好的 URL，由浅入深介绍一下 HTTP 协议

http://blog.csdn.net/hguisu/article/details/ ...

感谢白金，呵呵