搞定計算機網絡的常見面試問題

時間：2023-06-19 01:00:02 | 來源：網站運營

時間：2023-06-19 01:00:02 來源：網站運營

搞定計算機網絡的常見面試問題：在瀏覽器中輸入一個 URL 至頁面呈現(xiàn)，網絡上都發(fā)生了什么事？
能說說 ISO 七層模型和 TCP/IP 四層模型嗎？
TCP/IP 與 HTTP 有什么關系嗎？
TCP協(xié)議與UDP協(xié)議的區(qū)別？
請詳細介紹一下 TCP 的三次握手機制，為什么要三次握手？揮手卻又是四次呢？
詳細講一下TCP的滑動窗口？知道流量控制和擁塞控制嗎？
說一下對稱加密與非對稱加密？
狀態(tài)碼 206 是什么意思？
你們用的 https 是吧，https 工作原理是什么？
…

一、計算機網絡

通信協(xié)議

通信協(xié)議（communications protocol）是指雙方實體完成通信或服務所必須遵循的規(guī)則和約定。通過通信信道和設備互連起來的多個不同地理位置的數(shù)據(jù)通信系統(tǒng)，要使其能協(xié)同工作實現(xiàn)信息交換和資源共享，它們之間必須具有共同的語言。交流什么、怎樣交流及何時交流，都必須遵循某種互相都能接受的規(guī)則。這個規(guī)則就是通信協(xié)議。

網絡模型

隨著技術的發(fā)展，計算機的應用越來越廣泛，計算機之間的通信開始了百花齊放的狀態(tài)，每個具有獨立計算服務體系的信息技術公司都會建立自己的計算機通信規(guī)則，而這種情況會導致異構計算機之間無法通信，極大的阻礙了網絡通信的發(fā)展，至此為了解決這個問題，國際標準化組織（ISO）制定了OSI模型，該模型定義了不同計算機互聯(lián)的標準，OSI模型把網絡通信的工作分為7層，分別是物理層、數(shù)據(jù)鏈路層、網絡層、傳輸層、會話層、表示層和應用層。

這七層模型是設計層面的概念，每一層都有固定要完成的職責和功能，分層的好處在于清晰和功能獨立性，但分層過多會使層次變的更加復雜，雖然不需要實現(xiàn)本層的功能，但是也需要構造本層的上下文，空耗系統(tǒng)資源，所以在落地實施網絡通信模型的時候將這七層模型簡化合并為四層模型分別是應用層、傳輸層、網絡層、網絡接口層（各層之間的模型、協(xié)議統(tǒng)稱為：TCP/IP協(xié)議簇）。







從上圖可以看到，TCP/IP模型合并了OSI模型的應用層、表示層和會話層，將OSI模型的數(shù)據(jù)鏈路層和物理層合并為網絡訪問層。

上圖還列出了各層模型對應TCP/IP協(xié)議棧中的協(xié)議以及各層協(xié)議之間的關系。比如DNS協(xié)議是建立在TCP和UDP協(xié)議的基礎上，F(xiàn)TP、HTTP、TELNET協(xié)議建立在TCP協(xié)議的基礎上，NTP、TFTP、SNMP建立在UDP協(xié)議的基礎上，而TCP、UDP協(xié)議又建立在IP協(xié)議的基礎上，以此類推….

OSI中的層	功能	TCP/IP協(xié)議族

當我們某一個網站上不去的時候。通常會ping一下這個網站

ping 可以說是ICMP的最著名的應用，是TCP/IP協(xié)議的一部分。利用ping命令可以檢查網絡是否連通，可以很好地幫助我們分析和判定網絡故障。

二、TCP/IP

數(shù)據(jù)在網絡中傳輸最終一定是通過物理介質傳輸。物理介質就是把電腦連接起來的物理手段，常見的有光纖、雙絞線，以及無線電波，它決定了電信號(0和1)的傳輸方式，物理介質的不同決定了電信號的傳輸帶寬、速率、傳輸距離以及抗干擾性等等。網絡數(shù)據(jù)傳輸就像快遞郵寄，數(shù)據(jù)就是快件。只有路打通了，你的”快遞”才能送到，因此物理介質是網絡通信的基石。

寄快遞首先得稱重、確認體積(確認數(shù)據(jù)大小)，貴重物品還得層層包裹填充物確保安全，封裝，然后填寫發(fā)件地址(源主機地址)和收件地址(目標主機地址)，確認快遞方式。對于偏遠地區(qū)，快遞不能直達，還需要中途轉發(fā)。網絡通信也是一樣的道理，只不過把這些步驟都規(guī)定成了各種協(xié)議。

TCP/IP的模型的每一層都需要下一層所提供的協(xié)議來完成自己的目的。我們來看下數(shù)據(jù)是怎么通過TCP/IP協(xié)議模型從一臺主機發(fā)送到另一臺主機的。







當用戶通過HTTP協(xié)議發(fā)起一個請求，應用層、傳輸層、網絡互聯(lián)層和網絡訪問層的相關協(xié)議依次對該請求進行包裝并攜帶對應的首部，最終在網絡訪問層生成以太網數(shù)據(jù)包，以太網數(shù)據(jù)包通過物理介質傳輸給對方主機，對方接收到數(shù)據(jù)包以后，然后再一層一層采用對應的協(xié)議進行拆包，最后把應用層數(shù)據(jù)交給應用程序處理。

TCP/IP 與 HTTP

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網際協(xié)議）是指能夠在多個不同網絡間實現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP 協(xié)議不僅僅指的是 TCP 和 IP 兩個協(xié)議，而是指一個由FTP、SMTP、TCP、UDP、IP等協(xié)議構成的協(xié)議簇， 只是因為在TCP/IP協(xié)議中TCP協(xié)議和IP協(xié)議最具代表性，所以被稱為TCP/IP協(xié)議。

而HTTP是應用層協(xié)議，主要解決如何包裝數(shù)據(jù)。

“IP”代表網際協(xié)議，TCP 和 UDP 使用該協(xié)議從一個網絡傳送數(shù)據(jù)包到另一個網絡。把IP想像成一種高速公路，它允許其它協(xié)議在上面行駛并找到到其它電腦的出口。TCP和UDP是高速公路上的“卡車”，它們攜帶的貨物就是像HTTP，文件傳輸協(xié)議FTP這樣的協(xié)議等。

TCP 與 UDP

都屬于傳輸層協(xié)議。

TCP（Transmission Control Protocol，傳輸控制協(xié)議）是面向連接的協(xié)議，也就是說，在收發(fā)數(shù)據(jù)前，必須和對方建立可靠的連接。一個TCP連接必須有三次握手、四次揮手。

