摘要：分塊傳輸編碼使用字段的前提條件是，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長(zhǎng)度。最后是一個(gè)大小為的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。

文章有不當(dāng)之處，歡迎指正，如果喜歡微信閱讀，你也可以關(guān)注我的微信公眾號(hào)：好好學(xué)java，獲取優(yōu)質(zhì)學(xué)習(xí)資源。

協(xié)議，網(wǎng)絡(luò)協(xié)議的簡(jiǎn)稱，網(wǎng)絡(luò)協(xié)議是通信計(jì)算機(jī)雙方必須共同遵從的一組約定。如怎么樣建立連接、怎么樣互相識(shí)別等。只有遵守這個(gè)約定，計(jì)算機(jī)之間才能相互通信交流。它的三要素是：語(yǔ)法、語(yǔ)義、時(shí)序。

為了使數(shù)據(jù)在網(wǎng)絡(luò)上從源到達(dá)目的，網(wǎng)絡(luò)通信的參與方必須遵循相同的規(guī)則，這套規(guī)則稱為協(xié)議（protocol），它最終體現(xiàn)為在網(wǎng)絡(luò)上傳輸?shù)臄?shù)據(jù)包的格式。

協(xié)議往往分成幾個(gè)層次進(jìn)行定義，分層定義是為了使某一層協(xié)議的改變不影響其他層次的協(xié)議。

超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。1960年美國(guó)人Ted Nelson構(gòu)思了一種通過計(jì)算機(jī)處理文本信息的方法，并稱之為超文本（hypertext）,這成為了HTTP超文本傳輸協(xié)議標(biāo)準(zhǔn)架構(gòu)的發(fā)展根基。Ted Nelson組織協(xié)調(diào)萬維網(wǎng)協(xié)會(huì)（World Wide Web Consortium）和互聯(lián)網(wǎng)工程工作小組（Internet Engineering Task Force ）共同合作研究，最終發(fā)布了一系列的RFC，其中著名的RFC 2616定義了HTTP 1.1

簡(jiǎn)介

1996年5月，HTTP/1.0 版本發(fā)布，內(nèi)容大大增加。

首先，任何格式的內(nèi)容都可以發(fā)送。這使得互聯(lián)網(wǎng)不僅可以傳輸文字，還能傳輸圖像、視頻、二進(jìn)制文件。這為互聯(lián)網(wǎng)的大發(fā)展奠定了基礎(chǔ)。

其次，除了GET命令，還引入了POST命令和HEAD命令，豐富了瀏覽器與服務(wù)器的互動(dòng)手段。

再次，HTTP請(qǐng)求和回應(yīng)的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。

其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權(quán)限（authorization）、緩存（cache）、內(nèi)容編碼（content encoding）等。

請(qǐng)求格式

下面是一個(gè)1.0版的HTTP請(qǐng)求的例子。

    GET / HTTP/1.0
    User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5)
    Accept: */*

可以看到，這個(gè)格式與0.9版有很大變化。

第一行是請(qǐng)求命令，必須在尾部添加協(xié)議版本（HTTP/1.0）。后面就是多行頭信息，描述客戶端的情況。

回應(yīng)格式

服務(wù)器的回應(yīng)如下。

    HTTP/1.0 200 OK 
    Content-Type: text/plain
    Content-Length: 137582
    Expires: Thu, 05 Dec 1997 16:00:00 GMT
    Last-Modified: Wed, 5 August 1996 15:55:28 GMT
    Server: Apache 0.84

回應(yīng)的格式是"頭信息 + 一個(gè)空行（rn） + 數(shù)據(jù)"。其中，第一行是"協(xié)議版本 + 狀態(tài)碼（status code） + 狀態(tài)描述"。

Content-Type 字段

關(guān)于字符的編碼，1.0版規(guī)定，頭信息必須是 ASCII 碼，后面的數(shù)據(jù)可以是任何格式。因此，服務(wù)器回應(yīng)的時(shí)候，必須告訴客戶端，數(shù)據(jù)是什么格式，這就是Content-Type字段的作用。

下面是一些常見的Content-Type字段的值。

        text/plain
        text/html
        text/css
        image/jpeg
        image/png
        image/svg+xml
        audio/mp4
        video/mp4
        application/javascript
        application/pdf
        application/zip
        application/atom+xml

這些數(shù)據(jù)類型總稱為MIME type，每個(gè)值包括一級(jí)類型和二級(jí)類型，之間用斜杠分隔。

除了預(yù)定義的類型，廠商也可以自定義類型。

    application/vnd.debian.binary-package

上面的類型表明，發(fā)送的是Debian系統(tǒng)的二進(jìn)制數(shù)據(jù)包。

MIME type還可以在尾部使用分號(hào)，添加參數(shù)。

    Content-Type: text/html; charset=utf-8

上面的類型表明，發(fā)送的是網(wǎng)頁(yè)，而且編碼是UTF-8。

客戶端請(qǐng)求的時(shí)候，可以使用Accept字段聲明自己可以接受哪些數(shù)據(jù)格式。

    Accept: */*

