【傳輸協定】TCP、UDP以及HTTP

文章目錄

• 一、TCP/IP：
• • • TCP/IP協定分層
• 二、TCP：
• • • TCP封包格式
    • TCP三向交握
    • TCP四次握手
    • TCP相關：
• 三、UDP協定：
• • • UDP使用：
    • UDP報頭
    • UDP特性
    • UDP一次發送多少bytes好？
    • UDP協定：低開銷通信
    • UDP資料報重組
    • UDP伺服器程序與請求
    • UDP用戶端程序
• 四、HTTP
• • • HTTP簡介
    • 主要特點
    • HTTP之URL
    • URI和URL的差別
    • HTTP之請求消息Request
    • HTTP之響應消息Response
    • HTTP之狀态碼
    • HTTP請求方法
    • HTTP工作原理
    • GET和POST差別：

OSI參考模型（Open System Interconnect)，即開放式系統互聯，标準定義了網絡互聯的七層架構：1.實體層（最底層）；2.資料鍊路層；3.網絡層；4.運輸層；5.會話層；6.表示層；7.應用層。

** 可以參考 部落格 **

一、TCP/IP：

TCP/IP協定分層

• 應用層： 向使用者提供一組常用的應用程式，比如：電子郵件、檔案傳輸通路(使用FTP協定)、遠端登陸(使用TELNET協定)等；應用層有：FTP、HTTP、TELNET、SMTP、DNS等協定。
• 傳輸層： 提供應用程式間的通信，功能包括：1.格式化資訊流；2.提供可靠傳輸；為實作可靠傳輸，規定接收端必須發回确認；傳輸層有：TCP協定與UDP協定；
• 網絡層： 負責相鄰計算機之間的通信，網絡層有：IP協定、ICMP協定、ARP協定、RARP協定和BOOTP協定；
  • 處理來之傳輸層的分組發送請求，收到請求後，将分組裝入IP資料報，填充報頭，選擇去往信宿機的路徑，然後将資料報發往适當的網絡接口；
  • 處理輸入資料報：首先檢查其合法性，然後進行尋徑–假如該資料報已經到達信宿機，則去掉報頭，将剩下的部分交給适當的傳輸協定；假如該資料報尚未到達信宿，則轉發該資料報；
  • 處理路徑、流控、擁塞問題；

IP是無連接配接的：

IP是用于計算機之間的通信，IP是無連接配接的通信協定，不會占用兩個正在通信的計算機之間的通信線路，這樣就降低了對網絡線路的需求，每條線可以同時滿足許多不同的計算機之間的通信需要；

通過IP，消息（或者其他資料）被分割為小的獨立包，并通過網際網路在計算機之間傳送；

IP負責将每個包路由至目的地。

TCP使用固定的連接配接

TCP用于應用程式之間的通信，建立通信時，會發送一個請求，該請求被送到一個确切的位址。在雙方通過三次“握手”之後，TCP将在兩個應用程式之間建立一個全雙工的通信，占用兩個計算機之間的通信線路，直到它被一方或者雙方關閉。

IP路由器

當一個IP包從一台機計算機被發送，它會到達一個IP路由器，直接或者通過其他路由器，IP路由器負責把這個包路由到目的地。

在一個相同的通信中，一個包所經由的路徑可能會和其他的包不同，而路由器負責根據通信量、網絡中的錯誤或者其他的參數來進行正确地尋址。

域名

在全世界，數量龐大的DNS伺服器被連入網際網路，DNS伺服器負責将域名翻譯為TCP/IP位址，同時負責使用新的域名資訊更新彼此的系統。

TCP/IP

TCP負責應用軟體和網絡軟體之間的通信；IP負責計算機之間的通信。

TCP負責将資料分割并裝入IP包，然後在他們到達的時候，重新組合他們。

IP負責将包發送至接受者。

二、TCP：

TCP封包格式

