一、 說明 正常流程：第一個請求miss ，在第一個請求store_ok以后，以后的請求再訪問相同url則是hit。? 折疊流程： 第一個請求處理miss回源過程中，還沒有store_ok之前，第二個請求進來了。squid對該時期有兩種做法，如下： collapsed_forwarding on ?第一個請求進入miss后，即創建storeentry，以后的請求來了，就會hit。 collapsed_forwarding off ?第一個請求進入miss后， 在還沒有處理源站響應包頭之前。第二個請求也會miss。
二、詳解 正常流程沒什么可說的，來說說折疊流程。 在說之前先嘮叨下squid中storeSetPrivateKey和storeSetPublicKey 。 storeSetPrivateKey： 將entry設置PRIVATE標志，通過storeKeyPrivate（url，method，id）hash 獲得一個key，并且storeHashInsert（e,key）。 一般私有只能當前request用，其他request不可見。 storeSetPublicKey：將entry的PRIVATE標志清楚、通過storeKeyPublic（url,method）hash獲得一個key，并且storeHashInsert（e,key）。這個可共用，在后來的請求判斷是否命中時，都用publichash。
1、collapsed_forwarding on?折疊回源開啟 第一個請求 a、進入miss，clientprocessmiss，http->entrty為null，clientCreateStoreEntry->storeCreateEntry->storeSetPrivateKey. 將新建entry打上私有標簽 b、clientprocessmiss，進入Config.onoff.collapsed_forwarding條件分支，進入storeSetPublicKey。 c、storeSetPublicKey是將將之前的entry（當然此處沒有，因為第一個嘛）變成private ，將當前的entry變成public。
?第二個請求 a、進入clientProcessRequest， 進入clientProcessRequest2，e = http->entry = storeGetPublicByRequest(r)，判斷是否需緩存，如可緩存且entry不為null（當然不為null，第一個請求創建的），則hit。 b、當然如果源站有no_cache字段，第一個請求會給entry設置release標志且不會swapout，第二個請求會進入到內存命中，然后判斷是否有release標志，如有則miss。 2、collapsed_forwarding off 折疊回源關閉?? 第一個請求 a、進入miss，clientprocessmiss，http->entrty為null，clientCreateStoreEntry->storeCreateEntry->storeSetPrivateKey. 將新建entry打上私有標簽 b、讀事件，httpReadReply->httpProcessReplyHeader -->switch (httpCachableReply(httpState, &ncr)(是否緩存)) { case 1（可緩存）:httpMakePublic(entry);)-->?storeSetPublicKey（同上） c、在第一個請求的回源讀事件前，可能有其他請求過來。 第二個請求 a、在第一個請求沒有讀到源站數據前進入clientProcessRequest，進入clientProcessRequest2，e = http->entry = storeGetPublicByRequest(r)， 因第一個請求時用private key 插入道storehash，所以第二個請求用public key找不到entry，然后走miss流程。 b、這樣第一個和第二個請求都miss回源，都會有自己的storeentry。第二個請求產生的storeentry也通過第一個請求處理的方式a 將storeentry打上私有標志并插入到storetable中。 c、參考第一個請求處理方式b，storeSetPublicKey將之前的entry變成storeSetPrivateKey，將當前的entry變成storeSetPublicKey。
3、源站no_cache ? ??a、假如request2就是一個這樣的請求，它發生在在request1拿到原站的數據之前，并找到了request1創建的StoreEntry，而且“以為”自己hit了。而回源的reply中有Cache-Control:no-cache，那么當request2在進入clientCacheHit時，它找到的StoreEntry中一定會有RELEASE_REQUEST這個標識。這個標識是httpCachableReply函數發現no-cache之后設置的。當發現這個標識的時候，就會從clientCacheHit轉入clientProcessMiss，重新回源，不會跟request1取到相同的數據 b、進入miss，clientProcessMiss，http->entrty不為null但lock-- > 0,clientCreateStoreEntry->storeCreateEntry->storeSetPrivateKey.? c、接步驟b。此時可分折疊開或不開，但都會進入到storeSetPublicKey-->通過public key找到storetable中已存在的entry（第一個請求的），并將其設置成私有，然后將當前私有entry變成public，并插入到storetable d、接步驟c。這樣新的先hit后miss的請求所產生的entry永遠是最新的與public key綁定。之前請求的entry都變成private，直到requestfree釋放。

總結

以上是生活随笔為你收集整理的squid 折叠回源解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。