天天看點
傳回

網絡基礎知識 - HTTP協定

前傳：HTTP協定的演變過程

　　HTTP（HyperText Transfer Protocol）協定是基于TCP的應用層協定，它不關心資料傳輸的細節，主要是用來規定用戶端和服務端的資料傳輸格式，最初是用來向用戶端傳輸HTML頁面的内容。預設端口是80。

1.HTTP 0.9版本　　1991年

　　這個版本就是最初用來向用戶端傳輸HTML頁面的，是以隻有一個GET指令，然後伺服器傳回用戶端一個HTML頁面，不能是其他格式。利用這個版本完全可以建構一個簡單的靜态網站了。

2.HTTP 1.0版本　　1996年

　　1.0版本是改變比較大的，奠定了現在HTTP協定的基礎。這個版本的協定不僅可以傳輸HTML的文本頁面，還可以傳輸其他二進制檔案，例如圖檔、視訊。而且還增加了現在常用的POST和HEAD指令。請求消息和響應消息也不是單一的了，規定了一些中繼資料字段。例如字元集、編碼、狀态響應碼等。

3.HTTP 1.1版本　　1997年

　　實際上是在1.0版本之後半年時間又釋出了一個版本，這個版本在1.0版本的基礎上更加完善了。這個版本增加了持久連接配接，就是說之前版本的協定一次請求就是一次TCP連接配接，請求完成後這個連接配接就關閉掉了。衆所周知TCP協定是可靠的，建立連接配接需要3次握手，斷開連接配接需要4次揮手，并且TCP有流量控制和擁塞控制，有慢開始機制，剛建立連接配接時傳輸比較慢，這是比較耗費資源的。一個豐富的頁面會有許多圖檔、表單和超連結。這樣的話就會有多次的HTTP請求，是以在這個版本上預設不關閉TCP連接配接也不用聲明Connection: keep-alive字段。如果确實要關閉可以指定Connection: close字段。還引入了管道機制，就是說在一個TCP連接配接裡可以同時發送多個HTTP請求，而不必等待上一個請求響應成功再發送。還增加了PUT、PATCH、HEAD、 OPTIONS、DELETE等指令，豐富了用戶端和服務端互動動作。還增加了Host字段。

4.HTTP 2版本　　2015年

　　這個版本也是随着網際網路的發展，有了新的需求制定了新的功能還有對上一個版本的完善。1.1版本有了管道機制，但是正在服務端還是要對請求進行排隊處理。這個版本可以多工的處理。還有了頭資訊壓縮和伺服器的主動推送。

5.HTTPS

　　HTTPS是HTTP協定的安全版本，HTTP協定的資料傳輸是明文的，是不安全的，HTTPS使用了SSL/TLS協定進行了加密處理。

　　後面介紹沒有特殊說明預設HTTP/1.1版本

 一，HTTP概述

　　HTTP（hypertext transport protocol），即超文本傳輸協定。他是網際網路上應用最為廣泛的一種網絡協定。所有的WWW（WWW:World Wide Web 又稱為網際網路）檔案必須遵守這個标準，這個協定詳細規定了浏覽器和網際網路伺服器之間互相通信的規則。

　　HTTP是一個基于TCP/IP通信協定來傳遞資料（HTML 檔案, 圖檔檔案, 查詢結果等）。HTTP就是一個通信規則，通信規則規定了用戶端發送給伺服器的内容格式，也規定了伺服器發送給用戶端的内容格式。其實我們要學習的就是這個兩個格式！用戶端發送給伺服器的格式叫“請求協定”；伺服器發送給用戶端的格式叫“響應協定”。

網絡基礎知識 - HTTP協定

　　HTTP是一個屬于應用層的面向對象的協定，由于其簡潔，快速的方式，适用于分布式超媒體資訊系統，它于1990年提出，經過幾年的使用與發展，得到不斷地完善和擴充。HTTP協定工作于用戶端-服務端架構上。浏覽器作為HTTP用戶端通過URL向HTTP服務端即WEB伺服器發送所有請求。Web伺服器根據接收到的請求後，向用戶端發送響應資訊。 　　

