服务器端

1、TCP概述 TCP(Transmission Control Protocol)：传输控制协议，是一种面向连接的协议。 TCP不同于UDP，TCP严格区分客户端和服务器端，在通信时，必须先由客户端去连接服务器端才能实现通信，服务器端不可以去主动连接客服端，并且服务器端程序需要事先启动，等待客户端的连接。 在jdk中提供了两个类用于实现TCP程序，一个是ServerSocket类，用于表示服务器端，一个Socket类，用于表示客户端。 通信时，首先创建代表服务器端的ServerSocket对象，该对象相当于开启一个服务，并等待客户端的连接，然后创建代表客户端的Socket对象向服务器发送连接请求，服务器端相应请求，两者建立开始通信。 2、ServerSocket ServerSocket类的构造方法： ServerSocket(int port)：创建绑定到特定端口的服务器套接字。 常用方法： Socket accept()：侦听并接受到此套接字的连接。 InetAddress getInetAddress()：返回此服务器套接字的本地地址。 3、Socket Socket类构造方法： Socket(String host, int port)：创建一个流套接字并将其连接到指定主机上的指定端口号。 Socket(InetAddress address, int port)

转载： https://mp.weixin.qq.com/s?__biz=MzU2MTkwMTE4Nw==&mid=2247487168&idx=1&sn=e1cc38cae47b0ea86d66d64cb081e8a3&chksm=fc70f52ccb077c3a42b4c51919bec6b77a9a26bee7840a8a5529c286f7430ecfd56e65eb133d&scene=21#wechat_redirect 存在下面两种情形： 情形一 ：一个客户端连接服务器以后，如果长期没有和服务器有数据来往，可能会被防火墙程序关闭连接，有时候我们并不想要被关闭连接。例如，对于一个即时通讯软件，如果服务器没有消息时，我们确实不会和服务器有任何数据交换，但是如果连接被关闭了，有新消息来时，我们再也没法收到了，这就违背了“即时通讯”的设计要求。 情形二 ：通常情况下，服务器与某个客户端一般不是位于同一个网络，其之间可能经过数个路由器和交换机，如果其中某个必经路由器或者交换器出现了故障，并且一段时间内没有恢复，导致这之间的链路不再畅通，而此时服务器与客户端之间也没有数据进行交换，由于 TCP 连接是状态机，对于这种情况，无论是客户端或者服务器都无法感知与对方的连接是否正常，这类连接我们一般称之为“死链”。 情形一 中的应用场景要求必须保持客户端与服务器之间的连接正常

摘要 ： 本文介绍Cookie与Session原理，对于Cookie与Session的属性详情和其他扩展不做探讨。必须的前导知识：HTTP协议原理。 一、HTTP协议的缺陷—— 无状态 因为HTTP1.0被设计成是基于TCP协议的 短连接 ，即完成一次“请求-应答”之后会断开连接。所以，服务器接到一次HTTP请求时不知道之前是否曾经收到过同一个客户端发送来的请求，即“无状态”。这意味着如果服务器处理请求时需要上次请求的信息，客户端必须重传全部信息，这样可能导致每次连接传送的数据量巨增。 思考1：为什么HTTP被设计成短连接？能不能是长连接，这样就保存了会话状态？ 二、Cookie技术——客户端会话保持 (一)Cookie的原理 Cookie是通过HTTP协议扩展实现的，即在HTTP请求头里面增加Cookie字段，用于存储客户端信息。 Cookie的原理和实现步骤参考图1： 图1：Cookie实现会话保持步骤截图 1.客户端向Web服务器发起HTTP请求； 2.服务器在返回响应时，在HTTP响应头中设置Set-Cookie字段，该字段存储客户端信息和状态； Java实现： Cookie cookie = new Cookie("username","zhang3"); response.addCookie(cookie); 3.客户端解析服务器HTTP响应报头中的Set

