關(guān)于IP屬地公開(kāi)展示，你想了解的這里都有

輯導(dǎo)語(yǔ)：前段時(shí)間，有很多博主因?yàn)镮P屬地問(wèn)題“翻車(chē)”，而是否展示IP屬地也引發(fā)了廣大網(wǎng)友的討論。為什么各大平臺(tái)突然集體展示賬號(hào)IP屬地？這項(xiàng)功能有什么意義？本篇文章中，作者給出了答案，我們一起來(lái)看看吧。

最近，各大平臺(tái)網(wǎng)站陸續(xù)公開(kāi)了賬號(hào)IP屬地。對(duì)于這項(xiàng)新的政策，網(wǎng)上主流觀點(diǎn)都持支持態(tài)度。為什么突然間各大平臺(tái)網(wǎng)站很有默契的同時(shí)開(kāi)發(fā)且執(zhí)行了公開(kāi)賬號(hào)IP屬地這項(xiàng)功能，這對(duì)產(chǎn)品設(shè)計(jì)工作會(huì)有怎樣的影響，在這里一站式分享與你。

一、關(guān)于展示IP地址的相關(guān)規(guī)定

關(guān)于IP屬地展示，最早提出是為了網(wǎng)絡(luò)言論的實(shí)名化，即通過(guò)展示言論屬地IP來(lái)對(duì)不良網(wǎng)絡(luò)言論行為進(jìn)行威懾，達(dá)到清朗網(wǎng)絡(luò)環(huán)境的目的。

所以國(guó)家互聯(lián)網(wǎng)信息辦公室在2010年10月提出《互聯(lián)網(wǎng)用戶(hù)賬號(hào)名稱(chēng)信息管理規(guī)定（征求意見(jiàn)稿）》，其中十二條明確規(guī)定：

“互聯(lián)網(wǎng)用戶(hù)賬號(hào)服務(wù)平臺(tái)應(yīng)當(dāng)以顯著方式，在互聯(lián)網(wǎng)用戶(hù)賬號(hào)信息頁(yè)面展示賬號(hào)IP地址屬地信息。境內(nèi)互聯(lián)網(wǎng)用戶(hù)賬號(hào)IP地址屬地信息需標(biāo)注到?。▍^(qū)、市），境外賬號(hào)IP地址屬地信息需標(biāo)注到國(guó)家（地區(qū)）?！?/p>

但這里需要注意，這是一個(gè)征求意見(jiàn)稿，所以并不是本次執(zhí)行的法規(guī)依據(jù)。

通俗地講就是問(wèn)問(wèn)大家意見(jiàn)，這樣規(guī)定行不行，如果覺(jué)得不行那再修改修改。

雖然不是執(zhí)行文件，但是也表達(dá)了國(guó)家對(duì)IP展示方案的意向。

而此次各大平臺(tái)突然開(kāi)發(fā)展示賬戶(hù)IP屬地的真正原因是今年4月中央網(wǎng)信辦開(kāi)展的“清朗·網(wǎng)絡(luò)暴力專(zhuān)項(xiàng)治理行動(dòng)”

總而言之，目前并未有強(qiáng)制的法規(guī)要求平臺(tái)系統(tǒng)對(duì)賬號(hào)做地域展示，目前的展示主要也是用于響應(yīng)國(guó)家關(guān)于網(wǎng)絡(luò)環(huán)境的相關(guān)號(hào)召，或者是一種試運(yùn)行狀態(tài)。

二、我們?yōu)槭裁葱枰私?/h1>
既然沒(méi)有要求，那知道這些對(duì)我們是否還有意義？

1. 只是一個(gè)高曝光的知識(shí)點(diǎn)

既然主流的內(nèi)容平臺(tái)都已經(jīng)上線(xiàn)此功能，那么在各種需求會(huì)議上和日常工作交流中就有可能會(huì)被不經(jīng)意地提及。

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

而全面了解此功能的背景與現(xiàn)狀是我們從容應(yīng)對(duì)需求的基礎(chǔ)，同時(shí)也能表現(xiàn)自己的產(chǎn)品全面性與專(zhuān)業(yè)性，因?yàn)楣δ苄?，所以容易因擴(kuò)展的回答制造驚喜。

2. 這是一個(gè)風(fēng)險(xiǎn)點(diǎn)，而且可能是法律風(fēng)險(xiǎn)點(diǎn)