UDP（User Data Protocol，用戶數(shù)據(jù)報協(xié)議）是一個非連接的協(xié)議，傳輸數(shù)據(jù)之前源端和終端不建立連接， 當它想傳送時就簡單地去抓取來自應用程序的數(shù)據(jù)，并盡可能快地把它扔到網絡上

	TCP	UDP

TCP和UDP協(xié)議的一些應用







TCP連接的建立與終止

TCP雖然是面向字節(jié)流的，但TCP傳送的數(shù)據(jù)單元卻是報文段。一個TCP報文段分為首部和數(shù)據(jù)兩部分，而TCP的全部功能體現(xiàn)在它首部中的各字段的作用。

TCP報文段首部的前20個字節(jié)是固定的（下圖），后面有4n字節(jié)是根據(jù)需要而增加的選項（n是整數(shù)）。因此TCP首部的最小長度是20字節(jié)。







TCP報文首部

• 源端口和目的端口，各占2個字節(jié)，分別寫入源端口和目的端口；
• 序列號（Sequence number），占4字節(jié)。序號范圍是【0，2^32 - 1】，共2^32個序號。序號增加到 2^32-1后，下一個序號就又回到 0。TCP是面向字節(jié)流的。在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號。整個要傳送的字節(jié)流的起始序號必須在連接建立時設置。首部中的序號字段值則是指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。例如，一報文段的序號是301，而接待的數(shù)據(jù)共有100字節(jié)。這就表明：本報文段的數(shù)據(jù)的第一個字節(jié)的序號是301，最后一個字節(jié)的序號是400。顯然，下一個報文段（如果還有的話）的數(shù)據(jù)序號應當從401開始，即下一個報文段的序號字段值應為401。這個字段的序號也叫“報文段序號”;
• 確認號（Acknowledge number），占4個字節(jié)，是期望收到對方下一個報文的第一個數(shù)據(jù)字節(jié)的序號。例如，B收到了A發(fā)送過來的報文，其序列號字段是501，而數(shù)據(jù)長度是200字節(jié)，這表明B正確的收到了A發(fā)送的到序號700為止的數(shù)據(jù)。因此，B期望收到A的下一個數(shù)據(jù)序號是701，于是B在發(fā)送給A的確認報文段中把確認號置為701；
• 數(shù)據(jù)偏移，占4位，它指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠。
• 保留，占6位，保留為今后使用，但目前應置為0；
• 緊急URG（URGent），當URG=1，表明緊急指針字段有效。告訴系統(tǒng)此報文段中有緊急數(shù)據(jù)；
• 確認ACK（ACKnowledgment），僅當ACK=1時，確認號字段才有效。TCP規(guī)定，在連接建立后所有報文的傳輸都必須把ACK置1；
• 推送PSH（PuSH） ，當兩個應用進程進行交互式通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能收到對方的響應，這時候就將PSH=1；
• 復位RST（ReSeT），當RST=1，表明TCP連接中出現(xiàn)嚴重差錯，必須釋放連接，然后再重新建立連接；
• 同步SYN（SYNchronization），在連接建立時用來同步序號。當SYN=1，ACK=0，表明是連接請求報文，若同意連接，則響應報文中應該使SYN=1，ACK=1；
• 終止FIN（FINis），用來釋放連接。當FIN=1，表明此報文的發(fā)送方的數(shù)據(jù)已經發(fā)送完畢，并且要求釋放；
• 窗口，占2字節(jié)，指的是通知接收方，發(fā)送本報文你需要有多大的空間來接受；

• 檢驗和，占2字節(jié)，校驗首部和數(shù)據(jù)這兩部分；
• 緊急指針，占2字節(jié)，指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)；
• 選項，長度可變，定義一些其他的可選的參數(shù)

TCP是一種面向連接的單播協(xié)議，在發(fā)送數(shù)據(jù)前，通信雙方必須在彼此間建立一條連接。所謂的“連接”，其實是客戶端和服務器的內存里保存的一份關于對方的信息，如ip地址、端口號等。

TCP 三次握手

所謂三次握手(Three-way Handshake)，是指建立一個 TCP 連接時，需要客戶端和服務器總共發(fā)送3個包。

三次握手的目的是連接服務器指定端口，建立 TCP 連接，并同步連接雙方的序列號和確認號，交換 TCP 窗口大小信息。

• 第一次握手(SYN=1, seq=x)
  建立連接?？蛻舳税l(fā)送連接請求報文段，這是報文首部中的同步位SYN=1，同時選擇一個初始序列號 seq=x ，此時，客戶端進程進入了 SYN-SENT（同步已發(fā)送狀態(tài)）狀態(tài)。TCP規(guī)定，SYN報文段（SYN=1的報文段）不能攜帶數(shù)據(jù)，但需要消耗掉一個序號；
• 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)
  服務器收到客戶端的SYN報文段，如果同意連接，則發(fā)出確認報文。確認報文中應該 ACK=1，SYN=1，確認號ACKnum=x+1，同時，自己還要發(fā)送SYN請求信息，SYN=1，為自己初始化一個序列號 seq=y，服務器端將上述所有信息放到一個報文段（即SYN+ACK報文段）中，一并發(fā)送給客戶端，此時，TCP服務器進程進入了SYN-RCVD（同步收到）狀態(tài)。這個報文也不能攜帶數(shù)據(jù)，但是同樣要消耗一個序號
• 第三次握手(ACK=1，ACKnum=y+1)
  客戶端收到服務器的SYN+ACK報文段，再次發(fā)送確認包(ACK)，SYN 標志位為0，ACK 標志位為1，確認號 ACKnum = y+1，這個報文段發(fā)送完畢以后，客戶端和服務器端都進入ESTABLISHED（已建立連接）狀態(tài)，完成TCP三次握手。

為什么需要三次握手呢？兩次不行嗎？

為了防止已失效的連接請求報文段突然又傳送到了服務端，因而產生錯誤。

具體例子：“已失效的連接請求報文段”的產生在這樣一種情況下：client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網絡結點長時間的滯留了，以致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就向client發(fā)出確認報文段，同意建立連接。假設不采用“三次握手”，那么只要server發(fā)出確認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經建立，并一直等待client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止上述現(xiàn)象發(fā)生。例如剛才那種情況，client不會向server的確認發(fā)出確認。server由于收不到確認，就知道client并沒有要求建立連接。”

TCP 四次揮手

TCP 的連接的拆除需要發(fā)送四個包，因此稱為四次揮手(Four-way handshake)，也叫做改進的三次握手。客戶端或服務器均可主動發(fā)起揮手動作。

• 第一次揮手(FIN=1，seq=x)
  主機1（可以使客戶端，也可以是服務器端），設置seq=x，向主機2發(fā)送一個FIN報文段；此時，主機1進入FIN_WAIT_1狀態(tài)；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了；
