长连接

1.HTTP协议的五大特点 1)支持客户/服务器模式 2)简单快速 3)灵活 4)无连接 每次连接只处理一个请求，服务器处理完客户的请求，并受到客户的应答后，断开连接。 5)无状态 协议不会记录服务器客户端状态。 2.保持HTTP连接状态的两种方式 1)Cookie 在访问统一网站时，可以将信息写入cookie，方便在不同的页面间提取信息。 2)Session Session保存在服务器上，同时将标识Session的SessionId传递给客户端浏览器，保存在cookie中，浏览器关闭后，这个cookie就会被清掉。 浏览器每次请求都会额外加上这个参数值，服务器根据这个SessionId，就能取得客户端的数据信息。 3.什么是HTTP长连接，短连接 HTTP的长连接，短连接本质上是TCP长连接，短连接。 在HTTP/1.0中，默认使用的是短连接。 即浏览器和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。这样，如果一个网页中包含其他的web资源，如JavaScript文件，图像文件，CSS文件等，都需要建立连接。 从HTTP/1.1起，默认使用长连接。我们可以看到响应头有这样一行代码：Connection:keep-alive 当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页

HTTP实现长连接 HTTP是无状态的 也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个 HTTP 会话 HTTP1.1和HTTP1.0相比较而言，最大的区别就是增加了持久连接支持(貌似最新的 http1.0 可以显示的指定 keep-alive),但还是无状态的，或者说是不可以信任的。 如果浏览器或者服务器在其头信息加入了这行代码 Connection:keep-alive TCP连接在发送后将仍然保持打开状态，于是，浏览器可以继续通过相同的连接发送请求。保持连接节省了为每个请求建立新连接所需的时间，还节约了带宽。 实现长连接要客户端和服务端都支持长连接。 如果web服务器端看到这里的值为“Keep-Alive”，或者看到请求使用的是HTTP 1.1（ HTTP 1.1 默认进行持久连接 ），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点， web服务器需要在返回给客户端HTTP头信息中发送一个Content-Length（返回信息正文的长度）头，最简单的实现方法是

讨论Socket必讨论长连接和短连接 一、长连接和短连接的概念 　　1、长连接与短连接的概念：前者是整个通讯过程，客户端和服务端只用一个Socket对象，长期保持Socket的连接；后者是每次请求，都新建一个Socket,处理完一个请求就直接关闭掉Socket。所以，其实区分长短连接就是：整个客户和服务端的通讯过程是利用一个Socket还是多个Socket进行的。 　　可能你会想：这还不简单，长连接不就是不关Socket嘛，短连接不就是每次都关Socket每次都new Socket嘛。然而事实其实并没有那么简单的，请继续看下面的整理 　　2、关闭流而保持Socket正常? 　　　　在网上百度了一下，发现很多人都是以关闭流还是关闭Socket来区分长连接和短连接的，其实，个人感觉这种区分方法并没有什么意义：因为这里面有一个事实是，流关闭之后，便不能进行消息的发送（对应关闭输出流）或者接受（对应关闭输入流），因为其实关闭了对应的流，对应连接也就关闭了（这里所说的连接是发送消息的通道！），所以，流关闭而保持Socket开启，是没有达到长连接的效果，贴上测试代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 /

Socket的长连接和短连接 讨论Socket必讨论长连接和短连接 一、长连接和短连接的概念 　　1、长连接与短连接的概念：前者是整个通讯过程，客户端和服务端只用一个Socket对象，长期保持Socket的连接；后者是每次请求，都新建一个Socket,处理完一个请求就直接关闭掉Socket。所以，其实区分长短连接就是：整个客户和服务端的通讯过程是利用一个Socket还是多个Socket进行的。 　　可能你会想：这还不简单，长连接不就是不关Socket嘛，短连接不就是每次都关Socket每次都new Socket嘛。然而事实其实并没有那么简单的，请继续看下面的整理 　　2、关闭流而保持Socket正常? 　　　　在网上百度了一下，发现很多人都是以关闭流还是关闭Socket来区分长连接和短连接的，其实，个人感觉这种区分方法并没有什么意义：因为这里面有一个事实是，流关闭之后，便不能进行消息的发送（对应关闭输出流）或者接受（对应关闭输入流），因为其实关闭了对应的流，对应连接也就关闭了（这里所说的连接是发送消息的通道！），所以，流关闭而保持Socket开启，是没有达到长连接的效果，贴上测试代码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

