服务器端

作者： Dflying Chen （ http://dflying.cnblogs.com/ ） PS ：承蒙各位厚爱，在博客园中安家的两个月中我学到了不少东西，认识了许多朋友，且得到了好多机会。目前我有幸翻译一本 Atlas 的书： Foundations of Atlas: Rapid Ajax Development with ASP.NET 2.0 ，估计三个月后即可于人民邮电出版社并面世。所以这段时间比较忙， Blog 也不能有前一段时间那么频繁的更新了，特此表示歉意。当然，欢迎朋友们继续来讨论 Atlas 的相关问题，我会尽力回答。 未来的两个月内，对于 Foundations of Atlas 的翻译，我希望能够精益求精，所以一定会有不少问题需要与各位朋友讨论，例如术语，翻译风格等等。在这里我预先感谢了！ 在上一篇（请参考： 开发 ASP.NET Atlas 服务器端 Extender 控件 —— 编写客户端 Behavior ）中我们已经写好了客户端的 Behavior 。在本篇文章中，让我们将它包装起来作为服务器端控件运行。 首先来到 ValidateUserNameProperties.cs 文件，该类继承于 TargetControlPropertiesBase<Control> 基类，其中定义的是客户端属性值与服务器端属性值之间的映射关系。同时，

sessionStorage 和 localStorage 是HTML5 Web Storage API 提供的，可以方便的在web请求之间保存数据。有了本地数据，就可以避免数据在浏览器和服务器间不必要地来回传递。 sessionStorage、localStorage、cookie都是在浏览器端存储的数据，其中sessionStorage的概念很特别，引入了一个“浏览器窗口”的概念。sessionStorage是在同源的同窗口（或tab）中，始终存在的数据。也就是说只要这个浏览器窗口没有关闭，即使刷新页面或进入同源另一页面，数据仍然存在。关闭窗口后，sessionStorage即被销毁。同时“独立”打开的不同窗口，即使是同一页面，sessionStorage对象也是不同的。 Web Storage带来的好处： 1、减少网络流量：一旦数据保存在本地后，就可以避免再向服务器请求数据，因此减少不必要的数据请求，减少数据在浏览器和服务器间不必要地来回传递。 2、快速显示数据：性能好，从本地读数据比通过网络从服务器获得数据快得多，本地数据可以即时获得。再加上网页本身也可以有缓存，因此整个页面和数据都在本地的话，可以立即显示。 3、临时存储：很多时候数据只需要在用户浏览一组页面期间使用，关闭窗口后数据就可以丢弃了，这种情况使用sessionStorage非常方便。

thrift链接： https://www.cnblogs.com/sxrtb/p/12209455.html 一 总体介绍 　　thrift中主要文件包括.thrift文件(其中包括访问的接口、接口中的相关字段和异常处理等)，服务器端实现.thrift文件中的接口文件(可以处理相关异常），服务器根据thrift协议栈结构所示的方式编写的服务启动文件，客户端根据thrift协议栈结构所示的方式编写的调用服务器端接口的文件。 　　 　　这个协议栈结构已经在 thrift介绍 中说明，而且thrift文件已经进行过说明，现在就客户端和服务器端程序编写进行说明。 　　thrift文件中定义了接口可异常，但是接口的信息，异常的返回信息是需要我们服务端进行实现的。所以我们首先需要进行对thrift中定义的接口进行实现。thrift根据需要，可以在Service中定义多个接口，而服务器端有必要对多个接口进行实现。服务器端实现，就只需要implements ServiceName.Iface就行，并编写自己的业务逻辑。 　　1.Protocal（TProtocal定义了数据传输的格式，的具体具体实现有以下几种） 　　 　　TBinaryProtocol为而二进制格式，把各类型转换成 byte 数组，交给 TTransport 传输； 　　TCompactProtocol为压缩格式，使用

