程序中fork和vfork的區別
HTTP簡介
- WEB瀏覽器與WEB伺服器之間的一問一答的互動過程必須遵循一定的規則，這個規則就是HTTP協議。
- HTTP是HyperText Transfer Protocol(超文字傳輸協議)的簡寫，它是TCP/IP協議的一個應用層協議，用於定義WEB瀏覽器與WEB伺服器之間交換資料的過程及資料本身的格式。
- HTTP協議的版本：HTTP/1.0、HTTP/1.1
- HTTP協議是學習JavaWEB開發的基石，不深入瞭解HTTP協議，就不能說掌握了WEB開發，更無法管理和維護一些複雜的WEB站點。
HTTP1.0的基本執行方式
- 基於HTTP協議的客戶/伺服器模式的資訊交換過程，如圖所示，它分四個過程，建立連線、傳送請求資訊、傳送響應資訊、關閉連線。
- 瀏覽器與WEB伺服器的連線過程是短暫的，每次連線只處理一個請求和響應。對每一個頁面的訪問，瀏覽器與WEB伺服器都要建立一次單獨的連線。
- 瀏覽器到WEB伺服器之間的所有通訊都是完全獨立分開的請求和響應。
- 無狀態
HTTP1.1與HTTP1.0的比較
HTTP1.1的特點：
- 在一個TCP連線上可以傳送多個HTTP請求和響應。
- 多個請求和響應過程可以重疊
- 增加了更多的請求頭和響應頭，比如Host、If-Unmodified-Since請求頭等
HTTP請求訊息
客戶端連上伺服器後，向伺服器請求某個web資源，稱之為客戶端向伺服器傳送了一個HTTP請求。
一個完整的HTTP請求包括如下內容： 一個請求行、若干訊息頭、以及請求正文，其中的一些訊息頭和正文都是可選的，訊息頭和正文內容之間要用空行隔開。
HTTP響應訊息
一個HTTP響應代表伺服器向客戶端回送的資料。
一個完整的HTTP響應包括如下內容： 一個狀態行、若干訊息頭、以及響應正文，其中的一些訊息頭和正文都是可選的，訊息頭和正文內容之間要用空行隔開。
HTTP訊息頭（請求和響應共性）
- 使用訊息頭，可以實現HTTP客戶機與伺服器之間的條件請求和應答，訊息頭相當於伺服器和瀏覽器之間的一些暗號指令。
- 每個訊息頭包含一個頭欄位名稱，然後依次是冒號、空格、值、回車和換行符 如： Accept-Encoding: gzip, deflate
- 訊息頭欄位名是不區分大小寫的，但習慣上講每個單詞的第一個字母大寫。
- 整個訊息頭部分中的各行訊息頭可按任何順序排列。 訊息頭又可分為通用資訊頭、請求頭、響應頭、實體頭等四類 許多請求頭欄位都允許客戶端在值部分指定多個可接受的選項，多個選項之間以逗號分隔。
- 有些頭欄位可以出現多次，例如，響應訊息中可以包含有多個”Warning”頭欄位。
HTTP請求的細節——請求行
請求行 格式：請求方式 資源路徑 HTTP版本號<CRLF>
舉例：GET /temp3o116.shtml HTTP/1.1
請求方式：GET、POST、HEAD、OPTIONS、DELETE、TRACE、PUT
使用者如沒有設定，預設情況下瀏覽器向伺服器傳送的都是get請求，例如在瀏覽器直接輸地址訪問，點超連結訪問等都是get，使用者如想把請求方式改為post，可通過更改表單的提交方式實現。 不管POST或GET，都用於向伺服器請求某個WEB資源，這兩種方式的區別主要表現在資料傳遞上。 GET方式 如請求方式為GET方式，則可以在請求的URL地址後以?的形式帶上交給伺服器的資料，多個數據之間以&進行分隔，例如： GET /mail/1.html?name=abc&password=xyz HTTP/1.1
GET方式的特點：在URL地址後附帶的引數是有限制的，其資料容量通常不能超過1K。
POST方式 如請求方式為POST方式，則可以在請求的正文內容中向伺服器傳送資料，Post方式的特點：傳送的資料量無限制。
HTTP響應的細節——狀態行
狀態行
格式： HTTP版本號 狀態碼 原因敘述<CRLF>
舉例：HTTP/1.1 200 OK
狀態碼用於表示伺服器對請求的各種不同處理結果和狀態，它是一個三位的十進位制數。響應狀態碼分為5類，使用最高位為1到5來進行分類如下所示：
常用狀態碼：
200(正常) 表示一切正常，返回的是正常請求結果
302/307(臨時重定向) 指出被請求的文件已被臨時移動到別處，此文件的新的URL在Location響應頭中給出。
304(未修改) 表示客戶機快取的版本是最新的，客戶機可以繼續使用它，無需到伺服器請求。
404(找不到) 伺服器上不存在客戶機所請求的資源。
500(伺服器內部錯誤) 伺服器端的程式發生錯誤
請求頭細節
請求頭欄位用於客戶端在請求訊息中向伺服器傳遞附加資訊，主要包括客戶端可以接受的資料型別(MIME型別)、壓縮方法、語言以及發出請求的超連結所屬頁面的URL地址等資訊。 常用請求頭：
Accept:瀏覽器可接受的MIME型別
Accept-Charset: 瀏覽器通過這個頭告訴伺服器，它支援哪種字符集
Accept-Encoding:瀏覽器能夠進行解碼的資料編碼方式，比如gzip
Accept-Language:瀏覽器所希望的語言種類，當伺服器能夠提供一種以上的語言版本時要用到。 可以在瀏覽器中進行設定。
Host:初始URL中的主機和埠
Referer:包含一個URL，使用者從該URL代表的頁面出發訪問當前請求的頁面
Content-Type:內容型別
If-Modified-Since: Wed, 02 Feb 2011 12:04:56 GMT利用這個頭與伺服器的檔案進行比對，如果一致，則從快取中直接讀取檔案。
User-Agent:瀏覽器型別.
Content-Length:表示請求訊息正文的長度
Connection:表示是否需要持久連線。如果伺服器看到這裡的值為“Keep -Alive”，或者看到請求使用的是HTTP 1.1（HTTP 1.1預設進行持久連線
Cookie:這是最重要的請求頭資訊之一
Date：Date: Mon, 22 Aug 2011 01:55:39 GMT請求時間GMT
響應頭細節
Location: http://www.it315.org/index.jsp指示新的資源的位置
Server:apache tomcat指示伺服器的型別
Content-Encoding: gzip伺服器傳送的資料採用的編碼型別
Content-Length: 80 告訴瀏覽器正文的長度
Content-Language: zh-cn服務傳送的文字的語言
Content-Type: text/html; charset=GB2312伺服器傳送的內容的MIME型別
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT檔案的最後修改時間
Refresh: 1;url=http://www.it315.org指示客戶端重新整理頻率。單位是秒
Content-Disposition: attachment; filename=aaa.zip指示客戶端下載檔案
Set-Cookie:SS=Q0=5Lb_nQ; path=/search伺服器端傳送的
Cookie Expires: -1 Cache-Control: no-cache (1.1)
Pragma: no-cache (1.0) Connection: close/Keep-Alive Date: Tue, 11 Jul 2000 18:23:51 GMT
說明：cookie的資訊都是放置在頭中的。
表單提交涉及到的Http請求響應分析
在Form元素的語法中，EncType表明提交資料的格式 用 Enctype 屬性指定將資料回發到伺服器時瀏覽器使用的編碼型別。 例如：
application/x-www-form-urlencoded： 窗體資料被編碼為名稱/值對。這是標準的編碼格式。
multipart/form-data： 窗體資料被編碼為一條訊息，頁上的每個控制元件對應訊息中的一個部分，這個一般檔案上傳時用。
text/plain： 窗體資料以純文字形式進行編碼，其中不含任何控制元件或格式字元。
form的enctype屬性為編碼方式，常用有兩種：application/x-www-form-urlencoded和multipart/form-data，預設為application/x-www-form-urlencoded。
1.x-www-form-urlencoded
當action為get時候，瀏覽器用x-www-form-urlencoded的編碼方式把form資料轉換成一個字串（name1=value1&name2=value2…），然後把這個字串append到url後面，用?分割，載入這個新的url。
當action為post時候，就是將資料封裝到當前請求的請求體當中。
2.multipart/form-data
當action為post時候，瀏覽器把form資料封裝到http body中，然後傳送到server。 如果沒有type=file的控制元件，用預設的application/x-www-form-urlencoded就可以了。 但是如果有type=file的話，就要用到multipart/form-data了。瀏覽器會把整個表單以控制元件為單位分割，併為每個部分加上Content-Disposition(form-data或者file),Content-Type(預設為text/plain),name(控制元件name)等資訊，並加上分割符(boundary)。
另外，檔案下載也是需要設定響應頭中的Content-Disposition這個訊息頭
轉載於:https://my.oschina.net/whling/blog/1782846