不知道大家是否有這樣的經(jīng)歷，在規(guī)劃產(chǎn)品或者項(xiàng)目的時(shí)候，難免會(huì)遇到一道填空題，一道關(guān)于風(fēng)險(xiǎn)的填空題。

填的太真實(shí)，影響項(xiàng)目立項(xiàng)或者推進(jìn)，填的太敷衍，容易被diss說(shuō)沒(méi)經(jīng)驗(yàn)；假如選擇抄取前輩的“答案”，又擔(dān)心前輩變成評(píng)審會(huì)的參與方。

而現(xiàn)在就有一個(gè)現(xiàn)成的答案，既能政治正確又沒(méi)啥成本。

3. 這是一個(gè)小成本功能點(diǎn)

說(shuō)到成本，我想為了各項(xiàng)合規(guī)而開(kāi)發(fā)的功能中，展示IP是相對(duì)成本小的一個(gè)功能，甚至大部分系統(tǒng)的會(huì)員數(shù)據(jù)里面本來(lái)就擁有IP數(shù)據(jù)，甚至還有定位數(shù)據(jù)，而且還不用改變業(yè)務(wù)流程。

小成本功能是能很好地增加產(chǎn)品的靈活性。

4. 這是未來(lái)的趨勢(shì)

關(guān)于網(wǎng)絡(luò)環(huán)境治理，只會(huì)越來(lái)越規(guī)范。

關(guān)于IP屬地展示規(guī)定的試水，目前的主流觀點(diǎn)是持支持態(tài)度，所以大概率我們還是會(huì)迎來(lái)需要強(qiáng)制展示IP歸屬地的那一天，就像現(xiàn)在的域名備案一樣成為常態(tài)化硬性要求。

三、產(chǎn)品設(shè)計(jì)需要注意的事項(xiàng)

1. 當(dāng)前的主流設(shè)計(jì)

我整理了、知乎、貼吧、小紅書(shū)和快手的功能對(duì)比，總結(jié)下來(lái)主要是在三個(gè)位置做IP屬地的展示，分別是【作者主頁(yè)】、【文章頁(yè)】、【評(píng)論區(qū)】，詳細(xì)情況我已分別對(duì)上述各個(gè)平臺(tái)做了截圖介紹。

同樣是展示功能，各個(gè)平臺(tái)對(duì)于展示這件事的解釋有各自的理解：

頭條和知乎沒(méi)發(fā)現(xiàn)常態(tài)化對(duì)用戶(hù)的解釋型功能
貼吧和快手對(duì)IP展示的數(shù)據(jù)做出了解釋?zhuān)饕槍?duì)的是數(shù)據(jù)不準(zhǔn)確的這種情況，解決方案是需要用戶(hù)聯(lián)系客服進(jìn)行溝通
小紅書(shū)做的則特別小心，明確彈窗說(shuō)明增加IP屬地展示是為了維護(hù)網(wǎng)絡(luò)安全且數(shù)據(jù)來(lái)源于運(yùn)營(yíng)商，是目前我能找到解釋最全面的，從原因和數(shù)據(jù)準(zhǔn)確性?xún)蓚€(gè)維度都對(duì)用戶(hù)做了常態(tài)化的解釋。

2. 數(shù)據(jù)邏輯

IP屬地展示的數(shù)據(jù)源是來(lái)自于系統(tǒng)對(duì)用戶(hù)發(fā)生行為的時(shí)候獲取的IP地址數(shù)據(jù)進(jìn)行展示，所以主要分為兩種：

（1）博主IP

博主IP位置數(shù)據(jù)：根據(jù)賬號(hào)注冊(cè)時(shí)的IP屬地進(jìn)行存儲(chǔ)展示，即在博主注冊(cè)但未發(fā)表作品的狀態(tài)下展示對(duì)應(yīng)的IP位置，后期根據(jù)發(fā)布作品時(shí)的IP位置做對(duì)應(yīng)的統(tǒng)計(jì)得出博主IP位置。主要參考的邏輯是在設(shè)定的時(shí)間段內(nèi)作品發(fā)布時(shí)的IP統(tǒng)計(jì)和注冊(cè)IP屬地加權(quán)計(jì)算取值。

（2）作品和評(píng)論IP

用戶(hù)作品和評(píng)論的IP來(lái)源則是根據(jù)發(fā)布時(shí)的實(shí)際IP地址歸屬獲取并展示。

3. 展示位置與樣式設(shè)計(jì)思路

