① web伺服器訪問緩慢，作為運維人員，如何定位故障
遇到伺服器故障，問題出現的原因很少可以一下就想到。我們基本上都會從以下步驟入手：
一、盡可能搞清楚問題的前因後果
不要一下子就扎到伺服器前面，你需要先搞明白對這台伺服器有多少已知的情況，還有故障的具體情況。不然你很可能就是在無的放矢。
必須搞清楚的問題有：
故障的表現是什麼？無響應？報錯？
故障是什麼時候發現的？
故障是否可重現？
有沒有出現的規律（比如每小時出現一次）
最後一次對整個平台進行更新的內容是什麼（代碼、伺服器等）？
故障影響的特定用戶群是什麼樣的(已登錄的, 退出的, 某個地域的…)?
基礎架構（物理的、邏輯的）的文檔是否能找到?
是否有監控平台可用? （比如Munin、Zabbix、 Nagios、 New Relic…
什麼都可以）
是否有日誌可以查看?. （比如Loggly、Airbrake、 Graylog…）
最後兩個是最方便的信息來源，不過別抱太大希望，基本上它們都不會有。只能再繼續摸索了。
二、有誰在?
代碼如下:
$ w
$ last
用這兩個命令看看都有誰在線，有哪些用戶訪問過。這不是什麼關鍵步驟，不過最好別在其他用戶正幹活的時候來調試系統。有道是一山不容二虎嘛。（ne cook in
the kitchen is enough.）
三、之前發生了什麼?
$
history查看一下之前伺服器上執行過的命令。看一下總是沒錯的，加上前面看的誰登錄過的信息，應該有點用。另外作為admin要注意，不要利用自己的許可權去侵犯別人的隱私哦。
到這里先提醒一下，等會你可能會需要更新 HISTTIMEFORMAT
環境變數來顯示這些命令被執行的時間。對要不然光看到一堆不知道啥時候執行的命令，同樣會令人抓狂的。
四、現在在運行的進程是啥?
代碼如下:
$ pstree -a
$ ps aux
這都是查看現有進程的。 ps aux 的結果比較雜亂， pstree -a 的結果比較簡單明了，可以看到正在運行的進程及相關用戶。
五、監聽的網路服務
代碼如下:
$ netstat -ntlp
$ netstat -nulp
$
netstat -nxlp
我一般都分開運行這三個命令，不想一下子看到列出一大堆所有的服務。netstat -nalp倒也可以。不過我絕不會用 numeric 選項
（鄙人一點淺薄的看法：IP 地址看起來更方便）。
找到所有正在運行的服務，檢查它們是否應該運行。查看各個監聽埠。在netstat顯示的服務列表中的PID 和 ps aux 進程列表中的是一樣的。
如果伺服器上有好幾個Java或者Erlang什麼的進程在同時運行，能夠按PID分別找到每個進程就很重要了。
通常我們建議每台伺服器上運行的服務少一點，必要時可以增加伺服器。如果你看到一台伺服器上有三四十個監聽埠開著，那還是做個記錄，回頭有空的時候清理一下，重新組織一下伺服器。
六、CPU 和內存
代碼如下:
$ free -m
$ uptime
$ top
$
htop
注意以下問題:
還有空餘的內存嗎? 伺服器是否正在內存和硬碟之間進行swap?
還有剩餘的CPU嗎? 伺服器是幾核的? 是否有某些CPU核負載過多了?
伺服器最大的負載來自什麼地方? 平均負載是多少?
七、硬體
代碼如下:
$ lspci
$ dmidecode
$
ethtool
有很多伺服器還是裸機狀態，可以看一下：
找到RAID 卡 (是否帶BBU備用電池?)、 CPU、空餘的內存插槽。根據這些情況可以大致了解硬體問題的來源和性能改進的辦法。
網卡是否設置好?
是否正運行在半雙工狀態? 速度是10MBps? 有沒有 TX/RX 報錯?
八、IO 性能
代碼如下:
$ iostat -kx 2
$ vmstat 2 10
$ mpstat
2 10
$ dstat --top-io --top-bio
這些命令對於調試後端性能非常有用。
檢查磁碟使用量：伺服器硬碟是否已滿?
是否開啟了swap交換模式 (si/so)?
CPU被誰佔用：系統進程? 用戶進程? 虛擬機?
dstat 是我的最愛。用它可以看到誰在進行 IO： 是不是Mysql吃掉了所有的系統資源? 還是你的PHP進程?
九、掛載點 和 文件系統
代碼如下:
$ mount
$ cat /etc/fstab
$ vgs
$
pvs
$ lvs
$ df -h
$ lsof +D / /* beware not to kill your box
*/
一共掛載了多少文件系統?
有沒有某個服務專用的文件系統? (比如MySQL?)
文件系統的掛載選項是什麼： noatime?
default? 有沒有文件系統被重新掛載為只讀模式了？
磁碟空間是否還有剩餘?
是否有大文件被刪除但沒有清空?
如果磁碟空間有問題，你是否還有空間來擴展一個分區？
十、內核、中斷和網路
代碼如下:
$ sysctl -a | grep ...
$ cat
/proc/interrupts
$ cat /proc/net/ip_conntrack /* may take some time on busy
servers */
$ netstat
$ ss -s
你的中斷請求是否是均衡地分配給CPU處理，還是會有某個CPU的核因為大量的網路中斷請求或者RAID請求而過載了？
SWAP交換的設置是什麼？對於工作站來說swappinness 設為 60 就很好,
不過對於伺服器就太糟了：你最好永遠不要讓伺服器做SWAP交換，不然對磁碟的讀寫會鎖死SWAP進程。
conntrack_max 是否設的足夠大，能應付你伺服器的流量?
在不同狀態下(TIME_WAIT, …)TCP連接時間的設置是怎樣的？
如果要顯示所有存在的連接，netstat 會比較慢， 你可以先用 ss 看一下總體情況。
你還可以看一下 Linux TCP tuning
了解網路性能調優的一些要點。
十一、系統日誌和內核消息
代碼如下:
$ dmesg
$ less /var/log/messages
$
less /var/log/secure
$ less /var/log/auth
查看錯誤和警告消息，比如看看是不是很多關於連接數過多導致？
看看是否有硬體錯誤或文件系統錯誤?
分析是否能將這些錯誤事件和前面發現的疑點進行時間上的比對。
十二、定時任務
代碼如下:
$ ls /etc/cron* + cat
$ for user in
$(cat /etc/passwd | cut -f1 -d:); do crontab -l -u $user; done
是否有某個定時任務運行過於頻繁?
是否有些用戶提交了隱藏的定時任務?
在出現故障的時候，是否正好有某個備份任務在執行？
十三、應用系統日誌
這里邊可分析的東西就多了,
不過恐怕你作為運維人員是沒功夫去仔細研究它的。關注那些明顯的問題，比如在一個典型的LAMP（Linux+Apache+Mysql+Perl）應用環境里:
Apache & Nginx; 查找訪問和錯誤日誌, 直接找 5xx 錯誤, 再看看是否有 limit_zone 錯誤。
MySQL;
在mysql.log找錯誤消息，看看有沒有結構損壞的表， 是否有innodb修復進程在運行，是否有disk/index/query 問題.
PHP-FPM; 如果設定了 php-slow 日誌, 直接找錯誤信息 (php, mysql, memcache, …)，如果沒設定，趕緊設定。
Varnish; 在varnishlog 和 varnishstat 里, 檢查 hit/miss比.
看看配置信息里是否遺漏了什麼規則，使最終用戶可以直接攻擊你的後端？
HA-Proxy;
後端的狀況如何？健康狀況檢查是否成功？是前端還是後端的隊列大小達到最大值了？
結論
經過這5分鍾之後，你應該對如下情況比較清楚了：
在伺服器上運行的都是些啥？
這個故障看起來是和 IO/硬體/網路 或者 系統配置 (有問題的代碼、系統內核調優, …)相關。
這個故障是否有你熟悉的一些特徵？比如對資料庫索引使用不當，或者太多的apache後台進程。
你甚至有可能找到真正的故障源頭。就算還沒有找到，搞清楚了上面這些情況之後，你現在也具備了深挖下去的條件。繼續努力吧！
② 我開發 了一個WEB程序，現在需要連接身份證閱讀器，讀取出身份證跟我資料庫里做比對，我不會連接，求幫助
利用$_post接受身份證填如的數據，然後讀取資料庫，兩者做對照
③ web攻擊有哪些怎麼防護
1、DoS和DDoS攻擊（DoS(Denial of Service)，即拒絕服務，造成遠程伺服器拒絕服務的行為被稱為DoS攻擊。其目的是使計算機或網路無法提供正常的服務。最常見的DoS攻擊有計算機網路帶寬攻擊和連通性攻擊）
防範：(1) 反欺騙：對數據包的地址及埠的正確性進行驗證，同時進行反向探測。(2) 協議棧行為模式分析：每個數據包類型需要符合RFC規定，這就好像每個數據包都要有完整規范的著裝，只要不符合規范，就自動識別並將其過濾掉。(3) 特定應用防護：非法流量總是有一些特定特徵的，這就好比即便你混進了顧客群中，但你的行為還是會暴露出你的動機，比如老重復問店員同一個問題，老做同樣的動作，這樣你仍然還是會被發現的。(4) 帶寬控制：真實的訪問數據過大時，可以限制其最大輸出的流量，以減少下游網路系統的壓力。
2、CSRF(Cross Site Request Forgery)，即跨站請求偽造，是一種常見的Web攻擊，但很多開發者對它很陌生。CSRF也是Web安全中最容易被忽略的一種攻擊。
防範：(1) 驗證碼。應用程序和用戶進行交互過程中，特別是賬戶交易這種核心步驟，強制用戶輸入驗證碼，才能完成最終請求。在通常情況下，驗證碼夠很好地遏制CSRF攻擊。但增加驗證碼降低了用戶的體驗，網站不能給所有的操作都加上驗證碼。所以只能將驗證碼作為一種輔助手段，在關鍵業務點設置驗證碼。(2) Referer Check。HTTP Referer是header的一部分，當瀏覽器向web伺服器發送請求時，一般會帶上Referer信息告訴伺服器是從哪個頁面鏈接過來的，伺服器籍此可以獲得一些信息用於處理。可以通過檢查請求的來源來防禦CSRF攻擊。正常請求的referer具有一定規律，如在提交表單的referer必定是在該頁面發起的請求。所以通過檢查http包頭referer的值是不是這個頁面，來判斷是不是CSRF攻擊。但在某些情況下如從https跳轉到http，瀏覽器處於安全考慮，不會發送referer，伺服器就無法進行check了。若與該網站同域的其他網站有XSS漏洞，那麼攻擊者可以在其他網站注入惡意腳本，受害者進入了此類同域的網址，也會遭受攻擊。出於以上原因，無法完全依賴Referer Check作為防禦CSRF的主要手段。但是可以通過Referer Check來監控CSRF攻擊的發生。(3) Anti CSRF Token。目前比較完善的解決方案是加入Anti-CSRF-Token，即發送請求時在HTTP 請求中以參數的形式加入一個隨機產生的token，並在伺服器建立一個攔截器來驗證這個token。伺服器讀取瀏覽器當前域cookie中這個token值，會進行校驗該請求當中的token和cookie當中的token值是否都存在且相等，才認為這是合法的請求。否則認為這次請求是違法的，拒絕該次服務。這種方法相比Referer檢查要安全很多，token可以在用戶登陸後產生並放於session或cookie中，然後在每次請求時伺服器把token從session或cookie中拿出，與本次請求中的token 進行比對。由於token的存在，攻擊者無法再構造出一個完整的URL實施CSRF攻擊。但在處理多個頁面共存問題時，當某個頁面消耗掉token後，其他頁面的表單保存的還是被消耗掉的那個token，其他頁面的表單提交時會出現token錯誤。
3、XSS(Cross Site Scripting)，跨站腳本攻擊。為和層疊樣式表(Cascading Style Sheets，CSS)區分開，跨站腳本在安全領域叫做「XSS」。
防範：(1) 輸入過濾。永遠不要相信用戶的輸入，對用戶輸入的數據做一定的過濾。如輸入的數據是否符合預期的格式，比如日期格式，Email格式，電話號碼格式等等。這樣可以初步對XSS漏洞進行防禦。上面的措施只在web端做了限制，攻擊者通抓包工具如Fiddler還是可以繞過前端輸入的限制，修改請求注入攻擊腳本。因此，後台伺服器需要在接收到用戶輸入的數據後，對特殊危險字元進行過濾或者轉義處理，然後再存儲到資料庫中。(2) 輸出編碼。伺服器端輸出到瀏覽器的數據，可以使用系統的安全函數來進行編碼或轉義來防範XSS攻擊。在PHP中，有htmlentities()和htmlspecialchars()兩個函數可以滿足安全要求。相應的JavaScript的編碼方式可以使用JavascriptEncode。(3) 安全編碼。開發需盡量避免Web客戶端文檔重寫、重定向或其他敏感操作，同時要避免使用客戶端數據，這些操作需盡量在伺服器端使用動態頁面來實現。(4) HttpOnly Cookie。預防XSS攻擊竊取用戶cookie最有效的防禦手段。Web應用程序在設置cookie時，將其屬性設為HttpOnly，就可以避免該網頁的cookie被客戶端惡意JavaScript竊取，保護用戶cookie信息。(5)WAF(Web Application Firewall)，Web應用防火牆，主要的功能是防範諸如網頁木馬、XSS以及CSRF等常見的Web漏洞攻擊。由第三方公司開發，在企業環境中深受歡迎。
4、SQL注入(SQL Injection)，應用程序在向後台資料庫傳遞SQL(Structured Query Language，結構化查詢語言)時，攻擊者將SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字元串，最終達到欺騙伺服器執行惡意的SQL命令。
防範：(1) 防止系統敏感信息泄露。設置php.ini選項display_errors=off，防止php腳本出錯之後，在web頁面輸出敏感信息錯誤，讓攻擊者有機可乘。(2) 數據轉義。設置php.ini選項magic_quotes_gpc=on，它會將提交的變數中所有的』(單引號)，」(雙引號)，\(反斜杠)，空白字元等都在前面自動加上\。或者採用mysql_real_escape()函數或addslashes()函數進行輸入參數的轉義。(3) 增加黑名單或者白名單驗證。白名單驗證一般指，檢查用戶輸入是否是符合預期的類型、長度、數值范圍或者其他格式標准。黑名單驗證是指，若在用戶輸入中，包含明顯的惡意內容則拒絕該條用戶請求。在使用白名單驗證時，一般會配合黑名單驗證。
5、上傳漏洞在DVBBS6.0時代被黑客們利用的最為猖獗，利用上傳漏洞可以直接得到WEBSHELL，危害等級超級高，現在的入侵中上傳漏洞也是常見的漏洞。該漏洞允許用戶上傳任意文件可能會讓攻擊者注入危險內容或惡意代碼，並在伺服器上運行。
防範： (1)檢查伺服器是否判斷了上傳文件類型及後綴。 (2) 定義上傳文件類型白名單，即只允許白名單裡面類型的文件上傳。 (3) 文件上傳目錄禁止執行腳本解析，避免攻擊者進行二次攻擊。 Info漏洞 Info漏洞就是CGI把輸入的參數原樣輸出到頁面，攻擊者通過修改輸入參數而達到欺騙用戶的目的。
④ 寬頻帳戶不支持WEB認證怎麼辦 寬頻
在小區寬頻或者酒店、學校等環境下，寬頻運營商通過WEB認證方式來認證上網用戶。也就是電腦連接網路後，打開網頁會彈出認證界面，輸入用戶名密碼才能上網。下圖為某小區的WEB認證頁面：
⑤ JavaWeb 對於數據從前台頁面流轉到後台,並於mysql資料庫中數據比對的整個流程的理解.
oracle的sql腳本可以改成MySQL很簡單，自己學習一下 對自己有提高。
⑥ web伺服器被攻擊，從哪些日誌，或者現象可以看出來
如果伺服器（網站）被入侵了,一般都是伺服器或者網站存在漏洞，被黑客利用並提權入侵的，導致伺服器中木馬，網站被掛黑鏈，被篡改，被掛馬。解決辦法：如果程序不是很大，可以自己比對以前程序的備份文件，然後就是修復，或者換個伺服器，最好是獨立伺服器。也可以通過安全公司來解決，國內也就Sinesafe和綠盟等安全公司 比較專業.
⑦ 防止web頁面表單重復提交的方法有哪些
最常用的方法就是利用token。即：
1、在生成頁面的時候生成一個token（隨機字元串），並把它同時寫入表單的某個hidden中，和服務端的session中。
2、客戶端提交表單到伺服器時，比對表單中的token與session中的token是否一致。若不一致則認為是無效的請求。
3、不管第2步的校驗是否通過，token只要使用一次後就立即作廢（即：從session中銷毀）。同時token也可以關聯時間信息，超時後也自動作廢。
這樣，即便客戶端重復提交，也只有第一次的請求能夠成功。
⑧ 寬頻帳戶不支持WEB認證怎麼辦
故障現象：Web認證環境下，用戶在Portal登錄頁輸入正確的用戶名和密碼，認證不成功，提示認證異常的錯誤信息。
故障可能原因
1、接入設備的WEB認證配置錯誤
2、接入設備配置、ePortal和SAM配置信息不一致
3、ePortal伺服器啟動了系統自帶SNMP組件
4、接入設備未做降噪配置
故障處理流程
4、故障處理步驟
步驟1排查接入設備的Web認證配置是否正確
1. 通過Console口登錄到接入設備，執行」show run「命令，查看當前設備的配置信息。
2. 若Web認證接入設備為有線交換機，請比對以下典型配置，檢查設備的web認證配置是否正確。
² 典型的有線交換機web認證模板（以S26系列設備為例）如下：
Ruijie# configure terminal
/* 配置通信密鑰，對ePortal伺服器返回的鏈接加密，實例中通訊密鑰是「ruijie」 */
Ruijie(config)# web-auth portal key ruijie
/* 未認證用戶訪問直通地址，用於學習網關arp，通常設置網關（如192.168.33.1）為直通地址 */
Ruijie(config)# http redirect direct-site 192.168.33.1 arp
/* 設置重定向頁面的主頁，實例中「http://192.168.51.180/eportal/index.jsp」為ePortal重定向地址，其中IP地址可替換ePortal服務IP地址 */
Ruijie(config)# http redirect homepage http://192.168.51.180/eportal/index.jsp
/* 設置直通地址，即ePortal伺服器地址，如「192.168.51.180」 */
Ruijie(config)# http redirect 192.168.51.180
Ruijie(config)# interface FastEthernet 0/1
/* 埠必須開啟web認證受控，否則該埠下接設備web認證不生效 */
Ruijie(config-if-FastEthernet 0/1)# web-auth port-control
/* 啟用snmp community配置，其中團體名為public，可根據實際情況修改 */
Ruijie(config)# snmp-server community public rw
/* 配置web認證下線使用的snmp報文參數 ，其中主機地址為eportal伺服器IP（192.168.51.180），團體名為public，均可根據實際情況修改*/
Ruijie(config)# snmp-server host 192.168.51.180 informs version 2c public web-auth
Ruijie(config)# snmp-server enable traps web-auth
注意： 本例中snmp-server community 是重要配置，Web認證信息驗證通過後，會通知設備打開上網通道，若community key沒有配置會配置不正確，都會導致打開上網通道失敗，web認證不成功。
3. 若Web認證接入設備為無線交換機，存在兩種Web認證配置方法，分別稱為一代Portal認證和二代Portal認證，請比對以下典型配置，檢查設備的web認證配置是否正確。
²典型的無線一代portal認證模板（以WS57系列設備為例）如下：
Ruijie# configure terminal
/* 配置通信密鑰，對ePortal伺服器返回的鏈接加密，實例中通訊密鑰是「ruijie」 */
Ruijie(config)# web-auth portal key ruijie
/* 設置直通地址，即ePortal伺服器地址，如「172.20.1.100」 */
Ruijie(config)# http redirect 172.20.1.100
/* 設置重定向頁面的主頁，實例中「http://172.20.1.100/eportal /index.jsp」為ePortal重定向地址，其中IP地址可替換ePortal服務IP地址 */
Ruijie(config)# http redirect homepage http://172.20.1.100/eportal/index.jsp
/* 啟用snmp community配置，其中團體名為web-auth，可根據實際情況修改 */
Ruijie(config)# snmp-server community web-auth rw
Ruijie(config)# snmp-server enable traps web-auth
/* 配置web認證下線使用的snmp報文參數 ，其中主機地址為eportal伺服器IP（172.20.1.100），團體名為web-auth，均可根據實際情況修改*/
Ruijie(config)# snmp-server host 172.20.1.100 inform version 2c web-auth web-auth
Ruijie(config)# wlansec 100
/* 必須啟用基於WLAN的web認證受控，否則web認證不生效 */
Ruijie(wlansec)# webauth
Ruijie(wlansec)# exit
注意： 本例AC採用一代Portal配置，認證原理與有線交換機基本一致。同樣的，snmp-server community是重要配置，Web認證信息驗證通過後，會通知設備打開上網通道，若communitykey沒有配置會配置不正確，都會導致打開上網通道失敗，web認證不成功。
²典型的無線二代portal認證模板（以WS57系列設備為例）如下：
Ruijie# configure terminal
/* 創建全局Portal伺服器，伺服器名為default、IP地址172.20.1.10（可修改ePortal服務IP）、認證主頁http://172.20.1.10/eportal/index.jsp(URL內的IP地址可修改為ePortal服務IP) */
Ruijie(config)# portal-server default ip 172.20.1.10 url http://172.20.1.10/eportal/index.jsp
/* 配置default伺服器為全局使用的Portal伺服器 */
Ruijie(config)# web-auth portal-type v2 default
/* 啟用AAA認證記賬功能 */
Ruijie(config)# aaa new-model
/* 配置Radius-server主機地址和通訊口令，host是SAM伺服器IP地址，如172.20.1.20（可修改）；key為通訊口令，如ruijie（可修改） */
Ruijie(config)# radius-server host 172.20.1.20 key ruijie
/* 配置AAA的Web認證方法列表，使用默認的RADIUS組 */
Ruijie(config)# aaa authentication web-auth default group radius
/* 配置AAA的記賬方法列表，使用默認的RADIUS組 */
Ruijie(config)# aaa accounting network default start-stop group radius
/* 開啟radius動態擴展授權，支持強制用戶下線（DM）等功能 */
Ruijie(config)# radius dynamic-authorization-extension enable
Ruijie(config)# wlansec 100
/* 啟用二代portal認證 */
Ruijie(wlansec)# web-auth portal-type v2 default
/* 基於WLAN開啟Web認證功能 */
Ruijie(wlansec)# webauth
Ruijie(wlansec)# exit
注意： 本例AC採用二代Portal認證配置，與一代不同的是，AC還承擔Radius認證客戶端的角色，因此AAA配置是必須要有的，若是缺少AAA配置，web認證就無法正常進行。
檢查設備Web認證配置，排除配置錯誤導致認證失敗的問題，若依然認證不成功，則進入下一步驟的排查。
步驟2排查接入設備與ePortal和SAM配置信息是否一致
1. 在認證PC機的瀏覽器地址欄內輸入訪問網站的URL地址，如「http://www..com」，提交請求，頁面跳轉到認證登錄頁面，（以ePortal1.41認證頁面為例，其他版本認證頁面大體也是這樣的。）
2. 在認證登錄頁面，輸入用戶名密碼，點擊「登錄」按鈕，頁面頂部出現「認證失敗！"的提示。
3. 首先登錄ePortal系統，查看日誌管理下的日誌信息。
4. 若頁面認證失敗且ePortal日誌出現類似「用戶(xxx)認證失敗,原因：設備community配置錯誤導致設備不通,打開設備(xxx.xxx.xxx.xxx)上網通道失敗」的提示，說明接入設備的community key不正確
5. 若頁面認證失敗且ePortal日誌出現類似「用戶(xxx)認證失敗,Radius伺服器沒有響應」的提示，說明Web認證過程中，在進行Radius 認證的環節出現了問題。
按以下步驟檢查ePortal和SAM配置的Radius Key值是否一致。
1) 若接入設備是有線交換機或一代Portal認證的AC設備，ePortal作為認證客戶端發起Radius認證，需要檢查ePortal系統配置和SAM系統的設備配置。
首先，查看ePortal系統配置的Radius Key，
其次，查看SAM登記的RG-ePortal的設備Key，
檢查ePortal系統配置的Radius Key和SAM登記的RG-ePortal的設備Key的值，若兩者的值不一致，則需要修改成相同的值。
2) 若接入設備是一代Portal認證的AC設備，AC設備作為認證客戶端發起Radius認證，因此需要檢查AC設備和SAM系統的設備配置。
首先，查看AC設備的配置信息，通過Console口登錄設備，進入特權模式，執行「show run」命令，找到radius-server信息，查看key值
其次，查看SAM登記的AC設備的Key
檢查AC設備的Radius Key和SAM系統登記的AC設備Key的值，若兩者的值不一致，則需要修改成相同的值。
5. 檢查接入設備配置、ePortal和SAM的相關配置，排除配置錯誤導致認證失敗的問題，若依然認證不成功，則進入下一步驟的排查。
步驟3排查ePortal伺服器是否啟用系統自帶SNMP組件
1. 在認證PC機的瀏覽器地址欄內輸入訪問網站的URL地址，如「http://www..com」，提交請求，頁面跳轉到認證登錄頁面（以ePortal1.41認證頁面為例，其他版本認證頁面大體也是這樣的。）
2. 在認證登錄頁面，輸入用戶名密碼，點擊「登錄」按鈕，頁面頂部出現「認證失敗！"的提示
需要注意的是，雖然頁面提示「認證失敗」，但實際上已經可以正常連通網路，說明上網通道已經被打開了。
3. 登錄ePortal系統，查看日誌管理下的日誌信息，發現「用戶(xxx)上線失敗,由於出現異常情況」的提示
4. 登錄SAM系統，查看在線用戶表，發現該用戶已在線
5. 查看當前ePortal伺服器的系統服務是否異常，通過「開始」-- 「運行」，執行「services.msc「命令
打開服務列表窗口，查找是否存在「SNMP Service」的服務，且已經被啟動
若系統的SNMP Service服務被啟動，則與ePortal的SNMP服務沖突了，導致SNMP功能失效。
6. 依照以下步驟關閉系統SNMP服務
1) 雙擊「SNMP Service」
2) 啟動類型修改為「手動」
3) 手動停止SNMP Service
4) 點擊「確定」，使當前配置生效
7. 關閉系統SNMP服務後，重啟ePortal服務。
排除SNMP服務沖突的問題後，若依然認證不成功，則進入下一步驟的排查。
步驟4排查接入設備是否支持降噪配置
在網路環境沒有變化的情況下，若認證業務高峰期出現Web認證失敗問題，而在平時都可以正常認證，需要檢查web認證的接入設備是否支持降噪。
降噪是指接入設備屏蔽非瀏覽器發起的http請求，需要接入設備更新到特定軟體版本才能支持。按照以下步驟確認接入設備是否支持降噪配置：
1. 首先查看接入設備的軟體版本信息，通過Console口登錄接入設備，查看設備軟體版本信息；
2. 若接入設備為交換機設備，進入特權模式，輸入「show version」
查看software version信息，若軟體版本低於RGOS 10.3版本，則交換機版本不支持web認證降噪，需要升級到最新版本，請聯系4008111000索取最新版本信息。
3. 若接入設備為AC設備，進入特權模式，輸入「show version」，
查看software version信息，若軟體版本低於RGOS 10.4(1T17)版本，則AC交換機版本不支持web認證降噪，需要升級到最新版本，聯系4008111000協助處理。
4. 若接入設備為ACE設備，首先識別ACE硬體版本，若是ACEv5.0設備直接輸入「show version」，
查看version信息，若軟體版本低於3.4.0版本，則AC交換機版本不支持web認證降噪，需要升級到最新版本。ACEv3.0不支持降噪功能，請先升級到ACEv5.0版本。具體ACE升級版本和操作步驟，請聯系4008111000協助處理。
檢查接入設備版本符合降噪配置的要求，若依然認證不成功，則進入下一步驟的排查。
步驟5收集信息並聯系4008111000協助處理
撥打4008111000尋求技術支持，收集如下故障信息，進行故障進一步處理。
1. ePortal和SAM的軟體版本號
登錄ePortal系統，點擊「關於系統」圖標，彈出版本信息。
登錄SAM系統，點擊右下角「關於」圖標，彈出版本信息。
2. 接入設備的配置信息
若接入設備為交換機或AC無線設備，登錄設備進入特權模式，執行「show run」命令，將輸出結果保存成文件。
若接入設備為ACE設備，請將「認證伺服器配置」的配置內容截圖。
3. ePortal伺服器填寫的接入設備信息
進入「設備管理」菜單，選擇查看設備，彈出設備詳細信息。
4. SAM伺服器填寫的接入設備信息
進入「設備管理」菜單，選擇查看設備，彈出設備詳細信息。
5. 提供PC端、ePortal服務端、SAM服務端的報文
1) 分別在PC端、ePortal服務端和SAM服務端，打開wireshark工具，並監控網卡，准備開始抓包；
2) 在PC上執行一次完整的web認證操作，輸入用戶名密碼，直至出現認證失敗提示；
3) 完成web認證操作後，停止wireshark抓包，將抓取的報文保存成pcap文件；
4) 提交pcap報文時，請附帶說明報文文件的來源（PC端、ePortal端、SAM端）以及來源的IP地址。
⑨ web前端diff 演算法深入一下
有同學問：能否詳細說一下 diff 演算法。
詳細的說，請閱讀這篇文章，有疑問的地方歡迎留言一起討論。
因為 diff 演算法是 vue2.x ， vue3.x 以及 react 中關鍵核心點，理解 diff 演算法，更有助於理解各個框架本質。
說到「diff 演算法」，不得不說「虛擬 Dom」，因為這兩個息息相關。
比如：
等等
我們先來說說虛擬 Dom，就是通過 JS 模擬實現 DOM ，接下來難點就是如何判斷舊對象和新對象之間的差異。
Dom 是多叉樹結構，如果需要完整的對比兩棵樹的差異，那麼演算法的時間復雜度 O(n ^ 3)，這個復雜度很難讓人接收，尤其在 n 很大的情況下，於是 React 團隊優化了演算法，實現了 O(n) 的復雜度來對比差異。
實現 O(n) 復雜度的關鍵就是只對比同層的節點，而不是跨層對比，這也是考慮到在實際業務中很少會去跨層的移動 DOM 元素。
虛擬 DOM 差異演算法的步驟分為 2 步：
實際 diff 演算法比較中，節點比較主要有 5 種規則的比較
部分源碼 https://github.com/vuejs/vue/blob//src/core/vdom/patch.js#L501 如下：
在 reconcileChildren 函數的入參中
diff 的兩個主體是：oldFiber（current.child）和 newChildren（nextChildren，新的 ReactElement），它們是兩個不一樣的數據結構。
部分源碼
很多時候手工優化 dom 確實會比 virtual dom 效率高，對於比較簡單的 dom 結構用手工優化沒有問題，但當頁面結構很龐大，結構很復雜時，手工優化會花去大量時間，而且可維護性也不高，不能保證每個人都有手工優化的能力。至此，virtual dom 的解決方案應運而生。
virtual dom 是「解決過多的操作 dom 影響性能」的一種解決方案。
virtual dom 很多時候都不是最優的操作，但它具有普適性，在效率、可維護性之間達到平衡。
virutal dom 的意義：
vue2.x 的 diff 位於 patch.js 文件中，該演算法來源於 snabbdom，復雜度為 O(n)。了解 diff 過程可以讓我們更高效的使用框架。react 的 diff 其實和 vue 的 diff 大同小異。
最大特點：比較只會在同層級進行, 不會跨層級比較。
對比之前和之後：可能期望將 直接移動到
的後邊，這是最優的操作。
但是實際的 diff 操作是：
vue 中也使用 diff 演算法，有必要了解一下 Vue 是如何工作的。通過這個問題，我們可以很好的掌握，diff 演算法在整個編譯過程中，哪個環節，做了哪些操作，然後使用 diff 演算法後輸出什麼？
解釋：
mount 函數主要是獲取 template，然後進入 compileToFunctions 函數。
compileToFunction 函數主要是將 template 編譯成 render 函數。首先讀取緩存，沒有緩存就調用 compile 方法拿到 render 函數的字元串形式，在通過 new Function 的方式生成 render 函數。
compile 函數將 template 編譯成 render 函數的字元串形式。後面我們主要講解 render
完成 render 方法生成後，會進入到 mount 進行 DOM 更新。該方法核心邏輯如下：
上面提到的 compile 就是將 template 編譯成 render 函數的字元串形式。核心代碼如下：
compile 這個函數主要有三個步驟組成：
分別輸出一個包含
parse 函數：主要功能是 將 template 字元串解析成 AST（抽象語法樹） 。前面定義的 ASTElement 的數據結構，parse 函數就是將 template 里的結構（指令，屬性，標簽） 轉換為 AST 形式存進 ASTElement 中，最後解析生成 AST。
optimize 函數（src/compiler/optomizer.js）:主要功能是 標記靜態節點 。後面 patch 過程中對比新舊 VNode 樹形結構做優化。被標記為 static 的節點在後面的 diff 演算法中會被直接忽略，不做詳細比較。
generate 函數（src/compiler/codegen/index.js）:主要功能 根據 AST 結構拼接生成 render 函數的字元串 。
其中 genElement 函數（src/compiler/codgen/index.js）是根據 AST 的屬性調用不同的方法生成字元串返回。
總之：
就是 compile 函數中三個核心步驟介紹，
patch 函數 就是新舊 VNode 對比的 diff 函數，主要是為了優化 dom，通過演算法使操作 dom 的行為降低到最低， diff 演算法來源於 snabbdom，是 VDOM 思想的核心。snabbdom 的演算法是為了 DOM 操作跨級增刪節點較少的這一目標進行優化， 它只會在同層級進行，不會跨層級比較。
總的來說：
在創建 VNode 就確定類型，以及在 mount/patch 的過程中採用位運算來判斷一個 VNode 的類型，在這個優化的基礎上再配合 Diff 演算法，性能得到提升。
可以看一下 vue3.x 的源碼：https://github.com/vuejs/vue/blob//src/core/vdom/patch.js
對 oldFiber 和新的 ReactElement 節點的比對，將會生成新的 fiber 節點，同時標記上 effectTag，這些 fiber 會被連到 workInProgress 樹中，作為新的 WIP 節點。樹的結構因此被一點點地確定，而新的 workInProgress 節點也基本定型。在 diff 過後，workInProgress 節點的 beginWork 節點就完成了，接下來會進入 completeWork 階段。
snabbdom 演算法：https://github.com/snabbdom/snabbdom
定位：一個專注於簡單性、模塊化、強大功能和性能的虛擬 DOM 庫。
snabbdom 中定義 Vnode 的類型(https://github.com/snabbdom/snabbdom/blob//src/vnode.ts#L12)
init 函數的地址：
https://github.com/snabbdom/snabbdom/blob//src/init.ts#L63
init() 函數接收一個模塊數組 moles 和可選的 domApi 對象作為參數，返回一個函數，即 patch() 函數。
domApi 對象的介麵包含了很多 DOM 操作的方法。
源碼：
https://github.com/snabbdom/snabbdom/blob//src/init.ts#L367
源碼：
https://github.com/snabbdom/snabbdom/blob//src/h.ts#L33
h() 函數接收多種參數，其中必須有一個 sel 參數，作用是將節點內容掛載到該容器中，並返回一個新 VNode。
在 vue2.x 不是完全 snabbdom 演算法，而是基於 vue 的場景進行了一些修改和優化，主要體現在判斷 key 和 diff 部分。
1、在 snabbdom 中 通過 key 和 sel 就判斷是否為同一節點，那麼在 vue 中，增加了一些判斷 在滿足 key 相等的同時會判斷，tag 名稱是否一致，是否為注釋節點，是否為非同步節點，或者為 input 時候類型是否相同等。
https://github.com/vuejs/vue/blob//src/core/vdom/patch.js#L35
2、diff 差異，patchVnode 是對比模版變化的函數，可能會用到 diff 也可能直接更新。
https://github.com/vuejs/vue/blob//src/core/vdom/patch.js#L404