資料參考：

Cyc2018TCP三次握手第三次握手時ACK丟失怎麼辦三次握手，最後一次客戶端對伺服器的響應，如果失敗了，伺服器沒有收到，會產生什麼後果？DDOS攻擊TCP中的RST標誌(Reset)詳解TCP協議RST：RST介紹、什麼時候傳送RST包什麼是 DDoS 攻擊？HTTP和HTTPS協議，看一篇就夠了HTTP1.0和HTTP1.1和HTTP2.0的區別

1、HTTP

HyperText Transfer Protocol，用於傳輸HTML等內容的應用層協議，規定了瀏覽器和伺服器之間如何通訊以及通訊時的資料格式

HTTPS 原理 （HTTPS = HTTP + SSL)

Http 是明文傳輸，不安全，HTTPS 並不是新協議，而是讓 HTTP 先和 SSL（Secure Sockets Layer）通訊，再由 SSL 和 TCP 通訊，也就是說HTTPS 使用了隧道進行通訊。通過使用 SSL，HTTPS 具有了加密（防竊聽）、可靠認證（防偽裝）和完整性保護（防篡改）三大特點。SSL稱為安全套接字層，它位於傳輸層和應用層之間，為 Https 提供加密，認證，和完整性保護等服務。

HTTPS 採用的加密方式

HTTPS 採用混合的加密機制，使用非對稱金鑰加密傳輸對稱金鑰來保證傳輸過程的安全性，之後使用對稱金鑰加密進行通訊來保證通訊過程的效率。如果單獨使用非對稱祕鑰的話每次加密和解密的時間開銷太大，如果單獨使用對稱加密的話，可靠性不夠，容易被竊聽攔截後破解，所以同時使用對稱加密和非對稱加密。

HTTPS 建立連線的具體過程：

1. client向server傳送請求，然後連線到server的443埠，傳送的資訊主要是隨機值1和客戶端支援的加密演算法。2. server接收到資訊之後給予client握手資訊和數字證書，握手資訊包括隨機值2和匹配好的協商加密演算法，而數字證書就是公鑰。3. 客戶端解析證書，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨即值（預主祕鑰），接下來是通過隨機值1、隨機值2和預主祕鑰組裝會話祕鑰。然後通過證書的公鑰加密會話祕鑰。傳送這個會話祕鑰資訊。4. 服務端通過私鑰解密得到隨機值1、隨機值2和預主祕鑰，然後根據剛才協商好的加密演算法組裝成會話祕鑰。5. 客戶端通過會話祕鑰加密一條訊息傳送給服務端，主要驗證服務端是否正常接受客戶端加密的訊息。6. 同樣服務端也會通過會話祕鑰加密一條訊息回傳給客戶端，如果客戶端能夠正常接受的話表明SSL層連線建立完成了。

HTTPS 的缺點

• 因為需要進行加密解密等過程，因此速度會更慢；
  
• 需要支付證書授權的高額費用。
  

HTTP 和 HTTPS 的區別

1、HTTPS需要支付證書授權的高額費用

2、http是超文字傳輸協議，資訊是明文傳輸，https則是具有安全性的ssl加密傳輸協議。

3、http和https使用的是完全不同的連線方式，用的埠也不一樣，前者是80，後者是443。（這個只是預設埠不一樣，實際上埠是可以改的）

2、HTTP請求報文與響應報文格式

請求報文包含三部分：
a、請求行：包含請求方法、URI、HTTP版本資訊
b、請求首部欄位
c、請求內容實體
響應報文包含三部分：
a、狀態行：包含HTTP版本、狀態碼、狀態碼的原因短語
b、響應首部欄位
c、響應內容實體

3、Http協議中有哪些請求方式?

GET:用於請求訪問已經被URI(統一資源識別符號)識別的資源,可以通過URL傳參給伺服器

POST:用於傳輸資訊給伺服器,主要功能與GET方法類似,但一般推薦使用POST方式

PUT:傳輸檔案,報文主體中包含檔案內容,儲存到對應URI位置

HEAD:獲得報文首部,與GET方法類似,只是不返回報文主體,一般用於驗證URI是否有效

DELETE:刪除檔案,與PUT方法相反,刪除對應URI位置的檔案

OPTIONS:查詢響應URI支援的HTTP方法

4、在瀏覽器中輸入url地址 ->> 顯示主頁的過程(面試常客)

開啟一個網頁，整個過程會使用哪些協議

