1.什麼是FTP協議；

FTP（File Transfer Protocol，檔案傳輸協議） 是 TCP/IP 協議組中的協議之一。FTP協議包括兩個組成部分，其一為FTP伺服器，其二為FTP客戶端。其中FTP伺服器用來儲存檔案，使用者可以使用FTP客戶端通過FTP協議訪問位於FTP伺服器上的資源。eg:在開發網站的時候，通常利用FTP協議把網頁或程式傳到Web伺服器上。此外，由於FTP傳輸效率非常高，在網路上傳輸大的檔案時，一般也採用該協議。預設情況下FTP協議使用TCP埠中的 20和21這兩個埠，其中20用於傳輸資料，21用於傳輸控制資訊。但是，是否使用20作為傳輸資料的埠與FTP使用的傳輸模式有關，如果採用主動模式

，那麼資料傳輸埠就是20；如果採用被動模式，則具體最終使用哪個埠要伺服器端和客戶端協商決定。2.主被動工作原理：

先簡單理解就是：在主動模式下，客戶端首先向伺服器端傳送IP地址和埠號，然後等待伺服器端建立TCP連結。在被動模式下，客戶端同樣首先建立到伺服器的連結，但伺服器端會開啟一個埠（1024到5000之間），等待客戶端傳輸資料。

FTP支援兩種模式，一種方式叫做Standard(也就是 PORT方式，主動方式)，一種是Passive(也就是PASV，被動方式)。 Standard模式 FTP的客戶端傳送 PORT 命令到FTP伺服器。Passive模式FTP的客戶端傳送 PASV命令到 FTP Server。下面介紹一個這兩種方式的工作原理：

Port

1.FTP客戶端首先和FTP伺服器的TCP 21埠（控制資訊）建立連線，通過這個通道傳送命令，客戶端需要接收資料的時候在這個通道上傳送PORT命令。 PORT命令包含了客戶端用什麼埠接收資料。2.在傳送資料的時候，伺服器端通過自己的TCP 20埠連線至客戶端的指定埠傳送資料。 FTP server必須和客戶端建立一個新的連線用來傳送資料。

Passive

1.在建立控制通道的時候和Standard模式類似，但建立連線後傳送的不是Port命令，而是Pasv命令。---建立連線！！（客戶端首先和FTP伺服器的TCP 21埠（控制資訊）建立連線）2.FTP伺服器收到Pasv命令後，隨機開啟一個高階埠（

埠號大於1024）並且通知客戶端在這個埠上傳送資料的請求，客戶端連線FTP伺服器此埠，然後FTP伺服器將通過這個埠進行資料的傳送，這個時候FTP server不再需要建立一個新的和客戶端之間的連線。很多防火牆在設定的時候都是不允許接受外部發起的連線的，所以許多位於防火牆後或內網的FTP伺服器不支援PASV模式，因為客戶端無法穿過防火牆開啟FTP伺服器的高階埠；而許多內網的客戶端不能用PORT模式登陸FTP伺服器，因為從伺服器的TCP 20無法和內部網路的客戶端建立一個新的連線，造成無法工作。如下圖：

為了跟了解FTP的工作機制，啟用wireshark進行抓包得到如下的結果：

       圖中亮起的一行是本機37875埠向伺服器的ftp-data(20)埠傳送結束資料傳輸連線的【FIN,ACK】請求（在前面幾行還可以見到連線同步請求SYN）。

       控制連線的兩個埠號分別是40938和ftp(21)。

       此外，在百度百科中看見貌似啟用資料連線時用的是控制連線的隨機埠號+1，雖然在《TCP/IP詳解》中所舉例子都是符合這一說法，但是其在文中詳細說明的時候並沒有這樣表述。而且從抓包實驗中也可以看到，37875與40938貌似沒有服從這種+1的關係。

• FTP的IPv6擴充套件（EPRT和EPSV）

      FTP僅僅提供了建立在IPv4上進行資料通訊的能力，它基於網路地址是32位這一假設。比如原來的PORT命令格式如下PORT n1 ,n2 ,n3 ,n4 ,n5 ,n6 那麼有客戶端I P地址（n1 .n2 .n3 .n4）和埠（n5×2 5 6 +n6）。但是，當IPv6出現以後，地址就比32位長許多了。原來對FTP進行的擴充套件在多協議環境中有時會失敗。針對IPv6對FTP再次進行擴充套件,兩個FTP命令PORT和PASV通過擴充套件後，我們稱它們為EPRT和EPSV。

3.FTP優缺點思考

