Http協議系列—-字符編碼,cookie,緩存,疑難雜症

前言

這篇文章實話說我有點虛,因爲平時都不怎麽研究這一塊的,然後涉及到的知識點超多,我只能到處看看資料總結一下相關信息,所以在此我只想說句:
本文章內容只代表個人立場,有錯必改!
原本打算一次性總結,後來越扯越多超過字數限制了,就幹脆做成http系列文章了,不定時更新原有內容(發現哪裏出錯的話),不定時新增系列文章,請見諒!
Http協議系列----OSI參考模型,協議原理構成,三次握手,四次揮手,連接管理
Http協議系列—-字符編碼,cookie,緩存,疑難雜症

特殊字符編碼

在使用url進行參數傳遞時,經常會傳遞一些中文名的參數或URL地址,在後台處理時會發生轉換錯誤。例如:
在有些傳遞頁面使用GB2312,而在接收頁面使用UTF8,這樣接收到的參數就可能會與原來發生不一致。
使用服務器端的urlEncode函數編碼的URL,與使用客戶端javascript的encodeURI函數編碼的URL,結果就不一樣。

在請求參數中有些字段是不能直接傳輸的,可能會引起問題,于是我們需要在發送前先進行編碼.

方法用法返回值說明
escape(string)可對字符串進行編碼,這樣就可以在所有的計算機上讀取該字符串。已編碼的 string 的副本。其中某些字符被替換成了十六進制的轉義序列。該方法不會對 ASCII 字母和數字進行編碼,也不會對下面這些 ASCII 標點符號進行編碼: * @ - _ + . / 。其他所有的字符都會被轉義序列替換。
unescape(string)可對通過 escape() 編碼的字符串進行解碼。string 被解碼後的一個副本。通過找到形式爲 %xx 和 %uxxxx 的字符序列(x 表示十六進制的數字),用 Unicode 字符 \u00xx 和 \uxxxx 替換這樣的字符序列進行解碼。
encodeURI(URIstring)把字符串作爲 URI 進行編碼。URIstring 的副本,其中的某些字符將被十六進制的轉義序列進行替換。該方法不會對 ASCII 字母和數字進行編碼,也不會對這些 ASCII 標點符號進行編碼: - _ . ! ~ * ' ( ) 。該方法的目的是對 URI 進行完整的編碼,因此對以下在 URI 中具有特殊含義的 ASCII 標點符號,encodeURI() 函數是不會進行轉義的:;/?:@&=+$,#
decodeURI(URIstring)對 encodeURI() 函數編碼過的 URI 進行解碼。URIstring 的副本,其中的十六進制轉義序列將被它們表示的字符替換。
encodeURIComponent(URIstring)把字符串作爲 URI 組件進行編碼。URIstring 的副本,其中的某些字符將被十六進制的轉義序列進行替換。該方法不會對 ASCII 字母和數字進行編碼,也不會對這些 ASCII 標點符號進行編碼: - _ . ! ~ * ' ( ) 。其他字符(比如 :;/?:@&=+$,# 這些用于分隔 URI 組件的標點符號),都是由一個或多個十六進制的轉義序列替換的。
decodeURIComponent(URIstring)對 encodeURIComponent() 函數編碼的 URI 進行解碼。URIstring 的副本,其中的十六進制轉義序列將被它們表示的字符替換。
  • escape()除了 ASCII 字母、數字和特定的符號外,其他所有的字符都會被轉義序列替換(已被廢棄使用)。
  • encodeURI() 除了 ASCII 字母、數字和特定的符號外,對 URI 進行完整的編碼,並且URI中的合法字符都不會被編碼轉換
  • encodeURIComponent()除了 ASCII 字母、數字和特定的符號外,其他字符都是由一個或多個十六進制的轉義序列替換的。

注意:
1, 上面指明的特定符號每個方法都各不相同;
2, encodeURIComponent() 函數 與 encodeURI() 函數的區別之處在于前者假定它的參數是 URI 的一部分(比如協議、主機名、路徑或查詢字符串)。因此 encodeURIComponent() 函數將轉義用于分隔 URI 各個部分的標點符號

escape('https://www.baidu.com/index.html?abc=1&name=特殊字符編碼')
"https%3A//www.baidu.com/index.html%3Fabc%3D1%26name%3D%u7279%u6B8A%u5B57%u7B26%u7F16%u7801"

