1  TCP和UDP區別，應用場景

TCP：為應用層提供可靠的、面向連線的和基於流的服務。使用超時重傳、資料確認等方式來確保資料包被正確地傳送至目的端，因此服務是可靠的。使用TCP協議通訊的雙方必須先建立TCP連線，並在核心中為該連線維持一些必要的資料結構，比如連線的狀態、讀寫緩衝區，以及諸多定時器等。當通訊結束時，雙方必須關閉連線以釋放這些核心資料。TCP基於流。基於流的資料沒有邊界（長度）限制，它源源不斷地從通訊的一端流入另一端。傳送端可以逐個地向資料流中寫入資料，接收端也可以逐個地將它們讀出。

缺點：因為TCP有確認機制、三次握手機制，這些也導致TCP容易被人利用，實現DOS、DDOS、CC等攻擊

UDP：則與TCP想反，它為應用層提供不可靠、無連線和基於資料報的服務。“不可靠”意味著UDP協議無法保證資料從傳送端正確地傳送到目的端。如果資料在途中丟失，或者目的端通過資料校驗發現數據錯誤而將其丟棄，則UDP協議只是簡單地通知應用程式傳送失敗。因此使用UDP協議的應用程式通常要自己處理資料確認，超時重傳等邏輯。UDP是無連線的，即通訊雙方不保持一個長久的聯絡，因此應用程式每次傳送資料都要明確指定接收端的地址（IP地址等資訊）。基於資料報的服務，是相對基於流的服務而言的。每個UDP資料報都有一個長度，接收端必須以該長度為最小單位將其所有內容依次讀出，否則資料將被截斷。

UDP優點：快比TCP稍安全

缺點：不可靠，不穩定，如果網路質量不好，很容易丟包。

什麼時候該使用TCP： 當對網路通訊質量有要求的時候，比如：整個資料要準確無誤的傳遞給對方，這往往用於一些要求可靠的應用，比如HTTP、HTTPS、FTP等傳輸檔案的協議，POP、SMTP等郵件傳輸的協議。

在日常生活中，常見使用TCP協議的應用如下： 瀏覽器，用的HTTP FlashFXP，用的FTP Outlook，用的POP、SMTP Putty，用的Telnet、SSH QQ檔案傳輸

什麼時候使用UDP：當對網路通訊質量要求不高的時候，要求速度儘可能的快，這時就可以使用UDP。用UDP協議的應用如下： QQ語音 QQ視訊 TFTP。

2 瀏覽器輸入www.baidu.com後，網路過程

事件順序：

(3) 域名系統DNS解析出百度伺服器的IP地址 （詳細介紹DNS）-通過網關出去

(4) 瀏覽器與該伺服器建立TCP連線(預設埠號80)

(5) 瀏覽器發出HTTP請求，請求百度首頁

(6) 伺服器通過HTTP響應把首頁檔案傳送給瀏覽器

(7) TCP連線釋放

(8) 瀏覽器將首頁檔案進行解析，並將Web頁顯示給使用者。

涉及到的協議:

(1) 應用層：HTTP(WWW訪問協議)，DNS(域名解析服務)

DNS解析域名為目的IP，通過IP找到伺服器路徑，客戶端向伺服器發起HTTP會話，然後通過運輸層TCP協議封裝資料包，在TCP協議基礎上進行傳輸。

(2) 傳輸層：TCP(為HTTP提供可靠的資料傳輸)，UDP(DNS使用UDP傳輸)，HTTP會話會被分成報文段，新增源、目的埠；TCP協議進行主要工作。

(3)網路層：IP(IP資料資料包傳輸和路由選擇)，ICMP(提供網路傳輸過程中的差錯檢測)，ARP(將本機的預設閘道器IP地址對映成物理MAC地址)為資料包選擇路由，IP協議進行主要工作，相鄰結點的可靠傳輸，ARP協議將IP地址轉成MAC地址。

簡單理解:   域名解析 --> 發起TCP的3次握手 --> 建立TCP連線後發起http請求 --> 伺服器響應http請求，瀏覽器得到html程式碼 --> 瀏覽器解析html程式碼，並請求html程式碼中的資源（如js、css、圖片等） --> 瀏覽器對頁面進行渲染呈現給使用者。

3 三次握手和四次揮手過程

三次握手：

