Http protocal

 

 

https://tools.ietf.org/html/rfc2616

 

1. 状态码：status code

1xxx：信息--请求被接收，继续下一步处理

 

2xxx：成功--请求行为被成功接收、理解和接受

 

3xxx：重定向--需要进一步的处理来完成请求

 

4xxx：客户端错误--请求包含错误的语法或者无法处理

 

5xxx：服务器错误--服务器无法处理合理的请求

 

 

100：CONTINUE 请求已接受，请继续发送信息，

 

101：Switch Protocal 协议转换，Upgrade 更先进的协议

 

200：OK GET 请求的资源对象；HEAD 对应请求资源的 entity-header 字段，不包含消息体；POST；请求行为的结果消息体；TRACE: 包含请求消息的消息体

 

201：Created 请求处理完成，资源已创建。

 

202：（Accepted）请求接收，处理还未完成，使得客户端及时了解资源请求状况，监视进度

 

203：

 

204：No Content 请求处理完成，但是不需要返回消息体

 

205：Reset Content 服务器完成请求，客户端刷新view

 

206：Partial Content 回复包含 Range或者If-Range请求头的GET请求

 

300：Mutiple Choices，服务器返回包含可用资源列表的消息体供客户端选择，如果客户端一开始就有倾向，则需要在头信息 Location添加特殊URI信息，客户端可以使用此信息自动选择。

 

301：Move Permanently，请求资源永久重定向，服务器使用Location返回重定向URI，对于GET HEAD请求，客户端不能自动重定向请求

 

302：Found 临时重定向，其它同上

 

303：See Other，资源在其它路径，可以通过GET获取

 

304：Not Modify 客户端已缓存资源，并且服务器端为左更改，缓存可以继续使用

 

305：Use Proxy 必须使用代理反问资源，服务器使用Location返回代理资源路径

 

306：Unused 未使用

 

307：Temporary Redirect

 

400：Bad Request，语法错误，服务器无法处理

 

401：Unauthorized 未授权，需要请求信息包含 authentication： basic digest access authentication

 

402：未使用

 

403：Forbidden，理解请求，拒绝服务，

 

404：Not Found

 

405：Method Not Allowed 请求方法不允许，服务器返回allow：允许的方法头信息

 

406：Not Acceptable  无法满足所有的消息头要求；返回消息体，包含所能提供的资源表现形式的列表，允许用户手动进行选择。

 

407：Proxy Authentication Required 代理权限验证，代理返回Proxy-Authenticate：验证说明，客户端重新发送带有Proxy-Authorization头信息

 

408：Request Time Out：

 

409：Conflict 请求资源冲突，例如多客户段请求修改MVVC控制的资源

 

。。。

 

500：Internal Server Error 服务器内部错误

 

501：Not Implementd 未实现能完成请求的方法功能

 

502：Bad Gateway 网关错误

 

503：Service Unavalible 当前服务不可用，可以择机retry

 

504：Gateway Timeout

 

505：Http Version Not Supported

 

entity-body：= Content-Encoding（Content-Type（data））

 

没有默认的encoding

 

2. 消息类型：content-type

任何http/1.1消息，如果包含消息体，则必须在消息头上包含一个Content-type，如果未设置，接收方会尝试通过检查消息内容，或者根据url携带的资源名称扩展来判断消息类型。如果还是无法确定，则使用application/octet-stream

3. 消息长度：entity-length

entity-length 是指编码之前的消息体长度，transfer-length 是指编码之后的消息体长度。

 

4. 长连接：keepalive

• 持久化的http连接：http/1.1产生并默认
• 频繁的tcp连接：增加性能开销。网络负担，内存消耗及时效性浪费
• 节省端点（routers、hosts（clients、servers、proxies、gateways、tunnels、caches））cpu消耗
• TCP control block memory used saved in hosts 节省主机TCP控制块内存消耗
• pipelined操作，可以连续发送请求，而不必等待每一个回复。较小的elapsed time，使的单条TCP连接使用更有效率。
• 减少频繁tcp握手连接，关闭产生的报文对网络的影响，因为不需要每一次的握手建立连接，减少了后续请求延迟。
• 错误信息反馈不需要关闭当前TCP连接，再重新打开连接发送。发送错误信息后，连接依然维持
• Connection：close 关闭连接，如果客户端指向发送单次请求，然后关闭连接，则需要在头信息里添加Connection：close。
• 持久化连接发送的消息必须写到消息长度

5. Pipeline：客户端顺序发送请求，服务器按相同的顺序发送回复。

