服务器端

Cookie Cookie 是在 HTTP 协议下，服务器或脚本可以维护客户工作站上信息的一种方式。Cookie 是由 Web 服务器保存在用户浏览器（客户端）上的小文本文件，它可以包含有关用户的信息。无论何时用户链接到服务器，Web 站点都可以访问 Cookie 信息 。 目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除 。 持续的 Cookie 则保存在用户的 Cookie 文件中，下一次用户返回时，仍然可以对它进行调用。在 Cookie 文件中保存 Cookie，有些用户担心 Cookie 中的用户信息被一些别有用心的人窃取，而造成一定的损害。其实，网站以外的用户无法跨过网站来获得 Cookie 信息。如果因为这种担心而屏蔽 Cookie，肯定会因此拒绝访问许多站点页面。因为，当今有许多 Web 站点开发人员使用 Cookie 技术，例如 Session 对象的使用就离不开 Cookie 的支持 Session Session直接翻译成中文比较困难，一般都译成时域。在计算机专业术语中，Session是指一个终端用户与交互系统进行通信的时间间隔，通常指从注册进入系统到注销退出系统之间所经过的时间。以及如果需要的话，可能还有一定的操作空间。 需要注意的是

session: sessionid是一个会话的key，浏览器第一次访问服务器会在服务器端生成一个session，有一个sessionid和它对应。 存储在服务器的内存中，tomcat的StandardManager类将session存储在内存中，也可以持久化到file，数据库，memcache，redis等。客户端只保存sessionid到cookie中，而不会保存session，session销毁只能通过invalidate或超时，关掉浏览器并不会关闭session） 那么Session在何时创建呢？当然还是在服务器端程序运行的过程中创建的，不同语言实现的应用程序有不同创建Session的方法，而在Java中是通过调用HttpServletRequest的getSession方法（使用true作为参数）创建的。在创建了Session的同时，服务器会为该Session生成唯一的Session id，而这个Session id在随后的请求中会被用来重新获得已经创建的Session；在Session被创建之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中， 发到客户端的只有Session id ；当客户端再次发送请求的时候，会将这个Session id带上，服务器接受到请求之后就会依据Session id找到相应的Session

状态码类别: 1XX　　 informational 信息性状态码 2XX　　Suess 成功状态码 3XX　　Redirection 重定向状态码 4XX　　Client error 客户端错误状态码 5XX　　server error 服务器错误状态码 具体的状态码为: 200 OK 表示正常被处理 204 NO CONTENT 正常被处理 但是无返回值 一般用于客户端给服务器端发送信息, 服务器端不需要返回信息 206 PARTIAL CONTENT 响应报文包含有content-range范围中的信息. 301 Moved Permanently 永久性重定向 表示请求的资源已经被分配了新的URI 需要使用新的地址进行访问. 302 Found 临时性重定向 303 See Other 请求的资源存在另外一个URI 应该使用GET方法定向获取请求的资源 304 Not Modified 服务器端的资源未改变,可以直接使用客户端的缓存 307 Temporary Redirect 临时重定向 400 Bad Request 表示客户端请求的报文有语法错误,需要客户端修改 401 Unauthorized 表示发送的请求需要有HTTP认证, 如果是第一次打开应该弹出登录用户的提示 403 Forbidden 表示请求访问的资源被服务器拒绝,并且服务器没必要给出详细信息 404

1、首先需要安装nfs-utils 和 portmap: yum install nfs-utils portmap （安装软件，也可直接安装 yum install nfs* portmap）chkconfig rpcbind on （设置开机启动portmap）chkconfig nfs on （设置开机启动nfs）service rpcbind restart （启动portmap服务）service NFS restart （启动nfs服务） 2、服务器端配置文件/etc/exports：指定要共享的目录及权限 #：允许ip地址范围在192.168.0.*的计算机以读写的权限来访问/home/work 目录。 /home/work 192.168.0.*（rw,sync,root_squash） /home 192.168.1.105 (rw,sync) /public * (rw,sync) 配置文件每行分为两段：第一段为共享的目录，使用绝对路径，第二段为客户端地址及权限。 地址可以使用完整IP或网段，例如10.0.0.8或10.0.0.0/24，10.0.0.0/255.255.255.0当然也可以地址可以使用主机名，DNS解析的和本地/etc/hosts解析的都行，支持通配符，例如：*.chengyongxu.com 权限有： rw：read-write，可读写；