（1）博主IP

關(guān)于博主IP，目前看下來(lái)大家主要是以完成功能為主，但是值得參考的是快手的實(shí)踐。

快手將用戶(hù)自己設(shè)置的地址與IP地址結(jié)合，在主頁(yè)面是展示省份+城市。

但是這個(gè)數(shù)據(jù)其實(shí)是博主自己設(shè)置的數(shù)據(jù)，點(diǎn)擊進(jìn)去則會(huì)展示IP地址與博主自己設(shè)置的地址。

正常情況下用戶(hù)查看時(shí)兩個(gè)數(shù)據(jù)是對(duì)應(yīng)的，如果有不誠(chéng)實(shí)的情況，則也暴露的很明顯。而且其他的平臺(tái)主要還是在博主信息區(qū)對(duì)地址做展示。

（2）作品IP

目前看到的所有的作品詳情頁(yè)關(guān)于IP地址的展示都是不明顯的，但是這很合理，因?yàn)橛脩?hù)進(jìn)來(lái)看的是內(nèi)容又不是定位信息。

對(duì)于文章類(lèi)的就兩個(gè)思路，一種是在文章頭部展示，另一種是在文章尾部做展示，基本做到頁(yè)面和諧即可。

（3）評(píng)論IP

關(guān)于評(píng)論IP屬地的展示，各個(gè)平臺(tái)的展示思路高度一致，在原來(lái)頁(yè)面展示評(píng)論時(shí)間的后面直接追加對(duì)應(yīng)的IP屬地，省力又和諧。

4. 其他

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

用戶(hù)解釋文案：

“IP屬地以運(yùn)營(yíng)商信息為準(zhǔn)，如果有問(wèn)題可咨詢(xún)客服”；
“為維護(hù)網(wǎng)絡(luò)安全、保障良好生態(tài)和社區(qū)的真實(shí)性，根據(jù)網(wǎng)絡(luò)運(yùn)營(yíng)商數(shù)據(jù)，展示用戶(hù)IP屬地信息”。

四、寫(xiě)在最后

截止至我發(fā)文的時(shí)間，IP屬地展示功能了解即可，如果未來(lái)剛好遇到的真的要上這個(gè)功能，那希望也能為你提供一點(diǎn)點(diǎn)幫助。

參考資料：

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

2、國(guó)家互聯(lián)網(wǎng)信息辦公室官網(wǎng)：http://www.cac.gov.cn/2021-10/26/c_1636843202454310.html

本文由 @瑞見(jiàn)釘錘原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來(lái)自 Unsplash，基于CC0協(xié)議

薦閱讀：

搞懂Java 14中這個(gè)新功能，代碼調(diào)試快到飛起

一文秒懂Springboot發(fā)送郵件操作

TCP/IP概念

TCP/IP（Transmission Control Protocol/Internet Protocol，傳輸控制協(xié)議/網(wǎng)際協(xié)議）是指能夠在多個(gè)不同網(wǎng)絡(luò)間實(shí)現(xiàn)信息傳輸?shù)膮f(xié)議簇。TCP/IP協(xié)議不僅僅指的是TCP 和IP兩個(gè)協(xié)議，而是指一個(gè)由FTP、SMTP、TCP、UDP、IP等協(xié)議構(gòu)成的協(xié)議簇，同時(shí)是Internet最基本的協(xié)議、Internet國(guó)際互聯(lián)網(wǎng)絡(luò)的基礎(chǔ)，由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成。TCP/IP 定義了電子設(shè)備如何連入因特網(wǎng)，以及數(shù)據(jù)如何在它們之間傳輸?shù)臉?biāo)準(zhǔn)。
我的理解： 互聯(lián)網(wǎng)中的設(shè)備要相互通信，必須基于相同的方式，比如由哪一方發(fā)起通訊，使用什么語(yǔ)言進(jìn)行通訊，怎么結(jié)束通訊這些都要事先確定，不同設(shè)備之間的通訊都需要一種規(guī)則，我們將這種規(guī)則成為協(xié)議。

TCP/IP 的分層管理圖

TCP/IP協(xié)議中最重要的特點(diǎn)就是分層。由上往下分別為應(yīng)用層，傳輸層，網(wǎng)絡(luò)層，數(shù)據(jù)鏈路層，物理層。當(dāng)然也有按不同的模型分為4層或者7層的。

