前言
記錄一些網絡以及wifi的基礎內容，會持續補充，以便后續有需要的時候查漏補缺
網絡分層
- 分層的原因？如果不分層的話是否可行？
- 有了IP地址為何還需要mac地址？僅從地址作用上看用ipv6來取代mac地址是否可以？
為何分層？
Q1_個人理解
這種問題網上一大堆,其實我們沒有必要糾結這種問題，這種成熟的架構時至今日是這個樣子的，必定有其道理，搜索了下網上對此的解釋，有不少是拿比喻來解釋。
通過比喻向初學者解釋一個知識點其實是不合適的，但是我們往往在深刻理解了一個東西后會想到用一個比喻，試圖用它向不懂的人解釋。比喻的意義往往是一群懂的人之間心領神會的交流方式罷了，所以就我個人而言，學習一個知識點的時候最好不用試圖通過比喻來理解。
我們從軟件設計模式的角度來看，其實分層是不是有點像Andorid的架構設計模式，不論是MVC,MVP,MVVM等，其本質都是為了解耦, 為了更方便職責明確, 也便於后續的維護調試,后續修改的話只要修改一層即可而不會牽一發而動全身。
既然你說是因為職責明確，那么每一層都有什么職責呢？
比如傳輸層解決的是進程定位的問題，網絡層解決數據包尋路的問題，數據鏈路層解決局域網傳輸的問題等。
歸納起來就是一句話：
當一個系統足夠復雜時，通過聚合分為不同層次或不同模塊， 每層或模塊都是內聚的，對外屏蔽復雜性。
那么宏觀上看去，管理和問題定位很容易到具體層次和模塊。 然后層層遞進，很容易定位問題。
為何需要mac層？
Q2_個人理解
這個問題在網上試圖查找資料時，很多說的很多都是因為ip地址會變，mac不變的緣故。
但是包在到達目的地之前是不知道目標mac地址的，mac層包裝ip層的時候，對方的mac層地址還不一定是目標（最終的）mac地址，有可能是相連的一台路由器的mac地址，解碼之后看ip，發現ip不在這個局域網內，然后再次包裝一層mac地址，發給相連（也有可能不是相連，反正就是根據某種規則規定的下一個路由器）路由器，所以ip地址會變，mac不變的這樣的解釋是不合理的嗎？最起碼我覺得這種說法沒有解釋清楚這個問題。
網卡出廠就設置了mac地址是唯一的，我們也知道ip地址是可變的，就算機器沒有移動，一直處在一個局域網內，重啟網絡也可能會導致ip地址改變。
數據包上ip 地址的作用是在外網上投遞用的，內網就不行了，必須要用mac，使用mac地址的其中一個原因就是為了在局域網內確認到那台正確的計算機。
在知乎上找到一個比較好的解釋為何需要mac層，和上面的解釋是一樣的
信息傳遞時候，需要知道的其實就是兩個地址：
• 終點地址（Final destination address）
• 下一跳的地址（Next hop address）
IP地址本質上是終點地址，它在跳過路由器（hop）的時候不會改變，而MAC地址則是下一跳的地址，每跳過一次路由器都會改變。
歸納下來就是一句話：mac地址局域網尋址，ip地網絡尋址
這就是為什么還要用MAC地址的原因之一，它起到了記錄下一跳的信息的作用
用ipv6來取代mac地址是否可以？
既然ipv6號稱可以給世界上每一個沙子都分配一個ip地址，那為何不直接取消mac地址，給每一個網卡出場時分配一個ip地址。
這是一個看起來比較天馬行空的問題。
前面提到mac地址起到“下一跳IP地址”的作用，那么我們用ipv6反正不用擔心ip不夠用的問題對吧，假設交換機也支持IP地址轉發（現在的二層交換機不支持這樣做），mac地址好像看上去也並不是必要的對吧？
當然了mac地址不僅僅是標記網卡這一個作用，先假設它只有這么一個作用，想想這樣可行嗎？
很快便想到一個問題就是這個ip地址得廣播出去，假設地球上有幾百億的設備，轉發匹配這幾百億的記錄便不可能實現，需要的存儲太大太大。
這個問題搜索了網上貌似相關的解答比較少，知乎上有一個回答我覺得比較好，照抄過來:
IPv6定義了多種地址，其中一種地址叫Link-local地址，看上去可以取代mac地址，可是二層三層的封裝已經通行於全世界，ipv6何德何能可以打破所有網絡設備，主機，都在使用的規范？打破規范帶來的網絡中斷，遷移成本這些也是難以實現的
tcpip協議棧設計出來那天就沒有自己定義二層協議，也沒有取代二層協議，而是去兼容二層協議，僅此而已，讓自己能跑在各種二層協議之上
DHCP
本地抓取的正常流程的bugreport，分別包含logcat&driver日志片段，后續可以作為參考分析
靜態分配和dhcp分配導致的ip沖突報文
Q: DHCP Offer 和 DHCP ACK是廣播包嗎？由什么因素決定的？
A：這個其實是取決於client端的ip協議棧的能力，可以抓個報文看下就知道了。
如果協議棧在初始化過程中，不接收單播IP報文，請在DHCP Discovery / Request報文的Flags里明確告知服務器，通過設置“BROADCAST flag = 1”，服務器就使用廣播來和客戶端通信。
如果協議棧在初始化過程中，可以接收單播IP報文，請在DHCP Discovery / Request報文的Flags里明確告知服務器，通過設置“BROADCAST flag = 0”，服務器就使用單播來和客戶端通信。
既然廣播方式通信適合所有的協議棧，統統使用廣播不就ok了，為何要有這個Flags，豈不是多此一舉？
單播最大的優點：通信是點對點方式，不會影響到廣播域的其它主機。
廣播的特點：通信是點對所有點的方式，會影響到廣播域里其它所有主機
鏈路層放置目標機器的mac地址即可將信息送達客戶端機，非該mac地址的機器收到后會丟棄這個包，此時的ip層目標網絡地址填的就是要分配給該客戶端機的ip地址;
官方文檔說明
Q: 是否存在靜態ip和DHCP Server分配給Client的ip沖突的情況？ 有沖突后會怎么樣？會導致網絡訪問異常？
A：網上找到一篇文章，解釋的不錯，地址：DHCP以及客戶端是如何避免IP沖突
在最后的確認階段，當Client收到DHCP Server發送的DHCPACK報文之后，並不會馬上使用Server分配的這個地址，而是會發送目的地址為Server分配地址的ARP請求報文作最后的確認（即免費ARP）。
如果沒有檢測到沖突，則將此地址與自己綁定。如果檢測到沖突，就向DHCP Server發送DHCPDECLINE報文，在Request IP Address（option 50）字段填入Server提供的發生沖突的IP地址.發送完成后，等待一段時間再開始重新申請IP地址，直至申請到一個可用的IP地址。
Q：DHCP server的地址池是有限的吧？同時有大量的client發起請求會不會存在不夠用的情況？
A: 服務器收到了Discover 包之后，就會從地址池中選擇一個IP准備分配給請求者，當然正常情況下客戶端收到服務器發送的Offer會回復Request進行確認，但是在泛洪攻擊的場景下服務器會收到大量的Discover報文當然也會在地址池為這些請求者執行分配IP的操作並等待客戶端的應答。
在沒有得到客戶端確認的情況下，服務器將會為客戶端保留要分配的IP，當在大量泛洪攻擊的場景下服務器的地址池很快就會滿掉。從而影響正常客戶端的使用。
那我們這個時候就有疑問了，能不能盡可能的擴大這個地址池呢？想象一個極端的情況，地址池中的ip數無窮無盡，這不就不存在這個問題了嗎？
其實只要簡單修改掩碼，就可以實現更多的客戶端接入，別說254，一萬個254都裝的下。
掩碼是用來決定網段大小的，也就是說，一個網段能容納多少個終端（電腦，手機，攝像頭），是由掩碼來決定的。
最常用的掩碼是255.255.255.0，和題主說的一樣，最大的可用ip數量只有254
但如果把掩碼換成255.255.0.0，那么最大可用ip數量，就有256乘256減2，好幾萬了
但是為什么不推薦一個網段主機數太多呢？
在實際項目上，雖然通過掩碼可以讓網段變大，讓網絡的配置和調試變的簡單，但往往還是不用大網段。原因就在於“廣播域”
什么是廣播域，顧名思義，就是1個主機發出的廣播包，可以到達的范圍。
如果一個網段大，那么廣播域就大，就像我們再嘈雜的環境里，會收到大量和自己無關的數據，這些數據將占用我們的帶寬，以及消耗我們各個終端的計算資源。畢竟廣播包，目標地址是所有人，所有人收到都不能視而不見，都要處理。
所以，當終端數比較多的時候，一般會采用多個網段，多個vlan（虛擬局域網）的方法，而不是一下搞個大網段。
網關
這里穿插下網關的概念，什么是網關呢？
如果你去網上搜索，能搜索到的關於網關的解釋大多是這樣的:
網關往往是一個路由器，是一個三層轉發的設備。那么啥叫三層設備？就是把 MAC 頭和 IP 頭都取下來，然后根據里面的內容，看看接下來把包往哪里轉發的設備。
個人理解：
說來慚愧，之前對於網關的認識以為就是路由器，其實這種認識是不准確的。
首先‘網關’一個大概念，不具體特指一類產品，只要連接兩個不同的網絡的設備都可以叫網關；而‘路由器’一般特指能夠實現路由尋找和轉發的特定類產品，路由器很顯然能夠實現網關的功能。
當然電信行業說的‘路由器’又和家用的‘路由器’兩個概念。網關並不總是被視為路由器，路由器是最常見的網關，用於將家庭或企業網絡連接到Internet。
PC本身不具備路由尋址能力，所以PC要把所有的IP包發送到一個默認的中轉地址上面進行轉發，也就是默認網關。這個網關可以在路由器上，可以在三層交換機上，可以在防火牆上，可以在服務器上，所以和物理的設備無關。
網關只針對某個局域網，是某個局域網的出口地址，而一個路由器由多個網關組成
任何一個想發往其他局域網的包，都會到達其中一只手，被拿進來，拿下 MAC 頭和 IP 頭，看一下，根據自己的路由算法，選擇另一只手，加上 IP 頭和 MAC 頭，然后扔出去。
如果離開本局域網，就需要經過網關，網關是路由器的一個網口；路由器是一個三層設備，里面有如何尋找下一跳的規則；
WIFI漫游
下面這個圖摘自高通文檔上，主要是漫游的一個流程
代碼中關於漫游的原因，更加細致
本地抓取的9434附錄屏的漫游日志，類型：Dense roaming
上面fw中打印的roam reason對應的代碼地址(qcom)
vendor/qcom/opensource/wlan/fw-api/fw/wmi_unified.h
順便解釋下本地抓取的這份漫游reason 7對應的是DENSE roaming的解釋，摘自高通文檔
Dense roaming
Dense-roaming mechanism is a new feature of location retrieval function (LRF) 3.0. This feature retains high throughput when many roamable APs are present nearby and the data traffic is high then.
The original Wi-Fi roaming mechanism is designed to enable roaming when the current RSSI value reaches the defined RSSI threshold value, for example, -76 dBm.
However, in a high dense environment where there are many roamable APs, it is better to start roaming earlier when the traffic is high because high throughput is maintained for heavy traffic with minimal power consumption impact. Dense roaming functions in such a manner to retain high throughput during periods of heavy traffic.
To provide this value-added enhancement, the dense roaming mechanism is designed with the following two principles.
■ Relying on other triggered scans, sniffing is performed on the management packets to determine the number of roamable APs that are present then in the environment.
■ If a dense roaming environment is found (that is, the number of the found roamable APs is bigger than the configured dense roamable AP threshold value), and if there is significant traffic at that moment, then switch to use the dense RSSI threshold value so that the roaming is triggered earlier.
MTK online上關於MTK的漫游策略如下圖，其實和qcom大同小異，大的流程都是一樣的
如下是平時分析漫游可能會用到的關鍵字
//Logcat:
CTRL-EVENT-DISCONNECTED|CTRL-EVENT-CONNECTED|fetchRssiLinkSpeedAndFrequencyNative|NL80211_CMD_ROAM|(set AP RSN IE)|LOST_PROVISIONING|wpa_supplicant: wlan0: State
//fw log
VDEV_MGR_MY_BEACON_RECEIVED|ROAM_LOW_RSSI_INTERRUPT|PEER_ASSOC|ROAM_BETTER_CANDIDATE_FOUND|ROAM_SCAN_REQUESTED|VDEV_MGR_FIRST_BMISS_DETECTED|ROAM_FINAL_BMISS_RECVD|roaming attempt to bssid|RSSI_MONITOR_GET_BEACON_RSSI_AVG
- 觸發漫游的原因有哪些？
- 漫游到哪個候選AP(假設存在)? 有哪些評判條件？
- 漫游會斷線嗎？會重新走四次握手嗎？
ARP&NDP
上面是ARP的一個簡單流程，這里涉及到一個緩存的過程，大體解釋如下:
為了避免機器每次都使用ARP協議發送ARP請求，在每台機器的本地會進行ARP緩存。
–>只要涉及到緩存，那就是空間換時間的設計思想
- 一般機器都是先查本地ARP緩存
- 本地ARP緩存查不到，再去發送ARP請求在局域網中去找目標IP地址對應的MAC地址
當然機器會不斷地上線下線，IP 也可能會變，所以 ARP 的 MAC 地址緩存過一段時間就會過期
ipv6 ND
地址解析過程中使用了兩種ICMPv6報文：鄰居請求報文NS（Neighbor Solicitation）和鄰居通告報文NA（Neighbor Advertisement）。
• NS報文：Type字段值為135，Code字段值為0，在地址解析中的作用類似於IPv4中的ARP請求報文。
• NA報文：Type字段值為136，Code字段值為0，在地址解析中的作用類似於IPv4中的ARP應答報文。
NS報文
arp request
Q：什么是ARP風暴？
A：ARP廣播時，交換機會將一個端口收到的包轉發到其它所有的端口上。
比如數據包經過交換機A到達交換機B，交換機B又將包復制為多份廣播出去。
如果整個局域網存在一個環路，使得數據包又重新回到了最開始的交換機A，這個包又會被A再次復制多份廣播出去。
如此循環，數據包會不停得轉發，而且越來越多，最終占滿帶寬，或者使解析協議的硬件過載，行成廣播風暴。
DNS
如果分析類似網頁加載不出來的問題時候，我們首先需要清楚的知道加載一個網頁的流程
• DNS 解析:將域名解析成 IP 地址
• TCP 連接：TCP 三次握手
• 發送 HTTP 請求
• 服務器處理請求並返回 HTTP 報文
• 瀏覽器解析渲染頁面
• 斷開連接：TCP 四次揮手
Q: 對於已連接網絡無法上網問題的快速排查思路？
斷線問題
如下是本地測試打印，操作步驟是主動刪除已連接熱點
如下是本地測試打印，操作步驟是超出范圍斷開
Q: 斷線一般有哪些原因？
A:
- 用戶手動斷開
- FWK斷開
- Beacon miss斷線
- KickOut斷線
- Nud failed斷線
- Rx disassoc or deauth斷線
Q: 如何通過日志如何快速定位斷線是上層還是底層發起的？
A:如果是底層斷線，會先收到底層斷線發上來的DISCONNECT Event，然后supplicant才把state切到DISCONENCTED.
如果是上層斷線，disconnection request會先到supplicant，supplicant state會先切到DISCONNECTED, 發送disconnect request給driver去真正端開wifi連接.
歸納下來就是迅速定位是底層還是上層有一個好的辦法就是：
過濾這兩個關鍵字：wpa_supplicant: nl80211 , wpa_supplicant: wlan0看看先后關系
Q: 有哪些日志關鍵字可以過濾來分析斷線問題？
如下是一些關鍵字，當然前提你得清楚這些關鍵字的含義
//bugreport：
CMD_IP_REACHABILITY_LOST|NETWORK_DISCONNECTION_EVENT|Received Heart Beat Failure|dev wlan0 INCOMPLETE|get addr info failed|arp who-has|ICMPv4 dst|LOST_PROVISIONING|wma_peer_sta_kickout_event_handler|NetConnTag|No address associated with hostname|DnsMain|IcmpReader|NetworkProvider|NetworkDiagnostics|DnsService|PROBE_DNS
//driver:
STA kickout|blm_fill_reject_list|wma_peer_sta_kickout_event_handler|Sending Deauth frame with reason
//fw
ROAM_STA_KICKOUT_RECV|consecutive failure=
fw的關鍵字主要是看tx fail的閥值是否達到了上限，很多都是RSSI值太低導致，還有一種常見的問題是AP沒有回ack導致手機一直tx fail,最終觸發kickout，這種需要提供sniffer log確認。
連接不上問題
本地測試密碼錯誤抓取的bugreport，以便后續分析日志對照
//Auth fail
rx Auth frame from peer with failure code對應的fail code參見 802.11 Association Status Codes
https://wiki.n.miui.com/display/~lihaizhou/802.11+Association+Status+Codes
eg: code = 17 Association denied because AP is unable to handle additional associated stations
// portal fail
2020-12-03T18:08:11.852 - PROBE_DNS connect.rom.miui.com 12511ms FAIL
2020-12-03T18:08:39.391 - PROBE_HTTP http://connect.rom.miui.com/generate_204 Probe failed with exception java.net.UnknownHostException: Unable to resolve host "connect.rom.miui.com": No address associated with hostname
2020-12-03T18:08:39.394 - Probably not a portal: exception java.net.UnknownHostException: Unable to resolve host "m.baidu.com": No address associated with hostname
//filter：
Cannot add/update network|save network failed|All saved networks are lost|Association Rejection|CTRL-EVENT-ASSOC-REJECT|EVENT_DHCPACTION_TIMEOUT|NETWORK_SELECTION_DISABLED_BY_WRONG_PASSWORD|AUTHENTICATION_FAILURE|pre-shared key may be incorrect|wpa_supplicant: wlan0
//driver：
Auth frame from peer with failure|Auth Failure occurred
Q：連接不上通常有哪幾種情形？如何快速甄別？
Auth失敗
一般driver日志中會打印出Auth frame from peer with failure后面對應code值，code值查閱
802.11 Association Status Codes即可，正常返回的是0，如果問題有sniffer的話，也可以看auth幀的status值
像數值17 對應的含義 Association denied because AP is unable to handle additional associated stations 被AP拒絕了，這時候同時連接AP的sta可能太多了超過了AP的負載
四次握手異常
1,2握手失敗是密碼錯誤導致，其它的可能是路由器設置問題
DHCP失敗
DHCP請求沒有回復，看看當時rssi判斷信號弱不弱，為什么連接成功但是DHCP會失敗：因為連接過程一直發送管理幀，數據小，DHCP是數據幀，比較大，在信號弱時無法正常交互。