第一次握手：建立連線時，客戶端傳送SYN包到服務端，其中包含客戶端的初始序號seq=x,並進入SYN_SENT(同步已傳送)狀態，等待伺服器確認。（其中SYN=1，ACK=0，表示這是一個TCP連線請求資料報文；序號seq=x，表明資料傳輸資料時第一個資料位元組的序號是X）.

第二次握手：伺服器收到請求後，必須確認客戶的資料包。同時自己也傳送一個SYN包，即SYN+ACK包，此時伺服器進入SYN_RECV（同步以收到）狀態。（其中確認報文段中，標識位SYN=1,ACK=1，表示這是一個TCP連線響應資料報文，幷包含伺服器的初始序號seq(伺服器)=y,以及伺服器對客戶端初始序號的確認號ack(伺服器)=seq（客戶端）+1=x+1）.

第三次握手：客戶端收到伺服器的SYN+ACK 包，向伺服器傳送一個序列號(seq=x+1)，確認號為ack=y+1,此包傳送完畢，客戶端和伺服器進入ESTAB_LISHED（TCP連線成功)狀態，完成三次握手。

為啥三次握手：假設客戶端請求建立連線，發給伺服器SYN包等待伺服器確認，伺服器收到確認後，如果是兩次握手，假設伺服器給客戶端在第二次握手時傳送資料，資料從伺服器發出，伺服器任務連線已經建立，但在傳送資料的過程中資料丟失，客戶端認為連線沒有建立，會進行重傳。假設每一次傳送的資料一直在丟失，客戶端一直SYN，伺服器就會產生多個無效連線，佔用資源，這個時候伺服器可能會掛掉。這就是SYN的洪水攻擊

第三次握手是為了防止：如果客戶端遲遲沒有收到伺服器返回確認報文，這時會放棄連線，重新啟動一條連線請求，但問題是：伺服器不知道客戶端沒有收到，所以他會收到兩個連線，浪費連線開銷。如果每次都是這樣，就會浪費多個連線開銷。

四次揮手：

step1：第一次揮手

首先，客戶端傳送一個FIN，用來關閉客戶端到伺服器的資料傳送，然後等待伺服器的確認。其中終止標誌位FIN=1，序列號seq=u。

step2：第二次揮手

伺服器收到這個FIN，它傳送一個ACK，確認ack為收到的序號加一。

step3：第三次揮手

關閉伺服器到客戶端的連線，傳送一個FIN給客戶端。

step4：第四次揮手

客戶端收到FIN後，併發回一個ACK報文確認，並將確認序號seq設定為收到序號加一。首先進行關閉的一方將執行主動關閉，而另一方執行被動關閉。

客戶端傳送FIN後，進入終止等待狀態，伺服器收到客戶端連線釋放報文段後，就立即給客戶端傳送確認，伺服器就進入CLOSE_WAIT狀態，此時TCP伺服器程序就通知高層應用程序，因而從客戶端到伺服器的連線就釋放了。此時是“半關閉狀態”，即客戶端不可以傳送給伺服器，伺服器可以傳送給客戶端。
此時，如果伺服器沒有資料報傳送給客戶端，其應用程式就通知TCP釋放連線，然後傳送給客戶端連線釋放資料報，並等待確認。客戶端傳送確認後，進入TIME_WAIT狀態，但是此時TCP連線還沒有釋放，然後經過等待計時器設定的2MSL後，才進入到CLOSE狀態。

.為什麼需要2MSL時間？
首先，MSL即Maximum Segment Lifetime，就是最大報文生存時間，是任何報文在網路上的存在的最長時間，超過這個時間報文將被丟棄。《TCP/IP詳解》中是這樣描述的：MSL是任何報文段被丟棄前在網路內的最長時間。RFC 793中規定MSL為2分鐘，實際應用中常用的是30秒、1分鐘、2分鐘等。

TCP的TIME_WAIT需要等待2MSL，當TCP的一端發起主動關閉，三次揮手完成後傳送第四次揮手的ACK包後就進入這個狀態，等待2MSL時間主要目的是：防止最後一個ACK包對方沒有收到，那麼對方在超時後將重發第三次握手的FIN包，主動關閉端接到重發的FIN包後可以再發一個ACK應答包。在TIME_WAIT狀態時兩端的埠不能使用，要等到2MSL時間結束才可以繼續使用。當連線處於2MSL等待階段時任何遲到的報文段都將被丟棄。