網絡基礎知識 - HTTP協定

特點：

  • HTTP叫超文本傳輸協定，基于請求/響應模式的！
  • HTTP是無狀态協定：無狀态是指協定對于事務處理沒有記憶能力。缺少狀态意味着如果後續處理需要前面的資訊，則它必須重傳，這樣可能導緻每次連接配接傳送的資料量增大。另一方面，在伺服器不需要先前資訊時它的應答就較快。就是說每次HTTP請求都是獨立的，任何兩個請求之間沒有什麼必然的聯系。但是在實際應用當中并不是完全這樣的，引入了Cookie和Session機制來關聯請求。
  • 基于TCP協定：HTTP協定目的是規定用戶端和服務端資料傳輸的格式和資料互動行為，并不負責資料傳輸的細節。底層是基于TCP實作的。現在使用的版本當中是預設持久連接配接的，也就是多次HTTP請求使用一個TCP連接配接。
  • 支援B/S以及C/S模式
  • 無連接配接：無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。
  • 靈活：HTTP允許傳輸任意類型的資料對象。正在傳輸的類型由Content-Type加以标記。
  • 簡單快速：客戶向伺服器請求服務時，隻需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規定了客戶與伺服器聯系的類型不同。由于HTTP協定簡單，使得HTTP伺服器的程式規模小，因而通信速度很快。

　　URL：統一資源定位符（Uniform Resource Identifiers），就是一個網址：協定名://域名:端口/路徑，例如：http://www.baidu.com/index.html

以下面這個URL為例，介紹下普通URL的各部分組成：
http://www.aspxfans.com:8080/news/index.asp?boardID=5&ID=24618&page=1#name

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

1.協定部分：該URL的協定部分為“http：”，這代表網頁使用的是HTTP協定。
在Internet中可以使用多種協定，如HTTP，FTP等等本例中使用的是HTTP協定。
在"HTTP"後面的“//”為分隔符

2.域名部分：該URL的域名部分為“www.aspxfans.com”。一個URL中，也可以
使用IP位址作為域名使用

3.端口部分：跟在域名後面的是端口，域名和端口之間使用“:”作為分隔符。端口
不是一個URL必須的部分，如果省略端口部分，将采用預設端口

4.虛拟目錄部分：從域名後的第一個“/”開始到最後一個“/”為止，是虛拟目錄部分。
虛拟目錄也不是一個URL必須的部分。本例中的虛拟目錄是“/news/”

5.檔案名部分：從域名後的最後一個“/”開始到“？”為止，是檔案名部分，如果沒有“?”,
則是從域名後的最後一個“/”開始到“#”為止，是檔案部分，如果沒有“？”和“#”，那麼
從域名後的最後一個“/”開始到結束，都是檔案名部分。本例中的檔案名是“index.asp”。
檔案名部分也不是一個URL必須的部分，如果省略該部分，則使用預設的檔案名

6.錨部分：從“#”開始到最後，都是錨部分。本例中的錨部分是“name”。錨部分也不
是一個URL必須的部分

7.參數部分：從“？”開始到“#”為止之間的部分為參數部分，又稱搜尋部分、查詢部分。
本例中的參數部分為“boardID=5&ID=24618&page=1”。參數可以允許有多個參數，
參數與參數之間用“&”作為分隔符。

　　

二，HTTP工作原理

　　HTTP協定定義Web用戶端如何從Web伺服器請求Web頁面，以及伺服器如何把Web頁面傳送給用戶端。HTTP協定采用了請求/響應模型。用戶端向伺服器發送一個請求封包，請求封包包含請求的方法、URL、協定版本、請求頭部和請求資料。伺服器以一個狀态行作為響應，響應的内容包括協定的版本、成功或者錯誤代碼、伺服器資訊、響應頭部和響應資料。

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