• 16位源端口号： 16位的源端口中包含初始化通信的端口。源端口和源IP位址的作用是辨別封包的傳回位址。
• 16位目的端口号： 16位的目的端口域定義傳輸的目的。這個端口指明封包接收計算機上的應用程式位址接口。
• 32位序号： 32位的序列号由接收端計算機使用，重新分段的封包成最初形式。當SYN出現，序列碼實際上是初始序列碼（Initial Sequence Number，ISN），而第一個資料位元組是ISN+1。這個序列号（序列碼）可用來補償傳輸中的不一緻。
• 32位确認序号： 32位的序列号由接收端計算機使用，重組分段的封包成最初形式。如果設定了ACK控制位，這個值表示一個準備接收的包的序列碼。
• 4位首部長度： 4位包括TCP頭大小，訓示何處資料開始。
• 保留（6位）： 6位值域，這些位必須是0。為了将來定義新的用途而保留。
• 标志： 6位标志域。表示為：緊急标志、有意義的應答标志、推、重置連接配接标志、同步序列号标志、完成發送資料标志。按照順序排列是：URG、ACK、PSH、RST、SYN、FIN:
  • URG： 緊急标志，緊急标志為1，表明該位有效；
  • ACK： 确認标志。表明确認序号欄有效。大多數情況下該标志位是置位的。TCP報頭内的确認編号欄内包含的确認編号（w+1）為下一個預期的序列編号，同時提示遠端系統已經成功接收所有資料。
  • PSH： 推标志。該标志置位時，接收端不将該資料進行隊列處理，而是盡可能快地将資料轉由應用處理。在處理Telnet或rlogin等互動模式的連接配接時，該标志總是置位的。
  • RST： 複位标志。用于複位相應的TCP連接配接。
  • SYN： 同步标志。表明同步序列編号欄有效。該标志僅在三次握手建立TCP連接配接時有效。它提示TCP連接配接的服務端檢查序列編号，該序列編号為TCP連接配接初始端（一般是用戶端）的初始序列編号。在這裡，可以把TCP序列編号看作是一個範圍從0到4，294，967，295的32位計數器。通過TCP連接配接交換的資料中每一個位元組都經過序列編号。在TCP報頭中的序列編号欄包括了TCP分段中第一個位元組的序列編号。
  • FIN： 結束标志。
• 16位視窗大小： 用來表示想收到的每個TCP資料段的大小。TCP的流量控制由連接配接的每一端通過聲明的視窗大小來提供。視窗大小為位元組數，起始于确認序号字段指明的值，這個值是接收端正期望接收的位元組。視窗大小是一個16位元組字段，因而視窗大小最大為65535位元組。
• 16位校驗和： 16位TCP頭。源機器基于資料内容計算一個數值，收資訊機要與源機器數值 結果完全一樣，進而證明資料的有效性。檢驗和覆寫了整個的TCP封包段：這是一個強制性的字段，一定是由發送端計算和存儲，并由接收端進行驗證的。
• 16位緊急指針： 指向後面是優先資料的位元組，在URG标志設定了時才有效。如果URG标志沒有被設定，緊急域作為填充。加快處理标示為緊急的資料段。
• 選項： 長度不定，但長度必須為1個位元組。如果沒有選項就表示這個1位元組的域等于0。
• 資料： 該TCP協定包負載的資料。

TCP三向交握

所謂三次握手（Three-Way Handshake）即建立TCP連接配接，就是指建立一個TCP連接配接時，需要用戶端和服務端總共發送3個包以确認連接配接的建立。在socket程式設計中，這一過程由用戶端執行connect來觸發，整個流程如下圖所示：

第一次握手： Client将标志位SYN置為1，随機産生一個值seq=J，并将該資料包發送給Server，Client進入SYN_SENT狀态，等待Server确認。

第二次握手： Server收到資料包後由标志位SYN=1知道Client請求建立連接配接，Server将标志位SYN和ACK都置為1，ack=J+1，随機産生一個值seq=K，并将該資料包發送給Client以确認連接配接請求，Server進入SYN_RCVD狀态。

第三次握手： Client收到确認後，檢查ack是否為J+1，ACK是否為1，如果正确則将标志位ACK置為1，ack=K+1，并且将确認序号（J+1）放在資料段，将該資料包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正确則連接配接建立成功，Client和Server進入ESTABLISHED狀态，完成三次握手，随後Client與Server之間可以開始傳輸資料了。

TCP四次握手