encodeURI('https://www.baidu.com/index.html?abc=1&name=特殊字符編碼')
"https://www.baidu.com/index.html?abc=1&name=%E7%89%B9%E6%AE%8A%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81";

encodeURIComponent('https://www.baidu.com/index.html?abc=1&name=特殊字符編碼')
"https%3A%2F%2Fwww.baidu.com%2Findex.html%3Fabc%3D1%26name%3D%E7%89%B9%E6%AE%8A%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81"

Cookie

服務器發送到用戶浏覽器並保存在本地的一小塊數據,它會在浏覽器下次向同一服務器再發起請求時被攜帶並發送到服務器上。通常,它用于告知服務端兩個請求是否來自同一浏覽器,主要應用方面:

  • 會話狀態管理(如用戶登錄狀態、購物車、遊戲分數或其它需要記錄的信息)
  • 個性化設置(如用戶自定義設置、主題等)
  • 浏覽器行爲跟蹤(如跟蹤分析用戶行爲等)
    注意: 服務器指定Cookie後,浏覽器的每次請求都會攜帶Cookie數據,會帶來額外的性能開銷.

設置Set-Cookie屬性
需要傳輸的自定義鍵值對數據cookie-name=cookie-value:
1, cookie-name 可以是除了控制字符 (CTLs)、空格 (spaces) 或制表符 (tab)之外的任何 US-ASCII 字符。同時不能包含以下分隔字符: ( ) < > @ , ; : \ " / [ ] ? = { }.
2, cookie-value 是可選的,如果存在的話,那麽需要包含在雙引號裏面。支持除了控制字符(CTLs)、空格(whitespace)、雙引號(double quotes)、逗號(comma)、分號(semicolon)以及反斜線(backslash)之外的任意 US-ASCII 字符。關于編碼:許多應用會對 cookie 值按照URL編碼(URL encoding)規則進行編碼,但是按照 RFC 規範,這不是必須的。不過滿足規範中對于 <cookie-value> 所允許使用的字符的要求是有用的。
3, Secure- 前綴:以 Secure- 爲前綴的 cookie(其中連接符是前綴的一部分),必須與 secure 屬性一同設置,同時必須應用于安全頁面(即使用 HTTPS 訪問的頁面)。
4, Host- 前綴: 以 Host- 爲前綴的 cookie,必須與 secure 屬性一同設置,必須應用于安全頁面(即使用 HTTPS 訪問的頁面),必須不能設置 domain 屬性 (也就不會發送給子域),同時 path 屬性的值必須爲“/”。

配置屬性如下:

屬性描述
Domain指定 cookie 可以送達的主機名。假如沒有指定,那麽默認值爲當前文檔訪問地址中的主機部分(但是不包含子域名)。與之前的規範不同的是,域名之前的點號會被忽略。假如指定了域名,那麽相當于各個子域名也包含在內了
Path指定一個 URL 路徑,這個路徑必須出現在要請求的資源的路徑中才可以發送 Cookie 首部。字符 %x2F ("/") 可以解釋爲文件目錄分隔符,此目錄的下級目錄也滿足匹配的條件(例如,如果 path=/docs,那麽 "/docs", "/docs/Web/" 或者 "/docs/Web/HTTP" 都滿足匹配的條件)
Expire timecookie 的最長有效時間,形式爲符合 HTTP-date 規範的時間戳。參考 Date 可以獲取詳細信息。如果沒有設置這個屬性,那麽表示這是一個會話期 cookie 。一個會話結束于客戶端被關閉時,這意味著會話期 cookie 在彼時會被移除。然而,很多Web浏覽器支持會話恢複功能,這個功能可以使浏覽器保留所有的tab標簽,然後在重新打開浏覽器的時候將其還原。與此同時,cookie 也會恢複,就跟從來沒有關閉浏覽器一樣。
Max-age在 cookie 失效之前需要經過的秒數。一位或多位非零(1-9)數字。一些老的浏覽器(ie6、ie7 和 ie8)不支持這個屬性。對于其他浏覽器來說,假如二者 (指 Expires 和Max-Age) 均存在,那麽 Max-Age 優先級更高
secure一個帶有安全屬性的 cookie 只有在請求使用SSL和HTTPS協議的時候才會被發送到服務器。然而,保密或敏感信息永遠不要在 HTTP cookie 中存儲或傳輸,因爲整個機制從本質上來說都是不安全的,比如前述協議並不意味著所有的信息都是經過加密的。
httponly設置了 HttpOnly 屬性的 cookie 不能使用 JavaScript 經由 Document.cookie 屬性、XMLHttpRequest 和 Request APIs 進行訪問,以防範跨站腳本攻擊(XSS)。