網絡基礎知識 - HTTP協定

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

一個HTTP用戶端，通常是浏覽器，與Web伺服器的HTTP端口（預設為80）建立一個TCP套接字連接配接。例如，http://www.haojixing.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 文本并顯示内容; 　

三，請求協定(Request)

請求協定的格式如下：

請求首行；  // 請求方式 請求路徑 協定和版本，例如：GET /index.html HTTP/1.1
請求頭資訊；// 請求頭名稱:請求頭内容，即為key:value格式，例如：Host:localhost
空行；     // 用來與請求體分隔開
請求體。   // GET沒有請求體，隻有POST有請求體。

　　浏覽器發送給伺服器的内容就這個格式的，如果不是這個格式伺服器将無法解讀！在HTTP協定中，請求有很多請求方法，其中最為常用的就是GET和POST。

http請求消息結構圖

網絡基礎知識 - HTTP協定
網絡基礎知識 - HTTP協定

 　　簡單來說請求封包就是由請求行、請求頭、内容實體組成的，注意，每一行的末尾都有回車和換行，在内容實體和請求頭之間另有一個空行。其中請求行指定的是請求方法、請求URL、協定版本；請求頭是鍵值對的形式存在的，就是字段名：值；内容實體就是要傳輸的資料。稍後會對方法、請求頭字段做詳細的說明。

3.1　GET請求

HTTP預設的請求方法就是GET

     1. 沒有請求體

     2. 資料必須在1K之内！

     3. GET請求資料會暴露在浏覽器的位址欄中