所謂四次揮手（Four-Way Wavehand）即終止TCP連接配接，就是指斷開一個TCP連接配接時，需要用戶端和服務端總共發送4個包以确認連接配接的斷開。在socket程式設計中，這一過程由用戶端或服務端任一方執行close來觸發，整個流程如下圖所示：

注：TIME_WAIT狀态需要經過2MSL（最長封包壽命）才能傳回到CLOSE狀态

由于TCP連接配接時全雙工的，是以，每個方向都必須要單獨進行關閉，這一原則是當一方完成資料發送任務後，發送一個FIN來終止這一方向的連接配接，收到一個FIN隻是意味着這一方向上沒有資料流動了，即不會再收到資料了，但是在這個TCP連接配接上仍然能夠發送資料，直到這一方向也發送了FIN。首先進行關閉的一方将執行主動關閉，而另一方則執行被動關閉，上圖描述的即是如此。

TCP相關：

• SYN攻擊：

  在三次握手過程中，Server發送SYN-ACK之後，收到Client的ACK之前的TCP連接配接稱為半連接配接（half-open connect），此時Server處于SYN_RCVD狀态，當收到ACK後，Server轉入ESTABLISHED狀态。SYN攻擊就是Client在短時間内僞造大量不存在的IP位址，并向Server不斷地發送SYN包，Server回複确認包，并等待Client的确認，由于源位址是不存在的，是以，Server需要不斷重發直至逾時，這些僞造的SYN包将産生時間占用未連接配接隊列，導緻正常的SYN請求因為隊列滿而被丢棄，進而引起網絡堵塞甚至系統癱瘓。SYN攻擊時一種典型的DDOS攻擊，檢測SYN攻擊的方式非常簡單，即當Server上有大量半連接配接狀态且源IP位址是随機的，則可以斷定遭到SYN攻擊了，使用如下指令可以讓之現行：

#netstat -nap | grep SYN_RECV
           

• 為什麼建立連接配接是三次握手，而關閉連接配接卻是四次揮手呢？

  這是因為服務端在LISTEN狀态下，收到建立連接配接請求的SYN封包後，把ACK和SYN放在一個封包裡發送給用戶端。而關閉連接配接時，當收到對方的FIN封包時，僅僅表示對方不再發送資料了但是還能接收資料，己方也未必全部資料都發送給對方了，是以己方可以立即close，也可以發送一些資料給對方後，再發送FIN封包給對方來表示同意現在關閉連接配接，是以，己方ACK和FIN一般都會分開發送。

• 為什麼TIME_WAIT狀态需要經過2MSL(最大封包段生存時間)才能傳回到CLOSE狀态？

  原因有二：

  • 保證TCP協定的全雙工連接配接能夠可靠關閉:

    如果Client直接CLOSED了，那麼由于IP協定的不可靠性或者是其它網絡原因，導緻Server沒有收到Client最後回複的ACK。那麼Server就會在逾時之後繼續發送FIN，此時由于Client已經CLOSED了，就找不到與重發的FIN對應的連接配接，最後Server就會收到RST而不是ACK，Server就會以為是連接配接錯誤把問題報告給高層。這樣的情況雖然不會造成資料丢失，但是卻導緻TCP協定不符合可靠連接配接的要求。是以，Client不是直接進入CLOSED，而是要保持TIME_WAIT，當再次收到FIN的時候，能夠保證對方收到ACK，最後正确的關閉連接配接。

  • 保證這次連接配接的重複資料段從網絡中消失:

    如果Client直接CLOSED，然後又再向Server發起一個新連接配接，我們不能保證這個新連接配接與剛關閉的連接配接的端口号是不同的。也就是說有可能新連接配接和老連接配接的端口号是相同的。一般來說不會發生什麼問題，但是還是有特殊情況出現：假設新連接配接和已經關閉的老連接配接端口号是一樣的，如果前一次連接配接的某些資料仍然滞留在網絡中，這些延遲資料在建立新連接配接之後才到達Server，由于新連接配接和老連接配接的端口号是一樣的，又因為TCP協定判斷不同連接配接的依據是socket pair，于是，TCP協定就認為那個延遲的資料是屬于新連接配接的，這樣就和真正的新連接配接的資料包發生混淆了。是以TCP連接配接還要在TIME_WAIT狀态等待2倍MSL，這樣可以保證本次連接配接的所有資料都從網絡中消失。