為什么要分層呢？在設(shè)計(jì)的角度來(lái)講變得靈活了，當(dāng)某一層需要修改時(shí)，只需要拿掉對(duì)相應(yīng)的層，實(shí)現(xiàn)可拔插，無(wú)需變動(dòng)所有層。對(duì)于使用者來(lái)講，屏蔽了底層復(fù)雜的傳輸過(guò)程。

應(yīng)用層

TCP/IP模型將OSI參考模型中的會(huì)話(huà)層和表示層的功能合并到應(yīng)用層實(shí)現(xiàn)。這一層主要的代表有DNS域名解析/http協(xié)議

傳輸層

在TCP/IP模型中，傳輸層的功能是使源端主機(jī)和目標(biāo)端主機(jī)上的對(duì)等實(shí)體可以進(jìn)行會(huì)話(huà)。在傳輸層定義了兩種服務(wù)質(zhì)量不同的協(xié)議。即：傳輸控制協(xié)議TCP和用戶(hù)數(shù)據(jù)報(bào)協(xié)議UDP.

網(wǎng)絡(luò)層

網(wǎng)絡(luò)層是整個(gè)TCP/IP協(xié)議棧的核心。它的功能是把分組發(fā)往目標(biāo)網(wǎng)絡(luò)或主機(jī)。同時(shí)，為了盡快地發(fā)送分組，可能需要沿不同的路徑同時(shí)進(jìn)行分組傳遞。因此，分組到達(dá)的順序和發(fā)送的順序可能不同，這就需要上層必須對(duì)分組進(jìn)行排序。網(wǎng)絡(luò)層定義了分組格式和協(xié)議，即IP協(xié)議（Internet Protocol ）。

物理層

該層負(fù)責(zé) 比特流在節(jié)點(diǎn)之間的傳輸，即負(fù)責(zé)物理傳輸，這一層的協(xié)議既與鏈路有關(guān)，也與傳輸?shù)慕橘|(zhì)有關(guān)。通俗來(lái)說(shuō)就是把計(jì)算機(jī)連接起來(lái)的物理手段。

數(shù)據(jù)鏈路層

控制網(wǎng)絡(luò)層與物理層之間的通信，主要功能是保證物理線(xiàn)路上進(jìn)行可靠的數(shù)據(jù)傳遞。為了保證傳輸，從網(wǎng)絡(luò)層接收到的數(shù)據(jù)被分割成特定的可被物理層傳輸?shù)膸?。幀是用?lái)移動(dòng)數(shù)據(jù)結(jié)構(gòu)的結(jié)構(gòu)包，他不僅包含原始數(shù)據(jù)，還包含發(fā)送方和接收方的物理地址以及糾錯(cuò)和控制信息。其中的地址確定了幀將發(fā)送到何處，而糾錯(cuò)和控制信息則確保幀無(wú)差錯(cuò)到達(dá)。如果在傳達(dá)數(shù)據(jù)時(shí)，接收點(diǎn)檢測(cè)到所傳數(shù)據(jù)中有差錯(cuò)，就要通知發(fā)送方重發(fā)這一幀。

UDP 和 TCP 的特點(diǎn):

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

UDP的首部格式:

用戶(hù)數(shù)據(jù)報(bào)有兩個(gè)字段：數(shù)據(jù)字段和首部字段，數(shù)據(jù)字段很簡(jiǎn)單，只有8個(gè)字節(jié)，由四個(gè)字段組成，每個(gè)字段的長(zhǎng)度都是兩個(gè)字節(jié)。各字段意義如下：

源端口： 源端口號(hào)，在需要給對(duì)方回信時(shí)使用。不需要是可全用0.
目的端口號(hào)： 這在終點(diǎn)交付報(bào)文時(shí)必須使用。
長(zhǎng)度： 用戶(hù)數(shù)據(jù)報(bào)UDP的長(zhǎng)度，最小為8（僅首部）。
校驗(yàn)和： 用于校驗(yàn)用戶(hù)數(shù)據(jù)報(bào)在傳輸過(guò)程是否出錯(cuò)，出錯(cuò)則丟棄該報(bào)文。

TCP報(bào)文首部格式:

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

面試靈魂拷問(wèn)

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