讨论Socket必讨论长连接和短连接 一、长连接和短连接的概念 　　1、长连接与短连接的概念：前者是整个通讯过程，客户端和服务端只用一个Socket对象，长期保持Socket的连接；后者是每次请求，都新 建一个Socket,处理完一个请求就直接关闭掉Socket。所以，其实区分长短连接就是：整个客户和服务端的通讯过程是利用一个Socket还是多个 Socket进行的。 　　可能你会想：这还不简单，长连接不就是不关Socket嘛，短连接不就是每次都关Socket每次都new Socket嘛。然而事实其实并没有那么简单的，请继续看下面的整理 　　2、关闭流而保持Socket正常? 　　　　在网上百度了一下，发现很多人都是以关闭流还是关闭Socket来区分长连接和短连接的，其实，个人感觉这种区分方法并没有什么意义：因为 这里面有一个事实是，流关闭之后，便不能进行消息的发送（对应关闭输出流）或者接受（对应关闭输入流），因为其实关闭了对应的流，对应连接也就关闭了（这 里所说的连接是发送消息的通道！），所以，流关闭而保持Socket开启，是没有达到长连接的效果，贴上测试代码： //发送核心方法 public String send(String send) throws IOException { String rtn = null; BufferedWriter writer = null;

近年，不论是正在快速增长的直播，远程教育以及IM聊天场景，还是在常规企业级系统中用到的系统提醒，对websocket的需求越来越大，对websocket的要求也越来越高。从早期对websocket的应用仅限于少部分功能和IM等特殊场景，逐步发展为追求支持高并发，百万、千万级每秒通讯的高可用websocket服务。 面对各种新场景对websocket功能和性能越来越高的需求，不同的团队有不同的选择，有的直接使用由专业团队开发的成熟稳定的第三方websocket服务，有些则选择自建websocket服务。 作为一个具有多年websocket开发经验的老程序猿，经历了GoEasy企业级websocket服务从无到有，从小到大的过程，此文是根据过去几年在GoEasy开发过程中踩过的坑，以及为众多开发团队提供websocket服务、与众多开发者交流中的总结的一些经验和体会。 这次主要从搭建websocket服务的基本功能和特性方面做一些分享，下次有机会再从构建一个高可用websocket时要面对的高并发，海量消息，集群容灾，横向扩展，以及自动化运维等方面进更多的分享。 以下几点是个人认为在构建websocket服务时必须要考虑的一些技术特性以及能显著提高用户体验的功能，供各位同学参考： 1.建立心跳机制 心跳机制几乎是所有网络编程的第一步，经常容易被新手忽略。因为在websocket长连接中

先理解下长连接和短链接 短连接: 短连接就是每次请求一个资源就建立连接，请求完成后连接立马关闭。每次请求都经过“创建tcp连接->请求资源->响应资源->释放连接”这样的过程 长连接: 长连接(persistent connection)，就是只建立一次连接，多次资源请求都复用该连接，完成后关闭。要请求一个页面上的十张图，只需要建立一次tcp连接，然后依次请求十张图，等待资源响应，释放连接。 client发出的HTTP请求头需要增加connection:keep-Alive字段。 web-service端需要能识别到connection:keep-alice字段，并且在http的response里指定connection:keep-Alive字段，告诉client我们提供keep-alive服务，允许client暂时别关闭socket链接。 http 1.0版本中要实现长连接必须在http请求头显示指定Connection:keep-alive http 1.1版本中默认开始了keep-alive。 需要关闭keep-vlive的话在请求头指定connection:close 现在大多数浏览器都支持HTTP 1.1协议，所以keep-alive都是默认打开的，一旦client和server达成一致长连接就建立好了。 以NGINX 为例： keepalive_timeout

