本篇內(nèi)容介紹了“HTTP中的分塊傳輸編碼有什么好處”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
成都創(chuàng)新互聯(lián)是專業(yè)的肅北網(wǎng)站建設(shè)公司，肅北接單;提供做網(wǎng)站、網(wǎng)站設(shè)計(jì),網(wǎng)頁設(shè)計(jì),網(wǎng)站設(shè)計(jì),建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行肅北網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊(duì),希望更多企業(yè)前來合作!
通常情況下，HTTP的響應(yīng)消息體 message body 是作為整包發(fā)送到客戶端的，用頭『Content-Length』 來表示消息體的長度， 這個(gè)長度對(duì)客戶端非常重要，因?yàn)閷?duì)于持久連接TCP并不會(huì)在請(qǐng)求完立馬結(jié)束，而是可以發(fā)送多次請(qǐng)求/響應(yīng)，客戶端需要知道哪個(gè)位置才是響應(yīng)消息的結(jié)束，以及后續(xù)響應(yīng)的開始，因此Content-Length顯得尤為重要，服務(wù)端必須精確地告訴客戶端 message body 的長度是多少， 如果Content-Length 比實(shí)際返回的長度短，那么就會(huì)造成內(nèi)容截?cái)?，如果比?shí)體內(nèi)容長，客戶端就一直處于pendding狀態(tài)，直到所有的 message body 都返回了請(qǐng)求才結(jié)束。
Web2.0的出現(xiàn)使得網(wǎng)頁變得豐富多彩，內(nèi)容也比早期的網(wǎng)頁復(fù)雜很多，這樣就會(huì)遇到一個(gè)問題，對(duì)于一個(gè)復(fù)雜的頁面來說，如果是等到消息體完全創(chuàng)建好之后再計(jì)算出Content-Length返回給客戶端的話，在客戶端那邊會(huì)有一個(gè)漫長的等待過程，而對(duì)于用戶來說，一個(gè)頁面的所能容忍的等待時(shí)間不超過3秒，因此如何讓響應(yīng)內(nèi)容盡可能早的讓用戶看到是HTTP協(xié)議要考慮的問題。
分塊傳輸編碼（Transfer-Encoding）就是這樣一種解決方案：它把數(shù)據(jù)分解成一系列數(shù)據(jù)塊，并以多個(gè)塊發(fā)送給客戶端，服務(wù)器發(fā)送數(shù)據(jù)時(shí)不再需要預(yù)先告訴客戶端發(fā)送內(nèi)容的總大小，只需在響應(yīng)頭里面添加Transfer-Encoding: chunked，以此來告訴瀏覽器我使用的是分塊傳輸編碼，這樣就不需要 Content-Length 了，這就是分塊傳輸編碼 Transfer-Encoding 的作用。
HTTP分塊傳輸編碼允許服務(wù)器為動(dòng)態(tài)生成的內(nèi)容維持HTTP持久鏈接。通常，持久鏈接需要服務(wù)器在開始發(fā)送消息體前發(fā)送Content-Length消息頭字段，但是對(duì)于動(dòng)態(tài)生成的內(nèi)容來說，在內(nèi)容創(chuàng)建完之前是不可知的。
分塊傳輸編碼允許服務(wù)器在最后發(fā)送消息頭字段。對(duì)于那些頭字段值在內(nèi)容被生成之前無法知道的情形非常重要，例如消息的內(nèi)容要使用散列進(jìn)行簽名，散列的結(jié)果通過HTTP消息頭字段進(jìn)行傳輸。沒有分塊傳輸編碼時(shí)，服務(wù)器必須緩沖內(nèi)容直到完成后計(jì)算頭字段的值并在發(fā)送內(nèi)容前發(fā)送這些頭字段的值。
HTTP服務(wù)器有時(shí)使用壓縮（gzip）以縮短傳輸花費(fèi)的時(shí)間。分塊傳輸編碼可以用來分隔壓縮對(duì)象的多個(gè)部分。在這種情況下，塊不是分別壓縮的，而是整個(gè)負(fù)載進(jìn)行壓縮，壓縮的輸出使用本文描述的方案進(jìn)行分塊傳輸。在壓縮的情形中，分塊編碼有利于一邊進(jìn)行壓縮一邊發(fā)送數(shù)據(jù)，而不是先完成壓縮過程以得知壓縮后數(shù)據(jù)的大小。
在消息頭中指定Transfer-Encoding: chunked 就表示整個(gè)response將使用分塊傳輸編碼來傳輸內(nèi)容，一個(gè)完整的消息體由n個(gè)塊組成，并以最后一個(gè)大小為0的塊為結(jié)束。每個(gè)非空的塊包括兩部分，分別為：塊的長度（用十六進(jìn)制表示）后面跟一個(gè)CRLF （回車及換行），長度并不包括結(jié)尾的回車換行符。第二部分就是數(shù)據(jù)本身，同樣以CRLF （回車及換行）結(jié)束。最后一塊是單行，只由塊大?。?）以及CRLF組成，不包含任何數(shù)據(jù)。
現(xiàn)在就可以用Python實(shí)現(xiàn)一個(gè)簡(jiǎn)單的 HTTP Server 來指定 Response 的頭 Transfer-Encoding。
重慶分公司
重慶分公司
# -*- coding:utf-8 -*-
import socket
if __name__ == '__main__':
PORT = 8000
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.bind(('127.0.0.1', PORT))
sock.listen(1)
print 'Serving HTTP on port %s ...' % PORT
while 1:
conn, addr = sock.accept()
print conn, addr
request = conn.recv(1024)
# HTTP響應(yīng)消息
conn.sendall("HTTP/1.1 200 OK\r\n") # status line
conn.sendall("Content-Type: text/plain\r\n")
conn.sendall("Transfer-Encoding: chunked\r\n") # 聲明分塊傳輸編碼
conn.sendall("\r\n") # 空行
conn.sendall("b\r\n") # 11個(gè)字節(jié)的長度
conn.sendall("hello world\r\n") # 消息體
conn.sendall("0\r\n") # 最后一塊0長度
conn.sendall("\r\n")
conn.close()用telnet請(qǐng)求測(cè)試：
telnet localhost 8000 Trying ::1... telnet: connect to address ::1: Connection refused Trying fe80::1... telnet: connect to address fe80::1: Connection refused Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. get HTTP/1.1 / # 發(fā)送GET請(qǐng)求 HTTP/1.1 200 OK Content-Type: text/plain Transfer-Encoding: chunked b hello world 0
“HTTP中的分塊傳輸編碼有什么好處”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