GET請求常用的操作：

       1. 在浏覽器的位址欄中直接給出URL，那麼就一定是GET請求

       2. 點選頁面上的超連結也一定是GET請求

       3. 送出表單時，表單預設使用GET請求，但可以設定為POST

  • GET 127.0.0.1:8090/login  HTTP/1.1：GET請求，請求伺服器路徑為  127.0.0.1:8090/login ，協定為1.1；
  • Host:localhost：請求的主機名為localhost；
  • *User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0：與浏覽器和OS相關的資訊。有些網站會顯示使用者的系統版本和浏覽器版本資訊，這都是通過擷取User-Agent頭資訊而來的；
  •  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8：告訴伺服器，目前用戶端可以接收的文檔類型，其實這裡包含了*/*，就表示什麼都可以接收；
  • Accept-Language: zh-cn,zh;q=0.5：目前用戶端支援的語言，可以在浏覽器的工具選項中找到語言相關資訊；
  • Accept-Encoding: gzip, deflate：支援的壓縮格式。資料在網絡上傳遞時，可能伺服器會把資料壓縮後再發送；
  • Accept-Charset: GB2312,utf-8;q=0.7,*;q=0.7：用戶端支援的編碼；
  • Connection: keep-alive：用戶端支援的連結方式，保持一段時間連結，預設為3000ms；
  • Cookie: JSESSIONID=369766FDF6220F7803433C0B2DE36D98：因為不是第一次通路這個位址，是以會在請求中把上一次伺服器響應中發送過來的Cookie在請求中一并發送去過；這個Cookie的名字為JSESSIONID。

注意

　　HTTP無狀态：無狀态是指協定對于事務處理沒有記憶能力，伺服器不知道用戶端是什麼狀态。從另一方面講，打開一個伺服器上的網頁

　　和你之前打開這個伺服器上的網頁之間沒有任何聯系

　　如果你要實作一個購物車，需要借助于Cookie或Session或伺服器端API（如NSAPI and ISAPI）記錄這些資訊，請求伺服器結算頁面時同時将這些資訊送出到伺服器

　　當你登入到一個網站時，你的登入狀态也是由Cookie或Session來“記憶”的，因為伺服器并不知道你是否登入

優點：伺服器不用為每個用戶端連接配接配置設定記憶體來記憶大量狀态，也不用在用戶端失去連接配接時去清理記憶體，以更高效地去處理WEB業務

　　缺點：用戶端的每次請求都需要攜帶相應參數，伺服器需要處理這些參數容易犯的誤區：

　　1、HTTP是一個無狀态的面向連接配接的協定，無狀态不代表HTTP不能保持TCP連接配接，更不能代表HTTP使用的是UDP協定（無連接配接）

　　2、從HTTP/1.1起，預設都開啟了Keep-Alive，保持連接配接特性，簡單地說，當一個網頁打開完成後，用戶端和伺服器之間用于傳輸

             HTTP資料的TCP連接配接不會關閉，如果用戶端再次通路這個伺服器上的網頁，會繼續使用這一條已經建立的連接配接

　　3、Keep-Alive不會永久保持連接配接，它有一個保持時間，可以在不同的伺服器軟體（如Apache）中設定這個時間

3.2　POST請求

(1). 資料不會出現在位址欄中

(2). 資料的大小沒有上限

(3). 有請求體

(4). 請求體中如果存在中文，會使用URL編碼！

username=%E5%BC%A0%E4%B8%89&password=123

為什麼要進行URL編碼？

　　我們都知道Http協定中參數的傳輸是"key=value"這種鍵值對形式的，如果要傳多個參數就需要用“&”符号對鍵值對進行分割。如"?name1=value1&name2=value2"，這樣在服務端在收到這種字元串的時候，會用“&”分割出每一個參數，然後再用“=”來分割出參數值。

針對“name1=value1&name2=value2”我們來說一下用戶端到服務端的概念上解析過程:

  　　上述字元串在計算機中用ASCII嗎表示為：

  6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532。

   6E616D6531：name1

   3D：=

   76616C756531：value1

   26：&

   6E616D6532：name2

   76616C756532：value2 

  　　服務端在接收到該資料後就可以周遊該位元組流，首先一個位元組一個位元組的吃，當吃到3D這位元組後，服務端就知道前面吃得位元組表示一個key，再想後吃，如果遇到26，說明從剛才吃的3D到26子節之間的是上一個key的value，以此類推就可以解析出用戶端傳過來的參數。

  　　現在有這樣一個問題，如果我的參數值中就包含=或&這種特殊字元的時候該怎麼辦。

比如說“name1=value1”,其中value1的值是“va&lu=e1”字元串，那麼實際在傳輸過程中就會變成這樣“name1=va&lu=e1”。我們的本意是就隻有一個鍵值對，但是服務端會解析成兩個鍵值對，這樣就産生了奇異。

如何解決上述問題帶來的歧義呢？解決的辦法就是對參數進行URL編碼 

  　　URL編碼隻是簡單的在特殊字元的各個位元組前加上%，例如，我們對上述會産生奇異的字元進行URL編碼後結果：“name1=va%26lu%3D”，這樣服務端會把緊跟在“%”後的位元組當成普通的位元組，就是不會把它當成各個參數或鍵值對的分隔符。

使用表單可以發POST請求，但表單預設是GET

<form action="" method="post">
  關鍵字：<input type="text" name="keyword"/>
  <input type="submit" value="送出"/>
</form>

輸入wang後點選送出，檢視請求内容如下：

Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate
Accept-Language:zh-CN,zh;q=0.8
Cache-Control:no-cache
Connection:keep-alive
Content-Length:13
Content-Type:application/x-www-form-urlencoded
Cookie:csrftoken=z5H43ZwARx7AIJ82OEizBOWbsAQA2LPk
Host:127.0.0.1:8090
Origin:http://127.0.0.1:8090
Pragma:no-cache
Referer:http://127.0.0.1:8090/login/
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) 
           AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.89 Safari/537.36

Form Data
username:wang

POST請求是可以有體的，而GET請求不能有請求體。

  • Referer: http://localhost:8080/hello/index.jsp：請求來自哪個頁面，例如你在百度上點選連結到了這裡，那麼Referer:http://www.baidu.com；如果你是在浏覽器的位址欄中直接輸入的位址，那麼就沒有Referer這個請求頭了；
  • Content-Type: application/x-www-form-urlencoded：表單的資料類型，說明會使用url格式編碼資料；url編碼的資料都是以“%”為字首，後面跟随兩位的16進制。
  • Content-Length:13：請求體的長度，這裡表示13個位元組。
  • keyword=hello：請求體内容！hello是在表單中輸入的資料，keyword是表單字段的名字。

referer的應用

　　Referer請求頭是比較有用的一個請求頭，它可以用來做統計工作，也可以用來做防盜鍊。

統計工作：我公司網站在百度上做了廣告，但不知道在百度上做廣告對我們網站的通路量是否有影響，那麼可以對每個請求中的Referer進行分析，如果Referer為百度的很多，那麼說明使用者都是通過百度找到我們公司網站的。

　　防盜鍊：我公司網站上有一個下載下傳連結，而其他網站盜鍊了這個位址，例如在我網站上的index.html頁面中有一個連結，點選即可下載下傳JDK7.0，但有某個人的微網誌中盜鍊了這個資源，它也有一個連結指向我們網站的JDK7.0，也就是說登入它的微網誌，點選連結就可以從我網站上下載下傳JDK7.0，這導緻我們網站的廣告沒有看，但下載下傳的卻是我網站的資源。這時可以使用Referer進行防盜鍊，在資源被下載下傳之前，我們對Referer進行判斷，如果請求來自本網站，那麼允許下載下傳，如果非本網站，先跳轉到本網站看廣告，然後再允許下載下傳。

四，HTTP請求協定與響應協定

　　HTTP協定包含由浏覽器發送資料到伺服器需要遵循的請求協定與伺服器發送資料到浏覽器需要遵循的請求協定。用于HTTP協定互動的信為HTTP封包。請求端（用戶端）的HTTP封包做請求封包，響應端（伺服器端）的做響應封包。HTTP封包本身是由多行資料構成的字文本。

網絡基礎知識 - HTTP協定

4.1  請求協定

請求格式如下：

網絡基礎知識 - HTTP協定

請求方式：get和post請求

  •  GET送出的資料會放在URL之後，以？分割URL和傳輸資料，參數之間以 & 相連，而POST方法是把送出的資料放在HTTP包的請求體中。
  • GET送出的資料大小有限制（因為浏覽器對URL的長度有限制），而POST方法送出的資料沒有限制。
  • GET和POST請求在服務端擷取請求的資料方式不同。

GET送出資料如下：

EditBook?name=test1&id=123456.

4.2　響應内容

響應協定的格式如下：

響應首行；
響應頭資訊；
空行；
響應體。
網絡基礎知識 - HTTP協定

　　響應内容是由伺服器發送給浏覽器的内容，浏覽器會根據響應内容來顯示。遇到<img src=''>會開一個新的線程加載，是以有時圖檔多的話，内容會先顯示出來，然後圖檔才一張張加載出來。

Request URL:http://127.0.0.1:8090/login/
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:8090
Response Headers
view source
Content-Type:text/html; charset=utf-8
Date:Wed, 26 Oct 2016 06:48:50 GMT
Server:WSGIServer/0.2 CPython/3.5.2
X-Frame-Options:SAMEORIGIN

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<form action="/login/" method="post">
  使用者名：<input type="text" name="username"/>
  <input type="submit" value="送出"/>
</form>    
</body>
</html>
  • HTTP/1.1 200 OK：響應協定為HTTP1.1，狀态碼為200，表示請求成功，OK是對狀态碼的解釋；
  • Server:WSGIServer/0.2 CPython/3.5.2：伺服器的版本資訊；
  • Content-Type: text/html;charset=UTF-8：響應體使用的編碼為UTF-8；
  • Content-Length: 724：響應體為724位元組；
  • Set-Cookie: JSESSIONID=C97E2B4C55553EAB46079A4F263435A4; Path=/hello：響應給用戶端的Cookie；
  • Date: Wed, 25 Sep 2012 04:15:03 GMT：響應的時間，這可能會有8小時的時區差；

4.3　狀态碼

　　響應頭對浏覽器來說很重要，它說明了響應的真正含義。例如200表示響應成功了，302表示重定向，這說明浏覽器需要再發一個新的請求。

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

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

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

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

4xx：用戶端錯誤--請求有文法錯誤或請求無法實作

5xx：伺服器端錯誤--伺服器未能實作合法的請求
網絡基礎知識 - HTTP協定

　　狀态碼這裡就不一一介紹了，如果有需要的同學們。可以參觀下面部落格，很全面。

http://www.cnblogs.com/wj-1314/p/7805684.html

這裡重點講一下304 Not Modified

　　　　(未按預期修改文檔。用戶端有緩沖的文檔并發出了一個條件性的請求（一般是提供If-Modified-Since頭表示客戶隻想比指定日期更新的文檔）。伺服器告訴客戶，原來緩沖的文檔還可以繼續使用。)

　　　　當使用者第一次請求index.html時，伺服器會添加一個名為Last-Modified響應頭，這個頭說明了index.html的最後修改時間，浏覽器會把index.html内容，以及最後響應時間緩存下來。當使用者第

 　　　　二次請求index.html時，在請求中包含一個名為If-Modified-Since請求頭，它的值就是第一次請求時伺服器通過Last-Modified響應頭發送給浏覽器的值，即index.html最後的修改時間，If-Modified-Since請求頭就是在告訴伺服器，我這裡浏覽器緩存的index.html最後修改時間是這個。

  　　　　您看看現在的index.html最後修改時間是不是這個，如果還是，那麼您就不用再響應這個index.html内容了，我會把緩存的内容直接顯示出來。而伺服器端會擷取If-Modified-Since值，與index.html的目前最後修改時間比對，如果相同，伺服器會發響應碼304，表示index.html與浏覽器上次緩存的相同，無需再次發送，浏覽器可以顯示自己的緩存頁面，如果比對不同，那麼說明index.html已經做了修改，伺服器會響應200。

網絡基礎知識 - HTTP協定

4.4　其他響應頭

告訴浏覽器不要緩存的響應頭：

  • Expires: -1；
  • Cache-Control: no-cache；
  • Pragma: no-cache；

自動重新整理響應頭，浏覽器會在3秒之後請求http://www.baidu.com：

  • Refresh: 3;url=http://www.baidu.com 

4.5　HTML中指定響應頭

　　　　在HTMl頁面中可以使用<meta http-equiv="" content="">來指定響應頭，例如在index.html頁面中給出<meta http-equiv="Refresh" content="3;url=http://www.baidu.com">，表示浏覽器隻會顯示index.html頁面3秒，然後自動跳轉到http://www.baidu.com.

4.6  示例

　　示範示例：

import socket


sock=socket.socket()
sock.bind(("127.0.0.1",8808))
sock.listen(5)

while 1:
    print("server waiting.....")
    conn,addr=sock.accept()
    data=conn.recv(1024)
    print("data",data)

    # 讀取html檔案
    with open("login.html","rb") as f:
        data=f.read()

    conn.send((b"HTTP/1.1 200 OK\r\n\r\n%s"%data))
    conn.close()

　　login.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>



<form action="" method="post">
    使用者名 <input type="text" name="user">
    密碼 <input type="password" name="pwd">
    <input type="submit">
</form>

</body>
</html>

五，HTTP協定特性

5.1 基于TCP/IP

　　HTTP協定是基于TCP/IP協定之上的應用層協定。

5.2  基于請求-響應模式

　　HTTP協定規定：請求從用戶端發出，最後伺服器端響應請求并傳回。換句話說，肯定是先從用戶端開始建立通信的，伺服器端在沒有接受到請求之前不會發送響應。

網絡基礎知識 - HTTP協定

5.3  無狀态儲存

　　HTTP是一種不儲存狀态，即無狀态（stateless）協定。HTTP協定自身不對請求和響應之間的通信狀态進行儲存。也就是說在HTTP這個級别，協定對于發送過的請求或響應都不做持久化處理。

網絡基礎知識 - HTTP協定

　　使用HTTP協定，每當有新的請求發送時，就會有對應的新響應産生。協定本身并不保留之前一切的請求或相應封包的資訊。這是為了更快的處理大量事務，確定協定的可伸縮性，而特意把HTTP協定設計成如此簡單的。可是，随着Web的不斷發展，因無狀态而導緻業務處理變得棘手的情況增多了。比如，使用者登入到一家購物網站，即使他跳轉到該站的其他頁面後，也需要能繼續保持登入狀态。針對這個執行個體，網站為了能夠掌握是誰送出的請求，需要儲存使用者的狀态。HTTP1.1雖然是無狀态協定，但是為了實作期望的保持狀态功能，于是引入了Cookie技術。有了Cookie再用HTTP協定通信,就可以管 理狀态了。

5.4  無連接配接

　　無連接配接的含義是限制每次連接配接隻處理一個請求。伺服器處理完客戶的請求，并收到客戶的應答後，即斷開連接配接。采用這種方式可以節省傳輸時間。

六，關于HTTP的常見問題及其解答

1.GET和POST的差別

　　A. 從字面意思和HTTP的規範來看，GET用于擷取資源資訊而POST是用來更新資源資訊。

　　B. GET送出請求的資料實體會放在URL的後面，用?來分割，參數用&連接配接，舉個栗子：/index.html?name=wang&login=1

　　C. GET送出的資料長度是有限制的，因為URL長度有限制，具體的長度限制視浏覽器而定。而POST沒有。

　　D. GET送出的資料不安全，因為參數都會暴露在URL上。

2.408 Request Timeout和504 Gateway Timeout的差別

　　408是說請求逾時，就是建立連接配接之後再約定的時間内用戶端沒有發送請求到用戶端到服務端。本質上原因在于用戶端或者網絡擁塞。504是網關逾時，是說代理伺服器把用戶端請求轉發到應用伺服器後再約定的時間内沒有收到應用伺服器的響應。本質上原因在于服務端的響應過慢，也有可能是網絡問題。

3.Cookie和Session的差別和聯系

　　Cookie和Session都是為了儲存用戶端和服務端之間的互動狀态，實作機制不同，各有優缺點。首先一個最大的差別就是Cookie是儲存在用戶端而Session就儲存在服務端的。Cookie是用戶端請求服務端時伺服器會将一些資訊以鍵值對的形式傳回給用戶端，儲存在浏覽器中，互動的時候可以加上這些Cookie值。用Cookie就可以友善的做一些緩存。Cookie的缺點是大小和數量都有限制；Cookie是存在用戶端的可能被禁用、删除、篡改，是不安全的；Cookie如果很大，每次要請求都要帶上，這樣就影響了傳輸效率。Session是基于Cookie來實作的，不同的是Session本身存在于服務端，但是每次傳輸的時候不會傳輸資料，隻是把代表一個用戶端的唯一ID（通常是JSESSIONID）寫在用戶端的Cookie中，這樣每次傳輸這個ID就可以了。Session的優勢就是傳輸資料量小，比較安全。但是Session也有缺點，就是如果Session不做特殊的處理容易失效、過期、丢失或者Session過多導緻伺服器記憶體溢出，并且要實作一個穩定可用安全的分布式Session架構也是有一定複雜度的。在實際使用中就要結合Cookie和Session的優缺點針對不同的問題來設計解決方案。

此處參考http://www.cnblogs.com/yuanchenqi/articles/6000358.html

https://www.cnblogs.com/ranyonsue/p/5984001.html

在這裡寫主要是自己鞏固複習，友善看到的盆友一起進步。

不經一番徹骨寒 怎得梅花撲鼻香

計算機網絡基礎知識
上一篇: 網絡基礎知識--子網劃分
下一篇: javaScript對金額處理的方式

繼續閱讀