HTTP基礎(chǔ)知識整理
超文本傳輸協(xié)議（HyperText Transfer Protocol，縮寫：HTTP）是一種用于分布式蛔琅、協(xié)作式和超媒體信息系統(tǒng)的應(yīng)用層協(xié)議胎许。HTTP是萬維網(wǎng)的數(shù)據(jù)通信的基礎(chǔ)。
[TOC]
協(xié)議概述
HTTP是一個客戶端終端（用戶）和服務(wù)器端（網(wǎng)站）請求和應(yīng)答的標(biāo)準(zhǔn)（TCP）罗售。通過使用網(wǎng)頁瀏覽器辜窑、網(wǎng)絡(luò)爬蟲或者其它的工具，客戶端發(fā)起一個HTTP請求到服務(wù)器上指定端口（默認(rèn)端口為80）寨躁。我們稱這個客戶端為用戶代理程序（user agent）穆碎。應(yīng)答的服務(wù)器上存儲著一些資源，比如HTML文件和圖像职恳。我們稱這個應(yīng)答服務(wù)器為源服務(wù)器（origin server）所禀。在用戶代理和源服務(wù)器中間可能存在多個“中間層”，比如代理服務(wù)器放钦、網(wǎng)關(guān)或者隧道（tunnel）色徘。
盡管TCP/IP協(xié)議是互聯(lián)網(wǎng)上最流行的應(yīng)用，HTTP協(xié)議中操禀，并沒有規(guī)定必須使用它或它支持的層褂策。事實上，HTTP可以在任何互聯(lián)網(wǎng)協(xié)議上床蜘，或其他網(wǎng)絡(luò)上實現(xiàn)辙培。HTTP假定其下層協(xié)議提供可靠的傳輸。因此邢锯，任何能夠提供這種保證的協(xié)議都可以被其使用扬蕊。目前廣泛的是使用TCP作為其傳輸層。
通常丹擎，由HTTP客戶端發(fā)起一個請求尾抑，創(chuàng)建一個到服務(wù)器指定端口（默認(rèn)是80端口）的TCP連接。HTTP服務(wù)器則在那個端口監(jiān)聽客戶端的請求蒂培。一旦收到請求再愈，服務(wù)器會向客戶端返回一個狀態(tài)，比如"HTTP/1.1 200 OK"护戳，以及返回的內(nèi)容翎冲，如請求的文件、錯誤消息媳荒、或者其它信息抗悍。
它是無連接驹饺、 無狀態(tài)的
協(xié)議格式
請求格式
|請求方法|空格|URL|協(xié)議版本|回車|換行| --請求行
|頭部字段名|:|字段內(nèi)容|回車|換行| --請求頭部
...
|回車|換行|
|請求數(shù)據(jù)|
如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
POST請求：
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
響應(yīng)格式
|協(xié)議版本|狀態(tài)碼|狀態(tài)消息|回車|換行| --請求行
|頭部字段名|:|字段內(nèi)容|回車|換行| --請求頭部
...
|回車|換行|
|響應(yīng)數(shù)據(jù)|
如GET請求響應(yīng)：
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>
URI 和 URL
URI
統(tǒng)一資源標(biāo)識符（英語：Uniform Resource Identifier，或URI）是一個用于標(biāo)識某一互聯(lián)網(wǎng)資源名稱的字符串缴渊。 該種標(biāo)識允許用戶對網(wǎng)絡(luò)中（一般指萬維網(wǎng)）的資源通過特定的協(xié)議進(jìn)行交互操作赏壹。URI的最常見的形式是統(tǒng)一資源定位符（URL），經(jīng)常指定為非正式的網(wǎng)址衔沼。更罕見的用法是統(tǒng)一資源名稱（URN）蝌借，其目的是通過提供一種途徑。用于在特定的名字空間資源的標(biāo)識指蚁，以補(bǔ)充網(wǎng)址菩佑。
URI可被視為定位符（URL），名稱（URN）或兩者兼?zhèn)淠＝y(tǒng)一資源名（URN）如同一個人的名稱擎鸠，而統(tǒng)一資源定位符（URL）代表一個人的住址。
它用來標(biāo)識資源的時候缘圈，可以是相對的劣光，也可以是絕對的，如：
- 絕對地址：
- 相對地址：
- /relative/URI/with/absolute/path/to/resource.txt
- ../../resource.txt
URL
統(tǒng)一資源定位符（或稱統(tǒng)一資源定位器/定位地址糟把、URL地址等绢涡，英語：Uniform Resource Locator，城卜瑁縮寫為URL）雄可，有時也被俗稱為網(wǎng)頁地址（網(wǎng)址）。
-
統(tǒng)一資源定位符的標(biāo)準(zhǔn)格式如下：
協(xié)議類型:[//服務(wù)器地址[:端口號]][/資源層級UNIX文件路徑]文件名[?查詢][#片段ID] -
統(tǒng)一資源定位符的完整格式如下：
協(xié)議類型:[//[訪問資源需要的憑證信息@]服務(wù)器地址[:端口號]][/資源層級UNIX文件路徑]文件名[?查詢][#片段ID]
其中[訪問憑證信息@ :端口號 ?查詢 #片段ID]都屬于選填項缠犀。
以http://zh.wikipedia.org/w/index.php?title=Special:%E9%9A%8F%E6%9C%BA%E9%A1%B5%E9%9D%A2 為例数苫，其中：
- 協(xié)議類型：http
- 服務(wù)器地址：zh.wikipedia.org
- 端口號：默認(rèn)80，省略不寫
- 文件路徑：w/index.php
- 查詢：title=Special:隨機(jī)頁面
請求方法
HTTP/1.1協(xié)議中共定義了八種方法（也叫“動作”）來以不同方式操作指定的資源：
GET :
向指定的資源發(fā)出“顯示”請求辨液。使用GET方法應(yīng)該只用在讀取數(shù)據(jù)虐急，而不應(yīng)當(dāng)被用于產(chǎn)生“副作用”的操作中，例如在Web Application中滔迈。其中一個原因是GET可能會被網(wǎng)絡(luò)蜘蛛等隨意訪問止吁。HEAD :
與GET方法一樣，都是向服務(wù)器發(fā)出指定資源的請求燎悍。只不過服務(wù)器不傳回資源的本文部分敬惦。它的好處在于，使用這個方法可以在不必傳輸全部內(nèi)容的情況下谈山，就可以獲取其中“關(guān)于該資源的信息”（元信息或稱元數(shù)據(jù)）俄删。POST :
向指定資源提交數(shù)據(jù)，請求服務(wù)器進(jìn)行處理（例如提交表單或者上傳文件）。數(shù)據(jù)被包含在請求本文中畴椰。這個請求可能會創(chuàng)建新的資源或修改現(xiàn)有資源举哟。PUT :
向指定資源位置上傳其最新內(nèi)容。DELETE :
請求服務(wù)器刪除Request-URI所標(biāo)識的資源迅矛。TRACE :
回顯服務(wù)器收到的請求，主要用于測試或診斷潜叛。OPTIONS :
這個方法可使服務(wù)器傳回該資源所支持的所有HTTP請求方法秽褒。用'*'來代替資源名稱，向Web服務(wù)器發(fā)送OPTIONS請求威兜，可以測試服務(wù)器功能是否正常運作销斟。CONNECT :
HTTP/1.1協(xié)議中預(yù)留給能夠?qū)⑦B接改為管道方式的代理服務(wù)器。通常用于SSL加密服務(wù)器的鏈接（經(jīng)由非加密的HTTP代理服務(wù)器）椒舵。
注意：前面的5個方法是常用的方法蚂踊，我們通常在瀏覽器中使用最多的就是 GET 和 POST 方法。
GET 和 POST 的區(qū)別（現(xiàn)象上的）
| 方法 | GET | POST |
|---|---|---|
| 后退按鈕/刷新 | 無害 | 數(shù)據(jù)會被重新提交（瀏覽器應(yīng)該告知用戶數(shù)據(jù)會被重新提交） |
| 書簽 | 可收藏為書簽 | 不可收藏為書簽 |
| 緩存 | 能被緩存 | 不能緩存 |
| 編碼類型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data,為二進(jìn)制數(shù)據(jù)使用多重編碼笔宿。 |
| 歷史 | 參數(shù)保留在瀏覽器歷史中 | 參數(shù)不會保存在瀏覽器歷史中 |
| 對數(shù)據(jù)長度的限制 | 當(dāng)發(fā)送數(shù)據(jù)時犁钟，GET 方法向 URL 添加數(shù)據(jù),URL 的長度是受限制的（URL 的最大長度是 2048 個字符） | 無限制 |
| 對數(shù)據(jù)類型的限制 | 只允許 ASCII 字符 | 沒有限制,也允許二進(jìn)制數(shù)據(jù) |
| 安全性 | 與 POST 相比，GET 的安全性較差泼橘，因為所發(fā)送的數(shù)據(jù)是 URL 的一部分涝动。在發(fā)送密碼或其他敏感信息時絕不要使用 GET ！ | POST 比 GET 更安全炬灭，因為參數(shù)不會被保存在瀏覽器歷史或 web 服務(wù)器日志醋粟。 |
| 可見性 | 數(shù)據(jù)在 URL 中對所有人都是可見的 | 數(shù)據(jù)不會顯示在 URL 。 |
冪等性
冪等性: 是系統(tǒng)的接口對外一種承諾（而不是實現(xiàn)）重归，承諾只要調(diào)用接口成功米愿，外部多次調(diào)用對系統(tǒng)的影響是一致的。
- 一個冪等的操作典型如：把編號為5的記錄的A字段設(shè)置為0鼻吮，這種操作不管執(zhí)行多少次都是冪等的育苟。
- 一個非冪等的操作典型如：把編號為5的記錄的A字段增加1，這種操作顯然就不是冪等的椎木。
針對HTTP的幾種方法宙搬，他們的冪等性如下所示：
GET：GET方法用于獲取資源，不應(yīng)有副作用拓哺，所以是冪等的勇垛。
POST：POST和PUT的區(qū)別容易被簡單地誤認(rèn)為“POST表示創(chuàng)建資源，PUT表示更新資源”士鸥；而實際上闲孤，二者均可用于創(chuàng)建資源，更為本質(zhì)的差別是在冪等性方面。POST所對應(yīng)的URI并非創(chuàng)建的資源本身讼积，而是資源的接收者肥照。比如：POST http://www.forum.com/articles 的語義是在http://www.forum.com/articles下創(chuàng)建一篇帖子，HTTP響應(yīng)中應(yīng)包含帖子的創(chuàng)建狀態(tài)以及帖子的URI勤众。兩次相同的POST請求會在服務(wù)器端創(chuàng)建兩份資源舆绎，它們具有不同的URI；所以们颜，POST方法不具備冪等性吕朵。
PUT：PUT所對應(yīng)的URI是要創(chuàng)建或更新的資源本身。比如：PUT http://www.forum/articles/4231 的語義是創(chuàng)建或更新ID為4231的帖子窥突。對同一URI進(jìn)行多次PUT的副作用和一次PUT是相同的努溃；因此，PUT方法具有冪等性阻问。
DELETE：DELETE方法用于刪除資源梧税，有副作用，但它應(yīng)該滿足冪等性称近。比如：DELETE http://www.forum.com/article/4231第队， 調(diào)用一次和N次對系統(tǒng)產(chǎn)生的副作用是相同的，即刪掉id為4231的帖子刨秆；因此斥铺，調(diào)用者可以多次調(diào)用或刷新頁面而不必?fù)?dān)心引起錯誤。
狀態(tài)碼
所有HTTP響應(yīng)的第一行都是狀態(tài)行坛善，依次是當(dāng)前HTTP版本號晾蜘，3位數(shù)字組成的狀態(tài)代碼，以及描述狀態(tài)的短語眠屎，彼此由空格分隔剔交。
狀態(tài)代碼的第一個數(shù)字代表當(dāng)前響應(yīng)的類型：
- 1xx 消息: 請求已被服務(wù)器接收也拜，繼續(xù)處理
- 2xx 成功: 請求已成功被服務(wù)器接收撒桨、理解胚股、并接受
- 3xx 重定向: 需要后續(xù)操作才能完成這一請求
- 4xx 請求錯誤: 請求含有詞法錯誤或者無法被執(zhí)行
- 5xx 服務(wù)器錯誤: 服務(wù)器在處理某個正確請求時發(fā)生錯誤
其中常用的狀態(tài)碼：
- 200： 請求成功
- 301： 重定向霜浴，代表永久性轉(zhuǎn)移(Permanently Moved)
- 301： 重定向，代表暫時性轉(zhuǎn)移(Temporarily Moved )
- 304： 表示資源未被修改棘脐，通常會被瀏覽器緩存而不用重新請求服務(wù)器
- 401： 未認(rèn)證恋沃，即用戶沒有必要的憑據(jù)
- 403： Forbidden裆熙，服務(wù)器已經(jīng)理解請求橄镜，但是拒絕執(zhí)行它
- 404： Not Found偎快，未找到該資源
- 500： Internal Server Error，服務(wù)端出錯
- 502： Bad Gateway洽胶，網(wǎng)關(guān)或者代理出錯超時
常連接
我們知道 HTTP 協(xié)議采用“請求-應(yīng)答”模式晒夹，當(dāng)使用普通模式，即非 Keep-Alive 模式時，每個請求/應(yīng)答客戶和服務(wù)器都要新建一個連接丐怯，完成之后立即斷開連接（HTTP 協(xié)議為無連接的協(xié)議）喷好；當(dāng)使用 Keep-Alive 模式（又稱持久連接、連接重用）時读跷，Keep-Alive 功能使客戶端到服務(wù)器端的連接持續(xù)有效梗搅，當(dāng)出現(xiàn)對服務(wù)器的后繼請求時，Keep-Alive 功能避免了建立或者重新建立連接效览。
在 HTTP 1.0 版本中无切，并沒有官方的標(biāo)準(zhǔn)來規(guī)定 Keep-Alive 如何工作，因此實際上它是被附加到 HTTP 1.0協(xié)議上钦铺，如果客戶端瀏覽器支持 Keep-Alive ，那么就在HTTP請求頭中添加一個字段 Connection: Keep-Alive肢预，當(dāng)服務(wù)器收到附帶有 Connection: Keep-Alive 的請求時矛洞，它也會在響應(yīng)頭中添加一個同樣的字段來使用 Keep-Alive 。這樣一來烫映，客戶端和服務(wù)器之間的HTTP連接就會被保持沼本，不會斷開（超過 Keep-Alive 規(guī)定的時間，意外斷電等情況除外）锭沟，當(dāng)客戶端發(fā)送另外一個請求時抽兆，就使用這條已經(jīng)建立的連接。
在 HTTP 1.1 版本中族淮，默認(rèn)情況下所有連接都被保持辫红，如果加入 "Connection: close" 才關(guān)閉。目前大部分瀏覽器都使用 HTTP 1.1 協(xié)議祝辣，也就是說默認(rèn)都會發(fā)起 Keep-Alive 的連接請求了贴妻，所以是否能完成一個完整的 Keep-Alive 連接就看服務(wù)器設(shè)置情況。
由于 HTTP 1.0 沒有官方的 Keep-Alive 規(guī)范蝙斜，并且也已經(jīng)基本被淘汰名惩，以下討論均是針對 HTTP 1.1 標(biāo)準(zhǔn)中的 Keep-Alive 展開的。
注意:
HTTP Keep-Alive 簡單說就是保持當(dāng)前的TCP連接孕荠，避免了重新建立連接娩鹉。
HTTP 常連接不可能一直保持，例如 Keep-Alive: timeout=5, max=100稚伍，表示這個TCP通道可以保持5秒弯予，max=100，表示這個常連接最多接收100次請求就斷開个曙。
HTTP 是一個無狀態(tài)協(xié)議熙涤，這意味著每個請求都是獨立的，Keep-Alive 沒能改變這個結(jié)果。另外祠挫，Keep-Alive也不能保證客戶端和服務(wù)器之間的連接一定是活躍的那槽，在 HTTP1.1 版本中也如此。唯一能保證的就是當(dāng)連接被關(guān)閉時你能得到一個通知等舔，所以不應(yīng)該讓程序依賴于 Keep-Alive 的保持連接特性骚灸，否則會有意想不到的后果。
使用常連接之后慌植，客戶端甚牲、服務(wù)端怎么知道本次傳輸結(jié)束呢？兩部分：1. 判斷傳輸數(shù)據(jù)是否達(dá)到了Content-Length 指示的大械痢丈钙；2. 動態(tài)生成的文件沒有 Content-Length ，它是分塊傳輸（chunked）交汤，這時候就要根據(jù) chunked 編碼來判斷雏赦，chunked 編碼的數(shù)據(jù)在最后有一個空 chunked 塊，表明本次傳輸數(shù)據(jù)結(jié)束.
Transfer-Encoding
Transfer-Encoding 是一個用來標(biāo)示 HTTP 報文傳輸格式的頭部值芙扎。盡管這個取值理論上可以有很多星岗，但是當(dāng)前的 HTTP 規(guī)范里實際上之定義了一種傳輸取值——chunked。
如果一個HTTP消息（請求消息或應(yīng)答消息）的Transfer-Encoding消息頭的值為chunked戒洼，那么俏橘，消息體由數(shù)量未定的塊組成，并以最后一個大小為0的塊為結(jié)束圈浇。
每一個非空的塊都以該塊包含數(shù)據(jù)的字節(jié)數(shù)（字節(jié)數(shù)以十六進(jìn)制表示）開始寥掐，跟隨一個CRLF （回車及換行），然后是數(shù)據(jù)本身磷蜀，最后塊CRLF結(jié)束曹仗。在一些實現(xiàn)中，塊大小和CRLF之間填充有白空格（0x20）蠕搜。
最后一塊是單行怎茫，由塊大小（0）妓灌，一些可選的填充白空格轨蛤，以及CRLF。最后一塊不再包含任何數(shù)據(jù)虫埂，但是可以發(fā)送可選的尾部祥山，包括消息頭字段。消息最后以CRLF結(jié)尾掉伏。
一個示例響應(yīng)如下：
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25
This is the data in the first chunk
1A
and this is the second one
0
注意：
chunked 和 multipart 兩個名詞在意義上有類似的地方缝呕，不過在 HTTP 協(xié)議當(dāng)中這兩個概念則不是一個類別的澳窑。multipart 是一種 Content-Type，標(biāo)示 HTTP 報文內(nèi)容的類型供常，而 chunked 是一種傳輸格式摊聋，標(biāo)示報頭將以何種方式進(jìn)行傳輸。
chunked 傳輸不能事先知道內(nèi)容的長度栈暇，只能靠最后的空 chunk 塊來判斷麻裁，因此對于下載請求來說，是沒有辦法實現(xiàn)進(jìn)度的源祈。在瀏覽器和下載工具中煎源，偶爾我們也會看到有些文件是看不到下載進(jìn)度的，即采用 chunked 方式進(jìn)行下載香缺。
chunked 的優(yōu)勢在于手销，服務(wù)器端可以邊生成內(nèi)容邊發(fā)送，無需事先生成全部的內(nèi)容图张。HTTP/2 不支持 Transfer-Encoding: chunked锋拖，因為 HTTP/2 有自己的 streaming 傳輸方式。
HTTP Pipelining（HTTP 管線化）
默認(rèn)情況下 HTTP 協(xié)議中每個傳輸層連接只能承載一個 HTTP 請求和響應(yīng)埂淮，瀏覽器會在收到上一個請求的響應(yīng)之后姑隅，再發(fā)送下一個請求写隶。在使用持久連接的情況下倔撞，某個連接上消息的傳遞類似于請求1 -> 響應(yīng)1 -> 請求2 -> 響應(yīng)2 -> 請求3 -> 響應(yīng)3。
HTTP Pipelining（管線化）是將多個 HTTP 請求整批提交的技術(shù)慕趴，在傳送過程中不需等待服務(wù)端的回應(yīng)痪蝇。使用 HTTP Pipelining 技術(shù)之后，某個連接上的消息變成了類似這樣請求1 -> 請求2 -> 請求3 -> 響應(yīng)1 -> 響應(yīng)2 -> 響應(yīng)3冕房。
注意：
- 管線化機(jī)制通過持久連接（persistent connection）完成躏啰，僅 HTTP/1.1 支持此技術(shù)（HTTP/1.0不支持）
- 只有 GET 和 HEAD 請求可以進(jìn)行管線化，而 POST 則有所限制
初次創(chuàng)建連接時不應(yīng)啟動管線機(jī)制耙册，因為對方（服務(wù)器）不一定支持 HTTP/1.1 版本的協(xié)議 - 管線化不會影響響應(yīng)到來的順序给僵，如上面的例子所示，響應(yīng)返回的順序并未改變
- HTTP /1.1 要求服務(wù)器端支持管線化详拙，但并不要求服務(wù)器端也對響應(yīng)進(jìn)行管線化處理帝际，只是要求對于管線化的請求不失敗即可
- 由于上面提到的服務(wù)器端問題，開啟管線化很可能并不會帶來大幅度的性能提升饶辙，而且很多服務(wù)器端和代理程序?qū)芫€化的支持并不好蹲诀，因此現(xiàn)代瀏覽器如 Chrome 和 Firefox 默認(rèn)并未開啟管線化支持。
會話跟蹤
Q：什么是會話弃揽？
A：客戶端打開與服務(wù)器的連接發(fā)出請求到服務(wù)器響應(yīng)客戶端請求的全過程稱之為會話脯爪。
Q: 什么是會話跟蹤则北？
A: 會話跟蹤指的是對同一個用戶對服務(wù)器的連續(xù)的請求和接受響應(yīng)的監(jiān)視。
Q: 為什么需要會話跟蹤痕慢？
A: 瀏覽器與服務(wù)器之間的通信是通過HTTP協(xié)議進(jìn)行通信的尚揣，而HTTP協(xié)議是”無狀態(tài)”的協(xié)議，它不能保存客戶的信息守屉，即一次響應(yīng)完成之后連接就斷開了惑艇，下一次的請求需要重新連接，這樣就需要判斷是否是同一個用戶拇泛，所以才有會話跟蹤技術(shù)來實現(xiàn)這種要求滨巴。
會話跟蹤常用的方法
URL重寫
URL(統(tǒng)一資源定位符)是Web上特定頁面的地址，URL重寫的技術(shù)就是在URL結(jié)尾添加一個附加數(shù)據(jù)以標(biāo)識該會話,把會話ID通過URL的信息傳遞過去俺叭，以便在服務(wù)器端進(jìn)行識別不同的用戶恭取。
隱藏表單域
將會話ID添加到HTML表單元素中提交到服務(wù)器，此表單元素并不在客戶端顯示
Cookie
Cookie是Web服務(wù)器發(fā)送給客戶端的一小段信息熄守，客戶端請求時可以讀取該信息發(fā)送到服務(wù)器端蜈垮，進(jìn)而進(jìn)行用戶的識別。對于客戶端的每次請求裕照，服務(wù)器都會將Cookie發(fā)送到客戶端,在客戶端可以進(jìn)行保存,以便下次使用攒发。
客戶端可以采用兩種方式來保存這個Cookie對象，一種方式是保存在客戶端內(nèi)存中晋南，稱為臨時Cookie惠猿，瀏覽器關(guān)閉后這個Cookie對象將消失。另外一種方式是保存在客戶機(jī)的磁盤上负间，稱為永久Cookie偶妖。以后客戶端只要訪問該網(wǎng)站，就會將這個Cookie再次發(fā)送到服務(wù)器上政溃，前提是這個Cookie在有效期內(nèi)趾访，這樣就實現(xiàn)了對客戶的跟蹤。
Cookie是可以被禁止的董虱。
Session
每一個用戶都有一個不同的session扼鞋，各個用戶之間是不能共享的，是每個用戶所獨享的愤诱，在session中可以存放信息云头。
在服務(wù)器端會創(chuàng)建一個session對象，產(chǎn)生一個sessionID來標(biāo)識這個session對象转锈，然后將這個sessionID放入到Cookie中發(fā)送到客戶端盘寡，下一次訪問時，sessionID會發(fā)送到服務(wù)器撮慨，在服務(wù)器端進(jìn)行識別不同的用戶竿痰。
Session的實現(xiàn)依賴于Cookie脆粥，如果Cookie被禁用，那么session也將失效影涉。
課后問題：實現(xiàn)一個短連接分發(fā)器