.為什麼是四次揮手，而不是三次或是五次、六次？
雙方關閉連線要經過雙方都同意。所以，首先是客服端給伺服器傳送FIN，要求關閉連線，伺服器收到後會傳送一個ACK進行確認。伺服器然後再發送一個FIN，客戶端傳送ACK確認，並進入TIME_WAIT狀態。等待2MSL後自動關閉。

總結：
（1）為了保證客戶端傳送的最後一個ACK報文段能夠到達伺服器。即最後一個確認報文可能丟失，伺服器會超時重傳，然後伺服器傳送FIN請求關閉連線，客戶端傳送ACK確認。一個來回是兩個報文生命週期。

如果沒有等待時間，傳送完確認報文段就立即釋放連線的話，伺服器就無法重傳，因此也就收不到確認，就無法按步驟進入CLOSE狀態，即必須收到確認才能close。
（2）防止已經失效的連線請求報文出現在連線中。經過2MSL，在這個連續持續的時間內，產生的所有報文段就可以都從網路消失。

4 DNS域名解析過程：

步驟一：當在瀏覽器中輸入域名按下回車鍵後，瀏覽器會檢查快取中有沒有這個域名對應的解析過的IP地址。如果快取有，解析結束。瀏覽器快取域名在大小和時間上都是有限制的。快取時間可由TTL屬性來設定快取時間太長太短都不好，太長，會導致IP解析有變化，會導致域名不能正常解析，部分使用者無法訪問網站。快取時間太短，使用者每次都需要重新解析一次域名。

步驟二：如果使用者的瀏覽器中快取沒有，瀏覽器會查詢作業系統中是否有這個域名對應的DNS解析結果。其實作業系統中也會有一個域名解析的過程，在windows中可以通過c:\\windows\system32\drivers\etc\hosts檔案來設定，你可以將任何域名解析到任何能夠訪問的IP地址。（黑客劫持域名）步驟一和步驟二都是由本機完成的。

步驟三：當機無法完成域名解析，就會真正請求域名伺服器來解析這個域名了。我們怎樣知道域名伺服器？網路配置中都會有“DNS伺服器地址”作業系統會把這個域名傳送到設定中的LDNS，也就是本地的域名伺服器。DNS通常都會提供給你本地網際網路接入的一個DNS伺服器。比如你在學校，那麼這個DNS伺服器一定在你們學校。WIndows中可由ipconfig查詢這個地址。

步驟四：如果LDNS仍然沒有解析到，就直接到Root Service域名解析器請求解析

不周五：根域名伺服器返回給本地域名伺服器一個所查詢餘的主域名伺服器（gTLDServer）地址。gTLD是國際頂級域名伺服器，如：.com/.cn/.org等，全球只有13臺左右。

步驟六：本地域名伺服器（Local DNS Server）再向上一步返回的gTLD伺服器傳送請求

步驟七：接收請求的gTLD伺服器查詢並返回此域名對應的Name Server域名伺服器的地址，這個Name Server通常就是你註冊的域名伺服器（如你的域名供應商）

步驟八：Name Server域名伺服器會查詢儲存的域名和IP的對映關係表，正常情況下都根據域名得到目標IP記錄，連同一個TTL值返回給DNS Server域名伺服器

步驟九：返回該域名對應的IP和TTL值，Local DNS Server會快取這個域名和IP的對應關係，快取的時間有TTL值控制。

步驟十：把解析的結果返回給使用者，使用者根據TTL值快取在本地系統快取中，域名解析過程結束。

關於DNS解析的TTL引數：

我們在配置DNS解析的時候，有一個引數常常容易忽略，就是DNS解析的TTL引數，Time To Live。TTL這個引數告訴本地DNS伺服器，域名快取的最長時間。用阿里雲解析來舉例，阿里雲解析預設的TTL是10分鐘，10分鐘的含義是，本地DNS伺服器對於域名的快取時間是10分鐘，10分鐘之後，本地DNS伺服器就會刪除這條記錄，刪除之後，如果有使用者訪問這個域名，就要重複一遍上述複雜的流程。

5 HTTP協議

HTTP協議是Hyper Text Transfer Protocol（超文字傳輸協議）的縮寫,是用於從全球資訊網（WWW:World Wide Web ）伺服器傳輸超文字到本地瀏覽器的傳送協議。

HTTP是一個基於TCP/IP通訊協議來傳遞資料（HTML 檔案, 圖片檔案, 查詢結果等）。

HTTP是一個屬於應用層的面向物件的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。

主要特點：

1、簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。

2、靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。

3.無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。