三、UDP協定：

UDP（User Datagram Protocol），使用者資料報協定，是OSI(Open System Interconnection，開放式系統互聯) 參考模型中一種無連接配接的傳輸層協定，提供面向事務的簡單不可靠資訊傳送服務，IETF RFC 768是UDP的正式規範。UDP提供了無連接配接通信，且不對傳送資料包進行可靠性保證，适合于一次傳輸少量資料，UDP傳輸的可靠性由應用層負責。常用的UDP端口号有:

DNC-----端口号：53

TFTP-----端口号：69

SNMP-----端口号：161

UDP封包沒有可靠性保證、順序保證和流量控制字段等，可靠性較差。但是正因為UDP協定的控制選項較少，在資料傳輸過程中延遲小、資料傳輸效率高，适合對可靠性要求不高的應用程式，或者可以保障可靠性的應用程式，如DNS、TFTP、SNMP等。UDP在IP包中的位置如下：

可以看到，UDP其實就是在IP封包中添加了端口資訊，使資料到達主機後送達至相應端口的應用程式。

UDP使用：

由于UDP的特性:它不屬于連接配接型協定，因而具有資源消耗小，處理速度快的優點，是以通常音頻、視訊和普通資料在傳送時使用UDP較多，因為它們即使偶爾丢失一兩個資料包，也不會對接收結果産生太大影響。比如我們聊天用的QQ就是使用的UDP協定。

既然UDP是一種不可靠的網絡協定，那麼還有什麼使用價值或必要呢?其實不然，在有些情況下UDP協定可能會變得非常有用。因為UDP具有TCP所望塵莫及的速度優勢。雖然TCP協定中植入了各種安全保障功能，但是在實際執行的過程中會占用大量的系統開銷，無疑使速度受到嚴重的影響。反觀UDP由于排除了資訊可靠傳遞機制，将安全和排序等功能移交給上層應用來完成，極大降低了執行時間，使速度得到了保證。

UDP報頭

UDP報頭由4個域組成，其中每個域占用2個位元組，如下：

• UDP協定使用端口号為不同的應用保留其各自的資料傳輸通道。 UDP和TCP協定正是采用這一機制實作對同一時刻内多項應用同時發送和接收資料的支援。資料發送一方(可以是用戶端或伺服器端)将UDP資料包通過源端口發送出去，而資料接收一方則通過目标端口接收資料。有的網絡應用隻能使用預先為其預留或注冊的靜态端口;而另外一些網絡應用則可以使用未被注冊的動态端口。因為UDP報頭使用兩個位元組存放端口号，是以端口号的有效範圍是從0到65535。一般來說，大于49151的端口号都代表動态端口。
• 資料報的長度是指包括報頭和資料部分在内的總位元組數。 因為報頭的長度是固定的，是以該域主要被用來計算可變長度的資料部分(又稱為資料負載)。資料報的最大長度根據操作環境的不同而各異。從理論上說，包含報頭在内的資料報的最大長度為65535位元組。不過，一些實際應用往往會限制資料報的大小，有時會降低到8192位元組。
• UDP協定使用報頭中的校驗值來保證資料的安全。 校驗值首先在資料發送方通過特殊的算法計算得出，在傳遞到接收方之後，還需要再重新計算。如果某個資料報在傳輸過程中被第三方篡改或者由于線路噪音等原因受到損壞，發送和接收方的校驗計算值将不會相符，由此UDP協定可以檢測是否出錯。這與TCP協定是不同的，後者要求必須具有校驗值。
• 許多鍊路層協定都提供錯誤檢查，包括流行的以太網協定，也許你想知道為什麼UDP也要提供檢查和校驗。其原因是鍊路層以下的協定在源端和終端之間的某些通道可能不提供錯誤檢測。 雖然UDP提供有錯誤檢測，但檢測到錯誤時，UDP不做錯誤校正，隻是簡單地把損壞的消息段扔掉，或者給應用程式提供警告資訊。

UDP特性

