輯導語：前段時間，有很多博主因為IP屬地問題“翻車”，而是否展示IP屬地也引發了廣大網友的討論。為什么各大平臺突然集體展示賬號IP屬地？這項功能有什么意義？本篇文章中，作者給出了答案，我們一起來看看吧。

最近，各大平臺網站陸續公開了賬號IP屬地。對于這項新的政策，網上主流觀點都持支持態度。為什么突然間各大平臺網站很有默契的同時開發且執行了公開賬號IP屬地這項功能，這對產品設計工作會有怎樣的影響，在這里一站式分享與你。

一、關于展示IP地址的相關規定

關于IP屬地展示，最早提出是為了網絡言論的實名化，即通過展示言論屬地IP來對不良網絡言論行為進行威懾，達到清朗網絡環境的目的。

所以國家互聯網信息辦公室在2010年10月提出《互聯網用戶賬號名稱信息管理規定（征求意見稿）》，其中十二條明確規定：

“互聯網用戶賬號服務平臺應當以顯著方式，在互聯網用戶賬號信息頁面展示賬號IP地址屬地信息。境內互聯網用戶賬號IP地址屬地信息需標注到省（區、市），境外賬號IP地址屬地信息需標注到國家（地區）。”

但這里需要注意，這是一個征求意見稿，所以并不是本次執行的法規依據。

通俗地講就是問問大家意見，這樣規定行不行，如果覺得不行那再修改修改。

雖然不是執行文件，但是也表達了國家對IP展示方案的意向。

而此次各大平臺突然開發展示賬戶IP屬地的真正原因是今年4月中央網信辦開展的“清朗·網絡暴力專項治理行動”

總而言之，目前并未有強制的法規要求平臺系統對賬號做地域展示，目前的展示主要也是用于響應國家關于網絡環境的相關號召，或者是一種試運行狀態。

二、我們為什么需要了解

既然沒有要求，那知道這些對我們是否還有意義？

1. 只是一個高曝光的知識點

既然主流的內容平臺都已經上線此功能，那么在各種需求會議上和日常工作交流中就有可能會被不經意地提及。

雖然不是復雜的需求，但也是需求，是需求就需要處理。

而全面了解此功能的背景與現狀是我們從容應對需求的基礎，同時也能表現自己的產品全面性與專業性，因為功能小，所以容易因擴展的回答制造驚喜。

2. 這是一個風險點，而且可能是法律風險點

不知道大家是否有這樣的經歷，在規劃產品或者項目的時候，難免會遇到一道填空題，一道關于風險的填空題。

填的太真實，影響項目立項或者推進，填的太敷衍，容易被diss說沒經驗；假如選擇抄取前輩的“答案”，又擔心前輩變成評審會的參與方。

而現在就有一個現成的答案，既能政治正確又沒啥成本。

3. 這是一個小成本功能點

說到成本，我想為了各項合規而開發的功能中，展示IP是相對成本小的一個功能，甚至大部分系統的會員數據里面本來就擁有IP數據，甚至還有定位數據，而且還不用改變業務流程。

小成本功能是能很好地增加產品的靈活性。

4. 這是未來的趨勢

關于網絡環境治理，只會越來越規范。

關于IP屬地展示規定的試水，目前的主流觀點是持支持態度，所以大概率我們還是會迎來需要強制展示IP歸屬地的那一天，就像現在的域名備案一樣成為常態化硬性要求。

三、產品設計需要注意的事項

1. 當前的主流設計

我整理了、知乎、貼吧、小紅書和快手的功能對比，總結下來主要是在三個位置做IP屬地的展示，分別是【作者主頁】、【文章頁】、【評論區】，詳細情況我已分別對上述各個平臺做了截圖介紹。

同樣是展示功能，各個平臺對于展示這件事的解釋有各自的理解：

