1.Http是什么？

通俗來(lái)講，他就是計(jì)算機(jī)通過(guò)網(wǎng)絡(luò)進(jìn)行通信的規(guī)則，是一個(gè)基于請(qǐng)求與響應(yīng)，無(wú)狀態(tài)的，應(yīng)用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)。目前任何終端（手機(jī)，筆記本電腦。。）之間進(jìn)行任何一種通信都必須按照Http協(xié)議進(jìn)行，否則無(wú)法連接。

四個(gè)基于：

請(qǐng)求與響應(yīng)：客戶端發(fā)送請(qǐng)求，服務(wù)器端響應(yīng)數(shù)據(jù)

無(wú)狀態(tài)的：協(xié)議對(duì)于事務(wù)處理沒有記憶能力，客戶端第一次與服務(wù)器建立連接發(fā)送請(qǐng)求時(shí)需要進(jìn)行一系列的安全認(rèn)證匹配等，因此增加頁(yè)面等待時(shí)間，當(dāng)客戶端向服務(wù)器端發(fā)送請(qǐng)求，服務(wù)器端響應(yīng)完畢后，兩者斷開連接，也不保存連接狀態(tài)，一刀兩斷！恩斷義絕！從此路人！下一次客戶端向同樣的服務(wù)器發(fā)送請(qǐng)求時(shí)，由于他們之前已經(jīng)遺忘了彼此，所以需要重新建立連接。是不是炒雞不方便！！對(duì)！但是是有辦法解決的~接著往下看。

應(yīng)用層：Http是屬于應(yīng)用層的協(xié)議，配合TCP/IP使用。

TCP/IP：Http使用TCP作為它的支撐運(yùn)輸協(xié)議。HTTP客戶機(jī)發(fā)起一個(gè)與服務(wù)器的TCP連接，一旦連接建立，瀏覽器（客戶機(jī)）和服務(wù)器進(jìn)程就可以通過(guò)套接字接口訪問(wèn)TCP。

2.針對(duì)Http無(wú)狀態(tài)應(yīng)該怎么做？

狀態(tài)保存的四種方法：

<1>通過(guò)cookies保存狀態(tài)信息（常用）

SetCookie是設(shè)置客戶端的cookie，請(qǐng)求2發(fā)出時(shí)連同之前的cookie一起發(fā)送給服務(wù)端，這樣服務(wù)器通過(guò)Cookies，服務(wù)器就可以清楚的知道請(qǐng)求2和請(qǐng)求1來(lái)自同一個(gè)客戶端。

<2>通過(guò)Session保存狀態(tài)信息：（常用）Session機(jī)制是一種服務(wù)器端的機(jī)制，服務(wù)器使用一種類似于散列表的結(jié)構(gòu)（也可能就是使用散列表）來(lái)保存信息。

當(dāng)程序需要為某個(gè)客戶端的請(qǐng)求創(chuàng)建一個(gè)session的時(shí)候，服務(wù)器首先檢查這個(gè)客戶端的請(qǐng)求里是否已包含了一個(gè)session標(biāo)識(shí) - 稱為 session id，如果已包含一個(gè)session id則說(shuō)明以前已經(jīng)為此客戶端創(chuàng)建過(guò)session，服務(wù)器就按照session id把這個(gè) session檢索出來(lái)使用（如果檢索不到，可能會(huì)新建一個(gè)），如果客戶端請(qǐng)求不包含session id，則為此客戶端創(chuàng)建一個(gè)session并且生成一個(gè)與此session相關(guān)聯(lián)的session id，session id的值應(yīng)該是一個(gè)既不會(huì)重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個(gè)session id將被在本次響應(yīng)中返回給客戶端保存。

<3>通過(guò)表單變量保持狀態(tài)：比如Asp.net就通過(guò)一個(gè)叫ViewState的Input=“hidden”的框來(lái)保持狀態(tài),比如:

這個(gè)原理和Cookies大同小異，只是每次請(qǐng)求和響應(yīng)所附帶的信息變成了表單變量。