• UDP是一個無連接配接協定，傳輸資料之前源端和終端不建立連接配接，當UDP它想傳送時就簡單地去抓取來自應用程式的資料，并盡可能快地把它扔到網絡上。在發送端，UDP傳送資料的速度僅僅是受應用程式生成資料的速度、計算機的能力和傳輸帶寬的限制;在接收端，UDP把每個消息段放在隊列中，應用程式每次從隊列中讀一個消息段。
• 由于傳輸資料不建立連接配接，是以也就不需要維護連接配接狀态，包括收發狀态等，是以一台服務機可同時向多個客戶機傳輸相同的消息。
• UDP資訊包的标題很短，隻有8個位元組，相對于TCP的20個位元組資訊包的額外開銷很小。
• 吞吐量不受擁擠控制算法的調節，隻受應用軟體生成資料的速率、傳輸帶寬、源端和終端主機性能的限制。
• UDP使用盡最大努力傳遞，即不保證可靠傳遞，是以主機不需要維持複雜的連結狀态表(這裡面有許多參數)。
• UDP是面向封包的。發送方的UDP對應用程式交下來的封包，在添加首部後就向下傳遞給IP層。既不拆分，也不合并，而是保留這些封包的邊界，是以，應用程式需要選擇合适的封包大小。

UDP一次發送多少bytes好？

首先，我們知道TCP/IP通常被認為是一個四層協定系統，包括鍊路層、網絡層、傳輸層、應用層。UDP屬于傳輸層,下面我們由下至上一步一步來看: 以太網(Ethernet)資料幀的長度必須在46-1500位元組之間,這是由以太網的實體特性決定的。 這個1500位元組被稱為鍊路層的MTU(最大傳輸單元)。 但這并不是指鍊路層的長度被限制在1500位元組，其實這個MTU指的是鍊路層的資料區并不包括鍊路層的首部和尾部的18個位元組。是以事實上這個1500位元組就是網絡層IP資料報的長度限制。因為IP資料報的首部為20位元組，是以IP資料報的資料區長度最大為1480位元組。而這個1480位元組就是用來放TCP傳來的TCP封包段或UDP傳來的UDP資料報的。又因為UDP資料報的首部8位元組，是以UDP資料報的資料區最大長度為1472位元組。這個1472位元組就是我們可以使用的位元組數。

當我們發送的UDP資料大于1472的時候會怎樣呢？ 這也就是說IP資料報大于1500位元組，大于MTU。這個時候發送方IP層就需要分片(fragmentation)。 把資料報分成若幹片，使每一片都小于MTU。而接收方IP層則需要進行資料報的重組。這樣就會多做許多事情，而更嚴重的是，由于UDP的特性，當某一片資料傳送中丢失時，無法重組資料報，将導緻丢棄整個UDP資料報。是以，在普通的區域網路環境下，建議将UDP的資料控制在1472位元組以下為好。

進行Internet程式設計時則不同,因為Internet上的路由器可能會将MTU設為不同的值. 如果我們假定MTU為1500來發送資料的,而途經的某個網絡的MTU值小于1500位元組,那麼系統将會使用一系列的機制來調整MTU值,使資料報能夠順利到達目的地,這樣就會做許多不必要的操作. 鑒于Internet上的标準MTU值為576位元組, 是以我建議在進行Internet的UDP程式設計時. 最好将UDP的資料長度控件在548位元組(576-8-20)以内。

UDP協定：低開銷通信

UDP是一種簡單協定，提供了基本的傳輸層功能。與TCP相比，UDP的開銷極低，因為UDP是無連接配接的，并且不提供複雜的重新傳輸、排序和流量控制機制。

UDP資料報重組

與TCP的通信機制不同，由于UDP是無連接配接協定，是以通信發生之前不會建立會話。UDP是基于事務的，換言之，應用程式要發送資料時，它僅是發送資料而已。很多使用UDP的應用程式發送的資料量很小，用一個資料段就夠了。但是也有一些應用程式需要發送大量資料，是以需要用多個資料段。UDP PDU(協定資料單元) 實際意義是資料報，盡管資料段和資料報可以互換使用來描述某個傳輸層PDU。

将多個資料報發送到目的主機時，它們可能使用了不同的路徑，到達順序也可能跟發送時的順序不同。與TCP不同，UDP不跟蹤序列号。UDP不會對資料報重組，是以也不會将資料恢複到傳輸時的順序。