• 頭條和知乎沒發現常態化對用戶的解釋型功能
• 貼吧和快手對IP展示的數據做出了解釋，主要針對的是數據不準確的這種情況，解決方案是需要用戶聯系客服進行溝通
• 小紅書做的則特別小心，明確彈窗說明增加IP屬地展示是為了維護網絡安全且數據來源于運營商，是目前我能找到解釋最全面的，從原因和數據準確性兩個維度都對用戶做了常態化的解釋。

2. 數據邏輯

IP屬地展示的數據源是來自于系統對用戶發生行為的時候獲取的IP地址數據進行展示，所以主要分為兩種：

（1）博主IP

博主IP位置數據：根據賬號注冊時的IP屬地進行存儲展示，即在博主注冊但未發表作品的狀態下展示對應的IP位置，后期根據發布作品時的IP位置做對應的統計得出博主IP位置。主要參考的邏輯是在設定的時間段內作品發布時的IP統計和注冊IP屬地加權計算取值。

（2）作品和評論IP

用戶作品和評論的IP來源則是根據發布時的實際IP地址歸屬獲取并展示。

3. 展示位置與樣式設計思路

（1）博主IP

關于博主IP，目前看下來大家主要是以完成功能為主，但是值得參考的是快手的實踐。

快手將用戶自己設置的地址與IP地址結合，在主頁面是展示省份+城市。

但是這個數據其實是博主自己設置的數據，點擊進去則會展示IP地址與博主自己設置的地址。

正常情況下用戶查看時兩個數據是對應的，如果有不誠實的情況，則也暴露的很明顯。而且其他的平臺主要還是在博主信息區對地址做展示。

（2）作品IP

目前看到的所有的作品詳情頁關于IP地址的展示都是不明顯的，但是這很合理，因為用戶進來看的是內容又不是定位信息。

對于文章類的就兩個思路，一種是在文章頭部展示，另一種是在文章尾部做展示，基本做到頁面和諧即可。

（3）評論IP

關于評論IP屬地的展示，各個平臺的展示思路高度一致，在原來頁面展示評論時間的后面直接追加對應的IP屬地，省力又和諧。

4. 其他

IP屬地的展示深度只能到省份級別，直轄市則展示城市名。

用戶解釋文案：

• “IP屬地以運營商信息為準，如果有問題可咨詢客服”；
• “為維護網絡安全、保障良好生態和社區的真實性，根據網絡運營商數據，展示用戶IP屬地信息”。

四、寫在最后

截止至我發文的時間，IP屬地展示功能了解即可，如果未來剛好遇到的真的要上這個功能，那希望也能為你提供一點點幫助。

參考資料：

1、中央網信辦：http://www.cac.gov.cn/2022-04/24/c_1652422681278782.html

2、國家互聯網信息辦公室官網：http://www.cac.gov.cn/2021-10/26/c_1636843202454310.html

本文由 @瑞見釘錘 原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協議

薦閱讀：

搞懂Java 14中這個新功能，代碼調試快到飛起

一文秒懂Springboot發送郵件操作

TCP/IP概念

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協議/網際協議）是指能夠在多個不同網絡間實現信息傳輸的協議簇。TCP/IP協議不僅僅指的是TCP 和IP兩個協議，而是指一個由FTP、SMTP、TCP、UDP、IP等協議構成的協議簇，同時是Internet最基本的協議、Internet國際互聯網絡的基礎，由網絡層的IP協議和傳輸層的TCP協議組成。TCP/IP 定義了電子設備如何連入因特網，以及數據如何在它們之間傳輸的標準。

我的理解： 互聯網中的設備要相互通信，必須基于相同的方式，比如由哪一方發起通訊，使用什么語言進行通訊，怎么結束通訊這些都要事先確定，不同設備之間的通訊都需要一種規則，我們將這種規則成為協議。

TCP/IP 的分層管理圖

TCP/IP協議中最重要的特點就是分層。由上往下分別為 應用層，傳輸層，網絡層，數據鏈路層，物理層。當然也有按不同的模型分為4層或者7層的。

為什么要分層呢？在設計的角度來講變得靈活了，當某一層需要修改時，只需要拿掉對相應的層，實現可拔插，無需變動所有層。對于使用者來講，屏蔽了底層復雜的傳輸過程。

