1. 簡述www瀏覽器的工作原理
www
的工作基於客戶機/伺服器計算模型,由web
瀏覽器(客戶機)和web伺服器(服務
器)構成,兩者之間採用超文本傳送協議(http)進行通信,
http協議的作用原理包括四
個步驟:連接,請求,應答。根據上述http協議的作用原理,本文實現了get請求的web服
務器程序的方法,通過創建
tcplistener類對象,監聽埠8080;
等待、接受客戶機連
接到埠8080;
創建與socket字相關聯的輸入流和輸出流;然後,讀取客戶機的請求信
息,若請求類型是get,則從請求信息中獲取所訪問的html文件名,如果html文件存在,
則打開html文件,把http頭信息和
html文件內容通過socket傳回給web瀏覽器,然後關閉
文件。否則發送錯誤信息給web瀏覽器。最後,關閉與相應web瀏覽器連接的socket
字。
一、http協議的作用原理
www是以internet作為傳輸媒介的一個應用系統,www網上最基本的傳輸單位是
web網
頁。www的工作基於客戶機/伺服器計算模型,由web
瀏覽器(客戶機)和web伺服器(服務
器)構成,兩者之間採用超文本傳送協議(http)進行通信。http協議是基於tcp/ip協議
之上的協議,是web瀏覽器和web伺服器之間的應用層協議,是通用的、無狀態的、面向對
象的協議。http協議的作用原理包括四個步驟:
連接:web瀏覽器與web伺服器建立連接,打開一個稱為socket(套接字)的虛擬文
件,此文件的建立標志著連接建立成功。
請求:web瀏覽器通過socket向web伺服器提交請求。http的請求一般是get或post命
令(post用於form參數的傳遞)。get命令的格式為:
get
路徑/文件名
http/1.0
文件名指出所訪問的文件,http/1.0指出web瀏覽器使用的http版本。
應答:web瀏覽器提交請求後,通過http協議傳送給web伺服器。web伺服器接到後,
進行事務處理,處理結果又通過http傳回給web瀏覽器,從而在web瀏覽器上顯示出所請求
的頁面。
例:假設客戶機與www.mycomputer.com:8080/mydir/index.html建立了連接,就會發
送get命令:
get
/mydir/index.html
http/1.0。主機名為www.mycomputer.com的web服
務器從它的文檔空間中搜索子目錄mydir的文件index.html。如果找到該文件,web伺服器
把該文件內容傳送給相應的web瀏覽器。
為了告知
web瀏覽器傳送內容的類型,web伺服器首先傳送一些http頭信息,然後傳
送具體內容(即http體信息),http頭信息和http體信息之間用一個空行分開。
常用的http頭信息有:
①
http
1.0
200
ok
這是web伺服器應答的第一行,列出伺服器正在運行的http版本號和應答代碼。代碼
「200
ok」表示請求完成。
②
mime_version:1.0
它指示mime類型的版本。
③
content_type:類型
這個頭信息非常重要,它指示http體信息的mime類型。如:content_type:text/html
指示傳送的數據是html文檔。
④
content_length:長度值
它指示http體信息的長度(位元組)。
關閉連接:當應答結束後,web瀏覽器與web伺服器必須斷開,以保證其它web瀏覽器
能夠與web伺服器建立連接。
2. 簡述web瀏覽器打開一個web文件的工作過程
web瀏覽器打開一個web文件的工作過程如下:
1、在瀏覽器地址欄中輸入要訪問的主頁的地址;
2、用戶向瀏覽器發送拜訪請求,請求訪問該網站。
3、伺服器收到客戶端的訪問請求;
4、伺服器處理該請求(如果需要處理主頁上的動態文檔然後返回,如果是靜態文檔,則可以直接返回);
5、伺服器在客戶端的瀏覽器上顯示請求的處理結果。
(2)web瀏覽器的工作過程擴展閱讀:
web工作表現形式
1、超文本(超文本)
超文本是一種用於顯示文本和與文本相關的內容的用戶界面方法。目前,超文本通常以電子文檔的形式存在。
文本包含可以鏈接到其他欄位或文檔的超文本鏈接,從而允許從當前閱讀位置直接切換到超文本鏈接指向的文本。
2、超媒體
超媒體是超媒體的縮寫。它是信息瀏覽環境中超文本和多媒體的結合。用戶不僅可以從一個文本跳到另一個文本,還可以激活聲音,顯示圖形甚至播放動畫。
Internet使用超文本和超媒體信息組織方法將信息鏈接擴展到整個Internet。 Web是一種超文本信息系統,其主要概念之一是超文本鏈接。
3、超文本傳輸協議(HTTP,超文本傳輸協議)是Internet上使用最廣泛的網路協議。
3. 瀏覽器工作原理
工作原理如下:
1、解析HTML構建Dom樹(Document Object Model,文檔對象模型),DOM 是W3C組織推薦的處理可擴展置標語言的標准編程介面。
2、構建渲染樹,渲染樹並不等同於Dom樹,像head標簽 或 display: none這樣的元素就不需要放到渲染樹中了,但它們在Dom樹中。
3、對渲染樹進行布局,定位坐標和大小、確定是否換行、確定position、overflow、z-index等等,這個過程叫"layout" 或 "reflow"。
4、繪制渲染樹,調用操作系統底層API進行繪圖。
(3)web瀏覽器的工作過程擴展閱讀:
瀏覽器額的特點:
1、所有主流網頁瀏覽器都可透過多個窗口或多個標簽頁同時打開多種信息資源,亦可攔截彈出式廣告,以防止不必要的窗口在未經用戶同意的情況下彈出。
2、大部分網頁瀏覽器皆支持HTTPS,並可快捷地清除網頁快照、Cookie及瀏覽記錄。
3、瀏覽器擴展是一種擴展網頁瀏覽器功能的計算機程序。每個主流的網頁瀏覽器都支持擴展的開發。
4. 簡述WEB瀏覽器打開一個WEB文件的工作過程. 自己的觀點自己的回答 自己的想法。。。求。。
當輸入地址欄的時候,瀏覽器會發請求到指定的地址或者是伺服器上,然後伺服器會將你的請求進行處理,處理完以後就再次返回到瀏覽器,你所看到的東西!
5. 瀏覽器採用http 協議訪問網頁的工作過程
1. 首先嘛,你得在瀏覽器里輸入要網址:
2. 瀏覽器查找域名的IP地址
導航的第一步是通過訪問的域名找出其IP地址。DNS查找過程如下:
瀏覽器緩存 – 瀏覽器會緩存DNS記錄一段時間。 有趣的是,操作系統沒有告訴瀏覽器儲存DNS記錄的時間,這樣不同瀏覽器會儲存個自固定的一個時間(2分鍾到30分鍾不等)。
系統緩存 – 如果在瀏覽器緩存里沒有找到需要的記錄,瀏覽器會做一個系統調用(windows里是gethostbyname)。這樣便可獲得系統緩存中的記錄。
路由器緩存 – 接著,前面的查詢請求發向路由器,它一般會有自己的DNS緩存。
ISP DNS 緩存 – 接下來要check的就是ISP緩存DNS的伺服器。在這一般都能找到相應的緩存記錄。
遞歸搜索 – 你的ISP的DNS伺服器從跟域名伺服器開始進行遞歸搜索,從.com頂級域名伺服器到Facebook的域名伺服器。一般DNS伺服器的緩存中會有.com域名伺服器中的域名,所以到頂級伺服器的匹配過程不是那麼必要了。
DNS遞歸查找如下圖所示:
DNS有一點令人擔憂,這就是像wikipedia.org 或者 facebook.com這樣的整個域名看上去只是對應一個單獨的IP地址。還好,有幾種方法可以消除這個瓶頸:
循環 DNS 是DNS查找時返回多個IP時的解決方案。舉例來說,Facebook.com實際上就對應了四個IP地址。
負載平衡器 是以一個特定IP地址進行偵聽並將網路請求轉發到集群伺服器上的硬體設備。 一些大型的站點一般都會使用這種昂貴的高性能負載平衡器。
地理 DNS 根據用戶所處的地理位置,通過把域名映射到多個不同的IP地址提高可擴展性。這樣不同的伺服器不能夠更新同步狀態,但映射靜態內容的話非常好。
Anycast 是一個IP地址映射多個物理主機的路由技術。 美中不足,Anycast與TCP協議適應的不是很好,所以很少應用在那些方案中。
大多數DNS伺服器使用Anycast來獲得高效低延遲的DNS查找。
3. 瀏覽器給web伺服器發送一個HTTP請求
因為像Facebook主頁這樣的動態頁面,打開後在瀏覽器緩存中很快甚至馬上就會過期,毫無疑問他們不能從中讀取。
所以,瀏覽器將把一下請求發送到Facebook所在的伺服器:
GET http://facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: facebook.com
Cookie: datr=1265876274-[...]; locale=en_US; lsd=WW[...]; c_user=2101[...]
GET 這個請求定義了要讀取的URL: 「http://facebook.com/」。 瀏覽器自身定義 (User-Agent 頭), 和它希望接受什麼類型的相應 (Accept and Accept-Encoding 頭). Connection頭要求伺服器為了後邊的請求不要關閉TCP連接。
請求中也包含瀏覽器存儲的該域名的cookies。可能你已經知道,在不同頁面請求當中,cookies是與跟蹤一個網站狀態相匹配的鍵值。這樣cookies會存儲登錄用戶名,伺服器分配的密碼和一些用戶設置等。Cookies會以文本文檔形式存儲在客戶機里,每次請求時發送給伺服器。
用來看原始HTTP請求及其相應的工具很多。作者比較喜歡使用fiddler,當然也有像FireBug這樣其他的工具。這些軟體在網站優化時會幫上很大忙。
除了獲取請求,還有一種是發送請求,它常在提交表單用到。發送請求通過URL傳遞其參數(e.g.: http://robozzle.com/puzzle.aspx?id=85)。發送請求在請求正文頭之後發送其參數。
像「http://facebook.com/」中的斜杠是至關重要的。這種情況下,瀏覽器能安全的添加斜杠。而像「http: //example.com/folderOrFile」這樣的地址,因為瀏覽器不清楚folderOrFile到底是文件夾還是文件,所以不能自動添加 斜杠。這時,瀏覽器就不加斜杠直接訪問地址,伺服器會響應一個重定向,結果造成一次不必要的握手。
4. facebook服務的永久重定向響應
圖中所示為Facebook伺服器發回給瀏覽器的響應:
HTTP/1.1 301 Moved Permanently
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
Location: http://www.facebook.com/
P3P: CP="DSP LAW"
Pragma: no-cache
Set-Cookie: made_write_conn=deleted; expires=Thu, 12-Feb-2009 05:09:50 GMT;
path=/; domain=.facebook.com; httponly
Content-Type: text/html; charset=utf-8
X-Cnection: close
Date: Fri, 12 Feb 2010 05:09:51 GMT
Content-Length: 0
伺服器給瀏覽器響應一個301永久重定向響應,這樣瀏覽器就會訪問「http://www.facebook.com/」 而非「http://facebook.com/」。
為什麼伺服器一定要重定向而不是直接發會用戶想看的網頁內容呢?這個問題有好多有意思的答案。
其中一個原因跟搜索引擎排名有 關。你看,如果一個頁面有兩個地址,就像http://www.igoro.com/ 和http://igoro.com/,搜索引擎會認為它們是兩個網站,結果造成每一個的搜索鏈接都減少從而降低排名。而搜索引擎知道301永久重定向是 什麼意思,這樣就會把訪問帶www的和不帶www的地址歸到同一個網站排名下。
還有一個是用不同的地址會造成緩存友好性變差。當一個頁面有好幾個名字時,它可能會在緩存里出現好幾次。
5. 瀏覽器跟蹤重定向地址
現在,瀏覽器知道了「http://www.facebook.com/」才是要訪問的正確地址,所以它會發送另一個獲取請求:
GET http://www.facebook.com/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, [...]
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; [...]
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Cookie: lsd=XW[...]; c_user=21[...]; x-referer=[...]
Host: www.facebook.com
頭信息以之前請求中的意義相同。
6. 伺服器「處理」請求
伺服器接收到獲取請求,然後處理並返回一個響應。
這表面上看起來是一個順向的任務,但其實這中間發生了很多有意思的東西- 就像作者博客這樣簡單的網站,何況像facebook那樣訪問量大的網站呢!
Web 伺服器軟體
web伺服器軟體(像IIS和阿帕奇)接收到HTTP請求,然後確定執行什麼請求處理來處理它。請求處理就是一個能夠讀懂請求並且能生成HTML來進行響應的程序(像ASP.NET,PHP,RUBY...)。
舉 個最簡單的例子,需求處理可以以映射網站地址結構的文件層次存儲。像http://example.com/folder1/page1.aspx這個地 址會映射/httpdocs/folder1/page1.aspx這個文件。web伺服器軟體可以設置成為地址人工的對應請求處理,這樣 page1.aspx的發布地址就可以是http://example.com/folder1/page1。
請求處理
請求處理閱讀請求及它的參數和cookies。它會讀取也可能更新一些數據,並講數據存儲在伺服器上。然後,需求處理會生成一個HTML響應。
所 有動態網站都面臨一個有意思的難點 -如何存儲數據。小網站一半都會有一個SQL資料庫來存儲數據,存儲大量數據和/或訪問量大的網站不得不找一些辦法把資料庫分配到多台機器上。解決方案 有:sharding (基於主鍵值講數據表分散到多個資料庫中),復制,利用弱語義一致性的簡化資料庫。
委 托工作給批處理是一個廉價保持數據更新的技術。舉例來講,Fackbook得及時更新新聞feed,但數據支持下的「你可能認識的人」功能只需要每晚更新 (作者猜測是這樣的,改功能如何完善不得而知)。批處理作業更新會導致一些不太重要的數據陳舊,但能使數據更新耕作更快更簡潔。
7. 伺服器發回一個HTML響應
圖中為伺服器生成並返回的響應:
HTTP/1.1 200 OK
Cache-Control: private, no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Expires: Sat, 01 Jan 2000 00:00:00 GMT
P3P: CP="DSP LAW"
Pragma: no-cache
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
X-Cnection: close
Transfer-Encoding: chunked
Date: Fri, 12 Feb 2010 09:05:55 GMT
2b3Tn@[...]
整個響應大小為35kB,其中大部分在整理後以blob類型傳輸。
內容編碼頭告訴瀏覽器整個響應體用gzip演算法進行壓縮。解壓blob塊後,你可以看到如下期望的HTML:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
lang="en" id="facebook" class=" no_js">
<head>
<meta http-equiv="Content-type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-language" content="en" />
...
關於壓縮,頭信息說明了是否緩存這個頁面,如果緩存的話如何去做,有什麼cookies要去設置(前面這個響應里沒有這點)和隱私信息等等。
請注意報頭中把Content-type設置為「text/html」。報頭讓瀏覽器將該響應內容以HTML形式呈現,而不是以文件形式下載它。瀏覽器會根據報頭信息決定如何解釋該響應,不過同時也會考慮像URL擴展內容等其他因素。
8. 瀏覽器開始顯示HTML
在瀏覽器沒有完整接受全部HTML文檔時,它就已經開始顯示這個頁面了:
9. 瀏覽器發送獲取嵌入在HTML中的對象
在瀏覽器顯示HTML時,它會注意到需要獲取其他地址內容的標簽。這時,瀏覽器會發送一個獲取請求來重新獲得這些文件。
下面是幾個我們訪問facebook.com時需要重獲取的幾個URL:
圖片
http://static.ak.fbcdn.net/rsrc.php/z12E0/hash/8q2anwu7.gif
http://static.ak.fbcdn.net/rsrc.php/zBS5C/hash/7hwy7at6.gif
…
CSS 式樣表
http://static.ak.fbcdn.net/rsrc.php/z448Z/hash/2plh8s4n.css
http://static.ak.fbcdn.net/rsrc.php/zANE1/hash/cvtutcee.css
…
JavaScript 文件
http://static.ak.fbcdn.net/rsrc.php/zEMOA/hash/c8yzb6ub.js
http://static.ak.fbcdn.net/rsrc.php/z6R9L/hash/cq2lgbs8.js
…
這些地址都要經歷一個和HTML讀取類似的過程。所以瀏覽器會在DNS中查找這些域名,發送請求,重定向等等...
但 不像動態頁面那樣,靜態文件會允許瀏覽器對其進行緩存。有的文件可能會不需要與伺服器通訊,而從緩存中直接讀取。伺服器的響應中包含了靜態文件保存的期限 信息,所以瀏覽器知道要把它們緩存多長時間。還有,每個響應都可能包含像版本號一樣工作的ETag頭(被請求變數的實體值),如果瀏覽器觀察到文件的版本 ETag信息已經存在,就馬上停止這個文件的傳輸。
試著猜猜看「fbcdn.net」在地址中代表什麼?聰明的答案是"Facebook內容分發網路"。Facebook利用內容分發網路(CDN)分發像圖片,CSS表和JavaScript文件這些靜態文件。所以,這些文件會在全球很多CDN的數據中心中留下備份。
靜態內容往往代表站點的帶寬大小,也能通過CDN輕松的復制。通常網站會使用第三方的CDN。例如,Facebook的靜態文件由最大的CDN提供商Akamai來託管。
舉例來講,當你試著ping static.ak.fbcdn.net的時候,可能會從某個akamai.net伺服器上獲得響應。有意思的是,當你同樣再ping一次的時候,響應的伺服器可能就不一樣,這說明幕後的負載平衡開始起作用了。
10. 瀏覽器發送非同步(AJAX)請求
在Web 2.0偉大精神的指引下,頁面顯示完成後客戶端仍與伺服器端保持著聯系。
以 Facebook聊天功能為例,它會持續與伺服器保持聯系來及時更新你那些亮亮灰灰的好友狀態。為了更新這些頭像亮著的好友狀態,在瀏覽器中執行的 JavaScript代碼會給伺服器發送非同步請求。這個非同步請求發送給特定的地址,它是一個按照程式構造的獲取或發送請求。還是在Facebook這個例 子中,客戶端發送給http://www.facebook.com/ajax/chat/buddy_list.php一個發布請求來獲取你好友里哪個 在線的狀態信息。
提起這個模式,就必須要講講"AJAX"-- 「非同步JavaScript 和 XML」,雖然伺服器為什麼用XML格式來進行響應也沒有個一清二白的原因。再舉個例子吧,對於非同步請求,Facebook會返回一些JavaScript的代碼片段。
除了其他,fiddler這個工具能夠讓你看到瀏覽器發送的非同步請求。事實上,你不僅可以被動的做為這些請求的看客,還能主動出擊修改和重新發送它們。AJAX請求這么容易被蒙,可著實讓那些計分的在線游戲開發者們郁悶的了。(當然,可別那樣騙人家~)
Facebook聊天功能提供了關於AJAX一個有意思的問題案例:把數據從伺服器端推送到客戶端。因為HTTP是一個請求-響應協議,所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息,它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息,伺服器就會找到未完成的請求,把新消息做為響應返回給客戶端。
6. 簡述web瀏覽器打開一個文件的過程
A)解析Web頁面的URL,得到Web伺服器的域名
B)通過DNS伺服器獲得Web伺服器的IP地址
C)從Web伺服器獲得URL指定的文檔
D)獲得PC機的IP地址
E)與Web伺服器建立HTTP連接
F)與訪問路由器建立數據鏈路
G)瀏覽器解釋頁面文檔,並顯示在屏幕
H)通過電話網撥號與訪問路由器建立物理連接
I)與Web伺服器建立TCP連接
7. web前端開發的主要工作內容都有哪些
因為每項技術的不斷發展,現在每個企業的業務和發展要求都不一樣。來看看一些公司招聘公告上寫的工作內容,希望對你有所幫助。web前端工程師的工作要求是什麼?負責pc和手機的web前端開發、界面布局、美學設計、web應用程序設計開發、html/css代碼質量控制、java數據處理,熟練掌握Java、css、html等web標准化頁面設計。
消除了不同計算機之間信息交流的障礙。因此,它是目前網路上使用最廣泛的語言,也是Web文檔的主要語言。學好HTML是成為網路開發者的基本條件。2.CSS學好CSS是網頁外觀的重要一點,而CSS可以幫助網頁的外觀更加美觀。3.學習JavaScript的基本語法,以及如何使用JavaScript進行編程,將會提高開發人員的個人技能。4.操作系統了解Unix和Linux的基礎知識,對開發人員是有利的。
8. web瀏覽器的上網過程
tcp/IP協議,,渲染引擎首先通過網路獲得所請求文檔的內容,通常以8K分塊的方式完成。
下面是渲染引擎在取得內容之後的基本流程:
解析html以構建dom樹->構建render樹->布局render樹->繪制render樹
圖2:渲染引擎基本流程
渲染引擎開始解析html,並將標簽轉化為內容樹中的dom節點。接著,它解析外部CSS文件及style標簽中的樣式信息。這些樣式信息以及html中的可見性指令將被用來構建另一棵樹——render樹。
Render樹由一些包含有顏色和大小等屬性的矩形組成,它們將被按照正確的順序顯示到屏幕上。
Render樹構建好了之後,將會執行布局過程,它將確定每個節點在屏幕上的確切坐標。再下一步就是繪制,即遍歷render樹,並使用UI後端層繪制每個節點。
值得注意的是,這個過程是逐步完成的,為了更好的用戶體驗,渲染引擎將會盡可能早的將內容呈現到屏幕上,並不會等到所有的html都解析完成之後再去構建和布局render樹。它是解析完一部分內容就顯示一部分內容,同時,可能還在通過網路下載其餘內容。
9. 簡述web瀏覽器與web伺服器交互的過程
TCP協議:用戶發送請求信息,伺服器認證返回信息,用戶再發送指定訪問頁面請求
UDP協議:用戶發送,伺服器接收,直接傳輸數據信息
10. 瀏覽器採用http協議訪問網頁的工作過程是什麼
過程如下:
用戶在瀏覽器中輸入網址,計算機提取出域名;
瀏覽器通過DNS查找域名對應的IP地址,獲得IP地址後;
嘗試與對應的伺服器建立TCP連接,連接成功之後;
將用戶的請求裝入http數據包,通過建立的tcp連接發送給伺服器,等待數據返回;
如果數據成功返回,比如說,返回的是一個html頁面,則渲染這個頁面(可以理解為顯示出來);
渲染的過程中會遇到一些數據標記,比如圖片,這時候就查找本地緩存,如果緩存里有且沒過期,就使用本地緩存的數據,否則就向伺服器發送請求。