• pipeline消息只能建立在持久TCP连接上，并做好重发准备，如果服务器没有回复pipeline请求的所有消息，客户端也应该重发请求。
• pipeline的请求必须是幂等的，

6. proxy：

• 对于代理，是分别和客户端和服务器建立了持久的连接，
• 客户端，服务器，代理需要能够从不同的连接关闭事件中恢复。
• 客户端需要重新打开连接，发送丢失的请求
• 服务端一个连接需要至少回复一个请求，在回复所有请求前，不应该关闭连接
• 客户端需要限制同时连接到服务器的请求N，一般限制为N=2个；代理则至多使用2N个连接

 

TCP流控制机制 flow control mechanism

 

7. 监控连接错误信息：

• 当接收到错误信息后，应该立马终止消息传送；
• 当以 chunk 编码发送时，应该发送一条长度为0的chunk，结合 empty trailer 来告知接收方消息的结束。
• 当Content-length 头信息存在时，客户端需要立马关闭连接

 

8. status：100

 

作用：用作客户端在发送消息体之前，请求判断消息接收端是否愿意接收消息（根据请求头信息）

 

操作：客户端需发送  Expect: 100-continue

 

附注：如果不需要发送消息体，则不要发送此头信息

 

服务器端接收到包含  Expect: 100-continue 头信息的请求时，需要立马回复status 100，并继续读取消息，或者回复最终的消息状态码（之后可能终止连接或者接受并丢弃消息）。

 

一般来说，服务器不要回复100给未发送Expect: 100-continue头信息的请求，及来自http/1.0版本的请求。

例外：

http/1.1为了compatibility with RFC2068，对于put、post请求，服务器会添加100 回复，以减少内置等待100客户端的处理延迟。

 

 

服务器：

 

服务器在接收到部分或者全部消息体时，可能会回复100。

 

服务器发送完100后，也必须最终发送最终处理状态。

 

服务器接收完消息前，不能关闭连接

 

代理：

 

代理在能够确定转发服务器为http/1.1，或者不知道转发服务器协议版本时，必须完整转发包包含Expect: 100-continue头信息的请求。

 

代理在能够确定转发服务器为http/1.0时，不能转发此请求，并回复417状态（expection  field）

 

代理应该缓存最近转发的服务器的协议版本信息。

 

代理不应该想使用http/1.0版本发送的未带Expect: 100-continue头信息的请求回复100状态码；

 

 

9. http/1.1 host 头信息需求。

Options：为了在请求前获取url请求路径上的相关信息

 

200回复，需要在头信息中包含所有的服务器端对于请求资源支持的信息；Content-length需求。

 

Max-Forwards：指定到达请求脸上的某个代理，获取相应的信息，当收到options请求时，代理需要检查Max-Forwards字段，当为0时，不能在转发此消息，而需要返回自己的通讯选项信息。当大于0，直接转发请求。

 

不能中途添加此头信息。

 

 

“conditional GET” if the request message includes an IfModified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field：

 

传送满足头信息if条件的资源，减少网路传输

 

“partial GET” if the request message includes a Range header field.

 

获取部分资源请求。

 

Head方法除了服务器回复信息不能包含消息体外，其它与GET一样

 

PUT：存在更新，不存在创建

 

资源创建-》201，资源更新-》200 | 204

 

接收方不能忽略任何无法解析的Content-*头信息，并且需要回复501（not implemented）

 

对比与POST，PUT请求的资源非常明确，如果需要处理额外的资源，需要服务器返回重定向

 

DELETE:

 

删除资源，明确资源删除回复200，204 if no response entity，请求接收，为执行完，返回202（Accepted）

 

TRACE:

 

测试，诊断路径host，收到方需要将请求信息当作消息体（Content-type：message/http）返回200

 

TRACE请求不能包含消息体

 

不能缓存

 

CONNECT:

 

代理建立通道使用

 

referer：告知从哪个地址链接过来的

 

Http：半双工，单向流动，

 

其它：

轮训：间隔的发送请求，获取信息；处理低信息率情景，会浪费太多连接。

 

长轮训：客户端保持请求连接特定时间，直到请求的信息可用，或者到达超时时间，然后再重新发起连接。缺乏标准实现。

 

流化技术：客户端发送一个请求，服务端发送并维护一个持续更新和保持打开（设定时间）的响应。pingpong；防火墙和代理影响。

 

TCP：全双工。

 

websocket：自然的全双工，双向，单套接字连接。单一请求。