圖解（圖片來源：《圖解HTTP》）：

總體來說分為以下幾個過程:

1. DNS解析，將域名解析為ip地址，這個ip的查詢過程又分成三種情況：瀏覽器快取、路由器快取、DNS快取
2. TCP連線，用到了IP協議、OSPF協議、ARP協議
3. 傳送HTTP請求 ，用到了HTTP協議，瀏覽器將使用者的資料封裝到cookies中，並將cookie封裝到一個http請求中，如果網頁中存在多個url請求，會在本次tcp連線請求中發起多次http請求。
4. 伺服器處理請求並生成一個html響應，將這個響應封裝到一個http報文中並並返回HTTP報文
5. 瀏覽器解析渲染頁面
6. 連線結束

ARP(Address Resolution Protocol)是地址解析協議

5、一次tcp連線中可以傳送多少次 http 請求

如果是 http 1.0 則只能發一次，因為http1.0 是短連線，預設傳送一次 http 請求就會斷開連線，除非設定Connection: keep-alive如果是 http 1.1 則可以發多次，因為http1.1 是長連線，只有客戶端和伺服器有一個發出斷開連線的請求才會斷開連線。

6、HTTP1.0和HTTP1.1的區別

1. 長連線

HTTP1.0預設是短連線，傳送一次 http 請求就會斷開連線，除非設定Connection: keep-alive，而 在HTTP1.1中預設開啟長連線keep-alive，在一個TCP連線上可以傳送多個HTTP請求和響應，減少了建立和關閉連線的消耗和延遲。

2. 節約頻寬

HTTP 1.1 支援只發送header 資訊和斷點續傳功能。節約了頻寬。

3. HOST域

因為一個 iP 地址可能存在多臺虛擬主機，所以傳送請求時必須指明虛擬主機的主機號。

7、HTTP1.1 和 HTTP 2.0 的區別

1. 多路複用

HTTP2.0使用了多路複用的技術，做到同一個連線併發處理多個請求

2. 頭部壓縮

HTTP1.1不支援header資料的壓縮，只會壓縮訊息主題，HTTP2.0支援對header的資料進行壓縮，這樣資料體積更小了，在網路上傳輸就會更快。

3. 伺服器推送

也就是我們常說的預載入功能，允許伺服器將當前網頁所用的其他資源提前載入到瀏覽器，而不必等我們點選這個資源時再發起請求。這樣可以降低延遲。

8、TCP三次握手

• 客戶端–傳送SYN標誌位為 1 ， 序列號為 x 的資料包–一次握手–服務端，客戶端進入同步傳送狀態
• 服務端–傳送帶有 SYN/ACK 標誌的資料包–二次握手–客戶端，服務端進入同步接收狀態
• 客戶端–傳送帶有帶有 ACK 標誌的資料包–三次握手–服務端，客戶端進入連線狀態，服務端收到這個確認報文後也進入連線狀態。

為什麼要三次握手，兩次可以嗎？

第三次握手的過程是客戶端對伺服器傳送的確認連線進行確認，是為了防止失效的連線請求到達伺服器後，讓伺服器錯誤開啟連線。客戶端傳送的連線請求如果在網路中滯留，那麼就會隔很長一段時間才能收到伺服器端發回的連線確認。客戶端等待一個超時重傳時間之後，就會重新請求連線。但是這個滯留的連線請求最後還是會到達伺服器，如果不進行三次握手，每當伺服器收到一個請求傳送確認後就開啟連線，那麼伺服器就會開啟兩個連線。如果有第三次握手，在已經建立連線的情況下，客戶端會忽略伺服器之後傳送的對滯留連線請求的連線確認，不進行第三次握手，因此就不會再次開啟連線。

如果第三次握手失敗，即客戶端傳送的 ASK 確認包丟失怎麼辦

如果此時ACK在網路中丟失，那麼Server端該TCP連線的狀態為SYN_RECV，並且依次等待3秒、6秒、12秒後重新發送SYN+ACK包，以便Client重新發送ACK包。Server重發SYN+ACK包的次數，可以通過設定/proc/sys/net/ipv4/tcp_synack_retries修改，預設值為5。 如果重發指定次數後，仍然未收到ACK應答，那麼一段時間後，Server自動關閉這個連線。但是Client認為這個連線已經建立，如果Client端向Server寫資料，Server端將以RST包(用於強制關閉tcp連線)響應，方能感知到Server的錯誤。RST是TCP 首部的一個志位，表示復位，用來異常的關閉連線，只要傳送端覺得連線異常就會發送 RST 包，接收端收到這個包後就會馬上斷開連線。