4.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
5、支援B/S及C/S模式。

URI和URL的區別

URI，是uniform resource identifier，統一資源識別符號，用來唯一的標識一個資源。

Web上可用的每種資源如HTML文件、影象、視訊片段、程式等都是一個來URI來定位的
URI一般由三部組成：
①訪問資源的命名機制
②存放資源的主機名
③資源自身的名稱，由路徑表示，著重強調於資源。

URL是uniform resource locator，統一資源定位器，它是一種具體的URI，即URL可以用來標識一個資源，而且還指明瞭如何locate這個資源。

URL是Internet上用來描述資訊資源的字串，主要用在各種WWW客戶程式和伺服器程式上，特別是著名的Mosaic。
採用URL可以用一種統一的格式來描述各種資訊資源，包括檔案、伺服器的地址和目錄等。URL一般由三部組成：
①協議(或稱為服務方式)
②存有該資源的主機IP地址(有時也包括埠號)
③主機資源的具體地址。如目錄和檔名等

URN，uniform resource name，統一資源命名，是通過名字來標識資源，比如mailto:[email protected]。

URI是以一種抽象的，高層次概念定義統一資源標識，而URL和URN則是具體的資源標識的方式。URL和URN都是一種URI。籠統地說，每個 URL 都是 URI，但不一定每個 URI 都是 URL。這是因為 URI 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一個URI例項可以代表絕對的，也可以是相對的，只要它符合URI的語法規則。而URL類則不僅符合語義，還包含了定位該資源的資訊，因此它不能是相對的。
在Java類庫中，URI類不包含任何訪問資源的方法，它唯一的作用就是解析。
相反的是，URL類可以開啟一個到達資源的流。

HTTP之請求訊息Request

客戶端傳送一個HTTP請求到伺服器的請求訊息包括以下格式：

請求行（request line）、請求頭部（header）、空行和請求資料四個部分組成。

<br />

Http請求訊息結構.png

• 請求行以一個方法符號開頭，以空格分開，後面跟著請求的URI和協議的版本。

Get請求例子，使用Charles抓取的request：

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent  Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept  image/webp,image/*,*/*;q=0.8
Referer http://www.imooc.com/
Accept-Encoding gzip, deflate, sdch
Accept-Language zh-CN,zh;q=0.8

第一部分：請求行，用來說明請求型別,要訪問的資源以及所使用的HTTP版本.

GET說明請求型別為GET,[/562f25980001b1b106000338.jpg]為要訪問的資源，該行的最後一部分說明使用的是HTTP1.1版本。

第二部分：請求頭部，緊接著請求行（即第一行）之後的部分，用來說明伺服器要使用的附加資訊

從第二行起為請求頭部，HOST將指出請求的目的地.User-Agent,伺服器端和客戶端指令碼都能訪問它,它是瀏覽器型別檢測邏輯的重要基礎.該資訊由你的瀏覽器來定義,並且在每個請求中自動傳送等等

第三部分：空行，請求頭部後面的空行是必須的

即使第四部分的請求資料為空，也必須有空行。

第四部分：請求資料也叫主體，可以新增任意的其他資料。

這個例子的請求資料為空。

POST請求例子，使用Charles抓取的request：

POST / HTTP1.1
Host:www.wrox.com
User-Agent:Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Content-Type:application/x-www-form-urlencoded
Content-Length:40
Connection: Keep-Alive

name=Professional%20Ajax&publisher=Wiley

第一部分：請求行，第一行明瞭是post請求，以及http1.1版本。
第二部分：請求頭部，第二行至第六行。
第三部分：空行，第七行的空行。
第四部分：請求資料，第八行。

HTTP之響應訊息Response

一般情況下，伺服器接收並處理客戶端發過來的請求後會返回一個HTTP的響應訊息。

HTTP響應也由四個部分組成，分別是：狀態行、訊息報頭、空行和響應正文。

<br />

http響應訊息格式.jpg

例子

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
      <head></head>
      <body>
            <!--body goes here-->
      </body>
</html>

第一部分：狀態行，由HTTP協議版本號， 狀態碼， 狀態訊息 三部分組成。

第一行為狀態行，（HTTP/1.1）表明HTTP版本為1.1版本，狀態碼為200，狀態訊息為（ok）

第二部分：訊息報頭，用來說明客戶端要使用的一些附加資訊

第二行和第三行為訊息報頭，
Date:生成響應的日期和時間；Content-Type:指定了MIME型別的HTML(text/html),編碼型別是UTF-8

