1，DNS概述
DNS 是計算機域名系統 (Domain Name System 或Domain Name Service) 的縮寫，由解析器和域名服務器組成的。
域名服務器是指保存有該網絡中所有主機的域名和對應IP地址，並具有將域名轉換爲IP地址功能的服務器。
一般一個域名的 DNS解析時間 在10~60毫秒之間。
注意：一個域名必須對應一個IP地址，而一個IP地址不一定會有域名。
2，網絡通信簡單過程如下：
1，瀏覽器通過 DNS服務器 查找域名對應的 IP地址;
2，向 IP地址 對應的 Web服務器 發送請求;
3，Web服務器 響應請求，發回 HTML頁面;
4，瀏覽器解析 HTML內容，並顯示出來。
看如下圖詳解：
3，HTTP和HTTPS區別
HTTP協議（HyperText Transfer Protocol，超文本傳輸協議）：是一種發佈和接收 HTML頁面的方法。
HTTPS（Hypertext Transfer Protocol over Secure Socket Layer）簡單講是HTTP的安全版，在HTTP下加入SSL層。
SSL（Secure Sockets Layer 安全套接層）主要用於Web的安全傳輸協議，在傳輸層對網絡連接進行加密，保障在Internet上數據傳輸的安全。
HTTP的端口號爲80，
HTTPS的端口號爲443
網絡爬蟲抓取過程可以理解爲模擬瀏覽器操作的過程。
瀏覽器的主要功能是向服務器發出請求，在瀏覽器窗口中展示您選擇的網絡資源，HTTP是一套計算機通過網絡進行通信的規則。
4,瀏覽器發送HTTP請求過程
1，當用戶在瀏覽器的地址欄中輸入一個URL地址並按回車鍵之後，瀏覽器會向HTTP服務器發送HTTP請求。當我們在瀏覽器輸入URL http://www.baidu.com 的時候，瀏覽器發送一個Request請求去獲取 http://www.baidu.com 的html文件，服務器把Response文件對象發送回給瀏覽器。
2，瀏覽器分析Response中的 HTML，發現其中引用了很多其他文件，比如Images文件，CSS文件，JS文件。 瀏覽器會自動再次發送Request去獲取圖片，CSS文件，或者JS文件等。
3，當所有的文件都下載成功後，網頁會根據HTML語法結構，完整的顯示出來了。
URL（Uniform / Universal Resource Locator的縮寫）：統一資源定位符，是用於完整地描述Internet上網頁和其他資源的地址的一種標識方法。如下圖：
基本格式：scheme://host[:port]/path/…/[?query-string][#anchor]
scheme：協議(例如：http, https, ftp)
host：服務器的IP地址或者域名
port：服務器的端口（如果是走協議默認端口，缺省端口80）
path：訪問資源的路徑
query-string：參數，發送給http服務器的數據
anchor：錨（跳轉到網頁的指定錨點位置）
5，客戶端HTTP請求
1，請求消息格式
URL只是標識資源的位置，而HTTP是用來提交和獲取資源。客戶端發送一個HTTP請求到服務器的請求消息，包括以下格式：
請求行、請求頭部、空行、請求數據
四個部分組成，下圖給出了請求報文的一般格式。
2，一個典型的HTTP請求示例
3，請求方法
HTTP 1.0：完善的請求/響應模型，並將協議補充完整，定義了三種請求方法： GET, POST 和 HEAD方法。
HTTP 1.1：在 1.0 基礎上進行更新，新增了五種請求方法：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。
HTTP 2.0（未普及）：請求/響應首部的定義基本沒有改變，只是所有首部鍵必須全部小寫，而且請求行要獨立爲 :method、:scheme、:host、:path這些鍵值對。
4，HTTP請求主要分爲Get和Post兩類：
GET是從服務器上獲取指定頁面信息，POST是向服務器提交數據並獲取頁面信息。
GET請求參數都顯示在URL上，服務器根據該請求所包含URL中的參數來產生響應內容。 “Get” 請求的參數 是URL的一部分。
POST請求參數在請求體當中，消息長度沒有限制而且以隱式的方式進行發送，通常用來向HTTP服務器提交量比較大的數據（比如請求中包含許多參數或者文件上傳操作等）。 “POST”請求的參數 不在URL中，而在請求體中。
頁面的form表單一般都有method屬性，默認值是”get”。
舉個栗子，登錄時提交用戶名和密碼：
+ 如果用”get”方式，提交表單後，則用戶輸入的用戶名和密碼將在地址欄中暴露無遺；
+ 如果設置爲”post，則提交表單後，地址欄不會有用戶名和密碼的顯示。
所以處理登錄頁面的form表單時，發送的請求都是”POST”方式。
5，常用的請求報頭
1. Host (主機和端口號)
Host：對應網址URL中的Web名稱和端口號，用於指定被請求資源的Internet主機和端口號，通常屬於URL的Host部分。
2. Connection (連接類型)
Connection：表示客戶端與服務連接類型，通常情況下：
Client 發起一個包含 Connection:keep-alive 的請求（HTTP/1.1使用 keep-alive 爲默認值，是長連接的類型）
Server收到請求後：
如果 Server 支持 keep-alive，回覆一個包含 Connection:keep-alive 的響應，不關閉連接；
如果 Server 不支持 keep-alive，回覆一個包含 Connection:close 的響應，關閉連接。
如果client收到包含 Connection:keep-alive 的響應，向同一個連接發送下一個請求，直到一方主動關閉連接。
Connection : keep-alive 在很多情況下能夠重用連接，減少資源消耗，縮短響應時間。比如當瀏覽器需要多個文件時(比如一個HTML文件和多個Image文件)，不需要每次都去請求建立連接。
3. Upgrade-Insecure-Requests (升級爲HTTPS請求)
Upgrade-Insecure-Requests：升級不安全的請求，意思是會在加載 http 資源時自動替換成 https 請求，讓瀏覽器不再顯示https頁面中的http請求警報。
HTTPS 是以安全爲目標的 HTTP 通道，所以在 HTTPS 承載的頁面上不允許出現 HTTP 請求，一旦出現就是提示或報錯。
4. User-Agent (瀏覽器名稱)
User-Agent：標識客戶端身份的名稱，通常頁面會根據不同的User-Agent信息自動做出適配，甚至返回不同的響應內容。
5. Accept (傳輸文件類型)
Accept：指瀏覽器或其他客戶端可以接受的MIME（Multipurpose Internet Mail Extensions（多用途互聯網郵件擴展））文件類型，服務器可以根據它判斷並返回適當的文件格式。
舉例：
Accept: */*：表示什麼都可以接收。
Accept：image/gif：表明客戶端希望接受GIF圖像格式的資源；
Accept：text/html：表明客戶端希望接受html文本。
Accept: text/html, application/xhtml+xml;q=0.9, image/*;q=0.8：表示瀏覽器支持的 MIME 類型分別是 html文本、xhtml和xml文檔、所有的圖像格式資源。
q是權重係數，範圍 0 =< q <= 1，q 值越大，請求越傾向於獲得其“;”之前的類型表示的內容。若沒有指定q值，則默認爲1，按從左到右排序順序；若被賦值爲0，則用於表示瀏覽器不接受此內容類型。
Text：用於標準化地表示的文本信息，文本消息可以是多種字符集和或者多種格式的；Application用於傳輸應用程序數據或者二進制數據。6. Referer (頁面跳轉來源)
Referer：表明產生請求的網頁來自於哪個URL，用戶是從該 Referer頁面訪問到當前請求的頁面。這個屬性可以用來跟蹤Web請求來自哪個頁面，是從什麼網站來的等。
防盜鏈：有時候遇到下載某網站圖片，需要對應的referer，否則無法下載圖片，那是因爲人家做了防盜鏈，原理就是根據referer去判斷是否是本網站的地址，如果不是，則拒絕，如果是，就可以下載。
7. Accept-Encoding（文件編解碼格式）
Accept-Encoding：指出瀏覽器可以接受的編碼方式。編碼方式不同於文件格式，它是爲了壓縮文件並加速文件傳遞速度。瀏覽器在接收到Web響應之後先解碼，然後再檢查文件格式，許多情形下這可以減少大量的下載時間。
舉例：Accept-Encoding:gzip;q=1.0, identity; q=0.5, *;q=0
如果有多個Encoding同時匹配, 按照q值順序排列，本例中按順序支持 gzip, identity壓縮編碼，支持gzip的瀏覽器會返回經過gzip編碼的HTML頁面。
如果請求消息中沒有設置這個報頭，通常服務器假定客戶端不支持壓縮，直接返回文本。
8. Accept-Language（語言種類）
Accept-Langeuage：指出瀏覽器可以接受的語言種類，如en或en-us指英語，zh或者zh-cn指中文，當服務器能夠提供一種以上的語言版本時要用到。
如果目標網站支持多個語種的話，可以使用這個信息來決定返回什麼語言的網頁。
9. Accept-Charset（字符編碼）
Accept-Charset：指出瀏覽器可以接受的字符編碼。
舉例：Accept-Charset:iso-8859-1,gb2312,utf-8
ISO8859-1：通常叫做Latin-1。Latin-1包括了書寫所有西方歐洲語言不可缺少的附加字符，英文瀏覽器的默認值是ISO-8859-1.
gb2312：標準簡體中文字符集;
utf-8：UNICODE 的一種變長字符編碼，可以解決多種語言文本顯示問題，從而實現應用國際化和本地化。
如果在請求消息中沒有設置這個域，默認客戶端是任何字符集都可以接受，則返回網頁charset指定的編碼。
10. Cookie
Cookie：瀏覽器用這個屬性向服務器發送Cookie。Cookie是在瀏覽器中寄存的小型數據體，它可以記載和服務器相關的用戶信息，也可以用來實現模擬登陸。
11. Content-Type (POST數據類型)
Content-Type：POST請求裏用來表示的內容類型。
舉例：Content-Type = Text/XML; charset=gb2312：
指明該請求的消息體中包含的是純文本的XML類型的數據，字符編碼採用“gb2312”。
6，服務端HTTP響應
1，服務器響應格式
HTTP響應也由四個部分組成，分別是： 狀態行、消息報頭、空行、響應正文，如下圖所示：
2，典型的服務器響應案例
3，常用的響應報頭
1. Cache-Control：must-revalidate, no-cache, private。
這個值告訴客戶端，服務端不希望客戶端緩存資源，在下次請求資源時，必須要從新請求服務器，不能從緩存副本中獲取資源。
Cache-Control是響應頭中很重要的信息，當客戶端請求頭中包含Cache-Control:max-age=0請求，明確表示不會緩存服務器資源時,Cache-Control作爲作爲迴應信息，通常會返回no-cache，意思就是說，”那就不緩存唄”。
當客戶端在請求頭中沒有包含Cache-Control時，服務端往往會制定針對不同的資源，採用不同的緩存策略。比如說oschina在緩存圖片資源的策略就是Cache-Control：max-age=86400,這個意思是，從當前時間開始，在86400秒的時間內，客戶端可以直接從緩存副本中讀取資源，而不需要向服務器請求。
2. Connection：keep-alive
這個字段作爲迴應客戶端的Connection：keep-alive，告訴客戶端服務器的tcp連接也是一個長連接，客戶端可以繼續使用這個tcp連接發送http請求。
3. Content-Encoding:gzip
告訴客戶端，服務端發送的資源是採用gzip編碼的，客戶端看到這個信息後，應該採用gzip對資源進行解碼。
4. Content-Type：text/html;charset=UTF-8
告訴客戶端，資源文件的類型，還有字符編碼，客戶端通過utf-8對資源進行解碼，然後對資源進行html解析。通常我們會看到有些網站是亂碼的，往往就是服務器端沒有返回正確的編碼。
5. Date：Sun, 2 Sep 2015 05:10:11 GMT
這個是服務端發送資源時的服務器時間，GMT是格林尼治所在地的標準時間。http協議中發送的時間都是GMT的，這主要是解決在互聯網上，不同時區在相互請求資源的時候，時間混亂問題。
6. Expires:Sun, 1 Jan 2000 01:00:00 GMT
這個響應頭也是跟緩存有關的，告訴客戶端在這個時間前，可以直接訪問緩存副本，很顯然這個值會存在問題，因爲客戶端和服務器的時間不一定會都是相同的，如果時間不同就會導致問題。所以這個響應頭是沒有Cache-Control：max-age=*這個響應頭準確的，因爲max-age=date中的date是個相對時間，不僅更好理解，也更準確。
7. Pragma:no-cache
這個含義與Cache-Control等同。
8.Server：Tengine/1.4.6
這個是服務器和相對應的版本，只是告訴客戶端服務器的信息。
9. Transfer-Encoding：chunked
這個響應頭告訴客戶端，服務器發送的資源的方式是分塊發送的。一般分塊發送的資源都是服務器動態生成的，在發送時還不知道發送資源的大小，所以採用分塊發送，每一塊都是獨立的，獨立的塊都能標示自己的長度，最後一塊是0長度的，當客戶端讀到這個0長度的塊時，就可以確定資源已經傳輸完了。
10. Vary: Accept-Encoding
告訴緩存服務器，緩存壓縮文件和非壓縮文件兩個版本，現在這個字段用處並不大，因爲現在的瀏覽器都是支持壓縮的。
