移动端与后端数据传输加密

对称加密：对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高
非对称加密：非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。
方案：将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。
方案的流程介绍：
1、APP客户端需要和服务器进行数据交互，它的APP首先生成了一个随机数作为对称密钥(比如AES加密的密钥)。
2、APP客户端向服务器请求公钥
3、服务器将公钥发送给APP客户端
4、APP客户端使用服务器的公钥将自己的对称密钥(比如AES加密的密钥)加密
5、APP客户端将加密后的对称密钥发送给服务器
6、服务器使用私钥解密得到APP客户端的对称密钥
7、APP客户端与服务器可以使用对称密钥来对沟通的内容进行加密与解密了
App端和后台数据加密分两部分：
1数据传输的时候加密 （一般采用>

实现的原理如下：

无论是手机还是电脑，当浏览器访问URL时，客户端和服务器的交互都是基于>

当客户端向服务器发起访问请求时，>

显示不同的内容通常由服务器后端代码处理。 如果通过重定向实现，则可以使用js。

例如，百度贴吧，地址相同，手机端和电脑端分别返回的是wap页面和html页面。

扩展资料：

User Agent中文名称是用户代理，简称UA，它是一个特殊的字符串标头，使服务器可以识别 *** 作系统和版本，CPU类型，客户端使用的浏览器和版本，浏览器呈现引擎，浏览器语言，浏览器插件等。

有些网站通常会通过判断UA将不同的页面发送到不同的 *** 作系统和不同的浏览器，因此某些页面可能无法在某个浏览器中正确显示，但是可以通过伪装UA来绕过检测。

参考资料来源：

百度百科-用户代理

在用户和系统的整个交互过程中，有很大一部分交互流程是用户在客户端进行 *** 作，客户端将用户 *** 作所产生的请求发送给服务器，服务器找到请求的资源再返回给客户端，最后将请求的资源呈现在用户面前。在这个过程中，由于网络带宽、服务器性能、客户端性能等因素的影响，可能会导致请求的资源出现在用户面前需要一段时间。为了缓解用户在这段时间的焦虑，提示系统还在正常运行，因此需要设计loading。

用户需要等到加载完成才能进行其他 *** 作，模态加载时一般会停留在当前页面，等到内容加载完成才跳转、改变页面。模态加载一般用在单向流程、会造成不可逆结果的功能中，例如注册、支付、转账，这种情况下使用模态加载可以有效避免流程中出现各种异常情况。

模态加载常见的一种做法是在页面中间出现模态窗口，明显的告诉用户不可做其他 *** 作。
另一种做法是只在相应的区域出现加载提示，但是点击其他区域时不产生反应。
在模态加载的过程中，最好设定一个明确的超时判断，在超过指定时间数据仍未请求成功时，告知用户可能存在的原因和下一步行动点，避免一直卡在加载进程中。
全屏加载实质上是属于内容的模态加载，加载时会跳转到内容展示页，再一次性加载完页面所有数据。

常见的做法是内容区整体保持空白，中间或内容区顶部有加载提示符告知用户耐心等待，直至所有数据请求就绪，再整体展示。若加载失败，则页面为空。这种方式最简单的一种加载处理方法，适用于页面中所有数据，每次查都需要重新请求、不存在本地数据的情况。例如知乎、网易云音乐、虎牙直播等都有广泛采取这种方式。
同模态加载一样，全屏加载同样需要一个明确的超时判断，在超过指定时间数据仍未请求成功时，告知用户可能存在的原因和下一步行动点，避免一直卡在加载进程中。

加载快的元素（例如文字）优先加载出来，加载慢的元素（例如、动图、视频）先用相关占位符表示，之后再逐步加载出来，这样用户在页面还未完全加载完的情况下就能对整体内容有个大致预期。但是缺点就是也许会丢失掉重要的关键信息，无法建立信息获取的闭环。
对于资源，还可以通过分级加载可以让这一过程更加平滑，首先加载低清版（甚至模糊版）的缩略图，在保证内容完整呈现后，再加载高清资源。

对于优先加载，还可以在加载内容前，预先将整体结构占位符显示出来，可以从形到体地提前告知用户接下来将要看到的东西，再对内容进行优先加载。结构占位符一般是类似于线框图形式的灰阶色块图，将各个模块的典型结构元素展示出来，通常不代表真实情况——这意味着无法点击，所以实际上在这一阶段仍然类似整屏加载。

优先加载中还可以将结构占位符和内容优先加载结合起来。将全局性元素的结构占位符先加载出来，然后优先加载全局性的元素，再对内容区进行内容上的优先加载。这种方式针对于整体的结构占位符来说，更为简约清爽，能给用户一个非常轻松的过程。

优先加载的方式还有很多，有时候还要综合考虑业务因素，优先加载对业务目标最有利的因素，因此做优先加载时，需要根据具体情况做出更合适的方案。