應用層

TCP/IP模型將OSI參考模型中的會話層和表示層的功能合并到應用層實現。這一層主要的代表有DNS域名解析/http協議

傳輸層

在TCP/IP模型中，傳輸層的功能是使源端主機和目標端主機上的對等實體可以進行會話。在傳輸層定義了兩種服務質量不同的協議。即：傳輸控制協議TCP和用戶數據報協議UDP.

網絡層

網絡層是整個TCP/IP協議棧的核心。它的功能是把分組發往目標網絡或主機。同時，為了盡快地發送分組，可能需要沿不同的路徑同時進行分組傳遞。因此，分組到達的順序和發送的順序可能不同，這就需要上層必須對分組進行排序。網絡層定義了分組格式和協議，即IP協議（Internet Protocol ）。

物理層

該層負責 比特流在節點之間的傳輸，即負責物理傳輸，這一層的協議既與鏈路有關，也與傳輸的介質有關。通俗來說就是把計算機連接起來的物理手段。

數據鏈路層

控制網絡層與物理層之間的通信，主要功能是保證物理線路上進行可靠的數據傳遞。為了保證傳輸，從網絡層接收到的數據被分割成特定的可被物理層傳輸的幀。幀是用來移動數據結構的結構包，他不僅包含原始數據，還包含發送方和接收方的物理地址以及糾錯和控制信息。其中的地址確定了幀將發送到何處，而糾錯和控制信息則確保幀無差錯到達。如果在傳達數據時，接收點檢測到所傳數據中有差錯，就要通知發送方重發這一幀。

UDP 和 TCP 的特點:

• 用戶數據報協議 UDP（User Datagram Protocol）:無連接；盡最大努力的交付；面向報文；無擁塞控制；支持一對一、一對多、多對一、多對多的交互通信；首部開銷小(只有四個字段：源端口、目的端口、長度、檢驗和)。UDP是面向報文的傳輸方式是應用層交給UDP多長的報文，UDP發送多長的報文，即一次發送一個報文。因此，應用程序必須選擇合適大小的報文。
• 傳輸控制協議 TCP（Transmission Control Protocol）:面向連接；每一個TCP連接只能是點對點的(一對一)；提供可靠交付服務；提供全雙工通信；面向字節流。應用程序和TCP的交互是一次一個數據塊(大小不等)，但TCP把應用程序看成是一連串的無結構的字節流。TCP有一個緩沖，當應該程序傳送的數據塊太長，TCP就可以把它劃分短一些再傳送。

UDP的首部格式:

用戶數據報有兩個字段：數據字段和首部字段，數據字段很簡單，只有8個字節，由四個字段組成，每個字段的長度都是兩個字節。各字段意義如下：

1. 源端口： 源端口號，在需要給對方回信時使用。不需要是可全用0.
2. 目的端口號： 這在終點交付報文時必須使用。
3. 長度： 用戶數據報UDP的長度，最小為8（僅首部）。
4. 校驗和： 用于校驗用戶數據報在傳輸過程是否出錯，出錯則丟棄該報文。

TCP報文首部格式:

源端口和目的端口: 各占兩個字節，分別寫入源端口號和目的端口號。
序號 ： 占4個字節；用于對字節流進行編號，例如序號為 301，表示第一個字節的編號為 301，如果攜帶的數據長度為 100 字節，那么下一個報文段的序號應為 401。
確認號 ： 占4個字節；期望收到的下一個報文段的序號。例如 B 正確收到 A 發送來的一個報文段，序號為 501，攜帶的數據長度為 200 字節，因此 B 期望下一個報文段的序號為 701，B 發送給 A 的確認報文段中確認號就為 701。
數據偏移 ： 占4位；指的是數據部分距離報文段起始處的偏移量，實際上指的是首部的長度。
確認 ACK ： 當 ACK=1 時確認號字段有效，否則無效。TCP 規定，在連接建立后所有傳送的報文段都必須把 ACK 置 1。
同步 SYN ：在連接建立時用來同步序號。當 SYN=1，ACK=0 時表示這是一個連接請求報文段。若對方同意建立連接，則響應報文中 SYN=1，ACK=1。
終止 FIN ： 用來釋放一個連接，當 FIN=1 時，表示此報文段的發送方的數據已發送完畢，并要求釋放連接。
窗口 ： 占2字節；窗口值作為接收方讓發送方設置其發送窗口的依據。之所以要有這個限制，是因為接收方的數據緩存空間是有限的。
檢驗和： 占2個字節；檢驗和字段檢驗的范圍包括首部和數據這兩個部分。在計算檢驗和時，在TCP報文段的前面加上12字節的偽首部。
套接字： TCP連接的端點叫做套接字或插口。端口號拼接到IP地址即構成了套接字。

面試靈魂拷問

TCP的三次握手與四次揮手：

1. 第一次握手：Client將標志位SYN置為1，隨機產生一個值seq=J，并將該數據包發送給Server，Client進入SYN_SENT狀態，等待Server確認。
2. 第二次握手：Server收到數據包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack=J+1，隨機產生一個值seq=K，并將該數據包發送給Client以確認連接請求，Server進入SYN_RCVD狀態。
3. 第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數據包發送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨后Client與Server之間可以開始傳輸數據了。

為什么要進行三次握手呢? 第三次握手是為了防止失效的連接請求到達服器，讓服務器錯誤打開連接。客戶端發送的連接請求如果在網絡中滯留，那么就會隔很長一段時間才能收到服務器端發回的連接確認。客戶端等待一個超時重傳時間之后，就會重新請求連接。但是這個滯留的連接請求最后還是會到達服務器，如果不進行三次握手，那么服務器就會打開兩個連接。如果有第三次握手，客戶端會忽略服務器之后發送的對滯留連接請求的連接確認，不進行第三次握手，因此就不會再次打開連接。

如果此時變成兩次揮手行不行？舉個打電話的例子，比如：第一次握手：A給B打電話說，你可以聽到我說話嗎？第二次握手：B收到了A的信息，然后對A說：我可以聽得到你說話啊，你能聽得到我說話嗎？第三次握手：A收到了B的信息，然后說可以的，我要給你發信息啦！結論：在三次握手之后，A和B都能確定這么一件事：我能聽到你，你也能聽到我。這樣，就可以開始正常通信了。如果是兩次，那將無法確定。

當數據傳送完畢,斷開連接就需要進行TCP的四次揮手：

1. 第一次揮手，客戶端設置seq和 ACK ,向服務器發送一個 FIN(終結)報文段。此時，客戶端進入 FIN_WAIT_1狀態，表示客戶端沒有數據要發送給服務端了。
2. 第二次揮手，服務端收到了客戶端發送的 FIN 報文段，向客戶端回了一個 ACK 報文段。
3. 第三次揮手，服務端向客戶端發送FIN 報文段，請求關閉連接，同時服務端進入 LAST_ACK 狀態。
4. 第四次揮手，客戶端收到服務端發送的 FIN 報文段后，向服務端發送 ACK 報文段,然后客戶端進入 TIME_WAIT狀態。服務端收到客戶端的 ACK 報文段以后，就關閉連接。此時，客戶端等待2MSL（指一個片段在網絡中最大的存活時間）后依然沒有收到回復，則說明服務端已經正常關閉，這樣客戶端就可以關閉連接了。四次揮手

最后完整的過程圖

為什么要四次揮手？

客戶端發送了 FIN 連接釋放報文之后，服務器收到了這個報文，就進入了 CLOSE-WAIT 狀態。這個狀態是為了讓服務器端發送還未傳送完畢的數據，傳送完畢之后，服務器會發送 FIN 連接釋放報文。

HTTP持久連接

