1、HTTP/1.1默認持久連接和流水線
HTTP/1.1默認使用持久連接，只要客戶端服務端任意一端沒有明確提出斷開TCP連接，就一直保持連接，在同一個TCP連接下，可以發送多次HTTP請求。
同時，默認采用流水線的方式發送請求，即客戶端每遇到一個對象引用就立即發出一個請求，而不必等到收到前一個響應之后才能發出下一個請求;
但服務器端必須按照接收到客戶端請求的先后順序依次回送相應結果，以保證客戶端能夠區分出每次請求的相應內容，這樣也顯著地減少了整個下載過程所需要的時間。
HTTP/1.0默認使用短連接，要建立長連接，可以在請求消息中包含Connection: Keep-Alive頭域；
如果服務器願意維持這條連接，在響應消息中也會包含一個Connection: Keep-Alive的頭域。
Connection請求頭的值為Keep-Alive時，客戶端通知服務器返回本次請求資源過后保持連接；Connection請求頭的值為close時，客戶端通知服務器返回本次請求結果后關閉連接。
2、分塊傳輸數據
HTTP/1.0可用來指定實體長度的唯一機制是通過Content-Length字段。靜態資源的長度可以很容易的確定；
但是對於動態生成的響應來說，為獲取它的真實長度，只能等它完全生成之后，才能正確地填寫Content-Length的值，這便要求緩存整個響應，在服務器端占用大量的緩存，從而延長了響應用戶的時間。【服務端在沒有分塊返回所有請求資源的情況下，首先會在本地緩存所有動態的請求資源，緩存完成后計算請求資源的實體長度】
HTTP/1.1引入了被稱為分塊（chunked）的傳輸方法。該方法使發送方能將消息實體分割為任意大小的組塊（chunk），並單獨地發送它們。
在每個組塊前面，都加上了該組塊的長度，使接收方可確保自己能夠完整地接收到這個組塊。更重要的是，在最末尾的地方，發送方生成了長度為零的組塊，接收方可據此判斷整條消息都已安全地傳輸完畢。這樣也避免了在服務器端占用大量的的緩存。
Transfer-Encoding:chunked字段向接收方指出：響應將被分組塊，對響應分析時，應采取不同於非分組塊的方式。
3、狀態碼 100 Continue
HTTP/1.1加入了一個新的狀態碼 100 Continue，用於客戶端在發送POST數據給服務器前，征詢服務器的情況，看服務器是否處理POST數據。
當要POST的數據大於1024字節的時候，客戶端並不會直接就發起了POST請求，而是會分為2步：
（1）發送一個請求，包含一個Except: 100-continue，詢問Server是否願意接受數據。
（2）接收到Server返回的100 continue應答以后，才把數據POST給Server。
這種情況通常發生在客戶端准備發送一個冗長的請求給服務器，但是不確認服務器是否有能力接收。如果沒有得到確認，而將一個冗長的請求包發送給服務器，然后包被服務器給拋棄了，這種情況挺浪費資源的。
4、Host域
HTTP1.1在Request消息頭里多了一個Host域，HTTP1.0則沒有這個域。在HTTP1.0中認為每台服務器都綁定一個唯一的IP地址，這個IP地址上只有一個主機。但隨着虛擬主機技術的發展，在一台物理服務器上可以存在多個虛擬主機，並且它們共享一個IP地址。