感谢：http://www.cnblogs.com/dolphinX/p/3460545.html 转自百度经验：http://jingyan.baidu.com/article/08b6a591e07ecc14a80922f1.html 网络由下往上分为 　　物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。 　　通过初步的了解，我知道IP协议对应于网络层，TCP协议对应于传输层，而HTTP协议对应于应用层， 　　三者从本质上来说没有可比性， 　　socket则是对TCP/IP协议的封装和应用(程序员层面上)。 　　也可以说，TPC/IP协议是传输层协议，主要解决数据如何在网络中传输， 　　而HTTP是应用层协议，主要解决如何包装数据。 　　关于TCP/IP和HTTP协议的关系，网络有一段比较容易理解的介绍： 　　“我们在传输数据时，可以只使用(传输层)TCP/IP协议，但是那样的话，如果没有应用层，便无法识别数据内容。 　　如果想要使传输的数据有意义，则必须使用到应用层协议。 　　应用层协议有很多，比如HTTP、FTP、TELNET等，也可以自己定义应用层协议。 　　WEB使用HTTP协议作应用层协议，以封装HTTP文本信息，然后使用TCP/IP做传输层协议将它发到网络上。” 　　而我们平时说的最多的socket是什么呢，实际上socket是对TCP/IP协议的封装

什么是Cookie？ Cookie是服务器在本地机器上存储的小段文本，它是一个简单的字符串形式的键值对。 网络服务器用HTTP头向客户端发送cookie， (一般情况下Cookie是由服务端生成的，当然js也能操作cookie) 在客户端，浏览器解析这些cookies并将它们保存到本地， 而后当浏览器访问这个服务器时，它会在任何请求上加上这些cookie。 说白了就是每次你和服务器的交互都会带着这些cookie。 什么是Session？ session，中文经常翻译为会话，其本来的含义是指有始有终的一系列动作/消息，比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程可以称之为一个session。有时候我们可以看到这样的话“在一个浏览器会话期间，...”，这里的会话一词用的就是其本义，是指从一个浏览器窗口打开到关闭这个期间。最混乱的是“用户（客户端）在一次会话期间”这样一句话，它可能指用户的一系列动作（一般情况下是同某个具体目的相关的一系列动作，比如从登录到选购商品到结账登出这样一个网上购物的过程，有时候也被称为一个transaction），然而有时候也可能仅仅是指一次连接。 然而当session一词与网络协议相关联时，它又往往隐含了“面向连接”和/或“保持状态”这样两个含义，“面向连接”指的是在通信双方在通信之前要先建立一个通信的渠道，比如打电话，直到对方接了电话通信才能开始

4GB以上超大文件上传和断点续传服务器的实现 随着视频网站和大数据应用的普及，特别是高清视频和4K视频应用的到来，超大文件上传已经成为了日常的基础应用需求。 但是在很多情况下，平台运营方并没有大文件上传和断点续传的开发经验，往往在网上找一些简单的PHP或者Java程序来实现基本的上传功能，然而在实际使用中会发现，这些基于脚本语言实现的上传功能模块性能很弱，一是不支持2GB以上的内容上传；二是无法支持断点续传；三是效率极低，单台服务器最多支持几十个并发上传连接。 当前我们要搭建一个运营级的视频服务平台，在尝试了各种产品均无法满足要求，因此最后花精力自主用C++语言实现了这一高性能上传服务器。 项目地址： http://git://10.168.4.241/up6/web/asp.net.git Hyper Upload Server 超级上传服务器 这是一款超级文件上传服务器，采用异步I/O架构，采用C++语言编码实现。它支持4GB以上超大文件上传和断点续传，支持Windows和Linux服务器平台，支持任意格式的文件上传，尤其适合大的视频网站应用。单台服务器支持1000并发上传进程，支持PC端和智能手机端主流的浏览器。 主要特性 1. 服务器端采用异步I/O架设设计，具有高性能I/O处理能力，尤其适用于超大文件上传； 2.

