目錄
- Cookie詳解
- IP地址，域名，DNS 作用
- TCP與 UDP 的比較
- 網絡狀態碼
- GET與POST的區別
一.為什么要有cookie，最開始干嘛用的
1.1 cookies的起源
早期Web開發面臨的最大問題之一是如何管理狀態。簡言之，服務器端沒有辦法知道兩個請求是否來自于同一個瀏覽器。那時的辦法是在請求的頁面中插入一個token，并且在下一次請求中將這個token返回（至服務器）。這就需要在form中插入一個包含token的隱藏表單域，或著在URL的qurey字符串中傳遞該token。這兩種辦法都強調手工操作并且極易出錯。
1.2 cookie是什么？
坦白的說，一個cookie就是存儲在用戶主機瀏覽器中的一小段文本文件。Cookies是純文本形式，它們不包含任何可執行代碼。一個Web頁面或服務器告之瀏覽器來將這些信息存儲并且基于一系列規則在之后的每個請求中都將該信息返回至服務器。Web服務器之后可以利用這些信息來標識用戶。多數需要登錄的站點通常會在你的認證信息通過后來設置一個cookie，之后只要這個cookie存在并且合法，你就可以自由的瀏覽這個站點的所有部分。再次，cookie只是包含了數據，就其本身而言并不有害。
1.3 創建 cookie
通過HTTP的Set-Cookie消息頭，Web服務器可以指定存儲一個cookie。Set-Cookie消息的格式如下面的字符串（中括號中的部分都是可選的）
Set-Cookie:value [ ;expires=date][ ;domain=domain][ ;path=path][ ;secure]
1.4 cookie編碼
對于cookie的值進行編碼一直都存在一些困惑。通常的觀點是cookie的值必須被URL編碼，但是這其實是一個謬誤，盡管可以對cookie的值進行URL編碼。原始的文檔中指示僅有三種類型的字符必須進行編碼：分號，逗號，和空格。規范中提到可以利用URL編碼，但是并不是必須。RFC沒有提及任何的編碼。然而，幾乎所有的實現方式都對cookie的值進行了一些列的URL編碼。對于name=value的格式，name和value通常都單獨進行編碼并且不對等號“=”進行編碼操作。
1.5 有效期選項
緊跟cookie值后面的每個選項都以分號和空格分割，并且每個選項都指定cookie何時應該被發送到服務器。第一個選項是expires，其指定了cookie何時不會再被發送到服務器端的，因此該cookie可能會被瀏覽器刪掉。該選項所對應的值是一個格式為Wdy,DD-Mon--YYYY HH:MM:SS GMT的值，例如：
Set-Cookie:name=Nicholas;expires=Sat, 02 May 2009 23:38:25 GMT
1.6 domain選項
指示cookie將要發送到哪個域或那些域中。默認情況下，domain會被設置為創建該cookie的頁面所在的域名。例如本站中的cookie的domain屬性的默認值為www.nczonline.com。domain選項被用來擴展cookie值所要發送域的數量。例如:
Set-Cookie:name=Nicholas;domain=nczonline.net
二 IP地址與域名的關系，DNS 干嘛用的
- IP地址
IP地址是用來唯一標識互聯網上計算機的邏輯地址，讓電腦之間可以相互通信. 每臺連網計算機都依靠IP地址來互相區分、相互聯系。
IP地址采用二進制的形式表示的話很長，比較麻煩，為了便于使用，IP地址經常被寫成十進制的形式，用“.”分開，叫做“點分十進制表示法”,如：127.0.0.1。
- 域名
由于IP地址是數字標識，使用時難以記憶和書寫，因此在IP地址的基礎上又發展出一種符號化的地址方案，來代替數字型的IP地址。每一個符號化的地址都與特定的IP地址對應，這樣網絡上的資源訪問起來就容易得多了。這個與網絡上的數字型IP地址相對應的字符型地址，就被稱為域名。
- DNS
在Internet上域名與IP地址之間是一對一（或者多對一）的，域名雖然便于人們記憶，但機器之間只能互相認識IP地址，它們之間的轉換工作稱為域名解析，域名解析需要由專門的域名解析服務器來完成，DNS就是進行域名解析的服務器。域名的最終指向是IP。
- 網址
統一資源定位符（URL，英語UniformResourceLocator的縮寫）也被稱為網址，網址格式為：<協議>://<域名或IP>:<端口>/<路徑>。<協議>://<域名或IP>是必需的，<端口>/<路徑>有時可省略。如：https://www.baidu.com/。
三 TCP 與 UDP 的區別
- TCP是面向連接的可靠的傳輸控制協議（流模式），UDP是面向非連接的用戶數據報協議.
- TCP（三次握手保證相對可靠性）可傳大量數據，速度相對比較慢，UDP一次性傳輸少量對可靠性要求不高的數據，速度比較快
- 對系統資源的要求（TCP較多，UDP少）
- TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證
應用
TCP：面向連接、傳輸可靠(保證數據正確性,保證數據順序)、用于傳輸大量數據(流模式)、速度慢，建立連接需要開銷較多(時間，系統資源)。
UDP：面向非連接、傳輸不可靠、用于傳輸少量數據(數據包模式)、速度快。
3.1 UDP 詳解
用戶數據報協議，是一個非連接的協議。傳輸數據之前源端和終端不建立連接，當它想傳送時就簡單地去抓取應用程序的數據，并盡可能的把它扔到網絡上。
- 1、在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
- 2、 由于傳輸數據不建立連接，因此也就不需要維護連接狀態，包括收發狀態等，因此一臺服務機可同時向多個客戶機傳輸相同的消息。
- 3、UDP信息包的標題很短，只有8個字節，相對于TCP的20個字節信息包的額外開銷很小。
- 4、吞吐量不受擁擠控制算法的調節，只受應用軟件生成數據的速率、傳輸帶寬、源端和終端主機性能的限制。
- 5、UDP使用盡最大努力交付，即不保證可靠交付，因此主機不需要維持復雜的鏈接狀態表（這里面有許多參數）。
- 6、UDP是面向報文的。發送方的UDP對應用程序交下來的報文，在添加首部后就向下交付給IP層。既不拆分，也不合并，而是保留這些報文的邊界，因此，應用程序需要選擇合適的報文大小。
四 網絡狀態碼
它是用以表示網頁服務器HTTP響應狀態的3位數字代碼。狀態碼的第一個數字代表了響應的五種狀態之一。
4.1 1XX 系列
指定客戶端應相應的某些動作，代表請求已被接受，需要繼續處理。由于 HTTP/1.0 協議中沒有定義任何 1xx 狀態碼，所以除非在某些試驗條件下，服務器禁止向此類客戶端發送 1xx 響應。
100 （繼續） 請求者應當繼續提出請求。 服務器返回此代碼表示已收到請求的第一部分，正在等待其余部分。
101 （切換協議） 請求者已要求服務器切換協議，服務器已確認并準備切換。
4.2 2XX 系列
代表請求已成功被服務器接收、理解、并接受。這系列中最常見的有200、201狀態碼。
200 （成功） 服務器已成功處理了請求。 通常，這表示服務器提供了請求的網頁。
201 （已創建） 請求成功并且服務器創建了新的資源。
202 （已接受） 服務器已接受請求，但尚未處理。
203 （非授權信息） 服務器已成功處理了請求，但返回的信息可能來自另一來源。
204 （無內容） 服務器成功處理了請求，但沒有返回任何內容。
205 （重置內容） 服務器成功處理了請求，但沒有返回任何內容。
206 （部分內容） 服務器成功處理了部分 GET 請求。
4.3 3XX 系列
代表需要客戶端采取進一步的操作才能完成請求，這些狀態碼用來重定向，后續的請求地址（重定向目標）在本次響應的 Location 域中指明。
300 （多種選擇） 針對請求，服務器可執行多種操作。 服務器可根據請求者 (user agent) 選擇一項操作，或提供操作列表供請求者選擇。
301 （永久移動） 請求的網頁已永久移動到新位置。 服務器返回此響應（對 GET 或 HEAD 請求的響應）時，會自動將請求者轉到新位置。
302 （臨時移動） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。
303 （查看其他位置） 請求者應當對不同的位置使用單獨的 GET 請求來檢索響應時，服務器返回此代碼。
304 （未修改） 自從上次請求后，請求的網頁未修改過。 服務器返回此響應時，不會返回網頁內容。
305 （使用代理） 請求者只能使用代理訪問請求的網頁。 如果服務器返回此響應，還表示請求者應使用代理。
307 （臨時重定向） 服務器目前從不同位置的網頁響應請求，但請求者應繼續使用原有位置來進行以后的請求。
4.4 4XX 系列
表示請求錯誤。代表了客戶端看起來可能發生了錯誤，妨礙了服務器的處理。
400 （錯誤請求） 服務器不理解請求的語法。
401 （未授權） 請求要求身份驗證。 對于需要登錄的網頁，服務器可能返回此響應。
403 （禁止） 服務器拒絕請求。
404 （未找到） 服務器找不到請求的網頁。
405 （方法禁用） 禁用請求中指定的方法。
406 （不接受） 無法使用請求的內容特性響應請求的網頁。
407 （需要代理授權） 此狀態代碼與 401（未授權）類似，但指定請求者應當授權使用代理。
408 （請求超時） 服務器等候請求時發生超時。
409 （沖突） 服務器在完成請求時發生沖突。 服務器必須在響應中包含有關沖突的信息。
410 （已刪除） 如果請求的資源已永久刪除，服務器就會返回此響應。
411 （需要有效長度） 服務器不接受不含有效內容長度標頭字段的請求。
412 （未滿足前提條件） 服務器未滿足請求者在請求中設置的其中一個前提條件。
413 （請求實體過大） 服務器無法處理請求，因為請求實體過大，超出服務器的處理能力。
414 （請求的 URI 過長） 請求的 URI（通常為網址）過長，服務器無法處理。
415 （不支持的媒體類型） 請求的格式不受請求頁面的支持。
416 （請求范圍不符合要求） 如果頁面無法提供請求的范圍，則服務器會返回此狀態代碼。
417 （未滿足期望值） 服務器未滿足”期望”請求標頭字段的要求。
4.5 5XX系列
代表了服務器在處理請求的過程中有錯誤或者異常狀態發生，也有可能是服務器意識到以當前的軟硬件資源無法完成對請求的處理。
500 （服務器內部錯誤） 服務器遇到錯誤，無法完成請求。
501 （尚未實施） 服務器不具備完成請求的功能。 例如，服務器無法識別請求方法時可能會返回此代碼。
502 （錯誤網關） 服務器作為網關或代理，從上游服務器收到無效響應。
503 （服務不可用） 服務器目前無法使用（由于超載或停機維護）。 通常，這只是暫時狀態。
504 （網關超時） 服務器作為網關或代理，但是沒有及時從上游服務器收到請求。
505 （HTTP 版本不受支持） 服務器不支持請求中所用的 HTTP 協議版本。
五 GET 與 POST 的區別
序言：
1、一般在瀏覽器中輸入網址訪問資源都是通過GET方式；在FORM提交中，可以通過Method指定提交方式為GET或者POST，默認為GET提交。
2、Http定義了與服務器交互的不同方法，最基本的方法有4種，分別是GET，POST，PUT，DELETE
3、URL全稱是資源描述符，我們可以這樣認為：一個URL地址，它用于描述一個網絡上的資源，而HTTP中的GET，POST，PUT，DELETE就對應著對這個資源的查 ，改 ，增 ，刪 4個操作。到這里，大家應該有個大概的了解了，GET一般用于獲取/查詢 資源信息，而POST一般用于更新 資源信息(GET和POST的本質區別，也是協議設計者的本意，其它區別都是具體表現形式的差異 )。
GET請求, 將參數直接寫在訪問路徑上. 操作簡單, 不過容易讓外界看到, 安全性不高, 地址最多 255 字節.
POST 請求, 將參數放到 body 里面, POST請求的操作相對復雜, 需要將參數和地址分開, 不過安全性高,參數放在body里面, 不容易被捕獲.
GET使用URL或Cookie傳參。而POST將數據放在BODY中。
GET的URL會有長度上的限制，則POST的數據則可以非常大。
一般用GET來進行獲取數據，因為有緩存，所以可以降低服務器的壓力；而POST一般用來進行操作數據，如增刪改。
GET由于url或者瀏覽器長度限制，一般參數不能超過1k，而POST沒有長度限制，所以進行大文件上傳的話用POST。
5.1 GET 相對 POST 的優勢是什么
所以如果你希望
- 請求中的URL可以被手動輸入
- 請求中的URL可以被存在書簽里，或者歷史里，或者快速撥號里面，或者分享給別人。
- 請求中的URL是可以被搜索引擎收錄的。
- 帶云壓縮的瀏覽器，比如Opera mini/Turbo 2, 只有GET才能在服務器端被預取的。
- 請求中的URL可以被緩存。
請使用GET