1.與防火牆工作不協調
在檔案傳輸協議（FTP）誕生在網路地址轉換（NAT）和防火牆之前，那時的網路還不存在惡意攻擊。今天大多數終端使用者的IPv4地址已不可路由，這是因為防火牆的使用和IPv4地址的短缺。
這對FTP意味著什麼呢？這意味著如果FTP客戶端IP地址不可路由，或者位於防火牆之後，那麼就只能使用被動傳輸模式進行資料傳輸。
如果伺服器端的IP地址也不可路由，或者位於防火牆之後呢？FTP將無法進行資料傳輸！
現在，許多防火牆適用於NAT環境，可以使用一些特殊的技巧（hacks）允許FTP在防火牆之後正常工作。當然，這需要對防火牆進行配置。

2.密碼安全策略不完善
在網際網路早期，檔案傳輸協議（FTP）並沒有對密碼安全作出規定。在FTP客戶端和伺服器端，資料以明文的形式傳輸，任何對通訊路徑上的路由具有控制能力的人，都可以通過嗅探獲取你的密碼和資料。
我們當然可以使用SSL封裝FTP，但FTP是通過建立多次連結進行資料傳輸的，我們即便是保護了密碼安全，也很難保護資料傳輸的安全性。
自檔案傳輸協議（FTP）釋出以來，安全的資料傳輸也經歷了長足發展，推薦使用SCP取代FTP進行檔案傳輸。

3.FTP協議效率低下
從FTP伺服器上檢索一個檔案，包含繁複的交換握手步驟：
客戶端建立到FTP伺服器端控制埠的TCP Socket連結，並等待TCP握手完成
客戶端等待伺服器端傳送回執
客戶端向伺服器端傳送使用者名稱並等待響應
客戶端向伺服器端傳送密碼並等待響應
客戶端向伺服器端傳送SYST命令並等待響應
客戶端向伺服器端傳送TYPE I命令並等待響應
如果使用者需要在伺服器端切換目錄，客戶端仍然傳送命令並等待響應
主動模式下，客戶端需要傳送PORT命令到伺服器端，然後等待響應（被動模式與主動模式相反）
建立資料傳輸連結（需要經過三次握手，建立一條TCP Socket連線）
通過連結傳輸資料
客戶端等待伺服器端從控制連線傳送2xx指令，以確保資料傳輸成功
客戶端傳送QUIT命令，並等待伺服器響應

同樣的情形，我們來看看HTTP協議：
HTTP客戶端向HTTP伺服器端建立一條TCP Socket連線
HTTP客戶端向HTTP伺服器端傳送GET命令，包含URL、HTTP協議版本、虛擬主機名等等，並等待響應
HTTP伺服器端的響應包含了所有想要的資料，完成！

傳輸一個檔案，FTP需要往復10次，而HTTP只需要2次！如果傳輸多個檔案，FTP可以省略傳送使用者名稱和密碼的步驟，而HTTP則可以使用固定的套接字（Socket），在相同的TCP連線中傳輸檔案。

注：ACK 在資料通訊中，接收站發給傳送站的一種傳輸類確認控制字元

SYN (Synchronize) 

標記的包

SYN (Synchronize) 

標記的包

        SYN (Synchronize) 標記的包

總的歸納如下;

在TCP層，有個FLAGS欄位，這個欄位有以下幾個標識：SYN, FIN, ACK, PSH, RST, URG.

其中，對於我們日常的分析有用的就是前面的五個欄位。

 它們的含義是：

SYN表示建立連線，

FIN表示關閉連線，

ACK表示響應，

PSH表示有 DATA資料傳輸，

RST表示連線重置。

 其中，ACK是可能與SYN，FIN等同時使用的，比如SYN和ACK可能同時為1，它表示的就是建立連線之後的響應，

 如果只是單個的一個SYN，它表示的只是建立連線。

TCP的幾次握手就是通過這樣的ACK表現出來的。

 但SYN與FIN是不會同時為1的，因為前者表示的是建立連線，而後者表示的是斷開連線。

RST一般是在FIN之後才會出現為1的情況，表示的是連線重置。

 一般地，當出現FIN包或RST包時，我們便認為客戶端與伺服器端斷開了連線；而當出現SYN和SYN＋ACK包時，我們認為客戶端與伺服器建立了一個連線。

PSH為1的情況，一般只出現在 DATA內容不為0的包中，也就是說PSH為1表示的是有真正的TCP資料包內容被傳遞。

TCP的連線建立和連線關閉，都是通過請求－響應的模式完成的。