• 第二次揮手(ACK=1，ACKnum=x+1)
  主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段，Acknnum=x+1，主機1進入FIN_WAIT_2狀態(tài)；主機2告訴主機1，我“同意”你的關閉請求；
• 第三次揮手(FIN=1，seq=y)
  主機2向主機1發(fā)送FIN報文段，請求關閉連接，同時主機2進入LAST_ACK 狀態(tài)
• 第四次揮手(ACK=1，ACKnum=y+1)
  主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機1進入TIME_WAIT狀態(tài)；主機2收到主機1的ACK報文段以后，就關閉連接；此時，主機1等待2MSL后依然沒有收到回復，則證明Server端已正常關閉，那好，主機1也可以關閉連接了，進入 CLOSED 狀態(tài)。
  主機 1 等待了某個固定時間（兩個最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，沒有收到服務器端的 ACK ，認為服務器端已經正常關閉連接，于是自己也關閉連接，進入 CLOSED 狀態(tài)。

為什么連接的時候是三次握手，關閉的時候卻是四次握手？

因為當Server端收到Client端的SYN連接請求報文后，可以直接發(fā)送SYN+ACK報文。其中ACK報文是用來應答的，SYN報文是用來同步的。但是關閉連接時，當Server端收到FIN報文時，很可能并不會立即關閉SOCKET，所以只能先回復一個ACK報文，告訴Client端，“你發(fā)的FIN報文我收到了”。只有等到我Server端所有的報文都發(fā)送完了，我才能發(fā)送FIN報文，因此不能一起發(fā)送。故需要四步握手。

由于 TCP 協(xié)議是全雙工的，也就是說客戶端和服務端都可以發(fā)起斷開連接。兩邊各發(fā)起一次斷開連接的申請，加上各自的兩次確認，看起來就像執(zhí)行了四次揮手。

為什么TIME_WAIT狀態(tài)需要經過2MSL(最大報文段生存時間)才能返回到CLOSE狀態(tài)？

雖然按道理，四個報文都發(fā)送完畢，我們可以直接進入CLOSE狀態(tài)了，但是我們必須假象網絡是不可靠的，有可以最后一個ACK丟失。所以TIME_WAIT狀態(tài)就是用來重發(fā)可能丟失的ACK報文。

還有一個原因，防止類似與“三次握手”中提到了的“已經失效的連接請求報文段”出現(xiàn)在本連接中?？蛻舳税l(fā)送完最后一個確認報文后，在這個2MSL時間中，就可以使本連接持續(xù)的時間內所產生的所有報文段都從網絡中消失。這樣新的連接中不會出現(xiàn)舊連接的請求報文。

TCP協(xié)議如何來保證傳輸?shù)目煽啃?br>
對于可靠性，TCP通過以下方式進行保證：

• 數(shù)據(jù)包校驗：目的是檢測數(shù)據(jù)在傳輸過程中的任何變化，若校驗出包有錯，則丟棄報文段并且不給出響應，這時TCP發(fā)送數(shù)據(jù)端超時后會重發(fā)數(shù)據(jù)；
• 對失序數(shù)據(jù)包重排序：既然TCP報文段作為IP數(shù)據(jù)報來傳輸，而IP數(shù)據(jù)報的到達可能會失序，因此TCP報文段的到達也可能會失序。TCP將對失序數(shù)據(jù)進行重新排序，然后才交給應用層；
• 丟棄重復數(shù)據(jù)：對于重復數(shù)據(jù)，能夠丟棄重復數(shù)據(jù)；
• 應答機制：當TCP收到發(fā)自TCP連接另一端的數(shù)據(jù)，它將發(fā)送一個確認。這個確認不是立即發(fā)送，通常將推遲幾分之一秒；
• 超時重發(fā)：當TCP發(fā)出一個段后，它啟動一個定時器，等待目的端確認收到這個報文段。如果不能及時收到一個確認，將重發(fā)這個報文段；
• 流量控制：TCP連接的每一方都有固定大小的緩沖空間。TCP的接收端只允許另一端發(fā)送接收端緩沖區(qū)所能接納的數(shù)據(jù)，這可以防止較快主機致使較慢主機的緩沖區(qū)溢出，這就是流量控制。TCP使用的流量控制協(xié)議是可變大小的滑動窗口協(xié)議。

詳細講一下TCP的滑動窗口

滑動窗口機制

如果發(fā)送方把數(shù)據(jù)發(fā)送得過快，接收方可能會來不及接收，這就會造成數(shù)據(jù)的丟失。所謂流量控制就是讓發(fā)送方的發(fā)送速率不要太快，要讓接收方來得及接收。

利用滑動窗口機制可以很方便地在TCP連接上實現(xiàn)對發(fā)送方的流量控制。







從上面的圖可以看到滑動窗口左邊的是已發(fā)送并且被確認的分組，滑動窗口右邊是還沒有輪到的分組?；瑒哟翱诶锩嬉卜譃閮蓧K，一塊是已經發(fā)送但是未被確認的分組，另一塊是窗口內等待發(fā)送的分組。隨著已發(fā)送的分組不斷被確認，窗口內等待發(fā)送的分組也會不斷被發(fā)送。整個窗口就會往右移動，讓還沒輪到的分組進入窗口內。

可以看到滑動窗口起到了一個限流的作用，也就是說當前滑動窗口的大小決定了當前 TCP 發(fā)送包的速率，而滑動窗口的大小取決于擁塞控制窗口和流量控制窗口的兩者間的最小值。

流量控制

TCP 是全雙工的，客戶端和服務器均可作為發(fā)送方或接收方，我們現(xiàn)在假設一個發(fā)送方向接收方發(fā)送數(shù)據(jù)的場景來講解流量控制。首先我們的接收方有一塊接收緩存，當數(shù)據(jù)來到時會先把數(shù)據(jù)放到緩存中，上層應用等緩存中有數(shù)據(jù)時就會到緩存中取數(shù)據(jù)。假如發(fā)送方沒有限制地不斷地向接收方發(fā)送數(shù)據(jù)，接收方的應用程序又沒有及時把接收緩存中的數(shù)據(jù)讀走，就會出現(xiàn)緩存溢出，數(shù)據(jù)丟失的現(xiàn)象，為了解決這個問題，我們引入流量控制窗口。

假設應用程序最后讀走的數(shù)據(jù)序號是 lastByteRead，接收緩存中接收到的最后一個數(shù)據(jù)序號是 lastByteRcv，接收緩存的大小為 RcvSize，那么必須要滿足 lastByteRcv - lastByteRead <= RcvSize 才能保證接收緩存不會溢出，所以我們定義流量窗口為接收緩存剩余的空間，也就是Rcv = RcvSize - (lastByteRcv - lastByteRead)。只要接收方在響應 ACK 的時候把這個窗口的值帶給發(fā)送方，發(fā)送方就能知道接收方的接收緩存還有多大的空間，進而設置滑動窗口的大小。