注意Path:
1, Cookie默認的maxAge值爲–1;
2, 如果爲正數,則表示該Cookie會在maxAge秒之後自動失效。浏覽器會將maxAge爲正數的Cookie持久化,即寫到對應的Cookie文件中。無論客戶關閉了浏覽器還是電腦,只要還在maxAge秒之前,登錄網站時該Cookie仍然有效;
3, 如果爲負數,則表示該Cookie僅在本浏覽器窗口以及本窗口打開的子窗口內有效,關閉窗口後該Cookie即失效。maxAge爲負數的Cookie,爲臨時性Cookie,不會被持久化,不會被寫到Cookie文件中。Cookie信息保存在浏覽器內存中,因此關閉浏覽器該Cookie就消失了;
4, 如果maxAge爲0,則表示刪除該Cookie。Cookie機制沒有提供刪除Cookie的方法,因此通過設置該Cookie即時失效實現刪除Cookie的效果。失效的Cookie會被浏覽器從Cookie文件或者內存中刪除:

注意Max-age:
1, Cookie默認的maxAge值爲–1;
2, 如果爲正數,則表示該Cookie會在maxAge秒之後自動失效。浏覽器會將maxAge爲正數的Cookie持久化,即寫到對應的Cookie文件中。無論客戶關閉了浏覽器還是電腦,只要還在maxAge秒之前,登錄網站時該Cookie仍然有效;
3, 如果爲負數,則表示該Cookie僅在本浏覽器窗口以及本窗口打開的子窗口內有效,關閉窗口後該Cookie即失效。maxAge爲負數的Cookie,爲臨時性Cookie,不會被持久化,不會被寫到Cookie文件中。Cookie信息保存在浏覽器內存中,因此關閉浏覽器該Cookie就消失了;
4, 如果maxAge爲0,則表示刪除該Cookie。Cookie機制沒有提供刪除Cookie的方法,因此通過設置該Cookie即時失效實現刪除Cookie的效果。失效的Cookie會被浏覽器從Cookie文件或者內存中刪除:

例子:

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

類別:

  • 會話期Cookie
    1) 浏覽器關閉之後它會被自動刪除,不需要指定過期時間(Expires)或者有效期(Max-Age);
    2) 有些浏覽器提供了會話恢複功能,這種情況下即使關閉了浏覽器,會話期Cookie也會被保留下來;
  • 持久性Cookie
    指定一個特定的過期時間(Expires)或有效期(Max-Age);
  • Secure 和HttpOnly 標記
    1) 安全的Cookie只應通過HTTPS協議加密過的請求發送給服務端;
    2) 爲避免跨域腳本 (XSS) 攻擊,通過JavaScript的 Document.cookie API無法訪問帶有 HttpOnly 標記的Cookie;
  • 僵屍Cookie
    這類Cookie較難以刪除,甚至刪除之後會自動重建。它們一般是使用Web storage API、Flash本地共享對象或者其他技術手段來達到的

安全問題:

  • 會話劫持和XSS
  • 跨站請求僞造(CSRF)
    <br/>

Cookie的實現:

  • Javascript調用document.cookie
  • 服務器發送
    1) 服務器端在響應中利用Set-Cookie header來創建一個Cookie,發送給客戶端;
    2) 客戶端將Cookie保存到某個目錄下的文本文件內;
    3) 如果客戶端支持Cookie,下次請求同一網站時就可以Cookie直接發送給服務器;

<br/>
優點:
1, 能跟蹤用戶的整個會話,確定用戶身份;
2, 具有不可跨域名性(即使同一個父域也不行,但有辦法實現);