什麼是 syn - Flood 攻擊

攻擊方通過頻繁的切換ip或者利用大量的 ip 向伺服器發起大量的半連線請求，每次連線都只完成第二次握手，從而讓伺服器頻繁的重發連線確認，大量的半連線資訊將消耗伺服器大量的系統資源和網路頻寬，這樣伺服器就多餘的資源接收正常客戶的請求

解決辦法：

• 縮短超時（SYN Timeout）時間
• 增加最大半連線數
• 過濾閘道器防護

目前最流行也是最好用的攻擊方法就是使用SYN-Flood進行攻擊，SYN-Flood也就是SYN洪水攻擊。SYN-Flood不會完成TCP三次握手的第三步，也就是不傳送確認連線的資訊給伺服器。這樣，伺服器無法完成第三次握手，但伺服器不會立即放棄，伺服器會不停的重試並等待一定的時間後放棄這個未完成的連線，這段時間叫做SYN timeout，這段時間大約30秒-2分鐘左右。一個伺服器若是處理這些大量的半連線資訊而消耗大量的系統資源和網路頻寬，這樣伺服器就不會再有空餘去處理普通使用者的正常請求(因為客戶的正常請求比率很小)。這樣這個伺服器就無法工作了。

如果已經建立了連線，但是客戶端突然出現故障了怎麼辦？

TCP還設有一個保活計時器，。伺服器每收到一次客戶端的請求後都會重新復位這個計時器，時間通常是設定為2小時，若兩小時還沒有收到客戶端的任何資料，伺服器就會發送一個探測報文段，以後每隔75秒鐘傳送一次。若一連發送10個探測報文仍然沒反應，伺服器就認為客戶端出了故障，接著就關閉連線。

9、TCP四次揮手過程

A 傳送 FIN 標誌位為 1， 序列號為 u 的連線釋放報文，進入等待fin 報文的第一個階段B 收到之後發出確認，此時 TCP 屬於半關閉狀態，客戶端在收到這個確認進入 等待 Fin 報文的第二個階段。B 能向 A 傳送資料但是 A 不能向 B 傳送資料。當 B 不再需要連線時，傳送連線釋放報文，FIN=1。服務端進入最後確認階段A 收到後發出確認，進入 TIME-WAIT 狀態，等待 2 MSL（最大報文存活時間）後釋放連線。B 收到 A 的確認後釋放連線。

為什麼需要第四次揮手--（防止出現單方向沒有釋放連線）

假設只有三次揮手，也就是說服務端在傳送完資料就向客戶端傳送一個帶有 FIN 訊號的報文，之後服務端徹底關閉連線，但是如果這個 FIN 報文丟失了，客戶端沒有收到這個報文， 客戶端就會以為服務端仍有資料要傳送，不會關閉連線。所以我們需要第四次揮手，讓客戶端收到 FIN 報文後傳送一個確認報文，確認自己收到了關閉的訊號，這樣服務端在收到這個報文後就可以徹底關閉連線了。

TIME_WAIT

客戶端接收到伺服器端的 FIN 報文後進入此狀態，此時並不是直接進入 CLOSED 狀態，還需要等待一個時間計時器設定的時間 2MSL。這麼做有兩個理由：

• 確保最後一個確認報文能夠到達。如果 B 沒收到 A 傳送來的確認報文，那麼就會重新發送連線釋放請求報文，A 等待一段時間就是為了處理這種情況的發生。
  
• 等待一段時間是為了讓本連線持續時間內所產生的所有報文都從網路中消失，使得下一個新的連線不會出現舊的連線請求報文。因為報文段有生存時間，當連線關閉時，有可能收到遲到的報文段。這時，若立馬就建立新的連線（同一埠），那麼新的連線就會接收遲到的報文，誤以為是發給自己的。

參考：TCP連線狀態與2MSL等待時間

如何統計time_wait的次數

兩種方式，awk語句或者netstat｜greptime_wait｜wc-l

MSL

