http與www服務精解
TCP/IP 協議介紹
在介紹 HTTP 協議之前，先簡單說一下TCP/IP協議的相關內容。TCP/IP協議是分層的，從底層至應用層分別為：物理層、鏈路層、網路層、傳輸層和應用層，如下圖所示： 
從應用層至物理層，資料是一層層封裝，封裝的方式一般都是在原有資料的前面加一個數據控制頭，資料封裝格式如下：
其中，對於TCP傳輸協議，客戶端在於伺服器建立連線前需要經過TCP三層握手，過程如下：
HTTP協議簡介
超文字傳輸協議（Hypertext Transfer Protocol，簡稱HTTP）是應用層協議，是網際網路上應用最為廣泛的一種網路協議。所有的www都必須遵守這個標準，設計HTTP最初的目的是為了提供一種釋出和接收HTML頁面的方法。
HTTP 是一種請求/響應式的協議。一個客戶機與伺服器建立連線後，傳送一個請求給伺服器；伺服器接到請求後，給予相應的響應資訊。
HTTP 的第一版本 HTTP/0.9是一種簡單的用於網路間原始資料傳輸的協議；
HTTP/1.0由 RFC 1945 定義 ，在原 HTTP/0.9 的基礎上，有了進一步的改進，允許訊息以類 MIME 資訊格式存在，包括請求/響應正規化中的已傳輸資料和修飾符等方面的資訊；
HTTP/1.1(RFC2616) 的要求更加嚴格以確保服務的可靠性，增強了在HTTP/1.0 沒有充分考慮到分層代理伺服器、高速緩衝儲存器、持久連線需求或虛擬主機等方面的效能；
安全增強版的 HTTP （即S-HTTP或HTTPS），則是HTTP協議與安全套介面層(SSL)的結合，使HTTP的協議資料在傳輸過程中更加安全。
埠對應的服務
21 ftp
22 ssh sftp
25 smtp
3306 mysql
873 rsync
161 snmp
111 rpc
3389 windows 遠端桌面
80 http
443 https
110 pop3
55 dns
協議結構
HTTP協議格式也比較簡單，格式如下：
請求頭格式
a) 通用頭(general-header)：
Cache-Control：客戶端希望服務端如何快取自己的請求資料。
Connection：客戶端是否希望與服務端之間保持長連線。
Date：只有當請求方法為POST或get方法時客戶端才可能會有些欄位。
Pragma：包含了客戶端一些特殊請求資訊。
b) 請求頭(request-header)：
Accept： 表明客戶同端可接受的請求迴應的媒體類型範圍列表。“*”用於按範圍將型別分組，用“*/*”指示可接受全部型別；用“type/*”指示可接受 type型別的所有子型別，
Accept-Charset：客戶端所能識別的字符集編碼格式，格式：“ Accept-Charset: 字符集1[:權重]，字符集2[:權重] ”，如：“ Accept-Charset: iso-8859-5, unicode-1-1;q=0.8”；
Accept-Language：客戶端所能識別的語言，格式：“ Accept-Language: 語言1[:權重]，語言2[:權重] ”，如：” Accept-Language: zh, en;q=0.7”；
Host：客戶請求的主機域名或主機IP，格式：“ Host: 域名或IP[:埠號] ”，如：“Host: www.mysq.com:80“，請求行中若有HTTP/1.1則必須有該請求頭；
User-Agent：表明使用者所使用的瀏覽器標識，主要用於統計的目的；
Referer：指明該請求是從哪個關聯連線而來；
Accept-Encoding：客戶端所能識別的編碼壓縮格式，如：“Accept-Encoding: gzip, deflate”。
If- Modified-Since：該欄位與客戶端快取相關，客戶端所訪問的URL自該指定日期以來在服務端是否被修改過，如果修改過則服務端返回新的修改後 的資訊，如果未修改過則伺服器返回304表明此請求所指URL未曾修改過。
If-None-Match：該欄位與客戶端快取相關，客戶端傳送URL請求的同時傳送該欄位及標識，如 果服務端的標識與客戶端的標識一致，則返回304表明此URL未修改過，如果不一致則服務端返回完整的資料資訊，如：“If-None-Match: 0f0a893aad8c61:253, 0f0a893aad8c61:252, 0f0a893aad8c61:251”；
Cookie：為擴充套件欄位，儲存於客戶端，向同一域名的服務端傳送屬於該域的cookie，如：“Cookie: MailUserName=whouse”；
c) 實體頭(entity-header): (此類頭存在時要求有資料體)
Content-Encoding：客戶端所能識別的編碼壓縮格式，如：“Content-Encoding: gzip, deflate”；
Content-Length：客戶端以POST方法上傳資料時資料體部分的內容長度，如：“ Content-Length: 24”；
Content- Type：客戶端傳送的資料體的內容型別，如：“Content-Type: application/x-www-form-urlencoded”為以普通的POST方法傳送的資料；“Content-Type: multipart/form-data; boundary=---------------------------5169208281820”，則表明資料體由多部分組成，分隔符為 “-----------------------------5169208281820”；
響應格式
a) 通用頭(general-header)：
Cache- Control：服務端要求中間代理及客戶端如何快取自己響應的資料，如“Cache-Control: no-cache”，如：“Cache-Control: private” 不希望被快取，“Cache-Control: public” 可以被快取；
Connection：服務端是否希望與客戶端之間保持長連線，；
Date：只有當請求方法為POST或get方法時客戶端才可能會有些欄位；
Pragma：包含了服務端一些特殊響應資訊，如 “Pragma: no-cache” 服務端希望代理或客戶端不應快取結果資料；
Transfer-Encoding：服務端向客戶端傳輸資料所採用的傳輸模式(僅在HTTP1.1中出現)，如：“Transfer-Encoding: chunked”，注：該欄位的優先順序要高於“Content-Length”欄位的優先順序；
Via：一般用在代理閘道器嚮應用伺服器傳送的請求頭中，表明該來自客戶端的請求經過了閘道器代理，
格式為："Via: 請求協議版本 閘道器標識 [其它資訊] "，
如 ：" Via: 1.1 webcache_250_199.hexun.com:80 (squid)"
b）響應頭(response-header)：
Accept-Ranges：表明服務端接收的資料單位，如：“Accept-Ranges: bytes”, ；
Location：服務端向客戶端返回此資訊以使客戶端進行重定向，如：“Location: http://www.hexun.com”；
Server：服務端返回的用於標識自己的一些資訊，如：“ Server: Microsoft-IIS/6.0”；
ETag：服務端返回的響應資料的標識欄位，客戶端可根據此欄位的值向伺服器傳送某URL是否更新的資訊；
c）實體頭(entity-header): (此類頭存在時要求有資料體)
Content-Encoding：服務端所響應資料的編碼格式。
Content-Length：服務端所返回資料的資料體部分的內容長度。
Content-Type：服務端所返回的資料體的內容型別。
Set-Cookie：服務端返回給客戶端的cookie資料。
伺服器返回狀態碼
1xx：表明服務端接收了客戶端請求，客戶端繼續傳送請求；
2xx：客戶端傳送的請求被服務端成功接收併成功進行了處理；
3xx：服務端給客戶端返回用於重定向的資訊；
4xx：客戶端的請求有非法內容；
5xx：服務端未能正常處理客戶端的請求而出現意外錯誤。
比如：
“100” ; 服務端希望客戶端繼續；
“200” ; 服務端成功接收並處理了客戶端的請求；
“301” ; 客戶端所請求的URL已經移走，需要客戶端重定向到其它的URL；
“304” ; 客戶端所請求的URL未發生變化；
“400” ; 客戶端請求錯誤；
“403” ; 客戶端請求被服務端所禁止；
“404” ; 客戶端所請求的URL在服務端不存在；
“500” ; 服務端在處理客戶端請求時出現異常；
“501” ; 服務端未實現客戶端請求的方法或內容；
“502” ; 此為中間代理返回給客戶端的出錯資訊，表明服務端返回給代理時出錯；
“503” ; 服務端由於負載過高或其它錯誤而無法正常響應客戶端請求；
“504” ; 此為中間代理返回給客戶端的出錯資訊，表明代理連線服務端出現超時。
HTTP 請求方法
GET 、 POST 、HEAD、CONNECT、PUT、DELETE、TRACE、OPTIONS
| 方法 | 描述 |
|---|---|
| HEAD | 與 GET 相同，但只返回 HTTP 報頭，不返回文件主體。 |
| PUT | 上傳指定的 URI 表示。 |
| DELETE | 刪除指定資源。 |
| OPTIONS | 返回伺服器支援的 HTTP 方法。 |
| CONNECT | 把請求連線轉換到透明的 TCP/IP 通道。 |
Html程式碼
a）GET請求
GET http://mail.test.com/ HTTP/1.1 Host: mail.test.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Proxy-Connection: keep-alive
b）POST請求
POST / HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, application/vnd.ms-powerpoint, application/msword, */* Accept-Language: zh-cn Content-Type: application/x-www-form-urlencoded Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Host: www.test.com Content-Length: 24 Connection: Keep-Alive Cache-Control: no-cache name=value&submitsubmit=submit
c）POST方式上傳檔案
POST http://www.test.comt/upload_attach?uidl=%3C HTTP/1.1 Host: www.test.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; zh-CN; rv:1.8.1) Gecko/20061010 Firefox/2.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,zh-cn;q=0.7,zh;q=0.3 Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7 Content-Type: multipart/form-data; boundary=---------------------------5169208281820 Content-Length: 449 -----------------------------5169208281820 Content-Disposition: form-data; name="file_1"; filename="" Content-Type: application/octet-stream -----------------------------5169208281820 Content-Disposition: form-data; name="file_0"; filename="test.txt" Content-Type: text/plain hello world! -----------------------------5169208281820 Content-Disposition: form-data; name="oper" upload -----------------------------5169208281820--
雖然我不寫程式碼，但是還是說一下get與post傳參區別吧，畢竟瞭解過， 1）get引數通過url傳遞，post放在request body中。 2）get請求在url中傳遞的引數是有長度限制的，而post沒有 3）get比post更不安全，因為引數直接暴露在url中，所以不能用來傳遞敏感資訊。 4）get請求只能進行url編碼，而post支援多種編碼方get請求會瀏覽器主動cache，而post支援多種編碼方式。 5）get請求引數會被完整保留在瀏覽歷史記錄裡，而post中的引數不會被保留。 GET和POST本質上就是TCP連結，並無差別。但是由於HTTP的規定和瀏覽器/伺服器的限制，導致他們在應用過程中體現出一些不同，GET產生一個TCP資料包；POST產生兩個TCP資料包。
簡單的說：
對於GET方式的請求，瀏覽器會把http header和data一併傳送出去，伺服器響應200（返回資料）；
而對於POST，瀏覽器先發送header，伺服器響應100 continue，瀏覽器再發送data，伺服器響應200 ok（返回資料）。
總結：http協議通訊原理
１、http是osi模型中應用層協議。http協議的重要應用是www服務。
２、DNS解析原理
３、http請求資訊包含的內容。
４、http服務返回的內容，訊息主體也訊息頭。
５、使用者通過瀏覽器訪問站伺服器的請求到返回資料流程。
靜態網頁
概念：在網站設計中，純粹HTML格式的網頁（可以包含圖片，JS（前端功能實現），CSS（樣式）等）通常被稱為“靜態網頁”。
特點：所有程式在客戶瀏覽器端解析，客戶端如：IE瀏覽器，你編的是什麼，它顯示的就是什麼，一旦編寫完成，就不會有任何改變。維護和更新比較麻煩。
（1）靜態網頁每個頁面都有一個固定的URL，且網頁URL一般以.htm、.html、.shtml等常見形式為字尾，而且地址中不含問好“？”或“&”
（2）網頁內容一經發布到網站伺服器上，無論是否有使用者訪問，每個靜態網頁的內容都是儲存在網頁伺服器上的，也就是說，靜態網頁是實實在在儲存在伺服器上的檔案，每個網頁都是一個獨立的檔案
（3）靜態網頁的內容相對穩定，因此，容易被搜尋引擎收錄（優點，seo）
（4）靜態網頁沒有資料庫的支援，在網站製作和維護方面工作量較大，因此當網站資訊量很大時完全依靠靜態網頁製作的方式比較困難（缺點）
（5）靜態網頁的互動性較差，在功能方面有較大的限制（缺點）
（6）網頁程式在使用者瀏覽器端解析，如IE瀏覽器，這樣程式解析效率更高，由於服務端不進行解析，因此可以接受更多的併發訪問，當客戶端向伺服器請求資料時，伺服器直接把資料返回（不做任何解析），當客戶端拿到資料後，在瀏覽器端解析展現出來。
動態網頁
副檔名：常見副檔名為asp,aspx,php,jsp,cgi,perl等
（1）動態網頁一般以資料庫技術為基礎，可以大大降低網站的維護工作量
（2）採用動態網頁技術的網站可以實現更多的功能，如使用者註冊，使用者登入，線上調查，投票，使用者管理，訂單管理，發博文等等
（3）動態網頁大多並不是獨立存在於伺服器上的網頁檔案，只有當用戶請求時伺服器才返回一個完整的網頁
（4）動態網頁中的“?”對搜尋的收錄存在一定的問題，搜尋引擎一般不可能從一個網站的資料庫中訪問全部網頁，或者出於技術方面的考慮，搜尋蜘蛛一般不會區抓取網址中的“？”後面的內容，因此採用動態網頁的網站在進行搜尋引擎推廣時需要做一定的技術處理（偽靜態）才能適應搜尋引擎的抓取的要求
（5）程式在服務端解析，服務端：php引擎，java容器(tomcat,resin,jboss)
（6）由於程式在服務端解析，因此,會消耗大量的CPU和記憶體等資源，因此，效率遠不如靜態網頁。
偽靜態
偽靜態特點：從URL地址裡看，給人感覺是靜態內容（如地址結尾帶html）,通過rewrite規則實現URL重寫。地址規範、美觀、有利於搜尋引擎抓取。
1、動態網頁偽裝成靜態
2、目的：便於搜尋引擎搜錄，提升使用者訪問量以及使用者體驗。
3、由於僅僅是偽裝，實際上還是動態，效能沒有提升，轉換消耗資源因此效能反而下降。
4、儘可能轉換成真正的靜態頁面，除非併發量不是很大，用rewrite實現偽靜態。
什麼是DNS？
DNS( Domain Name System)是“域名系統”的英文縮寫，是一種組織成域層次結構的計算機和網路服務命名系統，它用於TCP/IP網路，它所提供的服務是用來將主機名和域名轉換為IP地址的工作。DNS就是這樣的一位“翻譯官”，它的基本工作原理可用下圖來表示。
Line"/>
Dns服務的工作過程
當 DNS 客戶機需要查詢程式中使用的名稱時，它會查詢本地DNS 伺服器來解析該名稱。客戶機發送的每條查詢訊息都包括3條資訊，以指定伺服器應回答的問題。
1） 指定的 DNS 域名 ，表示為完全合格的域名 (FQDN) 。
2） 指定的查詢型別 ，它可根據型別指定資源記錄，或作為查詢操作的專門型別。
3） DNS域名的指定類別，它始終應指定為 Internet 類別。
DNS 查詢以各種不同的方式進行解析。客戶機有時也可通過使用從 以前查詢獲得的快取資訊就地應答查詢 。DNS 伺服器可使用其自身的資源記錄資訊快取來應答查詢，也可代表請求客戶機來查詢或聯絡其他 DNS 伺服器，以完全解析該名稱，並隨後將應答返回至客戶機。這個過程稱為 遞迴 。
另外，客戶機自己也可嘗試聯絡其他的 DNS 伺服器來解析名稱。如果客戶機這麼做，它會使用基於伺服器應答的獨立和附加的查詢，該過程稱作 迭代 ，即DNS伺服器之間的互動查詢就是迭代查詢。
DNS解析流程圖（來源於網路）
1、在瀏覽器中輸入www.baidu.com域名，作業系統會先檢查自己本地的hosts檔案是否有這個網址對映關係，如果有，就先呼叫這個IP地址對映，完成域名解析。
2、如果hosts裡沒有這個域名的對映，則查詢本地DNS解析器快取，是否有這個網址對映關係，如果有，直接返回，完成域名解析。
3、如果hosts與本地DNS解析器快取都沒有相應的網址對映關係，首先會找TCP/ip引數中設定的首選DNS伺服器，在此我們叫它本地DNS伺服器，此伺服器收到查詢時，如果要查詢的域名，包含在本地配置區域資源中，則返回解析結果給客戶機，完成域名解析，此解析具有權威性。
4、如果要查詢的域名，不由本地DNS伺服器區域解析，但該伺服器已快取了此網址對映關係，則呼叫這個IP地址對映，完成域名解析，此解析不具有權威性。
5、如果本地DNS伺服器本地區域檔案與快取解析都失效，則根據本地DNS伺服器的設定（是否設定轉發器）進行查詢，如果未用轉發模式，本地DNS就把請求發至根DNS，根DNS伺服器收到請求後會判斷這個域名(.com)是誰來授權管理，並會返回一個負責該頂級域名伺服器的一個IP。本地DNS伺服器收到IP資訊後，將會聯絡負責.com域的這臺伺服器。這臺負責.com域的伺服器收到請求後，如果自己無法解析，它就會找一個管理.com域的下一級DNS伺服器地址(baidu.com)給本地DNS伺服器。當本地DNS伺服器收到這個地址後，就會找baiducom域伺服器，重複上面的動作，進行查詢，直至找到www.qq.com主機。
6、如果用的是轉發模式，此DNS伺服器就會把請求轉發至上一級DNS伺服器，由上一級伺服器進行解析，上一級伺服器如果不能解析，或找根DNS或把轉請求轉至上上級，以此迴圈。不管是本地DNS伺服器用是是轉發，還是根提示，最後都是把結果返回給本地DNS伺服器，由此DNS伺服器再返回給客戶機。