缺點:
1, 需要浏覽器支持或者啓用;
2, 部分情況需要將數據編碼(Unicode字符在內存中占4個字符,而英文屬于ASCII字符在內存中只占2個字節,前者如中文就需要編碼,否則亂碼);
3, 每次請求都會發送該域名下的所有cookie,即使不需要用到;
4, 修改、刪除Cookie時,新建的Cookie除value、maxAge之外的所有屬性,都要與原Cookie完全一樣。否則,浏覽器將視爲兩個不同的Cookie不予覆蓋,導致修改、刪除失敗;
5, 明文傳遞,不適合保存重要數據;
6, 長度限制,不適合保存複雜數據;

<br/>
Web Storage
Html5提供了本地緩存功能local storage和session storage,這個不算http東西我就不說了,看看文檔就懂.
優點:
1, 良好的API,即拿即用,使用簡單;
2, 無需請求,節省寬帶資源;
3, 讀取速度快;
4, session storage浏覽器關閉就移除,適合臨時數據;

缺點:
1, 不適合儲存改動頻繁數據;
2, local storage或者用戶手動移除,否則永遠存在;
(更多內容請自行查閱,本節到此爲止了.)

Session

如果說Cookie技術是通過客戶端來保持狀態的解決方案,Session技術則是通過服務器來保持狀態的解決方案.
浏覽器訪問服務器的時候,服務器把客戶端信息以某種形式記錄在服務器上。這就是Session。客戶端浏覽器再次訪問時只需要從該Session中查找該客戶的狀態就可以了,相當于做了一層個人檔案.而Session ID是唯一標識.
服務器會爲每一個訪問服務器的用戶創建一個session對象,並且把session對象的id保存在本地cookie上,只要用戶再次訪問服務器時,帶著session的id,服務器就會匹配用戶在服務器上的session,根據session中的數據,還原用戶上次的浏覽狀態或提供其他人性化服務.Session生成後,只要用戶繼續訪問,服務器就會更新Session的最後訪問時間,並維護該Session。用戶每訪問服務器一次,無論是否讀寫Session,服務器都認爲該用戶的Session“活躍(active)”了一次。爲了解決大量session占用服務器資源的問題,可以設置一個超時設置,當用戶活躍時間間隔超過超時設置,該session會被移除.
如果客戶端浏覽器將Cookie功能禁用,可以使用URL地址重寫,原理是將該用戶Session的id信息重寫到URL地址中。服務器能夠解析重寫後的URL獲取Session的id。這樣即使客戶端不支持Cookie,也可以使用Session來記錄用戶狀態

優點
1, 使用比cookie方便;
2, 能還原用戶上次的浏覽狀態或提供其他人性化服務;

缺點
1, Session會占用服務器內存中,請求高壓情況下有內存溢出的隱患;
2, 需要cookie保存session的關聯id(能通過URL地址重寫技術解決方案);

因爲這個是服務器的東西,我接觸不多,就說一些原理差不多了.
(更多內容請自行查閱,本節到此爲止了.)

緩存機制

讀到這裏大家應該也知道每次http請求要經過多少步驟涉及多少知識點了,在實際項目中請求往往是有相當數量的,但是其中有些請求是重複多余的,而這一節要講的緩存就是爲了這些請求而存在,http緩存機制在性能優化這一塊尤爲重要:

  • 避免不必要的數據傳輸甚至不需要發送請求;
  • 降低網絡狀況和距離時延影響,因爲上一條;
  • 減少服務器的壓力,因爲上兩條;

總體流程如下:

  • 當浏覽器在加載資源時,先根據這個資源的一些http header判斷它是否命中強制緩存:
    1) 如果命中,浏覽器直接從自己的緩存中讀取資源,流程結束
    2) 如果沒有命中,浏覽器一定會發送一個請求到服務器;
  • 服務器端收到請求之後依據資源的另外一些http header驗證這個資源是否命中協商緩存:
    1) 如果命中,服務器會返回對應狀態碼,但是不會返回這個資源的數據,而是讓客戶端直接從緩存中加載這個資源,流程結束
    2) 如果沒有命中,浏覽器直接從服務器加載最新資源數據,流程結束;

Pragma(可抛棄不說)

客戶端不對該資源讀緩存,即每次都得向服務器發一次請求才行。Pragma屬于通用首部字段,在客戶端上使用時,常規要求我們往html上加上這段meta元標簽(僅對該頁面有效,對頁面上的資源無效),優先級高于Cache-Control:

缺點:
1) 僅有IE才能識別這段meta標簽含義,但並不一定會在請求字段加上Pragma,不過的確會讓當前頁面每次都發新請求;

