辑导语：前段时间，有很多博主因为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