目錄
1.HTML資源交互
(1)媒體加載
(2)靜態頁面跳轉
(3)動態頁面
(4)GET和POST傳參的區別
2.網頁管理
(1)網頁的權限管理
(2)臨時重定向和永久重定向
①永久重定向(301)
②臨時重定向(302)
①會話保持
③session
3.搜索引擎
(1)搜索引擎和瀏覽器的關系
(2)搜索引擎的構建和更新
1.HTML資源交互
在這里,我重點講解前后端之間的聯系,它們是如何聯系起來的,不會過多涉及前端語法。
(1)媒體加載
如果有圖片、音頻等需要出現在網頁中,這些資源又都來自不同的文件,那么當客戶端訪問這些html時,這些媒體應該怎么加載呢?
對于絕大多數情況,就是第一次直接返回帶有媒體鏈接的html網頁(只有媒體文件的路徑),客戶端接收到回應后再根據里面的鏈接多次發送URL請求,之后服務器再多次以二進制方式讀取媒體文件并返回(每次返回時響應報頭都會聲明媒體類型)。所以我們會發現有時網慢的時候,一般都是先刷新出文字大綱之類的,后面慢慢地才會出現圖片。在只顯示文字期間,客戶端正源源不斷地根據第一次收到的html文件里面的鏈接訪問媒體資源。當然,對于特別小的圖標,會被直接讀到html里面并用Base64編碼,在第一次響應中就讓客戶端看到。
如果不進行優化的話,當遇到一個html里面大量圖片時,由于一個短鏈接就獲取一個資源,且短鏈接會導致頻繁訪問資源,造成浪費。因此現在的HTTP版本允許在同一次TCP連接中請求媒體資源。其具體實現來源于HTTP報頭的Connection字段,主要用于控制客戶端和服務器之間的連接狀態。Connection: keep-alive表示支持長鏈接,在一個TCP連接內,客戶端會自動掃描文本,并多次訪問服務端的資源,直到數據被請求完。這種復用TCP的技術大大減少了服務器的壓力。
(2)靜態頁面跳轉
.html里面遇到<a>標簽的時候,就說明有一個頁面跳轉鏈接,如<a href="/about.html">關于我們</a> ,點擊“關于我們”就會靜態跳轉到相應的頁面,即web_root/about.html
當然,實際情況可能不止這一個,如果是<a href="/about">關于我們</a>,這意味著什么呢?
這需要由服務器自行處理:當about是一個目錄時,有可能訪問的就會是/about/index.html;如果about本身就是一個無擴展名的文件,有可能就直接訪問它;也可能服務器會通過配置自動補齊擴展名;還有一種是申請訪問動態頁面,后面會講。
<!-- 跳轉到一個動態路由(如/about) -->
<a href="/about">關于我們</a><!-- 跳轉到一個帶后綴的動態頁面(如.php) -->
<a href="/user.php?id=123">用戶信息</a>
這個跳轉其實就是在用戶點擊鏈接后,由用戶的瀏覽器自動形成新的URL(新的訪問請求)向目標服務發起請求,然后等待服務端的回應。
以上大多是屬于靜態頁面的跳轉,即點擊鏈接后會直接到達新的網頁。
除了直接跳轉,還有一種借助JavaScript直接刷新頁面,更新頁面內容,這種情況下就不會跳轉到新的靜態網頁,看起來還是在原來的網站,但內容更新了。
(3)動態頁面
除了靜態網頁,但還有一種很相似的URL,如輸入賬號密碼后點擊登錄會出現/login?username=SGlow&passwd=123456,這是要跳轉嗎?靜態網頁能傳參嗎?后面的參數是什么意思呢?這就涉及到動態網頁的知識了。
用戶在網頁中輸入信息,需要form表單創建搜索框(其中input標簽可以設置type為文本),button提供按鈕提交信息,action表示提交給誰,點擊后action自動拼接到網址后,發起訪問。
<form action="/search" method="GET"><!-- 搜索輸入框:type="text",name="query" 定義參數名 --><input type="text" name="query" placeholder="輸入搜索關鍵詞" required><!-- 提交按鈕:觸發表單默認提交 --><button type="submit">搜索</button>
</form>
這里點擊提交之后,就會帶著參數訪問如www.test.com/search?query=xxx(input里面的name規定了該參數的名字)。但是,/search并不是一個靜態網頁,而是動態的。動態網頁的一個很強的特征就是它能夠接收參數。可以說,/search本身并不是一個實體,在Web根目錄下找不到這個文件或者目錄,它只是一個訪問接口,當服務端接收到這個接口訪問請求時,就會單獨拉出來處理。
服務器收到動態頁面請求后能夠讀取接收到的參數,并且給出響應。當請求端收到回應后就會顯示收到的結果,并將當前頁面的URL修改為請求發出的URL。
這里我們就可以看到,我們并不是真的打開了服務端的某個文件,而是我們訪問動態網頁,服務器通過參數返回了結果給我們,再由我們瀏覽器渲染出結果后顯示出來,并且更新URL為當時請求動態網頁時的URL而已。
在這里總結一下,靜態網頁的跳轉最有代表的就是<a>標簽,大多數情況下會跳轉到一個有實體的網頁中,即在服務端的Web根目錄中一定存在這么一個文件。而動態頁面就一定沒有實體,客戶端的/test實際上會被對方的服務器單獨處理,讀取請求的參數,返回結果給客戶端。在客戶端眼里就像是訪問了一個文件一樣,所以按照結果渲染頁面,并更改URL為請求的URL。
至于是靜態網頁還是動態網頁,區分最粗暴的方法是看有沒有參數傳遞,有沒有文件后綴。但有的靜態網頁也能處理參數(前端),沒有后綴時也可能是靜態網頁,如前面提過的<a href="/about">關于我們</a>。最根本的判斷標準就是動態網頁沒有實體,而靜態網頁有實體。
(4)GET和POST傳參的區別
我們已經講過動態頁面可以接收參數,參數的傳遞方式隨請求方法有所不同。POST傳參是通過正文傳參,GET傳參則直接體現在URL中。一般情況下不推薦用GET提交私密數據的參數,因為數據直接體現在URL中了。但我們不能說POST方法比GET安全,只能說相比而言更私密,POST本質是明文傳送,始終能夠被抓包、提取數據。要想安全就一定是要加密,也就是HTTPS。
2.網頁管理
(1)網頁的權限管理
當我們訪問VIP網站的時候,就算把URL分享出去,別人也是訪問不進來的,為什么?
對于VIP網站設計者來說是肯定要做權限管理的,它根據用戶是從哪里點進這個網站這件事就能篩掉一大批人;或者當沒有從規定網站跳轉進VIP網站時,就自動跳轉到登錄界面。
要實現這個很簡單,請求端訪問網站時會帶上請求報頭Referer,如Referer: https://www.baidu.com,當服務端收到這個報頭時就判斷對方是非法訪問,就會選擇拒絕回應或者直接跳轉到登錄界面。因此就實現了網頁的權限管理。
(2)臨時重定向和永久重定向
重定向有風險,重定向次數過多會失敗,要慎用
①永久重定向(301)
比較廣為人知的一個消息就是twitter改名為X,那么twitter的網站域名就要發生改變,不再是www.twitter.com了。但直接改會出現大量問題,原先的twitter積累的大量的用戶,一下子改網址顯然會引起很大的波動,每個人都需要改變自己的習慣,重定向就讓這個過程更加溫和。
永久重定向就像搬家,永遠不會回來了,IP也會變。那么如果有人要拜訪我家,我就需要在原來的家門口插上一塊牌子,寫著我的新地址。網址也是如此,當訪問old.com時,會有各種途徑(比較復雜)響應請求方狀態碼為301,并且請求報頭里面帶有Location: new.com,這個時候客戶端瀏覽器會馬上重定向,訪問new.com,這樣就實現了溫和的網址替換。一般Location都要帶新地址的全路徑,如果只是相對路徑的修改當然也可以只寫相對路徑。
在這個過程中,瀏覽器也很靈活,當收到301之后,它就會緩存這個新地址。當后續再訪問old.com時,瀏覽器就不走原來重定向那條路了,它會直接訪問new.com。因為是“永久”重定向,所以瀏覽器會做這種大膽的事情。
②臨時重定向(302)
臨時重定向就像旅游,住幾天酒店還會回來。那么這個時候家門口也要插塊牌子,寫著自己去旅游去了,地址在哪(和永久重定向一樣)。當請求端收到302和Location之后,也會自動再次訪問新的地址。注意對于301還是302,跳轉的含義都是指的客戶端再次發起請求,服務端不會跳轉的,它只會告訴客戶端下一步怎么做。
唯一的區別就是瀏覽器不會緩存301定位的地址,對方隨時會回來,瀏覽器自然不敢像永久重定向那樣替別人做決定。
(3)cookie
①會話保持
網頁上第一次打開b站要登錄,但短時間內第二次打開就不需要了。這是因為服務器第一次認證用戶和密碼,認證之后就會返回一些內容,寫到客戶端瀏覽器的某個位置。第二次訪問時,瀏覽器就會把上次服務器返回的信息自動攜帶上,這部分內容就是cookie。cookie保存在本地,可能是內存級(退出瀏覽器就清空)也可能是文件級(磁盤級保存),不同瀏覽器有不同策略。
刪掉cookie后我們訪問b站就需要再次登錄了。因此,cookie可以幫助服務器每次都認識我們,這就是基于cookie的會話保持功能。
更加具體地說,登錄后服務器的應答中包含Set-Cookie報頭,里面有我們的用戶名和密碼等信息,客戶端瀏覽器會將這個報頭的信息寫入cookie,之后每次請求登錄時都會帶上cookie。因此,服務器只要得到了這個認證信息,就認識客戶端。通過cookie,各大視頻網站也能實現試看五分鐘了,你會發現試看前都要求登錄,登錄之后只要訪問試看視頻資源時,客戶端就會上傳自己的cookie,服務器就一定能認識客戶端,從而形成時間控制。
②cookie的隱私泄露問題
HTTP是無連接、無狀態的,直接發起請求和回應。無連接是因為有連接的部分都交給TCP來做了,HTTP直接負責從TCP緩沖區那里獲取信息,而這個獲取的過程是無連接的。無狀態體現在HTTP不知道我們多久前訪問過網站,TCP釋放就釋放了,沒有記錄。因此,面對HTTP的這種無狀態特性,才有了讓cookie攜帶用戶信息這種事情。否則根據HTTP的無狀態特性,每次訪問都需要重新登錄,這讓人感到很不方便。
但是cookie是把雙刃劍,如果電腦中病毒,cookie文件被竊取的話就會導致隱私泄露,身份泄露,犯罪分子利用我們的cookie就有可能造成服務端錯認身份,錯認犯罪分子為賬號主人。因此光有cookie是完全不夠的。
③session
session就是應對cookie泄露的一個方法。每當服務端認證登錄之后,就會在服務器上形成一個新的session對象,包含用戶的賬號密碼等私密信息,這個對象也會對應唯一的session_id。
登錄后,服務器應答中的Set-Cookie里保存的就是session_id了,客戶端收到后同樣寫入cookie中,后續客戶端訪問服務器攜帶的就只是session_id了,這樣用戶私密信息不會泄露。
但其實這樣也避免不了cookie信息被盜取,只是相對更安全,私密信息始終是在服務端的,大公司都有自己的安全團隊,加上各種法律約束,所以被黑的風險小。除此外,服務端還可以設計各種策略來防止黑客的惡意操作。比如前一秒人在上海,下一秒就在緬北,遇到這種情況,服務器會直接讓session_id失效;服務器也可以對用戶的瀏覽行為監視實現判斷。
安全問題需要技術、法律共同約束,世上沒有完美的安全技術。
3.搜索引擎
(1)搜索引擎和瀏覽器的關系
瀏覽器可以認為是一個殼子,而殼子下的內核是搜索引擎。對于大部分用戶而言,使用什么瀏覽器就決定他們會使用什么搜索引擎(有的瀏覽器支持修改搜索引擎),所以對互聯網廠商而言,瀏覽器就是自己的門面,非常重要。
在電腦發展早期,人們都是通過上網來獲取資源,App沒有現在這么多。因此用戶電腦上使用什么搜索引擎就是各個廠商的競爭點。但是搜索引擎是個大工程,也需要海量數據來構建,這需要巨大的資金,所以很多公司都選擇先做瀏覽器,把自家瀏覽器、品牌推廣出去,后面再做出自己的搜索引擎。簡單來說,瀏覽器是入口,只有推廣了入口,后面自家的搜索引擎才能用起來。這就是電腦發展早期我們至少能見到幾十上百種瀏覽器的原因。
各家都瘋狂推出自己的瀏覽器,因此瀏覽器的標準爭奪非常劇烈,每家都有自己的一面之詞,都不甘服從別的公司的標準,這也造就了當今狀態碼使用分歧很大,就像前面說的狀態碼200,但返回404.html一樣。
(2)搜索引擎的構建和更新
搜索引擎可以用HTTP協議爬取網頁,即針對一個網頁發起請求并得到網頁返回,再對網頁文本進行分析,再從分析的文本種得到新的網址,再訪問......這樣就能把一個網址里面的所有內容全部爬取,再通過分詞得到大量的關鍵字文本,建立自己的搜索方案。這樣網頁的鏈接就能和網頁里面的內容關聯起來,用戶就可以根據關鍵字搜索網頁。搜索引擎可以幫助推廣,這里面也有商業模式。
一旦更新域名,網址就可能直接失效。但搜索引擎會定期更新爬取,自動更新網址,這樣用戶搜的時候就能直接跳轉。所以301不僅給了溫和的換域名適應方案,還能幫助搜索引擎更新網址。