<br/>

強制緩存

  • Expires
    指定了一個日期/時間,必須是格林威治時間(GMT), 在這個日期/時間之後,HTTP響應被認爲是過時的;無效的日期,比如 0, 代表著一個過去的事件,即該資源已經過期了。

    缺點:
    1) 時間是由服務器發送的,和客戶端時間不一定一致,無法用于精確度高的需求;
    2) 如果同時設置了 "max-age" 或者 "s-max-age" 指令的Cache-Control響應頭,那麽Expires頭就會被忽略;
    3) 過期之前即使資源修改了也依舊使用舊資源,非即時性緩存,強制緩存通病;
    <br/>

  • Cache-Control
    在http請求和響應中通過指定指令來實現緩存機制。緩存指令是單向的, 這意味著在請求設置的指令,在響應中不一定包含相同的指令.

    優點:
    1) 以時間間隔標識失效時間,避免服務器和客戶端相對時間的問題;
    2) 靈活的自定義配置選項;

    缺點:
    1) HTTP 1.1 才有的內容,不適用于HTTP 1.0;
    2) 過期之前即使資源修改了也依舊使用舊資源,非即時性緩存,強制緩存通病;

可緩存性字段描述
public表明響應可以被任何對象(包括:發送請求的客戶端,代理服務器,等等)緩存。
private表明響應只能被單個用戶緩存,不能作爲共享緩存(即代理服務器不能緩存它)。
no-cache告訴浏覽器、緩存服務器,不管本地副本是否過期,使用資源副本前,一定要到源服務器進行副本有效性校驗
only-if-cached表明客戶端只接受已緩存的響應,並且不要向原始服務器檢查是否有更新的拷貝
到期字段描述
max-age=秒設置緩存存儲的最大周期,超過這個時間緩存被認爲過期(單位秒)。與Expires相反,時間是相對于請求的時間。如果和Last-Modified一起使用時, 優先級較高
s-maxage=秒覆蓋max-age 或者 Expires 頭,但是僅適用于共享緩存(比如各個代理),並且私有緩存中它被忽略。
max-stale(=<秒>)表明客戶端願意接收一個已經過期的資源。 可選的設置一個時間(單位秒),表示響應不能超過的過時時間。
min-fresh=秒表示客戶端希望在指定的時間內獲取最新的響應。
重新驗證和重新加載字段描述
must-revalidate告訴浏覽器、緩存服務器,本地副本過期前,可以使用本地副本;本地副本一旦過期,必須去源服務器進行有效性校驗
proxy-revalidate與must-revalidate作用相同,但它僅適用于共享緩存(例如代理),並被私有緩存忽略。
immutable表示響應正文不會隨時間而改變。資源(如果未過期)在服務器上不發生改變,因此客戶端不應發送重新驗證請求頭(例如If-None-Match或If-Modified-Since)來檢查更新,即使用戶顯式地刷新頁面。在Firefox中,immutable只能被用在 https:// transactions.
其他字段描述
no-store緩存不應存儲有關客戶端請求或服務器響應的任何內容。
no-transform不得對資源進行轉換或轉變。Content-Encoding, Content-Range, Content-Type等HTTP頭不能由代理修改。例如,非透明代理可以對圖像格式進行轉換,以便節省緩存空間或者減少緩慢鏈路上的流量。 no-transform指令不允許這樣做。

例如緩存靜態資源可以這麽設置

交互結論
打開新窗口如果指定cache-control的值爲private、no-cache、must-revalidate,那麽打開新窗口訪問時都會重新訪問服務器。而如果指定了max-age值,那麽在此值內的時間裏就不會重新訪問服務器,例如:Cache-control: max-age=5 表示當訪問此網頁後的5秒內不會去再次訪問服務器.
在地址欄回車如果值爲private或must-revalidate,則只有第一次訪問時會訪問服務器,以後就不再訪問。如果值爲no-cache,那麽每次都會訪問。如果值爲max-age,則在過期之前不會重複訪問。
按後退按扭如果值爲private、must-revalidate、max-age,則不會重訪問,而如果爲no-cache,則每次都重複訪問.
按刷新按扭無論爲何值,都會重複訪問.

<br/>

