在您控制硬體配置並可以確定具有相同硬體型號的所有設備確實具有其網路介面的唯一 MAC 位址的情況下，編寫使用該假設的程式碼是否有任何缺點？ （根據一些回應請注意：我不會使用這種假設編寫網路程式碼。這只是一種為每個設備提供 uuid 的低接觸方式，而無需在之前使用 id 手動生成和更新設備 HDD部署到現場）
背景故事是我正在研究為客戶實現私人硬體物聯網類型的實作。我們將提供一組具有網路功能的硬體設備，以安裝在遠端位置。然後，這些設備將透過發送訊息與 API 進行通訊。為了降低設定複雜性，我希望在訊息中發送裝置上網路介面的 MAC 位址，將這些訊息與 API 端的「device_id」連結起來。我的想法是，透過使其在使用前不必在設備上進行設置，只需在正常操作期間對其進行查詢即可。我可以放心地假設我們可以確定每個設備的 MAC 位址實際上是唯一的，並且我們可以控制何時/是否更換設備，以了解該 device_id 的訊息現在將具有不同的 MAC 位址。
答案1
根據您在設定過程中可以確認的聲明，製造商 MAC 實際上在您正在建立的裝置網路中是唯一的（這本身並不是確定性的，儘管應該是確定性的），您可能可以繼續進行，但請考慮以下問題：
您是否使用 MAC 進行安全檢查（驗證、授權）？如果是這樣，MAC 是不夠的。甚至不考慮它。使用加密結構，並安全地傳輸任何身份驗證請求。
48 位元寬夠嗎？可能是這樣，但值得一問。
您是否需要透過更換網路卡來修理設備？
如果您確實要更換整個裝置或更換其網路卡，您是否需要能夠將新位址與資料庫中的現有金鑰相關聯，以確保部署位置資料收集的連續性？
是否存在任何維護介面，使用者（授權或未授權）可以透過該介面在 ROM、驅動程式或作業系統層級更改網卡？如果攻擊者要修改 MAC，則可能會在您的資料中引入缺陷。
您的資料是否會使用 MAC 作為金鑰與其他資料來源連線？
除了簡單地導航設備所連接的第 2 層 LAN（有線或無線）之外，您還會將 MAC 用於任何網路目的嗎？
您的裝置連接到的 LAN 是專用網絡，還是大量臨時用戶端（例如員工手機）將連接到的網路？
如果你的答案是
NO, yes, no, no, no, no, no, private
那我想不出你的計劃有什麼真正的缺陷。
請記住，您不需要全域唯一的 MAC 來實現這一目標；您只需要確保呼叫您的 API 的互聯網設備子集是唯一的。就像分配在兩個不同城市的重複網路卡不會發生衝突，因為它們位於不同的 LAN 上，如果 MAC 不呼叫您的 API，您就不會在 MAC 上發生資料庫衝突。
答案2
MAC位址不是唯一的
MAC 可能存在並且將會存在重複項。造成這種情況的原因有很多，其中之一就是他們不必是（全球）獨一無二。
MAC 在本地網路上必須是唯一的，以便 ARP/NDP 可以完成其工作，並且交換器知道將傳入資料封包傳送到哪裡。通常（不一定）滿足先決條件並且一切正常，只是因為在同一 LAN 上擁有兩個相同 MAC 的可能性非常低，即使它們不是唯一的。
另一個原因是設備的數量多於地址的數量。雖然 48 位元地址聽起來似乎在末日之前有足夠的地址供每個人使用，但事實並非如此。
位址空間被分成兩個 24 位元的一半（稍微複雜一些，但讓我們忽略一些瑣碎的細節）。其中一半是 OUI，您可以在 IEEE 註冊並分配給您的公司，費用約為 2000 美元。剩下的24位，你想做什麼就做什麼。當然，您可以註冊多個 OUI，這就是大公司所做的。
以英特爾為例。他們總共註冊了7個OUI，總共擁有1.16億個地址。
我的電腦主機板（使用X99晶片組）以及我的筆記型電腦主機板以及每一個我在過去 10-15 年中擁有的基於 x86 的電腦具有 Intel 網路卡作為晶片組的一部分。當然，全世界有超過 1.16 億台基於 Intel 的電腦。因此，他們的 MAC不可能是獨一無二的（在全球獨一無二的意義上）。
另外，據報道，呃……更便宜……製造商只是從別人的 OUI 中「竊取」地址。換句話說，他們只是使用了一些隨機地址。我聽說有些製造商也使用相同的地址來生產完整的產品系列。這兩者都不是真正符合要求，也沒有太大意義，但是你能做些什麼呢？這些網卡是存在的。再一次：它成為的可能性實際的如果地址用於其預期目的，問題仍然很低，您需要其中兩個在同一區域網路內甚至注意到。
現在，您的問題該怎麼辦？
解決方案可能比您想像的更簡單。您的 IoT 設備很可能需要一些時間概念，通常時間是透過 NTP 自動取得的。 NTP 的典型精度在微秒範圍內（是的，那是微，而不是毫）。我只是跑去ntpq -c rl確認一下，結果被告知 2 -20。
您的兩台裝置在同一微秒內首次開啟的可能性非常低。當然，這通常是有可能發生的（特別是如果您在很短的時間內售出數百萬件，恭喜您成功！）。但這不太可能——實際上不會發生。因此，在永久儲存上首次啟動後可以節省時間。
每個設備上的 IoT 設備的啟動時間都是相同的。但這根本不是真的。
考慮到高解析度計時器，即使在同一裝置上，每次啟動時間也會明顯不同。它可能只有幾個時脈週期的不同（或幾十萬個時脈週期，如果你讀過 CPU 的時間戳計數器之類的東西），所以不是很獨特，但它確實增加了一些熵。
同樣，所花費的時間connect第一次造訪 API 網站時傳回的結果每次都會略有不同，但可明顯不同。同樣，getaddrinfo首次尋找 Web API 的主機名稱時，每個裝置所需的時間略有不同，但可測量。
連接這三個或四個熵來源（MAC 位址、首次開機時間、首次啟動時間、連線時間）並從中計算雜湊值。 MD5 就可以很好地實現這一目的。在那裡，你是獨一無二的。
雖然這並不確實保證唯一性，它「幾乎」保證了它，並且失敗的可能性可以忽略不計。您必須擁有兩個具有相同 MAC 的設備，並且在同一微秒內首次打開，並花費完全相同的時間來啟動和連接到您的網站。那是不會發生的。如果確實發生了，您應該立即開始玩彩票，因為從所有情況來看，您都一定會贏。
但是，如果「不會發生」不足以作為保證，只需在每個裝置第一次存取您的 Web API 時向每個裝置傳遞一個連續遞增的數字（在伺服器上產生）即可。讓設備儲存該號碼，完成。
答案3
由於這裡的問題實際上是一個 XY 問題，因此我將解決這個問題：如何在硬體第一次啟動時獲取其唯一標識符，而無需將標識符預先加載到它們上。所有好的方法實際上都歸結為一件事：擁有熵源。
如果您的硬體有設計為硬體熵來源的東西（注意：這基本上是任何正確的 IoT 設備實現的要求，因為它需要 TLS，所以您的硬體應該設計時要考慮到這一點），只需使用它即可。如果沒有，你必須發揮創意。
幸運的是，幾乎每台電腦都有一個很好的熵源：晶體振盪器（時鐘）。給定晶體的速率不僅取決於細微的溫度變化，甚至受到溫度的影響滯後現象以非線性方式。然而，要測量熵，您需要第二個時鐘來為第一個時鐘計時。這意味著，只要您的電腦至少有兩個可以取樣的時鐘，您就可以使用一個時鐘測量另一個時鐘的速率作為非常高品質的熵源。
答案4
我討厭假設 XY 問題，因為通常 OP 有一個很好但很複雜的理由來按照他們正在做的方式做事，但你可能想研究其他方法來為每個設備生成唯一標識符，例如 MAC 地址，是“內建」到裝置中的，不需要產生您自己的識別碼。
如果設備全部來自同一製造商（或更好的是同一型號），您可以使用序號來產生識別碼。不過，即使您將其與製造商名稱和型號結合起來，這在不同製造商的設備上也不能很好地工作，因為在嵌入式/專有設備的情況下，由於不同的序號格式以及用於取得序號的API 可能不同。裝置序號的替代方案可能是主機板、CPU 或硬碟的序號（我相信 Windows 授權使用這些的組合）。
還值得記住的是，檔案系統格式化程式通常會為每個檔案系統產生唯一的 ID。除非您從同一個映像準備所有設備（出於不相關的原因，我建議您這樣做），否則每個硬碟都將擁有一個儲存在您可以使用的檔案系統中的唯一 ID。
話雖這麼說，但確實沒有理由不是使用 MAC 位址，特別是如果作為設定過程的一部分，您可以確定它們實際上是唯一的（儘管這甚至不是必要的，假設我們在這裡談論的設備不超過幾千台）。當然，請記住，無論您使用什麼，都可能被設備欺騙，因此不要在不受信任的環境中依賴它進行身份驗證（您說這是一個私人設置，所以大概這是一個“受信任”的環境，您不可以在其中進行身份驗證）關心您的客戶針對自己的伺服器欺騙自己的設備，但如果設備的管理移交給第三方或最終用戶，他們顯然應該記住這一點）。