擁塞控制

擁塞控制是指發(fā)送方先設置一個小的窗口值作為發(fā)送速率，當成功發(fā)包并接收到ACK時，便以指數(shù)速率增大發(fā)送窗口的大小，直到遇到丟包（超時/三個冗余ACK），才停止并調整窗口的大小。這么做能最大限度地利用帶寬，又不至于讓網絡環(huán)境變得太過擁擠。

最終滑動窗口的值將設置為流量控制窗口和擁塞控制窗口中的較小值。

TCP的擁塞處理

計算機網絡中的帶寬、交換結點中的緩存及處理機等都是網絡的資源。在某段時間，若對網絡中某一資源的需求超過了該資源所能提供的可用部分，網絡的性能就會變壞，這種情況就叫做擁塞。擁塞控制就是防止過多的數(shù)據(jù)注入網絡中，這樣可以使網絡中的路由器或鏈路不致過載。注意，擁塞控制和流量控制不同，前者是一個全局性的過程，而后者指點對點通信量的控制。擁塞控制的方法主要有以下四種：

1. 慢啟動：不要一開始就發(fā)送大量的數(shù)據(jù)，先探測一下網絡的擁塞程度，也就是說由小到大逐漸增加擁塞窗口的大小;
2. 擁塞避免：擁塞避免算法讓擁塞窗口緩慢增長，即每經過一個往返時間RTT就把發(fā)送方的擁塞窗口cwnd加1，而不是加倍，這樣擁塞窗口按線性規(guī)律緩慢增長。
3. 快重傳：快重傳要求接收方在收到一個 失序的報文段 后就立即發(fā)出 重復確認（為的是使發(fā)送方及早知道有報文段沒有到達對方）而不要等到自己發(fā)送數(shù)據(jù)時捎帶確認?？熘貍魉惴ㄒ?guī)定，發(fā)送方只要一連收到三個重復確認就應當立即重傳對方尚未收到的報文段，而不必繼續(xù)等待設置的重傳計時器時間到期。
4. 快恢復：快重傳配合使用的還有快恢復算法，當發(fā)送方連續(xù)收到三個重復確認時，就執(zhí)行“乘法減小”算法，把ssthresh門限減半，但是接下去并不執(zhí)行慢開始算法：因為如果網絡出現(xiàn)擁塞的話就不會收到好幾個重復的確認，所以發(fā)送方現(xiàn)在認為網絡可能沒有出現(xiàn)擁塞。所以此時不執(zhí)行慢開始算法，而是將cwnd設置為ssthresh的大小，然后執(zhí)行擁塞避免算法。

服務器出現(xiàn)了大量CLOSE_WAIT狀態(tài)如何解決

大量 CLOSE_WAIT 表示程序出現(xiàn)了問題，對方的 socket 已經關閉連接，而我方忙于讀或寫沒有及時關閉連接，需要檢查代碼，特別是釋放資源的代碼，或者是處理請求的線程配置。

講一講SYN超時，洪泛攻擊，以及解決策略

什么 SYN 是洪泛攻擊？在 TCP 的三次握手機制的第一步中，客戶端會向服務器發(fā)送 SYN 報文段。服務器接收到 SYN 報文段后會為該TCP分配緩存和變量，如果攻擊分子大量地往服務器發(fā)送 SYN 報文段，服務器的連接資源終將被耗盡，導致內存溢出無法繼續(xù)服務。

解決策略：當服務器接受到 SYN 報文段時，不直接為該 TCP 分配資源，而只是打開一個半開的套接字。接著會使用 SYN 報文段的源Id，目的Id，端口號以及只有服務器自己知道的一個秘密函數(shù)生成一個 cookie，并把 cookie 作為序列號響應給客戶端。

如果客戶端是正常建立連接，將會返回一個確認字段為 cookie + 1 的報文段。接下來服務器會根據(jù)確認報文的源Id，目的Id，端口號以及秘密函數(shù)計算出一個結果，如果結果的值 + 1等于確認字段的值，則證明是剛剛請求連接的客戶端，這時候才為該 TCP 分配資源

這樣一來就不會為惡意攻擊的 SYN 報文段分配資源空間，避免了攻擊。

三、HTTP

HTTP1.0、HTTP1.1、HTTP2.0 的區(qū)別
post 和 get 的區(qū)別

HTTP全稱是 HyperText Transfer Protocal，即：超文本傳輸協(xié)議。是互聯(lián)網上應用最為廣泛的一種網絡通信協(xié)議，它允許將超文本標記語言（HTML）文檔從Web服務器傳送到客戶端的瀏覽器。目前我們使用的是HTTP/1.1 版本。所有的WWW文件都必須遵守這個標準。設計HTTP最初的目的是為了提供一種發(fā)布和接收HTML頁面的方法。1960年美國人 Ted Nelson 構思了一種通過計算機處理文本信息的方法，并稱之為超文本（hypertext），這成為了HTTP超文本傳輸協(xié)議標準架構的發(fā)展根基。

URI 和 URL

每個Web 服務器資源都有一個名字，這樣客戶端就可以說明他們感興趣的資源是什么了，服務器資源名被稱為統(tǒng)一資源標識符（Uniform Resource Identifier,URI）。URI 就像因特網上的郵政地址一樣，在世界范圍內唯一標識并定位信息資源。

統(tǒng)一資源定位符（URL）是資源標識符最常見的形式。URL 描述了一臺特定服務器上某資源的特定位置。

現(xiàn)在幾乎所有的 URI 都是 URL。

URI 的第二種形式就是統(tǒng)一資源名（URN）。URN 是作為特定內容的唯一名稱使用的，與目前的資源所在地無關。

HTTP消息的結構

事務和報文

客戶端是怎樣通過HTTP與Web服務器及其資源進行事務處理的呢？一個HTTP事務由一條請求命令（從客戶端發(fā)往服務器）和一個響應（從服務器發(fā)回客戶端）結果組成。這種通信是通過名為HTTP報文（HTTP Message）的格式化數(shù)據(jù)塊進行的。

HTTP事務：







報文：

HTTP 報文是純文本，不是二進制代碼。從 Web 客戶端發(fā)往 Web 服務器的 HTTP 報文稱為請求報文（request message）。從服務器發(fā)往客戶端的報文稱為響應報文。







HTTP 報文包括三部分：

• 起始行
• 首部字段
• 主體

方法

Http協(xié)議定義了很多與服務器交互的方法，最基本的有4種，分別是GET,POST,PUT,DELETE. 一個URL地址用于描述一個網絡上的資源，而HTTP中的GET, POST, PUT, DELETE就對應著對這個資源的查，改，增，刪4個操作。我們最常見的就是GET和POST了。GET一般用于獲取/查詢資源信息，而POST一般用于更新資源信息。

