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：服務端未能正常處理客戶端的請求而出現意外錯誤。
詳解請看：http狀態碼
HTTP 請求方法
GET、POST、HEAD、CONNECT、PUT、DELETE、TRACE、OPTIONS
| 方法 | 描述 |
|---|---|
| HEAD | 與 GET 相同，但只返回 HTTP 報頭，不返回文檔主體。 |
| PUT | 上傳指定的 URI 表示。 |
| DELETE | 刪除指定資源。 |
| OPTIONS | 返回服務器支持的 HTTP 方法。 |
| CONNECT | 把請求連接轉換到透明的 TCP/IP 通道。 |
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就是這樣的一位“翻譯官”，它的基本工作原理可用下圖來表示。
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服務器再返回給客戶機。