上面代碼中，客戶端聲明自己可以接受任何格式的數(shù)據(jù)。

MIME type不僅用在HTTP協(xié)議，還可以用在其他地方，比如HTML網(wǎng)頁(yè)。

Content-Encoding 字段

由于發(fā)送的數(shù)據(jù)可以是任何格式，因此可以把數(shù)據(jù)壓縮后再發(fā)送。Content-Encoding字段說明數(shù)據(jù)的壓縮方法。

    Content-Encoding: gzip
    Content-Encoding: compress
    Content-Encoding: deflate

客戶端在請(qǐng)求時(shí)，用Accept-Encoding字段說明自己可以接受哪些壓縮方法。

    Accept-Encoding: gzip, deflate

缺點(diǎn)

HTTP/1.0 版的主要缺點(diǎn)是，每個(gè)TCP連接只能發(fā)送一個(gè)請(qǐng)求。發(fā)送數(shù)據(jù)完畢，連接就關(guān)閉，如果還要請(qǐng)求其他資源，就必須再新建一個(gè)連接。

TCP連接的新建成本很高，因?yàn)樾枰蛻舳撕头?wù)器三次握手，并且開始時(shí)發(fā)送速率較慢（slow start）。所以，HTTP 1.0版本的性能比較差。隨著網(wǎng)頁(yè)加載的外部資源越來越多，這個(gè)問題就愈發(fā)突出了。

為了解決這個(gè)問題，有些瀏覽器在請(qǐng)求時(shí)，用了一個(gè)非標(biāo)準(zhǔn)的Connection字段。

    Connection: keep-alive

這個(gè)字段要求服務(wù)器不要關(guān)閉TCP連接，以便其他請(qǐng)求復(fù)用。服務(wù)器同樣回應(yīng)這個(gè)字段。

    Connection: keep-alive

一個(gè)可以復(fù)用的TCP連接就建立了，直到客戶端或服務(wù)器主動(dòng)關(guān)閉連接。但是，這不是標(biāo)準(zhǔn)字段，不同實(shí)現(xiàn)的行為可能不一致，因此不是根本的解決辦法。

1997年1月，HTTP/1.1 版本發(fā)布，只比 1.0 版本晚了半年。它進(jìn)一步完善了 HTTP 協(xié)議，一直用到了20年后的今天，直到現(xiàn)在還是最流行的版本。

持久連接

1.1 版的最大變化，就是引入了持久連接（persistent connection），即TCP連接默認(rèn)不關(guān)閉，可以被多個(gè)請(qǐng)求復(fù)用，不用聲明Connection: keep-alive。

客戶端和服務(wù)器發(fā)現(xiàn)對(duì)方一段時(shí)間沒有活動(dòng)，就可以主動(dòng)關(guān)閉連接。不過，規(guī)范的做法是，客戶端在最后一個(gè)請(qǐng)求時(shí)，發(fā)送Connection: close，明確要求服務(wù)器關(guān)閉TCP連接。

    Connection: close

目前，對(duì)于同一個(gè)域名，大多數(shù)瀏覽器允許同時(shí)建立6個(gè)持久連接。

管道機(jī)制

1.1 版還引入了管道機(jī)制（pipelining），即在同一個(gè)TCP連接里面，客戶端可以同時(shí)發(fā)送多個(gè)請(qǐng)求。這樣就進(jìn)一步改進(jìn)了HTTP協(xié)議的效率。

舉例來說，客戶端需要請(qǐng)求兩個(gè)資源。以前的做法是，在同一個(gè)TCP連接里面，先發(fā)送A請(qǐng)求，然后等待服務(wù)器做出回應(yīng)，收到后再發(fā)出B請(qǐng)求。管道機(jī)制則是允許瀏覽器同時(shí)發(fā)出A請(qǐng)求和B請(qǐng)求，但是服務(wù)器還是按照順序，先回應(yīng)A請(qǐng)求，完成后再回應(yīng)B請(qǐng)求。