什么是http协议 http协议： 对浏览器客户端 和 服务器端 之间数据传输的格式规范 查看http协议的工具 1）使用火狐的firebug插件（右键->firebug->网络） 2）使用谷歌的“审查元素” Http请求 GET /day09/hello HTTP/1.1 -请求行 Host: localhost:8080 --请求头（多个key-value对象） User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9, / ;q=0.8 Accept-Language: zh-cn,en-us;q=0.8,zh;q=0.5,en;q=0.3 Accept-Encoding: gzip, deflate Connection: keep-alive –一个空行 name=eric&password=123456 --（可选）实体内容 请求行 GET /day09/hello HTTP/1.1 http协议版本 http1.0：当前浏览器客户端与服务器端建立连接之后，只能发送一次请求，一次请求之后连接关闭。 http1.1

前面说过，TLS/SSL协议可以和应用层协议结合，例如HTTP，SMTP和FTP等。提供数据完整性和机密性TLS/SSL协议建立在TCP或UDP之上，应用层协议之下，任何应用层协议使用了TLS，都要先把数据经过TLS/SSL处理。客户端浏览器连接服务器的443端口，发送HTTP数据到TLS/SSL协议，再到传输层TCP处。TLS协议部分有握手层和加密层两部分，握手层在上，加密层在下，握手层负责完成密码套件，也就是使用的加密算法，密钥参数生成和交换，发送证书等，最后完成密钥协商得到预备主密钥，预备主密钥用过密钥衍生算法得到主密钥，之后就可以把这它交给下面的加密层，完成数据加密和解密。加密层的功能顾名思义，在拿到握手层提供的主密钥后，对HTTP数据提供完整性和机密性保证。 握手层和加密层流程 在握手层，负责交换随机数，密钥套件和密钥协商等，无论是RSA还是DH方式，首先都是客户端发送自己支持的密码套件给服务器，服务器从中选择一个密钥套件，完成密码套件的协商，然后服务器端发送自己的证书给客户端进行身份验证，客户端完成身份验证后，可以开始密钥协商。RSA密钥协商，客户端直接把加密后的预备主密钥发送给服务器端，DH密钥协商则先由服务器端发送DH参数和DH公钥给客户端，客户端根据DH参数生成自己的密钥对，再把客户端DH公钥发送给服务器端，完成密钥协商。接下来就可以在通信中进行数据的加密和解密。

Tomcat基础《一》----WEB技术 Tomcat基础《二》----Tomcat基础介绍 负载均衡 动态服务器的问题，往往就是并发能力太弱，往往需要多台动态服务器一起提供服务。如何把并发的压 力分摊，这就需要调度，采用一定的调度策略，将请求分发给不同的服务器，这就是Load Balance负载 均衡。 当单机的Tomcat，演化出多机多级部署的时候，一个问题便凸显出来，这就是Session。而这个问题的 由来，都是由于HTTP协议在设计之初没有想到未来的发展。 HTTP的无状态，有连接和短连接 无状态：指的是服务器端无法知道2次请求之间的联系，即使是前后2次请求来自同一个浏览器，也没有任何数据能够判断出是同一个浏览器的请求。后来可以通过cookie、session机制来判断。 浏览器端第一次HTTP请求服务器端时，在服务器端使用session这种技术，就可以在服务器端产生一个随机值即SessionID发给浏览器端，浏览器端收到后会保持这个SessionID在Cookie当中，这个Cookie值一般不能持久存储，浏览器关闭就消失。浏览器在每一次提交HTTP请求的时候会把这个SessionID传给服务器端，服务器端就可以通过比对知道是谁了 Session通常会保存在服务器端内存中，如果没有持久化，则易丢失，为了速度，用了字典的技术 Session会定时过期。过期后浏览器如果再访问