如果有大量的連接，每次在連接，關閉都要經歷三次握手，四次揮手，這顯然會造成性能低下。因此。Http 有一種叫做 長連接（keepalive connections） 的機制。它可以在傳輸數據后仍保持連接，當客戶端需要再次獲取數據時，直接使用剛剛空閑下來的連接而無需再次握手。

HTTP和HTTPS

什么是HTTP?

超文本傳輸協議，是一個基于請求與響應，無狀態的，應用層的協議，常基于TCP/IP協議傳輸數據，互聯網上應用最為廣泛的一種網絡協議,所有的WWW文件都必須遵守這個標準。設計HTTP的初衷是為了提供一種發布和接收HTML頁面的方法。

HTTP特點：

1. 無狀態：協議對客戶端沒有狀態存儲，對事物處理沒有“記憶”能力，比如訪問一個網站需要反復進行登錄操作。
2. 無連接：HTTP/1.1之前，由于無狀態特點，每次請求需要通過TCP三次握手四次揮手，和服務器重新建立連接。比如某個客戶機在短時間多次請求同一個資源，服務器并不能區別是否已經響應過用戶的請求，所以每次需要重新響應請求，需要耗費不必要的時間和流量。
3. 基于請求和響應：基本的特性，由客戶端發起請求，服務端響應。
4. 簡單快速、靈活。
5. 通信使用明文、請求和響應不會對通信方進行確認、無法保護數據的完整性。

HTTP報文組成:

1. 請求行：包括請求方法、URL、協議/版本
2. 請求頭(Request Header)
3. 請求正文
4. 狀態行
5. 響應頭
6. 響應正文

HTTP的缺點：

1. 通信使用明文（不加密），內容可能會被竊聽。
2. 不驗證通信方的身份，因此有可能遭遇偽裝。
3. 無法證明報文的完整性，所以有可能已遭篡改。

什么是HTTPS?

HTTPS：是以安全為目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容就需要SSL。HTTPS協議的主要作用可以分為兩種：一種是建立一個信息安全通道，來保證數據傳輸的安全；另一種就是確認網站的真實性。

HTTPS 并非是應用層的一種新協議。只是 HTTP 通信接口部分用SSL（Secure Socket Layer）和 TLS（Transport Layer Security）協議代替而已。通常，HTTP 直接和 TCP 通信。當使用 SSL時，則演變成先和 SSL通信，再由 SSL和 TCP 通信了。簡言之，所謂 HTTPS，其實就是身披SSL協議這層外殼的 HTTP。

HTTPS通訊方式：

1. 客戶使用https的URL訪問Web服務器，要求與Web服務器建立SSL連接。
2. Web服務器收到客戶端請求后，會將網站的證書信息（證書中包含公鑰）傳送一份給客戶端。
3. 客戶端的瀏覽器與Web服務器開始協商SSL連接的安全等級，也就是信息加密的等級。
4. 客戶端的瀏覽器根據雙方同意的安全等級，建立會話密鑰，然后利用網站的公鑰將會話密鑰加密，并傳送給網站。
5. Web服務器利用自己的私鑰解密出會話密鑰。
6. Web服務器利用會話密鑰加密與客戶端之間的通信。

為什么HTTPS安全

1. SSL不僅提供加密處理，加密方式為混合加密。
2. SSL而且還使用了一種被稱為證書的手段，可用于確定方。證書由值得信任的第三方機構頒發，用以證明服務器和客戶端是實際存在的。另外，偽造證書從技術角度來說是異常困難的一件事。所以只要能夠確認通信方（服務器或客戶端）持有的證書。

加密方法

對稱加密：加密和解密同用一個密鑰的方式稱為共享密鑰加密（Common keycrypto system），也被叫做對稱密鑰加密.

對成加密的方式效率比較低，加密速度慢。另外對稱加密存在安全隱患的問題，堆成加密的密鑰必須要傳到對方對方才能解密，要是對方在密鑰傳輸的過程獲取到密鑰，那不是密鑰失去了加密的意義，所以完全使用對稱加密也是不安全的。

