服务器端

1．什么是兼容性测试 兼容性测试就是验证开发出来的程序在特定的运行环境中与特定的软件、硬件或数据相组合是否能正常运行、有无异常的测试过程。 2．兼容性测试包含哪几类 （1）浏览器兼容性测试： 在指定的浏览器上检查Web页面样式和元素的展示效果，以及交互是否正常。 主流浏览器： Windows:IE 9/10/11, Firefox（最新版本）, Chrome（最新版本）。 Mac:Safari, Chrome（最新版本）, Firefox（最新版本）。 测试注意事项： ① 浏览器兼容性测试常见于B/S（浏览器/服务器端）结构的产品中。 ② 虽然我们能通过官方的一些统计数据去收集主流的浏览器和对应的版本，但最好让产品经理明确定义出支持哪些浏览器和对应的版本，因为这也取决于产品的应用人群和具体的业务场景。 ③ 浏览器兼容性测试主要检查Web页面样式和元素的展示效果，以及交互是否会有异常，跟具体的业务逻辑无关。 ④ 跟前端开发人员多交流，明确哪些样式或元素不是标准的，很有可能会出现兼容性问题，先有针对性地在所有要求支持的浏览器版本上进行验证，再挑选每种浏览器的一个版本去验证所有的标准页面。 ⑤ 多记录，多总结，做好统计分析，在后续的测试中，只需针对有改动的、易出现兼容性问题的元素和样式进行测试。 ⑥ 留意IE大版本的升级，以及Chrome（谷歌浏览器）和Firefox（火狐浏览器

Response.Redirect()方法 以下情况使用Response.Redirect()方法： 1.用户连接到另一台服务器上的资源； 2.把用户连接到非ASPX的资源，例如HTML页面； 3.将查询字符串作为URL的一部分(因为其他2种方法不能做到2次postback)； 需要使用汉字查询的请先转换 string message =server.urlencode("汉字"); 4.要确保HTML输出合法； 5. 使用Session Cookies Application等对象进行页面间的数据传递。 缺点：反应慢（两次请求），控件信息丢失，不能访问前一页面提交的数据信息。 Server.Transfer()方法 以下情况使用Response.Transfer()方法： 1.aspx页面间的转换（不涉及登录）； 2.实现页面跳转的同时将页面的控制权进行移交； 3.跳转之后浏览器地址栏的Url不变。 优点：页面跳转过程中Request Session等保存的信息不变，跳转之后可以使用上一个页面提交的数据；这种方法的重定向请求是在服务器端的进行的，浏览器不知道页面已经发生了一次跳转 提示：如果要将执行流程转入同一Web服务器的另一个ASPX页面，应当使用Server.Transfer而不是Response.Redirect，因为Server.Transfer能够避免不必要的网络通信

是转载的,原文地址忘记了,如有冒犯请原作者见谅. HyperLink控件 1. Asp.net 服务器端控件 属性NavigateUrl指定要跳转到的Url地址 2. NavigateUrl是可以在服务器端使用代码修改，这个区别于<a> 3. 由于HyperLink本身没有事件所以要在服务器端其它事件中设置NavigateUrl 4. 代码示例 <Asp:HyperLink id=”hyperlink” runat=”server” NavigatoeUrl=”test.aspx”>ok</Asp:HyperLink> Response.Redirect()方法 1. 过程：发送一个Http响应到客户端，通知客户端跳转到一个新的页面，然后客户端再发送跳转请求到服务器端。 2. 页面跳转之后内部控件保存的所有信息丢失，当A跳转到B，B页面将不能访问A页面提交的数据信息。 3. 使用这个方法使用这个方法跳转后浏览器地址栏的Url信息改变 4. 可以使用Session Cookies Application等对象进行页面间的数据传递 5. 重定向操作发生在客户端，总共涉及到两次与Web服务器的通信：一次是对原始页面的请求，另一次是重定向新页面的请求 Server.Transfer()方法 1. 实现页面跳转的同时将页面的控制权进行移交 2. 页面跳转过程中Request