-------------------------------存在即合理，FTP還是使用很廣泛！

附錄1其他協議之TCP/IP:

TCP/IP 三次握手 ---from: http://swiftlet.net/archives/1082

在面試的過程中，TCP的傳輸協議經常會出現。以前我參加面試的過程中就被問到過，現在輪到我面試其他人的時候，我也會問一些相關的問題。作為一名開發者，無論使用什麼樣的開發語言，最基本的網路知識一定要理解透徹，這樣才能獲得更好的職業發展。

TCP連結協議概述

建立TCP需要三次握手才能建立，而斷開連線則需要四次握手。整個過程如下圖所示：
  

建立連線的過程

首先Client端傳送連線請求報文，Server段接受連線後回覆ACK報文，併為這次連線分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP連線就建立了。

斷開連線的過程

斷開連線端可以是Client端，也可以是Server端。假設1.Client端發起中斷連線請求，就先發送FIN報文。Server端接到FIN報文後，但是如果還有資料沒有傳送完成，則不必急著關閉Socket，可以繼續傳送資料。所以2.伺服器端先發送ACK，告訴Client端：請求已經收到了，但是我還沒準備好，請繼續等待停止的訊息。這個時候Client端就進入FIN_WAIT狀態，繼續等待Server端的FIN報文。當3.Server端確定資料已傳送完成，則向Client端傳送FIN報文，告訴Client端：伺服器這邊資料發完了，準備好關閉連線了。4.Client端收到FIN報文後，就知道可以關閉連線了，但是他還是不相信網路，所以傳送ACK後進入TIME_WAIT狀態， Server端收到ACK後，就知道可以斷開連線了。Client端等待了2MSL後依然沒有收到回覆，則證明Server端已正常關閉，最後，Client端也可以關閉連線了至此，TCP連線就已經完全關閉了！關閉連線的過程如下圖所示：

附錄2：曾今實習用到的SFTP協議

注：SFTP ------S--+ ---FTP(其中S為SSH)

一、協議的含義
SFTP協議能夠進行“遠端檔案獲取，檔案內容傳輸，檔案管理”等操作，它的控制訊號和資料訊號的傳輸通過安全資料通道進行。一般情況下，這個安全資料通道由SSH連線提供，即SSH連線隧道作為安全資料通道。
跟只能進行簡單檔案內容傳輸的SCP協議相比，SFTP協議更像是一個遠端檔案系統協議。
SFTP協議工作於OSI七層體系的應用層。

二、協議的原理
SFTP協議分為兩個端，分別是SFTP　Client和SFTP Server。SFTP Client和SFTP Server之間的控制訊號和檔案內容的傳輸得通過安全資料通道進行，安全資料通道可由“Transport Layer Security(TLS)”，“SSH”等協議提供，一般情況下是由SSH協議提供。
一旦SFTP Client和SFTP Server之間的連線得以建立，就可以通過二者之間的控制訊號和檔案內容的傳輸實現遠端檔案系統的功能。

SFTP是SSH File Transfer Protocol的縮寫，就是SSH檔案傳輸協議。一般的FTP客戶端比如Filezilla或者CuteFTP都支援SFTP。那麼如何建立SFTP服務呢？我們使用OpenSSH，這個軟體在Linux下是自帶的軟體包。往日傳東西上伺服器，因為搭建不是我搭建的架構，我用Filezilla來傳提示失敗，然後我就找原因以為伺服器ftp服務沒開就上伺服器上找發現沒找到有ftp的服務。我就納悶平常看同事都是這樣傳上去。後來想想是不是用了SFTP呢，看了一下果然而且前幾天自己剛剛改了ssh埠用同事原來設的22埠果斷登不上去的。改了一下埠就可以。

一般來說兩臺機器間的檔案傳輸，除了常用的ftp以外，還可以通過scp/sftp協議（就是本文介紹的sftp）進行。下面我們就來看看sftp協議與ftp協議之間的差別。    

（1）和ftp不同的是sftp/scp傳輸協議預設是採用加密方式來傳輸資料的，scp/sftp確保傳輸的一切資料都是加密的。而ftp一般來說允許明文傳輸，當然現在也有帶SSL的加密ftp，有些伺服器軟體也可以設定成“只允許加密連線”，但是畢竟不是預設設定需要我們手工調整，而且很多使用者都會忽略這個設定。    