导读： 使用WCF框架爱开发项目也有很长一段时间了，最开始的时候，是理解的不深，所以不写博客进行总结。后来是项目赶，发现需要总结的有很多，一直没有把WCF排上日程，尤其是最近研究EF这一块，更是研究了一些ORM框架的东西，包括Hibernate工作原理等。最后，是因为自己都会了，觉得就先不总结了吧，反正都会。现在，正式总结WCF的第一篇博客，先宏观 介绍一下。 在基本概述中，主要是从书本、网络上查找的一些基本的定义 一、基本概述 【以下内容是从维基百科上搜索的WCF的定义】 Windows Communication Foundation (WCF) is a framework for building service-oriented applications. Using WCF, you can send data as asynchronous messages from one service endpoint to another. A service endpoint can be part of a continuously available service hosted by IIS, or it can be a service hosted in an application. An endpoint can be a client of a

大纲 本系列会分为2-3篇文章. 第一篇介绍了SignalR的预备知识和原理 本文介绍SignalR以及ASP.NET Core里使用SignalR . 本文的内容: 介绍SignalR 在ASP.NET Core中使用SignalR SignalR SignalR是一个.NET Core/.NET Framework的开源实时框架. SignalR的可使用Web Socket, Server Sent Events 和 Long Polling作为底层传输方式. SignalR基于这三种技术构建, 抽象于它们之上, 它让你更好的关注业务问题而不是底层传输技术问题. SignalR这个框架分服务器端和客户端, 服务器端支持ASP.NET Core 和 ASP.NET; 而客户端除了支持浏览器里的javascript以外, 也支持其它类型的客户端, 例如桌面应用. 回落机制 SignalR使用的三种底层传输技术分别是Web Socket, Server Sent Events 和 Long Polling. 其中Web Socket仅支持比较现代的浏览器, Web服务器也不能太老. 而Server Sent Events 情况可能好一点, 但是也存在同样的问题. 所以SignalR采用了回落机制, SignalR有能力去协商支持的传输类型. Web

SAP官网的架构图 https://cloudplatform.sap.com/scenarios/usecases/authentication.html 上图介绍了用户访问SAP云平台时经历的Authentication过程。 本文使用的例子是用户访问SAP Marketing Cloud而非SAP云平台，但是原理一致。 步骤1：用户向Service provider发起服务请求。 步骤2：Service provider把这个请求重定向到提供认证的租户上，在我这个例子是SAP ID service，即account.sap.com. 这里Marketing Cloud和SAP ID Service被配置为互相信任。 请求1响应头里的302重定向字段： https://let-me-in.hybris.com/saml/idp-redirection?httpd_location=https://hybris.com/sap/bc/ui5_ui5/ui2/ushell/shells/abap/FioriLaunchpad.html 被重定向到SAP云平台的account ID service(accounts.sap.com): https://accounts.sap.com/saml2/idp/sso?sp=com:ydcHybris:spring:sp2

前言：作为目前世界上最先进的分布式版本控制系统，简单来说就是高端大气上档次！ 代码托管仓库有两种类型。远程仓库和本地仓库；两者没啥不同，纯粹为了7*24小时开机并交换大家的修改。 GitHub就是一个免费托管开源代码的远程仓库。但是对于某些视源代码如生命的商业公司来说，既不想公开源代码，又舍不得给GitHub交保护费，那就只能自己搭建一台Git服务器作为私有仓库使用。 相关git的具体介绍，有兴趣的同学可以去搜索“廖雪峰”。廖雪峰老师将git很全面的讲解了一遍，并且从中可以根据实际的操作命令能够更好的理解git。 链接地址： https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000 正文： 实验环境： centos7：172.20.6.231 #作为git的服务器端 centos7：172.20.2.240 #作为git客户端 一般来说服务器内部都有git这个命令。如果显版本低，可以自行升级。本地实验使用的是服务器内部自带的git。 服务端操作：172.20.6.231 1、创建git用户 #用来管理GIT服务，并为git用户设置密码；useradd git && passwd git 2、服务器端设置Git仓库 设置/home/data/git/gittest