问题 从一个例子说起，我们的客户端从服务器获取数据，这里假定获取文章。第一次使用，我们获取服务器端最新发表的几篇文章。 我们可以每次都重新获取，但这样费时又费流量。好的设计应该是我们把获取过的文章存下来，下次只获取最新发表的文章。 这样就有个问题，如果某一篇文章，我们已经获取过了，可有一天它更新了。。。。 还有个问题，文章持续获取下去，我们手机没空间了。。。。 如何使我们客户端能保存有限的文章，并且同时可以得到更新呢？ 解决方法 为了保证客户端不存过多文章，我们应该设置一个过期期限，当缓存的文章比较老旧，删除掉即可。 为了保证客户端的文章能够得到更新，服务器的文章表应该有个最后修改时间字段。同时服务器端保存客户端最后一次获取文章的时间，保存在session里。 1、文章表设计 | index | content | ts | dl | index 索引； content 内容； ts 文章最后一次的修改时间。把ts的格式设计为：NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP，即默认为当前的时间戳，且随着文章更改，自动更新为更改时间。 dl 文章是否被删除了； 2、客户端查询文章时服务器端的工作 从session中查询该用户对文章的最后一次获取时间，last_gotten_ts； 如果有该记录

客户端负载均衡器 在SpringCloud中Ribbon负载均衡客户端，会从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地。 让后在本地实现轮训负载均衡策略。 Ribbon与Nginx区别 1.服务器端负载均衡Nginx nginx是客户端所有请求统一交给nginx，由nginx进行实现负载均衡请求转发，属于服务器端负载均衡。 既请求有nginx服务器端进行转发。 2.客户端负载均衡Ribbon Ribbon是从eureka注册中心服务器端上获取服务注册信息列表，缓存到本地，让后在本地实现轮训负载均衡策略。 既在客户端实现负载均衡。 应用场景的区别： Nginx适合于服务器端实现负载均衡 比如Tomcat ，Ribbon适合与在微服务中RPC远程调用实现本地服务负载均衡，比如Dubbo、SpringCloud中都是采用本地负载均衡。 Ribbon是Spring Cloud （本地）客户端负载均衡器 Ribbon底层实现： Member： pom： <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0

1、CS、BS架构定义 　　CS（Client/Server）：客户端----服务器结构。C/S结构在技术上很成熟，它的主要特点是交互性强、具有安全的存取模式、网络通信量低、响应速度快、利于处理大量数据。因为客户端要负责绝大多数的业务逻辑和UI展示，又称为胖客户端。它充分利用两端硬件，将任务分配到Client 和Server两端，降低了系统的通讯开销。C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。 　　C/S 架构是一种典型的两层架构，其客户端包含一个或多个在用户的电脑上运行的程序，而服务器端有两种，一种是数据库服务器端，客户端通过数据库连接访问服务器端的数据；另一种是Socket服务器端，服务器端的程序通过Socket与客户端的程序通信。 　　BS（Browser/Server）：浏览器----服务器结构，是目前应用系统的发展方向。BS是伴随着Internet技术的兴起，对C/S架构的改进，为了区别于传统的C/S 模式，特意称为B/S模式。在这种结构下，通过W3浏览器来进入工作界面，极少部分事务逻辑在前端（Browser）实现，主要事务逻辑在服务器端（Server）实现，形成三层（3-tier）结构。这样使得客户端电脑负荷大大简化（因此被称为瘦客户端），减轻了系统维护、升级的支出成本

URI格式规范 URI中尽量使用连字符”-“代替下划线”_”的使用 URI中统一使用小写字母 URI中不要包含文件(脚本)的扩展名 URI命名规范 文档(Document)类型的资源用名词(短语)单数命名 集合(Collection)类型的资源用名词(短语)复数命名 仓库(Store)类型的资源用名词(短语)复数命名 控制器(Controller)类型的资源用动词(短语)命名 URI中有些字段可以是变量，在实际使用中可以按需替换 CRUD的操作不要体现在URI中，HTTP协议中的操作符已经对CRUD做了映射。 HTTP请求方法的使用 GET方法用来获取资源 PUT方法可用来新增/更新Store类型的资源 PUT方法可用来更新一个资源的全部属性，使用时传递所有属性的值，即使有的值没有改变 PATCH方法更新资源的部分属性。因为 PATCH 比较新，而且规范比较复杂，所以真正实现的比较少，一般都是用 POST 替代 POST方法可用来创建一个资源 POST方法可用来触发执行一个Controller类型资源 DELETE方法用于删除资源 HTTP响应状态码的使用 200 (“OK”) 用于一般性的成功返回，不可用于请求错误返回 201 (“Created”) 资源被创建 202 (“Accepted”) 用于Controller控制类资源异步处理的返回，仅表示请求已经收到