第一次握手：Client將標(biāo)志位SYN置為1，隨機(jī)產(chǎn)生一個(gè)值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進(jìn)入SYN_SENT狀態(tài)，等待Server確認(rèn)。
第二次握手：Server收到數(shù)據(jù)包后由標(biāo)志位SYN=1知道Client請(qǐng)求建立連接，Server將標(biāo)志位SYN和ACK都置為1，ack=J+1，隨機(jī)產(chǎn)生一個(gè)值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認(rèn)連接請(qǐng)求，Server進(jìn)入SYN_RCVD狀態(tài)。
第三次握手：Client收到確認(rèn)后，檢查ack是否為J+1，ACK是否為1，如果正確則將標(biāo)志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進(jìn)入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開(kāi)始傳輸數(shù)據(jù)了。

為什么要進(jìn)行三次握手呢? 第三次握手是為了防止失效的連接請(qǐng)求到達(dá)服器，讓服務(wù)器錯(cuò)誤打開(kāi)連接。客戶(hù)端發(fā)送的連接請(qǐng)求如果在網(wǎng)絡(luò)中滯留，那么就會(huì)隔很長(zhǎng)一段時(shí)間才能收到服務(wù)器端發(fā)回的連接確認(rèn)?？蛻?hù)端等待一個(gè)超時(shí)重傳時(shí)間之后，就會(huì)重新請(qǐng)求連接。但是這個(gè)滯留的連接請(qǐng)求最后還是會(huì)到達(dá)服務(wù)器，如果不進(jìn)行三次握手，那么服務(wù)器就會(huì)打開(kāi)兩個(gè)連接。如果有第三次握手，客戶(hù)端會(huì)忽略服務(wù)器之后發(fā)送的對(duì)滯留連接請(qǐng)求的連接確認(rèn)，不進(jìn)行第三次握手，因此就不會(huì)再次打開(kāi)連接。
如果此時(shí)變成兩次揮手行不行？舉個(gè)打電話(huà)的例子，比如：第一次握手：A給B打電話(huà)說(shuō)，你可以聽(tīng)到我說(shuō)話(huà)嗎？第二次握手：B收到了A的信息，然后對(duì)A說(shuō)：我可以聽(tīng)得到你說(shuō)話(huà)啊，你能聽(tīng)得到我說(shuō)話(huà)嗎？第三次握手：A收到了B的信息，然后說(shuō)可以的，我要給你發(fā)信息啦！結(jié)論：在三次握手之后，A和B都能確定這么一件事：我能聽(tīng)到你，你也能聽(tīng)到我。這樣，就可以開(kāi)始正常通信了。如果是兩次，那將無(wú)法確定。

當(dāng)數(shù)據(jù)傳送完畢,斷開(kāi)連接就需要進(jìn)行TCP的四次揮手：

第一次揮手，客戶(hù)端設(shè)置seq和 ACK ,向服務(wù)器發(fā)送一個(gè) FIN(終結(jié))報(bào)文段。此時(shí)，客戶(hù)端進(jìn)入 FIN_WAIT_1狀態(tài)，表示客戶(hù)端沒(méi)有數(shù)據(jù)要發(fā)送給服務(wù)端了。
第二次揮手，服務(wù)端收到了客戶(hù)端發(fā)送的 FIN 報(bào)文段，向客戶(hù)端回了一個(gè) ACK 報(bào)文段。
第三次揮手，服務(wù)端向客戶(hù)端發(fā)送FIN 報(bào)文段，請(qǐng)求關(guān)閉連接，同時(shí)服務(wù)端進(jìn)入 LAST_ACK 狀態(tài)。
第四次揮手，客戶(hù)端收到服務(wù)端發(fā)送的 FIN 報(bào)文段后，向服務(wù)端發(fā)送 ACK 報(bào)文段,然后客戶(hù)端進(jìn)入 TIME_WAIT狀態(tài)。服務(wù)端收到客戶(hù)端的 ACK 報(bào)文段以后，就關(guān)閉連接。此時(shí)，客戶(hù)端等待2MSL（指一個(gè)片段在網(wǎng)絡(luò)中最大的存活時(shí)間）后依然沒(méi)有收到回復(fù)，則說(shuō)明服務(wù)端已經(jīng)正常關(guān)閉，這樣客戶(hù)端就可以關(guān)閉連接了。四次揮手

最后完整的過(guò)程圖