<4>通過(guò)QueryString保持狀態(tài)：QueryString通過(guò)將信息保存在所請(qǐng)求地址的末尾來(lái)向服務(wù)器傳送信息，通常和表單結(jié)合使用，一個(gè)典型的QueryString比如:www.xxx.com/xxx.aspx?var1=value&var2=value2

3. VS：cookie/session

cookie

優(yōu)點(diǎn)：

1. 極高的擴(kuò)展性和可用性

2. 只在cookie中存放不敏感數(shù)據(jù)，即使被盜也不會(huì)有重大損失。

3. 控制cookie的生命期，使之不會(huì)永遠(yuǎn)有效。偷盜者很可能拿到一個(gè)過(guò)期的cookie。

缺點(diǎn)：

1. Cookie數(shù)量和長(zhǎng)度的限制。每個(gè)domain最多只能有20條cookie，每個(gè)cookie長(zhǎng)度不能超過(guò)4KB，否則會(huì)被截掉。

2. 安全性問(wèn)題。如果cookie被人攔截了，那人就可以取得所有的session信息。即使加密也與事無(wú)補(bǔ)，因?yàn)閿r截者并不需要知道cookie的意義，他只要原樣轉(zhuǎn)發(fā)cookie就可以達(dá)到目的了。

session

優(yōu)點(diǎn)：

1. 如果要在諸多Web頁(yè)間傳遞一個(gè)變量，那么用Session變量要比通過(guò)QueryString傳遞變量可使問(wèn)題簡(jiǎn)化。

2. 要使WEb站點(diǎn)具有用戶化，可以考慮使用Session變量。

缺點(diǎn)：

1. Session變量和cookies是同一類型的。如果某用戶將瀏覽器設(shè)置為不兼容任何cookie，那么該用戶就無(wú)法使用這個(gè)Session變量！

2. 當(dāng)一個(gè)用戶訪問(wèn)某頁(yè)面時(shí)，每個(gè)Session變量的運(yùn)行環(huán)境便自動(dòng)生成，這些Session變量可在用戶離開該頁(yè)面后仍保留20分鐘！如果在Session中置入了較大的對(duì)象那就有麻煩了！隨著站點(diǎn)訪問(wèn)量的增大，服務(wù)器將會(huì)因此而無(wú)法正常運(yùn)行！

3. 過(guò)度使用session變量將會(huì)導(dǎo)致代碼不可讀而且不好維護(hù)。

4.基于HTTP的網(wǎng)絡(luò)請(qǐng)求流程

例如當(dāng)你訪問(wèn)baidu.com網(wǎng)址時(shí)，我們來(lái)看看瀏覽器和服務(wù)器都做了些什么事：

一、本地域名解析： 瀏覽器搜索本地緩存。

1.??Chrome搜索自身的DNS緩存，看自身的緩存有沒有baidu.com的IP（有效期為1分鐘）

2.??如果沒有找到或者緩存失效，再搜索本機(jī)操作系統(tǒng)自身的DNS緩存。

3.??如果還是沒有，瀏覽器就會(huì)讀取本地的host文件。

4.??如果還是沒有，瀏覽器會(huì)發(fā)起一個(gè)DNS的一個(gè)系統(tǒng)調(diào)用，向本地主控的DNS服務(wù)器（一般是你的寬帶運(yùn)營(yíng)商提供）發(fā)起一個(gè)域名解析請(qǐng)求

二、運(yùn)營(yíng)商域名解析： 服務(wù)器響應(yīng)。

以西安郵電大學(xué)為例：

1.??校園寬帶（局域網(wǎng)）服務(wù)器查看本身緩存，找到對(duì)應(yīng)的條目，如果沒有過(guò)期，那么就解析成功了，返回響應(yīng)。

2.??如果校園寬帶沒有找到對(duì)應(yīng)的條目或者過(guò)期，就會(huì)代替瀏覽器向上一級(jí)域網(wǎng)發(fā)起一個(gè)迭代的DNS解析請(qǐng)求