Content-Length 字段

一個(gè)TCP連接現(xiàn)在可以傳送多個(gè)回應(yīng)，勢(shì)必就要有一種機(jī)制，區(qū)分?jǐn)?shù)據(jù)包是屬于哪一個(gè)回應(yīng)的。這就是Content-length字段的作用，聲明本次回應(yīng)的數(shù)據(jù)長(zhǎng)度。

    Content-Length: 3495

上面代碼告訴瀏覽器，本次回應(yīng)的長(zhǎng)度是3495個(gè)字節(jié)，后面的字節(jié)就屬于下一個(gè)回應(yīng)了。

在1.0版中，Content-Length字段不是必需的，因?yàn)闉g覽器發(fā)現(xiàn)服務(wù)器關(guān)閉了TCP連接，就表明收到的數(shù)據(jù)包已經(jīng)全了。

分塊傳輸編碼

使用Content-Length字段的前提條件是，服務(wù)器發(fā)送回應(yīng)之前，必須知道回應(yīng)的數(shù)據(jù)長(zhǎng)度。

對(duì)于一些很耗時(shí)的動(dòng)態(tài)操作來說，這意味著，服務(wù)器要等到所有操作完成，才能發(fā)送數(shù)據(jù)，顯然這樣的效率不高。更好的處理方法是，產(chǎn)生一塊數(shù)據(jù)，就發(fā)送一塊，采用"流模式"（stream）取代"緩存模式"（buffer）。

因此，1.1版規(guī)定可以不使用Content-Length字段，而使用"分塊傳輸編碼"（chunked transfer encoding）。只要請(qǐng)求或回應(yīng)的頭信息有Transfer-Encoding字段，就表明回應(yīng)將由數(shù)量未定的數(shù)據(jù)塊組成。

    Transfer-Encoding: chunked

每個(gè)非空的數(shù)據(jù)塊之前，會(huì)有一個(gè)16進(jìn)制的數(shù)值，表示這個(gè)塊的長(zhǎng)度。最后是一個(gè)大小為0的塊，就表示本次回應(yīng)的數(shù)據(jù)發(fā)送完了。下面是一個(gè)例子。

    HTTP/1.1 200 OK
    Content-Type: text/plain
    Transfer-Encoding: chunked

    25
    This is the data in the first chunk

    1C
    and this is the second one

    3
    con

    8
    sequence

    0

其他功能

1.1版還新增了許多動(dòng)詞方法：PUT、PATCH、HEAD、 OPTIONS、DELETE。

另外，客戶端請(qǐng)求的頭信息新增了Host字段，用來指定服務(wù)器的域名。

    Host: www.example.com

有了Host字段，就可以將請(qǐng)求發(fā)往同一臺(tái)服務(wù)器上的不同網(wǎng)站，為虛擬主機(jī)的興起打下了基礎(chǔ)。

缺點(diǎn)

雖然1.1版允許復(fù)用TCP連接，但是同一個(gè)TCP連接里面，所有的數(shù)據(jù)通信是按次序進(jìn)行的。服務(wù)器只有處理完一個(gè)回應(yīng)，才會(huì)進(jìn)行下一個(gè)回應(yīng)。要是前面的回應(yīng)特別慢，后面就會(huì)有許多請(qǐng)求排隊(duì)等著。這稱為"隊(duì)頭堵塞"（Head-of-line blocking）。

為了避免這個(gè)問題，只有兩種方法：一是減少請(qǐng)求數(shù)，二是同時(shí)多開持久連接。這導(dǎo)致了很多的網(wǎng)頁(yè)優(yōu)化技巧，比如合并腳本和樣式表、將圖片嵌入CSS代碼、域名分片（domain sharding）等等。如果HTTP協(xié)議設(shè)計(jì)得更好一些，這些額外的工作是可以避免的。

請(qǐng)求的數(shù)據(jù)里面包含三個(gè)部分內(nèi)容 ： 請(qǐng)求行 、 請(qǐng)求頭 、請(qǐng)求體

請(qǐng)求行

POST /examples/servlets/servlet/RequestParamExample HTTP/1.1 //請(qǐng)求路徑

POST ：請(qǐng)求方式 ，以post去提交數(shù)據(jù)

/examples/servlets/servlet/RequestParamExample
請(qǐng)求的地址路徑 ， 就是要訪問哪個(gè)地方。

HTTP/1.1: 協(xié)議版本