通常情况下，打开网页或app去查询或者刷新时，客户端向服务器发出请求然后返回数据,客户端与服务端对应的模式是: 客户端请求--服务端响应, 而在有些情况下,服务端会主动推送一些信息到客户端,例如:新闻的订阅,天气的提醒等等,那么在这样的模式下,会有些问题值得思考: 1）应用服务器如何确定每一个应用所在的设备？ 2）服务端把消息推到哪，客户端又不像服务器有一个固定的地址？ 3）服务端主动推送到客户端是怎么一个过程? 假设一个场景，商家在商家后台需要实时的获取到有没有新订单，有的话是几个；这个需求类似与日常中使用QQ或者微信时的新信息提醒一样，只要有新信息就需要提醒；商家基本在PC上使用，各式浏览器都有：如 IE系列（7.0，8.0，9.0及以上），chrome内核，firefox等；功能所属的部署在Tomcat 6.0上，如果技术需要可以部署到 Tomcat 7.0上。 这种浏览器与服务器实时通信的方式有哪些方式。 1、AJAX轮询 这是我们最自然想到的。 采用 常规AJAX轮询 的方式，每10s或者30s轮询一次，既可以判断出有有多少个新订单进入，且这种时间间隔对于消息提醒也是可以接受的。这种技术方式实现起来非常简单，目前的机器都是可以机器的，前端浏览器也都支持。 但是这种方式会有非常严重的问题，就是需要不断的向服务器发送消息询问，如果有1w个商家打开了浏览器，采用10s轮询的方式

关闭secureCRT声音： 直接在虚拟机上ssh道实验室的服务器时并没有发现过上一段时间不操作就会断开，可能是我没有注意，也能是操作时间间隔比较短。 但是在secureCRT上登录时，发现经常的断开，很是郁闷，所以baidu了一下，呵呵，好多人都遇到过这种问题。我也贴一下，方便记忆。 有 时候服务器端的 /etc/profile 或者 ~/.bash_profile 中设置了 TMOUT 选项，或者是 /etc/ssh/sshd_config 文件中设置了客户端连接时间的设置，很可能一段之间之后，SecureCRT就会被断开连接，所以SecureCRT又一个选项可以设置每隔多少秒自动发 送一个信息到服务器端，告诉服务器端客户端还在连接中。 会话选项 –> 终端 –> 反空闲 –> 发送字符串 可以设置 ，比如发送 \n 、null或其他信息过去，后面可以设置每隔多少秒发送，比如可以60秒一次，这样可以保证不会掉线。 如果想应用于所有会话的话，选择全局选项->默认会话->编辑默认设置.做上述修改修改就可以全局使用了. 来源： CSDN 作者： 盏茶作酒 链接： https://blog.csdn.net/qq_40999917/article/details/104215017

web开发也就是前端和后端，首先理解一下前后端分离技术，其实说的后端代码和前端代码分割开来。不然不利于前端和后端分别开发。 web开发 CS即客户端、服务端编程。传统的socket开发。 客户端、服务端之间需要使用socket，约定协议，版本（往往使用的协议是TCP或者UDP），指定地址和端口，就可以通信了。客服端、服务端传输数据，数据可以有一定的格式，双方必须先约定好。 BS编程，即Brower、Server开发。 brower浏览器，是一种特殊的 客户端，支持http(s)协议，能够通过URL向服务器发起请求，等待服务器返回HTML等数据，并在浏览器内可视化展示的程序。 SERVER,支持http协议，能够接受众多客户端发起的http协议请求，经过处理，将HTML等数据返回给浏览器。 本质上来说，BS是一种特殊的CS，即 客户端必须是一种支持http协议且能解析并渲染html的软件，服务端必须是能够接受多客户端http访问的服务器软件。 http协议底层是基于tcp协议实现。 BS开发分为两端开发。 客户端开发——或称前端开发。HTML（控制格式），css（控制样式），JavaScript等。 服务端开发， python有WSGI,django,flask,tornado等。 http协议 http协议是 无状态协议 。同一个客户端的两次请求之间并没有任何关系，从服务端角度来说

