1. 網(wǎng)絡體系
1.1 應用層
應用層(Application-layer）的任務是通過應用進程間的交互來完成特定網(wǎng)絡應用。應用層協(xié)議定義的是應用進程（進程：主機中正在運行的程序）間的通信和交互的規(guī)則。對于不同的網(wǎng)絡應用需要不同的應用層協(xié)議。在互聯(lián)網(wǎng)中應用層協(xié)議很多，如域名系統(tǒng)DNS，支持萬維網(wǎng)應用的 HTTP協(xié)議，支持電子郵件的 SMTP協(xié)議等等。我們把應用層交互的數(shù)據(jù)單元稱為報文。
1.1.1 域名系統(tǒng)
域名系統(tǒng)(Domain Name System縮寫 DNS，Domain Name被譯為域名)是因特網(wǎng)的一項核心服務，它作為可以將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便的訪問互聯(lián)網(wǎng)，而不用去記住能夠被機器直接讀取的IP數(shù)串。（百度百科）例如：一個公司的 Web 網(wǎng)站可看作是它在網(wǎng)上的門戶，而域名就相當于其門牌地址，通常域名都使用該公司的名稱或簡稱。例如上面提到的微軟公司的域名，類似的還有：IBM 公司的域名是 www.ibm.com、Oracle 公司的域名是 www.oracle.com、Cisco公司的域名是 www.cisco.com 等。
1.1.2 HTTP協(xié)議
超文本傳輸協(xié)議（HTTP，HyperText Transfer Protocol)是互聯(lián)網(wǎng)上應用最為廣泛的一種網(wǎng)絡協(xié)議。所有的 WWW（萬維網(wǎng)） 文件都必須遵守這個標準。設計 HTTP 最初的目的是為了提供一種發(fā)布和接收 html 頁面的方法。
1.2 運輸層
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數(shù)據(jù)傳輸服務。應用進程利用該服務傳送應用層報文。“通用的”是指并不針對某一個特定的網(wǎng)絡應用，而是多種應用可以使用同一個運輸層服務。由于一臺主機可同時運行多個線程，因此運輸層有復用和分用的功能。所謂復用就是指多個應用層進程可同時使用下面運輸層的服務，分用和復用相反，是運輸層把收到的信息分別交付上面應用層中的相應進程。
運輸層主要使用以下兩種協(xié)議:
傳輸控制協(xié)議 TCP（Transmission Control Protocol）--提供面向連接的，可靠的數(shù)據(jù)傳輸服務。
用戶數(shù)據(jù)協(xié)議 UDP（User Datagram Protocol）--提供無連接的，盡最大努力的數(shù)據(jù)傳輸服務（不保證數(shù)據(jù)傳輸?shù)目煽啃裕?/p>
1.3 網(wǎng)絡層
在 計算機網(wǎng)絡中進行通信的兩個計算機之間可能會經(jīng)過很多個數(shù)據(jù)鏈路，也可能還要經(jīng)過很多通信子網(wǎng)。網(wǎng)絡層的任務就是選擇合適的網(wǎng)間路由和交換結(jié)點， 確保數(shù)據(jù)及時傳送。 在發(fā)送數(shù)據(jù)時，網(wǎng)絡層把運輸層產(chǎn)生的報文段或用戶數(shù)據(jù)報封裝成分組和包進行傳送。在 TCP/IP 體系結(jié)構(gòu)中，由于網(wǎng)絡層使用 IP 協(xié)議，因此分組也叫 IP 數(shù)據(jù)報 ，簡稱 數(shù)據(jù)報。
這里要注意：不要把運輸層的“用戶數(shù)據(jù)報 UDP ”和網(wǎng)絡層的“ IP 數(shù)據(jù)報”弄混。另外，無論是哪一層的數(shù)據(jù)單元，都可籠統(tǒng)地用“分組”來表示。
這里強調(diào)指出，網(wǎng)絡層中的“網(wǎng)絡”二字已經(jīng)不是我們通常談到的具體網(wǎng)絡，而是指計算機網(wǎng)絡體系結(jié)構(gòu)模型中第三層的名稱.
互聯(lián)網(wǎng)是由大量的異構(gòu)（heterogeneous）網(wǎng)絡通過路由器（router）相互連接起來的。互聯(lián)網(wǎng)使用的網(wǎng)絡層協(xié)議是無連接的網(wǎng)際協(xié)議（Internet Protocol）和許多路由選擇協(xié)議，因此互聯(lián)網(wǎng)的網(wǎng)絡層也叫做網(wǎng)際層或IP層。
1.4 數(shù)據(jù)鏈路層
數(shù)據(jù)鏈路層(data link layer)通常簡稱為鏈路層。兩臺主機之間的數(shù)據(jù)傳輸，總是在一段一段的鏈路上傳送的，這就需要使用專門的鏈路層的協(xié)議。 在兩個相鄰節(jié)點之間傳送數(shù)據(jù)時，數(shù)據(jù)鏈路層將網(wǎng)絡層交下來的 IP 數(shù)據(jù)報組裝成幀，在兩個相鄰節(jié)點間的鏈路上傳送幀。每一幀包括數(shù)據(jù)和必要的控制信息（如同步信息，地址信息，差錯控制等）。
在接收數(shù)據(jù)時，控制信息使接收端能夠知道一個幀從哪個比特開始和到哪個比特結(jié)束。這樣，數(shù)據(jù)鏈路層在收到一個幀后，就可從中提出數(shù)據(jù)部分，上交給網(wǎng)絡層。 控制信息還使接收端能夠檢測到所收到的幀中有無差錯。如果發(fā)現(xiàn)差錯，數(shù)據(jù)鏈路層就簡單地丟棄這個出了差錯的幀，以避免繼續(xù)在網(wǎng)絡中傳送下去白白浪費網(wǎng)絡資源。如果需要改正數(shù)據(jù)在鏈路層傳輸時出現(xiàn)差錯（這就是說，數(shù)據(jù)鏈路層不僅要檢錯，而且還要糾錯），那么就要采用可靠性傳輸協(xié)議來糾正出現(xiàn)的差錯。這種方法會使鏈路層的協(xié)議復雜些。
1.5 物理層
在物理層上所傳送的數(shù)據(jù)單位是比特。
物理層(physical layer)的作用是實現(xiàn)相鄰計算機節(jié)點之間比特流的透明傳送，盡可能屏蔽掉具體傳輸介質(zhì)和物理設備的差異， 使其上面的數(shù)據(jù)鏈路層不必考慮網(wǎng)絡的具體傳輸介質(zhì)是什么。“透明傳送比特流”表示經(jīng)實際電路傳送后的比特流沒有發(fā)生變化，對傳送的比特流來說，這個電路好像是看不見的。
在互聯(lián)網(wǎng)使用的各種協(xié)中最重要和最著名的就是 TCP/IP 兩個協(xié)議。現(xiàn)在人們經(jīng)常提到的TCP/IP并不一定單指TCP和IP這兩個具體的協(xié)議，而往往表示互聯(lián)網(wǎng)所使用的整個TCP/IP協(xié)議族。
2. TCP
為了準確無誤地把數(shù)據(jù)送達目標處，TCP協(xié)議采用了三次握手策略。
2.1 三次握手圖解
第一次握手：建立連接時，客戶端發(fā)送syn包（syn=j）到服務器，并進入SYN_SENT狀態(tài)，等待服務器確認；SYN：同步序列編號（Synchronize Sequence Numbers）。
第二次握手：服務器收到syn包，必須確認客戶的SYN（ack=j+1），同時自己也發(fā)送一個SYN包（syn=k），即SYN+ACK包，此時服務器進入SYN_RECV狀態(tài)；
第三次握手：客戶端收到服務器的SYN+ACK包，向服務器發(fā)送確認包ACK(ack=k+1），此包發(fā)送完畢，客戶端和服務器進入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。
用自己的理解就是：
第一次握手：客戶端發(fā)起：“喂，能聽到嗎”
第二次握手：服務器端回應：“聽得到，你能挺到我么”
第三次握手：客戶端：“聽得到，我們可以發(fā)起通話了”
2.2 為什么要三次握手
三次握手的目的是建立可靠的通信信道，說到通訊，簡單來說就是數(shù)據(jù)的發(fā)送與接收，而三次握手最主要的目的就是雙方確認自己與對方的發(fā)送與接收是正常的。
第一次握手：Client 什么都不能確認；Server 確認了對方發(fā)送正常，自己接收正常
第二次握手：Client 確認了：自己發(fā)送、接收正常，對方發(fā)送、接收正常；Server 確認了：對方發(fā)送正常，自己接收正常
第三次握手：Client 確認了：自己發(fā)送、接收正常，對方發(fā)送、接收正常；Server 確認了：自己發(fā)送、接收正常，對方發(fā)送、接收正常
所以三次握手就能確認雙發(fā)收發(fā)功能都正常，缺一不可。
2.3 第二次握手中回傳了ACK，為什么還要回傳SYN
接收端傳回發(fā)送端所發(fā)送的ACK是為了告訴客戶端，我接收到的信息確實就是你所發(fā)送的信號了，這表明從客戶端到服務端的通信是正常的。而回傳SYN則是為了建立并確認從服務端到客戶端的通信。”
SYN 同步序列編號(Synchronize Sequence Numbers) 是 TCP/IP 建立連接時使用的握手信號。在客戶機和服務器之間建立正常的 TCP 網(wǎng)絡連接時，客戶機首先發(fā)出一個 SYN 消息，服務器使用 SYN-ACK 應答表示接收到了這個消息，最后客戶機再以 ACK(Acknowledgement）消息響應。這樣在客戶機和服務器之間才能建立起可靠的 TCP 連接，數(shù)據(jù)才可以在客戶機和服務器之間傳遞。
2.4 為什么要四次揮手
斷開一個 TCP 連接則需要“四次揮手”：
客戶端-發(fā)送一個 FIN，用來關閉客戶端到服務器的數(shù)據(jù)傳送
服務器-收到這個 FIN，它發(fā)回一 個 ACK，確認序號為收到的序號加1 。和 SYN 一樣，一個 FIN 將占用一個序號
服務器-關閉與客戶端的連接，發(fā)送一個FIN給客戶端
客戶端-發(fā)回 ACK 報文確認，并將確認序號設置為收到序號加1
用我自己的理解就是：
客戶端：“我打算關閉了！”
服務端回消息：“你的消息我收到了！但是我活還沒干完，等我一會！”
服務端：“好了，我活干完了！”
客戶端：“好的，我掛斷了！”——客戶端同時等待一段時間后關閉，而服務端收到消息后立即關閉
3. TCP和UDP的區(qū)別
UDP 在傳送數(shù)據(jù)之前不需要先建立連接，遠地主機在收到 UDP 報文后，不需要給出任何確認。雖然 UDP 不提供可靠交付，但在某些情況下 UDP 確是一種最有效的工作方式（一般用于即時通信），比如： QQ 語音、 QQ 視頻 、直播等等
TCP 提供面向連接的服務。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送結(jié)束后要釋放連接。 TCP 不提供廣播或多播服務。由于 TCP 要提供可靠的，面向連接的傳輸服務（TCP的可靠體現(xiàn)在TCP在傳遞數(shù)據(jù)之前，會有三次握手來建立連接，而且在數(shù)據(jù)傳遞時，有確認、窗口、重傳、擁塞控制機制，在數(shù)據(jù)傳完后，還會斷開連接用來節(jié)約系統(tǒng)資源），這一難以避免增加了許多開銷，如確認，流量控制，計時器以及連接管理等。這不僅使協(xié)議數(shù)據(jù)單元的首部增大很多，還要占用許多處理機資源。TCP 一般用于文件傳輸、發(fā)送和接收郵件、遠程登錄等場景。
4. TCP 如何保證可靠傳輸
應用數(shù)據(jù)被分割成 TCP 認為最適合發(fā)送的數(shù)據(jù)塊。
TCP 給發(fā)送的每一個包進行編號，接收方對數(shù)據(jù)包進行排序，把有序數(shù)據(jù)傳送給應用層。
校驗和： TCP 將保持它首部和數(shù)據(jù)的檢驗和。這是一個端到端的檢驗和，目的是檢測數(shù)據(jù)在傳輸過程中的任何變化。如果收到段的檢驗和有差錯，TCP 將丟棄這個報文段和不確認收到此報文段。
TCP 的接收端會丟棄重復的數(shù)據(jù)。
流量控制： TCP 連接的每一方都有固定大小的緩沖空間，TCP的接收端只允許發(fā)送端發(fā)送接收端緩沖區(qū)能接納的數(shù)據(jù)。當接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包丟失。TCP 使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。 （TCP 利用滑動窗口實現(xiàn)流量控制）
擁塞控制： 當網(wǎng)絡擁塞時，減少數(shù)據(jù)的發(fā)送。
ARQ協(xié)議： 也是為了實現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個分組就停止發(fā)送，等待對方確認。在收到確認后再發(fā)下一個分組。
超時重傳： 當 TCP 發(fā)出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發(fā)這個報文段。
4.1 ARQ協(xié)議
自動重傳請求（Automatic Repeat-reQuest，ARQ）是OSI模型中數(shù)據(jù)鏈路層和傳輸層的錯誤糾正協(xié)議之一。它通過使用確認和超時這兩個機制，在不可靠服務的基礎上實現(xiàn)可靠的信息傳輸。如果發(fā)送方在發(fā)送后一段時間之內(nèi)沒有收到確認幀，它通常會重新發(fā)送。ARQ包括停止等待ARQ協(xié)議和連續(xù)ARQ協(xié)議。
4.1.1 停止等待ARQ協(xié)議
停止等待協(xié)議是為了實現(xiàn)可靠傳輸?shù)模幕驹砭褪敲堪l(fā)完一個分組就停止發(fā)送，等待對方確認（回復ACK）。如果過了一段時間（超時時間后），還是沒有收到 ACK 確認，說明沒有發(fā)送成功，需要重新發(fā)送，直到收到確認后再發(fā)下一個分組。
在停止等待協(xié)議中，若接收方收到重復分組，就丟棄該分組，但同時還要發(fā)送確認。
優(yōu)缺點：
優(yōu)點： 簡單
缺點： 信道利用率低，等待時間長
1) 無差錯情況:
發(fā)送方發(fā)送分組,接收方在規(guī)定時間內(nèi)收到,并且回復確認.發(fā)送方再次發(fā)送。
2) 出現(xiàn)差錯情況（超時重傳）:
停止等待協(xié)議中超時重傳是指只要超過一段時間仍然沒有收到確認，就重傳前面發(fā)送過的分組（認為剛才發(fā)送過的分組丟失了）。因此每發(fā)送完一個分組需要設置一個超時計時器，其重傳時間應比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。這種自動重傳方式常稱為 自動重傳請求 ARQ 。另外在停止等待協(xié)議中若收到重復分組，就丟棄該分組，但同時還要發(fā)送確認。連續(xù) ARQ 協(xié)議 可提高信道利用率。發(fā)送維持一個發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可連續(xù)發(fā)送出去，而不需要等待對方確認。接收方一般采用累積確認，對按序到達的最后一個分組發(fā)送確認，表明到這個分組位置的所有分組都已經(jīng)正確收到了。
3) 確認丟失和確認遲到
確認丟失 ：確認消息在傳輸過程丟失。當A發(fā)送M1消息，B收到后，B向A發(fā)送了一個M1確認消息，但卻在傳輸過程中丟失。而A并不知道，在超時計時過后，A重傳M1消息，B再次收到該消息后采取以下兩點措施：1. 丟棄這個重復的M1消息，不向上層交付。 2. 向A發(fā)送確認消息。（不會認為已經(jīng)發(fā)送過了，就不再發(fā)送。A能重傳，就證明B的確認消息丟失）。
確認遲到 ：確認消息在傳輸過程中遲到。A發(fā)送M1消息，B收到并發(fā)送確認。在超時時間內(nèi)沒有收到確認消息，A重傳M1消息，B仍然收到并繼續(xù)發(fā)送確認消息（B收到了2份M1）。此時A收到了B第二次發(fā)送的確認消息。接著發(fā)送其他數(shù)據(jù)。過了一會，A收到了B第一次發(fā)送的對M1的確認消息（A也收到了2份確認消息）。處理如下：1. A收到重復的確認后，直接丟棄。2. B收到重復的M1后，也直接丟棄重復的M1。
4.1.2 連續(xù)ARQ協(xié)議
連續(xù) ARQ 協(xié)議可提高信道利用率。發(fā)送方維持一個發(fā)送窗口，凡位于發(fā)送窗口內(nèi)的分組可以連續(xù)發(fā)送出去，而不需要等待對方確認。接收方一般采用累計確認，對按序到達的最后一個分組發(fā)送確認，表明到這個分組為止的所有分組都已經(jīng)正確收到了。
優(yōu)缺點：
優(yōu)點： 信道利用率高，容易實現(xiàn)，即使確認丟失，也不必重傳。
缺點： 不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。 比如：發(fā)送方發(fā)送了 5條 消息，中間第三條丟失（3號），這時接收方只能對前兩個發(fā)送確認。發(fā)送方無法知道后三個分組的下落，而只好把后三個全部重傳一次。這也叫 Go-Back-N（回退 N），表示需要退回來重傳已經(jīng)發(fā)送過的 N 個消息。
4.2 滑動窗口和流量控制
TCP 利用滑動窗口實現(xiàn)流量控制。流量控制是為了控制發(fā)送方發(fā)送速率，保證接收方來得及接收。 接收方發(fā)送的確認報文中的窗口字段可以用來控制發(fā)送方窗口大小，從而影響發(fā)送方的發(fā)送速率。將窗口字段設置為 0，則發(fā)送方不能發(fā)送數(shù)據(jù)。
4.3 擁塞控制
在某段時間，若對網(wǎng)絡中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡的性能就要變壞。這種情況就叫擁塞。擁塞控制就是為了防止過多的數(shù)據(jù)注入到網(wǎng)絡中，這樣就可以使網(wǎng)絡中的路由器或鏈路不致過載。擁塞控制所要做的都有一個前提，就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。擁塞控制是一個全局性的過程，涉及到所有的主機，所有的路由器，以及與降低網(wǎng)絡傳輸性能有關的所有因素。相反，流量控制往往是點對點通信量的控制，是個端到端的問題。流量控制所要做到的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。
為了進行擁塞控制，TCP 發(fā)送方要維持一個 擁塞窗口(cwnd) 的狀態(tài)變量。擁塞控制窗口的大小取決于網(wǎng)絡的擁塞程度，并且動態(tài)變化。發(fā)送方讓自己的發(fā)送窗口取為擁塞窗口和接收方的接受窗口中較小的一個。
TCP的擁塞控制采用了四種算法，即 慢開始 、 擁塞避免 、快重傳 和 快恢復。在網(wǎng)絡層也可以使路由器采用適當?shù)姆纸M丟棄策略（如主動隊列管理 AQM），以減少網(wǎng)絡擁塞的發(fā)生。
慢開始： 慢開始算法的思路是當主機開始發(fā)送數(shù)據(jù)時，如果立即把大量數(shù)據(jù)字節(jié)注入到網(wǎng)絡，那么可能會引起網(wǎng)絡阻塞，因為現(xiàn)在還不知道網(wǎng)絡的符合情況。經(jīng)驗表明，較好的方法是先探測一下，即由小到大逐漸增大發(fā)送窗口，也就是由小到大逐漸增大擁塞窗口數(shù)值。cwnd初始值為1，每經(jīng)過一個傳播輪次，cwnd加倍。
擁塞避免： 擁塞避免算法的思路是讓擁塞窗口cwnd緩慢增大，即每經(jīng)過一個往返時間RTT就把發(fā)送放的cwnd加1.
快重傳與快恢復： 在 TCP/IP 中，快速重傳和恢復（fast retransmit and recovery，F(xiàn)RR）是一種擁塞控制算法，它能快速恢復丟失的數(shù)據(jù)包。沒有 FRR，如果數(shù)據(jù)包丟失了，TCP 將會使用定時器來要求傳輸暫停。在暫停的這段時間內(nèi)，沒有新的或復制的數(shù)據(jù)包被發(fā)送。有了 FRR，如果接收機接收到一個不按順序的數(shù)據(jù)段，它會立即給發(fā)送機發(fā)送一個重復確認。如果發(fā)送機接收到三個重復確認，它會假定確認件指出的數(shù)據(jù)段丟失了，并立即重傳這些丟失的數(shù)據(jù)段。有了 FRR，就不會因為重傳時要求的暫停被耽誤。 當有單獨的數(shù)據(jù)包丟失時，快速重傳和恢復（FRR）能最有效地工作。當有多個數(shù)據(jù)信息包在某一段很短的時間內(nèi)丟失時，它則不能很有效地工作。
5. 在瀏覽器中輸入url地址 ->> 顯示主頁的過程
上圖有一個錯誤，請注意，是OSPF不是OPSF。 OSPF（Open Shortest Path First，ospf）開放最短路徑優(yōu)先協(xié)議,是由Internet工程任務組開發(fā)的路由選擇協(xié)議
總體來說分為以下幾個過程:
DNS解析
TCP連接
發(fā)送HTTP請求
服務器處理請求并返回HTTP報文
瀏覽器解析渲染頁面
連接結(jié)束
6. 狀態(tài)碼
7. 各種協(xié)議與http協(xié)議之間的關系
8. http 長連接和短連接
在HTTP/1.0中默認使用短連接。也就是說，客戶端和服務器每進行一次HTTP操作，就建立一次連接，任務結(jié)束就中斷連接。當客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JAVAScript文件、圖像文件、css文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。
而從HTTP/1.1起，默認使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應頭加入這行代碼：
Connection:keep-alive
在使用長連接的情況下，當一個網(wǎng)頁打開完成后，客戶端和服務器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關閉，客戶端再次訪問這個服務器時，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務器軟件（如Apache）中設定這個時間。實現(xiàn)長連接需要客戶端和服務端都支持長連接。
HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接。
9. HTTP是不保存狀態(tài)的協(xié)議,如何保存用戶狀態(tài)?
HTTP 是一種不保存狀態(tài)，即無狀態(tài)（stateless）協(xié)議。也就是說 HTTP 協(xié)議自身不對請求和響應之間的通信狀態(tài)進行保存。那么我們保存用戶狀態(tài)呢？Session 機制的存在就是為了解決這個問題，Session 的主要作用就是通過服務端記錄用戶的狀態(tài)。典型的場景是購物車，當你要添加商品到購物車的時候，系統(tǒng)不知道是哪個用戶操作的，因為 HTTP 協(xié)議是無狀態(tài)的。服務端給特定的用戶創(chuàng)建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了（一般情況下，服務器會在一定時間內(nèi)保存這個 Session，過了時間限制，就會銷毀這個Session）。
在服務端保存 Session 的方法很多，最常用的就是內(nèi)存和數(shù)據(jù)庫(比如是使用內(nèi)存數(shù)據(jù)庫redis保存)。既然 Session 存放在服務器端，那么我們?nèi)绾螌崿F(xiàn) Session 跟蹤呢？大部分情況下，我們都是通過在 Cookie 中附加一個 Session ID 來方式來跟蹤。
Cookie 被禁用怎么辦?
最常用的就是利用 URL 重寫把 Session ID 直接附加在URL路徑的后面。
10. cookie 和 session
Cookie 和 Session都是用來跟蹤瀏覽器用戶身份的會話方式，但是兩者的應用場景不太一樣。
Cookie 一般用來保存用戶信息
①比如我們在 Cookie 中保存已經(jīng)登錄過得用戶信息，下次訪問網(wǎng)站的時候頁面可以自動幫你登錄的一些基本信息給填了；
②一般的網(wǎng)站都會有保持登錄也就是說下次你再訪問網(wǎng)站的時候就不需要重新登錄了，這是因為用戶登錄的時候我們可以存放了一個 Token 在 Cookie 中，下次登錄的時候只需要根據(jù) Token 值來查找用戶即可(為了安全考慮，重新登錄一般要將 Token 重寫)；
③登錄一次網(wǎng)站后訪問網(wǎng)站其他頁面不需要重新登錄。
Session 的主要作用就是通過服務端記錄用戶的狀態(tài)。
典型的場景是購物車，當你要添加商品到購物車的時候，系統(tǒng)不知道是哪個用戶操作的，因為 HTTP 協(xié)議是無狀態(tài)的。服務端給特定的用戶創(chuàng)建特定的 Session 之后就可以標識這個用戶并且跟蹤這個用戶了。
Cookie 存儲在客戶端(瀏覽器端)中，而Session存儲在服務器上，相對來說 Session 安全性更高。如果要在 Cookie 中存儲一些敏感信息，不要直接寫入 Cookie 中，最好能將 Cookie 信息加密然后使用到的時候再去服務器端解密。
11. http1.0和1.1 有什么區(qū)別
長連接 : 在HTTP/1.0中，默認使用的是短連接，也就是說每次請求都要重新建立一次連接。HTTP 是基于TCP/IP協(xié)議的,每一次建立或者斷開連接都需要三次握手四次揮手的開銷，如果每次請求都要這樣的話，開銷會比較大。因此最好能維持一個長連接，可以用個長連接來發(fā)多個請求。HTTP 1.1起，默認使用長連接 ,默認開啟Connection： keep-alive。 HTTP/1.1的持續(xù)連接有非流水線方式和流水線方式 。流水線方式是客戶在收到HTTP的響應報文之前就能接著發(fā)送新的請求報文。與之相對應的非流水線方式是客戶在收到前一個響應后才能發(fā)送下一個請求。
錯誤狀態(tài)響應碼 :在HTTP1.1中新增了24個錯誤狀態(tài)響應碼，如409（Conflict）表示請求的資源與資源的當前狀態(tài)發(fā)生沖突；410（Gone）表示服務器上的某個資源被永久性的刪除。
緩存處理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires來做為緩存判斷的標準，HTTP1.1則引入了更多的緩存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
帶寬優(yōu)化及網(wǎng)絡連接的使用 :HTTP1.0中，存在一些浪費帶寬的現(xiàn)象，例如客戶端只是需要某個對象的一部分，而服務器卻將整個對象送過來了，并且不支持斷點續(xù)傳功能，HTTP1.1則在請求頭引入了range頭域，它允許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發(fā)者自由的選擇以便于充分利用帶寬和連接。
12. URI和URL
URI(Uniform Resource Identifier) 是統(tǒng)一資源標志符，可以唯一標識一個資源。
URL(Uniform Resource Location) 是統(tǒng)一資源定位符，可以提供該資源的路徑。它是一種具體的 URI，即 URL 可以用來標識一個資源，而且還指明了如何 locate 這個資源。
URI的作用像身份證號一樣，URL的作用更像家庭住址一樣。URL是一種具體的URI，它不僅唯一標識資源，而且還提供了定位該資源的信息。
13. HTTP和HTTPS
端口 ：HTTP的URL由“http://”起始且默認使用端口80，而HTTPS的URL由“https://”起始且默認使用端口443。
安全性和資源消耗： HTTP協(xié)議運行在TCP之上，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務器端都無法驗證對方的身份。HTTPS是運行在SSL/TLS之上的HTTP協(xié)議，SSL/TLS 運行在TCP之上。所有傳輸?shù)膬?nèi)容都經(jīng)過加密，加密采用對稱加密，但對稱加密的密鑰用服務器方的證書進行了非對稱加密。所以說，HTTP 安全性沒有 HTTPS高，但是 HTTPS 比HTTP耗費更多服務器資源。
對稱加密：密鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密算法有DES、AES等；
小知識點：
對稱加密：密鑰只有一個，加密的解密都是用的同一個密鑰，加密解密的速度快，典型的對稱加密有AES。
非對稱加密:密鑰成對出現(xiàn)，一般加密用是私鑰，解密用的是公鑰，通過私鑰是無法推算出公鑰的，公鑰也無法推算出私鑰，加解密的速度相對對稱加密來說慢，典型的非對稱有RSA。
