1. 瀏覽器採用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是一個請求-響應協議，所以聊天伺服器不能把新消息發給客戶。取而代之的是客戶端不得不隔幾秒就輪詢下伺服器端看自己有沒有新消息。
這些情況發生時長輪詢是個減輕伺服器負載挺有趣的技術。如果當被輪詢時伺服器沒有新消息，它就不理這個客戶端。而當尚未超時的情況下收到了該客戶的新消息，伺服器就會找到未完成的請求，把新消息做為響應返回給客戶端。
2. 應該如何製作web流程圖
一、設計的任務：設計是一種審美活動，成功的設計作品一般都很藝術化。但藝術只是設計的手段，而並非設計的任務。設計的任務是要實現設計者的意圖，而並非創造美。 網頁設計的任務，是指設計者要表現的主題和要實現的功能。站點的性質不同，設計的任務也不同。從形式上，可以將站點分為以下三類。 第一類是資訊類站點，像新浪、網易、搜狐等門戶網站。這類站點將為訪問者提供大量的信息，而且訪問量較大。因此需注意頁面的分割、結構的合理、頁面的優化、界面的親和等問題。 第二類是資訊和形象相結合的網站，像一些較大的公司、國內的高校等。這類網站在設計上要求較高，既要保證資訊類網站的上述要求，同時又要突出企業、單位的形象。然而就現狀上來看，這類網站有粗製濫造的嫌疑。 第三類則是形象類網站，比如一些中小型的公司或單位。這類網站一般較小，有的則有幾頁，需要實現的功能也較為簡單，網頁設計的主要任務是突出企業形象。這類網站對設計者的美工水平要求較高。 當然，這只是從整體上來看，具體情況還要具體分析。不同的站點還要區別對待。別忘了最重要的一點，那就是客戶的要求，它也屬於設計的任務。
3. 簡述web瀏覽器打開一個web文件的工作過程
web瀏覽器打開一個web文件的工作過程如下：
1、在瀏覽器地址欄中輸入要訪問的主頁的地址；
2、用戶向瀏覽器發送拜訪請求，請求訪問該網站。
3、伺服器收到客戶端的訪問請求；
4、伺服器處理該請求（如果需要處理主頁上的動態文檔然後返回，如果是靜態文檔，則可以直接返回）；
5、伺服器在客戶端的瀏覽器上顯示請求的處理結果。
(3)web應用訪問網站的流程圖擴展閱讀：
web工作表現形式
1、超文本（超文本）
超文本是一種用於顯示文本和與文本相關的內容的用戶界面方法。目前，超文本通常以電子文檔的形式存在。
文本包含可以鏈接到其他欄位或文檔的超文本鏈接，從而允許從當前閱讀位置直接切換到超文本鏈接指向的文本。
2、超媒體
超媒體是超媒體的縮寫。它是信息瀏覽環境中超文本和多媒體的結合。用戶不僅可以從一個文本跳到另一個文本，還可以激活聲音，顯示圖形甚至播放動畫。
Internet使用超文本和超媒體信息組織方法將信息鏈接擴展到整個Internet。 Web是一種超文本信息系統，其主要概念之一是超文本鏈接。
3、超文本傳輸協議（HTTP，超文本傳輸協議）是Internet上使用最廣泛的網路協議。
4. 跪求一份在win7(旗艦版)下如何利用iis搭建web伺服器的流程圖（最好配有截圖）謝謝高手同胞！
進入windows 7的 控制面板，選擇左側的(turn windows features on or off)打開或關閉Windows功能，單擊後會出現安裝Windows功能的選項菜單，找到「internet information services「,把所需要的都打上勾
2：:在桌面右鍵「我的電腦」—選擇「manage」—「services and applications」-「internet information services managemer」
3：選擇 Default Web Site，並雙擊 ASP 的選項IIS7中」ASP」—「enable parent path」選擇"true"。
4: 右鍵「default web site」—「manage web site』—「advanced settings」—「physical path」選擇你本地源碼的位置，到這里基本上iis的配置已經可以了，不過小7還有個許可權的問題。下面就一起來搞定：呵呵：
首先，找到系統安裝盤:\Windows\ServiceProfiles\NetworkService\AppData\Local（註：該文件是屬於隱藏的文件，所以建議直接在地址欄輸入上面的路徑）
然後，右鍵「temp」文件夾—「properties」—「security」—「edit」—「add」—在底部的輸入框輸入字母「A」—「check names」—找到Athenticated Users這個用戶—「ok」
最後：賦予這個Athenticated Users所有許可權，把Allow 下面的復選框都打上鉤，注意：在這部過程中，會有安全提示你的，點ok就是了
一般在這里就可以了，只要你的路徑（physical path）指向的是你的本地某個站點的目錄就可以了，不過如果你的路徑不是指向某也指定的站點的時候就會報錯，這樣你就的在配置裡面做下更改了，下面我們一起來：
打開iis管理器—找到並雙擊「directory browsing」—在裡面的「time,size,extension,data,long data」的前面都打上鉤，最後點擊左側的「apply」,做完這一部，就可以不用把路徑指向某一特定站點了，可以直接指向你所有源碼所在的目錄（比如你在D盤下有asp文件，下面全是asp源碼，這樣你就可以直接指向Asp這個文件夾，而不用指向asp文件夾下的某一站點，這樣省的每次打開iis更換路徑）
最後還要註明一下，怎麼設置預設首頁文件(index.asp—index.html等等)，跟上面一部差不多，只是找到並雙擊 「default document」在裡面進行設置就可以了，一般需要自己加入「index.asp」，在這里也可以更改他們的順序,」move up」或者」move down」
5. web開發流程圖 一般用什麼軟體
1. Codepen
Codepen應該是全世界最受歡迎的開發環境之一了。CSS技巧的作者Chris Coyier是Codepen的聯合創始人之一，這也就是為什麼這款app看起來那麼豪華。除了視覺上的優秀效果，它可以生動地展現預覽，當你修改了代碼，就可以看到效果，使你能夠更容易地找出變化。
Codepen用於CSS的預處理器包括SCSS、SASS，LESS和Stylus，用於JS的有CoffeeScript和LiveScript，用於HTML的包括Haml、Markdown、Slim和Jade。另外，它還包含了8個可用的內置的JS庫。Codepen中合作和私人的「pens」需要付費使用。【前往Codepen】
2. JSFiddle
JSFiddle可以說是成就了開發環境的流行，它是第一個也是最出名的平台。JSFiddle有超過30個可以立即使用的JavaScript庫，你還可以輕松的添加外部文件。在預處理方面，它有用於CSS的SCSS、用於JS的CoffeeScript以及用於HTML的簡單Vanilla。
如果你在與其他開發者合作，我強烈建議你使用JSFiddle。在所有的開發環境中，JSFiddle的協作特性是同類型應用中最好的，而且區別於Codepen的是，它的這個特性是操作簡單並且免費的。
但JSFiddle沒有的是預覽功能，你需要手動刷新頁面。和其它開發平台相比，JSFiddle確實也比較慢。另外，JSFiddle還有一個不足就是它的執行鍵不是很靈敏，有時需要多點擊幾次才能夠執行代碼。【前往JSFiddle】
3. JS Bin
JS Bin是由JavaScript開發大師Remy Sharp創建的，他擁有一家專注於JavaScript和HTML5的web開發公司。JS Bin的JS預處理器包括CoffeeScript、TypeScript、Traceur、JSX以及可供使用的超過40個的JS庫。你同樣可以添加外部文件，但是必須在編輯器上手動操作。而用於CSS的預處理器，它提供了LESS。
JS Bin和以前開發平台的區別在於它允許你把文件下載到你的電腦上，這對於開發者，尤其是在離線狀態下調試代碼的程序員來說，是一個很不錯的特點。你還可以創建私人的Bin空間，不過你需要對此付費。另外，JS Bin不支持協作功能。【前往JS Bin】
4. CSSDeck
CSSDeck已經存在一些年了，但它的影響力好像不是很大。不過，由於它的簡潔性，它還是值得關注的。如果你不需要其它平台里那些復雜的功能，那CSSDeck就應該是你的選擇。
CSSDeck的預處理器包括用於HTML的HAML、Markdown、Slim和Jade，用於CSS的LESS、Stylus、SASS和SCSS，以及用於JS的CoffeeScript。它還有幾個可用的CSS和javascript庫，對於沒有的庫，你只需要將其手動地添加到庫的列表中就可以使用了。
CSSDeck雖然很簡潔，但它有一個讓我很吃驚的特性，就是它支持用戶改變字體大小，這是一個簡單卻實用的功能。所以說，如果你在尋找有很多很炫的功能的開發平台，CSSDeck可能不適合你。它的簡潔性讓你更專注於最重要的事情，這也是它最大的特點。【前往CSSDeck】
5. Dabblet
當我還在使用十六進制顏色代碼的時候，Dabblet的特性讓我驚訝了，它的顏色預覽居然顯示在代碼旁，這是我第一次見到這樣的設置。雖然我不確定這是否是一個有用的特性，但是它的整潔性還是給我留下了很深的印象。
現在，Dabblet最棒的地方在於它允許用戶以5個不同的視角進行預覽，分別是CSS編輯器和效果，HTML編輯器和效果，CSS和HTML的編輯器和效果，JavaScript及運行結果，全部綜合效果。這些功能在絕大部分的開發環境中都沒有。
它也有不足，第一，Dabblet缺乏HTML和CSS的預處理器，這是令人困惑的。第二，它沒有內置的JavaScript庫，不過你可以通過手動插入JavaScript庫來解決。第三，它的每個板塊大小是固定的，無法作出調整，這和以前傳統的調試平台是一樣的。第四，它缺少一個用於演示其他用戶作品的板塊。【前往Dabblet】
6. Liveweave
Liveweave是一個擁有很多功能的開發平台，比如可以關閉的實時預覽。你也可以為了保護視力，開啟夜間模式，將所有界面都變暗。Liveweave提供了20多個JavaScript庫，甚至還支持SVG。其內置的標尺使測量更加精確，更符合美學標准。
它還有一個吸引我眼球的地方，就是它的協作功能。如果你過去曾經使用過Teamviewer，你會發現它們是相似的。你需要做的事只是點擊協作鏈接，你就可以分享來自於你到weave的鏈接了。
你甚至可以下載你的weave文件，並把它保存為單獨的HTML文件或者保存為包含獨立HTML、CSS和JS文件的zip壓縮包。對了，Liveweave還有一個內置的Lorem Ipsum生成器。 【前往Liveweave】
結語
當然，每一個平台和工具都有它自己的特性，都會對你有所幫助
6. 什麼是web應用系統
Web應用程序是一種可以通過Web訪問的應用程序。Web應用程序的一個最大好處是用戶很容易訪問應用程序。用戶只需要有瀏覽器即可，不需要再安裝其他軟體。一個Web應用程序是由完成特定任務的各種Web組件（web components)構成的並通過Web將服務展示給外界。在實際應用中，Web應用程序是由多個Servlet、JSP頁面、HTML文件以及圖像文件等組成。所有這些組件相互協調為用戶提供一組完整的服務。
(6)web應用訪問網站的流程圖擴展閱讀：
應用程序有兩種模式C/S、B/S。C/S是客戶端/伺服器端程序，也就是說這類程序一般獨立運行。而B/S就是瀏覽器端/伺服器端應用程序，這類應用程序一般藉助IE等瀏覽器來運行。WEB應用程序一般是B/S模式。Web應用程序首先是「應用程序」，和用標準的程序語言，如C、C++等編寫出來的程序沒有什麼本質上的不同。然而Web應用程序又有自己獨特的地方，就是它是基於Web的，而不是採用傳統方法運行的。換句話說，它是典型的瀏覽器/伺服器架構的產物。
7. 我是做web前端的，要實寫一個流程圖，不會寫，沒思路，求指教
如果這個流程圖是固定的，也就是說是不會隨著數據，改變位置的話，那就做五行七列的格子，然後往格子里加東西應該就可以了。像那個藍色四個角，你可以在這個包裹電話的小盒子里，定位四個小正方形，定位到四個角上。
例外那個每個圖標樣式都是固定的上圖下文，上圖帶四個小正方形的交互，並且大部分帶箭頭，可以寫公共樣式。像那些線，如果嫌麻煩，可以用圖片代替，定位上去。
8. web的工作原理
web的工作原理：
1、用戶在瀏覽器中輸入要訪問的web站點地址或在已打開的站點點擊超鏈接。
2、由DNS進行域名解析，找到伺服器的IP地址，向該地址指向的web伺服器發出請求。
3、web伺服器根據請求將URL地址轉換為頁面所在的伺服器上的文件全名，查找相應的文件。
4、若URL指向靜態文件，則伺服器將文件通過http協議傳輸給用戶瀏覽器；若HTML文檔中嵌入了ASP,PHP,JSP等程序，則由伺服器直接運行後返回給用戶；
如果web伺服器所運行程序包含對資料庫的訪問，伺服器會將查詢指令發送給資料庫伺服器，對資料庫執行查詢操作，查詢結果由資料庫返回給web伺服器，再由web伺服器將結果潛入頁面，並以html格式發送給瀏覽器。
5、瀏覽器解釋html文檔，在客戶端屏幕上展示結果。
(8)web應用訪問網站的流程圖擴展閱讀
web的特點
1、圖形化
Web 非常流行的一個很重要的原因就在於它可以在一頁上同時顯示色彩豐富的圖形和文本的性能。在Web之前Internet上的信息只有文本形式。Web可以提供將圖形、音頻、視頻信息集合於一體的特性。
2、與平台無關
無論用戶的系統平台是什麼，你都可以通過Internet訪問WWW。瀏覽WWW對系統平台沒有什麼限制。無論從Windows平台、UNIX平台、Macintosh等平台我們都可以訪問WWW。
3、分布式的
大量的圖形、音頻和視頻信息會佔用相當大的磁碟空間，我們甚至無法預知信息的多少。對於Web沒有必要把所有信息都放在一起，信息可以放在不同的站點上，只需要在瀏覽器中指明這個站點就可以了。
4、動態的
由於各Web站點的信息包含站點本身的信息，信息的提供者可以經常對站上的信息進行更新。如某個協議的發展狀況，公司的廣告等等。一般各信息站點都盡量保證信息的時間性。所以Web站點上的信息是動態的、經常更新的，這一點是由信息的提供者保證的。
5、交互的
Web的交互性首先表現在它的超鏈接上，用戶的瀏覽順序和所到站點完全由他自己決定。另外通過FORM的形式可以從伺服器方獲得動態的信息。用戶通過填寫FORM可以向伺服器提交請求，伺服器可以根據用戶的請求返回相應信息。