只加载用户当前视线内的内容，看不见的内容通过用户的 *** 作来触发再次加载。例如当页面滚动到底部尽头或下拉页面时，才会自动加载内容。懒加载一般用在无尽的信息流页面，或者有内容折叠的页面。

这种方式和懒加载方式恰恰相反，不是偷懒只加载用户视线内的内容，而是在用户浏览当前页的时候就预先加载之后用户可能点击的页面，当用户点击进入已经加载的页面就能感受飞一般的速度。但是这种方式会增加客户端和服务器的负载，也会占用一定的网络带宽。例如今日头条APP，加载新闻列表的时候就预加载好了新闻详情。

1提供视觉交互体验

有趣的加载动画可以让等待的过程变成了一种享受，让用户体会到新鲜有趣的等待过程。
2提供明确的提示，告诉用户所处处境和阶段

在用户的连接速度很慢，而页面又没有明确进程指示的情况下，用户很可能会不断刷新尝试重新连接，这就造成了用户的二次等待，使等待时间延长。为了避免这种情况，我们可以给出一定的提示，告诉用户所处处境和阶段。

好了，以上就是这次针对loading设计的一些总结和思考，在实际情况中运用的时候还是要考虑产品的具体诉求。想给用户提供一种什么视觉感觉，重点功能是否需要优先照顾到，重点流程是否需要确保足够流畅，某些流程是不是会造成不可逆后果等等具体问题，只有考虑清楚后才能设计出最适合你产品的loading哦。

android客户端和服务器端是基于IntentService的，具体如下：

后台使用简单的servlet，支持GET或POST。这个servlet最终返回给前台一个字符串flag，值是true或false，表示登录是否成功。

然后在安卓的ADT上创建一个安卓项目，建立两个Activity，分别作为登录界面和登录成功界面。

>

IntentService服务，用于在后台以队列方式处理耗时 *** 作。

在AndroidManifestxml中注册IntentService。注意uses-permission节点，为程序开启访问网络的权限。

登陆界面处理，注意按钮监听事件中，使用Intent将要传递的值传给service。接收广播类中，同样使用Intent将要传递的值传给下一个Activity。在onCreate()中，动态注册接收广播类的实例receiver。在接收广播类中，不要使用完毕后忘记注销接收器，否则会报一个Are you missing a call to unregisterReceiver() 的异常。

1、DHCP Client以广播的方式发出DHCP Discover报文

2、所有的DHCP Server都能够接收到DHCP Client发送的DHCP Discover报文，所有的DHCP Server都会给出响应，向DHCP Client发送一个DHCP Offer报文。

DHCP Offer报文中“Your(Client) IP Address”字段就是DHCP Server能够提供给DHCP Client使用的IP地址，且DHCP Server会将自己的IP地址放在“option”字段中以便DHCP Client区分不同的DHCP Server。DHCP Server在发出此报文后会存在一个已分配IP地址的纪录。

3、DHCP Client只能处理其中的一个DHCP Offer报文，一般的原则是DHCP Client处理最先收到的DHCP Offer报文。

DHCP Client会发出一个广播的DHCP Request报文，在选项字段中会加入选中的DHCP Server的IP地址和需要的IP地址。

4、DHCP Server收到DHCP Request报文后，判断选项字段中的IP地址是否与自己的地址相同。如果不相同，DHCP Server不做任何处理只清除相应IP地址分配记录；如果相同，DHCP Server就会向DHCP Client响应一个DHCP ACK报文，并在选项字段中增加IP地址的使用租期信息。

5、DHCP Client接收到DHCP ACK报文后，检查DHCP Server分配的IP地址是否能够使用。如果可以使用，则DHCP Client成功获得IP地址并根据IP地址使用租期自动启动续延过程；如果DHCP Client发现分配的IP地址已经被使用，则DHCP Client向DHCPServer发出DHCP Decline报文，通知DHCP Server禁用这个IP地址，然后DHCP Client开始新的地址申请过程。

6、DHCP Client在成功获取IP地址后，随时可以通过发送DHCP Release报文释放自己的IP地址，DHCP Server收到DHCP Release报文后，会回收相应的IP地址并重新分配。

在一个典型组网中，一个TURN客户端连接在一个私有网络中，通过一个或多个NAT来连接到公网。在公网中有一个TURN服务器。在因特网的别处有一个或多个对端是这个TURN客户端希望通讯的。这些对端也有可能是在一个或多个NAT的后面。该客户端使用服务器作为一个中继来发送数据包 到这些对端去，并且从这些对端接收数据包。

客户端通过一个IP地址和端口的组合来与服务器建立会话。客户端使用TURN命令在服务器上创建和 *** 作一个ALLOCATION。一旦这个allocation创建好了，客户端能够在数据发往哪个对端的指示下发送应用数据到这个服务器，服务器将中继这些数据到合适的对端。