（2）普通ftp僅使用埠21作為命令傳輸。由伺服器和客戶端協商另外一個隨機埠來進行資料傳送。在pasv模式下，伺服器端需要偵聽另一個口。假如伺服器在路由器或者防火牆後面，埠對映。會比較麻煩，因為無法提前知道資料埠編號，無法對映。（現在的ftp伺服器大都支援限制資料埠隨機取值範圍，一定程度上解決這個問題，但仍然要對映21號以及一個數據埠範圍，還有些伺服器通過UPnP協議與路由器協商動態對映，但比較少見）    

（3）當你的網路中還有一些unix系統的機器時，在它們上面自帶了scp等客戶端，不用再安裝其它軟體來實現傳輸目的。    

（4）scp/sftp屬於開源協議，我們可以免費使用不像FTP那樣使用上存在安全或版權問題。所有scp/sftp傳輸軟體（伺服器端和客戶端）均免費並開源，方便我們開發各種擴充套件外掛和應用元件。    

小提示：當然在提供安全傳輸的前提下sftp還是存在一些不足的，例如他的帳號訪問許可權是嚴格遵照系統使用者實現的，只有將該帳戶新增為作業系統某使用者才能夠保證其可以正常登入sftp伺服器。

附錄3：曾今實習用到的HTTPS協議 

from:http://www.jb51.net/network/68135.html

我們都知道HTTPS能夠加密資訊，以免敏感資訊被第三方獲取。所以很多銀行網站或電子郵箱等等安全級別較高的服務都會採用HTTPS協議。

　　HTTPS簡介

　　HTTPS其實是有兩部分組成：HTTP + SSL / TLS(安全傳輸層協議（TLS）用於在兩個通訊應用程式之間提供保密性和資料完整性。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。)(SSL(Secure Sockets Layer 安全套接層),及其繼任者傳輸層安全（Transport Layer Security，TLS）是為網路通訊提供安全及資料完整性的一種安全協議。TLS與SSL在傳輸層對網路連線進行加密。SSL協議位於TCP/IP協議與各種應用層協議之間，為資料通訊提供安全支援。SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。)，也就是在HTTP上又加了一層處理加密資訊的模組。服務端和客戶端的資訊傳輸都會通過TLS進行加密，所以傳輸的資料都是加密後的資料。具體是如何進行加密，解密，驗證的，且看下圖。

1. 客戶端發起HTTPS請求

　　這個沒什麼好說的，就是使用者在瀏覽器裡輸入一個https網址，然後連線到server的443埠。

　　2. 服務端的配置

　　採用HTTPS協議的伺服器必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想象成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

　　3. 傳送證書

　　這個證書其實就是公鑰，只是包含了很多資訊，如證書的頒發機構，過期時間等等。

　　4. 客戶端解析證書

　　這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

　　5. 傳送加密資訊

　　這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通訊就可以通過這個隨機值來進行加密解密了。

　　6. 服務段解密資訊

　　服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將資訊和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠複雜，資料就夠安全。

　　7. 傳輸加密後的資訊

　　這部分資訊是服務段用私鑰加密後的資訊，可以在客戶端被還原。

　　8. 客戶端解密資訊

　　客戶端用之前生成的私鑰解密服務段傳過來的資訊，於是獲取瞭解密後的內容。整個過程第三方即使監聽到了資料，也束手無策。

附錄4：HTTP協議：

HTTP是一個屬於應用層的面向物件的協議，由於其簡捷、快速的方式，適用於分散式超媒體資訊系統。它於1990年提出，經過幾年的使用與發展，得到不斷地完善和擴充套件。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規範化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經提出。
HTTP協議的主要特點可概括如下：
1.支援客戶/伺服器模式。
2.簡單快速：客戶向伺服器請求服務時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯絡的型別不同。由於HTTP協議簡單，使得HTTP伺服器的程式規模小，因而通訊速度很快。
3.靈活：HTTP允許傳輸任意型別的資料物件。正在傳輸的型別由Content-Type加以標記。
4.無連線：無連線的含義是限制每次連線只處理一個請求。伺服器處理完客戶的請求，並收到客戶的應答後，即斷開連線。採用這種方式可以節省傳輸時間。
5.無狀態：HTTP協議是無狀態協議。無狀態是指協議對於事務處理沒有記憶能力。缺少狀態意味著如果後續處理需要前面的資訊，則它必須重傳，這樣可能導致每次連線傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。

一、HTTP

1.1 HTTP協議詳解之URL篇

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

HTTP URL (URL是一種特殊型別的URI，包含了用於查詢某個資源的足夠的資訊)的格式如下：