在B/S模型的Web应用中，客户端常常需要保持和服务器的持续更新。这种对及时性要求比较高的应用比如：股票价格的查询，实时的商品价格，自动更新的twitter timeline以及基于浏览器的聊天系统（如GTalk）等等。由于近些年AJAX技术的兴起，也出现了多种实现方式。本文将对这几种方式进行说明，并用jQuery+tornado进行演示，需要说明的是，如果对tornado不了解也没有任何问题，由于tornado的代码非常清晰且易懂，选择tornado是因为其是一个非阻塞的(Non-blocking IO）异步框架（本文使用2.0版本）。 在开始之前，为了让大家有个清晰的认识，首先列出本文所要讲到的内容大概。本文将会分以下几部分： 普通的轮询（Polling) Comet ：基于服务器长连接的“服务器推”技术。这其中又分为两种： 基于AJAX和基于IFrame的 流（streaming）方式 。 基于AJAX的 长轮询（long-polling）方式 。 WebSocket 古老的轮询 轮询最简单也最容易实现，每隔一段时间向服务器发送查询，有更新再触发相关事件。对于前端，使用js的setInterval以AJAX或者JSONP的方式定期向服务器发送request。 var polling = function(){ $.post('/polling', function(data,

今天主要介绍一款高效的性能测试工具wrk。wrk的使用方式和apache bench这些工具也大体相似，通过命令行的方式即可发起。但是wrk比起apache bench更为高效，因为它支持多线程，更容易发挥多核CPU的能力，甚至可以压满CPU。wrk还支持Lua脚本来提供更多的参数定制、参数加密等需求，灵活度更高。 安装 wrk支持大部分UNIX系统，不支持windows系统。安装过程比较简单，从github克隆项目到本地，再在项目路径下make即可，在此就不详述，具体可查看github文档。 基础使用 wrk -t12 -c400 -d30s http://127.0.0.1:80/index.html 以上命令行表示对本地80端口的index.html文件发起请求，压测时间持续30秒，并发12线程，保持400个HTTP连接请求。 输出结果： Running 30s test @ http://127.0.0.1:80/index.html 12 threads and 400 connections Thread Stats Avg Stdev Max +/- Stdev Latency 90.43ms 201.95ms 1.99s 88.34% Req/Sec 1.79k 1.80k 21.57k 89.17% 577891 requests in 30.09s, 188

Comet4J(Comet for Java)是一个纯粹基于AJAX(XMLHTTPRequest)的服务器推送框架，消息以JSON方式传递，具备长轮询、长连接、自动选择三种工作模式。 功能特性 推送消息广播。 推送定向消息。 提供连接上线前、上线、下线前、下线、发送消息等多种可处理事件。 消息缓存机制，确保长轮询工作模式下不丢失消息。 客户端正常下线，服务端可立即感知。 客户端异常停止工作，服务端可定时检查并感知。 以注册通道应用的方式，让开发者对框架功能进行扩展，实现自己的应用。 框架特性 独立小巧，不依赖于第三方包。 与应用紧密集成，无需独立应用或服务器。 与Session无关的连接机制，为开发人员提供最大程度的功能可控性。 面向事件编程，客户端与服务器端均为事件驱动开发模式，提供了良好的可扩展性机制。 各项性能参数均可配置。 支持多种主流浏览器，并支持Air应用环境。 支持XMLHTTPRequest对象的浏览器均可支持长轮询工作模式，但不一定能够支持长连接。 浏览器/平台 版本 长轮询 长连接 Internet Explorer 6,7,8,9 √ X FireFox 3.0+(更底版本未知) √ √ Chrome 7.0+(更底版本未知) √ √ Safari 5+(更底版本未知) √ √ Opera 11.10+(更底版本未知) √ X Air 1.5+(更底版本未知