SSRF SSRF(Server-Side Request forgery，服务器端请求伪造）是一种攻击者构造请求，由服务器端发起请求的web安全漏洞，很多时候的SSRF攻击的目标是外网无法访问的内部主机系统，因为由服务器发起的请求很多时候是外网无法访问的内部系统。可以算是内部信息泄露。 SSRF漏洞原理： SSRF的形成大多是由于服务器端提供了从其他相联的服务器应用获取数据的功能且没有对目标地址做过滤和限制。 THE HACKER 操作服务端从指定URL地址获取网页文本内容，加载指定地址的图片等等，利用的是服务端的请求伪造。SSRF利用存在缺陷的WEB应用作为代理攻击远程和本地的服务器。 主要攻击方式。 对外网，服务器所在内网，本地进行端口扫描，获取服务的banner信息。 攻击运行在内网或本地的应用程序。 对内网WEB应用进行指纹识别，识别企业内部的资产消息。 攻击内往网的Web应用，主要是使用HTTP GET 请求就可以实现的攻击（比如struts2，SQli等）。 利用file协议读取本地文件等。 SSRF漏洞利用 现在服务器上有一个ssrf.php的页面，该页面的功能是获取URL参数，然后将URL的内容显示到网页页面上。 <?php function curl($url){ $ch=curl_init(); curl_setopt($ch,CURLOPT_URL,$url

HTTP请求报文 请求方式 GET请求：向指定URL请求资源 POST请求：向指定URL提交待处理的数据 URL URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来唯一的标识一个资源。 协议版本 格式为HTTP/主版本号.次版本号，常用为：HTTP/1.1 HTTP/1.0 请求头部 Host：接受请求的服务器地址，可以是IP或者是域名 User-Agent：发送请求的应用名称 Connection：指定与连接相关的属性，例如（Keep_Alive，长连接） Accept-Charset：通知服务器端可以发送的编码格式 Accept-Encoding：通知服务器端可以发送的数据压缩格式 Accept-Language：通知服务器端可以发送的语言 请求正文 HTTP响应报文 协议版本 同请求报文 状态码 100-199表示请求已收到继续处理，200-299表示成功，300-399表示资源重定向，400-499表示客户端请求出错，500-599表示服务器端出错 200：响应成功 302：跳转，重定向 400：客户端有语法错误 403：服务器拒绝提供服务 404：请求资源不存在 500：服务器内部错误 响应头部 Server：服务器应用软件的名称和版本 Content-Type：响应正文的类型 Content-Length：响应正文的长度

会话技术 1. 会话：一次会话中包含多次请求和响应。 * 一次会话：浏览器第一次给服务器资源发送请求，会话建立，直到有一方断开为止 2. 功能：在一次会话的范围内的多次请求间，共享数据 3. 方式： 1. 客户端会话技术：Cookie 2. 服务器端会话技术：Session Cookie： 1. 概念：客户端会话技术，将数据保存到客户端 2. 快速入门： * 使用步骤： 创建Cookie对象，绑定数据 new Cookie(String name, String value) 发送Cookie对象 response.addCookie(Cookie cookie) 获取Cookie，拿到数据 Cookie[] request.getCookies() 3. 实现原理 * 基于响应头set-cookie和请求头cookie实现 4. cookie的细节 1. 一次可不可以发送多个cookie? 可以 可以创建多个Cookie对象，使用response调用多次addCookie方法发送cookie即可。 2. cookie在浏览器中保存多长时间？ 默认情况下，当浏览器关闭后，Cookie数据被销毁 持久化存储： setMaxAge(int seconds) 正数：将Cookie数据写到硬盘的文件中。持久化存储。并指定cookie存活时间，时间到后，cookie文件自动失效 负数：默认值

@by Ruth92 （转载请注明出处） 第7章 网络编程 Node 只需要几行代码即可构建服务器，无需额外的容器。 Node 提供了以下4个模块（适用于服务器端和客户端）： net -> TCP dgram -> UDP http -> HTTP https -> HTTPS OSI 模型：由七层组成，分别为物理层、数据链路层、网络层、传输层、表示层、应用层。 一、构建 TCP 服务 TCP TCP（传输控制协议），属于传输层协议，是面向连接的协议。 许多应用层协议基于 TCP 构建，典型的是 HTTP、SMTP、IMAP 等协议。 【显著特征】：在传输之前需要3次握手形成会话。 只有会话形成之后，服务器端和客户端之间才能互相发送数据 在创建会话的过程中，服务器端和客户端分别提供一个套接字，这两个套接字共同形成一个连接。 服务器端与客户端则通过套接字实现两者之间连接的操作。 创建 TCP 服务器端 TCP-Server.js var net = require('net'); var server = net.createServer(function(socket) { // 新的连接 socket.on('data', function(data) { socket.write('你好'); }); socket.on('end', function() { console