是以，UDP僅僅是将接收到的資料按照先來後到的順序轉發到應用程式。如果資料的順序對應用程式很重要，那麼應用程式隻能自己标志資料的正确順序，并決定如何處理這些資料。

UDP伺服器程序與請求

與基于TCP的應用程式相同的是，基于UDP的伺服器應用程式也被配置設定了公認端口或已注冊的端口。當上述應用程式或程序運作時，它們就會接受與所配置設定端口相比對的資料。當UDP收到用于某個端口的資料報時，它就會按照應用程式的端口号将資料發送到相應的應用程式。

UDP用戶端程序

對于TCP而言，用戶端/伺服器模式的通信初始化采用由用戶端應用程式向伺服器程序請求資料的形式。而UDP用戶端程序則是從動态可用端口中随機挑選一個端口号，用來作為會話的源端口。而目的端口通常都是配置設定到伺服器程序的公認端口或已注冊的端口。

采用随機的源端口号的另一個優點是提高安全性。如果目的端口的選擇方式容易預測，那麼網絡入侵者很容易就可以通過嘗試最可能開放的端口号通路用戶端。

由于UDP不建立會話，是以一旦資料和端口号準備就緒，UDP就可以生成資料報并遞交給網絡層，并在網絡上尋址和發送。

需要謹記的是，用戶端標明了源端口和目的端口後，通信事務中的所有資料封包頭都采用相同的端口對。對于從伺服器到達用戶端的資料來說，資料報頭所含的源端口和目的端口作了互換。

四、HTTP

HTTP簡介

HTTP協定是Hyper Text Transfer Protocol（超文本傳輸協定）的縮寫,是用于從網際網路（WWW:World Wide Web ）伺服器傳輸超文本到本地浏覽器的傳送協定。

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

HTTP是一個屬于應用層的面向對象的協定，由于其簡捷、快速的方式，适用于分布式超媒體資訊系統。

HTTP協定工作于用戶端-服務端架構上。浏覽器作為HTTP用戶端通過URL向HTTP服務端即WEB伺服器發送所有請求。Web伺服器根據接收到的請求後，向用戶端發送響應資訊。

主要特點

• 簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯系的類型不同。由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。
• 靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以标記；
• 無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間；
• 無狀态：HTTP協定是無狀态協定。無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。
• 支援B/S(Browser/Server)及C/S(Client/Server)模式。

HTTP之URL

HTTP使用統一資源辨別符（Uniform Resource Identifiers, URI）來傳輸資料和建立連接配接。URL是一種特殊類型的URI，包含了用于查找某個資源的足夠的資訊。

URL,全稱是UniformResourceLocator， 中文叫統一資源定位符,是網際網路上用來辨別某一處資源的位址。以下面這個URL為例，介紹下普通URL的各部分組成：

http://www.abcde.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

從上面的URL可以看出，一個完整的URL包括以下幾部分：

• 協定部分：URL的協定部分為“http：”，這代表網頁使用的是HTTP協定。在Internet中可以使用多種協定，如HTTP，FTP等等本例中使用的是HTTP協定。在"HTTP"後面的“//”為分隔符；
• 域名部分：該URL的域名部分為“www.abcde.com”。一個URL中，也可以使用IP位址作為域名使用;
• 端口部分：跟在域名後面的是端口，域名和端口之間使用

  :

  作為分隔符。端口不是一個URL必須的部分，如果省略端口部分，将采用預設端口;
• 虛拟目錄部分：從域名後的第一個“/”開始到最後一個“/”為止，是虛拟目錄部分。虛拟目錄也不是一個URL必須的部分。本例中的虛拟目錄是“/news/”;
• 檔案名部分：從域名後的最後一個“/”開始到“？”為止，是檔案名部分，如果沒有“?”,則是從域名後的最後一個“/”開始到“#”為止，是檔案部分，如果沒有“？”和“#”，那麼從域名後的最後一個“/”開始到結束，都是檔案名部分。本例中的檔案名是“index.asp”。檔案名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的檔案名;
• 錨部分：從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不是一個URL必須的部分
• 參數部分：從“？”開始到“#”為止之間的部分為參數部分，又稱搜尋部分、查詢部分。本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，參數與參數之間用“&”作為分隔符。

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 的示例。