客户端发送的应用数据包含在TURN消息中，服务器将数据提取出来，并以UDP数据包方式发送给对端。反向上，对端以UDP数据包方式发送应用数据到这个allocation提供的中继传输地址。

因为TURN消息总是包含客户端与哪些对端通讯的指示，客户端能够使用单一的allocation来与多个对端通讯。

turn 术语
TURN client：遵循RFC5766的STUN客户端。
TURN server：遵循RFC5766的STUN服务器。
Peer：TURN客户端希望连接的主机。TURN服务器为TURN客户端和它的对端中继流量，但Peer并不与TURN服务器使用TURN协议进行交互，它接收从TURN服务器发送过来的数据，并向TURN服务器发送数据。
Transport Address：IP地址与端口号的组合。
Host Transport Address：客户端或对端的传输地址。
Server-Reflexive Transport Address：NAT公网侧的传输地址，该地址由NAT分配，相当于一个特定的主机传输地址。
Relayed Transport Address：TURN服务器上的传输地址，用于客户端和对端中继数据。
TURN Server Transport Address：TURN服务器上的传输地址，用于客户端发送STUN消息给服务器。
Peer Transport Address：服务器看到的对端的传输地址，当对端是在NAT后面，则是对端的服务器反射传输地址。
Allocation：通过Allocate请求将中继传输地址提供给客户端，除了中继状态外，还有许可和超时定时器等。
5-tuple：五元组，包括客户端IP地址和端口，服务器IP地址和端口和传输协议（包括UDP、TCP、TLS）的组合。
Channel：通道号与对端传输地址的关联，一旦一个通道号与一个对端的传输地址绑定，客户端和服务器就能够利用带宽效应更大的通道数据消息来交换数据。
Permission：一个对端允许使用它的IP地址和传输协议来发送数据到TURN服务器，服务器只为从对端发来的并且匹配一个已经存在的许可的流量中继到相应的客户端。
Realm：服务器内用于描述服务器或内容的一个字符串，这个realm告诉客户端哪些用户名和密码的组合可用于认证请求。
Nonce：服务器随机选择的一个字符串，包含在报文摘要中。为了防止中继攻击，服务器应该有规律的改变这个nonce。

协议交互过程详细举例
以图2为例进行讲解，每个消息中，多个属性包含在消息中并显示它们的值。为了方便阅读，值以人们可读的格式来显示。

接着，客户端为了准备向对端A发送一些应用数据而创建一个permission。这里通过一个CreatePermission请求来做到。该请求携带XOR-PEER-ADDRESS属性包含有确定的请求的IP地址，这里为对端A的地址；需要注意的是，属性中地址的端口号被设置为0在CreatePermission请求中，并且客户端使用的是对端A的server-reflexive地址而不是它的主机地址（私网地址）；客户端在该请求中携带与之前的Allocate请求中一样的username、realm和nonce值，因此该请求被服务器认可。此时在该请求中，客户端没有携带SOFTWARE属性。
服务器收到该CreatePermission请求，产生一个相应的许可，并以CreatePermission成功响应来回应。该响应中只包含了Transaction-ID和MESSAGE-INTEGRITY属性。

现在客户端使用Send indication来发送应用数据到对端A。对端的server-reflexive传输地址包含在XOR-PEER-ADDRESS属性中，应用数据包含在DATA属性中。客户端已经在应用层上执行了路径MTU发现功能，因此通过DON’T-FRAGMENT属性来告知服务器当通过UDP方式来向对端发送数据时应设置DF位。Indications不能使用长期证书机制来认证，所以该消息中没有MESSAGE-INTEGRITY属性。
服务器收到Send indication后，提取出应用数据封装成UDP格式发给对端A；UDP报文的源传输地址为中继传输地址，并设置DF位。
对端A回应它自己的包含有应用数据的UDP包给服务器。目的地址为服务器的中继传输地址。当服务器收到后，将生成Data indication消息给客户端，携带有XOR-PEER-ADDRESS属性。应用数据包含在DATA属性中。

接着，对端B发送UDP数据包回应给服务器的中继传输地址。服务器收到后，回应给客户端ChannelData消息，包含UDP数据包中的数据。服务器知道是给哪个客户端发送ChannelData消息，这是因为收到的UDP数据包中的目的地址（即服务器的中继传输地址），并且知道使用的是哪个通道号，这是因为通道已经与相应的传输地址绑定了。

首先不要管安卓端还是苹果端，现在一般都是响应式的app，你放到安卓或者苹果或者pc或者平板都是没有问题的。一般采用的是>

在游览器与WEB服务器之间信息交互的过程中使用的协议是>

>

应答的服务器上存储着（一些）资源，比如HTML文件和图像。（我们称）这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，比如代理，网关，或者隧道（tunnels）。

尽管TCP/IP协议是互联网上最流行的应用，>

扩展资料：

协议功能

>

它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示(如文本先于图形)等。

>

参考资料来源：百度百科-->