• GET
• HEAD
• PUT
• POST
• TRACE
• OPTIONS
• DELETE

Get與POST的區(qū)別

GET與POST是我們常用的兩種HTTP Method，二者之間的區(qū)別主要包括如下五個方面：

1. 從功能上講，GET一般用來從服務器上獲取資源，POST一般用來更新服務器上的資源；
2. 從REST服務角度上說，GET是冪等的，即讀取同一個資源，總是得到相同的數(shù)據(jù)，而POST不是冪等的，因為每次請求對資源的改變并不是相同的；進一步地，GET不會改變服務器上的資源，而POST會對服務器資源進行改變；
3. 從請求參數(shù)形式上看，GET請求的數(shù)據(jù)會附在URL之后，即將請求數(shù)據(jù)放置在HTTP報文的 請求頭 中，以?分割URL和傳輸數(shù)據(jù)，參數(shù)之間以&相連。特別地，如果數(shù)據(jù)是英文字母/數(shù)字，原樣發(fā)送；否則，會將其編碼為 application/x-www-form-urlencoded MIME 字符串(如果是空格，轉換為+，如果是中文/其他字符，則直接把字符串用BASE64加密，得出如：%E4%BD%A0%E5%A5%BD，其中％XX中的XX為該符號以16進制表示的ASCII)；而POST請求會把提交的數(shù)據(jù)則放置在是HTTP請求報文的 請求體 中。
4. 就安全性而言，POST的安全性要比GET的安全性高，因為GET請求提交的數(shù)據(jù)將明文出現(xiàn)在URL上，而且POST請求參數(shù)則被包裝到請求體中，相對更安全。
5. 從請求的大小看，GET請求的長度受限于瀏覽器或服務器對URL長度的限制，允許發(fā)送的數(shù)據(jù)量比較小，而POST請求則是沒有大小限制的。

HTTP請求結構：請求方式 + 請求URI + 協(xié)議及其版本

HTTP響應結構：狀態(tài)碼 + 原因短語 + 協(xié)議及其版本

狀態(tài)碼

每條HTTP響應報文返回時都會攜帶一個狀態(tài)碼。狀態(tài)碼是一個三位數(shù)字的代碼，告知客戶端請求是否成功，或者是都需要采取其他動作。

• 1xx：表明服務端接收了客戶端請求，客戶端繼續(xù)發(fā)送請求；
• 2xx：客戶端發(fā)送的請求被服務端成功接收并成功進行了處理；
• 3xx：服務端給客戶端返回用于重定向的信息；
• 4xx：客戶端的請求有非法內容；
• 5xx：服務端未能正常處理客戶端的請求而出現(xiàn)意外錯誤。
• 200 OK：表示從客戶端發(fā)送給服務器的請求被正常處理并返回；
• 204 No Content：表示客戶端發(fā)送給客戶端的請求得到了成功處理，但在返回的響應報文中不含實體的主體部分（沒有資源可以返回）
• 206 Patial Content：表示客戶端進行了范圍請求，并且服務器成功執(zhí)行了這部分的GET請求，響應報文中包含由Content-Range指定范圍的實體內容。
• 301 Moved Permanently：永久性重定向，表示請求的資源被分配了新的URL，之后應使用更改的URL；
• 302 Found：臨時性重定向，表示請求的資源被分配了新的URL，希望本次訪問使用新的URL；
• 303 See Other：表示請求的資源被分配了新的URL，應使用GET方法定向獲取請求的資源
• 304 Not Modified：表示客戶端發(fā)送附帶條件（是指采用GET方法的請求報文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的請求時，服務器端允許訪問資源，但是請求為滿足條件的情況下返回改狀態(tài)碼；
• 400 Bad Request:表示請求報文中存在語法錯誤；
• 401 Unauthorized：經許可，需要通過HTTP認證；
• 403 Forbidden：服務器拒絕該次訪問（訪問權限出現(xiàn)問題）
• 404 Not Found：表示服務器上無法找到請求的資源，除此之外，也可以在服務器拒絕請求但不想給拒絕原因時使用；
• 500 Inter Server Error：表示服務器在執(zhí)行請求時發(fā)生了錯誤，也有可能是web應用存在的bug或某些臨時的錯誤時；
• 503 Server Unavailable：表示服務器暫時處于超負載或正在進行停機維護，無法處理請求；

HTTP 是個應用層協(xié)議。HTTP 無需操心網絡通信的具體細節(jié)，而是把這些細節(jié)都交給了通用可靠的因特網傳輸協(xié)議 TCP/IP。

在 HTTP 客戶端向服務器發(fā)送報文之前，需要用網絡協(xié)議（Internet Protocol，IP）地址和端口號在客戶端和服務器之間建立一條 TCP/IP 協(xié)議。而 IP 地址就是通過 URL 提供的，像 http://207.200.21.11:80/index.html，還有使用域名服務（Domain Name Services，DNS）的 http://www.lazyegg.net。







協(xié)議版本

• HTTP/0.9
  HTTP協(xié)議的最初版本，功能簡陋，僅支持 GET 方法，并且僅能請求訪問 HTML 格式的資源
• HTTP/1.0
• 增加了請求方式 POST 和 HEAD
• 不再局限于0.9版本的HTML格式，根據(jù)Content-Type可以支持多種數(shù)據(jù)格式，即MIME多用途互聯(lián)網郵件擴展，例如text/html、image/jpeg等
• 同時也開始支持 cache，就是當客戶端在規(guī)定時間內訪問統(tǒng)一網站，直接訪問cache即可
• HTTP請求和回應的格式也變了。除了數(shù)據(jù)部分，每次通信都必須包括頭信息（HTTP header），用來描述一些元數(shù)據(jù)。其他的新增功能還包括狀態(tài)碼（status code）、多字符集支持、多部分發(fā)送（multi-part type）、權限（authorization）、緩存（cache）、內容編碼（content encoding）等
• 但是1.0版本的工作方式是每次TCP連接只能發(fā)送一個請求，當服務器響應后就會關閉這次連接，下一個請求需要再次建立TCP連接，就是不支持keepalive

• HTTP/1.0+
  在20世紀90年代中葉，為滿足飛快發(fā)展的萬維網，很多流行的 Web 客戶端和服務器飛快的向 HTTP 中添加各種特性，包括持久的 keep-alive 連接、虛擬主機支持，以及代理連接支持都被假如到 HTTP 中，并稱為非官方的事實標準。這種非正式的 HTTP 擴展版本通常稱為 HTTP/1.0+