為什么要四次揮手？
客戶(hù)端發(fā)送了 FIN 連接釋放報(bào)文之后，服務(wù)器收到了這個(gè)報(bào)文，就進(jìn)入了 CLOSE-WAIT 狀態(tài)。這個(gè)狀態(tài)是為了讓服務(wù)器端發(fā)送還未傳送完畢的數(shù)據(jù)，傳送完畢之后，服務(wù)器會(huì)發(fā)送 FIN 連接釋放報(bào)文。
HTTP持久連接
如果有大量的連接，每次在連接，關(guān)閉都要經(jīng)歷三次握手，四次揮手，這顯然會(huì)造成性能低下。因此。Http 有一種叫做長(zhǎng)連接（keepalive connections）的機(jī)制。它可以在傳輸數(shù)據(jù)后仍保持連接，當(dāng)客戶(hù)端需要再次獲取數(shù)據(jù)時(shí)，直接使用剛剛空閑下來(lái)的連接而無(wú)需再次握手。

HTTP和HTTPS

什么是HTTP?

超文本傳輸協(xié)議，是一個(gè)基于請(qǐng)求與響應(yīng)，無(wú)狀態(tài)的，應(yīng)用層的協(xié)議，常基于TCP/IP協(xié)議傳輸數(shù)據(jù)，互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議,所有的WWW文件都必須遵守這個(gè)標(biāo)準(zhǔn)。設(shè)計(jì)HTTP的初衷是為了提供一種發(fā)布和接收HTML頁(yè)面的方法。

HTTP特點(diǎn)：

無(wú)狀態(tài)：協(xié)議對(duì)客戶(hù)端沒(méi)有狀態(tài)存儲(chǔ)，對(duì)事物處理沒(méi)有“記憶”能力，比如訪(fǎng)問(wèn)一個(gè)網(wǎng)站需要反復(fù)進(jìn)行登錄操作。
無(wú)連接：HTTP/1.1之前，由于無(wú)狀態(tài)特點(diǎn)，每次請(qǐng)求需要通過(guò)TCP三次握手四次揮手，和服務(wù)器重新建立連接。比如某個(gè)客戶(hù)機(jī)在短時(shí)間多次請(qǐng)求同一個(gè)資源，服務(wù)器并不能區(qū)別是否已經(jīng)響應(yīng)過(guò)用戶(hù)的請(qǐng)求，所以每次需要重新響應(yīng)請(qǐng)求，需要耗費(fèi)不必要的時(shí)間和流量。
基于請(qǐng)求和響應(yīng)：基本的特性，由客戶(hù)端發(fā)起請(qǐng)求，服務(wù)端響應(yīng)。
簡(jiǎn)單快速、靈活。
通信使用明文、請(qǐng)求和響應(yīng)不會(huì)對(duì)通信方進(jìn)行確認(rèn)、無(wú)法保護(hù)數(shù)據(jù)的完整性。

HTTP報(bào)文組成:

請(qǐng)求行：包括請(qǐng)求方法、URL、協(xié)議/版本
請(qǐng)求頭(Request Header)
請(qǐng)求正文
狀態(tài)行
響應(yīng)頭
響應(yīng)正文

HTTP的缺點(diǎn)：

通信使用明文（不加密），內(nèi)容可能會(huì)被竊聽(tīng)。
不驗(yàn)證通信方的身份，因此有可能遭遇偽裝。
無(wú)法證明報(bào)文的完整性，所以有可能已遭篡改。

什么是HTTPS?

HTTPS：是以安全為目標(biāo)的HTTP通道，簡(jiǎn)單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細(xì)內(nèi)容就需要SSL。HTTPS協(xié)議的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩?；另一種就是確認(rèn)網(wǎng)站的真實(shí)性。

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

HTTPS通訊方式：

客戶(hù)使用https的URL訪(fǎng)問(wèn)Web服務(wù)器，要求與Web服務(wù)器建立SSL連接。
Web服務(wù)器收到客戶(hù)端請(qǐng)求后，會(huì)將網(wǎng)站的證書(shū)信息（證書(shū)中包含公鑰）傳送一份給客戶(hù)端。
客戶(hù)端的瀏覽器與Web服務(wù)器開(kāi)始協(xié)商SSL連接的安全等級(jí)，也就是信息加密的等級(jí)。
客戶(hù)端的瀏覽器根據(jù)雙方同意的安全等級(jí)，建立會(huì)話(huà)密鑰，然后利用網(wǎng)站的公鑰將會(huì)話(huà)密鑰加密，并傳送給網(wǎng)站。
Web服務(wù)器利用自己的私鑰解密出會(huì)話(huà)密鑰。
Web服務(wù)器利用會(huì)話(huà)密鑰加密與客戶(hù)端之間的通信。