3.??校園服務(wù)器請(qǐng)求到baidu.com的IP時(shí)，就會(huì)把結(jié)果返回操作系統(tǒng)內(nèi)核，同時(shí)緩存到自己的緩存區(qū)（這個(gè)緩存有時(shí)間限制）

4.??操作系統(tǒng)內(nèi)核就會(huì)把請(qǐng)求到的IP地址返回給瀏覽器

5.??最終瀏覽器拿到了www.baidu.com對(duì)應(yīng)的IP地址

三、HTTP“三次握手”： 建立TCP/IP傳輸連接

第一次：客戶端要求建立聯(lián)機(jī)?？蛻舳税l(fā)送位碼為syn＝1,隨機(jī)產(chǎn)生seq number=1234567的數(shù)據(jù)包到上述得到的IP地址對(duì)應(yīng)的服務(wù)器，服務(wù)器由syn=1知道，客戶端要求建立聯(lián)機(jī)；

第二次：服務(wù)端確認(rèn)聯(lián)機(jī)信息。服務(wù)器發(fā)送ack number=(客戶端的seq+1),syn=1,ack=1,隨機(jī)產(chǎn)生seq=7654321的包

第三次：客戶端確認(rèn)聯(lián)機(jī)信息，正確則連接建立成功。

客戶端收到后檢查ack number是否正確，即第一次發(fā)送的seq number+1,以及位碼ack是否為1，若正確，客戶端會(huì)再發(fā)送ack number=(主機(jī)B的seq+1),ack=1，服務(wù)端收到后確認(rèn)seq值與ack=1則連接建立成功。

完成三次握手，客戶端與服務(wù)器開始傳送數(shù)據(jù)。

四、TCP/IP連接建立起來(lái)后，瀏覽器就可以向服務(wù)器發(fā)送HTTP請(qǐng)求了

五、服務(wù)器接收到了這個(gè)請(qǐng)求之后，根據(jù)路徑參數(shù)，經(jīng)過(guò)后端的一些處理之后，把處理后的結(jié)果數(shù)據(jù)返回給瀏覽器。如果是百度的搜索首頁(yè)，就會(huì)把完整的HTML頁(yè)面代碼返回給瀏覽器

六、瀏覽器拿到百度的完整HTML代碼之后，解析和渲染這個(gè)頁(yè)面。這個(gè)過(guò)程同樣需要請(qǐng)求這個(gè)頁(yè)面里的js，css，圖片靜態(tài)資源，每一次請(qǐng)求都會(huì)做上述的所有步驟。

七、最終，瀏覽器向用戶展現(xiàn)了百度頁(yè)面。

5.http的請(qǐng)求方法

GET? ?? ?? ? 請(qǐng)求指定的頁(yè)面信息，并返回實(shí)體主體。

POST? ?? ???向指定資源提交數(shù)據(jù)進(jìn)行處理請(qǐng)求（例如提交表單或者上傳文件）。

HEAD? ?? ???類似于get請(qǐng)求，只不過(guò)返回的響應(yīng)中沒有具體的內(nèi)容，用于獲取報(bào)頭

PUT? ?? ?? ???從客戶端向服務(wù)器傳送的數(shù)據(jù)取代指定的文檔的內(nèi)容。

DELETE? ? 請(qǐng)求服務(wù)器刪除指定的頁(yè)面。

CONNECT HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。

OPTIONS??允許客戶端查看服務(wù)器的性能。

TRACE? ?? ?回顯服務(wù)器收到的請(qǐng)求，主要用于測(cè)試或診斷。

6.VS：GET/POST

1. get是從服務(wù)器上獲取數(shù)據(jù)，post是向服務(wù)器傳送數(shù)據(jù)。