• HTTP/1.1
• http1.1是目前最為主流的http協(xié)議版本，從1997年發(fā)布至今，仍是主流的http協(xié)議版本。
• 引入了持久連接，或叫長連接（ persistent connection），即TCP連接默認不關閉，可以被多個請求復用，不用聲明Connection: keep-alive。
• 引入了管道機制（ pipelining），即在同一個TCP連接里，客戶端可以同時發(fā)送多個請求，進一步改進了HTTP協(xié)議的效率。
• 新增方法：PUT、 PATCH、 OPTIONS、 DELETE。
• http協(xié)議不帶有狀態(tài)，每次請求都必須附上所有信息。請求的很多字段都是重復的，浪費帶寬，影響速度。

• HTTP/2.0（又名 HTTP-NG）
• http/2發(fā)布于2015年，目前應用還比較少。
• http/2是一個徹底的二進制協(xié)議，頭信息和數(shù)據(jù)體都是二進制，并且統(tǒng)稱為"幀"（frame）：頭信息幀和數(shù)據(jù)幀。
• 復用TCP連接，在一個連接里，客戶端和瀏覽器都可以同時發(fā)送多個請求或回應，且不用按順序一一對應，避免了隊頭堵塞的問題,此雙向的實時通信稱為多工（ Multiplexing）。
• HTTP/2 允許服務器未經請求，主動向客戶端發(fā)送資源，即服務器推送。
• 引入頭信息壓縮機制（ header compression） ,頭信息使用gzip或compress壓縮后再發(fā)送。

四、HTTPS

HTTP缺點：

1. 通信使用明文不對數(shù)據(jù)進行加密（內容容易被竊聽）
2. 不驗證通信方身份（容易偽裝）
3. 無法確定報文完整性（內容易被篡改）

因此，HTTP協(xié)議不適合傳輸一些敏感信息，比如：信用卡號、密碼等支付信息。

為了解決HTTP協(xié)議的這一缺陷，需要使用另一種協(xié)議：安全套接字層超文本傳輸協(xié)議 HTTPS，為了數(shù)據(jù)傳輸?shù)陌踩?，HTTPS在HTTP的基礎上加入了SSL（安全套接層）協(xié)議，SSL依靠證書來驗證服務器的身份，并為瀏覽器和服務器之間的通信加密。

與 SSL（安全套接層）組合使用的 HTTP 就是 HTTPS










img

HTTP和HTTPS對比

HTTP協(xié)議傳輸?shù)臄?shù)據(jù)都是未加密的，也就是明文的，因此使用HTTP協(xié)議傳輸隱私信息非常不安全，為了保證這些隱私數(shù)據(jù)能加密傳輸，于是網景公司設計了SSL（Secure Sockets Layer）協(xié)議用于對HTTP協(xié)議傳輸?shù)臄?shù)據(jù)進行加密，從而就誕生了HTTPS。簡單來說，HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，要比http協(xié)議安全。

HTTPS和HTTP的區(qū)別主要如下：

1. https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2. http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3. http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4. http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，比http協(xié)議安全。

對稱加密與非對稱加密

主要的加密方法分為兩種：一種是共享密鑰加密（對稱密鑰加密），一種是公開密鑰加密（非對稱密鑰加密）

共享密鑰加密(對稱秘鑰加密)

加密與解密使用同一個密鑰，常見的對稱加密算法：DES，AES，3DES等。




img

也就是說在加密的同時，也會把密鑰發(fā)送給對方。在發(fā)送密鑰過程中可能會造成密鑰被竊取，那么如何解決這一問題呢？

公開密鑰（非對稱密鑰）

公開密鑰使用一對非對稱密鑰。一把叫私有密鑰，另一把叫公開密鑰。私有密鑰不讓任何人知道，公有密鑰隨意發(fā)送。公鑰加密的信息，只有私鑰才能解密。常見的非對稱加密算法：RSA，ECC等。

也就是說，發(fā)送密文方使用對方的公開密鑰進行加密，對方接受到信息后，使用私有密鑰進行解密。







對稱加密加密與解密使用的是同樣的密鑰，所以速度快，但由于需要將密鑰在網絡傳輸，所以安全性不高。

非對稱加密使用了一對密鑰，公鑰與私鑰，所以安全性高，但加密與解密速度慢。

為了解決這一問題，https采用對稱加密與非對稱加密的混合加密方式。

SSL/TSL

SSL（Secure Sockets Layer），中文叫做“安全套接層”。它是在上世紀90年代中期，由網景公司設計的。

SSL 協(xié)議就是用來解決 HTTP 傳輸過程的不安全問題，到了1999年，SSL 因為應用廣泛，已經成為互聯(lián)網上的事實標準。IETF 就在那年把 SSL 標準化。標準化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協(xié)議”。

很多相關的文章都把這兩者并列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。

SSL/TLS協(xié)議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。

但是，這里有兩個問題。

• 如何保證公鑰不被篡改？

解決方法：將公鑰放在數(shù)字證書中。只要證書是可信的，公鑰就是可信的。

• 公鑰加密計算量太大，如何減少耗用的時間？
  每一次對話（session），客戶端和服務器端都生成一個"對話密鑰"（session key），用它來加密信息。由于"對話密鑰"是對稱加密，所以運算速度非?？?，而服務器公鑰只用于加密"對話密鑰"本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS協(xié)議的基本過程是這樣的：

1. 服務端將非對稱加密的公鑰發(fā)送給客戶端；
2. 客戶端拿著服務端發(fā)來的公鑰，對對稱加密的key做加密并發(fā)給服務端；
3. 服務端拿著自己的私鑰對發(fā)來的密文解密，從來獲取到對稱加密的key；
4. 二者利用對稱加密的key對需要傳輸?shù)南⒆黾咏饷軅鬏敗?/li>

HTTPS相比HTTP，在請求前多了一個「握手」的環(huán)節(jié)。

握手過程中確定了數(shù)據(jù)加密的密碼。在握手過程中，網站會向瀏覽器發(fā)送 SSL 證書，SSL 證書和我們日常用的身份證類似，是一個支持 HTTPS 網站的身份證明，SSL 證書里面包含了網站的域名，證書有效期，證書的頒發(fā)機構以及用于加密傳輸密碼的公鑰等信息，由于公鑰加密的密碼只能被在申請證書時生成的私鑰解密，因此瀏覽器在生成密碼之前需要先核對當前訪問的域名與證書上綁定的域名是否一致，同時還要對證書的頒發(fā)機構進行驗證，如果驗證失敗瀏覽器會給出證書錯誤的提示。

證書







實際上，我們使用的證書分很多種類型，SSL證書只是其中的一種。證書的格式是由 X.509 標準定義。SSL 證書負責傳輸公鑰，是一種PKI（Public Key Infrastructure，公鑰基礎結構）證書。

我們常見的證書根據(jù)用途不同大致有以下幾種：