為什么HTTPS安全

SSL不僅提供加密處理，加密方式為混合加密。
SSL而且還使用了一種被稱(chēng)為證書(shū)的手段，可用于確定方。證書(shū)由值得信任的第三方機(jī)構(gòu)頒發(fā)，用以證明服務(wù)器和客戶(hù)端是實(shí)際存在的。另外，偽造證書(shū)從技術(shù)角度來(lái)說(shuō)是異常困難的一件事。所以只要能夠確認(rèn)通信方（服務(wù)器或客戶(hù)端）持有的證書(shū)。

加密方法

對(duì)稱(chēng)加密：加密和解密同用一個(gè)密鑰的方式稱(chēng)為共享密鑰加密（Common keycrypto system），也被叫做對(duì)稱(chēng)密鑰加密.

對(duì)成加密的方式效率比較低，加密速度慢。另外對(duì)稱(chēng)加密存在安全隱患的問(wèn)題，堆成加密的密鑰必須要傳到對(duì)方對(duì)方才能解密，要是對(duì)方在密鑰傳輸?shù)倪^(guò)程獲取到密鑰，那不是密鑰失去了加密的意義，所以完全使用對(duì)稱(chēng)加密也是不安全的。

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

那么非對(duì)稱(chēng)個(gè)加密就一定安全嗎？非對(duì)稱(chēng)加密也不安全，為什么呢？因?yàn)榇嬖谥虚g偽造公鑰和私鑰，假如在公鑰傳給對(duì)方的時(shí)候，有人獲取到公鑰，雖然她不能用你的公鑰做什么，但是它截獲公鑰后，把自己偽造的公鑰發(fā)送給對(duì)方，這樣對(duì)方獲取的就不是真正的公鑰，當(dāng)對(duì)方用公鑰進(jìn)行加密文件，再將文件發(fā)送給對(duì)方，這樣即使截獲人沒(méi)有獲取到真正的私鑰，但是加密時(shí)的公鑰是截獲人的，他獲取到加密文件，只需要用自己的私鑰進(jìn)行解密就成功獲取到文件了。

混合加密機(jī)制（對(duì)稱(chēng)加密與非對(duì)稱(chēng)加密結(jié)合的方式）顧名思義也就是對(duì)稱(chēng)加密和非對(duì)稱(chēng)加密的方式相結(jié)合。

如何證明公開(kāi)沒(méi)要本身的真實(shí)性。因?yàn)樵诠_(kāi)秘鑰傳輸?shù)倪^(guò)程中，可能真正的公開(kāi)秘鑰已經(jīng)被攻擊者替換掉了。

為了解決上述問(wèn)題，于是除了CA認(rèn)證證書(shū)。服務(wù)器將CA證書(shū)發(fā)送給客戶(hù)端，以進(jìn)行公開(kāi)密鑰加密方式通信。接到證書(shū)的客戶(hù)端可使用數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)的公開(kāi)密鑰，對(duì)那張證書(shū)上的數(shù)字簽名進(jìn)行驗(yàn)證，一旦驗(yàn)證通過(guò)，客戶(hù)端便可明確兩件事：

一：認(rèn)證服務(wù)器的公開(kāi)密鑰的是真實(shí)有效的數(shù)字證書(shū)認(rèn)證機(jī)構(gòu)；
二：服務(wù)器的公開(kāi)密鑰是值得信賴(lài)的。

那么公開(kāi)密鑰如何交接給客戶(hù)端是一件非常重要的事，因此多數(shù)瀏覽器開(kāi)發(fā)商發(fā)布版本時(shí)，會(huì)事先在內(nèi)部植入常用認(rèn)證機(jī)關(guān)的公開(kāi)密鑰，這樣就確保公鑰是使用認(rèn)證機(jī)構(gòu)的公鑰避免了公鑰偽造的過(guò)程，進(jìn)而確保了安全。

您的項(xiàng)目需求

*請(qǐng)認(rèn)真填寫(xiě)需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。

整合營(yíng)銷(xiāo)服務(wù)商

關(guān)于IP屬地公開(kāi)展示，你想了解的這里都有

一、關(guān)于展示IP地址的相關(guān)規(guī)定

二、我們?yōu)槭裁葱枰私?/h1>既然沒(méi)有要求，那知道這些對(duì)我們是否還有意義？