協商緩存

  • Last-Modified && If-Modified-Since
    服務器在響應請求時,告訴浏覽器資源的最後修改時間Last-Modified。之後客戶再次請求時可以通過If-Modified-Since請求頭提供一個日期,該請求將被視爲一個條件GET,只有改動時間遲于指定時間的文檔才會返回,否則返回一個304(Not Modified)狀態。Last-Modified也可用setDateHeader方法來設置。

    優點:
    1) 如果資源修改了服務器就會返回最新資源;
    2) 如果資源沒修改服務器就只返回304(Not Modified)狀態碼,節省不必要的數據傳輸;

    缺點:
    1) 文檔的最後改動不意味著實際內容有改動,這時候的緩存是不起作用了;
    2) If-Modified-Since能檢查到的粒度是s級的,無法識別一秒內進行多次修改的情況;
    3) 某些服務器不能精確的得到文件的最後修改時間;
    4) 一定會發送請求,協商緩存通病;
    <br/>

  • ETag && If-None-Match
    ETag一般不以明文形式相應給客戶端。在資源的各個生命周期中,它都具有不同的值,用于標識出資源的狀態。當資源發生變更時,如果其頭信息中一個或者多個發生變化,或者消息實體發生變化,那麽ETag也隨之發生變化.Etag由服務器端生成,客戶端通過If-Match或者說If-None-Match這個條件判斷請求來驗證資源是否修改。

    優點:
    1) Etag是根據資源內容計算出來的,比單純比較資源最後修改時間的做法精確度高得多;
    2) 能識別一秒內進行多次修改的情況;
    3) Etag可以綜合Inode,MTime和Size避免某些服務器不能精確的得到文件的最後修改時間這個問題;

    缺點:
    1) 分布式服務器存儲的情況下,計算ETag的算法如果不一樣,會導致浏覽器從一台服務器上獲得頁面內容後到另外一台服務器上進行驗證時發現ETag不匹配的情況;
    2) ETag不管怎麽樣的算法,在服務器端都要進行計算,計算就有開銷,會帶來性能損失;
    3) 一定會發送請求,協商緩存通病;

<br>

總結流程圖

因爲Cache-Control自定義配置效果太多,就一筆帶過了,大家知道就好.
圖片描述
圖片描述