1. SSL證書，用于加密HTTP協(xié)議，也就是HTTPS。
2. 代碼簽名證書，用于簽名二進制文件，比如Windows內核驅動，F(xiàn)irefox插件，Java代碼簽名等等。
3. 客戶端證書，用于加密郵件。
4. 雙因素證書，網銀專業(yè)版使用的USB Key里面用的就是這種類型的證書。

這些證書都是由受認證的證書頒發(fā)機構——我們稱之為CA（Certificate Authority）機構來頒發(fā)，針對企業(yè)與個人的不同，可申請的證書的類型也不同，價格也不同。CA機構頒發(fā)的證書都是受信任的證書，對于 SSL 證書來說，如果訪問的網站與證書綁定的網站一致就可以通過瀏覽器的驗證而不會提示錯誤。

為什么服務端要發(fā)送證書給客戶端

互聯(lián)網有太多的服務需要使用證書來驗證身份，以至于客戶端(操作系統(tǒng)或瀏覽器等)無法內置所有證書，需要通過服務端將證書發(fā)送給客戶端。

客戶端為什么要驗證接收到的證書

中間人攻擊

客戶端<------------攻擊者<------------服務端 偽造證書 攔截請求

客戶端如何驗證接收到的證書

為了回答這個問題，需要引入數(shù)字簽名(Digital Signature)。

+---------------------+ | A digital signature | |(not to be confused | |with a digital | |certificate) | +---------+ +--------+ | is a mathematical |----哈希--->| 消息摘要 |---私鑰加密--->| 數(shù)字簽名 | |technique used | +---------+ +--------+ |to validate the | |authenticity and | |integrity of a | |message, software | |or digital document. | +---------------------+

將一段文本通過哈希（hash）和私鑰加密處理后生成數(shù)字簽名。

假設消息傳遞在Bob，Susan和Pat三人之間發(fā)生。Susan將消息連同數(shù)字簽名一起發(fā)送給Bob，Bob接收到消息后，可以這樣驗證接收到的消息就是Susan發(fā)送的

+---------------------+ | A digital signature | |(not to be confused | |with a digital | |certificate) | +---------+ | is a mathematical |----哈希--->| 消息摘要 | |technique used | +---------+ |to validate the | | |authenticity and | | |integrity of a | | |message, software | 對 |or digital document. | 比 +---------------------+ | | | +--------+ +---------+ | 數(shù)字簽名 |---公鑰解密--->| 消息摘要 | +--------+ +---------+

當然，這個前提是Bob知道Susan的公鑰。更重要的是，和消息本身一樣，公鑰不能在不安全的網絡中直接發(fā)送給Bob。此時就引入了證書頒發(fā)機構（Certificate Authority，簡稱CA），CA數(shù)量并不多，Bob客戶端內置了所有受信任CA的證書。CA對Susan的公鑰（和其他信息）數(shù)字簽名后生成證書。

Susan將證書發(fā)送給Bob后，Bob通過CA證書的公鑰驗證證書簽名。

Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任鏈（Chain Of Trust）就是這樣形成的。

事實上，Bob客戶端內置的是CA的根證書(Root Certificate)，HTTPS協(xié)議中服務器會發(fā)送證書鏈（Certificate Chain）給客戶端。

HTTPS的工作原理

1. Client 使用https的URL訪問 Server，要求與 Server 建立 SSL 連接
2. Server 把事先配置好的公鑰證書返回給客戶端。
3. Client驗證公鑰證書：比如是否在有效期內，證書的用途是不是匹配Client請求的站點，是不是在CRL吊銷列表里面，它的上一級證書是否有效，這是一個遞歸的過程，直到驗證到根證書（操作系統(tǒng)內置的Root證書或者Client內置的Root證書）。如果驗證通過則繼續(xù)，不通過則顯示警告信息。
4. Client使用偽隨機數(shù)生成器生成加密所使用的對稱密鑰，然后用證書的公鑰加密這個對稱密鑰，發(fā)給Server。
5. Server使用自己的私鑰（private key）解密這個消息，得到對稱密鑰。至此，Client和Server雙方都持有了相同的對稱密鑰。
6. Server使用對稱密鑰加密“明文內容A”，發(fā)送給Client。
7. Client使用對稱密鑰解密響應的密文，得到“明文內容A”。
8. Client再次發(fā)起HTTPS的請求，使用對稱密鑰加密請求的“明文內容B”，然后Server使用對稱密鑰解密密文，得到“明文內容B”。

HTTPS的優(yōu)點

盡管HTTPS并非絕對安全，掌握根證書的機構、掌握加密算法的組織同樣可以進行中間人形式的攻擊，但HTTPS仍是現(xiàn)行架構下最安全的解決方案，主要有以下幾個好處：

1. 使用HTTPS協(xié)議可認證用戶和服務器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務器；
2. HTTPS協(xié)議是由SSL+HTTP協(xié)議構建的可進行加密傳輸、身份認證的網絡協(xié)議，要比http協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性。
3. HTTPS是現(xiàn)行架構下最安全的解決方案，雖然不是絕對安全，但它大幅增加了中間人攻擊的成本。
4. 谷歌曾在2014年8月份調整搜索引擎算法，并稱“比起同等HTTP網站，采用HTTPS加密的網站在搜索結果中的排名將會更高”。

HTTPS的缺點

雖然說HTTPS有很大的優(yōu)勢，但其相對來說，還是存在不足之處的：

1. HTTPS協(xié)議握手階段比較費時，會使頁面的加載時間延長近50%，增加10%到20%的耗電；
2. HTTPS連接緩存不如HTTP高效，會增加數(shù)據(jù)開銷和功耗，甚至已有的安全措施也會因此而受到影響；
3. SSL證書需要錢，功能越強大的證書費用越高，個人網站、小網站沒有必要一般不會用。
4. SSL證書通常需要綁定IP，不能在同一IP上綁定多個域名，IPv4資源不可能支撐這個消耗。
5. HTTPS協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務攻擊、服務器劫持等方面幾乎起不到什么作用。最關鍵的，SSL證書的信用鏈體系并不安全，特別是在某些國家可以控制CA根證書的情況下，中間人攻擊一樣可行。

HTTP 切換到 HTTPS

如果需要將網站從http切換到https到底該如何實現(xiàn)呢？

這里需要將頁面中所有的鏈接，例如js，css，圖片等等鏈接都由http改為https。例如：http://www.baidu.com改為https://www.baidu.com

BTW，這里雖然將http切換為了https，還是建議保留http。所以我們在切換的時候可以做http和https的兼容，具體實現(xiàn)方式是，去掉頁面鏈接中的http頭部，這樣可以自動匹配http頭和https頭。例如：將http://www.baidu.com改為//http://www.baidu.com。然后當用戶從http的入口進入訪問頁面時，頁面就是http，如果用戶是從https的入口進入訪問頁面，頁面即使https的。

什么是Cookie，Cookie的使用過程是怎么樣的？

