一、TCP/IP四層模型和OSI七層模型的概念
TCP/IP四層模型
TCP/IP是一組協議的代名詞，它還包括許多協議，組成了TCP/IP協議簇。ISO制定的OSI參考模型的過於龐大、複雜招致了許多批評。與此對照，由技術人員自己開發的TCP/IP協議棧獲得了更爲廣泛的應用。
TCP/IP通訊協議採用了4層的層級結構，每一層都呼叫它的下一層所提供的網絡來完成自己的需求。這4層分別爲：
1、應用層：應用程序間溝通的層，如簡單電子郵件傳輸（SMTP）、文件傳輸協議（FTP）、網絡遠程訪問協議（Telnet）等。
2、傳輸層：在此層中，它提供了端到端的數據傳送服務，如傳輸控制協議（TCP）、用戶數據報協議（UDP）等。TCP協議是一個面向連接的、可靠的協議。它將一臺主機發出的字節流無差錯地發往互聯網上的其他主機。在發送端，它負責把上層傳送下來的字節流分成報文段並傳遞給下層。在接收端，它負責把收到的報文進行重組後遞交給上層。TCP協議還要處理端到端的流量控制，以避免緩慢接收的接收方沒有足夠的緩衝區接收發送方發送的大量數據。UDP協議是一個不可靠的、無連接協議，主要適用於不需要對報文進行排序和流量控制的場合。
3、網絡互連層：負責提供基本的數據包傳送功能，讓每一塊數據包都能夠到達目的主機（但不檢查是否被正確接收），如網際協議（IP）。網絡互連層除了需要完成路由的功能外，也可以完成將不同類型的網絡（異構網）互連的任務。除此之外，網絡互連層還需要完成擁塞控制的功能。
4、網絡接口層：對實際的網絡媒體的管理，定義如何使用實際網絡（如Ethernet、Serial Line等）來傳送數據。只是要求能夠提供給其上層-網絡互連層一個訪問接口，以便在其上傳遞IP分組。
OSI七層模型
OSI（Open System Interconnection，開放系統互連）七層網絡模型稱爲開放式系統互聯參考模型 ，是一個邏輯上的定義，一個規範，它把網絡從邏輯上分爲了7層。每一層都有相關、相對應的物理設備，比如路由器，交換機。OSI 七層模型是一種框架性的設計方法 ，建立七層模型的主要目的是爲解決異種網絡互連時所遇到的兼容性問題，其最主要的功能使就是幫助不同類型的主機實現數據傳輸。它的最大優點是將服務、接口和協議這三個概念明確地區分開來，通過七個層次化的結構模型使不同的系統不同的網絡之間實現可靠的通訊。
1、物理層：主要定義物理設備標準，如網線的接口類型、光纖的接口類型、各種傳輸介質的傳輸速率等。它的主要作用是傳輸比特流（就是由1、0轉化爲電流強弱來進行傳輸,到達目的地後在轉化爲1、0，也就是我們常說的數模轉換與模數轉換）。這一層的數據叫做比特。
2、數據鏈路層：它控制網絡層與物理層之間的通信。它的主要功能是如何在不可靠的物理線路上進行數據的可靠傳遞。爲了保證傳輸，從網絡層接收到的數據被分割成特定的可被物理層傳輸的幀。幀是用來移動數據的結構包，它不僅包括原始數據，還包括髮送方和接收方的物理地址以及檢錯和控制信息。其中的地址確定了幀將發送到何處，而糾錯和控制信息則確保幀無差錯到達。。在物理層提供比特流服務的基礎上，建立相鄰結點之間的數據鏈路，通過差錯控制提供數據幀（Frame）在信道上無差錯的傳輸。數據幀。
3、網絡層：在位於不同地理位置的網絡中的兩個主機系統之間提供連接和路徑選擇。Internet的發展使得從世界各站點訪問信息的用戶數大大增加，而網絡層正是管理這種連接的層。 數據包/數據報。
4、傳輸層：定義了一些傳輸數據的協議和端口號（WWW端口80等），如：TCP（傳輸控制協議，傳輸效率低，可靠性強，用於傳輸可靠性要求高，數據量大的數據），UDP（用戶數據報協議，與TCP特性恰恰相反，用於傳輸可靠性要求不高，數據量小的數據，如QQ聊天數據就是通過這種方式傳輸的）。 主要是將從上層接收的數據進行分段和傳輸，到達目的地址後再進行重組。報文段。
5、會話層：通過傳輸層（端口號：傳輸端口與接收端口）建立數據傳輸的通路。主要在你的系統之間發起會話或者接受會話請求（設備之間需要互相認識可以是IP也可以是MAC或者是主機名）
6、表示層：可確保一個系統的應用層所發送的信息可以被另一個系統的應用層讀取；對數據進行翻譯、加密和壓縮。例如，PC程序與另一臺計算機進行通信，其中一臺計算機使用擴展二一十進制交換碼（EBCDIC），而另一臺則使用美國信息交換標準碼（ASCII）來表示相同的字符。如有必要，表示層會通過使用一種通格式來實現多種數據格式之間的轉換。
7、應用層： 是最靠近用戶的OSI層。這一層爲用戶的應用程序（例如電子郵件、文件傳輸和終端仿真）提供網絡服務。
二、TCP/IP報文格式
IP報文格式
●版本（Version）字段：佔4比特。用來表明IP協議實現的版本號，當前一般爲IPv4，即0100。
●報頭長度（Internet Header Length，IHL）字段：佔4比特。是頭部佔32比特的數字，包括可選項。普通IP數據報（沒有任何選項），該字段的值是5，即160比特=20字節。此字段最大值爲60字節。
●服務類型（Type of Service ，TOS）字段：佔8比特。其中前3比特爲優先權子字段（Precedence，現已被忽略）。第8比特保留未用。第4至第7比特分別代表延遲、吞吐量、可靠性和花費。當它們取值爲1時分別代表要求最小時延、最大吞吐量、最高可靠性和最小費用。這4比特的服務類型中只能置其中1比特爲1。可以全爲0，若全爲0則表示一般服務。服務類型字段聲明瞭數據報被網絡系統傳輸時可以被怎樣處理。例如：TELNET協議可能要求有最小的延遲，FTP協議（數據）可能要求有最大吞吐量，SNMP協議可能要求有最高可靠性，NNTP（Network News Transfer Protocol，網絡新聞傳輸協議）可能要求最小費用，而ICMP協議可能無特殊要求（4比特全爲0）。實際上，大部分主機會忽略這個字段，但一些動態路由協議如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根據這些字段的值進行路由決策。
●總長度字段：佔16比特。指明整個數據包的長度（以字節爲單位）。最大長度爲65535字節。而數據鏈路只允許1500字節，所以一般都需要MTU分片。
●標識字段：佔16比特。用來唯一標識主機發送的每一份數據包。通常每發一份報文，它的值會加1。
●標誌位字段：佔3比特。標誌一份數據包是否要求分片。
●段偏移字段：佔13比特。如果一份數據包要求分片的話，此字段指明該段偏移距原始數據包開始的位置。
發送方會在IP層將要發送的數據分成多個數據包分批發送，而接收方則將數據按照順序再從新組織起來，等接收到一個完整的數據報之後，然後再提交給上一層傳輸層。
TCP協議爲可靠的傳輸協議，它避免了IP分片的發生，它會在TCP層對數據進行處理，對數據進行分段(不在詳述)，IP分片用的多的在UDP協議(如果分片的話，中間的包沒有UDP頭部，即0字節)。
●生存期（TTL：Time to Live）字段：佔8比特。用來設置數據報最多可以經過的路由器數。由發送數據的源主機設置，通常爲32、64、128等。每經過一個路由器，其值減1，直到0時該數據報被丟棄。
●協議字段：佔8比特。指明IP層所封裝的上層協議類型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等。
●頭部校驗和字段：佔16比特。內容是根據IP頭部計算得到的校驗和碼。計算方法是：對頭部中每個16比特進行二進制反碼求和。（和ICMP、IGMP、TCP、UDP不同，IP不對頭部後的數據進行校驗）。
●源IP地址、目標IP地址字段：各佔32比特。用來標明發送IP數據報文的源主機地址和接收IP報文的目標主機地址。
●可選項字段：佔32比特。用來定義一些任選項：如記錄路徑、時間戳等。這些選項很少被使用，同時並不是所有主機和路由器都支持這些選項。可選項字段的長度必須是32比特的整數倍，如果不足，必須填充0以達到此長度要求。
TCP數據段格式
TCP是一種可靠的、面向連接的字節流服務。源主機在傳送數據前需要先和目標主機建立連接。然後，在此連接上，被編號的數據段按序收發。同時，要求對每個數據段進行確認，保證了可靠性。如果在指定的時間內沒有收到目標主機對所發數據段的確認，源主機將再次發送該數據段。
●源、目標端口號字段：佔16比特。TCP協議通過使用”端口”來標識源端和目標端的應用進程。端口號可以使用0到65535之間的任何數字。在收到服務請求時，操作系統動態地爲客戶端的應用程序分配端口號。在服務器端，每種服務在”衆所周知的端口”（Well-Know Port）爲用戶提供服務。
●序號字段：佔32比特。用來標識從TCP源端向TCP目標端發送的數據字節流，它表示在這個報文段中的第一個數據字節的序號。
●確認號字段：佔32比特。只有ACK標誌爲1時，確認號字段纔有效。它包含目標端所期望收到源端的下一個報文段的數據的第一個字節的序號。
●頭部長度字段：佔4比特。給出頭部佔32比特的數目。沒有任何選項字段的TCP頭部長度爲20字節；最多可以有60字節的TCP頭部。
●標誌位字段（U、A、P、R、S、F）：佔6比特。各比特的含義如下：
◆URG：緊急指針（urgent pointer）有效。
◆確認位ACK：確認序號有效。
◆PSH：接收方應該儘快將這個報文段交給應用層。
◆RST：重建連接。
◆同步位SYN：發起一個連接。
◆終止位FIN：釋放一個連接。
●窗口大小字段：佔16比特。此字段用來進行流量控制。單位爲字節數，這個值是本機期望一次接收的字節數。
●TCP校驗和字段：佔16比特。對整個TCP報文段，即TCP頭部和TCP數據進行校驗和計算，並由目標端進行驗證。
●緊急指針字段：佔16比特。它是一個偏移量，和序號字段中的值相加表示緊急數據最後一個字節的序號。
●選項字段：佔32比特。可能包括”窗口擴大因子”、”時間戳”等選項。
UDP數據段格式
UDP是一種不可靠的、無連接的數據報服務。源主機在傳送數據前不需要和目標主機建立連接。數據被冠以源、目標端口號等UDP報頭字段後直接發往目的主機。這時，每個數據段的可靠性依靠上層協議來保證。在傳送數據較少、較小的情況下，UDP比TCP更加高效。
三、TCP的三次握手和四次揮手
TCP建立連接的三次握手過程
三次握手：
A:“喂，你聽得到嗎？”A->SYN_SEND
B:“我聽得到呀，你聽得到我嗎？”應答與請求同時發出 B->SYN_RCVD | A->ESTABLISHED
A:“我能聽到你，今天balabala……”B->ESTABLISHED
●源主機發送一個同步標誌位（SYN）置1的TCP數據段。此段中同時標明初始序號（Initial Sequence Number，ISN）。ISN是一個隨時間變化的隨機值x。然後客戶端進入SYN_SEND狀態，等待服務器的確認響應。
●目標主機發回確認數據段，此段中的同步標誌位（SYN）同樣被置1，且確認標誌位（ACK）也置1，同時在確認序號字段表明目標主機期待收到源主機下一個數據段的序號x+1（即表明前一個數據段已收到並且沒有錯誤）。此外，此段中還包含目標主機的段初始序號y。此時服務器進入SYN_RECV狀態。
●源主機再回送一個數據段，同樣帶有遞增的發送序號和確認序號。發送完成後，客戶端和服務器端都進入ESTABLISHED狀態。
至此爲止，TCP會話的三次握手完成。接下來，源主機和目標主機可以互相收發數據。
爲什麼需要“三次握手”
在謝希仁著《計算機網絡》第四版中講“三次握手”的目的是“爲了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤”。在另一部經典的《計算機網絡》一書中講“三次握手”的目的是爲了解決“網絡中存在延遲的重複分組”的問題。這兩種不用的表述其實闡明的是同一個問題。
謝希仁版《計算機網絡》中的例子是這樣的，“已失效的連接請求報文段”的產生在這樣一種情況下：client發出的第一個連接請求報文段並沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以後的某個時間纔到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段後，就誤認爲是client再次發出的一個新的連接請求。於是就向client發出確認報文段，同意建立連接。假設不採用“三次握手”，那麼只要server發出確認，新的連接就建立了。由於現在client並沒有發出建立連接的請求，因此不會理睬server的確認，也不會向server發送數據。但server卻以爲新的運輸連接已經建立，並一直等待client發來數據。這樣，server的很多資源就白白浪費掉了。採用“三次握手”的辦法可以防止上述現象發生。例如剛纔那種情況，client不會向server的確認發出確認。server由於收不到確認，就知道client並沒有要求建立連接。主要目的防止server端一直等待，浪費資源。
TCP釋放連接的四次握手過程
第一次揮手：客戶端打算關閉連接，就向其TCP發送一個連接釋放報文段，並停止再發送數據，主動關閉TCP連接，該報文的FIN標誌位爲1，seq=u(等於前面已經發送過去的數據的最後一個字節的序號加一)。客戶端進入FIN_WAIT_1狀態，即告訴服務端沒有數據需要傳輸了，請求關閉連接。
第二次揮手：服務端收到FIN包後，發送一個ACK給對方，確認序號爲收到序號+1，即u+1，該報文段自己的序號是v，此時TCP連接就處於半關閉狀態，從客戶端到服務端的連接已經釋放。（與SYN相同，一個FIN佔用一個序號）。應答客戶端你的請求我收到了，但是我還沒準備好，請等待我的關閉請求。客戶端收到後進入FIN_WAIT_2狀態。
第三次揮手：若服務器已經沒有要向客戶端發送的數據，就通知TCP釋放連接，此時它就發送FIN=1的連接釋放報文段，seq=w,ack=u+1。服務器進入LAST_ACK狀態。
第四次揮手：客戶端收到FIN後，發送一個ACK給被動關閉方，確認序號爲收到序號+1，seq=u+1,ack=w+1。至此，完成四次揮手。客戶端收到服務端的FIN報文段後，向服務端應答一個Acknowledgment Number爲Sequence Number+1的ACK報文段，然後客戶端進入TIME_WAIT狀態；服務端收到客戶端的ACK報文段後關閉連接進入CLOSED狀態，客戶端等待2MSL後依然沒有收到回覆，則證明服務端已正常關閉，客戶端此時關閉連接進入CLOSED狀態。
1、當主機A確認發送完數據且知道B已經接受完了，想要關閉發送數據口（當然確認信號還是可以發），就會發FIN給主機B。
2、主機B收到A發送的FIN，表示收到了，就會發送ACK回覆。
3、但這是B可能還在發送數據，沒有想要關閉數據口的意思，所以FIN與ACK不是同時發送的，而是等到B數據發送完了，纔會發送FIN給主機A。
4、A收到B發來的FIN，知道B的數據也發送完了，回覆ACK，B收到ACK後關閉鏈接； A等待2MSL以後，沒有收到B傳來的任何消息，知道B已經收到自己的ACK了，A就關閉鏈接。
四次揮手時爲什麼要等待2MSL？
和TCP三次同步握手不一樣的是，TCP關閉連接用四次握手來實現，即A—>B Fin, B—>A ACK, B—>A Fin, A—>B ACK，爲什麼要這樣？
A—>B Fin, B—>A ACK ，A屬於主動關閉方，收到B的ACK後，A到B的方向連接關閉，即half shutown ，這時A不能再發送數據了。
這種狀態下B還是可以單向發送數據的，B的數據發送完畢，也做關閉動作了：
B—>A Fin, A—>B ACK
B收到ACK，關閉連接。但是A無法知道ACK是否已經到達B，於是開始等待？等待什麼呢？假如ACK沒有到達B，B會爲FIN這個消息超時重傳 timeout retransmit ，那如果A等待時間足夠，又收到FIN消息，說明ACK沒有到達B，於是再發送ACK，直到在足夠的時間內沒有收到FIN，說明ACK成功到達。這個等待時間至少是：B的timeout + FIN的傳輸時間，爲了保證可靠，採用更加保守的等待時間2MSL。
四、HTTP請求報文和HTTP響應報文
HTTP報文是面向文本的，報文中的每一個字段都是一些ASCII碼串，各個字段的長度是不確定的。HTTP有兩類報文：請求報文和響應報文。
HTTP請求報文
一個HTTP請求報文由請求行（request line）、請求頭部（header）、空行和請求數據4個部分組成，下圖給出了請求報文的一般格式。
1.請求行
請求行由請求方法字段、URL字段和HTTP協議版本字段3個字段組成，它們用空格分隔。例如，GET /index.html HTTP/1.1。
HTTP協議的請求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
而常見的有如下幾種：
1).GET
可以看到，GET方式的請求一般不包含”請求內容”部分，請求數據以地址的形式表現在請求行。
地址中”?”之後的部分就是通過GET發送的請求數據，我們可以在地址欄中清楚的看到，各個數據之間用”&”符號隔開。顯然，這種方式不適合傳送私密數據。另外，由於不同的瀏覽器對地址的字符限制也有所不同，一般最多隻能識別1024個字符，所以如果需要傳送大量數據的時候，也不適合使用GET方式。
2).POST
對於上面提到的不適合使用GET方式的情況，可以考慮使用POST方式，因爲使用POST方法可以允許客戶端給服務器提供信息較多。POST方法將請求參數封裝在HTTP請求數據中，以名稱/值的形式出現，可以傳輸大量數據，這樣POST方式對傳送的數據大小沒有限制，而且也不會顯示在URL中。
可以看到，POST方式請求行中不包含數據字符串，這些數據保存在”請求內容”部分，各數據之間也是使用”&”符號隔開。POST方式大多用於頁面的表單中。
3).HEAD
HEAD就像GET，只不過服務端接受到HEAD請求後只返回響應頭，而不會發送響應內容。當我們只需要查看某個頁面的狀態的時候，使用HEAD是非常高效的，因爲在傳輸的過程中省去了頁面內容。
2.請求頭部
請求頭部由關鍵字/值對組成，每行一對，關鍵字和值用英文冒號“:”分隔。請求頭部通知服務器有關於客戶端請求的信息。
3.空行
最後一個請求頭之後是一個空行，發送回車符和換行符，通知服務器以下不再有請求頭。
4.請求數據
請求數據不在GET方法中使用，而是在POST方法中使用。POST方法適用於需要客戶填寫表單的場合。與請求數據相關的最常使用的請求頭是Content-Type和Content-Length。
HTTP響應報文
HTTP響應也由三個部分組成，分別是：狀態行、消息報頭、響應正文。
在響應第一行中用狀態行信息代替了請求行信息。狀態行（status line）通過提供一個狀態碼來說明所請求的資源情況。
狀態行格式如下：
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示服務器HTTP協議的版本；Status-Code表示服務器發回的響應狀態代碼；Reason-Phrase表示狀態代碼的文本描述。狀態代碼由三位數字組成，第一個數字定義了響應的類別，且有五種可能取值。
1xx：指示信息–表示請求已接收，繼續處理。
2xx：成功–表示請求已被成功接收、理解、接受。
3xx：重定向–要完成請求必須進行更進一步的操作。
301：永久性轉移，第一次轉移之後，瀏覽器會記錄轉移情況，下次再次請求就會直接向服務器請求
302：臨時轉移4xx：客戶端錯誤–請求有語法錯誤或請求無法實現。
5xx：服務器端錯誤–服務器未能實現合法的請求。
常見狀態代碼、狀態描述的說明如下。
200 OK：客戶端請求成功。
400 Bad Request：客戶端請求有語法錯誤，不能被服務器所理解。
401 Unauthorized：請求未經授權，這個狀態代碼必須和WWW-Authenticate報頭域一起使用。
403 Forbidden：服務器收到請求，但是拒絕提供服務。
404 Not Found：請求資源不存在，舉個例子：輸入了錯誤的URL。
500 Internal Server Error：服務器發生不可預期的錯誤。
503 Server Unavailable：服務器當前不能處理客戶端的請求，一段時間後可能恢復正常，舉個例子：HTTP/1.1 200 OK（CRLF）。
五、HTTP中Get與Post的區別
1、Get是最常用的方法，通常用於請求服務器發送某個資源。
2、HEAD方法與GET方法的行爲很類似，但服務器在響應中只返回實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查，使用HEAD，我們可以更高效的完成以下工作：
在不獲取資源的情況下，瞭解資源的一些信息，比如資源類型；
通過查看響應中的狀態碼，可以確定資源是否存在；
通過查看首部，測試資源是否被修改。
3、PUT方法是讓服務器用請求的主體部分來創建一個由所請求的URL命名的新文檔；如果那個文檔存在的話，就用這個主體來代替它。
4、POST方法向服務器提交數據，比如完成表單數據的提交，將數據提交給服務器處理。
5、TRACE方法會在目的服務器端發起一個“迴環”診斷，我們都知道，客戶端在發起一個請求時，這個請求可能要穿過防火牆、代理、網關、或者其它的一些應用程序。這中間的每個節點都可能會修改原始的HTTP請求，TRACE方法允許客戶端在最終將請求發送服務器時，它變成了什麼樣子。由於有一個“迴環”診斷，在請求最終到達服務器時，服務器會彈回一條TRACE響應，並在響應主體中攜帶它收到的原始請求報文的最終模樣。這樣客戶端就可以查看HTTP請求報文在發送的途中，是否被修改過了。
6、OPTIONS方法用於獲取當前URL所支持的方法。若請求成功，則它會在HTTP頭中包含一個名爲“Allow”的頭，值是所支持的方法，如“GET, POST”。
7、DELETE方法就是請求服務器刪除指定URL所對應的資源。但是，客戶端無法保證刪除操作一定會被執行，因爲HTTP規範允許服務器在不通知客戶端的情況下撤銷請求。
- 誤區一：POST可以比GET提交更多更長的數據？
由於使用GET方法提交數據時，數據會以&符號作爲分隔符的形式，在URL後面添加需要提交的參數，有人就會說了，瀏覽器地址欄輸入的參數是有限的，而POST不用再地址欄輸入，所以POST就比GET可以提交更多的數據。難道真的是這樣的麼？
而實際上，**URL不存在參數上限的問題，HTTP協議規範沒有對URL長度進行限制。這個限制是特定的瀏覽器及服務器對它的限制。**IE對URL長度的限制是2083字節(2K+35)。對於其他瀏覽器，如Netscape、FireFox等，理論上沒有長度限制，其限制取決於操作系統的支持。
同時，POST是沒有大小限制的，HTTP協議規範也沒有進行大小限制。POST數據是沒有限制的，起限制作用的是服務器的處理程序的處理能力。
總歸一句話，這個限制是針對所有HTTP請求的，與GET、POST沒有多少關係。 - 誤區二：POST比GET安全？
首先，我們要承認安全的概念有很多種，要是從最基本的肉眼看到就不安全，肉眼看不到那就是安全的概念說呢，GET確實沒有POST安全，畢竟小白用戶確實可以看到在URL中帶有的數據信息，這個你無法狡辯。那麼要是往嚴謹了說呢，POST是不是要比GET安全呢？其實不是的。
上面也說了，GET將提交到服務器的數據添加到URL中了，可見；雖然POST的數據，你肉眼看不到，你抓個包看看，在HTTP包的包體中，我們提交的數據時仍然可見的；所以說，從這方面來說，POST也是以五十步笑百步了。
六、HTTP和HTTPS區別
http://www.mahaixiang.cn/internet/1233.html
HTTPS工作原理
七、cookie 和session 的區別
當你在瀏覽網站的時候，WEB 服務器會發送一些小資料放在你的計算機上，Cookie 會把你在網站上所打的文字或是一些選擇，都紀錄下來。當下次你再光臨同一個網站，WEB 服務器會先看看有沒有它上次留下的 Cookie 資料，有的話，就會依據 Cookie裏的內容來判斷使用者，送出特定的網頁內容給你。 Cookie 的使用很普遍，許多有提供個人化服務的網站，都是利用 Cookie來辨認使用者，以方便送出使用者量身定做的內容，像是 Web 接口的免費 email 網站，都要用到 Cookie。
具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。
同時我們也看到，由於採用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上它還有其他選擇。
cookie機制
正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示(Set-Cookie:now=23)以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由瀏覽器按照一定的原則在後臺自動發送給服務器的。瀏覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。
cookie的內容主要包括：名字，值，過期時間，路徑和域。路徑與域一起構成cookie的作用範圍。若不設置過期時間，則表示這個cookie的生命期爲瀏覽器會話期間，關閉瀏覽器窗口，cookie就消失。這種生命期爲瀏覽器會話期的cookie被稱爲會話cookie。
會話cookie一般不存儲在硬盤上而是保存在內存裏，當然這種行爲並不是規範規定的。若設置了過期時間，瀏覽器就會把cookie保存到硬盤上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進程間共享，比如兩個IE窗口。而對於保存在內存裏的cookie，不同的瀏覽器有不同的處理方式。
session機制
session機制是一種服務器端的機制，服務器使用一種類似於散列表的結構（也可能就是使用散列表）來保存信息。當程序需要爲某個客戶端的請求創建一個session時，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識（稱爲session id），如果已包含則說明以前已經爲此客戶端創建過session，服務器就按照session id把這個session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含session id，則爲此客戶端創建一個session並且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個session id將被在本次響應中返回給客戶端保存。保存這個session id的方式可以採用cookie，這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發送給服務器。一般這個cookie的名字都是類似於JSESSIONID。
但cookie可以被人爲的禁止，則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴服務器。
經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的後面。還有一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞迴服務器。比如：
< form name=”testform” action=”/xxx”>
< input type=”hidden” name=”jsessionid” value=”ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764”>
< input type=”text”>
< /form>
實際上這種技術可以簡單的用對action應用URL重寫來代替。
cookie 和session 的區別：
1、cookie數據存放在客戶的瀏覽器上，session數據放在服務器上。
2、cookie不是很安全，別人可以分析存放在本地的COOKIE並進行COOKIE欺騙
考慮到安全應當使用session。
3、session會在一定時間內保存在服務器上。當訪問增多，會比較佔用你服務器的性能
考慮到減輕服務器性能方面，應當使用COOKIE。
4、單個cookie保存的數據不能超過4K，很多瀏覽器都限制一個站點最多保存20個cookie。
5、所以個人建議：
將登陸信息等重要信息存放爲SESSION
其他信息如果需要保留，可以放在COOKIE中
- 由於HTTP協議是無狀態的協議，所以服務端需要記錄用戶的狀態時，就需要用某種機制來識別具體的用戶，這個機制就是Session（HttpSession）。典型的場景比如購物車，當你點擊下單按鈕時，由於HTTP協議無狀態，所以並不知道是哪個用戶操作的，所以服務端要爲特定的用戶創建了特定的Session，用於標識這個用戶，並且跟蹤用戶，這樣才知道購物車裏面有幾本書。這個Session是保存在服務端的，有一個唯一標識。在服務端保存Session的方法很多，內存、數據庫、文件都有。集羣的時候也要考慮Session的轉移，在大型的網站，一般會有專門的Session服務器集羣，用來保存用戶會話，這個時候 Session 信息都是放在內存的，使用一些緩存服務比如Memcached之類的來放 Session。
- 思考一下服務端如何識別特定的客戶？這個時候Cookie就登場了。每次HTTP請求的時候，客戶端都會發送相應的Cookie信息到服務端。實際上大多數的應用都是用 Cookie 來實現Session跟蹤的，第一次創建Session的時候，服務端會在HTTP協議中告訴客戶端，需要在 Cookie 裏面記錄一個Session ID，以後每次請求把這個會話ID發送到服務器，我就知道你是誰了。有人問，如果客戶端的瀏覽器禁用了 Cookie 怎麼辦？一般這種情況下，會使用一種叫做URL重寫的技術來進行會話跟蹤，即每次HTTP交互，URL後面都會被附加上一個諸如 sid=xxxxx 這樣的參數，服務端據此來識別用戶。
- Cookie其實還可以用在一些方便用戶的場景下，設想你某次登陸過一個網站，下次登錄的時候不想再次輸入賬號了，怎麼辦？這個信息可以寫到Cookie裏面，訪問網站的時候，網站頁面的腳本可以讀取這個信息，就自動幫你把用戶名給填了，能夠方便一下用戶。這也是Cookie名稱的由來，給用戶的一點甜頭。
- 所以，總結一下：Session是在服務端保存的一個數據結構，用來跟蹤用戶的狀態（用於區分會話和不同用戶的訪問），這個數據可以保存在集羣、數據庫、文件中；Cookie是客戶端保存用戶信息的一種機制，用來記錄用戶的一些信息，也是實現Session的一種方式：session 因爲 session id 的存在，通常要藉助 cookie 實現。