非對稱加密：公開密鑰加密使用一對非對稱的密鑰。一把叫做私有密鑰（private key），另一把叫做公開密鑰（public key）。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發布，任何人都可以獲得。公鑰加密，私鑰解密使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方收到被加密的信息后，再使用自己的私有密鑰進行解密。

那么非對稱個加密就一定安全嗎？非對稱加密也不安全，為什么呢？因為存在中間偽造公鑰和私鑰，假如在公鑰傳給對方的時候，有人獲取到公鑰，雖然她不能用你的公鑰做什么，但是它截獲公鑰后，把自己偽造的公鑰發送給對方，這樣對方獲取的就不是真正的公鑰，當對方用公鑰進行加密文件，再將文件發送給對方，這樣即使截獲人沒有獲取到真正的私鑰，但是加密時的公鑰是截獲人的，他獲取到加密文件，只需要用自己的私鑰進行解密就成功獲取到文件了。

混合加密機制（對稱加密與非對稱加密結合的方式）顧名思義也就是對稱加密和非對稱加密的方式相結合。

如何證明公開沒要本身的真實性。因為在公開秘鑰傳輸的過程中，可能真正的公開秘鑰已經被攻擊者替換掉了。

為了解決上述問題，于是除了CA認證證書。服務器將CA證書發送給客戶端，以進行公開密鑰加密方式通信。接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證通過，客戶端便可明確兩件事：

• 一：認證服務器的公開密鑰的是真實有效的數字證書認證機構；
• 二：服務器的公開密鑰是值得信賴的。

那么公開密鑰如何交接給客戶端是一件非常重要的事，因此多數瀏覽器開發商發布版本時，會事先在內部植入常用認證機關的公開密鑰，這樣就確保公鑰是使用認證機構的公鑰避免了公鑰偽造的過程，進而確保了安全。

推薦閱讀：

一文秒懂Springboot發送郵件操作

如何用“十分鐘”搞定阿里面試官，完美拿下P6 offer

實戰文檔：徹底搞懂JVM+Linux+MySQL+Netty+Tomcat+并發編程

作者：非科班的科班

來源：微信公眾號

RL也被稱為網址。

URL 可以由單詞組成,比如 "w3school.com.cn"，或者是因特網協議(IP)地址：192.168.1.253。

大多數人在網上沖浪時,會鍵入網址的域名,因為名稱比數字容易記憶。

URL(Uniform Resource Locator)

當您點擊 HTML 頁面中的某個鏈接時,對應的<a>標簽指向萬維網上的一個地址。

統一資源定位器(URL)用于定位萬維網上的文檔(或其他數據)。

網址,比如 http://www.w3school.com.cn/html/index.asp,遵守以下的語法規則：

scheme://host.domain:port/path/filename

解釋：

scheme 定義因特網服務的類型。最常見的類型是 http

host 定義域主機(http 的默認主機是 www)

domain 定義因特網域名，比如 w3school.com.cn

:port 定義主機上的端口號(http 的默認端口號是 80)

path 定義服務器上的路徑(如果省略，則文檔必須位于網站的根目錄中)。

filename 定義文檔/資源的名稱

編者注：URL 的英文全稱是 Uniform Resource Locator，中文也譯為"統一資源定位符"。

URL Schemes

以下是其中一些最流行的 scheme：

Scheme 訪問 用于...

http 超文本傳輸協議 以 http:// 開頭的普通網頁。不加密。

https 安全超文本傳輸協議 安全網頁。加密所有信息交換。

ftp 文件傳輸協議 用于將文件下載或上傳至網站。

file 您計算機上的文件。

URL編碼

URL只能使用ASCII字符集來通過因特網進行發送。

由于URL常常會包含ASCII集合之外的字符,URL 必須轉換為有效的ASCII格式。

URL編碼使用"%"其后跟隨兩位的十六進制數來替換非ASCII字符。

URL不能包含空格。URL編碼通常使用+來替換空格。

URL編碼表參考

http://www.w3school.com.cn/tags/html_ref_urlencode.html