2. get是把參數(shù)數(shù)據(jù)隊(duì)列加到提交表單的ACTION屬性所指的URL中，值和表單內(nèi)各個(gè)字段一一對(duì)應(yīng)，在URL中可以看到。post是通過(guò)HTTP post機(jī)制，將表單內(nèi)各個(gè)字段與其內(nèi)容放置在HTML HEADER內(nèi)一起傳送到ACTION屬性所指的URL地址。用戶看不到這個(gè)過(guò)程。

3. 對(duì)于get方式，服務(wù)器端用Request.QueryString獲取變量的值，對(duì)于post方式，服務(wù)器端用Request.Form獲取提交的數(shù)據(jù)。

4. get傳送的數(shù)據(jù)量較小，不能大于2KB。post傳送的數(shù)據(jù)量較大，一般被默認(rèn)為不受限制。但理論上，IIS4中最大量為80KB，IIS5中為100KB。

5. get安全性非常低，post安全性較高。但是執(zhí)行效率卻比Post方法好。

建議：

1、get方式的安全性較Post方式要差些，包含機(jī)密信息的話，建議用Post數(shù)據(jù)提交方式；

2、在做數(shù)據(jù)查詢時(shí)，建議用Get方式；而在做數(shù)據(jù)添加、修改或刪除時(shí)，建議用Post方式；

7.HTTP狀態(tài)碼

1**? ?? ?服務(wù)器收到請(qǐng)求

2**? ?? ?成功，操作被成功接收并處理

3**? ?? ?需要進(jìn)一步的操作以完成請(qǐng)求

4**? ?? ?客戶端錯(cuò)誤，請(qǐng)求包含語(yǔ)法錯(cuò)誤或無(wú)法完成請(qǐng)求

5**? ?? ?服務(wù)器錯(cuò)誤，服務(wù)器在處理請(qǐng)求的過(guò)程中發(fā)生了錯(cuò)誤

8.Http與TCP/IP區(qū)別

TPC/IP協(xié)議是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡(luò)中傳輸，而HTTP是應(yīng)用層協(xié)議，主要解決如何包裝數(shù)據(jù)。關(guān)于TCP/IP和HTTP協(xié)議的關(guān)系，網(wǎng)絡(luò)有一段比較容易理解的介紹：“我們?cè)趥鬏敂?shù)據(jù)時(shí)，可以只使用（傳輸層）TCP/IP協(xié)議，但是那樣的話，如果沒有應(yīng)用層，便無(wú)法識(shí)別數(shù)據(jù)內(nèi)容，如果想要使傳輸?shù)臄?shù)據(jù)有意義，則必須使用到應(yīng)用層協(xié)議，應(yīng)用層協(xié)議有很多，比如HTTP、FTP、TELNET等，也可以自己定義應(yīng)用層協(xié)議。WEB使用HTTP協(xié)議作應(yīng)用層協(xié)議，以封裝HTTP 文本信息，然后使用TCP/IP做傳輸層協(xié)議將它發(fā)到網(wǎng)絡(luò)上?！?/p>

9.TCP/IP為什么一定要三次握手？?jī)纱涡胁恍校?/p>

由三次握手圖可得：客戶主機(jī)向服務(wù)主機(jī)發(fā)送連接請(qǐng)求，服務(wù)主機(jī)向客戶主機(jī)授予連接，而客戶主機(jī)收到服務(wù)主機(jī)的應(yīng)答后，便知道了自己這一方發(fā)送和接收數(shù)據(jù)都沒有問(wèn)題，這是兩次握手，如果到這個(gè)時(shí)候停止了，那么服務(wù)主機(jī)僅僅知道自己接收數(shù)據(jù)沒有問(wèn)題，由于客戶主機(jī)再?zèng)]有向他發(fā)送確認(rèn)，因此他也不知道自己向客戶主機(jī)發(fā)送的授予連接的信息有沒有發(fā)送成功，只有當(dāng)客戶主機(jī)再次向服務(wù)器主機(jī)發(fā)回確認(rèn)時(shí)，服務(wù)器主機(jī)才知道自己的發(fā)送和接收都是ok的。