第三部分：空行，訊息報頭後面的空行是必須的

第四部分：響應正文，伺服器返回給客戶端的文字資訊。

空行後面的html部分為響應正文。

HTTP之狀態碼

狀態程式碼有三位數字組成，第一個數字定義了響應的類別，共分五種類別:

1xx：指示資訊--表示請求已接收，繼續處理

2xx：成功--表示請求已被成功接收、理解、接受

3xx：重定向--要完成請求必須進行更進一步的操作

4xx：客戶端錯誤--請求有語法錯誤或請求無法實現

5xx：伺服器端錯誤--伺服器未能實現合法的請求

以下是 HTTP 請求/響應的步驟：

1、客戶端連線到Web伺服器

一個HTTP客戶端，通常是瀏覽器，與Web伺服器的HTTP埠（預設為80）建立一個TCP套接字連線。例如，http://www.oakcms.cn。

2、傳送HTTP請求

通過TCP套接字，客戶端向Web伺服器傳送一個文字的請求報文，一個請求報文由請求行、請求頭部、空行和請求資料4部分組成。

3、伺服器接受請求並返回HTTP響應

Web伺服器解析請求，定位請求資源。伺服器將資源複本寫到TCP套接字，由客戶端讀取。一個響應由狀態行、響應頭部、空行和響應資料4部分組成。

4、釋放連線TCP連線

若connection 模式為close，則伺服器主動關閉TCP連線，客戶端被動關閉連線，釋放TCP連線;若connection 模式為keepalive，則該連線會保持一段時間，在該時間內可以繼續接收請求;

5、客戶端瀏覽器解析HTML內容

客戶端瀏覽器首先解析狀態行，查看錶明請求是否成功的狀態程式碼。然後解析每一個響應頭，響應頭告知以下為若干位元組的HTML文件和文件的字符集。客戶端瀏覽器讀取響應資料HTML，根據HTML的語法對其進行格式化，並在瀏覽器視窗中顯示。

例如：在瀏覽器位址列鍵入URL，按下回車之後會經歷以下流程：

1、瀏覽器向 DNS 伺服器請求解析該 URL 中的域名所對應的 IP 地址;

2、解析出 IP 地址後，根據該 IP 地址和預設埠 80，和伺服器建立TCP連線;

3、瀏覽器發出讀取檔案(URL 中域名後面部分對應的檔案)的HTTP 請求，該請求報文作為 TCP 三次握手的第三個報文的資料傳送給伺服器;

4、伺服器對瀏覽器請求作出響應，並把對應的 html 文字傳送給瀏覽器;

5、釋放 TCP連線;

6、瀏覽器將該 html 文字並顯示內容;

GET和POST區別：

• GET提交的資料會放在URL之後，以?分割URL和傳輸資料，引數之間以&相連，如EditPosts.aspx?name=test1&id=123456. POST方法是把提交的資料放在HTTP包的Body中.

• GET提交的資料大小有限制（因為瀏覽器對URL的長度有限制），而POST方法提交的資料沒有限制.

• GET方式需要使用Request.QueryString來取得變數的值，而POST方式通過Request.Form來獲取變數的值。