http://host[":"port][abs_path]
　　http表示要通過HTTP協議來定位網路資源；host表示合法的Internet主機域名或者IP地址；port指定一個埠號，為空則使用預設埠80；abs_path指定請求資源的URI；如果URL中沒有給出abs_path，那麼當它作為請求URI時，必須以“/”的形式給出，通常這個工作瀏覽器自動幫我們完成。
eg:
1、輸入：瀏覽器自動轉換成：http://www.guet.edu.cn/
2、http:192.168.0.116:8080/index.jsp 

1.2 HTTP協議詳解之請求篇

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

1、請求行以一個方法符號開頭，以空格分開，後面跟著請求的URI和協議的版本，格式如下：

Method Request-URI HTTP-Version CRLF  
其中 Method表示請求方法；Request-URI是一個統一資源識別符號；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字元）。

請求方法（所有方法全為大寫）有多種，各個方法的解釋如下：
GET　　　　請求獲取Request-URI所標識的資源
POST　　　 在Request-URI所標識的資源後附加新的資料
HEAD　　　 請求獲取由Request-URI所標識的資源的響應訊息報頭
PUT　　　　 請求伺服器儲存一個資源，並用Request-URI作為其標識
DELETE　　 請求伺服器刪除Request-URI所標識的資源
TRACE　　  請求伺服器回送收到的請求資訊，主要用於測試或診斷
CONNECT　 保留將來使用
OPTIONS　  請求查詢伺服器的效能，或者查詢與資源相關的選項和需求
應用舉例：
GET方法：在瀏覽器的位址列中輸入網址的方式訪問網頁時，瀏覽器採用GET方法向伺服器獲取資源，eg:GET /form.html HTTP/1.1 (CRLF)

POST方法要求被請求伺服器接受附在請求後面的資料，常用於提交表單。
eg：POST /reg.jsp HTTP/ (CRLF)
Accept:image/gif,image/x-xbit,... (CRLF)
...
HOST:www.guet.edu.cn (CRLF)
Content-Length:22 (CRLF)
Connection:Keep-Alive (CRLF)
Cache-Control:no-cache (CRLF)
(CRLF)         //該CRLF表示訊息報頭已經結束，在此之前為訊息報頭
user=jeffrey&pwd=1234  //此行以下為提交的資料

HEAD方法與GET方法幾乎是一樣的，對於HEAD請求的迴應部分來說，它的HTTP頭部中包含的資訊與通過GET請求所得到的資訊是相同的。利用這個方法，不必傳輸整個資源內容，就可以得到Request-URI所標識的資源的資訊。該方法常用於測試超連結的有效性，是否可以訪問，以及最近是否更新。
2、請求報頭後述
3、請求正文(略) 

1.3 HTTP協議詳解之響應篇

　　在接收和解釋請求訊息後，伺服器返回一個HTTP響應訊息。

HTTP響應也是由三個部分組成，分別是：狀態行、訊息報頭、響應正文
1、狀態行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態程式碼；Reason-Phrase表示狀態程式碼的文字描述。
狀態程式碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示資訊--表示請求已接收，繼續處理
2xx：成功--表示請求已被成功接收、理解、接受
3xx：重定向--要完成請求必須進行更進一步的操作
4xx：客戶端錯誤--請求有語法錯誤或請求無法實現
5xx：伺服器端錯誤--伺服器未能實現合法的請求
常見狀態程式碼、狀態描述、說明：
200 OK      //客戶端請求成功
400 Bad Request  //客戶端請求有語法錯誤，不能被伺服器所理解
401 Unauthorized //請求未經授權，這個狀態程式碼必須和WWW-Authenticate報頭域一起使用 
403 Forbidden  //伺服器收到請求，但是拒絕提供服務
404 Not Found  //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //伺服器發生不可預期的錯誤
503 Server Unavailable  //伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常
eg：HTTP/1.1 200 OK （CRLF）

2、響應報頭後述

3、響應正文就是伺服器返回的資源的內容 

1.4 HTTP協議詳解之訊息報頭篇

　　HTTP訊息由客戶端到伺服器的請求和伺服器到客戶端的響應組成。請求訊息和響應訊息都是由開始行（對於請求訊息，開始行就是請求行，對於響應訊息，開始行就是狀態行），訊息報頭（可選），空行（只有CRLF的行），訊息正文（可選）組成。

HTTP訊息報頭包括普通報頭、請求報頭、響應報頭、實體報頭。
每一個報頭域都是由名字+“：”+空格+值 組成，訊息報頭域的名字是大小寫無關的。

1、普通報頭
　　在普通報頭中，有少數報頭域用於所有的請求和響應訊息，但並不用於被傳輸的實體，

相關推薦