在http 1.1 版本中有以下新特性：
1、預設持久連線，
節省通訊量，只要客戶端和服務端任意一端沒有明確的斷開tcp連線，就可以傳送多次http請求
2、管線化
客戶端可以同時傳送多個http請求，而不用乙個個等待響應
3、斷點續傳原理
當客戶端請求續傳時，客戶端需要在http頭中宣告本次需要續傳的片斷，如下：
range: bytes=500000——這個頭通知伺服器從檔案的500k位置開始傳檔案
伺服器收到斷點續傳請求後，從檔案的500k位置開始傳輸檔案，並在http頭開始增加content-range:bytes=500000-1024000
並且此時伺服器端返回的http狀態碼應該是206，而不是200
實際上，會出現一種請況，就是在終端發起續傳請求時，url對應的檔案內容在伺服器端已經發生變化，因此續傳的資料肯定是錯誤的，解決方法如下：
怎樣判斷檔案是否已發生修改呢？
我們先了解一下http它的二次請求原理：
當客戶端第一次請求資源時，伺服器除了返回本次請求額資源以外，還在頭資訊中返回幾個重要屬性：
①、last-modified// 最後修改時間如： last-modified thu, 26 nov 2009 13:50:19 gmt
②、etag// 指示資源的狀態唯一標識如：etag 「8fb8b-14-4794674acdcc0″
if-modified-since thu, 26 nov 2009 13:50:19 gmt
if-none-match 」8fb8b-14-4794674acdcc0″
伺服器會判斷該檔案從上次時間到現在都沒有過修改或者etag資訊沒有變化，
伺服器判斷傳送過來的etag和計算出來的etag匹配，因此if-none-match為false，不返回200，返回304，並返回etag，etag值不變，客戶端繼續使用本地快取，
因此，有兩種方法判斷檔案是否發生修改：
1、可以last-modified來識別檔案的最後修改時間，
2、可以使用etag給檔案設定唯一標識
一般我們都是用etag來判斷檔案是否修改，用etag來解決last-modified不能解決的問題，原因如下：
1、一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get;
2、某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是s級的，這種修改無法判斷(或者說unix記錄
mtime只能精確到秒)
3、某些伺服器不能精確的得到檔案的最後修改時間；
NHibernate 3版本新特性
在configuration部分新增兩種loquacious configuration方式 流配置 fluent configuration 和lambda表示式配置 lambda configuration fluent configuration顧名思義，使用fluent api配置sessi...
Swift 1 2版本新特性
隨著xcode6.3正式版本的推出，swift語言也正式進入1.2版本，那麼1.2版本有什麼新特性呢？來快速了解一下吧。1.速度的提公升 速度的提公升首先體現在對工程中增量的單獨編譯，這使得我們在改動較大的工程的時候，執行速度會得到大幅度的提公升。其次體現在swift自己的執行庫的執行時性的增強。s...
Web效能（三） HTTP1 1的特性
請公升級到http1.1 完了 解決問題的核心就是 消除和減少不必要的網路延遲，把傳輸的位元組數降到最少。持久連線的優點 非持久http連線的代價 持久http連線的好處 http管道 並行處理請求 管道弊端 隊首阻塞問題 被大多瀏覽器禁用 並行tcp連線 並行的好處 並行的代價 網域名稱分割槽 每...