MSL是Maximum Segment Lifetime英文的縮寫，中文可以譯為“報文最大生存時間”，他是任何報文在網路上存在的最長時間，超過這個時間報文將被丟棄。因為tcp報文（segment）是ip資料報（datagram）的資料部分，具體稱謂請參見《資料在網路各層中的稱呼》一文，而ip頭中有一個TTL域，TTL是time to live的縮寫，中文可以譯為“生存時間”，這個生存時間是由源主機設定初始值但不是存的具體時間，而是儲存了一個ip資料報可以經過的最大路由數，每經過一個處理他的路由器此值就減1，當此值為0則資料報將被丟棄，同時傳送ICMP報文通知源主機。RFC 793中規定MSL為2分鐘，實際應用中常用的是30秒，1分鐘和2分鐘等。來源：https://blog.csdn.net/xiaofei0859/article/details/6044694

CLOSE_WAIT

伺服器收到客戶端傳送來的 釋放連線訊號後，對這個訊號進行確認，隨後進入這個CLOSE_WAIT半關閉狀態，此時服務端可以繼續 向客戶端傳送資料，但是客戶端不能向服務端傳送資料。

10、TCP有哪些特性保證了其可靠性，其中哪一個可以去掉

TCP協議保證資料傳輸可靠性的方式主要有：

校驗和、序列號、確認應答、超時重傳、連線管理、流量控制、擁塞控制

• 校驗和：保證資料的正確性
• 序列號：保證了針對資料包到達接收端主機順序

確認應答和超時重傳保證了 tcp 的可靠傳輸，連線管理中的三次握手和四次揮手保證了連線的正確建立和釋放，流量控制和擁塞控制保證了客戶端或者服務端能夠來得及接受資料，並且不會出現網路擁堵。

• 確認應答：停止等待協議，傳送之後等待收到應答。

• 超時重傳：針對資料包丟失或者出現定時器超時
• 連線管理：三次握手與四次揮手
• 流量控制：針對避免網路擁堵時候；針對高效傳輸資料包的流動視窗的控制
• 擁塞控制：針對剛開始啟動的時候避免一下子傳送大量資料包而導致網路癱瘓的慢啟動演算法和擁塞控制。

哪一個可以去掉

擁塞控制可以去掉，因為在頻寬較大，網路資源豐富時，流量控制已經約束了傳送的速率，基本上不會造成網路擁塞。

11、是什麼保證了TCP的 可靠傳輸

TCP 使用確認重傳來實現可靠傳輸：如果一個已經發送的報文段在超時時間內沒有收到確認，那麼就重傳這個報文段。

12、路由協議

自治系統內部的路由選擇：RIP 和 OSPF自治系統間的路由選擇：BGP

1. 內部閘道器協議 RIP（路由資訊協議）

RIP 是一種基於距離向量的路由選擇協議。距離是指跳數，直接相連的路由器跳數為 1。跳數最多為 15，超過 15 表示不可達。RIP 按固定的時間間隔僅和相鄰路由器交換自己的路由表，經過若干次交換之後，所有路由器最終會知道到達本自治系統中任何一個網路的最短距離和下一跳路由器地址。RIP 協議實現簡單，開銷小。但是 RIP 能使用的最大距離為 15，限制了網路的規模。並且當網路出現故障時，要經過比較長的時間才能將此訊息傳送到所有路由器。

2. 內部閘道器協議 OSPF

開放最短路徑優先 OSPF，是為了克服 RIP 的缺點而開發出來的。最短路徑優先表示使用了 Dijkstra 提出的最短路徑演算法SPF。所有路由器都具有全網的拓撲結構圖，並且是一致的。相比於 RIP，OSPF 的更新過程收斂的很快。

3. 外部閘道器協議 BGP

BGP（Border Gateway Protocol，邊界閘道器協議）AS 之間的路由選擇很困難，主要是由於：網際網路規模很大；各個 AS 內部使用不同的路由選擇協議，無法準確定義路徑的度量；AS 之間的路由選擇必須考慮有關的策略，比如有些 AS 不願意讓其它 AS 經過。BGP 只能尋找一條比較好的路由，而不是最佳路由。每個 AS 都必須配置 BGP 發言人，通過在兩個相鄰 BGP 發言人之間建立 TCP 連線來交換路由資訊。

13、擁塞控制，什麼時候知道網路擁塞？

擁塞控制

慢開始演算法、擁塞避免、快速重傳、快速恢復

1. 慢開始與擁塞避免