某厂面试归来，发现自己落伍了！>>> 1. 什么是Cookie 1.1什么是Cookie？ Cookie 意为“小甜点”，是由 W3C 组织提出，最早由 Netscape 社区发展的一种机制。目前 Cookie 已经成为标准，所有的主流浏览器如 IE、Netscape、Firefox、Opera 等都支持 Cookie。其实Cookie就是一个键和一个值构成的，随着服务器端的响应发送给客户端浏览器。然后客户端浏览器会把Cookie保存起来，当下一次再访问服务器时把Cookie再发送给服务器。 Cookie是HTTP协议的规范之一，它是服务器和客户端之间传输的小数据。 首先由服务器通过响应头把Cookie传输给客户端，客户端会将Cookie保存起来。 当客户端再次请求同一服务器时，客户端会在请求头中添加该服务器保存的Cookie，发送给服务器。 Cookie就是服务器保存在客户端的数据！ Cookie就是一个键值对！！！ 1.2Cookie规范 Cookie大小上限为4KB； 一个服务器最多在客户端浏览器上保存20个Cookie； 一个浏览器最多保存300个Cookie； 注意，不同浏览器之间是不共享Cookie的。也就是说在你使用IE访问服务器时，服务器会把Cookie发给IE，然后由IE保存起来，当你在使用FireFox访问服务器时，不可能把IE保存的Cookie发送给服务器。

某厂面试归来，发现自己落伍了！>>> “ 数据防泄漏 ”是数据使用安全的一个名词，也是如今互联网时代，大家耳熟能详的名词。数据防泄漏、企业数据安全、个人数据安全都成为这个时代在网络安全的一个重点管控层面。也是互联网企业发展的难题，无论是政企层面，还是个人层面而言，数据防泄漏工作都是一个持续的过程，不能间断的过程。因而，“数据防泄漏”成为共同关注的话题，也是企业发展迫切的需求解决的难题。 为什么数据防泄漏如此的重要呢？目前，企业与企业之间的竞争、个人与个人之间的竞争已经是知识产权和版权的竞争了，一旦企业发生数据泄漏事件，就会给企业造成巨大的经济损失并且严重的危害企业的形象。企业数据安全如此的重要，做为发展中的企业，又该如何避免和有效的防止商业数据泄漏事件的发生？如何采取有效的举措来对企业局域网环境下的内部核心数据文件加密？ 在企业中难免会有这样的事情发生，例如：员工的某项工作没有做完，想要将公司的文档外发到自己家里的电脑上面去使用，这样就存在一个外发过程中可能会被第三方获取，以及外发出去使用有可能造成一个二次扩散的数据泄漏问题。还有就是员员工要将一些数据文件外发给合作伙伴或者是客户，这样如果直接外发出去，也存在一个二次泄漏的问题，最后就是内部员工携带笔记本出差，如果发生笔记本丢失就会造成企业数据泄漏……等等一系列有关企业可能造成数据泄漏的因素，一旦发生

某厂面试归来，发现自己落伍了！>>> 在网络编程中经常用到线程池和连接池，今天就对其中常用的线程池的基本应用场景和模型做个简单的对比分析。 1、 业务流程对比 a、 非线程池业务流模型： 上图标识了基本的非线程池的线程模型，前端 1 有多少连接则前端客户端 2 与前端服务器端 3 均需建立一对一的线程数进行响应的连接。前端服务器端 3 与后端服务器端 4 也需建立响应数目的线程进行连接处理相关业务。 当一个任务处理完毕后线程退出，在下一个任务到来的时候前端服务器端创建新的线程来处理新的任务。 b 、线程池模型： 上图标识了基本的线程池模型。前端客户端大量的连接通过服务端的任务接收线程将连接任务放入前端服务器端的任务队列中，前端服务器端起固定数量的处理线程处理前端的任务，当处理线程处理完任务后从任务队列中获取下一个处理任务。保证了前端服务器端和后端服务器端的连接数不会超过前端服务器端的处理任务线程数 n ，从而保证了后端服务器端的压力。 当处理线程处理完一个任务而任务队列中没有任务的时候线程并不退出，阻塞等待新的任务。 通过上图可以看出，当前端服务器端通过设置合理的处理线程数和任务队列大小，可以有效的屏蔽前端客户端高并发量对后端服务器端的冲击。 2、 应用场景分析对比 a、 非线程池模型 适用于单次连接任务执行时间较长，并发量不高的情况。一旦并发量很高则线程频繁创建的开销是巨大的。