請(qǐng)求頭

        Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, */*
        Referer: http://localhost:8080/examples/servlets/servlet/RequestParamExample
        Accept-Language: zh-CN
        User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)
        Content-Type: application/x-www-form-urlencoded
        Accept-Encoding: gzip, deflate
        Host: localhost:8080
        Content-Length: 31
        Connection: Keep-Alive
        Cache-Control: no-cache

Accept: 客戶端向服務(wù)器端表示，我能支持什么類型的數(shù)據(jù)。
Referer ： 真正請(qǐng)求的地址路徑，全路徑
Accept-Language: 支持語(yǔ)言格式
User-Agent: 用戶代理 向服務(wù)器表明，當(dāng)前來訪的客戶端信息。
Content-Type： 提交的數(shù)據(jù)類型。經(jīng)過urlencoding編碼的form表單的數(shù)據(jù)
Accept-Encoding： gzip, deflate ： 壓縮算法 。
Host ： 主機(jī)地址
Content-Length： 數(shù)據(jù)長(zhǎng)度
Connection : Keep-Alive 保持連接
Cache-Control ： 對(duì)緩存的操作

請(qǐng)求體

瀏覽器真正發(fā)送給服務(wù)器的數(shù)據(jù)

發(fā)送的數(shù)據(jù)呈現(xiàn)的是key=value,如果存在多個(gè)數(shù)據(jù)，那么使用 &firstname=zhang&lastname=sansan

請(qǐng)求的數(shù)據(jù)里面包含三個(gè)部分內(nèi)容 ： 響應(yīng)行 、 響應(yīng)頭 、響應(yīng)體

    HTTP/1.1 200 OK
    Server: Apache-Coyote/1.1
    Content-Type: text/html;charset=ISO-8859-1
    Content-Length: 673
    Date: Fri, 17 Feb 2017 02:53:02 GMT

    ...這里還有很多數(shù)據(jù)...

響應(yīng)行

        HTTP/1.1 200 OK

HTTP/1.1:協(xié)議版本

200:狀態(tài)碼

咱們這次交互到底是什么樣結(jié)果的一個(gè)code.

200 : 成功，正常處理，得到數(shù)據(jù)。
403 : for bidden 拒絕
404 ： Not Found
500 ： 服務(wù)器異常

OK:對(duì)應(yīng)前面的狀態(tài)碼

響應(yīng)頭

        Server:  服務(wù)器是哪一種類型。  Tomcat
    
        Content-Type ： 服務(wù)器返回給客戶端你的內(nèi)容類型

        Content-Length ： 返回的數(shù)據(jù)長(zhǎng)度

        Date ： 通訊的日期，響應(yīng)的時(shí)間    

HTTP之狀態(tài)碼

狀態(tài)代碼有三位數(shù)字組成，第一個(gè)數(shù)字定義了響應(yīng)的類別，共分五種類別:

1xx：指示信息--表示請(qǐng)求已接收，繼續(xù)處理
2xx：成功--表示請(qǐng)求已被成功接收、理解、接受
3xx：重定向--要完成請(qǐng)求必須進(jìn)行更進(jìn)一步的操作
4xx：客戶端錯(cuò)誤--請(qǐng)求有語(yǔ)法錯(cuò)誤或請(qǐng)求無法實(shí)現(xiàn)
5xx：服務(wù)器端錯(cuò)誤--服務(wù)器未能實(shí)現(xiàn)合法的請(qǐng)求

常見狀態(tài)碼

200 OK                        //客戶端請(qǐng)求成功
400 Bad Request               //客戶端請(qǐng)求有語(yǔ)法錯(cuò)誤，不能被服務(wù)器所理解
401 Unauthorized              //請(qǐng)求未經(jīng)授權(quán)，這個(gè)狀態(tài)代碼必須和WWW-Authenticate報(bào)頭域一起使用 
403 Forbidden                 //服務(wù)器收到請(qǐng)求，但是拒絕提供服務(wù)
404 Not Found                 //請(qǐng)求資源不存在，eg：輸入了錯(cuò)誤的URL
500 Internal Server Error     //服務(wù)器發(fā)生不可預(yù)期的錯(cuò)誤
503 Server Unavailable        //服務(wù)器當(dāng)前不能處理客戶端的請(qǐng)求，一段時(shí)間后可能恢復(fù)正常

更多狀態(tài)碼 http://www.runoob.com/http/ht...

Get 和 Post請(qǐng)求區(qū)別

post

數(shù)據(jù)是以流的方式寫過去，不會(huì)在地址欄上面顯示。 現(xiàn)在一般提交數(shù)據(jù)到服務(wù)器使用的都是POST

以流的方式寫數(shù)據(jù)，所以數(shù)據(jù)沒有大小限制。

get

會(huì)在地址欄后面拼接數(shù)據(jù)，所以有安全隱患。 一般從服務(wù)器獲取數(shù)據(jù)，并且客戶端也不用提交上面數(shù)據(jù)的時(shí)候，可以使用GET

能夠帶的數(shù)據(jù)有限， 1kb大小

HTTP協(xié)議定義Web客戶端如何從Web服務(wù)器請(qǐng)求Web頁(yè)面，以及服務(wù)器如何把Web頁(yè)面?zhèn)魉徒o客戶端。HTTP協(xié)議采用了請(qǐng)求/響應(yīng)模型。客戶端向服務(wù)器發(fā)送一個(gè)請(qǐng)求報(bào)文，請(qǐng)求報(bào)文包含請(qǐng)求的方法、URL、協(xié)議版本、請(qǐng)求頭部和請(qǐng)求數(shù)據(jù)。服務(wù)器以一個(gè)狀態(tài)行作為響應(yīng)，響應(yīng)的內(nèi)容包括協(xié)議的版本、成功或者錯(cuò)誤代碼、服務(wù)器信息、響應(yīng)頭部和響應(yīng)數(shù)據(jù)。

以下是 HTTP 請(qǐng)求/響應(yīng)的步驟：

1、客戶端連接到Web服務(wù)器

一個(gè)HTTP客戶端，通常是瀏覽器，與Web服務(wù)器的HTTP端口（默認(rèn)為80）建立一個(gè)TCP套接字連接。

2、發(fā)送HTTP請(qǐng)求

通過TCP套接字，客戶端向Web服務(wù)器發(fā)送一個(gè)文本的請(qǐng)求報(bào)文，一個(gè)請(qǐng)求報(bào)文由請(qǐng)求行、請(qǐng)求頭部、空行和請(qǐng)求數(shù)據(jù)4部分組成。

3、服務(wù)器接受請(qǐng)求并返回HTTP響應(yīng)

Web服務(wù)器解析請(qǐng)求，定位請(qǐng)求資源。服務(wù)器將資源復(fù)本寫到TCP套接字，由客戶端讀取。一個(gè)響應(yīng)由狀態(tài)行、響應(yīng)頭部、空行和響應(yīng)數(shù)據(jù)4部分組成。

4、釋放連接TCP連接

若connection 模式為close，則服務(wù)器主動(dòng)關(guān)閉TCP連接，客戶端被動(dòng)關(guān)閉連接，釋放TCP連接;若connection 模式為keepalive，則該連接會(huì)保持一段時(shí)間，在該時(shí)間內(nèi)可以繼續(xù)接收請(qǐng)求;

5、客戶端瀏覽器解析HTML內(nèi)容

客戶端瀏覽器首先解析狀態(tài)行，查看表明請(qǐng)求是否成功的狀態(tài)代碼。然后解析每一個(gè)響應(yīng)頭，響應(yīng)頭告知以下為若干字節(jié)的HTML文檔和文檔的字符集?？蛻舳藶g覽器讀取響應(yīng)數(shù)據(jù)HTML，根據(jù)HTML的語(yǔ)法對(duì)其進(jìn)行格式化，并在瀏覽器窗口中顯示。

例如：在瀏覽器地址欄鍵入U(xiǎn)RL，按下回車之后會(huì)經(jīng)歷以下流程：

1、瀏覽器向 DNS 服務(wù)器請(qǐng)求解析該 URL 中的域名所對(duì)應(yīng)的 IP 地址;

2、解析出 IP 地址后，根據(jù)該 IP 地址和默認(rèn)端口 80，和服務(wù)器建立TCP連接;

3、瀏覽器發(fā)出讀取文件(URL 中域名后面部分對(duì)應(yīng)的文件)的HTTP 請(qǐng)求，該請(qǐng)求報(bào)文作為 TCP 三次握手的第三個(gè)報(bào)文的數(shù)據(jù)發(fā)送給服務(wù)器;

4、服務(wù)器對(duì)瀏覽器請(qǐng)求作出響應(yīng)，并把對(duì)應(yīng)的 html 文本發(fā)送給瀏覽器;

5、釋放 TCP連接;

6、瀏覽器將該 html 文本并顯示內(nèi)容;

參考資料

http://www.ruanyifeng.com/blo...

https://blog.csdn.net/green70...

https://www.jianshu.com/p/80e...

http://blog.51cto.com/1280510...