傳送的最初執行慢開始，令 cwnd = 1，傳送方只能傳送 1 個報文段；當收到確認後，將 cwnd 加倍，因此之後傳送方能夠傳送的報文段數量為：2、4、8 ...注意到慢開始每個輪次都將 cwnd 加倍，這樣會讓 cwnd 增長速度非常快，從而使得傳送方傳送的速度增長速度過快，網路擁塞的可能性也就更高。設定一個慢開始門限 ssthresh，當 cwnd >= ssthresh 時，進入擁塞避免，每個輪次只將 cwnd 加 1。如果出現了超時，則令 ssthresh = cwnd / 2，然後重新執行慢開始。

2. 快重傳與快恢復

在接收方，要求每次接收到報文段都應該對最後一個已收到的有序報文段進行確認。在傳送方，如果收到三個重複確認，那麼可以知道下一個報文段丟失，此時執行快重傳，立即重傳下一個報文段。例如收到三個 M 2 ，則 M 3 丟失，立即重傳 M3 。快恢復指的是發生快重傳之後不必進入慢開始狀態，而是將傳送視窗減半，直接開始擁塞避免。慢開始和快恢復的快慢指的是 cwnd 的設定值，而不是 cwnd 的增長速率。

流量控制：

流量控制是為了控制傳送方傳送速率，保證接收方來得及接收。通過滑動視窗機制可以實現這個傳送速率的控制，傳送視窗大小不能大於接受視窗，動態的改變視窗的大小，從而影響傳送方的傳送速率。將視窗欄位設定為0，則傳送方不能傳送資料。可以通過持續計數器和傳送探測報文可以打破僵。

什麼時候知道網路擁塞

通過觀察網路的吞吐量與網路負載間的關係

如果隨著網路負載的增加，網路的吞吐量明顯小於正常的吞吐量，那麼網路就進入輕度擁塞的狀況。

如果網路得吞吐量隨著網路負載的增大反而下降，那麼網路就可能進入擁塞狀態。

14、UDP 和 TCP 的區別和特點

使用者資料報協議 UDP（User Datagram Protocol）是無連線的，盡最大可能交付，沒有擁塞控制，面向報文（對於應用程式傳下來的報文不合並也不拆分，只是新增 UDP 首部），支援一對一、一對多、多對一和多對多的互動通訊。傳輸控制協議 TCP（Transmission Control Protocol）是面向連線的，提供可靠交付，有流量控制，擁塞控制，提供全雙工通訊，面向位元組流（把應用層傳下來的報文看成位元組流，把位元組流組織成大小不等的資料塊），每一條 TCP 連線只能是點對點的（一對一）。之所以只能是一對一，我覺得可能是如果支援多播的話，那因為確認應答和超時重傳機制，每次接收方都對傳送發的資料進行確認應答，而如果一定時間沒有收到接收方的確認，傳送方也需要超時重傳，這樣如果在多播的情況下，如果有一個接收方因為各種原因沒有傳送應答訊號，可能會影響整個多播網路的訊息傳輸

tcp 和 udp 別適合什麼應用？聊天要用什麼？

TCP 應用於對效率要求相對低，但對準確性要求相對高；或者是有連線的場景 如：檔案傳輸，傳送郵件，遠端登入UDP 應用於對效率要求相對高，對準確性要求相對低的場景，比如：

1. 即時通訊（QQ聊天，對資料準確性和丟包要求比較低，但速度必須快）；

2、線上視訊（RTSP 速度一定要快，保證視訊連續，但是偶爾花了一個影象幀，人們還是能接受的）

3、網路語音電話（VoIP 語音資料包一般比較小，需要高速傳送，偶爾斷音或串音也沒有問題）等等

參考：TCP和UDP的區別分析和應用場景

15、HTTP狀態碼

http的狀態碼：伺服器返回的 響應報文 中第一行為狀態行，包含了狀態碼以及原因短語，用來告知客戶端請求的結果。100：continue，表示到目前位置都很正常，可以繼續請求或者忽略這個迴應。200：OK204：No content：請求已經成功處理，但是響應不包含主體部分。206：partial content：返回請求的範圍部分301：move permanently：永久性重定向，一般是資源（網頁等）被永久轉移到其它URL302：found：臨時性重定向，一般是資源臨時移動303：see other:和302類似，但是明確要求用GET304：not modified；請求首部包含一些條件，不滿足則返回304307：和302類似，但是明確要求瀏覽器不將POST變為GET400：bad request:請求報文中存在語法錯誤，多半是前端提交的欄位名稱或者欄位型別和後臺的實體類不一樣，或者前端提交的引數跟後臺需要的引數個數不一致，導致無法封裝。401：unauthorized:表示請求需要有認證資訊，如果已經請求過一次了，則說明認證失敗。403：forbidden:請求被拒絕，通常原因是伺服器上某些檔案或目錄設定了許可權，客戶端許可權不夠404：not found:使用者輸入錯誤的連結，該連結指向的網頁不存在。除此之外，也可以在伺服器端拒絕請求且不想說明理由時使用。405: method not allowed:方法不允許500: Internal serval error:伺服器處理請求時發生錯誤,伺服器內部錯誤（比如瀏覽器代理除了問題，ip，埠不對等）該狀態碼錶明伺服器端在執行請求時發生了錯誤。也有可能是Web應用存在的bug或某些臨時的故障。503: server unavarilable：伺服器負載過大或者正在維護。504，Gateway Timeout閘道器超時 伺服器作為閘道器或代理，未及時從上游伺服器接收請求。

