Web

Connection reset 在使用HttpClient调用后台resetful服务时，“Connection reset”是一个比较常见的问题，有同学跟我私信说被这个问题困扰很久了，今天就来分析下，希望能帮到大家。例如我们线上的网关日志就会抛该错误： 从日志中可以看到是Socket socket 在read数据时抛出了该错误。 导致“Connection reset”的原因是服务器端因为某种原因关闭了Connection，而客户端依然在读写数据，此时服务器会返回复位标志“RST”，然后此时客户端就会提示“java.net.SocketException: Connection reset”。 可能有同学对复位标志“RST”还不太了解，这里简单解释一下： TCP建立连接时需要三次握手，在释放连接需要四次挥手；例如三次握手的过程如下： 第一次握手：客户端发送syn包 (syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认； 第二次握手：服务器收到syn包，并会确认客户的SYN (ack=j+1），同时自己也发送一个SYN包 (syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态； 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED (TCP连接成功）状态，完成三次握手。 可以看到握手时会在客户端和服务器之间传递一些TCP头信息，比如ACK标志、SYN标志以及挥手时的FIN标志等。 除了以上这些常见的标志头信息，还有另外一些标志头信息，比如推标志PSH、复位标志RST等。其中复位标志RST的作用就是“复位相应的TCP连接”。 TCP连接和释放时还有许多细节，比如半连接状态、半关闭状态等。详情请参考这方面的巨著《TCP/IP详解》和《UNIX网络编程》。 前面说到出现“Connection reset”的原因是服务器关闭了Connection[调用了Socket.close()方法]。大家可能有疑问了：服务器关闭了Connection为什么会返回“RST”而不是返回“FIN”标志。原因在于Socket.close()方法的语义和TCP的“FIN”标志语义不一样：发送TCP的“FIN”标志表示我不再发送数据了，而Socket.close()表示我不在发送也不接受数据了。问题就出在“我不接受数据” 上，如果此时客户端还往服务器发送数据，服务器内核接收到数据，但是发现此时Socket已经close了，则会返回“RST”标志给客户端。当然，此时客户端就会提示：“Connection reset”。详细说明可以参考oracle的有关文档：http://docs.oracle.com/javase/1.5.0/docs/guide/net/articles/connection_release.html。 另一个可能导致的“Connection reset”的原因是服务器设置了Socket.setLinger (true, 0)。但我检查过线上的tomcat配置，是没有使用该设置的，而且线上的服务器都使用了nginx进行反向代理，所以并不是该原因导致的。关于该原因上面的oracle文档也谈到了并给出了解释。 此外啰嗦一下，另外还有一种比较常见的错误“Connection reset by peer”，该错误和“Connection reset”是有区别的： 服务器返回了“RST”时，如果此时客户端正在从Socket socket 的输出流中读数据则会提示Connection reset”； 服务器返回了“RST”时，如果此时客户端正在往Socket socket 的输入流中写数据则会提示“Connection reset by peer”。 “Connection reset by peer”如下图所示： 前面谈到了导致“Connection reset”的原因，而具体的解决方案有如下几种： 出错了重试； 客户端和服务器统一使用TCP长连接； 客户端和服务器统一使用TCP短连接。 首先是出错了重试：这种方案可以简单防止“Connection reset”错误，然后如果服务不是“幂等”的则不能使用该方法；比如提交订单操作就不是幂等的，如果使用重试则可能造成重复提单。 然后是客户端和服务器统一使用TCP长连接：客户端使用TCP长连接很容易配置 (直接设置HttpClient就好），而服务器配置长连接就比较麻烦了，就拿tomcat来说，需要设置tomcat的maxKeepAliveRequests、connectionTimeout等参数。另外如果使用了nginx进行反向代理或负载均衡，此时也需要配置nginx以支持长连接 (nginx默认是对客户端使用长连接，对服务器使用短连接）。 使用长连接可以避免每次建立TCP连接的三次握手而节约一定的时间，但是我这边由于是内网，客户端和服务器的3次握手很快，大约只需1ms。ping一下大约0.93ms (一次往返）；三次握手也是一次往返 (第三次握手不用返回）。根据80/20原理，1ms可以忽略不计；又考虑到长连接的扩展性不如短连接好、修改nginx和tomcat的配置代价很大 (所有后台服务都需要修改）；所以这里并没有使用长连接。ping服务器的时间如下图： 最后的解决方案是客户端和服务器统一使用TCP短连接：我这边正是这么干的，而使用短连接既不用改nginx配置，也不用改tomcat配置，只需在使用HttpClient时使用http1.0协议并增加http请求的header信息 (Connection: Close），源码如下： 最后再补充几句，虽然对于每次请求TCP长连接只能节约大约1ms的时间，但是具体是使用长连接还是短连接还是要衡量下，比如你的服务每天的pv是1亿，那么使用长连接节约的总时间为： 神奇的是，亿万级pv的服务使用长连接一天内节约的总时间为27.78小时 (竟然大于一天）。 ...

XHTML HTML5 http://www.wkeke.cn/archives/xhtml2-html5/ 下面这些迹象都一一表明: XHTML2夭亡，而HTML5则是集万千宠爱于一身，还未出现，早已博得满堂喝彩。W3C 日前宣布将从2009年底起终止同 XHTML 2 工作组的合约，并以此暗示曾经一度野心勃勃的 XHTML 2 的正式死亡。Web 设计界是否该因此而恐慌？毕竟 XHTML 1.x 是所有对 Web 标准验证有着某种情节的人的首选，然而事实并非如此，XHTML 2.0 偃旗息鼓已有时日，W3C 只是明确了它的死亡日期，并将主要精力倾注到他们的新宠儿，HTML 5 身上。 如何看待 Web 设计师们所钟爱的 XHTML？ 要弄明白 XHTML 如何获得人们的青睐，得从 HTML4 说起。HTML 4 是一种松散的语言，它拥有很多选项，囊括了太多人们对 Web 的试验性想法，一些是好的，一些是坏的，然而，要 HTML 4 为蹩脚的网页代码负责，好比要英语为低劣的小说负责。 HTML 4 也可以结构严谨并拥有合法的语义，只要设计师们知道该如何使用它。 而 XHTML 1.0 更严格，那些验证工具更容易指出其中的错误，如果你很懒，又想保证自己的代码结构严谨，XHTML 1.x 要容易检查得多。 然而问题是，XHTML 的使命并非单单如此，XHTML 的使命在于它名字中的那个 X，X 的存在不是为了耍酷，而是因为 XHTML 事实上属于 XML。象正在为 HTML 5 细则工作的 Henri Sivonen 指出的那样，XHTML 事实上有两个意义，一是技术上的，一是市场上的。 从技术的角度，XHTML 原本是要以 application/xhtml+xml MIME 类型输出纯粹的 XML 的，然而这种情形很少见，这并非说 XML 不重要，事实上未来的 XHTML 5 将对 HTML 5 提供序列化服务。而 XHTML 的大量使用更多是基于市场的角度，换句话说，那些采用 XHTML 语法的网页仍然被浏览器按 text/html MIME 类型渲染，因此，尽管这些文档属于 XML，但它们并没被当作真正的 XML，而是按 HTML 进行渲染。 ...

HTML XHTML 什么是XHTML？与HTML相比XHTML有什么特点？ http://www.wm23.com/resource/R01/Internet_1010.htm HTML是一种基本的WEB网页设计语言，XHTML是一个基于XML的置标语言，看起来与HTML有些相象，只有一些小的但重要的区别。本文简单介绍什么是XHTML，以及与HTML相比XHTML有什么特点。 什么是XHTML？ HTML是一种基本的WEB网页设计语言，XHTML是一个基于XML的置标语言，看起来与HTML有些相象，只有一些小的但重要的区别，XHTML就是一个扮演着类似HTML的角色的XML，所以，本质上说，XHTML是一个过渡技术，结合了XML (有几分) 的强大功能及HTML (大多数) 的简单特性。 2000年底，国际W3C(World Wide Web Consortium)组织公布发行了XHTML 1.0版本。XHTML 1.0是一种在HTML 4.0基础上优化和改进的的新语言，目的是基于XML应用。XHTML是一种增强了的HTML,它的可扩展性和灵活性将适应未来网络应用更多的需求。下面是W3C的HTML工作组主席Steven Pemberton回答的关于XHTML的常见基础问题。 问: 什么是XHTML? 答: XHTML是一种为适应XML而重新改造的HTML。当XML越来越成为一种趋势，就出现了这样一个问题: 如果我们有了XML，我们是否依然需要HTML?为了回答这个问题，1998年5月我们在旧金山开了两天的工作会议，会议的结论是: 需要。我们依然需要使用HTML。因为大量的人们已经习惯使用HTML来作为他们的设计语言，而且，已经有数以百万计的页面是采用HTML编写的。 问: 为什么XHTML 1.0相对HTML 4.0独立发展? 答: 并不是这样。XHTML恰恰就是HTML 4.0的重新组织，(确切的说它是HTML 4.01，是一个修正版本的HTML 4.0，只不过以XHTML 1.0命名发行。) 它们在XML里的解释会有一些必要的差别，但另一方面，它们依然非常相似，我们可以把XHTML的工作看作是HTML 4.0基础上的延续。 问: XHTML 1.0如何实现XML标准? 答: XHTML就是一种XML应用。它采用XML的DTD文件格式定义，并运行在支持XML的系统上。这里要感谢XML的Namespaces功能，浏览器制造商不需要再创造新的私有标签(tags)，他们只需要在XHTML代码里包含XML代码片段，或者XML代码里包含XHTML代码片段。 与HTML相比XHTML有什么特点？ (1) XHTML解决HTML语言所存在的严重制约其发展的问题。HTML发展到今天存在三个主要缺点: 不能适应现在越多的网络设备和应用的需要，比如手机、PDA、信息家电都不能直接显示HTML；由于HTML代码不规范、臃肿，浏览器需要足够智能和庞大才能够正确显示HTML；数据与表现混杂，这样你的页面要改变显示，就必须重新制作HTML。因此HTML需要发展才能解决这个问题，于是W3C又制定了XHTML，XHTML是HTML向XML过度的一个桥梁。 (2) XML是web发展的趋势，所以人们急切的希望加入XML的潮流中。XHTML是当前替代HTML4标记语言的标准，使用XHTML 1.0，只要你小心遵守一些简单规则，就可以设计出既适合XML系统，又适合当前大部分HTML浏览器的页面。这个意思就是说，你可以立刻设计使用XML，而不需要等到人们都使用支持XML的浏览器。这个指导方针可以使web平滑的过渡到XML。 (3) 使用XHTML的另一个优势是: 它非常严密。当前网络上的HTML的糟糕情况让人震惊，早期的浏览器接受私有的HTML标签，所以人们在页面设计完毕后必须使用各种浏览器来检测页面，看是否兼容，往往会有许多莫名其妙的差异，人们不得不修改设计以便适应不同的浏览器。 (4) XHTML是能与其它基于XML的标记语言、应用程序及协议进行良好的交互工作。 (5) XHTML是Web标准家族的一部分，能很好在无线设备等其它用户代理上。 (6) 在网站设计方面，XHTML可助你去掉表现层代码的恶习，帮助你养成标记校验来测试页面工作的习惯。 【说明】: 本文根据部分网站上的相关资料编辑，来源包括: http://www.pconline.com.cn/pcedu/sj/wz/other/0406/385830.html http://hedong.3322.org/newblog/archives/000044.html http://www.pconline.com.cn/pcedu/sj/wz/other/0410/469461.html

使用负边距创建自适应宽度的流体布局 http://www.cnblogs.com/zzh/archive/2008/10/13/1309841.html <!DOCTYPE html> <html> <head> <title>CTS</title> <style type="text/css"> body,p,h1,h2,ul { margin:0;padding:0; } #header { background-color: #A8A754; } #footer { background-color: #A8A754; clear: both; } #mainer { width: 100%; margin-right: -250px; float: left; } #sideBar { float: right; width: 250px; color: #FFF; background-color: #36361A; } #main { margin-right: 250px; background-color: #616030; } </style> </head> <body> 顶部区域 使用负边距创建自适应宽度的流体布局 随着越来越大的浏览器的出现及普及，网站界面如何能满足不同分辨率浏览器使用者的浏览需求，逐渐成为前端开发工程师必须面对的问题。采 用百分比进行架构是个不错的主意。以往我们进行这类架构都是使用table表格。但，其实使用很小的技术就可以创建出符合WEB标准化的自适应布局。 最新文章 最新文章一 最新文章二 最新文章三 底部区域 </body> </html>

px pt em px: pixel，像素，屏幕上显示的最小单位，用于网页设计； pt: point，是一个标准的长度单位，1pt＝1/72英寸，用于印刷业； em: 即％，在CSS中，1em＝100％，是一个比率，结合CSS继承关系使用。 http://www.douban.com/note/155032221/ http://blog.csdn.net/shizhu_1010/article/details/8089510 http://orgcent.com/android-textview-linespacingextra/

html textarea TextArea <textarea rows="3" cols="30"> 这里是文本域中的文本 ... ... ... ... </textarea> Code: `` Setting TextArea Size The text area size is determined using the attributes “rows” and “cols”. You can change the size of text area by changing the values of rows and cols. Example Code: text area in status 2sdfsdfsdf

“http method, get, head, post, options, put, delete, trace, connect” https://www.cnblogs.com/machao/p/5788425.html HTTP Method 的历史: HTTP 0.9 这个版本只有 GET 方法 HTTP 1.0 这个版本有 GET HEAD POST 这三个方法 HTTP 1.1 这个版本是当前版本，包含 GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT 这 8 个方法 我们先看看HTTP 1.1 规范的中文翻译 方法定义 (Method Definitions) HTTP/1.1常用方法的定义如下。虽然方法可以被展开，但新加的方法不能认为能分享与扩展的客户端和服务器同样的语义。 Hst 请求头域 (见13.23节) 必须能在所有的HTTP/1.1请求里出现。 9.1 安全和等幂 (Idempotent) 方法 9.1.1 安全方法 (Safe Methods) 实现者应当知道软件是代表用户在互联网上进行交互，并且应该小心地允许用户知道任何它们可能采取的动作(action)，这些动作可能给他们自己或他人带来无法预料的结果。 特别的，GET和HEAD方法仅仅应该获取资源而不是执行动作 (action) 。这些方法应该被考虑是"安全"的。可以让用户代理用其他的方法，如: POST，PUT，DELETE，这样用户代理就能知道这些方法可能会执行不安全的动作。 自然的，保证当服务器由于执行GET请求而不能产生副作用是不可能的；实际上，一些动态的资源会考虑这个特性。用户并没有请求这些副作用，因此不需要对这些副作用负责。 9.1.2等幂方法 (Idempotent Mehtods) 方法可以有等幂的性质因为 (除了出错或终止问题) N>0个相同请求的副作用同单个请求的副作用的效果是一样 (译注: 等幂就是值不变性，相同的请求得到相同的响应结果，不会出现相同的请求出现不同的响应结果) 。方法GET，HEAD，PUT，DELETE都有这种性质。同样，方法OPTIONS和TRACE不应该有副作用，因此具有内在的等幂性。然而，有可能几个请求的序列是不等幂的，即使在那样的序列中所有方法都是等幂的。 (如果整个序列整体的执行的结果总是相同的，并且此结果不会因为序列的整体，部分的再次执行而改变，那么此序列是等幂的。) 例如，一个序列是非等幂的如果它的结果依赖于一个值，此值在以后相同的序列里会改变。 ...