下面主要從幾個不同的方面介紹http/1.0與http/1.1之間的差別，當然，更多的內容是放在解釋這種差異背後的機制上。
可擴充套件性的乙個重要原則：如果http的某個實現接收到了自身未定義的頭域，將自動忽略它。
ø 在訊息中增加版本號，用於相容性判斷。注意，版本號只能用來判斷逐段（hop-by-hop）的相容性，而無法判斷端到端（end-to-end）的相容性。
例如，一台http/1.1的源伺服器從使用http/1.1的proxy那兒接收到一條**的訊息，實際上源伺服器並不知道終端客戶使用的是http/1.0還是http/1.1。因此，http/1.1定義via頭域，用來記錄訊息**的路徑，它記錄了整個路徑上所有傳送方使用的版本號。
ø http/1.1增加了options方法，它允許客戶端獲取乙個伺服器支援的方法列表。
ø 為了與未來的協議規範相容，http/1.1在請求訊息中包含了upgrade頭域，通過該頭域，客戶端可以讓伺服器知道它能夠支援的其它備用通訊協議，伺服器可以據此進行協議切換，使用備用協議與客戶端進行通訊。
在http/1.0中，使用expire頭域來判斷資源的fresh或stale，並使用條件請求（conditional request）來判斷資源是否仍有效。例如，cache伺服器通過if-modified-since頭域向伺服器驗證資源的last-modefied頭域是否有更新，源伺服器可能返回304（not modified），則表明該物件仍有效；也可能返回200（ok）替換請求的cache物件。
此外，http/1.0中還定義了pragma:no-cache頭域，客戶端使用該頭域說明請求資源不能從cache中獲取，而必須回源獲取。
http/1.1在1.0的基礎上加入了一些cache的新特性，當快取物件的age超過expire時變為stale物件，cache不需要直接拋棄stale物件，而是與源伺服器進行重新啟用（revalidation）。
http/1.0中，if-modified-since頭域使用的是絕對時間戳，精確到秒，但使用絕對時間會帶來不同機器上的時鐘同步問題。而http/1.1中引入了乙個etag頭域用於重啟用機制，它的值entity tag可以用來唯一的描述乙個資源。請求訊息中可以使用if-none-match頭域來匹配資源的entitytag是否有變化。
為了使caching機制更加靈活，http/1.1增加了cache-control頭域（請求訊息和響應訊息都可使用），它支援乙個可擴充套件的指令子集：例如max-age指令支援相對時間戳；private和no-store指令禁止物件被快取；no-transform阻止proxy進行任何改變響應的行為。
cache使用關鍵字索引在磁碟中快取的物件，在http/1.0中使用資源的url作為關鍵字。但可能存在不同的資源基於同乙個url的情況，要區別它們還需要客戶端提供更多的資訊，如accept-language和accept-charset頭域。為了支援這種內容協商機制(content negotiation mechanism)，http/1.1在響應訊息中引入了vary頭域，該頭域列出了請求訊息中需要包含哪些頭域用於內容協商。
http/1.1中在請求訊息中引入了range頭域，它允許只請求資源的某個部分。在響應訊息中content-range頭域宣告了返回的這部分物件的偏移值和長度。如果伺服器相應地返回了物件所請求範圍的內容，則響應碼為206（partial content），它可以防止cache將響應誤以為是完整的乙個物件。
另外一種情況是請求訊息中如果包含比較大的實體內容，但不確定伺服器是否能夠接收該請求（如是否有許可權），此時若貿然發出帶實體的請求，如果被拒絕也會浪費頻寬。
http/1.1加入了乙個新的狀態碼100（continue）。客戶端事先傳送乙個只帶頭域的請求，如果伺服器因為許可權拒絕了請求，就回送響應碼401（unauthorized）；如果伺服器接收此請求就回送響應碼100，客戶端就可以繼續傳送帶實體的完整請求了。注意，http/1.0的客戶端不支援100響應碼。但可以讓客戶端在請求訊息中加入expect頭域，並將它的值設定為100-continue。
節省頻寬資源的乙個非常有效的做法就是壓縮要傳送的資料。content-encoding是對訊息進行端到端（end-to-end）的編碼，它可能是資源在伺服器上儲存的固有格式（如jpeg格式）；在請求訊息中加入accept-encoding頭域，它可以告訴伺服器客戶端能夠解碼的編碼方式。
而transfer-encoding是逐段式（hop-by-hop）的編碼，如chunked編碼。在請求訊息中加入te頭域用來告訴伺服器能夠接收的transfer-coding方式，
http 1.0規定瀏覽器與伺服器只保持短暫的連線，瀏覽器的每次請求都需要與伺服器建立乙個tcp連線，伺服器完成請求處理後立即斷開tcp連線，伺服器不跟蹤每個客戶也不記錄過去的請求。此外，由於大多數網頁的流量都比較小，一次tcp連線很少能通過slow-start區，不利於提高頻寬利用率。
http 1.1支援長連線（persistentconnection）和請求的流水線（pipelining）處理，在乙個tcp連線上可以傳送多個http請求和響應，減少了建立和關閉連線的消耗和延遲。例如：乙個包含有許多影象的網頁檔案的多個請求和應答可以在乙個連線中傳輸，但每個單獨的網頁檔案的請求和應答仍然需要使用各自的連線。
在http/1.0中，要建立長連線，可以在請求訊息中包含connection: keep-alive頭域，如果伺服器願意維持這條連線，在響應訊息中也會包含乙個connection: keep-alive的頭域。同時，可以加入一些指令描述該長連線的屬性，如max，timeout等。
事實上，connection頭域可以攜帶三種不同型別的符號：
1、乙個包含若干個頭網域名稱的列表，宣告僅限於一次hop連線的頭域資訊；
2、任意值，本次連線的非標準選項，如keep-alive等；
3、close值，表示訊息傳送完成之後關閉長連線；
客戶端和源伺服器之間的訊息傳遞可能要經過很多中間節點的**，這是一種逐跳傳遞（hop-by-hop）。http/1.1相應地引入了hop-by-hop頭域，這種頭域僅作用於一次hop，而非整個傳遞路徑。每乙個中間節點（如proxy，gateway）接收到的訊息中如果包含connection頭域，會查詢connection頭域中的乙個頭網域名稱列表，並在將訊息**給下乙個節點之前先刪除訊息中這些頭域。
通常，http/1.0的proxy不支援connection頭域，為了不讓它們**可能誤導接收者的頭域，協議規定所有出現在connection頭域中的頭網域名稱都將被忽略。
http訊息中可以包含任意長度的實體，通常它們使用content-length來給出訊息結束標誌。但是，對於很多動態產生的響應，只能通過緩衝完整的訊息來判斷訊息的大小，但這樣做會加大延遲。如果不使用長連線，還可以通過連線關閉的訊號來判定乙個訊息的結束。
http/1.1中引入了chunkedtransfer-coding來解決上面這個問題，傳送方將訊息分割成若干個任意大小的資料塊，每個資料塊在傳送時都會附上塊的長度，最後用乙個零長度的塊作為訊息結束的標誌。這種方法允許傳送方只緩衝訊息的乙個片段，避免緩衝整個訊息帶來的過載。
在http/1.0中，有乙個content-md5的頭域，要計算這個頭域需要傳送方緩衝完整個訊息後才能進行。而http/1.1中，採用chunked分塊傳遞的訊息在最後乙個塊（零長度）結束之後會再傳遞乙個拖尾（trailer），它包含乙個或多個頭域，這些頭域是傳送方在傳遞完所有塊之後再計算出值的。傳送方會在訊息中包含乙個trailer頭域告訴接收方這個拖尾的存在。
在http1.0中認為每台伺服器都繫結乙個唯一的ip位址，因此，請求訊息中的url並沒有傳遞主機名（hostname）。但隨著虛擬主機技術的發展，在一台物理伺服器上可以存在多個虛擬主機（multi-homed web servers），並且它們共享乙個ip位址。
http1.1的請求訊息和響應訊息都應支援host頭域，且請求訊息中如果沒有host頭域會報告乙個錯誤（400 bad request）。此外，伺服器應該接受以絕對路徑標記的資源請求。
http/1.0中只定義了16個狀態響應碼，對錯誤或警告的提示不夠具體。http/1.1引入了乙個warning頭域，增加對錯誤或警告資訊的描述。
此外，在http/1.1中新增了24個狀態響應碼，如409（conflict）表示請求的資源與資源的當前狀態發生衝突；410（gone）表示伺服器上的某個資源被永久性的刪除。
為了滿足網際網路使用不同母語和字符集的使用者，一些網路資源有不同的語言版本（如中文版、英文版）。http/1.0定義了內容協商（contentnegotiation）的概念，也就是說客戶端可以告訴伺服器自己可以接收以何種語言（或字符集）表示的資源。例如如果伺服器不能明確客戶端需要何種型別的資源，會返回300（multiple choices），幷包含乙個列表，用來宣告該資源的不同可用版本，然後客戶端在請求訊息中包含accept-language和accept-charset頭域指定需要的版本。
就像有些人會說幾門外語，但每種外語的流利程度並不相同。類似地，網路資源也可以有不同的表達形式，比如有母語版和各種翻譯版本。http引入了乙個品質因子（quality values）的概念來表示不同版本的可用性，它的取值從0.0到1.0。例如乙個母語是英語的人也能**語、甚至還學了點丹麥語，那麼他的瀏覽器可用作如下配置：accept-language: en, fr;q=0.5, da;q=0.1。這時，伺服器會優先選取品質因子高的值對應的資源版本作為響應。
Http1 1與Http1 0的比較
上篇部落格 web開發基礎 http1.0協議 客戶端與伺服器端的互動 1 允許在乙個 tcp連線上 可以傳送多個http請求和響應 這樣乙個包含多個影象的網頁的多個請求和響應就可以在乙個連線中進行傳輸了 但是每個單獨的網頁檔案的請求和 仍然還是需要使用各自的連線的。2 允許客戶端不用等待上一次的請...
HTTP1 0與HTTP1 1的區別
下面主要從幾個不同的方面介紹 http 1.0與http 1.1 之間的差別，當然，更多的內容是放在解釋這種差異背後的機制上。1 可擴充套件性 可擴充套件性的乙個重要原則 如果http的某個實現接收到了自身未定義的頭域，將自動忽略它。在訊息中增加版本號，用於相容性判斷。注意，版本號只能用來判斷逐段 ...
HTTP1 0與HTTP1 1的區別
1.效能方面 html1.0只支援短連線，在頁面需要載入其他，css，js檔案時，會有多次建立，斷開連線的過程。並且客戶端的每個請求必須等上乙個請求結果返回後，才可以傳送下乙個請求。這兩點令html1.0的執行效率很低。而html1.1支援長連線，並且允許客戶端在上乙個結果返回之前就傳送下乙個請求，...