P即為無線存取橋接器（Access Point）簡稱，中文譯為“無線訪問節點”，它主要是提供無線工作站對有線局域網和從有線局域網對無線工作站的訪問，在訪問接入點覆蓋范圍內的無線工作站可以通過它進行相互通信。AP 可以連接到有線網絡，實現無線網絡和有線網絡的互聯，通俗的講，無線AP是無線網和有線網之間溝通的橋梁，AP是組建WLAN的核心設備，在AP信號覆蓋范圍內的無線工作站可以通過它進行相互通信，沒有AP基本上就無法組建真正意義上可訪問Internet的WLAN，AP在WLAN中就相當于發射基站在移動通信網絡中的角色。
1
根據AP的功用不同，WLAN（無線局域網）可以根據用戶的不同網絡環境的需求, 實現不同的組網方式。目前市場上的AP可支持以下五種無線AP工作模式。
一、無線AP的五種工作模式主要有以下：
1、AP模式：無線客戶端接入, IP由路由器的DHCP分配
2、WDS模式(無線分布式系統/無線橋接模式)：通過無線連接有線網絡,不提供無線客戶端接入, 所有AP在同一網絡,IP由路由器的DHCP分配。
（1）WDS分類：
A:WDS-P2P模式（無線點對點橋接模式）
B:WDS-P2MP模式（無線點對多點橋接模式）
（2）WDS+AP模式：連接多個無線網絡,提供無線客戶端接入,所有AP在同一個網絡中, IP由無線路由器的DHCP分配或AP自己的DHCP分配,只需其中一個AP開啟DHCP。
2
3、WISP(無線互聯網服務提供商)
WISP用于將自己無線設備的wan口通過無線連接對方的無線,從而上網.LAN口IP由自己的DHCP分配,不用在對方路由器上設置自己的Mac地址,自己有路由功能。
4、Repeater模式（無線中繼器模式）：無線信號由無線路由器提供,延伸無線信號,無線客戶端接入, IP由無線路由器的DHCP分配。
5、APClient模式（AP客戶端模式或Wireless Client）：AP Client端的用戶為有線接入,IP由路由器的DHCP分配,用于將有線網絡通過無線接入另外的網絡
總結：
有DHCP功能的是：WDS+AP,WISP
有路由器功能的是：WISP
3
二、五種工作模式的應用
1、無線接入點（AP）模式
在此模式下，該設備相當于一臺無線交換機.可實現無線之間、無線到有線、無線到廣域網絡的訪問。最常見的能夠提供無線客戶端的接入，例如：無線網卡接入等。
4
AP模式可以簡單的把有線的網絡傳輸轉換為無線傳輸，如果您已經有了一臺有線路由器，又想使用無線網絡的話，那么這種方式剛好符合您的要求。
2、WDS模式
WDS模式各設備之間通過MAC地址來互相連接,且要求SSID、信道、密碼、加密方式相同。
（1）WDS點對點橋接（WDS-P2P）模式
兩個有線局域網之間，通過兩臺無線AP將它們連接在一起，可以實現兩個有線局域網之間通過無線方式的互連和資源共享，也可以實現有線網絡的擴展。此種模式下AP不支持無線客戶端的接入，只能作為無線網橋使用。
5
（2）WDS點對多點橋接（WDS-P2MP）模式
點對多點的無線網橋能夠把多個離散的有線網絡連成一體，結構相對于點對點無線網橋來說較復雜。點對多點無線橋接通常以一個網絡為中心點發送無線信號，其他接收點進行信號接收。（一般AP在點對多點橋接模式時，最多支持4個遠程點的接入），此模式下，不支持無線客戶端的接入。
6
點對多點模式可以將多個有線局域網通過無線AP連接起來，而不用使用到網線，這應用于需要進行數據連接而又不方便布線的網絡環境； 若“根AP”設置為點對多點模式，其它（最多支持4個）遠端AP必須設置為點到點模式。
3、WISP模式
WISP用于將自己的無線設備的wan口通過無線連接對方的無線,從而上網.LAN口IP由自己的DHCP分配。
WISP與WDS的區別是:WISP不用在對方路由器上設置自己的Mac地址
WDS要在對方路由器或AP上設置自己的Mac地址。
4、無線中繼器（Repeater）模式
中繼器模式可以實現信號的中繼和放大, 從而延伸無線網絡的覆蓋范圍。可適用于那些場地相對開闊、不便于鋪設以太網線的場所。此模式下，可以同時支持無線客戶端的接入。
7
AP的無線中繼方式：各設備之間可以通過MAC地址來互相連接。當兩個局域網絡間的距離超過無線局域網產品所允許的最大傳輸距離，或者在兩網絡之間有較高或較大干擾的障礙物存在時，便可以采用無 線中繼方案。
8
5、無線客戶端（Client）模式
在此模式下,各設備之間通過MAC地址來互相連接，通過該設備的LAN口連接到有線網卡的以太網接口,此設備可當作無線網卡使用。當您選擇此種方式時，您必須使用有線網卡或通過有線網絡連到您的設備，因為此種方式下設備將被當成一塊無線網卡使用，請設置該設備與您使用的網絡在同一個網段。
9
如果遇到布線問題，未能將ADSL MODEM和無線放置到理想的位置，又不想拉網線的話，可以通過W300A的基礎結構模式（把該設備當作一片無線網卡來使用）來連接無線AP或無線，這種方式便可以滿足您的需求。
三、無線AP網絡組網方式詳解
無線局域網的組網模式大致上可以分為兩種，一種是Ad－hoc模式，即點對點無線網絡；另一種是Infrastructure模式，即集中控制式網絡。
10
1、Ad－hoc模式
Ad-hoc網絡是一種點對點的對等式移動網絡，沒有有線基礎設施的支持，網絡中的節點均由移動主機構成。網絡中不存在無線AP，通過多張無線網卡自由的組網實現通信。基本結構如下圖所示：
11
要建立對等式網絡需要完成以下幾個步驟：
1）首先為您的電腦安裝好無線網卡，并且為您的無線網卡配置好IP地址等網絡參數。注意，要實現互連的主機的IP必須在同一網段，因為對等網絡不存在網關，所以網關可以不用填寫。
2）設定無線網卡的工作模式為Ad-hoc模式，并給需要互連的網卡配置相同的SSID、頻段、加密方式、密鑰和連接速率。
2、Infrastructure模式
集中控制式模式網絡，是一種整合有線與無線局域網架構的應用模式。在這種模式中，無線網卡與無線AP進行無線連接，再通過無線AP與有線網絡建立連接。實際上Infrastructure模式網絡還可以分為兩種模式，一種是無線路由器+無線網卡建立連接的模式；一種是無線AP與無線網卡建立連接的模式。
12
“無線路由器+無線網卡”模式是目前很多家庭都使用的模式，這種模式下無線路由器相當于一個無線AP集合了路由功能，用來實現有線網絡與無線網絡的連接。例如我司的無線路由器系列，它們不僅集合了無線AP功能和路由功能，同時還集成了一個有線的四口交換機，可以實現有線網絡與無線網絡的混合連接，如下圖所示：
13
另一種是“無線AP加無線網卡”模式。在這種模式下，無線AP應該如何設置，應該如何與無線網卡或者是有線網卡建立連接，主要取決于您所要實現的具體功能以及您預定要用到的設備。因為無線AP有多種工作模式，不同的工作模式它所能連接的設備不一定相同，連接的方式也不一定相同。下面是我司的無線AP TL-WA501G（以下簡稱為501G）的工作模式及其設置。我們的501G支持5種基本的工作模式，分別是：AP模式、AP client模式、repeater模式、Bridge(Point to Point)模式和Bridge(Point to Multi-Point)模式。
1）AP模式
AP（Access Point，接入點模式），這是我們無線AP的基本工作模式，用于構建以無線AP為中心的集中控制式網絡，所有通信都通過AP來轉發，類似于有線網絡中的交換機的功能。這種模式下連接方式大致如下圖所示：
14
在這種模式下，無線AP即可以和無線網卡建立無線連接，也可以和有線網卡通過網線建立有線連接。我們的501G只有一個LAN口，一般不用它來直接接電腦，而是用來與有線網絡建立連接，直接連接前端的路由器或者是交換機。這種模式下，對我們的501G的設置具體的如下圖所示：
15
首先是設置該網絡工作的頻段，選擇的范圍從1到13。選擇中應該注意的是，如果周圍環境中還有其他的無線網絡，盡量不要與它使用相同的頻率段。然后選擇501G工作的模式，我們的501G支持11Mbps帶寬的802.11b、54Mbps帶寬的802.11g模式（兼容802.11b模式）。同時注意開啟無線功能，就是不要選中‘關閉無線功能’的這個選項即可。選中‘Access Point’選項，設置好SSID號即可。注意，通過無線方式與我們的無線AP建立連接的無線網卡上設置的SSID號必需與我們無線AP上設置的SSID號相同，否則無法接入網絡。
2)AP客戶端模式
AP client模式下，即可以有線接入網絡也可以無線接入網絡，但此時接在無線AP下的電腦只能通過有線的方式進行連接，不能以無線方式與AP進行連接。工作在AP client模式下的無線AP建立連接的方式大致的如下圖所示：
16
圖中的無線設備A ，即可以是無線路由器，也可以是無線AP。當需要用我們的501G與我們的無線路由器建立無線連接時，在無線AP上的設置如下圖所示：
17
在client模式下，可以有兩種方式使無線AP接入前端的無線路由器，一種就是通過設置和無線路由器相同的SSID號，從而連接無線路由器；另一種就是通過在‘AP的MAC地址’處填寫無線路由器的LAN口的MAC地址來建立連接。
● 開啟WDS功能 - 如果開啟WDS，將使用4地址包格式與AP通信，否則使用3地址包格式。（主要考慮與前端無線路由器的兼容性）
● SSID - 指定SSID來選擇AP。
● AP的MAC地址 - 指定MAC地址來接入AP。
說明：當前我公司的無線路由器都支持WDS，所以在WA501G上，是否關閉WDS都可以連接上。
當我們工作在AP client模式下的無線AP再與另外的無線AP建立連接時，連接的無線AP可以是AP模式，也可以是中繼了前端信號的repeater模式。當前端的AP設置為repeater模式時，它并沒有SSID號，因此，我們設置為AP client的無線AP要與它建立連接，只能通過在‘AP的MAC地址’欄中填寫前端AP的MAC地址來實現連接。
3）Bridge(Point to Point)模式
當前無線網橋模式下，無線AP既可以通過無線的方式與無線網卡進行連接，也能使用無線AP的LAN口有線的連接電腦。在這種模式下使用時，一般都是兩個AP都設置為橋接模式來進行對連，其效果就相當于一根網線將兩者的LAN口相連。具體的如下圖所示的連接：
18
設置成橋接模式的無線AP可以啟用自身的AP功能來連接無線工作站，同時也可以通過指定要接入的AP的MAC地址來進行橋接，界面如下圖所示：
19
在要通過橋模式來進行連接的兩個無線AP，設置好對端AP的MAC地址來與對端的AP來進行連接。設置中需要注意的是，兩個無線AP必須設置相同的工作頻段，否則可能無法進行連接。當然在無論在路由器還是WA501G+中設置，都需要考慮整個網絡的網關、DHCP服務器等問題。
4）Bridge(Point to Multi-Point)模式
無線多路橋模式下，無線AP最多可以與4個設置成橋接模式的AP配合使用，組建點對多點的無線網絡，其自身也可以開啟AP功能。基本模式如下圖所示：
20
圖中有三個無線AP，分別為A、B、C。其中A和C都設置成橋接模式，B號無線AP設置為多路橋接模式，在A和C號無線AP上都要設置成指向B，即填入B號無線AP的MAC地址，在B號無線AP上同時要添加A和C號無線AP的MAC地址，從而建立連接。設置成多路橋模式的無線AP中，有多個填寫MAC地址的欄目需要填寫，如果填寫的條目少于兩條，那么在保存時將會報錯。也就是說當無線AP設置成多路橋模式時，至少要與另外的兩個無線AP進行連接。我們的501G的多路橋模式下，最多可以同時與四個無線AP進行連接。如果開啟AP功能，B下還可以連接無線工作站。其設置界面如下圖所示：
21
5）repeater模式
無線中繼模式下的無線AP 起到的作用是對信號的放大和重新發送，因此它可以與設置成AP模式的無線AP來進行連接并對它的信號進行中繼。Repeater模式的無線AP還可以與同樣設置成repeater模式的無線AP進行連接。如下圖所示：
22
Repeater模式的無線AP主要是用來擴大無線網絡的覆蓋范圍。在上圖中假設B和D下面的電腦要相互通信，可是B的信號無法到達D，因此我們可以在中間加一個無線AP對B的信號進行中繼，從而實現B和D的通信。我們可以把B設置為AP模式，把C設置為對B的中繼，再把D設置為對C的中繼，從而使B和D實現通信。把C設置成對B的中繼，只要把B的MAC地址填入C的‘AP的MAC地址’欄內即可。如下圖所示：
23
● Universal 模式是指使用非WDS模式與AP通訊，具有更廣泛的兼容性。
目前，無線網絡已經成為現代化時尚辦公的新寵，但是單個AP的覆蓋面積有限，因此一些覆蓋面積較大的公司往往會安置兩個或者是兩個以上的無線AP以擴大無線網絡覆蓋的范圍。但是會遇到這樣的問題，就是當移動的用戶在不同的無線AP之間切換時每次都要查找無線網絡，重新進行連接，非常麻煩。這種情況下，我們就引入了無線漫游這樣一個新概念。
無線信號在傳播的過程中會不斷的衰減，導致AP的通訊范圍被限定在一定的范圍之內。這個范圍通常被稱為微單元，當網絡環境中存在多個無線AP，并且使他們的微單元相互有一定范圍的重合時，無線用戶可以在整個無線信號覆蓋的范圍內進行移動，無線網卡能夠自動發現附近信號強度最大的無線AP，并通過這個AP來收發數據，保持不間斷的網絡連接，這就稱為無線漫游。
在實際應用中，無線有時只有一個出口，這樣就如下面的應用。如下圖所示是4個無線AP組成的無縫漫游網絡，四個無線AP分別通過網線與有線網絡相連，形成以有線網絡為基礎的無線網絡，所有終端通過最近的無線AP連入網絡，實現對整個網絡資源的訪問。要實現無縫漫游，首先我們必須給每個無線AP分配好IP地址，并且保證所有無線AP的IP地址都在同一網段。每個無線AP都設置成AP模式，并且所設置的SSID必須相同。如果要設置加密，那么無線AP的加密方式和加密的密鑰也必須相同。并且最好只保留上游無線路由器中的DHCP功能，關閉無線AP的DHCP功能，否則會導致IP地址分配混亂。
24
在圖中我們可以看到，要實現漫游，無線AP的覆蓋范圍有一部分是相互重疊的，如果覆蓋范圍重疊的無線AP之間使用了有信號重疊的信道，那么它們的信號在傳輸時就會相互干擾，從而降低網絡性能和效率。因此各個AP的覆蓋區域所占信道之間必須遵循一定的規范，覆蓋范圍有重疊的AP不能使用相同的信道。802.11b協議工作在2.4000GHz~2.4835GHz信道上，一共存在著相互重疊的11個信道，在這11個信道中只有三個信道是不重疊的，分別是信道1、6、11，如下圖所示：
25
因此，無縫漫游時使用這三個信道是最合適的。我們如果配置簡單的無線漫游，則只需要該漫游區域為各無線AP的重合區域，并且各AP的SSID號，加密方式一致即可。
四、無線網絡中的術語
網絡模式：可以選擇以下一種模式，默認為11b/g/n模式；
11b模式：可以允許無線客戶端以11b模式下速率連接AP，最大支持速率為11Mbps；
11g模式：可以允許11g或11n無線客戶以11g模式下速率連接AP，最大支持速率為54Mbps；
11b/g模式：可以允許11b/11g無線客戶端以自適應的速率接入AP，允許11n無線客戶端以11g模式下速率接入AP。
11b/g/n模式：允許所有模式下的客戶端接入AP，自適應連接速率。
SSID(服務集標識符),分為BSSID(AP的Mac地址)和ESSID(無線網絡名稱,在沒有嚴格區分的話也叫SSID)
主SSID：主服務集標識，即設備在無線網絡中名稱標識。本AP支持同時支持兩個SSID，主SSID是必須的。
次SSID：次絡服務集標識，即設備在無線網絡中名稱標識。次SSID可選。
廣播（SSID）：選定關閉SSID廣播功能，AP將不再廣播自己的SSID號，如果有無線連接請求則需手動填寫SSID號。
MBSSID AP 隔離：基于無線MAC地址的訪問控制功能，啟用此功能后，連接到同一SSID的無線客戶端之間不能互相訪問。例如：設置本AP的主SSID與次SSID分別為AP1、AP2， 計算機PC1、PC2使用無線網卡都連接到AP1， 并設置PC1、PC2在同一網段內，啟用此功能后，兩臺計算機將不能互相通訊，但可以與連接到AP2的無線客戶端進行通訊，此功能實現連接到同一SSID的無線客戶端通訊隔離。
AP 隔離：基于SSID的訪問控制功能，連接到主SSID與次SSID的無線客戶端之間不能互相訪問，使用此功能可以進一步增強無線網絡安全。例如：設置主SSID、次SSID分別為AP1、AP2后，PC1通過無線網卡連接到AP1，PC2通過無線網卡連接到PC2后，啟用此功能后，兩臺PC之間就不能進行互相通訊。此功能實現連接到不同SSID的無線客戶端通訊隔離。
如果要實現連接到AP上所有的無線客戶端之間的通訊隔離功能，請同時啟用MBSSID AP隔離、AP隔離功能。
BSSID：無線AP的MAC地址
信道：用于確定本無線網絡工作的有效信道段，選擇范圍從1到13或是自動選擇。
擴展信道：為了增大無線網絡的數據吞吐量，在使用11n模式時無線網絡使用的擴展信道段。
安全設置：此欄用于設置AP網絡的無線安全。和無線路由器部分安全設置相同，
加密方式（由低到高）:WEP、WPA-PSK、WPA-PSK2
加密算法（由低到高）:WEP、TKIP、AES
WEP加密設置項說明
WEP 密鑰：可以設置ASCII碼，十六進制兩種格式的WEP密鑰。可以選擇ASCII碼（5或13個ASCII，禁止輸入 “/” 等非法字符）或者16進制數字符（10或26個16進制數）。
默認密鑰： 可以從預先設置好的4組密鑰中選擇其一作為當前有效密鑰。
TKIP加密設置項說明
加密密鑰：請輸入您想使用的加密字符串，密鑰字符為8到63個ASCII碼字符。
AES加密設置項說明
加密密鑰：請輸入您想使用的加密字符串，密鑰字符為8到63個ASCII碼字符。
AP MAC地址：填入要連接遠端設備的MAC地址(MAC地址可通過掃描來獲得進行拷貝或手工填寫)；
開啟掃描：通過開啟掃描來獲取遠端AP MAC地址。設置完畢后點擊“保存”即可。AP將自動重啟，重啟后使設置生效。
WPS:
無線保護設置，支持的模式是：個人識別碼(PIN)模式和按鈕(PBC)模式。PIN模式在路由器上可以查到，用戶端輸入PIN就可安全使用。PBC模式客戶端要支持，客戶端開啟PBC后，按路由器上的PBC按鈕，會自動識別。
位點協議PPP（Point-to-Point Protocol）是目前使用最廣泛的點對點數據鏈路層協議。
一般的家庭用戶是如何接入到因特網的呢？通常都是要通過連接到某個因特網服務提供者IPS，例如中國電信 中國聯通，中國電信這三大運營商，才能接入因特網。這些ISP已經從因特網管理機構申請到了一批IP地址，用戶計算機只有獲取到ISP所分配的合法IP地址后，才能成為因特網上的主機，用戶與進行通信時，所使用的數據鏈路層協議通常就是PPP協議。
在1999年公布的以太網上運行的PPP協議，即PPP over Ethernet,簡稱PPPoE，它使得ISP可以通過DSL、電路調制解調器、以太網等寬帶接入技術，以以太網接口的形式為用戶提供接入服務。另外，PPP協議也廣泛用于廣域網路由器之間的專用線路。
PPP協議是因特網工程任務組IETF在1992年制定的，經過993、1994年的修訂，現在的PPP協議已成為因特網的正式標準[RFC1661,RFC1662]。
PPP協議為在點對點傳輸各種協議數據報提供了一個標準方法，主要由以下三部分構成：
對各種協議數據報的封裝方法（封裝成幀）
鏈路控制協議LCP，用于建立、配置以及測試數據鏈路的連接
一套網絡控制協議NCPs，其中的每一個協議支持不同的網絡層協議
從網絡結構的層面看，PPP是數據鏈路層的協議。他將上層交付下來的協議數據單元封裝成PPP幀。為了支持不同的網絡層協議，PPP協議包含了一套網絡控制協議NCPs（s表示復數），其中的每一個協議支持不同的網絡層協議，例如TCP/IP中的IP，Novell NetWare網絡操作系統中的IPX，Apple中的AppleTalk，鏈路控制協議LCP用于建立、配置以及測試數據鏈路的連接。
PPP協議能夠在多種類型的點對點鏈路上運行。例如面向字節的異步鏈路，面向比特的同步鏈路。
接下來我們看一下PPP協議的幀格式，幀首部由4個字段構成（FACP），幀尾部由2個字段(FCS、F)構成。各字段的長度以及幀的數據部分最大長度如圖所示。
標志字段F(flag):PPP幀的定界符，取值為0x7E
地址字段A（Address）：取值為0xFF，預留（目前沒有什么作用）
控制字符C（Control）:取值為0X0E，預留（目前沒有什么作用）
協議字段P（Protocol）:指明幀的數據部分送交哪個協議處理
幀尾部中的幀檢驗序列FCS字段，其值是使用循環冗余校驗CRC計算出的校驗位，用于檢測PPP幀是否存在誤碼。
PPP協議是如何解決透明傳輸問題的？
當PPP幀的數據部分出現幀尾和幀首中的標志字段時，如果不采取措施，會造成接收方對PPP幀是否結束的誤判。因為標志字段F是PPP幀的定界符，取值為十六進制的0x7E（01111110）。PPP協議實現透明傳輸的方法，取決于所使用的鏈路類型，如果是面向字節的異步鏈路，則采用字節填充法，也就是插入轉義字符。如果是面向比特的同步鏈路，則采用比特填充法，也就是插入比特0。
舉例說明字節填充法，也就是以字節7E為PPP幀的定界符，以字節為單位處理。
發送方的處理：
出現的每一個7E（PPP幀的定界符）字節，都轉變成2字節序列[7D,5E]，如圖，這相當于在7E字節前插入轉義字符7D，并將7E字節減去十六進制的20。
將出現的每一個7D（轉義字符）字節轉變成2字節序列（7D,5D）。
在出現的每一個ASCLL碼控制字符（數值小于0x20的字符）前插入一個7D字節，同時在該字符的編碼上加上20進制的20.
接收方的處理：
進行反變換即可恢復出原來幀的數據部分。
再舉例說明，面向比特的同步鏈路采用插入比特0的比特填充法
PPP幀的位置包含一個兩字節的幀檢驗序列FCS字段。使用循環冗余校驗CRC的來計算該字段的取值，采用生成多項式為
為了減少對CPU的占用，采用查表法進行實現，FCS的計算范圍為幀首以及幀數據部分，若CRC檢驗正確，接收，反之，丟棄。使用PPP幀的數據鏈路層向上不提供可靠傳輸服務。
最后，我們以撥號接入為例，簡單介紹一下PPP協議的工作狀態。
PPP鏈路的開始和結束狀態都是“靜止”狀態，這時，不存在物理層的連接。當檢測到調制解調器的載波信號，并建立物理層連接后，PPP就進入鏈路的“建立”狀態，這是鏈路控制協議LCP開始協商一些配置選項，若協商成功，則進入“鑒別”狀態，若協商失敗，則退回到“靜止”狀態。協商的配置選項，包括最大幀長、鑒別協議等。可以不使用鑒別，也可以使用口令鑒別協議PAP，或挑戰握手鑒別協議CHAP。若通信雙方無需鑒別或鑒別成功，則進入“網絡”狀態；鑒別失敗，進入終止狀態，進入網絡狀態后，進行NCP配置，配置完成后，進入“打開”狀態。
PPP鏈路的兩端通過相互交換網絡層特定的NCP分組，來進行NCP配置，如果在PPP協議鏈路上運行的協議是IP協議，則使用IP控制協議IPCP，對PPP鏈路的每一段配置IP模塊，例如分配IP地址，只有鏈路處于“打開”狀態，就可以進行數據通信，當出現故障或者鏈路的一段發出終止請求時，就進入“終止”狀態，當載波停止后則回到“靜止”狀態。
本文為筆者在自學過程中整理的筆記，如有錯誤之處，歡迎指正，感謝關注！
上一篇：計算機網絡三種可靠傳輸的實現機制之三-選擇重傳協議SR
下一篇：「筆記」計算機網絡之媒體接入控制的基本概念
者 | L的存在
來源 | 我是程序員小賤（ID：Lanj1995Q）
說到后端開發，難免會遇到各種所謂高大上的「關鍵詞 」，對于我們應屆生小白，難免會覺得比較陌生，因為在學校確實比較少遇見這些所謂高大上的東西，那么今天就帶著學習的態度和大家分享這些看似可以裝逼可以飛的帶逼格的關鍵詞吧。
大綱
在學校里的項目中，一個 Web 系統可能咋們一個人就搞定，因為幾乎不考慮并發量，性能咋樣，所謂「過得去 」足矣，但是為了面試考慮，我們又不得不找點類似秒殺系統作為我們簡歷的支撐項目(即使已經爛大街)。那么先問你第一個問題，為什么就采用了分布式的方案落地這個項目？
當一個人或者幾十個使用你的系統，哎呀我去，請求秒回，效果倍棒，于是乎簡歷砰砰寫上卻多么牛X，當面試官就會問你你這項目做了啥，測試過沒，并發量如何，性能如何？你就…..
當訪問系統的用戶越來越多，可是我們的系統資源有限，所以需要更多的 CPU 和內存去處理用戶的計算請求，當然也就要求更大的網絡帶寬去處理數據的傳輸，也需要更多的磁盤空間存儲數據。
資源不夠，消耗過度，服務器崩潰，系統也就不干活了，那么在這樣的情況怎么處理？
垂直伸縮
縱向生長。通過提升單臺服務器的計算處理能力來抵抗更大的請求訪問量。比如使用更快頻率的CPU，更快的網卡，塞更多的磁盤等。
其實這樣的處理方式在電信，銀行等企業比較常見，讓摩托車變為小汽車，更強大的計算機，處理能力也就越強，但是對于運維而言也就越來越復雜。那真的就這樣花錢買設備就完事了？
當然不，單臺服務器的計算處理能力是有限的，而且也會嚴重受到計算機硬件水平的制約。
水平伸縮
一臺機器處理不過來，我就用多臺廉價的機器合并同時處理，人多力量大嘛，通過多臺服務器構成分布式集群從而提升系統的整體處理能力。這里說到了分布式，那我們看看分布式的成長過程
記住一句話：系統的技術架構是需求所驅動
最初的單體系統，只需要部分用戶訪問：
單體結構
做系統的原因當然是有需求，有價值，可賺錢。隨著使用系統的用戶越來越多，這時候關注的人越來越多，單臺服務器扛不住了，關注的人覺得響應真慢，沒啥意思，就開始吐槽，但是這一吐槽，導致用戶更多，畢竟大家都愛吃瓜。
這樣下去不得不進行系統的升級，將數據庫和應用分離。
數據庫應用分離
這樣子，咋們將數據庫和應用程序分離后，部署在不同的服務器中，從1臺服務器變為多臺服務器，處理響應更快，內容也夠干，訪問的用戶呈指數增長，這多臺服務器都有點扛不住了，怎么辦？
加一個緩存吧，我們不每次從數據庫中讀取數據，而將應用程序需要的數據暫存在緩沖中。緩存呢，又分為本地緩存和分布式的緩存。分布式緩存，顧名思義，使用多臺服務器構成集群，存儲更多的數據并提供緩存服務，從而提升緩存的能力。
加了緩存哪些好處？
應用程序不再直接訪問數據庫，提升訪問效率。因為緩存內容在內存中，不用每次連接存放磁盤中的數據庫。
系統越來越火，于是考慮將應用服務器也作為集群。
集群
干啥啥不行，緩存第一名。不吹牛，緩存應用在計算機的各個角落。緩存可說是軟件技術中的的殺手锏，無論是程序代碼使用buffer，還是網絡架構中使用緩存，虛擬機也會使用大量的緩存。
其實最初在CPU中也就開始使用緩存。緩存分為兩種，一種是通讀緩存，一種是旁路緩存
通讀緩存
假設當前應用程序獲取數據，如果數據存在于通讀緩存中就直接返回。如果不存在于通讀緩存，那么就訪問數據源，同時將數據存放于緩存中。
下次訪問就直接從緩存直接獲取。比較常見的為CDN和反向代理。
通讀緩存
CDN
CDN稱為內容分發網絡。想象我們京東購物的時候，假設我們在成都，如果買的東西在成都倉庫有就直接給我們寄送過來，可能半天就到了，用戶體驗也非常好，就不用從北京再寄過來。
同樣的道理，用戶就可以近距離獲得自己需要的數據，既提高了響應速度，又節約了網絡帶寬和服務器資源。
旁路緩存
應用程序需要自己從數據源讀取數據，然后將這個數據寫入到旁路緩存中。這樣，下次應用程序需要數據的時候，就可以通過旁路緩存直接獲得數據了。
旁路緩存
緩存的好處
因為大部分緩存的數據存儲在內存中，相比于硬盤或者從網絡中獲取效率更高，響應時間更快，性能更好；
通過 CDN 等通讀緩存可以降低服務器的負載能力；
因為緩存通常會記錄計算結果。如果緩存命中直接返回，否則需要進行大量的運算。所以使用緩存也減少了CPU 的計算小號，加快處理速度。
緩存缺點
我們緩存的數據來自源數據，如果源數據被修改了，俺么緩存數據很肯能也是被修改過的，成為臟數據，所以怎么辦？
過期失效
在每次寫入緩存數據的時候標記失效時間，讀取數據的時候檢查數據是否失效，如果失效了就重新從數據源獲取數據。
失效通知
應用程序在更新數據源的時候，通知清除緩存中的數據。
是不是數據使用緩存都有意義呢？
非也，通常放入緩存中的數據都是帶有熱點的數據，比如當日熱賣商品，或者熱門吃瓜新聞，這樣將數據存放在緩存中，會被多次讀取，從而緩存的命中率也會比較高。
在前面中，通過緩存實際上很多時候是解決了讀的問題，加快了讀取數據的能力。因為緩存通常很難保證數據的持久性和一致性，所以我們通常不會將數據直接寫入緩存中，而是寫入 RDBMAS 等數據中，那如何提升系統的寫操作性能呢？
此時假設兩個系統分別為A,B，其中A系統依賴B系統，兩者通信采用遠程調用的方式，此時如果B系統出故障，很可能引起A系統出故障。
從而不得不單獨進行升級，怎么辦？
使用消息隊列的異步架構，也成為事件驅動模型。
異步相對于同步而言，同步通常是當應用程序調用服務的時候，不得不阻塞等待服務期完成，此時CPU空閑比較浪費，直到返回服務結果后才會繼續執行。
同步
舉個例子，小藍今天想在系統中加一個發郵件的功能，通過SMTP和遠程服務器通信，但是遠程服務器有很多郵件需要等待發送呢，當前郵件就可能等待比較長時間才能發送成功，發送成功后反饋與應用程序。
這個過程中，遠程服務器發送郵件的時候，應用程序就阻塞，準確的說是執行應用程序的線程阻塞。
這樣阻塞帶來什么問題“？
不能釋放占用的系統資源，導致系統資源不足，影響系統性能
無法快速給用戶響應結果
但是在實際情況中，我們發送郵件，并不需要得到發送結果。比如用戶注冊，發送賬號激活郵件，無論郵件是否發送成功都會收到"返回郵件已經發送，請查收郵件確認激活"，怎樣才能讓應用程序不阻塞？
消息隊列的異步模型
此時就比較清晰了，調用者將消息發送給消息隊列直接返回，應用程序收到返回以后繼續執行，快讀響應用戶釋放資源。
有專門的消費隊列程序從中消息隊列取出數據并進行消費。如果遠程服務出現故障，只會傳遞給消費者程序而不會影響到應用程序。
消息隊列
消息隊列模型中通常有三個角色，分別為生產者，消息隊列和消費者。生產者產生數據封裝為消息發送給消息隊列，專門的消費程序從消息隊列中取出數據，消費數據。
在我看來，消息隊列主要是緩沖消息，等待消費者消費。其中消費的方式分為兩種：
點對點
對生產者多消費者的情況。一個消息被一個消費者消費
多生產消費
上述的發郵件例子就是典型的點對點模式。互不干擾，其中某個服務出現問題不會印象到全局。
訂閱模式
開發人員在消息隊列中設置主題，生產者往相應的主題發送數據，消費者從對應的主題中消費數據，每個消費者按照自己業務邏輯分別進行計算
訂閱模式
這個比較好理解，比如在用戶注冊的時候，我們將注冊信息放入主題用戶中，消費者訂閱了這個主題，可能有構造短信消息的消費者，也有推廣產品的消費者，都可以根據自己業務邏輯進行數據處理。
用戶注冊案例
使用異步模型的優點
快速響應
不在需要等待。生產者將數據發送消息隊列后，可繼續往下執行，不虛等待耗時的消費處理
削峰填谷(需要修改)
互聯網產品會在不同的場景其并發請求量不同。互聯網應用的訪問壓力隨時都在變化，系統的訪問高峰和低谷的并發壓力可能也有非常大的差距。
如果按照壓力最大的情況部署服務器集群，那么服務器在絕大部分時間內都處于閑置狀態。
但利用消息隊列，我們可以將需要處理的消息放入消息隊列，而消費者可以控制消費速度，因此能夠降低系統訪問高峰時壓力，而在訪問低谷的時候還可以繼續消費消息隊列中未處理的消息，保持系統的資源利用率。
降低耦合
如果調用是同步，如果調用是同步的，那么意味著調用者和被調用者必然存在依賴，一方面是代碼上的依賴，應用程序需要依賴發送郵件相關的代碼，如果需要修改發送郵件的代碼，就必須修改應用程序，而且如果要增加新的功能
那么目前主要的消息隊列有哪些，其有缺點是什么？(好好記下這個高頻題目啦)
一臺機器扛不住了，需要多臺機器幫忙，既然使用多臺機器，就希望不要把壓力都給一臺機器，所以需要一種或者多種策略分散高并發的計算壓力，從而引入負載均衡，那么到底是如何分發到不同的服務器的呢？
最初實現負載均衡采取的方案很直接，直接上硬件，當然也就比較貴，互聯網的普及，和各位科學家的無私奉獻，各個企業開始部署自己的方案，從而出現負載均衡服務器。
HTTP重定向負載均衡
也屬于比較直接，當HTTP請求叨叨負載均衡服務器后，使用一套負載均衡算法計算到后端服務器的地址，然后將新的地址給用戶瀏覽器，瀏覽器收到重定向響應后發送請求到新的應用服務器從而實現負載均衡，如下圖所示：
HTTP重定向負載均衡
優點：
簡單，如果是java開發工程師，只需要servlet中幾句代碼即可
缺點：
加大請求的工作量。第一次請求給負載均衡服務器，第二次請求給應用服務器
因為要先計算到應用服務器的 IP 地址，所以 IP 地址可能暴露在公網，既然暴露在了公網還有什么安全可言
DNS負載均衡
了解計算機網絡的你應該很清楚如何獲取 IP 地址，其中比較常見的就是 DNS 解析獲取 IP 地址。
用戶通過瀏覽器發起HTTP請求的時候，DNS 通過對域名進行即系得到 IP 地址，用戶委托協議棧的 IP 地址簡歷 HTTP 連接訪問真正的服務器。這樣不同的用戶進行域名解析將會獲取不同的IP地址從而實現負載均衡。
DNS負載均衡
乍一看，和HTTP重定向的方案不是很相似嗎而且還有 DNS 解析這一步驟，也會解析出 IP 地址，不一樣的暴露？
每次都需要解析嗎，當然不，通常本機就會有緩存，在實際的工程項目中通常是怎么樣的呢？
通過 DNS 解析獲取負載均衡集群某臺服務器的地址；
負載均衡服務器再一次獲取某臺應用服務器，這樣子就不會將應用服務器的 IP 地址暴露在官網了。
反向代理負載均衡
這里典型的就是Nginx提供的反向代理和負載均衡功能。用戶的請求直接叨叨反向代理服務器，服務器先看本地是緩存過，有直接返回，沒有則發送給后臺的應用服務器處理。
反向代理負載均衡
IP負載均衡
上面一種方案是基于應用層的，IP很明顯是從網絡層進行負載均衡。TCP./IP協議棧是需要上下層結合的方式達到目標，當請求到達網絡層的黑猴。
負載均衡服務器對數據包中的IP地址進行轉換，從而發送給應用服務器。
IP負載均衡
注意，這種方案通常屬于內核級別，如果數據比較小還好，但是大部分情況是圖片等資源文件，這樣負載均衡服務器會出現響應或者請求過大所帶來的瓶頸。
數據鏈路負載均衡
它可以解決因為數據量他打而導致負載均衡服務器帶寬不足這個問題。怎么實現的呢。它不修改數據包的IP地址，而是更改mac地址。
應用服務器和負載均衡服務器使用相同的虛擬IP。
數據鏈路負載均衡
以上介紹了幾種負載均衡的方式，但是很重要的負載均衡算法卻沒有設計，其中包含了輪詢，隨機，最少連接，下面分別對此進行介紹。
公司存在的價值在于流量，流量需要數據，可想而知數據的存儲，數據的高可用可說是公司的靈魂。那么改善數據的存儲都有哪些手段或方法呢？
數據主從復制
主從復制比較好理解，需要使用兩個數據庫存儲一樣的數據。其原理為當應用程序A發送更新命令到主服務器的時候，數據庫會將這條命令同步記錄到Binlog中。
然后其它線程會從Binlog中讀取并通過遠程通訊的方式復制到另外服務器。服務器收到這更新日志后加入到自己Relay Log中，然后SQL執行線程從Relay Log中讀取次日志并在本地數據庫執行一遍，從而實現主從數據庫同樣的數據。
主從復制
主從復制可以方便進行讀寫分離，可以使用一主多從的方式保證高可用，如果從數據庫A掛了，可以將讀操作遷移到從數據庫完成高可用。
但是如果主數據庫掛了咋搞，那就Mysql的主主復制。可是不管上面說的那種方式都不是提升它的存儲能力，這就需要進行數據庫的分片了。
數據庫分片
將一張表分成若干片，其中每一片都包含一部分行記錄，然后將每一片存儲在不同的服務器中，這樣就實現一張表存放在多臺服務器中，哪都有哪些分片存儲的方案？
最開始使用"硬編碼"的方式，此方式從字面上可以理解為直接在代碼中指定。假定表為用戶表，通過ID的奇偶存放在不同的服務器上，如下圖：
這種方式的缺點很明顯，當需要增加服務器的時候，就需要改動代碼，這就不友好了。比較常見的數據庫分片算法是通過余數Hash算法，根據主鍵ID和服務器的數量取模，根據余數確定服務器。
我們使用谷歌瀏覽器的時候，輸入搜索關鍵字，就會出現搜索到多少條結果，用時多少，它是如何做到在如此短的時間完成這么大數據量的搜索。
先來想第一個問題，全世界這么多網頁在哪里？
互聯網的存在讓你和我隔著屏幕都知道你多帥。當然，每個網頁中都會存在很多其他網頁的超鏈接，這樣構成了龐大的網絡。
對于搜索引擎而言，目標為解析這些網頁獲取超鏈接，下載鏈接內容(過濾)，具體一些說。
將URL存放于池子中，從池子中取出URL模擬請求，下載對應的HTML，并存放于服務器上，解析HTML內容時如果有超鏈接URL，檢測是否已經爬取過，如果沒有暫存隊列，后面再依次爬取。架構圖如下：
爬蟲常規方法
將獲取的所有網頁進行編號并得到網頁集合。然后通過分詞技術獲得每一個單詞，組成矩陣如下所示：
分詞
就這樣按照單詞-文檔的方式組織起來就叫做倒排索引了。
倒排索引
Google通過建立<單詞，地址>這樣的文檔，主要搜索到單詞就能定位到文檔的地址列表，然后根據列表中文檔的編號就展現文檔信息從而實現快速的檢索。
如果搜索出來結果很多，Google是如何能更精準的將我們需要的信息呈現給我們呢。它很明顯有個排序功能，那是如何排序的？
Google使用了一種叫做"PageRank"的算法，通過計算每個網頁的權重，并按照權重排序，權重高的自然就在顯示在前面，那問題來了，為啥權重高的，排在前面的通常就是用戶所需要的呢？這就得了解下pagerank算法了。
在pagerank中，如果網頁A包含網頁B說明A認可B，即投一票。如下圖ABCD四個網頁所示，箭頭代表超鏈接的方向，比如A->B代表A網頁包含B的超鏈接
pagerank
怎么計算的？
ABCD 初始值都為1，然后根據關系計算權重。比如此時B包含了AD兩個網頁，那么權重1被分為兩個1/2分別給A和D，此時A包含BCD，那么此時A頁面新的權重為1/2 + 1/3 + 1=11/6。
pagerank 值越受推薦，代表用戶越想看到。基于每個網頁的 pagerank 值對倒排索引中的文檔列表排序，靠前者則是用戶想看到的文檔。
這種是因為超鏈接，引入權值的方式排序。還有其他諸如對于商品售賣次數排序或者電影點贊或評價分數排序。
還有通過關鍵字查找，希望找到和搜索詞相關，這個時候可能就會采用詞頻TF進行排序，詞頻代表所查詞和文檔的相關程度。
詞頻TF
比如我們搜索"Java后端"出現的結果以"后端"的相關技術。
在大部分的應用中都會涉及到搜索引擎技術，技術龐大且復雜，希望各位老鐵根據自身情況搜索相關所需學習，校招面試中不出現盲點即可。
技術的引進一定是想解決某個痛點。我不希望在一個系統中，一小點改動就影響到全局，希望各個功能模塊拆分清晰，不管是測試還是運維都能節省更多的時間。
那么單體的架構出現了哪些問題？
代碼分支管理困難
各個部門分別完成各自的任務，但是最后需要 merge 在一起成為整個系統，merge過程經歷的人都知道，問題是真XX多。所以不再是996
新增功能麻煩
隨著項目的效益越來越好，用戶的需求也更多，招聘的人可能更多，對于新手來說上來是一臉懵逼的，老員工忙的要死，新員工成為了摸魚專家
耗盡連接
用戶的增多，每個應用都得和數據庫連接，給數據庫的連接造成太大的壓力甚至耗盡連接
微服務
“微"-------微微一笑很傾城，微笑，微小。顧名思義，講一個大的系統，拆分為一個個小的服務，分別對各個小服務進行管理。這樣說感覺太不專業了，專業點
大應用拆分為小模塊
小模塊不屬于集群中
通過遠程調用的方式依賴各個獨立的模塊完成業務的處理
這些小的模塊就叫做------微服務，整體也就是所謂的微服務架構。
既然拆分成了小服務，這么多小服務怎么協調成為一個問題，甚至都不知道怎么掉這個服務，所以在微服務的整體架構中出現了注冊中心，誰需要調用使用提供的接口即可。如下圖所示：
注冊中心
從上圖我們能知道主要是三個概念：
服務提供者
微服務的具體提供者，其他微服務通過接口調用即可
服務消費者
對應于服務提供者，按照提供者接口編程即可。這么輕松的嘛，當然很多細節。舉個例子，注明的dubbo服務框架，服務接口通過Dubbo框架代理機制訪問Dubbo客戶端，客戶端通過服務接口聲明去注冊中心查看有哪些服務器，并將這服務器列表給客戶端。
客戶端然后根據負載均衡策略選擇其中一個服務器，通過遠程調用的方式發送服務調用。那么使用微服務需要注重哪幾點？
選擇中的注意事項
不要拿工具硬上需求，結合業務也許會更佳！
高可用，意味著一臺機器掛了沒事，其他機器可以照常工作，用戶體驗一樣倍棒，用戶壓根就不知道，臥槽，你居然升級了系統，我居然一點感受都沒有。那么高可用總有個標準吧，是百分之80就行還是90？
一個系統突然不能訪問的原因很多：
硬件故障
數據庫宕機
磁盤孫歡
bug
光纜斷了
可用性指標
通過多少個9來衡量，比如大寶系統可用性為4個9，意味著是99.99%，說明它的服務保證運行時間只有0.01不可用。
高可用涉及到技術成本和設備成本，不是說高可用值越高越好，而是根據具體工具具體場景而定，這里分享一些高可用策略。
冗余備份
任何一個服務都有備份，就反復我們都會對我們筆記本電腦相關文件進行備份一樣，以防萬一。即使一臺服務器掛了，可以很快的切換以致于讓用戶不會覺得"這系統怎么這么渣"。
負載均衡
使用多臺服務器分擔一臺服務器的壓力，滿足高并發的請求。怎么實現的呢，應用程序會有一個心跳檢測/健康檢查機制，如果發現不妥切換即可。上面提到的數據庫主主復制也是高可用的方案之一，技術思想果然是相通的
負載均衡
限流降級
我們的目標不是沒有蛀牙，而是希望整個系統不要掛掉。限流是對部分請求進行丟棄處理，保證大部分的用戶可以正常的請求完成任務。
降級：
可以屏蔽部分當前看來不是很有用的任務。比如電商系統做秒殺活動的過程中，確認收貨功能給予的壓力挺大，暫時看來并不是核心任務，而且系統到期也會自動確認收貨，所以暫時關閉，將系統的資源留給準備下單，放購物車的太太們
異地多活：
有時候我在想要是地震，火災等自然災害發生的時候，很多系統的數據怎么辦啊。想多了撒，大些的系統多會在各個地方部署數據中心，采用異地多活的多機房策略。用戶可以訪問任何數據中心，那問題來了，用戶的請求是如何到達不同的機房去的？
域名解析
公司中的數據財產，其重要程度不言而喻。系統的健壯性和安全性是保證系統持久運行的基礎。不要因為數據泄露才去關注安全問題。
也許說到安全問題，首先想到的是“用戶名密碼”泄漏，數據庫被脫褲導致數據泄露，hack直接拿到用戶的敏感信息，所以我們通常有哪些手段或方法來盡全力的抵抗hack嘞，辦法總比問題多嘛。
數據加解密
通過對用戶密碼，身份證等敏感數據加密是常用方法。加密方法通常分為：單向散列加密，對稱加密和非對稱加密。
所謂單向散列加密，主要體現在單向二字，意味著對明文加密后是不可以解密，你即使是給明文加密的加密者，也無法通過密文知道其明文是什么，即加密單向，不支持解密。說的這么絕對？這么無敵？
那只是理論上而已，常用的MD5算法就是大象散列加密，我們完全可以通過彩虹表等方式進行破解。怎么破解？
說個簡單的道理，我們設置密碼的時候，通常會使用生日？手機號？什么love？什么520？，這些組合是有限的，我們就可以建立一個比如生日和密文的映射表，然后通過XX彩虹表就可得到密碼明文。
單向散列加密
所以，通常的情況，使用單向散列加密的時候需要加一點鹽，這樣一來，hack拿到密文，不知道鹽，無法建立彩虹表，就更難還原明文。
應用場景：通常應用在用戶密碼加密。其加密和校驗過程如下：
應用場景
我們通過上圖來回顧一下一個網站的注冊登錄模塊中的用戶部分，用戶注冊需要輸入用戶名和密碼，我們一般不會將裸露的將密碼直接存放在數據庫，不然被脫褲直接算裸奔。
所以，用戶輸入密碼，應用服務器獲得密碼后，調用單向散列加密算法，將加密的密文存放于數據庫，用戶下一次登錄的時候，用戶依然會輸入密碼。
只是到了Web服務器后，Web服務器會對輸入的密碼再進行一次單向散列加密，然后和數據庫中取出來的密文進行對比，如果相同，則用戶的驗證成功，通常這樣的方式可以保證用戶密碼的安全性，當然如果加一點鹽，會增加破解的難度。
對稱加密
對稱加密是通過一個加密算法和密鑰，對一段明文進行加密后得到密文，然后使用相同的密鑰和對應的解密算法進行解密得到明文。
對稱加密
舉個例子，我們不會將銀行卡卡號，有效期等直接存儲在數據庫，而是會通過先加密，然后存儲于數據庫。
使用的時候必須對密文進行解密還原出明文。這個時候使用對稱加密算法，存儲的時候加密算法進行加密，使用的時候解密算法解密。
非對稱加密
非對稱加密是說使用一個加密算法和一個加密秘鑰進行加密得到密文，但是在解密出明文的時候，其加解密密鑰和加密密鑰不同，通常加密密鑰叫做公鑰，解密密鑰叫做私鑰。
非對稱加密
其實我們常用的 HTTPS 即是非對稱加密的應用場景。用戶在客戶端進行通訊的時候，對數據使用的加密密鑰和加密算法進行加密得到密文，到了服務端以后，使用解密密鑰和算法進行解密得到明文。
但是非對稱消耗的資源比較多，所以HTTPS不是每次請求響應都采用非對稱加密，而是先利用非對稱加密，在客戶單和服務器之間交換一個對稱加密的密鑰，然后每次的請求響應再使用對稱加密。
綜上，使用費對稱加密保證對稱加密迷藥的安全，使用對稱加密密鑰保證請求響應數據的安全。
HTTP攻擊與防護
HTTP明文協議，咋們通過嗅探工具就可以清晰查看會話內容，這也是hack攻擊門檻最低的方式。很常見的也就是SQL注入和XSS攻擊。
SQL注入是攻擊者在提交請求參數的時候，包含了惡意的SQL腳本：
SQL注入
server處理計算后向數據庫提交的SQL如下：
Select id from users where username='Mike';
如果是惡意攻擊，提交的HTTP請求如下：
http://www.a.com?username=Mike';drop table users;--
此時最終生成的SQL是：
Select id from users where username='Mike';drop table users;--';
查詢完就直接給刪除表了。怎么防護？
比較常用的解決方案是使用PrepareStaement預編譯，先將SQL交給數據庫生成執行計劃，后面hack不管提交什么字符串也只能交給這個執行計劃執行，不會生成新的SQL，也就不會被攻擊啦。
XSS攻擊
跨站點腳本攻擊，攻擊者通過構造惡意的瀏覽器腳本文件，使其在其他用戶的瀏覽器運行進而進行攻擊。
假設小A將含有惡意腳本的請求給360服務器，服務器將惡意的腳本存儲在本地的數據庫，當其他正常用戶通過這個服務器瀏覽信息的時候，服務器就會讀取數據庫中含有惡意腳本的數據并呈現給用戶，在用戶正常使用瀏覽器的時候達到攻擊的目的。
防御：
比較常見的是在入口處對危險的請求比如drop table等進行攔截，設置一個Web應用防火墻將危險隔離。
安全防御
其實在上面提到的分布式中就有涉及大數據相關知識。無外乎是數據量越來越大，我們如何盡可能使用較低的成本存儲更多的數據，給公司企業帶來更好的利潤。上面說過分布式緩存，負載均衡等技術，其共同特點是如何抵抗高并發的壓力，而這里的大數據技術主要談論的是如何滿足大規模的計算。
通過對數據的分析，進而發掘海量數據中的價值，這里的數據包含數據庫數據，日志信息，用戶行為數據等等。那么這么多不同類型的數據，怎么去存儲呢？
分布式文件存儲 HDFS 架構
如何將數以萬計的服務器組成統一的文件存儲系統？其中使用Namenode服務器作為控制塊，負責元數據的管理(記錄文件名，訪問權限，數據存儲地址等)，而真正的文件存儲在DataNode中。
Mapreduce
大量的數據存儲下來的目的是通過相應的算法進行數據分析，獲得通過深度學習/機器學習進行預測，從而獲取有效的價值，這么大的文件，我們不可能將HDFS當做普通的文件，從文件中讀取數據然后計算，這樣子不知道算到何時何地。
大數據處理經典的處理框架即MapReduce，分為Map和Reduce兩個階段，其中一個Map過程是將每個服務器上啟動Map進程，計算后輸出一個
下面以WordCount統計所有數據中相同的詞頻數據為例，詳細看看Map和Reduce的過程。
wordcoun計算過程
在這個例子中，通過對value中的1組成的列表，reduce對這些1進行求和操作從而得到每個單詞的詞頻。代碼實現如下：
public class WordCount {
// Mapper四個參數：第一個Object表示輸入key的類型；第二個Text表示輸入value的類型；第三個Text表示表示輸出鍵的類型；第四個IntWritable表示輸出值的類型。map這里的輸出是指輸出到reduce
public static class doMapper extends Mapper<Object, Text, Text, IntWritable> {
public static final IntWritable one=new IntWritable(1);//這里的IntWritable相當于Int類型
public static Text word=new Text;//Text相當于String類型
// map參數<keyIn key,valueIn value,Context context>，將處理后的數據寫入context并傳給reduce
protected void map(Object key, Text value, Context context) throws IOException, InterruptedException {
//StringTokenizer是Java工具包中的一個類，用于將字符串進行拆分
StringTokenizer tokenizer=new StringTokenizer(value.toString, " ");
//返回當前位置到下一個分隔符之間的字符串
word.set(tokenizer.nextToken);
//將word存到容器中，記一個數
context.write(word, one);
}
}
//參數同Map一樣，依次表示是輸入鍵類型，輸入值類型，輸出鍵類型，輸出值類型。這里的輸入是來源于map,所以類型要與map的輸出類型對應 。
public static class doReducer extends Reducer<Text, IntWritable, Text, IntWritable> {
private IntWritable result=new IntWritable;
@Override
protected void reduce(Text key, Iterable<IntWritable> values, Context context)
throws IOException, InterruptedException {
int sum=0;
//for循環遍歷，將得到的values值累加
for (IntWritable value : values) {
sum +=value.get;
}
result.set(sum);
context.write(key, result);//將結果保存到context中，最終輸出形式為"key" + "result"
}
}
public static void main(String[] args) throws IOException, ClassNotFoundException, InterruptedException {
System.out.println("start");
Job job=Job.getInstance;
job.setJobName("wordCount");
Path in=new Path("hdfs://***:9000/user/hadoop/input/buyer_favorite1.txt");//設置這個作業輸入數據的路徑(***部分為自己liunx系統的localhost或者ip地址)
Path out=new Path("hdfs://***:9000/user/hadoop/output/wordCount"); //設置這個作業輸出結果的路徑
FileInputFormat.addInputPath(job, in);
FileOutputFormat.setOutputPath(job, out);
job.setJarByClass(WordCount.class);// 設置運行/處理該作業的類
job.setMapperClass(doMapper.class);//設置實現了Map步的類
job.setReducerClass(doReducer.class);//設置實現了Reduce步的類
job.setOutputKeyClass(Text.class);//設置輸出結果key的類型
job.setOutputValueClass(IntWritable.class);//設置輸出結果value的類型
////執行作業
System.exit(job.waitForCompletion(true) ? 0 : 1);
System.out.println("end");
}
}
那么這個map和reduce進程是怎么在分布式的集群中啟動的呢？
map/reduce啟動過程
上圖比較清晰地闡述的整個過程，再描述一波。MR中主要是兩種進程角色，分別為 JobTracke r和 TaskTracker 兩種。
JobTracker在集群中只有一個，而 TaskTracker 存在多個，當 JobClient 啟動后，往 JobTracker 提交作業，JobTracker查看文件路徑決定在哪些服務器啟動 Map 進程。
然后發送命令給 TaskTracker，告訴它要準備執行任務了，TaskTracker收到任務后就會啟動 TaskRunner 下載任務對應的程序。
map計算完成，TaskTracker對map輸出結果 shuffer 操作然后加載 reduce 函數進行后續計算，這就是各個模塊協同工作的簡單過程。
上述過程還是比較麻煩，我們能不能直接寫SQL，然后引擎幫助我們生成mapreduce代碼，就反復我們在web開發的時候，不直接寫SQL語句，直接交給引擎那么方便，有的，它就是HIVE。
舉個例子：
SQL
拆分
那么使用MR的計算過程完成這條SQL的處理：
MR TO SQL
Spark是基于內存計算的大數據并行計算框架。基于此說說上面hadoop中組件的缺點：
磁盤IO開銷大。每次執行都需要從磁盤讀取并且計算完成后還需要將將中間結果存放于磁盤
表達能力有限。大多數計算都需要轉換為Map和Reduce兩個操作，難以描述復雜的數據處理
spark優點：
編程模型不限于map和reduce，具有更加靈活的編程模型
spark提供內存計算，帶來更高的迭代運算效率且封裝了良好的機器學習算法
采用了基于圖DAG的任務調度機制
Flink
Flink是大數據處理的新規，發展速度之快，這兩年也相繼出現中文資料。作為流式數據流執行引擎，針對數據流的分布式計算提供數據分布，數據通信以及容錯機制等功能。同時Flink也提供了機器學習庫，圖計算庫等。
附一張去年參加會議回答問題中獎的馬克杯，嘻嘻。
去年參會
關于大數據相關知識點可作為擴充點，在面試的過程中經常會有大數問題，除了從算法的角度來闡述，也可以從這些框架中吸取一些經驗。
對于之前從事c/c++開發的我，很多時候是Linux的開發。在學校又沒怎么接觸系統性的項目，更不知道后端技術的博大進深，可能文中涉及的也就一部分，不過希望還在學校的小伙伴可以知道有這些東西，然后通過強大的搜索引擎，給自己個比較明確的方向，也許會少走點彎路，這周的文章就到這了，goodbye！
點分享