在什么技术都要用私有云服务器技术，这不，车牌识别也来了；目前识别效果比较好的当属服务器端车牌识别，即服务器版车牌OCR识别软件，该软件可部署在客户私有服务器中（私有本地服务器或云服务器均可），APP和业务系统可通过webservice接口调用该识别服务，设备端只负责拍摄图像后上传，上传到已部署服务器端车牌识别软件的服务器中进行识别，识别完成后再返回标准的XML数据。整个识别过程和我公司没有任何交互，均在企业自有的服务器上完成识别。 车牌OCR-SDK 王经理 13371621309 服务器端车牌识别软件目前支持Windows、Linux等主流服务器操作系统。 1、服务器端车牌识别可识别污损车牌、阴阳牌、大角度车牌，白天识别率≥99.7%，夜间识别率≥98%。 2、可以在同一服务器上开启多个识别进程，多个进程同时识别，提升识别效率。 3、服务器端车牌识别提供API：WebService、RestService、Http等多种接口方式。 4、识别车牌种类多：支持横版车牌识别、竖版车牌识别，及其他板式的各种车牌。 5、服务器端车牌识别识别时间快：毫秒级速度识别一张车牌，包含整网络交换过程也可在2秒内完成。 6、支持负载均衡，自动分发。 来源： oschina 链接： https://my.oschina.net/u/4426693/blog/3160278

著作权归作者所有。 商业转载请联系作者获得授权，非商业转载请注明出处。 作者：徐小花 链接：http://www.zhihu.com/question/20462696/answer/18731073 来源：知乎 开启Google的登陆二步验证（即Google Authenticator服务）后用户登陆时需要输入额外由手机客户端生成的一次性密码。 实现Google Authenticator功能需要服务器端和客户端的支持。服务器端负责密钥的生成、验证一次性密码是否正确。客户端记录密钥后生成一次性密码。 目前客户端有： android版： Google 身份验证器 iOS版： https:// itunes.apple.com/cn/app /google-authenticator/id388497605 https://github.com/google/google-authenticator-android 实现原理： 一、用户需要开启Google Authenticator服务时， 1.服务器随机生成一个类似于『DPI45HKISEXU6HG7』的密钥，并且把这个密钥保存在数据库中。 2.在页面上显示一个二维码，内容是一个URI地址（otpauth://totp/账号?secret=密钥），如『otpauth://totp/kisexu@gmail.com?secret

整个流程 域名解析 —> 与服务器建立连接 —> 发起HTTP请求 —> 服务器响应HTTP请求，浏览器得到html代码 —> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片） —> 浏览器对页面进行渲染呈现给用户 1. 域名解析 以Chrome浏览器为例： ① Chrome浏览器 会首先搜索浏览器自身的DNS缓存（缓存时间比较短，大概只有1分钟，且只能容纳1000条缓存），看自身的缓存中是否有https://www.cnblogs.com 对应的条目，而且没有过期，如果有且没有过期则解析到此结束。 注：我们怎么查看Chrome自身的缓存？可以使用 chrome://net-internals/#dns 来进行查看 ② 如果浏览器自身的缓存里面没有找到对应的条目，那么Chrome会搜索操作系统自身的DNS缓存,如果找到且没有过期则停止搜索解析到此结束. 注：怎么查看操作系统自身的DNS缓存，以Windows系统为例，可以在命令行下使用 ipconfig /displaydns 来进行查看 ③ 如果在Windows系统的DNS缓存也没有找到，那么尝试读取hosts文件（位于C:\Windows\System32\drivers\etc），看看这里面有没有该域名对应的IP地址，如果有则解析成功。 ④ 如果在hosts文件中也没有找到对应的条目