HTTP基礎知識概括（1）

HTTP基礎知識概括（1）

每日寄語：等風來不如追風去

此文章側重點是將零碎的知識點進行概括總結;文章大體講如下知識點：

• HTTP的一次請求過程所通過的流程
• URL、URI、URN的概念及區別
• 字符亂碼的本質
• DNS的域名解析過程
• 請求報文和響應報文的結構：頭、首部字段、主體
• 常見的狀態碼及首部字段

---

一、HTTP一次請求流程

   如上圖可知：HTTP的一次請求過程大體通過如下步驟：

• 一、域名解析：當用戶在瀏覽器上輸入網址按上回車鍵後會進行域名解析來得到所需的服務器的IP地址；
• 二、TCP三次握手創建TCP鏈接：瀏覽器會根據IP地址和端口號向目標服務器發起TCP鏈接；
• 三、鏈接創建發送請求：鏈接創建起來後瀏覽器向服務器發送請求；
• 四、服務器接收請求並處理：（這裏的處理邏輯有多是應用服務器在處理，應用服務器接收請求並處理的過程省略）
• 五、服務器向客戶端發送響應請求
• 六、瀏覽器接收響應報文並根據要求進行渲染頁面。
• 七、TCP四次揮手關閉鏈接。

有兩點問題須要咱們着重關注（面試會問的哦）：DNS解析的過程以及TCP的三次握手和四次揮手；若是想深刻了解能夠參考網上的技術博客。

二、DNS的域名解析過程

    DNS域名解析大體通過的過程以下：

• 一、域名解析首先會在本身本機下的host文件下找
• 二、若是沒有找到會到本地域名解析服務器（Local DNS Server）下找，找到就返回
• 三、若是在Local DNS Server下沒有找到，會跳到根域名服務器解析請求， 根域名服務器返回給LDNS一個所查詢域的主域名服務器（gTLD Server，國際頂尖域名服務器，如.com .cn .org等）地址
• 四、LDNS會向gTLD域名服務器發起請求
• 五、接受請求的gTLD查找並返回這個域名對應的Name Server的地址，這個Name Server就是網站註冊的域名服務器
• 六、Name Server根據映射關係表找到目標ip，返回給LDNS
• 七、LDNS緩存這個域名和對應的ip
• 八、LDNS把解析的結果返回給用戶，用戶根據TTL值緩存到本地系統緩存中，域名解析過程至此結束

---

三、URL、URI、URN的概念及區別

名    稱	描 述
URI	(Uniform Resource Identifier,URI) 統一資源標誌符；惟一標誌並定位信息資源。
URL	(Uniform Resource Location，URL)統一資源定位符；明確說明如何從一個精準、固定的位置獲取資源。下面會詳細介紹URL的標準格式。
URN	(Uniform Resource Name，URN) 統一資源名；URN是做爲特定內容的惟一名稱使用的，與目前的資源所在定無關。

URL的標準格式

URL的通用格式
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

其中URL最重要的3個部分是方案<scheme>、主機<host>、路徑<path>

   其中咱們應注意帶有片斷的URL的請求：好比：http://www.joes-hardware.com/...; 在這個例子中，片斷drills引用了Joe的五金商店的web服務器上頁面/tools.html中的一個部分，這個部分的名字叫作dirlls。那這個請求是如何進行的呢？因爲HTTP服務器一般只處理整個對象，而不是對象的片斷，因此瀏覽器向服務器發送請求的時會剔除片斷向瀏覽器請求整個資源，瀏覽器接受資源後會根據片斷展現所應該展現的內容。

---

四、字符亂碼的本質

首先，咱們的明白什麼是字符集以及一個字符集來講要正確編碼轉碼一個字符須要三個關鍵元素

        字符集:字符集就規定了某個文字對應的二進制數字存放方式（編碼）和某串二進制數值表明了哪一個文字（解碼）的轉換關係。
        一個字符集來講要正確編碼轉碼一個字符須要三個關鍵元素：

• 字符庫：是一個至關於全部可讀或者可顯示字符的數據庫，字庫表決定了整個字符集可以展示表示的全部字符的範圍；
• 編碼字符集：即用一個編碼值code point來表示一個字符在字庫中的位置；
• 字符編碼：將編碼字符集和實際存儲數值之間的轉換關係。

三者之間的關係以下圖：

舉例：

假如採用ASCII字符集，字符A在字符表中位置爲65，65經規則轉化爲1000001（1000001就存儲在編碼字符集中），而65和1000001的對應關係就存在了字符編碼中，而字符亂碼是由於採用不一樣的編碼其映射關係不一樣解析的數據也就不一樣了。

問題擴展 (摘錄)

   看到這裏，可能不少讀者都會有和我當初同樣的疑問：字庫表和編碼字符集看來是必不可少的，那既然字庫表中的每個字符都有一個本身的序號，直接把序號做爲存儲內容就行了。爲何還要畫蛇添足經過字符編碼把序號轉換成另一種存儲格式呢？

   其實緣由也比較容易理解：統一字庫表的目的是爲了可以涵蓋世界上全部的字符，但實際使用過程當中會發現真正用的上的字符相對整個字庫表來講比例很是低。例如中文地區的程序幾乎不會須要日語字符，而一些英語國家甚至簡單的ASCII字庫表就能知足基本需求。而若是把每一個字符都用字庫表中的序號來存儲的話，每一個字符就須要3個字節（這裏以Unicode字庫爲例），這樣對於本來用僅佔一個字符的ASCII編碼的英語地區國家顯然是一個額外成本（存儲體積是原來的三倍）。算的直接一些，一樣一塊硬盤，用ASCII能夠存1500篇文章，而用3字節Unicode序號存儲只能存500篇。因而就出現了UTF-8這樣的變長編碼。在UTF-8編碼中本來只須要一個字節的ASCII字符，仍然只佔一個字節。而像中文及日語這樣的複雜字符就須要2個到3個字節來存儲。

五、參考文獻

• 《HTTP權威指南》
• 《圖解HTTP》
• 史上最通俗，完全搞懂字符亂碼問題的本質

未完待續。。。。；若是閱讀過程當中發現文中的知識點有錯誤的話，能夠反饋給我，咱們共同來完善。