HTTP之請求消息Request

用戶端發送一個HTTP請求到伺服器的請求消息包括以下格式：

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

Get請求舉例：

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，伺服器端和用戶端腳本都能通路它，它是浏覽器類型檢測邏輯的重要基礎，該資訊由你的浏覽器來定義，并且在每個請求中自動發送等等；

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

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

• 第四部分：請求資料也叫主體，可以添加任意的其他資料（該例子請求資料為空）

HTTP之響應消息Response

一般情況下，伺服器接收并處理用戶端發過來的請求後會傳回一個HTTP的響應消息；

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

例子：

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),

  charset: 編碼類型是UTF-8

• 第三部分：空行，消息報頭後面的空行是必須的
• 第四部分：響應正文，伺服器傳回給用戶端的文本資訊。

HTTP之狀态碼

狀态代碼有三位數字組成，第一個數字定義了響應的類别，共分五種類别:

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

HTTP請求方法

五種請求方法：

OPTIONS

,

PUT

,

DELETE

,

TRACE

和

CONNECT

方法。

• GET 請求指定的頁面資訊，并傳回實體主體。
• HEAD 類似于get請求，隻不過傳回的響應中沒有具體的内容，用于擷取報頭
• POST 向指定資源送出資料進行處理請求（例如送出表單或者上傳檔案）。資料被包含在請求體中。POST請求可能會導緻新的資源的建立和/或已有資源的修改。
• PUT 從用戶端向伺服器傳送的資料取代指定的文檔的内容。
• DELETE 請求伺服器删除指定的頁面。
• CONNECT HTTP/1.1協定中預留給能夠将連接配接改為管道方式的代理伺服器。
• OPTIONS 允許用戶端檢視伺服器的性能。
• TRACE 回顯伺服器收到的請求，主要用于測試或診斷。

HTTP工作原理

HTTP請求/響應步驟：

1. 用戶端連接配接到Web伺服器：

   一個HTTP用戶端，通常是浏覽器，與Web伺服器的HTTP端口（預設為80）建立一個TCP套接字連接配接；

2. 發起HTTP請求：

   通過TCP套接字，用戶端向Web伺服器發送一個文本的請求封包，一個請求封包由請求行、請求頭部、空行和請求資料4部分組成；

3. 伺服器接受請求并傳回HTTP響應：

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

4. 釋放連接配接TCP連接配接：

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

5. 用戶端浏覽器解析HTML内容：

   用戶端浏覽器首先解析狀态行，檢視表明請求是否成功的狀态代碼。然後解析每一個響應頭，響應頭告知以下為若幹位元組的HTML文檔和文檔的字元集。用戶端浏覽器讀取響應資料HTML，根據HTML的文法對其進行格式化，并在浏覽器視窗中顯示。

GET和POST差別：

1. GET送出的資料會在位址欄中顯示出來，而POST送出，位址欄不會改變，會把資料放在HTTP包的包體中；

2. 傳輸資料大小：

   GET：浏覽器對URL長度有限制，是以對GET請求資料的大小也有限制；

   POST：由于不是通過URL傳值，理論上資料不受 限。但實際各個WEB伺服器會規定對post送出資料大小進行限制，Apache、IIS6都有各自的配置。

3. 安全性：

   POST的安全性要比GET的安全性高；

4. GET，POST，SOAP

   get： 請求參數是作為一個key/value對的序列（查詢字元串）附加到URL上的查詢字元串的長度受到web浏覽器和web伺服器的限制（如IE最多支援2048個字元），不适合傳輸大型資料集同時，它很不安全；

   post： 請求參數是在http标題的一個不同部分（名為entity body）傳輸的，這一部分用來傳輸表單資訊，是以必須将Content-type設定為:application/x-www-form- urlencoded。post設計用來支援web窗體上的使用者字段，其參數也是作為key/value對傳輸，但是它不支援複雜資料類型，因為post沒有定義傳輸資料結構的語義和規則。

   soap： 是http post的一個專用版本，遵循一種特殊的xml消息格式Content-type設定為: text/xml 任何資料都可以xml化。