16、get 和 post 的區別

以前我看在書上看到的區別的是：

• GET引數通過URL傳遞，而URL 中傳送的引數是有長度限制的，POST放在Request body中，大小沒有限制。
• GET比POST更不安全，因為引數直接暴露在URL上，所以不能用來傳遞敏感資訊。
• 對引數的資料型別，GET只接受ASCII字元，而POST沒有限制。
• GET請求會被瀏覽器主動cache，而POST不會，除非手動設定。
• GET請求引數會被完整保留在瀏覽器歷史記錄裡，而POST中的引數不會被保留。
• GET是冪等的，執行多少遍不影響最終儲存的結果。而post每次呼叫都會建立新的資源。
• GET常用於獲取資源的請求 、POST常用於修改伺服器資源的請求

但是我又看到網上部落格說它們的本質都是 TCP 連結，並無區別。但是由於 HTTP 的規定以及瀏覽器/伺服器的限制，導致它們在應用過程中可能會有所不同。

get請求冪等性

get/post 以及冪等性

17、虛擬專用網 VPN

由於 IP 地址的緊缺，一個機構能申請到的 IP 地址數往往遠小於本機構所擁有的主機數。並且一個機構並不需要把所有的主機接入到外部的網際網路中，機構內的計算機可以使用僅在本機構有效的 IP 地址（專用地址）。有三個專用地址塊：10.0.0.0 ~ 10.255.255.255172.16.0.0 ~ 172.31.255.255192.168.0.0 ~ 192.168.255.255VPN 使用公用的網際網路作為本機構各專用網之間的通訊載體。專用指機構內的主機只與本機構內的其它主機通訊；虛擬指好像是，而實際上並不是，它有經過公用的網際網路。

網路地址轉換 NAT

專用網內部的主機使用本地 IP 地址又想和網際網路上的主機通訊時，可以使用 NAT 來將本地 IP 轉換為全球 IP

18、Socket

(1)服務端如何起一個Socket服務

(2)如何限制Socket的最大連線數-設定一個集合和count變數-這個集合用什麼資料結構比較好

(3)Client發起連線請求是怎樣的，何時才能發起請求

19、session 和 cookie 的區別：

HTTP是一種無狀態的協議，為了分辨連線是誰發起的，需自己去解決這個問題。不然有些情況下即使是同一個網站每開啟一個頁面也都要登入一下。而Session和Cookie就是為解決這個問題而提出來的兩個機制。

區別：

• 儲存資料量方面：session 能夠儲存任意的 java 物件，cookie 只能儲存 String 型別的物件且單個cookie 能夠儲存的資料 <= 4KB，大小限制是因為cookie需要在伺服器和瀏覽器之間傳遞，如果大小太大會影響效能
  
• 一個在客戶端一個在服務端。因Cookie在客戶端所以可以編輯偽造，不是十分安全。所以不是很隱私的資料才會存在cookie中
  
• Session過多時會消耗伺服器資源，大型網站會有專門Session伺服器，Cookie存在客戶端沒問題。比較隱私的資料都存在session中
  
• 域的支援範圍不一樣，Cookie支援跨域訪問，但是 Session 不支援跨域訪問。比方說a.com的Cookie在a.com下都能用，而www.a.com的Session在api.a.com下都不能用，解決這個問題的辦法是JSONP或者跨域資源共享/

20、DNS 域名系統(Domain Name System)

把網址轉換成 ip 地址

域名伺服器的結構：

根域名伺服器，頂級域名伺服器， 許可權域名伺服器，本地域名伺服器

域名查詢的方式：

1. 迭代查詢2. 遞迴查詢