疑難雜症

  • HTTP/1.x缺點?
    1, Header不會被壓縮;
    2, 兩個報文之間的 header 通常非常相似,但它們仍然在連接中重複傳輸;
    3, 無法複用。當在同一個服務器打開幾個連接時:TCP 熱連接比冷連接更加有效;
  • HTTP/2.x改進?
    1, 是二進制協議而不是文本協議。不再可讀和無障礙的手動創建,改善的優化技術現在可被實施;
    2, 複用協議。並行的請求能在同一個鏈接中處理,移除了HTTP/1.x中順序和阻塞的約束;
    3, 壓縮了headers。因爲headers在一系列請求中常常是相似的,其移除了重複和傳輸重複數據的成本;
    4, 其允許服務器在客戶端緩存中填充數據,通過一個叫服務器推送的機制來提前請求;
    優點: HTTP/2 幀機制是在 HTTP/1.x 語法和底層傳輸協議之間增加了一個新的中間層,而沒有從根本上修改它,即它是建立在經過驗證的機制之上。Web 開發人員不需要在其使用的 API 中做任何更改來利用 HTTP 幀;當浏覽器和服務器都可用時,HTTP/2 將被打開並使用。
  • HTTP控制的常見特性?
    1) 緩存
    服務端能告訴代理和客戶端哪些文檔需要被緩存,緩存多久,而客戶端也能夠命令中間的緩存代理來忽略存儲的文檔;
    2) 開放同源限制
    爲了防止網絡窺聽和其它隱私泄漏,浏覽器強制對Web網站做了分割限制。只有來自于相同來源的網頁才能夠獲取網站的全部信息。這樣的限制有時反而成了負擔,HTTP可以通過修改頭部來開放這樣的限制,因此Web文檔可以是由不同域下的信息拼接成的(某些情況下,這樣做還有安全因素考慮);
    3) 認證
    一些頁面能夠被保護起來,僅讓特定的用戶進行訪問。基本的認證功能可以直接通過HTTP提供,使用Authenticate相似的頭部即可,或用HTTP Cookies來設置指定的會話;
    4) 代理和隧道
    通常情況下,服務器和/或客戶端是處于內網的,對外網隱藏真實 IP 地址。因此 HTTP 請求就要通過代理越過這個網絡屏障。但並非所有的代理都是 HTTP 代理。例如,SOCKS協議的代理就運作在更底層,一些像 FTP 這樣的協議也能夠被它們處理;
    5) 會話
    使用HTTP Cookies允許你用一個服務端的狀態發起請求,這就創建了會話;
  • 什麽是代理?
    代理是位于客戶端和服務器之間的HTTP中間實體。接收所有客戶端的HTTP請求,並將這些請求轉發給服務器(可能會對請求進行修改之後轉發)。
  • 代理(Proxies)作用?
    1) 緩存(可以是公開的也可以是私有的,像浏覽器的緩存);
    2) 過濾(像反病毒掃描,家長控制...);
    3) 負載均衡(讓多個服務器服務不同的請求);
    4) 認證(對不同資源進行權限管理);
    5) 日志記錄(允許存儲曆史信息);
  • 什麽是網關?
    網關是一種特殊的服務器,作爲其他服務器的中間實體使用。通常用于將HTTP流量轉換成其他的協議。
  • 什麽是隧道?
    隧道是建立起來之後,就會在兩條連接之間對原始數據進行盲轉發的HTTP應用程序。常見用途是通過HTTP連接承載加密的安全套接字層(SSL)流量,這樣SSL流量就可以穿過只允許Web流量通過的防火牆了。
  • 什麽是Agent代理?
    用戶Agent代理是代表用戶發起HTTP的客戶端程序。比如Web浏覽器。另外有些自動發送HTTP請求並獲取內容的代理,比如“網絡蜘蛛”或者“Web機器人”。
  • 可以禁止浏覽器緩存的方法?
    1) Expires設置0;
    2) Cache-Control: no-cache;
    3) Pragma: no-cache;
  • 關于Cache-Control: no-cache和no-store,max-age=0區別?
    1) no-cache代表不緩存過期的資源,緩存會向服務器進行有效處理確認之後處理資源;
    2) no-store才是真正的不進行緩存;
    3) max-age=<0就請求服務器,如果資源修改了服務器就會返回最新資源,如果資源沒修改服務器就只返回304(Not Modified)狀態碼;
  • 什麽是CDN?
    CDN的全稱是Content Delivery Network,即內容分發網絡。其基本思路是盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節,使內容傳輸的更快、更穩定,通過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡,CDN系統能夠實時地根據網絡流量和各節點的連接、負載狀況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節點上,其目的是使用戶可就近取得所需內容,解決 Internet網絡擁擠的狀況,提高用戶訪問網站的響應速度。

    1) 本地Cache加速: 提高了企業站點(尤其含有大量圖片和靜態頁面站點)的訪問速度,並大大提高以上性質站點的穩定性
    2) 鏡像服務: 消除了不同運營商之間互聯的瓶頸造成的影響,實現了跨運營商的網絡加速,保證不同網絡中的用戶都能得到良好的訪問質量。
    3) 遠程加速: 遠程訪問用戶根據DNS負載均衡技術智能自動選擇Cache服務器,選擇最快的Cache服務器,加快遠程訪問的速度
    4) 帶寬優化: 自動生成服務器的遠程Mirror(鏡像)cache服務器,遠程用戶訪問時從cache服務器上讀取數據,減少遠程訪問的帶寬、分擔網絡流量、減輕原站點WEB服務器負載等功能。
    5) 集群抗攻擊: 廣泛分布的CDN節點加上節點之間的智能冗余機制,可以有效地預防黑客入侵以及降低各種D.D.o.S攻擊對網站的影響,同時保證較好的服務質量 。

  • 緩存服務器作用?
    加速資源訪問速度,降低源服務器的負載。緩存服務器從源服務器獲取資源,並返回給浏覽器。此外,緩存服務器一般還會在本地保存資源的副本,當有相同的資源請求到來,緩存服務器可返回資源副本,以此提高資源訪問速度。
  • 使用cookie保存登陸信息的方法?
    1) Cookie保存用戶名與密碼,與數據庫比較;
    2) Cookie保存加密後的密碼,訪問時解密與數據庫比較;
    3) Cookie保存用戶名與加密後的用戶名,與數據庫比較賬號的加密規則是否正確;
评论 ( 0 )
最新评论
暂无评论

赶紧努力消灭 0 回复