• GET方式提交資料，會帶來安全問題，比如一個登入頁面，通過GET方式提交資料時，使用者名稱和密碼將出現在URL上，如果頁面可以被快取或者其他人可以訪問這臺機器，就可以從歷史記錄獲得該使用者的賬號和密碼.

  http請求由三部分組成，分別是：請求行、訊息報頭、請求正文

  HTTP（超文字傳輸協議）是一個基於請求與響應模式的、無狀態的、應用層的協議，常基於TCP的連線方式，HTTP1.1版本中給出一種持續連線的機制，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用。

  1、常用的HTTP方法有哪些？
  GET： 用於請求訪問已經被URI（統一資源識別符號）識別的資源，可以通過URL傳參給伺服器。
  POST：用於傳輸資訊給伺服器，主要功能與GET方法類似，但一般推薦使用POST方式。
  PUT： 傳輸檔案，報文主體中包含檔案內容，儲存到對應URI位置。
  HEAD： 獲得報文首部，與GET方法類似，只是不返回報文主體，一般用於驗證URI是否有效。
  DELETE：刪除檔案，與PUT方法相反，刪除對應URI位置的檔案。
  OPTIONS：查詢相應URI支援的HTTP方法。
  
  
  2、GET方法與POST方法的區別
  區別一：
  get重點在從伺服器上獲取資源，post重點在向伺服器傳送資料；
  區別二：
  get傳輸資料是通過URL請求，以field（欄位）= value的形式，置於URL後，並用"?"連線，多個請求資料間用"&"連線，如http://127.0.0.1/Test/login.action?name=admin&password=admin，這個過程使用者是可見的；
  post傳輸資料通過Http的post機制，將欄位與對應值封存在請求實體中傳送給伺服器，這個過程對使用者是不可見的；
  區別三：
  Get傳輸的資料量小，因為受URL長度限制，但效率較高；
  Post可以傳輸大量資料，所以上傳檔案時只能用Post方式；
  區別四：
  get是不安全的，因為URL是可見的，可能會洩露私密資訊，如密碼等；
  post較get安全性較高；
  區別五：
  get方式只能支援ASCII字元，向伺服器傳的中文字元可能會亂碼。
  post支援標準字符集，可以正確傳遞中文字元。
  
  
  3、HTTP請求報文與響應報文格式

  請求報文包含三部分：
  a、請求行：包含請求方法、URI、HTTP版本資訊
  b、請求首部欄位
  c、請求內容實體
  響應報文包含三部分：
  a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語
  b、響應首部欄位
  c、響應內容實體
  
  4、常見的HTTP相應狀態碼

  返回的狀態
  1xx：指示資訊--表示請求已接收，繼續處理
  2xx：成功--表示請求已被成功接收、理解、接受
  3xx：重定向--要完成請求必須進行更進一步的操作
  4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
  5xx：伺服器端錯誤--伺服器未能實現合法的請求

  
  200：請求被正常處理
  204：請求被受理但沒有資源可以返回
  206：客戶端只是請求資源的一部分，伺服器只對請求的部分資源執行GET方法，相應報文中通過Content-Range指定範圍的資源。
  301：永久性重定向
  302：臨時重定向
  303：與302狀態碼有相似功能，只是它希望客戶端在請求一個URI的時候，能通過GET方法重定向到另一個URI上
  304：傳送附帶條件的請求時，條件不滿足時返回，與重定向無關
  307：臨時重定向，與302類似，只是強制要求使用POST方法
  400：請求報文語法有誤，伺服器無法識別
  401：請求需要認證
  403：請求的對應資源禁止被訪問
  404：伺服器無法找到對應資源
  500：伺服器內部錯誤
  503：伺服器正忙

  
  
  
  5、HTTP1.1版本新特性
  a、預設持久連線節省通訊量，只要客戶端服務端任意一端沒有明確提出斷開TCP連線，就一直保持連線，可以傳送多次HTTP請求

  b、管線化，客戶端可以同時發出多個HTTP請求，而不用一個個等待響應

  c、斷點續傳原理

  
  
  6、常見HTTP首部欄位
  a、通用首部欄位（請求報文與響應報文都會使用的首部欄位）
  Date：建立報文時間
  Connection：連線的管理
  Cache-Control：快取的控制
  Transfer-Encoding：報文主體的傳輸編碼方式
  b、請求首部欄位（請求報文會使用的首部欄位）
  Host：請求資源所在伺服器
  Accept：可處理的媒體型別
  Accept-Charset：可接收的字符集
  Accept-Encoding：可接受的內容編碼
  Accept-Language：可接受的自然語言
  c、響應首部欄位（響應報文會使用的首部欄位）
  Accept-Ranges：可接受的位元組範圍
  Location：令客戶端重新定向到的URI
  Server：HTTP伺服器的安裝資訊
  d、實體首部欄位（請求報文與響應報文的的實體部分使用的首部欄位）
  Allow：資源可支援的HTTP方法
  Content-Type：實體主類的型別
  Content-Encoding：實體主體適用的編碼方式
  Content-Language：實體主體的自然語言
  Content-Length：實體主體的的位元組數
  Content-Range：實體主體的位置範圍，一般用於發出部分請求時使用
  
  
  7、HTTP的缺點與HTTPS
  a、通訊使用明文不加密，內容可能被竊聽
  b、不驗證通訊方身份，可能遭到偽裝
  c、無法驗證報文完整性，可能被篡改

  HTTPS就是HTTP加上加密處理（一般是SSL安全通訊線路）+認證+完整性保護

  8、HTTP優化

  利用負載均衡優化和加速HTTP應用

  利用HTTP Cache來優化網站