由于 http 協(xié)議是無狀態(tài)協(xié)議，如果客戶通過瀏覽器訪問 web 應用時沒有一個保存用戶訪問狀態(tài)的機制，那么將不能持續(xù)跟蹤應用的操作。比如當用戶往購物車中添加了商品，web 應用必須在用戶瀏覽別的商品的時候仍保存購物車的狀態(tài)，以便用戶繼續(xù)往購物車中添加商品。

cookie 是瀏覽器的一種緩存機制，它可用于維持客戶端與服務器端之間的會話。由于下面一題會講到session，所以這里要強調cookie會將會話保存在客戶端（session則是把會話保存在服務端）

這里以最常見的登陸案例講解cookie的使用過程：

1. 首先用戶在客戶端瀏覽器向服務器發(fā)起登陸請求
2. 登陸成功后，服務端會把登陸的用戶信息設置 cookie 中，返回給客戶端瀏覽器
3. 客戶端瀏覽器接收到 cookie 請求后，會把 cookie 保存到本地（可能是內存，也可能是磁盤，看具體使用情況而定）
4. 以后再次訪問該 web 應用時，客戶端瀏覽器就會把本地的 cookie 帶上，這樣服務端就能根據(jù) cookie 獲得用戶信息了

什么是session，有哪些實現(xiàn)session的機制？

session 是一種維持客戶端與服務器端會話的機制。但是與 cookie 把會話信息保存在客戶端本地不一樣，session 把會話保留在瀏覽器端。

我們同樣以登陸案例為例子講解 session 的使用過程：

1. 首先用戶在客戶端瀏覽器發(fā)起登陸請求
2. 登陸成功后，服務端會把用戶信息保存在服務端，并返回一個唯一的 session 標識給客戶端瀏覽器。
3. 客戶端瀏覽器會把這個唯一的 session 標識保存在起來
4. 以后再次訪問 web 應用時，客戶端瀏覽器會把這個唯一的 session 標識帶上，這樣服務端就能根據(jù)這個唯一標識找到用戶信息。

看到這里可能會引起疑問：把唯一的 session 標識返回給客戶端瀏覽器，然后保存起來，以后訪問時帶上，這難道不是 cookie 嗎？

沒錯，session 只是一種會話機制，在許多 web 應用中，session 機制就是通過 cookie 來實現(xiàn)的。也就是說它只是使用了 cookie 的功能，并不是使用 cookie 完成會話保存。與 cookie 在保存客戶端保存會話的機制相反，session 通過 cookie 的功能把會話信息保存到了服務端。

進一步地說，session 是一種維持服務端與客戶端之間會話的機制，它可以有不同的實現(xiàn)。以現(xiàn)在比較流行的小程序為例，闡述一個 session 的實現(xiàn)方案：

1. 首先用戶登陸后，需要把用戶登陸信息保存在服務端，這里我們可以采用 redis。比如說給用戶生成一個 userToken，然后以 userId 作為鍵，以 userToken 作為值保存到 redis 中，并在返回時把 userToken 帶回給小程序端。
2. 小程序端接收到 userToken 后把它緩存起來，以后每當訪問后端服務時就把 userToken 帶上。
3. 在后續(xù)的服務中服務端只要拿著小程序端帶來的 userToken 和 redis 中的 userToken 進行比對，就能確定用戶的登陸狀態(tài)了。

session和cookie有什么區(qū)別

經過上面兩道題的闡述，這道題就很清晰了

1. cookie 是瀏覽器提供的一種緩存機制，它可以用于維持客戶端與服務端之間的會話
2. session 指的是維持客戶端與服務端會話的一種機制，它可以通過 cookie 實現(xiàn)，也可以通過別的手段實現(xiàn)。
3. 如果用 cookie 實現(xiàn)會話，那么會話會保存在客戶端瀏覽器中
4. 而 session 機制提供的會話是保存在服務端的。

Other FAQ

從輸入網址到獲得頁面的過程

1. 瀏覽器查詢 DNS，獲取域名對應的IP地址:具體過程包括瀏覽器搜索自身的DNS緩存、搜索操作系統(tǒng)的DNS緩存、讀取本地的Host文件和向本地DNS服務器進行查詢等。對于向本地DNS服務器進行查詢，如果要查詢的域名包含在本地配置區(qū)域資源中，則返回解析結果給客戶機，完成域名解析(此解析具有權威性)；如果要查詢的域名不由本地DNS服務器區(qū)域解析，但該服務器已緩存了此網址映射關系，則調用這個IP地址映射，完成域名解析（此解析不具有權威性）。如果本地域名服務器并未緩存該網址映射關系，那么將根據(jù)其設置發(fā)起遞歸查詢或者迭代查詢；
2. 瀏覽器獲得域名對應的IP地址以后，瀏覽器向服務器請求建立鏈接，發(fā)起三次握手；
3. TCP/IP鏈接建立起來后，瀏覽器向服務器發(fā)送HTTP請求；
4. 服務器接收到這個請求，并根據(jù)路徑參數(shù)映射到特定的請求處理器進行處理，并將處理結果及相應的視圖返回給瀏覽器；
5. 瀏覽器解析并渲染視圖，若遇到對js文件、css文件及圖片等靜態(tài)資源的引用，則重復上述步驟并向服務器請求這些資源；
6. 瀏覽器根據(jù)其請求到的資源、數(shù)據(jù)渲染頁面，最終向用戶呈現(xiàn)一個完整的頁面。

XSS 攻擊

XSS 是一種經常出現(xiàn)在web應用中的計算機安全漏洞，與SQL注入一起成為web中最主流的攻擊方式。XSS是指惡意攻擊者利用網站沒有對用戶提交數(shù)據(jù)進行轉義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到web頁面中去，使別的用戶訪問都會執(zhí)行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。

IP地址的分類

IP地址是指互聯(lián)網協(xié)議地址，是IP協(xié)議提供的一種統(tǒng)一的地址格式，它為互聯(lián)網上的每一個網絡和每一臺主機分配一個邏輯地址，以此來屏蔽物理地址的差異。IP地址編址方案將IP地址空間劃分為A、B、C、D、E五類，其中A、B、C是基本類，D、E類作為多播和保留使用，為特殊地址。

每個IP地址包括兩個標識碼（ID），即網絡ID和主機ID。同一個物理網絡上的所有主機都使用同一個網絡ID，網絡上的一個主機（包括網絡上工作站，服務器和路由器等）有一個主機ID與其對應。A~E類地址的特點如下：

A類地址：以0開頭，第一個字節(jié)范圍：0~127；

B類地址：以10開頭，第一個字節(jié)范圍：128~191；

C類地址：以110開頭，第一個字節(jié)范圍：192~223；

D類地址：以1110開頭，第一個字節(jié)范圍為224~239；

E類地址：以1111開頭，保留地址