zoukankan      html  css  js  c++  java
  • HTTP协议

    什么是HTTP?

    HTTP是超文本传输协议,是一种用于在万维网,传输文件,无论是HTML文件,还是图片,请求等数据的网络协议。通常HTTP协议是建立在TCP/IP socket通信基础之上的。

    HTTP协议是客户端(client)和服务器(servers)通信的协议。浏览器就是一个客户端,因为它发送请求给HTTP服务器(也就是web服务器),web服务器返回响应给客户端。符合HTTP协议的服务器,默认监听80端口,当然也可以重新指定任何一个端口。

    什么是资源?

    HTTP协议是用来传播资源,而不仅仅只是文件。资源就是一个URL链接所对应的一些信息。我们普遍见到的资源就是文件,同时资源也可能是:通过不同编程语言写的CGI脚本,动态生成,并输出。返回请求结果的文件。

    学习HTTP,有助于理解资源类似于文件的概念。实际场景中,HTTP资源不是静态文件,就是服务器端脚本动态生成的结果。

    HTTP的传输结构

    就像大多数的网络协议,HTTP也是C/S模式:客户端向服务器发送请求连接和请求的信息内容,服务器返回响应信息。通常包含请求的资源。服务器发送完响应后,关闭连接。(HTTP是一个无状态的连接)

    请求和响应的格式长得差不多,它们都是由:

    • 一条初始行
    • 零或多条头信息
    • 一个空行
    • 一个可选的消息体
      组成的,格式如下,:
    <initial line, different for request vs. response>
    Header1: value1
    Header2: value2
    Header3: value3
    
    <optional message body goes here, like file contents or query data;
     it can be many lines long, or even binary data $&*%@!^$@>

    initial lineheaders必须由回车结尾。

    Initial Request Line(请求行)

    请求的第一行和响应的第一行不一样!请求的第一行有三个部分:方法名,请求资源的路径(也就是/分隔的路径),使用的HTTP协议版本。访问我的博客首页时,请求头如下:

    GET / HTTP/1.1

    注意:

    • GET方法是HTTP中最常用的方法,他的意思是:‘我要得到这个资源’。另外一个常用的方法是:POST后面会在做详细的说明。方法名全部大写。
    • 域名后面的部分就是路径,默认是‘/’。
    • HTTP版本形如:‘HTTP/x.x’,全部大写。

    Initial Response Line(响应声明行或状态行)

    响应的初始行,称作‘状态行’。也是由三个部分组成的:HTTP协议版本,状态码,状态码描述。同样以我博客为例子,状态行如下:

    HTTP/1.1 304 Not Modified

    注意

    • HTTP版本的内容,形式跟上面一样。
    • 状态码是三位的整数,第一位通常分为如下几类:
      • 1xx 这一类型的状态码,代表请求已被接受,需要继续处理。(消息)
      • 2xx 这一类型的状态码,代表请求已成功被服务器接收、理解、并接受。(成功)
      • 3xx 这类状态码代表需要客户端采取进一步的操作才能完成请求。(重定向)
      • 4xx 这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。(客户端错误)
      • 5xx 这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生。(服务器错误)

    常见的状态码:
    200 OK:请求成功,接收到资源。
    404 Not Found:请求失败,未找到资源。
    301 Moved Permanently:永久性转移。
    302 Moved Temporarily:暂时性转移。
    303 See Other:请求的资源已经移到了另外一个URL上了,客户端会自动跳转。这个通常是CGI脚本使用redirect,使得客户端,重定向到另外一个URL。
    500 Server Error:一个未知的服务器错误。

    Header Lines(请求头)

    请求头提供了请求或响应的信息,或者是关于发送的消息体(message body)的信息。

    请求头的格式为:每条头信息占一行例如“Header-Name: value”,以回车结尾。这个格式也被用于邮件等,更加详细的说明:

    • 请求头是区分大小写的
    • 冒号‘:’后面可以有任意多个空格

    下面的两种格式,效果是一样的:

    Header1: some-long-value-1a, some-long-value-1b
    
    HEADER1:    some-long-value-1a,
                some-long-value-1b

    HTTP1.0定义了16种头,没有强制要带的。而HTTP1.1定义了46种头,并且请求时必须带(Host:)。请求时,一些约定俗称的规定(不遵守没问题,但是最好遵守)。

    • From头:包含谁请求的,或者这个操作做了什么。
    • User-Agent:它包含了谁请求的信息(用户身份),例如:User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.87 Safari/537.36

    上面说的这些头,帮助网络管理员分析问题。这些信息也提供了用户的身份(这些信息可以伪造)。
    如果你在写一个‘servers’,考虑返回响应时把下面这些头加上:

    • Server:类似User-Agent头,表示的是服务的身份。
    • Last-Modified:记此文件在服务期端最后被修改的时间。通常用于缓存,节省带宽。例如:Last-Modified: Fri, 31 Dec 1999 23:59:59 GMT

    Message Body(消息实体)

    一个HTTP消息,头信息后面可能有一个消息实体。响应的时候,这个消息实体就是:客户端请求的资源,或者是提示的错误信息。请求时,消息实体就是:用户输入的数据,或者上传的文件。

    如果一个HTTP消息包含消息实体,那么通常就会下面的几个头,用来描述消息实体,例如:

    • Content-type: 用来表示消息实体的数据类型例如:‘text/html’或者‘image/gif’
    • Content-Length: 表示消息体的大小(bytes)

    HTTP交互的例子

    例如请求一个文件:http://www.somehost.com/path/file.html

    首先与目标网站:'www.somehost.com'的80端口建立起socket连接。之后通过socket连接发送类似:

    GET /path/file.html HTTP/1.0
    From: someuser@jmarshall.com
    User-Agent: HTTPTool/1.0
    [blank line here]

    这时服务器回返回响应,内容格式如下:

    HTTP/1.0 200 OK
    Date: Fri, 31 Dec 1999 23:59:59 GMT
    Content-Type: text/html
    Content-Length: 1354
    
    <html>
    <body>
    <h1>Happy New Millennium!</h1>
    (more file contents)
      .
      .
      .
    </body>
    </html>

    发送完响应之后,服务器会关闭这个socket连接。

    HTTP代理

    HTTP代理就是服务器和客户端的一个中间程序。它从客户端接受请求,然后把这些请求再发送给服务器。响应返回的时候也是同理,需要通过代理。

    代理通常用于防火墙,局域网的安全等。

    当客户端使用代理,它就会把所有的请求发送给代理,而不是发给服务器。通过代理请求和普通的请求有一点不同:第一行,代理请求使用完整的URL,而不是只有path。例如:

    通过代理请求:GET http://www.somehost.com/path/file.html HTTP/1.0
    普通请求:GET /path/file.html HTTP/1.0

    通过这种方式,代理就知道请求的服务器地址了。

    ‘宽容待人’

    就像常说的:“严格的发送,宽容的接收。”你交互信息过程中,其它的客户端和服务器,它们发送的信息都有可能有瑕疵。但是,你应该尝试预料到这些问题,从而使一切正常的运行。下面有些建议:

    • 即使规定必须以回车(CRLF)结尾,但是一些人可能只用换行(LF),所以请同时接受这两者。
    • 发送的消息内部,每一个部分必须由一个空行进行隔离。但是,其它程序有可能使用几个空行来隔离。所以也一定要考虑接受这种情况。

    当然还有一些其他的情况,总之要多兼容。

    结尾

    这是HTTP的基本知识。如果你想知道更多,你需要查看官方的资料。

    到此为止只讲理HTTP1.0的知识,下面会讲HTTP1.1的知识,所以休息一下,让我们升级一下!

    HTTP1.1

    想很多的协议一样,HTTP是不断升级的。HTTP1.1完善了HTTP1.0的一些缺点。总的来说,改善的地方包括:

    • 更快的响应,在一个连接上允许多个HTTP的请求和响应。(叫做:HTTP持久连接)
    • 增加缓存的支持,节省了带宽,提高了响应的速度。
    • 更快的响应和生成页面,因为支持分块编码,允许发送的数据可以分成多个部分,好处是:发送数据之前,不需要预先知道发送内容的总大小。
    • 因为增加了Host头字段,web浏览器可以使用一个IP地址配置多个虚拟web站点。

    HTTP1.1需要再服务器和客户端增加一些额外的东西。接下来的两个部分,分别讲:如何编写遵循HTTP1.1协议的客户端和服务器。当然,你如果只写客户端,只需要看客户端的部分。可以根据自己的需求选择阅读。

    HTTP1.1 Clients(客户端)

    为了符合HTTP1.1,客户端必须:

    • 每次请求必须包含Host头。
    • 允许响应是chunked data(分块传输编码)。
    • 每个请求,必须在头信息中,声明是否支持持久连接。
    • 支持响应返回状态码:‘100 Continue’。

    Host Header(Host头)

    HTTP1.1开始,支持一个IP对应多个虚拟主机。比如:“www.host1.com”和“www.host2.com”可以是同一个服务器(同一IP)。

    一个服务器,有多个域名就像:不同的人,共享一个手机。打电话的人知道他们要找谁,但是接电话的人不知道!所以,打来电话的人需要明确的指出他要找谁。同理,每一个HTTP请求必须在Host头中,明确地指出请求的host。例如:

    GET /path/file.html HTTP/1.1
    Host: www.host1.com:80
    [blank line here]

    其中:80不需特别指出,因为默认就是访问80端口。
    HTTP1.1协议下的请求,请求头中必须包含Host。没有它,每一个域名需要一个独一无二的IP地址,IP地址的数据量正在急剧减少,而网站(域名)却以爆炸的速度增长。Host可以有效的缓解IP地址紧张的现状。

    分块传输编码

    如果服务器想要在知道响应数据总量之前,就发送响应(比如特别长的响应内容,这样计算数据总量会耗费很长的时间),那么就会用到‘分块传输编码’。它把完整的响应数据,分成很多个大小相同的数据块,然后发送。你可以同样接收这样的数据,因为头已经包含了‘Transfer-Encoding: chunked’。所有的HTTP1.1客户端必须可以接收分块的信息。

    分块的消息内容需要包含:有一行是‘0’,用于表示内容的结束。有'footers',和一个空行。必须包含两个部分:

    • 有一行是用16进制表示这个块的大小,后面的额外参数用分号隔离。
    • 数据以回车分割。

    例如:

    HTTP/1.1 200 OK
    Date: Fri, 31 Dec 1999 23:59:59 GMT
    Content-Type: text/plain
    Transfer-Encoding: chunked
    
    a; ignore-stuff-here
    abcdefghijklmnopqrstuvwxyz
    10
    234567890abcdef
    0
    some-footer: some-value
    another-footer: another-value
    [blank line here]

    不要忘记,最后有一行空行。文本内容的大小是42bytes(1a+10=16+10+16=42),内容是:‘abcdefghijklmnopqrstuvwxyz1234567890abcdef’。

    分块数据可以包含任意的二进制数据。下面内容是一样的,但是没有使用‘分块传输编码’的响应。如下:

    HTTP/1.1 200 OK
    Date: Fri, 31 Dec 1999 23:59:59 GMT
    Content-Type: text/plain
    Content-Length: 42
    some-footer: some-value
    another-footer: another-value
    
    abcdefghijklmnopqrstuvwxyz1234567890abcdef

    Persistent Connections(持久连接)

    在HTTP1.0之前,每个请求和响应完成后都会关闭TCP连接,所以每次获取都是一个单独,独立的���接。创建和关闭TCP连接花费大量的CPU资源,带宽和内存。实际操作中,组成一个网页的多个文件都是在一台服务器上。所以,多个请求和响应都可以通过一个持久连接进行传输。

    HTTP1.1默认是持久连接,所以如果没有特殊的需求使用的就是持久连接。只需要建立一个连接,就是可以发送多个请求和读取返回的响应。如果你这么做,一定要注意读取响应返回的长度,以确保正确的区别他们。

    如果一个客户端在请求头中声明了“Connection: close”的话,连接会在响应送达后关闭。比如,这种操作的场景:如果你知道这是这个连接的,最后一个请求。同样的,如果响应头包含这个声明,服务器会在发送完响应之后,关闭连接。所以,客户端不能通过这个链接,发送任何请求。

    服务器可能在发送任何一个响应之前关闭连接。所以,客户端必须保持时刻检查Persistent Connections头的值。以确保选择的连接是通路。

    100 Connections(100状态码)

    客户端使用HTTP1.1协议向服务器发送请求,服务器可能返回临时响应:‘100 Coninue’。它表示服务器接收到了请求的第一部分,后面还有一些缓慢的数据传输。所以,无论如何HTTP1.1的客户端必须能正确处理‘100’状态码的响应。

    返回的‘100 Continue’状态码,和我们前面说的‘200 OK’都是一样的,符合正常的响应的格式。唯一不同的是,响应的内容。如下:

    HTTP/1.1 100 Continue   #没有过完整的响应内容。
    
    HTTP/1.1 200 OK
    Date: Fri, 31 Dec 1999 23:59:59 GMT
    Content-Type: text/plain
    Content-Length: 42
    some-footer: some-value
    another-footer: another-value
    
    abcdefghijklmnoprstuvwxyz1234567890abcdef

    为了解决上面的这种情况(100 状态码没有数据),一个简单的HTTP1.1客户端可以通过socket读取响应;如果状态码是100,就忽略这次响应,转而读取下个响应。

    HTTP1.1服务器

    为了遵从HTTP1.1,服务器必须:

    • 从客户端的请求中得到host头。
    • 接受绝对url的请求。
    • 可以接收分块传输编码。
    • 支持‘持续连接’。
    • 恰当的使用‘100 Continue’。
    • 每个响应中包含‘Date’头。
    • 能够处理‘If-Modified-Since’和‘If-Unmodified-Since’头。
    • 最起码要支持‘GET’和‘HEAD’方法。
    • 兼容HTTP1.0的请求。

    需要Host头

    每个请求,必须包含Host头,否则就会返回‘400 Bad Request’响应,如下:

    HTTP/1.1 400 Bad Request
    Content-Type: text/html
    Content-Length: 111
    
    <html><body>
    <h2>No Host: header received</h2>
    HTTP 1.1 requests must include the Host: header.
    </body></html>

    接受绝对地址

    Host头实际上是一个过渡的解决区别host的办法。以后的HTTP版本,请求将要使用绝对地址代替路径,比如:GET http://www.somehost.com/path/file.html HTTP/1.2

    HTTP1.1服务器必须接受这种格式的请求,尽管HTTP1.1客户端不发送这样的请求。如果客户端没有host头,服务器还必须要报告错误。

    分块传输编码

    就像HTTP1.1客户必须接受分块的响应,服务器必须接受分块的请求。服务器不需要生成,分块的信息。只要能够接受分块请求就可以了。

    持久连接

    如果HTTP1.1客户端通过一个连接,发送了多个请求。为了支持持久连接,服务器返回响应的顺序应该和请求的顺序是一样的。

    如果过一个请求包含‘Connection: close’头,表示这是这个连接的最后一个请求,服务器需要在返回响应后关闭连接。服务器也会关闭超时闲置的连接。(通常设置10s超时)

    如果你不想支持持久连接,响应头中包含‘Connection: close’。这就是表示:返回当前这个响应之后,连接就会关闭。正确的支持HTTP1.1客户端能正确的接受这个头信息。

    100 Coninue

    正如HTTP1.1客户端那段描述的那样,这个响应是为了处理反应慢的连接的。

    当一个HTTP1.1服务器收到一个HTTP1.1请求,如果不是返回‘100 Continue’就是错误代码。如果它发送‘100 Continue’响应,那么接下来服务还会发送另外一个响应。‘100 Continue’不需要头,但是必须含有空行。如下:

    HTTP/1.1 100 Continue
    [blank line here]
    [another HTTP response will go here]

    不要向HTTP1.0客户端发送‘100 Continue’

    Date头

    缓存是HTTP1.1的一个重大改善,同时离不开响应的时间戳。所以,服务器返回的每个响应,必须包含Date头,表示当前时间。格式如下:Date: Fri, 31 Dec 1999 23:59:59 GMT

    除了‘1xx’的状态码的响应,所有的响应必须包括Date头。时间同一用:格林威治标准时间表示。

    If-Modified-Since和If-Unmodified-Since头

    避免发送不必要的资源,这样就节省了带宽。HTTP1.1定义了‘If-Modified-Since’和‘If-Unmodified-Since’请求头。用于表示:“只有在这个时间之后修改过的才发送”;客户端不需这些,但是HTTP1.1需要这些信息。

    不幸的是,早期的HTTP版本,时间值的格式不统一,例如:

    If-Modified-Since:  Fri, 31 Dec 1999 23:59:59 GMT
    If-Modified-Since:  Friday, 31-Dec-99 23:59:59 GMT
    If-Modified-Since:  Fri Dec 31 23:59:59 1999

    所以这次,HTTP统一使用格林威治标准时间表示。

    尽管服务器必须接受三种时间格式,HTTP1.1客户端和服务器只能生成一种时间格式。如果没有这个头,请求将返回不成功的状态码。

    If-Modified-Since头被用在GET请求上。如果请求资源在给的这段时间修改过,忽略这个头,正常的返回资源。否则返回‘304 Not Modified’响应,包含Date头,同时没有消息实体。比如:

    HTTP/1.1 304 Not Modified
    Date: Fri, 31 Dec 1999 23:59:59 GMT
    [blank line here]

    If-Unmodified-Since头和If-Modified-Since头是相似的,但是不能用于任何方法。指定的请求资源只有在字段值内指定的日期时间之后,未发生更新的情况下,才能处理请求。如果在指定日期时间后发生更新,则以状态码412 Precondition Failed作为响应返回。例如:

    HTTP/1.1 412 Precondition Failed
    [blank line here]

    支持GET和HEAD方法

    HTTP1.1服务器必须支持GET和HEAD方法。如果你正在使用CGI脚本,你需要也支持POST方法。

    HTTP1.1定义的其它四个方法(PUT, DELETE, OPTIONS, and TRACE),它们不经常被用到。如果客户端请求的方法,服务器不支持,则返回‘501 Not Implemented’,如下:

    HTTP/1.1 501 Not Implemented
    [blank line here]

    支持HTTP1.0请求

    为了兼容老的浏览器,HTTP1.1服务器必须支持HTTP1.0请求。当一个请求使用HTTP1.0:

    • 不需要Host头
    • 不能发‘100 Continue’响应

     

  • 相关阅读:
    Kafka 生产者 自定义分区策略
    同步互斥
    poj 1562 Oil Deposits(dfs)
    poj 2386 Lake Counting(dfs)
    poj 1915 KnightMoves(bfs)
    poj 1664 放苹果(dfs)
    poj 1543 Perfect Cubes (暴搜)
    poj 1166 The Clocks (暴搜)
    poj 3126 Prime Path(bfs)
    处理机调度
  • 原文地址:https://www.cnblogs.com/RichShen/p/5430219.html
Copyright © 2011-2022 走看看